Industrial automation is traditionally organized as a hierarchy, also called the Automation Pyramid, and while somewhat dated, the ISA-95 levels still describe it well. Sensors and actuators sit at the field level, PLCs and distributed control systems execute deterministic control above them, SCADA and MES handle supervision and production management, and enterprise systems plan business operations. Each level was built around a different time scale, from microseconds at the drive to weeks at the ERP. Industry 4.0 tries to reduce layers as much as possible.
Physical AI is a new technology that does not fit cleanly into that stack: intelligent reasoning. It does not replace the infrastructure below it; instead, it sits beside the supervisory levels and feeds decisions downward, letting a system perceive, interpret, and optimize conditions that are hard to express as pre-determined logic. Physical AI speaks its own language and has its own security requirements; you have to convert or deliver new interfaces like ONNX and MCP to connect. Getting the seam between those two worlds right is the engineering challenge.
Where reasoning belongs, and where it does not
Motion control, interlocks, and closed-loop process control need a bounded worst-case execution time. A servo update or a PLC scan either finishes inside its cycle or the machine faults. Neural network inference offers no comparable guarantee. Its latency depends on the input, on memory pressure, on cache behavior, and on whatever else is competing for the accelerator, and the tail latency matters more than the mean.
The split that matters is one of authority. Deterministic controllers keep authority over actuation. The reasoning layer proposes: a setpoint, a trajectory, a schedule, a grasp pose, a classification. The controller accepts a proposal only if it passes a validity check, and falls back to a known-good policy when the proposal arrives late, lands out of range, or does not arrive at all. Under that contract a slow or wrong inference costs throughput instead of safety, which is the only version of this architecture that survives a hazard analysis.
Within that boundary, Physical AI earns its place wherever uncertainty is the dominant problem: object recognition, dynamic planning, adaptive scheduling, anomaly detection, predictive optimization, and autonomous decision support. Nothing about it improves a function that a deterministic controller already handles well.
Necessary capabilities
Perception comes first. Cameras, lidar, force sensors, encoders, and industrial IoT devices supply multimodal information about the state of the production environment. Fusing that information requires a common time base and a common frame of reference, which in practice means hardware timestamping and clock synchronization through gPTP (IEEE 802.1AS) or PTP (IEEE 1588), plus extrinsic calibration between e.g. camera and robot base. Sensor data that is unsynchronized or uncalibrated does not fuse properly resulting in a model that may look plausible but is quietly wrong.
The fused data becomes a world model: a digital representation tracking machines, products, inventory, operators, and workflows. Digital twins increasingly serve as these continuously updated models, and the Asset Administration Shell standardizes how an asset describes itself, splitting the description into submodels whose fields carry semantic references to dictionaries like ECLASS instead of plant-local tag names. The world model is the contract between perception and reasoning, so it has to carry uncertainty as well as values. A state estimate without a timestamp and a confidence figure cannot be planned against safely.
Reasoning sits on top. Models weigh production objectives, operational constraints, equipment health, quality metrics, and scheduling priorities before selecting a course of action. In most working systems this is a hybrid rather than one large learned policy: learned components do perception and prediction, while the decision itself goes to a constraint solver or a model-predictive controller that can be inspected, bounded, and explained to a safety engineer. That division also localizes potential failure. When output goes wrong you can tell whether the model misread the world or the optimizer was given the wrong objective.
Orchestration coordinates multiple heterogeneous assets rather than a single robot: robots, PLCs, AGVs, CNC machines, machine vision systems, and enterprise software. This is a distributed systems problem with a physical edge to it. Sequencing, resource locking, and partial failure all apply, but retries do not, because effects on physical objects are rarely idempotent, e.g. dispensing an adhesive twice is not the same as dispensing it once.
Deterministic execution stays where it already lives. Once a decision is made, PLCs, motion controllers, and safety systems carry it out with predictable timing. Keeping the stochastic layer separate from the deterministic one is what lets each be validated by the method that suits it: statistical evaluation for the model, timing analysis and formal argument for the controller.
Timing and placement
Inference usually runs e.g. via ONNX at the industrial edge to avoid latencies while cloud platforms can handle the computationally intensive training that happens before actual implementation. On the edge side the techniques are familiar from real-time engineering: quantize to INT8, fuse operators, run at batch size one, isolate cores and shield them from the general scheduler, use a PREEMPT_RT kernel or a hypervisor partition so that inference cannot starve the control task on a shared multicore part.
The network matters as much as the compute. EtherCAT, PROFINET IRT, and POWERLINK provide determinism on their own terms, and Ethernet TSN provides it generically through scheduled traffic (IEEE 802.1Qbv) and synchronized clocks, with OPC UA FX over TSN coming to production lines soon as the interoperable path. The mistake to avoid is budgeting only the model. Measure the chain: exposure and readout, transfer, preprocessing, inference, postprocessing, fieldbus delivery.
💡 Preprocessing and I/O frequently dominate, and a model optimization that halves inference time can move the total by very little.
Data quality starts in the plant
Industrial datasets are frequently incomplete, inconsistent, or noisy, and the reasons are specific enough to design around. Defect classes are rare, so the interesting label is the one you have least of. Labels come from operators whose criteria drift between shifts. Historians store deadband-compressed values rather than the raw signal, which is fine for trending and misleading for training. Timestamps arrive from unsynchronized sources. Equipment changes without announcement, and a replaced part or a new supplier's material shifts the input distribution while every dashboard still reads green.
The countermeasures are contextualization against ISA-95 and ISA-88 semantics or a unified namespace, validation at ingestion rather than at training time, and explicit drift monitoring on inputs as well as outputs. There is also a feedback trap worth naming early: once a model influences the process, later data reflects the model's own behavior, so a naive retraining loop can converge on its own assumptions.
Interoperability
A Physical AI platform has to integrate with OPC UA and its companion specifications, OPC UA FX for controller-to-controller exchange, MQTT with Sparkplug B, industrial Ethernet, legacy fieldbus protocols, MES platforms, historians, ERP systems, and vendor-specific APIs. Transport is the easy half. The expensive half is semantics, because two machines that both publish a tag called temperature may differ in unit, sampling interval, filtering, and what physical thing is being measured. Information models are what turn integration from a per-asset project into something that scales. A physical AI platform therefore has to be built around a semantic model with user defined ontologies.
Safety and the regulatory clock
Functional safety certification continues to reside within conventional safety architecture, under IEC 61508 and the machinery standards derived from it, ISO 13849-1 with its performance levels and IEC 62061 with its safety integrity levels. Safe communication still travels a black channel through PROFIsafe, FSoE, CIP Safety, or openSAFETY. Collaborative operation still answers to ISO 10218 and ISO/TS 15066. None of that moves because a model is now in the loop.
What changes is the burden of argument around the AI layer. Its outputs have to operate inside envelopes enforced by safety-rated logic through monitored speed and position, restricted zones, and safe stops that do not depend on the model behaving. Two regulatory dates make this concrete for anyone designing in Europe. The Machinery Regulation (EU) 2023/1230 applies from 20 January 2027 and explicitly covers modules using learning techniques that ensure safety functions. Under the AI Act as amended by the Digital Omnibus, Regulation (EU) 2026/1744, which entered into force on 27 July 2026, obligations for Annex I high-risk systems, meaning AI used as a safety component of machinery, now apply from 2 August 2028. Architecture decisions taken this year will be assessed under both. Security belongs in the same conversation: IEC 62443 applies to the model endpoint like any other service, and a sensor that can be spoofed is a control problem before it is a data problem.
Lifecycle management
Software updates now include AI model validation, continuous monitoring, dataset governance, explainability, and retraining strategy alongside traditional software engineering practice. The structural difference from conventional releases is that the deployed artifact is no longer just code. It is code, weights, the training dataset, and the preprocessing pipeline, and reproducing a field issue means having all four under version control with the same rigour.
The practices that follow from that are unglamorous and effective. Run new models in shadow mode, scoring live data without authority, before they influence anything. Canary onto one cell or one line rather than a fleet. Keep recorded production data for deterministic replay, and use hardware-in-the-loop simulation for anything closed-loop. Define retraining triggers in advance so the decision to retrain is not made under schedule pressure. Where a model touches a safety-related function, any change re-enters change control and revalidation, which puts a hard ceiling on iteration speed. That ceiling is a design constraint to plan around, not an obstacle to route past.
What it enables
The architecture makes a set of applications practical that used to be difficult to implement. Adaptive robotic assembly absorbs part variation without an extensive fixture redesign, using force and vision feedback in place of mechanical precision. Vision-guided inspection improves its own defect detection from operational feedback, provided borderline cases route to a human whose judgment is recorded. Autonomous logistics reroutes material dynamically as production priorities change. AI-assisted process control finds complex relationships between operating parameters that conventional control strategies cannot easily model, typically advising the existing advanced process control layer rather than displacing it.
Process industries apply the same pattern to equipment diagnostics, energy optimization, predictive quality control, process anomaly detection, and autonomous inspection. The economics differ from discrete manufacturing because the assets are larger and the failures are more expensive, but the engineering pattern holds: the model advises, the qualified control strategy decides.
Conclusion: A systems problem
Physical AI sits where artificial intelligence, industrial control, robotics, simulation, and systems engineering meet, and each of those disciplines brings validation methods the others do not have. That is what makes it an integration problem. The teams that get it into production treat model behavior as an engineering artifact, with the same requirements traceability, timing analysis, and change control they already apply to everything else on the machine.
Sources:
EU-OSHA on Regulation 2023/1230, White & Case on the AI Omnibus, Travers Smith on delayed deadlines, IDTA AAS metamodel specification, IDTA-01001 Part 1 (PDF)