The emulation of process control system code is utilized to verify and demonstrate PLC, SCADA and HMI code prior to site installation and commissioning. The benefits of process emulation within the office or shop environment are numerous and typically include a reduction in overall project execution time.
Process emulation not only proves the code as designed, it provides an opportunity for operations to work with the system prior to installation to ensure it was designed as it needs to be operated. It provides a platform for operator training off-line.In conjunction with the business enterprise systems, emulation can be used to prove data transfers and execution of MES and business system integration to the automation system.
Figure 1: Emulation code can be executed in a PLC simulator or in a PLC test chassis.
In most cases of PLC control, the physical IO connection of field devices can be disabled within the processor configuration allowing the IO tag data areas to be manipulated by a set of emulation programs. Since SCADA and HMI code is executed on data references that are linked via a communication path to the PLC tags, it is possible to implement the emulation code in the PLC alone. SCADA and HMI code can be used as it will be deployed. Additionally, since we are emulating the physical IO connections with virtual IO, the PLC process code can also be utilized as it will be deployed.
Since the main purpose of emulation is to prove the final code, separation of emulation code from process code is important. In PLC’s such as Rockwell Automation Logix, the emulation code can be developed under a separate program or routine which can be imported as a block into the program structure and removed in its entirety without modification to the process code. GAMP guidelines state that simulation is an allowable tool for system testing provided application code is frozen and “dead code” removed prior to testing. Separation of emulation code is important in meeting these requirements.
Figure 3: Emulation code should be all contained in a separate program so it can be easily exported, imported and removed from the delivered project.
Emulation code in its simplest form, mimics normal equipment functions. Some basic examples are as follows:
- When an output is energized to open a valve, the valve open limit switch input tag is activated.
- When an output is energized to start a motor via contactor, the motor running auxiliary contact input tag is activated.
- When a VFD is activated, the status, direction status, motor amps and motor speed feedback tags are emulated based on the control values.
- When an inlet valve to a tank opens, the tank level or tank weight increases.
- When a PID loop output to heat a tank increases, the temperature increases.
- The off, closed, stopped and decreasing states are all emulated as well.
- When all equipment that can be controlled by the processes is properly emulated, the equipment should be able to be controlled without faulting. Process code used to move product or to control processes should execute and stabilize the process variable to setpoint. Sequences should progress from start to end without manually forcing states. From the SCADA or HMI point of view, the operator should feel as if they are executing a real process.
Figure 4: Controls all inputs necessary for the system to execute the processes to be tested. This may include valves, motors, scales, level switches and communications to other controllers.
In most cases, testing of control code functionality does not require an exact replication of real world reactions and timing. In fact, for rapid testing of multiple scenarios, it is preferable that processes complete much faster than in the real world. Tanks should fill, reach temperature and empty much faster than real world situations. This allows for rapid replay for debug and for testing a slew of rare event scenarios that would not fit within the commissioning time window allocated at start-up. Emulation also allows testing without the use of product which may need to be scrapped.
Figure 5: The emulation code can be used to decrease the duration for programmed process timers to speed up the testing of sequences.
There will be some effort required to debug emulation code to get all functions executing properly but with experience, this effort becomes minimized. There are best practices in PLC code development that when used, simplify emulation implementation and execution. Coding practices such as mapping physical IO points to equipment tag data structures in a separate routine from the process control code module that executes on those equipment IO states is one example.
Following testing of normal process operation, the emulation code can then be used to test a variety of abnormal circumstances by disabling or manipulating the emulation code for various devices. Valves can be forced to fail. High alarm and low alarm level points can be tripped. Tanks, hoppers or weigh scales can fail to reach setpoint levels. Upset conditions, critical alarm and emergency stop scenarios can be tested. With operator interaction at the SCADA or HMI, recovery scenarios can be tested and optimized. After the system is operational on site, new recipes or control strategies can be tested prior to modifying live code.
Figure 6: While emulation code is executing, the SCADA or HMI should be able to run the application without modification. Manual and automatic operations, sequences and displays can then be verified prior to site commissioning.
System emulation can be an extremely effective way to manage risk by testing out changes in an offline environment instead of on the plant floor. Offline emulation testing and debug will provide an ROI in time/cost savings and perhaps more importantly, credibility and trust. Plant personnel should not have to wait for basic code debug during start-up. There will always be some equipment and real world issues to work out after installation on site but with a thorough emulation testing procedure, many design misinterpretations and coding errors can be corrected prior to site commissioning and initial production runs. When operators are brought in to test run the emulation system, operator driven improvements can be discussed, implemented and tested prior to deployment. Emulation testing and training reduces commissioning time, last minute changes and operational errors.
For more information please reach out to Allan directly at astier@Hallam-ICS.com or via
About the author
Allan Stier is the Vermont Controls Engineering Manager for Hallam-ICS. He has been designing, installing and programming control systems since 1986.
Read My Hallam Story
Hallam-ICS is an engineering and automation company that designs MEP systems for facilities and plants, engineers control and automation solutions, and ensures safety and regulatory compliance through arc flash studies, commissioning, and validation. Our offices are located in Massachusetts, Connecticut, New York, Vermont and North Carolina and our projects take us world-wide.