How Industrial Automation Primes Are Adopting Model-Based Systems Engineering

Siemens, Rockwell Automation, and ABB are building systems that would have been unrecognizable to their engineering teams a decade ago. A modern automated production line is not a collection of discrete machines with clean interfaces. It is a continuously running hybrid of programmable logic, servo drives, edge AI inference, industrial networking, safety logic, and software-defined control — often supplied by three or four vendors, integrated by a system integrator, and operated by a customer who expects a digital twin of the whole thing before commissioning even starts.

That level of complexity does not compress into a Word document requirements spec. And the industrial automation sector — historically resistant to the heavyweight methodology overhead that aerospace and automotive absorbed decades ago — is now moving toward Model-Based Systems Engineering faster than most observers expected.

The pace is still slower than aerospace. The tooling choices are still fragmented. But the forcing functions are real, and they are not going away.

The Current State: Behind Aerospace, Ahead of Where Industrial Was

To understand how far industrial automation has to go, it helps to understand how far it has come — and how far aerospace already is.

In aerospace and defense, MBSE adoption has been building since the mid-2000s. The Department of Defense began formally pushing model-based approaches around 2010. Major primes like Lockheed Martin and Boeing embedded SysML and MBSE into their development processes under a combination of customer requirement and internal complexity pressure. By the early 2020s, MBSE was standard practice on major programs, with tooling ecosystems — Cameo, DOORS Next, Rhapsody — established enough to support supplier flow-down.

Automotive arrived later but moved faster. ISO 26262 for functional safety and, more recently, SOTIF and the complexity of ADAS development forced systematic requirements traceability on every major OEM and Tier 1. By 2023, no serious automotive electronics or software supplier could operate without demonstrable requirements management and V&V traceability. Tools like Polarion and Codebeamer became standard partly because they sit well in the automotive supplier ecosystem and support ASPICE compliance documentation.

Industrial automation, by contrast, spent the 2010s talking about Industry 4.0 and investing heavily in connectivity and digital twin infrastructure, while requirements and systems engineering discipline lagged behind. The tooling conversation was often about PLM and SCADA, not MBSE. Requirements management, where it existed, was typically handled in IBM DOORS deployments maintained by individual companies without systematic cross-supplier discipline.

That is starting to change, and three factors are driving it simultaneously.

What Is Actually Forcing the Change

Customer digital twin mandates. End customers in energy, food and beverage, and pharmaceutical manufacturing are increasingly specifying that suppliers must deliver a digital twin of the installed system as part of the contract. A pharmaceutical company building a new aseptic filling line wants a live, queryable model of that line — not just P&IDs and wiring diagrams. That requirement, when it flows down to system integrators and component suppliers, forces an upstream conversation about how the system was modeled in the first place. You cannot deliver a meaningful digital twin if you never had a system model.

Regulatory pressure in safety-critical verticals. IEC 62443 for industrial cybersecurity, IEC 61511 for process safety, and FDA 21 CFR Part 11 and EU Annex 11 for pharmaceutical manufacturing all require demonstrable traceability between requirements, design decisions, and validation evidence. These are not new regulations, but enforcement and audit intensity have increased. Customers in these verticals increasingly require that their suppliers demonstrate systematic traceability — and “we have it in DOORS” is no longer a sufficient answer if the traceability is incomplete or manually maintained.

Multi-vendor integration complexity. A Siemens drive system integrated with Rockwell safety logic and ABB robotics on an EtherNet/IP backbone, feeding process data to a cloud historian via an OPC-UA gateway, with edge AI anomaly detection running on a third-party compute node — that is not an unusual configuration. It is increasingly typical. Integrating systems at that level requires clear interface definitions, shared models of behavior, and a way to trace what changed when something breaks. Document-based requirements management is structurally inadequate for this problem.

How the Three Primes Are Responding

Siemens has the most integrated MBSE story of the three, largely because of its 2007 acquisition of UGS and subsequent buildout of the Xcelerator portfolio. Siemens positions NX, Teamcenter, and Capital as a combined systems engineering and digital twin environment. For automation-specific applications, the integration between TIA Portal (for PLC and drive programming), NX MCD (for mechatronic concept design), and Teamcenter (for requirements and lifecycle management) gives Siemens customers a path to model-based development that stays largely within a single vendor ecosystem.

The strength of this approach is coherence — models and requirements can flow between tools without manual export-import cycles. The limitation is lock-in: customers who want to integrate suppliers running non-Siemens toolchains face friction. Siemens has made progress on open standards support (OPC-UA, AutomationML) but the native pull is always toward the Xcelerator stack.

