From Level 0 to 1: Connecting the PLCs You Already Have

Physical AI does not start with the robot. It starts with the data of the machine you already have. This article describes the engineering of the first rung: moving from a plant where data lives inside each device to a plant where every device speaks a common language and the data reaches one place with time and context. Inventory of sources, protocol choice, sampling rate, timestamping, edge buffering, a canonical naming model and connection security, with the criteria for deciding each one.

Inventory of sources: what you have and where to start

On the Physical AI Ladder, level 0 is an isolated plant: the data exists, but it lives inside each machine, it is read on the panel screen or written on a report, and there is no comparable history and no common clock. Level 1 is a connected plant: the equipment speaks a common language and the data reaches one place with time and context. The jump between the two is not a product, it is engineering work on the perception layer. The general guide to the framework is physical AI in manufacturing: what it is, what it is not and why it starts with data; this article stays inside the first rung.

It helps to place that layer inside the full loop. Perceiving is not one single thing: it is an acquisition chain (sensor, conditioning, sampling and timestamp) followed by a state estimation that turns numbers into meaning. Everything that follows in this article belongs to the first of those two stages, and its quality bounds the quality of all the rest.

The inventory starts with the families of sources almost any plant already has. The question to ask about each one is not whether it can be connected, but what data it holds, with what fidelity and what is lost along the way:

• Programmable controllers (PLCs). They are the richest source: machine states, part and reject counters, alarms and process variables. Their memory is organised by address and not by meaning, so a register named after its address says nothing about which quantity it is or in which unit.
• Variable frequency drives and starters. They know speed, estimated torque, current, running hours and drive faults. It is a source of energy and motor diagnostics that usually falls outside the scope because nobody asks for it.
• Energy meters and power analysers. They give active and reactive power, accumulated energy and supply quality. At the right cadence they allow consumption to be allocated to a line and to a product, which the bill does not.
• Scales, field instruments and standalone sensors. Flow meters, pressure transmitters, load cells, probes added for a project that ended. Often they are not even on the current electrical drawings.
• Existing SCADA and historians. They already hold consolidated data and sometimes context, with two warnings: the timestamp may be the one of their own ingestion rather than the origin, and their aggregates may have lost the resolution needed downstream. When to lean on them and when to read from the device is what the role of the industrial historian discusses.
• Management systems. The ERP and the production system contribute no signal, they contribute context: order, batch, product, shift, planned time. Without that context the signal can be counted, but it cannot be explained.

To decide where to start there is a single rule that avoids the most expensive mistake of this phase: scope is chosen by asset relevance, not by protocol availability. Connecting first whatever already spoke a convenient protocol leaves out the old machine that causes half the downtime. The practical order is to rank assets by impact (bottleneck, accumulated downtime, consumption, rejects), keep the first ones and connect them end to end until a defensible indicator is visible, before extending to the easy ones.

Every selected signal needs a minimum record before anything is touched: the asset it belongs to, quantity and unit, range and scale, nature (discrete state, counter or continuous variable), the frequency of the phenomenon it represents, the available reading path and the person who owns it. That list is the first deliverable of level 1 and it is also the criterion used afterwards to check whether level 1 has been reached.

Industrial protocols: which one to use in each case

A protocol does two different things: it transports values and it transports meaning. The old ones only do the first, and everything they do not transport has to be declared by hand in the capture layer. That is the practical difference that orders the choice, far more than speed or fashion. The detailed comparison of the two dominant families is in OPC UA versus MQTT.

The selection criteria, as five questions in order of weight:

1. What does the device already speak? The protocol already in service almost always wins, because it does not force any change to the control system.
2. Which one carries more semantics? Between two available paths, the one that carries type, unit and quality saves declaration work that otherwise gets paid for with interest.
3. Does it allow publication on change? Subscription on change avoids polling and reduces both the load on the device and the loss of short events.
4. Can it be segmented and encrypted? A protocol that forces inbound ports into the control network conditions the whole security architecture.
5. How many protocols go upwards? One. Seven can coexist below; above the capture layer there must be a single model, not seven dialects.

One clarification about the direction of communication at this level: the capture layer reads and does not write. Writing belongs to level 3, where the loop closes with a catalogue of authorised actions, supervision and traceability. Mixing them on the first rung turns a data project into a change to the control system.

Sampling rate: choose it signal by signal

There is no globally correct sampling rate. It is set per variable, according to the phenomenon you want to be able to reconstruct. The theoretical starting point is the Nyquist criterion: to reconstruct a signal you must sample above twice its highest component. In industrial practice you work with five to ten times the frequency of the phenomenon, because the goal is not only to avoid the error but to see the shape of the curve and be able to explain it.

Before sampling there is one condition that cannot be fixed afterwards. If the signal has content above half the sampling rate, that content does not disappear: it folds back onto the useful band and shows up as a false component, indistinguishable from a real one. That is why the antialiasing filter is analogue and sits before the converter. No later processing separates what has already been mixed.

