Automotive Safety Integrity Level

There is an automotive-specific, risk-based approach for determining risk classes known as Automotive Safety Integrity Levels, ASlLs. ... 

For Automotive Safety Integrity Level , this book only uses the abbreviation ASIL. 

All of these measures affect the level of graphics. But what is about the content of the shown information itself A required by the automotive industry is the automotive safety integrity level (ASIL) for electrical items in the vehicle. The integrated signature unit in the MB88F334 monitors the defined display content and can detect a calculated CRC value of deviation in the application. 

The purpose of the HARA is to find all foreseeable hazards of an item by applying a systematic search method, and to rate the hazards on a scale of Automotive Safety Integrity Levels (ASILs) from A (lowest) to D (highest), or to rate them as not specifically safety-critical (QM = normal Quality Management is considered sufficient to cope with them). 

The ISO 26262 [ISO 08] standard is the variation of the lEC 61508 [lEC 98] standard of the automotive industry. Levels SIL 1 to SIL 3 are adjusted on a scale known as ASIL (automotive safety integrity level) described below with the impacting key points for the safety concepts. 

Finally, in Chapter 9 we present examples in the automotive field. The automotive field is currently evolving. This development will result in the establishment of a variation of the lEC 61508 standard for the automotive industry called ISO 26262. This standard takes the safety level concept (called here the automotive safety integrity level, or ASIL) and identifies recommendations for activities and methodologies for implementation in order to achieve a given safety... 

In this paper, a method of software safety verification at the system level based on STPA is proposed. We investigated the application of the STPA structure to software, and we found that STPA can be directly used for software. We mapped the results of the STPA safety analysis to a formal specification to be able to verify safety requirements at the software code level. The limitation of the method is that the formal specification is done manually which may lead to much effort to construct and check the potential combinations of relevant states. Therefore, we are exploring the automation of this step and integrate it with our A-STPA tool as future work. Furthermore, we plan in-depth case studies to improve the method by applying it to real safety-critical software in industry. We plan also to investigate the effectiveness of using the proposed method during an ISO 26262 life cycle in the automotive industry. 

Especially in distributed developments partial assessments are necessary, because the integrator on vehicle level is not able all necessary aspects of functional safety for complex products, such as software based multifunctional automotive systems. 

---