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 that are appropriate to the assessment scope. This means ASPICE, while a software standard, can also add processes specific to 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.
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.”1 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.2
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.
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.
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 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.
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.
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.
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).
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 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, and 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 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.
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.
|
ASPICE |
ISO 26262 |
|
This applies to the development of all systems focusing on software and system parts |
Applicable to vehicle systems categorized as safety-critical |
|
Focuses on “Continuous Improvement” of the implemented process for improved capability level |
Does not require process improvements unless there is a gap in compliance with the standard |
|
Requirements Analysis also includes the consideration of cost and schedule impacts on the product development |
There is no consideration of schedule or cost factors: safety is the primary concern of the standard |
|
Focuses on the organization and project level process implementation: the assessment is performed on the organization/project level |
Assessments are performed on the system level to ensure the functional safety objectives are satisfied for the defined safety-critical level of that particular system |
The similarities are found in the supporting processes such as Configuration Management and Change Management.
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.
LHP is a technology integrator and turnkey systems and software developer for applications in many industries, including aerospace, medical, and of course, automotive. We have always been a proponent of the Automotive Software Process Capability dEtermination (ASPICE) framework. ASPICE compliance has been a mainstay of the LHP Functional Safety Ecosystem for the better part of a decade. The ASPICE standard and framework have recently undergone a revision change – the first in six years – in response to evolutionary developments in automotive systems and software. What does the ASPICE 4.0 update mean to you?
LHP has always viewed ASPICE as an invaluable tool to improve the quality of workflows when developing systems for automotive applications. The standard uses process modeling to establish goals for every aspect of the system development workflow. Based on this process model, the entire system development lifecycle is expressed as multiple groupings of processes, with requirements for each aspect of the lifecycle. These process groups are then assessed against capability levels and process dimensions established in the standard and set forth in the framework. Assessing an organization’s processes in relation to the standard can reveal opportunities for process and quality improvements, risk mitigation, and increased competitiveness in the market.
The ASPICE 4.0 release, with its new rules and structure, increases the power of the standard by addressing hardware aspects and attempting to guide the development of the future: machine learning. This expansion aligns ASPICE with other standards being used in the industry for functional safety and cybersecurity. Let's examine what the ASPICE 4.0 update means, and why your organization should explore certification to this new standard.
ASPICE was created, much like other software quality systems, to aid engineers and developers in managing the increasingly complex world of embedded controls and software. ASPICE 4.0 represents a continuation of that effort, with clarification of requirements and streamlining among its goals.
The change between ASPICE 3.1 and 4.0 that would impact organizations the most is the addition of hardware engineering and machine learning process groups. This expands the applicability of the standard to address the entire system lifecycle, by including hardware, and provides regulation for the new aspects of machine learning.
Previous ASPICE 3.1 process reference model:
ASPICE 4.0’s process reference model has been updated to the following:
One thing to note is the addition of three process groups: the Validation Process Group (VAL), the Hardware Engineering Process Group (HWE), and the Machine Learning Engineering Process Group (MLE). As can be seen in the figure above, the color coding groups the processes under three categories: “Primary Lifecycle,” “Organizational Lifecycle,” and “Supporting Lifecycle,” as ASPICE 4.0 has updated the VDA scope to provide an increasingly flexible plugin feature to facilitate the assessment of an organization’s lifecycle processes.
The new and extensive machine learning process group is located within the ASPICE framework’s primary lifecycle processes group. This group of processes was added in response to the proliferation of artificial intelligence (AI) in automotive feature design, as well as the increases in automation of both features within the finished vehicle, and the processes to design and develop them. The ongoing work to make autonomous vehicles (AVs) a more concrete reality, as well as improve and increase the operation and integration of Level 2 and 3 advanced driver assistance (ADAS) features, have been major driving forces behind these increases in automation. The addition of the machine learning engineering (MLE) process group to the ASPICE 4.0 process model projects continued support for this development and engineering work into the future.
The hardware process group was added to the standard as one of the primary lifecycle process groups. This change reflects the extensive use of hardware in modern automotive mechatronic control systems and responds to the absence of dedicated specific processes for hardware engineering in previous versions of ASPICE.
Adding hardware engineering processes to the model allows developers to achieve full coverage of systems and aligns ASPICE 4.0 more closely with other main standards in the industry, such as ISO 26262: 2011, Road Vehicles – Functional Safety, and ISO/SAE 21434:2021, Road Vehicles – Cybersecurity.
Another major change that affects automotive suppliers and OEMs is the fact that the German Association of the Automobile Industry (VDA), has rescoped its guidelines and requirements for the ASPICE framework. This scope change is meant as a clarification and can be represented by the following graphic:
![LSS-[24-004] LHP - Blog - What Does the ASPICE 4.0 Update Mean to You_ - Graphic_02.1](https://www.lhpes.com/hs-fs/hubfs/LSS-%5B24-004%5D%20LHP%20-%20Blog%20-%20What%20Does%20the%20ASPICE%204.0%20Update%20Mean%20to%20You_%20-%20Graphic_02.1.png?width=2160&height=1222&name=LSS-%5B24-004%5D%20LHP%20-%20Blog%20-%20What%20Does%20the%20ASPICE%204.0%20Update%20Mean%20to%20You_%20-%20Graphic_02.1.png)
These changes were necessary since the system and software landscape within the automotive industry is rather different from what it was six years ago. In this way, the updates to the assessment modeling help the standard to keep pace with the latest practices and technologies.
From its first release in 2005 by the VDA, the ASPICE standard has been a resource for automotive manufacturers and suppliers to help manage the surging proliferation of code, especially in embedded controls. The software and systems that are defined by embedded controls (and are also reliant upon them), began almost immediately to not only find use in more applications but also became able to do more in the applications where they were in use. In other words, they have been doing more in two senses of the word.
Our current usage of these controls, while evolving, is still expanding, as the market demands features that are typically possible only with the use of embedded control or mechatronic systems. These include features related to connectivity and mobility, “infotainment,” and advanced driver assistance systems (ADAS), among others.
ASPICE is valuable to OEMs and suppliers alike, because, like certain other manufacturing quality standards, it can act to tame some of the chaos stemming from the massive proliferation of the quantity of code within these essential systems. For the developers who choose to adhere to the ASPICE process guidelines, the rewards are enhanced quality due to the tighter control and precise monitoring of the individual processes, as well as standards of assessment that, if not universal (because not everyone follows ASPICE), are at least standardized. Like many manufacturing standards, the ASPICE standard works toward identifying, defining, and codifying the best practices for developing embedded control systems and software.
ASPICE has seen widespread adoption as a software development quality standard. As it proliferates further, and acceptance or adoption of the standard and its assessment framework penetrates the automotive industry, the additional control that ASPICE gives over multiple processes will further aid systems and software developers.
Demonstrating ASPICE compliance has long been a major aid to OEMs in ensuring the quality of software and systems shipped in from suppliers, and by suppliers as a differentiator to stand out among their peers and compete for business more aggressively. The new revision 4.0 will likely continue that trend, as OEMs and suppliers recommit to training their personnel to take full advantage of the new process models, and the thousands of trained ASPICE assessors worldwide bring their certification into compliance with the new standard.
There has been some discussion of whether ASPICE 4.0 is evolutionary or revolutionary. Most likely, the original 2005 release of the standard is still the best candidate for the label “revolutionary.” And, similarly, this new iteration of the standard is simply an evolution of the original groundbreaking idea. ASPICE 4.0 certainly seems to have an emphasis on streamlining and efficiency and reflects earnest consideration of how we design, develop, and apply the systems and software for embedded controls in modern automaking.
The VDA says of the new ASPICE revision:
“… the current version 4.0 of this standard has been established worldwide and is used by leading OEMs and suppliers to evaluate the development processes of software-based systems in and around the vehicle…. The demands of the market for environmental friendliness, safety, economic efficiency and user-friendliness force innovations with increasing complexity at ever shorter intervals. The associated shorter development times, in conjunction with increasing demands on reliability, make it essential to monitor and improve the development processes in software-based system development1.”
ASPICE 4.0, like the previous iterations of the standard, provides both process reference and process assessment models. There are indicators and markers for performance; the expected correlation is that compliance with the ASPICE standard is much the same as adherence to the industry’s best practices.
One slightly less-pronounced change in the new ASPICE standard is the re-assignment of the importance of strategies, or plan documents, in the assessment of processes to Capability Level 2. This change may simplify assessments and the developers’ planning in some instances, streamlining at least one segment of the process that may sometimes have been confusing for users of the standard.
While this requirement has been altered, it is also worth noting that, even at the lowest capability levels, the developer organization must at least have a vision of how to demonstrate compliance and verification, even if this is not strictly a fully defined “strategy.” The standard still demonstrates rigor and adherence to best practices, while streamlining and building a slightly more forgiving quality into the assessment model.
ASPICE 4.0 is the first new ASPICE revision in six years. This new standard demonstrates significant process assessment support for mechatronic development and machine learning, as well as providing new assessor training guidelines. The revision provides an updated tool for developers, programmers, and technology integrators within the automotive industry, and delivers a fresh new way to use the ASPICE toolset. These innovations help ASPICE to keep pace with the evolution of embedded control systems, their software, and the innovative new ways they are used in automotive development.
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.
Marty Muse : Mar 29, 2021 11:57:42 AM
This blog on 2021 Predictions for Automotive Product and Systems Development was originially published here from Jama Software, and was answered by ...
Karilyn Odom : Mar 5, 2024 3:25:02 PM
Electric Vehicle Considerations for Functional Safety Verification and Validation Testing The functional safety standard for the automotive industry,...
Steve Neemeh : May 23, 2022 10:01:00 PM
The question: When looking at functional safety, what is the difference between being ISO 26262 compliant and being ISO 26262 certified?
Steve Neemeh