What is ASPICE in Automotive?

ASPICE | What it Means for Automotive

Automotive Software Performance Improvement and Capability dEtermination (ASPICE) as a standard provides the framework for defining, implementing, and evaluating the process required for system development focused on software and system parts in the automotive industry. This framework can be extended to include processes from other domains like hardware and mechanical engineering using the “Plug-in” concept explained in the ISO+IEC 33001:2015 standard family, which governs ASPICE.

In the plug-in concept, developers are given the freedom to pull processes in from other engineering disciplines which are appropriate to the assessment scope. This means ASPICE, while a software standard, can also add processes specific these other domains, if it will aid in the development and subsequent assessment of a given piece of software.

Following the integration of other domain-specific processes into the assessment of software performance is vitally important to capture the capability of modern software in development as vehicles become increasingly mechatronic. This means the electronic and the mechanical aspects of designed components are merging somewhat, becoming less distinct from one another, as their functions combine. Software, hardware, and mechanical processes continue to intersect and integrate as the pace of software innovation increases. The organizations with the most to gain are the ones that can navigate most effectively in the mechatronic environment we will soon enter. Effective navigation in this case means, for one thing, understanding ASPICE and how it affects developers, manufacturers, and suppliers.

Contents

• What ASPICE means for suppliers
• What it means for Original Equipment Manufacturers (OEMs)
• Outline of ASPICE
• Process Reference Model
• Process Measurement Framework
• Relation to other safety standards
  • Functional Safety (ISO 26262)
  • CMMI vs ASPICE
• Conclusion

Product innovation in the automotive industry has been steadily increasing, and that innovation is largely on the software side. Herbert Dies, the chairman of Volkswagen, predicted in 2021 that “software will account for 90% of future innovations in the car.”₁ Informatics professor Manfred Broy goes further, stating that a vehicle’s value is directly tied to the software it contains:

“Once, software was a part of the car. Now, software determines the value of a car,” notes Manfred Broy, emeritus professor of informatics at Technical University, Munich and a leading expert on software in automobiles. “The success of a car depends on its software much more than the mechanical side.” Nearly all vehicle innovations by auto manufacturers, or original equipment manufacturers (OEMs) as they are called by industry insiders, are now tied to software, he says.₂

Product differentiation by electronic features has exploded the number of vehicle platforms and vehicle variants. Each variant is a unique combination of features that will have different interactions and safety risks. This situation mandates the need for the definition, implementation, and evaluation of proper processes for system development and the coordination of all stakeholders (e.g., OEM, tier supplier, etc.) more than ever.

What ASPICE Means for Suppliers

In the automotive industry, ASPICE is becoming a widely adopted standard. Major OEMs such as Audi, BMW, Daimler, and Ford are assessing their electronic and software suppliers based on the ASPICE assessment rating. It provides a more controlled system development process to ensure product quality, shortens the release schedule, and reduces cost impact on the product development due to quality issues identified in later stages of product development.

For suppliers, ASPICE proliferation means that they need to ensure that their software development processes comply with the ASPICE standard. This may require them to make changes to their existing processes or to implement new processes altogether. Failure to comply with ASPICE can result in lost business opportunities and a damaged reputation.

Tier one suppliers must be proactive in ensuring compliance with ASPICE and continuously improving their software development processes, to meet the evolving demands of their customers and the needs of consumers. Suppliers whose products are assessed to carry a high degree of risk may suffer a loss of business as a result.

For a supplier who can dominate the assessment, the adoption of ASPICE standards among OEMs can also mean increased opportunities. Presenting high ASPICE compliance can be a differentiating factor in supplier selection and retention.

What ASPICE Means for OEMs

OEMs can use the ASPICE framework to assess their supplier’s process quality capability during supplier selection. Rapidly understanding a supplier’s product capabilities and knowing where to require improvement can greatly speed up the development and implementation of high-quality software. OEMs can define their own system development process to be ASPICE compliant, which will help them assess and improve the process capability.

From powerplant management to connectivity to cybersecurity, OEMs have immense software propagation to contend with. Embedded controllers are found everywhere in modern software-defined vehicles, and as a true over-the-air (OTA) update function begins to seem more feasible, manufacturers have more incentive than ever to ensure that current and future software performs as needed.

OEMs are currently racing to develop EV technology past its infancy. Hybrid and EV applications require intense and specific power management and monitoring software, all of which must be developed rapidly and remain error-free. Combustion engines, in the perpetual hunt for more power and greater efficiency, will continue to require new and improved software to drive those improvements; this software must also be vetted as it is produced.

