Hardware-in-the-Loop (HIL) simulation – also referred to as emulation – becomes increasingly important to ensure high software quality and short development cycles for complex automation solutions. In the funded research project OMSIS Dresden University of Technology and INCONTROL Simulation Solutions cooperated to strengthen the ENTERPRISE DYNAMICS software for HIL simulation.

Traditionally, when building complex mechatronic systems, software engineering is the last step during the development cycle that can take place not before the mechanical parts of the facility have been assembled. Significant parts of the software engineering process are typically carried out during the commissioning phase of the production ramp-up, leading to a loss of time and quality. An approach that is referred to as Hardware-in-the-Loop (HIL) simulation tries to overcome this situation: By emulating the mimics of the yet to build automation hardware, engineering and validation of the control software or the HMI (Human-Machine Interface) can take place much earlier, which allows for higher quality and shorter product development cycles. Furthermore, any inadvertences whilst programming do not risk the facility or personnel to take damage.

In order to successfully adopt this approach, an efficient I/O coupling between simulation and real time controller has to be established which transfers (virtual) sensor values to the controller on the one hand and accepts control values for the (virtual) actuators on the other hand. Typically, there are several hundred of signals to be exchanged within milliseconds. This seems to be rather intricate with respect to cabling at first glance. However, the widely-used structure of most modern automation installations allows an elegant solution: The I/O modules that operate sensors and actuators are usually installed very close to the mechanical components (or are even integrated); data communication with the Programmable Logic Controller (PLC) is realized via PROFIBUS DP (Decentralized Peripherals) – a standardized and very wide-spread field bus solution.

Now, when operating a simulation instead of the real plant, it makes sense to use the PROFIBUS as an interface to the virtual plant, instead of “cutting” hundreds of I/O lines. This can be achieved by so called multi-slave emulation: The emulation hardware (i. e. a PCI card) replaces multiple DP slaves and provides access to all input and output variables via a software API, while the PLC does not notice any difference. The most prevalent multi-slave emulation solution is SIMBApro, which is, although being a Siemens product, not limited to Siemens hardware, but can be used with any PROFIBUS compatible controller and DP slave.
 
In order to use ENTERPRISE DYNAMICS for the factory simulation part, an interface to the SIMBApro suite has been created within the OMSIS project. From a user’s point of view, this interface consists of three new atoms in the library tree of ENTERPRISE DYNAMICS: the SimbaProCtrl atom, which is meant to be used exactly once per model, covers global settings for the HIL simulation, such as the set of DP slaves to emulate or the update rate for all I/O variables. The FromPlc atom represents a PLC output, which is an input on the model side and can be, for instance, used to control a conveyor drive. The atom allows 4DScript commands to be executed whenever the related PLC signal changes, thus the user has full freedom in defining how the signal impacts on the model. The ToPlc atom, on the other hand, represents a PLC input coming from a (virtual) sensor in the model, like a light barrier. This atom is meant to be attached to the model element that provides the sensing value. Again, a 4DScript command can be used to describe how exactly the output value is to be evaluated from the model. In addition the user can adjust one of the predefined settings in the atom’s GUI like the number of contained sub-items in the attached element or its status (idle, busy, empty, full, conveying, etc.).

In order to validate the HIL interface, the teaching model shown in Figure 4 was built in ENTERPRISE DYNAMICS. The model consists of a U-shaped one-way conveyor line with two machines attached, and a handling robot that picks processed workpieces and places them onto the foremost conveyor. 24 digital outputs from the PLC control the robot axes, conveyors as well as machine operations. 21 digital inputs provide the states from light barriers, limit switches and front panel control buttons. In ENTERPRISE DYNAMICS the whole system was built based on several atoms that represent mechanical entities like a single conveyor module or a machine. All atoms process the same input signals and provide the same outputs as the mechanical model. Furthermore, all entities were programmed in order to report a message whenever they would have taken damage in the “real” world, e. g. workpieces that were dropped on the floor or the robot being driven beyond the limit of one of its movement axes. Thus, it was possible to completely develop and test the controlling PLC application in combination with the virtual model and afterwards instantly switch to the physical model without any more effort than removing the PROFIBUS cable form the simulation PC and plugging it into the PROFIBUS-DP I/O modules.

Experiments with the described model have shown that ENTERPRISE DYNAMICS is capable of being used in HIL scenarios. Performance tests have also shown that the number of I/O signals used in the presented example is by no means an upper limit, thus projects with a “real-life” amount of I/O signals can be realized. However, the experiments also revealed that HIL simulation requires a complete new set of library atoms that actually have to be far less smart than their counterparts already existing in the ENTERPRISE DYNAMICS logistics library. All transport, handling or processing atoms must not start their work event driven, following a preconfigured strategy, whenever a workpiece is entering. The atoms have to receive all their commands from the PLC, even if these commands make no sense and would – in reality – damage the installation. Although creating these new atoms means significant work, it pays off rapidly as automation businesses typically equip many different facilities with similar mechanical components, i. e. handling technology, and can reuse these atoms in every new project.