HiL (Hardware in the Loop)

Meta-Information

Origin: Wolfgang Herzner / AIT, David Gonzalez-Arjona / GMV

Written: April 2019

Purpose: Testing the target SUT (hard- and software) in a real-time hardware simulation environment for assessing its correct operation in a closed-loop setting under situations that are perhaps too risky or too rare in reality.

Context/Pre-Conditions:
– The simulation hardware must provide all relevant stimuli in real-time.
– Interface of SUT and HiL hardware required.

To consider: Developing the HiL hardware is expensive and requires sound expert knowledge.

Structure

Participants and Important Artefacts

Participants:

SUT: target SUT, comprising all its soft- and hardware components.

HiL system: hardware required to simulate in real-time all relevant environmental aspects as well as any part of the system the SUT is a component, together with its software. (The HiL system is sometimes shortly referred to as ‘HiL’.)

Engineer (expert): In charge of selecting test, initializing HiL runs, monitoring progress, and terminate the HiL process.

Artefacts:

Scope: set of requirements, test cases, and/or scenarios that shall be addressed during the HiL process. Note that this may include aspects propagated from SiL phase.

Test data: information for the HiL system how to carry out the (next) test run, usually derived from one or more test cases. This can consist of precise data lists that are simply processed by the HiL system or more general information which provides more freedom to but also requires more intelligence in the HiL system. Test data include set-up information for HiL and SUT.

SUT input:

(a) stimuli representing environmental aspects measured by sensors, e.g. temperature, or “raw” data such as cameras images or radar measures.

(b) control data, e.g. provided by other components of the final system to the SUT.

SUT output (Actuator data): output by the SUT, mainly to control actuators, e.g. amperage values for electro motors, or to provide data to other components of the final system, but perhaps also implicitly, e.g. pollutant emissions.

Logging data: the HiL system generates logging data during HiL runs, containing all information to evaluate whether the test run was successful; for example, SUT speed or positions of obstacles. Can include parameter that allow effective progress monitoring and requirements adherence, e.g. KPIs (Key Performance Indicators).

Actions/Collaborations

Test selection: deciding which of the (still) open test cases to address in the next HiL run and how. Produces respective test data.

HIL setup: prior to test run, the whole HiL system is set into its initial state. (Is shown as automated process, but will likely require manual operation.)

HIL execution: controlled by test data, the HiL system computes in real-time input (stimuli) for the SUT, processes SUT output and updates the simulated environment (including remaining parts of the system the SUT will finally be part of). It also logs progress data.

SUT setup: bringing it into the initial state.

SUT Execution: in principle, the SUT performs in real-time as in the final environment. In particular, input is processed and output produced as in the final application.

Progress/Coverage Monitoring: processes log data, either offline after SiL run or in real-time during HiL run. It assesses whether HiL run stays within scope, e.g. if requirements are not violated, and evaluates scope coverage.

Discussion

Benefits:

– The target SUT software can be tested pretty close to reality without risking danger to environment.

– Situations can be simulated that are hard to encounter in reality.

Limitations:

– Development of HiL system can be very expensive. In practice, however, HiL components can be reused for a large number of SUTs.

– Simulation of certain aspects can sometimes be too computational to meet real-time criteria, even with hardware.

Comments:

(Im)perfect Stimuli: depending on purpose of the overall XiL process, simulated sensor inputs can be perfect or defective. The latter will be used if robustness of sensor data processing is to be tested.

SUT input/output conversion: because the SUT operates as in the final application, it’s up to the HiL system to carry out all data conversions between HiL system and SUT in real time.

HiL (run) termination: A HiL run is usually terminated when the test data for the given run are processed. The HiL process is usually terminated after all test cases in its scope have been executed. It is then decided whether the whole Xil process was successful, i.e. the SUT passes, or unacceptable faults occurred, i.e. the SUT failed. If it passes, it is still possible that scenarios or test cases have been left over for testing the final system in reality.

Application Example

ENABLE-S3 UC8 “Reconfigurable Video Processors for Space”:
xx– Image Processing Module

.

Relations to other Patterns

Pattern Name	Relation*
Closed-Loop Testing	Description of overal XiL-process. Is super-pattern of this pattern
SiL (Software in the Loop)	Previous pattern in XiL-process
Test Plan Specification	Supports allocation of requirements to HiL-level
Scenario-based V&V Process	Supports allocation of test scenarios / cases to HiL-level

* “this pattern” denotes the pattern described here, “that pattern” denotes the related pattern