SIST EN 4660-002:2011
(Main)Aerospace series - Modular and Open Avionics Architectures - Part 002: Common Functional Modules
Aerospace series - Modular and Open Avionics Architectures - Part 002: Common Functional Modules
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.
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
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
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
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
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
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
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
— 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
: 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
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
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
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
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
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
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 each PE in Mbytes unsigned Long
Specific to PE moduleInfo/MTP pe_num_timer Number of Timers within the PE unsigned Short
Specific to PE moduleInfo/MTP For each Timer within each PE resident on the CFM pe_timer_id Timer ID unsigned Short
Specific to PE moduleInfo/MTP pe_timer_ resolution Resolution of the timer in nanoseconds unsigned Short
Specific to PE Timer ModuleInfo/MTP SIST EN 4660-002:2011
moduleStatus/ MTP: read only maintenance_log Log describing the maintenance history of the CFM. A log entry needs to include:
Up to 256 bytes per entry readLogDevice: read onlyMTP: read/write
• Time-stamp (op hours) • Maintainer identity • Maintenance action identity unsigned LongString String
30 222
system_log Log describing the usage history of the CFM. A log entry needs to include:
32 bytes per entry readLogDevice/ MTP: read onlywriteLogDevice: write only
• Time-stamp (op hours) • Relevant system identity unsigned LongString
cfm_status Present status of the CFM; OK, Fail, PBIT in progress, IBIT in progress etc. String 10 moduleStatus/ MTP: read only
4.2.2.2 Built-in Test Capability (BIT) Each CFM shall provide hardware and software resources to provide a level of fault detection within its own resources according to the following three BIT capabilities: Power-up/Power-down BIT (PBIT) - Performs built-in test subsequent to module power-up. PBIT shall verify that the resources available on the CFM are fully operational before operational code is downloaded. Details on the initialisation are given in 4.2.4. Continuous BIT (CBIT) - CBIT shall be performed as a background activity during normal operation of the CFM. Initiated BIT (IBIT) - IBIT shall be performed when initiated by another entity. After initiation of IBIT the normal operation of the CFM shall be interrupted and IBIT performed. After IBIT has terminated the CFM shall return to normal operation.
All BIT results, with the exception of a CBIT pass result, shall be reported to the Fault Log. The requirements for fault logging are given in 4.2.2.3.
4.2.2.3 Fault Logging Each CFM shall provide a Fault Log implemented in non-volatile storage. Each entry in the Fault Log shall be time stamped. The Fault Log shall be accessible for off-aircraft test and maintenance via the Maintenance Test Port (MTP), which is detailed in 4.2.2.6.
Details on fault management are given in ASAAC guidelines for Fault Management, refer to ASAAC2-GUI-32450-001-CPG Issue 01 (Volume 2).
NOTE The fault log should be readable without the rest of the module being powered. Therefore the test connector should provide power inputs directly to the memory hardware that is used to implement the log.
4.2.2.5 Hours of Operation Each CFM shall provide a non-volatile counter for time of operation. This counter shall maintain hours and minutes and shall have a range of at least 100 000 hours. The hours of operation shall be accessible for purpose of test and maintenance via the Maintenance Test Port, as given in 4.2.2.6. The format of hours of operation is given in Table 2.
4.2.2.6 Maintenance Test Port (MTP) Each CFM shall provide maintenance test port that allows access to internal resources for Inegrated Test and Maintenance (ITM) purpose. An interface compatible with IEEE P1149.1 (JTAG) may be used as a standard means of access.
As a minimum the following operations on the internal resources of the CFM shall be possible: Read Fault Log, Erase Fault Log. Read hours of operation. Activate PBIT, read PBIT results. Activate IBIT, read IBIT results. Download updated MSL software. Access of on-module facilities for CFM debugging and monitoring. The MTP shall not be part of the MPI but shall only give access after opening the cover of a CFM. SIST EN 4660-002:2011
The following Interfaces shall be supported by the MSL: Module Support Layer to Operating System Interface (MOS), refer to EN 4660-005. Module Logical Interface (MLI), refer to Clause 5. Maintenance Test Port Interface, refer to 4.2.2.6. The MSL comprises two parts: the Module Initialisation Support (MIS) and the full Module Support. Layer. The MIS provides the minimum set of MSL functions required to Boot the module and is defined in 4.2.4.
The following functionality shall be provided by the MSL: The MSL shall provide CFM resource information. The MSL shall provide memory management services - e.g. services for partitioning, protection, memory locking, logical to physical translation. The MSL shall provide interrupt handling services that supports connection, masking, polling and acknowledgement of interrupts. The MSL shall provide HW exception management services that provides the access to exception table(s). The MSL shall provide BIT management services - e.g. test activation and access to module resource states. The MSL shall provide status reporting, a service that provides the status of the module (go/no go, failure description, etc.). The MSL shall provide HW timer and clock management services - e.g. calendar, alarm and tick based on global time. The MSL shall provide low level physical interface drivers - e.g. low level services for Send/Receive of streams of un-typed information and control of physical devices. The MSL shall support the MOS communication services as defined in EN 4660-005. The MSL shall provide module control services. These shall include cold start-up, inhibition and reset. The MSL shall provide debugging services - e.g. low level debugging services (SW loading, memory and register access, single stepping, SW breakpoint, performance measurement, resource monitoring). The MSL shall provide fault management support - e.g. Fault Log access, watchdog timers. 4.2.4 Module Initialisation Each CFM shall have a boot process that performs the CFM type specific functions for module start up and an initialisation process. From the system point of view two states can characterise a CFM: CFM Booted state. CFM Initialised state. SIST EN 4660-002:2011
On reaching the booted state the CFM shall be able to reply to Module Logical Interface (MLI) requests
(see EN 4660-005). The CFM shall provide a single default TC to enable this communication. Then it shall be able to process the MLI commands required for ending the CFM Booting sequence.
The MIS may be either the necessary sub-set of the MSL functionalities or a complete MSL. ´ When the MIS is a complete MSL it shall be ready to download an OS whose technology is compliant with the present MSL. Otherwise an MSL, which is compliant to the expected OS, shall be downloaded first to run on top of or overwrite the MIS.
When the MIS is a sub-set of the MSL it shall be able to download an image containing a complete MSL to run on top of or overwrite the MIS.
It shall be noticed that an image may contain either only the MSL or the MSL and additionally other components such as OS, GSM or RTBP. Once the MSL is set up and running the CFM is in a state where it may download the components such as OS, GSM or RTBP. The boot sequence is now complete. The MMM shall boot in standalone by its own. Therefore, the MIS within a MMM shall be particular and different from the others. It shall be able to bring autonomously the MMM from a booted state to a state where the full ASAAC software stack (see EN 4660-005) is set up and running. Additionally it shall provide Maintenance Test Port Interface services as described in 4.2.2.6. 4.2.4.2 MIS Interfaces and Requirements The functionalities below are the minimal functionalities required for booting all CFMs.
The MIS shall provide the following functionalities as a minimum and as a subset of the MSL. These MIS functions are those MSL functions required by the MLI and MTP interfaces. These services are defined in EN 4660-005. The minimal functionalities, as a sub-set of the MSL, required within the MIS are those needed by the MLI and MTP interfaces. These are:
Load image. PBIT result. CFM Status. SIST EN 4660-002:2011
Load Time Configuration; NSM and PCM only whether they shall host only the MSL. The Maintenance and Test Port Interface services defined in 4.2.2.6. 4.2.4.3 Module Boot Requirements The CFM Boot process is defined specifically for the following module types:
Power Conversion Module (PCM). Network Support Module (NSM). Processing modules:
Data Processing Module (DPM). Signal Processing Module (SPM).
Graphic Processing Module (GPM).
Mass Memory Module (MMM). 4.2.4.3.1 Power Conversion Module (PCM) The PCM shall provide a boot procedure as follows: After power is applied to a PCM, PCM PBIT shall be activated automatically by the PCM. All PBIT results shall be collected and any failure logged in the Fault Log. If the PCM passes PBIT without any failures, the PCM shall apply power to the two pre-defined outputs. The PCM shall then wait for further commands. If PBIT detects any failures, the PCM shall fail silent and shall not apply power to any of its outputs. Details of the system and fault management of an ASAAC system are fully specified in ASAAC2-GUI-32450-001-CPG Issue 01 (Volume 2). 4.2.4.3.2 Network Support Module (NSM) The NSM shall follow the CFM Boot procedure as follows. It shall only apply the “NSM only” MIS services: After power is applied to the NSM, NSM PBIT shall be activated automatically by the NSM. All PBIT results shall be collected and any failure logged to the Fault Log. If the NSM passes PBIT without any failures, the NSM shall configure automatically to the default configuration. The NSM shall then wait for further commands. SIST EN 4660-002: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...