- 1. Requirements Management
- 1 What is Requirements Management?
- 2 Why do you need Requirements Management?
- 3 Four Fundamentals of Requirements Management
- 4 Adopting an Agile Approach to Requirements Management
- 5 Conquering the 5 Biggest Challenges of Requirements Management
- 6 Three Reasons You Need a Requirements Management Solution
- 2. Writing Requirements
- 1 Functional requirements examples and templates
- 2 Product requirements document template and examples
- 3 How to write system requirement specification (SRS) documents
- 4 Adopting the EARS Notation to Improve Requirements Engineering
- 5 Jama Software Requirements Advisor
- 6 Frequently Asked Questions about the EARS Notation and Jama Connect Requirements Advisor
- 7 How to Write an Effective Product Requirements Document
- 8 Functional vs. Non-functional requirements
- 9 What Are Non-Functional Requirements and How Do They Impact Product Development?
- 10 Characteristics of Effective Software Requirements and Software Requirements Specifications (SRS)
- 11 8 Do’s and Don’ts for Writing Requirements
- 3. Requirements Gathering and Management Processes
- 4. Requirements Traceability
- 1 What is Requirements Traceability and Why Does It Matter for Product Teams?
- 2 How to Create and Use a Requirements Traceability Matrix
- 3 Live Traceability vs. After-the-Fact Traceability
- 4 How to Overcome Organizational Barriers to Live Requirements Traceability
- 5 Requirements Traceability, What Are You Missing?
- 6 Four Best Practices for Requirements Traceability
- 8 What Are the Benefits of End-to-End Traceability During Product Development?
- 5. Requirements Management Tools and Software
- 6. Requirements Validation and Verification
- 7. Meeting Regulatory Compliance and Industry Standards
- 8. Project Management
- 9. Measuring Requirements
- 10. Systems Engineering
A Guide to Automotive Safety Integrity Levels (ASIL)
The new revolution in automotive technology is not just on the horizon, it’s here. From the rapid proliferation of electric vehicles to self-driving cars, automobiles have advanced rapidly from the days of mechanical systems. These advancements are exciting and welcome for a variety of reasons, but they bring along ever-increasing challenges and considerations for developers of everything from windshield wipers to microchips to built-in cameras. As drivers grow increasingly dependent on systems that make getting from point A to point B easier and more fun, they also need to have the assurance that those systems are safe and reliable.
In this new automotive reality, adhering to safety guidelines has never been more important. As developers and manufacturers work to achieve compliance with ISO 26262, they must understand Automotive Safety Integrity Levels, or ASIL, to know what level of rigor to apply.
What is ASIL?
ASIL stands for Automotive Safety Integrity Level, and it is a risk classification system for functional safety of road vehicles. ASIL is defined by the ISO 26262 standard, part nine, and is adapted from the Safety Integrity Level (SIL) guidance published in IEC 61508.
While compliance with ISO 26262 is not mandatory, it is the state-of-the-art practice within the industry, and ASIL is a key piece of the standard. ASIL determines how rigorous the process for developing a product should be based on the risk of that product harming a person if it fails. By doing a full safety assessment of each component, module, or system based on a variety of factors, teams can come to a reasonable expectation of risks and outcomes in the event of failure and implement mitigation efforts to reduce risks.
ASIL is determined after a full hazard analysis and risk assessment, or HARA. Engineers or developers assess each component or system with an eye toward risks and hazards presented by the potential failure of that component or system. How likely is the system to fail? What will happen if it fails? Can a driver compensate or manage the failure without injury? Is injury likely to occur in the event of failure, and if so, how severe will the injury be? Once the hazard analysis and risk assessment are complete, teams can assign the ASIL.
What are the different ASILs?
ASIL classifies hazards in one of four levels, denoted as A through D, with a fifth additional level for non-hazardous systems or components. ASIL D represents the highest level of risk, while ASIL A represents the lowest risk level. The additional level, QM, stands for Quality Management and denotes non-hazardous items that require only standard quality management compliance.
In general, systems such as anti-lock brakes or airbags require an ASIL D classification because the risks associated with failure are the highest in those systems. At the other end of the spectrum, a system such as rear lights would only require an ASIL A classification; while there is certainly a safety component associated with rear lights, most drivers could mitigate those risks, and the potential severity of injury is typically not high.
What factors determine an ASIL?
To determine an ASIL, developers and engineers consider three factors:
- Severity (potential severity of injuries caused by a hazardous event)
- Exposure (frequency of conditions that would potentially cause injury)
- Controllability (likelihood that the driver could act to prevent injury)
Within each of the three factors are additional levels as expressed numerically:
S0: No injuries
S1: Light to moderate injuries
S2: Severe to life-threatening injuries (survival probable)
S3: Life-threatening (survival uncertain) to fatal injuries
E0: Incredibly unlikely
E1: Very low probability
E2: Low probability
E3: Medium probability
E4: High probability (injury could happen under most operating conditions)
C0: Controllable generally
C1: Simply controllable
C2: Normally controllable (most drivers could act to prevent injury)
C3: Difficult to control or uncontrollable
RELATED ARTICLE: The Impact of ISO 26262 on Automotive Development
How do I choose my ASIL?
To determine the ASIL, development teams should put each system, module, or component through a full hazard analysis and risk assessment (HARA). The purpose of this assessment is to identify all of the malfunctions that could lead to hazards or failures and evaluate the risks associated with those failures. Any manufacturer who is aiming for ISO 26262 compliance on any product should conduct a HARA and assign an ASIL .
During the HARA, teams assign the levels of severity, exposure, and controllability as established by the chart above. Once these levels are established within those categories, teams can use the chart below to arrive at the ASIL :
PLEASE NOTE: While this guide may help you generally identify your ASIL, it should not serve as an official ASIL determination.
What are some examples of ASIL classifications?
Though there is some degree of subjectivity within the different ASIL classifications, some systems and components have fairly consistent classifications. Here are a few examples:
ASIL D: Airbags, antilock braking, electric power steering
ASIL C: Adaptive cruise control, battery management, suspension
ASIL B: Brake lights, rear view camera, instrument cluster
ASIL A: Rear lights, heating and cooling, body control units
QM: GPS/Navigation systems, satellite/digital radio, connectivity (USB, HDMI, Bluetooth)
Even within these examples, there may be variance between different models, manufacturers, or risk assessments. For example, depending on other factors, “Engine management” risks could be ASIL C or D, and various powertrain systems and risks could vary between ASIL B and ASIL D. A host of considerations go into assessing risk and assigning levels.
In addition, it is possible for ASIL to change. For example, an OEM (Original Equipment Manufacturer) may determine that a component has a level of ASIL B, but once the component is integrated with other systems, the level may be raised or lowered in conjunction with an additional hazard analysis and risk assessment.
What are the challenges of ASIL?
Although the chart above shows how to arrive at an ASIL based on the severity, exposure, and controllability levels, there is some amount of subjectivity involved in assigning those levels. For example, road conditions, environmental factors, traffic density, driver competence, and likelihood of exposure can all vary widely. A driver who is operating a vehicle on a wide, empty, dry road may be more likely to control for a hazardous event than a driver operating in heavy traffic during a rainstorm. The ASIL classification system depends on subjective interpretation with words such as “usually,” “likely,” and “probably,” which involves some level of educated judgment on the part of engineers and developers. Another challenge with determining ASIL levels is the temptation to make an assumption based on past level assignments without doing a full hazard analysis and risk assessment. For example, if a system was previously assigned ASIL level B, it might be tempting to assume its current level should be the same. However, improvements in the system or integrations with other systems could change the level. If a GPS system now integrates with camera equipment or some other intelligent technology, that new integration could raise or lower the ASIL level.
Finally, teams that are not keeping good documentation records or tracking requirements properly may arrive at inaccurate ASILs — or even neglect risks entirely. When documentation and requirements aren’t thoroughly tracked, teams may miss key functional safety risks. Requirements tracking and traceability is essential not only for compliance with ISO 26262, but also for the practical market need to thoroughly and accurately assess and mitigate risks.
How does ASIL impact product development?
Once the ASIL for a system has been developed, ISO 26262 defined different levels of rigor that are required based on the ASIL. For example, for ASIL A and B, an information notation is sufficient for capturing requirements. This typically means that requirements are written in natural language and augmented with simple figures to illiterate key concepts. For ASIL C and D, a more semi-formal notation is recommended. Requirements are still often written in natural language, but then models of the system are developed to more accurately describe behavior. Developing these models requires additional expertise on the team but increases the accuracy of the documentation and decreases the risk of miscommunication. Teams developing higher ASIL system often require additional expertise as well as specialized software tools to support the process.
How are ASILs evolving?
The Society for Automotive Engineers (SAE) issued J2980 in 2015 to provide additional guidance for assessing severity, exposure, and controllability. In addition, J2980 itself was updated in 2018, as was ISO 26262.
As automotive technology advances with AI (Artificial Intelligence), self-driving features, and integration to external systems through IoT (internet of things), the concept of controllability presents particular challenges. Currently, “controllability” largely refers to the human vehicle operator, but as autos become more able to react independently, the standards for assessing controllability may change. With features that compensate more and more for driver error, cars are becoming safer and more intelligent, decreasing the likelihood of hazards that cause severe injury or death. At the same time, however, access to external systems can introduce cyber vulnerabilities that complicate ASIL considerations.
Cybersecurity vulnerabilities can lead to safety considerations just like hardware failures. As a result, teams are now starting to analyze the safety and security of systems together. ISO 21434 especially makes recommendations that tie in with ISO 26262 to support this process.
In This Webinar, Learn About Standardizing Requirements Across Your Organization
Automotive Safety Integrity Level is a risk classification system for functional safety of road vehicles. ASIL is defined by the ISO 26262 standard, part nine, and is adapted from the Safety Integrity Level (SIL) guidance published in IEC 61508.