Book Image

Operator Training Simulator Handbook

By : Joseph Philip
Book Image

Operator Training Simulator Handbook

By: Joseph Philip

Overview of this book

Operator training simulators in the process industry have been around since the 1970s, but you may not find a book that documents the development of these systems and the standard best practices. The Operator Training Simulator Handbook covers best practices for OTS engineering and OTS training development and delivery, starting from the basic the jargon and the different types of OTS systems. It will take you through the best approaches to project specification as well as building, maintenance, planning, and delivering these systems by sharing real-life experiences and dos and don’ts. As you advance, you'll uncover the various challenges in the planning and delivery of operator training models and understand how to address those by working through real-world projects. This book helps in specifying the best fit for purpose, choosing a cost-effective system when acquiring an OTS. You'll also learn how you can turn your OTS projects into digital twins before finally learning all about documentation in a typical OTS project, covering the sample structure that you can use as a starting point in your projects. By the end of the book, you'll have learned best practices for developing operator training simulator systems and have a reference guide to overcome common challenges.
Table of Contents (11 chapters)
1
Section 1: Introduction, Definitions, and Classifications
3
Section 2: Best Practices for the Development of OTS Systems
6
Section 3: OTS' Future, Training Model, and Reference Documents

OTS – MPDS or digital twin

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

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)

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

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.