Processes 1 and 2 Case A:
3.5 Development of Operator Training Simulator (OTS) for Biodiesel Process 1
Figure 3.11 shows the methodology followed in the OTS development. OTS uses the optimal parameters and the PWC structure found the earlier sections. In principle, the OTS consists of a computer system which includes one or more trainee station(s), one field operator station, and one instructor station, as described in Section 1. The centre of the OTS workstation will be the instructor station that functions as simulator engine, and instructor tools that interconnects with other work stations namely operator station and field operator station.
121
Figure 3.11 Flowchart on the general framework of the OTS.
Simulator model will be loaded from the instructor station and transmitted to both operator and field operator stations. DCS can be emulated, stimulated or partially stimulated that acts as a human machine interface (HMI) and is made available on the operator station with the mentioned simulator model to convey similar information, features, and functionalities as of the actual DCS system.
Graphical representations of the field operated device such as block valve, local panel, etc is located on the filed operator station to provide the interface in operating the said devices which commonly cannot be operated from control room or DCS.
However, in the absence of actual/emulated/stimulated/partially stimulated DCS, a standalone OTS is investigated in this study, where instructor station and operator station is the same. This is the simplest and cheapest mode of OTS; however, it is
Develop a dynamic OTS using APD
Verification and implementation of
OTS
Project Completion
Create several emergency, startup, safety scenarios in APD
122
probably the least effective among all other modes. The scope of this study is to show applicability of APD in OTS development for the complex biodiesel process for varieties of scenarios, which is the core of OTS. Therefore, HMI development for instructor or operator is not focused on in this study.
There are 3 main steps before using Aspen OTS Framework. Firstly, the process is simulated in Aspen Plus. Secondly, suitable control strategy is employed in APD. Thirdly, each training scenario is created in APD by writing the tasks. It is then accessed through Aspen OTS framework, which enables a large dynamic simulation to run in real time using parallel processing and also enables the various components of OTS to link to the simulation via OPC. It is possible to split the simulation into smaller partitions, each with its own integration step size and running in parallel on a different CPU/core, which helps simulation to run in real time as well as at increased speed. Aspen OTS framework can be used to identify the name and location of the partitions, make stream and control signal connections, publish tags, launch simulation cases, run and synchronize the partitions, exchange stream data between them, and display simulation variables and commands via OPC (Aspen OTS Framework: Help: Aspen Technology: Cambridge, MA).
Figure 3.12 shows the snapshot of the developed OTS. Controller faceplates are arranged so that all individual controllers can be monitored simultaneously.
Controller modes, transient profiles (i.e. historian), controller tuning, CV-MV limits can be accessed through the respective faceplate. Other variables can be seen from
‘Process Flowsheet Window’ (Figure 3.12). Training scenarios can be (de)activated
123
through ‘Contents of Flowsheet’ window in Figure 3.12; ‘Simulation Messages’
window shows simulation status.
Figure 3.12 Snapshot of the developed OTS.
In OTS, a dynamic simulation is typically synchronized to run in real time.
The simulation is a replica of a plant continuously generating time series data, responding to operator actions, instructor initiated upsets and DCS actions (if external controls are being used). The simulations for operator training are mostly very detailed containing all equipment items in the plant including items not normally included in an engineering study model (such as instruments and spare pumps). Consequently, these simulations are very large and include operations having fast dynamics and slow dynamics as well, e.g. compressors (fast dynamics) and distillation columns (slow dynamics). The integration size must be small catering
124
to the fast dynamics for accuracy. Running such a simulation on a single processor can lead to mismatch between simulation time and real time due to the limited capability of a single processor. A suitable OTS framework must be able to cope with this by some means. Using Aspen OTS Framework, it is possible to split the simulation into smaller partitions, each with its own integration step size, and each running in parallel on a different CPU/core.
The Aspen OTS Framework enables users to configure the partitions, and it manages the synchronization and data exchange among the partitions during runtime.
However, it is essential to tear the streams downstream of a valve. The torn stream results in a product stream with a fixed boundary pressure in the source partition and a feed stream with a fixed flow, temperature and composition in the destination partition. The method of partitioning is illustrated in the following example (Figure 3.13), taken from Aspen OTS Framework’s help (Aspen Technology, 2013). In Figure 3.13, stream 2 is cut resulting in two partitions of roughly the same size. The resulting flow sheet on the left hand side will have a product stream 2 with pressure specified. On the right hand side of the flow sheet, feed stream 2 will have flow rate, temperature and composition (and not pressure) specified. Because of the pressure/flow network, it is necessary to ensure that both the partitioned simulations are synchronized in time, with connecting stream variables updated as frequently as possible, e.g. every integration step.
125
Figure 3.13 Partitioning of the process flow sheet.
The breaking of a stream (e.g. ‘2’ in the above example into product stream 2 and feed stream 2) will result in the downstream variables: flow (F), temperature (T) and composition (z*) lagging behind the corresponding upstream values by one integration time step, and the upstream pressure lagging behind the downstream pressure (P). Even this small lag may result in unstable oscillations. These oscillations can be eliminated if the flow copied to the downstream partition is updated using the flow/pressure derivative as;
𝐹𝑑𝑜𝑤𝑛 = 𝐹𝑢𝑝 +𝜕𝑓𝜕𝑃(𝑃𝑢𝑝− 𝑃𝑑𝑜𝑤𝑛)
(3.15)
𝜕𝑓
𝜕𝑡 is calculated by the upstream valve using differential pressure flow equation:
𝑓 = 𝐶𝑣√∆𝑃
(3.16)
126
𝜕𝑓
𝜕𝑡 =12√∆𝑃𝐶𝑣
(3.17)
Substituting 𝐶𝑣 in Eq. (3.17):
𝜕𝑓
𝜕𝑡 =12∆𝑃𝐹
(3.18)
𝜕𝑓
𝜕𝑡 is calculated from the upstream valve using Eq. 3.18. The pressure drop of the source partition’s upstream valve is used to calculate the flow/pressure derivative for each connecting stream ensuring the stability of the pressure/flow network. The partition must be done immediately downstream of a valve as the Aspen OTS Framework uses the valve in the source partition to calculate the stream’s pressure-flow derivative.
Setting simulation speed, pause, resume etc can be done using Aspen OTS Framework. Figures 3.14, 3.15, 3.16 show the snapshots of OTS with flowsheet partitioned. Right bottom section, left section and right top section show esterification section, transesterification section and OTS Framework, respectively.
In Figure 3.14, two partitions, namely ‘OTS_Data_Fire_PSV_bypass_Burst _Utility_part_1’ (i.e. esterification section) and ‘OTS_Data_Fire_PSV_bypass_Burst _Utility_part_2’ (i.e. transesterification section) are synchronized using Aspen OTS Framework (see highlighted part in Figure 3.14). In Figure 3.15, output of first partition (i.e. esterification section) ‘str1’ is connected with second partition (i.e.
transesterification section) ‘str2’ (see highlighted part in Figure 3.15) to be synchronized. All required variables can be tagged to be able to monitor them and publish them (for example, see highlighted part in Figure 3.16). Step size for either/both partition(s) can also be changed according to the fast or slow dynamics.
127
As shown in these Figures, OTS speed can be enhanced or reduced by changing
‘Real time factor’. Also, data transfer rate can be increased or decreased by changing
‘Data transfer interval’ (see highlighted part in Figure 3.14). Figure 3.17 shows interface for a complete process in APD.
The scenarios for which OTS training is to be carried out should created in APD by writing the ‘Task’. An example of task writing is depicted for startup of FRAC-3, in the Appendix C. The results are discussed in Section 4.5. The scenario, written as a ‘Task’, has to be first compiled and then activated. When OTS is run, the scenario plays out at the time specified while creating the scenario in the ‘Task’.
Alternatively, direct change can be made into the simulation to impart some faults.
Several scenarios, such as equipment malfunctions, fire, pressure safety valves, bursting disks, interlocks and startup-shutdowns etc, can be created and tested using this OTS. These are described in section 4.4.
128
Figure 3.14 Snapshot of the developed OTS with flowsheet partitioned (Two partitions are synchronized).
129
Figure 3.15 Snapshot of the developed OTS with flowsheet partitioned (Streams of two partitions are connected).
130
Figure 3.16 Snapshot of the developed OTS with flowsheet partitioned (Few tags are published).
131
Figure 3.17 Complete process interface in APD.
132