Current Projects


SIL2LinuxMP

The SIL2LinuxMP project aims at the certification of the base components of an
embedded GNU/Linux RTOS running on a single-core or multi-core industrial COTS
computer board. Base components are boot loader, root filesystem, Linux kernel
and C library bindings to access the Linux kernel. With the exception of a minimal
set of utilities (to inspect the system, manage files and start test procedures),
user space applications are not included.

Traditionally, safety-critical systems isolate the safety-related functions into a
single node or a small number of nodes that exclusively cover a minimal and simple
functionality. Such nodes usually run on simple single-core processors and use a
minimum software set [0].
But with the growing complexity of systems, e.g. including network security
requirements, complex control algorithms and even cognitive functions, much
more nodes would be required than the policy of using small and simple nodes
can handle. The main reason for this limitation is related to the exponentially
increasing requirement of inter-node communication. Thus, it may still be
possible to keep the single nodes simple - but at the cost of an over-boarding
overall system complexity that can no longer be managed.

In our opinion KISS [1] was always a design principle, aiming at ensuring that the
requirements and design, ideally, fit into the minds of the developers and
users, but not about necessarily keeping the implementation simple. This is
very nicely expressed by the NASA Software Safety Standard.

"This Standard does not discourage the use of software in
safety-critical systems. When designed and implemented correctly,
software is often the first, and sometimes the best, hazard detection
and prevention mechanism in the system."
[NASA NPR 8719.13B 1.2]

A further development of the past decade simply is that the target hardware for
a lot of safety-related systems and their software components have been
single-core CPUs, which can be qualified as an close-to-extinct species by mid
2014[2] . Aggravating the issue is the fact that many of the traditional safe RTOS
simply do not support multi-core, and adding multi-core support often amounts
to a re-design and re-implementation. Moving an OS/RTOS to a multi-core
environment is a fundamental design change that will effectively invalidate
most of traditionally used software components rather than just limiting the
benefit of re-using "proven-in-use" concepts and components.

Finally, we can observe a significant change in the dynamics of technical
evolution: CPUs that would last for two decades are becoming rare, and while
they do exist, using them de-couples projects from main stream technology and
with that from know-how and vital experience.
Keeping safety-related systems a step or two behind the hype is a matter of common
sense, but letting it fall too far behind effectively puts safety-related systems
in uncharted lands. In this case, "well-tested" processors and software components
run in environments they were never designed for and run applications that were
not envisioned at the time when the OS/RTOS was designed.

One possible - and maybe not the only possible - answer to these challenges is
to utilize main-stream multi-core ready Open Source RTOS like GNU/Linux RTOS
(based on RT_PREEMPT). Precisely this is the goal of the SIL2LinuxMP project.

Jailhouse Safe (JHS)

Safety related systems are generally thought of as simple systems - ideally 8 bit
micro-controllers without an operating system, utilizing boolean logic... For
contemporary systems this approach is increasingly inadequate - full featured
mixed-criticality, fully-connected, high-performance systems are needed to
address the challenges of contemporary safety related systems.

Our take on functional safety is "Managed complexity allowing to manage risk"
- keeping things simple is thus not a mater of "simple code" but a matter of
how to approach a problem with the right means for the given complexity of the
system at hand while adhering to the KISS principle.

In our opinion KISS [1] was always a design principle, aiming at ensuring that the
requirements and design, ideally, fit into the minds of the developers and
users, but not about necessarily keeping the implementation simple. This is
very nicely expressed by the NASA Software Safety Standard.

"This Standard does not discourage the use of software in
safety-critical systems. When designed and implemented correctly,
software is often the first, and sometimes the best, hazard detection
and prevention mechanism in the system."
[NASA NPR 8719.13B 1.2]

Contrasting this with IEC 61508-3 Ed 2 7.4.2.6

"As far as practicable the design shall keep the safety-related part of the software simple"

Our take on this "discrepancy" - as much as necessary - as little as possible.
A partitioning hypervisor is one building block in system de-composition and a
high-level divide-and-conquer strategy. The prime problem resolution intended
by JHS is to provide this top level fault-containment/logical-isolation
capability to systems engineers building mixed criticality systems on
multi-core hardware.

[0] IEC 61508-3 Ed 2 7.4.2.6 As far as practicable the design shall keep the safety-related part of the software simple.

[1] "Keep it simple, stupid" is a design principle introduced in the 60s by the US Navy for battleships.

[2] Practically all hardware vendor announcements made in 2014 are multi-core systems.