01 September 2003
Impact on the bottom line
This control engineer learned from painful experience to plan ahead!
By Marco Rodriguez
PLC simulation has come a long way since the days when simulation took place via hardwiring potentiometers, push buttons, indicators, sliders, and forcing I/O in the programmable logic controller (PLC) data table.
Today, virtual factories running on Intel-powered PCs provide plant models that enable the control engineer to validate controller software before site commissioning.
Simulation models allow the substitution of real I/O with simulated I/O without changing tag names in the controller. In addition to instrument equipment, chemical process dynamics can add to the virtual factory models.
Having a process model and virtual process transducers allows one to test exception handling capabilities and robustness of the controller code. Moreover, testing controller to controller handshaking and supervisory control and data acquisition (SCADA) communications is possible. Human errors can be a part of the simulated process to verify the safe operation of the plant.
There is a myriad of trades asking for verified and validated software prior to plant start-up: government agencies, commissioning personnel, process engineers, operators, plant managers, and control system integrators, among others.
In the pursuit of time reduction, it is essential that developing simulation models becomes part of the overall software development plan.
Simulation models must develop in parallel with software.
Simulation models must be fine-tuned and revisited at different points of the software generation to reflect design and functionality changes.
Simulation lowers factory acceptance cost and will result in faster software commissioning and engineering cost savings.
How hard could programming be
I remember the first time I had to write PLC software for the control of a milling machine. I would develop the PLC code in a software programming style called ladder logic. How hard could it be?
I had a degree in computer engineering and plenty of experience writing code in FORTRAN, Turbo Pascal, and C++.
My application consisted of an induction motor driven by a variable frequency drive, an operator interface (OI) display, and a few temperature elements. The PLC would command the start and stop of the motor and provide reference velocity.
The operator interface would display milling chamber temperature, batch timer, speed set point and actual, a few alarms, and two push buttons to start and stop the process.
The PLC processor would be the process variable server to a data historian—the perfect assignment for a new control engineer. The first pass of the PLC and OI software took me about one week.
Then I waited for the equipment installation and all the wire terminations. I was confident that it would take me no more than one day to load the software on the PLC and operator interface and commission the whole code.
It took me two weeks to get the PLC and OI programs running. I spent my days walking from the control room to the milling machine station trying to figure out why the motor would not start or stop when requested, and why the information on the operator interface was consistently wrong.
Further, I was constantly explaining to the customer why the start-up was taking so long and the delays kept coming. Obviously, I could have done a better job preventing software bugs.
Since then, I have been an ardent supporter of software simulation and testing prior to commissioning and start-up.
Enterprise and manufacturing networks
So, what's to simulate?
In addition to instrument equipment, chemical process dynamics can be a part of the virtual factory models. First and second order chemical processes, dead times, heat losses, material flows, mass balances, process upsets, and signal noise can also incorporate into the plant model.
Proportional, integral, derivative (PID) control algorithm actions can tune into the controller to respond to the plant dynamics. One can also program complex control algorithms into the controller.
A process model and virtual process transducers allow testing of exception handling capabilities and robustness of the controller code. In addition, controller to controller handshaking and SCADA communications can undergo testing.
One can introduce human errors to the simulated process to verify the safe operation of the plant. Equipment failures such as faulty valve limit switches, open transducers, and calibration errors are built into the equipment models to test the safety of the process.
E-stops and controller faults can also be evaluated to ensure that the system can be brought to a safe state after the event.
Controller/OI software development process
Everybody is asking for it
With the increased complexity of batch processing algorithms and the increased pressure from government agencies to reduce accident incidents and hazardous spills, off-line simulation and testing have become essential tasks during development of controller software.
There are many trades asking for verified and validated software before plant start-up.
Government agencies: Safety regulations regarding personnel injury and environmental releases compel companies to ensure the safety of the process.
Plant simulation reduces the chances of equipment damage and personnel harm. Simulation also reduces the production of hazardous wastes during plant start-up.
Commissioning personnel: Making software simulation part of software development activities will dramatically reduce on-site software debug time. In most cases, fully debugging the program prior to software deployment will take the software out of the pool of assignable causes when problems arise.
One can test functionality such as alarms, trending, OI graphic displays, recipe downloading, and report generation beforehand.
Process engineers: Anything that can expedite the factory acceptance test (FAT) phase of the project is welcome. Well-simulated process dynamics will reduce time required for parameter tuning.
Recipe management, batch tracking, and reporting can undergo evaluation well before the plant goes live. Simulation programs can also be useful after the project is over to test new operation sequences.
Process problems can double up off-line using the simulation models. Changes to the program logic can receive consideration and evaluation before they go online, and one can validate SCADA and historical databases using simulated data.
Operators: Plant simulation provides the perfect tool for training operators. Operators can practice standard operating procedures prior to equipment start-up. Operators can undergo certification even before they have contact with the process area.
Furthermore, operators will gain a sense of ownership of the system before the plant is in place. Nuisance alarms that might sabotage an operator's confidence in the system can be less of a disturbance. After start-up, the company can recycle simulation models in a lab setting for re-certification and training new operators.
Plant managers: Anything that can reduce debug time and speed up start-up will always receive a warm welcome and a big hug.
Control system integrators: In addition to all the benefits mentioned above, one added benefit of generating simulation models is the potential of creating libraries of reusable models for future projects.
What is the bottom line?
Time and money are always in the mind of management. Nowadays, the pressures of cost and time reductions resonate with and inside engineering organizations and system integrators.
Return on investment (ROI) is a closely monitored statistic these days. The faster a plant is up and running, the faster the capital investment pays off.
To reduce time, the development of simulation models must become part of the overall software development plan. Simulation models must develop in parallel with and at the same time as the software.
One must revisit and fine-tune simulation models at different times in the software generation to include design and functionality changes. Time invested in the development and utilization of simulation software will pay multiple times in savings during commissioning.
Control software bug fixing shall not be the main objective of the commissioning team. Having all major software bugs fixed ahead of time will free commissioning personnel to work on mechanical, wiring, calibration, power distribution, and training issues.
There is a direct correlation between the time duration and the budgetary cost of a project. The longer the project runs, the more it costs.
Engineering organizations and control integrators that do not invest in making sure that their software is free of preventable bugs are destined to longer debug times.
They also risk damaging the equipment and, more importantly, putting operators in danger. Simulation lowers factory acceptance cost and will result in faster software commissioning and engineering cost savings. AIT
Behind the byline
Marco Rodriguez has a master's degree in electrical engineering and a bachelor's degree in computer engineering. He is a senior engineer at Corning Incorporated and a registered professional engineer in the state of N.Y. He is also an ISA member. Write him at RodrigueMA@Corning.com.