What Is Automotive SPICE?
Automotive SPICE®* or ASPICE (Automotive Software Process Improvement and Capability dEtermination) is an automotive standard based on ISO®/IEC 15504 and the ISO 330xx series of standards. Automotive SPICE allows organizations across the automotive supply chain to assess and improve the capability levels of their own processes as well as those of their suppliers. In practice, Automotive SPICE allows customers (OEMs and their multitier network) to assess the processes of their suppliers during the selection process.
Model-Based Design and model-based systems engineering provide the ingredients and mechanics that allow organizations to meet Automotive SPICE requirements and allow suppliers to satisfy and even exceed their customer expectations. Take traceability as an example of a key ASPICE concept: Using Simulink®, System Composer™, and other specification, design, code generation, and verification/validation (V&V) tools from MathWorks, you can maintain a digital thread across all your project artifacts (Figure 1). Using forward and backward traceability, you can see how requirements are realized and how your design constraints are met in the developed system and software. This also extends to all verification and validation artifacts.
Figure 1. With Model-Based Design and model-based systems engineering, you can easily maintain a digital thread between your artifacts throughout your development lifecycle. This is a key principle of Automotive SPICE.
The support Model-Based Design has for ASPICE is described in full detail in a mapping document from IEC Certification Kit that maps tool use cases to ASPICE base practices.
The Dimensions of Automotive SPICE
ASPICE has two dimensions: a process reference model (PRM) and a measurement framework. During assessment, assessors rate processes with respect to predefined attributes. Automotive SPICE includes mechanisms for aggregating ratings across processes and their attributes to determine the capability level achieved by an organization.
Figure 2. The two-dimensional framework for ASPICE process assessment: Certain processes are selected from a process reference model (first dimension) and their capability levels (second dimension) are determined based on evidence.
ASPICE defines six capability levels in total, going from level 0 (incomplete processes) to level 5 (innovating processes).
ASPICE is increasingly becoming widespread in the automotive industry with many OEMs and their multitier networks requiring all their suppliers to have at least Automotive SPICE level 2, with plans to achieve level 3 for future projects or in the future in general.
Figure 3 depicts the six levels of Automotive SPICE and the additional process attributes required for assessment at each level.
Figure 3. The six capability levels of Automotive SPICE. ASPICE defines six levels for process capabilities, going from incomplete process (level 0) to innovating process (level 5). Specific process attributes need to be achieved and evidenced to move from one level to the next.
Process Reference Model (PRM)
The process reference model of ASPICE defines processes and their interrelations. Each process is described by its name, main purpose, and associated outcomes.
Each process also specifies certain base practices that define activities considered as indicators for achieving associated process outcomes. Additionally, each process has certain work products. The existence of these formal documents or work products signifies the positive conclusion of certain activities in Automotive SPICE.
The standard categorizes these processes (32 in total) into three process categories (primary, organizational, and supporting) and into eight process groups.
- Primary lifecycle processes consist of the acquisition process group (at the customer side), supply process group (at the supplier end), and engineering processes needed for product specification, design, development, integration, and testing at the system and software levels.
- Supporting lifecycle processes include processes such as documentation, verification, joint review, and change management. These processes can be employed by other processes throughout the product lifecycle.
- Organizational lifecycle processes include management, reuse, and process improvement process groups. These processes allow organizations to achieve their business goals by developing processes, products, and reusable resource assets to use in projects.
Figure 4. ASPICE process reference model. It specifies 32 processes under three categories and eight process groups. The orange frame denotes Automotive SPICE processes in the VDA scope.
Measurement Framework
The measurement framework of Automotive SPICE allows assessors to determine the capability dimension for each process under consideration based on measurable process characteristics or attributes. Assessors obtain evidence for compliance by considering:
- Available work products and repository content for assessed processes
- Testimonies given by process performers and managers
Process attribute ratings follow a four-step ordinal scale (Not achieved, Partially achieved, Largely achieved, and Fully achieved). To achieve a specific capability level for a process, all process attributes of that level must be either Largely or Fully achieved and processes attributes of previous levels must be Fully achieved.
ASPICE Engineering Processes
The primary lifecycle process category in ASPICE includes system and software engineering process groups. These two groups define necessary engineering processes to develop automotive products at the system and software levels. The system level is where disciplines such as software, hardware, mechanical, and thermal meet.
The system engineering process group describes individual processes (SYS.1–SYS.5) that are necessary to gather and manage customer and internal requirements, develop the system architecture, and perform integration, integration testing, and qualification activities at the system level.
Similarly, the software engineering process group describes individual processes (SWE.1–SWE.6).
SWE.1–3 specify processes at the left side of the V-model. The purpose of these processes is to specify software requirements, develop the software architectural design, detail the design, and construct software units. On the other side of the V, SWE.4–6 processes cover verification, integration, testing, and qualification activities.
Automotive organizations across the automotive value chain use Model-Based Design and model-based systems engineering with Simulink to develop electrical and/or electronic (E/E) products that meet and exceed customer, market, and standardizations requirements. When it comes to Automotive SPICE, model-based approaches with Simulink provide a wide spectrum of support to your engineering processes. This is summarized in a tool mapping document that is part of IEC Certification Kit.
For more details, view the webinars in the sidebar.
The wide adoption of Model-Based Design and model-based systems engineering to perform ASPICE engineering processes and base practices can be attributed to automation and simulation capabilities. For example, approaches that use Model-Based Design let you effectively and efficiently perform trade studies early in the design process and let you establish a digital thread (2:36) with full traceability among all your project artifacts, including requirements specification, design, implementation, verification, and validation artifacts. Such capabilities allow engineers to focus on developing state-of-the-art products and innovations and leverage tooling support to achieve process quality aspects such as completeness, consistency, and correctness.
Learn More from Model-Based Design and Model-Based Systems Engineering Case Studies to Achieve Automotive SPICE
Automotive SPICE and the ISO 26262 and IATF 16949 Standards
ISO 26262 is the functional safety standard in the automotive industry. The standard outlines objectives and prescribes necessary requirements and activities that need to be performed to develop functionally safe (i.e., free from unreasonable risk) E/E automotive items by meeting these objectives.
The standard covers the complete safety lifecycle of automotive items spanning the concept, development, production, operation, service, and decommissioning phases. Safety requirements (i.e., what the system is not supposed to do) are identified by performing safety analysis activities, which include hazard analysis and risk assessment (HARA) at the concept phase, failure mode and effects analysis (FMEA), and fault tree analysis (FTA) during product development at the system, hardware, and software levels. Process FMEA is also performed during the production, operation, service, and decommissioning phases.
Whereas ISO 26262 covers the whole lifecycle from the concept phase to decommissioning, Automotive SPICE has more focus on design and development. Automotive SPICE also highlights the importance of bidirectional traceability to ensure consistency, correctness, and completeness.
Furthermore, ISO 26262-2:2018, Clause 5.4.5.1 states that “organizations shall have a quality management system that supports functional safety and complies with a quality management standard, such as IATF 16949 in conjunction with ISO 9001 or equivalent.” Having a quality management system (QMS) is particularly important for software development where all errors are systematic errors. A QMS helps to prevent and detect issues, inconsistencies, and mistakes as early as possible.
On the other hand, IATF 16949 itself refers to Automotive SPICE in FAQs related to clause 8.3.2.3 on development of embedded software. Another important aspect in the relationship between ISO 26262 and Automotive SPICE is the fact that ISO 26262 defines four automotive safety integrity levels (ASIL A to ASIL D). The standard also defines an additional QM class of hazards. Quality management processes (e.g., ASPICE) are sufficient to manage these QM hazards.
During design and development phases, there is a great overlap between ISO 26262 and Automotive SPICE. If you develop according to Automotive SPICE already, you are consequently satisfying multiple requirements from ISO 26262. This is also true for IATF 16949 in general. As such, it is possible and highly recommended to coordinate and harmonize ISO 26262 and ASPICE (and IATF 16949) processes, as well as synchronize ASPICE and functional safety assessments and audits.
Check out this article to learn how IEC Certification Kit can support your ISO 26262 project.
Extensions to Automotive SPICE
Due to the increasing relevance of cybersecurity to the automotive industry, a new cybersecurity supplement was introduced to Automotive SPICE in 2021. The supplement includes four new engineering processes focused on cybersecurity (i.e., SEC.1–4), spanning cybersecurity requirements and their implementation, as well as V&V activities. Automotive SPICE for cybersecurity process reference models is shown in Fig. 5. In addition to cybersecurity, there are existing add-ons to Automotive SPICE to cover hardware and mechanical engineering processes. These add-ons allow you to consider all common mechatronics domains within the scope of Automotive SPICE.
Figure 5. Automotive SPICE for cybersecurity process reference model. It introduces four new engineering processes in addition to MAN.7 and ACQ.2.
Examples and How To
Software Reference
See also: functional safety standards, applying Model-Based Design for ISO 26262 (Training Services), ISO 26262 Process Deployment Advisory Service (Consulting Services)
