A decade inside automotive software — and what every engineer should understand about the machines we build
The Hook
You’ve probably debugged a microservice that wouldn’t talk to another microservice. You’ve traced a race condition across threads. You’ve stared at a distributed system failure that made no sense until you finally found the one assumption nobody had documented.
Now imagine doing all of that — but the system is moving at 120 km/h, the components were built by a dozen different suppliers across three continents, and a failure in the wrong subsystem doesn’t crash a server. It crashes a car.
Welcome to automotive software engineering.
Modern vehicles are not mechanical machines with some software bolted on. They are distributed software systems — some of the most complex ones humans have ever built — wrapped in metal and rubber and expected to run reliably for fifteen years.
This is a map of how that system works. Written for software engineers who’ve never looked under the hood.
The Map You Didn’t Expect
Imagine you’re a software engineer joining an automotive company on your first day.
You’ve built distributed systems before. Microservices, message queues, event-driven architecture — you know how complex software systems behave. You’re not easily surprised.
Then someone hands you the system architecture diagram for a modern vehicle.
It’s not a diagram. It’s a map — dozens of small computers, each one dedicated to a single function, all connected through a web of communication networks. One for the brakes. One for the engine. One for the airbags. One for the infotainment screen. One for the cameras watching the lane markings at 120 km/h.
These computers are called ECUs — Electronic Control Units. And a modern car can have over 100 of them.
Your first reaction might be: why so many? That’s exactly the right question.
How We Got to 100 ECUs
In the 1970s, a car had zero ECUs.
The engine was mechanical. The brakes were hydraulic. The windows were manual. If something broke, a mechanic with a wrench could usually fix it without a laptop.
Then regulations changed. Emissions standards arrived. Safety requirements tightened. And the market started demanding features that mechanical systems simply couldn’t deliver.
The first ECU appeared in the late 1970s — a dedicated controller for engine management, replacing the mechanical carburetor with something that could be precisely tuned and monitored electronically.
It worked. So the industry did what any engineering organisation does when something works: it repeated the pattern.
ABS needed a dedicated controller. So it got one. Airbags needed a dedicated controller. So they got one. Infotainment. ADAS. Battery management. Climate control. Each new feature arrived with its own ECU — isolated, purpose-built, and owned by a different supplier.
This wasn’t laziness or poor planning. It was rational engineering.
Adding a new ECU was faster than modifying an existing one. Safer too — because touching a certified, safety-validated module to add an unrelated feature risked breaking guarantees that took years to establish. Isolation meant one supplier’s problem stayed one supplier’s problem.
The automotive supply chain runs on this logic. An OEM like BMW or Toyota doesn’t build everything in-house. They integrate components from Tier-1 suppliers like Bosch, Harman, Continental — each delivering their own ECU, their own software stack, their own communication interface.
Nobody sat down in 1995 and decided “let’s build a car with 100 computers.” It happened one feature at a time, one decade at a time, one supplier at a time. By the time anyone stepped back and counted, the number had crossed 100 — and the vehicle had quietly become something nobody had explicitly designed: a massively distributed software system.
How ECUs Talk to Each Other
So you have 100+ computers in a car. Each one doing its job in isolation. But isolation only works up to a point.
The moment you want your brakes to respond to what your ADAS camera sees, or your instrument cluster to display what your engine is reporting, or your infotainment system to know the car is reversing — the ECUs need to talk to each other.
The automotive industry solved the communication problem the same way it solved the ECU problem — incrementally, one requirement at a time.
In the 1980s, a protocol called CAN (Controller Area Network) was developed by Bosch. It was elegant for its time — a two-wire bus that let ECUs broadcast messages to each other without a central coordinator. Any ECU could send. Any ECU could listen. Simple, robust, and fast enough for the problems of that era.
CAN is still in almost every vehicle today.
But CAN was designed for a world where a car had a handful of ECUs exchanging small, infrequent messages. It was not designed for streaming a rear-view camera feed, or running a navigation system, or handling the data throughput of a modern ADAS stack.
So new protocols arrived. LIN for simple, low-speed peripherals. FlexRay for safety-critical, time-sensitive communication. And eventually Ethernet — because nothing else could handle the data volumes that modern vehicles demand.
Today a single vehicle can run four or five different communication protocols simultaneously. Each one optimised for a different trade-off between speed, reliability, cost, and safety.
An ADAS system processing camera data runs on Ethernet. The signal it generates — “obstacle detected, brake now” — travels across a protocol boundary to reach the braking ECU on CAN. Two different protocols. Two different timing models. Two different assumptions about message delivery. The braking ECU doesn’t speak Ethernet. The ADAS system doesn’t speak CAN. Something in between has to translate — and that translation layer is exactly the kind of place where unexpected behaviour hides.
Where Complexity Really Lives
Here’s something that took me years to fully appreciate.
In a distributed system, the hardest bugs are rarely inside a component. They live between them.
Every ECU in a vehicle is tested. Every communication protocol is validated. Every software module goes through review cycles that would make a consumer software team wince. The individual pieces are, by and large, well-engineered.
And yet vehicles still produce failures that nobody predicted. Failures that don’t show up in unit tests, integration tests, or even months of validation drives. Failures that only appear when the full system — all 100 ECUs, all five communication protocols, all the supplier stacks running simultaneously — is finally assembled and pushed to its limits.
The Security Problem Nobody Planned For
Nobody redesigned the underlying architecture when vehicles became connected to the internet.
The same 100 ECUs designed for isolation and reliability — the architecture that made perfect sense in a pre-connected world — suddenly became a security liability.
In a well-designed security architecture, you want clear boundaries. You want to know exactly what can talk to what, who owns each boundary, and where you enforce trust. You want a small, well-understood attack surface that you can monitor and defend.
A vehicle with 100 ECUs communicating across five protocols, built by dozens of suppliers over thirty years, is the opposite of that.
Security researchers demonstrated this reality in 2015 when they remotely took control of a Jeep Cherokee through its infotainment system — killing the engine, disabling the brakes, taking over the steering. The vehicle’s internal network, once breached, offered a path from the entertainment system all the way to safety-critical functions.
The isolation that was designed to contain failures turned out to also contain security ownership. Nobody owns the full picture. The OEM owns the vehicle integration but not every ECU. The Tier-1 supplier owns their ECU but not the network it connects to. The software vendor owns their stack but not the hardware it runs on.
You can’t patch what you can’t reach. You can’t defend what nobody owns.
Where the Industry Is Heading
The automotive industry is not unaware of what it built.
The answer the industry has converged on has a name: Software Defined Vehicle.
Instead of 100 specialised ECUs, a Software Defined Vehicle runs on a smaller number of powerful central compute nodes — think of them as the vehicle’s brain, rather than its nervous system. Vehicle functions that once lived in dedicated hardware are abstracted into software running on shared compute. Features can be updated, added, or changed over the air without touching hardware.
The architectural shift underneath this is called zone architecture. Instead of organising the vehicle by function, zone architecture organises it by physical location. A zone controller sits in each corner of the vehicle, managing everything in its physical zone, and communicating upward to a central vehicle computer. Fewer nodes. Cleaner boundaries. Centralised security enforcement. A dramatically smaller attack surface.
But here’s what the spec documents don’t tell you.
The vehicles on the road today still run the old architecture. They will run it for another ten, fifteen, twenty years. And even in new vehicles, the transition is never clean. Legacy ECUs don’t disappear overnight. Safety-certified components can’t simply be replaced with software running on a shared compute node — not without revalidating every safety guarantee that certification was built on.
There is also something bigger happening beneath the SDV transition that rarely gets discussed in press releases.
Open source is entering automotive in a serious way. Projects under the Eclipse SDV foundation — Kuksa, Velocitas, uProtocol, and others — are building the open infrastructure layer for the Software Defined Vehicle. The COVESA alliance is standardising vehicle signal specifications. S-CORE, a project under Eclipse Foundation, is tackling the configuration and deployment infrastructure that SDV platforms need.
For an industry that spent thirty years building proprietary, supplier-locked software stacks, this is a cultural shift as significant as the architectural one.
Closing Thought
Software engineers often ask me what it’s like to work in automotive.
My honest answer: it is the most humbling domain I have encountered in a decade of building software.
In most software systems, a failure means a degraded experience. A page doesn’t load. A transaction fails. A notification doesn’t arrive. Frustrating, sometimes costly, rarely dangerous.
In automotive software, the failure modes sit on a different spectrum entirely. The same distributed system complexity we’ve walked through in this article — the boundary assumptions, the protocol mismatches, the fragmented security ownership — exists in a machine that carries human lives at high speed.
That reality changes how you think about every architectural decision. Every interface. Every assumption you leave undocumented.
The automotive software industry is in the middle of the most significant transition it has ever faced. It needs software engineers who understand distributed systems. Who think carefully about boundaries and assumptions. Who know what happens when complexity compounds across components that were never designed to talk to each other.
If you’ve read this far, you already think that way.
The vehicle stack is more familiar than it looks. It’s just a distributed system — with higher stakes, a longer history, and a transition underway that will define the next generation of the machines billions of people use every day.
Welcome to automotive software engineering.
Utsav Krishna have nearly a decade of experience in automotive software engineering across Bosch, Harman International and LG Soft India. He writes about automotive software, SDV architecture, and the open-source ecosystem shaping the future of vehicles.
Follow him on LinkedIn | utsavkrishna.com