Automotive Regulatory Landscape
The automotive industry is going through significant change, with the rapid migration to Electric Vehicles (EVs) and simultaneous introduction of autonomous driving technologies. Both of these changes are resulting in the rise of Software Defined Vehicles (SDV) where cars are becoming technology platforms, and car OEM manufacturers are becoming software companies as much as hardware manufacturers.
However, for reasons of public safety, many of the practices and methodologies used by pure-play software companies are not appropriate or legal when applied to real-time embedded systems such as automobiles and other road vehicles. In this whitepaper we outline the key standards and regulatory frameworks that need to be considered, and explain how software lifecycle management tools like SpiraPlan can help bridge the worlds of software and functional safety.
We will next discuss the different components of the regulatory landscape and how they relate to each other.
What is ISO 26262
ISO 26262 is an international standard for functional safety in the automotive industry. It was first published in 2011 and is now widely adopted by automotive manufacturers and their supply chains.
The standard outlines a risk-based approach to developing and implementing safety-related systems in road vehicles. It covers the entire lifecycle of a safety-related system, from concept to decommissioning, and defines the requirements for each stage of development. It consists altogether of 10 parts, 9 of them are normative and one - part 10 - represents an additional guideline, including providing examples on how to decompose ASILs (Automotive Safety Integrity Levels), and how to combine Fault Mode Effects Analysis (FMEAs) and Fault Tree Analysis (FTA).
In addition, parts 11 and 12 were added to provide guidance on applying ISO26262 to semiconductors and motorcycles respectively.
ISO 26262 is intended to provide a common framework for achieving functional safety and to promote a common understanding of the key concepts and terminology used in the field. The standard is designed to be scalable and can be applied to all types of road vehicles, from motorcycles to trucks and buses.
Compliance with ISO 26262 is becoming increasingly important for companies operating in the automotive sector, as regulators and customers are placing greater emphasis on safety and the mitigation of risks associated with complex automotive systems.
What is IEC 61508
IEC 61508 is an international standard for functional safety of electrical, electronic, and programmable electronic safety-related systems. It was first published in 1998 and has since been updated several times.
The standard provides a framework for the development of safety-related systems and is intended to be applicable to a wide range of industries, including automotive, aerospace, medical devices, process control, and others.
IEC 61508 defines a risk-based approach to functional safety and provides guidelines for the design, development, and operation of safety-related systems. The standard covers the entire lifecycle of a system, from concept to decommissioning, and includes requirements for hazard and risk analysis, safety requirements specification, design and implementation, verification and validation, and maintenance.
Compliance with IEC 61508 is often required by regulators and customers in industries where safety is critical. The standard is widely recognized and accepted, and its use can help to ensure that safety-critical systems are designed and operated in a safe and reliable manner.
What is ASPICE
Automotive Software Process Improvement and Capability dEtermination (ASPICE) also known as Automotive SPICE, is a framework for the assessment and improvement of software processes in the automotive industry. It was developed by a consortium of automotive manufacturers, suppliers, and engineering service providers to establish a common framework for software process assessment and improvement.
Automotive SPICE is a domain-specific variant of the international standard ISO/IEC 15504 (SPICE). The purpose of Automotive SPICE is to evaluate the performance of the development processes of ECU suppliers in the automotive industry.
ASPICE provides a structured approach for evaluating software development processes and is used to assess the capability and maturity of organizations in the automotive supply chain. The framework is based on the ISO/IEC 12207 software development standard and is tailored specifically to the needs of the automotive industry. In general, ASPICE builds on the V-Model of software development. In a V-Model methodology, every system specification on the left side of the ‘V’, has a corresponding validation and verification on the right side. For ASPICE, it looks like the following:
The ASPICE framework consists of a process reference model, a process assessment model, and a process capability model. The process reference model defines a set of processes that are relevant to automotive software development, while the process assessment model provides a method for evaluating the maturity of these processes within an organization. The process capability model provides a way to measure and compare the capability of organizations in the automotive supply chain.
Compliance with ASPICE is often required by automotive manufacturers and their suppliers as a condition of doing business, and it is becoming increasingly important in the industry as the complexity of automotive software systems continues to grow. By adopting ASPICE, organizations can improve their software development processes, reduce risks, and increase the quality of their products.
Comparing ISO 26262 with ASPICE
ISO 26262 and ASPICE are both standards related to the automotive industry, but they have different purposes and focus on different aspects of the development process.
As described above, ISO 26262 is a standard for functional safety and is concerned with ensuring the safety of electrical and electronic systems in road vehicles. It defines a risk-based approach to developing and implementing safety-related systems and provides guidelines for the entire lifecycle of a system.
On the other hand, ASPICE is a framework for the assessment and improvement of software processes in the automotive industry. It provides a structured approach for evaluating software development processes and is used to assess the capability and maturity of organizations in the automotive supply chain.
While both standards are concerned with ensuring the quality and safety of automotive products, ISO 26262 specifically focuses on functional safety, while ASPICE addresses the broader issue of software process improvement.
However, there is some overlap between the two standards. ISO 26262 does require that the development process be conducted in accordance with a defined software development process, and ASPICE can provide a framework for meeting this requirement.
In summary, ISO 26262 and ASPICE are complementary standards that address different aspects of the automotive development process. ISO 26262 is focused on functional safety, while ASPICE is focused on software process improvement.
Comparing ISO 26262 with IEC 61508
ISO 26262 and IEC 61508 are both standards related to functional safety, but they have different scopes and are applied in different industries.
IEC 61508 is a general standard for the functional safety of electrical, electronic, and programmable electronic safety-related systems. It is a broad standard that covers a wide range of industries, including process control, medical devices, and transportation systems.
ISO 26262, on the other hand, is a specific standard for the functional safety of road vehicles. It is based on IEC 61508 but includes additional requirements and guidance specific to the automotive industry.
In other words, ISO 26262 is a derivative standard of IEC 61508, tailored specifically to the needs of the automotive industry. ISO 26262 adopts the fundamental principles of IEC 61508 but adds specific requirements and guidance that are relevant to automotive systems, such as requirements for the verification and validation of safety-related software.
It is worth noting that compliance with IEC 61508 does not guarantee compliance with ISO 26262, but many of the concepts and principles are similar. In fact, compliance with IEC 61508 may be used as a basis for demonstrating compliance with ISO 26262, with additional requirements and guidance specific to the automotive industry being added as necessary.
Using SpiraPlan for Product Development & Safety Compliance
As described above, ISO 26262 prescribes ways to identify and mitigate safety risks for automotive applications. These methods depend on so-called Automotive Safety Integrity Levels (ASILs) which represent safety risk severity classes related to a specific software application. There are 4 ASILs marked with letters A through D from least to most severe, where ASIL-D stands for potential death or severe injury.
It is important to understand that SpiraPlan itself cannot be ISO-26262 certified since it does not run within a road vehicle. Instead, SpiraPlan and the processes implemented on top of it can significantly support teams in achieving the actual automotive application compliance. This can be achieved by:
- Maintaining a central register of hazards and risks, together with their associated mitigations, tasks, tests and requirements.
- Increasing test coverage and frequency which helps mitigate risks, especially when full-scope testing is not possible as it is with artificial intelligence systems or autonomous driving
- Creating an auditable/traceable record of tests and ensuring every change is easily connected with a corresponding requirement and risk
- Versioning requirements, code, test definitions and documentation
- Integrating the different tools used in the software definition, development and testing processes so that there is a single source of truth.
We now discuss how SpiraPlan can assist in each of the key parts of the functionality safety process.
Part 3: Concept Phase
In the concept phase, we need to undertake the following activities:
- Item definition
- Initiation of the safety lifecycle
- Hazard analysis and risk assessment
- Functional Safety concept
Item Definition
Firstly, using SpiraPlan we will want to define the product itself. In this example we will be looking at a fictitious Automated Driving System. This is one of the samples that ships with SpiraPlan:
Using the product-level custom properties available in SpiraPlan, we can specify fields to capture key pieces of information such as the overall product description, any constraints, assumptions and other structured meta-data. In addition, we can use the Product Documents section to store any unstructured information associated with the item in questions, such as ideas, sketches, results from previous trials and any patent/IP information.
Once the item moves into the later phases, these documents can be reused and linked to the various product work items.
Next, we use the Product requirements section to define the key Components and top-level items that make up the product in question. From the supplied sample we have:
Now we can proceed into the next phase – hazard analysis and risk assessment.
Hazard Analysis and Risk Assessment
In this phase, we need to define the various hazards and risks that can occur to each of the different product components. To clarify the difference, a “hazard” means a situation or thing that has the potential to harm a person (for example, a person may be in the road ahead of the vehicle), whereas a “risk” is the possibility that harm (death, injury or illness) might occur when exposed to a hazard, for example the automated driving system not stopping when that person is in the road ahead.
In SpiraPlan, the various hazards are defined in the Risk Types section of the application:
Now that we have defined the hazards, we can create the risks that describe how that particular hazard affects the different components of the product items/components. For example, if we consider how the hazard of a person standing in the roadway would affect the sensor systems component, we would create the following risk:
Note that each hazard will typically results in one or more risks, and each component will also be affected by multiple hazards (and therefore risks):
Once we have defined the various hazards and risks, we will want to categorize the risks by probability, impact, and controllability to determine the overall exposure and Risk Priority Number (RPN):
In this example we have determined that the probability of someone being in the roadway is likely (medium), the impact of this happening is life threatening (for the person and the driver), and the controllability is “uncontrollable”, since the driver would not have time to manually apply the brakes and stop. This yields an exposure value of 9, calculated from Probability X Impact and a RPN of 27, which is Probability X Impact X Controllability.
In accordance with the ISO 26262 standards, we have defined the following risk probabilities:
And the following risk impact values:
For the risk controllability ratings, we need to use the SpiraPlan FMEA SpiraApp that extends the risk management module to use a third factor such as detectability or controllability. Using that add-in, we have defined the following controllabilities:
This is used to denote how much the driver can do to avoid the injury if the hazard occurs.
Functional Safety Concept
The standard defines functional safety as “the absence of unreasonable risk due to hazards caused by malfunctioning behavior of electrical or electronic systems.” Automotive Safety Integrity Levels (ASILs) establish safety requirements―based on the probability and acceptability of harm―for automotive components to be compliant with ISO 26262.
There are four ASILs identified by ISO 26262―A, B, C, and D. ASIL A represents the lowest degree and ASIL D represents the highest degree of automotive hazard. In order to be able to assign an aggregate ASIL grade to each of the risks, we need to create a risk custom property and associated custom list in SpiraPlan to track the values:
A combination of the three factors determines the ASIL requirement:
- Severity - how bad are the safety consequences should a hazard take place.
- Probability - the probability of occurrence for the given hazard
- Controllability - how likely is the driver able to control the hazard scenario.
ASIL = Severity x (Exposure x Controllability)
This can therefore be calculated from the Risk Priority Number (RPN) number value we calculated earlier.
So, with a RPN value of 27, this specific risk would be categorized as an ASIL C level risk. Using our new custom property, we can formally assign this rating:
The next step is to create the safety goals for the item in the context of each of the identified risks. In SpiraPlan, these safety goals become a type of Requirement:
Then you can create the appropriate safety goals in the requirements hierarchy. For example, we will create a sample functional safety goal that maps to the previously identified risk:
You can use the Associations tab to map this to the identified risk:
Finally, we can use the same ASIL custom list to create a custom property on the safety goal requirement to ensure it is also tagged with ASIL level C:
This completes the concept phase of the process.
Parts 4-6: Product Development
If we now look at parts 4-6, they deal with the systems development and engineering itself. The ISO 26262 process defines the following activities, focusing on the overall system development (step 4) which is then decomposed into the hardware development (step 5) and the software development (step 6):
Although this is useful from a compliance and functional safety level, it is not by itself an implementable framework for embedded systems development. In particular with the move towards software defined vehicles and the closer integration of hardware and software capabilities, a more defined system development process is needed. As described earlier in this whitepaper, that is where ASPICE comes in.
The ASPICE Software Development Lifecycle
The Verification and Validation model, also known as a V-model, is what ASPICE builds on. The V-model is strict in its requirement for constant evaluation and development, so that potential issues can be eliminated at the first stage. The V-model consists of two stages. Each one of them includes different phases, as illustrated in the graphic below:
In a V-model, there’s a testing phase alongside each stage of the development. After the development, the software is tested in a sequential order against the requirements specified at the beginning of the project. Now you might think that this model would imply that you can only follow ASPICE with a waterfall process, but that is not the case, you can follow ASPICE in an agile process such as Scrum or Kanban.
ASPICE doesn’t specify how the development process should be conducted. It determines what should be done and what results should be achieved. So, you can map an agile, iterative process to ASPICE as long as you ensure that necessary deliverables and outcomes are created at the end of specific milestones.
SpiraPlan supports V-model, agile and hybrid methodologies, and ensures that whatever lifecycle you choose, you will be in compliance with ASPICE and meet your defined functional safety goals.
Requirements and Architecture Definition
Taking the safety goal created earlier, we can now use this as the basis for our system, software and hardware requirements. Since we are using risks as the starting point, this is an example of Risk Driven Development (RDD).
SpiraPlan has powerful requirements management functionality that includes support for multiple views of requirements (mind map, document, boards, backlogs and grids), history tracking, audit trails, end-to-end traceability and product baselining.
SpiraPlan has support for multiple levels of requirements, so you can create a hierarchy that mirrors the ASPICE process for documenting the system requirements, software requirements (and even the hardware requirements):
We can then use the Associations tab of SpiraPlan to create traceability between the system and software requirements and the original safety goal:
In this example, we can see the original safety goal has resulted in the creation of two system requirements, covering two different aspects of how the system needs to address the goal (covering low speed maneuvering and high-speed driving). Each of these system requirements would be further decomposed into detailed software requirements (or epics and user stories if using Agile).
In the case of software architecture, SpiraPlan includes a built-in diagram editor that lets you define and create system and software architecture models that can be easily linked to your requirements:
The individual diagrams can be linked to the requirements using the Associations feature.
Software Development
SpiraPlan makes it easy to take each of the defined and approved software requirements and create detailed software development tasks that can be planned as part of the overall lifecycle:
These tasks are assigned to the individual developer, with SpiraPlan providing real-time visibility into the progress and completion of the tasks against the parent requirement and the associated milestones.
Once the tasks have been assigned, the developers can create the software code and commit it into the appropriate source code repository, for example SpiraPlan comes with a built-in Git repository called TaraVault. Alternatively, you can use other options such as GitHub or GitLab that SpiraPlan integrates with. SpiraPlan includes built-in support for code browsing, and will let you link the source code commits to the individual requirements and tasks so that you have traceability of all changes made to the system:
SpiraPlan includes the ability to manage pull requests and code reviews as part of the overall development process.
Verification and Validation
When it comes to the testing side of the V-model, SpiraPlan lets you create different types of test case that will be mapped to the different types of requirement (system, software and safety goal):
You then create the different test cases in the SpiraPlan test management module. Often it is convenient to use different folders for the different types, or you can group them by the part of the system being tested. Regardless of the chosen folder structure, you should use the correct test case type for each test case:
This is important because SpiraPlan lets you have different workflows for the different types of test case, and the ISO 26262 standard will require different verification and approval activities for each type.
SpiraPlan includes powerful requirements test traceability features that lets you map different test cases to the requirements to ensure there is test coverage:
Typically, the different tests will cover the detailed system and software requirements as well as the originating safety goal requirement.
Automated Testing
For many of the tests and verifications, there will be ways to automate some or potentially all of the testing to reduce human error and decrease testing time.
For unit testing activities, SpiraPlan has integration with a wide variety of unit testing frameworks that cover the most popular programming languages.
For integration, system and qualification testing, SpiraPlan integrates with our own Rapise test automation platform that can test a variety of different technologies, or you can choose a best of breed set of test automation tools from other vendors:
The verification phases of ASPICE requires that the appropriate verification cases (test cases) and verification procedures are developed and maintained in a version-controlled repository with appropriate change-tracking in place. In addition, it requires that the verification phase includes an analysis of all code as well as an audit of the traceability from tests and results to all requirements.
When you define the requirements in SpiraTest using the requirements module, you can tie the verification cases, verification procedures, test results, defects and any corrective actions to these source requirements.
This end-to-end traceability allows you to prove that all of the required features have been fully tested and that all required verification scenarios have been executed, and that all reported defects have been corrected.
Part 7: Production and Operation
This part of the ISO26262 process is concerned with the production, operation, service (maintenance and repair) and decommissioning of the automotive products being developed and tested. SpiraPlan does not directly provide functionality for production, service and decommissioning, but as production defects and issues are reported from the field, it will assist in the defect triaging process.
SpiraPlan will typically be integrated into the field service support system used to provide production support. Using its APIs, you can have product defects from the support system be automatically entered into the appropriate SpiraPlan products:
In this example, we have a defect raised from the service organization that relates to the automated driving system that we defined earlier. We can now link this raised defect to the requirement and product item it relates to:
Part 8: Supporting Processes
In addition to the core functional safety and product development activities, there are additional required supporting activities that SpiraPlan can assist with.
- Interfaces within distributed development
- Specification and management of safety requirements
- Configuration management
- Change management
- Verification
- Documentation
- Confidence in the use of software tools
- Qualification of software components
- Qualification of hardware components
- Proven in use argument
We discuss some of the key processes that SpiraPlan can assist with that are not already covered previously.
Configuration Management
Configuration Control focuses on the specifications of both the deliverables and the processes. In the configuration management system, you manage the changes related to the product specification and the process. For example, suppose you are developing a product and the client requests the addition of some extra features. Since this change is related to the configuration of the product, you will deal with this change using the configuration management system.
For more information on using SpiraPlan for configuration management, please refer to the article “Using SpiraPlan for Configuration & Change Management”.
Change Management
Change Management is focused on identifying, documenting and controlling changes to the project and the project baselines. In the change management system, you manage the changes related to the project scope, planning, and baselines. To minimize disruption, a change management system must ensure that all parameters are identified and analyzed for any possible impact. If the change request is approved, you will update the concerned baseline, update the project documents, and inform the concerned stakeholders.
For more information on using SpiraPlan for change management, please refer to the article “Using SpiraPlan for Configuration & Change Management”.
Qualification of Components
Supplier qualification is the process by which a company will choose the correct supplier/third-party vendor for components/raw materials/services based on its requirements and regulatory protocols.
Supplier qualification means that a company needs to thoroughly evaluate candidate suppliers and third-party vendors as per their requirements, and then choose the best supplier or third-party vendor. These are usually regulatory requirements.
Qualifying the software and hardware components will require both supplier qualification and also qualification and validation of the individual software and hardware components made by the supplier.
Part 9: ASIL-oriented and Safety-oriented Processes
This part of the ISO 26262 standard - ASIL Oriented and Safety Oriented Analysis provides various mechanism for the tailoring of the ASIL associated with safety goals and their respective functional safety requirements along with mechanisms for validating this tailoring.
SpiraPlan’s rich repository of hazards, risks, safety goals, requirements, tests, verification data as well as defects provides support to organizations looking to customize their ASIL levels based on their identified safety goals. In addition, the reporting and analytics available in SpiraPlan is very helpful when you need to identify and analyze any potential event or cause that could invalidate any ASIL tailoring and thus breach a safety goal or functional safety requirement.
Conclusion
SpiraPlan is a project management and software development platform that can be used for developing automotive software products. There are several reasons why using SpiraPlan can be beneficial for developing automotive software products, including:
- Comprehensive project management: SpiraPlan provides a comprehensive project management framework that can help manage the development process from start to finish. It includes features such as task management, requirements management, test management, and bug tracking that can help ensure that all aspects of the development process are properly managed.
- Collaboration and communication: Developing automotive software products requires collaboration and communication between different teams, such as software developers, hardware engineers, and quality assurance testers. SpiraPlan provides a centralized platform that can facilitate collaboration and communication between different teams and stakeholders.
- Traceability and compliance: Automotive software products are subject to strict regulations and standards, such as ISO 26262, which require traceability and documentation of the development process. SpiraPlan provides features such as traceability matrices and audit trails that can help ensure compliance with these regulations and standards.
- Integration with other tools: SpiraPlan can integrate with other tools commonly used in the development of automotive software products, such as JIRA, GitHub, and Jenkins. This can help streamline the development process and improve efficiency.
Overall, using SpiraPlan for developing automotive software products can help ensure that the development process is properly managed, compliant with regulations and standards, and efficient.
Disclaimer
The information provided on this website is to be used for informational purposes only. The information should not be relied upon or construed as legal or compliance advice or opinions. The information is not comprehensive and will not guarantee compliance with any regulation or industry standard. You must not rely on the information found on this website as an alternative to seeking professional advice from your attorney and/or compliance professional.