Linux Safety News

Because now it has been demonstrated not only that it is possible, but that it actually works so well that our Linux solution has been positively assessed by TÜV Nord for SIL2 EN 61508 and ASILB ISO 26262.

Here are some facts worth considering before going through the architectural decisions for your next system.

Embedded Linux for Safety Applications (EbcLfSA) has been out there for a year; a minimum viable product has been built, is functional, and has been positively assessed by an independent assessor.

It is not an obscure black box; its motivation, core concept and implementation strategy have been publicly presented at various conferences and within papers, also the features used to implement such an innovative approach to functional safety have been disclosed.

EBcLfSA has such a strong technical foundation that is has been positively assessed by TÜV Nord, one of the most authoritative assessment bodies, to the fundamental norm on functional safety EN 61508, and also to the standard used within the automotive domain ISO 26262 no other Linux-based solution has ever received such a positive and comprehensive assessment from an accredited assessment body like TÜV Nord.

Wide range of possible applications

Not only the compliance with software development prescriptions has been positively assessed, but also, which is even more important, the dependability of a system implemented using this solution, which has been positively assessed to:

• perform safety functions up to SIL2 according to EN 61508
• fulfill safety requirements up to ASILB according to ISO 26262.

This makes this solution suitable for almost any regulated industry, including automotive; a fully‑featured version is currently being developed.

The comprehensiveness of the positive assessment already achieved minimises, in terms of analysis, documentation and testing, the effort required to the user for the positive assessment of a system developed using this solution.

Even for the achievement of higher SILs or ASILs, this solution offers a broad range of possibilities that can be exploited on a project-specific basis.

Virtual domains for more complexity

For more advanced projects, multiple different independent virtual domains are supported, including a low level of abstraction virtual domain directly hosted by the Hypervisor. Further virtual domains can be added with a reasonable effort because their independence is largely covered by the already achieved positive safety assessment.

The above mentioned independent domains are suitable to implement techniques (like, for instance, diversity, redundancy or cross-check) able to achieve the required level of safety integrity for the most demanding projects.

Architectural patterns that can be built with this solution are briefly described and made public (find more information in our related blog-post).

EBcLfSA does solve a fundamental problem: by completely decoupling the kernel from to safety‑related processes running in the userland, it prevents detrimental interferences between them; as a consequence, no reliance is placed on the Linux kernel itself for the dependability of the system.

In addition, EBcLfSA achieves functional safety while being easily maintainable throughout a product’s lifetime (we call it maintainable safety): established processes on how to patch Linux can be followed; there is no need to clone open-source repositories or to influence OSS development practices.

Note: Our paper, presented at the embedded world conference 25, provides a more fine-grained analysis of the core areas of conflict, the advantages of using Linux and how to address those while maintaining functional safety and cybersecurity for up to 15 years.
 

EBcLfSA implements the basic strategies:

• Change the paradigm: use the strength of Linux and detect when things go wrong rather than trying to prevent faults. Let the kernel run as usual. Do not attempt to change it. Use it. And instead, “put it into a box”.
• Just indicate once integrity cannot be ensured and allow fault-reactions to be added as needed by the project.
• Focus on an application’s data space. Ensure correctness. Make it a dependable data space.
• Separate lifecycles of the various constituents (Hypervisor, Supervisor, kernel, userland applications with its libraries).
• Can run any safety function that performs a computation on data received either from other applications, or over the network, or gathered from the storage, and makes the outcomes available for delivery.
• Implements a fundamental goal on functional safety. The HI Application(s) (safety-related process) executes correctly; notification is provided if this is not the case.
  • Embedded Linux for Safety Applications implements this goal while running multiple processes in parallel.
  • And embedded Linux for Safety Applications implements this goal without limiting “other” kernel code, which is not invoked by a subset of syscalls on memory- and process-management.
• Does not need an assessment of Linux and re-assessments throughout its lifetime.
• Has been positively assessed by TÜV Nord for SIL2 EN 61508 / ASILB ISO 26262.
• Has a claim on functional safety which is independent from the open-source community’s engagement in Linux and does not need any SLAs to the open-source community

As Linux is big and complex, very big and very complex:

• functional specification is sparse, incomplete, and of questionable quality
• Linux is monolithic, difficult to decompose for detailed specification and testing
• automatic analysis tools may show the complexity, but they do not make it less complex
• and all that needs to be repeated for each new release (so, quite often)

“Making Linux dependable” smells of “reverse engineering” from a mile. Maybe just a bit better mannered or sugar-coated, but still “reverse” engineering. Or maybe post-mortem examination…

Instead, we just detect when Linux is NOT dependable:

• we are not interested in Linux itself
• we do not need an assessment of Linux or of any software
• we are interested in the cyber-physical systems built on Linux
• we focus on the application software and not on the operating system
• we add to Linux a “guardian angel” who detects when Linux misbehaves
• we limit access rights of Linux using the features of the ARM architecture

If you were interested, have a look at the slides presented at safe.tech2025, go through the paper you find here or reach out to solutions@~@emlix.com.