At a glance (1 minute)
I have zero automotive background, and I am wading in anyway. I see a modern car not only as torque, motion, powertain etc. and linkages between those, but as a host of a complex, distributed software system — state management, concurrency, time-bound communication, and predictable behaviour. That is the problem-set I have worked for three decades: protocol, middleware, distributed systems, and diagnostics on Linux/Unix.
This outsider's clean slate that I bring, is, I argue, a strategic advantage — not a licence to skip the domain.I still have to fill in CAN, UDS, VSS etc., and the safety culture that automotive software has to deal with. Vehicle behaviour is software, so it should be modelled like any other reliable software system: State machines, Correct-by-construction, Predictability, and Electro-mechanical parts treated as Peripheral interfaces, with a Digital Twin as the source of truth. A software-centric approach, if you like.
The path I am taking:
- listen to industry experts, veterans and practitioners on YouTube and at conferences;
- work through digital.auto's training material;
- study SDV through Eclipse SDV;
- form a mental model of a vehicle Digital Twin;
- then build one model — code-first — as a proof of that understanding.
I will know I qualify when that twin can be driven, watched, and replayed — and when people who already live in this domain can point at what it gets wrong.
╔═══════════════════════╗
║ An honest confession: ║
╚═══════════════════════╝I have ZERO background of the world of Automotive Engineering. Yet, I have decided to wade into this vast space, aided by a mix of trepidation and excitement. The raised eyebrows ask me: why?
╔═════════════════════════════════════════════════════════════════╗
║ I see a car as a host of a complex, distributed software system ║
╚═════════════════════════════════════════════════════════════════╝For decades, automotive engineering was a world of combustion, torque, and physical linkages. From whatever I have been reading for some time now, today, that world is being abstracted. If we view the car not as a collection of mechanical parts, but as a complex device managed by a sophisticated OS, it becomes a problem of state management, concurrency, asynchronous / time-bound communication between components and and predictable behavior.
I tell myself: If the behavior of a vehicle is governed by software, then it can—and should—be modeled using the same rigorous architectural patterns that govern the world's most reliable distributed systems. And, I had the opportunity to work for over three decades, exactly in that area of protocol , communication, middleware, distributed systems software and diagnostics, on Linux/Unix. I see these same themes appearing repeatedly in the discussions happening in the world of SDV; domain has its own constraints but the problem-set is very similar to what I have worked for many years.
╔════════════════════════════════════════════╗
║ But, then, I am a rank outsider; am I not? ║
╚════════════════════════════════════════════╝Yes. Very much.
What, even by stretched arguments, can I even bring to the table?
I come to this field with three decades of experience in architecting / designing / deploying complex software, but zero history in traditional automotive engineering. I believe and posit that this "clean slate" is a strategic advantage. From my PoV, we need to design a complex piece of software (the 'car' takes the backstage) and in that, the following are where my hands-on experience are quite applicable:
-
Behavioral Modeling: Moving away from hard-wired logic toward flexible and auditable State Machines.
-
Systemic Predictability: Applying the "Correct by Construction" philosophy to ensure that software-driven maneuvers are safe and verifiable.
-
Abstraction over Complexity: Treating electro-mechanical components as peripheral interfaces, allowing the "Digital Twin" to become the primary source of truth.
That clean slate is not a skip. I still have to learn the vehicle bus (CAN), the diagnostic conversation (UDS), the signal vocabulary (VSS), and the safety culture in which this software is allowed to run. Those are the gaps I am filling; they are not optional flavour.
╔═══════════════════════════════════════╗
║ What is the path that I have charted? ║
╚═══════════════════════════════════════╝-
Listening to experts on YouTube channels and at conferences
-
Filling myself in with what digital.auto's training material contains
-
Studying the world of Software Defined Vehicle primarliy through Eclipse SDV initiative
-
Making a mental model of how a Digital Twin of car is supposed to behave
-
Build a Digital Twin - all by myself - as a proof of concept, to establish if my understanding is correct and in the hope that some day, I will be able to contribute towards a real-life Digital Twin. This project is my way of understanding that intersection by building software (#code-first) rather than merely studying architectures.
I will know the case holds when that twin can be driven, watched, and replayed — and when experts and peers can point at what it gets wrong. Until then, "do I qualify?" stays an open check, not a claim.