When Every Component Passes but the Vehicle Still Fails 

Distributed Features, Supplier Integration and the Growing Cost of Automotive Complexity

I reviewed 6,038 NHTSA recall campaigns in preparation for a chat with John McElroy from Autoline and Rachel Evens from UKiMedia.  I reviewed reports between 2020 and September 2026; one conclusion became increasingly clear: many vehicle failures cannot be understood by examining a single component in isolation. Modern distributed automotive features depend on hardware, software, calibrations, networks, and supplier subsystems working together under changing operating conditions. A sensor, controller, or software module may meet its individual specification while the complete customer-facing feature still fails because of an interface, timing, configuration, or system-integration problem. This makes automotive quality more than a component issue—it is a product-development, supplier-management, and systems-engineering challenge.

A sensor, ECU, software module, and actuator may each satisfy their individual specifications, yet the customer-facing feature can still fail. This specific event is in the data, along with many other similar events. 

What 6,038 NHTSA Recall Campaigns Tell Us

Some interesting findings, well, at least I found this interesting.  I confess that I thought this would likely lay out a little differently based on experience.  From experience, I expected the difficulty to stem from software.  Software has a reputation for being invisible, complicated, and interacting in complex ways within and beyond the system.  Hardware is typically visible and tangible, but it remains complex.

• Approximately 30% involved mechanical or vehicle systems.
• Approximately 17% involved electrical or electronic systems.
• Approximately 10% involved software, firmware, or calibration.
• Less than 4% involved batteries, EVs, or high-voltage systems.
• Approximately 72% involved hardware categories requiring significant supplier coordination.
• Approximately 15.5% used software updating, reprogramming, or reflashing as part of the remedy.

One qualification: supplier-relevant does not mean supplier-caused. NHTSA generally identifies the failed system, not which organization was responsible. 

Another element: the supply chain has expanded greatly over the years, sub-assemblies come from all over the world, and managing these changes requires robust configuration management and systems mapping to understand the consequences and control of even the smallest changes.

The Recall Is Rarely as Simple as Its Component Name

Vehicle systems are complex and complicated. In the olden days, there were few electronic control units (ECUs).  However, we have always been working with systems. A system isn’t just installed on the vehicle; it also includes the mechanisms that deliver the product. The failure symptom may not have only a passing connection to the observed malady.  

Potential sources behind a component-level failure

In reality, many reasons can cause a latent system defect that results in a recall.  Below is a short list of individual reasons; however, many combinations of versions and variations in system components and the vehicle application can cause issues.  We can use standards, such as SAE J-1455, which recommends environmental practices and testing guidelines for electronic equipment used in heavy-duty vehicles, to develop requirements for the components we will later test.

• Incomplete requirements
• System incompatibility
• Misunderstanding of the range of stimuli to which the product can be subjected
• Misunderstanding of the combination of stimuli to which the product can be subjected
• Incorrect software or calibration
• Hardware revisions
• Manufacturing variation
• Assembly and installation errors
• Configuration mismatches
• Network timing
• Supplier-interface assumptions
• Ineffective corrective actions

 

 

Distributed Features Create Distributed Failure Modes

Many vehicle features no longer reside within a single component or ECU. A customer-facing feature may depend on sensors, software, network communications, gateways, controllers, actuators, and displays supplied by several organizations. Each component can meet its individual requirements and pass its own verification testing while the complete feature still fails at the vehicle level.

The failure often exists between the components rather than within them. A message may arrive too late, two controllers may interpret a signal differently, or a software calibration may not match the installed hardware revision. One supplier may assume another subsystem will detect a fault or provide a degraded operating mode. These assumptions can remain hidden until the systems are integrated under an unanticipated operating condition.

Distributed features also create shared dependencies. Several functions may rely on the same sensor, network, power source, clock, or central controller. A failure in one shared service can therefore affect multiple features that appear unrelated to the driver. The wider the dependency, the greater the potential vehicle population and recall exposure when a common problem reaches production.

This is why component-level testing is necessary but insufficient. Requirements, configuration control, and verification must follow the entire feature from the customer need through the sensors, networks, software, controllers, and actuators that deliver it. Distributed features require end-to-end ownership, system-impact analysis, and testing under nominal, degraded, and faulted conditions. The objective is not simply to prove that every component passed; it is to demonstrate that the complete feature performs safely and reliably as part of the vehicle.

