Safety-Critical Parts Are Not Commodities
Safety-Critical Parts Are Not Commodities
Core thesis
Safety-critical parts cannot be managed as a commodity transaction when it carries vehicle-level responsibility.
Executive Thesis: Safety-Critical Parts
The organization may buy a sensor, camera, fastener, label, coating, ECU, wire harness, bracket, software module, calibration file, or service procedure. However, the vehicle does not experience those items as commodities. Instead, it experiences them as contributors to a vehicle-level function.
That function may detect, classify, warn, restrain, brake, steer, display, support, retain, seal, protect, diagnose, suppress, deploy, or preserve a load path. Therefore, the part matters not only because of what it is, but because of the responsibility it carries inside the vehicle-level system.
What Commodity Thinking Sees
It sees the camera, sensor, fastener, label, coating, connector, module, harness, software package, or calibration file. From there, the organization asks whether the item meets specification, can be sourced, fits the package, meets cost, arrives on time, and can be delivered by the supplier at production volume.
Those questions are necessary. After all, vehicle programs cannot function without cost discipline, sourcing discipline, packaging discipline, delivery discipline, and specification discipline.
However, commodity thinking becomes dangerous when it stops at the item.
A part may meet its commodity description and still fail to preserve the vehicle-level function. For example, a drawing can be satisfied while an interface risk remains unresolved. Similarly, a supplier test can pass while a validation gap remains open. In another case, a bench check may succeed even though the part fails under the vehicle state that matters. Finally, a piece-price reduction may transfer risk into the safety case.
Therefore, the problem is not that cost matters. The problem is that cost cannot define the function by itself.
What Function Thinking Adds: Safety-Critical Parts
Function thinking starts with vehicle-level responsibility. Instead of asking only whether the part meets its individual specification, it asks what the system must accomplish, under what operating conditions, with what verification evidence, and within what known limits. From there, the organization evaluates how each part, interface, material, software element, label, sensor, calibration, and diagnostic contributes to the safety-critical vehicle function.
This approach does not ignore the part. Instead, it places the part inside the function.
A camera may support visibility, sensing, or perception. Likewise, a coating may protect a structural load path. In another case, a fastener may preserve attachment authority. Meanwhile, a certification label communicates a certified use boundary. Software adds another layer because it controls authority, timing, state transitions, diagnostics, and system response.
As a result, function thinking asks a broader set of systems-engineering questions:
- Which vehicle-level behavior depends on this item?
- What assumptions does the item carry?
- Which interface conditions must remain true?
- Where can this item introduce a failure mode?
- How will the system detect when the item no longer supports the function?
- Most importantly, what verification evidence proves the vehicle-level function, not merely the part?
This is the difference between managing a component as a commodity and managing it as part of a safety-critical product-development system.
Vehicle-Level Examples
Function thinking changes how ordinary engineering content is understood.
A fastener or joint is not merely hardware. In a suspension system, it may preserve the physical attachment state between a control arm and a knuckle. However, if the organization confirms only a process step while the actual attachment state remains unresolved, it has managed the commodity but missed the function.
Corrosion protection also carries vehicle-level responsibility. In a structural system, coating performance may preserve the load path that allows the vehicle to carry suspension forces over its intended life. When lifecycle exposure defeats that protection, the structure may no longer support the function the original design assumed.
A certification label serves the same purpose in a different form. It communicates the declared load envelope to the customer, dealer, service network, and regulator. Therefore, if the stated axle-weight rating is wrong, the user-facing information boundary can mislead loading decisions and increase crash risk.
Electrical content creates another example. Wiring, connections, residual power, and thermal vulnerability are not merely isolated components. In a parked vehicle, they may define whether the vehicle remains electrically and thermally safe when the driver believes it is off.
Recent recall examples across attachment systems, corrosion protection, certification labels, and parked-state electrical behavior illustrate the same systems-engineering discipline. In each case, the part matters because of the safety-critical vehicle function it supports.
Commodity thinking asks whether the part exists, was sourced, was installed, or met its local requirement. By contrast, function thinking asks what vehicle-level responsibility the part carries, what assumptions depend on it, and what happens when that responsibility is not preserved.
The OEM and Supplier Boundary: Safety-Critical Parts
This is not an anti-supplier argument.
Suppliers deliver essential capability. They provide parts, materials, electronics, software, validation data, manufacturing-process knowledge, and technical depth that no OEM can reproduce internally for every system. In fact, strong suppliers are indispensable to modern vehicle development.
However, vehicle-level function remains the OEM’s responsibility.
A supplier may own a component requirement, but the OEM owns the integrated vehicle claim. Likewise, a supplier may validate a part against defined conditions, while the OEM must determine whether those conditions close the vehicle-level usecase. In many cases, the supplier provides evidence. Even then, the OEM must decide whether that evidence proves the function inside the vehicle environment.
Commodity thinking weakens this boundary because it treats supplier content as a purchasable object. By contrast, function thinking strengthens the boundary because it connects supplier content to vehicle-level responsibility.
Why Commodity Thinking Creates Hidden Cost
Commodity thinking often appears cheaper at the beginning of a program.
At first, it simplifies sourcing, reduces discussion, narrows requirements, and focuses attention on piece price, timing, and delivery. However, that early simplicity can create hidden cost later when the vehicle-level function was not fully understood.
Those costs may appear as late validation failures, warranty exposure, field actions, service complexity, supplier disputes, software workarounds, diagnostic gaps, engineering rework, launch delays, containment actions, or recall campaigns. As a result, the organization may believe it saved money on a component while transferring unresolved complexity into the integrated system.
Function thinking may look more expensive at the beginning. It requires clearer requirements, stronger interface definition, better usecases, broader validation logic, and deeper supplier discussion. In practice, however, it reduces the probability that the program buys a part while failing to buy the function.
Usecases as the Bridge: Safety-Critical Parts
Usecases provide the bridge between commodity content and vehicle-level function.
A Usecase defines the actors, conditions, triggers, assumptions, exclusions, states, expected behavior, evidence, and boundaries required to prove a function. As a result, it makes responsibility visible before the organization converts that responsibility into parts, software, materials, diagnostics, labels, and supplier statements of work.
Without Usecases, a team may specify the object and still miss the function. With Usecases, however, the team can trace each object back to the vehicle-level condition it must support.
That traceability is not bureaucracy. Instead, it protects the program against false simplification.
Most importantly, it helps the organization know whether it is only buying a part, buying capability, or actually proving the vehicle-level function.
The Systems-Engineering Lesson
Systems engineering begins when the organization moves beyond the object.
The object matters. So does the drawing, supplier, cost, timing, and quality record. However, none of those items replaces the vehicle-level function.
A function carries more than a specification. It has operating conditions, system states, authority, interfaces, evidence, degraded modes, assumptions, exclusions, and lifecycle exposure. In addition, it exists inside a real vehicle environment that includes customers, service technicians, manufacturing plants, suppliers, software updates, regulators, and field conditions.
Therefore, commodity thinking can manage the object, but function thinking must manage the responsibility.
Conclusion: Safety-Critical Parts
A vehicle safety function cannot be reduced to a commodity purchase.
The organization may buy parts, software, sensors, materials, labels, calibrations, and services. However, vehicle-level responsibility remains larger than the purchased content.
That is why function thinking matters.
It forces the organization to ask what the item supports, which assumptions it carries, which boundaries constrain it, what evidence proves it, and how the system should respond when its state changes.
For the same reason, systems engineering must remain connected to sourcing, validation, manufacturing, service, software, and supplier management. The function does not stop at the drawing. Instead, it lives across interfaces, lifecycle states, and vehicle-level usecases.
Commodity thinking asks what the part is. By contrast, function thinking asks what responsibility the part carries.
Only the second question can support safety-critical engineering.
References
Related Reading
Change Control in Systems Engineering: Preserving System Integrity – preserving system integrity through disciplined engineering controls:
https://georgedallen.com/change-control-in-systems-engineering-preserving-system-integrity/
External References:
- NASA Systems Engineering Handbook — general systems-engineering / verification framework. https://www.nasa.gov/wp-content/uploads/2018/09/nasa_systems_engineering_handbook_0.pdf
- ISO 26262 Road Vehicles — Functional Safety — automotive safety lifecycle context. https://www.iso.org/publication/PUB200262.html
- NIST IR 8356 — Digital Twin Technology — state representation / model-based trust context. https://csrc.nist.gov/pubs/ir/8356/final
- Ford Ball Joint Recall: NHTSA Recall 26V340 — physical attachment-state example https://static.nhtsa.gov/odi/rcl/2026/RCLRPT-26V340-0609.pdf
- Honda Subframe Recall: NHTSA Recall 26V365 — environmental durability / Salt Belt boundary https://static.nhtsa.gov/odi/rcl/2026/RCLRPT-26V365-6590.pdf
- Jeep Wrangler / Gladiator Fire Risk: NHTSA Park-Outside Warning — parked-state electrical boundary example. https://www.nhtsa.gov/press-releases/urgent-park-outside-warning-issued-1-million-jeeps
- Subaru GAWR Certification Label Recall: NHTSA Recall 26V436 — certified load-envelope / information-boundary example. https://static.nhtsa.gov/odi/rcl/2026/RCLRPT-26V436-5346.pdf
Copyright Notice
© 2026 George D. Allen.
All rights reserved. No portion of this publication may be reproduced, distributed, or transmitted in any form or by any means without prior written permission from the author.
For editorial use or citation requests, please contact the author directly.
About George D. Allen Consulting:
George D. Allen Consulting is a pioneering force in driving engineering excellence and innovation within the automotive industry. Led by George D. Allen, a seasoned engineering specialist with an illustrious background in occupant safety and systems development, the company is committed to revolutionizing engineering practices for businesses on the cusp of automotive technology. With a proven track record, tailored solutions, and an unwavering commitment to staying ahead of industry trends, George D. Allen Consulting partners with organizations to create a safer, smarter, and more innovative future. For more information, visit www.GeorgeDAllen.com.
Contact:
Website: www.GeorgeDAllen.com
Email: inquiry@GeorgeDAllen.com
Phone: 248-509-4188
Unlock your engineering potential today. Connect with us for a consultation.
