High-fidelity operator training simulators
Integrating a high-fidelity simulation model with a real plant control system requires some finessing to produce a true high-fidelity operator training simulator
Viewed : 3547
The current trend in operator training simulators (OTS) is to connect a high-fidelity dynamic simulation model to a copy of the actual plant distributed control system (DCS) that is running the same software as the plant and uses the same human-machine interface (HMI). This approach is attractive and usually offers the best opportunity to produce a high-fidelity OTS that will maximise training value. However, success is not guaranteed by the project model, and there are often some complex and difficult issues to solve as part of the project delivery, particularly for existing plants where the process and control dynamics are well known.
Project award only arrives after a lot of preliminary work by the sales team and the buyer. Issues are discussed and decisions taken. Project award typically marks the end of this phase and is usually a happy occasion. Those involved (vendor and buyer) will congratulate themselves on their decisions and look forward to an OTS that meets all their expectations. Thereafter, the project implementation team will be put to work following a fairly standard project model (see Figure 1).
The first major implementation task is model development. A new dynamic process model will require an enormous amount of data to be processed and configured within a model framework. This needs the attention of simulation experts in order to ensure robustness, accuracy and adequate simulation speed. Several months (or more) are likely to be needed. Short-cuts are rarely available or effective because they almost inevitably reduce robustness and/or accuracy and, therefore, compromise the project’s objectives.
A pre-existing simulation model can be used, but it is still likely to need significant work to adapt it to the specific OTS requirements, current plant configuration and operating conditions, and/or to make it consistent with the current simulation technology. Reuse of an existing model also risks depriving the project of the deep process understanding that comes from building a high-fidelity model. Process understanding is almost always crucial to any problem solving on an OTS, including issues with the DCS and ESD functionality, and it is critical this is not ignored. Common mistakes include:
• Separating the model builders from those with real plant experience
• Trying to apply a one size fits all execution model
• Ring-fencing parts of an existing process model against any change.
These approaches should be avoided, even if they appear superficially cost effective.
Pre-existing models often come with baggage, too. Rose-tinted glasses can make old models unrealistically attractive, even though the project team accepts that there have been changes to the plant, changes to simulation software and the need for a new project at all. Too many projects have floundered on the unrealistic assumption that a pre-existing model will be good enough to meet elevated standards.
The dynamic process model must then be validated. Tests are usually set up on the standalone model to prove its accuracy to one or more steady state conditions before testing the model’s dynamic behaviour. The model responses should be ‘reasonable and realistic’ for a wide range of transients. Judging reasonableness and realism is difficult. Typically, experienced operating staff are asked to make this assessment and, while this is usually the best option, it is not quantifiable and is subject to preconceptions and other human factors. For example, it is very common to have experienced operators reporting that a model reacts more slowly than the real plant. This misconception is well known by the idiom that a watched pot never boils. Real plant data that are free of excessive noise and unmeasured disturbances would be ideal, but is difficult to collect and is not usually included in the project planning.
Model validation is, occasionally (and wrongly), considered an unnecessary luxury. Maybe those involved are sufficiently confident of the model’s fidelity, or they feel the schedule is more pressing than quality control. However, skipping model validation (or failing to take sufficient notes during the process) is usually the prelude to a project’s disaster.
In parallel with model development (or starting slightly later) is the preparation of an OTS version of the real plant DCS. This step is necessary to incorporate basic OTS functionality such as start, stop, save, load and possibly faster than real-time operation. It may also be a necessary (or cost effective) mechanism to ensure the project hardware costs are minimised so that redundancy (unnecessary in an OTS) is not built in accidentally. Not all vendors have the same approach to preparing the OTS version of the real plant DCS, and it is not guaranteed that all aspects of the DCS functionality will be fully supported. In particular, logic sequences and alarm monitoring systems should be scrutinised to ensure that they function correctly under all circumstances, including save and load. This phase is not trivial, and the effort involved should be measured against the likely statement of requirements that it should be possible to quickly and easily import that current plant DCS database into the OTS.
So far, so good. The project has successfully developed a high- fidelity dynamic simulation model of the process and an OTS version of the real plant DCS. The integration of these two systems will typically take a few weeks to a few months. This task is predominantly mechanistic, although there will always be a set of more taxing problems to solve, and the difficulty should not be dismissed lightly. Care needs to be taken to ensure that signals have the right sense (on/off or healthy/unhealthy), control actions and valve actions match, and signals arrive at the correct landing site with the DCS. The complexity of this task is often multiplied by the need to include an ESD system that is tightly coupled to the DCS, or to manipulate process signals to meet plant formats. Aspects of this project phase can be automated, but only after establishing the rules that apply for this particular project.
The finish line would seem to be in sight. However, it is at this stage of the project that someone will suddenly discover that a particular control loop on the integrated system (model plus simulated DCS) is unstable or slow to converge. They will be disappointed and an investigation will begin. The first port of call is likely to be checking the controller tuning constants, perhaps by ringing the control room to make sure the project team has the latest data! Next, someone will conclude that the tuning is right so that the model is wrong. The simulation engineer will then be asked to fix the high-fidelity dynamic simulation model to better match actual plant performance. And this is where the problems really start.
Process control engineers tend to have the best understanding of the offset between a model and reality. They are often reluctant to use the results of a dynamic simulation model to build or tune their controllers. Instead, they prefer to use the plant as a test bed and tune their controllers to the actual plant responses. In most cases, this approach is pragmatic, sensible and efficient (although it is often possible to get good, noise-free data from a high-fidelity simulation, too). What should be clear is that combining plant controller tuning constants with a simulation model built from theory is not guaranteed to work perfectly. However, despite this, it often comes as a surprise to the project team and is unlikely to have ever been discussed back at the post-award dinner.
Add your rating:
Current Rating: 2