Industry Voices: Europe's SDV Push Is Too Big for Any One Company to Build Alone

Andreas Eckel led the Grants Projects Group at TTTech Computertechnik AG until March 2026, when he passed the role to the next generation. He now holds the position of Senior Innovation Projects & Funding Manager, and continues to coordinate European and nationally funded R&D initiatives — including HAL4SDV, a project bringing together more than 50 partners across 11 countries to build the architecture, tools, and building blocks for the next generation of software-defined vehicles (SDVs). He also sits in the Chips JU Governing Board as a delegate of the INSIDE Industry Association, and in the INSIDE Industry Association Board itself — positions that give him a voice in shaping future EU R&D programs.

In this conversation, Eckel pushes back on the idea that the SDV has stalled, explains why time-triggered architectures beat priority-based, event driven systems in safety-critical automotive networks, and makes the case that a 50-partner, 11-country consortium isn't a symptom of European fragmentation — it's the only structure built to solve a problem too large for any single organization to carry alone.

Ask why the SDV feels stuck, and the usual answer points to consumer apps and OTA feature drops running behind schedule. Eckel doesn't think that's where the real story is.

The automotive industry has been talking about software-defined vehicles for years, but the reality on the road tells a different story. What's actually holding things back — and why does hardware abstraction matter so much right now?

Andreas Eckel: "I don't agree with this statement. Software-defined vehicles are complex products where software can be updated, or even new functions can be added to an existing in-service vehicle, over the air. This is already available for services in the non-safety-relevant domain, like infotainment. Concerning the more complex parts, where safety and security play substantial roles, the matter is significantly more difficult and riskier to develop, and thus is also in its development phase. However, the industry is working on this, and significant progress is being made toward a product group that will even change the business model in the long run — vehicles might increase their value over time rather than losing it."

"The only way of avoiding complex integration software being developed for each and every solution is abstraction."

Efforts to build that abstraction layer are, in Eckel's view, too large for any one organization to carry — and duplicating the effort across every OEM isn't a viable alternative either. What looks like a stalled industry from the outside is, from the inside, a very hard problem finally being tackled by the people equipped to solve it.

TTTech has been building safety-critical real-time platforms for over two decades. What does "safety-critical" actually mean in the context of an SDV — and why is it fundamentally different from the software challenges we see in cloud infrastructure or consumer electronics?

AE: "With largely rising bandwidth in control data communication, real-time solutions requiring higher bandwidth gained importance. The alternative used before is 'event-driven' systems, as used in CAN bus systems using priorities. This quickly led to scenarios with overload on the communication channels and unintended data collision scenarios. More complex systems must cover so many different scenarios that handling them via priorities quickly becomes impossible. This is one of the reasons why time-triggered systems with dedicated communication schedules have massive advantages, since they can guarantee timing and are collision-free by definition. Safety in automotive means, alike in aircraft, that certain functions provided must be guaranteed at a reliability rate of 10 to the minus 6 or better. Consider an ABS system, or functions needed for autonomous driving like steering — these must be guaranteed in all instances, and a 'blue-screen' scenario, like we know from our laptops, must absolutely be avoided, since it leads to fatalities."

"In a mobile phone, a loss of channel never leads to fatalities and is considered acceptable to happen."

That's the line separating automotive and aerospace safety architecture from everything else built in software today: a dropped connection is a nuisance almost everywhere else. In a vehicle control system, it isn't survivable.

Mixed-criticality systems — running certified safety functions and non-certified workloads on the same computing platform — is one of the hardest engineering problems in automotive. Where does the industry stand today, and what does a working solution actually look like?

AE: "The big problem in running different levels of criticality in one and the same system is found in providing a computing environment that is free from interference by different software, using in most cases even the same memory. Thus, the secret lies in the specific safety-critical architecture for such a system. Layered concepts provide a platform that ensures collision-free memory access by special services, and restricts access on the data communication channels according to the needs of the criticality level. The automotive domain benefits from the results of solving such technical problems in aerospace systems, which are capable of managing such situations. The problem is that a simple take-over of technologies and concepts from the aerospace domain is much too expensive for realistic implementation in the automotive industry. Thus, adaptation suitable for automotive requirements is needed — and certainly, dedicated concepts and developments are also being done in the automotive domain itself."

