Understanding an ASIL in the Functional Safety Standard ISO 26262

An Automotive Safety Integrity Level (ASIL), according to the ISO 26262 standard, is defined as one of four levels to specify an item or element’s necessary ISO 26262 requirements and safety measures as they apply to avoid an unreasonable risk – Level D represents the most stringent requirements, and Level A represents the least stringent. In other words, ASIL is a risk classification scheme as defined by the Automotive Functional Safety Standards Standard ISO 26262 (safety of road vehicles). The ISO 26262 standard is the State Of The Art (SOTA) in the automotive industry and automotive electronics world for the design of electronic systems in safety-critical applications. The automotive world is moving towards vehicles becoming safety-critical devices, particularly since it is moving towards both the high-voltage and electric-vehicle markets, as well as autonomous driving. This adds to the complexity of electrical and electronic design, further adding challenges to efficiently integrate and test such complex systems posing potential risks to human safety. ISO 26262 is the adaptation of the IEC 61508 series of standards to address the sector-specific needs of electrical or electronic (E/E) systems within road vehicles. The systems or subsystems within a vehicle can all be classified using the letter “A,” “B,” “C” or “D,” and that gives a more high-level view of how critical a subsystem is. For example, a Steering Control System (SCS) poses a very high risk in case of failure in situations when the vehicle is in motion. If such failure happens, it has a high potential to cause harm to humans (including the driver, passengers, pedestrians, and others in surrounding vehicles). Therefore, it's classified with the highly safety-critical ASIL D. Conversely, the failure of a radio likely won't cause harm to the driver. Therefore, it is classified as ASIL A, or quality management (QM). QM refers to the standard's consideration that it is below ASIL A in which there is no safety relevance, and only standard QM processes are required to fulfill any relevant requirements. The ISO 26262 standard actually recommends system-level analysis from a vehicle level to define these subsystems and classify them accordingly based on criticality. The letter – ASIL A, B, C, or D – a system is assigned depends on three main things: the probability of exposure, severity, and the controllability of the actual system. The ASIL letter itself is an outcome of the analysis from a Hazard Analysis and Risk Assessment (HARA), which is defined in Part 3 (Concept Phase) of the ISO 26262 standard.

New call-to-action

Although this type of classification is not new, the term ASIL is relatively new. The term ASIL first originated from the ISO 26262 standard, which was released in 2011 and became publicly available since then. Other industries use very similar classifications. The rail industry uses Safety Integrity Level (SIL), and the aerospace industry uses Design Assurance Level (DAL). The differences in industries are more related to the application itself. For example, “controllability” is something that doesn't necessarily exist within the concept of aerospace because there are no drivers. The pilot could technically be considered a driver, but a pilot’s capability to adversely affect solutions 30,000 feet in the air is very limited relative to a driver in a car.


In fact, in the future of the automotive industry, controllability might not even be much of a factor if the driver is removed from the situation, especially in cases where the automotive industry is moving rapidly toward full autonomy. Another interesting difference between industries is that an ASIL D is actually classified with a failure rate of ten to negative eight (10-8). So, looking at it from a high level, it’s undesirable for a highly safety-critical system, such as a steering system, to fail very often. In this case, the probability of its failure should be less than 10-8. In aerospace, that number is actually 10 to the negative nine (10-9). In comparing the industries, this shows that the safety-critical level of things in flight is higher than things on the ground or in a car. From a general perception standpoint, that is an accurate statement. However, taking into consideration that the automotive industry is working to remove the driver in the future, it is likely that these standards will be adapted accordingly.

What Does This Mean? Why Is It important? What Can Be Done?

This depends on whether the system is classified as ASIL A, B, C, or D. Each of these levels defines how much work really must be performed to qualify and verify a system within the ISO 26262 standard. If the system ends up in any of the ASIL classifications, it means there are certain requirements, recommendations, and guidelines to be followed according to the ISO 26262 standard. An example of that is in ISO 26262, Part 6, which describes requirements and methods for structural coverage on software. If the system is recognized as ASIL D, ISO 26262 highly recommends the performance of Modified Condition Decision Coverage (MC/DC) structural testing on all the software. MC/DC is a heavy labor-intensive testing of code at the lowest level, which is considered very expensive in both of the industries requiring it – automotive and aerospace. The tables in the ISO 26262 standard provide the definition of how much work needs to be done for each level of ASIL by listing methods and classifying them as recommended methods or highly-recommended methods based on the ASIL. The higher the ASIL, the more work is required to be performed as more complex methods are highly recommended. That's just one example on the software side; Part 6 has multiple tables with similar spectrums of work.

