Safety certification becomes more and more mandatory for software component of embedded systems. Although complex programs apparently cannot be made bug-free, an occasional system failure may be acceptable for a desktop system but by no means for safety-critical embedded systems. A failure of such a system can harm or even kill humans. Therefore, it must be shown to be reliable before it can be allowed to control, e.g. an airplane, a chemical plant, e vehicle etc. The effort of safety certification, whatever it relates to DO-178B, IEC 61508, EN 50128 or ISO 26262,  can be reduced significantly if the software design ensures a small trusted code base, reduced software complexity and different criticality levels in complex embedded systems.

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.

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 fig.). 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.