ASPICE and ISO 26262: How does this Union Impact the Automotive Software Development Landscape
Category : Embedded Blog
Being the major driver of innovation in automotive industry, software development is in a constant state of improvement. And the fact that the innovation is being carried out by all stakeholders (OEMs, tier-1 suppliers, technology providers), there is a need for standard frameworks that bind all of them. A coordination between these stakeholders with respect to definition, implementation and process evaluation for software development is critical for a seamless collaboration. Automotive Software Performance Improvement and Capability dEtermination (ASPICE) is one such framework that aims to bring about this coordination.
Functional Safety of road vehicles mandated by ISO 26262 standard adds one more dimension to this standardization. In addition to improving the quality of software, the safety aspect of an automotive system also assumes much importance. ISO 26262 is now a de-facto automotive functional safety standard that all road vehicles must adhere to.
We have talked about two different concepts here; one that takes care of the overall software quality and the other that deals with the safety aspect. How are they related? Do ASPICE and ISO 26262 complement each other? Can they co-exist? Let’s try to find some answers! But first, we must understand ASPICE and ISO 26262 in their individual capacity.
Role of ASPICE in Improving Quality of Automotive Applications
ASPICE has been defined under ISO ISO/IEC 15504 by a group comprising of European car manufacturers. ASPICE is a standard that provides a framework to establish and evaluate the process of automotive software development.
The direct impact of adopting ASPICE is on the refinement of the processes and thus the quality of the software. During the supplier selection, an OEM can use the ASPICE framework to assess the capability and the quality of a supplier. On the other hand, ASPICE can prove to be a framework for the suppliers to take their quality a few notches higher.
ASPICE is a two-dimensional model which comprises Process dimension and Process Capability dimension.
ASPICE identifies different process like Requirement elicitation, System requirement analysis, process management etc. Essentially, these processes are nothing but the activities to be performed during the software development lifecycle. You can easily identify processes like requirement analysis, architectural design, unit testing as part of the V-model. Process dimension categorizes the processes in groups such as system engineering process group and management process group and so on. This categorization takes the form of a model called the Process Reference Model. Here, each process is defined in terms of its scope and the functional objective.
ASPICE identifies different process like Requirement elicitation, System requirement analysis, process management etc. Essentially, these processes are nothing but the activities to be performed during the software development lifecycle. You can easily identify processes like requirement analysis, architectural design, unit testing as part of the V-model. Process dimension categorizes the processes in groups such as system engineering process group and management process group and so on. This categorization takes the form of a model called the Process Reference Model. Here, each process is defined in terms of its scope and the functional objective.
Now that the process dimension has been captured, the process capability needs to be measured. For every process, the ISO 15504 standard defines the capability level from Level 0 to 5.
Level 0 – Incomplete: Development process are incomplete or not documented properly.
Level 1 – Performed: The process achieves its purpose; however, there might be gaps here and there.
Level 2 – Managed: The processes are implemented in a managed way i.e., they are planned and monitored.
Level 3 – Established: The processes are well-established, and documentation has been followed diligently across the supply-chain.
Level 4 – Predictable: The process is implemented within a defined limit and the output can be predicted.
Level 5 – Innovating: There is an ongoing improvement in the predictable process to meet the new challenges that present themselves from time to time.
The capability level is determined by process attributes (PA) clearly defined in the ISO 15504 standard. These attributes are as follows:
- Process performance
- Performance management
- Work product management
- Process definition
- Process deployment
- Process measurement
- Process control
- Process innovation
- Process optimization
Each of these attributes is concerned with a specific aspect of the process capability level. These PAs rated against a scale as follows:
N (Not Achieved): Outcome was not achieved or not implemented
P (Partially Achieved): A few intended outcomes were achieved but the capability has not been achieved in entirety
L (largely Achieved): Increased likelihood of outcome achievement but there is no certainty of achieving the intended quality, time, and budget targets.
F (Fully Achieved):
The final assessment is performed using a Process Assessment Model. A sample PAM is shown below:
ISO 26262 and the Automotive Functional Safety Aspect
A lot of components inside an automobile are safety critical such as electronic Steering System, Anti-lock Braking System, Air-bags, powertrain ECUs, and more.
By safety critical, we imply that a failure of such components poses a risk to the driver or the passengers’ life.
ISO 26262 is a standard that defines a safety lifecycle to implement safety practices during the design, development, and the testing of all electrical and electronic components of a road vehicle.
ISO26262 standard is a set of steps that regulate the product lifecycle at the software, hardware and system level. ASIL (Automotive Safety Integrity Level) is a classification scheme for software or hardware component that signifies its safety-criticality.
ASIL has four categories- ASIL A, ASIL B, ASIL C, and ASIL D. ASIL A indicates least critical level and D indicates the most critical level.
When ASPICE met ISO 26262
ASPICE covers the entire system development and that’s one of the reasons why ASPICE also provides an ideal framework to implement the ISO 26262 standard.
As is clear from the image above, the ISO 26262 lifecycle can be matched with the V-model followed by Automotive SPICE.
The additional items that ISO 26262 brings to the table are mostly related to the concept phase. They include:
- Item Definition: It is a list of the system, sub-systems, functional dependencies, and various such attributes. The information contained in the item definition document, serves as an input for the HARA process.
- Failure Mode Effect Analysis (FMEA): FMEA is an inductive analysis method to find the causes and effects of a failure. It also contributes to the identification of functional and non-functional requirements, which might not have been identified during HARA.
- Failure Modes, effects, and diagnostic analysis (FMEDA): Failure Modes, Effects, and Diagnostic analysis (FMEDA), is an ideal method for the derivation of Hardware Architecture Metrics like PMHF (Probabilistic Metrics for Hardware Failures), SPFM (Single-Point Fault Metric) and LFM (Latent Fault Metric).
- Failure Tree Analysis (FTA): Fault Tree Analysis (FTA) is an example of deductive failure analysis where root case of the fault is depicted using Boolean logic.
- Hazard Analysis and Risk Analysis (HARA): The purpose of HARA is to identify the malfunctions that could possibly lead to E/E system hazards and assess the risk associated with them.
Together with ISO 26262 and ASPICE, there are approximately 250 work products and 60 process to take care of which is indeed a sheer quantity of work.
The ISO 26262 mandated safety lifecycle is followed simultaneously with ASPICE. At every stage of V-cycle, certain analyses recommended by ISO 26262 standard are performed alongside ASPICE processes. For instance, a hazard analysis is performed as an extension to risk management (ASPICE). More analyses like FMEA and FMEDA are introduced to derive safety goals, failure in time (FIT) and certain hardware metrics such as SPFM, LFM and PMHF.
Moreover, the System Requirement specification would also include safety requirements. The Verification and Validation processes would also follow the methodologies as mentioned in the ISO 26262 standard. The diagram makes the overlapping of ISO 26262 and ASPICE clearer:
The Road Ahead
ASPICE covers the broad aspects of software development and ISO 26262 can expand its safety aspect. These two standards are different in many regards such as cost and time implications, assessments etc. However, they have quite a few similarities that include process areas such as configuration and change management and commitment towards achieving bi-directional traceability between the work-products.
Several tools and templates are also available that make the integration of ASPICE and ISO 26262 easier for the development and compliance teams. Functional Safety consultancy organizations leverage these tools and templates to help the OEMs and suppliers in achieving the required compliance.
