XtratuM

Source: Wikipedia, the free encyclopedia.
XtratuM
TypeHypervisor for safety-critical systems
LicenseGNU GPL-2.0
Websitewww.xtratum.org

XtratuM is a bare-metal

ARM v7 and V8 processors (TMS570, R5, A9, A52, A53) and RISC-V processor.[1]

It was initially developed by the

Universidad Politécnica de Valencia (Spain). XtratuM was released as free and open-source software, subject to the requirements of the GNU General Public License
(GPL), version 2 or any later.

A new version of XtratuM from scratch (XtratuM New Generation XNG) is commercialized by fentISS under a proprietary license. It has been qualified for critical systems. [1]

XtratuM is a hypervisor designed for embedded systems to meet safety critical real-time requirements. It provides a framework to run several operating systems (or real-time executives) in a robust partitioned environment. XtratuM can be used to build a MILS (Multiple Independent Levels of Security) architecture.

History

The name XtratuM derives from the word stratum. In geology and related fields it means:

Layer of rock or soil with internally consistent characteristics that distinguishes it from contiguous layers.

In order to stress the tight relation with Linux and the open-source movements, the “S” was replaced by “X”. XtratuM would be the first layer of software (the one closest to the hardware), which provides a solid basis for the rest of the system.

XtratuM 1.0 was initially designed as a substitution of the

Hardware Abstraction Layer
) to meet temporal and spatial partitioning requirements. The goal was to virtualize the essential hardware devices to execute several OSes concurrently, with at least one of these OSes being a RTOS. The other hardware devices (including booting) were left to a special domain, named root domain.

After this experience, it was redesigned to be independent of Linux and bootable. The result of this is XtratuM 2.0 which is type 1 hypervisor that uses para-virtualization. The para-virtualized operations are as close to the hardware as possible. Therefore, porting an operating system that already works on the native system is a simple task: replace some parts of the operating system HAL with the corresponding hypercalls.

Overview

The design of a hypervisor for critical real-time embedded systems follows these criteria:

  • Strong temporal isolation: fixed cyclic scheduler.
  • Strong spatial isolation: all partitions are executed in processor user mode, and do not share memory.
  • Basic resource virtualization: clock and timers, interrupts, memory,
    CPU
    and special devices.
  • Real-time scheduling policy for partition scheduling.
  • Efficient context switch for partitions.
  • Deterministic hypercalls (hypervisor system calls).
  • Health monitoring support.
  • Robust and efficient inter-partition communication mechanisms (sampling and queuing ports).
  • Low overhead.
  • Small size.
  • Static system definition via configuration file (XML).

In the case of embedded systems, particularly avionics systems, the ARINC 653 standard defines a partitioning scheme. Although this standard was not designed to describe how a hypervisor must operate, some parts of the model are quite close to the functionality provided by a hypervisor.

The XtratuM API and internal operations resemble the ARINC 653 standard. XtratuM is not an ARINC 653 compliant system. The standard relies on the idea of a separation kernel defining both the API and operations of the partitions and also how the threads or processes are managed inside each partition.

XtratuM hypervisor supports the LEON 2/LEON 3/LEON 4 (SPARCv8) and Cortex R4/Cortex R5/Cortex A9 (ARMv7) architectures.[1]

XtratuM support as execution environments:

  • XAL (XtratuM Abstraction Layer) for bare-C applications
  • POSIX PSE51 Partikle RTOS
  • ARINC-653 P1 compliant LITHOS RTOS
  • ARINC-653 P4 compliant uLITHOS runtime
  • Ada Ravenscar profile ORK+[2]
  • RTEMS
  • Linux

See also

References

  1. ^ a b c "Fent Innovative Software Solutions".
  2. ^ "STRAST group".

External links