Detailed equipment & batch data models set up by pharmaceutical and biotech companies have enabled the creation of equipment centric machine learning (ML) models for example, batch evolution monitoring. The next step is to extend the existing equipment centric models and create process or end-to-end models.
The challenge is that the current data models do not fully support the extension:
· Equipment models are based on the ISA-95 structure and reflect only the physical layout of the manufacturing facilities.
· Batch Execution Systems (BES) are integrated using ISA-88 and entail only equipment that is controlled by the batch execution system. Often BES systems are set up to execute single unit procedures and subsequent processing steps are executed separately.
· Management Execution Systems (MES) typically map the entire process and material flow but as a level 3+ system is difficult to integrate into a data modelling pipeline.
· There are also facilities that use paper-based process tracking instead of MES\BES, which makes traceability even more challenging.
Batch-to-Batch traceability can quickly become very complex especially when many different assets are involved. The following shows an example of a reactor train in a biotech facility:
It shows all the different product pathways from reactor ‘01’ to the final processing step, as an example in red: 01, 11, 22, 33, 44. At any moment in time, the other reactors are either being cleaned or used for a parallel process.
Such a process is difficult to model in a BES or MES system and real time visibility or historical analysis is very challenging. This is especially true if subsequent processing steps are to be included (Chromatography, Fill and Finish, ....)
The missing link to model the different pathways is to integrate each transfer between reactors or equipment. OSIsoft AF offers the AF Transfer model that is fully integrated in the AF system. AF Transfer event can be defined with the out-the-box properties:
· Source Equipment
· Destination Equipment
· Start Time
· End Time
The AF Transfer model has a lot of the same features that AF event frames offer. Transfers can be templated and through the in-and-outflow ports defined in different granularities.
Once the transfer between equipment has been defined, batches can be traced back in real time with or without using the batch id. This is possible through the equipment and time context of the transfer model:
In this case, starting from the end reactor ‘44’ all previous steps can be retraced by going backwards in time and using the source-destination equipment relationships.
The implementation requires a data reference to configure each transfer. The configuration user interface requires the following attributes:
· Destination Element: Attribute of the destination Element
· Name: Name of the transfer
· Optional: Description, Batch Id and Total
The result is transfer logs can be matched up to the corresponding unit procedures by time and equipment context as shown below:
As shown in this example, the end time of transfer log 'Transfer Id S7MZUDGK' matches the start time of unit procedure: "Batch Id WNJ6H99R". The entire pathway can now be reconstructed in one query.
The sequence of discrete processing events such as unit procedures can be modelled using the OSIsoft AF Transfer class. The resulting transfer logs allow retracing the process backwards in time by using the source-destination relationship of the transfer model. Modelling the process flow is key to expanding equipment centric ML models.
Please contact us for more information.
Machine Learning (ML) will undoubtedly transform manufacturing and grow from a few selected application such as Predictive Maintenance to a wide range of use cases. The technology already exists today, libraries are widely available under open-source licenses and on-premises IT infrastructure as well as cloud service allow these applications to scale.
So, what is holding it back?
One area that limits the wide adoption of ML models is the underlying data structure. Companies have heavily invested in their data infrastructure and the creation of meta databases (mostly ISA-95 and ISA-88), but the productizing of ML models is still lagging. There are several reasons for this:
Industrial standards ISA-95 and ISA-88 provide a framework to structure the equipment and batch model, but by design do not support ML modeling. For example, one equipment can have several ML uses cases that all require a different structure, e.g. example multivariate batch modeling, predictive maintenance, forecasts for predictive control, …
One approach to structure industrial models is ML Relational Mapping (MLRM). It builds on the already existing object relational mapping (ORM) by linking existing type systems. The concept does not require restructuring existing data models and is therefore fast to implement:
MLRM adds an additional type or class that links for example equipment and batch types as well as provides definitions for the ML model. By separating the functionality, this approach does not clutter the existing type system and provides the flexibility to define different models for one class or multi class models without the need to restructure.
The following shows an OSIsoft AF based UI that implements MLRM:
Machine Learning applications will show grow rapidly in the Manufacturing Environment. The challenge will be to provide the right structure, so that ML models can be built on top of existing type systems. ML Relational Mapping (MLRM) provides a flexible approach by implementing a model specific type system that links to existing data models.
