Reading time
4 minutes

Developing an Automotive OS is a complex task requiring collaboration between multiple organizations, both inside and outside the automotive industry. An Automotive OS will be built by a mix of software and service suppliers, along with in-house software organizations that implement, verify, and deploy software applications and software infrastructure. The open-source community will also be part of the collaboration.

Although it might not be immediately visible, the Automotive OS has functional safety at its core. Functional safety impacts not only the development of its safety-related software elements on the software platform, but a whole range of supporting processes as well.

The fundamental question is, how to make sure that this network of suppliers, teams, business units, and open-source communities work together to achieve functional safety?

The answer is actually simple. Functional safety cannot be outsourced to a service provider or a separate safety organization. To achieve functional safety, each organizational unit that touches the safety surface of an Automotive OS must take ownership of their safety processes.

Distributed development of any system is hard; in an Automotive OS it will be even harder. In the past, organizations could manage and control all aspects of the safety processes, and the complete lifecycle of the deployed system.

In an Automotive OS platform, the development is distributed across many organizations and the lifecycle of the platform is continuous rather than a once-to-be-deployed system.

The traditional solution to distributed development is to define a contract between stakeholders – the Development Interface Agreement (DIA). The DIA puts the responsibilities of safety processes in writing. One immediately sees where the commitment gaps are before they become problems. You don’t pretend that problems will iron themselves out – you tackle the gaps head-on.

The fact is many people dislike the whole idea of a contract. It’s anti-agile. Cooperation should be built on trust, not a contract.

Cooperation on functional safety must be explicit and intentional. Share ownership of a safety process, and take ownership when no one else will. You need to overshare – make it visible what decisions you have made, and what direction you will be heading in. You must build up the relationships with development partners. See yourself as a supplier and not the customer, even if you are the one providing the budget.

A strong safety culture must be in the DNA of the Automotive OS.

This is hard work, and it is continual work. This work must be prioritized and valued. A strong safety culture must be in the DNA of the Automotive OS.

While safety cannot be outsourced, it still must be centrally audited. Breakdowns in communication or cooperation need to be identified early. Measures to resolve issues must be followed up until completion. Unfortunately, if an organization or team can’t break away from silo thinking, there is no way around a DIA.

By making use of open-source software (OSS) the automotive industry will not only reduce costs associated with license fees, but also tap into a community of developers and users who have realized emerging technologies that the Automotive OS will heavily rely on.

However, the collaboration between the automotive industry and the OSS community represents a paradigm shift in comparison to the traditional supplier relationships within the automotive industry.

To make this collaboration successful, it is critical to align the goals of the OSS community and the automotive industry, and to identify and address the gaps between them. To safely make use of OSS, the automotive industry must take responsibility for these gaps.

Open-source software will not be a free lunch. Automotive OEMs and suppliers must work together to safely integrate, verify, and validate open-source software they use. For safety-related open-source software, the governance model plays a central role. The automotive industry must actively participate in open-source software development to ensure it is aligned with industry standards. Organizations such as the ELISA Project, Eclipse SDV, and SOAFEE demonstrate how this collaborative approach can be effectively implemented.

On a final note, a Development Interface Agreement (DIA) should also be thought of as a living document, updated continually, and shouldn’t be thought of as a work contract. It could even be used to document your assumptions on how you will work with the open-source community. It documents how you want to work together.

Many people who despise DIAs are completely right on one point. A DIA cannot specify every aspect of how organizations must work together, and it will always have gaps. A DIA can only show the interfaces for cooperation. However, garnering commitment on this early, and it can serve as your foundation for a productive and reliable cooperation.