On the hardware side, Part 5 of the ISO 26262 standard includes a section called, “Hardware Architectural Metrics.” This is a statistical computation of the probability of failure. There are methods defined in the standard of how to perform the computations. That only applies to or is only highly recommended, for ASIL B, C, and D. As the ISO 26262 standard is 700-plus pages, including 12 different parts, there are many requirements within the standard itself. Therefore, there are more requirements and efforts necessary to validate and verify high-level safety-critical (ASIL C or D) systems.


So, what should suppliers in this situation be doing? That's a big question. Each system is rated with an ASIL letter. The first thing to do is negotiate an ASIL letter classification as a result of qualitative assessment, which is more subjective in nature. Looking at Part 3 in the ISO 26262 standard – HARA – the letter is defined by how controllable something is, how severe something is, and how much exposure is probable. There is a lot of variability within those definitions, as those three attributes have various levels to choose from. When the original equipment manufacturers (OEMs) give an ASIL letter rating, it doesn't mean that the decision is final. In fact, as a part of a larger development program, these things will likely change. A supplier can then modify its ASIL letter rating (as things are likely to change and more details are available, either based on program development or negotiations) possibly to a lower ASIL, resulting in a reduced amount of work needed on the supplier’s side. It is also very important for a supplier to understand where its ASIL ratings fit within the overall vehicle. The second thing suppliers can do is ASIL decomposition. There is a way to break down a system from one higher ASIL letter to two ASILs. Looking into the ISO 26262 standard, suppliers will find a section in Part 9 on how to decompose a higher ASIL. The goal is to actually get down from an ASIL D to an ASIL C or B, resulting in reduced efforts and less work overall. Another very important item to consider when getting an ASIL letter is the Development Interface Agreement (DIA) between suppliers and OEMs. Even within the categorization of an ASIL, there will always be certain amounts of work that are necessary and are described in the ISO 26262 standard.

eBook: Implementing Functional Safety; Step by step guide: how to implement functional safety through iso 26262

That's another point of negotiation that a supplier should have with its OEMs. This is important because it then drives how much work and cost will be involved in the development of these safety-critical systems for a vehicle.

Finally, ASIL ratings are extremely important from the standpoint of auditing. There's a parallel here in aerospace. The Boeing 737 Max definitely has a highly safety-critical flight control system, and concerning the people getting involved with an issue like this, the DAL-rating decision goes all the way to Congress. Automotive companies aren't currently facing this kind of scrutiny. However, in the future when autonomous driving reaches the general public, it's very likely that there will be some government auditing agencies involved in assessments of the validation of vehicles. Currently, accredited third-party government agencies handle this, such as the TÜV NORD GROUP. Still, in the United States, there is no Federal Aviation Administration (FAA)-type body looking into the engineering development processes or implementation of the ISO 26262 standard. So, the spectrum is fairly undefined, and it goes back to the ASIL letters – A, B, C, or D. Highly safety-critical systems are more likely to be scrutinized in a failure situation where someone is harmed. A supplier will want to manage its system’s safety criticality as much as possible and look for opportunities to move it down the letter list. These are the major aspects of the ASIL definition, how it's used, and why it's important for suppliers to understand.



Interested in learning more about AUTOSAR for your organization? Contact our team today!



Further reading and references

Ashutosh Chandel

Written by Ashutosh Chandel

Ashutosh Chandel joined LHP in 2011. He is the Director of Engineering managing an engineering team spread all over the United States, directing the growth and integration of LHP’s ecosystem of core competencies. Ashutosh also serves as a Level II FSCAC (Functional Safety Certified Automotive Consultant) and instructor for the ISO 26262 automotive standard. His engineering experience includes 20 years in all aspects of project planning and execution, including activities such as writing technical requirements, design, development, writing proposals, project estimation, budgeting, and risk analysis. With almost 2 decades of experience, Ashutosh has resided in various domains, such as embedded, manufacturing IT, R&D, remote monitoring and diagnostics, industrial and plant automation for the automotive industry, automotive functional safety, medical device and equipment, pharmaceutical, manufacturing and plant automation and integration domains. Other responsibilities include evaluating third party vendors and suppliers for product evaluation and testing to verify acceptable matches of devices, products, and tools for his programs. Besides his involvement in engineering, Ashutosh has been successful leading and implementing projects and programs, working closely with business development managers and sometimes, taking on the role of account manager. His expertise is peppered all along the engineering V-diagram, involved in various phases of the SDLC, such as requirements gathering, design, development and construction, integration, testing, installation and commissioning, acceptance and implementation phases along with configuration management and quality control. The vast exposure has given him knowledge in N-Tier application architecture and implementation. Ashutosh is certified through TUV Nord as a Functional Safety Certified Automotive Consultant and a Functional Safety Certified Automotive Engineer. Through National Instruments, he is a certified LabVIEW Architect. Ashutosh holds an MBA from Texas A&M University – Corpus Christi, and a Bachelor of Engineering from the University of Pune. He and his family live in Columbus, Indiana.