The Automotive industry was used to focusing on the hardware aspects, being driven by the mechanical components of the vehicle.
This, however, has changed approximately 50 years ago with the introduction of relatively simple software that was primarily used for engine control. Relatively simple software then evolved into more complex software that improved engine efficiency and fuel consumption, and progressively continued its evolution and increased its usability. Today, automotive software has become an essential part of modern cars, making the safety of the software and the associated development practices critical aspects of the automotive industry.
As a result, automotive software must meet strict safety and reliability standards and undergo rigorous testing and debugging throughout the development process.
With the continued evolution of the automotive industry and its technology, software development will keep playing a vital role in shaping the future of this industry.
Shifting Gears: From Proprietary to Open Source Software Development
Now, taking a deeper look into how and where such software is developed, we see that the general approach used to be that some car manufacturers (OEMs – Original Equipment Manufacturers) started to form their own software development teams and departments while others have looked for and hired second and third party companies (known as tier 1, tier 2, etc, or suppliers) that developed and delivered the respective software to them. This is all proprietary software.
Such proprietary software is developed following very precise and strict corporate defined processes that are derived from multiple of the automotive industry standards like A-SPICE (Automotive Software Process Improvement and Capability Determination, ISO/IEC 33020:2015) or CMMI (Capability Maturity Model Integration), Automotive Functional Safety (ISO 26262), Automotive Cyber Security (ISO 21434), SOTIF (Safety Of The Intended Functionality, ISO/PAS 21448).
But there is another form of developing software, out in the open, under free licence, generating the open source software.
The automotive industry began to seriously adopt open source software in the early 2000s, though its use has grown significantly over the past two decades. The industry's move towards open source was driven by several factors, including the increasing complexity of software in vehicles, the need for standardisation, and the benefits of collaboration.
Bridging the Gap: Aligning Open Source Practices with Automotive Industry Standards
While the people that develop open source software for the automotive industry are aware of and familiar with the industry’s standards mentioned above, such standards are hardly applied in the open source projects. Automotive-related open source projects mainly focus on following the typical general software development best practices like writing clean code, documenting the code (either through comments in the actual code or through additional associated documentation), making proper code commits that come as a tested answer to an issue (whether the issue is about implementing something missing, something new or a fix to a bug).
Unfortunately, such practices, even though they are the best practices of producing source code, fall short of meeting the strict requirements and scrutiny of the automotive industry. As a result, it is hard to get automotive open source projects certified and finally integrated into the vehicles that are released to the market for the end users.
Join Us in Shaping a Safety Critical Development Process for Open Source in Automotive
With this in mind, we at Eclipse Foundation have started an initiative to define and deploy a Development Process for Safety Critical Applications. This process aims to harmonise the specificities of the open source values, principles, and ways of working with the stringent demands of the automotive industry, enabling Eclipse safety critical projects to become ready for functional safety certification.
We hope that what you read here so far regarding this initiative makes you eager to be part of it and we welcome you to come and contribute to it by raising issues with your comments, questions, and suggestions on the First Draft of the Eclipse Foundation Functional Safety Process. The resulting issues will be triaged and addressed starting January 2025.
You can find the Process in its own GitLab repository together with the associated list of issues.
