From Level 1 to 2: The Plant That Knows What Is Happening

A level 1 plant has the data of its equipment in one place, with time, unit and asset identity. That is still not knowing what is happening. The jump to level 2 of the Physical AI Ladder consists of turning signals into statements about the process: how much is produced, why it stops, how much energy each part costs and what is outside normal right now. This guide explains how that jump is made, what it requires and where it breaks.

From signal to indicator

A level 1 system answers questions about signals: what value the temperature of furnace 2 had last Tuesday at 14:03. A level 2 system answers questions about the process: how long line 3 was stopped last Tuesday for lack of material and how many parts that stop cost. The difference is not one of data volume or computing power. It is a change of object.

In control engineering terms, level 1 transports observations and level 2 performs state estimation: it reconstructs what is happening to the process from noisy, partial and unordered measurements. In plant language, estimating state means going from "digital input 7 is at zero and the counter is not advancing" to "line 3 has been in a micro-stop for forty seconds for lack of material upstream". That jump is exactly what separates one level from the other.

It is made of three transformations, and they are worth treating separately because they fail for different reasons:

Time aggregation. From samples to intervals. A series of instantaneous states becomes episodes with a start, an end and a duration. This is where it is decided what counts as a stop and what counts as a fluctuation, and that decision is not made by the algorithm: it is made by a written definition.
Context assignment. Each interval is given the order, the product, the shift and the operating mode that were in force. It is the part most often underestimated and the one that breaks the most indicators when it is missing.
Classification. The episode is given a meaning from a closed catalogue: micro-stop, breakdown, changeover, lack of material, trial. Without a closed catalogue there is no possible aggregation, because every person writes the reason in different words.

None of the three is automatic, and all three need a governance decision before a technical one. What comes out at the end is not a number: it is an indicator, and an indicator has three mandatory parts. A written definition, an explicit denominator and a way back to the samples it is made of. Without all three, what you have is a figure on a screen, and a figure on a screen gets argued about; an indicator gets audited.

What a plant is able to do at each level, from 4 at the top to 0 at the bottom. A level counts as reached when its criteria and those of every level below are met.

The matrix summarises what a plant is able to do at each rung. The useful reading for this article is in the two middle rows: at level 1 capture and context are already solved and real time is still partial; at level 2 real time is complete and the ability to decide appears, partially. Actuation, which belongs to level 3, is still absent. That is why an aware plant reports very well and still closes no loop.

The five layers of context

Contextualising means attaching to each value whatever is needed to compare it, add it up and explain it. Without context, a history is a collection of correct and useless numbers. It helps to order context in five layers, because each one comes from a different place and its absence breaks different indicators.

Layer	What it adds	What breaks without it	Where it comes from
1. Asset identity	Which piece of equipment produced the value and where it sits in the plant hierarchy.	Any aggregate by line or by area. The data cannot be added up.	The asset model, not the register address in the PLC.
2. Time context	Instant stamped at source, in universal time, with time zone, shift and calendar.	Comparison across shifts and years, and the causal order of a failure cascade.	The synchronised clock of the device or of the capturing gateway.
3. Production context	Order, batch, product or recipe being run and the nominal speed of that product.	The performance factor of OEE and any consumption per unit produced.	The production management system, or the order released on the floor.
4. Operating context	Machine state, mode (production, changeover, maintenance) and downtime reason from a closed catalogue.	Availability and root cause analysis. Downtime is left unexplained.	Equipment state signals plus the classification made by the operator.
5. Semantics and data quality	Quantity, unit, scaling, range, quality flag (good, uncertain, bad, substituted) and version of the signal definition.	Trust in the history. An unrecorded rescaling invalidates the whole series.	A signal dictionary with a named owner and versioned changes.

An arithmetic example, with invented numbers so the mechanics can be seen. The record "412" says nothing. The record "412 kWh" already has quantity and unit, but cannot be compared with anything. The record "412 kWh consumed by line 2 between 06:00 and 14:00 on the morning shift, running order 7781 of product A, with 9,400 good parts and 120 rejects" becomes 0.0438 kWh per good part, and that number can be compared with the same product run on another line, on another shift or last month. The same five layers turn a part counter into performance and a digital input into availability.

