Mechatronics is one of the few engineering disciplines with a definition tight enough to argue about. The IEEE/ASME Transactions on Mechatronics, established in 1996, describes its subject as “the synergetic integration of mechanical engineering with electronic and intelligent computer control in the design and manufacture of industrial products and processes.” The operative word is integration: the artifact is designed as one thing, and a decision made in the control software is a decision about the gearbox.
For most of that history, “intelligent computer control” meant deterministic control. A transfer function, a state machine, a tuned loop — specified in advance, verifiable against the specification, and failing in ways an engineer could enumerate. The change now underway is narrow and consequential. Inference is becoming a component that lives inside the machine rather than a service the machine calls. The control loop acquires a learned element, and that has downstream effects on design, safety, verification, and where the value actually shows up.
What changes when inference becomes a part
Edge AI here means inference executed on or beside the machine rather than in a remote service. Physical AI means a system that senses and acts on the physical world rather than producing text or charts for a person to read. Robotics digital intelligence is the useful shorthand for what the combination produces: a machine that interprets its own state and acts on it, rather than executing a plan computed somewhere else. All three terms are used loosely in the market; the distinction that matters to a designer is none of them. It is the difference between a component and a service.
A component has a line on the bill of materials, a power draw, a thermal contribution, a failure rate, and a defined behavior at its interfaces. A service has an availability target and a contract. Moving inference across that boundary converts a commercial property into a physical one. The model now competes for watts with the actuators, adds heat inside the same enclosure, and has to survive the same vibration and temperature range as everything else in the housing. Enclosure volume, heat path, and power budget become model-selection constraints — which is precisely the kind of cross-domain coupling mechatronics exists to handle, and precisely the kind that no single discipline owns.
There is a second effect, quieter. ISO 8373:2021, the robotics vocabulary standard, defines a robot as a “programmed actuated mechanism with a degree of autonomy … to perform locomotion, manipulation or positioning,” where degree of autonomy is assessed by the quality of the machine’s decision-making and its independence from a human. A learned element raises autonomy by that definition. It does not, on its own, raise anyone’s ability to state what the machine will do.
Why put it inside the machine at all
Three reasons, in order of how binding they are.
Time. A control loop has a cycle budget measured in milliseconds or less, and everything inside the loop needs a worst case. A network round trip is a distribution, not a bound. Anything whose latency cannot be bounded belongs outside the loop by construction, which is the whole argument in one line.
Availability. A machine whose function depends on a link has made connectivity a single point of failure. Mechanical engineers already know how to reason about single points of failure, and generally reject them in load paths. The same instinct applies here and is often not applied, because the dependency is invisible on the drawing.
Signal. This is the underrated one, and it carries most of the value. The measurements that reveal a machine’s condition earliest are the dense ones: full-rate vibration, current and voltage waveforms, acoustic emission. Shipping them upstream means downsampling or summarizing them first, which discards exactly the features that carry early information. Running inference at the source lets a model see the signal at its native rate. The gain is not a cheaper bill. It is a class of evidence that was previously unusable becoming usable.
The learned element belongs inside a deterministic envelope
That is not a stylistic preference. ISO 13849–1:2023 defines a safety-related part of a control system and assigns it a performance level — a discrete level specifying the ability to perform a safety function under foreseeable conditions. IEC 61508, the generic functional safety standard for electrical, electronic, and programmable electronic safety-related systems, assigns safety integrity levels on the basis of systematic capability, architectural constraints, and probability of dangerous failure. Both frameworks assume the same two things: that the intended function can be stated, and that an implementation can be shown to deliver it with a quantified failure probability.
A learned element is specified by its training distribution and evaluated statistically. Neither standard has a natural slot for that. So the practical architecture puts torque limits, stop functions, and interlocks in the rated deterministic layer, and lets the model shorten a cycle, adjust a set point, or flag a degrading bearing — inside limits it has no authority to move.
A learned element earns its place by making a machine better within limits it cannot change. The moment it can change the limits, everything upstream of it has to be certifiable, and nothing about how such elements are built makes that easy.
The verification problem the discipline has not solved
Standards bodies have acknowledged the gap without closing it. ISO/IEC TR 5469:2024, Artificial intelligence — Functional safety and AI systems, published in January 2024, sets out a qualitative view of functional safety risk across combinations of AI technology class and usage level, describes a three-stage realization principle for using AI technology in safety-related systems, and devotes separate clauses to verification and validation challenges and to control and mitigation measures. Its status is worth reading carefully: a technical report is informative rather than normative. The subject was live enough to require a document and unsettled enough that the document could not yet be a requirement.
NIST’s AI Risk Management Framework (AI 100–1, 2023) supplies the complementary organizational discipline, and it is a management framework rather than a verification method. Neither document hands a machine designer a test to run.
What is actually missing is a treatment of the failure mode. Conventional component failure is bounded and detectable: a sensor opens circuit, an encoder loses counts, a driver latches. A learned element fails by being confidently and plausibly wrong in a region of input space it was never shown, and that failure leaves no signature at the interface. Detecting it requires a second, independent estimate — a physics-based model, redundant sensing, or a plausibility bound derived from the mechanics of the machine itself. Designing that independent check, not selecting the model, is where the engineering effort belongs.
Where it lands first: robot cells and shared workspaces
Industrial robotics is the leading case because the installed base is large and already instrumented. The International Federation of Robotics reports 542,000 industrial robots installed worldwide in 2024, the fourth consecutive year above 500,000 units, bringing operational stock to 4,664,000 units, up 9 percent year over year; Asia accounted for 74 percent of new deployments against 16 percent in Europe and 9 percent in the Americas, with U.S. installations at 34,200 units, down 9 percent. The IFR projects roughly 575,000 installations for 2025, a figure that should be read as a forecast rather than a result. Learned components will mostly arrive as retrofits into that stock, not as a new category of machine — which is why robotics digital intelligence will show up first as an upgrade to installed equipment rather than as a new class of robot.
The standards moved with it. ISO 10218–1:2025, the third edition, published in February 2025, replaced the 2011 edition; per its scope, it incorporates safety requirements for industrial robots used in collaborative applications — content formerly carried in ISO/TS 15066:2016 — and adds requirements for cybersecurity to the extent it bears on robot safety, alongside clarified functional safety requirements and a robot classification scheme.
Collaborative operation is where perception quality becomes a safety-relevant engineering quantity. Under speed and separation monitoring — one of four collaborative modes treated in ISO/TS 15066:2016, alongside safety-rated monitored stop, hand guiding, and power and force limiting — the system maintains a protective separation distance from the person and modulates robot speed to preserve it. Throughput is therefore a direct function of how quickly and how accurately the machine can locate a human. A better perception model buys cycle time and changes a safety margin through the same variable. Very few design problems put economic value and safety consequence on the same axis; this one does, and the design has to hold both at once.
Smart human–computer–machine interaction spaces
Call a smart interaction space one where a person, a computing system, and a machine share physical volume, and the machine acts on an inferred model of the person. Two consequences follow, and both are design obligations rather than features.
First, the model of the human is a safety-relevant component. Once machine behavior depends on an inference about where someone is, where they are heading, or whether they are attending, that inference inherits a specification burden it never carried when it only drove a display.
Second, legibility becomes a safety property. ISO 9241–210:2019 sets out requirements and recommendations for human-centered design across the life cycle of computer-based interactive systems. Applied to a machine that moves, the principle sharpens: the person sharing the space has to be able to predict what it will do next. A machine that is technically safe but behaviorally unpredictable gets worked around, and a safety function people route around is not performing a safety function.
Where it goes next, and when
Outside the robot cell, the same shift reaches ordinary installed equipment — pumps, fans, handling gear, building systems. The design consequence there is that the sensor stops being an instrument and becomes part of the model. Calibration drift, mounting variation, and mechanical aging are no longer measurement nuisances to be corrected; they are distribution shift, and they degrade inference rather than merely biasing a reading. Where the accelerometer mounts and how the enclosure resonates set the model’s input distribution for the service life of the unit. Nobody in a conventional org chart owns that decision, which is the clearest sign it is a mechatronics decision.
As for when: the institutional clock is already running. NIST published its AI risk framework in 2023, ISO/IEC issued the functional safety and AI technical report in January 2024, and ISO published the first substantive revision of the industrial robot safety standard in fourteen years in February 2025. Three consecutive years of movement by standards bodies is not a forecast; it is a record. Procurement language and insurance requirements historically follow published standards with a lag, so machines being designed now are likely to be sold into a market that asks for evidence rather than assurances.
Three practices follow, and none require a new technology. State the authority partition explicitly in the design documentation: what the learned element is permitted to change, and what it is not. Specify the independent check before selecting the model, including which physics supplies the second estimate. And treat the mechanical mounting as part of the model specification, because it is.
Mechatronics has always been the discipline that refuses to let mechanical, electronic, and control decisions be made separately. A learned element in the loop is simply the next thing that cannot be designed in isolation — and the first one whose failures do not announce themselves. Robotics digital intelligence will be judged, in the end, not on what the model can infer but on whether the machine around it was designed to contain a component that can be wrong.
References
IEEE/ASME Transactions on Mechatronics (published since 1996), Aims and Scope, IEEE Xplore, accessed August 2026. https://ieeexplore.ieee.org/xpl/RecentIssue.jsp?punumber=3516
International Organization for Standardization (2021), ISO 8373:2021 — Robotics — Vocabulary, accessed August 2026. https://www.iso.org/standard/75539.html
International Organization for Standardization (2025), ISO 10218–1:2025 — Robotics — Safety requirements — Part 1: Industrial robots, accessed August 2026. https://www.iso.org/standard/73933.html
International Organization for Standardization (2016), ISO/TS 15066:2016 — Robots and robotic devices — Collaborative robots, accessed August 2026. https://www.iso.org/standard/62996.html
International Organization for Standardization (2023), ISO 13849–1:2023 — Safety of machinery — Safety-related parts of control systems — Part 1: General principles for design, accessed August 2026. https://www.iso.org/standard/73481.html
International Electrotechnical Commission (2010), IEC 61508–1:2010 — Functional safety of electrical/electronic/programmable electronic safety-related systems — Part 1: General requirements, accessed August 2026. https://webstore.iec.ch/en/publication/5515
ISO/IEC (2024), ISO/IEC TR 5469:2024 — Artificial intelligence — Functional safety and AI systems, accessed August 2026. https://www.iso.org/standard/81283.html
National Institute of Standards and Technology (2023), Artificial Intelligence Risk Management Framework (AI RMF 1.0), NIST AI 100–1, accessed August 2026. https://doi.org/10.6028/NIST.AI.100-1
International Federation of Robotics (2025), World Robotics 2025 — Global Robot Demand in Factories Doubles Over 10 Years, accessed August 2026. https://ifr.org/ifr-press-releases/news/global-robot-demand-in-factories-doubles-over-10-years
International Organization for Standardization (2019), ISO 9241–210:2019 — Ergonomics of human-system interaction — Part 210: Human-centred design for interactive systems, accessed August 2026. https://www.iso.org/standard/77520.html
Originally published on Medium.
Top comments (0)