The Software-Defined Vehicle: How Industrial Edge Intelligence Are Transforming Cars

The automobile is being redefined in software. As the industry shifts from dozens of fixed-function controllers to centralized, high-performance compute, the software-defined vehicle is emerging as the most complex connected edge device most people will ever own, one that keeps getting safer and more capable long after it leaves the showroom.

At IoT Slam Live 2026, IoT Community’s hybrid flagship event bringing together enterprise and industrial leaders to share real world outcomes, architectures, and roadmaps at the intersection of 5G, mobile edge compute, GenAIoT, and agentic AI, Guy Merritt, Chief Technology Officer at KMS Technology, sat down with Dr. Dirk Schulte of Valeo for a fireside chat unpacking what the software-defined vehicle actually means, from the architecture under the hood to the autonomy levels everyone has heard of but few can explain, and from AI-powered sensor fusion to the data and privacy questions inside the cabin.

The Speakers

Guy Merritt, Chief Technology Officer, KMS Technology

A C-suite technology executive with 35 years of engineering leadership, Guy advises manufacturers and connected-device companies on modernizing legacy systems through IoT, cloud-native platforms, and AI-driven architectures. He is the author of Proactive Risk Management: Controlling Uncertainty in Product Development and leads technology strategy and innovation initiatives across multiple industry verticals.

Dr. Dirk Schulte, R&D Director, Advanced Engineering and Product Platforms, Valeo BRAIN

Dirk leads Driving Automation and Interior Experience research and development for Valeo BRAIN in North America. He joined Valeo in 1999 and has held roles of increasing responsibility across powertrain and electrical systems before focusing on ADAS, driver assistance, and cabin interior technology, including ten years in France and eight in Brazil. He holds a doctoral degree in Aerospace Engineering from RWTH Aachen and is based at Valeo’s Technical Center in Troy, Michigan.

What is The Software-Defined Vehicle?

Guy opened by asking Dirk to define the term everyone in the room had heard but not everyone could explain. “The software-defined vehicle has become almost a little bit like a buzzword now,” Dirk acknowledged, but the underlying shift is real: the center of vehicle development is moving away from a mechanical, hardware-first worldview and toward software.

That shift is only possible because compute has become dramatically cheaper and more accessible. Robotaxis proved the model first, and now the same centralized architecture is trickling down into everyday passenger vehicles. Valeo itself reflects the same transition. As Dirk put it, the company now calls itself a technology company rather than a component supplier, organized around three divisions spanning lighting, powertrain and battery systems, and BRAIN, which covers driving automation, interior experience, and, increasingly, software.

From Robotaxis to the Driveway: How Autonomy Trickles Down

Guy pointed to the Waymos he’d seen lined up outside his hotel that morning and asked what the robotaxi era is teaching the rest of the industry. Dirk’s answer: robotaxis made the massive centralized compute and dense sensor suites possible in the first place, but they operate at a scale passenger vehicles don’t yet match. “There is a scaling effect that needs to take place,” he explained. The sensor quantity, perception algorithms, and fusion techniques proven in robotaxis are now being leveled down, feature by feature, into the vehicles people actually buy.

Under the Hood: Centralized Compute Replaces the ECU Sprawl

Asked to walk through the architectural change driving all of this, Dirk corrected a common misconception before answering: it isn’t dozens of electronic control units in a traditional vehicle, it’s often 70 to 100, each running its own static firmware, unable to learn anything new after the vehicle leaves the factory. The software-defined vehicle consolidates that sprawl into one central compute unit, sometimes paired with zonal controllers, and connects it so it can be updated and improved over time.

Dirk illustrated the payoff with a real production feature: Valeo Racer, which repurposes the vehicle’s existing perception cameras and an augmented reality interface to turn the view out the windshield into a driving game for passengers. “You are playing literally Mario Kart inside your vehicle, looking on the road in front of you,” he said, noting the feature also reduces motion sickness because what a passenger sees matches what the vehicle is actually doing. It’s already live in production with Renault in South Korea.

Centralizing compute isn’t only a capability unlock. It also strips out miles of cabling that would otherwise connect dozens of separate ECUs, cutting both cost and weight, a meaningful benefit as the industry shifts toward electric vehicles. The tradeoff is that everything now shares one processor, which means safety-critical functions have to be strictly prioritized over things like infotainment running on the same silicon.

That shift is also changing what a Tier 1 supplier like Valeo has to be. “Yes, we are becoming a software company to some extent,” Dirk said, pointing to software development centers the company has built out in Egypt, India, China, and Mexico. Even so, he was clear that OEMs won’t hand over everything: the design language and personality of a vehicle still belongs to the automaker, which means suppliers and OEMs increasingly build compound teams to develop features together.

Decoding the Autonomy Levels: Why Level 3 Is the Watershed

Guy asked for a plain-English translation of the SAE levels 0 through 5 that get thrown around constantly but rarely explained. Dirk walked through them directly: Level 1 is one-dimensional assistance, like lane keeping or adaptive cruise control on its own. Level 2 combines those into a two-dimensional system that steers and manages following distance simultaneously.

The real dividing line sits between Level 2 and Level 3. “Up to level two, the responsibility for the driving is with the driver,” Dirk explained. “Level three is the first level where the machine becomes responsible for driving.” In a Level 3 vehicle, a human remains the fallback, typically with around eight seconds to retake control if needed. Level 4 removes the human fallback entirely, but only within a clearly defined operational design domain, specific roads, geofenced areas, or particular weather conditions, which is where today’s robotaxis sit. Level 5, a fully autonomous vehicle with no operational restrictions at all, doesn’t exist yet.

