OPC UA and Information Modeling for Pharmaceutical Manufacturing
- November 18, 2020
Introduction
In the last year or two, we have noticed an increase in interest in OPC UA technologies in the pharmaceutical manufacturing industry. Automation of processes combined with the heavy regulation of the field means that the tools used have to meet many high standards. While compliance with regulations is always the responsibility of the system owner, well-suited tools can streamline development and provide out-of-box solutions for many basic level requirements, allowing more development time to be allocated to customize the system for specific scenarios.
As a result, I wrote my Master’s Thesis titled “OPC UA and Information Modeling for Pharmaceutical Manufacturing”. The research conducted in this thesis is based on an information model developed by Prosys OPC in cooperation with companies working in the field of pharmaceutical manufacturing. In addition, Bayer Oy provided insight into the practicalities of these systems and how to apply regulatory compliance to these processes.
The thesis is publicly available from Aalto University here.
Scope of The Environment
OPC UA is a communication protocol, which means that it can be used in pretty much any network connected via internet or LAN. This thesis focused on very specific layer of automation. The picture below describes the hierarchy model defined by ISA-95 standard.
Again, OPC UA could be used between any layer here and the protocol level benefits can generally be applied as such. For the information modeling section of the thesis, the focus was on the connection between Level 3 and Level 2 Batch Control.
Protocol Level Benefits
This section of the thesis focused on protocol level benefits provided by OPC UA, that are generally available in OPC UA SDKs (like SDKs for Java and Delphi).
These benefits are core part of OPC UA and can be leveraged in any OPC UA connection. While this part of the evaluation is also conducted considering connections between Level 3 and Level 2 of ISA-95 hierarchy, it is apparent that many if not all of these benefits can be leveraged pretty much anywhere.
ALCOA+ and Data Integrity
The first evaluated objective that OPC UA can help with as a protocol is data integrity, which aims to make sure that the transferred data is reliable. This characteristic is important in any system handling data, but it is especially critical in systems controlling and supervising manufacturing. This is the cornerstone of product quality and traceability.
ALCOA+ is a set of principles developed for GMP records to provide general guidelines for data integrity. It is very general level and can be applied to electronical and paper records alike. It is also important to note that ALCOA+ only defines what measures should be taken, but not how they should be implemented.
| ALCOA+ principle | Principle description | OPC UA features |
| Attributable | Who/what created, accessed or modified the data? |
|
| Legible | Data and audit trails need to be readable by humans and are accessible throughout life cycle |
|
| Contemporaneous | Data is recorded when the activity is performed |
|
| Original | Data is captured and stored automatically, and the first record is the original data |
|
| Accurate | Data contains no errors, is not edited manually and conforms to truth and standards |
|
| Complete | All data, including metadata is stored |
|
| Consistent | All processes for the data are well documented and timestamps are in correct sequence |
|
| Enduring | Data is recorded long-term format for the retention period |
|
| Available | Data is accessible for review, audit, or inspection throughout the retention period |
|
Security
Security is always important to deny unauthorized access to both protect data and to prevent changes to the processes. A lot of system security is based on the policies employed by the organization owning it. However, there are two key areas where OPC UA can provide the tools necessary to enforce these policies.
Firstly, access control can be used to limit access to the system. In addition to providing initial access to the OPC UA servers, each node can have individual access levels for different users. This allows different types of users to exist on the server, limiting access to data, methods, events and pretty much anything based on their role in the process.
Second feature, encryption, ensures that no data can be intercepted by third parties. As of OPC UA specification version 1.04, three encryption algorithms are listed, all of which are generally considered safe to use. The more important fact is that two older algorithms have been deprecated in 1.04, showing that the security features are properly re-evaluated during major updates.
Recovery & Redundancy
For this section, the main methods of providing value were determined to be data loss prevention and service availability. While the former is important for trustworthy data, the latter has a more direct business impact by ensuring that the manufacturing processes can continue uninterrupted.
Data loss prevention is not built into the protocol itself, but two main tools can help with it; subscriptions and historizing. OPC UA subscriptions query data to be sent to the client, thus allowing data to be buffered and delivered after recovering from connection interruption. It should be noted that this is not the primary function of subscriptions and the amount of data buffered depends on the configuration of the server.
Historizing means that the OPC UA application saves the data and its changes to an external data system, usually a database, where it can be accessed directly or via OPC UA using Historical Access.
For service availability, the OPC UA specification offers clear documentation for reconnection procedures, different redundancy setups and failure handover modes. While the implementation of these procedures is still up to the developer, having this documentation adds inherent value for regulatory compliance, where every bit of extensive documentation can be used to support compliance claims.
Information Modeling
For this section, two models were developed. The first model was used to build a tag-based system to reflect more classic hierarchical systems, typical in older process control products. The second model is built using features specific to OPC UA, like methods, events, and subscriptions. These models were then built using four common use-cases in pharmaceutical manufacturing: batch control, recipe control, step control and sampling.
In addition to the models themselves, the communication facilitated by these models was also evaluated. The communications use-cases are based on MES Message Events that were composed by the Plug & Produce Hackathon. You can read more about Plug & Produce from our earlier blog post: OPC UA Enabling Plug & Produce – Report from OPC Day Finland 2019.
This blog post will cover recipe control for the model itself and sampling for communication graph. Rest of the use-case analysis’s can be found in the full thesis.
System Architecture
As mentioned earlier, this thesis focused on the connection between Level 3 (MES or equivalent) and Level 2 (SCADA or equivalent) of ISA-95 hierarchy model. One possible network setup for this is described in the picture below.
This picture covers both cases where MES has direct control of the equipment, as well as when process control system is used to coordinate the control of a larger set of equipment instead of MES.
The architecture also includes two different state machine implementations, one to monitor and optionally control equipment and one to monitor and control the overall batch process.
For equipment, established PackML state machine is used for monitoring the system state, but the precise configuration of these servers are left for further research.
The process control OPC UA server uses a simple state machine based on ISA88 standard for batch control. This state machine tracks the overall state of the batch manufacturing process, which may include any number of steps and equipment. This state machine is described below.
Model for Recipe Management
Recipe control deals with controlling what recipes are available in the specific system and which of them is active. The developed model for this use case can be seen below.
The difference between the two models is that in the advanced OPC UA model, the active recipe is changed via method, as opposed to the tag-based system, where the switching is done by writing all relevant information to the CurrentRecipeId, CurrentRecipeVersion and optionally Parameters variables directly.
The main draw-back for the tag-based system is that while OPC UA can write to multiple nodes with a single write call to the server, each of these variables are handled separately. This means that some of them can succeed and others fail. This immediately requires that the input is validated after it has already been written to the server and the process cannot continue before this validation is complete.
For method-based solution, the validity of the variable combination can be evaluated by the server before it is written to the variables, making sure that the recipe exists and is usable. Method response message can also be modified, allowing the server to send detailed error information of why some requests might be rejected.
Communication for Sampling
Another benefit gained from a more robust protocol and modeling support can be observed when inspecting how the two systems communicate. Each message sent can be an extra point of failure as well as cause more traffic on the network. The more the complexity of the network increases, the faster it can become congested.
The picture below describes the messaging happening when the MES system initiates a sampling request to the Level 2 system for both tag-based solution (left) and server using methods and subscriptions (right).
This picture highlights how subscriptions can be used to reduce unnecessary polling from the client to the server to check when new data is available. By delegating the reporting responsibility to the server, the overall traffic can be reduced. In addition, this can be useful in situations where multiple clients are connected to the server, as they might not be aware when another client has requested a sampling procedure.
Summary
As mentioned in the beginning, the regulatory compliance is always the responsibility of the system owner, but OPC UA can offer set of tools to reach these requirements. Protocol level features help with the integrity of the data transmission, making it easier to validate that data is reliable. Information modeling can be used to create smarter solutions for network and system hierarchies, reducing overhead in many operations. These differences might seem minor in isolated context, but in more complex systems the benefits start to stack up quickly.
Finally, this blog post and the thesis it is based on only scratch the surface of how OPC UA can benefit processes in pharmaceutical manufacturing, but it should serve as a quick starting point for those interested in using this technology in fields with demanding regulation.
Author Info
Aku Viitanen
Software Engineer
Email: aku.viitanen@prosysopc.com