Bsi bs en 04660 001 2011

NO COPYING WITHOUT BSI PERMISSION EXCEPT AS PERMITTED BY COPYRIGHT LAWBSI Standards Publication Aerospace series — Modular and Open Avionics Architectures Part 001: Architecture... This

NO COPYING WITHOUT BSI PERMISSION EXCEPT AS PERMITTED BY COPYRIGHT LAW

BSI Standards Publication

Aerospace series — Modular and Open Avionics Architectures

Part 001: Architecture

This British Standard is the UK implementation of EN 4660-001:2011.The UK participation in its preparation was entrusted to TechnicalCommittee ACE/6, Aerospace avionic electrical and fibre optictechnology.

A list of organizations represented on this committee can beobtained on request to its secretary

This publication does not purport to include all the necessaryprovisions of a contract Users are responsible for its correctapplication

© BSI 2011ISBN 978 0 580 62441 4ICS 49.090

Compliance with a British Standard cannot confer immunity from legal obligations.

This British Standard was published under the authority of theStandards Policy and Strategy Committee on 31 March 2011

Amendments issued since publication

Date Text affected

Série aérospatiale - Architectures Avioniques Modulaires et

Ouvertes - Partie 001: Architecture Luft- und Raumfahrt - Modulare und offene Avionikarchitekturen - Teil 001: Architektur

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

C O M I T É E U R O P É E N D E N O R M A L I S A T I O N

E U R O P Ä I S C H E S K O M I T E E FÜ R N O R M U N G

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-001:2011: E

2

Foreword 4

0 Introduction 4

0.1 Purpose 5

0.2 Document Structure 6

1 Scope 7

2 Normative references 7

3 Terms, definitions and abbreviations 7

3.1 Terms and definitions 7

3.2 Abbreviations 8

3.3 Definitions 9

4 IMA Drivers and Characteristics 9

4.1 Drivers 9

4.2 Introduction to IMA Concepts 10

4.2.1 Non-IMA Systems 10

4.2.2 Characteristics for an IMA System 11

4.2.3 IMA System Design 11

5 Requirements and the Architecture Standard 13

5.1 Software Architecture 13

5.2 Common Functional Module 15

5.3 Communication / Network 15

5.4 Packaging 16

6 Guidelines 16

6.1 System Management 17

6.2 Fault Management 17

6.3 System initialisation and shutdown 17

6.4 System Configuration / reconfiguration 18

6.5 Time Management 18

6.6 Security Aspects 18

6.7 Safety 19

Annex A (informative) Power Distribution Architecture 20

A.1 General Description 20

A.2 The Double Conversion Architecture 20

A.3 The Line Replaceable Chamber 21

Table of Figures Page

Figure 1 — ASAAC Standard Documentation Hierarchy 5

Figure 2 — A Typical Federated Aircraft System 10

Figure 3 — IMA Core System 12

Figure 4 — IMA System 12

Figure 5 — An IMA System 13

Figure 6 — Three Layer Software Architecture 14

Figure A.1 — Double Conversion Architecture 20

Table of Tables Page Table 1 — Architectural Characteristics 11

Table 2 — Software Layer Independence 14

4

Foreword

This document (EN 4660-001:2011) 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 August 2011, and conflicting national standards shall be withdrawn at the latest by August 2011

Attention is drawn to the possibility that some of the elements of this document may be the subject of patent rights CEN [and/or CENELEC] shall not be held responsible for identifying any or all such patent rights According to the CEN/CENELEC Internal Regulations, the national standards organizations 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, Romania, Slovakia, Slovenia, Spain, Sweden, Switzerland and the United Kingdom

0 Introduction

0.1 Purpose

This document was produced under the ASAAC Phase II Contract

The purpose of the ASAAC Programme is to define and validate a set of open architecture standards, concepts and guidelines for Advanced Avionics Architectures (A3) in order to meet the three main ASAAC drivers The standards, concepts and guidelines produced by the Programme are to be applicable to both new aircraft and update programmes

The three main drivers for the ASAAC Programme are:

 Reduced life cycle costs,

 Improved mission performance,

 Improved operational performance

The 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 systems,

 The guidelines for system implementation through application of the standards

The document hierarchy is given hereafter: (in this figure, the current document is highlighted)

Guidelines for System Issues

Standards for Architecture

Standards for Common Functional Modules

Standards for Communications and

Network

Standards for Packaging

Standards for Software

Figure 1 — ASAAC Standard Documentation Hierarchy

6

0.2 Document Structure

The document contains the following clauses:

Clause 1, gives the scope of the document,

Clause 2, identifies normative references,

Clause 3, gives the terms, definitions and abbreviations,

Clause 4, presents the set of architecture drivers and characteristics as well as an introduction to IMA, Clause 5, defines the architecture standard, and introduces the other standards,

Clause 6, introduces the guidelines for implementing an IMA architecture,

Annex A, presents the power supply architecture

2 Normative references

The following referenced documents are indispensable for the application 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

EN 4660-002, Aerospace series — Modular and Open Avionics Architectures — Part 002: Common Functional Modules

EN 4660-003, Aerospace series — Modular and Open Avionics Architectures — Part 003: Communications/Network

EN 4660-004, Aerospace series — Modular and Open Avionics Architectures — Part 004: Packaging

EN 4660-005, Aerospace series — Modular and Open Avionics Architectures — Part 005: Software

ASAAC2-GUI-32450-001-CPG Issue 01, Final Draft of Guidelines for System Issues 1)

— 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

3 Terms, definitions and abbreviations

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

1) Published by: Allied Standard Avionics Architecture Council

