Parts 1 to 3 of our series addressed the subject of “Assistance Systems” in general, then took a look at “Advanced Process / Model Predictive Control” before turning to the complex of issues referred to as “Digital Twin, Real Time Optimization and MirrorPlant”.
We learned that all of these assistance systems are designed to support or assist us with certain activities. Among other things, they do this by simultaneously capturing and evaluating a large number of variables and supplying us with the correct, current setpoint. Some systems relieve us of the burden of continuously having to respond to minor changes in order to keep the plant running stably. Always with the objective of improving efficiency, safety and availability in production.
Today’s assistance system is slightly different. It’s more like an “electronic driving instructor”, who is constantly there to assist me with his experience and get me through safely, not only in tricky situations. He’s a driver assistance system in the truest sense of the word.
The standard operating procedure (SOP) – A help and a problem
Let’s start by looking at the standard operating procedure (SOP). This is a document that exists for every plant. It describes how to start the plant up and shut it down again, how to run it in normal operation, how to move it to another operating point, etc. It should be noted in this connection that the SOP doesn’t simply explain (at least in the best case) what I, as the plant operator, must do in the control room but also what must be done in cooperation with the field operators and others, for example opening valves manually during the startup process. All in all, it’s a crucial document in.
Unfortunately, there tends to be a snag … the SOP is usually only available in paper form. It isn’t designed for interactive scenarios with the plant operator. This can easily lead to a situation like the following:
Plant operator: “Where is it? Is it even up to date, and where on earth is the section I need right NOW? That’s the way my colleague did it last time but it doesn’t say anything about that here”. And so on and so forth.
Sometimes, you hit on a SOP that leaves you at a loss for words because about the only thing it tells you is that starting up is “complicated” (reality or satire?). What we can say, though, in a nutshell is that …
- The SOP is not always up to date.
- Operator knowledge that has been built up over time is not documented in the SOP.
- “Paper files” provide suboptimal support in what is in any case a complex situation.
What I have in mind and what I really want is this: first, an electronic SOP (eSOP) that makes it easy for me to stay up to date and document changes in a traceable manner. Second, once I’ve got an eSOP, to make it available in a form where interaction is child’s play, in short an interactive driver assistance system.
eSOP and automated driving system – One solution, many options
4 distillation columns, 2 reactors, 1 crystallizer … the startup process is complex.
What’s more, when starting up the reactors account must be taken of a so-called “Ex nose”. Even though a detailed SOP exists, the startup times and results vary considerably. If we look over the shoulders of the plant operators, we can see that each one implements the SOP in a slightly different way. And every now and then, the startup path is too close to the Ex nose, so that the plant is shut down again. All in all, that isn’t very satisfactory. It’s something we need to focus on and the objective is clear:
To standardize the startup process and make it safer and more economical.
The solution we choose is a combination of an eSOP (electronic SOP) and an automated driving system. We’re convinced by the results. There are far fewer variations in the column startup process and the startup time is one third shorter on average. Even more impressive is the amount of off-spec material during the startup. It’s typically 90% lower. Emergency shutdowns have been virtually eliminated while the reactors are starting up. Once again, the startup time has been reduced by one third, and at the end of it the reactor is operating at 100% load rather than just 70%. This example from the German chemical industry has an ROI of well under a year.
I’d like to make one more point about complexity in this example. Approximately 600 measuring points and 800 manual interventions have to be considered during the startup. When I say manual interventions here, I’m mainly referring to setpoint adjustments, manual operations, etc. The introduction of the assistance system results in 4200 parameters and 7500 different instructions being executed in the automated driving system during the startup. A lot of manual steps are still necessary in spite of all the automation.
eSOP & driver assistance system – Principle & implementation
eSOP – More than just digitized paper
Let’s begin by taking a look at the SOP. We’re talking about more than simply digitizing a SOP that already exists here. As I mentioned earlier, SOPs frequently suffer from serious shortcomings. The following objectives are specified when writing an eSOP:
- Determine the actual condition of the plant and the control system as well as the current, related “operating modes”.
- Take account of all relevant players in these modes, namely control room, field and other personnel.
- Incorporate all of the knowledge built up by the operators in the past (control room, field, etc.).
- Establish an easy means of updating, where document management is an integral element.
- Be readily understandable and traceable.
So far, you could be forgiven for thinking that the new eSOP is no more than an ordinary Word document. However, if that were the case, we’d simply end up with old wine in new bottles. That’s why we also need to set ourselves other goals:
- Make the eSOP interactively available to the operator
– As an electronic document (Word, PDF, etc.) in or at the PCS
– As a graphical, real-time “navigation” system through a procedure, e.g. the startup* - Take this one step further (based on the eSOP)
– As a graphical, real-time “navigation” system AND active assistant during operation of the system**
– Ultimately enable procedures to be implemented completely independently, e.g. grade changes***
* Driving instruction ** Driver assistance *** Automated driving system
In order, therefore, for the eSOP to capture and retain the best operational knowledge, merely taking the existing SOP as a basis is not enough. Operator know-how and evaluations of log files are other useful sources. In the same way as we search for the “golden batch”, we’re now searching for the “golden mode”, which we want to analyze and document as a procedure. In the meantime, this can also be partially automated.
From driving instruction to automated driving system – Using the eSOP interactively
When we discuss SOPs with the operators, one wish they express is that they should be rapidly and interactively available. They’re keen to make the leap from a simple eSOP to a driver 
assistance system. This driver assistance system could be a simple “navigation” system that churns out driving instructions in either offline or (preferably) online open loop mode alongside the PCS. Parallel to what the operators are doing, the driver assistance system shows what needs to be done next as well as what has already been done. The activities in question are either manually acknowledged or automatically triggered by actual values. Example: The pending activity is to open a valve 50%. With an offline system, the operator would have to manually acknowledge the 50% position after carrying out this activity whereas with an online system, the 50% position is read out automatically and the activity flagged as “done”. As an automated driving system running in an online closed loop, the assistance system executes all necessary and automated steps independently, for example if it is triggered by a measured value or by the result of a calculation (RTO). The operator is only required to intervene if parts of the procedure, such as communication with the field, are not automated.
Isn’t that just a sequence? No, it’s not!
No – because a sequence would be stored in the PCS or another control system. Our driver assistance system collaborates with the various control systems and takes account of all relevant players in the procedure. That simplifies cooperation as well as making it safer and more secure. Thanks to the interaction with a driver assistance system, it’s now practically impossible not to realize that manual valves A, B and C first have to be closed in the field before you set the setpoint for valve V-001 to 50%. The sequence is clear and you can even set a block so that a new setpoint can only be specified on the PCS after something has been switched on the separate hard panel A.
Apart from ease of use, another benefit that has frequently been mooted in discussions about assistance systems such as this is ease of interaction and maintenance. You don’t have to be an expert in PCS or PLC programming to set up, maintain and use our driver assistance system. If I want to make any changes to the startup process, for instance, I can enter them in the driver assistance system without going anywhere near the PCS. The system can be expanded with operator know-how at any time, and all changes are documented.
A good driver assistance system is designed to support the operator and is independent of the PCS manufacturer. It incorporates the knowledge which has been built up by the operators into the SOP and retains it without compromising the PLC’s integrity. It increases safety while the plant is running and hence improves productivity.
And by the way, a driver assistance system may not be an operator training simulator, but in addition to everything mentioned above it can also be used as a training aid in offline open loop mode – and one that is definitely more “exciting” than reading the operating procedure.
END of our four-part series on “Assistance Systems”
