Functional safety and continuous certification on Linux

The automotive industry is rapidly evolving as technologies develop to allow for new and different methodologies to build the software-defined vehicle.

As part of this evolution, open technologies can help the industry advance innovative ideas and reduce costs. However, this initiative is complicated in the automotive space in particular because of functional safety requirements. Understanding what functional safety is, and how it would shape a continuous functional safety certification, is the first step in understanding how open technologies can change the automotive industry.

Functional safety is a concept that applies across many industries, including automotive, and is inherently based on the concept that if it’s possible for a system to fail, it should fail in as predictable a manner as possible. That way, the failure can be planned for, and the harm of said failure can be mitigated as much as possible.

Functional safety is distinct from the concept of trying to remove the possibility of failure from the system completely. Although this is also an admirable aim, it’s outside the scope of the concept.

Functional safety is implemented by:

• Identifying all of the points where a safety system is required when the tool being assessed is performing in its intended context.
• Assessing the risk reduction of that safety function.
• Making sure that safety function works.
• Conducting checks to ensure that the safety function still works over time.

In the specific case of electronic devices in vehicles, functional safety means that all electronic components in the car, including computing devices, are free from unreasonable risk when operating in their intended context, and they meet the requirements of ISO 26262 as defined by the International Organization for Standardization. Which, of course, leads to the next question:

What is ISO 26262?

ISO 26262 is an international standard that covers functional safety for electrical and electronic systems in road vehicles. It is an adaptation of the functional safety standard IEC 61508, published by the International Electrotechnical Commission. Initially, ISO 26262 only covered passenger cars, but in 2018 it was extended to include all road vehicles except mopeds.

ISO 26262 aims to address possible harms caused by vehicle electronic and electrical (E/E) systems when they malfunction. The standard covers not only the electrical and electronic components of the vehicle, but also those of the mechanical subsystems related to those components. So, in a vehicle, it understandably covers a lot.

The standard of ISO 26262 is risk-based, meaning it assesses possible harms qualitatively and outlines safety measures in order to mitigate, control or avoid systematic failures.

What is a functional safety certification?

Functional safety certification is the process in which proficiency is demonstrated in the IEC 61508 standard as well as specific standards such as ISO 26262. These certifications are often given out by widely recognized industry associations, and prove qualification, knowledge, and experience.

What are some of the challenges related to functional safety certification?

For any system to claim that it meets a functional safety standard such as ISO 26262, there needs to be an independent body that certifies the system. That body would also perform ongoing surveillance audits to follow up and make sure that the system maintains its certified standard.

One of the challenges of getting a functional certification for vehicles is that the standards of ISO 26262 were adapted from those created for electronics in the automotive industry in the 1970s and 1980s.

When looking for certification with closed systems, the software is developed almost from a clean room (focusing on keeping extant elements out of the system lest they cause defects) where the requirements are understood and the specifications are understood, and there’s a very high degree of traceability between the requirements, code, and coverage. However, modern, open systems are made up of hundreds or thousands of components, with many different projects aggregated together. While those projects have similar approaches to software development, they aren't identical. Those differences accumulate more as the project becomes more complex.

Since ISO 26262 standards are based on a philosophy that was not designed for off-the-shelf components to be slotted in together to create a new-and-different collective whole, the certification process becomes bottlenecked.

Under the existing system, for a complex framework such as an automotive operating system, it can take three to five years for the entire system to be certified. And if there’s a small change to the configuration, it can take a significant period of time for that change to get certified, sometimes the better part of a year. The entire process can become incredibly resource intensive as a new certification process starts when small components of the overall system change.

Thus, for a true, open vehicle operating system to succeed, and specifically Linux-based ones, there needs to be a new paradigm for certification: a continuous functional safety certification process.

One of the biggest challenges with functional safety is change management.

Currently, when there is a functional safety certification, it applies only to a specific software configuration on specific hardware and subject to the approved and documented conditions and assumptions. And if there's a security vulnerability or if new requirements are introduced, that certification needs to be redone. With traditional methods, the recertification effort is significant even for small changes.

With continuous functional safety certification, the aim is to minimize the cost and length of recertification so that the systems in place are being continuously certified at a pace similar to how software is generally updated to fix security issues or add features.

Within this new rubric, the certification process would become part of the software update process, reducing the burden of constant timely and cost-intensive recertifications from the automakers. From this perspective, this standardization toward an open source, Linux-based OS would then give automakers the ability to push updates faster and with fewer resources.

However, continuous safety certification requires a significant engineering effort to get the process up-and-running, and may involve changes to the ISO 26262 certification process.

Red Hat In-Vehicle Operating System

The Red Hat In-Vehicle Operating System is an extension of Red Hat Enterprise Linux to the automotive industry, with the goal of offering a functionally-safe platform for innovation. The Red Hat In-Vehicle Operating System looks to be a new standard in software defined vehicles. General Motors agrees, and has chosen the Red Hat In-Vehicle OS as the basis for its next-generation computing system.

Leaning into open source software as a vital component of the next-generation vehicles can help automakers achieve greater and faster innovation and elevate customer experience. Red Hat In-Vehicle Operating System intends to support the software-defined vehicle by applying Linux to safety-critical automotive systems, accelerating development, reducing costs and creating opportunities for new services and revenue streams.

As mentioned above, however, this approach has its challenges, and the functional safety challenges need to be worked out. Along these lines, these are the pillars of Red Hat’s leadership efforts to standardize and codify continuous functional safety to make the Red Hat In-Vehicle Operating System possible.

What is exida, and why is Red Hat partnered with it?

exida is a leader in functional safety across multiple industries. Founded in 2000, the company specializes in automotive system safety, alarm management, cybersecurity, and availability. Red Hat is partnering with exida as part of the project to deliver a functionally-safety certified evolving Linux operating system for the automotive industry, which would be developed and maintained by Red Hat and continuously certified by exida.

Of course, achieving a functional safety certification has its challenges, and doing so from an open source stance requires a different mindset and strategy.

The future of software-defined vehicles

The future of driving experiences will soon be open to a wave of innovation when open, Linux-based solutions are more available in the automotive space. Red Hat takes its leadership role in developing the future of continuous functional safety in the automotive space seriously, as it also is the future of software-defined automotive in general.
Learn more about Red Hat’s In-Vehicle Operating System.