Automotive Software Performance Improvement and Capability Determination, or ASPICE, is a standard that provides a framework for defining, implementing, and evaluating the processes required for system development focused on software and system components in the automotive industry. This framework can be extended to include processes from other domains, such as hardware and mechanical engineering, using the “Plug-in” concept described 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 include processes specific to these other domains if they aid in the development and subsequent assessment of a given piece of software.
Integrating other domain-specific processes into the assessment of software performance is vitally important to capture the capabilities of modern software in development, as vehicles become increasingly mechatronic. This means the electronic and mechanical aspects of the 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, among other things, understanding ASPICE and its impact on developers, manufacturers, and suppliers.
Product innovation in the automotive industry has been steadily increasing, largely on the software side. Herbert Diess, 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 increased 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 definition, implementation, and evaluation of appropriate processes for system development and the coordination of all stakeholders (e.g., OEMs, tier suppliers, etc.) more than ever.
ASPICE is becoming a widely adopted standard by OEMs and, therefore, the automotive suppliers that support them. Major OEMs such as Audi, BMW, Daimler, and Ford are evaluating their electronic and software suppliers based on their ASPICE ratings. It provides a more controlled system development process to ensure product quality, shortens the release schedule, and reduces the cost impact of quality issues identified in later stages of product development.
For suppliers, ASPICE proliferation means they must ensure their software development processes comply with the ASPICE standard. This may require them to revise their existing processes or implement new ones 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 consumers. Suppliers whose products are assessed as high-risk may lose business.
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 suppliers’ process quality capability during supplier selection. Understanding a supplier’s product capabilities and identifying areas for improvement can greatly accelerate 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 their process capability.
From powerplant management to connectivity to cybersecurity, OEMs face immense software proliferation. Embedded controllers are found everywhere in modern software-defined vehicles, and as true over-the-air or OTA updates become more feasible, manufacturers have more incentive than ever to ensure that current and future software performs as needed.
OEMs are currently racing to advance EV technology beyond infancy. Hybrid and EV applications require highly specialized, robust power management and monitoring software that 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 infrastructure, especially as Advanced Driver-Assistance Systems become more complex and powerful. As this software continues to grow and proliferate, ASPICE and other frameworks will be instrumental in evaluating the software produced by developers, suppliers, and, increasingly, OEMs themselves. As the functions of individual systems become increasingly interconnected, the need for systematic, coordinated development of the software governing them can only grow. ASPICE becomes more necessary as code propagates and becomes increasingly complex.
ASPICE has its own Process Reference Model (PRM), tailored to 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 its process areas, their scope, purpose, and outcomes. 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 and its unique functional objectives when performed in a particular environment.
Capability Dimension consists of Capability Levels, which are further subdivided into Process Attributes. Process Attributes 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 as a percentage of achievement for a process attribute, as shown 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 significant.
Audits and evaluations are conducted to determine the compliance, or degree of compliance, of an internal process with standard criteria (such as ISO 9001 or ISO 16949). Audits include a reference to a management system.
Assessments, on the other hand, such as those with ASPICE, act as measurement models for specific customer project-related processes. An ASPICE assessment concerns only whether the ASPICE requirements have been met. The assessment will indicate whether a process requires improvement and which one. It will not provide recommendations for improvement.
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, followed by an aggregate level rating (see the 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 required to develop high-performing products and deliver them on time. 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 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 broader System Development topics, so implementing it may provide a framework for meeting ISO 26262 requirements.
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 automatically make an organization or project compliant with ASPICE. Even though both standards share the same core concepts, they use different process assessment models, and there are gaps in the implementation of their process areas.
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.
The ASPICE standard and framework have recently undergone a revision change – the first in many years – in response to evolutionary developments in automotive systems and software. So, what does the ASPICE 4.0 update mean to you?
LHP has always viewed ASPICE as an invaluable tool for improving workflow quality 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, each with requirements for each lifecycle aspect. 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 against the standard can reveal opportunities for process and quality improvements, risk mitigation, and increased market competitiveness.
The ASPICE 4.0 release, with its new rules and structure, increases the standard's power by addressing hardware aspects and aiming to guide the future of development: machine learning. This expansion aligns ASPICE with other industry standards 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, like other software quality systems, to help engineers and developers manage the increasingly complex world of embedded controls and software. ASPICE 4.0 continues that effort, with clarification of requirements and streamlining among its goals.
The change between ASPICE 3.1 vs ASPICE 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 regulatory oversight for the new aspects of machine learning.
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 ASPICE 4.0 Machine Learning Engineering 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 increased automation of both features in the finished vehicle and the processes for designing and developing them. The ongoing work to make autonomous vehicles a more concrete reality, as well as improve and increase the operation and integration of Level 2 and Level 3 advanced driver assistance (ADAS) features, has been a major driving force 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 ASPICE 4.0 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 addresses the absence of dedicated hardware engineering processes in previous versions of ASPICE.
Adding hardware engineering processes to the model enables developers to achieve full coverage of systems and aligns ASPICE 4.0 more closely with other key industry standards, such as ISO 26262:2011, Road Vehicles – Functional Safety, and ISO/SAE 21434:2021, Road Vehicles – Cybersecurity.
Another major change affecting automotive suppliers and OEMs alike is 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 because the system and software landscape in the automotive industry is quite 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.
Since its 2005 release by the VDA, the ASPICE standard has been a resource for automotive manufacturers and suppliers to help manage the rapid proliferation of code, especially in embedded controls. The software and systems defined by embedded controls (and reliant on them) began almost immediately not only to find use in more applications but also to do more in the applications where they were used. In other words, they have been doing more in two senses of the word.
Our current use of these controls, while evolving, is still expanding as the market demands features that are typically possible only with embedded controls or mechatronic systems. These include features related to connectivity and mobility, “infotainment,” and ADAS, among others.
ASPICE is valuable to OEMs and suppliers alike because, like other manufacturing quality standards, it can help tame the chaos stemming from the massive proliferation of code in these essential systems. For developers who choose to adhere to the ASPICE process guidelines, the rewards include enhanced quality due to tighter control and precise monitoring of individual processes, as well as assessment standards that, while not universal (because not everyone follows ASPICE), are at least standardized. Like many manufacturing standards, the ASPICE standard aims to identify, define, and codify best practices for developing embedded control systems and software.
ASPICE has been widely adopted as a software development quality standard. As it proliferates and acceptance or adoption of the standard and its assessment framework spreads across the automotive industry, the additional control that ASPICE provides 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 by suppliers, and to 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 emphasize streamlining and efficiency and reflects earnest consideration of how we design, develop, and apply systems and software for embedded controls in modern automotive manufacturing.
“… 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 market's demands for environmental friendliness, safety, economic efficiency, and user-friendliness drive innovations that become increasingly complex 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 of performance; the expected correlation is that compliance with the ASPICE standard is roughly equivalent to adherence to industry best practices.
One slightly less pronounced change in the new ASPICE standard is the reassignment of the importance of strategies or plan documents in the assessment of processes to Capability Level 2. This change may simplify assessments and developers’ planning in some instances, streamlining at least one segment of the process that can sometimes be 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 for demonstrating 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 revision of ASPICE in many years. This new standard provides significant support for process assessment in mechatronic development and machine learning, as well as new training guidelines for assessors. 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, ASPICE is a valuable tool for engineers in both OEM and supplier settings. In an era of continually increasing software integration and mechatronic complexity, robust application of standardized frameworks such as ASPICE is necessary for developing and maintaining processes that produce high-quality software.
Steve Neemeh : Apr 9, 2024 11:07:33 AM
The Role of ASPICE in Systems and Software Development LHP’s proven process for forging an embedded systems and software development solution helps...
Steve Neemeh : Jan 12, 2021 3:21:01 PM
How to Design Safety Into ADAS Products
Steve Neemeh : Mar 18, 2021 3:13:00 PM
How to Ensure Safety in ADAS Design and Verification
Steve Neemeh