# Autonomous Driving--A Crash Explained in Detail
## 6 Perception - Detection Module Issue
### Enhanced Error Detection Mechanisms  
Software has to meet a variety of requirements, which often works very well as long as there is no error. However, if errors occur in hardware or software, it quickly becomes dangerous for the passengers of the car. This is why it is important to make software safer and error-tolerant through structured procedures and certain methods. Even if this can never be achieved 100 percent, emergency strategies can be implemented that mitigate the consequences of an error. The ISO 26262 standard deals with the attainment of functional safety for road vehicles and therefore also includes measures and recommendations for the development of software functions [37]. The automotive safety integrity level (ASIL) classifies hazardous situations caused by system or component failures in four groups. To certify a system for use in a high ASIL situation, it is necessary to integrate error detection mechanisms at software level. In our software we will use the following:  
* Interval test of input and output data
* Plausibility checks through models or comparison of different data sources
* Detection of data errors by error detection algorithms and multiple data storage
* Selected deactivation of faulty functions
* External monitoring devices, e.g., watchdog
* Independent redundancies with different software structures  
However, with growing complexity of the software deployed on autonomous vehicles (especially when compared to nowadays advanced driver assistance systems (ADAS)), the current standards for functional safety reach their limits. Besides the existing methods in the software development of autonomous driving functions, further approaches tackling the arising challenges have to be established. Coming from the perspective that this crash happened because of an improper velocity profile, we propose the integration of two new mechanisms enhancing safety:  
1. Safety layer for the trajectory planner: We propose the integration of a safety layer for the trajectory planner. The idea is to have a second planner that runs as a redundancy for the actual trajectory planner. To get reliable results this second planner should be developed independently and on another basis than the main planner. This safety layer can then be used for the inspection of the feasibility of the generated velocity profiles. In addition, it should secure that the emergency trajectory always ends at 0 km/h. Additional conditions can be integrated. If any of the conditions is not matched, the safety layer switches immediately to the last valid emergency trajectory. To make the approach even more robust the safety layer and the main planner could run on different hardware. The Devbot has a Nvidia Drive PX2 as main ECU. This ECU offers two seperate GPU/CPU combinations that can run software individually [27]. In addition, an AURX microcontroller is integrated as decisive safety compute element.
2. _Supvervisor submodule_: We propose the development of an additional runtime verification module, called \"supervisor\". The scope of this sub-module is to safeguard autonomous driving functions. Thereby, the goal is to identify and monitor an exhaustive list of features contributing to a safe operation, i.e., trajectory. Each of these features is then tracked by an evaluation metric. Based on the full list of metrics, a classification function decides on the binary safety state of a corresponding trajectory (\"safe\" or \"unsafe\"). Since an extensive list of features is surveyed this way, the supervisor module ensures the trajectory planner to stay within safe bounds. As a side product, approval of a complex trajectory planner can be eased up. The development of such a supervisor is part of future research in our team.