At 9 a.m. on July 1, Dr. Detlef Zerfowski, Vice President of Engineering Excellence at ETAS, opened AID 2026 in Suwon by boiling down where the automotive industry stands today, and where it needs to go, into a single line: "Forty middleware are too many." It wasn't a complaint about a number. It was a challenge to an old belief — that an OEM can build everything itself — and to an industry structure in which, even in the SDV era, everyone keeps rebuilding the same foundation on their own.

By Sang Min Han _ han@autoelectronics.co.kr
한글로보기






Forty Middleware Are Too Many

"Forty middleware are too many. Forty isn't a figure of speech. It's a number we actually counted."
That was the first line out of Dr. Detlef Zerfowski's mouth, the ETAS Vice President of Engineering Excellence who took the first microphone of AID 2026 at 9 a.m. on July 1 at Suwon Convention Center.
Moving between Europe, the US, and China, he said, he's watched the Software Defined Vehicle ecosystem grow to the point where 40 separate middleware stacks are being developed right now. And he followed that immediately with the line that mattered most in the whole talk.
"We've seen several OEMs try to do everything themselves, and fail miserably. That's not a belief. That's something we've watched happen."
What followed over the next thirty minutes was, in effect, the argument behind that one sentence: the mistake the auto industry keeps repeating in the SDV era, and the fix for not repeating it — Open Core, and its real-world form, the Eclipse S-CORE project. That's how Automotive Innovation Day 2026 opened.








Software Is Not Software

Zerfowski's talk started by breaking a common assumption.
"People talk about 'software' like it's one thing. That's already wrong. There are five fundamentally different worlds of software inside and outside a car."
Here's the picture he drew. First, the deeply embedded ECU — the world of hard real-time software controlling engine management, ESP, airbags. It runs on familiar terms like CAN, FlexRay, functional safety (ISO 26262), the V-model, ASPICE. "This software sits very close to physical reality. You have to understand the combustion engine, vehicle dynamics, how ESP actually behaves." This is control-engineer territory.
Second, the microprocessor-based vehicle computer — a data-driven world fed by camera, LiDAR, and ultrasonic data. This software is written by computer scientists, not by control engineers who picked up programming along the way. It's also where POSIX-based operating systems like QNX or Linux decouple the hardware from the software layers above it.
Third, the cloud, where OTA and remote services live. The DevOps practices the auto industry is only now adopting have already been standard in cloud development for years. Fourth, infotainment — a world Android and iOS already took over, but one that has nothing to do with functional safety.
And last, a category people tend to forget: tooling. It's developing faster than anything else right now, driven by AI, but it comes out of a completely different background than the other four.
These five worlds differ in how they're developed, who builds them, even how people think about them. Zerfowski's conclusion was blunt: "No single company can own and drive all of this by itself."



SDV's Real Problem Isn't Technology. It's Economics.

The second pillar of the talk, arguably, was the part the room most needed to sit with. What Zerfowski identified wasn't a shortage of engineering talent or a gap in available technology — it was the structure of the industry itself. Economics.
He laid out six pains OEMs are living with on a single slide: time-to-market and innovation pressure, duplicated development and integration and qualification work, vendor lock-in, organizational fragmentation, compliance burden, and maintenance that runs 20-plus years. On top of all six, he laid one more idea — Conway's Law.
"You can only develop something the way your own organization is structured. If your development departments are still siloed, the software that comes out of them won't fit together either."
That single law was his answer to why the industry has forty middleware stacks right now. Forty middleware, in his account, isn't a shortage of technology. It's forty organizations, each producing its own answer inside its own walls.
Everyone is rebuilding the exact same thing, redoing the foundation over and over. And the smaller the company, the heavier this duplication cost lands per vehicle. Time-to-market, lock-in, fragmentation, maintenance — every one of these pains, in his telling, branches off from a single root cause: duplication the industry can no longer afford.



Cars Are Not Smartphones

"We're not talking about smartphones here. A phone with faulty software, or a phone that gets hacked, is not a danger to your life. But if your car stops working while you're doing 100 or 150 kilometers an hour on the highway, that can threaten not just your life, but other people's lives too."
It's the reason open source built for a car can never be the same as open source built for anything else. He broke it down into a concrete list: homologation under ISO 26262, ASIL ratings applied to braking, steering, and driver assistance, extensive testing with no shortcuts, software updates that must never introduce a new vulnerability or malfunction, and maintenance that lasts 20-plus years. And where all of that pointed was security — the two words he kept returning to were software maintenance and security risk, because both, he said, are about to grow sharply over the next months and years.
A successful cyberattack can directly compromise vehicle safety, and at the extreme end, he warned, someone hacking a vehicle could turn it into a remote weapon. That's why open source in this industry can't just be "free software" — it has to be infrastructure carrying a 20-year safety and security obligation.