Undersampling is the obvious mistake: it loses events and produces indicators that come out high and false, which is worse than not having them. Oversampling is the expensive and silent mistake, and it is worth spelling out why. It multiplies the volume stored across every year of retention. It makes every query more expensive, because aggregates walk far longer series. It loads the controller CPU when it is implemented through polling. And, above all, it adds no information: the real bandwidth is set by the sensor and conditioning chain, not by the sampler. Ten samples per second from a probe with a one minute time constant cost ten times as much and say the same.

There is a frequent confusion worth undoing: the cadence of the control loop is not the cadence at which you should historise. According to the 5G-ACIA and ZVEI white paper on the integration of industrial Ethernet networks with 5G (November 2019), common cycle times in periodic industrial communication range from 10 ms to 0.5 ms. That is the rate at which the control system closes its loop, and it is right that it lives inside the cabinet. Historising every plant variable at that rate does not add analytical capability, it adds cost.

Timestamping: why the server clock is not enough

A number with no instant and no asset identity is not data, it is a figure. And the instant must be the one at source, as close to the sensor as possible, never the one at ingestion. The reason is concrete: if the gateway or the platform stamps the data on arrival, any network delay displaces the events. That displacement is neither uniform nor random, it is largest exactly when the network is worst, which is exactly the moment of the fault you wanted to explain. Causal order is destroyed at the only moment it mattered.

What has to be required is not just average accuracy, it is a bound on the variability of the delay. That variability has a name, jitter, and it weighs more than the mean: a large but constant delay can be compensated, a variable one cannot. A reasonable target is that the stamp error be better than half the sampling period of the fastest channel that signal will be correlated with.

From that come two clearly different working regimes:

• Tens of milliseconds. This is what a well deployed NTP achieves on the plant network, and it is enough to calculate OEE, allocate energy, compare shifts and analyse a day of production. NTP synchronises in software by estimating the round trip delay, and its limit shows up when the two paths are not symmetric or when the operating system introduces delays of its own.
• A millisecond or better. This is needed to order events causally across different devices, that is, to answer what tripped first when a fault cascade lasts less than a second. That is where PTP comes in, the precision time protocol defined in IEEE 1588-2019, approved by the IEEE Standards Association on 7 November 2019 and published on 16 June 2020, which works in the sub-microsecond range when switches and network interfaces stamp packets in hardware.

Above those two regimes sits the domain of motion applications. The same 5G-ACIA and ZVEI white paper (November 2019) notes that the working clock domain, on which robots and motion control rely, requires synchronisation of less than or equal to 1 microsecond, with a tendency to push accuracy to 100 nanoseconds. That level of demand is not imposed by analytics, it is imposed by axis coordination, and it comes with delivery guarantees on the network itself. That is the territory of TSN: the time-sensitive networking profile for industrial automation, IEC/IEEE 60802, was published on 29 June 2026 according to the IEEE 802.1 TSN Task Group, so it is now a published standard and no longer a draft.

Two implementation details that get forgotten and cost dearly. First: always store in universal time, with the time zone as context. Storing local time produces, twice a year, one shift of twenty-three hours and another of twenty-five, and breaks any year on year comparison without anyone noticing. Second: clock accuracy has to be measurable. The evidence that a plant is synchronised is the same event seen by two different systems, with their two timestamps side by side.

Frequency, timestamp, context and retention are not loose requirements: they form a substrate that hardens as you climb, and every rung inherits everything from the one below.

Edge buffering: what happens when the network drops

The edge is compute placed in the plant, next to the equipment, and it exists for two reasons: to meet latencies and to keep operating when the link to the outside is gone. The second decides whether the history is usable: a layer that depends on the network in order not to lose data has holes precisely during incidents, which are the periods most consulted afterwards.

The behaviour to require can be stated in five points:

• Local store and forward. Whatever cannot be sent is persisted to disk on the edge itself and forwarded when the link returns, with the data keeping its source timestamp. This is what makes backfill possible: if the stamp came from ingestion, the whole buffer would collapse into the instant of reconnection.
• Explicit sizing. Autonomy is calculated: bytes per second across all signals times the hours of outage you want to survive. That number should be written down and tested by disconnecting the link on purpose.
• Ordered and idempotent replay. On reconnection you must avoid duplicates and avoid the backfill trampling aggregates already computed. The natural key is asset, signal and source instant, and recomputing the affected aggregates must be a planned operation.
• A declared full-buffer policy. When an outage exceeds the autonomy you have to decide in writing what gets discarded and record it. A buffer that silently overflows produces a history that lies without warning.
• Gaps are marked as gaps. Interpolating in silence is manufacturing data. Completeness is measured per channel and per period, never globally: an aggregate 99% can hide a whole channel down for an entire shift, and gaps are not random, they cluster in the unusual hours.

The architectural detail of this layer, including sizing and replay strategies, is developed in industrial edge buffering.

Normalisation and a canonical naming model

The most common reason a three year history turns out to be useless is not technical, it is governance: someone renamed, rescaled or reused a signal and it was not recorded. That is why the naming model is decided before the first device is connected, not after the fiftieth.

