The characteristics of smart devices are made of software. It controls complex systems like airplanes, cars, and even entire factories in the Internet of Things. Hence, software must ensure and prove the safety of humans, machines and the environment. PikeOS is an excellent foundation for this requirement. It provides a hypervisor on top of a micro kernel allowing the separation of diverse applications into different partitions. This system design reduces the effort of Safety certification significantly due to a small trusted code base. Additionally, strict separation allows certification of each application according to its individual safety level, whether DO-178B, IEC 61508, EN 50128 or ISO 26262.
By the way: PikeOS received the first SIL 4 certification on a multi-core platform.
Micro-kernel based small trusted code base
PikeOS has been designed for use in safety-critical applications and has gone through a comprehensive validation according to safety standards like DO-178B, EN 50128, IEC 62304, IEC 61508, ISO 26262, IEC 61513 for either the avionics, automotive, railway, medical, industrial automation or nuclear power plants. Since only the micro-kernel runs in privileged mode, all of its code contributes to the trusted code base of every application that might run on top of it.
The effort of certifying a program is roughly proportional to the amount of code to be examined. This comprises the code of the program itself, but also that of the run-time environment (i.e. operating system, libraries etc.) which the program relies on. Therefore, the PikeOS micro-kernel consists of less than 10,000 lines of code making certification less expensive than that of conventional monolithic real-time operating systems. Even better: PikeOS allows the combination of applications of different levels of criticality where every application can be certified independently from others.
Reduction of Software Complexity
In many areas of safety-critical applications, multiple independent applications are executed on a common machine. Besides helping to reduce hardware complexity (thus increasing reliability) this also reduces costs. On the other hand multiple applications on a single machine imply rising complexity of the software because any program is able to cause a malfunction of any other program. Thus, if the functions have different criticality levels, the highest of those levels implicitly applies to all software in the system.
To reduce software complexity PikeOS is equipped with ARINC-653 compliant resource partitioning. The idea is to establish subsets of system resources, so-called “partitions”, serving as fault container: each program can only access its partition's own set of resources, so programs running in separate partitions cannot interfere with each other. Therefore, they do not need to trust each other and individual criticality levels can be assigned to each of them independently.
Different Criticality Levels
ARINC-653 compliant resource partitioning of PikeOS offers the implementation of separate partitions for multiple independent applications with different levels of criticality, e.g. application 1 on operating system 1 in partition 1 with Safety-criticality level A, application 2 on API 2 in partition 2 with Safety criticality level B etc. (see figure above).
The Safety standards assign levels of criticality to applications, according to worst case potential damage that could result from a malfunction. Although they use different nomenclatures (e.g. “levels” in the DO-178B, “SIL” in the IEC 61508,), the general concept in all of the standards is similar: The higher the level, the more rigorous testing or even formal verification is required to obtain certification.
Resource partitioning reduces the trusted code base for each of the applications and enables their certification independently from applications in other partitions, thus reducing certification cost significantly for industries like Aerospace & Defense, Automotive & Transportation, Industrial Automation & Medical, Network Infrastructure and Consumer Electronics.