When personal computers first came into common use in the 1980s, the closest a microchip came to an automobile was during transit to its final destination.
Few consumers could have predicted there would come a time when their automobiles would be controlled by computer chips, much less have integrated technologies to manage everything from cell phone calls to satellite radio to entertainment features, GPS mapping, and even drive controls.
The automobile of the 2020s hasn’t just transcended crank starters and wood paneling; today’s automobiles integrate multiple technologies developed by teams across industries all over the globe. The automobile market has evolved to include everything from self- or assisted-driving technology, automated safety features, and various green technologies, including electric and hybrid options.
These marketing forces are creating the following challenges:
- Surge in connected cars
- Autonomous vehicles (AV) disrupt regulations
- Push to electrification of vehicles (EVs) balanced with high technology cost
- Increased mobility services
- Product quality that meets safety-critical standards
RELATED: Jama Connect® for Automotive Solution
With all of these new market demands, it’s not uncommon for automobiles to require over 100 million lines of code. By 2030, a late model auto could require as many as 300 million lines of code. Connected cars can process 25 gigabytes of data per hour and generate over 4 terabytes of data per day.
All of this data means that today’s cars can fall prey to software malfunctions, connection interference, or even hacking. And because lives are in the balance, development teams have more incentive—and responsibility—than ever to get it right from beginning to end.
In this complex world of modern automotive development, many companies are adopting the ASPICE standard for software development to meet these new automotive safety challenges.
What is Automotive SPICE (ASPICE)?
ASPICE started as a variation of the ISO/IEC 15504, or SPICE, standard. SPICE stands for “Software Process Improvement and Capability determination.” The SPICE standard began as a way to provide a framework for independent assessors to evaluate an organization’s capability for software development.
As other teams and manufacturers looked for software suppliers, this SPICE score could serve as one way to evaluate whether the developer can meet certain standards for performance, safety, and quality. Though the SPICE standard didn’t gain much traction in other development fields, it did start to take hold in automotive as German auto manufacturers began using it.
As the standard became focused more toward automotive, the moniker “Automotive SPICE” or “ASPICE” took hold. As it stands now, ASPICE is a process assessment model and a process reference model for software development in the automotive industry. Software teams who design and develop software for the automotive industry should use ASPICE to document processes and measure the maturity of the organization’s processes.
The SPICE standard began as a way to provide a framework for independent assessors to evaluate an organization’s capability for software development.
Fundamentally, the goal of ASPICE is to define best practices for development of embedded software for vehicles.
Given that a modern vehicle can involve hundreds of millions of lines of code, creating some objective “best practices” can only benefit the teams working on this code. And it’s not just how much code is required that adds complexity — it’s also the fact that companies increasingly work across geographic and industry boundaries. When looking for suppliers, having some objective standards of assessment can be useful.
ASPICE is based on the V-Model — a model that requires logical decomposition of requirements and rigorous evaluation through testing at each stage of development. This model benefits both suppliers and system integrators by giving opportunity to eliminate problems in early development stages and providing a framework for ideation and development.
It also ensures continuous innovation and product development. On the left side of the V-Model are initial phases of product development.
- Requirement Analysis: Discovering, listing, and prioritizing client requirements
- System Design: Mapping client needs and putting them into a viable work model
- Architecture Design: Organizing requirements into logical operations
- Module Design: Creating software requirements that match system requirements and developing service units
- Coding: Designing and implementing units; this is the point of the V
On the right side of the V-Model are the secondary phases of product development:
- Unit Testing: Determining if code and design match and standards and requirements are met
- Integration Testing: Evaluating software architecture and service units
- System Testing: Integrating everything into the full system and testing
- Acceptance Testing: Performing final tests
The advantage of the V-model is that it promotes testing and improvement throughout the development cycle. For each point along the V, there is a corresponding testing phase and additional traceability and management processes. Suppliers who follow this ASPICE model can earn certifications according to standardized achievement phases; the ASPICE standard is scored in levels from zero to five, which clients can use to evaluate the proficiency of the development team.
ASPICE levels are as follows:
LEVEL 0 | Basic
Teams at Level 0 are still developing processes or systems. They can, at most, “partially” achieve ASPICE requirements. These teams should focus most of their efforts on managing basic tasks.
LEVEL 1 | Performed
Teams achieving Level 1 either nearly or completely deliver standard ASPICE requirements, but likely have gaps in their processes.
LEVEL 2 | Managed
Level 2 teams can reliably deliver work products and almost or completely achieve ASPICE standards.
LEVEL 3 | Established
At Level 3, teams have established and set performance standards and are engaged in continuous improvement to constantly evaluate and learn.
LEVEL 4 | Predictable
Level 4 teams measure, record, and analyze outcomes; evaluate outcomes and processes objectively; and consistently meet performance standards.
LEVEL 5 | Innovating
Level 5 teams have reached a stage where they are not only consistently delivering high performance and quality products, but also engaging and investing in continuous improvement. These teams also analyze performance standards for quantitative feedback and causal analysis resolution.
ASPICE does not prescribe tools or techniques for teams, but rather gives a framework for examining the approach to internal development methods. The ASPICE standard is mostly generic and largely tool and process “agnostic” — that is, it gives a framework for evaluating the process and outcomes, but does not dictate the best processes or methods for every team. Because every team is different, this generic approach can help bring order and improvement to any team operating in any automotive system or space.
ASPICE levels look daunting, and for a start-up or young team, the idea of achieving Level 5 might seem out of the question. However, it’s important to note that Levels 4 and 5 are aspirational; most teams that achieve these levels are part of very large corporations. Level 2 is a more realistic initial target, and by the time teams are at Level 3, they are functioning at a standard broadly considered “excellent.”
How ASPICE Affects Automotive Development
The world of automotive development is only becoming more complex.
Some factors that are increasing complexity:
Consumer demand: A connected world means that consumers want seamless connectivity across their entire lives. The lines between work, home, and leisure are increasingly blurry, and consumers who still need vehicles to get from point A to point B will want all of those pieces of their lives to be integrated — even behind the wheel.
Increasing regulation: With the increasing complexity of auto systems and a focus on reducing climate impact, auto manufacturers will have to comply with new and possibly shifting regulations across different entities.
Rapid innovation: Technology continues to change and innovate at a breakneck pace. With systems increasingly integrated into automobiles, manufacturers will have no choice but to keep up with innovation. In fact, as of 2019, 80% of product innovation in automotive comes through software development
Fortunately, ASPICE can help auto suppliers and original equipment manufacturers (OEMs) respond to this increasing complexity in multiple ways:
Control the process: ASPICE gives teams clear guidance for evaluating and controlling their development processes, which can help ensure product quality, shorten time to market, and reduce costs.
Streamline supplier selection: By clearly defining levels of achievement, ASPICE can help OEMs assess and evaluate suppliers. If suppliers achieve Level 2 or 3 in ASPICE, OEMs can be fairly certain they are getting quality products.
Reduce costs and improve time to market: Because ASPICE is more concerned with process than with specific regulations or safety guidelines, using the standard can help teams reduce costs and improve efficiency, thereby improving overall market competitiveness.
How to Ensure Compliance with ASPICE
Most automotive developers are rigorously working towards ASPICE compliance and there are many advantages to aiming for it.
1.) It’s possible that compliance will be required some time in the future, so working toward it now is a positive step in preparation.
2.) Automotive development is only getting more complicated, not less, and development will continue to require teamwork across industries, companies, and geographies. Working within the ASPICE standard will help ensure consistency.
3.) Working within ASPICE will give teams a competitive edge over other suppliers and OEMs who are not yet using the standard.
But knowing that compliance is desired and actually achieving it are two different things. How can teams ensure compliance with the ASPICE standard?
Start with an honest assessment.
Teams can’t know where to go until they know where they are. A good place to start is to draft current processes and compare them to the ASPICE V-model. This effort can provide good insights into current levels compliance and where improvements can be made.
Confront the gaps and missing pieces.
Most teams will have some gaps in their processes or procedures. Likewise, some teams will have unclear separation between steps in the V-Model. Look at the gaps and assess how to close them, and identify where additional steps should be introduced.
Include stakeholders.
Be sure that all stakeholders have complete visibility into the ASPICE compliance efforts, and clearly define the resources those stakeholders can provide where necessary.
Test every phase.
Testing is vital to ASPICE compliance. Be sure to include rigorous testing at every phase in the process.
Operate under the new guidelines.
Once the plan is in place, implement it immediately.
Reassess and improve.
After completing a new product under the new ASPICE compliant processes, reassess, evaluate, and look for ways to improve. This constant focus on improvement is what allows teams to achieve higher levels of ASPICE compliance.