Two practical consequences. The first is that context is attached at capture time, not when the report is built: reconstructing after the fact which order was running fourteen months ago is expensive when it is possible and false when it is not. The second is that context also ages and is also versioned: if the definition of a signal, the scaling of a sensor or the reason catalogue changes, the series before and after are not the same series, and the system must know it. The detail of how this layer is modelled is in the guide to industrial data contextualisation.

The asset model and the ISA-95 hierarchy

The first layer of context, asset identity, needs a skeleton. That skeleton is the asset model: a tree where each piece of equipment holds a stable place. The usual industrial reference is the ISA-95 equipment hierarchy, published as well as IEC 62264, which orders the plant into nested levels: enterprise, site, area, work centre (a line or a cell) and work unit (the individual machine). It is not the only way to organise it, but it is the one that almost every production management system understands, and adopting it saves translations later on.

The model has three pieces and all three are necessary:

The hierarchy. It allows aggregation without hand-written code: the energy of a line is the sum of that of its units, and an order assigned to a work centre passes its product down to everything below it.
The types. An asset class declares which signals every piece of equipment of that class must have, with which unit and at which frequency. A new press is instrumented against the type "press" and on day one already computes the same indicators as the others. Without types, every report is coded for every machine and nothing is comparable.
The instances. Each real machine maps its signals onto those of the type. This is where the physical address in the PLC is translated into a name with meaning, and where that name stops depending on the hardware.

The rule that avoids the most expensive mistake is this one: the identity of an asset is a node in the tree, never the address of a register. When the model replicates PLC addressing, the history is tied to one specific configuration, and any equipment replacement or reprogramming forces a reprocessing of the past. Modelling the asset first costs weeks; redoing it three years later costs the whole history.

The hierarchy also changes over time: a machine moves to another line, two areas merge, a work centre is split. That is why the relations in the tree are stored with temporal validity, so the system can answer which line that press belonged to in March last year. Without temporal validity, every reorganisation silently rewrites the past. This is one of the reasons why plant time series storage is designed separately from the business database: the detail is in the guide to the industrial historian.

Real-time OEE and its traps

The indicator that defines level 2 is OEE, the product of availability, performance and quality. Its full construction, with the time cascade and the six big losses, is in the OEE guide. What matters here is only what changes when it is computed continuously from captured data instead of once a day from a paper report.

Computing OEE in real time means recomputing it on every event over an interval that has not finished yet. That introduces two requirements the daily calculation does not have. The first is that the denominator is open: you have to decide whether the running shift is measured against elapsed time or against the full planned time, and both readings are legitimate as long as you declare which one is on screen. The second is that machine state, part counter and energy measurement have to be aligned in time: a ten second offset between counter and state is enough to book parts against the wrong downtime reason, or against the wrong shift if the offset falls on the changeover.

From there, the traps repeat in almost every plant and none of them is a software problem.

Trap	Symptom	Root cause	What to check
What counts as downtime	OEE goes up without anything changing on the floor.	Some downtime was moved from unplanned time into planned time.	The written definition of planned time, with its date and version.
The micro-stop	Availability is high and performance is low, and nobody can explain where time goes.	Slow polled capture does not see short stops, so their loss is booked as performance, where no cause can be assigned.	Capture resolution for machine state and the declared micro-stop threshold.
Nominal speed	OEE correlates with nothing and the plant stops using it.	Performance is computed against a catalogue capacity instead of the capacity of the product being run.	The nominal speed table per product, and who maintains it.
Unclassified reasons	The dominant downtime reason is "other".	A badly sized catalogue, or classification asked of the operator without any return for classifying well.	The reason breakdown of the last month and the share of unclassified time.
Hours with unknown state	Two lines with the same OEE behave differently.	Capture gaps are not random: the hours that get lost are the odd ones, which are exactly the ones that explain the losses.	Completeness per channel and per shift, not the aggregate figure for the plant.