That handoff at Level 3 is as much a legal problem as a technical one. “From level three on, it is the system that is responsible for the driving, because the system is officially driving,” Dirk said. “But the question is now, who is the system?” Whether that responsibility falls to the OEM, the software developer, or someone else is still being worked out, and Dirk was candid that the legal step may be a bigger challenge than the technical one.

Guy also asked Dirk to demystify “Level 2+,” a term that shows up constantly in marketing but not in any official standard. Dirk didn’t mince words: “It is pure marketing,” he said, though not without reason. Features like automatic lane changes on a Tesla with supervised FSD or a GM vehicle with Super Cruise are still legally Level 2, since the driver remains responsible, but they clearly do more than basic Level 2 systems, so manufacturers reach for extra pluses to signal the difference.

When Autonomy Learns to Walk: The Crossover With Humanoid Robots

The conversation turned to embodied AI, and Dirk drew a direct line between the two fields. “A robotaxi is somehow nothing else than a robot,” he said, “and embodied AI, if you want, to some extent, on your own wheels.” The same autonomy categories are already being applied to humanoid robots, with most current implementations sitting somewhere between Level 2 and Level 3, either teleoperated or autonomous within a tightly defined operational domain, such as a warehouse robot trained to move a specific box from one shelf to another. The key difference, Dirk noted, is that humanoids carry far more degrees of freedom than a vehicle, which only moves forward, backward, left, or right. Grasping and manipulation introduce a category of complexity that doesn’t exist in automotive today, and Dirk sees that complexity eventually feeding knowledge back into vehicle design.

No Single Sensor Is Enough

Guy asked Dirk to make the case for sensor fusion, and why some manufacturers betting on camera-only systems aren’t necessarily wrong, just leaving performance on the table. “No single sensor is enough,” Dirk said, though he acknowledged plenty of engineers would debate that. A single sensor modality, cameras alone, can technically deliver strong perception. Humans, after all, drive with only two eyes. But fusing modalities makes the system meaningfully more robust. Cameras excel at classification, reading a traffic sign or recognizing a pedestrian, while radar measures distance and closing speed with centimeter-level precision. Combining automatic emergency braking systems that rely on camera alone with radar data, Dirk explained, produces a system that is not just approximating risk but measuring it.

Validating the Unvalidatable: Probabilistic AI Meets Deterministic Safety

One of the harder questions Guy raised was how an industry built on deterministic safety standards validates AI systems that are fundamentally probabilistic. Dirk pointed to two governing frameworks: ISO 26262, which addresses how a system behaves when a component fails, and the newer SOTIF standard, which addresses whether a system behaves safely within its intended functionality even when nothing has technically failed.

The harder problem underneath both standards is data. “It is extremely difficult to gather enough data to cover all the corner cases,” Dirk said, noting that new edge cases emerge daily and full coverage is effectively impossible. That’s why, alongside real-world data collection and classical regulatory testing against defined scenarios, simulation has become central to the industry’s approach, capable of extrapolating from real traffic data to generate entirely new edge cases for training and validation.

Trust, HMI, and Keeping the Driver in the Loop

As autonomy levels climb, Guy asked how manufacturers keep drivers appropriately calibrated, neither over-trusting nor under-trusting the system. Dirk pointed to over-reliance as the leading cause of both driver frustration and accidents, often rooted in drivers misunderstanding what their vehicle can actually do. The fix is twofold: clear human-machine interface design that communicates constantly what the vehicle is doing and when a takeover is required, and driver monitoring systems, typically infrared camera-based, that track attentiveness and drowsiness and can escalate to a warning or a controlled pullover if the driver becomes unresponsive.

Inside the Cabin: AI as Co-Pilot and the Privacy Question

The same sensor fusion principles used outside the vehicle apply inside it. Cameras and radar combine for use cases like child presence detection, precise occupant positioning for airbag deployment, and monitoring vital signs like heart rate and breathing. Layered with generative AI, the in-cabin experience is shifting from a simple voice assistant to something closer to a co-pilot, in some deployments capable of addressing a passenger directly to flag that the driver seems distracted.

That level of in-cabin sensing naturally raises data and privacy questions, and Guy pushed Dirk on where the industry draws the line. Dirk was direct that driver monitoring systems operate as closed loop systems: they process only short windows of data, five to ten seconds at a time, transform it into a form that cannot be decrypted or reconstructed, and never send it to the cloud. “It doesn’t tell you who it is,” Dirk said. “And it doesn’t leave the vehicle.”

The Vehicle as the Ultimate Edge Device

Framing the discussion for the IoT audience in the room, Dirk laid out what makes a modern vehicle the most demanding edge and IoT platform in production today: sensors, compute, perception, communication networks, and software all operating together, but inside a potentially life-threatening environment, under extreme temperature swings and constant vibration, and compressed into split-second decision windows that most IoT deployments never have to contend with.

Looking Ahead

Asked what excites him most looking five to ten years out, Dirk pointed to the more than 40,000 traffic fatalities that occur on North American roads every year, and the real possibility that rising levels of automation meaningfully reduce that number. He doesn’t expect full autonomy everywhere within a decade, but he does expect vehicles to keep getting measurably safer.

The harder problem, in his view, isn’t any single sensor or algorithm. It’s the sheer complexity of an industry built on partnerships across suppliers, OEMs, and connectivity providers all having to move in coordination, which is exactly why he sees events like IoT Slam Live as valuable: a chance to get every stakeholder in the same room.