Industrial AI will not transform automation until it can move from advice to action. ARC analysts were recently briefed on Xentara, a runtime platform developed by embedded ocean GmbH for what the company describes as the next stage of industrial automation: physical AI. The ambition is to move AI beyond dashboards, offline analytics, and cloud applications into the operational layer, where machines sense, decide, and act in real time. That shift depends on more than better algorithms. It requires a runtime foundation that can connect industrial assets, execute deterministically, preserve semantic context, and enforce security at the machine level.
That is the gap Xentara is targeting. Much of today’s industrial AI still operates beside the production line rather than inside the control loop. Vision systems, simulation models, historians, machine learning applications, and cloud analytics can all create value. Too often, however, they remain separated from deterministic control by legacy architectures, proprietary ecosystems, and brittle point-to-point integrations. Xentara’s central message is that physical AI is not only an AI challenge; it is a runtime challenge.
The platform’s proposition is to bring connectivity, real-time control, and edge AI into one runtime on commercially available x86, AMD64, or ARM hardware. Xentara combines semantic, timing, and security models with support for fieldbuses, databases, IoT interfaces, PLC connectivity, microservices, simulation, and ONNX-based machine learning inference. Its interface set reflects broader software-defined automation trends: Linux RT, OPC UA, TSN and WebSockets, MQTT, REST, EtherCAT, PROFINET, Modbus, Siemens S7, Beckhoff ADS, FMI/FMUs, C++, and microservices. The point is not simply more connectivity, but a coherent execution layer for data, timing, permissions, and inference.
The near-term opportunity is less about fully autonomous machines and more about brownfield modernization. Many machine builders have proven application logic, HMI behavior, mechanics, and process know-how tied to aging motion cards, obsolete real-time kernels, or limiting communications layers. Xentara’s migration argument is pragmatic: preserve the application value while replacing the system layer with a more open, model-based runtime, Linux with PREEMPT_RT, and EtherCAT-based motion communication.
One of the stronger technical arguments is the move from analog drive commands to process-data-rich bus communication. Analog setpoints can move a machine, but reveal little about what is happening inside the drive or process. A modern bus connection can expose position, torque, following error, parameters, and diagnostics in the bus cycle. For OEMs, this can turn existing drive information into useful signals for quality monitoring, condition monitoring, and process optimization. In practical terms, the drive becomes less of a black box and more of a process sensor.
ARC sees Xentara as part of the emerging software-defined automation landscape rather than a conventional controller replacement. If Xentara can build credible references, it could become a meaningful runtime layer for OEMs and manufacturers bridging today’s automation systems with tomorrow’s physical AI applications.
