Hardware-in-the-loop simulation

Hardware-in-the-loop simulation has two ingredients:

1. the simulation has to be synchronized to real time;
2. there has to be a way the simulation can communicate with the real world: it has to be able to receive external events, and possibly also to send events out of the simulation.

The implementation of external communication in (2) can be very different from one simulation scenario to another. It can be as simple as TCP sockets (as here) or pipes, it can be raw communication on an Ethernet NIC or an USB port, or communication with a interface card via interrupts and DMA transfer. If you plan to do hardware-in-the-loop simulation, you'll most likely have to implement your own external communication interface.

The implementation is based on real-time simulation, but there is an important difference: during waiting, the scheduler has to stay tuned and watch if something of importance arrives on the external communication interface. If it does, it immediately has to be converted into a simulation event, and injected into the simulation model with a simulation time that corresponds to the real time in that moment. The scheduler of course has to have a built-in knowledge of how to convert external events into simulation messages, and to which module the event has to be delivered.

Outbound communication does not necessarily have to go through the scheduler object, but because inbound and outbound communications are often not independent (e.g. they may be implemented as send and receive operations on the same socket), it is often practical to do both via the scheduler.

Home