'. PHP_EOL; } elseif ( strpos( $page_path, "deutsch") !== false) { echo ''. PHP_EOL; } elseif ( strpos( $page_path, "francais") !== false) { echo ''. PHP_EOL; } elseif ( strpos( $page_path, "italiano") !== false) { echo ''. PHP_EOL; } ?>

Challenge of Designing PCS-Driven MES Architectures for a Greenfield Facility

by | Apr 24, 2017 | Industry, Life Sciences & Medical, Operations & Business Management

Jim Cahill

Jim Cahill

Chief Blogger, Social Marketing Leader

Emerson's Jonathan Lustri

Author: Jonathan Lustri

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.

Syncade WorkflowBecause 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.

Popular Posts


Follow Us

We invite you to follow us on Facebook, LinkedIn, Twitter and YouTube to stay up to date on the latest news, events and innovations that will help you face and solve your toughest challenges.

Do you want to reuse or translate content?

Just post a link to the entry and send us a quick note so we can share your work. Thank you very much.

Our Global Community

Emerson Exchange 365

The opinions expressed here are the personal opinions of the authors. Content published here is not read or approved by Emerson before it is posted and does not necessarily represent the views and opinions of Emerson.