Aerospace series - Modular and Open Avionics Architectures - Part 002: Common Functional Modules

1.1   General
This standard defines the functionality 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 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.
Although the physical organisation and implementation of a CFM should remain the manufacturer's 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 definition includes:
-   the Generic CFM, which defines the generic functionality applicable to the complete set of CFMs. The generic functionality is defined in 4.2;
-   the processing capability, which defines the unique functionality associated with each CFM type within the set. This functionality is defined in 4.4;
-   the logical and physical interfaces that enable CFMs to be interoperable and interchangeable, these are defined in Clause 6;
-   the functionality required by a CFM to support the operation of the System is defined in Clause 6.
1.2   Relationship with other ASAAC Standards
The definition 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;
-   CFM Software architecture - ASAAC Standards for Software;
-   CFM Functional requirements - This document.

Luft- und Raumfahrt - Modulare und offene Avionikarchitekturen - Teil 002: CFM

Diese Norm definiert die Funktionalität und wesentliche Schnittstellen für das Standardfunktionsmodul (Com-mon Functional Module, CFM), um dessen Interoperabilität sicherzustellen, und enthält Entwurfsleitlinien als Unterstützung für die Implementierung derartiger CFM. Dieses Dokument ist Teil einer Reihe von Normen, die ein integriertes modulares Avioniksystem definieren, das den Vorgaben des ASAAC-Standards (Allied Stan-dard Avionics Architecture Council) entspricht.
Die Definition von Schnittstellen und Funktionalitäten erlaubt einen CFM-Entwurf, der mit allen anderen CFM nach diesem Standard interoperabel ist, der technologisch transparent ist, der für einen Markt mit einer Viel-zahl von Herstellern offen ist und COTS-Technologien am wirkungsvollsten nutzen kann.
Obwohl die physikalische Organisation und Implementierung eines CFM dem Hersteller überlassen bleiben sollte, ist es im Sinne der wirkungsvollsten Nutzung der aktuellen Technologien notwendig, für jedes CFM eine Struktur zu definieren, um eine logische Definition des CFM mit einer definierten Funktionalität zu erhal-ten. Die Definition umfasst:
- Das generische CFM, das die für den gesamten CFM-Satz geltende generische Funktionalität definiert. Die generische Funktionalität ist in 4.1 definiert.
- Die Verarbeitungsfähigkeit, welche die spezielle Funktionalität definiert, die jedem CFM-Typ im Satz zuge-ordnet ist. Diese Funktionalität ist in 4.3 definiert.
- Die logischen und physikalischen Schnittstellen, die eine Interoperabilität von CFM und ihren Austausch untereinander ermöglichen; diese Schnittstellen sind in Abschnitt 6 definiert.
- Die von einem CFM zur Unterstützung des Systembetriebs benötigte Funktionalität ist in Abschnitt 6 definiert.
1.1
Zusammenhang mit anderen ASAAC-Standards
Die Definition des vollständigen CFM ist durch folgende ASAAC-Standards abgedeckt:
- mechanische Eigenschaften und physikalische Schnittstellen des CFM — ASSAC-Standards für Paketie-rung.
- Kommunikationsfunktionen des CFM - ASAAC-Standards für Software.
- Netzwerkschnittstelle des CFM - ASAAC-Standards für Kommunikation und Netzwerk.
- Softwarearchitektur des CFM - ASAAC-Standards für Software.
- Funktionsanforderungen des CFM - vorliegendes Dokument.

Série aérospatiale - Architectures Avioniques Modulaires et Ouvertes - Partie 002: CFM

