44,39 €
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.
Das E-Book können Sie in Legimi-Apps oder einer beliebigen App lesen, die das folgende Format unterstützen:
Seitenzahl: 275
Veröffentlichungsjahr: 2022
The Operator Training Simulator (OTS) industry has been changing quickly, especially in the last decade. While in some industries, such as aviation and nuclear energy, simulation has been well established, in the process industry it is taking shape and trying to catch up.
This book is an attempt to set some standards for the OTS sector in the process industry. It will share real project experiences and best practices with you to help broaden your knowledge about the subject.
The book is not meant to be a theoretical textbook, but a guide based on real-world experience in the field.
This book will share the experience of the author, who has worked for more than 30 years in the industry, delivering and using OTS systems, to help you in many ways. You may be someone who is thinking of acquiring an OTS, a supplier who builds OTSs, or an end user who uses an OTS.
Chapter 1, OTS Introduction, is an introduction to OTSs that will go into who this book is for, different types of OTSs, and jargon used when talking about OTSs.
Chapter 2, OTS Benefits and Best Use, covers OTS benefits and best use using real-life project experiences.
Chapter 3, OTS Project Execution and Best Practices, covers the best practices of building and delivering OTS projects using real project examples.
Chapter 4, OTS Going Forward Toward Digital Twins, explains how to move an OTS project to make it a digital twin, making the most of the OTS.
Chapter 5, OTS Training and Delivery, provides a training module for you to use in your own projects.
Chapter 6, OTS Sample Documentation, shares a sample template of the main OTS project documents.
To get the most out of this book, a basic knowledge of process plants will go a long way. If you have been involved in an OTS or ICSS projects, then that will help you grasp the concepts in this book quickly. Having said that, for those who don't have OTS project experience, there are some basic concepts that are laid out for engineers, operators and training instructors that will be easy to digest.
We also provide a PDF file that has color images of the screenshots and diagrams used in this book. You can download it here: https://static.packt-cdn.com/downloads/9781803242958_ColorImages.pdf.
Feedback from our readers is always welcome.
General feedback: If you have questions about any aspect of this book, email us at [email protected] and mention the book title in the subject of your message.
Errata: Although we have taken every care to ensure the accuracy of our content, mistakes do happen. If you have found a mistake in this book, we would be grateful if you would report this to us. Please visit www.packtpub.com/support/errata and fill in the form.
Piracy: If you come across any illegal copies of our works in any form on the internet, we would be grateful if you would provide us with the location address or website name. Please contact us at [email protected] with a link to the material.
If you are interested in becoming an author: If there is a topic that you have expertise in and you are interested in either writing or contributing to a book, please visit authors.packtpub.com.
Once you've read Operator Training Simulator Handbook, we'd love to hear your thoughts! Please click here to go straight to the Amazon review page for this book and share your feedback.
Your review is important to us and the tech community and will help us make sure we're delivering excellent quality content..
In this section of the book, you will be introduced to Operator Training Simulators (OTSs) and be taken on a journey of how these systems developed over the past 50 years.
Some jargon that is used in the industry is understood differently by different users. In the first chapter, precise definitions will be given that could be used as a standard in the industry.
Finally, the chapter will go through the different classifications of the different types of OTSs.
This section contains the following chapter:
Chapter 1, OTS IntroductionIt 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 OTSWho is this book directed toward?OTS – Multi-Purpose Dynamic Simulator (MPDS) or digital twinOTS jargon and definitionsThe instructor stationOTS typesThird-party representationSome use casesThere 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
