The Factory Is Eating Its Own Engineering Process
There’s an irony running through the industrial automation industry right now. Companies that sell precision control systems — products whose entire value proposition is structured, deterministic behavior — have historically run their own engineering processes with startling informality. Requirements lived in Word documents, tribal knowledge, and the long memories of senior engineers who’d been with the company since the fieldbus era.
That’s changing, and the driver is not purely internal discipline. It’s a convergence of three external pressures: AI tooling that has finally matured enough to be useful in engineering contexts, safety standards that are demanding more structured evidence than informal processes can produce, and customers — automotive OEMs, pharmaceutical manufacturers, food processors — who are asking harder questions about system behavior and expecting traceable answers.
The result is an industry in the early, uneven stages of applying requirements engineering rigor to its own product development, while simultaneously grappling with what it means to write requirements for systems that increasingly adapt at runtime.
What’s Actually Happening on the Ground
Talk to systems engineers at PLC vendors, SCADA platform companies, or collaborative robotics firms and you’ll hear a consistent story: the tooling is ahead of the process maturity. Companies are purchasing requirements management platforms, deploying AI-assisted specification tools, and then discovering that the harder problem is upstream — figuring out what requirements to capture in the first place.
The automation industry’s requirements problem is partly structural. PLCs are not designed in isolation. A Siemens S7-1500 or an Allen-Bradley ControlLogix is developed against a requirements set that spans firmware, hardware, software, certification bodies, and dozens of vertical-market use cases simultaneously. The requirements surface is vast, and historically the way companies managed this was through deep specialization: firmware engineers knew firmware requirements, hardware engineers knew hardware requirements, and integration was handled through experience and iteration rather than through explicit requirement-to-requirement traceability.
AI-assisted tools are beginning to stress-test this model. When a tool can ingest a requirements document and flag gaps, inconsistencies, or missing verification criteria, it suddenly matters whether your requirements document actually contains your requirements — or whether it’s an artifact that ratifies decisions already made by people whose reasoning was never written down.
This is the tacit knowledge problem, and it’s particularly acute in industrial automation.
Tacit Knowledge Is the Actual Hard Problem
Every industrial automation company has engineers who carry irreplaceable operational knowledge in their heads. The PLC firmware developer who knows that a particular timing behavior was introduced in 2019 to accommodate a Modbus edge case on a specific European grid configuration. The SCADA architect who can tell you why a particular data historian schema was designed the way it was, and why changing it would break three integrations nobody has documented. The robotics safety engineer who knows which risk reduction measures were accepted by the notified body and which ones were proposed and rejected.
This knowledge is not in any requirements document. It lives in commit histories, meeting notes, email threads, and increasingly, nowhere at all as those engineers retire.
AI-assisted requirements tools can help, but the mechanism matters. Tools that work purely on existing documentation will systematically miss tacit knowledge because tacit knowledge by definition isn’t in the documentation. The more productive application is using AI to structure knowledge elicitation — helping senior engineers articulate what they know in a form that becomes part of a structured model, rather than trying to extract requirements from documents that never fully captured them.
This is where the difference between document-centric and model-centric approaches becomes operational rather than theoretical. A document-centric tool gives you a better Word document. A model-centric tool gives you a graph of relationships that can reveal where knowledge is missing — where a requirement has no verification method, where a design decision has no upstream requirement, where a safety measure has no associated hazard analysis artifact. Those gaps are visible in a model in a way they simply aren’t in a document.
IEC 61511 and IEC 62061: Standards as Requirements Forcing Functions
The safety standards landscape is accelerating this shift more than any internal initiative. IEC 61511, which governs functional safety for process industry sectors, and IEC 62061, which addresses safety of machinery including automation systems, are both demanding levels of requirements traceability that informal processes cannot satisfy.
IEC 61511’s requirement for a safety requirements specification — the SRS — is not new. What’s changing is how rigorously certification bodies and end customers are auditing compliance. A manufacturer claiming SIL 2 compliance for a safety instrumented function needs to demonstrate not just that the SRS exists, but that requirements are traceable through design, implementation, verification, and validation. Auditors who accepted informal evidence five years ago are increasingly asking for structured artifacts.
IEC 62061, updated as part of the broader IEC 62061:2021 revision, has sharpened requirements around safety function requirements specifications (SFRS) and the explicit link between risk assessment outputs and safety requirements. For collaborative robot manufacturers specifically — who are operating under both IEC 62061 and ISO/TS 15066 for human-robot collaboration — this means safety requirements must be traceable from hazard identification through risk reduction measures through functional requirements through verification test cases.
This is a non-trivial traceability chain, and maintaining it manually across a product with multiple hardware variants, software versions, and customer-specific configurations is not a sustainable engineering practice. It’s one area where requirements tooling that supports configuration-aware traceability — tracking which requirements apply to which product variant — provides immediate, auditable value.
The important point for engineering teams is that these standards are not asking you to adopt any particular tool. They’re asking you to demonstrate structured evidence. The tool question is downstream of the evidence question: what evidence do you need, and what’s the most reliable way to produce and maintain it?
The Blurring Boundary: Product Requirements vs. Production System Requirements
Perhaps the most structurally interesting development in industrial automation right now is the collapse of a boundary that the industry has historically taken for granted: the line between product requirements and production system requirements.
When a PLC was a discrete device with a fixed instruction set, the manufacturer’s requirements and the end user’s application requirements were clearly separate. The manufacturer specified the hardware and firmware. The user specified the application logic. The integration was the user’s problem.
That model is dissolving. Modern industrial automation systems — edge-computing-capable PLCs, cloud-connected SCADA platforms, collaborative robots with onboard AI — are increasingly configured, parameterized, and sometimes trained by end users in ways that affect system behavior at a level that was previously only touched by manufacturers. A cobot’s speed and force limits might be configured by a system integrator based on a site-specific risk assessment. A SCADA historian’s anomaly detection model might be retrained on plant-specific data. An edge PLC might be running inference against a model provided by the OEM, fine-tuned by the customer.
In this environment, whose requirements govern system behavior? The answer is increasingly: both, and they need to be explicitly connected.
This creates a requirements engineering challenge that neither traditional product development tools nor traditional operational technology documentation practices were designed to handle. Requirements tools built for hardware product development assume a relatively stable product boundary. Operational technology documentation practices assume that the product is a fixed artifact being configured, not an adaptive system being co-developed with end users.
The companies getting ahead of this are treating production system requirements as first-class artifacts alongside product requirements — and building traceability not just within each set but across the boundary. A product-level requirement for safe stopping behavior needs to trace forward to the configuration parameters that implement it in a specific application, which need to trace forward to the risk assessment that justified those parameters, which need to trace back to the hazard analysis that identified the relevant scenarios. That full chain is a requirements problem, not just an integration problem.
How Modern Requirements Tools Are Responding
The requirements tooling landscape for industrial automation has historically meant IBM DOORS or Jama Connect — document-centric tools that manage requirements as structured text and provide basic traceability. These tools work. They have track records in aerospace, automotive, and defense that prove they can support complex systems engineering. But their limitations become visible precisely in the conditions that define modern industrial automation: dynamic system boundaries, AI-augmented functions, and requirements that need to span product and production contexts.
The more interesting developments are coming from tools built on graph-based data models, where the fundamental unit is not a requirement document but a network of typed relationships between requirements, design decisions, hazards, verification methods, and configuration states. This architecture makes cross-boundary traceability — the product-to-production connection described above — a natural operation rather than a workaround.
Flow Engineering has built its platform around this model, with an explicit focus on the AI-native generation and management of requirements graphs for hardware and systems teams. For industrial automation companies dealing with the product-to-production boundary problem, the relevant capability is the ability to model requirements across organizational and system boundaries without forcing everything into a single document hierarchy. Requirements from a safety instrumented system, a product specification, and a site-specific risk assessment can exist in the same model with explicit relationships, rather than in three separate documents with informal cross-references.
This matters operationally when a design change is proposed. A graph-based model can propagate the impact of that change across all related requirements and verification artifacts — including across the product-to-production boundary — in a way that document-based systems require significant manual effort to replicate.
The limitation worth naming honestly: tools built for the AI-native, model-centric approach are newer and carry less certification body recognition than DOORS-based workflows. For teams under strict regulatory scrutiny where tool qualification matters, this requires explicit assessment. It’s a deliberate trade-off between methodological modernity and institutional familiarity — not a reason to avoid these tools, but a reason to plan tool qualification activities into your adoption timeline.
Practical Assessment: Where to Start
Industrial automation engineering teams considering this shift should resist the urge to solve the tooling problem before solving the knowledge problem. The sequence matters.
The first step is identifying where tacit knowledge is creating the most risk — typically in safety-critical subsystems, in areas with high retirement risk among senior engineers, or in product-to-production integration points that currently have no formal requirements documentation. These are the areas where structured requirements work will return the most value.
The second step is choosing a requirements model — document-based or graph-based — based on the actual traceability questions you need to answer. If your primary challenge is satisfying an IEC 61511 audit with cleaner documentation of requirements you already understand, document-centric tools may be sufficient. If your challenge is maintaining traceability across a system where boundaries are dynamic and requirements exist at multiple organizational levels, a graph-based approach will prove more durable.
The third step is taking AI assistance seriously as a knowledge elicitation tool, not just a document processing tool. The most productive use of AI in requirements engineering for industrial automation is helping engineers articulate what they know in structured form — asking the generative questions that surface implicit assumptions, incomplete rationale, and missing verification criteria.
Honest Assessment
The industrial automation industry is at the beginning of a genuine shift in how it manages requirements. The drivers are real — safety standards with teeth, system complexity that exceeds what informal processes can handle, and AI tooling that is now capable enough to be useful in engineering contexts. The progress is real but uneven. Companies are adopting tooling faster than they’re building the process maturity to use it well, and the harder problem — capturing tacit knowledge before it walks out the door — remains largely unsolved.
The boundary collapse between product requirements and production system requirements is the most structurally significant development, and it’s the one existing tooling handles least well. Teams that build requirements models capable of spanning that boundary — connecting product specifications to site-specific configurations to safety cases — will be better positioned for the next decade of industrial automation than teams that treat it as someone else’s problem.
That’s not a comfortable conclusion for an industry that has long relied on clean system boundaries to manage complexity. But the complexity is already there. The question is whether to make it visible and manageable, or to leave it implicit and hope the next audit goes well.