1、ASD STANDARD NORME ASD ASD NORM prEN 4660-002 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 002: Final Draft of Proposed Standards for Common Functional Modules Srie arospatiale Architectures Avioniques Modulaires et Ouvertes Partie 002 : Proposition Finale des Standards pour les CFM Luft- und Raumfahrt Modulare und offene Avionika
3、rchitekturen Teil 002: Endgltiger Entwurf des Standards fr CFM 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 impl
6、ement 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 Procedure
7、s Domain Copyright 2009 by ASD-STAN prEN 4660-002:2009 (E) 2 Contents Page Foreword3 0.1 Purpose.4 0.2 Document structure.5 1 Scope 5 1.1 Relationship with other ASAAC Standards 5 2 Normative references 6 3 Terms, definitions and abbreviations6 3.1 Terms and definitions .6 3.2 Abbreviations.7 3.3 Co
8、nventions used in this Standard .9 4 CFM Definition9 4.1 Generic CFM 10 4.2 Module Support Unit. 12 4.3 Module Processing Capability. 19 4.4 Network Interface Unit (NIU) and Routing Unit (RU) . 28 4.5 Module Power Supply Element . 28 4.6 Module Physical Interface (MPI. 30 5 Common Functional Module
9、Interfaces . 30 5.1 Module Logical Interface (MLI) 30 5.2 Module Physical Interface (MPI) 30 5.3 MOS Interface 31 6 CFM System Support and Guidelines.31 6.1 Fault Management 32 6.2 Fault Detection 32 6.3 Fault Masking 32 6.4 Fault Confinement 32 6.5 Safety and Security. 33 Annex A (informative) Perf
10、ormance Sheet for all Common Functional Modules 35 A.1 Data Processor Module 35 A.2 Signal Processing Module . 36 A.3 Graphic Processing Module 37 A.4 Mass Memory Module 37 A.5 Network Support Module . 38 A.6 Power Conversion Module. 38 Figures Page Figure 1 ASAAC Standard Documentation Hierarchy.4
11、Figure 2 Functional representation of a generic CFM. 10 Figure 3 IMA Common Functional Modules Graphical Composition . 20 Figure 4 The Power Supply Distribution functions of the PCM . 25 Figure 5 Power Supply Element functions . 29 Figure 6 Software Architecture Model - Three Layer Stack 31 prEN 466
12、0-002:2009 (E) 3 Tables Page Table 1 CFM Embedded Information Read Only .13 Table 2 CFM Embedded Information Read / Write 14 Table 3 PCM output characteristics.26 Table 4 PSE input voltage characteristics 29 Table A-1 Performance sheet for a DPM .35 Table A-2 Performance sheet for a SPM36 Table A-3
13、Performance sheet for a GPM .37 Table A-4 Performance sheet for a MMM 37 Table A-5 Performance sheet for a NSM .38 Table A-6 Performance sheet for a PCM .38 Foreword This standard was reviewed by the Domain Technical Coordinator of ASD-STANs Engineering Procedures Domain. After inquiries and votes c
14、arried out in accordance with the rules of ASD-STAN defined in ASD-STANs General Process Manual, this standard has received approval for Publication. prEN 4660-002:2009 (E) 4 0 Introduction 0.1 Purpose This document was produced under the ASAAC Phase II Contract. The purpose of the ASAAC Programme i
15、s 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 program
16、mes. The three main drivers for the ASAAC Programme are: 1. Reduced life cycle costs. 2. Improved mission performance. 3. 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 Architectur
17、e 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 System Man
18、agement Fault Management Initialisation / Shutdown Configuration / Reconfiguration Time Management Security Safety Standards for Architecture Standards for Common Functional Modules Standards for Communications and Network Standards for Packaging Standards for Software Figure 1 ASAAC Standard Docume
19、ntation Hierarchy prEN 4660-002:2009 (E) 5 0.2 Document structure The document contains the following sections: Section 1, scope of the document. Section 2, normative references. Section 3, the terms, definitions and abbreviations. Sections 4 and 5 provide CFM concept definition, requirements and st
20、andards. Section 6 provides guidelines for implementation of standards. Performance sheets for each of the CFMs are attached to the end of the document. These sheets contain a list of attributes to be defined by the system designer and used by the CFM provider. 1 Scope This standard defines the func
21、tionality and principle interfaces for the Common Functional Module (CFM) to ensure the interoperability of Common Functional Modules and provides design guidelines to assist in implementation of such a CFM. It is one of a set of standards that define an ASAAC (Allied Standard Avionics Architecture
22、Council) Integrated Modular Avionics System. This definition of interfaces and functionality allows a CFM design that is interoperable with all other CFM to this standard, that is technology transparent, that is open to a multi-vendor market and that can make the best use of COTS technologies. Altho
23、ugh the physical organisation and implementation of a CFM should remain the manufacturers choice, in accordance with the best use of the current technology, it is necessary to define a structure for each CFM in order to achieve a logical definition of the CFM with a defined functionality. This defin
24、ition includes: The Generic CFM, which defines the generic functionality applicable to the complete set of CFMs. The generic functionality is defined in section 4.1. The processing capability, which defines the unique functionality associated with each CFM type within the set. This functionality is
25、defined in section 4.3. The logical and physical interfaces that enable CFMs to be interoperable and interchangeable, these are defined in section 6. The functionality required by a CFM to support the operation of the System is defined in section 6. 1.1 Relationship with other ASAAC Standards The de
26、finition of the complete CFM is partitioned and is covered by the following ASAAC standards: CFM Mechanical properties and physical Interfaces ASAAC Standards for Packaging. CFM Communication functions ASAAC Standards for Software. CFM Network interface ASAAC Standards for Communications and Network
27、. CFM Software architecture ASAAC Standards for Software. CFM Functional requirements This document. prEN 4660-002:2009 (E) 6 2 Normative references The following referenced documents are indispensable for the application of this document. For dated references, only the edition cited applies. For un
28、dated references, the latest edition of the referenced document (including any amendments) applies. ISO 1540, Aerospace Characteristics of aircraft electrical systems. EN 4660-001, Aerospace series Modular and open Avionics Architectures Part 001: Final Draft of Proposed Standards for Architecture.
29、1)EN 4660-003, Aerospace series Modular and open Avionics Architectures Part 003: Final Draft of Proposed Standards for Communications/Network. 1)EN 4660-004, Aerospace series Modular and open Avionics Architectures Part 004: Final Draft of Proposed Standards for Packaging. 1)EN 4660-005, Aerospace
30、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 Management. Volume 2 Fault Management. Volume 3 Initialisation and Shutdown. Volume 4 Configura
31、tion / 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 express a mandatory requirement of th
32、e 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 will be followed unless good reasons are stated for not doing so. 1) Published as ASD Prestandard at the date of publica
33、tion of this standard. 2) Published by: Allied Standard Avionics Architecture Council. prEN 4660-002:2009 (E) 7 The word MAY in the text expresses a permissible practice or action. It does not express a requirement of the standard. Open System: A system with characteristics that comply with specifie
34、d, publicly maintained, readily available standards and that therefore can be connected to other systems that comply with these same standards. 3.2 Abbreviations 2D : Two Dimensional 3D : Three Dimensional A3 : Advanced Avionics Architecture AGT : Absolute Global Time ALT : Absolute Local Time APOS
35、: Application to Operating System Interface ASAAC : Allied Standard Avionics Architecture Council BIT : Built-in Test CBIT : Continuous BIT CFM : Common Functional Module CORBA : Common Object Request Broker Architecture COTS : Commercial Off The Shelf CRC : Cyclic Redundancy Check dc : Direct Curre
36、nt DPM : Data Processing Module DSP : Digital Signal Processor EDAC : Error Detection And Correction FFT : Fast Fouriert Transformation FIR : Finite Impulse response Filter FMECA : Fault Mode Effect and Criticality Analysis GPM : Graphic Processing Module GSM : Generic System Management HW : Hardwar
37、e HDD : Head-Down Display HMD : Helmet Mounted Display HUD : Head-Up Display IBIT : Initiated BIT ID : Identification prEN 4660-002:2009 (E) 8 IDL : Interface Definition Language IEEE : Institute of Electrical and Electronics Engineers IFFT : Inverse Fast Fourier Transformation IMA : Integrated Modu
38、lar Avionics ISO : International Standards Organisation ITM : Integrated Test and Maintenance JTAG : Joint Test Action Group MC : Module Controller MIS : Module Initialisation Support MLI : Module Logical Interface MMM : Mass Memory Module MOS : Module Support Layer to Operating System Interface MPI
39、 : Module Physical Interface MSL : Module Support Layer MSU : Module Support Unit MTP : Maintenance Test Port N/A : Not Applicable NIU : Network Interface Unit NSM : Network Support Module OMG : Object Management Group O/P : Output OS : Operating System OSL : Operating System Layer PBIT : Power-up /
40、 power-down BIT PCM : Power Conversion Module PCU : Power Conversion Unit PE : Processing Element PMS : Power Management System PSA : Power Switch Array PSE : Power Supply Element PU : Processing Unit RC : Reference Clock RLT : Relative Local Time prEN 4660-002:2009 (E) 9 RTBP : Runtime Blueprints R
41、U : Routing Unit SPM : Signal Processing Module TC : Transfer Connection TLS : Three Layer Stack Vdc : Voltage dc 3.3 Conventions used in this Standard The Interface Definition Language (IDL) as defined in the Common Object Request Broker Architecture (CORBA) 2.3 is used to express the MOS services
42、as programming language independent services in this document. The conventions used in this document are as follows: 3.3.1 Special Fonts Words that have a special meaning appear in specific fonts or font styles. All code listings, reserved words and the name of actual data structures, constants, and
43、 routines are shown in Courier. 3.3.2 Naming Conventions Parameter and variable names contain only words with lower case letters, which are separated by underscore. Example vc_message NOTE Upper and lower case letters are treated as the same letter. 4 CFM Definition The Common Functional Modules (CF
44、Ms) are line replaceable items and provide an ASAAC IMA system with a computational capability, network support capability and power conversion capability. The following set of modules have been defined for use within an IMA core processing system: Signal Processing Module (SPM). Data Processing Mod
45、ule (DPM). Graphics Processing Module (GPM). Mass Memory Module (MMM). Network Support Module (NSM). Power Conversion Module (PCM). This set of CFMs complies with the generic CFM format defined in this section. It is assumed that a System Design Specification will be raised for each specific project
46、 implementation in which the detailed performance requirements for each CFM will appear. prEN 4660-002:2009 (E) 10 4.1 Generic CFM 4.1.1 Generic CFM Description The internal architecture of each CFM consists of a set of functional elements that are applied to each CFM implementation. These are shown
47、 graphically in Figure 2 and are detailed below. All functions, with the exception of the Processing Unit, are generic to each CFM type. Processing Unit - SP - DP - GP - MM Links to Network Routing Unit Power Generic Common Functional Module Module Support Unit Network Interface Unit Power Supply El
48、ement Module Physical Interface Figure 2 Functional representation of a generic CFM (For PCM and NSM refer to Figure 3) The Module Support Unit (MSU) controls and monitors the module and provides common functions such as Built-in-Test (BIT) control, module initialisation, time management, status rec
49、ording/reporting and support for MLI (section 5), system management and debugging. The Processing Unit (PU) provides the specific function of a CFM, for example data processing, signal processing, mass storage. These are defined in section 4.3. The Module Physical Interface (MPI) defines the physical characteristics of the module and implements the mechanical, optical, electrical and cooling interfaces. These are detailed in sec
