Right-sized SDV: A Blueprint to Reduce Variants and Gain Speed

At CES 2026, Elektrobit (EB) was not selling a new feature - it was selling a way to carry SDV. EB’s message was structural: flatten vertical silos into a horizontal architecture, reduce variants through a Semantic API layer, and separate cost from upgrades through a Cost/Value Zone split. In EB’s framing, SDV is no longer a technology demo. It competes as an operating model.

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






SDV is not a technology story - it is a bill of materials for reality. On the show floor, what blocks SDV is rarely “functionality.” It is cost, timeline, manpower, and variant management. The moment an OEM decides to move toward SDV, these are the first numbers they calculate. That is why the theme Elektrobit (EB) brought to CES 2026 felt like an uncomfortable invoice rather than a futuristic promise. EB argued SDV should not be treated as a “rip-and-replace revolution,” but as a structure that organizations can climb step by step - at a cost they can actually afford.
Jungwoo Cho, Managing Director of EB Korea, started by explaining why traditional development models collide with SDV. The moment an OEM operates multiple Tier-1 suppliers, even a single ECU becomes a variant explosion. Hardware differs. Software platforms differ. Application structures diverge. Cho did not describe this as merely “complicated.”
“When one OEM has two or three Tier-1 suppliers for the same region, you instantly end up managing two or three ECU variants. This complexity grows by multiplication - and that becomes the first barrier to SDV.”
Organizations want to build more functions. But if the “container” that should carry those functions is vertically fractured, development slows down, validation slows down, updates slow down, and variant management becomes endless. EB’s answer is a shift from vertical integration to a horizontal structure.



The question Foxconn and the “Smart EV Platform” raises

EB has been building the “Smart EV Platform” in collaboration with Taiwan’s Foxconn since last year. Foxconn provides a reference hardware platform, EB provides the software platform above it, and SDV applications run on top of that stack.
At a glance, this sounds like a standard division of labor. Cho even said, “Up to this point, it doesn’t look that different from others.” But EB’s real question was not about division of labor - it was about how OEMs will carry SDV in a sustainable way.
When EB explained this structure at CES 2026, the phrase it repeated was the language of rebuilding the supply chain: “Rethinking the Supply Chain.”
And the goal was clearly stated: “Reduce Time-to-Market and Enable Build-to-Print.”
Instead of treating SDV as a massive, bespoke project, EB’s model aims to shorten time-to-market and push manufacturing toward a specification-driven, build-to-print structure.
In the traditional approach, an OEM requests an ECU from a Tier-1. The Tier-1 designs the hardware, purchases the software platform externally, then builds the application stack vertically on top. Once established, the workflow feels familiar. But when multiple Tier-1s coexist, and platforms and hardware begin to diverge, variants surge. At that point, SDV cost and timeline don’t collapse because of function development - they collapse in the hell of variant management.
What EB attempted through its Foxconn collaboration was to “unfold” that vertical structure into a horizontal one - creating options. Hardware manufacturing can be handled by Foxconn, or it can remain with existing Tier-1s. Foxconn provides reference hardware designs for high-performance ECUs such as telematics, VCU, ADAS domain controllers, IVI, and central HPC. EB provides the software platform on top. The architecture becomes manageable by separating layers horizontally - regardless of who builds the hardware.
The key point is not who manufactures the hardware. The key point is that OEMs gain a way to reduce cost, time, and workforce pressure as they pursue SDV.
“What matters is that EB’s target isn’t limited to large enterprises. For mid-sized OEMs with limited budgets and manpower - or Tier-1s forced to carry SDV requirements together - this optionality becomes far more directly meaningful.”


 

Semantic API: the layer that eliminates variants

The idea of separating into a horizontal architecture is not new. Hardware abstraction layers, separation of platform and apps, and reusability have been discussed for years. Where EB pushed further at CES 2026 was this: for separation to actually reduce cost, signals and interfaces must become unified. That is why EB positioned the Semantic API as the key layer.
Cho directly referenced COVESA’s vehicle signal standardization. Even if the industry continues to live with the reality that every brand and platform has different signal systems, there must be a layer above them where functions can be developed the same way.
“Above the Semantic API, everything is the same - no matter which model, no matter which brand.”
This sentence summarizes EB’s SDV approach. The core is not denying legacy. Keep existing ECUs and existing software as much as possible. Add at least one high-performance HPC. Then place a “translation layer” in between to absorb brand-specific signal differences. From that point upward, development can operate the same way even when the vehicle changes or the brand changes.
EB’s demo screen at CES explained this even more directly. The Semantic API exposes vehicle data and functions to enable independent function development - and more importantly, it allows different configurations without introducing software variants. It compresses a “multiplying variant structure” into a single manageable layer.
EB calls the lower layer the SDV Cost Zone. It means legacy ECUs remain largely untouched, and cost becomes controllable.
“We define the lower layer where the Semantic API applies as the SDV Cost Zone. It means you can keep most of the existing ECUs almost as they are.”


 


SDV Cost Zone and SDV Value Zone:
Lock down cost, accelerate upgrades

