OASYS - 653


OASYS - 653

Overview

Embedded systems for safety critical applications often integrate multiple functions and must generally be fault tolerant. In hard real-time applications, it must be guaranteed by design that all real-time transactions will produce the correct result and meet their deadlines. These requirements lead to a need for mechanisms and services that provide protection against fault propagation and ease the construction of distributed fault tolerant applications. A key feature of an avionics RTOS is its ability to meet tight processing deadlines. An application program controlling the release of a weapon may require an action from the operating system in less than onethousandth of a second. The avionics computer resource is an embedded generic computing platform that is able to host multiple applications with different levels of criticality. Safety- critical applications such as flight control, cockpit display, navigation, radar control etc., run on an avionics computer resource. These applications need strong assurance from the operating system that their hard real-time requirements are met. More importantly, they require the assurance that in the presence of faults, a fault in one application should not propagate to the others

Partitions

Automated aircraft control has traditionally been divided into distinct functions that are implemented separately (e.g., autopilot, auto-throttle, flight management); each function has its own fault tolerant computer system. A byproduct of this federated architecture is that faults are strongly contained within the computer system of the function where they occur and cannot readily propagate to affect the operation of other functions. The obvious disadvantage to the federated approach is its profligate use of resources: each function needs its own computer system (which is generally replicated for fault tolerance), with all the attendant costs of acquisition, space, power, weight, cooling, installation, and maintenance. Integrated Modular Avionics (IMA) has therefore emerged as a design concept with a single computer system (with internal replication to provide fault tolerance) providing a common computing resource to several functions. As a shared resource, IMA has the potential to diminish fault containment between functions, so any realization of IMA must provide partitioning to ensure that the shared computer system provides protection against fault propagation from one function to another. Partitioning uses appropriate hardware and software mechanisms to restore strong fault containment to such integrated architectures.


The advantages of having partitions

  • Allow applications with different criticalities to coexist and run on the same core module without causing any potential damages to other partitions/applications.
  • Allow integrating and reusing applications written on a federated architecture.
  • Provide the flexibility to add enhancement to an application without modifying the schedule or any.
  • Making modifications in one partition and not have to ‘regression-test’ the others because partition.

ARINC 653

ARINC 653 is a standard specification for avionics application software drafted by Airlines Electronic Engineering Committee in 1997. ARINC stands for Aeronautical Radio INC. ARINC 653 standard is a general purpose APEX (APplication EXecutive) interface for an avionics computer’s operating system and the application software. The standard includes interface requirements as well as a list of services that allow the application software to control the scheduling, communication, and status information of its internal processing elements. Central to the ARINC 653 philosophy is the concept of partitioning, whereby functions resident on a core module are partitioned with respect to space (memory partitioning) and time (temporal partitioning). A partition is therefore a program unit of the application designed to satisfy these partitioning constraints. The OS is responsible for enforcing partitioning and managing individual partitions. A robustly partitioned system allows partitions with different criticality levels to execute in the same core module, without affecting one another spatially or temporally. The time partitioning ensures that activities in one partition do not disturb the timing of events in other partitions. Space partitioning ensures that software in one partition cannot change the software or private data of another partition either in memory or in transit.