Can you introduce yourself in a few words?
My name is Gregory Rousseau, I’m a Product Owner for 3 years at AVSimulation. I’m in charge of defining the Roadmap, monitoring the progress of developments, while anticipating or listening to the present or future needs of customers. On the other hand, I follow up some projects such as SERKET, for RUAG Défense France which develops a simulator for the DGA and in which we will integrate software interfaces developed by our team.
Can you explain the acronym HIL?
HiL is the acronym for Hardware in the Loop. A HIL device – usually referred to as a HIL bench – consists of operating a physical element (sensor or actuator) in a simulation loop.
Today, all vehicles contain ECUs which are systems defined by inputs and outputs, and which integrate control laws in charge of controlling systems (such as ADAS, air conditioning, lighting systems, etc.).
The concrete example is to be able to test an ECU on a table, before putting it in place on a vehicle. To do this, it is necessary to feed the ECU inputs with virtual measurements (from a simulation loop) and thus see the evolution of its output values. In other words, the ECU will receive information from emulated sensors and will act on actuators, or it will give instructions to other ECUs.
A simple example is the case of a gear lever of a piloted gearbox, operated by a person: a sensor will recover the position of the gearshift, and transmit the information to the ECU (driver’s gear change request). In return, and if the validity conditions are verified, the latter will activate a gear change system. For such a system, the HIL bench can be used to test and validate either the shift sensor and/or the gearbox actuator.
The examples related to ADAS are often more complex, involving different sensors (real or simulated) and a computer that will eventually proceed to the fusion of multi-sensor data to validate the choice of a set point.
Can you also quickly explain MIL, SIL, DIL ?
MiL: Model in the Loop. It is a test model that is not compiled. It does not yet meet all the constraints of use and integration of an embedded software (defined operating frequency, low-level layers, etc.). In other words, it is a bit of a raw product that allows the control law to be developed and the first tests to be carried out: only the algorithm of the embedded system is evaluated.
SiL: Software in the Loop. For this type of test, compiled control laws are used, thus homogeneous to what will be in the ECU. These command laws constitute the embedded software. The rest of the environment, including the hardware part of the embedded software, remains simulated.
DiL: Driver in the Loop. Here, it is a test used when a simulator driven by a driver is in the simulation loop. As soon as a physical person will control something during the simulation, we can talk about DiL.
The objective of this type of bench is to evaluate the reactions of the driver to an event that occurs (display of information, sound emission of a prevention or warning signal, etc.).
Is there an alternative to HiL test benches? How did the engineers do it when these did not exist?
HiL benches can be used to test ECUs (Electronic Control Units) with integrated control laws or sensors. This is entirely related to the emergence of electronics in the automotive field: previously, mechanical tests were sufficient. The automotive industry was much less mature than today.
So car manufacturers designed prototype vehicles and tested them on the track, with a limited number of tests, if only because of the small number of prototypes.
When electronics began to appear, test benches or laboratory tests were conducted as an alternative to HiL benches. The test benches allow to isolate a part of the vehicle to test it in a unitary way by feeding the ECU with virtual data.
What types of problems can HIL test benches solve?
HiL test benches solve several problems.
First, those related to cost: track testing is particularly expensive. HIL test benches represent an initial investment, but they are then inexpensive to maintain, and can be interfaced with different products to be tested or validated. They are therefore very quickly profitable in terms of the savings they allow to make.
In addition, they save a lot of time. For example, if we want to test control laws on a sensor that is not yet developed or under development. The latter, which has not yet been released, can be tested in advance using simulation.
Finally, repeatability problems are avoided. Indeed, it is possible to repeat the same scenario infinitely, without undergoing the variations (human or material) inherent to a real test.
Where in the V-cycle are the HiL benches located?
In the V-cycle, there is first of all, in the design phase, the MiL. This consists of having models that are not yet well structured or capable of being compiled. It is more the quality of the algorithms that is tested at this stage. Little by little, the models will be improved, then industrialized to be compiled in order to be used in SiL, as they are when they are integrated in an ECU.
When we go back up the V-cycle for the test and validation phase, the HIL intervenes, to connect a real system to a simulation loop, in order to test it.
Finally, the ViL will be used to test the vehicle and its sensors in real time, partly powered by a simulated environment.
What are the features that allow SCANeR to be used in a HIL test bench?
We have the RTGateway module which allows to connect SCANeR to a real time target and to retrieve all the information (sensors for example) which transit on the SCANeR network.
On the other hand, at AVSimulation we have developed a vehicle dynamics model, named CALLAS RT, which is also able to run on a real time target, so on a HiL bench.
Today, these are the products that are integrated in the Real Time Targets pack, which allow to use SCANeR connected to a real time target, on which the CALLAS RT vehicle dynamics model can run, in order to interface it with different systems (sensors or actuators). This set constitutes the HIL bench, with SCANeR as a simulation loop.
Can you give us examples of sensors that are integrated in HIL benches and examples of benches that you have built or are working on?
An example of a HIL sensor bench can be designed with a camera.
The principle is to project the SCANeR visual on a screen, which is then filmed with a camera. This camera is installed in a box (a kind of box of about 1 to 2 m3) and adjusted to film the screen. The idea is to emulate a real scene, via the SCANeR visual, and to film it with the camera as if it were installed on a car windshield.
These cameras are able to detect targets (presence of a vehicle, speed, inter-vehicle distance) in order to be used for functions such as ACC (adaptive cruise control).
Connected to a real-time bench itself connected to SCANeR, the camera transmits the detected targets and their speed: this HIL bench becomes a test and validation bench for ADAS functions, thanks to simulation.
Another use of a HIL bench is to use it with a radar. In the same way that we emulate a real-world image via a screen, the idea is to emulate the waves of a radar that are reflected by a real scene: this is done using a radar bench. Powered by a radar sensor model such as the SCANeR L2 radar model, the radar bench can send waves that are then received by a real radar sensor. Using a Doppler echo processing layer, the radar provides the targets it detects to an ADAS system. In a fully looped HIL test bench, the ADAS system is connected to a SCANeR vehicle, and can be tested to validate its operation on scenarios leading to accident situations.
In one of our projects, we worked with our partner Conrad to connect the camera test bench with SCANeR. On the latter, the HiL connection is implemented with a Mobileye camera connected to a real-time target that acquires the video stream and the various information that is sent by the camera.
More recently, with Keysight Technologies and the support of OKTAL SE, we are working on a project to demonstrate the use of an L2 radar in a radar bench application.
A word to finish up?
ViL and HiL are key elements in our SCANeR Roadmap, which is why we have been working for several years to be compatible with a number of real-time target providers such as National Instrument, dSpace, and many others.
The operation of our CALLAS vehicle model as we use it in massive simulation will be the same as when we use it on a real-time target: we are working to converge as best we can towards Digital Continuity.