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.
ASPICE
ISO 26262
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 to 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.
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.