EN 4660-005:2019

Aerospace series - Modular and Open Avionics Architectures - Part 005: Software

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

Luft- und Raumfahrt - Modulare und offene Avionikarchitekturen - Teil 005: Software

Diese Europäische Norm legt einheitliche Anforderungen an den Entwurf und die Entwicklung von Software¬architekturen für modulare Avioniksysteme fest.

Série aérospatiale - Architectures Avioniques Modulaires et Ouvertes - Partie 005 : Software

Aeronavtika - Modularne in odprte letalske elektronske arhitekture - 005. del: Programska oprema

Ta evropski standard določa enotne zahteve za načrtovanje in razvoj programske opreme arhitekture za modularne letalske sisteme.

General Information

• Status: Published
• Publication Date: 20-Aug-2019
• Withdrawal Date: 28-Feb-2020
• ICS: 49.090 - On-board equipment and instruments
• Technical Committee: ASD-STAN - Aerospace
• Drafting Committee: ASD-STAN/D 1/S 2 - MOAA Modular and Open Avionics Architecture
• Current Stage: 6060 - Definitive text made available (DAV) - Publishing
• Start Date: 21-Aug-2019
• Completion Date: 21-Aug-2019
• Ref Project: SIST EN 4660-005:2019 - Aerospace series - Modular and Open Avionics Architectures - Part 005: Software

Relations

• Replaces: EN 4660-005:2011 - Aerospace series - Modular and Open Avionics Architectures - Part 005: Software
• Effective Date: 04-Feb-2015

Overview - EN 4660-005:2019 (Aerospace series: Modular and Open Avionics Architectures - Part 005: Software)

EN 4660-005:2019 is the CEN European standard that defines the software architecture for modular and open avionics systems. Part of the EN 4660 aerospace series, this 2019 revision supersedes EN 4660-005:2011 and provides a structured framework for software components, runtime services, interfaces and management functions used in on‑board avionics equipment. The standard is published in English, French and German and was approved by CEN in December 2018.

Key Topics and Technical Scope

This standard addresses software-level architecture and service specifications for open, modular avionics. Major technical topics and required elements covered include:

• Software architectural components: Functional Applications, Application Management (AM), Operating System (OS), Generic System Management (GSM), Module Support Layer (MSL) and Run‑Time Blueprints (RTBP).
• Defined interfaces: Direct interfaces and logical interfaces such as APOS (Application to OS), MOS (Module Support to OS), SMBP (System Management to Blueprints), SMOS, OLI, GLI, SMLI, MLI.
• System functions: System Management, error handling, built‑in test (BIT), module and mass memory management, graphics and power management.
• Communication: MOAA communication model, data transfer types, multicast and distributed multicast, streaming, data representation and protocol considerations.
• Security management: Application and generic security functions, encryption/decryption, authentication, security audit and monitoring.
• Network and time management: Network configuration, health monitoring, technology transparency, clock hierarchy and time reference.
• Runtime and OS services: Process/thread management, fault management, VC configuration, logging, CFM (configuration/firmware) services and resident software.

Applications - Who uses EN 4660-005 and why

EN 4660-005 is intended for organizations designing, implementing or integrating modular and open avionics software, including:

• Avionics system architects and software engineers specifying software partitioning and interfaces.
• RTOS and middleware vendors implementing APOS/MOS/SMOS/SMBP service sets.
• Aircraft OEMs, avionics equipment suppliers and integrators seeking interoperability, portability and modular reuse.
• Certification and testing laboratories validating conformance to modular architecture principles.
• Systems integrators designing secure communication, mass memory and network/time management for aircraft systems.

Adoption promotes clearer interface contracts, improved component reuse, and easier integration of third‑party modules across avionics platforms.

Related standards

EN 4660-005 is one part of the broader EN 4660 modular and open avionics series. Implementers should consider other parts of the series (hardware, interfaces, validation) and relevant industry standards for avionics software, RTOS, networking and security when applying this document.

Standards Content (Sample)

