In May, at the 29th International Automotive Electronics Congress, a document was signed by major players in the automotive industry: BMW, Bosch, Mercedes-Benz, Volkswagen, and others. Together, they want to push an Open Source project: Eclipse S-CORE.
The goal is to create the middleware for modern automotive architecture. In this industry, "middleware" means more than just message exchange. It is comparable in ambition to the GNU Project or Android, but for vehicle control units rather than PCs or smartphones.
S-CORE is positioned as a competitor to AUTOSAR, a partnership involving many of the same companies. AUTOSAR was founded over 20 years ago with similar goals to S-CORE, but focused on microcontrollers, whereas today's priorities include microprocessors, GPUs, and cloud integration. Apparently, dissatisfaction with AUTOSAR's development has led to this Open Source experiment now.
However, before we compare S-CORE and AUTOSAR, it is important to know some context, as the automotive industry has unique characteristics.
Automotive software is safety-critical
Software in a car quickly becomes "safety-critical" because a ton of metal moving at high speeds can significantly impact the well-being of nearby people. The automotive industry has adopted standards like ISO 26262 over time, which have successfully contributed to a decades-long decline in traffic fatalities. However, these standards come with bureaucracy: managers must ensure compliance and be able to prove it in court if necessary. This includes requirements like 100% test coverage.
For software components and tools to be combined across companies, there is a complex web of qualification and certification processes.
In contrast, every Open Source license comes with a disclaimer:
THE SOFTWARE IS PROVIDED 'AS IS', WITHOUT WARRANTY.
When a car is sold as a product, manufacturers must provide certain guarantees and for example, if needed, improve test coverage.
Typically, they require their suppliers to do this work, but with Open Source, you can’t demand anything.
You can only contribute.
Automotive software must be real-time capable
The software often needs to be "real-time capable," both for safety and driving experience. This requires simplicity, as every minor additional feature introduces edge cases, limiting the reuse of libraries. Standard libraries (POSIX, C++, etc.) aren’t designed for this, so AUTOSAR specifies its own alternatives, and reuse is rare in the industry.
This explains why the automotive industry struggles with Open Source. Beyond that, the industry is highly fragmented. Even Volkswagen, one of the largest automakers including all its brands (Audi, Porsche, Skoda, etc), only has a global market share of only 10-15%. The same applies to suppliers like Vector, a leading AUTOSAR software provider. Unlike the smartphone on wheels analogy suggests, there is nothing like Android with over 70% market share here. Thus, cooperation is key.
Cooperation takes different forms
How can this cooperation be structured? The classic answer, embodied by AUTOSAR, is to cooperate on specifications but compete on implementation. A similar approach is seen with the Data Distribution Service (DDS) Middleware, standardized by the OMG and available in both commercial and Open Source implementations. There was an attempt at an Open Source AUTOSAR implementation with COMASSO, but it didn’t gain traction.
Among developers, AUTOSAR has a poor reputation. It is seen as outdated and cumbersome: large XML files, C++14, and an Eclipse IDE-based GUI. Modern developers instead prefer lean YAML files, Rust, and a Visual Studio Code plugin.
For managers, development times are a problem. Like all standards, extending AUTOSAR takes years. While commercial providers offer proprietary extensions, vendor lock-in is a concern.
Is Open Source the answer?
A strength of Open Source projects is that they provide a neutral space for collaboration, similar to standardization bodies. Even competing companies can work together: Intel, AMD, Huawei, NXP, and others all contribute to the Linux kernel.
Developers love Open Source, and management does too, as long as it means free access to tools. The challenge arises when developers want to release something as Open Source, which requires effort and costs money.
Why are these industry giants doing this? The S-CORE document was not signed by a few passionate developers but by CEOs and CTOs. The goal must be to cut costs or increase profits.
Open Source must be faster
S-CORE promises to solve the same problems as AUTOSAR but in a more modern and faster way. Instead of a standard defined by a committee, Open Source offers a de facto standard through implementation. Discussions shift from specifications to code changes (pull requests), eliminating the wait for a supplier to deliver an implementation.
But can Open Source deliver on this promise? Even in the Linux project, development can take years. For example, integrating Rust into Linux took over three years and sparked dramatic discussions. In AUTOSAR's Adaptive variant, Rust is still under discussion, while it is already part of S-CORE. This sounds like a win for Open Source, but is it due to the approach or AUTOSAR's legacy constraints?
Open Source must be more than just be faster
The Rust project develops a compiler Open Source. With Ferrocene, you can get this compiler certified for safety-critical applications. What did Ferrous Systems have to do? Primarily, document requirements and link them to tests. This means the Rust community had already developed the software to the necessary level, such as full test coverage. This is above average for Open Source projects but shows it is possible.
S-CORE belongs to the automotive industry, evident in its Platform Management Plan, which describes roles like Quality Manager responsible for creating quality reports to meet ASPICE requirements. This will be familiar to developers from the proprietary sector and likely won’t evoke positive associations. Some APIs are even directly copied from AUTOSAR, which isn’t surprising since many developers previously worked on AUTOSAR.
This suggests S-CORE won’t be faster. Innovations in S-CORE will also influence AUTOSAR discussions. There is no technical reason AUTOSAR couldn’t integrate parts of S-CORE; the question is how much the two will diverge architecturally.
S-CORE is currently a German initiative without participants like Toyota, Ford, or Denso. The real measure of success will be whether developers from more companies join. Open Source makes this transparent, at least.
Verdict: Worth a try
Will S-CORE succeed, or will it be practically dead in five years, like COMASSO? I give it a 30% chance. That may sound pessimistic, but for comparison: Jeff Bezos gave Amazon a 30% chance of success in 2000. The German automotive industry is in crisis, and this chance is worth investing a few millions.