LithOS is a para-virtualised guest operating system which provides the primitives to create the system resources (blackboards, buffers, events, semaphores...) and the mechanisms to create threads, timers and the process scheduler.This is a non-standard interface designed for the efficient and accurate development of standards which define the OS personality.

LithOS implements the process concept presented in the ARINC-653 standard which is not present in XtratuM . Processes may operate concurrently in order to satisfy the application requirements. LithOS adds the multi-process support, the communication between processes and the process scheduler.

ARINC-653 services

The ARINC 653 specification defines the functionality that an operating system must guarantee to enforce robust spatial and temporal partitioning. LithOS implements the ARINC-653 application executive (APEX), a set of software services a compliant operating system must provide to the application developers. LithOS uses the services provided by XtratuM to complete the mechanisms required to develop application based on ARINC-653:

LithOS provides the ARINC-653 application executive (APEX). LithOS offers partitions the intra-partition communication, inter-partition communication, process management, partition management, time management and Health Monitoring services.

  • Partition management: The standard defines basic services related to the partition such as set the partition mode or get the partition status. The set partition mode permits to restart the current partition (COLD or WARM RESET). The standard does not defines a partition identification allowing the services to manage other partitions (i.e. reset, start, stop, shutdown). In addition, the access to the status of other partitions is not considered either.
  • Process management: These services are entirely implemented by LithOS to offer complete the ARINC-653 specification. So, a LithOS partition can create a set of processes (tasks or threads in other nomenclature) that permit to design multi-process applications. There is a clear differentiation between the partition initialisation phase (COLD or WARM RESET state) and the execution phase (NORMAL state). System resources (processes, ports, blackboards, ...) can only be created during the initialisation phase.
  • Time management: LithOS uses the basic services provided by XtratuM to retrieve the current time or arm a timer. Internally, LithOS implements a timer data structure (heap structure) to build as many timers as needed by the application. The clock granularity is 1 microsecond.
  • Inter-partition communication: The inter-partition communication mechanisms (ports and channels) defined in XtratuM were inspired in the ARINC-653 specification. So, these services are used directly by LithOS' internal processes.
  • Intra-partition communication: LithOS layer implements the services to communicate and synchronise processes. Inter-process communication is conducted via buffers and blackboards which can support the communication of a single message type between multiple source and destination processes. Buffers are stored using a queue discipline whereas blackboards only store a message. Inter-process synchronisation is conducted by using semaphores and events. Semaphores are counting semaphores and are used to control the access to shared resources. Events are synchonisation mechanisms which allow notification of an occurrence of a condition to processes which may wait for it. An event is composed of a bi-valued state variable (up and down).
  • Health monitoring (HM): XtratuM defines a HM service inspired in the ARINC-653 HM. Through the configuration file, the predefined HM events are associated to predefined services. Some of them can be propagated to the faulty partition. LithOS provide the services to install an exception handler process which is in charge of manage the raised exceptions. Application based exceptions can be defined, raised and managed using the services provided by LithOS .

ARINC-653 extended services

LithOS implements the multiple module schedule defined in ARINC-653 Part 2, "Extended Services". This service permits to extend the single and static module scheduler to several scheduling plans. Plans are identified by means of a plan identifier. When XtratuM starts the partition execution, the plan identified as ”0” is set as the current plan. A partition with the appropriated rights can request a plan change which, if accepted, is effective at the end of the current major frame (MAF).

The system architect can define as many plans as needed. A partition with the appropriated rights is in charge of conduct the system to the plan needed at each moment. Initially, plans are related to the system modes. Plan 0 is defined as the initialisation schedule plan. In this mode, partitions are initialised and the internal resources are created and initialised. One of the partitions with system attributes is in charge of the mode change requests. Plan 1 is considered as Maintenance mode. By default, this is the plan executed when a health monitor event selects as action a mode change. Plan 2 and next ones are operational modes. The system architect can define as many modes as needed for the system operation.

ARINC-653 validation

LithOS has been validated according to the coverage of the official specification, ARINC-653 Part3 Conformity test specification. The ARINC-653 specification Part 1 defines the mandatory services and describes the invocation of those services and the data structures. The LithOS tests have been defined to prove the interface behavior is in compliance with the ARINC-653 specification.