Learn about Eclipse Kuksa’s journey from research project to future vehicle software building block
What’s cooking for Eclipse Kuksa? We recently caught up with four members of the project team, Erik Jaegervall, Sven Erik Jeroschewski, Lukas Mittag, and Sebastian Schildt, to find out what the automotive project is currently working on.
Beyond the Ivory Tower
It’s a common myth in the software industry that research projects stifle innovative ideas. This misconception suggests that these projects rarely prove useful, let alone deliver business value, outside the cosy cocoons of academia and well-funded corporate labs. It’s easily overlooked that, for example, the PageRank algorithm, which became the foundation of the leading global search engine and the cornerstone of Google’s business, was developed at Stanford University by the Google founders themselves. And let’s not forget that Dartmouth College is recognised as the birthplace of modern artificial intelligence.
Eclipse Kuksa, an open source automotive project, might become another shining example of how a former research project can grow into a thriving, successful technology. Initiated in 2016 as part of the APPSTACLE research project – where universities and research institutions work alongside software and telecommunications companies – Eclipse Kuksa is developing into a force to be reckoned with, both in the automotive industry and in the open source realm. It’s thanks to the hard work and persistence of the people behind the project – Johannes Kristan, Sven Erik Jeroschewski, Sebastian Schildt, Erik Jaegervall, Andre Weber, and Lukas Mittag, to name only a few – that Eclipse Kuksa is currently reaching a new level of maturity and gaining traction in other open source communities.
Pioneering Eclipse SDV
Eclipse Kuksa is part of a rapidly expanding ecosystem that promotes the advancement of open source components for the automotive industry: the Eclipse Software Defined Vehicle (SDV) Working Group. In fact, it was one of the Working Group’s first projects. With great foresight, the APPSTACLE team around Bosch, Netas, FH Dortmund, and others decided to contribute the project to an open source organisation right from the outset. They agreed that, “instead of only producing paper that later gets burned or is put into some drawers, whenever we build prototypes or proofs of concept, this should be contributed to an open source project under the Eclipse Foundation,” as Sebastian Schildt explained in an EclipseCon talk in 2018. Making the existing code available via an open source foundation was also recognised by fellow project team members as the best approach to help the project gain wider adoption: “We had three years of public funds to work on the APPSTACLE project and at the end of it, the results had to be able to live on their own,” stated Johann Kristan, one of the original project members, in 2020. “Otherwise, after those three years, the research project would be over, the work would be abandoned, and although the individual participants could use their own results, no one would be using the collective results of the research.”
Although Eclipse Kuksa didn’t influence the creation of Eclipse SDV directly, as Sven Erik Jeroschewski sees it, the automotive community had arrived at a “crystallisation point” at which collaboration on open source automotive software had become indispensable, with Eclipse Kuksa serving as a “lighthouse” project in this context. To the question of what motivated Bosch to contribute this project to an open source foundation, given the required investment of resources, Jeroschweski answered: "We were already engaged in open source projects relating to the Internet of Things, and this was an opportunity to further our progress in the automotive domain. In addition, the creation of the research project has already demonstrated that the challenge of connecting vehicle applications in an interoperable way cannot be solved by a single player. Creating such fundamental APIs and data models requires the collaboration and perspective of multiple partners. As a consequence, it was seen as a natural step to continue the development under an OSS license to ensure the success of the overall ecosystem. Contributing to such a shared platform allows the involved parties to continue their individual business activities on top of it."
Sebastian Schildt added: "As automotive was doing its first steps to more open collaborative work, the COVESA Vehicle Signal Specification gained more traction, by describing and unifying the semantics of vehicle data. The Eclipse Kuksa team identified having such a standardised data model as a strategically interesting topic. Since specifications without implementations are, in most cases, anything but relevant, the decision was to drive the development of VSS as a standard by means of an implementation. Thus, the Kuksa project was further refined and driven to make the VSS easy and efficient to integrate and use in a vehicle."
Software Is Eating the Automotive World
With its suite of integrated tools for both in-vehicle and external use cases, Eclipse Kuksa arrived at an opportune moment. Modern cars contain several hundred million lines of code, underscoring the critical role of software in the automotive industry. As Marc Andreessen might say, "Software is eating the automotive world." As a result, no automotive manufacturer alone will be able to meet strict safety standards while maintaining a competitive edge and delivering value to their customers without harnessing the innovative power of open source ecosystems that collaboratively build the foundation of future vehicles.
“The interesting thing [about Eclipse Kuksa] is to have a kind of industry alignment, especially when adopting VSS [Vehicle Signal Specification]”, said Jeroschewski. “The way I perceive it, it’s not too hard to invent something like VSS in-house, but it’s very hard to maintain and coordinate it in the long run. My expectation is that, rather than building it in a proprietary way, [automakers] will realise it doesn’t make sense to develop a piece of software over and over again.”
Adoption in Cars and Other Open Source Communities
Originally, Eclipse Kuksa aimed to provide a comprehensive suite of software tools and stacks for in-vehicle, cloud and IDE components. Relying, in its original concept, on a multitude of other open source software projects – such as Eclipse Che and Eclipse Theia (for the Cloud IDE), Eclipse Ditto, Eclipse Hono, Eclipse hawkBit and Eclipse Leshan (for the Cloud platform) as well as Automotive Grade Linux, Keycloak, Docker container runtime, and Raspbian (for the in-vehicle platform) – Eclipse Kuksa has been dedicated to open source and state-of-the-art technologies right from the beginning. Initially, it also encompassed an app store, i.e. a marketplace for potential third-party car app and services vendors. Early prototypes and use cases included remote driver authentication and an automotive ethernet gateway.
Meanwhile, the team has narrowed the scope to focus more on highly industry-relevant in-vehicle components and overall goals that are within the capacity of a relatively small team of committers. This also involves a pragmatic approach to ensure that the project avoids duplicating efforts by reusing existing components where possible. For example, rather than integrating Automotive Grade Linux (AGL) into the Kuksa in-vehicle platform, as was originally planned, the AGL team has adopted Eclipse Kuksa as part of their stack in the last two years. In addition, Red Hat integrated parts of Eclipse Kuksa into their in-vehicle operating system (see the Databroker and Container Image in the CentOS Automotive project on GitLab). These strategic decisions help avoid the literal reinvention of the wheel by distributing the development and maintenance work across multiple open-source communities with shared goals, rather than relying solely on one community. At the same time, they increase the project’s relevance across open source communities. “If I see people who want to use [Eclipse] Kuksa, I try to support them as best as possible,” said Sebastian Schildt.
This is how Sebastian Schildt explained the current focus: “What I like about Kuksa is that, while the scope is small – i.e. Kuksa will definitely not solve the SDV problem for you – it’s a base layer of signals, meaning simple things in the car like the current speed, whether car doors open or closed, or the battery is charged. The lowest level of the car, embedded microcontrollers etc., all operate based on signals, and Kuksa is the first step to bringing these signals into an abstract interface to make sure [they] are the same across vehicles.” In other terms, Eclipse Kuksa serves as a data broker or middleware between the VSS layer and the application layer on top of it. Schildt: “On top, you can add more functionality and services. But [Eclipse Kuksa] is the first layer any SDV will need.”
More Eyeballs, More Security, More Safety?
In safety-critical systems such as those in the automotive sector, where security and safety are inextricably linked, manufacturers have traditionally been reluctant to use open source software components. From the point of view of automakers, functional safety standards require stringent development processes for automotive software, a criterion many OSS projects do not meet, according to industry experts recently interviewed. While the Eclipse Foundation is not planning to safety-certify any of its projects, it is pioneering a process that can be applied in the open source domain to develop automotive grade software. A recently created Special Interest Group for Automotive Grade Open Source and the introduction of maturity badges are the first steps toward developing a full SDV software stack that meets functional safety requirements.
From the perspective of some open source advocates, scepticism towards open source is unfounded when it comes to security concerns. According to Linus’s Law, "given enough eyeballs, all bugs are shallow." In other words, a diverse ecosystem of stakeholders, each with real skin in the game, provides the best guarantee for software security. The current challenge is, thus, to tread the middle ground by reconciling the stringent requirements of safety-critical systems with the advantages of agile and open source software development so as to achieve the best of both worlds. Regarding software security considerations, constant checks and security audits can help raise trust in open source automotive projects. This is why Eclipse Kuksa was the first project of the Eclipse SDV Working Group to undergo such an audit. Conducted in May 2024 by Quarkslab, the report revealed only a few findings. Most of them concerned the sdv.databroker.v1 API, which was then deprecated anyway. “There were no major findings in the Kuksa concept as such”, said Erik Jaegervall, pointing out that the audit marks another milestone on Eclipse Kuksa’s journey from a prototyping platform towards a production-ready solution.
Roadmap for Eclipse Kuksa
Needless to say, the establishment of a common SDV platform will take time. According to a recent research paper, this process could take anywhere from five to twenty years. For the not-so-distant future, Schildt, Jeroschewski and the rest of the project team have set themselves quite tangible goals:
- Optimise the Kuksa interface implemented by the Databroker (in the long run, this could help pave the way for a unified “vehicle API”, as Jeroschewski suggests)
- Align with the VISS standard
- Focus on reliability
- Provide integration paths with other existing and upcoming (automotive) technologies, such as IEEE1722 or Eclipse Zenoh
3 Reasons to Adopt Eclipse Kuksa
What are the most compelling reasons to use Eclipse Kuksa? We asked the team how they would persuade potential users and developers to adopt or join the project.
Sebastian Schildt responded: “It’s the most advanced solution to use COVESA VSS inside a vehicle”. Sven Erik Jeroschewski added: “We use the claim ‘Sa(m|n)e Interfaces.’ Using or deploying Eclipse Kuksa into your architecture allows you to have the same interface – which is also sane – for your applications and also the underlying layers of deeply embedded systems.”
Another reason to consider adopting Eclipse Kuksa, according to Jeroschewski, is that it’s written in Rust, making it extremely lightweight. Schildt added: “Eclipse Kuksa has been successfully tested to run on existing vehicle computers using little CPU and memory resources. This is software that can run in today’s vehicle architectures.”
Rust is the area of focus of another Special Interest Group recently initiated within the Eclipse Foundation. As it’s quickly gaining popularity, particularly among embedded developers, the Eclipse Kuksa team also decided to harness this emerging programming language and its vibrant ecosystem, switching from C and C++, the languages Eclipse Kuksa was originally written in. This strategic move underscores the project team’s eagerness to always keep Eclipse Kuksa up to date with the latest technological developments, making it future-proof, SDV-ready, and sustainable in the long run. Sebastian Schildt: “Today, and in the foreseeable future, basic embedded components in the lowest layer of a vehicle are communicating using various non-standardised signals. Abstracting those signals via VSS and making them safely and easily accessible via Eclipse is the first step towards building an SDV system.”
Many thanks to Erik Jaegervall, Sven Erik Jeroschewski, Lukas Mittag, and Sebastian Schildt for their valuable support in creating this blog post.
