The execution conditions for an “open-source core,” as seen through the VDA × Qorix × Accenture panel
2026-01-28 / 03월호 지면기사
/ 한상민 기자_han@autoelectronics.co.kr
.jpg)
Open source is always cool. The problem is: cool code doesn’t substitute for accountability. At Tokyo Big Sight’s Conference Tower, S-CORE’s real question narrowed down to one thing - who will carry the responsibility for the next 10 - 15 years? Qorix translated that question not into technology, but into “production language”: evidence, audits, and long-term maintenance. And that’s the conclusion - S-CORE has moved beyond the phase of “Do we need this?” and into the phase of “How do we actually finish the race?”
By | Sang Min Han _ han@autoelectronics.co.kr
한글로보기
Eclipse SDV: Moving from Vision to Release
“Who takes final responsibility for safety and security?
Who will maintain and evolve the architecture for the next 10 to 15 years?”
On the final day of Automotive World 2026, at the highest point of Tokyo Big Sight - the Conference Tower - I found myself looking back on the arc I’ve witnessed: from S-CORE’s launch last June, to the second MoU announced at CES in Las Vegas, and now this VDA - Qorix - Accenture panel. The trajectory of Eclipse SDV and S-CORE had moved beyond a declaration of “we need open source,” and was drawing closer - visibly - toward the realities of production.
The idea of building a shared foundation for the SDV era is not new. But the moment you translate that idea into the language of production programs, the story changes. Product schedules and audits, evidence and responsibility boundaries, and maintenance across vehicle generations - none of that can be solved with “good code” alone.
As I parted ways with Qorix’s Caroline Pastian, I told her, “Now I understand why you came here.” The question she raised - and the way she answered it - made one thing clear: S-CORE is now at its real test. An open-source core can be a starting point. But what OEM programs demand is not a starting point - it’s a way to finish. And finishing, in this industry, is ultimately defined by accountability, maintainability, and automotive-grade execution.
.jpg)
Martin Schleicher of the VDA framed SDV as an enabler - software defining the customer experience and continuously delivering a “better experience” over time. The premise was broader than feature additions: cybersecurity updates, and eventually an ecosystem where third-party applications can run in the vehicle - software cutting through the entire vehicle lifecycle.
What he emphasized was not “the benefits of open source” in the abstract, but the conditions under which open source can actually work in automotive. At the center is a development paradigm where the code - not documents or specs - becomes the single source of truth. The traditional approach writes massive specs, implements them, and discovers problems too late during integration. In a code-first model, learning and iteration happen earlier, and the burden of validation and quality shifts forward in time.
Another pillar S-CORE is pushing is the toolchain. With an automated workflow - built on “docs-as-code” - specs, code, and tests are connected, and traceability is treated as a default requirement. Functional safety and cybersecurity are not “add-ons later,” but embedded into the development system from the start. Under these conditions, open source can realistically pursue speed and quality at the same time.
“In automotive development, the biggest effort is integration and validation. It takes enormous work to make things that should work together actually work together in a new system. If source code is transparent and experts can spot issues in the same place and solve them together, we can find and fix problems faster. That raises both quality and speed.” Schleicher said.
And that’s where the real question begins. The more speed and openness increase - and the more companies touch the same code - the more urgent it becomes to ask: where does accountability land in a production program?
The moment Caroline changed the room:
“If open source is to become an OEM program”
“Let me explain how Qorix turns an open-source core into an automotive-grade software platform. Put simply: Qorix converts an open-source core into a production-ready platform. We call it a ‘Performance Stack.’”
That’s how Caroline opened. While she acknowledged S-CORE as a foundation for “a common technical language, transparency, and collaboration,” she didn’t hide the question that remains from an OEM perspective:
“Who takes final responsibility for safety and cybersecurity?”
“Who maintains and evolves the architecture for the next 10 - 15 years - and guarantees functionality across vehicle generations?”
Open source creates potential. But potential alone does not equal automotive-grade execution. Between “the code exists” and “it ships in production,” there is one more layer the industry demands. And that layer isn’t defined by technical specs - it’s defined by accountability, evidence, and operational continuity over the long term. If open source provides the foundation, automotive-grade execution is the work of fixing that foundation into the language of production programs.
Caroline described that “extra layer” through Qorix’s roles:
“Within the S-CORE ecosystem, Qorix acts as a Contributor and a Maintainer. Outside the ecosystem, we act as a Distributor.”
A contributor is not merely someone who uploads code; it’s someone who delivers functions and modules - including documentation and APIs - in a sustainable way that shapes the platform. A maintainer stabilizes and evolves the core over time. And a distributor, as the productization owner, doesn’t simply “carry” community code as-is - it transforms it into what OEM programs actually require.
“How do we do this? Our development workflow combines our internal R&D processes with the open-source ecosystem. We regularly review the latest S-CORE changes, combine them with internal feature development, cover OEM requirements, tailor to target hardware, and - when needed - upstream changes back into the community. Ultimately, we deliver production-ready software solutions.”
The words she emphasized weren’t “code.” They were safety work products, documented evidence, audit-ready artifacts, and program support. Those are what reduce the blocking risks OEMs fear: integration effort, time-to-SOP, and the question of “who owns it when it breaks.”
The Q&A reinforced that point once more. When asked, “Can I download it, modify it, and put it into my product?” the panel said yes - Apache 2.0 allows it. But the caveat came immediately: the key issue isn’t permission; it’s responsibility. Licenses grant permission. Accountability and evidence require someone to take ownership. That was the target of Caroline’s question.
What “automotive-grade” really means:
the technical grammar of mixed criticality
Caroline anchored the message in technical terms as well. The faster SDV transformation accelerates, the more middleware becomes a decisive enabler for managing rising complexity on HPC platforms. Yet proprietary stacks often show limits in openness, scalability, and interoperability. Common foundations like S-CORE, in contrast, can create shared platforms, reduce duplicated engineering work, and shorten timelines. That’s why the question is no longer “Do we need open source?” but:
“How can open source meet automotive-grade expectations over decades?”
Qorix’s technical expression can be summarized in three axes.
First: modular architecture across SoCs and operating systems.
Modern vehicles run across different SoCs and OS environments, with varying performance profiles. A modular architecture absorbs those variations and enables scalability.
Second: how to handle mixed criticality.
On a single HPC, safety-critical workloads, non-critical applications, and high-throughput data processing run simultaneously. The key isn’t just “running them together,” but enforcing rules so that they don’t destabilize each other. Caroline’s emphasis was on deterministic runtime orchestration - predictable behavior, controlled resource usage, and freedom from interference for safety-critical functions. In other words: enforcing order at runtime so safety-critical functions are not shaken by load spikes or scheduling shifts in other domains.
Third: proving it as consistency on production hardware - not as a demo.
Caroline put it like this:
“This isn’t just a vision - we’ve already demonstrated it at multiple events. We provide multiple demo scenarios on the same foundation. One is a consolidation scenario integrating multiple environments on a high-performance ECU.”
She also referenced mixed-criticality scenarios on “line/space SDV platforms” and “safety-informed SDV platforms.”
“In other words, we demonstrate predictable behavior on production hardware, and by combining our adaptive/runtime/orchestration capabilities, we deliver consistent behavior across different ECU architectures.”
And again, the endpoint returns to accountability. Mixed-criticality capability is technical - but it becomes a product only when it is fixed into OEM language: long-term maintenance, evidence, and audit readiness.
Accenture’s frame:
from systems to platforms - and stack plus development system
Joining by video, Accenture’s Christoph Horn elevated the perspective one level up. His core diagnosis was simple: we are entering a transition where platforms matter more than systems.
Platforms don’t stay within one vehicle - they spread across generations and lineups through reuse. OEM architectures are increasingly decomposed into layers and APIs, and they are starting to look more alike. That similarity creates an opportunity to share the layers customers don’t see - non-differentiating, “below-the-surface” layers.
What he emphasized, in particular, was that successful open source requires not only the stack, but also the processes, methods, and tools that run the stack. If past standardization slowed down by starting with requirements documents and consensus-heavy discussions, S-CORE started from code and pairs that with tooling to prove it is a foundation for “serious development.” In other words: platformization is not only a code problem - it’s a development-system problem. And when that system exists, sharing becomes not just cost reduction, but a strategic choice that increases the probability of speed and quality.
.jpg)
Martin Schleicher
He currently supports the VDA (German Association of the Automotive Industry), focusing on SDV and automotive software-related work. Previously, he spent many years at Continental leading software strategy, where he helped build an SDV solution stack that was later deployed with a Japanese customer. Before that, he was at Elektrobit, responsible for software strategy as well as product and portfolio management. He has also served as an industry representative across multiple bodies and initiatives—including AUTOSAR-related boards, the SOFI governing body, Eclipse SDV, and the European Commission—building deep expertise in standards, governance, and ecosystem development.
Practical takeaways from the Q&A:
you can use it - but “automotive-grade” isn’t free
Interestingly, the Q&A focused less on grand visions and more on practical questions like “Can I actually take this and use it?”
The answer was straightforward. The repository is open; anyone can download it and inspect it. The license is Apache 2.0, so it can be combined with proprietary commercial software. Upstreaming modified code back to the community is possible, but not mandatory.
But those practical points immediately connect back to the core argument. Many assume “open source = free,” but in automotive that assumption doesn’t hold. Meeting automotive-grade quality and safety/security requirements takes skilled engineers and a working system. Business models may shift - from license-centric to service, open core, or productization support - but a “platform that runs for free” does not exist. And that’s exactly where Caroline’s question returns: who owns it, and who maintains it?
.jpg)
Caroline Pastian
This panel can be compressed into one sentence: the open-source core is the starting point, and an OEM program is completed by an accountability structure. VDA presented the operating conditions of S-CORE - code-first development, the toolchain, and global collaboration. Accenture placed it within the broader shift from systems to platforms. But the decisive sentence came from Qorix:
“Who takes responsibility for safety and security?”
“Who will maintain it for the next 10 - 15 years?”
These are program questions that shape sourcing decisions and SOP outcomes. Qorix offered a structure of answers through a three-role model - Contributor, Maintainer, Distributor - and through automotive-grade artifacts such as safety work products, audit readiness, and program support. In other words, S-CORE matters in global SDV not because we’ve rediscovered “why open source,” but because the debate has moved from “need” to execution and responsibility.
Right after his talk, Martin added a short but telling point: S-CORE is open source, anyone can review it, and by scanning a QR code you can reach the main page and download the source to inspect it yourself. “If you’re interested, go look and judge for yourself,” he said - perhaps the simplest sentence capturing how far this initiative has already come. The roadmap is also becoming more concrete. A 1.0 release is planned for later this year, and the project expects that to enable “serious development.” The target SOP is 2030, but some components may appear in the market earlier. The next scene, then, is clear: on top of S-CORE as a shared core, commercial automotive-grade stacks such as Qorix will rise - and the language of accountability and maintenance will flow into the supply chain as reality.
On-site Q&A: a checklist for those who want to “touch” S-CORE now
Q. Can anyone download it?
A. Yes. The panel said it is publicly available on GitHub and accessible without membership sign-up.
Q. Can I modify it for internal testing?
A. Yes. Whether you upstream your changes back to the community is optional.
Q. Can I put my modified code into my product?
A. The panel stated that under Apache 2.0, it can be combined with proprietary commercial software.
Q. Isn’t open source free?
A. Automotive-grade quality and safety/security require a cost structure. Models may shift from licensing to service/open core/productization support, but a “free platform” is unlikely to hold in automotive.
Q. Is the programming language standardized?
A. No. Multiple languages coexist, and some components may use Rust depending on need.
Q. Does S-CORE replace all legacy software?
A. It depends on project decisions. The direction presented was not full replacement, but standardization, interoperability, and removing duplicated implementations.
AEM(오토모티브일렉트로닉스매거진)
<저작권자 © AEM. 무단전재 및 재배포 금지>
.jpg)
.jpg)
.jpg)