• Sensors
• ECUs
• Software applications
• Vehicle networks
• Gateways
• Actuators
• Shared computing services
• Multiple suppliers

Everything passes, but fails

Traditional verification often divides the vehicle into manageable components. Teams test the sensor, the ECU meets its requirements, the actuator performs within spec, and the software passes unit and integration tests. Each team can show its deliverable passed, yet the complete feature can still fail.

One reason is the cumulative effect of component variation. A sensor may produce an acceptable but slightly different signal response, a wiring harness may introduce additional resistance, a connector may affect signal quality, and an ECU may interpret the input near its detection threshold. None of these components is necessarily defective. However, their combined variation can cause intermittent detection, delayed response, or feature loss under certain operating and environmental conditions.

Variation

Component variation can also affect system performance. The sensor, network, controller, and actuator may each meet their individual requirements, but changes in their combined behavior can extend total response time beyond what the vehicle-level feature requires. Individual components pass, but the customer experiences a feature that reacts too slowly, inconsistently, or differently across vehicles.

Configuration adds another layer of risk. Testing may have used one combination of hardware, software, calibration, wiring, and supplier content, while production vehicles contain another. A revised component, alternate supplier, material change, or manufacturing-process adjustment can change electrical or performance characteristics without making the component individually noncompliant. Those differences may affect diagnostics, software thresholds, network behavior, or interactions with adjacent systems.

This is the difference between verifying the parts and validating the feature. Component testing demonstrates that each item meets its own specification. End-to-end feature testing determines whether the complete system remains safe and reliable across realistic component variation, environmental conditions, production configurations, and operating scenarios. Passing components do not guarantee a passing system when their combined behavior changes feature performance.

• Messages arrive too late.
• Data becomes stale.
• Signal scaling is inconsistent.
• Software and hardware versions are incompatible.
• Suppliers make different interface assumptions.
• Two features compete for the same actuator.
• Fault ownership is unclear.
• The complete operating scenario was never tested.

Distributed vehicle features create distributed failure modes.

Hardware Updates

Hardware Updates Can Behave Like Software Updates. Software changes are widely recognized as potential sources of system-level risk, but hardware updates can create similar consequences. A revised sensor, connector, wiring harness, controller, battery module, or mechanical component may retain the same basic function and still change how the complete system behaves.

A new hardware revision can alter electrical characteristics, signal response, thermal performance, mechanical loading, network behavior, or diagnostic thresholds. Even when the updated component meets its individual specification, its variation may interact differently with existing software, calibrations, and adjacent components. A physically interchangeable part is not necessarily functionally equivalent within the complete vehicle.

Hardware changes can also propagate across organizational boundaries. A supplier may revise a material, production process, or internal component without recognizing how the change affects another supplier’s subsystem. The OEM may approve the change based on component-level evidence without repeating the vehicle-level tests that established the original configuration. The change may seem minor until it causes intermittent failures, diagnostic issues, or degraded features under specific operating conditions.

This is why hardware revisions require the same configuration discipline applied to software releases. Link the change to requirements, drawings, EBOM and MBOM records, DFMEA, PFMEA, Control Plans, software and calibration baselines, affected vehicle configurations, and verification evidence. Review and update APQP and PPAP artifacts based on the change’s impact—not simply because the part number remained the same.  In fact, based on experience, we may want to change the part number to segregate and trace the new from the old.

The right question isn’t just, “Does the revised component meet its specification?” The more important question is, “What else in the vehicle could this change affect?” Hardware updates should trigger system-impact analysis, supplier-interface review, and appropriate regression testing from the component through the complete customer-facing feature.

• Signal ranges
• Response times
• Electrical loading
• Thermal behavior
• Network communication
• Software thresholds
• Diagnostics
• Mechanical tolerances
• Electromagnetic compatibility

Physical interchangeability is not functional equivalence

A sensor can fit the mounting location and connect to the harness yet deliver a signal the controller cannot correctly interpret. Pin assignments, signal characteristics, response time, and calibration matter. Substitution requires verification of the resulting system behavior.

The connector fits. Does the system work?