The principle is easy to state and hard to sustain: you model the asset, not the controller addressing. A name that replicates the memory address forces you to know the PLC program to interpret it and breaks when someone reorganises the blocks. The canonical name describes a stable physical hierarchy: plant, area, line, cell, asset and quantity. That hierarchy is the basis of a unified namespace, which is the single interface offered upwards; the full pattern is in what a unified namespace is and how it is designed.

Every value must travel with a minimum context, and this is the one to require:

• A stable asset identity, independent of the vendor, of the equipment model and of the register address. If the PLC is replaced, the name does not change.
• Quantity and unit, normalised at the edge. A system that mixes bar and kilopascals produces meaningless aggregates that nobody detects until someone adds up two lines.
• Scale and range, so an out of range value can be told apart from a scaling fault and so what comes in can be validated automatically.
• Data quality with explicit states: good, uncertain, bad, substituted. A substituted value travelling as good contaminates any later analysis.
• A version of the signal definition, with a date. It is what allows a history that crosses a change of scale or of meaning to be read correctly.

All of this is sustained by a signal dictionary with a named owner and versioned changes. How that semantic model is built and how it is linked to order, product and shift is detailed in industrial data contextualisation. Redoing it late is not just renaming: it forces reprocessing the entire history, and that is why it pays to take the cost at the beginning, when the history is weeks old.

Connection security: segmentation, traffic direction and 62443

Connecting the plant widens its exposed surface, and the priority in an industrial environment is not the same as in an office system: here availability and the safety of people come first, because a failure produces not an annoyance but a stoppage or harm. The reference framework is the ISA/IEC 62443 series, which defines requirements and processes for implementing and maintaining secure industrial automation and control systems. According to the ISA (consulted in September 2026), the series is organised in four groups: terminology and models, programme requirements for asset owners and service providers, risk assessment and system security requirements, and the development lifecycle and component requirements. The document that sets what the asset owner has to do is IEC 62443-2-1, whose edition 2.0 was published in August 2024 according to the IEC Webstore.

In practice, for a capture layer, that means four decisions:

1. Segmentation into zones and conduits. The control network is a zone with its own requirements and everything entering or leaving does so through a declared conduit. Management traffic does not share a segment with cyclic traffic: when it does, the symptom is intermittent stoppages with no apparent cause that burn confidence in the project.
2. One-way traffic initiation. The connection is always initiated by the capture layer from the inside out. No inbound ports are opened into the control network. This is the technical argument that usually decides in favour of publishing on change to a broker rather than a query initiated from outside.
3. Read without write, and separate permissions. At level 1 the account that reads has no write permission on any device. When the loop is later closed, writing arrives with its own account, its closed catalogue of actions and its record of who approved each one.
4. Identity, encryption and logging. Named accounts instead of shared credentials, certificates and security policies enabled in OPC UA, encrypted transport in MQTT and a record of which system reads which signal and from where. Without it you cannot answer the question that arrives on the day of the incident.

On top of this comes an operational constraint managed the same way: the capture layer must not be able to degrade the process. That means declared limits on cadence and on connections per device, bounded timeouts and a failure behaviour that never blocks the controller.

Typical mistakes and how to detect them

The following failures share their symptom with far more dramatic problems, which is why it pays to know the concrete test that tells them apart.

• The easy things get connected and what matters is left out. Scope was chosen by protocol availability. Detect it by crossing connected assets with the downtime breakdown of the last quarter: if the equipment that leads the losses is not connected, the scope is wrong.
• Timestamp set at ingestion. Detect it by causing a brief link outage and looking at the history afterwards: if the events from the outage appear bunched at the instant of reconnection instead of spread over time, the stamp is not from source.
• Polling where change of state capture was needed. Detect it by plotting the distribution of stop durations: if it cuts off abruptly around the polling period, the shorter stops do not fail to exist, they fail to be seen.
• Oversampling. Detect it by comparing storage growth per signal with the real bandwidth of the sensor. If a variable with a time constant of minutes takes up as much as an energy meter at one second, there is cadence to spare.
• Badly declared units or scales. Detect it with two cheap checks: validate physically plausible ranges and close a balance, for instance the sum of line consumptions against the main meter.
• Invisible gaps under a good average. Detect it by replacing the global completeness figure with an availability panel per channel and per shift. The evidence that there are no gaps is the panel, not the statement.
• Names that replicate the controller addressing. Detect it by asking someone who did not program the machine to interpret ten signals picked at random. If they need the PLC program to know what they are, the semantic model does not exist.
• Local time in the aggregates. Detect it by looking in the history for the two daylight saving weekends: if shifts of twenty-three and twenty-five hours show up, storage is not in universal time.

None of these eight failures is a product problem and none is solved by changing tool. All of them are solved by deciding beforehand: what gets connected first, where the clock is stamped, what each signal is called and who owns it. That, in short, is the real content of the first rung of the ladder.

Frequently asked questions about connecting existing PLCs

The full architecture everything above rests on is described in the industrial data platform, and the framework that places this rung inside the whole path is in the physical AI guide. If you want to review your plant inventory and the order of connection, tell us what equipment you have.