## 5 New Challenge: Safety
### Robustness of HMI to Failures
#### 5.2.3 Proposal for Universal Safety Framework in Automotive HMIs  
While various standards, guidelines, and best practices exist for designing automotive HMIs (e.g., ISO 15007, ISO 9241-110, and NHTSA guidelines), there is currently no unified, universally applied safety framework that harmonizes these requirements across all vehicle systems and manufacturers. Inconsistent applications of safety principles can lead to confusion, inefficiencies, and even increased risk for drivers as interfaces and interaction models differ between vehicles. Therefore, it is relevant to explore the concept of a general and universally applicable HMI Safety Standard that could ensure consistency, reduce ambiguity, and enhance overall user trust and safety across the automotive industry. Several leading European countries have also started to develop their own regulations. An ADAS safety regulatory framework would certainly be a good thing to have at the European or global level to avoid unnecessary and partially overlapping requirements, taking into account the specificity of the roads of each country. Such a document could follow the proposed plan below:  
1. Aim: Definition of the aim of the document: 1. Provide a regulatory framework for the development of ADAS vehicles; 2. Remove unnecessary barriers to the development of ADAS vehicles; 3. Harmonize regulations between countries/member states. 2. Exclusion: Concepts excluded from the frame of the document: 1. Liability in case of accident;* 2. Cybersecurity. * 3. Used terms: Definition of terms and concepts:
* 1. ADAS/Traditional Vehicle;
* 2. Driver/user, occupant, another vehicle, pedestrian, etc. ;
* 3. SAE levels of driving automation;
* 4. Technical terms: HMI (Human-Machine Interface), ISA (Intelligent Speed Assistance), AEB (Autonomous Emergency Braking), ELKS (Emergency Lane Keeping System), DDAW (Driver Drowsiness and Attention Warning), etc. ;
* 5. Safety terms: ASIL (Automotive Safety Integrity Level), FMEA (Failure Modes and Effects Analysis), etc. * 4. Failure types: Types of failures or events considered in the frame of the safety framework:
* 1. Hardware failures;
* 2. Transmission errors. * 5. Scale of failures: Definition of the scale of failures and associated criticality (for example: Catastrophic for loss of life, Hazardous, Major, Minor, etc.). Associated qualitative objective, if any. * 6. Quantitative requirements: Quantitative safety design requirements (similarly to aeronautics, a mean time between failures (MTBF) could be allocated to ensure a certain system probability of catastrophic failure, leading to loss of life--for example, a specific MTBF can be allocated to a critical function such as automatic braking). * 7. Qualitative requirements: Qualitative safety design requirements:
* 1. An active redundancy required (inspired from the aeronautics fail-safe design concept) for all critical functions. * 2. Diverse redundancy for critical software, which implies the determination of what are the critical functions and the critical software. * 8. Design requirements: Safety design requirements--means of demonstration. Demonstration could be carried out in a couple of ways. As in other domains, quantitative safety design requirements could be demonstrated through different safety analyses techniques such as Petri Nets, Markov Graphs, Failure Modes and Effects Analysis (FMEA), and Fault Tree Analysis (FTA). Quantitative safety design requirements could also be demonstrated with simulation or experience (open-road testing), which could be interesting with regards to transmission errors. Such demonstration is difficult to achieve in Aeronautics and Space domains due to the relatively low number of hours of experience and the difficulty and cost to implement the test. In the AV domain, it is possible to achieve rapidly millions of hours of experience. Furthermore, as seen previously (Figures 8 and 9), AI is trained to tackle extremely rare conditions and scenarios.