╔═══════════════════════╗
║ 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.
╔═══════════════════════════════════════╗
║ What is the path that I have charted? ║
╚═══════════════════════════════════════╝-
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.