Recall / Excel row	Affected vehicles	Sensor or harness issue	System impact
24V798000 — row 1662	2023–2024 Nissan Z; 4,036 vehicles	Right-side pedestrian detection sensor connectors may be reversed in the front bumper harness. Remedy: replace the harness.	Pedestrian protection pop-up hood may fail to activate.
21V094000 — row 5165	2021–2022 Great Dane Champion and 2022 Everest trailers; 1,770 units	ABS sensor cables may be plugged into the wrong ECU ports. Remedy: inspect and correct connections.	ABS may malfunction.
24V021000 — row 2422	Certain 2019–2024 Lode-King trailers; 6 units	ABS computer may have reversed sensor connections.	During wheel lockup, the system may activate brakes on the opposite side of the trailer.
22V434000 — row 3844	2022 Isuzu NQR/NRR gasoline trucks; 974 vehicles	Engine harness incorrectly wired to the oil pressure sensor. Remedy: correct the connector wiring.	The driver may not receive a low-oil-pressure warning, potentially causing the engine to stall.
22V042000 — row 4228	2021 Mercedes-Benz AMG GT Black Series; 172 vehicles	The front wheel speed sensor harness may be the wrong length, allowing damage while driving.	Stability control, traction control, and ABS may be impaired.

What other requirements, components, software functions, manufacturing processes and test cases could this change affect?

Software Updates Are Both Remedy and Risk

In this recall dataset, 15.5% of campaigns involve software updates or reprogramming as part of the remedy. That does not mean software caused 15.5% of the failures. Software can compensate for hardware behavior, modify diagnostic thresholds, or provide a safer degraded operating mode when a component fails. The remedy tells us how the manufacturer intends to address the problem. It does not, by itself, establish the root cause.

I hold a perhaps controversial view of remote downloads. I think some companies use remote updates to justify releasing software before they have adequately vetted it. The reasoning is tempting: release now, gather field experience, and fix problems in the next download. We used to call this SPT: Series Production Testing. The customer becomes part of the test program, whether they understand that role or not.

Remote updates can shorten the time between identifying a defect and deploying a correction. That is valuable. However, delivering a correction quickly does not prove the original release—or the correction—was sufficiently tested. Also, the 15.5% figure includes updates and reprogramming generally; it does not establish how many remedies were delivered remotely.

For distributed automotive features, an update must work with the hardware, calibration, wiring, and other software versions present in the vehicle. A change that corrects one behavior can affect timing, diagnostics, or another controller’s interpretation of a signal. Verification must therefore cover the affected feature and its interactions, including degraded operation and recovery from an interrupted update.

The ability to update a vehicle after delivery should strengthen our response to defects. It should never become our justification for releasing an inadequately verified product.  However, this requires some prerequisites.

Controls required for vehicle updates

A vehicle update changes an operating system of interacting hardware and software. Before we release it, we need to know which vehicles can accept the change, what behavior it affects, and what evidence demonstrates that the resulting configuration works.

Configuration management is the foundation. “The vehicle has the latest software” tells us very little without knowing the rest of its configuration. Which controller hardware revision is installed? What sensor and harness variants? Are there specific calibrations? What software versions are running in the controllers that exchange information with the updated module?

Consider a hypothetical replacement sensor that fits the original mounting location and connector but has a different output characteristic. An updated controller calibration correctly interprets that sensor. However, vehicles retaining the original sensor still require the original calibration. Sending the new calibration to every vehicle could correct one population while introducing an error into another.

We must therefore control the approved combination of sensor, harness, controller hardware, software, and calibration. We need traceability from that approved combination to the individual vehicle, including changes made during service. The production record alone becomes insufficient once a repair changes the installed configuration.

Each control contributes evidence needed to release and support the update:

• Configuration management: Identify approved combinations, record what is installed, and determine which vehicles are eligible for the update. Preserve configuration history so you can trace failures to specific changes.

• Compatibility verification: Confirm that the update works with the installed hardware, interfaces, calibrations, and communicating controllers. Check signal interpretation, message content, timing, and diagnostic behavior.

• Regression testing: Demonstrate that the correction preserves previously working functions. Extend testing to interacting features and operating conditions identified through change-impact analysis.

• Release documentation: Describe what changed, why it changed, applicable configurations, prerequisites, test evidence, known limitations, and installation instructions. Give engineering, manufacturing, service, and support a consistent account of the release.

• Cybersecurity controls: Authenticate the update source, verify package integrity, control authorization, and protect the update process against unauthorized modification or installation.