La présente norme définit la fonctionnalité et les principales interfaces concernant le Module Fonctionnel
Commun (CFM) pour assurer l’interopérabilité des modules fonctionnels communs et elle fournit des lignes
directrices de conception pour faciliter la mise en oeuvre d’un tel CFM. Elle fait partie d’un ensemble de normes
qui définit un système avionique modulaire intégré ASAAC (Allied Standard Avionics Architecture Council).
Cette définition des interfaces et de la fonctionnalité permet une conception de CFM qui est interopérable avec
tous les autres CFM selon la présente norme, qui est transparente du point de vue technologique, ouverte au
marché multi-vendeurs et qui peut utiliser de manière optimale les technologies COTS.
Bien que l’organisation physique et la mise en oeuvre d’un CFM restent liés au choix du fabricant,
conformément à l’utilisation optimale de la technologie courante, il est nécessaire de définir une structure pour
chaque CFM afin d’obtenir une définition logique de CFM ayant une fonctionnalité définie. Cette définition
comprend :
- Le CFM générique qui définit la fonctionnalité générique applicable pour réaliser un ensemble de CFM. La
fonctionnalité générique est définie dans le Paragraphe 4.1.
- La capacité de traitement qui définit la fonctionnalité unique associée à chaque type de CFM à l’intérieur
de l’ensemble. Cette fonctionnalité est définie dans le Paragraphe 4.3.
- Les interfaces logiques et physiques qui permettent aux CFM d’être interopérables et interchangeables,
celles-ci sont définies dans l’Article 6.
- La fonctionnalité requise par un CFM pour supporter le fonctionnement du système est définie dans
l’Article 6.
1.1 Relation avec les autres Normes ASAAC
La définition du CFM complet est divisée en parties et elle est couverte par les normes ASAAC suivantes :
- Propriétés mécaniques et interfaces physiques des CFM - Normes ASAAC pour le Packaging.
- Fonctions de communication des CFM - Normes ASAAC pour le Software.
- Interface réseau des CFM - Normes ASAAC pour la Communication et le réseau.
- Architecture logicielle des CFM - Normes ASAAC pour le Software.
- Exigences fonctionnelles des CFM - Présent document.

Aeronavtika - Modularne in odprte letalske elektronske arhitekture - 002. del: CFM

1.1 Splošno
Ta standard določa funkcionalnost in glavne vmesnike za splošni funkcionalni modul (CFM), da zagotovi medobratovanje splošnih funkcionalnih modulov in podaja smernice za načrtovanje kot pomoč pri implementaciji takih CFM. Je eden izmed niza standardov, ki določajo integriran modularni letalski sistem ASAAC (Svet za povezane standarde letalske arhitekture).
Ta definicija vmesnikov in funkcionalnosti dopušča načrt CFM, ki je interoperabilen z drugimi CFM v tem tehnološko preglednem standardu, odprt za trg z več dobavitelji in lahko kar najbolj izkoristi tehnologije COTS.
Čeprav naj bosta fizična organizacija in implementacija CFM izbiri proizvajalca v skladu z najboljšo uporabo trenutne tehnologije, je treba določiti strukturo za vsak CFM, da dosežemo logično definicijo CFM z določeno funkcionalnostjo. Ta definicija vključuje:
- splošni CFM, ki določa splošne funkcionalnosti, veljavne za celoten niz CFM. Splošna funkcionalnost je določena v 4.2,
- zmožnost obdelave, ki določa unikatno funkcionalnost, povezano z vsakim tipom CFM znotraj niza. Ta funkcionalnost je določena v 4.4,
- logične in fizične vmesnike, ki omogočajo, da so CFM interoperabilni in medsebojno izmenljivi; ti so določeni v točki 6,
- funkcionalnost, ki jo potrebuje CFM, da podpira delovanje sistema, je opredeljena v točki 6.
1.2 Razmerje z drugimi standardi ASAAC
Definicija celotnega CFM je razdeljena in zajeta v naslednjih standardih ASAAC:
- mehanske lastnosti in fizični vmesniki CFM – standardi ASAAC za pakiranje,
- komunikacijske funkcije CFM – standardi ASAAC za programsko opremo,
- omrežni vmesnik CFM – standardi ASAAC za komunikacije in omrežje,
- programska arhitektura CFM - standardi ASAAC za programsko opremo,
- funkcionalne zahteve CFM – ta dokument.

General Information

Status
Published
Publication Date
23-Oct-2011
Technical Committee
Current Stage
6060 - National Implementation/Publication (Adopted Project)
Start Date
14-Oct-2011
Due Date
19-Dec-2011
Completion Date
24-Oct-2011

Buy Standard