If legacy is not disturbed, cost goes down. But SDV only becomes meaningful if new functions can keep rising on top. That is why EB splits the structure into two.
“Drive for value and optimize cost.”
The conclusion is: “Separation into SDV value zone and SDV cost zone.”
The Value Zone is where upgrades happen. The logic shown in the demo is clear: feature upgrades must be performed on central controllers - quickly and frequently. For that to work, the lower layer must be stabilized as a Cost Zone, while the upper layer must be managed consistently across brands and models through the Semantic API.
This separation is what “Right-sized SDV” really means. You can defend cost and still climb toward SDV - without ripping everything out. EB’s message is not “go all-in.” It is closer to: control the risk and move forward.


 


Step-by-step SDV is Right-sized SDV:
From white-label vehicles to individual ECUs

EB’s adoption path is not a single route. The phrase “Flexible adoption options” literally branches from white-label vehicles to software platform-only adoption, and further down to individual ECU-level entry points. The proposal is simple: start SDV at the speed and scale you actually need.
“What makes OEMs hesitate about SDV is cost, time, and manpower. Large companies may carry it, but mid-sized OEMs or Tier-1s need options.”
This is why EB’s strategy is closer to operations than technology. SDV transformation is ultimately decided by organizational capability and investment scale. EB solves that gap through “steps.” It protects cost by keeping legacy, accelerates feature expansion through a Semantic API + HPC layer, and - when needed - combines Foxconn reference hardware with EB’s software platform to offer a white-label option. If customers want to bring the platform under their own branding without showing Foxconn or EB, that is also possible.
Of course, for companies with a strong internal push to build SDV independently, this model may be less directly applicable. But that does not mean “large enterprises won’t use it.” In fact, EB believes large companies already learned that carrying everything internally can become a risk.
“Because companies understand that pouring massive capital into SDV - like the Volkswagen case - can be risky, large OEMs will also have partial demand.”


 


The ‘new product’ is the cockpit: EB civion 

The cockpit is where functions change the fastest - and where validation and integration move the slowest.
If Smart EV Platform and Semantic API explain the structure of SDV, EB civion shows how to actually run that structure. Cho spent the most time explaining civion on the CES floor for a simple reason: the most realistic bottleneck in SDV is cockpit development and integration.
Traditional cockpit development takes time to change. You modify code, build, integrate, run tests, and confirm the result. Even small changes can take a week, sometimes several days. EB claims it compresses this process inside a cloud-based virtual environment. The key point Cho emphasized was that developers do not have to directly touch the code.
“In the browser, you click and configure using a UX design tool like Figma. Then the result is automatically compiled and integrated. Test cases are automatically generated too.”
The civion screen shows the same flow. If UI is designed in Figma, components are generated automatically (e.g., based on Jetpack Compose), the structure is mapped, and vehicle data is connected through HAL (Hardware Abstraction Layer). Design - logic - data stay separated, but they are automatically connected - so the development loop becomes much shorter.
“That’s the big difference. These changes can take as little as 1 - 2 minutes.”
EB explained civion was not something created suddenly for CES. It is a productization of methods verified through the Afeela project conducted with Sony and Honda over the past three years. In other words, civion is not a concept - it is a set of proven workflows extracted from real projects and turned into a product family.
Civion is organized into three product lines: Creator (a virtualized CI/CD-style tool), Core (the target software platform), and Cockpit (a more complete configuration including hardware). At CES 2026, EB demonstrated civion simultaneously on AMD Ryzen-based hardware and on Qualcomm-based hardware.
EB also added a generative AI element. In the demo, EB connected Google Gemini to generate themes. For example, if you request “apply a Korea-related theme,” the system generates and applies the theme after some time. EB calls this a theme engine - less as the core of civion, and more as proof that as cockpits become software-defined, design and branding elements also enter the development flow.



EB civion demo. EB presented a browser-based virtual development - automatic build/integration - test workflow to shorten cockpit development loops, and demonstrated the system on both AMD Ryzen and Qualcomm platforms.

EB civion’s workflow. Figma-based UI design triggers automatic component generation (e.g., Jetpack Compose), structure mapping, and HAL integration - implementing an automated loop that connects design - logic - data while keeping them separated.



EB’s “carryable SDV”

EB’s SDV is not about flashy functions - it is about an operable structure. Vertically fractured supply chains and development structures create variant hell in SDV. EB proposed the Smart EV Platform as a model that separates hardware, software, and applications horizontally, redesigns the supply chain toward time-to-market and build-to-print, and reduces variants by absorbing signal differences through a Semantic API layer - so configuration differences do not generate software variants. EB then separates cost and upgrades through SDV Cost Zone and SDV Value Zone, and finally presents civion as a product family that proves the structure through cockpit development time - something you can start with immediately.
EB’s SDV protects cost at the lower legacy layer (SDV Cost Zone), enables fast and frequent upgrades through Semantic API and the central controller layer (SDV Value Zone), and offers step-by-step adoption options. That is what “Right-sized SDV” means. SDV ambition is growing - but not every organization can transform the same way. EB brought a blueprint that solves the gap through “steps,” and civion is the result of turning that blueprint into a product.


 

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

---