How using a digital twin reduces engineering, validation and testing time
Using a digital twin of existing machines, together with a new message-based communication protocol, engineers can determine how best to implement shop floor integration prior to installation, as Gero Lustig, Global Business Manager Pharma and Life Sciences at ABB explains.
For years, pharmaceutical manufacturers have purchased equipment from various original equipment manufacturers (OEMs). This has resulted in production lines with different automation and control systems each with their own data handling, housed within their own repositories, within their own database. Today, industry is faced with the dilemma of how to integrate these production lines and the existing machines or equipment into current manufacturing execution systems (MES). As important, is the need to harmonise the different shop floors from a digital perspective, without making costly replacements of machinery that are performing perfectly well.
Shop floor integration
Shop floor integration (SFI) software is one solution designed for established pharmaceutical manufacturing plants and their existing machinery or equipment. It allows for the creation of a digital twin of the existing system prior to installation and does not require the installation of a DCS or SCADA to control the line.
By creating such a digital data twin of the existing equipment and using message-based communication, the SFI can be accomplished in a very flexible and efficient way. It results in reduced engineering, validation and testing time and minimises the plant’s downtime. Using this software, engineers save between 40 and 70% of the time spent on integrating systems when compared to existing solutions.
ABB’s SFI interface connects Werum’s PAS-X manufacturing execution system (MES) to existing shop floor equipment in a very flexible, yet cyber secure way. This digital solution prevents production bottlenecks and reduces cycle times so as to lower inventories, free up capacity and increase efficiency.
Building a digital twin
To implement SFI, a digital twin or model of the machine’s data runtime behaviour is created, using the software’s design environment. The model comprises data inputs from the machine and the outputs to control it. A message-based communications system sends and receives instructions between the MES and the production equipment. This includes starting or stopping of the machine or setpoints to control the equipment in different ways, including exceptions like alarms and messages. This provides regular synchronisation between the systems and communicates data such as quality, setpoint and consumption. The design environment gives engineers the opportunity to test the running of the line in the digital world before any connection is made in the real world.
The historical route for integration between manufacturing systems is labor-intensive and multi-staged including the definition of OPC tags, interface handshakes, states and logic. SFI cuts down this often-lengthy process and replaces it with a simple, efficient and qualified interface needing just a few steps: define the message, then define Master Batch Record (MBR) interaction and steps and recipe parameters of the equipment independently of each other. This reduces the possibilities for malfunctioning and makes it simpler to program, with minimised machine-operator interaction during the manufacturing process.
This type of SFI is an extension to ABB’s manufacturing operations management (ABB Ability MOM) technology. In contrast to today’s tag-based integration, the new concept is based on OPC UA (Unified Architecture) which is a modern industrial communication architecture that is open, secure, efficient and cross-platform.
How the digital twin works
The digital twin model itself contains all the mapping of the messages together with all the state logic needed to control the equipment with the messaging.
From the PAS-X/ MES or the MBR perspective, you do not see the complex logic, with messages being sent and transformed to inputs/outputs by the SFI server. This approach makes a huge saving when creating the MBR as you no longer need to deal with the mapping or state logic in the PAS-X/MES. You simply rely on the digital twin to take care of it.
SFI modeler
The starting point is the SFI modeller, shown in the diagram below. Here messages are defined, such as the parameters required, how the messages are sent and received, together with the logic. Once everything is tested, the modeller contains a debugging facility thereby providing an ability to test out the model in the tool itself, without involving PAS-X/MES. The input and output can be simulated in the modeller directly too, thereby ensuring everything is tested before actual live operation takes place. Also documents that describe the model, and which are required for the validation process, are generated by the design environment.
When the model is ready, it can be approved before moving into the actual configuration. At this stage the model can no longer be changed. The model can be exported to another machine along with the interface description and these are imported straight into PAS-X/MES.
SFI Configurator
When the model is ready, the SFI Configurator is brought into play. The configurator uses an approved model which then will be instantiated to run the communication for the individual machine. So, for example, if there is more than one packaging machine, a model is created that fits the type of machinery. Then, using the SFI Configurator, it is configured to the physical world. Typically, tag lists are imported from the SCADA system controlling the machinery, leading to automation outputs and inputs for the model itself. The object instance is then instantiated and is the one that takes care of the true digital twin to the physical equipment. The object instances communicate with PAS-X/MES using messages sent and received.
This is a very convenient way to model all equipment into digital twins, proving sent and received messaging from the MES to the machinery or equipment.
Modelling mode
The modelling part shows four panes or windows alongside of which is the search bar.
The model is defined within the first pane. This is done by defining all the inputs and outputs and variables along with the necessary code. The code is compiled on the fly so when you instantiate it and run it, it is instantly effective and runs very fast.
Once it is checked that the code can run, it instantiates a temporary object. This object is stimulated by the inputs, enabling messages to be sent and received to the object. This enables a lot of testing before the object is ever introduced in the physical world.
Configurator
Once the model is built, it is saved and approved, and is ready for the configurator. The configurator can instantiate the models into physical objects that hook up to the physical equipment.
The image below shows the run time of the digital twin with all the inputs and outputs that are replicated on the actual machinery.
Extensive testing can be undertaken by sending messages from this pane to the object, before it is passed onto the PAS-X/MES.
Summary
Such an approach provides a smart way of simulating the communication and auto-creation of configuration documents. Now, prior to installation, manufacturers test the set-up, shorten the validation effort and minimise a plant’s downtime.
The solution is a message-based communications system that sends and receives instructions in the form of standardised XML-files between the MES and the production equipment. This provides regular synchronisation between the systems and communicates data such as parameters, critical quality data and consumption.
Its standout feature is its flexibility, as new instruction sets can be defined to support data queries or any other data exchange without re-engineering. This helps prevent production bottlenecks and reduces cycle times to lower inventories, free up capacity and increase efficiency.