Software-Defined Vehicles
and the Tool Chain Problem

You Can Build Tomorrow's Vehicle on Yesterday's Tool Chain. For a While.

Abstract

A 23-minute conversation between Steve Neemeh of LHP Engineering Solutions and Dr. Steven Fraser, founder of Unatech Technology Solutions, on centralized compute, interface integrity across teams, and what AI can and cannot be trusted with in a safety case.

Every OEM and supplier says they are moving to software-defined vehicles. Fewer can say who owns the interface contract once the boxes go away. Steve sits down with Dr. Fraser, who has spent about 30 years in embedded automotive software architecture and teaches embedded architecture and ISO 26262 at Oakland University, to work through what changes in the architecture, in the org chart, and in the safety argument.

What's Covered

• A one-question test for whether you actually have an SDV. Can you change vehicle behavior without changing the bill of materials, and can you do it after job one? If not, you have a vehicle with software in it.
• Why the shift is happening now. Past 100 to 150 ECUs, the wiring harness became one of the heaviest and most expensive components, silicon got good enough to run mixed criticality on one SoC, and cross-domain features became the product.
• Four terms that are not the same thing. Zonal architecture is a wiring answer. Centralized compute is where behavior moves. The vehicle OS is the abstraction layer everyone is fighting over commercially. Fewer ECUs is an outcome, not a goal.
• The hardest technical problem, and it is not compute. The same interface described in five places by five teams in five formats, with nothing forcing the descriptions to agree. Integration becomes archaeology, and six weeks go to a data problem.
• What breaks in the org chart. The federated model let you organize by box. Once the boxes are gone, integration has to become a horizontal function, and somebody has to own the interface contract centrally.
• Where AI earns its keep, and it is not code generation. Requirements consistency and completeness review, HARA and FMEA review, and continuous architectural rule checking;  all of it is pattern work that humans do badly at scale. The condition: AI has to operate on structured data, not documents.
• How this survives an ISO 26262 assessment. Tool qualification versus output verification, why output verification is the honest answer for generative AI, and one workflow rule: AI should never be the last step before a safety artifact is released.

Speakers

Steve Neemeh, LHP Engineering Solutions. Host of LHP's fireside chat series, where he sits down with experts to unpack complex technical topics and how AI affects them.

Dr. Steven Fraser, Founder, Unatech Technology Solutions. About 30 years in embedded automotive software architecture, integration, control systems, powertrain, and functional safety. An LHP alum who served as Solution Architect for Model-Based Design and AUTOSAR, he teaches embedded architecture and ISO 26262 at Oakland University and continues to work on commercial programs.