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.
Figure 2: Emulation controls the INPUT data elements associated with physical points provided the physical connection can be inhibited from updating.
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:
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
About Hallam-ICS
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.