A Risk-Based Workflow Connects Digital Controller Design and Validation

Validation has to keep pace with control development

Digital control systems can be developed faster than pharmaceutical manufacturers can fit them into validation practice. That mismatch matters because a controller’s technical performance is only one part of its path into production: teams also need to understand the process it affects, define what the system must do, and produce evidence that it works as intended. Researchers at the Pharmaceutical Manufacturing Technology Center at the University of Limerick propose a risk-based workflow that brings process understanding, controller design and validation evidence together across the engineering lifecycle.

The gap, says Dermot McMorrow, assistant professor of digital manufacturing, isn’t primarily a regulatory problem. Guidance already supports automation, iterative development and digital tools, he told GEN. The difficulty is turning those lifecycle principles into routine engineering work, especially when qualification remains sequential and document-driven, with validation activities kept separate from the development process.

That separation can leave risk assessment, requirements, verification and evidence generation disconnected. Teams may identify a concern in one part of the work, then struggle to show how it shaped a design decision or a test later on. The proposed workflow aims to establish those links from the start, so validation-related evidence accumulates as a system is built instead of being assembled after development.

That’s a practical distinction. When evidence is generated alongside engineering decisions, it can be easier to see what a test covers and which risks remain unresolved. The approach doesn’t remove the need for review or judgment; it gives those activities a clearer thread to follow.

Risk informs the controller lifecycle

The team tested the approach on a model predictive controller for pH regulation. Led by Damian McCarthy, staff robotics test engineer, with senior author Eoin Hinchy, associate professor of automated manufacturing, the researchers used a data-driven Hammerstein-Wiener model to support controller tuning. They also analyzed the process and control system to identify and rank failure modes. Those risks then informed requirements and the scope of verification.

This sequence connects process knowledge to the decisions engineers make about the controller. A risk assessment has limited value if it sits in a separate document and doesn’t affect what gets built or tested. Here, the team used identified failure modes to help define what the controller needed to do and what evidence would be relevant to checking it.

McMorrow describes the central benefit as a connected engineering lifecycle: process understanding and quality risk management inform controller development, requirements, verification and deployment. The workflow also traces each identified risk to functional requirements, acceptance criteria, verification activities and the evidence those activities produce. That chain gives teams a way to inspect whether important concerns have been carried through the work.

This traceability can help teams focus testing on the risks that matter most. The researchers’ approach supports repeatable automated tests alongside physical challenge testing, which address different parts of the verification task. Automated tests can be repeated as the design changes; physical challenges can provide evidence about behavior in the process context. Neither type of test answers every question on its own.

If process changes are easier to validate, manufacturers may also find it less difficult to make ongoing system improvements. That’s the intended practical value: a change can be assessed through the same linked requirements and evidence, rather than forcing teams to reconstruct the reasoning after the fact. The claim is plausible, but it depends on teams maintaining those links as the system evolves.

The team demonstrated deployment in an industrial programmable logic controller environment. The controller, developed and verified in a model-based setting, was implemented using IEC 61131-3 structured text, an industry-recognized format. McMorrow says that format also supports traceability across the wider model-based workflow.

Moving from a model to an industrial controller is a useful step because it tests whether the workflow can reach an implementation environment manufacturers recognize. It doesn’t by itself establish that every deployment will follow the same path or produce the same results. The details of a process, its risks and an organization’s quality system still shape what evidence is needed.

Adoption calls for staged implementation

Introducing this approach in a regulated manufacturing organization will take iteration, testing and user feedback. The researchers recommend assessing both the maturity of the technology and the organization’s readiness to adopt it. That distinction matters: a technically capable tool can still be difficult to integrate if teams, processes or supporting systems aren’t prepared for the work it requires.

Their earlier work includes an innovation maturity rubric to help structure those assessments. A staged review can give an organization a clearer view of where a proposed method is ready for use and where further development is needed. It also gives teams a basis for gathering feedback as they learn how the workflow fits actual engineering and validation practices.

In prior doctoral research, McMorrow found that model-based design and digital validation could streamline compliance work, reduce resource demands and improve traceability in practical settings. The proposed workflow could also reduce repeated manual testing and documentation, supporting the real-time reconfiguration required in modern production. Those potential gains are relevant, but they don’t mean the work disappears: teams still need to decide what must be tested, review the results and maintain records that fit their quality system.

There are limits to what the study establishes. McMorrow characterizes it as a practical proof of concept, not a prevalidated system ready for direct use. Any deployment would need to fit the organization’s quality system, validation strategy and regulatory context. Related work from the team has examined model-based validation for new and existing equipment, including legacy programmable logic controller systems.

The test is whether traceability survives change

The larger significance is that validation can be treated as part of engineering development instead of a separate package assembled at the end. This is more significant than it looks: when design choices, risks and verification evidence stay connected, teams have a clearer way to explain why a controller was tested as it was. But a workflow only helps if that connection remains current when requirements or system behavior change.

And this is the part most people overlook: traceability is a maintenance task as much as a design feature. If you're working in this space, the useful question is whether teams can keep the risk-to-evidence links accurate through revisions, handoffs and deployment. A map that goes stale can create confidence without providing much help.

The practical test for this approach will be whether manufacturers can preserve risk traceability as systems change, while generating useful verification evidence throughout development. A proof of concept offers a method to examine; adoption will depend on whether organizations can make that method work within their own processes. The hard part is sustaining the discipline.

Read the researchers’ study. McMorrow’s earlier doctoral research describes related work.