If you're unfamiliar with Modular Procedural Automation (MPA), it helps automate start-up, shutdown and other data-driven procedures in a process, increasing efficiency, optimizing production, and reducing wear and tear on equipment. Additionally, MPA helps increase operator productivity and confidence.
Adapted from the case study in Control Magazine, this blog post covers how Air Liquide, a world leader in chemicals manufacturing, is migrating to MPA using OPC UA and OPC bridging to lower startup time by over 60% and increase production to over 500 additional tons of liquid oxygen (LOX) resulting in increased profitability.
For many large global organizations, the sheer quantity of different distributed control systems (DCS) operating different aspects of the operation is an ongoing challenge. At Air Liquide, their air separation units (ASU) and associated equipment around the world are controlled by a diverse assortment of DCS systems. Fortunately, with many of the company’s plants operating in a similar fashion, it became possible for Air Liquide to take advantage of a common library of unit modules. This ability allowed them to standardize consistent, reproducible execution and implement a platform for advanced functionality including Modular Procedural Automation (MPA).
As mentioned previously, MPA helps by automating start-up, shutdown and other data-driven procedures, increasing efficiency, optimizing production, and reducing wear and tear on equipment while also increasing operator productivity and confidence. All of these things lead to reduced downtime, more efficient production and increased profits.
So, revisiting the previously stated challenge of diverse legacy control system, it is necessary to use a supervisory controller that can be retrofitted onto existing systems and that seamlessly integrates with newer control systems as facilities are upgraded. Further, since the ASUs directly feed pipelines or the clients’ production units, unscheduled downtime for programming changes or code updates to the supervisory controller is extremely costly and, so, is not an option. A vendor-agnostic solution that factors in this diversity of systems and challenges was required.
How Does MPA Synchronize Process Systems Safely?
The first implementation of Air Liquide’s Process Unit Modular Automation (PUMA) initiative was deployed at the Ingleside, Texas ASU facility. An Emerson DeltaV PK controller acts as the supervisory platform for MPA and is connected to a legacy Foxboro DCS through a Cogent DataHub. Acting as an OPC gateway, DataHub effectively bridges the older OPC DA communications from the DCS engineering station with the modern OPC UA interface of the DeltaV PK controller.
One of the primary concerns of using a system that is external to the plant DCS itself to execute high level automation tasks is preventing communication errors. Writing the wrong value or even the correct value at the wrong time to certain DCS tags can have severe consequences, such as a loss of production or even a plant shutdown (i.e. very costly mistakes).
The most sensitive situations prone to errors or issues are when components in the system are started, stopped or modified. For instance, when the OPC bridging software is first turned on, a stale value could potentially be rewritten. Or, if the DeltaV PK controller code is modified, outputs may reinitialize to 0 and be written to setpoints within the DCS, leading to delays or downtime.
In other applications, DCS level watchdogs and integration logic have to be added on a tag-by-tag basis to ensure proper safeguards are observed. However, with modular automation, there are often many tags to write to, so building safeguards for all of these tags into the DCS would be a mammoth task.
The conditional bridging design detailed below in the rest of this post, however, builds the necessary safeguards into the OPC bridging layer in DataHub. What makes this possible is following the philosophy that certain protected tags exist in the DCS, and any write to these tags should be deliberately made by the PK controller logic and not through any accidental circumstance.
Flexible Conditional OPC Bridging with Cogent DataHub OPC Gateway
In this system, logic allowing writes to protected DCS tags requires that three conditions must be met:
- The PK controller modular logic must be ready to write to the tag group containing the tag.
- Communication from the OPC bridge to the DCS and the PK controller is verified to be in a working state.
- The DCS is ready to receive writes.
If all these conditions are not met, the bridges to these protected tags will be disabled, and no writes to these tags will take place or even be possible. However, other non-protected tags will continue to be bridged as usual.
To verify Condition #1 that the DCS controller’s modular logic is ready to write, there is a flag for each specific tag group of protected tags that the DataHub bridging software can monitor. Based on the state of that flag tag, the DataHub script can know whether the logic in the controller is ready to write or not, meeting the first condition.
As an additional safeguard, there is another Boolean flag in the DCS controller that can be set by DCS logic and/or by operators. If that flag is false, all writes to protected tags will be disabled. This provides a simple breaker mechanism to disable writes from the modular automation system. Even if normally left in the active position, this is an important safeguard to have available when doing modifications on the system for example – it provides a sort of “maintenance” mode mechanism.
To verify Condition #2 – that communication between DataHub, the DCS and the PK controller is working normally – there are heartbeat tags in the PK controller and DCS that are constantly changing. DataHub can monitor the value changes of these heartbeat tags to ensure it is successfully communicating. And, likewise, the DCS and PK controller can monitor each other’s respective heartbeat tag to ensure communication there is good.
Logic is built into the DataHub script such that, if the heartbeat tags haven’t recently changed, the writes to the protected tag groups are disabled. This is an important safeguard to ensure that current (not stale) values of the flag tags are being read. It also ensures that if/when DataHub is restarted, no unintentional writes to protected tags will occur.
Additionally, a set of tags in the DCS are monitored by the PK controller so that it knows the actual values of the protected tags in the DCS whenever communications are established, even at times where writes to these tags are prevented. This allows the modular automation logic to synchronize tag values with the DCS and confirm the tags have reasonable initial values (thus fulfilling Condition #3) before writing any new values to them.
A final important consideration is that protected tags must not receive any written values from cache. To ensure this, writes aren’t performed on the initial value only on subsequent values. This safeguards against any inadvertent writes occurring, such as when the write logic is first enabled and a source value might still be cached.
At the heart of the previously referenced conditional bridging functionality, DataHub uses its integrated scripting language. The parameters required for bridging were built into a script that reads from a configuration (.csv) file including the specifications of all bridges, whether they're protected, and of which PK group they're a member. This script is designed to be reused on all similar projects in the future, lowering maintenance and maximizing scalability across locations and projects.
Modular Procedural Automation - Designing the Right Sequence
The conditional bridging architecture built in DataHub effectively safeguards against all potential situations that lead to inadvertent writes. This necessitates using a specific design sequence in the modular automation procedures.
A typical sequence is:
- Disable all writes from the PK controller side.
- Wait until the DCS is ready for writes and any other logic conditions to be met.
- Synchronize PK tags with DCS tags.
- Enable writes from the PK controller side.
- Run main sequence logic.
- After the sequence is complete, disable writes from the PK controller side.
The order of aligning DCS tags, enabling the bridge, and writing new tags is key to ensuring that everything works as required. Following this process precisely makes certain that the first new value written to the protected tags in the PK controller gets written to the proper corresponding DCS tags.
Successful Modular Procedural Automation Proof-of-Concept
The successful ability to deploy this robust Modular Procedural Automation (MPA) has been demonstrated at Air Liquide’s Ingleside ASU. This is the very beginning of Air Liquide’s larger vision. They’ve demonstrated that if operators can start and stop equipment in more convenient and efficient fashion, those operators will take the steps necessary to operate in the most optimized method whenever possible.
For now, MPA operates in an “operator advisory” mode at Air Liquide. For example, MPA alerts an operator when an argon column’s product tank is full and the column can be shut down, saving significant amounts of energy (as opposed to fully automating that shutdown without operator control).
Ultimately, as operations gains greater comfort and confidence in the MPA process and reliability, the PUMA controller will be able to shut down the column automatically—without operator intervention. And while the MPA’s actions are limited to start and stop for now, the team is considering other data-driven tasks that, as they gain confidence in the solution, can be initiated automatically in the future for further time and cost savings.
Air Liquide has seen substantial gains in plant performance after implementing this MPA methodology when comparing post-implementation production to historical production for the same period. For example, one ASU was expected to produce over 500 additional tons of liquid oxygen (LOX) when compared to the same period in the prior year.
And speaking to time-savings, the startup process of the ASU went from 2 hours to 45 minutes - an over 60% reduction - resulting in more time actually producing (which translates into increased profits. Additionally, since market demand for argon gas isn't consistent, it's possible to more effectively shut down argon production during periods of low demand to switch to liquid oxygen production, increasing profitability in that fashion, as well.
For a full nuts-and-bolts deep-dive on this project, we encourage you to read the full write-up in Control Magazine by Abdulkadar Susnerwala (process controls engineer), Bruce Eng (advanced process engineer) and Marty Martin (director of process controls) who work together at the Center of Technical Expertise for Air Liquide USA.
If the use case above is intriguing to you or you have another similar project and you would like to try DataHub for your own OPC UA and other integration projects, you can get a free trial of Cogent DataHub. Click to Download Your Free Trial.
