A common problem for some of our customers is that when their products malfunction due to a software bug, solving the issue can be very complicated. Often, the product, e.g. an industrial machine, cargo ship or similar, could be deployed at a site anywhere in the world. The company sends a “superengineer”, to locate the error and fix it – this takes time and resources, often at a high cost. Is there no better solution?
Well, one way could be to develop a Hardware-In-the-Loop (HIL) simulator. In a HIL simulator, the code is run on the target, e.g. a PLC, in realtime. Since the code is running in exactly the same way as in a real machine, it expects to receive data from sensors and to send data to actuators (most likely with actuator feedback as well). If the machine hardware is not available, all sensors and actuators need to be modeled in a plant model. This plant model could also include a graphical interpretation of the machine, which allows the operator to see what happens in the same way as when observing the real machine. The plant model is then deployed to a realtime system, containing a machine with appropriate IO modules, which communicates with the target. If machine hardware is available, it is possible to interface this as well.
In the HIL simulator, the virtual machine can be configured to run with the exact same settings as when the failure occurred in the real machine. If the machine is modeled properly, the failure will be detected in the simulation and the bug can be fixed. The software update can then be sent to the customer, without ever having had access to the machine. The superengineer is happy, since he or she can focus on delivering the best solution. The machine site is happy, since they can get up and running quicker. The company is happy, since they save money and resources.
How to model the machine depends on how it is being used. For example:
- Is the production code autogenerated, e.g. from MATLAB/Simulink, or developed directly in the target environment?
- How complex is the plant process? What level of detail does the model require?
- How many, and what type of, IO signals are needed?
When using MATLAB/Simulink, two popular options are Speedgoat and dSPACE. Speedgoat is specifically developed to integrate seamlessly with Simulink Real-Time and xPC Target in real-time testing. The systems from dSPACE are modular with a wide range of IO options, suitable for real-time simulation. Both systems are easy to use with MATLAB/Simulink and the benefits with each systems should be evaluated on a case-to-case basis.
If MATLAB/Simulink is not being used or if the code is developed in the target environment, e.g. implementing structured text in a PLC vendor system, another option is for example the systems from National Instrument. National Instrument does support MATLAB/Simulink, as well as other common languages and environments, but these systems are mainly intended to use LabVIEW. LabVIEW is an integrated development environment using graphical programming , which also supports creating user interfaces and instrument control.
The scenario described above is also applicable when the machine is not readily available due to testing costs and/or time allocation. The HIL simulator also allows for faster and more extensive testing. For example, it is possible to skip certain machine steps that are not relevant, which saves time, or to simulate settings that would potentially be of risk to the operator when performad in the machine.
If you have any questions on HIL solutions, or for more information on how Combine can help your company, please contact us.