Industrial automation is moving intelligence to the edge: from static PLC logic and centralised control to machines, sensors and mobile assets that sense, decide and adapt locally. They are networked by OPC UA over TSN, a service-oriented architecture on deterministic Ethernet, and secured at the device. The engineering pattern is what a buyer specifies, not the brand.
If you are specifying an industrial controller, edge node or mobile asset now, decide four things before the architecture is drawn. Which decisions must be taken on the device with no round trip to a central system. Which deterministic network carries the result and to what latency. How the controller is secured at the device rather than at the perimeter. And which of the four hardware demands the enclosure and the power budget will actually allow: compute density, deterministic interrupts, predictable memory and thermal stability. Each of those four decisions has a published standard, a vendor’s own page or a review gate behind it.
For decades, industrial automation was built around predictability.
Factories were designed for static workflows, fixed production lines, hard-coded logic, and centralised control systems that changed only when engineers manually reprogrammed them. Programmable Logic Controllers (PLCs) executed deterministic routines, sensors reported status, and optimisation happened periodically, not continuously.
That era is over.
Today’s industrial environments operate under constant pressure: fluctuating demand, shorter product lifecycles, labour shortages, energy constraints, and zero tolerance for downtime. Modern factories no longer need systems that execute instructions; they need systems that sense, decide, adapt, and optimise autonomously, every second of operation.
Industry leaders such as Siemens and Bosch are driving this transformation by fundamentally rethinking how intelligence is embedded across industrial systems. Their approach signals a broader shift in embedded systems development, hardware design and development, and firmware development services, where efficiency is no longer achieved by scaling centralised systems, but by engineering intelligence directly into the edge.
Why is industrial automation moving from static control to continuous intelligence?
Industrial automation is moving from static control to continuous intelligence because factories now face material flow disruptions, machine wear, dynamic schedules, energy price swings and autonomous logistics in real time, and a control system that changes only when an engineer reprograms it cannot keep up. Intelligence has to move closer to where the data is generated.
Traditional industrial systems were designed around stability. Once configured, control logic rarely changed. Optimisation cycles ran once per shift or once per day. Decision-making was centralised, and responsiveness was limited by network latency and human intervention.
Modern industrial operations demand something entirely different.
Factories today must react in real time to:
- Material flow disruptions
- Machine wear and failure risks
- Dynamic production schedules
- Energy price fluctuations
- Autonomous logistics coordination
This requires a new architectural model, one that moves intelligence closer to where data is generated.
Siemens and Bosch exemplify this shift by embedding advanced computation, analytics, and decision-making directly into machines, sensors, and mobile assets.
The programmable logic controller at the centre of the old model is itself a standardised thing, and knowing that helps a buyer read a proposal. IEC 61131-3 “specifies the syntax and semantics of programming languages for programmable controllers as defined in IEC 61131-1”, and the languages it defines include ladder diagram, function block diagram, structured text and sequential function chart. A controller that only runs those languages against a fixed scan is the static model; a controller that also hosts analytics and inference is the continuous one, and the question for a supplier is which of the two the proposal is describing.
What do autonomous mobile robots show about intelligence at the edge?
Autonomous mobile robots show what intelligence at the edge means in industrial automation: unlike automated guided vehicles on fixed paths under central control, an AMR interprets its sensor data locally, reroutes around obstacles and coordinates with other systems without a round trip to the cloud. That takes hardware, a real-time operating system and firmware engineered together for deterministic behaviour.
Siemens’ deployment of Autonomous Mobile Robots (AMRs) illustrates how embedded intelligence is reshaping factory operations.
Unlike traditional Automated Guided Vehicles (AGVs), which rely on fixed paths and centralised control, Siemens’ AMRs operate using local AI models running directly on embedded hardware. These robots:
- Interpret sensor data locally.
- Reroute dynamically.
- Avoid congestion and obstacles autonomously.
- Coordinate with other systems without constantly relying on the cloud.
This architectural choice dramatically reduces latency and improves resilience. Decisions no longer need to travel to a central controller and back. Instead, intelligence lives at the edge, enabling real-time adaptation even in complex, decentralised environments.
From an embedded systems development perspective, this requires tight coordination between hardware capabilities, real-time operating systems, and firmware logic to ensure deterministic behaviour under constantly changing conditions.
What Siemens itself publishes is narrower and more useful to a buyer than a summary of it. Its SIMOVE page describes “modular AGV and AMR software, hardware and services for flexible automation, fleet management and smart intralogistics” and “laser-based, feature-driven SLAM navigation on a PLC/PC (Linux) platform”, a vendor’s description of its own product. The page names a PLC/PC platform and says nothing about where that platform sits, which is the engineering point: navigation only counts as an edge decision if the computer running it rides on the vehicle. The check to run on any AMR proposal is to ask which decisions are taken on the vehicle, which on a fleet manager and which need a network, because the answer decides what happens when the network is not there.
How does predictive maintenance work at the edge?
Predictive maintenance at the edge means an industrial node analyses vibration, temperature, acoustic and electrical signals where they are measured and flags early signs of failure, instead of streaming every sample to a central platform. Failures are predicted earlier, interventions scheduled, spares optimised and disruptions reduced, which puts real-time analytics and on-device inference squarely on the firmware.
Bosch, among others, offers predictive maintenance services that apply machine learning to sensor signals. These services continuously analyse vibration, temperature, acoustic and electrical signals to detect early signs of failure.
McKinsey puts the potential of digital maintenance and reliability transformations generally, not of any one company’s approach, at an increase in asset availability of 5 to 15 percent and a reduction in maintenance costs of 18 to 25 percent (2018).
The impact goes beyond maintenance efficiency:
- Failures are predicted earlier.
- Interventions are scheduled proactively.
- Spare parts inventory is optimised.
- Production disruptions are minimised.
This model highlights the growing importance of firmware development services that support real-time analytics, on-device inference, and long-term reliability under harsh industrial conditions.
The signals named are the ones a maintenance vendor’s own page names too. Bosch Rexroth describes its predictive maintenance service as one where “a machine learning algorithm monitors the signals of the various sensors of the machine, equipment or group of machines, such as pressure, flow, vibration, temperature and oil quality”, on its predictive maintenance page, which also describes the service as cloud-based. That is worth knowing, because “predictive maintenance” covers both cloud analytics on streamed data and inference on an edge node, and they place opposite demands on the device: a streamed design needs bandwidth and a reliable link, an edge design needs a processor, memory and a power budget on the node. The check to run on a proposal is to ask which of the two it is, and what the node does when the link is down.
McKinsey’s later work is worth reading beside the 2018 figures: its article on choosing an analytics-based maintenance strategy reports that predictive maintenance “often underperforms due to false positives”, which is the first thing to ask a supplier to show it has designed against.
Why are hard-coded PLC architectures declining?
Hard-coded PLC architectures are declining because rigid ladder logic and fixed control sequences cannot deliver adaptive manufacturing; industrial automation is moving to event-driven controllers, modular logic, software-defined layers and dynamic task orchestration under a real-time operating system. The hardware has to follow: higher compute density, deterministic interrupts, predictable memory access and thermal stability under continuous load.
Classic PLC-based automation relies on rigid ladder logic and fixed control sequences. While robust, these systems lack the flexibility required for modern, adaptive manufacturing.
Industry leaders are now transitioning toward:
- Event-driven controllers
- Modular control logic
- Software-defined automation layers
- Dynamic task orchestration
Real-time operating systems (RTOS) are increasingly used to manage I/O loops under strict microsecond deadlines, allowing systems to respond deterministically while remaining adaptable.
This shift places new demands on hardware design and development. Controllers must support:
- Higher compute density
- Deterministic interrupt handling
- Predictable memory access
- Thermal stability under continuous load
Automation hardware is no longer just about executing logic; it is about hosting intelligence.
Compute density, deterministic interrupt handling, predictable memory access and thermal stability are each decided at a different point in the design, and each leaves a different document behind: a selection note with headroom, a measured worst-case interrupt latency, a memory map with timing and an accepted thermal study.
The four hardware demands a controller that hosts intelligence must meet, where each is decided and the check to run
| Hardware demand | Where it is decided | Check to run |
|---|---|---|
| Higher compute density | Processor and memory selection, board layout | Headroom left at full load, in writing |
| Deterministic interrupt handling | Processor choice, RTOS configuration | Worst-case interrupt latency, measured |
| Predictable memory access | Memory architecture, cache and DMA policy | Memory map with timing, not just size |
| Thermal stability under continuous load | Enclosure, power budget, thermal study | Thermal feasibility study, accepted and signed |
Hosting intelligence on a controller is a hardware programme with review gates, not a firmware upgrade. On one industrial gateway programme, every design stage is paired with its own review and rework step: schematic design, schematic review, schematic rework, component placement, layout, layout review, layout rework, output files, then order, with design change notices prepared and reviewed as tracked work. The reason to insist on that sequence for a controller is thermal stability under continuous load: it is decided by the enclosure, the power budget and the layout together, and a review that happens after the board is ordered cannot move any of them. Our page on how an electronic product development programme is staged and gated sets out the sequence.
What does OPC UA over TSN change in industrial communication?
OPC UA over TSN changes industrial communication by replacing isolated legacy fieldbuses with deterministic Ethernet: guaranteed latency, synchronised communication across distributed assets, scalable interoperability and one network for IT and OT. Real-time control then works across plants, provided firmware, networking stack and hardware timing are engineered as one, which is the hardest part of the specification.
Industrial communication is also undergoing significant transformation.
Legacy fieldbuses were designed for isolated systems with limited bandwidth. As factories become more interconnected, these protocols struggle to support modern requirements.
Siemens is actively adopting OPC UA over Time-Sensitive Networking (TSN), replacing traditional fieldbuses with deterministic Ethernet.
This architecture provides:
- Guaranteed latency
- Synchronised communication across distributed assets
- Scalable interoperability
- Seamless integration between IT and OT layers
Deterministic Ethernet enables real-time control even across geographically distributed plants, an essential capability for global manufacturing operations.
Implementing this reliably requires deep coordination between firmware, networking stacks, and hardware timing mechanisms, reinforcing the importance of integrated embedded systems development expertise.
The two halves of the name come from two different standards bodies, and a buyer should ask about both. OPC UA is the OPC Foundation’s “platform independent service-oriented architecture”, first released in 2008, and the Foundation’s Field Level Communications initiative “has been launched in order to extend OPC UA to the field level and to meet the diverse requirements of industrial automation”. Time-Sensitive Networking is a set of IEEE 802.1 standards whose task group describes its aim as “guaranteed packet transport with bounded latency, low packet delay variation, and low packet loss”. The fieldbuses being replaced are standardised too: the PROFIBUS organisation says on its own technology page that PROFIBUS is “standardized in IEC 61158”. The check to run on a proposal is which OPC UA profile and which TSN mechanisms the controller’s networking stack will implement, and whether the hardware timing to hold the bounded latency has been shown, not assumed. Our post on bridging legacy and modern industrial protocols covers what happens at the boundary between the old fieldbus and the new network.
Why is industrial security moving from the perimeter to the device?
Industrial security is moving from the perimeter to the device because a connected controller cannot rely on a network firewall alone: modern devices carry secure boot, hardware-backed roots of trust, runtime integrity monitoring and firmware-level anomaly detection. In industrial automation the security, performance and real-time constraints then have to coexist inside the same firmware without compromise.
As industrial systems become more connected, traditional perimeter-based security models are no longer sufficient.
Recognising this, companies like Rockwell Automation are embedding security directly into device firmware.
Instead of relying solely on network firewalls, modern industrial devices now include:
- Secure boot mechanisms
- Hardware-backed roots of trust
- Runtime integrity monitoring
- Firmware-level anomaly detection
Some systems integrate AI-based behavioral analysis directly into firmware, allowing devices to detect abnormal activity in real time and respond autonomously.
This evolution significantly impacts firmware development services, where security, performance, and real-time constraints must coexist without compromise.
Secure boot, a hardware-backed root of trust, runtime integrity monitoring and firmware-level anomaly detection are each implemented in a different place: the boot chain, the silicon, the running firmware and an on-device model. Each takes its own question to a supplier.
Four device-level security features, where each is implemented and the check to run
| Device-level security feature | Where it is implemented | Check to run |
|---|---|---|
| Secure boot | Boot ROM, bootloader, signing keys | What refuses to run an unsigned image |
| Hardware-backed root of trust | Silicon: secure element or on-die key store | Where the device identity key is kept |
| Runtime integrity monitoring | Firmware and RTOS services | What is measured, how often, who is told |
| Firmware-level anomaly detection | Firmware, sometimes an on-device model | What counts as abnormal, and what happens next |
The public reference points for device-level security are a standards series and a vendor’s own record. The IEC 62443 series, in the IEC’s own words, “was developed to secure industrial automation and control systems (IACS) throughout their lifecycle”. Rockwell Automation’s own press release of 15 November 2018 announced control devices supporting CIP Security, which it says “protects critical communications in a Connected Enterprise” by limiting device connectivity to trusted systems, preventing data tampering and encrypting communications, a vendor describing its own product. On a Pinetics programme the device-level decision is taken early rather than retrofitted: the architecture gate has published exit criteria that include a signed cybersecurity architecture decision alongside a signed hardware/software interface control document. The check to run on your own programme is to ask which document records the security decision, who signed it and on what date.
How do embedded AI cores make industrial systems self-optimising?
Embedded AI cores make industrial systems self-optimising by putting inference inside controllers, sensors and motion systems: sensor grids recalibrate as conditions change, motion controllers adjust trajectories within their control cycle and machines trade performance, energy and wear against each other. That is only possible when intelligence is engineered into the hardware and firmware, not layered on afterwards.
One of the most profound shifts in industrial automation is the rise of embedded AI cores within controllers, sensors, and motion systems.
Industrial systems are being deployed where:
- Sensor grids self-calibrate in response to environmental changes.
- Motion controllers adjust trajectories dynamically within their control cycle.
- Machines adapt operating parameters to balance performance, energy use, and wear.
These capabilities are only possible when intelligence is embedded at the hardware and firmware level, not layered afterwards.
This trend underscores a critical principle: efficiency today is not achieved by scaling systems vertically, but by distributing intelligence horizontally across every operational node.
A motion controller’s trajectory update has to fit inside its own control cycle, whatever that cycle is, and the figure a buyer should ask for is the one measured on the controller in question, in writing, rather than a round number quoted about someone else’s machine. Where the loop closes across a network rather than inside one box, the bound that matters is the network’s: the IEEE 802.1 Time-Sensitive Networking task group sets its aim at “bounded latency” and “low packet delay variation”, and a bound measured on the real traffic mix is worth more than a headline cycle time. An embedded AI core changes what a node computes, not what the physics and the network will allow.
What does engineering intelligence at the edge require?
Engineering intelligence at the edge requires architectural thinking rather than isolated technologies: decisions made where data is generated, latency minimised by local processing, resilience built through decentralisation and determinism kept despite complexity. In industrial automation the hardware, firmware, network and security decisions are taken together or not at all, because each one constrains the other three.
Isolated technologies do not drive the success of Siemens and Bosch; rather, it is architectural thinking.
They redesign systems from the ground up to ensure that:
- Decisions are made where data is generated.
- Latency is minimised by local processing.
- Resilience is built through decentralisation.
- Systems remain deterministic despite complexity.
This requires a holistic approach to hardware design and development, firmware development services, and embedded systems development, where hardware, software, networking, and security are engineered as one cohesive system.
Making decisions where data is generated is a hardware decision before it is a software one, because the node that decides needs the processor, the memory and the power to do so. Security belongs in the same sequence: the IEC 62443 series was developed, the IEC says, to secure industrial automation and control systems “throughout their lifecycle”, and a lifecycle property is not something a later firmware release can supply. Our post on choosing an IoT gateway for edge computing projects works through what an edge node has to carry to make its own decisions.
Why is the future of industrial automation distributed?
The future of industrial automation is distributed: intelligent machines, autonomous mobile assets, adaptive controllers, secure self-monitoring firmware and deterministic high-speed networks, with efficiency measured by how well intelligence is embedded in every node rather than by throughput alone. That moves the specification work to the node: what it decides on its own, and what it must prove.
The next generation of industrial automation will not be controlled solely from larger control rooms or centralised dashboards.
It will be powered by:
- Intelligent machines
- Autonomous mobile assets
- Adaptive controllers
- Secure, self-monitoring firmware
- Deterministic, high-speed networks
Efficiency will no longer be measured by throughput alone, but by how effectively intelligence is embedded into every node of the system.
Factories will become living systems that continuously sense, learn, and optimise in real time.
Industrial automation is undergoing a fundamental shift. Static workflows, rigid control logic, and centralised decision-making are giving way to distributed intelligence, real-time adaptability, and autonomous optimisation.
Companies like Siemens and Bosch are leading this transformation by embedding intelligence directly into machines, controllers, and sensors, demonstrating that actual efficiency is achieved not by scaling systems, but by engineering intelligence at the edge.
At Pinetics, we share this philosophy. Through deep expertise in embedded systems development, hardware design and development and firmware development services, we help industrial innovators design and build intelligent, resilient and future-ready automation systems. Our focus is on creating tightly integrated hardware and software architectures that deliver real-time performance, security and scalability in demanding industrial environments: the on-device decisions written down before the processor is chosen, the deterministic network and its latency specified rather than assumed and the cybersecurity architecture decision signed at the architecture gate rather than retrofitted after the board exists. That work rests on 100,000+ engineering hours and a leadership team with 20+ years of experience, and it runs inside the customer’s quality system rather than under a certification of our own.
If your organisation is rethinking how intelligence should be embedded across industrial systems, Pinetics is ready to partner with you to engineer the next generation of automation.
Sanjay Barewar, Director, Co-Founder and Global Chief Delivery Officer, Pinetics. 22+ years in electronic product development. BE Electrical, Pune University. LinkedIn
