ASPICE Traceability Is More Than Linking Requirements: Controlling Change Across the Automotive Supply Chain

This post originates from a short exchange on LinkedIn with Yuchao Luo.  We were chatting about the difficulty in keeping ASPICE traceability under control across R&D teams. Keeping it under control across an automotive supply chain involving OEM engineering groups, Tier 1 suppliers, Tier 2 suppliers, software teams, hardware teams, test organizations, and manufacturing is considerably harder.  I want to point out, that this post is specific to the supply chain and product  development. However, development tools and and testing tools and fixtures should also consider

The problem is not simply whether Requirement 147 links to Test Case 386.

The larger question is whether we can determine what changed, why it changed, which configuration it applies to, what else it affects, what depending changes are required to keep the system intact, who must know about it, and what evidence demonstrates that the resulting system still works as intended.

That makes traceability as much a configuration-management and systems-engineering problem as a requirements-management problem.

And increasingly, AI can help us manage that complexity—but it should help us ask better questions and expose potential consequences, not make engineering decisions for us.

Traceability Must Follow the Product, Not Just the Requirement

In automotive development, a requirement rarely exists in isolation.

A vehicle-level requirement may decompose into system and subsystem requirements distributed across several organizations. Those requirements eventually influence architecture, interfaces, hardware, software, calibration, diagnostics, manufacturing processes, verification methods, and validation activities.

A useful traceability chain might look something like:

But there is another dimension running through that chain:

configuration.

• Which requirement revision?
• Which software build?
• Which ECU hardware revision?
• Which calibration?
• Which interface definition?
• Which supplier drawing?
• Which test procedure?
• Which test-equipment configuration (HIL revision)?
• Which test data – sources and content?
• Which vehicle configuration?

A test result without configuration context may tell us that something passed. It may not demonstrate that the configuration being released passed.

That distinction becomes critical as development becomes more distributed.

Supplier Integration Makes Traceability a Network

The traditional supply-chain diagram is often drawn as below, there are horizontal and vertical components. It is easy to get caught in the trap of focusing on the vertical only, and that can come with not so pleasant consequences.

Actual product integration is not nearly that clean.

A Tier 1 subsystem can depend upon another Tier 1 subsystem. Both may depend upon software, sensors, connectors, semiconductors, communication interfaces, or components supplied by organizations farther down the supply chain.

The result looks less like a hierarchy and more like a network.

Consider a seemingly modest change to an ECU.

It could affect:

• CAN or Ethernet messaging (source of message and message structure)
• network timing
• diagnostic services
• power consumption
• connector pin assignments
• sensor behavior
• another supplier’s ECU
• software interfaces
• calibration
• cybersecurity assumptions
• functional-safety analyses
• manufacturing test
• service diagnostics
• system-level verification

The organization requesting the change may see only its portion of the system.

That is precisely why disciplined configuration management matters.

Configuration Management Provides the Control Structure

Configuration management is sometimes reduced to revision control. That dramatically understates its purpose.

Good configuration management establishes the identity of the product and provides controlled mechanisms for changing that identity.

That means identifying configuration items and maintaining controlled baselines for things such as requirements, architecture, drawings, specifications, interface-control documents, source code, software builds, calibration files, BOMs, test procedures, test results, manufacturing documentation and released product configurations.

When a change is proposed, the question should not simply be:

Can we make this change?

The better question is:

What are the consequences of making this change to the system and the organizations responsible for delivering it?

That requires impact analysis before acceptance.

Traceability Across Suppliers Requires More Than a Common Tool

There is a temptation to believe that putting everyone into the same PLM, ALM or requirements-management environment solves traceability.

Tools help.

They do not eliminate the underlying management problem.

Different suppliers may use different requirements tools, PLM systems, source repositories, test-management platforms and internal configuration-management processes. Forcing every participant into one tool may not even be practical.

What matters is establishing the information relationships and controls.

At subsystem boundaries, I want to know:

• What is the configuration item?
• Who owns it?
• What is its current approved revision?
• What requirements does it satisfy?
• What interfaces does it have?
• What other configuration items depend upon it?
• What evidence verifies it?
• What changes are pending?
• Which suppliers are affected?
• Has the impact analysis been completed?
• Has the resulting configuration been verified?

This can be supported through unique identifiers, controlled baselines, interface-control documents, requirements traceability matrices, change-control records, versioned supplier deliverables, configuration status accounting and formal release records.

The objective is not documentation for documentation’s sake.

The objective is system awareness.

Don’t Let Schedule Pressure Eliminate Thinking Time

When I was working on my engineering degree, I lived out of a room in an old house.  There was an old ex-Navy gentleman (Lou) that had a room there also. He used to say “make haste slowly”.  He is also the guy who drank my bottle of rum. At the time I thought odd, but I get the truth in this.  One of the recurring problems in product development is the belief that disciplined analysis takes too much time.

A change appears.

The program is already behind.

Someone says:

“We need to accept this today.”

That may save several hours today and cost several weeks later.

Complex systems punish incomplete thinking.

A disciplined change process needs enough time to identify the affected configuration, examine upstream and downstream traceability, determine interface consequences, engage affected suppliers, assess verification needs and document the decision.

Not every change requires a week-long review.

The depth of the review should be proportional to the potential consequences.

A documentation correction might require minutes. An ECU interface change affecting multiple subsystems may require a structured cross-functional review.

The important point is that time for impact analysis must be treated as development work—not administrative overhead.  Identifying what should belong under configuration management and managing the changes is not a single person or department role.  This will require communication throughout the system and development pipeline.

