scope:

General scope

This European Standard establishes uniform requirements for design and development of software architecture for modular avionics systems.

Software Architecture Overview

The MOAA Software Architecture is based on a three-layer stack as shown by a simplified Figure 2.

Each layer is described in terms of it dependency/independency on both the aircraft system and the underlying hardware.

Software Architectural Components

General

Figure 3 provides an overview of the software architectural components and software interfaces.

Functional Applications

The term "Functional Applications" relates to all functions that handle the processing of operational data, e.g.

- Radar Applications;

- Mission Management;

- Stores Management;

- Vehicle Management System;

- Communication, Navigation and Identification.

Application Management (AM)

AM is responsible for the non-standardised system management, i.e. the AM performs the non-generic system management. As an example, the AM may perform the mission/moding management. The interface between the AM and GSM is the System Management Logical Interface (SMLI) (see 4.1.3).

Operating System (OS)

A Real-Time OS provides the part of OSL functionality that controls the real-time behaviour of the Processing Element and its associated resources (see 5.2.2).

Generic System Management (GSM)

The GSM is responsible for the management of the core processing (see 4.1.2 and 5.2.1). This functionality is divided into four areas:

- Health Monitoring;

- Fault Management;

- Configuration Management;

- Security Management.

Run-Time Blueprints (RTBP)

The RTBP contain the information (e.g. process description, routing information, fault management data) required to configure and manage the core processing on which it is hosted (see 5.3).

Module Support Layer (MSL)

The MSL encapsulates the details of the underlying hardware and provides generic, technology independent access to low-level resources (see 5.1).

Application to OS Interface (APOS)

The APOS is a direct interface that separates the aircraft dependent software (AL) from the aircraft independent software (OSL). Its purpose is to provide the processes in the AL with a standardised OS independent interface to those services provided by the OS, thus promoting the portability and re-use of application software (see 6.1).

Module Support to OS Interface (MOS)

The MOS is a direct interface that separates the OSL from the hardware dependent software (MSL). Its purpose is to provide the OS with a hardware independent/technology transparent interface to the functionality contained within the MSL. The MOS therefore allows the same OSL software to reside on different implementations of a CFM regardless of the underlying hardware (see 6.2).

System Management to Blueprints Interface (SMBP)

This direct interface, encapsulated within the OSL between the GSM and the blueprints, allows the structure and implementation of the blueprints to remain non-standardised, while defining a standardised interface to them (see 6.2.3).

System Management to OS Interface (SMOS)

This direct interface, encapsulated within the OSL, describes the services provided by the OS to the GSM (see 6.3).

OS Logical Interface (OLI)

The OLI describes the intercommunications between two instantiations of OS's regarding Virtual Channel (VC) communications and data presentation (see 7.1).

GSM Logical Interface (GLI)

The GLI describes the intercommunications between GSM instances on separate RE (see 7.2).

System Management Logical Interface (SMLI)

The SMLI standardises a VC based communication protocol between the AM and GSM. AM and the GSM must cooperate and to do so, they communicate and synchronise themselves via the SMLI (see 7.3).

Module Logical Interface (MLI)

This logical interface (communication protocol) defines the logical interactions between modules to meet the module interoperability and system buildability requirements (see 7.4).