Automotive SoftwareIn vehicle software, speed comes from fewer hand-offs.
Automotive Software/NRG Insights
In vehicle software, speed comes from fewer hand-offs.
Some carmakers change their cars' software almost as readily as technology companies update an app. NRG's analysis traces the gap to something countable: how many times a requirement changes hands on its way to code, between companies and between documents. One large Asian carmaker group's public record shows a company setting out to cut that count: it first said every vehicle in its line-up would soon be software-defined, then, years later, set a separate date for its first mass-produced software-defined vehicle. NRG reads the two as different milestones.
Much of what a driver sees and feels in a modern car is now set by software, and the number of hand-offs behind that software decides how fast it can change.
本研究简报以英文发布。
Some carmakers now change a car's software almost as readily as a technology company updates an app; for others, a change still waits for the next model year. The gap is usually put down to culture, or to how many software engineers a company can hire. NRG's analysis points to something more mechanical, and easier to count.
It is the number of borders a single requirement crosses between the moment someone writes it and the moment it runs in a car. A border is any point where the requirement must be handed to another company or copied into another document. Each crossing adds a step that has nothing to do with writing the software, and the step is repeated every time the requirement changes. The development model underneath is common ground. The V-model, with requirements broken down on one side and tests built back up on the other, is shared industry practice: functional-safety practice is written around it, and Automotive SPICE, which its publisher says leading carmakers and suppliers use to assess how software-based systems are developed, is a common yardstick on both sides of a supply contract. The V does not show which company draws each part of it, and that is where carmakers differ. The ones that ship quickly have removed borders.
The public record of one large Asian carmaker group shows a company setting out to remove them. Early in the decade, the group said it would make every vehicle software-defined, and able to receive over-the-air updates, within a few years, and pledged a large multi-year investment to strengthen its software capabilities. This year it said its first mass-produced software-defined vehicle would arrive later in the decade, with Level 2+ automated driving developed with a chip supplier. The two statements describe different milestones: a line-up able to receive over-the-air updates, and a first car whose software is designed as one system.
Both kinds of border leave public traces. The company border shows in the share of a car's controllers that the carmaker designs itself, a share that has moved sharply at one electric-vehicle maker, as the next section shows. The document border shows in the standards built to manage it. The Object Management Group, which maintains the Requirements Interchange Format, starts from the observation that "two companies in the manufacturing industry are rarely able to work on the same requirements repository". The format exists so that requirements written in one company's tools can be exchanged with another's as files.
Seen as borders, the speed gap is arithmetic rather than culture. A requirement that crosses two borders pays for both each time it changes; one that crosses none pays only for its review. Vehicle software changes constantly, and over-the-air updates keep it changing after the car is sold, so the difference compounds with every release.
The company border is the more visible of the two. When a carmaker buys a controller with its software, the requirements travel under a supply contract, so changing them is a commercial matter as well as an engineering one. The arrangement exists for good reasons — a supplier's development cost is shared across many carmakers — but it puts a commercial step on the path of every change. The document border follows from it: every change makes the trip out of one company's system and into another's, and every trip is a chance for a line to be read differently.
Removing a border does not mean removing discipline. When a carmaker owns the architecture and writes more of the software itself, the Object Management Group's premise no longer applies: one requirements repository becomes possible, and a change is made where the requirement lives instead of being shipped as a file. Review and functional-safety evidence remain; the commercial step and the file exchange do not. The two ends of this spectrum, which this article calls the contracted and the integrated model, are archetypes rather than descriptions of any company discussed here; every carmaker runs some mix of both.
A requirement that crosses a company border travels as a document, and every change sends it on the trip again. Removing the border keeps the review and the safety evidence; it removes the copying.
Different routes across the same borders
Public examples show that the borders can be removed in more than one way. The routes differ in which border they remove and in how much a carmaker has to own to remove it, and none of them is a template.
One German premium carmaker took back the architecture. When it previewed its own vehicle operating system, with partners that included a large technology company and a chip supplier, its chief executive said the company had decided to be the architect of that system. The system arrived later than first planned, in a new model presented as the first vehicle to run entirely on it, with over-the-air updates of the entire vehicle software, driver-assistance systems included. In NRG's reading, that is a border strategy: by owning the operating system, the carmaker rather than each supplier defines the platform its software is written for.
A group of Chinese carmakers has taken another route: keeping the company border but having only one partner on the other side of it. Their cars are sold through an alliance led by a Chinese technology group. According to CarNewsChina, the core driver-assistance and smart-cabin technologies in those cars are developed by that group, and the brands are standardizing shared components such as the cockpit operating system. The software-heavy domains are still bought, but from one partner rather than from many suppliers.
One electric-vehicle maker has gone furthest: it is designing the boxes itself. According to IDTechEx, writing in MOTOR, the share of controllers it designed in-house rose model by model from about a fifth to more than four-fifths, and the company has stated a target of designing every controller in its next-generation vehicle in-house. When the carmaker designs the controller itself, the company border disappears, and the document border with it. So does the supplier's ability to spread development cost across many customers, which is why few carmakers can follow this route all the way.
One EV maker — share of controllers designed in-house
A fifth → all
About a fifth in an earlier model, more than four-fifths in a later one, and a stated target of all controllers in the next-generation vehicle. Owning the controller removes the company border outright. Source: IDTechEx in MOTOR (2023); the target is the company's own.
“A carmaker becomes fast in software by cutting the number of times a requirement changes hands — between companies and between documents — before it reaches the car.”
— Nathan Research Group, NRG Insights
How one carmaker group is moving its borders
The Asian carmaker group's public record over the past few years reads as an attempt to remove borders in a particular order: first the architecture, then the cockpit.
Stage
Public statement
Border addressed
First
Large multi-year investment to strengthen software capabilities; every vehicle software-defined and OTA-capable within a few years; fewer, more integrated controllers
Sets the target
Second
Software brand; in-house vehicle OS; central computer plus zone controllers
Architecture: one platform to specify against
Third
New infotainment system on a facelifted large sedan; tens of millions of vehicles targeted by the end of the decade
Cockpit
Latest
First mass-produced software-defined vehicle later in the decade, with Level 2+ automated driving developed with a chip supplier
Announced target date
One Asian carmaker group's public software-defined-vehicle milestones, in the order announced. Targets are the group's own; the third column is NRG's reading. Sources: company announcements and press coverage.
The first border was architectural. The group launched a software brand built on an in-house vehicle operating system and an electrical-electronic architecture that pairs a high-performance vehicle computer with zone controllers, with the stated aim of decoupling hardware and software development. The second was the cockpit: a new infotainment system, built on a third-party automotive operating system, was slated first for a facelifted large sedan, and the group aims to put it in tens of millions of vehicles by the end of the decade.
A central computer with zone controllers gives the carmaker one platform to specify against. The fewer boxes it buys with another company's software inside, the fewer borders each change has to cross.
The five-year outlook: software grows faster than the car
The market these borders sit in is growing faster than vehicle sales, though no two forecasters measure it the same way. Estimates of the automotive software market alone cluster around US$19–20bn for 2023–2025: MarketsandMarkets puts it at US$19.0bn in 2023, Mordor Intelligence at US$19.28bn in 2025 and Global Market Insights at US$19.8bn in 2025. Grand View Research starts from US$33.0bn in 2025, a base high enough to imply a wider definition. Growth rates run from about 8% to 16% a year, and the two narrower forecasts that stop at the turn of the decade land at roughly US$32–33bn by 2030–2031.
Source
Base
Forecast
CAGR
MarketsandMarkets
US$19.0bn (2023)
US$32.3bn (2030)
7.8%
Mordor Intelligence
US$19.28bn (2025)
US$32.93bn (2031)
9.33%
Global Market Insights
US$19.8bn (2025)
US$56.5bn (2035)
11.1%
Grand View Research
US$33.0bn (2025)
US$108.6bn (2033)
16.4%
Automotive software market — independent estimates and forecasts. Scope differs by publisher, so compare growth rates rather than levels; Grand View Research's higher base points to a wider definition. Sources: MarketsandMarkets; Mordor Intelligence; Global Market Insights; Grand View Research.
The wider frame tells the same story. In The Automotive Software and Electronics Market Through 2035, McKinsey projects software and electronics together reaching US$519bn by 2035, a 4.5% compound annual rate against around 1% for the global vehicle market, with cars at Level 2 or higher making up nearly 70% of global sales by then. Value inside the car is shifting toward the parts that are written rather than stamped.
Automotive software and electronics, 2035
US$519bn
Projected global market for automotive software and electronics, growing at a 4.5% CAGR against around 1% a year for vehicles. Source: McKinsey, The Automotive Software and Electronics Market Through 2035, as reported by ANI (July 2026).
Over the next five years, two shifts follow from the border analysis. Requirements will increasingly move between companies as structured data rather than documents, because a carmaker that updates software after sale cannot afford a manual re-entry on every change. Supplier contracts will shift from pricing boxes toward pricing software components, integration and long-term update support, as carmaker-owned operating systems and architectures like those described above turn controllers into hosts for software the carmaker specifies. Neither shift removes review or safety evidence. Both make each remaining border more expensive to keep.
What to watch
Whether the Asian carmaker group's first mass-produced software-defined vehicle holds the later-in-the-decade timing it announced.
How far over-the-air updates reach beyond infotainment into driver assistance and core vehicle functions, as the German premium carmaker says its new model already does.
The share of controllers carmakers design in-house — the clearest public measure of the company border.
Whether requirements exchange between carmakers and suppliers moves from documents to shared, structured data.
For any carmaker, the date of a first fully software-defined vehicle depends heavily on how many of its domains can be specified and changed without crossing a contract. The lesson also generalizes beyond cars. In any industry where a product is assembled from parts made by many companies — aircraft, ships, industrial machinery — software exposes the cost of each hand-off, because software changes more often than hardware and every change must cross every border again. The organizations that ship software quickly have counted their borders and decided which to remove, which to keep and which to hand to a single partner.
How this article was made. Figures come from public sources — company announcements and filings, press coverage, standards bodies and published market research — cited in the text. The border analysis and the contracted and integrated models reflect NRG's own research into automotive software practice, described at process level only; the two models are archetypes, not descriptions of any company discussed in the article. Companies are described rather than named. A figure from NRG's research rather than a public source would be shown as a rounded range marked "NRG estimate" and published only where public evidence points the same way; this article contains none. This is business and market research, not investment advice.
与 NRG 合作的方式
与 Nathan Research Group 合作。
Announcements show the dates, the budgets and the architecture diagrams; they do not show how the hand-offs between companies work in practice. That knowledge sits with the people who specify, build, buy and maintain vehicle software. Reaching them, compliantly, is what we do.
韩国首家专家网络 — 首尔，2013年至今
我们会请谁到场
Vehicle architecture specialists
Central computing and electrical-electronic architecture, and how carmakers decide which functions to consolidate onto fewer computers.
Embedded software engineers
Software for vehicle controllers and central computers.
Supplier-management specialists
How carmakers work with software and electronics suppliers, across the industry.
Systems-engineering and requirements specialists
Requirements management and functional-safety practice.
Automotive software market specialists
Market sizing, the supplier landscape and how value in the vehicle is shifting from hardware to software.
