{"id":8102,"date":"2026-05-04T11:50:34","date_gmt":"2026-05-04T11:50:34","guid":{"rendered":"https:\/\/eclipsesdv.org\/?post_type=blogs&p=8102"},"modified":"2026-05-06T09:44:05","modified_gmt":"2026-05-06T09:44:05","slug":"the-first-sdv-hackfest-esslingen-2026-hands-on-integration-real-vehicles-and-open-code","status":"publish","type":"blogs","link":"https:\/\/eclipsesdv.org\/ja\/blogs\/the-first-sdv-hackfest-esslingen-2026-hands-on-integration-real-vehicles-and-open-code\/","title":{"rendered":"The first SDV HackFest Esslingen 2026: Hands-on integration, real vehicles, and open code"},"content":{"rendered":"\n

On 28-29 April 2026, the Eclipse SDV<\/a> community gathered at Esslingen University, Campus Stadtmitte, for the SDV HackFest HS Esslingen to strengthen the SDV ecosystem and project adoption. Around 50 participants from industry, academia, and the Eclipse SDV project community came together for two days of hands-on work on software-defined vehicle technologies. The event focused on accelerating Eclipse SDV projects, working directly with open source components, and tackling integration and testing tasks together with project maintainers and mentors. <\/strong><\/p>\n\n\n\n

\"A<\/figure>\n\n\n\n

Unlike a hackathon, this HackFest was not built around competing teams, predefined challenges, judging criteria, or winners. Instead, the goal was to try ideas on a shared technical architecture, bring projects closer together, and find out what works \u2014 and what still needs work \u2014 when SDV components meet real vehicles, virtual setups, embedded platforms, and diagnostics tooling.<\/p>\n\n\n\n

From target architecture to working integration<\/h2>\n\n\n\n

The starting point for the HackFest was a shared target architecture connecting several Eclipse SDV projects and vehicle environments. The setup included Eclipse OpenSOVD<\/strong><\/a>, Eclipse S-CORE<\/strong><\/a>, Eclipse OpenBSW<\/strong><\/a>, Eclipse openDuT<\/strong><\/a>, diagnostics servers, UDS communication, build toolchains, virtual vehicles, 1:10 scale vehicles, robots, and real OEM vehicles from Mercedes-Benz, BMW, and Porsche.<\/p>\n\n\n\n

Day one began with technical introductions and hardware onboarding. Participants then formed teams around concrete work packages, ranging from OpenSOVD demonstrations and S-CORE integration to openDuT-based connectivity and advanced debugging. The event page also announced an introduction session for the four Eclipse projects involved, supporting participants in quickly finding their way into the technical scope.<\/p>\n\n\n\n

The projects involved covered key layers of the SDV stack: Eclipse OpenSOVD provides an open source implementation of the Service-Oriented Vehicle Diagnostics standard; Eclipse S-CORE aims to create a common, safety-critical runtime foundation and software platform for SDVs; Eclipse OpenBSW provides an embedded basic software stack for microcontrollers; and Eclipse openDuT enables distributed, reproducible testing of ECUs and virtual\/physical test setups.<\/p>\n\n\n\n

The integration tracks were \u2026<\/h2>\n\n\n\n

Eclipse OpenSOVD \u00d7 S-CORE: bringing middleware and diagnostics together<\/h3>\n\n\n\n

One major track focused on the integration of Eclipse OpenSOVD<\/strong> and Eclipse S-CORE<\/strong>. The teams made first strides toward building OpenSOVD as part of S-CORE and identified a number of valuable learnings and integration challenges.<\/p>\n\n\n\n

A particular highlight was the end-to-end demonstration of S-CORE with OpenSOVD on top of EB corbos Linux using a Raspberry Pi<\/strong>. The project leads described this as an important first proof point for the combined stack.<\/p>\n\n\n\n

Another notable result was a prototype in which vehicle functions were controlled using S-CORE as middleware and made diagnosable through OpenSOVD. Admittedly, the \u201cvehicle\u201d was an academic 1:10 RC car mock-up \u2014 but it was still a very tangible and motivating result.<\/p>\n\n\n\n

The OpenSOVD teams also developed and demonstrated web-based UIs for interactive usage, reducing the need for command-line tooling. In addition, AI-assisted diagnostic workflows were explored through an AI chat interface and MCP server integration. The idea is to make diagnostic tooling easier to use not only for developers, but also for integrators, testers, and aftersales experts.<\/p>\n\n\n\n

OpenSOVD \u00d7 real vehicles: interoperability in practice<\/h3>\n\n\n\n

The HackFest also created a rare opportunity for direct interoperability testing with real vehicles from Mercedes-Benz, BMW, and Porsche<\/strong>.<\/p>\n\n\n\n

The results were highly valuable: communication via the OpenSOVD Classic Diagnostic Adapter (CDA)<\/strong> worked in principle with all available vehicles. At the same time, the teams uncovered several diagnostic description challenges. Some issues were already fixed during or shortly after the HackFest, while others are still under investigation.<\/p>\n\n\n\n

Full functionality was demonstrated on a Mercedes-Benz vehicle, with continued work ongoing to reach the same level of functionality for BMW and Porsche vehicles. This kind of real-world testing directly improves project quality, because it exposes the kinds of interoperability issues that rarely show up in isolated demos.<\/p>\n\n\n\n

OpenBSW \u00d7 OpenSOVD: diagnosing a virtual vehicle<\/h3>\n\n\n\n

Another team worked on an OpenBSW + OpenSOVD demo<\/strong>, connecting an OpenBSW-based virtual ECU with the OpenSOVD CDA and visualisation tooling. The demo architecture combines an OpenBSW ECU, an OpenSOVD CDA, and Grafana: the OpenBSW ECU simulates UDS diagnostic services over DoIP, the CDA translates the SOVD REST API to UDS\/DoIP diagnostic commands, and Grafana visualises live sensor and fault data. <\/p>\n\n\n\n

The resulting demo included simulated diagnostic trouble codes, sensor values, UDS services for reading and clearing diagnostic data, a SOVD REST API, Swagger UI, and Grafana dashboards. <\/p>\n\n\n\n

This was one of the clearest examples of what the SDV HackFest was meant to achieve: not just talking about integration, but actually wiring components together and making the results visible.<\/strong><\/p>\n\n\n\n

openDuT: remote access, distributed testing, and debugging the testbench<\/h3>\n\n\n\n

The Eclipse openDuT<\/strong> track focused on distributed test environments and vehicle connectivity. For the HackFest, the openDuT team prepared Raspberry Pis with edge software installed, an openDuT backend, and several work ideas around remote ECU access, virtual CDA setups, and edge device setup. <\/p>\n\n\n\n

The results showed both progress and useful friction. One setup established a CDA connection to a car via openDuT and was able to trigger vehicle behaviour \u2014 including folding mirrors from inside. The team also worked on RC car remote control via CAN, connected a S-CORE image to the internet, installed EDGAR natively on the S-CORE image, and identified several issues around configuration, NetBird sessions, CAN support, kernel modules, and documentation. <\/p>\n\n\n\n

In other words: openDuT did exactly what a good test infrastructure project should do at a HackFest \u2014 enable experiments, reveal assumptions, and turn setup pain into actionable improvements.<\/p>\n\n\n\n

\n

“This was one of the clearest examples of what the SDV HackFest was meant to achieve: not just talking about integration, but actually wiring components together and making the results visible.<\/strong>“<\/p>\n<\/blockquote>\n\n\n\n

Pains and gains<\/h2>\n\n\n\n

Of course, putting several active open source projects, real vehicles, virtual environments, embedded hardware, diagnostic descriptions, and build systems into one architecture is not frictionless.<\/p>\n\n\n\n

The main pains were exactly where one would expect them:<\/p>\n\n\n\n