In software-defined vehicles, the real trouble starts between the boxes on the process diagram
A few weeks ago, I wrote about why Automotive SPICE matters more — not less — in the era of software-defined vehicles. The response on LinkedIn was encouraging. It also reinforced something I have noticed in conversations with automotive engineering teams: everyone agrees that complexity is increasing. The real question is where is that complexity is causing the biggest problems?
The obvious answer is “the process.” I am not convinced.
Most established automotive organizations solid have processes. They have requirements templates, architecture reviews, change boards, test plans, supplier checkpoints and enough acronyms to make a bowl of alphabet soup look underqualified. They may even have good tools supporting each discipline.
The trouble is what happens between them.
A system requirement changes, but the software team does not see the effect until a sprint is already underway. A supplier delivers a component against an earlier interface definition. A test fails, but it takes three meetings to establish which requirement the test was intended to verify. An assessor asks for objective evidence and the evidence exists — somewhere — in several repositories, a spreadsheet and an email thread nobody wants to admit is important.
None of those failures begins with an Automotive SPICE assessment. The assessment simply makes them difficult to ignore.
The handoff is where good processes go to get lost
Automotive SPICE is often discussed as a collection of processes: requirements analysis, system architecture, software development, verification, validation, project management and supporting practices. That structure is necessary. It gives organizations a disciplined way to evaluate how work is performed.
As we know, real engineering does not happen in tidy process boxes. It moves sideways.
A customer need becomes a system requirement. That requirement influences an architectural decision. The system design determines what the hardware does and what the software does. Software requirements become code and tests. A defect travels backward through the same chain. Changes can enter from almost anywhere: a new regulation, a supplier limitation, a safety analysis, a cybersecurity finding or an executive who has discovered that a competitor’s vehicle does something interesting.
Every one of those movements is a handoff. Every time work moves from one team, tool, or supplier to another, important details can be misunderstood, changed, or lost.
That was manageable when a vehicle program had relatively stable functions and a familiar set of electronic control units. It is much harder when software is shared across vehicle lines, features depend on cloud services, development is distributed among OEMs and suppliers, and functionality continues evolving after launch.
The vehicle may be software-defined. The organization is still often spreadsheet-coordinated.
Traceability is not a collection of hyperlinks
This is where teams can fool themselves about traceability. They may have links between requirements, tasks, and tests, but still be unable to see what a change affects or prove that the work was completed correctly.
A link proves that two artifacts were connected at some point. It does not automatically prove that the relationship is correct, current or understood.
Useful traceability should help answer practical questions:
- What downstream work is affected by this requirement change?
- Which software and hardware components implement this behavior?
- What evidence shows that the current requirement was verified?
- Which defects, risks or cybersecurity concerns remain open?
- Did the supplier build against the same approved baseline we did?
- Who reviewed the change, and what did they know when they approved it?
If answering those questions requires a small archaeology expedition, the organization does not have a traceability problem in the narrow sense. It has a decision problem.
Engineers cannot make good decisions if they do not understand what a change will affect. Managers cannot tell whether a project is ready from status reports that are not backed by engineering data. Assessors cannot approve a process if they cannot trace its results from beginning to end.
The point of traceability is not to create a prettier audit trail. It is to make the next engineering decision less speculative.
Software-defined vehicles make coordination even harder
The current version of Automotive SPICE reflects a broader engineering reality. Automotive SPICE 4.0 expanded the model’s treatment of systems and introduced process groups addressing hardware and machine learning engineering. The Automotive SPICE for Cybersecurity extension adds another set of concerns that must connect to the rest of development rather than live in a separate compliance folder.
That matters because the biggest risks no longer stay within one team or one discipline. A cybersecurity requirement, for example, does not belong only to the security team. It can affect the system design, software interfaces, testing, and how the vehicle is monitored after it is on the road.
A hardware limitation can lead to a software change. That change can affect performance. If nobody sees the connection early enough, it becomes a late and expensive surprise.
You can have good people in every area and still run into trouble if the information connecting their work is incomplete or unreliable.
Another process meeting usually will not fix this. Teams do not need another place to report status. They need a reliable way to keep the important details connected as work moves between people, departments, suppliers, and tools.
The handoff between automakers and suppliers matters most
Some of the weakest handoffs are also the most commercially sensitive: the ones between OEMs and suppliers.
Both sides may be following documented processes. Both may be producing the required artifacts. Yet they can be operating with different baselines, different interpretations of a requirement and different ideas about what constitutes sufficient evidence. The usual response is to exchange more documents.
Documents are necessary, but documents are snapshots. They are good at showing what was true when the file was generated. They are less effective at showing what changed afterward, why it changed and which downstream work should now be questioned.
This does not mean every supplier must use the same tool as the OEM. That is usually not realistic. It does mean the information exchanged between them needs structure, version control and an agreed meaning. The transfer cannot end with “the file was sent.” Someone needs to be able to answer: Which version did the supplier agree to build? How did they break it down into their work? What proof did they provide that it was done? And did everyone account for changes made afterward?
Otherwise, the contractual handoff and the engineering handoff become two different things.
That gap can stay hidden for months. Then a failed integration test reveals it all at once.
A better question to ask before the next assessment
When an assessment is coming, teams often start looking for missing documents. Sometimes that is necessary, but by then you are already playing catch-up.
A better test is to pick one real requirement that changed after development started and follow it all the way through. Look at the original request, what the team thought it would affect, changes to the design and software, what was shared with suppliers, how it was tested, and who approved it.
Do not rely on a slide deck showing how the process is supposed to work. Look at what actually happened.
Where did the trail become ambiguous? Where did someone manually re-enter information? Where was a document exported and then disconnected from its source? Where did the team rely on a person’s memory to explain why a decision made sense?
Following one real change through the organization will tell you far more than another generic process review.
It may also show that you do not need to replace every tool. Often, the better first step is to connect the information already in those tools, make it clear who owns each connection, and show people what a change will affect.
IBM Engineering Lifecycle Management can help by connecting requirements, designs, plans, tests, and other engineering evidence. But the software alone will not fix the problem. The way teams use it still has to match how they actually make decisions and hand work to one another.
No tool can rescue a process the organization has never agreed upon. On the other hand, a good process held together by exports, spreadsheets and institutional memory will eventually reach its limit.
The assessment shows you what is already there
Automotive SPICE gets blamed for creating bureaucracy, but most of that bureaucracy was there already. The duplicate spreadsheets, disconnected tools, and confusion over who owns what did not appear because of the assessment.
The assessment just makes the problem harder to hide. It asks a simple but uncomfortable question: can you show how the work was done, who made the decisions, and whether the same process would work again on the next program?
With software-defined vehicles, no one department can answer that alone. A requirement may affect the system design, software, hardware, safety, cybersecurity, suppliers, and testing. The important question is whether those connections are visible when a change is made.
Organizations that manage those connections well do more than make assessments easier. They find problems earlier, understand the impact of changes sooner, and spend less time trying to reconstruct why a decision was made six months after the person who made it has moved on.
That is the practical value of Automotive SPICE. It is not just something to prepare for when an assessment is coming. It shows whether engineering information is moving through the organization in a way people can trust.
PS — Join us at NASPICE in Novi, MI Sept 29–30th
