Our printing machines consist primarily of discrete I/O with a small quantity of analog I/O. We ship these machines worldwide, and to reduce startup time and travel we plan to start doing more extensive shop testing. Right now, we test on-machine I/O to some extent. But some I/O cannot be tested easily as it's either field installed or requires actual production for responses to make sense. For those I/O points, is software simulation the answer? Or should we go with hardware simulation by wiring at least some outputs to devices and reading responses at the inputs?
—from July'09 Control Design
ANSWERS
Test Multiple Configurations
To guarantee a robust machine, responses of the control system should be tested for every possible I/O configuration under every process. Doing this with hardware usually means wiring outputs to safety inputs to simulate specific fault or sensor conditions. Unfortunately, even a system with relatively few I/O and processes still will require several man hours, days or even weeks to test all possible conditions. This investment in manpower is usually necessary unless the control system inputs and processes can be simulated fully with software. This requires a powerful simulator that can emulate the real-time machine control application completely and also must provide the user the ability to simulate system inputs and fault conditions during machine operation.
Controller simulators having this full functionality allow the user to simply implement a routine that will run simultaneously and independently of the machine control application, systematically simulating input configurations and fault conditions during different machine operation modes. Such a simulation can run overnight in a lab and test many thousands or even millions of conditions, potentially many more than could be done by a technician over several months. Compared to hardware simulation, this method will save the machine builder the cost of hardware testing equipment and the much-more-significant cost of many man hours. Ultimately, production experience is invaluable for judging the robustness of a machine, but efficient software simulation with a fully capable machine simulator will improve overall quality greatly and reduce time to market.
Jason Goerges
Control and Application Engineer
ACS Motion Control
Weigh Field I/O's Role
The choice between hardware- and software-based simulations comes down to the role the inaccessible field I/O has on the final product. If the field I/O is only partially critical to machine function, it is perfectly acceptable to simulate these scenarios with software implementations, especially if the simulation software can provide a graphic user interface to visualize the running simulation.
However, if the timing and functionality of the I/O is critical to basic machine function or the amount of simulated I/O is too great, it is probably better to implement hardware-based simulations. This should be done with test boxes. These test boxes should use quick disconnection so no hardwiring issues are created on re-install, have their own logic controllers so they can be customized quickly for each application and use flexible I/O solutions to be flexible enough for any type of I/O that would need to be simulated.
Nick Clute
Product Specialist
Turck
Two Ways to Test
There are two options. One option is to make a dedicated controller that emulates the process/field and thus tests the machine. This would be another controller, additional to the one in the machine. This controller could be configured to interact with the same control program running on the machine controller, thereby providing the ability to test the machine for normal and extreme conditions.
The other option is to make a handheld test panel that connects those few points that cannot be connected otherwise. For example, this could be a panel of knobs and switches that supplies the voltages expected by the machine. An operator would need to be trained to provide or simulate the signals from the field as part of the machine test process.
Ben Orchard
Sales Engineer
Opto 22
Don't Confuse Simulation With Validation
I'm a huge fan of simulation for software development, but it seems like they are asking about validating a machine before shipment. I strongly encourage simulation for software development and early testing of the machine without hardware, however, validation before shipment requires actual connection to the I/O points as close to the actual field/optional hardware. I would value switches over a non-hardware simulation. Best would be a simulation in a box with its own I/O to connect into the field connections.
This test system must have sufficient value to be a small project that is tested, managed and documented. To do less can lead to false results and over-reliance on tribal knowledge.
This is a complex issue that must be managed dependent on the company's culture, expertise and known problems with current procedures. Documentation on actual problems encountered can lead to the low-hanging fruit such as simple wiring checks or automated cable checking.
Ken Hill
Senior Software Engineer
Strasbaugh
Mimic to Save Time
Use desktop and real-time simulation to perform system-level design and testing before final validation on the actual machine.
Develop a system model in Simulink that captures the dynamic behavior of the printing machine, the control system and I/O. Use this system model to run desktop simulations. This lets you begin testing very early in your development schedule. You can validate requirements, identify and correct integration issues and gain a better understanding of the machine before you get into detailed design and before committing to controls and I/O hardware. Then you can use these system models to thoroughly test the system by simulating conditions that would be difficult or dangerous to do in the field.
Desktop simulation can transition to real-time simulation. Using the model to generate C-code lets you develop system and controller models that can run on a real-time prototyping system that mimics the system and I/O behavior. This gives you a couple of options for additional testing. You can create a real-time prototype controller that can be used to verify your control strategy before committing to the controller architecture. Also, it lets you test controller hardware against a real-time simulation that mimics the physical behavior of the system including the synchronization aspects of the design. This alone can save a great deal of time and prevent damage to capital equipment from a faulty control strategy.
Tony Lennon
Industry Marketing Manager
The MathWorks
Hardware in the Loop
What you're looking for is commonly referred to as "hardware in the loop," or HIL. Using HIL, the machine is replaced by a plant model that acts like the actual machine, but without any sensor and actuator hardware. Instead, software is generated that models the relationship between actuators and sensors to simulate machine behavior. Outputs of the machine controller are connected to actuator inputs of the HIL simulator, and outputs of the HIL simulator are connected to sensor inputs of the machine controller.
That connection can be done in two ways. The HIL simulation can run on the machine controller, and the connections are virtual, meaning no I/O points are connected. The other method is to have the HIL simulation running on its own controller with its I/Os connected to the machine controller I/Os. The second method has the advantage that the machine controller has the same processor load and timing behavior, whether it is connected to the HIL simulator or the real machine.
Customers in Our industry traditionally insisted on multiple-light, audible-horn, annunciator-type panels for alarming and operator notification. We want to move forward with up-to-date HMI touchscreens and to incorporate alarming and important operating notifications there. We'd like this to be part of the normal HMI configuration with screens that look as much like the old annunciator boards as possible. What are some possibilities?
SEND US YOUR COMMENTS, SUGGESTIONS OR SOLUTIONS FOR THIS PROBLEM. We'll include it in the November '09 issue, and post it on ControlDesign.com. Send visuals if you'd like—a sketch is fine. Email us at [email protected]. Please include your company, location and title in the response.HAVE A PROBLEM YOU'D LIKE TO POSE to the readers? Send it along, too.
Code for the HIL can be written directly in the programming environment for the machine controller, often using IEC 61131-3 programming languages. But for complex machines, more sophisticated models might be necessary to achieve proper simulation results. In this case, a modeling software package such as Simulink can be used where models can be developed using extensive libraries of pre-existing simulation blocks. Sequential operations can be created within Simulink using state flow, a basic flowchart-like programming method to simulate sequential operations and processes.To get the machine simulation to run on the control in real time, B&R has its Automation Studio Target for Simulink. With this tool, it is possible to automatically generate code out of Simulink into Automation Studio, which then can be transferred to the controller. Complex HIL simulations can be developed in proven and powerful simulation environments like Simulink and seamlessly integrated and executed within the controller for fast and real simulation results.
Robert Muehlfellner
Director, Automation Technology
B&R Industrial Automation
Shop-Tested Results
We wrestle with that dilemma on every skid or equipment assembly we build. You must keep in mind a few important points.
- Anything that can be shop-tested, should be. That always should be the rule. This is where all your resources, tools, part suppliers, design staff, drawings, specs and shop test equipment are close by.
- All P&ID components should be correct and in the correct order, I/O should be checked, and all pressure tests and electrical communication tests should be complete.
- We understand that not everything can be shop-tested, but getting qualitative tests instead of final commissioning detail results always will be helpful when the assembly gets onsite for installation. It will reduce site install commissioning time drastically the if all the pre-checks can occur at the shop.
- Even if a client needs to provide input signals to you, you should still try to simulate something. For example, if your equipment reacts to a pressure increase--your assembly might close down a valve, open a vent, initiate an alarm-- simulate it by gradually opening up a water line or compressed air line and watch your newly assembled equipment react. Again, a qualitative test at the least.
- We have found that the most effective tests are when the actual software is used to communicate with electrical hardware, which then runs the mechanical equipment. This way, a complete line of SW/HW communication is intact and running the equipment before it is shipped to the installation site.
Mark Haboian
Senior Program Manager
Optimation
Amortize Your Simulation
This is a typical question that comes up with any SI doing a real simulation in the shop.
It appears the person asking the question is a machine builder and might be simulating some standard product offering. In this case, I would do software simulation of the questionable I/O. The cost of this simulation can be amortized over some quantity of machines that also need this simulation. If these are all custom machines, they would need a custom simulation that could be cost-prohibitive, but would pay for itself in security of operations.
Duane Grob
VP of engineering, TSD Division
Optimation
Experience Counts
Back in the '90s, as a controls engineer for a system integrator, I once had to build an I/O mechanism to test a large control system that was to be used in manufacturing a popular hair-growth product. Company policy was to use hardware simulation, so I spent days wiring several boards of relays, lights and potentiometers. I also spent a long night troubleshooting the hardware when the system shorted and popped circuit breakers the day before the customer visit.
As a result of my experiences, I can honestly say that I prefer to do as much with software simulation as I can. This is an option that has become more plausible in the past few years as the number of software tools capable of I/O simulation have proliferated. Bosch Rexroth, for instance, includes a PLC simulator as a standard feature in the IndraWorks programming suite to test a program without even the necessity of a PLC. Included is a built-in HMI so that a programmer can design a simulator with slides, switches and displays——much faster than wiring hardware, less expensive than paying someone to wire and troubleshoot a physical system and easier to modify. Many automation vendors include some functionality for controlling digital and analog I/O by forcing values; this functionality should be examined before going to any further expense.
Regardless of the method you use to do I/O testing, make sure you have someone, or several someones, test your system for you. Having someone who doesn't know how the system is supposed to work flip switches, virtual or otherwise, is the best way of ensuring that your routines and fault handling are as bulletproof as possible.
Ted Thayer
Automation Systems Product Manager
Bosch Rexroth