SLOVENSKI STANDARD
01-oktober-2019
Nadomešča:
SIST EN 4660-005:2011
Aeronavtika - Modularne in odprte letalske elektronske arhitekture - 005. del:
Programska oprema
Aerospace series - Modular and Open Avionics Architectures - Part 005: Software
Luft- und Raumfahrt - Modulare und offene Avionikarchitekturen - Teil 005: Software
Série aérospatiale - Architectures Avioniques Modulaires et Ouvertes - Partie 005 :
Software
Ta slovenski standard je istoveten z: EN 4660-005:2019
ICS:
35.080 Programska oprema Software
49.090 Oprema in instrumenti v On-board equipment and
zračnih in vesoljskih plovilih instruments
2003-01.Slovenski inštitut za standardizacijo. Razmnoževanje celote ali delov tega standarda ni dovoljeno.

EN 4660-005
EUROPEAN STANDARD
NORME EUROPÉENNE
August 2019
EUROPÄISCHE NORM
ICS 49.090 Supersedes EN 4660-005:2011
English Version
Aerospace series - Modular and Open Avionics
Architectures - Part 005: Software
Série aérospatiale - Architectures Avioniques Luft- und Raumfahrt - Modulare und offene
Modulaires et Ouvertes - Partie 005 : Logiciel Avionikarchitekturen - Teil 005: Software
This European Standard was approved by CEN on 2 December 2018.

CEN members are bound to comply with the CEN/CENELEC Internal Regulations which stipulate the conditions for giving this
European Standard the status of a national standard without any alteration. Up-to-date lists and bibliographical references
concerning such national standards may be obtained on application to the CEN-CENELEC Management Centre or to any CEN
member.
This European Standard exists in three official versions (English, French, German). A version in any other language made by
translation under the responsibility of a CEN member into its own language and notified to the CEN-CENELEC Management
Centre has the same status as the official versions.

CEN members are the national standards bodies of Austria, Belgium, Bulgaria, Croatia, Cyprus, Czech Republic, Denmark, Estonia,
Finland, France, Germany, Greece, Hungary, Iceland, Ireland, Italy, Latvia, Lithuania, Luxembourg, Malta, Netherlands, Norway,
Poland, Portugal, Republic of North Macedonia, Romania, Serbia, Slovakia, Slovenia, Spain, Sweden, Switzerland, Turkey and
United Kingdom.
EUROPEAN COMMITTEE FOR STANDARDIZATION
COMITÉ EUROPÉEN DE NORMALISATION

EUROPÄISCHES KOMITEE FÜR NORMUNG

CEN-CENELEC Management Centre: Rue de la Science 23, B-1040 Brussels
© 2019 CEN All rights of exploitation in any form and by any means reserved Ref. No. EN 4660-005:2019 E
worldwide for CEN national Members.

Contents
Page
European foreword . 5
Introduction . 6
1 Scope . 7
1.1 General scope . 7
1.2 Software Architecture Overview . 7
1.3 Software Architectural Components . 7
1.3.1 General . 7
1.3.2 Functional Applications . 8
1.3.3 Application Management (AM) . 8
1.3.4 Operating System (OS) . 8
1.3.5 Generic System Management (GSM). 8
1.3.6 Run-Time Blueprints (RTBP) . 9
1.3.7 Module Support Layer (MSL) . 9
1.3.8 Application to OS Interface (APOS) . 9
1.3.9 Module Support to OS Interface (MOS). 9
1.3.10 System Management to Blueprints Interface (SMBP) . 9
1.3.11 System Management to OS Interface (SMOS) . 9
1.3.12 OS Logical Interface (OLI) . 9
1.3.13 GSM Logical Interface (GLI) . 9
1.3.14 System Management Logical Interface (SMLI) . 9
1.3.15 Module Logical Interface (MLI) . 9
2 Normative references . 10
3 Terms, definitions and abbreviations . 11
3.1 Terms and definitions . 11
3.2 Abbreviations . 11
4 System Functions. 14
4.1 System Management Function. 14
4.1.1 General . 14
4.1.2 GSM Function . 15
4.1.3 AM Function . 18
4.1.4 Error Handling . 19
4.1.5 Built-In Test . 19
4.2 Communication . 21
4.2.1 MOAA Communication Model . 21
4.2.2 Types of Data Transfer . 24
4.2.3 Communication Configuration . 25
4.2.4 Communication Protocols . 26
4.2.5 Multicast . 28
4.2.6 Distributed Multicast . 30
4.2.7 Streaming . 34
4.2.8 Data Representation . 34
4.3 Security Management . 40
4.3.1 Application Security Management . 40
4.3.2 Generic Security Management . 41
4.3.3 Encryption/Decryption and Authentication . 42
4.3.4 Security Audit . 43
4.3.5 Security Reference Monitoring . 43
4.4 Module Management . 43
4.5 Mass Memory Management . 44
4.5.1 Overview . 44
4.5.2 MMM Local File Management . 44
4.5.3 Application File Access . 45
4.5.4 CFM Download . 45
4.5.5 Application Downloading . 46
4.6 Graphics Management . 47
4.7 Power Management . 47
4.7.1 GSM Controlled Solution . 48
4.7.2 MLI Controlled Solution. 49
4.8 Network Management . 50
4.8.1 Network Definition . 50
4.8.2 Network Configuration . 50
4.8.3 Network Health Monitoring . 51
4.8.4 Network Technology Transparency . 51
4.9 Time Management . 51
4.9.1 Time reference . 52
4.9.2 Clock Hierarchy . 53
4.9.3 Clock Configuration . 54
4.9.4 Clock Management . 54
5 Software Architecture Definition . 55
5.1 MSL . 56
5.1.1 MSL Module Management . 56
5.1.2 MSL Communication Capability . 57
5.1.3 Resident Software . 61
5.2 OSL . 61
5.2.1 GSM . 61
5.2.2 OS Functions . 69
5.3 RTBP . 86
5.3.1 Overview . 86
5.3.2 RTBP tree . 86
5.3.3 SMBP Services to Access the RTBP Tables . 87
5.4 Application Layer. 88
5.4.1 Language Considerations . 89
5.4.2 Application Error Handling . 89
6 Direct Interfaces Definitions . 90
6.1 APOS . 90
6.2 MOS . 93
6.2.1 Generic MOS . 95
6.2.2 Specific Services . 137
6.2.3 MOS Bespoke Extension Services . 152
6.3 SMBP . 170
6.3.1 RTBP Tree Grammar . 171
6.3.2 Services for Retrieving Tables . 177
6.4 SMOS . 187
6.4.1 Process and Thread Management Services . 189
6.4.2 Fault Management Services . 190
6.4.3 VC Configuration Services . 192
6.4.4 Network Configuration Services . 199
6.4.5 Security Management Services. 202
6.4.6 Built-In Test Management Services . 207
6.4.7 CFM Information Services . 211
6.4.8 CFM Resources Management Services . 214
6.4.9 Time Configuration Services . 217
6.4.10 Logging Management Services . 218
7 Logical Interfaces Definitions . 222
7.1 OLI . 222
7.1.1 VC Header . 222
7.1.2 OLI Services . 222
7.2 GLI . 222
7.2.1 GLI Representation . 222
7.2.2 GLI Services . 222
7.3 SMLI . 230
7.3.1 SMLI Representation . 230
7.3.2 SMLI Services . 230
7.4 MLI . 238
7.4.1 TC Header . 238
7.4.2 MLI Services . 238
7.4.3 Protocol . 259
8 Data Type Definitions . 265
8.1 IDL . 265
8.1.1 General . 265
8.1.2 Basic Types . 265
8.1.3 Name Spaces . 265
8.1.4 Limitations . 266
8.2 Data Types . 266
9 Tailoring . 290
Annex A (normative) RTBP XML Schema . 297
A.1 MOAA Types . 297
A.2 MOAA Type Extensions . 303
A.3 MOAA Runtime Blueprints . 306
Annex B (informative) Standard Evolution Form . 320
Bibliography . 321

European foreword
This document (EN 4660-005:2019) has been prepared by the Aerospace and Defence Industries
Association of Europe - Standardization (ASD-STAN).
After enquiries and votes carried out in accordance with the rules of this Association, this Standard has
received the approval of the National Associations and the Official Services of the member countries of
ASD, prior to its presentation to CEN.
This European Standard shall be given the status of a national standard, either by publication of an
identical text or by endorsement, at the latest by February 2020, and conflicting national standards
shall be withdrawn at the latest by February 2020.
Attention is drawn to the possibility that some of the elements of this document may be the subject of
patent rights. CEN shall not be held responsible for identifying any or all such patent rights.
This document supersedes EN 4660-005:2011.
According to the CEN-CENELEC Internal Regulations, the national standards organisations of the
following countries are bound to implement this European Standard: Austria, Belgium, Bulgaria,
Croatia, Cyprus, Czech Republic, Denmark, Estonia, Finland, France, Germany, Greece, Hungary, Iceland,
Ireland, Italy, Latvia, Lithuania, Luxembourg, Malta, Netherlands, Norway, Poland, Portugal, Republic of
North Macedonia, Romania, Serbia, Slovakia, Slovenia, Spain, Sweden, Switzerland, Turkey and the
United Kingdom.
Introduction
The purpose of this MOAA standard is to define a set of open architecture standards, concepts &
guidelines for Advanced Avionics Architectures (A3).
The three main goals for the MOAA Standards are:
 reduced life cycle costs;
 improved mission performance;
 improved operational performance.
The MOAA standards are organised as a set of documents including:
 a set of agreed standards that describe, using a top down approach, the Architecture overview to all
interfaces required to implement the core within avionics system and
 the guidelines for system implementation through application of the standards.
The document hierarchy is given hereafter: (in Figure 1 the document is highlighted)

Figure 1 — MOAA Standard Documentation Hierarchy
1 Scope
1.1 General scope
This European Standard establishes uniform requirements for design and development of software
architecture for modular avionics systems.
1.2 Software Architecture Overview
The MOAA Software Architecture is based on a three-layer stack as shown by a simplified Figure 2.

Figure 2 — MOAA Three Layer Software Architecture
Each layer is described in terms of it dependency/independency on both the aircraft system and the
underlying hardware.
Table 1 — Software Layer Independence
Software Layer Aircraft Dependency Hardware Dependency
Application Layer (AL) Dependent Independent
Operating System Layer (OSL) Independent Independent
Module Support Layer (MSL) Independent Dependent

1.3 Software Architectural Components
1.3.1 General
Figure 3 provides an overview of the software architectural components and software interfaces.
Figure 3 — The Software Architecture Model
1.3.2 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.
1.3.3 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).
1.3.4 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).
1.3.5 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.
1.3.6 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).
1.3.7 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).
1.3.8 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).
1.3.9 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).
1.3.10 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).
1.3.11 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).
1.3.12 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).
1.3.13 GSM Logical Interface (GLI)
The GLI describes the intercommunications between GSM instances on separate RE (see 7.2).
1.3.14 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).
1.3.15 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).
2 Normative references
The following documents are referred to in the text in such a way that some or all of their content
constitutes requirements of this document. For dated references, only the edition cited applies. For
undated references, the latest edition of the referenced document (including any amendments) applies.
IEEE 1588:2008, Standard for a Precision Clock Synchronization Protocol for Networked Measurement
and Control Systems
IEEE 754:1985, Binary Floating-Point Arithmetic
IEEE 802.3, IEEE Standard for Ethernet
ISO/IEC 14977:1996, Information technology — Syntactic metalanguage — Extended BNF
ASAAC2-GUI-32450-001-CPG Issue 01, Final Draft of Guidelines for System Issues
— Volume 1 — System Management
— Volume 2 — Fault Management
— Volume 3 — Initialisation and Shutdown
— Volume 4 — Configuration/Reconfiguration
— Volume 5 — Time Management
— Volume 6 — Security
— Volume 7 — Safety
ARINC 653P1, Avionics Application Software Standard Interface, Part 1, Required Services, (Version 3,
11-2010)
ARINC 653P2, Avionics Application Software Standard Interface, Part 2, Extended Services, (Version 2,
06-2012)
OpenGL® ES, The Khronos Group Inc.
RFC 1350:1992, The TFTP Protocol (Revision 2)
RFC 2347:1998, TFTP Option Extension

1 Published by: IEEE (Institute of Electrical and Electronics Engineers), http://standards.ieee.org
2 Published by: International Organization for Standardization (ISO), www.iso.org
3 In preparation at the date of publication of this standard.
4 Published by: ARINC, www.aviation-ia.com/product-categories
5 Published by: The Khronos group, www.khronos.org
6 Published by: RFC Editor, www.rfc-editor.org
RFC 2348:1998, TFTP Block Size Option
RFC 2349:1998, TFTP Timeout Interval and Transfer Size Options
RFC 951:1985, Bootstrap Protocol (BOOTP)
RFC 1542:1993, Clarification and Extensions for the Bootstrap Protocol
RFC 2132:1997, DHCP options and BOOTP Vendor Extensions
3 Terms, definitions and abbreviations
For the purposes of this document, the terms, definitions and abbreviations apply.
ISO and IEC maintain terminological databases for use in standardization at the following addresses:
 ISO Online browsing platform: available at http://www.iso.org/obp
 IEC Electropedia: available at http://www.electropedia.org/
3.1 Terms and definitions
Use of “shall”, “should” and “may” within the standards observe the following rules:
 the word 'SHALL' in the text expresses a mandatory requirement of the standard;
 the word 'SHOULD' in the text expresses a recommendation or advice on implementing such a
requirement of the standard. It is expected that such recommendations or advice be followed
unless good reasons are stated for not doing so;
 the word 'MAY' in the text expresses a permissible practice or action. It does not express a
requirement of the standard.
3.2 Abbreviations
AC Aircraft
AGT Absolute Global Time
AL Application Layer
ALT Absolute Local Time
AM Application manager
APOS Application to OS [interface]
ASAAC Allied Standard Avionics Architecture Council
ATM Asynchronous Transfer Mode
BIT Built-In Test
BMC Best Master Clock
BMC Between Module Communication
CBIT Continuous BIT
CDR Common Data Representation
CFM Common Functional Module
CM Configuration Management
COTS Commercial-Off-The-Shelf
CPU Central Processing Unit
DMC Distributed Multicast Communication
DPM Data Processing Module
EBNF Extended Backus-Naur Form
EW Electronic Warfare
FC Fibre Channel
FIFO First In First Out
FM Fault Management
GLI Generic System Management Logical Interface
GSM Generic System Management
HM Health Monitoring
HW Hardware
IA Integration Area
IBIT Initiated BIT
ID Identification
IDL Interface Definition Language
IEEE Institute of Electrical and Electronics Engineers
IF Interface
IMA Integrated Modular Avionics
IMC Intra Module Communication
IPC Intra Processor Communication
IPEC Intra PE Communication
LC Logical Configuration
LSB Least Significant Byte
MC Master Clock
MLI Module Logical Interface
MMM Mass Memory Module
MOS MSL to OS [interface]
MRC Master Reference Clock
MSB Most Significant Byte
MSL Module Support Layer
MSU Module Support Unit
N/A Not Applicable
NC Network Channel
NII Network Independent Interface
NIU Network Interface Unit
NSM Network Support Module
NW Network
OC Ordinary Clock
OLI Operating System Logical Interface
OMG Object Management Group
OS Operating System
OSL Operating System Layer
PBIT Power-Up BIT
PCM Power Conversion Module
PE Processing Element
PSE Power Supply Element
PTP Precision Time Protocol
PU Processing Unit
QoS Quality of Service
RE Resource Element
RC Remote Clock
RF Radio Frequency
RFC Request for Comments
RLT Relative Local Time
RTBP Runtime Blueprints
RU Routing Unit
SCU Switch Control Unit
SM Security Management
SMBP System Management to Blueprints Interface
SMLI System Management Logical Interface
SMOS System Management to OS Interface
SPM Signal Processing Module
SW Software
TC Transfer Connection
TC Transparent Clock
tftp trivial file transfer protocol
TLS Three Layer Stack
VC Virtual Channel
VL Video Library
4 System Functions
This clause describes the system context and the mapping of system functions onto software
architectural components.
4.1 System Management Function
4.1.1 General
NOTE For requirements on the System Management including detailed examples refer to the respective
volumes of ASAAC2-GUI-32450-001-CPG Issue 01.
The System Management is responsible for managing the IMA system during initialisation, all
operational phases in flight and on ground, and system shutdown until power-off. Thus, its tasks
include:
 control of the system initialisation, reconfiguration, and shutdown processes,
 identification, masking, filtering, and localisation of errors and
 provision of security related services.
The System Management is comprised of two functions located on the application and OSL’s of the IMA
Three-Layer-Stack model (Figure 3):
 the Application Management function (AM): Aircraft dependent, HW independent;
 the GSM function (GSM): Aircraft independent, HW independent.
The underlying principles of this architecture are the separation between hardware and aircraft
dependent layers and the separation between avionics functions represented by functional applications
and system management functions.
The System Management function is organized hierarchically on three level types (Figure 4) covering
the following functionalities:
 Aircraft (AC) level;
 Integration Area (IA) level;
 Resource Element (RE) level.
Figure 4 — Hierarchical Organisation of the System Management
Each level has dedicated characteristics:
AC Level:
 The AC level is a single system management entity responsible for controlling/monitoring the
entire IMA core.
IA Level:
 The IA level is a logical grouping of closely integrated functional applications with their resources.
This grouping need not be static, but may be created and deleted dynamically during a mission.
 Each IA controls one or more RE’s.
 IA’s may internally be organised hierarchically, i.e. a system may include one or more IA levels. In
this case, the lowest-level IA must control one or more PE’s.
 A system may be designed so that it does not include an IA level. In this case, there is one AC level,
and one or more RE levels.
RE Level:
 The resource element is the lowest addressable level in the system management hierarchy
responsible for managing the functionality of a single Processing Element (PE).
4.1.2 GSM Function
The GSM function GSM is responsible for the management and control of all resources and management
of the IMA system behaviour via the use of RTBP (see 5.3).
Figure 5 — GSM Decomposition for RE-Management (Example)
Functions:
The GSM comprises four functions:
 Configuration Management:
set-up of the initial configuration, reconfiguration management;
 Health Monitoring:
monitoring of the health status, error collection, filtering, and transmission to the FM;
 Fault Management:
masking, filtering, and localisation of faults including the processing of corrective actions;
 Security Management:
implementation of the system security policy: authentication, decryption, and encryption.
Hierarchical Organisation:
The following figures illustrate possible mappings of resources to the system management hierarchy:
 RE management (Figure 5): An AC manager controlling 2 IA managers IA1 and IA4; IA1 controlling
the IA managers IA2 and IA3; IA2, IA3, and IA4 each controlling 2 RE’s

Figure 6 — IA Application Control (Example)
 Application configuration control (Figure 6): An AC manager controlling IA1 and IA4; IA1
controlling IA2 and IA3; IA2 controlling the applications App1 and App2; IA3 controlling the
applications App3 and App4 (redundant); IA4 controlling the redundant application App4.

Figure 7 — GSM Decomposition for Module Management (Example)
 Application configuration control (Figure 7): An AC manager controlling IA1 and IA4; IA1
controlling IA2 and IA3; IA2 controlling the applications App1 and App2; IA3 controlling the
applications App3 and App4 (redundant); IA4 controlling the redundant application App4.
Configuration Data:
The configuration data is obtained from the RTBP via SMBP. The reconfiguration is defined through
dedicated sequences obtained via SMBP.
Initialisation and Shut-Down:
Initialisation and shut-down is performed on three different levels:
 application;
 system;
 module.
4.1.3 AM Function
The AM function is responsible for the management and control of all AC dependent functions
(functional applications) on the Application Layer (AL). It acts as an interface between the functional
applications and a dedicated instantiation of the GSM.
Hierarchical Organisation:
The AM should only be located on the AC- and IA-levels, as the RE level is resource-oriented, whereas
the AC and IA levels are function-oriented.
An example for the hierarchical organisation of the AM showing the assignment of functional
applications to IA’s is depicted in Figure 8:

Figure 8 — Hierarchical Organisation of the AM (Example)
Internal Interfaces:
The standardised internal interface of the AM is the System Management Logical Interface (SMLI). The
SMLI includes a request-response protocol for the change of the logical configuration.
External Interfaces:
There are no standardised external interfaces of the AM. All external interfaces are application-
dependent.
4.1.4 Error Handling
MOAA compliant systems require that software developers write their functional application code to
interface with the underlying OS using the standardised service calls that comprise the APOS
interface (6.1). However, it is possible at run-time for an APOS service not to perform correctly and to
return an error status to the calling Application Process. This might be due to a real fault in the
underlying system or by misuse of the APOS interfaces themselves (e.g. posting a semaphore before it
has been created). In either case the fault is handled through a standardised process (see
ASAAC2-GUI-32450-001-CPG Issue 01) in which the precise error identification is passed to the Health
Monitoring function within the GSM. Any error handling shall be subject to the decisions made by the
fault management function. In handling the error, the fault management function may delegate the
error handling back to a functional Application Process by invoking the error handler thread of the
Application Process. In this case, the complete error information shall be accessible to this error
handler thread.
The error information shall be accessible to the application itself, but used for debugging purposes only.
Exceptions to this rule are timeouts and resources, which are managed by the application. Note
however that functional Application Processes shall handle situations where a called APOS service has
timed out. In this case, the application calling a service shall be informed by means of a return value.
4.1.5 Built-In Test
4.1.5.1 General
The BIT Services provide the ability to execute module built-in tests and read their results. The built-in-
test component provides access to all built-in-test routines
...