What it takes to write the software inside a car.

The number Prashanth 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 as an architecture lesson rather than a boast. 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.

Prashanth 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.

Prashanth 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.

Prashanth'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.

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.

Prashanth 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."

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.

Prashanth 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.

One of the most quietly revolutionary lines in the conversation. Prashanth 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.

The India operation is not a back office. Prashanth 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 Prashanth 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.

Prashanth gives the cleanest one-line architecture of advanced driver-assistance systems in the conversation. Sense: cameras, radar, lidar and 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.

The number Prashanth 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 translates into specific product orders: emissions Euro-IV to Euro-VI (BS-VI in Indian nomenclature), Bharat NCAP, CAFE norms, the proposed cybersecurity AIS-189. A car safety supplier in India in 2026 is, structurally, in a tailwind that did not exist a decade ago.

Prashanth 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.

The most candid passage of the interview. Prashanth 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.

Two announcements live inside the same conversation. First: Continental Edge is built in collaboration with AWS, so 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.

Prashanth does not name the coding standards in the interview, since they live a layer below the conversation, but they sit 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.

One of the most underreported facts in modern automotive software, and Prashanth 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. Prashanth 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.

The plant side of the conversation is overlooked but rich. Prashanth 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.

Prashanth 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-wheeler makers, Ola Electric (post-IPO, now in a difficult phase), Bajaj Chetak, Ather and 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.