Nico Hartmann
CTO, Qorix
🗓️ July 29, 2026 | Reading Time: 6 min
If you ask an automotive software engineering lead how many configuration tools their team uses for the SDV stack, the answer is rarely one. It is usually three, four, or five. Sometimes more.
Each stack has its own incumbent: one tool for AUTOSAR Classic, another for AUTOSAR Adaptive, a third for Bootloader, perhaps a fourth for performance orchestration. Each with its own license, its own CI pipeline integration, its own binary file format, its own training curve. Each one a silo.
This fragmentation is so normalized that most teams have stopped questioning it. It is simply how automotive software configuration works.
But the cost is real. And it is larger than most organizations realize.
The cost of fragmented SDV configuration toolchains is rarely visible on a single line of a project budget. It accumulates across hundreds of engineering decisions, integration events, and review cycles.
The Integration Tax
Every release cycle in automotive software has an integration phase. This is the moment when configurations authored across multiple tools and multiple teams are brought together into a single system. And it is consistently where programs lose time.
The reason is structural. When each stack is configured in a separate tool with a separate file format, cross-domain consistency cannot be verified until integration. An AUTOSAR Classic runnable that references a task that no longer exists in the OS configuration. An Adaptive service that assumes a communication path that was not set up in the Classic Com-Stack. A Bootloader configuration that conflicts with a watchdog timer setting configured three weeks earlier in a different tool by a different engineer.
None of these errors are invisible in isolation. They are simply invisible across tools. And so they surface at integration. After days or weeks of downstream engineering have already been committed on a broken foundation.
The cost of finding and fixing a cross-domain configuration error at integration is not just the fix itself. It is the rework of everything that was built on top of it.
The Traceability Gap
Automotive software programs operate under ASPICE requirements. Configuration decisions need to be traceable: who made this change, when, why, and what was the impact on the system.
In a fragmented toolchain built on binary, proprietary file formats, this traceability is effectively impossible to maintain automatically. It has to be created manually, after the fact, by someone who was not always in the room when the decision was made.
Every team I have spoken to has a version of the same story: an ASPICE audit is approaching, and engineers spend days reconstructing the rationale behind configuration decisions that were made months ago, in a tool that does not support comments, does not integrate with Git, and cannot produce a human-readable diff.
This is not an edge case. It is the default state of AUTOSAR configuration tooling in most programs today.
Binary configuration files cannot be reviewed in a Pull Request. They cannot be diffed. They cannot be commented on. The entire discipline of modern software engineering — review, traceability, collaboration — stops at the boundary of the configuration tool.
The Onboarding Overhead
Fragmented toolchains have a second, quieter cost: they make onboarding slow and expensive.
A new engineer joining an automotive software team does not need to learn one tool. They need to learn five. Each with its own interface, its own terminology, its own quirks. The knowledge required to configure a full SDV stack is spread across multiple tool vendors, multiple training courses, and multiple years of accumulated tribal knowledge.
In an industry facing significant pressure on engineering capacity and program timelines, this is a problem that compounds over time. Every engineer who exits the company takes their tool-specific knowledge with them. Every engineer who joins must rebuild it from scratch.
The License Complexity
There is also a straightforward commercial cost. Multiple stacks mean multiple vendors, multiple contracts, multiple license management systems, and multiple renewal cycles. In large OEM programs with hundreds of engineers across multiple Tier-1 suppliers and subcontractors, managing configuration tool licensing alone becomes a project.
And when license availability becomes a bottleneck — when a build farm cannot validate a configuration because a license server is unavailable — the entire release stops.
What the Numbers Look Like
These costs are difficult to put on a single line of a project budget because they are distributed across the program. But they add up.
Consider a conservative estimate for a mid-size SDV program:
- Integration events that run approx. 3 to 5 days longer than planned due to cross-domain configuration errors: 2 to 4 per year
- Engineering hours spent on ASPICE configuration documentation that could be automated: approx. 20 to 40 hours per release cycle
- Onboarding time for a new engineer to reach productivity across all configuration tools: approx. 4 to 8 weeks
- License management overhead across 3 to 5 tool vendors: approx. 1 to 2 person-days per month
None of these are dramatic. Together, they represent a significant and recurring drain on program capacity.
The hidden cost of fragmented SDV toolchains is not a single catastrophic event. It is a steady, invisible tax on every program that runs on one.
The Alternative
The obvious question is: what would it look like if this complexity simply did not exist?
If every stack — AUTOSAR Classic, AUTOSAR Adaptive, Bootloader, Classic Lite, Qorix Performance — were configured in the same workspace, with the same file format, stored in Git alongside the rest of the codebase? If cross-domain validation ran automatically, catching inconsistencies before they reached integration? If every configuration change was traceable by design, not reconstructed after the fact?
This is not hypothetical. It is the problem we set out to solve at Qorix, and the reason we built Qorix Developer the way we did. But the architecture decision — YAML in Git as the single source of truth for every stack — is available to any team willing to move beyond the fragmented toolchain model.
The first step is to recognize the cost. Most teams have accepted it as inevitable. It is not.
Nico Hartmann is CTO at Qorix. He writes about automotive software architecture, SDV configuration, and the engineering decisions behind Qorix Developer.
Related: Discover how Qorix Developer addresses these challenges at qorix.ai/products/qorix-developer/
