It has been a long time since I wanted to write this book, and as always, time was an issue. The coronavirus lockdown in 2020 managed to give me the time needed to do so. I have been working in the Operator Training Simulator (OTS) field for more than 30 years, and I thought it would be good to document this experience in a textbook that will help many stakeholders in this field.

In this chapter, we will introduce OTS in the process industry and provide a classification of these systems. We will discuss who this book is directed toward and who the stakeholders are that will make the most of the information provided. The industry uses a lot of jargon, and in this chapter, we will look at some definitions to set a base to understand these terms.

Finally, we will discuss what is good for the user and give some sample cases from my past experience in this field.

In this chapter, we'll cover the following main topics:

• Introduction to OTS
• Who is this book directed toward?
• OTS – Multi-Purpose Dynamic Simulator (MPDS) or digital twin
• OTS jargon and definitions
• The instructor station
• OTS types
• Third-party representation
• Some use cases

There are no technical requirements for this chapter. Those who will benefit the most would already be involved with OTS projects as suppliers or contractors. Even if you are not involved with OTS, this chapter will be a good introduction to the subject.

We can start with the fact that, for the last 40 years, flight simulators have been providing the aviation industry with training simulators for all their pilots at all stages of their careers. These simulators have evolved over the years, but they have always had the ability to train pilots before they take their first flight.

Providing this training over the years has reduced air traffic accidents and provided pilots with a huge amount of experience in normal and abnormal flight conditions. Flight simulation has also provided the mechanism to practice evolving safety practices and maintain a very high degree of competence.