• Rollback and recovery: Define how the vehicle returns to a safe, usable condition if installation fails or the update causes unacceptable behavior. Verify that any rollback remains compatible with the hardware and stored data.

• Vehicle-variant verification: Cover the affected combinations of powertrain, options, model year, market, and service replacements. Document the basis for treating variants as equivalent where representative testing is used.

• Post-update monitoring: Track installation failures, diagnostic changes, customer complaints, and unexpected behavior against the actual vehicle configuration. Establish criteria to stop deployment and investigate adverse results.

Without configuration management, we cannot definitively assess component compatibility.

Supplier-Relevant: Not-Caused

Approximately 72% of the NHTSA recall campaigns I reviewed involved hardware categories that normally require substantial supplier coordination. That does not mean suppliers caused 72% of the recalls. NHTSA generally identifies the affected component or vehicle system, but it does not consistently identify whether responsibility rests with the supplier, the OEM, software development, manufacturing, service, or the interaction among them.

A supplier can manufacture a component exactly to the approved drawing and still become associated with a vehicle-level failure. The specification may be incomplete, an interface requirement may be ambiguous, or another subsystem may have changed after the component was validated. Hardware, software, and calibration may not match. A supplied component can meet its requirements while its variation changes the performance of the complete feature.

Responsibility becomes even harder to isolate when several suppliers contribute to a distributed feature. One supplier may provide the sensor, another the controller, another the actuator, and additional organizations may develop the network, software, and calibration. Each supplier may verify its own deliverable against the information provided, while no one adequately verifies the complete chain under realistic operating and production conditions.

This is why supplier capability must extend beyond manufacturing a conforming part. Suppliers need practical knowledge of APQP, PPAP, DFMEA, PFMEA, Control Plans, MSA, SPC, configuration management, and engineering-change control. These methods create a common evidence system that connects product requirements, design risks, manufacturing risks, process controls, and verification results. They also give the OEM and supplier a disciplined way to evaluate whether a proposed change affects other components, interfaces, or vehicle functions.

Supplier quality should therefore focus on collaboration and evidence rather than automatically assigning blame. OEMs and suppliers must jointly clarify requirements, manage interfaces, evaluate changes, and confirm vehicle-level performance. A supplier-relevant recall shows the supply chain contributed to the product—not that one supplier independently caused the failure.

• The specification was incomplete.
• Variation in components, systems, and applications was unaccounted for
• Interface requirements were ambiguous.
• A different subsystem changed.
• Software did not match the hardware revision.
• Manufacturing variation was overlooked.
• Vehicle-level testing did not cover the interaction or range of variations and combinations

Suppliers are development partners

Suppliers should not be treated as organizations that receive a finished drawing, manufacture a part, and submit it for approval. This is not a new theme; I have worked on many OEM projects that include suppliers in developing the technology and the product. Suppliers are often selected by their commitment to growing their technology knowledge and application (see Technology Readiness Level).  In modern vehicle development, suppliers often have detailed knowledge of component technology, manufacturing processes, material behavior, and operating limits that the OEM needs to make sound system decisions. That knowledge provides the greatest value when it is included early—not after a design has been released or a problem has reached production.

Supplier participation should begin with requirements reviews. The objective is not merely to confirm that a requirement can be met, but to identify ambiguity, conflicting expectations, missing operating conditions, and assumptions that may affect the surrounding system. A supplier may recognize that a specified signal range, temperature limit, response time, or material requirement creates risks that are not apparent at the vehicle-requirement level.

Interface reviews are equally important. The supplied component must operate within mechanical, electrical, software, network, thermal, and diagnostic interfaces. These boundaries often create failures because each organization controls only part of the interaction. Jointly reviewing the interface makes assumptions visible and establishes ownership of each requirement, signal, response, and fault condition.

Change Management

Suppliers must also participate in engineering-change decisions. A change to a component, material, process, software version, or manufacturing location can affect vehicle functions beyond the part itself. The supplier can explain internal changes, while the OEM and other affected suppliers evaluate the consequences across the vehicle configuration.

Risk analysis should combine supplier process knowledge with OEM system knowledge. DFMEA, PFMEA and related analyses are strongest when the organizations examining product risks understand how design variation, manufacturing variation and feature interactions can combine. The objective is not to produce separate risk documents that satisfy contractual requirements; it is to develop a shared understanding of how the product can fail.

