I have previously written about a design strategy where the process control system (PCS) is the primary system driving all procedural batch activity within a pharmaceutical process. In this architecture, the PCS ISA-88 procedural model must execute the both automated procedures and call the manufacturing execution system (MES) workflows to be executed when they are needed by the process. The advantage of this approach is that flexible equipment and product independent workflows can be developed which reduces the cost of introducing new products and results in less engineering and maintenance for the MES system. Another benefit of this approach is more robust coordination between the MES and PCS procedural activities and simplification of the MES procedural model. See the Pharmtech.com article, Connecting MES to Process Control, for more information on this architecture.
While this architecture has many benefits, there are challenges implementing this architecture. Challenges include project roles and responsibilities, driving common design for similar activities, and client focus on how manual activities will be performed. The PCS-driven MES architecture requires a more holistic view of the process for automation design personnel. In the typical batch automation engineering project, the automation engineer is mostly concerned only about what is automated with instruments and valves. There is some requirement to understand manual activities using manual prompts from the PCS. However, in a PCS-driven MES architecture, the automation engineer must take ownership for understanding the entire process.
Because the MES workflows must be called by the PCS, the PCS automation engineer must understand the process in a lot more detail including the manual activities. The automation engineer designing the procedural model must have responsibility for designing the procedural model to include the MES workflows. I have seen also that the project personnel working with the automation supplier will prepare in detail information needed to design the automated procedures executed with the PCS batch, but devote very little focus on the manual activities that work be executed in a workflow.
In a greenfield plant, a lot of focus is made early in the project on the capital equipment and PCS automation, with details for manual procedures coming much later. This makes it difficult to design the PCS automation and MES workflows to the same schedule meeting a common factory acceptance testing (FAT) schedule.
There is also a challenge in driving common activities to a common design. Automation teams within the supplier’s project team and the client’s process experts are often organized around process units including different people responsible for different units. Client and automation resources develop a detailed understanding of how each unit operates and how it must be automated, but there is very little focus on how similar activities performed on different units should be designed to be common. A well-designed MES system should deploy common workflows across units to reduce the cost of implementation and maintenance.
The client will have process experts on the different unit operations, but often do not have any focus to define a common set of workflows to be used across the units. This leaves the supplier in a position where they must interview the process experts on the scope of manual activity within their units and try to identify what activities across units can be common. This can be a challenge since there is not a strategic effort on the part of the client to drive manual work activities to be common when it’s possible. Under the pressure of a project schedule, it may be faster to simply define separate workflows for each unit, resulting in a costlier architecture.
The final challenge in designing MES workflows in this architecture is the overall lack of attention given to the definition of workflows by the client. It’s striking to see the significant effort put into defining how the process control layer should be designed, but very little effort is made to define process and data requirements around manual actions executed with workflows. I often see that the overall effort to define the functional specification for process controls is begun earlier than for the MES workflows.
I believe this fact comes from the fact that most people still come from a legacy of paper batch records where the definition of the batch record comes much later in a capital project. As the life sciences industry transitions to a strategy for electronic batch records and release by exception, more attention to the definition of manual workflows and data requirements must be paid early in the capital project so that it can be part of the main automation schedule.
From Jim: You can connect and interact with other manufacturing execution systems and pharmaceutical & biotech industry experts in the Operations Management and Life Sciences groups in the Emerson Exchange 365 community.
