Industrial Automation’s Quiet Systems Engineering Transformation

Walk into the engineering offices of a mid-size PLC manufacturer five years ago and you would have found requirements living in Microsoft Word, verification evidence scattered across SharePoint folders, and a general understanding that the safety team handled “the IEC stuff” while the rest of engineering built features. That picture is changing — not dramatically, not all at once, but in ways that are restructuring how automation OEMs hire, what tools they buy, and how they defend their products when a process plant goes wrong.

This transformation is being driven by three converging forces: functional safety standards with teeth, customers who are now sophisticated enough to audit engineering processes rather than just test products, and a product liability environment that has grown considerably less forgiving. Understanding how these forces interact — and where automation companies are succeeding or stumbling — matters for anyone building systems that end up inside industrial environments.

The Standards Are No Longer Decorative

IEC 61511 (Functional Safety: Safety Instrumented Systems for the Process Industry) and IEC 62061 (Safety of Machinery: Functional Safety of Safety-Related Control Systems) are not new. What has changed is how rigorously they are being applied and, critically, how they are being interpreted by customers and auditors rather than manufacturers.

IEC 61511 is particularly consequential. Its third edition, combined with the process industry’s accumulated incident history, has created a situation where engineering documentation is no longer just a certification artifact — it is legal evidence. When a safety instrumented system fails to shut down a process that then injures workers or causes an environmental release, the forensic question is not only “did the SIS fail?” but “was the SIS designed, verified, and validated with an engineering process that could reasonably have been expected to catch this failure mode?” That question requires traceable requirements, traceable test evidence, and a demonstrable link between them.

IEC 62061 is pressing in a different direction — into collaborative robots, light curtains, and safety PLCs used in machinery applications — but the structural demand is similar: you must be able to show that requirements were allocated to subsystems, that each requirement was verified, and that the verification evidence was produced systematically rather than retroactively assembled.

The practical implication for OEMs is that the safety lifecycle is no longer something you can run in parallel with product development and then reconcile at the end. It has to be woven into the development process from concept through decommissioning. That is not a process improvement — it is an organizational redesign for companies that grew up building products rather than managing safety cases.

Customer-Driven Pressure Is More Specific Than Standards

Standards define process requirements in the abstract. Customers define them in contracts, and the customers pushing hardest are the ones with the most sophisticated engineering organizations themselves.

Automotive Tier 1 suppliers and OEMs buying factory automation systems now routinely include supplier quality requirements that reference ISO 9001, IATF 16949, and internal process standards in the same document. They want to see requirements management plans, traceability matrices linking system requirements to subsystem specifications to test records, and evidence that design changes go through formal impact analysis. For a collaborative robot manufacturer selling into an automotive body shop, meeting these requirements is a condition of the purchase order, not a nice-to-have.

Pharmaceutical end-users come from a different direction but arrive at similar demands. FDA 21 CFR Part 11 and GAMP 5 (Good Automated Manufacturing Practice) create validation obligations for the automation systems used in regulated manufacturing. When a pharmaceutical company deploys a SCADA system or a batch control platform, their internal validation team must produce evidence that the system is qualified — and that evidence is far easier to produce when the OEM can provide structured requirements documentation, configuration management records, and formal test protocols.

The net effect is that automation OEMs selling into these verticals now face requirements audits that look a lot like what their aerospace counterparts have dealt with for decades. The difference is that aerospace companies built engineering processes around these requirements from the beginning. Many industrial automation companies are retrofitting process rigor onto organizations and toolchains that were not designed for it.

Where Engineering Organizations Are Actually Breaking

The honest account of where automation OEMs are struggling is not flattering to the industry, but it is accurate.

Requirements authorship is distributed and unstructured. Product management writes market requirements in presentation decks. Systems engineers write functional specifications in Word. Software writes feature tickets in Jira. Hardware writes design specifications in a separate Word document. Nobody has owned the problem of making these artifacts traceable to each other, because historically nobody needed to. When a customer or auditor asks for a traceability matrix, the answer is often a manually assembled spreadsheet that took an engineer three weeks to produce and is already out of date.

Verification is activity-based rather than requirement-based. Test plans are written around what the product does, not what the requirements say it must do. This means passing a test suite does not actually demonstrate requirement coverage — it demonstrates that tested behaviors work. The difference matters enormously in a safety case.