8

 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 will 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

A3 : Advanced Avionics Architectures

AM : Application Management

AL : Application Layer

APOS : Application Layer / Operating System Layer Interface

ASAAC : Allied Standard Avionics Architecture Council

BIT : Built-In Test

BW : Band-Width

CFM : Common Functional Modules

CNI : Communication / Navigation / Identification

COMSEC : Communication Security

COTS : Commercial Off The Shelf

CPU : Computer Processing Unit

GPM : Graphic Processing Module

GSM : Generic System Management

IFF : Identification Friend or Foe

IMA : Integrated Modular Avionics

LRC : Line Replaceable Chamber

LRM : Line Replaceable Module

MMM : Mass Memory Module

MOS : Module Support Layer / Operating System Layer Interface

MPI : Module Physical Interface

NSM : Network Support Module

OS : Operating System

PCM : Power Conversion Module

PCU : Power Conversion Unit

PSE : Power Supply Element

SPM : Signal Processing Module

TD&T : Target Detection and Tracking

TRANSEC : Transmission Security

UAV : Unmanned Aerial Vehicle

IMA Core System

avionics system comprising one or a series of avionic racks containing sets of standardised CFMs linked together by a unified communication network and executing reusable functional applications that are hardware independent, operating systems and system management software

3.3.3

Common Functional Modules (CFM)

line replaceable items and provide an IMA Core System with a computational capability, network support capability and power conversion capability

3.3.4

Software Layered Architecture

common software model based on the concept of a layered software architecture Within this model, the layers are separated by standardised interfaces in order to provide independence of these layers

3.3.5

System Management

management of the resources and services of an IMA Core System during initialisation, all operational phases

in flight and on ground, and system shutdown

4 IMA Drivers and Characteristics

4.1 Drivers

The three principle drivers for the architecture are:

10

 Reduced Life Cycle Cost:

 A major objective is to reduce the accumulated costs over the life cycle of a system i.e the development, acquisition and support costs

 Improved Mission Performance:

 The system must be capable of fulfilling the missions and satisfy all possible airborne platforms in terms of functionality, capability, reliability, accuracy, configurability and interoperability under the full scope of operating conditions

 Improved Operational Performance:

 The goal adopted is that the system (aircraft) should achieve a combat capability of 150 flying hours

or 30 days without maintenance, with an availability of at least 95 %

 This goal far exceeds that achievable today and an IMA System will be required to exhibit fault tolerance so that it can survive the occurrence of faults with the required level of functionality

4.2 Introduction to IMA Concepts

4.2.1 Non-IMA Systems

Non-IMA systems (e.g federated systems) often comprise avionics units supplied by different equipment suppliers These units invariably contain custom embedded computer systems in which the functional software is habitually bound to the hardware It is not uncommon practice for these units to communicate via a number of different data busses, with perhaps two or three communication standards being the norm Figure 2 depicts a simplified federated system architecture

S2

S2

S6 S6 S6

S6

Sn - Supplier number

Data Bus – Comms Standard ‘A’

Data Bus – Comms Standard ‘B’

Data Bus – Comms Standard ‘C’

Figure 2 — A Typical Federated Aircraft System

It is widely accepted within the aerospace community that the consequences of continuing to develop aircraft along these lines are: frequent maintenance, low aircraft availability, low hardware and software re-use and large spares inventories - all of which contribute to higher costs for the initial production and the subsequent maintenance of avionics systems Aircraft systems are becoming increasingly larger and more complex, driven as they are by current mission and operational requirements, while market availability of components is getting so short that systems are often becoming obsolete during their development

4.2.2 Characteristics for an IMA System

The first step in defining a solution to meet the drivers defined in 4.1 is to establish a suite of derived requirements or architecture characteristics that would collectively lend themselves to the main drivers being met

The key architectural characteristics (ultimately there are many) derived from the three main drivers are identified in Table 1

Table 1 — Architectural Characteristics

Define comprehensive BIT and fault tolerance techniques to allow deferred maintenance ✔ ✔ ✔

4.2.3 IMA System Design

Once the three high level drivers are translated into architectural characteristics, the next step is to define the scope of what these new standards, concepts and guidelines should be applicable to The boundaries are drawn at the IMA Core System

The IMA Core System can be defined as a set of one or more racks comprising a set of standardised modules from a limited set of module types communicating across a unified digital network The IMA Core System processes inputs received from the platform’s low and high bandwidth sensors and transmits its outputs to the platform’s low and high bandwidth effectors Figure 3 shows an IMA Core System within a representative aircraft system

- Pilot’s Controls

- Maintenance Panel

High BW Sensors

- RADAR

- EO

- EW

Aircraft Sources

- Clocks

Power Supply System

High BW Effectors

- Pilot’s Controls

- Maintenance Panel

Platform

Figure 3 — IMA Core System

The IMA Core System can be viewed as a single entity comprising many integrated processing resources which can be used to construct any avionics system regardless of size and complexity The concept of the IMA Core System is therefore equally applicable to smart missiles, UAVs, fast jets, large military aircraft

The digital processing that occurs within the IMA Core System includes all the typical functional applications normally associated with avionics platforms: Vehicle Management, Mission Management, Stores Management, CNI, Target Detection & Tracking, HUD & HDD Displays, etc, as shown in Figure 4 The unified network used as the communication medium within the IMA Core System is also used to enable the functional applications to communicate with the platform’s sensors and effectors This communication is made possible

by the use of interfaces to the network

Stores Mgmt

RADAR

EW

Maintenance Panel

Platform

Figure 4 — IMA System