The Linux Safety Monitor, developed as part of an innovative development project together with Elektrobit Automotive GmbH in Erlangen, is immediately available for integration into projects in domains such as medical technology, industrial automation, and power engineering.
It allows bridging the gap between safety and open source solutions which has existed until now.
SIL2 Safety applications directly on Linux
Embedded Linux has been in use in various safety-critical applications for years. However, it is ordinarily reserved for non-safety-critical functions, most commonly communication, networking, update-functionality, and visualisation.
If a safety load is placed on the Linux system, a redundancy approach is predominantly used. This redundancy approach creates costs, both direct, such as for hardware, as well as indirect, for example for maintenance. As a rule, two different operating systems with two separate maintenance lifecycles will run on the two separate SOCs. The maintenance also requires the corresponding experties in both operating systems as well as communication at the interfaces.
This new architecture allows using a single SOC with one CPU and a Linux operating system together with a hypervisor.
Running rust, C, and C++ applications directly on the Linux system is no longer a problem with the Linux Safety Monitor and corresponding safety compiler. Further programming languages and compilers can also be used as long as they produce Linux-compatible ELF binaries.
Alongside the usual communication channels, a shared memory interface enables low latency communication, which safety applications can use to interact with each other. Futhermore, there exists a similar interface to a non-safety virtual machine available to safety applications.
Linux for Safety Applications in various industries
The approval against the requirements of both ISO26262 and IEC61508 massively expands the range of deployment possibilities in various industries.
In the industrial automation domain an example would be certain aspects of the control of safety-critical lasers. The configuration of the lasers could still be carried out by a non-safety-critical application. A safety-critical application would then ensure that the values never lie outside certain hard upper and lower limits. For example, these could be the intensity of the laser beam or the maximum angle of the orientation.
Another example, this time from the medical technology domain, demonstrates the potential of a Linux system supervised by the Linux Safety Monitor: displaying safety-critical information on the same screen as non-safety-critical information. A concrete example would be the vital signs of a patient together with alarm functionality, both of which must be entirely reliable, paired with some convenient information for the medical personal.
The display of safety-critical information cannot be corrupted by non-safety-critical data because the rendering happens in a separate layer that can never be overwritten. Critical data is then only rendered once a final check by the safety-related application has occurred.
These two examples show how the software architecture can be reimagined. Hardware costs will be reduced, although the real leverage lies in the massively reduced complexity of the lifecycle maintenance.
Through the integration of non-safety-critical and safety-critical applications on a single SOC it becomes possible to implement lower latency communication between the applications as well as to use the inherent performance of a Linux system.
Contact
Julia Schilling
Phone +49 551 306640
presse@emlix.com