Change management is not formally connected to requirements. Engineering change orders exist, but they are not systematically linked to the requirements they affect. When a change propagates unexpected impacts through a system, the organization discovers this through integration testing or, worse, through field failures.

Safety engineers are a constraint rather than a capability. In many automation OEMs, the functional safety team is small, specialized, and positioned as a gate at the end of development rather than a practice integrated into the engineering process. This creates both quality problems and scheduling problems — the safety case review becomes a blocking dependency that is always on the critical path.

What Forward-Looking OEMs Are Actually Doing

The companies moving fastest on this transformation share a few structural characteristics.

They are separating the requirements management function from document management. The old approach was to write a requirements document and manage versions of that document. The new approach is to manage requirements as individual objects — with attributes, ownership, status, and linkages to other requirements, design elements, and test records. This is the difference between a filing system and a model.

They are building V&V into sprint cycles rather than treating it as a post-development phase. This requires requirements that are specific enough to be independently verifiable at the end of each development increment — which in turn requires upfront investment in requirements quality that many teams have never had to make.

They are investing in toolchain integration. Requirements need to connect to CAD outputs, firmware ticket systems, simulation results, and test management platforms. The traceability that safety standards and customer audits demand cannot be maintained manually at any reasonable scale.

This is where modern requirements management tools become operationally important rather than theoretically appealing. Platforms like Flow Engineering, built specifically for hardware and systems engineering teams, implement graph-based traceability natively — meaning that the connection between a system requirement, its derived subsystem requirements, its verification methods, and its test records is a live, queryable data structure rather than a manually maintained spreadsheet. When a requirement changes, the tool surfaces what else is affected. When a safety auditor asks for coverage evidence, the report is generated from the model, not assembled by hand.

For automation OEMs navigating IEC 61511 or IEC 62061 compliance, this kind of connected traceability is not a convenience — it is the difference between a manageable audit and an engineering fire drill.

The Organizational Dimension

Tooling changes are necessary but not sufficient. The deeper transformation happening at leading automation OEMs is organizational.

Systems engineering, historically a role that existed on paper or in a small centralized team, is being distributed across product development. Model-based thinking — decomposing systems into functions, allocating functions to subsystems, and tracing requirements bidirectionally — is becoming a baseline competency expected of product-level engineers, not just a specialty practiced by a systems group.

This is producing real hiring pressure. Systems engineers who understand both functional safety standards and modern requirements tooling are not abundant. Companies that invested in developing this capability internally — through training, mentoring, and structured process improvement — are ahead of those trying to hire their way to compliance.

The other organizational shift is in how engineering leadership thinks about verification. In the old model, verification was something QA did. In the model being adopted under safety standard pressure, verification is an engineering activity that development teams own, with QA providing oversight and audit rather than execution. This is a meaningful cultural change in organizations where “testing” and “engineering” have historically been separate.

An Honest Assessment of Where This Is Heading

The transformation is real and the direction is clear, but the pace is uneven and the friction is significant.

Large automation OEMs — Siemens, Rockwell, Emerson, Honeywell — have the resources to invest in formal systems engineering practice and have been doing so for years, driven in part by their own product liability exposure. Their toolchains are often a patchwork of legacy platforms (IBM DOORS for requirements, various custom integrations for test management) supplemented by newer tools, but the process discipline exists.

Mid-size OEMs — companies building specialized PLCs, collaborative robots, or domain-specific SCADA platforms — are at a more uncertain point. Many have recognized the problem but have not yet committed to the toolchain and organizational investment required to solve it. They are feeling the customer pressure but managing it through heroic individual effort rather than systematic process.

Small automation companies selling into regulated verticals are often one major audit failure away from a significant business problem. Their engineering processes were designed for building good products, not for demonstrating to external parties that the products were built rigorously. The gap between those two things is exactly what IEC 61511 and sophisticated customers are now probing.

The companies that will be best positioned in three to five years are those that treated this not as a compliance exercise but as an engineering capability investment. Requirements quality, traceability architecture, and formal V&V processes are genuinely hard to build — but once built, they become a competitive differentiator in markets where customer trust and liability management are part of the value proposition.

The irony is that industrial automation, an industry built on making complex systems reliable, is now having to apply that same rigor to how it builds the systems themselves. That is not a bad irony. It is probably overdue.