Industrial Automation Is Hitting a Complexity Ceiling — And Systems Engineering Is Being Rediscovered

For most of the twentieth century, industrial automation was hard in the mechanical and electrical sense. A programmable logic controller running a bottling line, a hydraulic press with safety interlocks, a conveyor system with proximity sensors — these were complex devices, but their failure modes were largely bounded. They broke in ways engineers could anticipate, test, and document.

That era ended somewhere around the time industrial Ethernet became cheap, cloud connectivity became assumed, and “digital twin” went from academic concept to procurement requirement. What emerged in its place — networks of edge-computing nodes, AI-driven quality inspection systems, OPC-UA connected robotics, and remote monitoring platforms that report to enterprise ERP systems — is a different category of system entirely. These aren’t complicated machines. They’re complex systems, in the formal sense: their behaviors emerge from interactions, not components, and their failure modes can propagate across boundaries that were never designed to be boundaries at all.

Industrial automation is hitting a complexity ceiling. And the engineering discipline that exists to manage this kind of complexity — systems engineering — is being urgently rediscovered by an industry that largely skipped it the first time.

What Changed, and Why It Happened Fast

The discrete-machine paradigm that dominated industrial automation for decades had a practical virtue: each machine was its own system. Requirements lived in a specification document. Testing happened on the factory floor. Acceptance criteria were physical. A safety relay either opened or it didn’t.

Industry 4.0 didn’t just add connectivity to this paradigm — it dissolved the boundaries that made it tractable. When a collaborative robot arm receives real-time path adjustments from an AI inference engine running on edge hardware that gets its model updates from a cloud pipeline managed by an IT team, you no longer have a machine. You have a distributed system with software-defined behavior, operational technology (OT) physics, and information technology (IT) security boundaries — all of which interact.

The implications aren’t theoretical. Consider a connected robotic welding cell: the robot firmware, the vision system, the safety PLC, the MES integration layer, and the remote monitoring dashboard all constitute a single functional system from a safety standpoint — but they were almost certainly procured from four different vendors, integrated by a system integrator who may not have had full access to any vendor’s design documentation, and qualified by a safety engineer who was given a completed system and asked to sign off on it.

This is not an edge case. This is how the majority of industrial automation systems are built today.

Standards as Forcing Functions

Two standards are doing the most work in forcing the rediscovery of formal systems engineering in industrial environments: IEC 61508 and IEC 62443.

IEC 61508 — the foundational functional safety standard for electrical, electronic, and programmable electronic safety-related systems — has existed since 1998. For most of its history, it was treated as a certification burden: something you addressed at the end of a project by engaging a TÜV assessor and producing the required documentation. The standard’s requirements for hazard and risk analysis, safety requirements specifications, and systematic software development were acknowledged but frequently abbreviated.

What’s changed is the systems being certified. When a safety function is implemented in distributed software across multiple hardware platforms — which is increasingly the case for machine safety in connected environments — the standard’s requirements for systematic development and traceability become genuine constraints on how engineering must be organized, not just documentation requirements to satisfy at the end. You cannot produce a credible safety case for a complex system without having done the systems engineering work. The document is evidence of the analysis. If the analysis wasn’t done, the document cannot be credibly produced.

IEC 62443 — the series covering industrial cybersecurity — is producing a similar effect but from a different direction. The standard establishes security levels (SL 1 through SL 4) and requires that security requirements be allocated to system zones and conduits, traced to specific design elements, and verified through documented testing. For industrial automation vendors competing for contracts in critical infrastructure, energy, or process industries, demonstrating conformance to IEC 62443-4-1 (the secure development lifecycle requirements) is increasingly a procurement requirement, not a differentiator.

The interaction between these two standards creates a structural problem for organizations without mature systems engineering practices: functional safety requirements and cybersecurity requirements must be analyzed together, because they interact. A cybersecurity countermeasure that delays a safety function creates a new hazard. A safety architecture that relies on communications integrity creates a security dependency. Managing these interactions requires a connected requirements model — one where safety requirements, security requirements, functional specifications, and verification activities are explicitly linked. A collection of documents in a shared drive cannot do this job at scale.

The Talent Gap: Real, but Not Uniform

The workforce dimension of this problem is nuanced and worth examining carefully, because the conversation tends to collapse into either panic (“there are no systems engineers in industrial automation”) or dismissal (“controls engineers have always done systems thinking”).

Both are partially true.

Controls engineers in industrial automation have always reasoned about systems. A experienced PLC programmer who has designed safety interlocks for a decade understands functional dependencies, failure modes, and the difference between a safe state and a fault state. What they typically lack is the formal vocabulary and methodology of systems engineering: FMEA at the system level, hazard analysis structured around IEC 61508 requirements, requirements management that supports traceability, and model-based techniques for capturing system architecture.

This gap is not a reflection of capability. It’s a reflection of what industrial automation required until recently. A controls engineer who spent fifteen years working on discrete manufacturing lines didn’t need SysML. They needed deep knowledge of the SIMATIC ecosystem, ladder logic, and how to build a panel. That knowledge remains valuable. It just needs to be augmented.

Several patterns are emerging in how companies are developing this capacity:

Incident-driven learning is the most common and least efficient path. An audit failure, a near-miss incident with regulatory consequences, or a major project that fails certification drives a company to invest in systems engineering capability. The knowledge is acquired under pressure, applied to the problem at hand, and sometimes institutionalized — and sometimes lost when the project team disperses.

Systems integrators as intermediaries is a structural workaround. Industrial system integrators who specialize in safety-critical environments (automation specialists working in pharma, oil and gas, or nuclear-adjacent industries) have developed systems engineering capability because their customers demanded it. These integrators are effectively transferring methodology into end-user and machine-builder organizations through project work — which is slow but real.

University curriculum updates are happening, but slowly. Mechatronics and industrial engineering programs are incorporating functional safety and systems engineering content, often driven by faculty who came from automotive, aerospace, or defense. The graduates entering the workforce in 2025 and 2026 have more exposure to formal systems engineering methods than any previous cohort — but they’re a small fraction of the workforce, and they need experienced mentors to develop practical judgment.

Professional development programs from IEC standards bodies, TÜV SÜD, exida, and industry associations are providing functional safety engineering certification (CFSE) and similar credentials at scale. These programs are raising the floor of functional safety literacy significantly, even if they don’t produce fully-formed systems engineers on their own.

The net picture is an industrial workforce that is developing systems engineering capability unevenly, under pressure, and with significant variance between subsectors. Automotive-adjacent industrial automation is ahead. Process industries are making progress. General manufacturing equipment builders are the furthest behind.

What Rigorous Systems Engineering Actually Requires in This Context

The rediscovery of systems engineering in industrial automation isn’t primarily about adopting new tools. It’s about recognizing that certain engineering activities that were optional at lower complexity levels are now mandatory — and that the organizational structures, processes, and tools need to support them.

At minimum, industrial automation organizations building connected, safety-critical systems need:

A structured requirements process that distinguishes stakeholder needs from system requirements from component specifications, and that explicitly allocates requirements to subsystems. This sounds obvious. In practice, most industrial automation requirements exist as customer specifications in PDF format and internal engineering notes. The allocation and traceability don’t exist.

Formal hazard analysis conducted early in the design process, not as a documentation exercise at the end. This means HARA (Hazard Analysis and Risk Assessment) for functional safety, TARA (Threat Analysis and Risk Assessment) for cybersecurity, and — critically — analysis of the interactions between them.

Connected traceability from safety and security requirements through design decisions to verification evidence. In complex systems, this traceability cannot be maintained in spreadsheets without significant labor and significant error rate. The relationships are too numerous and too dynamic.

Change impact analysis as a first-class engineering activity. When a software update changes the behavior of an edge AI model, the systems engineering infrastructure should make it possible to identify which safety and security requirements are potentially affected. Without that infrastructure, every change is a risk.

The tools that support this work matter. Traditional requirements management systems — IBM DOORS, Polarion, and similar platforms — were built for the documentation paradigm of the 1990s and 2000s. They can store requirements and link them with discipline, but they treat requirements as document objects rather than nodes in a model. For industrial automation systems where the interesting information is in the relationships between requirements — between safety goals and security controls, between functional requirements and hardware allocations — that distinction is significant.

Platforms like Flow Engineering, built on a graph-based model rather than a document hierarchy, reflect the architectural insight that systems engineering for complex connected systems is fundamentally a network problem. Requirements, design decisions, hazard analyses, verification results, and change records all need to exist in a connected model that can be queried, analyzed, and traversed — not filed in folders. For teams implementing IEC 61508 or IEC 62443 systematically, this structural difference reduces the labor required to maintain traceability and makes impact analysis tractable. The AI-assisted gap detection in such tools — identifying requirements that lack verification coverage or safety goals that lack allocated mitigations — is particularly relevant for teams that are building their systems engineering capability while actively running programs.

The Competitive Dimension

There is a commercial reality underlying this technical and organizational picture that shouldn’t be ignored: rigorous systems engineering is becoming a competitive differentiator in industrial automation procurement.

End customers in regulated industries — pharmaceutical manufacturers, energy utilities, chemical processors — are increasingly requiring that machine builders and system integrators demonstrate certified functional safety processes, documented cybersecurity conformance, and traceable design documentation as conditions of supplier approval. This is moving down the supply chain from tier-one system builders toward component suppliers.

Industrial automation companies that have invested in the engineering infrastructure to support this — not just the certifications, but the underlying processes and tools — can compete for these contracts. Companies that haven’t are either excluded or forced to rapidly acquire capability on a project-by-project basis, which is expensive and produces variable results.

The organizations positioned best for the next decade of industrial automation are those treating systems engineering infrastructure as a capital investment, not a project cost.

An Honest Assessment

Industrial automation’s rediscovery of systems engineering is real, necessary, and happening — but it is not happening uniformly, quickly, or without pain. The talent gap is genuine. The tooling gap is being addressed but unevenly. The standards are driving the right behaviors, but compliance-oriented implementation can produce the documentation of systems engineering without the substance.

The complexity ceiling is not a temporary condition that will resolve as technology matures. Edge AI, connected robotics, and digital twins are not becoming simpler. The engineering discipline required to build safe, secure, and reliable systems from these components is not optional. Industrial automation companies that recognize this and invest accordingly are not gold-plating their processes. They’re building the capability required to compete in the market that already exists — and the one that’s coming.

The companies that skipped systems engineering when their machines were simpler have a window to close the gap before it closes them.