Open Core: The Answer

With the problem, the cause, and the constraints all on the table, Zerfowski brought out the answer: Open Core.
On one side of the slide, each OEM stacks the same structure — app, middleware, OS/virtualization, core middleware layer, HPC — separately, on its own. On the other side, that bottom layer gets pooled into a single shared open core, with OEMs, integrators, and hardware tiers all joining a community built around it. Several attendees near the front took photos of the slide as Zerfowski walked through the two sides of the comparison.
"Even with a collaborative approach, the functionality is exactly the same as if you'd built it in-house. Initial product functionality is identical either way."
Open Core doesn't trade away capability for the sake of cost. It gets the same result for a fraction of the duplicated spend, and what it adds on top runs six deep: cost efficiency, shorter time-to-market, continuous innovation, stronger vulnerability detection, and more efficient software lifecycle maintenance.
The real name behind this Open Core is Eclipse S-CORE.
"S-CORE started around 2022, when the European Union was discussing publicly funded projects for the European auto industry. I was personally part of those early discussions," Zerfowski said, speaking to the project's origins firsthand.
In May 2025, 12 to 14 European companies signed a memorandum of understanding under the VDA's lead — he was a co-author of that MoU. Responsibility later passed to the Eclipse Foundation. By CES in January 2026, a much longer list of companies had signed on, including BMW, Mercedes-Benz, Stellantis, Bosch, Qualcomm, and, from Korea, 42dot, LG, and Hyundai Mobis.
Three principles make this work: vendor-neutral governance (a level playing field no single company controls the direction of), robust IP management (the decisive difference from "fake open source" you can read but can't modify or contribute to), and commercial-friendly licensing — "you're not forced to open-source the proprietary layer you build on top of the middleware." On top of that, he added one more demand for a mindset shift across the whole industry.
"It's code-first, not specification-first. We've always approached this requirements-first. Now it's the other way around."



S-CORE Has Moved From Hype to Reality

Zerfowski moved on to what S-CORE has actually delivered.
Started in October 2024, S-CORE went from roughly 3,000 lines of code that December, to 300,000 by March 2025, 780,000 by September, and 1.9 million lines as of June 2026. It has around 454 contributors. In just the past six months, more than 2,000 pull requests have been merged, and more than 4,000 pull requests have been closed since December 2024. Most of them close within 24 hours.
"We're talking about hours here, not weeks or months," he emphasized.
Seventy percent of top contributors work across more than one project area, not just one. Half of all code contributions get merged the same day they're submitted. And for every three work items raised, two get solved by someone other than whoever was originally responsible.
S-CORE, in other words, is no longer a concept sitting in a European policy document. It's a living development community, and a roadmap follows from that confidence. Version 0.5 was released in 2025; v1.0 will be feature-complete within 2026 and ready for real use by OEMs and Tier 1s. ETAS's own distribution, the Vehicle Software Platform Suite, will be ready for start of development in 2027, feature-complete in 2028, and reach start of production in 2029.
"An OEM that wants to adopt this kind of solution will be able to use it for a serious production launch starting around 2029."
He was also careful to flag something the auto industry is particular about: S-CORE itself does not get safety-certified. A codebase that keeps changing can't be a certification target to begin with. Instead, S-CORE is built from the start around the industry's safety rules, which makes it far easier for the Tier 1s productizing it to get their own distributions certified. On the roadmap slide, the line marked "safety certified" wasn't S-CORE itself — it was the next step down the chain, ETAS's own distribution, and Zerfowski paused there long enough to make sure the distinction registered with the room.







What OEMs Should Actually Build

At the end of the talk, Zerfowski pulled all of it together into one concrete architecture. In ETAS's Vehicle Software Platform Suite, the hard real-time territory on the microcontroller still belongs to AUTOSAR Classic.
"I'm not saying AUTOSAR Classic is going away. Not at all."
Instead, on the microprocessor side, running on QNX and Linux, a new S-CORE-based layer takes shape across three profiles: ADAS/AD, general purpose, and rapid app development. AUTOSAR Classic keeps the MCU. S-CORE takes the HPC. The two run side by side — this is coexistence, not replacement — and the architecture points toward one destination: build the common foundation together, and let OEMs differentiate only on top of it.
"It lets your development team focus on the features that actually differentiate you, instead of rebuilding the same underlying plumbing everyone else is rebuilding too."
That circled back to the line he'd opened with, thirty minutes earlier: "Forty middleware are too many. Let's move forward together with an open-source-based solution."
The message, stripped down, was straightforward: in the SDV era, competitive advantage may come less from rebuilding common software foundations from scratch, and more from knowing where to collaborate and where to differentiate.

AEM(오토모티브일렉트로닉스매거진)