1、ASD STANDARD NORME ASD ASD NORM prEN 4660-001 Edition P 1 July 2009 PUBLISHED BY THE AEROSPACE AND DEFENCE INDUSTRIES ASSOCIATION OF EUROPE - STANDARDIZATIONAvenue de Tervuren, 270 - B-1150 Brussels - Tel. + 32 2 775 8126 - Fax. + 32 2 775 8131 - www.asd-stan.orgICS: Descriptors: ENGLISH VERSION Aer
2、ospace series Modular and Open Avionics Architectures Part 001: Final Draft of Proposed Standards for Architecture Srie arospatiale Architectures Avioniques Modulaires et Ouvertes Partie 001 : Proposition Finale des Standards pour lArchitecture Luft- und Raumfahrt Modulare und offene Avionikarchitek
3、turen Teil 001: Entgltiger Entwurf des Standards fr Architektur This “Aerospace Series“ Prestandard has been drawn up under the responsibility of ASD-STAN (The AeroSpace and Defence Industries Association of Europe - Standardization). It is published for the needs of the European Aerospace Industry.
4、 It has been technically approved by the experts of the concerned Domain following member comments. Subsequent to the publication of this Prestandard, the technical content shall not be changed to an extent that interchangeability is affected, physically or functionally, without re-identification of
5、 the standard. After examination and review by users and formal agreement of ASD-STAN, it will be submitted as a draft European Standard (prEN) to CEN (European Committee for Standardization) for formal vote and transformation to full European Standard (EN). The CEN national members have then to imp
6、lement the EN at national level by giving the EN the status of a national standard and by withdrawing any national standards conflicting with the EN. Edition approved for publication 31 July 2009 Comments should be sent within six months after the date of publication to ASD-STAN Engineering Procedur
7、es Domain Copyright 2009 by ASD-STAN Copyright ASD-STAN Provided by IHS under license with AECMA Not for ResaleNo reproduction or networking permitted without license from IHS-,-,-prEN 4660-001:2009 (E) 2 Table of Contents Page Foreword3 0.1 Purpose.4 0.2 Document Structure 5 1 Scope 6 2 Normative r
8、eferences 6 3 Terms, definitions and abbreviations6 3.1 Terms and definitions .6 3.2 Abbreviations.7 3.3 Definitions 8 4 IMA Drivers and Characteristics 8 4.1 Drivers.8 4.2 Introduction to IMA Concepts 9 4.2.1 Non-IMA Systems 9 4.2.2 Characteristics for an IMA System . 10 4.2.3 IMA System Design 10
9、5 Requirements and the Architecture Standard. 12 5.1 Software Architecture 12 5.2 Common Functional Module . 14 5.3 Communication / Network . 14 5.4 Packaging 15 6 Guidelines 15 6.1 System Management 16 6.2 Fault Management 16 6.3 System initialisation and shutdown 16 6.4 System Configuration / reco
10、nfiguration. 17 6.5 Time Management. 17 6.6 Security Aspects. 17 6.7 Safety . 18 Annex A (informative) Power Distribution Architecture. 19 A.1 General Description 19 A.2 The Double Conversion Architecture . 19 A.3 The Line Replaceable Chamber 20 Copyright ASD-STAN Provided by IHS under license with
11、AECMA Not for ResaleNo reproduction or networking permitted without license from IHS-,-,-prEN 4660-001:2009 (E) 3 Table of Figures Page Figure 1 ASAAC Standard Documentation Hierarchy .4 Figure 2 A Typical Federated Aircraft System9 Figure 3 IMA Core System 11 Figure 4 IMA System11 Figure 5 An IMA S
12、ystem12 Figure 6 Three Layer Software Architecture.13 Figure A.1 Double Conversion Architecture.19 Table of Tables Page Table 1 Architectural Characteristics 10 Table 2 Software Layer Independence 13 Foreword This standard was reviewed by the Domain Technical Coordinator of ASD-STANs Engineering Pro
13、cedures Domain. After inquiries and votes carried out in accordance with the rules of ASD-STAN defined in ASD-STANs General Process Manual, this standard has received approval for Publication. Copyright ASD-STAN Provided by IHS under license with AECMA Not for ResaleNo reproduction or networking per
14、mitted without license from IHS-,-,-prEN 4660-001:2009 (E) 4 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 Archi
15、tectures (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, I
16、mproved 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 implementati
17、on through application of the standards. The document hierarchy is given hereafter: (in this figure, the current document is highlighted) Guidelines for System Issues System Management Fault Management Initialisation / Shutdown Configuration / Reconfiguration Time Management Security SafetyStandards
18、 for ArchitectureStandards for Common Functional ModulesStandards for Communications andNetworkStandards for PackagingStandards for SoftwareFigure 1 ASAAC Standard Documentation Hierarchy Copyright ASD-STAN Provided by IHS under license with AECMA Not for ResaleNo reproduction or networking permitte
19、d without license from IHS-,-,-prEN 4660-001:2009 (E) 5 0.2 Document Structure The document contains the following sections: Section 1, gives the scope of the document, Section 2, identifies normative references, Section 3, gives the terms, definitions and abbreviations, Section 4, presents the set
20、of architecture drivers and characteristics as well as an introduction to IMA, Section 5, defines the architecture standard, and introduces the other standards, Section 6, introduces the guidelines for implementing an IMA architecture, Annex A, presents the power supply architecture. Copyright ASD-S
21、TAN Provided by IHS under license with AECMA Not for ResaleNo reproduction or networking permitted without license from IHS-,-,-prEN 4660-001:2009 (E) 6 1 Scope The purpose of this standard is to establish uniform requirements for the architecture for Integrated Modular Avionic (IMA) systems as defi
22、ned by the ASAAC Programme. The IMA architecture can be built by using common components. These components are specified in separate standards. Ways of using these components are described in a set of guidelines. This document gives references to these Standards and Guidelines as well as a short int
23、roduction to IMA. 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-
24、002, Modular and open Avionics Architectures Part 002: Final Draft of Proposed Standards for Common Functional Modules. 1)EN 4660-003, Modular and open Avionics Architectures Part 003: Final Draft of Proposed Standards for Communications/Network. 1)EN 4660-004, Modular and open Avionics Architecture
25、s Part 004: Final draft of Proposed Standards for Packaging. 1)EN 4660-005, Aerospace series Modular and open Avionics Architectures Part 005: Final Draft of Proposed Standards for Software. 1)ASAAC2-GUI-32450-001-CPG Issue 01, Final Draft of Guidelines for System Issues 2) Volume 1 System Managemen
26、t. 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
27、 the following rules: The word SHALL in the text expresses a mandatory requirement of the standard. 1) Published as ASD Prestandard at the date of publication of this standard. 2) Published by: Allied Standard Avionics Architecture Council. Copyright ASD-STAN Provided by IHS under license with AECMA
28、 Not for ResaleNo reproduction or networking permitted without license from IHS-,-,-prEN 4660-001:2009 (E) 7 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
29、 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 / Oper
30、ating 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 DC :
31、 Direct Current DPM : Data Processing Module EO : Electro-Optic EMI : Electro-Magnetic Interference EW : Electronic Warfare GPM : Graphic Processing Module GSM : Generic System Management HDD : Head-Down Display HUD : Head-Up Display HW : Hardware IED : Insertion / Extraction Device IF : Interface I
32、FF : Identification Friend or Foe Copyright ASD-STAN Provided by IHS under license with AECMA Not for ResaleNo reproduction or networking permitted without license from IHS-,-,-prEN 4660-001:2009 (E) 8 IMA : Integrated Modular Avionics LRC : Line Replaceable Chamber LRM : Line Replaceable Module MMM
33、 : 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 Det
34、ection and Tracking TRANSEC : Transmission Security UAV : Unmanned Aerial Vehicle 3.3 Definitions IMA System is a full system that is built from an IMA Core System and non-Core equipment. IMA Core System is an avionics system comprising one or a series of avionic racks containing sets of standardise
35、d CFMs linked together by a unified communication network and executing reusable functional applications that are hardware independent, operating systems and system management software. Common Functional Modules (CFM) are line replaceable items and provide an IMA Core System with a computational cap
36、ability, network support capability and power conversion capability. Software Layered Architecture is a 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 laye
37、rs. System Management is the 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: Reduced Life Cyc
38、le 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. Copyright ASD-STAN Provided by IHS under license with AECMA Not for ResaleNo reproduction or networking permitted without license from IHS-,-,-prEN 4660-
39、001:2009 (E) 9 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 Ope
40、rational 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
41、 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 em
42、bedded 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 sy
43、stem architecture. S2S1 S2 S3 S4 S5S2S6S6S6S6Sn - Supplier numberData Bus Comms Standard AData Bus Comms Standard BData Bus Comms Standard CFigure 2 A Typical Federated Aircraft System It is widely accepted within the aerospace community that the consequences of continuing to develop aircraft along
44、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 a
45、nd 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. Copyright ASD-STAN Provided by IHS under license with AECMA Not for ResaleNo reproductio
46、n or networking permitted without license from IHS-,-,-prEN 4660-001:2009 (E) 10 4.2.2 Characteristics for an IMA System The first step in defining a solution to meet the drivers defined in section 4.1 is to establish a suite of derived requirements or architecture characteristics that would collect
47、ively 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 Architectural Characteristics Mission Performance Operational performance Life C
48、ycle Costs Define a small module set with wide applicability - 4 4 Design modules to be replaceable at 1stline - 4 4 Maximise interoperability and interchangeability of modules - 4 4 Adopt the use of an open system architecture - - 4 Maximise the use of commercial off-the-shelf technology - 4 4 Maximise technology transparency for both hardware and software components - - 4 Minimise impact of Hardware & OS upgrades - - 4 Maximise software reuse & Portability - 4 4 Define comprehensive BIT and fault tolerance tec
