Definition: Trying to improve the performances of an agent on a target set of which limited data is available by first training on a source set with more data available. Less target data is therefore needed

Interesting parameters:

DHW: distance between the front and following car

THW: DHW divided by the speed of the following vehicule

TTC: DHW divided by relative speed of the 2 cars

Hardware in the loop testing:

Definition: technique used in development and testing of embedded real-time systems. In hardware in the loop simulation we add plant complexity to the test platform by adding the mathematical representation of all the dynamic systems involved.

Different from rapid control prototyping: here we do not use definitive hardware but we act with so physical elements of the plant.

advantages of HIL: reduced testing cost, reduced risk, concurrent development of elements of the control system, testing many plants variations.

Autonomous Vehicle Testing and Validation Platform: Integrated Simulation System with Hardware in the Loop (2018)

Hardware in the loop testing with the final ECU in a simulated environment. The ECU sends control instructions (throttle brake steer) to a lower level simulation layer. The simulation then update the state of the car and the scenario, computes simulated sensor response that are fed to the ECU.

Same but without hard real-time constraints. The simulation provides sensor data at a higher rate than the ECU clock speed, only the latest image is saved and fed to the ECU.

HIL testing with more hardware executed in real-time (the other vehicles are run offline and time synchronized)

Driver controlled steering, throttle and brake, steering actuator

Communication between ECU and HIL via dspace proprietary bus and CAN

Tire force emulator for emulated lateral forces and alignment torque for handwheel torque feedback

From norms:

ISO norms covering ADAS systems:

-ISO 26262 (2018 review): Road vehicles functional safety

Safety systems that include one or more electronic components installed on production vehicles

Addresses possible hazards caused by malfunctioning of these safety equipments

e.g sensor not responding, eye damage from laser sensor

hazards resulting from functional insufficiencies of the intended functionality or by reasonably foreseeable (and unintentional) misuse by the users

intended functionality where proper situational awareness is critical to safety, and where that situational awareness is derived from complex sensors and processing algorithms

especially emergency intervention systems (e.g. emergency braking systems) and Advanced Driver Assistance Systems (ADAS) with levels 1 and 2 on the OICA/SAE standard J3016 automation scales

verification vs validation

From that, ISO 21448 seems more interesting in our case

Scenarios that the system may encounter are according to 2 criterias. Are they safe or unsafe, are they known (used for training) or unknown (used for verification for example).

The norm proposes a continuous improvement development cycle which goal is to increase the number of known safe scenarios and reduce the number of known unsafe and unknow unsafe scenarios. Every unknown unsafe scenario becomes a known unsafe scenario when encountered. The risk associated with known unsafe scenarios should be mitigated with technical measures (e.g training) to becomes a safe scenario or be safe within an acceptable margin.

The residual risk is evaluated by considering the results of the verification and validation phase. V&V can include model in the loop, software in the loop, hardware in the loop, test driving and long term endurance tests.