The first two deserve some development. Planned time is the boundary between what counts as a loss and what is excluded from the calculation, so moving that boundary changes the indicator without changing the plant. It is a governance decision: written once, applied identically across every line, versioned with a date and, if it is modified, either the history is recomputed or the break in the series is marked visibly on the chart.

The micro-stop is a sampling problem before it is a definition problem. A short stop only exists in the indicator if capture sees it, which is why machine state and counters are recorded on change of state, that is, when they change, with a resolution of one second or better, instead of by periodic polling. If the resolution is coarser than the declared micro-stop threshold, the loss does not disappear from the process, it disappears from the accounting: it moves into the performance factor, where it has no assignable cause and no possible action. It is the most common way of having a high and false OEE, which is worse than having none.

Energy per line and per product, quality and traceability

OEE describes time. An aware plant also needs to describe energy cost and quality, and both rest on the same five layers of context.

Energy. The billing aggregate, taken in fifteen minute intervals at the supply point, is good for paying the bill and useless for explaining anything: it does not separate lines, it does not separate products and it cannot see the start-up signature of a machine. Explaining requires metering per line or per panel at a resolution of the order of one second, and assignment to the product being run. The resulting indicator is specific consumption, kilowatt hours per unit produced, and building it involves two decisions that must be declared: the denominator, which should be good parts and not parts made, because the energy spent on a reject is loss and not production; and the system boundary, that is, whether the indicator includes shared utilities such as compressed air, cooling or HVAC. Allocating shared utilities across products is legitimate if the allocation rule is published next to the indicator, and it is a source of endless argument if it is done silently.

On that base, the correct comparison is not against last month but against a baseline: a model that expresses expected consumption as a function of production and of conditions (outside temperature, product mix, number of start-ups). Without a baseline you cannot separate savings from a drop in activity. It is the capability behind the only result Captia publishes: over 30% energy savings in energy-intensive companies.

Quality and traceability. Knowing how many rejects there were is accounting; being able to go from the defect to its process conditions is traceability, and it requires two technical things. The first is genealogy: the identity of the part or batch is propagated along the line, so you know which raw material went in, which stations it passed through and in which time window it was at each one. The second is that those time windows are precise enough to be crossed with the process series; if the station timestamp and the process variable timestamp do not share a clock, the correlation between the defect and the condition that caused it is not computed, it is guessed.

One accounting detail breaks many reports: rework. A part that is recovered is neither good nor scrap, and counting it in both places or in neither throws off the quality factor and the specific consumption at the same time. It is decided once, written down and applied identically across the company.

Anomaly detection: why a fixed threshold fails

A fixed threshold works when the variable has a physical or safety limit that depends on nothing else: a maximum pressure, a trip temperature. In those cases it is the best possible solution, because it is auditable, explainable and does not degrade. The problem appears when the same instrument is used to watch variables whose normal value depends on context.

There are three reasons why that use fails, and they are of different natures:

Non-stationarity. The mean and the spread of the signal depend on the product being run, the load, the ambient temperature and the point in the cycle. A perfectly normal value while running product A can be clearly anomalous while running B.
Drift. Wear, fouling and the ageing of the sensor itself move the operating point slowly. A threshold that was right six months ago stops being right without anyone having touched anything.
Regime change. A changeover moves the process to a different operating point by decision and not by failure. To a fixed threshold it is indistinguishable from a fault.

The consequence is a trade-off that no amount of fine tuning avoids: a threshold tuned to miss nothing fires false positives until the operator stops looking, and one tuned not to bother anyone stops detecting. The cost of a false positive is not zero, it is the attention of a person.

A statistical or learned model built on plant data can do better, but only if it meets five conditions that are rarely spelled out:

Condition on the regime. Model per product, per machine state and per speed band, or feed those variables into the model. A model that cannot see them learns the production schedule and warns every time the product changes.
Define normality over a labelled period. The envelope of normality is estimated over a stretch someone has declared normal, not over "the whole history", which contains precisely the failures you want to detect.
Declare the window and the latency. A statistic computed over an hour of data detects with an hour of delay by construction. The window is chosen from the deadline within which detection is still useful.
Watch model drift. You need a metric measuring how far real conditions have moved from those the model was fitted on, and a threshold on that metric that triggers review. A model with no drift monitoring switches itself off, months later, with no diagnosis.
Validate with the false positive rate, not only with the hit rate. The metric that decides whether the system is viable is how many unfounded warnings an operator gets per shift, because that is what determines whether they will still pay attention three months from now.

It also helps not to confuse two things. An anomaly is an observation that is unlikely under a model of normality. A fault is a state of the equipment with consequences. Every anomaly deserves a record; only some deserve a warning. The difference between those two lists is decided with the maintenance team, not with the algorithm. The reference definition is in the anomaly detection entry.

Alarms that do not get ignored

All of the above ends at the same bottleneck: the attention of the people on the floor. It is a finite and saturable resource, and the alarm system is how it gets spent. Alarm fatigue is what happens when more warnings are issued than can be attended to: the operator stops reading them, and from that moment the system is not warning, it is making noise with the appearance of warning, which is worse because it creates a false sense of coverage.

The sector reference guide for the design, management and procurement of alarm systems is EEMUA publication 191. Its reference rates depend on the type of plant and should be taken from the document itself, not from an article. What is transferable is the discipline, which comes down to six rules:

Every alarm has a defined response. If there is no action the person can take, it is not an alarm: it is information and its place is the panel, not the notification.
Priority is set by consequence and by the time available to respond, not by who asked for the alarm. A system where almost everything is high priority has no priorities.
Conditional suppression is declared. During a planned stop, a changeover or a start-up there are alarms that do not apply. They are declared in writing, applied automatically and logged. Silencing them by hand is the first step towards leaving them silenced forever.
Deadband, hysteresis and confirmation delay. Without them, a signal oscillating around the limit raises an alarm on every crossing and saturates the log. It is the most frequent technical cause of an alarm flood.
The alarm system is measured the way the process is measured. Alarms per operator and per shift, a ranking of the ten most repeated, floods during a failure and the share of alarms never acknowledged. Without those four series there is no way of knowing whether it is improving.
It is reviewed periodically with the people who attend to it. The metric that matters is not how many are issued, it is how many produce an action. Retiring an alarm nobody attends to is an improvement, not a loss of coverage.

This discipline is what separates a level 2 plant that gets used daily from one that gets dismantled after six months. It is also a prerequisite for level 3: a system that is going to propose or execute actions needs the warnings it issues to be read.

What real time means in each case

"Real time" does not mean fast. It means the answer arrives within a declared and known deadline, and that if the deadline is missed the result stops being useful even when it is correct. What defines a real-time system is therefore not its average speed but its bound, and in control the variability of the delay matters more than its average value: a loop with variable delay cannot be tuned, it either becomes slow to stay stable or it oscillates.

The bound is not the same across the plant. The decision horizons of a factory span nine or ten orders of magnitude in time, and each one imposes its own deadline and its own place for the compute.

Each decision belongs at the highest level that meets its latency and still lets the level below degrade safely. The 10 ms to 0.5 ms range of periodic industrial communication comes from the 5G-ACIA and ZVEI white paper of November 2019.

The figures at the fast end have a source. The 5G-ACIA and ZVEI white paper on integrating industrial Ethernet networks with 5G networks, published in November 2019, states that common cycle times in periodic industrial communication are in the range of 10 ms to 1 ms and down to 0.5 ms, and that working clock domains, where robots and motion control live, require time synchronisation of 1 microsecond or better, with a tendency to push it to 100 nanoseconds. The standard behind that synchronisation is IEEE 1588 in its 2019 edition, approved by the IEEE Standards Association on 7 November 2019, which defines the precision clock synchronisation protocol for networked measurement and control systems.