I have always asked myself why, if aviation pilots always train on simulators (please refer to Figure 1.1, taken from https://www.cae.com/civil-aviation/aviation-simulation-equipment/training-equipment/full-flight-simulators/), the process industry has not fully adopted this practice for their personnel who take responsibility for the control of major assets; the process industry equivalent of pilots being Control Room Operators/Technicians (CROs/CRTs):

Figure 1.1 – A CAE flight simulator

You could say pilots have, in their hands, the lives of tens, maybe hundreds, of people if they are flying an Airbus 350 or a Jumbo Jet. Similarly, CRTs are running assets with tens of personnel in the plant while they are maintaining the running parameters, which can go into the hundreds, of atmospheric pressure and very high temperatures, along with fuel vessels that carry a heat capacity of far more than what a nuclear bomb would deliver! So, the risks and responsibilities are equally high and can be compared with flying an aircraft. The industry has changed over the last 20 years, and it has evolved with new projects coming that provide training simulators.

This is the evolution that we need in the industry. In Chapter 4, Going Forward Toward Digital Twins I will describe my vision for the 21st century.

Similarly, the nuclear industry has been actively using simulators, and no nuclear reactor operator will work in the control room before getting their training on a simulator first.

Again, you could ask why all nuclear plant operators train on simulators but thermal plant power plants don't get the same treatment. I think the time has come to change this concept. In every project I have delivered, there was a huge benefit to the users, and the companies that invested in these systems got their Return on Investment (ROI) in no time at all. We will look at some of the examples of these benefits in upcoming chapters.

For now, let's explore what an OTS is.

Figure 1.2 shows how Inputs/Outputs (IOs) to and from the field communicate with the control system with its Process Automation System (PAS), Safety Instrumented System (SIS), Fire and Gas (F&G), and third-party controllers such as Compressor Control (CC), for example.

The CRTs in the control room can see the status of the plant through their Human Machine Interface (HMI) screens and can control it from the control room:

Figure 1.2 – A real-life plant

In an OTS environment (Figure 1.3), the HMI in the OTS control room is exactly the same as the one in the real-life plant, so the CRTs will see no difference between operating the OTS and operating a real plant:

Figure 1.3 – The OTS of the plant

The control system in the OTS environment is an emulation of the actual control system, which also matches the same behavior as the real control system. One difference is that while the real system controllers run on a controller where everyone can handle up to any number of IOs (let's say 100), the emulation will run on a virtual/desktop machine that emulates many controllers in one virtual/desktop machine.

The process in the field is modeled using process modeling software (such as AspenTech's HYSYS®, Honeywell's UniSim®, AVEVA'S DYNSIM®, or NAPCON's ProsDS®). Usually, this will be running on another virtual/desktop machine.

Figure 1.4, taken from https://www.fossilconsulting.com/2018/10/01/purchase-a-training-simulator/, shows how the OTS looks very similar to the control room. The operator should not see any difference between the two:

Figure 1.4 – The OTS of the plant is similar to the control room

Now that we have defined the OTS system that we will address in this book, let's discuss who this book is directed toward.

One of the main issues suppliers are faced with is that end users do not know exactly what they want. So, here, I am trying to provide information for end users to help them understand what is best for them. We will start with defining the necessary specification for an OTS for a new project and continue right through to the project cycles, KOM, data collection, and more until Site Acceptance Test (SAT). We will even look beyond this to the training and engineering uses of the OTS.

As I have delivered many simulators over the years with different suppliers and different setups, I will be including a chapter on project execution and best practices, which will help suppliers access my long experience and discover what really worked during project delivery.

Additionally, a chapter showing the benefits of OTS will list a few real-life examples and the benefits that were achieved. This will provide a useful example of real project work on how the OTS was put to use.

Finally, there will be a chapter on training development and execution. When the OTS/MPDS/Digital Twin (DT) is delivered, the assumption from the end user is that it can be used for training straightaway. This concept is incorrect, and many end users forget that there is a period needed to set up the system to be ready for training, which could vary from weeks to months based on the complexity of the project. This is not to say that this cannot be broken down into smaller pieces, and preparation is only needed for the next deliverable training session, for example, an introduction to the OTS, but still, the length of time required is considerable and will need to be catered for.

Another challenge on the training side is what is known as bums on seats! I reckon this is the most challenging task in training as CRTs/CROs have different tasks to do alongside OTS training. This is more difficult on an offshore project for obvious reasons. So, this task will need to be planned and agreed upon with management well in advance of the actual training dates.

To summarize, contractors that are thinking of investing in a simulator will benefit from this book by seeing what the best practices are to specify a simulator that will give you what you want for the investment that you are taking. In addition to this, it will show them how they can benefit from their system and the best ways of using it.

Vendors will benefit from seeing the best practices of executing these projects; an experience spanning 30 years of delivering these systems and challenges will be shared in this book.

A final group of individuals that this book is directed toward is users and engineers who are thinking of getting into this field. They will also be able to see what these projects are about.

The naming of the OTS systems has been evolving over the years. First, we will go through that evolution, and define every term.

I started with simulation some 36 years ago while doing my undergraduate degree. My first program was FORTRAN IV running on a Honeywell mainframe computer. It was a simulation of an internal combustion engine.

Personal computers were coming up at the time, so I convinced my supervisor to use QBASIC on an IBM XT computer. At least I would no longer need to worry about punch cards. In the old days, the means of inputting program information into a computer was done by punching every program statement into a punch card using a special machine. The computer would have a punch card reading machine that would be able to translate the punch card into a program statement in the computer environment. Imagine the time spent punching in these cards compared to typing it directly these days – let alone fixing mistakes, which was very troublesome, as you can imagine:

Figure 1.5 – A sample punch card

I was successful and started using an HP plotter to plot my result (Figure 1.6). I needed to save the BASIC plotter programs on a cassette after formatting it, which was also a hassle:

Figure 1.6 – The output of the HP plotter result (1989)

When I started working with Techcomm Simulation in Sydney, Australia (which was later taken over by Yokogawa, in 1999), I started using the C language to model power plants. Unlike these days, there was nothing like dragging-and-dropping modeling software tools (such as HYSYS®, UniSim®, DYNSIM®, Petro-SIM®, or INDISS®). Every model needed to be written in C and tested, then integrated with other C models. When all of the models were tested locally, they were integrated together with the Distributed Control System (DCS) emulation in a Unix environment.

I still remember a colleague of mine, Lloyd Watts, telling me, Joseph, you should be very happy when we run one step (0.25 seconds), and the simulator does not crash!

At the end of the 1980s and during the early 1990s, the simulators were called operator training simulators, as their main purpose was to train operators. Building simulators used to take much longer and delivering an OTS a year before the first startup was still a dream. OTS projects were always delivered well before the plant was commissioned and started up, so using the simulator to test the DCS was not usually the case.

As computers became better, more sophisticated, and the simulation software became more reliable, simulators could be delivered at reasonable times. In addition to that, the DCS/Integrated Control and Safety System (ICSS) emulation started becoming much more accurate as well.

At that time, we started calling the process simulators MPDSes. The main purpose was still to train the control room operators. However, because we could deliver the simulators early enough, a few months after the ICSS being Factory Acceptance Tested (FATed), we started using the simulators to do the following:

• Debug ICSS controls.
• Check the operating procedure.
• Tune the process controllers.
• Check the HMI graphics.
• Use for process debottlenecking.
• Process engineering studies.
• Control engineering studies.
• Perform emergency response training.

I usually don't like name changes, but what followed, I am totally for. And here is the reason why.

Recently, we started calling the process simulators digital twins!

The origins of digital twins take us back to 2002, to a presentation by Dr. Michael Greives at the University of Michigan, where he described the twin as a conceptual ideal for product life cycle management.

The concept had all the definitions of a digital twin, virtual space, real space, and an information link:

Figure 1.7 – The digital twin concept

To view the full reference of this, please refer to Dr. Michael Grieves and John Vicker's paper, Digital Twin: Mitigating Unpredictable, Undesirable Emergent Behavior in Complex Systems (Excerpt).

If we look at Figure 1.2 and Figure 1.3, we can see that they are digital twins, that is, real and virtual spaces. The data that you use to build the virtual space is the data link, and the outcome from the twin that you can use to improve the real space is the information link referenced earlier.

The industry started using simulators in parallel to the ICSS project, by using the simulator to properly test the ICSS. Finally, I had seen what I was hoping to see many years ago. We will discuss this in more detail in Chapter 4, OTS Going Forward Toward Digital Twins

Now, let's look at some jargon terms and try to define them as the industry uses them.

It is very important to clarify some definitions at the beginning of this book as there is a mix-up in the industry, and many terms are used interchangeably; for example, Initial Conditions (ICs) and snapshots, snapshots and backtracks, scenarios and ICs, and more.

While the nuclear and thermal power OTS industries have standards, the oil and gas, chemical, pharmaceutical, and, in general, process OTS industries do not have one. Perhaps this chapter can serve as a starting point to achieve this; therefore, in this chapter, there will be more concentration toward OTS projects within these industries.

Nuclear power plant simulators are used for operator training and examination. The standard is ANS-3.5-2018 and can be found on the American Nuclear Society website at https://www.techstreet.com/ans/standards/ans-3-5-2018?product_id=2090333.

This link was valid at the time of writing. If the link does not work, you can try searching for the standard name Nuclear power plant simulators for use in operator training and examination.

Additionally, there are fossil fuel power plant simulators – the functional requirements standard is ANSI/ISA 77.20.01-2012 and can be found on the American National Standards Institute website at https://webstore.ansi.org/Standards/ISA/ANSIISA7720012012.

This link was valid at the time of writing. If the link does not work, you can try to search for the standard name Fossil Fuel Power Plant Simulators – functional requirements.

Next, we will look at the jargon terms used in the process industry regarding OTS projects. I will explain each one so that we have a baseline definition to remove any vagueness around these established terms in the industry.

With every simulator, there must be an interface that the instructor (trainer) uses to control the simulator. The instructor station will serve this purpose. From this station, the instructor will be able to do the following:

• Run/freeze the simulator.
• Set the simulation speed.
• Load/save the simulator state (including ICs, snapshots, and more).
• Apply malfunctions.
• Initiate training scenarios.
• Use tools to assess the trainees.
• Operate the Field-Operated Devices (FODs).

In the next section, we will discuss the main features of the instructor station and define each one.

Run/freeze

When the simulator is in run mode, that means the model is calculating values to send and receive data from the ICSS representation, and the simulator time will start ticking. Similarly, freeze mode means to hold the calculation, so the simulator time will stop ticking.

Initial conditions

The instructor will need to save the status of the simulated plant (all simulated components, model and controls representation) in an electronic form to be reloaded at the time of choice. These files are called initial conditions or generally referred to as ICs. ICs are states that the trainer will use in training, and, usually, they are kept for a long time.

Here are some examples of ICs:

• Steady state: Usually, this is when the plant is operating at a steady production, for example, full production.
• Cold start: The plant is in shutdown condition and has been for a long period of time and is ready for a restart.
• Warm start: The plant is in shutdown condition and has been for some time (usually, a few hours), so the plant is not yet cold.
• Hot restart: The plant is in shutdown condition and has been for a short period of time and is ready for a restart.
• Low rates: The plant is operating but at low production rates.
• Generator ready to sync: The power plant has been started up, the turbine is at synchronization speed, and the generator is ready to be synchronized to the grid.

Snapshots

These are similar to ICs; the only difference is that they are usually temporary files. The instructor will save these during a training session to show the trainees a specific thing, or they will be saved at the end of a training session to be loaded later to continue training.

Backtracks

All OTS suppliers will supply functionality to automatically save a snapshot at a period defined by the instructor. These snapshots are called backtracks. Every OTS supplier will have this functionality designed differently, but in general, there will be a set of backtracks or a time limit to save these backtracks as these files could be large and fill the disk. So, for example, some suppliers will make the instructor define the number of backtracks that they want to save, for example, 20 backtracks and the backtrack is saved every 30 minutes. The OTS will save 20 backtracks at 30-minute intervals, so across 10 hours. Then, backtrack number 21 will overwrite backtrack number 1.

Other suppliers will fix the number of backtracks to 10 and allow the instructor to define the period.

Malfunctions

These are meant to represent an abnormal operation in the simulated process. They usually come in two types.

Generic malfunctions

These are also called standard malfunctions. They usually come installed with every piece of modeled equipment, such as the following:

• Valves – fail open, fail close, or stuck in position
• Motors – pumps, compressors, fans, trip, or inhibit to start
• Heat exchangers – the fouling of either side of the heat exchange
• Transmitter – fail high, fail low, fail in position, and drift

Custom malfunctions

These are bespoke malfunctions built by the supplier based on some specific requirements of the end user. Examples of these would be the following:

• Pipe rupture
• Disk burst
• Foaming in a knockout drum or in columns
• Fire detected in a specific plant area
• Gas leak detected

Instructor scenarios

I have found that there is a mix-up in the concepts of scenarios in the industry, and this needs to be clarified. Usually, end users mix scenarios with ICs or snapshots. I think the reason for this is that end users usually think of training scenarios, for example, a startup training scenario, and hence, they mix the two. A training scenario is not the same as an instructor scenario.

Instructor scenarios are a set of one or more actions played by the simulator at prespecified times by the instructor.

For example, let's imagine that an instructor wants to do the following:

• Load an IC.
• Run the simulator for 10 minutes.
• Apply a generic malfunction at a simulator time of 10 minutes.
• Apply a custom malfunction at a simulator time of 20 minutes.
• At the simulator time of 30 minutes, freeze the simulator.

The preceding actions can be saved in the OTS, and the instructor can call these at any time and run them to test the trainees.

Record and playback

The ability to save the instructor's actions and play them back at the instructor's request is what is meant here by record and playback.

Simulator speed (real time)

The ability to change the simulator speed to run faster or slower than real time is the simulator speed functionality of the instructor station. When the simulator speed is 1, the simulator elapsed time is the same as the real time, and this is usually referred to as real time. When the simulator speed is 2, and 1 minute of real time lapses, the simulator time will show 2 minutes. For example when the simulator speed is 2 and filling a tank needs 1 hour, then with this speed you will need 30 minutes to fill it.

This functionality is useful when the instructor does not want to wait a long time to fill big tanks, heat big pieces of metal, and so on.

FODs

To be able to operate the FODs on the simulator, for example, manual valves, field hand switches, or locally operated pumps, usually they will need to be accessed from the instructor station.

Now that we have completed our discussion on the main features of an instructor station, next, we can talk about the different OTS types and their classifications.

An OTS can be categorized in many ways. Here, we will list the three main ways in which to categorize an OTS. The three categories are as follows:

• Representation
• Fidelity
• ICSS representation

Representation

An OTS can be categorized to show how specific it is to the plant that the operators are to be trained on. Under this category, there are two types, namely, generic simulators and replica simulators.

Generic simulators

A generic simulator is defined as a simulator that will simulate a specific type of process, that is, a part of a refinery, a part of an FPSO, a combined cycle power plant, an Ethylene plant, and more. The simulated process is not the same plant as the one the operators are training on. In this type of simulator, the operator's screens will point to equipment that will look and operate in the same way as the ones used by the operator in the plant but will not have the same tag numbers.

Generic simulators are suitable for training new operators on a specific process area or a specific ICSS. They can serve as an introductory level to the processes and controls within a process plant. They are much cheaper and quicker to build in comparison to replica simulators.

Generic simulators are ideal for training and practicing a back-to-basics approach. Underpinning this is an understanding of the principles of process operation and the instruments used. A good example of this is the operation of a cascade instrument loop to control. Cascade control basics are the same, so no matter what you are controlling, you can train the operators on the basics of these loops.

A good example for training companies that offer training courses on generic simulators is ESD Simulation Training (https://www.esd-simulation.com/w/uk). This offers different process and control courses using generic simulators:

Figure 1.8 – ESD training in progress

Another example of such a company is TSC Simulation, https://www.tscsimulation.co.uk/, which is based in the United Kingdom, but there are many others around the world:

Figure 1.9 – TSC's virtual control room

In many cases, a generic simulator will be both beneficial and cost-effective, while in other cases, a more detailed simulation will be needed, as we will discover in the next section.

Replica simulators

A replica simulator is defined as when the simulated process and the ICSS are exactly modeled in the OTS. This allows the operator to see the OTS, including the same graphics, and notice the same behavior between the process and the ICSS.

Replica simulators can be used for specific plant operations, optimization, and can serve as an extended level of testing to process plant design, especially for dynamic and ICSS control checkouts.

An excellent example of a replica simulator is a nuclear plant simulator. Here, the simulator control room is a copy of the actual control room.

Figure 1.10, taken from https://www.wbur.org/earthwhile/2019/05/31/plymouth-reactor-training-center, shows a simulator for Pilgrim Nuclear Power Station:

Figure 1.10 – The Pilgrim Nuclear Power Station simulator

In the following table, we will discuss some of the comparisons between generic simulators and replica simulators:

Table 1.1 – Generic versus replica pros and cons

To sum up, an OTS can be classified by the way it represents the process plant. It can either be a generic simulation model or a replica one. Both have their advantages and disadvantages, which we have tried to highlight in a pros and cons table for ease of comparison. In the next section, we will classify OTS based on the process model of fidelity, which ranges between high-, medium-, and low-fidelity OTS. We will discuss each of them, and we will let you decide which one is more suitable for your business case.

Fidelity

Another way to categorize OTS is by the level of model fidelity, which ranks from low to high and includes a medium step. Describing these different types will help you decide what is good for your specific situation; however, we will discuss this later in the chapter.

Low fidelity

ICSS contractors prefer to call these tie-back simulators, but in reality, they are low fidelity. Some OTS suppliers can only generate a model with ICSS IO points. These can be wired back to the ICSS, making the HMI graphics read default points. As its name suggests, the IOs will tie back to the ICSS and can be varied from the model in a lump way, for example, by turning on or off all the alarms to activate or deactivate them. This can be done in a specific scenario over a specified time. The same thing can be done for analog points to ramp all 4-20 mAmp inputs from 4 to 20 within a specific time ramp.

This will allow you to test that all IO devices are connected properly to the ICSS, and all HMI graphics can be tested using the low-fidelity simulator.

A low-fidelity simulator can be put together in a matter of days or perhaps a couple of weeks, making their cost low.

As low-fidelity simulators are quick to build, they can be used while the replica simulator is being built to train operators for getting familiar with the ICSSes and, in particular, the HMI. I have used this technique in a few of my projects and that proved very useful.

Medium fidelity

When the process model is simplified, for example, by using a water-like component in an oil plant and adding it to the low-fidelity simulator described earlier, we end up with a medium-fidelity simulator.

In this type, the operator's use of the simulators is slightly improved, creating a familiarization system for them. Operators can open and close valves and start and stop motors with a very low level of dynamic response fidelity.

On the other hand, ICSS use is dramatically increased in comparison to the low-fidelity model. These types of simulators can be used to validate controls, safety, and alarm philosophies. In such simulators, automatic sequences can be checked out, as these are never adequately tested in an ICSS FAT.

The time required to build these is typically 2–3 months (of course, this depends on how big the process model is and the use of automatic tools to generate the model, for example, reading smart P&IDs). This will make the price for these simulators higher than the low-fidelity ones.

High fidelity

This type of model is built based on actual P&IDs, datasheets, Heat and Mass (H&M) balance reports, and all other process inputs.

All process dynamics, pipe volumes, valve CVs and characteristics, and pump and compressor curves are used to build the model. In turn, this model is integrated into the ICSS, making the simulator behave as close as possible to the real plant.

This will dramatically increase the use of the simulator for operator training, dynamic studies, and plant optimization.

These simulators will take anything between 12 and 24 months to build, making their cost the highest of all.

Figure 1.12 describes the effectiveness of all three types of simulators versus the cost and time taken to build the simulator.

In the lower-left corner, we see the low-fidelity simulators showing a low cost and being quick to build, with little use. In the middle, we see that the medium-fidelity simulators show a little use on the operator training side but more use on the ICSS side, taking the price and time to build slightly higher.

In the upper-right corner, we see high fidelity reflecting the model use of the simulators, but at the same time, at a much higher cost and with a much longer time to build.

A good scope document should list all the uses of the simulator against cost and justify the investment, as we will see in later chapters of this book:

Figure 1.11 – OTS effectiveness versus cost

In this section, we have learned how an OTS can be a low-, medium-, or high-fidelity simulation process. Each will have its own uses and advantages. Before making the OTS investment, it is always advisable to get all the project stakeholders to agree on which OTS type will bring the most benefits to the business.

In the next section, we will classify an OTS based on its ICSS representation.

ICSS representation

Another way of categorizing OTS is by the way the ICSS is simulated.

Emulated

This was a well-known solution in the 1980s and early 1990s. ICSS contractors did not have well-developed connections when it came to modeling software. Some OTS companies, or OTS teams diverted from process control suppling companies, introduced this solution to the market.

In this solution, all HMI graphics of the ICSS are redrawn, and the ICSS logic is converted into a model that can run on a personal computer. Sometimes, this process is done automatically, while at other times, the process is manual or semi-automatic.

Of course, this was very costly, and errors were likely to be made in the conversion, which would have meant longer integration, OTS commissioning, and approval processes. In those days, that gave simulators a very bad reputation.

As the ICSS suppliers started to make links to the process models possible, this solution started disappearing from the market; however, in recent years, it started making a comeback due to the market pushing for lower-price OTS models and OTS supplier competition increasing. But today, these simulators should no longer be on the market, as we have a proper solution, and using these will make the simulator much less useful. Additionally, the bitterness in the market toward OTS makes the idea not worth it!

Stimulated

In this type of OTS, the actual ICSS controllers are used in the simulator along with the same ICSS hardware. Therefore, the HMI operator station is the same as the one used in the control room for the plant that is being simulated.

This technique is no longer used as it is very expensive, but it will give the same reaction as the actual ICSS. This is because the hardware is the same.

Hybrid

Many ICSS suppliers have created a solution in which to run an emulation of their controllers on a computer that can be integrated with an OTS. The control is faithfully emulated, and the code is exactly the same as the one that runs in the ICSS controller. Additionally, the HMI is exactly the same as the one used in the control room.

Usually, this type is referred to as "emulated" OTS; however, in this book, we will use "hybrid" as the emulation here is different from the emulated type of simulator. The emulation here is done by the ICSS contractor, and the control's code is the same as the one used in the ICSS controller.

This solution has been adopted by many ICSS suppliers, such as Yokogawa, Honeywell, Schneider, and Emerson, just to mention some of the major players in control automation within the process industry:

Figure 1.12 – OTS types

So far, we have classified OTS as both generic and a replica, based on its plant representation. Following this, we classified OTS based on its model representation, including low-, medium-, and high-fidelity simulation models.

Finally, we classified OTS based on its ICSS representation, and we discussed emulated, stimulated, and hybrid systems.

In the next section, we will discuss how third-party controls are represented in an OTS.

In addition to the ICSS, usually, there are third-party compressor controls, turbine controls, power management systems, or other controls that need to be simulated, and this control is outside the scope of the ICSS.

This can be represented in two ways:

• Simplified and modeled in the process model
• Using the supplier emulation and integrating this into the simulator

The first option is cheaper, but its effectiveness is lower. The second is expensive but is far more effective.

On one FPSO project, the compressor controls were CCC, and the emulation of the CCC was used. While this solution was expensive, we could tune the compressor controls within a week onshore using the simulator. The tuning parameters were used offshore, and a huge saving of cost was achieved.

In the much less stressful simulation environment, we needed a week to tune the compressors. Now imagine doing this offshore while trying to commission or start up the compressor. This will take at least 3 additional weeks, if not more.

In the simulation environment, we could run the compressor sequence as many times as we want in a day. This is impossible offshore.

Having gone through the different types of simulators, you might be asking, what would be the best one to choose?

Well, it mainly depends on two primary factors:

• What will the simulator be used for?
  • A brownfield or greenfield plant
  • Is the simulator purely for training?
  • Are the operators experienced or do we need to train new ones?
  • Are engineering studies, process debottlenecking, and process optimization of any sort required?
  • Do we need the OTS to debug the ICSS?
• What is the available budget to spend and the time allowed for the project to run?
  • It is important to put aside the budget for building the simulator and then running it.
  • Define the exact time available to build the simulator and its usage plan afterward.

On the first front, before embarking on an OTS project, users must clearly define what the simulator is going to be used for.

If the plant is an existing one (brownfield), then the need for a simulator will come either from the need to upgrade the ICSS or a change to the process units (or both), or the need to train new operators. In all these cases, it is very likely that a generic model or a lower-fidelity model will not serve the purpose.

Additionally, if we need to train a few new apprentice operators who are new to control rooms, a generic (cheap) simulator might be sufficient.

If the plant is being newly built (greenfield), then we need to decide whether we need operator training; most likely, we will need a higher-fidelity OTS. However, if we only need to check out the ICSS IOs, then a tie-back simulator will be sufficient.

The budget that is available comes at the end: low-fidelity models are around $100k, while the high-fidelity ones would be no less than $500k. Of course, it will all depend on how big the process is and the number of IOs in the ICSS.

Another very important cost that needs to be considered is the running cost, as follows:

• The cost of a training instructor.
• The usual day-to-day upkeep of the simulator, consumables, backups, and more.
• Travel and living for trainees.
• The catering cost during the training session.
• The cost of keeping the simulator up to date. This could be the highest cost but will ensure the continued use of the simulator.

Hopefully, this section will be useful to you if you want to invest in an OTS project and help you decide what will be good for you. But the following case studies will give some examples that will clarify this and bring some real-life examples home.

Without further ado, let's look at some case studies that will help you to understand what OTS will fit the case better.

Case study 1

An end user needs to upgrade their ICSS with no major change to the control logic and no change in the ICSS supplier, all operators are experienced, and no major process change is expected.

In this case the need is just to train the operators on the new interface. This does not justify major spend on a full replica simulator. A tie-back simulator will serve the purpose of operator HMI familiarization.

A tie-back simulator will have access to the new HMI system that can be used to train the operators with a very small investment compared to other expensive systems.

Case study 2

We'll stick with the same end user as in case study 1; this time they need to upgrade their ICSS to a different ICSS supplier, all operators are experienced, and no major process change is expected.

Now that the ICSS HMI has changed, the operators will need to understand better the new interface. Since the process has not change, then a medium-fidelity simulator to familiarize the operators with the new HMI and being able to validate the new control and alarm system will be sufficient.

In case study 1 we just needed to use the HMI system to get the operators introduced to the new HMI changes and for that we just need a tie-back feedback, that is, when a pump is started, the start command is feedback to say the pump is running.

In case study 2, we will need a bit more accurate feedback as the HMI is new to the operators and we will need to operate, for example, automatic sequences. If we use tie back, then that will give the operators wrong impressions of the process. Reasonable feedback will do the job. If we start a pump, then a level in the suction will need to be reasonably calculated. So, if the liquid is modeled as water, rather than oil for example, it should be fine. Of course, the timing of the level going down will not be same as in the real space, but that will be fine for what we want to achieve here with savings in our investment.

Case study 3

We'll stick with the same end user as in case study 2; this time they want to be able to debug the ICSS, tune all the PID controllers on the simulator, and be able to test ICSS changes on the simulator before pushing these changes to the plant ICSS.

Due to this last requirement only, a full replica simulator will be able to satisfy the new requirement.

Let's take tuning the PID controllers; for example, if we don't model the size of the plant then our tuning will not be correct.

Similarly, if we need to debug the new ICSS, then the process feedback will need to be the same as in the real space so our test will be valid.

Case study 4

In this case study we will consider a running plant where a few operators will be retiring soon, and the company will need to recruit new operators; they are getting a few apprentices to train them to be able to replace the retiring operators in a few years' time.

Here the end user can go for a cheap generic simulator to train the apprentices on the basics of the process and plant operation and when that is done (or in parallel), to be sitting in the control room next to the experienced operators to be trained on day-to-day operation.

Training new operators on basic process operation and control can be done on any generic plant. If we need to train the operator when a controller is in manual control, then you can set the output directly in the controller faceplate. That can be done on any controller.

Similarly, when the controller is in Automatic model, we need to show the operator how the set point can be changed and the controller will control the process until the process vale (measured vale) is very close to the set point. Again, this can be shown on any system and not necessarily a replica simulator.

Case study 5

The end user in this case is building a new plant and will need to recruit operators from other sites or newly recruited operators. The end user wants to be able to do process studies and ICSS debugging and upgrade capabilities on the OTS.

There is nothing required to satisfy the preceding needs other than a full replica simulator.

In this case as we need to do engineering studies, on the process or the control system, we will need a full replica simulator to be able to test the process successfully.

I would hope by giving these case studies, you will have some examples on what OTS type to choose when you want to invest in one. OTS can be expensive and it is vitally important to choose a solution that is fit for purpose.

In this chapter, we introduced the concept of OTS, how these systems evolved to become MPDS, and finally, how they became digital twins.

Additionally, we talked about some of the jargon that is used in the industry and set some definitions to create a base of understanding for terms such as ICs, generic and custom malfunctions, scenarios, and more.

Next, OTS classifications were discussed to define generic versus replica simulators, different fidelity simulators, and different ICSS representation simulators.

Finally, we ended the chapter by giving some hypothetical cases to show what type of simulators to use in different real-life situations.

In the next chapter, we will discuss the benefits and best uses of OTS systems. In my experience, a lot of time, the projects that companies put large investments into do get used to their optimum capabilities, and that is what we will try to address next.

• What is an operator training simulator (OTS)?
• What is a multi-purpose dynamic simulator (MPDS)?
• What is an initial condition (IC)?
• What are generic malfunctions?
• What are Filed Operated Devices (FODs)?
• What is the difference between a generic simulator and a replica simulator?
• What is a full replica simulator?
• What is the difference between an emulated ICSS and a stimulated ICSS?
• You are working on an upstream project and the company needs to invest in a simulator to train operators before the first plant startup (first oil). As well as this, the company will need to use the simulator to verify operating procedures and check the ICSS alarm and trip settings. What type of simulator would you go for?