Verification planning should likewise include supplier input. Suppliers may conduct component and subsystem testing, but the evidence must connect to vehicle-level requirements and realistic configurations. The parties should agree on what to test, at what level, using which configuration, under what environmental conditions, and how the results will support the release decision.

Finally, suppliers should participate in corrective-action evaluation. Corrective action is not complete because one component was replaced or one process was adjusted. The team must confirm the failure mechanism, determine whether the proposed action addresses the system-level cause, and verify that the change does not introduce another problem.

Treating suppliers as development partners does not remove accountability. It makes accountability more effective by connecting supplier knowledge to requirements, interfaces, changes, risks, testing, and field evidence throughout the product lifecycle.

• Requirements reviews
• Interface reviews
• Engineering changes
• Risk analysis
• Verification planning
• Corrective-action evaluation

Global Supplier Integration and Project Management for Automotive Engineers

Roopa Shenoy and I explored many of these cross-organizational challenges in the SAE International book Project Management for Automotive Engineers: A Field Guide.

We are also exploring opportunities to bring our SAE International Project Management for Automotive Engineers: A Field Guide and its practical automotive-development lessons to Turkey through the Bursa Branch of the Chamber of Mechanical Engineers (MMO).

Bursa’s automotive OEM and supplier community provides a relevant environment for discussing distributed product development, supplier integration, configuration management, and vehicle-level quality.

Integration Tools

Supplier familiarity with APQP and PPAP must extend beyond knowing the terminology, completing templates, and submitting a package before production. These methods are intended to integrate product design, manufacturing readiness, risk management, verification, and change control across the OEM and supplier network.

APQP provides a structured way to move from customer and regulatory expectations through product design, process development, validation, launch, and continuing improvement. Its value does not come from completing each activity independently. Its value comes from keeping requirements, risks, controls, and evidence connected as the product matures.

PPAP should demonstrate that the released design and the proposed manufacturing process can repeatedly produce conforming parts under production conditions. A Part Submission Warrant alone does not provide that confidence. The supporting design records, engineering changes, DFMEA, process flow, PFMEA, Control Plan, measurement studies, capability results, material testing, performance testing, and dimensional evidence must describe the same product and process configuration.

These artifacts should also agree with one another. Address a risk identified in the DFMEA through design controls or verification. A process risk identified in the PFMEA should appear in the Control Plan when appropriate. A critical characteristic on the drawing should connect to the measurement method, MSA evidence, capability results, and reaction plan. If the documents do not tell a consistent story, the organization has a collection of forms—not an integrated quality system.

APQP and PPAP must also remain active after initial approval. Hardware revisions, supplier changes, software updates, manufacturing-process changes, and field evidence can invalidate earlier assumptions. Review the affected requirements, FMEAs, Control Plans, and verification evidence whenever the approved configuration changes.

Used correctly, APQP and PPAP create a common evidence system among engineering, manufacturing, quality, purchasing, and suppliers. They provide the structure needed to determine not only whether a part conforms, but whether the part, process, and surrounding vehicle systems are ready to perform safely and consistently in production.

 

What APQP should connect

APQP should provide the connecting structure from the initial customer need through product development, production launch, and field learning. Each activity produces information that should influence the activities that follow—and, when new evidence emerges, update those that came before it. Customer and regulatory requirements must flow into vehicle and system requirements, design risks must influence verification, manufacturing risks must shape process controls, and supplier readiness must support the production plan. Launch readiness should therefore reflect the maturity of the complete product-development system, not simply checklist completion. 

• Customer and regulatory requirements
• Vehicle and system requirements
• Design risk
• Manufacturing risk
• Supplier readiness
• Verification and validation
• Process controls
• Launch readiness
• Field and warranty evidence

PPAP is a system of evidence

PPAP is not a collection of independent documents assembled to obtain a signature. It is a connected body of evidence demonstrating that the approved design, manufacturing process, measurement system, and production controls can consistently deliver the intended product. Design records and engineering changes must align with the DFMEA; the process flow must connect to the PFMEA and Control Plan; measurement-system capability must support dimensional and performance results; and the approved samples and Part Submission Warrant must represent the same production configuration.