Standard
EN 4660-002:2011
English language
39 pages
sale 10% off
Preview
sale 10% off
Preview
e-Library read for
1 day

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 - 002. del: CFMLuft- und Raumfahrt - Modulare und offene Avionikarchitekturen - Teil 002: CFMSérie aérospatiale - Architectures Avioniques Modulaires et Ouvertes - Partie 002: CFMAerospace series - Modular and Open Avionics Architectures - Part 002: Common Functional Modules49.090On-board equipment and instrumentsICS:Ta slovenski standard je istoveten z:EN 4660-002:2011SIST EN 4660-002:2011en01-december-2011SIST EN 4660-002:2011SLOVENSKI
STANDARD



SIST EN 4660-002:2011



EUROPEAN STANDARD NORME EUROPÉENNE EUROPÄISCHE NORM
EN 4660-002
February 2011 ICS 49.090 English Version
Aerospace series - Modular and Open Avionics Architectures - Part 002: Common Functional Modules
Série aérospatiale - Architectures Avioniques Modulaires et Ouvertes - Partie 002: CFM
Luft- und Raumfahrt - Modulare und offene Avionikarchitekturen - Teil 002: CFM 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-002:2011: ESIST EN 4660-002:2011



EN 4660-002:2011 (E) 2 Contents Page Foreword .40Introduction .50.1Purpose .50.2Document structure .61Scope .61.1Relationship with other ASAAC Standards .62Normative references .73Terms, definitions and abbreviations .73.1Terms and definitions .73.2Abbreviations .83.3Conventions used in this Standard . 104CFM Definition . 104.1Generic CFM . 114.2Module Support Unit. 134.3Module Processing Capability . 204.4Network Interface Unit (NIU) and Routing Unit (RU) . 294.5Module Power Supply Element . 294.6Module Physical Interface (MPI . 315Common Functional Module Interfaces . 315.1Module Logical Interface (MLI) . 315.2Module Physical Interface (MPI) . 315.3MOS Interface . 326CFM System Support and Guidelines. 326.1Fault Management . 336.2Fault Detection . 336.3Fault Masking . 336.4Fault Confinement . 336.5Safety and Security. 34Annex A (informative)
Performance Sheet for all Common Functional Modules . 36A.1Data Processor Module . 36A.2Signal Processing Module . 37A.3Graphic Processing Module . 38A.4Mass Memory Module . 38A.5Network Support Module . 39A.6Power Conversion Module . 39 Figures Page Figure 1 — ASAAC Standard Documentation Hierarchy . 5 Figure 2 — Functional representation of a generic CFM . 11 Figure 3 — IMA Common Functional Modules – Graphical Composition . 21 Figure 4 — The Power Supply Distribution functions of the PCM . 26 Figure 5 — Power Supply Element functions . 30 Figure 6 — Software Architecture Model - Three Layer Stack . 32 SIST EN 4660-002:2011



EN 4660-002:2011 (E) 3
Tables
Page Table 1 — CFM Embedded Information – Read Only . 14 Table 2 — CFM Embedded Information – Read / Write . 15 Table 3 — PCM output characteristics . 27 Table 4 — PSE input voltage characteristics . 30 Table A-1 — Performance sheet for a DPM . 36 Table A-2 — Performance sheet for a SPM . 37 Table A-3 — Performance sheet for a GPM . 38 Table A-4 — Performance sheet for a MMM . 38 Table A-5 — Performance sheet for a NSM . 39 Table A-6 — Performance sheet for a PCM . 39
SIST EN 4660-002:2011



EN 4660-002:2011 (E) 4 Foreword This document (EN 4660-002: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.
SIST EN 4660-002:2011



EN 4660-002:2011 (E) 5 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: 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 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− System Management − 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 Documentation Hierarchy SIST EN 4660-002:2011



EN 4660-002:2011 (E) 6 0.2 Document structure The document contains the following clauses: Clause 1, scope of the document. Clause 2, normative references. Clause 3, the terms, definitions and abbreviations.
Clauses 4 and 5 provide CFM concept definition, requirements and standards. Clause 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 functionality 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 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.
Although the physical organisation and implementation of a CFM should remain the manufacturer’s 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 definition includes:  The Generic CFM, which defines the generic functionality applicable to the complete set of CFMs. The generic functionality is defined in 4.1.  The processing capability, which defines the unique functionality associated with each CFM type within the set. This functionality is defined in 4.3.  The logical and physical interfaces that enable CFMs to be interoperable and interchangeable, these are defined in Clause 6.  The functionality required by a CFM to support the operation of the System is defined in Clause 6. 1.1 Relationship with other ASAAC Standards The definition 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.  CFM Software architecture – ASAAC Standards for Software.  CFM Functional requirements – This document. SIST EN 4660-002:2011



EN 4660-002:2011 (E) 7 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. ISO 1540, Aerospace — Characteristics of aircraft electrical systems EN 4660-001, Aerospace series — Modular and Open Avionics Architectures — Part 001: Architecture 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 express 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 will be followed unless good reasons are stated for not doing so.
1) Published by: Allied Standard Avionics Architecture Council. SIST EN 4660-002:2011



EN 4660-002:2011 (E) 8  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 specified, 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 : 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 Current 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 : Hardware HDD : Head-Down Display HMD : Helmet Mounted Display HUD : Head-Up Display IBIT : Initiated BIT ID : Identification SIST EN 4660-002:2011



EN 4660-002:2011 (E) 9 IDL : Interface Definition Language IEEE : Institute of Electrical and Electronics Engineers IFFT : Inverse Fast Fourier Transformation IMA : Integrated Modular 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 : 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 / 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 SIST EN 4660-002:2011



EN 4660-002:2011 (E) 10 RTBP : Runtime Blueprints RU : 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 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 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 (CFMs) 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 Module (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 clause. It is assumed that a System Design Specification will be raised for each specific project implementation in which the detailed performance requirements for each CFM will appear. SIST EN 4660-002:2011



EN 4660-002:2011 (E) 11 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 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 Element 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 recording/reporting and support for MLI (Clause 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 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 Clause 5 and are fully defined in EN 4660-004.  The Routing Unit (RU) provides the internal communications capability of the CFM and interconnects the Network Interface Unit (NIU) with the Processing Unit (PU) and the Module Support Unit (MSU). The RU also provides a direct coupling between a network input link and a network output link. The RU is controlled by the MSU. SIST EN 4660-002:2011



EN 4660-002:2011 (E) 12  The Network Interface Unit (NIU) performs the external communications capability by interfacing the off-module network with the module internal data paths implemented by the Routing Unit. The NIU supports the implementation of the communication part and the Network properties part of the Module Logical Interface (MLI). These are defined in EN 4660-005 and EN 4660-003 respectively. It also supports network configuration in conjunction with the MSU.  The Power Supply Element (PSE) converts the external supply voltage into the appropriate internal supply voltages. Consolidation of redundant multiple power inputs shall also be provided by the PSE. The power supply architecture is defined in EN 4660-001. The CFM shall comprise hardware components, that implement the mechanical and electrical functionality and the physical interfaces of the CFM and software components collectively termed the “Module Support Layer” (MSL). The MSL provides, in conjunction with the hardware, the functional requirements and logical interfaces defined in the ASAAC Standards identified in 1.1. The interfaces for the CFM are as follows and are detailed in Clause 5:  The Module Physical Interface (MPI), which defines the physical properties of the CFM including the mechanical, optical, electrical and cooling interfaces.  The Module Logical Interface (MLI), which defines the logical communication and command interface of the CFM.  The interface between the Module Support Layer (MSL) and the Operating System, the MOS, which provides generic, technology independent access to the low-level resources of a CFM and the communications interface to the other CFMs. 4.1.2 Generic CFM – Requirements All CFMs designed to this standard shall meet the following requirements:  Have all set of functional elements as shown in Figure 2 for DPM, SPM, MMM and GPM. For PCM and NSM refer to Figure 3.  Provide open system (see for definition 3.1) compliant processing hardware,  Promote insertion and use of commercial and military standards and technologies, and the reuse of software.  Provide integrated diagnostics (built-in test) and fault isolation means to support fault tolerance, failure management, reconfiguration and maintenance.  Conform to the Module Physical Interface (MPI) definition (see EN 4660-002) and 4.6.
 Support at least one input and one output link to the network. The number of links will be dependent on the module type and system implementation.  Comply with the MOS interface definition and provide the required supporting software in the MSL. This software must also meet the requirements defined in EN 4660-005. The NSM is exempt from this requirement.  Provide the common communication services, within the MOS interface, to allow access to the network resources (see EN 4660-003).  Comply with the MLI definition. Note, that the NSM shall comply to the appropriate sub-set
(see EN 4660-005). SIST EN 4660-002:2011



EN 4660-002:2011 (E) 13  Be programmable in high-level languages.  Time synchronisation. Note that the NSM and MMM have additional time distribution capability.  Ensure internal communication bandwidth is compatible with external communication.
 Comply with the Power Supply Architecture specified in EN 4660-001.  Provide the second stage of the power supply architecture.  Be capable of operating in a fault tolerant configuration, i.e. it shall be possible to consolidate power supplies of a CFM (with the exception of the PCM) from two or more PCMs. 4.2 Module Support Unit This subclause covers the generic functionality provided by the MSU. 4.2.1 Module Support Unit – Description The module support functionality is to be provided by the logical element the MSU. The MSU controls and monitors all activities for a DPM, SPM, GPM and MMM. The MSU provides all functions and services required for system management, external and internal communications and module management. Guidelines for these functions are provided in EN 4660-005. In order to achieve the flexibility to control different types of modules a general-purpose processor called a Module Controller (MC) may be used. 4.2.2 Module Support Unit – Requirements The services and capabilities, which shall be provided by the MSU, are described in the following subclauses.
4.2.2.1 CFM Embedded Information Each CFM shall contain information regarding particular characteristics of the CFM itself. This information shall be located in non-volatile storage to ensure no loss of information caused by removal of power. The information to be stored shall be distinguished as follows:
 Read-Only is information that, after definition and programming,
cannot be altered during operational use. The original manufacturer shall be the only one who is capable of programming or modifying these data. This constitutes data such as the manufacturers identity, CFM type, production batch number etc. that reflect the identity of the CFM. The required retrievable information are listed in Table 1.  Read/Write is information that can be updated whenever the module is operational. This constitutes data such as the hours of operation, executed maintenance activities, operational log, etc. that reflect the operational history of the CFM. The required information that shall be available is listed in Table 2. Fault Logging is considered separately in 4.2.2.3. The information with read-only access shall be accessible using the following methods:  By interrogation of the Maintenance Test Port, a function covered in detail in 4.2.2.6.  By use of the MOS services, defined in EN 4660-005. SIST EN 4660-002:2011



EN 4660-002:2011 (E) 14 Table 1 — CFM Embedded Information – Read Only Name Definition Type Length in Bytes Scope Accessed Via manufacturer_id Manufacturer's ID String 30 Global moduleInfo/MTP serial_id Serial ID unsigned Short
Specific to a single manufacturer moduleInfo/MTP prod_batch_ date Date of production (week: 2 year: 4) String 6 N/A MTP cfm_type Standard type of CFM (SPM, DPM, GPM, MMM, NSM, PCM) String 10 Global moduleInfo/MTP hw_version Version of hardware unsigned Short
Specific to a single manufacturer MTP msl_version Version of MSL code stored on-CFM unsigned Short
Specific to a single manufacturer MTP standard_mpi_ version_ compliance Version of the MPI standard that the CFM is compatible with unsigned Short
Global MTP standard_mos_version_ compliance Version of the MOS standard that the CFM is compatible with unsigned Short
Global moduleInfo/MTP standard_mli_ version_ compliance Version of the MLI standard that the CFM is compatible with unsigned Short
Global moduleInfo/MTP num_network Number of different network interfaces on the CFM unsigned Short
Specific to CFM moduleInfo/MTP num_pe Number of PEs resident on the CFM unsigned Short
Specific to CFM moduleInfo/MTP For each Network interface resident on the CFM network_if_id Network interface ID unsigned Short
Specific to CFM moduleInfo/MTP network_if_type Type of network interface (variable scope shall be across all possible network interface types) String 10 Global moduleInfo/MTP For each PE resident on the CFM pe_id PE ID unsigned Short
Specific to CFM moduleInfo/MTP pe_type Type of PE (variable scope shall be across all possible PE types) String 10 Global moduleInfo/MTP pe_performance Standardised performance available from PE in MOPS unsigned Long
Specific to PE moduleInfo/MTP pe_nonvol_ memory Amount of available non-volatile memory within each PE in Mbytes unsigned Long
Specific to PE moduleInfo/MTP pe_vol_memory Amount of available volatile memory within ea
...

Questions, Comments and Discussion

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