The software that runs your car is outgrowing the tools that built it
Modern vehicles are no longer mechanical products with a software layer on top, they are software platforms on wheels. The average car today runs hundreds of millions of lines of code spread across dozens of independent Electronic Control Units (ECUs), and in some cases, rivals commercial aircraft in sheer software complexity. Power management, body control, infotainment, and advanced driver-assistance systems all depend on code, and that code never stops changing.
Yet many automotive embedded teams are still anchored to workflows and architectures built for a very different era, one where a five-year development cycle was perfectly acceptable. Today, that timeline has been compressed to under two years, driven by what industry insiders call "China speed": the relentless pace at which new OEMs bring vehicles to market and push over-the-air (OTA) updates to customers. China's speed is no longer an exception. It is reshaping global expectations for how fast vehicles are designed, built, and updated.
This is what IAR calls the 100 million-line trap, and it has very practical consequences for every team building safety-critical embedded software for the automotive market.
Trying to move fast and break things, as we see in other industries, simply does not work in automotive software. Recalls and late fixes introduce unpredictable costs and long-term risk to the brand.
What makes the trap so hard to escape?
The core problem is not the volume of code itself, it is how that code is structured and managed. Traditional automotive platforms are built around dozens of independent ECUs, each running its own software stack, managed by its own supplier, with its own lifecycle, and communicating over a CAN bus that every system contends for.
In that environment, even a small change becomes a major coordination effort. Updating a single function may require multiple suppliers, extensive retesting across different ECUs, and fresh validation evidence before any safety certification body will sign off on the release. The result is slower releases, longer exposure to unpatched vulnerabilities, and a growing technical debt that makes every future change more expensive.
Four persistent challenges keep teams stuck:
- Legacy hardware constraints: Traditional ECU designs connected over CAN limit software reuse and slow development due to tight hardware coupling, bandwidth, and memory boundaries.
- Misaligned processes: Hardware-centric development models clash with modern DevOps and CI/CD practices, making automation, simulation, and reproducible builds difficult, and software growth is outpacing hardware growth on these systems.
- Fragmented architectures: Without a unified approach, teams build proprietary stacks that struggle to integrate AUTOSAR, service-oriented middleware, and mixed communication protocols.
- Compliance complexity: Meeting ISO 26262 functional safety and ISO/SAE 21434 cybersecurity requirements across dozens of ECUs is slow and resource-intensive. Even small changes can trigger full recertification.
- Pre-integrated software bundles with partners including Infineon, Qt, Vector, and Elektrobit deliver ready-to-use, validated foundations, graphics stacks, safety-critical control software, that let teams go from concept to production without starting integration from scratch.
- Validated AUTOSAR Classic and MCAL integrations with partners such as Vector, ETAS, and Elektrobit deliver deterministic, ISO 26262-optimized workflows for safety-critical MCUs, reducing integration risk and recertification effort. Scalable ECU development across domains, while still meeting the highest safety requirements.
- CI/CD pipeline specialists such as Dojo5 can set up and maintain containerized pipelines for teams that lack in-house DevOps expertise. They can establish the pipeline and hand it over, train engineers to maintain it, or run it on an ongoing basis, meaning that the absence of a dedicated CI/CD specialist is not a barrier to adoption, even for small teams.
When these challenges compound, scaling automotive software becomes extremely difficult and it explains why new architectures and workflows are no longer optional.
Rethinking the architecture: From domains to zones
Escaping the trap requires rethinking both the vehicle architecture and the development workflows that surround it. Traditional automotive platforms are built around ECU-centric domain architectures, body, powertrain, ADAS and even within these structures, teams face duplicated software, complex wiring, and slow system-wide updates.
Image: Siemens Digital Industries
The industry is now moving towards zonal and mixed-domain zonal architectures. Rather than organizing ECUs by function, zonal designs group them by physical location on the vehicle and connect them to centralized or regional compute structures. This reduces cabling and weight, increases data throughput, and critically simplifies integration and updates.
As more functions consolidate into fewer, more powerful controllers, containerization and virtualization become essential: they allow mixed-criticality software to run safely on shared hardware. But for this to scale, software must be decoupled from hardware, enabling reuse and updates without constant requalification. That demands new workflows, tighter collaboration across hardware, software, functional safety, and cybersecurity teams, and unified toolchains with reproducible CI/CD pipelines.
Modern architectures only deliver value when the workflows evolve with them.
OTA updates, reproducible builds, and the long game
In a software-defined vehicle world, software does not stop changing at the Start of Production (SOP). Frequent over-the-air updates, even in safety-critical systems, are now the norm. Vehicles must be patched, updated, and improved in the field throughout their entire lifetime, something that traditional V-cycle processes alone cannot support.
This creates a requirement that many teams underestimate: they must be able to rebuild the exact same software years later to validate OTA updates, investigate field issues, and maintain functional safety compliance. Containerization is the key enabler. By locking toolchains and building environments inside containers, teams produce deterministic, traceable binaries that regulatory authorities can trust, the same binary on the developer's machine, in the CI pipeline, and in the OTA delivery system.
This is not a theoretical benefit. A practical demonstration during IAR's webinar showed a motor control project building correctly in a GitHub Actions pipeline but failing on a local developer machine with the same toolchain version and source code, resulting in different output. The missing piece: device support files for Infineon MCUs that were present in the containerized Docker image but absent from the local install. Opening the project inside a dev container, the same environment the pipeline uses, resolved it immediately. Same build. No errors. That is what reproducible builds look like in practice.
And because vehicles last 10, 15, or even 25 years or more, long-term support is not a nice-to-have. It is a foundation for maintaining functional safety compliance. Every toolchain change creates friction for development teams and for safety re-qualification. Without stable, supported toolchains, every OTA update after year five becomes a recertification project. Long-term support keeps CI/CD pipelines and safety evidence valid, enabling fleet-wide OTA updates to be safe, compliant, and predictable throughout the vehicle's lifetime.
The IAR Platform: Built for the full vehicle lifecycle
IAR addresses these challenges with a safety-certified development platform designed not just for launch, but for the entire lifecycle of a software-defined vehicle, from first design commit through decades of field updates.
Safety certification up to ASIL D from day one
IAR’s toolchain is TÜV SÜD-certified to ISO 26262 up to Automotive Safety Integrity Level D (ASIL D), the highest level of functional safety rigor. This matters more than many teams realize. Without a pre-qualified toolchain, teams typically spend between six and twelve person-months re-qualifying their compiler for every new certification project, running extensive tests to demonstrate that the toolchain produces repeatable, standard-conforming results.
With a pre-certified toolchain, that evidence already exists. Teams submit the tool certificate to their certifying entity, which then focuses on the application's safety functions and the testing performed on them, not on the toolchain itself. The savings in time, cost, and risk are substantial.
This also argues with a decision that surprises some teams: functional safety tooling should be chosen at the very beginning of a project, not introduced mid-development. Switching toolchains once a program is underway is one of the most disruptive things a team can do, and certification authorities will take a dim view of it. In practice, once a team standardizes on a certified toolchain, they keep it for the product's full lifecycle, typically 10 to 15 years. The toolchain selection is a program commitment, not a procurement detail.
Debugging, analysis, and code quality built in
Advanced debugging and tracing capabilities, including multi-core debugging, live code profiling, and RTOS awareness, make complex SDV systems observable and predictable. Built-in static analysis with C-STAT and runtime analysis catch issues early in the cycle, while model-based design and MISRA-compliant code generation support structured, certifiable development. The result is quality and compliance established automatically at each build, so updates do not become last-minute risk assessments.
Broad MCU/MPU coverage, no hardware lock-in
IAR supports ARM, RISC-V, Renesas, STM8, and many other architectures, with deep device support for silicon from Infineon, NXP, Microchip, STMicroelectronics, SemiDrive, and more. This breadth lets teams reuse software across ECUs, zones, and vehicle generations rather than rewriting for each new platform, a critical advantage as volatile supply chains continue to force hardware pivots. Flexibility today protects long-term programs tomorrow.
CI/CD, containers, and the modern embedded workflow
IAR integrates directly into modern CI/CD environments: GitHub Actions, GitLab CI, Jenkins, and Kubernetes, so embedded software teams can move with the same velocity as cloud software teams. The IAR extension for VS Code and IAR Build Tools for headless builds bring the same safety-certified toolchain into containerized DevOps pipelines. Cloud-enabled licensing means the toolchain travels with the team, not with a fixed machine. Containerized environments remove the friction from day-to-day development: builds are predictable, updates are repeatable, and the "works on my machine" problem disappears.
An ecosystem built for production at scale
Moving at China speed requires more than a good toolchain, it requires an ecosystem of pre-validated integrations that eliminates months of bring-up effort. To avoid custom glue code and fragile workflows, IAR has built a partner ecosystem that lets teams start from proven foundations:
That last point matters more than it might appear. Containerization is often assumed to be a concern only for large organizations with dedicated platform teams. It is not. In smaller teams, it is common for one developer's machine to quietly become the de facto build server. When that person is unavailable, builds stop. Containerization removes that single point of failure, makes onboarding straightforward, and positions the team to scale without rebuilding its infrastructure when growth demands it. The investment is modest. The risk reduction is not.
Why long-term support is a safety issue, not a vendor decision
Automotive software has a lifecycle unlike almost any other industry. Electric vehicles are designed to last the better part of a buyer's career. Features must be added, defects must be patched, and security vulnerabilities must be addressed, possibly 20 or 25 years after SOP. During that entire period, teams need to rebuild software, issue OTA updates, and produce compliance evidence that regulators will accept.
That requires a toolchain supplier who will still be present, supported, and capable of issuing certified maintenance releases two decades from now. Long-term support is not an operational detail, it is a foundation for maintaining functional safety in software-defined vehicles. Without it, every tool update after the first few year’s risks invalidating existing safety evidence and forcing costly re-qualification.
IAR has been in business since 1983. Long-term assurance services, maintenance releases, certified service packs, and stable licensing are built into the platform model precisely because automotive software outlives most technology companies. This is worth factoring in at procurement time: the toolchain decision is one your team will live with for the full program lifetime, which in automotive often means outlasting the careers of the engineers who made it.
Build with confidence today and maintain that predictability for the long road ahead.
Fewer surprises, more time building what matters
The 100-million-line trap is real, but it is not inevitable. Teams that rethink their architecture, modernize their workflows, and anchor development on a safety-certified platform with genuine long-term support can escape it.
What this looks like in practice: pre-certified solutions up to ASIL D reduce certification effort and risk from the first sprint. Modern workflows and containers let teams move faster without sacrificing code quality. The platform surfaces issues early, limiting the recalls and late-cycle fixes that introduce the most unpredictable costs. Combined with broad AUTOSAR and MCAL support, deep MCU/MPU coverage, and a strong third-party ecosystem, teams gain the flexibility to build across architectures, vendors, and vehicle domains without rewriting the same software for each one.
Less overhead. Fewer surprises. More time delivering the features that define your brand at the pace modern automotive software demands. That is the IAR Platform.
What’s next?
Watch the on-demand webinar ”Escaping the 100 M-line Trap: From Legacy Silos to Agile Software-Defined Vehicles” for a practical demo, including how containerized builds eliminate the "works on my machine" problem for safety-critical embedded development.
Or try the interactive demo to see how the IAR Platform helps you de-risk ISO 26262 compliance with safety-certified compilers and code analysis, advanced debugging, and modern CI/CD.
