NEO PI: industrial data historian for regulated environments

An industrial data historian is software that continuously records time-stamped measurements from the plant floor — sensors, machines, PLCs and SCADA systems — and stores them, with their quality and their asset context, for later query and analysis. It is also called a process historian, a manufacturing historian or, in its classic form, a process information system.

Underneath, a historian is a time series database specialised for industrial signals: high ingestion rates, out-of-order and delayed readings, per-point quality codes, and aggregation over long retention windows. What separates a historian from a generic database is the context layer above it — the measurement is not a lone number but a reading of a named asset, in a named area, of a named plant.

NEO PI is that historian for regulated manufacturing. It ingests over OPC-UA, OPC-DA, MQTT, LoRaWAN and REST, organises everything under an ISA-95 asset hierarchy, and exposes it as a Unified Namespace for industrial IoT that MES, quality and analytics systems read from — the data foundation Industry 4.0 and smart manufacturing programmes depend on.

In pharmaceutical and other GMP manufacturing, a process value is not just an operational figure — it is evidence. Regulators expect records that satisfy ALCOA+ (attributable, legible, contemporaneous, original, accurate, and complete, consistent, enduring, available), and frameworks such as FDA 21 CFR Part 11 and EU GMP Annex 11 set expectations for electronic records, audit trails and electronic signatures.

A spreadsheet exported from a datalogger fails most of those tests at once: it is not contemporaneous, its origin is not attributable, and nothing prevents a silent edit. A modern historian closes that gap by capturing the reading at the source, keeping the original event write-once, and recording every configuration change in a hash-chained audit trail.

That is what makes a historian part of a digital compliance strategy rather than a purely technical purchase — and why it belongs inside the scope of your computerised system validation under GAMP 5.

When the format is proprietary: codecs

Not every manufacturer follows a standard. A codec is a declarative expression that translates a vendor’s raw payload into measurements — configured through the interface, tested before saving, with an AI-assisted draft from a sample payload. In practice: equipment sending {"temp_raw":247} starts recording 24.7 °C without a line of code and without waiting for a release, so connecting a new device is a configuration task rather than a project.

Data goes out too: data forwarding

Data forwarding rules deliver readings to external systems by webhook (HMAC-signed, token-authenticated) or MQTT publication, with optional payload transformation, batched delivery, a durable retry queue and automatic shutoff when a destination keeps failing. The durable queue is what keeps a downstream outage from turning into a gap in your records.

Connecting the installed base is a project in itself — our industrial IoT solution covers the wider picture, and connecting the shop floor over OPC-UA and MQTT walks through what that looks like in practice.

Upstream, NEO PI speaks to the control layer directly: OPC-UA and OPC-DA for PLCs and SCADA systems, MQTT for edge gateways and industrial IoT brokers, LoRaWAN for wireless sensors in areas with no network, and REST for anything able to POST. Proprietary payloads are handled by codecs rather than by custom development.

Downstream, it is a source rather than a destination. Manufacturing execution and the electronic batch record read current values and history over the read API; ERP, LIMS and BI tools consume the same REST and SSE endpoints; and data forwarding pushes readings out by webhook or MQTT where a system prefers to be fed. Scoped read keys mean each consumer sees only the assets it should.

The electronic batch record drives production: procedures, work orders, in-process controls. Historically, process values reach that record by manual transcription — an operator reads the display and types. That is simultaneously the slowest and the most fragile step of the record: subject to misreading, typing errors and delay, and it demands second-person review precisely because of that.

With NEO PI, the value comes from the historian:

• the in-process control in NEO EBR reads the measurement directly from the corresponding asset in PI
• the value arrives with its origin timestamp and quality, not the time someone typed it
• the batch record points to immutable data, traceable back to the raw event
• out-of-range deviations stand out against the full history, not an isolated point

EBR consumes PI through the read API, which exposes a navigable name space — a hierarchical path of the form plant/area/asset/measurement, the so-called namespace — with current-value reads, history queries with aggregations and live event subscription over SSE. All authenticated by scoped read keys that limit each consumer to exactly the assets and measurements it should see: the packaging team does not get the reactor data.

That API is an open protocol, and nothing about it is NEO-specific. NEO W&D, for weighing and dispensing reads weights from it the same way; NEO OEE, for equipment performance reads downtime; and any third-party system — MES, LIMS, ERP, a BI tool — consumes it over plain REST and SSE. PI is a layer your plant owns, not a captive component of one suite.

Trustworthy readings are the foundation of data integrity and the ALCOA+ principles, and of the digital compliance posture an inspection actually tests. If you are still mapping the route from paper, the paper-to-paperless roadmap for pharmaceutical manufacturing sets out the usual sequence — and where a historian fits into it.