The software industry is probably unique in its custom to release products to the market even when they are likely to have residual bugs. For consumer goods users have come to accept that complex software programs apparently cannot be made bug-free, and have adjusted to the occasional system failure as a consequence of fast innovation. This, however, is entirely different in the area of Safety-critical software systems, and for good reason: A failure of such a system could harm or even kill humans. Therefore, it must be shown to be reliable before it can be allowed to control, e.g. an air plane, a chemical plant, a vehicle, and many more.

There exist a number of internationally accepted standards for the certification of Safety-critical software (e.g. DO-178C, IEC 61508, EN 50128). As different as these standards may seem, they do share some common principles: The needed effort to obtain certification for a given program is generally high and it depends on two parameters:

Code Complexity

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 runtime environment (i.e. operating system, libraries, etc.) which the program relies on.

Criticality Level

The Safety standards assign levels of criticality to applications, according to the worst potential damage that could result from a malfunction. Although they use different nomenclatures, the general concept in all of the standards is similar: The higher the level, the more rigorous testing or even formal verification needs to be done.

In many areas of Safety-critical applications, multiple independent applications are executed in a common machine. Besides helping to reduce hardware complexity (thus increasing its reliability) this also reduces cost. However, such a configuration creates new potential for problems: Without special precautions, the programs are able to disturb each other, so each of them has to trust all others to behave correctly. 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 now implicitly applies to all software in the system.

Safety Certification

Safety has to cope with new Requirements

Safety-critical application programs come in various levels of both functional complexity and criticality. Increasingly, there is a desire to consolidate disparate applications on a single hardware architecture for the benefit of efficiency, stability, and ease of maintenance.

If several programs with different criticality levels are to coexist in one machine, the underlying OS must ensure that they remain strictly independent and therefore are capable of achieving Safety certification independently. PikeOS combines resource partitioning and virtualization to make coexistent applications certifiable independently and at different criticality levels.

Each guest operating system virtual machine (VM) has its own, separate set of resources, and programs hosted by one VM - independent of those hosted by another. This allows for legacy programs such as Linux applications to co-exist with Safety-critical programs in one machine. Unlike other popular virtualization systems, PikeOS was on purpose designed for embedded systems, therefore it features not only separation of spatial resources, but also strictly separates temporal resources of its client OSes. This allows hard real-time systems to be virtualized, while still retaining their timing properties. This separation of resources is established by a minimal amount of trusted code, so the system is well suited for Safety-critical projects requiring certification in accordance with the prevailing standards for software Safety.

Safety in Avionics

One example of resource partitioning and virtualization in Safety-critical systems is the use of PikeOS by Airbus for their next generation aircraft. Airbus is using PikeOS for certified equipment to be deployed on the A350 XWB aircraft.

Among the many requirements related to this new Airbus architecture, the following were particularly important:

  • a multi-partitioned system that provides POSIX as one of the main requirements
  • the ability to develop certifiably safe software while also allowing high flexibility including the reuse of existing code
  • the possibility to easily build upon the existing technology to provide a secure storage device and network connection access
  • a flexible platform that allows interactive display functionality

The two key aspects of PikeOS architecture that enable mixed certification platforms are resource partitioning and virtualization. PikeOS partitions resources both spatially and temporally. Spatial partitioning provides separate resource pools for user memory and kernel memory. Temporal partitioning ensures deterministic access of a program to processor time.

Strict partitioning is what enables each application to have its own level of criticality and certifiability, without impact from other partitions.

Safety & Certification

More and more industry sectors are concerned by providing the necessary level of Safety for the equipments they propose to their customers. Some industries require an official approval from independent authorities according to international standards. This requirement translates into a special process called certification.

When an entire equipment is certified, evidence must be provided to the certification authority. Those evidences concern both hardware and software parts. As such, PikeOS is required to provide the same documents, source code and other test results as any other software component for the certified system.

PikeOS has been designed from ground-up to be certified according to all major Safety standards like

  • Avionics: DO-178C
  • Space: ECSS-E-ST-40C
  • Railway: EN 50128 / EN 50657
  • Automotive: ISO 26262
  • Industrial: IEC 61508
  • Medical: IEC 62304

Overview of our Certification Kits

Customer Benefits


PikeOS is pre-certified on highest Safety certification levels per industry


Our PikeOS product roadmap aligns to the latest certification standards as they appear


SYSGO offers pre-certified components, such as CIP, CFS or CML to reduce time of system certification


SYSGO directly works with well known certification authorities, such as TUEV (TÜV) or BSI (Federal Cyber Security Authority). Customers can rely on this relationship


More than 75% of SYSGO engineering staff has experiences in certification projects


Certification Kits are available as standard, for authority or for BSP creation


We offer Safety bulletins to inform customers about vulnerabilities


Need more Information?

Tell us about your project and your needs.

Contact us