• Design records
• Engineering changes
• DFMEA
• Process flow
• PFMEA
• Control Plan
• MSA
• Capability results
• Dimensional results
• Material and performance testing
• Approved samples
• Part Submission Warrant

Emphasize:

If the drawing, FMEAs, Control Plan, software baseline and test evidence describe different configurations, the PPAP package does not represent the production product.

Progressive PPAP for evolving designs

Through our work supplying components to specialty-vehicle manufacturers, we have explored how to refine PPAP for products that continue to evolve through prototype and early-production builds. In these environments, the first assemblies may serve simultaneously as design-learning units, manufacturing prototypes, and early approval parts. Waiting until the design is considered complete to begin PPAP work can cause valuable evidence to be lost and lead to important problems being discovered too late.

Configuration Management Connects the Evidence

APQP and PPAP can generate substantial evidence, but configuration management determines whether that evidence applies to the product actually built, installed, and delivered. The drawing, software, calibration, manufacturing process, and test results must describe the same configuration at the same point in time.

The required relationship is:

Part revision + software version + calibration + vehicle configuration + manufacturing process + verification evidence

If one element changes, the organization must determine what else is affected. A new component revision may require a different calibration. A software update may be valid only for certain hardware. A manufacturing-process change may alter product performance even when the drawing and part number remain unchanged. Previous verification evidence cannot automatically be assumed valid for the new combination.

Engineering Change Requests and Engineering Change Notices provide the control structure for evaluating and implementing these changes. The ECR should describe the proposed change, its reason, affected requirements, interfaces, risks, and verification needs. The ECN should define what was approved, which records must be updated, when the change becomes effective and how the transition will be controlled.

Effectivity is essential. The organization must know the date, serial number, VIN, or vehicle population at which a new component, software release, calibration, or manufacturing process was introduced. Without effectivity control, engineering may know what was approved but not which vehicles contain it.

The EBOM and MBOM must also remain aligned. The EBOM describes the intended product engineering, while the MBOM defines how manufacturing will build it. Differences may be necessary, but they must be deliberate and traceable. An approved engineering configuration has little value if production instructions, service parts, or supplier releases describe something different.

Software and calibration baselines need the same discipline as physical parts. Treat the applicable hardware revision, software version, calibration file, and feature configuration as one controlled system. Compatibility rules must be explicit, particularly when several variants, suppliers, or regional configurations exist.

Supplier change notification is another critical link. Suppliers must communicate proposed material, process, tooling, location, sub-tier, or design changes early enough for system-impact analysis. The OEM must then determine whether drawings, FMEAs, Control Plans, PPAP evidence, software, calibrations, or test plans require revision.

Configuration changes should lead to appropriate updates in the DFMEA, PFMEA and Control Plan. They should also produce regression-test evidence demonstrating that the change corrected the intended problem without degrading another component, interface or customer-facing feature.

Configuration management is therefore more than document control. It connects the approved product, production process, installed software and verification evidence throughout development, manufacturing and service.

Without configuration traceability, an organization may test one product, manufacture another and service a third.

Digital Twins Help—But They Are Still Models

Digital twins let development teams explore vehicle, subsystem, and manufacturing behavior before committing the required physical resources. They can increase the number of conditions examined, reveal interactions that may be difficult or expensive to reproduce, and let teams evaluate proposed changes before they reach production or the customer.

Digital twins can support:

• Interface analysis

• Thermal and electrical evaluation

• Network timing

• Fault injection

• Manufacturing-process development

• Change-impact analysis

• Degradation prediction

• Comparison with field behavior

However, a digital twin is still a model constructed from assumptions, equations, boundaries, and available data. A detailed model is not necessarily an accurate representation of the physical system. Its usefulness depends on whether you’ve verified and validated its inputs, assumptions, and predicted behavior against appropriate evidence.

This is why physical prototypes and testing remain necessary. Use testing not only to confirm expected results, but also to challenge the model and reveal where its representation of the product, process, or operating environment is incomplete. When physical evidence contradicts the twin, treat the discrepancy as a learning opportunity rather than something to explain away.

The productive cycle is:

Model → predict → test → compare → learn → update the model

Digital twins improve quality when they remain connected to the correct product configuration, manufacturing process, verification results, and field evidence. Without configuration control and ongoing validation, the organization may make decisions based on a sophisticated model of the wrong product.