Rockwell Automation has taken a different approach. Rather than building a vertically integrated model-based environment, Rockwell has leaned into ecosystem partnerships. The Plex acquisition (2021) added cloud ERP and manufacturing execution capability; the Plex and FactoryTalk integration gives customers operational data connection. For systems engineering specifically, Rockwell has partnered with third-party MBSE and requirements management platforms rather than building proprietary capability. This gives customers more flexibility on tooling but places more integration burden on the customer or system integrator. Rockwell’s MBSE story is more about enabling the model-based environment than owning it.

ABB is the most heterogeneous of the three. ABB’s industrial automation portfolio spans robotics (post-KUKA competition, with its own IRB lines), electrification, process automation, and motion control — each with historically separate development organizations and tooling choices. ABB has made public commitments to digital twin capability through its ABB Ability platform, and its acquisition activity in software (B&R was acquired but remains largely independent; Bernina’s digital integration efforts are ongoing) shows intent. But the internal consolidation of MBSE tooling and process is still underway. ABB customers in process industries see strong digital twin capability at the system level but variable requirements traceability discipline depending on which ABB division is delivering.

Where Industrial Automation MBSE Differs from Aerospace and Automotive

Three structural differences define the gap.

Certification structure. Aerospace programs live or die by certification. DO-178C, DO-254, ARP4754A — these standards have specific requirements for how design artifacts are structured, traced, and reviewed. That certification pressure creates a forcing function for systematic MBSE that simply does not exist at the same intensity in most industrial automation programs. IEC 61511 and IEC 62443 impose discipline, but the audit and certification infrastructure is less rigorous than aviation.

Supplier ecosystem maturity. Aerospace and automotive have spent decades establishing tooling standards that flow down through supply chains. An automotive OEM can specify ASPICE Level 2 compliance and know that major Tier 1 suppliers have implemented processes to meet it. Industrial automation supply chains are more fragmented, with smaller suppliers, more custom integrations, and less standardized process maturity. Getting a consistent MBSE approach to flow down to a drive manufacturer, a vision system vendor, and a safety relay supplier simultaneously is a different class of problem.

Program timelines. A major aerospace program runs for decades. An industrial automation project to build a new production line might run 18 months from concept to commissioning. The methodology overhead that is amortized over a 20-year aircraft program is harder to justify on an 18-month integration project, even if the underlying complexity warrants it. Industrial automation teams are looking for MBSE approaches that are lightweight enough to fit their project timelines, which pushes them toward tools that reduce methodology overhead rather than adding it.

What This Means for Tooling Choices

The tooling conversation in industrial automation MBSE is different from aerospace and automotive in one important respect: requirements traceability and the system model need to connect to operational data in ways that aerospace programs historically did not require. A pharmaceutical customer does not just want a model that traces requirements to design decisions — they want a model that connects to the live system and can be used to support change management, validation, and ongoing compliance.

That operational connection is where graph-based, AI-native platforms have an advantage over document-centric tools. Tools like Flow Engineering, which build requirements traceability on a connected model rather than a document hierarchy, are better positioned to serve industrial automation’s need for live traceability between requirements, design artifacts, and operational data than legacy platforms that treat the requirements database as a separate artifact from the system model.

The specific failure mode of document-based requirements management in industrial automation is multi-vendor interface change. When a supplier changes a component specification, the impact on system-level requirements needs to propagate automatically — not through a manual change notice process that relies on someone knowing which rows in which spreadsheet to update. Graph-based traceability handles this structurally because the impact is encoded in the model relationships, not in a document that someone has to remember to check.

Honest Assessment: Progress Is Real, But Discipline Is Uneven

Industrial automation’s MBSE adoption is genuine and accelerating. The investment in digital twin infrastructure by Siemens, Rockwell, and ABB is substantial and real. End customer mandates are creating market pull that was absent five years ago. Regulatory pressure in safety-critical verticals is tightening.

But the discipline gap is real. Having a digital twin of an installed system is not the same as having practiced MBSE during development. Many industrial automation teams have the infrastructure for model-based operation but have not yet built the upstream requirements and architecture modeling discipline that makes the model authoritative rather than decorative.

Aerospace got there through certification pressure and long program timelines. Automotive got there through safety standards and supply chain discipline. Industrial automation is getting there through customer demand and regulatory pressure — but the translation of that pressure into consistent internal practice is still uneven across teams, suppliers, and verticals.

The companies that close that gap fastest will be the ones that treat requirements traceability not as compliance documentation but as the connective tissue between system design and operational reality. That is a different mindset than most industrial automation organizations have historically maintained. It is also, increasingly, what their customers are paying for.