None of that is what level 2 requires, and confusing the two is an expensive mistake in both directions. Translated into the indicators of this article:

The OEE of a line. It tolerates latencies of seconds without losing any value in use: what gets decided with it happens on the scale of the shift.
Micro-stop detection. It does not require low latency, it requires high resolution at capture. These are different things and are often confused: a record that arrives ten seconds late but keeps the exact instant the event happened is useful; a record that arrives instantly but is sampled every thirty seconds is not.
A process alarm. Its deadline is set by the time the person has to act before the consequence occurs. That number comes from the process, not from the technology.
In-line quality inspection. It has a hard bound imposed by the cycle: the decision must arrive before the part leaves the station. If it does not, there is no decision, there is a report.

The design rule that orders all of this is easy to state and rarely applied: every indicator declares the latency it tolerates and the maximum age the data feeding it may have, and both are measured in production. Level 2 does not require milliseconds. It requires declared and verified deadlines, which is a considerably harder requirement to dodge.

Frequently asked questions

What is the difference between having connected data and having an aware plant?

A connected plant (level 1) has the values of its equipment in one place, with time, unit and asset identity. An aware plant (level 2) turns those values into statements about the process: how much was produced, how long it stopped and why, how much energy each part cost and what is outside normal right now. The jump is not about data volume, it is about the object: you move from transporting observations to estimating the state of the process, and that requires production, operating and semantic context that the signal does not carry on its own.

How often does data have to be captured for OEE to be credible?

There is no single frequency: it is set per variable and by the phenomenon you need to be able to see. For machine state and part counters the rule is change of state capture, that is, recording the change when it happens instead of polling at intervals, with a resolution of one second or better. The reason is arithmetic: an eight second stop disappears completely if you ask every thirty seconds, and with it disappears the largest availability loss of many lines. Slow process variables such as temperatures or pressures are reconstructed well with one sample per second.

Why does my OEE not match the one the shift manager reports?

It is almost never a calculation problem. It is usually a difference of definition in three places: what counts as planned time, what the nominal speed of the product being run is, and what counts as scrap or as rework. Until those three definitions are written down, unique across the company and versioned with a date, OEE is not arguable, it is a matter of opinion, and meetings are spent negotiating the denominator instead of attacking the loss.

Can I compute energy per product without a meter on every machine?

Partly. With metering per line or per panel and production context properly assigned, you get consumption per order and per product for everything hanging off that meter, which is usually enough to compare products and shifts. What you cannot do silently is allocate shared utilities such as compressed air, cooling or HVAC across products: if you allocate them, the allocation rule is written down and published next to the indicator, because it changes the result. The alternative to metering more is metering better what is already metered, and stating clearly what falls outside the boundary.

Why do fixed thresholds fail at detecting anomalies?

Because a fixed threshold assumes that "normal" is always the same value, and in a plant it almost never is. The mean and the spread of a variable depend on the product being run, the load, the ambient temperature and the point in the cycle. On top of that there is slow drift from wear or fouling, and regime changes at changeover that are not failures. A threshold tuned to miss nothing fires false positives until the operator stops looking; one tuned not to bother anyone stops detecting. The way out is to condition normality on the regime: model per product and per state, or feed those variables into the model.

How many alarms are too many?

The operational answer is not a catalogue number, it is a comparison: they are too many when they exceed what one person can attend to and understand during a shift, because beyond that point an alarm stops producing an action. The sector reference guide for the design, management and procurement of alarm systems is EEMUA publication 191, and its reference rates should be taken from the document itself, since they depend on the type of plant. What anyone can measure from day one is their own system: alarms per operator and per shift, a ranking of the most repeated ones, floods during a failure and the share of alarms never acknowledged.

The starting point for all of the above is having the data captured with time and context, which is level 1 and is described in the industrial data platform. The full five-rung framework is in the guide to physical AI in manufacturing. If you want to check where your plant stands and which indicators its data can support today, tell us what equipment you have.