Speed comes from making informed decisions quickly, not from skipping the work required to make them informed.

AI Can Become an Impact-Analysis Assistant

This is one area where I see significant potential for AI.

Automotive programs already generate enormous quantities of structured and unstructured information: requirements, specifications, interface documents, drawings, change requests, BOMs, test procedures, test results, FMEAs, issue reports and supplier documentation.

Humans cannot continuously cross-check every relationship manually.

AI can help.

Before approving an engineering change, an AI-enabled workflow could examine the proposed change against the available engineering baseline and flag potential consequences.

For example:

Proposed change: Modify message timing for an ECU communication signal.

An AI-supported review might identify:

This signal is referenced by three subsystem requirements, two interface specifications, four software components and six verification procedures. Two external suppliers consume this signal. Existing system-level timing requirements may require reevaluation.

That does not mean AI should approve or reject the change.

It means AI gives the engineer or change-control board a better starting point.

Use AI to Ask “What Are We Missing?”

AI can be particularly valuable as a vetting and alert mechanism.

Before accepting a change, it can help search for relationships that may otherwise remain hidden:

Requirements impact
Which upstream and downstream requirements could be affected?

Interface impact
Does the change alter electrical, mechanical, network, software or diagnostic interfaces?

Configuration impact
Which released or developmental configurations contain the affected item?

Supplier impact
Which suppliers provide or consume the affected interface or component?

Verification impact
Which test procedures, test cases and qualification activities may need to be repeated?

Manufacturing impact
Do work instructions, tooling, fixtures, end-of-line tests, PFMEAs or Control Plans require changes?

Risk impact
Does the proposed change affect assumptions contained in DFMEA, functional-safety, cybersecurity or other risk analyses?

AI becomes another mechanism for challenging our assumptions.

The engineer remains responsible for determining whether those relationships are real and what actions are appropriate.

AI Also Needs Configuration Control

There is an important catch.

AI cannot perform meaningful impact analysis if we give it uncontrolled information.

If the AI is searching five versions of an interface specification, three obsolete requirements sets and an outdated BOM, the resulting analysis can be confidently wrong.

Therefore, AI does not eliminate configuration management.

AI makes good configuration management more valuable.

The AI system needs to know which documents and data represent the applicable baseline. Ideally, its output should also identify the sources and revisions that produced its conclusions.

We should be able to ask:

“Why did you flag this?”

And receive traceable evidence rather than simply an answer.

A Practical Change-Control Sequence

For significant changes affecting distributed automotive systems, I prefer a disciplined sequence:

1. Identify the proposed change.
Define precisely what is changing and why.

2. Establish the applicable baseline-assemblies and sub-systems, and systems.
Identify the requirements, hardware, software, calibration, interfaces and supplier configurations involved.

3. Perform automated impact screening.
Use traceability tools and AI to search requirements, interfaces, configuration items, supplier dependencies, risk analyses and verification artifacts.

4. Conduct engineering review.
Have the responsible engineers evaluate the identified relationships and determine which consequences are technically credible.

5. Engage affected suppliers.
Do not assume that an apparently internal change remains internal.

6. Determine verification consequences.
Identify what must be inspected, analyzed, demonstrated or tested again.

7. Make the change decision.
Accept, reject, modify or defer the proposed change based upon evidence.

8. Update the baseline and traceability.
If accepted, ensure requirements, configuration items, supplier releases and verification artifacts remain synchronized.

9. Verify the resulting integrated configuration.
The final evidence must demonstrate that the changed system—not merely the changed component—performs as intended.

That process takes time.

It also consumes considerably less time than discovering the overlooked dependency during vehicle integration.

Traceability Should Support Decisions

ASPICE traceability should never become a contest to see how many links we can create in a requirements-management tool.

The value of traceability appears when something changes.

Can we move from a failed system test back to the responsible requirements, design decisions, software version, hardware configuration and supplier?

Can we move in the other direction?

When a supplier changes a component, can we identify the vehicle functions, subsystems, interfaces, risks and verification evidence that may be affected?

That is useful traceability.

The Goal Is Controlled Change, Not Frozen Change

Automotive development requires change.

Requirements evolve. Software evolves. Components become unavailable. Suppliers identify better solutions. Testing exposes assumptions that were wrong. Manufacturing discovers conditions engineering did not anticipate.

Trying to prevent change is unrealistic.

The objective is to make change visible, traceable, critique-able and deliberate.

Configuration management gives us control of the baseline.

Traceability shows us the relationships.

Systems engineering helps us understand the interactions.

Verification provides the evidence.

AI can help us search the growing body of engineering information for consequences we might otherwise miss.

And disciplined engineering gives us the time to consider that evidence before we make the decision.

That combination becomes increasingly important as automotive products become more software-intensive, interconnected and distributed across multiple suppliers.

The question should no longer be simply:

“Is this requirement traceable?”

A more useful question is:

“If this changes today, can we determine what else changes tomorrow?”

That is where traceability becomes a practical engineering capability rather than a compliance exercise.

For more information, contact us:

The Value Transformation LLC store.

Follow us on social media at:
Amazon Author Central https://www.amazon.com/-/e/B002A56N5E
Follow us on LinkedIn: https://www.linkedin.com/in/jonmquigley/
https://www.linkedin.com/company/value-transformation-llc
Follow us on Google Scholar: https://scholar.google.com/citations?user=dAApL1kAAAAJ