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:
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:
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:
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.