Written by Philipp Ahmann, ELISA Project Ambassador and Manager at ADIT

Where it all started – The automotive WG 

The ELISA Project was launched two years ago by the Linux Foundation. We had our first workshop in person at the BMW training center (Munich, Germany) and the majority of participants with automotive focuses were screaming, “Enable Linux in safety application within the car!” But what happened then?

Since then, the following workshops as well as our weekly meetings, had a strong focus on automotive use cases. There were a lot of participants and a lot of interest but not a lot of volunteers to help with tasks. We kept receiving requests from Toyota, Suzuki, BMW and Automotive Grade Linux (AGL)… In response to this, the Automotive Working Group was established a little more than a year after the launch of the ELISA Project.

From the beginning, while looking for datasheets, reference designs, documentation, and technical concepts, the words “NDA” and “IP” are something we always have in our minds. As a result, we approached the work cautiously as a group:

• Concentrated on what ISO26262 showcased about functional safety;
• Focused our work with a simulation that is open for everybody;
• Stopped saying “could and should” and started using practical examples; and 
• Pause lengthy discussions about problems that are not Linux specific.

Gaining momentum – The telltale use case

Following these principles, the Automotive Working Group started making progress.  We got a good mixture of safety expertise, Linux know-how and automotive backgrounds. We also frequently talk about new things with the curiosity and questioning mindset of a child, which has helped us create a healthy learning environment that is engaging and productive. 

Due to Suzuki’s and AGL’s introduced use case, we decided to concentrate on the enablement of telltales (often referred to also as tell-tale) based on a Linux instrument cluster. Thanks to AGL a demo and some high-level ideas were already available. 

As we continued our momentum as a group, we recognized that we were spreading our key learnings around in different formats – a bit of source code in a git, diagrams in PlantUML, PowerPoint, or other tools. Documentation was spread over presentations and google docs, so it was hard to create materials and engage interested participants outside the working group. We were determined to continue our momentum and began leveraging tools that would enable others to reproduce and understand our work.

Public means public – The tools

Functional safety projects typically have a very limited set of tools used in the development flow, which have run through a tool qualification. This is expensive because of the license fees and proprietary tools. Putting everything in plain text is good version control and a good baseline, which is key. But monolithic documents make it hard to maintain relationships and traceability – you may even find yourself lost in long text passages. 

To make documentation reviews easier and put them under proper version control, we changed from initial sketches in google docs to documentation in GitHub. While also taking requirements in GitHub, we saw they are hard to maintain, put in the relationship and maintain traceability. So the transition was done to maintain them in Freeplane with a plugin developed by Jochen Kall, who is the Automotive WG lead. This plugin also includes e.g. an export script that renders requirements in markdown. Also, the ReqIF exporter is under preparation.

Similar to text, we also had architectural diagrams that the working group converted. We worked to take initial sketches in slide decks and presentations into a storable format. In this case, PlantUML was efficient and easy for us to use.

After this, we recognized that the use case designs end up in the same issue – no relationship between elements within the single PlantUML diagrams, so it was time to change the tool again. The OSS tool we use now is Papyrus based on Eclipse. The files are stored in XML format and in this way can also be put under proper version control. 

In the end, all of this hard work has led us to a steady set of tools:

• Github for all source code and documentation;
• Freeplane to maintain requirements (storable in version control and exportable to text also stored in version control); and 
• Papyrus for Eclipse. 

We are aware that our tools currently used will not survive a safety assessment out of the box, but this is not our intention. The generated artifacts should be shareable so that they can be re-used by others in their established infrastructure. Also, we are targeting to enable others to build safe Linux-based systems and follow the development process for safety integrity standards accordingly. However, in the end, our telltale example will remain an example. A fully qualified product is out of the scope of the ELISA project.

What’s next

So, here we are. Out of creativity and storming team spirit, we settle and start to standardize the tools we use. Version control, review, traceability became major elements of our work. 

The practical demo provided by AGL was enhanced to serve the fundamental demands of the telltale use case with a watchdog and a safety app as a codebase. The build can be reproduced with the help of a docker image and the binary can run on qemu. 

We still have a long way to go but our goals for the next quarter are:

• The source code analysis and interaction with the ELISA Architecture Working Group will be enhanced; 
• The use case will be benchmarked against Autosar Adaptive safety requirements and its demands on the operating system; and 
• Documentation needs to reach a draft state good enough to share with an external audience and to stand critical questions.
• The existing Kernel config will be cleaned up towards a slim config (by throwing out unused things) and feedback on our changes to AGL

To learn more about the Automotive Working Group, please subscribe to the mailing list, join our weekly calls and become an active member. Never underestimate what you can achieve with a group. We are happy to welcome additional contributors – get ready to get your hands dirty and have fun with a passionate group of people.