In 2010, TSC won a bid to create a Multi-Purpose Dynamic Simulator (MPDS) of a new nuclear reprocessing asset, which was in the design phase. The requirement was for DCS checkout, sequence design and checkout, and then evolve into an Operator Training Simulator (OTS) for use on site.
Although the process plant itself was relatively simple, it was critical to make sure it would operate correctly, as most of the process would be radioactive and inaccessible to humans once the processing activity started. An added modelling complexity was that at normal processing capacity, the bulk stores of highly active liquor (HAL) generated >200kW of heat from radioactive decay; this had to be modelled accurately. The process was semi-batch, and included complex process flows where some lines were used for steam, water and air at distinct stages of the batch process.
The DCS selected was new to TSC, but as this project was to be entirely stimulated (directly connected to the control system) rather than emulated, no emulation work was required.
The build started with an extensive kick off meeting that discussed detailed modelling scope, project timeline and phases, progress reporting, technical and commercial points of contact. Project control, documentation, and TQ procedures were established. There was a chain of two subcontractors (EPC and nuclear consultants) between us and the client, which added some project control complexity.
Initially, TSC built the dynamic mathematical model using our in-house software (SimCreate) with a generic UI as the MAC had not completed build of the DCS. We also built our own version of the control system using the design data for the DCS. This was used to check the feasibility of the control philosophy and batch sequence design. Some dynamic issues were found which resulted in feedback to the consultants and EPC, which resulted in important changes to the control philosophy, saving significant time and cost later in the build process.
Once the MAC had completed testing of the DCS, they delivered a version of the DCS on a set of physical servers to TSC. The mathematical model was linked to the DCS via OPC. This required a complete I/O match, with dummy and status values added for stimulation of the DCS where modelling was out of scope. We also added a switching and reset mechanism into the model so that the either the TSC control system or DCS could be used, and DCS could be switched into saved states representing different parts of the semi-batch process.
The DCS checkout part of the process revealed some issues where the DCS build had not respected the design, for instance around fail-open states. This had not been revealed in MAC testing as their basic simulator had been built with the same errors. Discovering this early also saved commissioning time and expense.
Following the DCS checkout and some modifications by the MAC, the DCS copy at TSC was updated and the model relinked. The complete system was then delivered to site to be used by the commissioning engineers and as an OTS. This happened well in advance of build completion and enabled training to be conducted well before the live asset was commissioned.
The initial build and connection took around 6 months. Once the DCS update was delivered, the conversion to OTS took a further 6 weeks. There were multiple updates to the system during the build and commissioning phases between 2011 and 2016.
The project resulted in several key benefits:
