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

The purpose of this European Standard is to establish uniform requirements for design and development of software architecture for modular avionics systems as defined per ASAAC.
1.1   Software Architecture Overview
The ASAAC 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.
1.2   Software Architectural Components
Figure 3 provides an overview of the software architectural components and software interfaces.
1.2.1   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.2.2   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.2).
1.2.3   Operating System (OS)
A Real-Time OS provides the particular part of OSL functionality that controls the real-time behaviour of the Processing Element and its associated resources (see Clause 0).
1.2.4   Generic System Management (GSM)
The GSM is responsible for the management of the core processing (see 4.1.1 and 5.2.1). This functionality is divided into four areas:
-   Health Monitoring,
-   Fault Management,
-   Configuration Management,
-   Security Management.
1.2.5   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).
(...)

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

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

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

Namen tega evropskega standarda je vzpostaviti enotne zahteve za načrtovanje in razvoj programske arhitekture za modularne letalske sisteme, kot je opredeljeno v ASAAC.

General Information

Status
Withdrawn
Publication Date
03-May-2011
Withdrawal Date
20-Jan-2026
Technical Committee
ASD-STAN - Aerospace
Drafting Committee
ASD-STAN/D 1 - General
Current Stage
9960 - Withdrawal effective - Withdrawal
Start Date
21-Aug-2019
Completion Date
21-Jan-2026

Relations

Effective Date
04-Feb-2015
Effective Date
28-Jan-2026
Effective Date
28-Jan-2026
Effective Date
28-Jan-2026
Effective Date
28-Jan-2026
Standard

EN 4660-005:2011

English language
505 pages
Preview
Preview
e-Library read for
1 day

Get Certified

Connect with accredited certification bodies for this standard

National Aerospace and Defense Contractors Accreditation Program (NADCAP)

Global cooperative program for special process quality in aerospace.

ANAB United States Verified

NSF-ISR

NSF International Strategic Registrations.

ANAB United States Verified

Orion Registrar Inc.

US-based certification body for management systems.

ANAB United States Verified

Sponsored listings

Frequently Asked Questions

EN 4660-005:2011 is a standard published by the European Committee for Standardization (CEN). Its full title is "Aerospace series - Modular and Open Avionics Architectures - Part 005: Software". This standard covers: The purpose of this European Standard is to establish uniform requirements for design and development of software architecture for modular avionics systems as defined per ASAAC. 1.1 Software Architecture Overview The ASAAC 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. 1.2 Software Architectural Components Figure 3 provides an overview of the software architectural components and software interfaces. 1.2.1 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.2.2 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.2). 1.2.3 Operating System (OS) A Real-Time OS provides the particular part of OSL functionality that controls the real-time behaviour of the Processing Element and its associated resources (see Clause 0). 1.2.4 Generic System Management (GSM) The GSM is responsible for the management of the core processing (see 4.1.1 and 5.2.1). This functionality is divided into four areas: - Health Monitoring, - Fault Management, - Configuration Management, - Security Management. 1.2.5 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). (...)

The purpose of this European Standard is to establish uniform requirements for design and development of software architecture for modular avionics systems as defined per ASAAC. 1.1 Software Architecture Overview The ASAAC 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. 1.2 Software Architectural Components Figure 3 provides an overview of the software architectural components and software interfaces. 1.2.1 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.2.2 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.2). 1.2.3 Operating System (OS) A Real-Time OS provides the particular part of OSL functionality that controls the real-time behaviour of the Processing Element and its associated resources (see Clause 0). 1.2.4 Generic System Management (GSM) The GSM is responsible for the management of the core processing (see 4.1.1 and 5.2.1). This functionality is divided into four areas: - Health Monitoring, - Fault Management, - Configuration Management, - Security Management. 1.2.5 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). (...)

EN 4660-005:2011 is classified under the following ICS (International Classification for Standards) categories: 49.090 - On-board equipment and instruments. The ICS classification helps identify the subject area and facilitates finding related standards.

EN 4660-005:2011 has the following relationships with other standards: It is inter standard links to EN 4660-005:2019, EN 4660-001:2011, EN 4660-003:2019, EN 4660-002:2011, EN 4660-004:2019. Understanding these relationships helps ensure you are using the most current and applicable version of the standard.

EN 4660-005:2011 is available in PDF format for immediate download after purchase. The document can be added to your cart and obtained through the secure checkout process. Digital delivery ensures instant access to the complete standard document.

Standards Content (Sample)


2003-01.Slovenski inštitut za standardizacijo. Razmnoževanje celote ali delov tega standarda ni dovoljeno.Aeronavtika - Modularne in odprte letalske elektronske arhitekture - 005. del: Programska opremaLuft- und Raumfahrt - Modulare und offene Avionikarchitekturen - Teil 005: SoftwareSérie aérospatiale - Architectures Avioniques Modulaires et Ouvertes - Partie 005: SoftwareAerospace series - Modular and Open Avionics Architectures - Part 005: Software49.090On-board equipment and instrumentsICS:Ta slovenski standard je istoveten z:EN 4660-005:2011SIST EN 4660-005:2011en,fr,de01-oktober-2011SIST EN 4660-005:2011SLOVENSKI
STANDARD
EUROPEAN STANDARD NORME EUROPÉENNE EUROPÄISCHE NORM
EN 4660-005
May 2011 ICS 49.090 English Version
Aerospace series - Modular and Open Avionics Architectures - Part 005: Software
Série aérospatiale - Architectures Avioniques Modulaires et Ouvertes - Partie 005: Software
Luft- und Raumfahrt - Modulare und offene Avionikarchitekturen - Teil 005: Software This European Standard was approved by CEN on 26 June 2010.
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, Romania, Slovakia, Slovenia, Spain, Sweden, Switzerland and United Kingdom.
EUROPEAN COMMITTEE FOR STANDARDIZATION
COMITÉ EUROPÉEN DE NORMALISATION EUROPÄISCHES KOMITEE FÜR NORMUNG
Management Centre:
Avenue Marnix 17,
B-1000 Brussels © 2011 CEN All rights of exploitation in any form and by any means reserved worldwide for CEN national Members. Ref. No. EN 4660-005:2011: ESIST EN 4660-005:2011

AGL . 496 A.1 The Concept . 496 A.2 Graphical Command Set . 496 A.2.1 Overview . 496 A.2.2 Command Listings . 497 A.2.3 Auxiliary Library (AL) Definition . 501 A.2.4 Video Library (VL) Definition . 502 A.2.5 Texture Mapping Constraints . 503 A.2.6 Display Frame and Synchronisation . 505 A.2.7 Command Responses and Delays . 505
Figures Page Figure 1 — ASAAC Standard Documentation Hierarchy . 11 Figure 2 — ASAAC Three Layer Software Architecture . 12 Figure 3 — The Software Architecture Model . 13 Figure 4 — Hierarchical Organisation of the System Management . 20 Figure 5 — GSM Decomposition for RE-Management (Example) . 21 Figure 6 — IA Application Control (Example) . 22 Figure 7 — GSM Decomposition for Module Management (Example) . 23 Figure 8 — Hierarchical Organisation of the AM (Example) . 24 Figure 9 — The ASAAC Communication Stack . 27 Figure 10 — Types of Data Transfer . 29 Figure 11 — Communication Concept . 30 Figure 12 — Between AL Communication Routing . 31 Figure 13 — ASAAC Message in BMC Data Transfer . 33 Figure 14 — Multicast Scheme With a Single TC . 34 Figure 15 — Multicast Scheme With Multiple Simple TC’s . 35 Figure 16 — Data Parallelism . 36 Figure 17 — Corner Turn . 36 Figure 18 — Corner Turn in Three Dimensions. 37 Figure 19 — Illustration of the Involved Services in DSP1 . 38 Figure 20 — Data Representation . 41 Figure 21 — GSM Interfaces . 46 SIST EN 4660-005:2011

Tables
Page Table 1 — Software Layer Independence . 13 Table 2 — CBIT Modes . 26 Table 3 — Routing Information and Data Transfer . 33 Table 4 — IDL Primitive Types . 43 Table 5 — IDL Constructive Types . 45 Table 6 — Power Switching Services . 56 Table 7 — Layers, Process Classes, and Standardised Interfaces . 66 Table 8 — List of SMOS Services for RE-CM . 74 Table 9 — List of SMOS Services for RE-HM . 75 Table 10 — List of SMOS Services for RE-FM . 75 Table 11 — List of SMOS Services for RE-SM . 76 Table 12 — List of SMOS Services for IA-CM . 77 Table 13 — List of SMOS Services for IA-FM . 78 Table 14 — List of SMOS Services for AC-FM . 79 Table 15 — Transition of Thread States . 82 Table 16 — Condition of State Transition . 82 Table 17 — Properties of Time Services . 93 Table 18 — Resource Parameters of Basic Resource Entities . 112 SIST EN 4660-005:2011

Guidelines for System Issues • System Management • Fault Management • Initialisation / Shutdown • Configuration / Reconfiguration• Time Management • Security • Safety Standard for Architecture Standard for Common Functional Modules Standard for Communications and Network Standard for Packaging Standard for Software
Figure 1 — ASAAC Standard Documentation Hierarchy SIST EN 4660-005:2011

Application LayerOperating System LayerModule Support LayerAPOSMOS Figure 2 — ASAAC Three Layer Software Architecture Each layer is described in terms of it dependency/independency on both the aircraft system and the underlying hardware. SIST EN 4660-005:2011

Figure 3 — The Software Architecture Model 1.2.1 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.2.2 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.2). SIST EN 4660-005:2011
...

Questions, Comments and Discussion

Ask us and Technical Secretary will try to provide an answer. You can facilitate discussion about the standard in here.

Loading comments...