Automotive SoftwareVehicle software: who can approve the next change?
Automotive Software/NRG Insights
Vehicle software: who can approve the next change?
Owning more software can change who controls a release. It does not remove internal review, tool differences or integration work. NRG examines decision rights, requirements traceability and the limits of the public evidence on development speed.
Software changes after a vehicle is sold. Release control depends on code rights, interfaces and the evidence needed to approve a change.
A software release can wait even after the code is complete. The unanswered question may be who can approve a changed interface, whether a licence permits the change, or which test result belongs to the current requirement. These are distinct constraints, and bringing development in-house does not resolve all of them.
NRG treats coordination as a possible source of delay, not a measured explanation of the difference between regions or carmakers. The public sources reviewed here do not count actual hand-offs and link those counts to release times. They offer sourcing surveys, engineering standards and market models. Together they support a way to investigate a release process; they do not establish how much faster an ownership model makes it.
Ownership and speed are different measures
AlixPartners and Berylls surveyed 1,002 automotive executives in November–December 2025, including 495 automaker respondents, and published the results in April 2026. Among automaker respondents in each regional group, 41% in China reported primarily building their SDV software in-house, against 25% in the US and 27% in the survey’s EU/UK group. These are organisational sourcing responses, not shares of vehicles, controllers or code.
The same survey reports that 67% of automakers took more than eight weeks from code complete to deployment of a new SDV application at their organisation. That question does not establish customer-fleet rollout time. Nor does a regional sourcing percentage identify the release performance of a particular respondent. Architecture, reuse, safety scope and internal queues can all change the result.
We use cookies to understand how our site is used so we can improve it. Necessary cookies are always on. You can accept all, reject all, or choose what to allow. Learn more
Decision rights before hardware ownership
A contract can make a technical change depend on an external decision: a revised interface may require a new licence, a changed scope of work or support beyond the original agreement. This is conditional. Standard software with a clear interface and agreed update rights may need less negotiation than custom software developed inside a large organisation.
Roland Berger’s May 2026 analysis describes software being unbundled from hardware in automotive procurement. That makes software scope, licences, integration and support more visible as separate obligations. NRG’s interpretation is to inspect those obligations directly. Designing a controller internally is not a reliable substitute for knowing who may change the code, who approves an interface and who supplies the evidence.
Control point
What to establish
What ownership alone misses
Change authority
Code rights, licence scope and interface approval
External dependencies can remain inside an owned platform
Requirements exchange
Persistent identifiers, attribute meaning and revision state
Files may be automated; internal tools may still disagree
Release assurance
Impact analysis, integration tests and evidence links
Internal review and safety work survive consolidation
NRG analytical framework: questions to investigate, not measured effects or company archetypes. Public anchors: OMG ReqIF, prostep ivip and Roland Berger (May 2026).
Requirements may cross tools as structured XML. Stable identifiers and agreed change meanings matter more than whether the exchange uses a file.
Structured exchange still needs shared meaning
ReqIF XML is already structured requirements data. OMG’s exchange format allows tools to transfer requirements without sharing a repository. The January 2024 prostep ivip implementation guide explains how identifiers, attributes and embedded content can survive that transfer. Its four-step system-attribute example is an interoperability scenario, not evidence that every change requires manual re-entry.
Transport and meaning are different problems. A file can preserve an identifier while the receiving team interprets an attribute differently. A shared database can also contain inconsistent versions or broken links to tests. Useful checks include whether an identifier survives exchange, whether the current revision is unambiguous and whether impact analysis still points to the right verification evidence.
Automotive SPICE 4.1, dated August 24, 2026, provides a current process-assessment model. Its availability does not prove that every organisation has been assessed or that evidence from different tools is automatically comparable. NRG’s process synthesis is narrower: review and traceability remain necessary when responsibility moves. No single repository or software-ownership percentage proves a fast release process.
“The useful question is who can approve a change, and whether its meaning and evidence survive the journey.”
— Nathan Research Group, NRG Insights
Consolidation moves integration work
McKinsey’s January 2026 outlook covers light vehicles: passenger cars and light commercial vehicles. In its Current Trajectory model, distributed electronics fall from 71% of production in the 2025 model base to 47% in 2030 and 23% in 2035. These are modelled production shares, not the architecture of the installed fleet in 2026.
Fewer computers do not mean fewer integration tasks in the same proportion. Central and zonal systems combine functions and create dependencies across domains. Internal teams can retain separate tools and review queues; bought software can remain on internally designed hardware. Consolidation changes who performs integration and who pays for it. Net workload depends on architecture, reuse and assurance, not ownership alone.
Consolidating computers changes where integration happens. Software rights, interface responsibilities and safety validation still need explicit owners.
A five-year lens from 2026 to 2031
The August 2026 MarketsandMarkets edition estimates automotive software at US$43.22bn in 2026 and forecasts US$83.26bn in 2033, with 9.8% annual growth. The table uses current accessible publisher summaries. Different baselines and horizons remain visible; neither levels nor growth rates have been reconciled into a single market definition. Full paid methodologies were not reviewed.
Publisher
2026 estimate
Forecast
CAGR / interval
MarketsandMarkets
US$43.22bn
US$83.26bn (2033)
9.8% / 2026–2033
Mordor Intelligence
US$21.08bn
US$32.93bn (2031)
9.33% / 2026–2031
Global Market Insights
US$21.8bn
US$56.5bn (2035)
11.1% / 2026–2035
Grand View Research
US$37.4bn
US$108.6bn (2033)
16.4% / 2026–2033
Automotive software: publisher estimates and forecasts checked November 5, 2026. Estimates are not audited actuals; CAGRs refer to each publisher’s stated interval.
Applying each published CAGR for five annual intervals to an illustrative 2026 index of 100 gives about 156–214 in 2031 (NRG calculation). This is a rate illustration, not a set of published 2031 point forecasts, a probability range or a forecast of different ownership strategies. Normalising the base does not make market scopes comparable.
The longer structural view is separate. McKinsey models software and electronics together at US$519bn in 2035 under its light-vehicle scope. Its integration, verification and validation line rises from US$14bn in 2025 to US$27bn in 2030, about 93% growth (NRG calculation). That forecast does not show that external sourcing causes the integration bill, or that bringing code in-house reduces it.
After-sale activity is not a speed score
China’s SAMR records 1.756 million vehicles covered by OTA recall campaigns in 2025, or 25.7% of the annual recall vehicle count (NRG calculation). Campaign coverage is not verified repair completion. ResearchInChina’s issuer abstract separately reports OTA installation in 76.2% of China passenger cars in January–October 2025 and forecasts more than 95% in 2030. Those populations are different.
The downloadable report also separates a reported third-party city-NOA category from its unclassified remainder; the remainder cannot be called wholly in-house software. Regulatory dates apply to specified products and approval categories. China’s GB 47955-2026 has a January 1, 2027 effective date and was still forthcoming at this check. Detailed transition clauses and the substantive effect of the January 2026 amendment to GB 44496-2024 were not established here.
What to watch
Which changes require an external commercial decision, and which fall within existing code and licence rights.
Whether requirement identifiers, revision states and test links survive exchanges across tools.
How much elapsed release time is spent in internal review, integration and assurance after code completion.
Whether later sourcing surveys use the same question and population before comparing them with the late-2025 baseline.
How this article was made. Public evidence was checked on November 5, 2026; observation periods and forecast horizons are identified separately. The decision-rights and traceability framework is NRG’s bounded process synthesis, not a causal estimate of release speed. Public-input arithmetic is marked NRG calculation. A numerical internal-research range would be marked NRG estimate; this article contains none. Companies are described rather than named. This is business and market research, not investment advice.
Working With Nathan Research Group
Partner With Nathan Research Group
Architecture charts and sourcing percentages leave practical questions open: who may approve a change, how requirements remain traceable and where integration work waits. Industry practitioners can help a team investigate those questions within clear compliance boundaries.
Korea’s first dedicated expert network — Seoul, since 2013
Who we put in the room
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.
We turn your industry research question into a precise expert profile and question set, aligned with the decision you need to make.
2Source & vet
We screen and compliance-clear each expert — relevance, recency, and the absence of conflicts — before any call.
3Convene & synthesize
We arrange interviews on your timeline and, where useful, deliver written synthesis tied back to your questions.
If your team is evaluating vehicle software development, the software-defined vehicle transition, or the broader automotive software market, tell us the decision you’re trying to make.
A direct reply from a partner, not an intake form.
Based on public sources and NRG's own research. Figures marked NRG estimate are rounded ranges checked against public data. Nathan Research Group does not request or facilitate material non-public information, and runs every engagement through a documented compliance protocol.