Software-defined vehicles are inherently and increasingly connected to each other, and to external infrastructures, especially as advanced driver-assistance systems (ADAS) become more complex and powerful. As this software continues to grow and propagate, ASPICE and other frameworks will be instrumental in evaluating the software produced by developers, suppliers, and, increasingly, by the OEMs themselves. As the functions of individual systems grow increasingly interconnected, the need for systematic and coordinated development of the software governing them can also only grow. ASPICE becomes more necessary as code propagates and becomes increasingly complex.

Outline of ASPICE

ASPICE has its own Process Reference Model (PRM) which is tailored considering the specific needs of the automotive industry. The ASPICE Process Assessment Model (PAM) uses the PRM when performing an assessment.

In ASPICE, capability determination is based on a two-dimensional framework: Process Dimension and Capability Dimension.

The Process Dimension defines the PRM in terms of process areas and their scope, purpose, and outcome. The Capability Dimension consists of the capability levels and process attributes for the process areas identified in the PRM.

Process Reference Model (Process Dimension)

Processes are grouped into categories according to the type of activity they address. Each process is described in terms of a purpose statement, with unique functional objectives of the process when performed in a particular environment.

Process Measurement Framework (Capability Dimension)

Capability Dimension consists of Capability Levels (CL) which are further subdivided into Process Attributes (PA). PAs provide measurable characteristics to determine the process capability.

Process Capability levels are determined by rating the process attributes for each capability level.

The scale above can be represented in the percentage of achievement of a process attribute as below.

Below is a sample of a Process Assessment Model (PAM).

Audit versus Assessment

ASPICE assessments are not audits. This difference may not seem relevant, but in the specialized vocabulary of these frameworks and standard systems, it is an important one.

Audits and evaluations are conducted to determine the compliance, or degree of compliance, of an internal process with standard criteria (like (ISO 9001 or ISO 16949, for example). Audits include reference to a management system.

Assessments, on the other hand, assessments, such as happens with ASPICE, act as a measurement model for specific customer project-related processes. An ASPICE assessment is concerned only with whether the ASPICE requirements have been met. The assessment will show whether a process requires improvement, and it will show which process requires improvement. It will not give recommendations for how to improve.

The assessor can apply an attribute to a process, then evaluate it to determine if the process or its attribute meets the ASPICE requirement. This returns a level statement and then an aggregate level rating (see Process Capability tables, above).

At the customer’s request, ASPICE assessments can be scoped to evaluate for process improvement opportunities, or for product risk items. Both scope choices focus on the capabilities associated with a particular process, to develop high-performing products and deliver them in a timely manner. A process improvement assessment establishes a baseline by identifying process strengths and weaknesses. This allows a supplier to redesign and prepare for a product risk assessment. The second type, product risk assessment, measures the supplier’s ability to supply their customer appropriately in relation to a product release.

Relation to other safety standards

Functional Safety (ISO 26262) / ASPICE

While ISO 26262 and ASPICE are both rooted in standards produced by ISO and the International Electrotechnical Commission (IEC) and their scopes can overlap, their aims are different. Functional Safety as a discipline aims to mitigate the risk of injury or damage from failures in any mechatronic systems on a vehicle. ASPICE does not specify safety but is entirely concerned with evaluating and measuring software systems and their development. ASPICE covers the broader topics of System Development, so implementing ASPICE may provide a framework for implementing the requirements for ISO 26262.

Some key differences between ASPICE and ISO 26262 are as follows.

The similarities are found in the supporting processes such as Configuration Management and Change Management.

CMMI vs ASPICE

Capability Maturity Model Integration (CMMI) compliance does not mean that an organization or project is automatically compliant with ASPICE. Even though both standards look the same in the core concepts, they use different process assessment models, and there are gaps in the process area implementations.

Since ASPICE was developed for the automotive industry, it is a better choice for an OEM or supplier organization to implement in alignment with the rest of the industry. For organizations that have already adopted CMMI and want to implement ASPICE as well, a detailed gap analysis of the current process vs. ASPICE is the best place to start.

Conclusion

As an extensive framework for defining, implementing, and evaluating the process of developing automotive software, the ASPICE rule set is a valuable tool for engineers in either supplier or OEM settings. In an era of constantly increasing software integration and mechatronic complexity, a robust application or adherence to standardized frameworks such as ASPICE is necessary for developing and maintaining processes for producing high-quality software.

1. Robert Charette. "How Software is Eating the Car." 7 June 2021 https://spectrum.ieee.org/software-eating-car
2. Ibid

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