Aerospace already solved a version of this problem. What automotive can't do is import that solution wholesale — the economics don't transfer, even when the engineering principle does.

Open-source software has transformed every other industry. But automotive safety certification demands traceability, audit trails, and supplier accountability — things that don't map cleanly onto community-driven development. Is open source compatible with ASIL-certified systems, or are we chasing a contradiction?

AE: "I wouldn't say that the attributes mentioned above cannot be satisfied in community-driven development. The question is whether the results will be economically feasible. The ECLIPSE S-Core project targets an OS safety-relevant platform and functions for higher-ASIL certifiable systems. The problem that came up is how to cover the maintainer function for OS software contributions, how to make sure a certain quality of contributions can be assured, how a certification package would be implemented, and so on. When we started HAL4SDV, claiming that results would be provided as OS building blocks, the initial partners in the consortium claimed this should only comprise non-safety-relevant systems that are 'non-differentiating.' The question that quickly came up: which software function today, with autonomous driving in mind, is 'non-safety-relevant'?"

"Even the infotainment system, with the navigation function hosted in it, becomes highly safety-relevant when considering autonomous operation."

Over-the-air updates are the defining promise of the software-defined vehicle — the idea that a car keeps getting better after it leaves the factory. But updating software on a platform running certified safety functions is an entirely different problem from pushing a smartphone update. How do you keep a vehicle safe through its entire software lifecycle?

AE: "Over-the-air updates, or even adding new functions as such, are not the limiting factor. Testing and validation of the suitability of a software update, or adding a new function, must also be conducted thoroughly and according to standards, in the same way as if the new software were added in a certified repair shop. The question is how to prevent unauthorized providers and unintended intruders from access when using OTA updates and software loading. This also involves dedicated security services in the system that prevent such intervention or intrusion opportunities. It must be assured that only 'certified' and 'cleared' software from authorized providers is uploaded when talking about safety-relevant systems."

The update itself was never the hard part, any more than the code contribution was. In both cases, the real engineering problem is the same: deciding what's safety-relevant, and keeping everyone except an authorized, cleared party away from it.

With Chinese and American players investing heavily and moving fast, it's tempting to read a 50-plus-partner, 11-country consortium like HAL4SDV as evidence of European fragmentation rather than a fix for it. Eckel reads it the opposite way.

AE: "The projects in the SDV R&D initiative never promised to deliver each and every architecture, technological strategy, software building block, or technology ready to launch in a series production product within one project. The issue is more to start the first technical investigations of the matter and stay aligned with what is being done at the players' organizations involved. The value of the large, overarching consortium in each of the projects is to overcome the obstacles of cooperating across competing organizations, and for joining forces to benefit from a common development that unifies rather than developing specialized, stand-alone solutions. The R&D matter is too big to be borne by one organization only, and it is too strongly interwoven with autonomous operation for it to be the task of 'one,' with everybody doing their own solution."

"It is an essential result that the consortium in almost all these R&D projects looks almost the same, and the partners are alike. Thus, cooperation is found overarching the individual projects."

If HAL4SDV delivers on its goals, the project aims to supply European industry with:

• An overarching open architecture, general enough to cover today's major approaches while specific enough to apply to the next generation of SDVs

• A dedicated, open set of SDV requirements

• An open-source, interoperable tools landscape for SDV configuration and design

• A use-case-proven set of first SDV building blocks across the architecture

• A specification and SDV model approach — covering the architecture, requirements, and use cases — built in CATIA MAGIC, with an OS connection to CEA Papyrus

• A working SDV ecosystem that has learned to cooperate and co-develop for shared European benefit and competitive advantage

None of these promises a finished software-defined vehicle by 2030. What it promises is a shared foundation other companies can build the finished vehicle on top of.

Critical Software designs, builds, and validates safety-critical automotive software and systems across the full vehicle lifecycle, supporting OEMs and partners in complex, software-defined environments. If you're navigating mixed-criticality architecture or hardware abstraction for your next platform, get in touch with our Automotive team.