What it takes to write the software inside a car.
A modern car carries roughly two hundred million lines of code — about four times an F-35 fighter, three times Facebook. It weighs two tonnes, runs four operating systems, travels at two hundred kilometres an hour, and is not allowed to crash because a chatbot felt unwell. Prashant Doreswamy runs Continental's India business — five thousand engineers in Bangalore, ten thousand employees across seven plants, building the safety, autonomy, infotainment, and material science inside a hundred-and-fifty-two-year-old German tier-one. In this conversation he walks through the architecture: distributed ECUs collapsing into five high-performance computers, then into one; AUTOSAR giving way to software-defined vehicles; ISO 26262 as the unspoken curriculum every line of code has to graduate from. The car is becoming a phone that cannot fail. This is the workshop behind it.
In sixty seconds.
Until roughly 2005, a car was metal, rubber, plastic, and a wiring harness. Today it is two hundred million lines of code wrapped around the same two tonnes of metal. The thing that changed is not the car. It is what counts as engineering inside it.
Prashant's thesis is that the philosophical gap between a software company and a car company is becoming the central business problem of the decade. Software companies ship and iterate. Continental cannot. A buggy iPhone is irritating; a buggy ECU at one hundred and twenty kilometres an hour is fatal. ISO 26262, ASIL ratings, AUTOSAR, automotive SPICE — the alphabet soup is the price of being trusted with the lives of two passengers and three children for fifteen years.
The structural question is who writes the next layer. As the architecture collapses from eighty distributed ECUs to five high-performance computers to one central brain plus middleware, the value moves up the stack, into software-defined-vehicle platforms. Tier-ones either own that layer or get disintermediated by Apple, Google, Waymo, and an Ola that started life as an aggregator and is now building cars. Continental's bet is its hundred-and-fifty-two-year-old discipline plus a five-thousand-engineer India operation that has crossed the threshold from cost arbitrage to core design.
Where to land in the conversation.
Each chapter opens the YouTube video at that timestamp in a new tab.
Six ideas to carry into your own work.
Mental models lifted from the conversation that travel beyond automotive. Each one is the kind of thing you can quote in a strategy meeting on Tuesday.
Physical-stakes software
A buggy phone is an irritation. A buggy car at two hundred kilometres an hour is fatal. Once the artefact you ship can kill its user, the entire engineering culture rewires — V-model lifecycles, traceability matrices, formal verification, ASIL hazard analyses. Prashant frames it as the unbridgeable line between "launch then fix" and "100% perfect before launch." That line is the moat.
Long-life engineering
A car ships in 2026 and is on the road in 2041. The ECUs inside it run software written before AUTOSAR Adaptive existed. The supplier has to support that code while shipping new architectures simultaneously. Continental's 152-year continuity is not nostalgia; it is the only way to underwrite a fifteen-year warranty on a thing whose toolchain refuses to stand still.
Certification as architecture
ISO 26262, ASIL A through D, ISO 21434, Automotive SPICE, UNECE WP.29 R155/R156 — these are not paperwork bolted onto a finished design. They are the design. ASIL-D systems require redundancy, diverse coding, formal proof, traceable requirements. A tier-one that has internalised this for two decades has an engineering organism that no Series-B challenger can replicate in five years.
The SDV business-model rewrite
For a century the tier-one sold a black box once and the OEM owned the customer. Software-defined vehicles flip that. Functions move to the cloud, sold by subscription, updated over-the-air, monetised across the car's lifetime. The OEM becomes a platform; the tier-one becomes either a platform partner or a parts vendor. Prashant is clear which side Continental is choosing.
Indian engineering as decade-old moat
Five thousand R&D engineers in Bangalore working on radar platforms, autonomous mobility, two-wheeler ABS, body electronics. Continental's TCI is not a back office; it is the global lead for several product lines. The depth compounded silently across the 2010s. It is now near-impossible to replicate from a standing start — you cannot conjure HL7-equivalent automotive fluency in three years.
AUTOSAR Classic to Adaptive: the transition signal
AUTOSAR Classic was built for static, signal-based ECUs — the architecture of the 2000s. AUTOSAR Adaptive is built for high-performance, service-oriented, dynamically-linked computing — the architecture cars are migrating to now. Every tier-one is somewhere on that arc. Watch the ratio of Classic-only headcount to Adaptive-ready headcount. It tells you who survives the SDV transition.
Seventeen things to actually walk away with.
Each one carries the timestamps where the moment lives, and a transferable note for work that isn't automotive.
Two hundred million lines of code in a car — and what the comparison really tells you.
The number Prashant offers is the line that should travel out of this conversation. A modern car carries about two hundred million lines of code. An F-35 fighter, by comparison, carries about fifty million. Facebook is about sixty-five million. The vehicle parked in your driveway is, by lines of code, more complex than a fifth-generation combat aircraft and more complex than the social-graph engine serving three billion users. He gives the comparison not as bravado but as architecture lesson — the iPhone-15, he points out, has one display, one processor, maybe four sensors, weighs two hundred grams, and if it crashes you are mildly annoyed. The car has four displays, four operating systems, hundreds of processors, hundreds of sensors, weighs two tonnes, travels at two hundred kilometres an hour, and if its software is faulty, somebody dies.
The reframe matters because it dissolves a common misconception. People look at Tesla and assume "consumer software in a car" is a solved problem. It is not. The hidden mass of regulated, safety-critical, redundancy-engineered, formally-verified code under every brake-by-wire, every adaptive cruise, every airbag controller is what makes the line count so large. The visible infotainment is the small part.
ISO 26262 is not a checklist — it is the shape of the SDLC.
Prashant returns to it in different language each time. The car industry, he says, comes from a philosophy that nothing ships unless it is 100% perfect. The software industry comes from a philosophy that you launch and fix it on the air. The reconciliation between those two philosophies is, in practice, ISO 26262 — the functional-safety standard that defines hazard analysis, ASIL classification, requirements traceability, and the V-model lifecycle every automotive engineer learns before they learn anything else. It is the discipline that lets you mix software-style iteration with car-style consequence.
A team that has internalised 26262 builds differently from day zero. Every requirement is traced to a hazard. Every change is impact-analysed against the safety case. Every release goes through an automotive-SPICE process audit. None of this looks like the agile board on a SaaS company's wall. It looks like a flight test programme — because at two-tonne, two-hundred-kilometre-an-hour scale, that is what it is.
ASIL inheritance: how a single hazard rating reshapes a hundred files.
Prashant does not name ASIL explicitly in the conversation, but it lives under everything he says about safety. Automotive Safety Integrity Levels run from A (lowest) to D (highest). An emergency-braking-assist function is typically ASIL-D — the highest tier — because a wrong braking decision can kill someone. ASIL-D demands redundancy in hardware, diversity in software (two algorithms by different teams), formal methods on the safety-critical paths, and a chain of evidence from the safety goal down to the last branch in the code.
The structural consequence is that ASIL ratings inherit. A component that is ASIL-B in isolation may be ASIL-D inside a vehicle integration because the higher function depends on it. Decisions made at the system level cascade down to file-level changes. This is why the tier-one's safety architecture team is the most powerful unwritten body in the company — they decide which components carry the highest evidentiary burden, and that decision is the cost structure.
From distributed ECUs to five HPCs to one brain.
Prashant's architecture diagram, told in three sentences: today's car has eighty to a hundred distributed ECUs — engine, transmission, doors, lighting, body control, each a small computer running its own software. The industry is now consolidating those down to five high-performance compute units — one each for interior, body, powertrain, chassis, and autonomous mobility. In another three to four years, those five collapse further to a single central computer running an operating system with a middleware layer that allows the application code to be platform-portable. The plumbing is being redrawn on a five-year clock.
The implication is large. Distributed ECUs gave each function a dedicated processor and a hard isolation boundary. Consolidated HPCs mean cross-function timing, security domains, and shared memory have to be designed from scratch. The work that fills Continental's order book for the rest of the decade lives precisely in this transition. So does the talent crunch — engineers who can do safety-isolated multi-domain Linux on Arm-A78 are rarer than the role descriptions admit.
The Software-Defined Vehicle rewrites the tier-one business model.
For a century the rules of the automotive industry were: tier-one builds part, sells it once to OEM, OEM owns the customer relationship for the life of the car. Software-defined vehicles dissolve that contract. Functions move to the cloud. Updates happen over-the-air. The OEM can sell features post-purchase — heated seats by subscription, autonomous-driving capability by month. The tier-one can either be a platform partner that ships into this lifecycle or a parts vendor whose part shipped years ago and is now replaceable.
Prashant is direct that this is why Continental is pushing differentiating middleware as the wedge — upper layers and lower layers can be sourced anywhere; the middle, where the safety, the security, and the cross-domain orchestration sit, is where the tier-one's discipline still adds value the OEM cannot replicate in-house. The economics are also direct: development time for a new platform drops from years to "maybe two years for a platform, maybe one year for a program update," and validation moves into the cloud through what he calls "road-to-cloud in one day."
OTA opens a new attack surface — ISO 21434, UNECE WP.29 R155, R156.
The same over-the-air channel that lets the OEM upgrade your car also lets an attacker corrupt your brakes. Once a vehicle is internet-addressable, it inherits the threat model of every other internet-addressable thing — only with kinetic consequences. The industry has responded with ISO 21434 (the cybersecurity engineering standard, ratified 2021) and UNECE WP.29 regulations R155 (cybersecurity management systems, mandatory for new type-approvals from July 2022) and R156 (software update management). Penetration tests, vulnerability disclosure, secure boot chains, signed-update verification — all of it is now a regulatory minimum.
Prashant references the work obliquely — Continental Edge with AWS, partnership with VISA for in-car payments, the stringent integration testing every third-party app must pass before it can ride on a Continental display. The deeper point is that cybersecurity is not a feature in a car; it is the table-stakes for being allowed to type-approve a vehicle in Europe at all. Tier-ones that internalised this early are now selling cybersecurity engineering as a discrete product line.
The Visa-in-the-car partnership is a glimpse of the wider rewrite.
One of the most quietly revolutionary lines in the conversation. Prashant mentions, almost in passing, that Mercedes-Benz customers in the UK and Europe can now do financial transactions while sitting inside the car safely through Visa. The car is becoming a wallet. A fuelling station, a tollbooth, a drive-through, a parking meter — each becomes a payment endpoint authenticated by the vehicle rather than the phone. The technical pieces (tokenised PAN, secure element in the head unit, biometric driver auth) are not exotic. What is new is the willingness to put a payment surface inside a moving safety-critical artefact.
The business-model implication is the more interesting part. Once Visa is in your dashboard, the tier-one and the OEM start sharing revenue with the network. Continental's car-as-IoT framing — "extended IoT device" he calls it — is the architectural language for this future. Every function in the car is a potential service endpoint. Every endpoint is a potential revenue line. The tier-one that owns the orchestration layer between car and external service owns a piece of every transaction.
Continental India: ten thousand employees, five thousand engineers, full design ownership.
The India operation is not a back office. Prashant breaks the numbers down without flourish: ten thousand-plus employees across seven plants, five thousand-plus R&D engineers in Bangalore, and increasingly the global lead for specific product lines. Bangalore is the worldwide platform-responsible centre for radar — design, development, validation, integration, sustaining. Two-wheeler single-channel ABS is fully Indian-led; the home market drives the global product. The Center of Excellence model that Cognizant, Wipro, and Infosys built in IT services has migrated, with a generation of compounding domain depth, into automotive.
The corollary, which Prashant offers near the end of the conversation, is that universities are not yet producing engineers ready for this work. Continental spends six months on each new hire bringing them up to the bar. The fix is upstream — Continental is signing MOUs with universities to influence curricula in semesters five through eight, and is in discussion with a few institutions to insert the full eighth-semester curriculum directly. The talent funnel is being redesigned, not just recruited from.
Sense-Plan-Act: the secret name of every ADAS function.
Prashant gives the cleanest one-line architecture of advanced driver-assistance systems in the conversation. Sense — cameras, radar, lidar, ultrasonic sensors take in the world. Plan — the electronic control unit (or adaptive control unit) processes the information in a fraction of a second. Act — the actuators (brake, steering, throttle) execute. The classic AEB (automatic emergency braking) example: radar detects an obstacle, the ECU computes time-to-collision faster than the driver can react, the brake fires before the human has noticed there was anything to react to.
What makes the architecture hard is not any single step. It is the latency budget. From photon hitting the sensor to brake-line pressure rising, the total window is tens of milliseconds. Every layer — sensor fusion, perception, prediction, planning, actuation — has to fit inside it. AI is increasingly inside every layer; the perception stack alone is now mostly deep learning. But the discipline that holds the latency budget is what separates a tier-one from a start-up demo.
India is structurally short on road safety — and the government is closing the gap.
The number Prashant offers, almost matter-of-fact, is hard to read past. Globally, about 1.45 million people die on roads each year. India contributes roughly 150,000 of those — ten percent of the global total, against a population share of roughly seventeen percent of humanity but a vehicle share of a small fraction. The fatality rate per vehicle is among the highest in the world. He credits MoRTH (Ministry of Road Transport and Highways) and the recent regulatory cadence — AIS standards, ABS mandates on two-wheelers above 125cc, mandatory dual airbags, the slow-but-real introduction of NCAP-style crash testing — with closing the gap meaningfully over the last five to six years.
The downstream consequence for Continental's India business is straight-line growth. Every regulatory tightening — emissions Euro-IV to Euro-VI (BS-VI in Indian nomenclature), Bharat NCAP, CAFE norms, the proposed cybersecurity AIS-189 — translates into specific product orders. A car safety supplier in India in 2026 is, structurally, in a tailwind that did not exist a decade ago.
The $1.5T software opportunity by 2030.
Prashant unpacks the size of the prize with disciplined numbers. In 2020 the global automotive market was about $2.75 trillion. Of that, $2.5 trillion was pure mechanical — metal, rubber, glass, the everything that you can touch. Three hundred billion was software embedded in the vehicle. Thirty billion was software-as-a-service: the connected-car, OTA, telematics layer. The projection he carries from the Hanover sessions: by 2030, the market grows to $5.4 trillion, embedded software rises from $300B to $1.5 trillion, and software-as-a-service rises from $30B to $300B. Software quintuples. SaaS goes up tenfold. Mechanical roughly doubles.
Two implications fall out. The first is that the centre of gravity of automotive engineering value is moving from atoms to bits faster than most non-specialist observers realise. The second is that the cake is large enough that the tier-one, the OEM, the cloud hyperscaler, the chip vendor, the model-foundation lab, and the systems integrator can all win — but only one of them per layer wins biggest. Continental's bet is to own the middleware-and-domain-controller layer. The Apples, Googles, and Olas of the world are betting on layers above and below.
Tesla, Apple, Google, Waymo, Ola — the disintermediation question.
The most candid passage of the interview. Prashant names them by category: software companies like Apple or Google, autonomy-natives like Waymo, two-wheeler aggregators like Ola who started as ride-hailing and are now building cars themselves. He frames the threat clearly — these challengers feel the software content of the car is now so high that their core competence is enough to win. The traditional tier-ones come from a different philosophy: design, picking, validation, "unless everything is 100% perfect we don't launch." The software-native philosophy is launch then fix.
The interesting move is his answer. It is not "we are right, they are wrong." It is "cross-learning has to happen with both companies." Continental needs to internalise software-style iteration in the layers where it is safe. The software natives need to internalise safety-critical discipline in the layers where it is not. Whichever side closes its gap first wins the next decade. The honest read on Tesla is that they have made significant progress on the second; the honest read on most legacy tier-ones is that they have made meaningful but incomplete progress on the first.
Continental Edge + AWS, Google partnership — the hyperscaler dependency.
Two announcements live inside the same conversation. First: Continental Edge is built in collaboration with AWS — the company's vehicle-cloud platform sits on Amazon's hyperscaler. Second: Continental has just announced a partnership with Google for generative AI applied to interior displays and voice interfaces. The dependency, if you read it cynically, is uncomfortable: a hundred-and-fifty-two-year-old industrial firm now relies on two American hyperscalers for its software-defined-vehicle backbone. The European regulatory conversation around sovereign cloud (Gaia-X, the EU Data Act) lives precisely in this tension.
The pragmatic reading is the more interesting one. Building hyperscale cloud from scratch would have taken Continental a decade of capital outlay it does not have. Partnering means it ships in 2027 instead of 2034. The trade is operational dependency for time-to-market. The mitigation is contract structure — multi-cloud abstractions, data-residency clauses, exit-rights language. The exposure is real and reasonable people inside the company are paid to worry about it.
MISRA C, AUTOSAR Classic, and the Rust question.
Prashant does not name the coding standards in the interview — they live a layer below the conversation — but they live under everything he says about software discipline. MISRA C (the Motor Industry Software Reliability Association's C subset) has been the lingua franca of safety-critical automotive code since the late 1990s. AUTOSAR Classic, written in MISRA-compliant C, runs in the eighty-to-a-hundred distributed ECUs he describes. The argument in the next-generation community is whether MISRA C is fit for the new architecture or whether Rust — with its compile-time memory safety guarantees — is a better fit for the post-2025 stack.
The honest read: the industry is experimenting. Volvo and a handful of others have shipped Rust in vehicle code. AUTOSAR Adaptive uses C++ rather than C, partly to gain some of the safety properties Rust offers. Wholesale replacement of MISRA C is implausible inside the decade; coexistence is the realistic path. The deeper signal is that the language debate is finally on the table at all — for two decades it was settled and unfashionable to question. That is changing.
Eclipse Foundation: competitors building shared substrate.
One of the most underreported facts in modern automotive software, and Prashant offers it cleanly. Two years ago, the OEMs and tier-ones — companies that compete viciously in every other room — formed an Eclipse Foundation working group (Eclipse SDV: Software Defined Vehicle) to share substrate and find joint solutions for problems the industry faces as a whole. Open-source middleware, common security frameworks, shared tooling for AUTOSAR Adaptive. Competitors collaborate on the layers that benefit nobody to re-implement, and differentiate where customers actually care.
The strategic logic is clean. AOSP (Android Open Source Project) and Linux in cars (Automotive Grade Linux, QNX for safety-critical) have already demonstrated that base-layer commoditisation accelerates everyone's roadmap. Eclipse SDV is the European industry's answer to AGL — keep the substrate open, keep the differentiation in the application layer. Prashant frames it as the industry recognising that "win-lose becomes win-win." It is also a hedge against being individually disintermediated by an American hyperscaler.
Industry 4.0 inside the plant: cobots, AR goggles, predictive analytics.
The plant side of the conversation is overlooked but rich. Prashant defines Industry 4.0 in one sentence: full visibility of material flow through the value chain, end to end. Every machine instrumented, every data point streamed to a central server, algorithms running predictive and prescriptive analysis ahead of incidents rather than diagnosing them after the fact. The textbook definition is data-king; the lived definition is "use this data to act before the problem occurs." On the floor that looks like cobots (collaborative robots) working alongside humans on repetitive tasks; AR goggles letting a remote technician in Germany walk an Indian shop-floor engineer through an install; and digital twins running validation in the cloud while the physical line keeps producing.
The COVID anecdote he offers is the cleanest illustration. Production-Part-Approval Process (PPAP) requires customer-witnessed two-day production runs — a hard requirement in automotive procurement. Nobody could travel. Continental put AR goggles on the line supervisor; the customer in Delhi or Mumbai or Stuttgart watched the run through them. The audit cleared. The same approach now extends to equipment installation, maintenance training, and second-level technical support. Tools the industry was experimenting with in 2019 became table stakes inside eighteen months.
The Indian EV map and where Continental sits inside it.
Prashant does not enumerate the players, but the conversation lives downstream of them. Tata Motors has consolidated its position as India's largest EV manufacturer, with Punch.ev and Curvv.ev pushing volume; JLR's electrification programme drives the high end. Mahindra has bet aggressively on the BE6 and XEV9e, both born-electric platforms. Maruti is finally engaging through the e-Vitara. Hyundai is shipping the Creta Electric. Two-wheelers — Ola Electric (post-IPO, now in a difficult phase), Bajaj Chetak, Ather, TVS — are racing to capture the largest commuter-EV market in the world. Each one needs ECUs, battery-management-system electronics, motor controllers, ADAS modules, infotainment.
Continental's positioning is platform-neutral by design. It supplies "almost every single OEM," in his words, across two-wheelers and passenger cars. The internal-combustion-engine roll-off is happening, but the tier-one's order book stays full because each EV needs more electronics, not fewer — and most of the electronics Continental supplies are powertrain-agnostic. The hedge is structural: as long as the vehicle moves and is regulated, Continental is in the bill of materials.
Lines worth keeping near your desk.
The jargon, unpacked.
Some will be obvious; some won't. Skim, mark the unfamiliar, come back later.
Check what you actually retained.
Try to answer before you click. The point is to notice where the conversation is fuzzy in your memory, then return to the transcript.
Five questions worth sitting with.
No correct answers. Type into the boxes — your responses are saved locally and exportable along with your notes.
Prashant draws a sharp line between "launch then fix" software and "100% perfect before launch" automotive. Where in your own work is that line — and which side of it are you actually disciplined for?
The architecture inside cars is collapsing from 100 distributed ECUs to one central brain plus middleware. Where in your own systems is consolidation overdue — and what is the cost of starting it three years late?
Continental's India operation crossed the threshold from cost arbitrage to core design without an announcement — only in retrospect was it obvious. Where in your industry is a similar threshold being crossed quietly right now?
The Eclipse Foundation working group is competitors collaborating on substrate so they can differentiate higher. Where is your own industry's substrate ripe for being open-sourced, and who would lose if it were?
Prashant's daily routine is two hours of walking. Across a thirty-year career he protects it before he protects almost anything else. What is the equivalent ritual in your week, and have you let it slip in the last quarter?
Where to push back.
The strongest version of each disagreement, written to be persuasive — not to win.
"Tesla proves you don't need this rigour."
The honest counter has three layers. First, Tesla has internalised more safety-critical discipline than the dismissal credits — its safety engineering team is large, its hazard analysis is real, its software architecture is more layered than the marketing suggests. The brand is iconoclastic; the engineering is closer to mainstream than people think. Second, the public-safety record runs in both directions — Tesla has shipped genuine breakthroughs (sentry mode, FSD evolution) and genuine regrets (autopilot crashes, NHTSA investigations, mass recalls of beta features). Third, the regulatory clock has caught up: UNECE R155, R156, ISO 21434, the EU AI Act, China's auto-cyber rules. The room in which Tesla operated 2014-2020 no longer exists; everyone in the industry is now playing the same compliance game. The argument that "you don't need the rigour" was, at most, a brief window. The window is closing.
"SDV eats tier-one suppliers."
The version of this claim that is correct is also limited. Yes — if the tier-one ships pure commodities, it is disintermediated. The version of the claim that is too strong assumes OEMs can build the safety-critical software stack themselves. Most cannot, certainly not on the talent budget they have allocated. The tier-one that owns differentiating middleware, ASIL-D-certified base software, and twenty years of process maturity has the asset the OEM is trying to build. The realistic outcome is a layered economy: hyperscaler at the bottom (cloud), tier-one in the middle (middleware, domain controllers, safety substrate), OEM at the top (brand, UX, customer relationship). Pure disintermediation would require OEMs to staff up the equivalent of a Continental software organisation. Volkswagen tried this with Cariad; the experience has been bracing. The middle layer is harder to displace than the dismissal suggests.
"Rust will replace MISRA C."
The serious counter is that the rate-limiting step is not the language. It is the tool-chain certification, the safety-case evidence base, the legacy code volume, and the workforce. ISO 26262 requires qualified compilers and linkers; the Rust qualification ecosystem is improving (Ferrocene, the Rust Foundation's safety-critical working group) but is a decade behind the equivalent for C. The installed base of MISRA C automotive code is on the order of one hundred million lines — replacement is implausible inside the decade. The realistic path is coexistence: Rust in greenfield safety-critical components where the tooling permits, C++ for AUTOSAR Adaptive applications, MISRA C in legacy AUTOSAR Classic for the foreseeable future. The teams that bet on wholesale replacement will discover they have been recruited to a methodology debate rather than a product programme.
"Indian automotive engineering can't move beyond services."
The conversation itself is the counter. Continental's TCI is the global platform-responsibility centre for radar — design, validation, sustaining — and for two-wheeler single-channel ABS. Bosch India, ZF India, Aptiv India have made comparable transitions in adjacent product lines. The Center of Excellence pattern that Indian IT services pioneered has transplanted into automotive over roughly two decades. The threshold question is whether a true automotive software product company emerges from Bengaluru or Pune in the next decade. Conditions are present in a way they were not in 2010 — domain depth across radar, vision, AUTOSAR, ASPICE, ISO 26262; venture funding willing to back hard-tech (KaaynaIQ, NewSpace, Ather's silicon team); and OEMs (Tata, Mahindra) willing to source critical electronics from Indian suppliers. The "back office" frame is correct for firms that have not yet crossed; it is wrong for the ones now crossing.
Three angles on Monday morning.
If you don't work in automotive, here's what to take.
If you're an engineer
- Map your work against safety-critical lifecycles even if your industry isn't there yet. Traceability, V-model, hazard analysis are not bureaucracy — they are a discipline that scales when the consequences of a bug do.
- Learn the latency budget for your system end-to-end. Most real-time bugs hide there, not in the algorithm. Measure photon-to-brake-pressure, not just function execution time.
- Pick a side of the AUTOSAR Classic / Adaptive transition. The middle of the migration is where promotions and platform leadership are being decided. Sitting it out is itself a choice.
- Read ISO 26262 Part 6 (software) end to end once. The conceptual return on the investment lasts the rest of your career, whatever your industry turns into.
- Treat cybersecurity (ISO 21434) as a peer of safety, not a sub-discipline. The disciplines are siblings; the regulator is increasingly going to treat them that way.
If you're a hiring leader
- Score candidates on safety-critical discipline, not just framework fluency. A C++ engineer who has shipped through automotive SPICE is worth two who have shipped only on consumer products.
- Bias toward engineers who can describe a hazard analysis. Most cannot. The ones who can have absorbed something most CVs don't show.
- Build the bridge between automotive and consumer-software cultures yourself. Each side undervalues the other; the leader who can fluently translate between them is the rarest hire on the market.
- Plan for the AUTOSAR Adaptive talent crunch. The supply is single-digit thousands globally. Either grow your own from AUTOSAR Classic backgrounds or pay an over-market premium for the transitioned engineers.
- Invest in university partnerships now. Continental's "influence semesters 5–8" approach is the workable answer; recruiting fully-formed engineers in a five-year talent shortage is the unworkable one.
If you're a strategist
- Track the migration ratio: percentage of OEM and tier-one engineering headcount allocated to AUTOSAR Adaptive vs Classic. It is the leading indicator of who survives the SDV transition.
- Watch UNECE rule cadence. R155 and R156 set the floor for 2022; the next wave (autonomous driving regulation, generative-AI-in-cockpit rules) is being drafted now. Procurement follows nine months behind.
- Read Eclipse SDV as a strategic signal. Competitors collaborating on substrate is a tell that the layer of competition has moved up. Re-price the stack accordingly.
- Take the $1.5T-software-by-2030 number seriously and decompose it into the four layers that share it (cloud / middleware / app / SaaS). The mistake is treating it as one TAM. It is four, each with a different winner.
- The Indian engineering threshold has been crossed. Quietly. The tier-ones already buying core IP from Bangalore will spend the next decade outcompeting the ones still treating it as cost arbitrage.
A hundred and fifty years of an industry, briefly.
The arc Prashant sketches in the conversation, lined up against the wider regulatory clock.
The whole conversation, searchable.
Click a timestamp to open YouTube at that moment. Click any line to highlight it (yellow). Highlights and notes save in this browser only.
00:00 in the page to seek.