Models must be challenged by evidence

 

Test the Complete Feature, Not Only the Components

We call it end-to-end: testing throughout the function delivery pipeline.

Customer need → vehicle requirement → system function → subsystem requirement → interface → hardware/software configuration → verification method → test result → validation evidence

Feature-level testing should include

• Nominal operation
• Degraded modes
• Delayed or lost messages
• Stale or conflicting data
• Controller resets
• Power interruptions
• Incorrect configuration combinations
• Hardware/software interactions
• Supplier-subsystem interfaces
• Recovery and rollback
• Complete-vehicle regression

What Automakers and Suppliers Should Do Differently

Reducing recalls requires attention to how the vehicle works as a system. A component can meet its specification while the feature it supports fails under particular operating conditions. Automakers and suppliers must connect responsibility, configuration, change control, and verification across organizational boundaries.

1. Assign an end-to-end owner for every distributed feature. Give someone the responsibility and authority to coordinate requirements, interfaces, and verification across the controllers, software, sensors, actuators, and suppliers involved. That responsibility must extend to demonstrated vehicle behavior.

2. Define and control system and supplier interfaces. Document electrical characteristics, message content, timing, units, tolerances, diagnostics and fault responses. Review the assumptions on both sides of each interface, including what happens when information is missing, delayed, or incorrect.

3. Manage hardware, software and calibration baselines together. Identify the combinations approved for each vehicle configuration. A part number or software version alone does not establish compatibility or show which test evidence applies.

4. Perform impact analysis before approving changes. Examine effects on connected functions, manufacturing, service procedures, and previously completed verification. Use that analysis to determine what must be reviewed and retested.

5. Include suppliers in design, interface and change reviews. Suppliers need enough system context to understand how they will use their products. Their knowledge of component limitations, process variation, and proposed changes must inform vehicle-level decisions.

6. Use APQP and PPAP as evolving evidence systems. Keep the supporting evidence aligned with the current design and manufacturing process. An earlier approval does not demonstrate readiness after changes to the product, process, or application.

7. Connect FMEAs and Control Plans to testing and field evidence. Use test failures, manufacturing findings, warranty returns, and recall investigations to revisit failure mechanisms and controls. Carry those lessons into related products and future programs.

8. Run regression testing after hardware and software changes. Select regression coverage using the impact analysis, including affected interfaces, vehicle variants, and fault conditions. Hardware substitutions can alter behavior just as software revisions can.

9. Verify that corrective actions do not introduce new failures. Demonstrate that the correction addresses the original failure mechanism, then test its effects on other functions and operating conditions. Closing the action requires evidence beyond making the original symptom disappear.

10. Measure integration readiness—not merely component completion. Track verified interfaces, tested configurations, unresolved system defects, and demonstrated feature performance. Individually completed components do not establish that the assembled vehicle is ready for release.

The practical question at a release review is: What evidence shows this vehicle configuration works, and what has changed since that evidence was collected?

The Vehicle Fails as a System

Improving vehicle quality requires clear requirements that define expected behavior, controlled interfaces that make interactions explicit, and supplier capability to deliver consistently. APQP and PPAP discipline must connect development and production decisions to current evidence. Configuration traceability must identify what was built, tested, and released, while end-to-end verification must demonstrate that the complete feature works under intended operating conditions and foreseeable faults.

These practices must remain connected throughout development, production, and field updates. Every change needs a defensible answer to three questions: What does it affect? Which configurations are involved? What evidence demonstrates that the resulting system still works?

The modern vehicle does not recognize departmental boundaries, contractual divisions or supplier tiers. It operates—and fails—as one integrated system.

Reinforce that improving quality requires:

• Clear requirements
• Controlled interfaces
• Supplier capability
• APQP and PPAP discipline
• Configuration traceability
• End-to-end verification

The objective is not simply to prove that every component meets its specification. The objective is to produce evidence that the complete vehicle works safely, reliably and consistently for the customer.

Call to action

Would you like to see the results of the 2020-2026 recall?  Contact us: https://valuetransform.com/contacts/ 

Need help connecting supplier quality, configuration management, and system-level verification?  Contact us; we will work with your team to transfer knowledge and capabilities.

Value Transformation LLC helps organizations improve product-development processes from concept and prototype through APQP, PPAP, production readiness, and field learning. 

 

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

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