3.2 Abbreviations 2D : Two Dimensional 3D : Three Dimensional A3 : Advanced Avionics Architecture AGT : Absolute Global Time ALT : Absolute Local Time APOS : Application to Operat
Purpose
This document was produced under the ASAAC Phase II Contract
The ASAAC Programme aims to establish and validate open architecture standards, concepts, and guidelines for Advanced Avionics Architectures (A3) to address its three primary drivers These standards and guidelines are designed for application in both new aircraft and upgrade programs.
The three main drivers for the ASAAC Programme are:
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)
Standards for Common Functional Modules
Figure 1 — ASAAC Standard Documentation Hierarchy
Document structure
The document contains the following clauses:
Clause 1, scope of the document
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
Attached at the end of the document are performance sheets for each CFM, which include a list of attributes that the system designer must define and that will be utilized by the CFM provider.
This standard outlines the functionality and key interfaces for the Common Functional Module (CFM), ensuring interoperability among these modules It also offers design guidelines to aid in the implementation of a CFM This standard is part of a series that defines the Integrated Modular Avionics System under the Allied Standard Avionics Architecture Council (ASAAC).
The definition of interfaces and functionality enables a CFM design that is interoperable with all other CFMs adhering to this standard It promotes technology transparency, supports a multi-vendor market, and optimizes the use of Commercial Off-The-Shelf (COTS) technologies.
The physical organization and implementation of a CFM should be determined by the manufacturer, utilizing the latest technology However, it is essential to establish a structured framework for each CFM to ensure a clear definition and specific functionality.
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.
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
The referenced documents are essential for applying this document For dated references, only the specified edition is applicable, while for undated references, the most recent edition, including any amendments, is relevant.
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:
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)
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 term "SHOULD" in the text indicates a recommendation or advice regarding the implementation of a standard requirement It is anticipated that these recommendations will be adhered to unless valid reasons are provided for non-compliance.
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.
Abbreviations
APOS : Application to Operating System Interface
ASAAC : Allied Standard Avionics Architecture Council
CORBA : Common Object Request Broker Architecture
COTS : Commercial Off The Shelf
CRC : Cyclic Redundancy Check dc : Direct Current
EDAC : Error Detection And Correction
FIR : Finite Impulse response Filter
FMECA : Fault Mode Effect and Criticality Analysis
IEEE : Institute of Electrical and Electronics Engineers
IFFT : Inverse Fast Fourier Transformation
ITM : Integrated Test and Maintenance
JTAG : Joint Test Action Group
MOS : Module Support Layer to Operating System Interface
PBIT : Power-up / power-down BIT
Conventions used in this Standard
The Interface Definition Language (IDL), as outlined in the Common Object Request Broker Architecture (CORBA) 2.3, is utilized in this document to represent MOS services as programming language-independent services.
The conventions used in this document are as follows:
In programming documentation, words with special significance are typically displayed in distinct fonts or styles Specifically, all code listings, reserved keywords, and the names of data structures, constants, and routines are presented in Courier font.
Parameter and variable names contain only words with lower case letters, which are separated by underscore
NOTE Upper and lower case letters are treated as the same letter
Common Functional Modules (CFMs) are line replaceable items that equip the ASAAC IMA system with essential computational, network support, and power conversion capabilities A specific set of modules has been established for integration within the IMA core processing system.
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.
Generic CFM
The internal architecture of each CFM includes a collection of functional elements specific to its implementation, as illustrated in Figure 2 All functions, except for the Processing Unit, are standardized across all CFM types.
Figure 2 — Functional representation of a generic CFM
(For PCM and NSM refer to Figure 3)
The Module Support Unit (MSU) is responsible for controlling and monitoring the module, offering essential functions such as Built-in-Test (BIT) control, module initialization, time management, status recording and reporting, as well as 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) outlines the physical attributes of the module, encompassing mechanical, optical, electrical, and cooling interfaces These specifications are elaborated in Clause 5 and are comprehensively defined in EN 4660-004.
The Routing Unit (RU) is essential for internal communications within the CFM, linking the Network Interface Unit (NIU) to both the Processing Unit (PU) and the Module Support Unit (MSU) Additionally, the RU facilitates a direct connection between network input and output links, with its operations managed by the MSU.
The Network Interface Unit (NIU) facilitates external communications by connecting the off-module network to the internal data paths managed by the Routing Unit It plays a crucial role in implementing both the communication and network properties aspects of the Module Logical Interface (MLI), as outlined in EN 4660-005 and EN 4660-003 Additionally, the NIU collaborates with the MSU to support network configuration.
The Power Supply Element (PSE) is responsible for converting external supply voltage into suitable internal supply voltages while also consolidating redundant multiple power inputs The power supply architecture is outlined in the EN 4660-001 standard.
The CFM consists of hardware components that deliver mechanical and electrical functionality, along with physical interfaces, and software components known as the "Module Support Layer" (MSL) Together, the MSL and hardware fulfill the functional requirements and logical interfaces outlined in the ASAAC Standards referenced in section 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 Module Support Layer (MSL) interfaces with the Operating System (MOS) to offer a generic and technology-independent access point to the low-level resources of a CFM, as well as facilitating communication with other CFMs.
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
To ensure compliance with the MOS interface definition, it is essential to provide the necessary supporting software in the MSL, which must also adhere to the standards outlined in EN 4660-005 However, the NSM is not subject to 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)
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.
Module Support Unit
This subclause covers the generic functionality provided by the MSU
The module support functionality is managed by the MSU, which oversees all activities for DPM, SPM, GPM, and MMM It delivers essential functions for system management, as well as internal and external communications Detailed guidelines for these operations are outlined in EN 4660-005 To enhance flexibility in controlling various module types, a general-purpose processor known as the Module Controller (MC) can be utilized.
The services and capabilities, which shall be provided by the MSU, are described in the following subclauses
Each CFM must include specific details about its characteristics, which should be stored in non-volatile memory to prevent data loss during power outages.
The information to be stored shall be distinguished as follows:
Read-Only information refers to data that cannot be changed during operational use once it has been defined and programmed Only the original manufacturer has the authority to program or modify this data, which includes critical details such as the manufacturer's identity, CFM type, and production batch number Essential retrievable information is outlined in Table 1.
The Read/Write feature allows for the updating of information while the module is operational, including data on hours of operation, maintenance activities, and operational logs that document the CFM's history Essential information is detailed in Table 2, while Fault Logging is addressed in section 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
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
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
MTP msl_version Version of MSL code stored on-
MTP standard_mpi_ version_ compliance
Version of the MPI standard that the CFM is compatible with unsigned Short
Global MTP standard_mos_ver sion_ 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
Specific to CFM moduleInfo/MTP
For each Network interface resident on the CFM network_if_id Network interface ID unsigned
Specific to CFM moduleInfo/MTP network_if_type Type of network interface
(variable scope shall be across all possible network interface types)
For each PE resident on the CFM pe_id PE ID unsigned
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
Specific to PE moduleInfo/MTP
For each Timer within each PE resident on the CFM pe_timer_id Timer ID unsigned
Specific to PE moduleInfo/MTP pe_timer_ resolution
Resolution of the timer in nanoseconds unsigned Short
Table 2 — CFM Embedded Information – Read / Write
In Bytes Accessed via operational_ hours
Number of operational hours for the CFM (resolution = 1 minute) unsigned Long 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 only MTP: read/write
• Maintenance action identity unsigned Long String String
222 system_log Log describing the usage history of the CFM
A log entry needs to include:
MTP: read only writeLogDevice: write only
• Relevant system identity unsigned Long
String 28 cfm_status Present status of the CFM; OK, Fail, PBIT in progress, IBIT in progress etc
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:
The Power-up/Power-down BIT (PBIT) conducts a built-in test after the module is powered up, ensuring that all resources on the CFM are fully operational prior to the downloading of operational code Further details regarding the initialization process can be found in section 4.2.4.
Continuous BIT (CBIT) - CBIT shall be performed as a background activity during normal operation of the CFM
Initiated BIT (IBIT) occurs when prompted by another entity, leading to a temporary interruption of the normal operation of the CFM Once IBIT is completed, the CFM resumes its standard operations.
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
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)
The fault log must remain accessible even when the rest of the module is unpowered Consequently, the test connector should supply power directly to the memory hardware responsible for maintaining the log.
The CFM will supply timers to support the System Time Management function, which can be synchronized with an external source through network messages.
The universal time of day, recognized both in and out of the aircraft, is expressed in year, month, day, hour, minute, and second, with optional fractional seconds The System Design Specification must outline the required resolution and accuracy, with a minimum resolution set at 1 millisecond.
The aircraft's local time reference will offer higher resolution than absolute global time, with absolute local time utilized for application synchronization and scheduling The required resolution for the Absolute Local Time (ALT) is in the range of tens of microseconds, while its accuracy should be within tens of nanoseconds The System Design Specification will detail the exact resolution and accuracy requirements.
Relative local time (RLT) offers a higher resolution than other time references, enabling precise synchronization of closely linked computing processes It is essential for RLT to maintain a resolution of less than a specified threshold to ensure effective coordination.
1 microsecond The precise resolution and accuracy for the RLT shall be specified by the System Design Specification
The ASAAC time management concept is specified in ASAAC Standards for System and Fault Management ASAAC2-GUI-32450-001-CPG Issue 01 (Volume 2)
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 for testing and maintenance can be accessed through the Maintenance Test Port, as outlined in section 4.2.2.6 For detailed information, please refer to the format provided in Table 2.
Each CFM must include a maintenance test port to facilitate access to internal resources for Integrated Test and Maintenance (ITM) purposes A standard interface compatible with IEEE P1149.1 (JTAG) can be utilized for this access.
As a minimum the following operations on the internal resources of the CFM shall be possible:
Read Fault Log, Erase Fault Log
Activate PBIT, read PBIT results
Activate IBIT, read IBIT results
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
Each CFM will consist of a collection of software components known as the MSL, which are essential for supporting and executing the logical interfaces and functions needed by both the MSU and the CFM.
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 consists of two components: the Module Initialisation Support (MIS) and the complete Module Support Layer The MIS offers the essential MSL functions necessary for booting the module, as outlined in section 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
Module Processing Capability
The module processing capability is defined by the logical element known as the Processing Unit (PU), which distinguishes each type of CFM The PU is responsible for delivering specific functions tailored to the module.
The Processing Unit of a CFM consists of multiple Processing Elements (PE1 to PE n), which are distinct and independently functioning processing resources Each Processing Element is equipped with a software stack that complies with ASAAC standards as outlined in EN 4660-005.
The following subclauses describe the CFM type specific functionality that shall be expected from each CFM type implementation Figure 3 shows the graphical representation of the CFM types considered
The Network Support Module (NSM) is an exception to the standard definition of processing capability, as it primarily serves as a component of the communications network rather than a processing resource Despite containing the generic CFM functionality and the Module Physical Interface, it is included in the subsequent subclause to ensure continuity in the CFM definition.
Power Supply Element Network Interface Unit Module Physical Interface
Power Supply Element Network Interface Unit Module Physical Interface
GP Ele me nt n Frame Store (opt)
(a) Data Processing Module (b) Signal Processing Module
(c) Graphic Processing Module (d) Mass Memory Module
(e) Network Support Module (f) Power Conversion Module
Network Interface Unit Routing Unit
Module Physical Interface Power Switch Array
Figure 3 — IMA Common Functional Modules – Graphical Composition
The DPM in architecture is designed to support general-purpose processing across a variety of avionics applications It ensures consistent throughput efficiency while managing diverse data types and formats, including bits, words, structured, fixed, and floating data Additionally, it performs various processing types, such as logical and algorithmic operations, primarily using High Order Level languages The internal functional organization of the DPM is illustrated in Figure 3a.
The DPM shall adhere to the generic CFM requirements
In addition the DPM shall provide the following capabilities:
Memory management, to provide code and data segregation
The System Design Specification shall define the DPM specific implementation of the CFM generic requirements and in addition the DPM capabilities listed above
For each implementation of a DPM the parameters set out in Annex A.1 shall be provided
The SPM architecture is designed to enhance signal processing capabilities for avionics applications by utilizing multiple interconnected Digital Signal Processors (DSPs) This approach ensures that signal processing algorithms are executed efficiently while maintaining a clear separation from data processing functions, such as module control and status monitoring.
The SPM shall support the following three types of signal processing:
General or Heterogeneous Signal Processing
Figure 3b shows the functional organisation of a SPM
The SPM shall adhere to the generic CFM requirements
In addition the SPM shall provide the following capabilities:
Memory management to provide code and data segregation
The number of communication links
FIR filtering, correlation and convolution
The System Design Specification shall define the SPM specific implementation of the CFM generic requirements and in addition the SPM capabilities listed above
For each implementation of a SPM the parameters set out in A.2 shall be provided
The GPM is responsible for graphics processing, enabling 2D and 3D graphics generation and manipulation for avionics display applications, utilizing specialized graphics processors.
Generation of display pixel data
Receive and manipulate sensor/stored images in a variety of formats and co-ordinate schemes
Overlay/composite received images with internally generated pixel data
Output the display image in an appropriate format for transfer to displays via the network
Support different output formats (e.g for HDD, HUD or HMD)
Allow composition of larger images, distributed across multiple GPM
The PEs shall receive high-level commands in accordance with the Graphics Tag Language (See Annex A of
Figure 3c shows the functional organisation of a GPM
The GPM shall adhere to the generic CFM requirements
In addition the GPM shall provide the following capabilities
To receive images across the network
To support a variety of formats and co-ordinate schemes
Be able to perform transformations on the received images including scaling, translations and rotations
To overlay the internally and externally generated images
To format pixel data destined for the display surfaces
To support various display resolutions, frame update rates and bits-per-pixel
To be capable of generating 2D and 3D images and enable 3D projection
To be capable of Modelling functions - e.g a translation, rotation, and scaling
To provide a Translucency function (8 bits for alpha value)
To provide multiple clipping planes
To provide perspective texture mapping
To provide an anti-aliasing function
To provide a function that removes hidden surfaces
For each implementation of a GPM the parameters set out in A.3 shall be provided
The MMM in architecture serves to offer essential mass storage capabilities, facilitate file and database operations, and ensure effective time distribution This mass storage is crucial for housing the Operating System, Application Software, function libraries, and databases, which can be downloaded into other CFMs.
The MMM should also be required to accommodate different data type retention requirements The different data retention categories are:
Long term retention duration (e.g several months), for example software or terrain data
Medium term retention (e.g days), for example maintenance data
Short term retention (e.g seconds) for example storage of context data used for warm-start
The management of both volatile and non-volatile memory space, which is physically distinct from the module, enables the installation of removable data cartridges while maintaining oversight under a unified Mass Memory Manager.
The Mass Memory Module should support the following data types:
Secure data and non-secure data
Safety-critical and non-safety critical data
The access rights to the MMM contents may be read, write and erase
Error detection and correction, which can be implemented either by software or by hardware, may operate continuously, cyclically or upon initiation
The MMM should also be capable of supporting multiple data confidentiality levels and their inherent constraints
The Mass Memory Module (MMM) must include a "Quick-Erase" feature, which allows for the rapid deletion of a substantial portion of its storage space during emergencies This process ensures that the erased data cannot be recovered later.
Figure 3d shows the functional organisation of a MMM
The MMM shall adhere to the generic CFM requirements
In addition the MMM shall provide the following capabilities:
Mass storage capability (volatile and non-volatile) for other modules
Memory management to provide code and data segregation, segmentation capability and the virtual address space
Management of a partition of its memory space (volatile and non-volatile) which is physically separated from the module itself in order to allow the installation of removable data cartridge(s)
Support for multiple data confidentiality levels
Process several requests for reading and writing memory spaces or files concurrently,
Service simultaneous multiple access requests from multiple modules
For each implementation of a MMM the parameters set out in A.4 shall be provided
The Power Conversion Module (PCM) plays a crucial role in the initial stage of power conversion within the "two-stage power supply architecture" as outlined in EN 4660-001 It transforms the aircraft's supply into a suitable internal DC voltage for distribution to various CFMs within a rack Additionally, the PCM is equipped with processing capabilities and power management applications, enabling it to effectively control and monitor the power levels for each output connected to the CFMs.
The functional elements of the Power Conversion Module (PCM) that relate to the Power Supply Distribution Architecture are illustrated in Figure 4 and are as follows:
Power Conversion Unit (PCU): This unit converts the 270 Vdc input voltage(s) down to the 48 Vdc backplane voltage The PCU consolidates the emergency voltage input (the battery supply)
The Power Management System (PMS) is essential for managing the power ON and OFF sequences of avionics systems It includes hardware that facilitates communication with the system to oversee power distribution within the rack and identify any faults Additionally, the PMS regulates the Power Switch Array (PSA) based on system data to ensure the appropriate CFMs are powered.
The Power Switch Array (PSA) is an integral component managed by the power management system, responsible for switching and monitoring multiple outputs to the other CFMs in the rack It offers both standard switched outputs and safety-critical switched outputs, ensuring reliable operation and safety.
PCM Logic supplies DC/DC conversion (Maintained supply rail)
Protection and current sensing O/P filter
Safety Critical Outputs Standard Outputs
Figure 4 — The Power Supply Distribution functions of the PCM
The PCM shall adhere to the generic CFM requirements
In addition the PCM shall provide the following capabilities:
Comply with the Power Supply Architecture specified in EN 4660-001
Provide the first stage of the power supply architecture
Provide the Power Management System
Provide the Power Switch Array
Provide both safety critical and non safety critical switched outputs Note: Safety critical outputs shall be supplied from the aircraft’s emergency power supply
The PCM shall fulfil the requirements specified in EN 4660-001
The PCM shall have the following input and output characteristics:
Table 3 — PCM output characteristics Parameter Value
Input Voltage 1 Platform emergency voltage
Input Voltage 1 characteristics See ISO 1540, see EN 4660-001
Input Voltage 2 characteristics See ISO 1540
Input Voltage 3 characteristics See ISO 1540
Output Voltages characteristics 46 to 50 Vdc
Output Voltages for Emergency Platform battery voltage
Number of Emergency voltage outputs At least 5
Filtering High frequency (> 30 MHz) filtered supply
For each implementation of a PCM the parameters set out in Annex A.6 shall be provided
The NSM facilitates routing and configures network connections, thereby reducing backplane complexity This design allows for easier access to active switch components within the network fabric, simplifying maintenance Notably, the NSM does not include a processing unit.
The NSM will perform two main functions:
Connection to the network or networks and when necessary the configuration of network paths and switching capabilities for switched networks
The maintenance of a Master Reference Clock to support the distribution of time throughout the system
The NSM is regarded as an ideal site for the Master Reference Clock, as it is anticipated that many systems will incorporate one or more NSMs However, alternative options for the Master Reference Clock, such as those provided by MMM, are also possible.
The internal logical structure of the NSM, in compliance with the selected network baseline, will consist of the following building blocks as illustrated in Figure 3e
The Module Physical Interface (MPI) as defined in 4.6
The Power Supply Element as defined in 4.5
The Communication Control Unit is responsible for managing the communication unit and distributing ALT, supported by a Master Reference Clock that ensures accurate time distribution across the system It monitors functions on the NSM, reporting any faults to the system management software Additionally, it establishes necessary connections for a default communications network during power-up and adjusts the switch configuration as needed.
Each Communication Unit will provide reconfigurable interconnection for its network interfaces
The Communication Network Interface Unit will provide an interface to the network connections in the rack backplane
The NSM is not required to adhere completely to the generic CFM concept but shall implement the following subset of the generic functionality:
In addition the NSM shall provide the following capabilities:
Support functions, including switching and routing capabilities as required by EN 4660-003
Maintain a default communication configuration that can be adopted on power-up
Provide non-blocking facilities for the routing and reconfiguration of the ASAAC network.
Network Interface Unit (NIU) and Routing Unit (RU)
The NIU and RU facilitate all communications within the CFM and connect to the external network under the MSU's control, enabling intercommunication among all PEs in a modular system Each CFM module's NIU and RU support various types of communication.
Intra-Module Communication: Allowing communication between PEs inside the module
Between-Module Communication: Allowing communication between modules
Intra-PE Communication: Allowing communication between processors inside a PE
To enable interoperability between CFMs of a different type or between different implementations of the same CFM type, the Module Logical Interface (MLI) is defined, see Clause 5
The NIU and RU functions shall support the required number of ASAAC Network interfaces as defined for each module type in 4.3
The NIU and RU shall support Intra-Module, Between-Modules and Intra-PE communications
The NIU and RU shall provide an interface to the Operating System (at the MOS level) compliant with the MOS Communication Services defined in EN 4660-005.
Module Power Supply Element
4.5.1 Module Power Supply Element Description
To effectively power the hardware of a CFM, it must accept a standardized DC voltage from the backplane and convert it to the specific power levels needed for the module This function is facilitated by a physical Power Supply Element.
The functions of the Power Supply Element (PSE) are described in Figure 5
Figure 5 — Power Supply Element functions
The dc to dc conversion of the CFM supplied voltages down to the required component voltage(s): there is no limitation on the number of the PSE outputs
The consolidation of supplied voltages coming from different PCMs during normal operation For fault tolerance reasons, at least two PCMs are supplying each CFM
The Power Supply Element within a CFM shall accept the following input voltage characteristics:
Table 4 — PSE input voltage characteristics Parameter Value
Input Voltage 1 characteristics 36 to 75 Vdc
Input Voltage 2 characteristics 36 to 75 Vdc
Input voltage consolidation Load sharing between input voltages 1 and 2
dc to dc conversion down to component voltages
Module Physical Interface (MPI
The MPI is those parts of the module that provide the common physical interfaces for the module and that adhere to the Module Physical Interface definition, see 4.6.2
All ASAAC Common Functional Modules shall adhere to the MPI, which is specified in EN 4660-004
This clause outlines the logical and physical interfaces that establish the interoperability requirements for the Common Functional Module For a comprehensive definition of these interfaces, please refer to the ASAAC Standards listed below.
Module Logical Interface (MLI)
To enable interoperability between CFMs of a different type or between different implementations of the same CFM type, the Module Logical Interface (MLI) is defined This comprises two parts:
The Module Logical Interface (MLI) for Network Properties defines the network medium, format, protocol, control, and communication characteristics between Network Interface Units (NIUs) across different Configuration Management Frameworks (CFMs) This specification is outlined in EN 4660-003.
The Module Logical Interface for Communications specifies the data presentation and Virtual Channel communication format between the Communication Manager instances and the MOS communication services, both operating above the NIU This logical communication framework facilitates efficient data exchange and interaction.
This is defined in EN 4660-005
All CFM must adhere to the MLI specifications for communication services outlined in EN 4660-005, as well as comply with the MLI specifications for network properties defined in EN 4660-003.
Module Physical Interface (MPI)
The MPI defines the principle interfaces: Cooling, connector and insertion extraction device, for more details refer to EN 4660-004
All ASAAC Common Functional modules shall adhere to the MPI, which is specified in EN 4660-004.
MOS Interface
The Module Support Layer to Operating System Layer (MOS) interface establishes a crucial set of services that ensure hardware independence for the operating system This interface enables the operating system software to access resources located on a CFM, which are managed by the Module Support Layer (MSL) software As outlined in EN 4660-005, the MOS interface is a fundamental component of the three-layer architectural model, as depicted in Figure 6.
Figure 6 — Software Architecture Model - Three Layer Stack 5.3.2 MOS Interface – Requirement
The Data Processing Module (DPM), Signal Processing Module (SPM), Graphics Processing Module (GPM), Mass Memory Module (MMM), and Power Conversion Module (PCM) will feature a MOS interface that meets the Operating System requirements outlined in EN 4660-005 It is important to note that the NSM is not required to have a MOS interface, as specified in section 4.1.2.
6 CFM System Support and Guidelines
This clause provides guidelines when implementing system functionality in a CFM To support the implementation of CFMs compliant with the Standards and Systems Issues These will cover:
Fault Management
The Fault Management section of the Final Draft Guidelines for System and Fault Management (ASAAC2-GUI-32450-001-CPG Issue 01, Volume 2) outlines the details of the System and Fault Management for an ASAAC system.
Fault Detection
The module must incorporate Power-On Built-In Test (PBIT) techniques to identify faults during power-up Any faults detected by PBIT should be recorded in the Fault Log for future analysis and ITM purposes, as outlined in section 4.2.2.3.
NOTE During operational mode CBIT and IBIT faults may be logged by the fault manager, which runs above the MOS
This guideline does not aim to provide an exhaustive list of fault detection techniques; for comprehensive details, refer to ASAAC2-GUI-32450-001-CPG Issue 01 (Volume 2) Below are the general requirements for effective fault detection.
To ensure high availability of on-module resources, it is essential that individual hardware components, including processing elements, network interfaces, and module controllers, can conduct Built-In Tests (BIT) independently This modular testing approach allows for maintenance without disrupting the overall functionality of the module.
Data checks should be implemented across all communication channels, both on and off the module It is strongly advised that the system includes built-in error correction capabilities.
To enhance system efficiency, the module must monitor key performance aspects, including processing and communication Processors should implement a performance task to track task usage, while communication channel interfaces need to maintain a packet throughput register Utilizing accurate time data is essential for effective performance measurement.
Fault Masking
To enhance system availability and protect against minor failures that could disrupt operations, the module should strive to mask any detected faults whenever feasible The method of masking is contingent upon the specific technology employed and should be evaluated alongside fault analysis.
Code checks such as CRC and EDAC on communication channels provide a simple fault masking method as they possess inherent error correction capabilities
Memory technology is prone to storage location faults and address mapping issues To address this, it is advisable to implement a technique that eliminates faulty locations from the memory map while ensuring that the access characteristics remain unchanged despite the modifications in address mapping.
If critical paths or paths subject to a high fault occurrence probability exist, then multiple identical paths should be implemented similarly.
Fault Confinement
Fault masking cannot conceal all potential system faults, making it crucial to contain any occurring faults within a defined boundary Regarding CFMs, there are two primary approaches.
To ensure optimal performance, isolate the module hardware by disabling all network interfaces except for a dedicated link to the module controller The module will then identify faults using Built-In Test (BIT) and assess their impact on its operation If the fault is determined to be non-repeatable, the module can be re-integrated into the system, although this decision rests with the system implementor.
To ensure safety and simplify design and construction, it is advisable to isolate the complete module by turning it off via the PCM, as this method poses the least risk to the system.
Safety and Security
To ensure the proof of Safety within the ASAAC IMA system architecture, it is essential to uphold three key requirements: data integrity, availability of data and resources, and predictability.
The data integrity requirements for computing process resources significantly influence the design of the processing capabilities in the DPM, GPM, and MMM modules Consequently, the design must ensure a high level of confidence in data integrity.
The requirement for data integrity in communications, ensuring no corruption or misrouting, significantly influences the overall design of the Network Security Model (NSM) and the internal communication components of all Critical Functional Modules (CFMs) related to safety applications, particularly Data Processing Modules (DPMs), General Processing Modules (GPMs), and Monitoring and Management Modules (MMMs).
This implies that on all these parts:
During the design phase, it is essential to provide sufficient information regarding the internal organization and operations This enables thorough risk analysis and Failure Mode, Effects, and Criticality Analysis (FMECA), allowing for accurate risk estimates related to critical failure events.
At run time their operation and associated resources (e.g configuration tables and mapping tables) should be maintained safe from hazards or faults occurring in adjacent areas
At run time, sufficient fault detection and localisation should be performed to achieve the fault tolerance objectives
6.5.1.2 Availability of Data and Resources
At runtime, it is crucial to demonstrate with high confidence that memory management allocates the specified data and program memory space to processes, as outlined in EN 4660-005 This necessitates the implementation of efficient monitoring and integrated testing mechanisms.
The architecture of a CFM should ensure that internal communications operation is predictable in terms of time and is guaranteed to be free from lock-up situation
Memory management utilities may be used to prevent access to invalid memory addresses according to blueprint information by errant or illicit computing processes
Modules should be designed such that electromagnetic coupling effects between data communication and power supply do not result in unintentional transmission of data off modules
The mechanical and electrical design of processing and networking modules must ensure adequate electromagnetic decoupling between internal areas to prevent unintentional transmission on the module's electrical interfaces.
It is assumed that the Network optical physical layer is immune against electromagnetic coupling
Electromagnetic coupling effects must be managed to prevent data leakage between CFM modules, ensuring that no classified information is stored in non-volatile memory locations.
All processing modules (DPM, GPM, SPM and MMM) may be designed such that all classified data is deleted when power is removed
The MMM can autonomously initiate a memory erase if it detects unauthorized removal, necessitating the use of specific memory technologies for storing sensitive information.
Performance Sheet for all Common Functional Modules
Data Processor Module
This sheet provides a performance parameter framework that may be used to indicate the capability of an implemented CFM
Table A.1 — Performance sheet for a DPM
Integer Processing Power per Processor SPECint95
Floating Point Processing Power per Processor SPECfp95
Total Non-Volatile Memory Size Mbyte
Total Volatile Memory Size Mbyte
Total Number of Timers Integer
Rate per Network Link – for each type Gbytes/s
Number of Input Network Links – for each type Integer
Number of Output Network Links – for each type Integer
Signal Processing Module
This sheet provides a performance parameter framework that may be used to indicate the capability of an implemented CFM
Table A.2 — Performance sheet for a SPM
Number of Digital Signal Processors Integer
Integer Processing Power per Processor SPECint95
Floating Point Processing Power per Processor SPECfp95
Total Non-Volatile Memory Capacity Mbyte
Total Volatile Memory Capacity Mbyte
Total Number of Timers Integer
Rate per Network Link – for each type Gbytes/s
Number of Input Network Links – for each type Integer
Number of Output Network Links – for each type Integer
Graphic Processing Module
This sheet provides a performance parameter framework that may be used to indicate the capability of an implemented CFM
Table A.3 — Performance sheet for a GPM
Number of Graphics Processors Integer
Image resolution pixels x pixels x bits
Line/Polygon drawing rate vectors/sec
Gouraud/Phong Shading rate triangles/sec
Total Non-Volatile Memory Capacity Mbyte
Total Volatile Memory Capacity Mbyte
Total Number of Timers Integer
Rate per Network Link – for each type Gbytes/s
Number of Input Network Links – for each type Integer
Number of Output Network Links – for each type Integer
Mass Memory Module
This sheet provides a performance parameter framework that may be used to indicate the capability of an implemented CFM
Table A.4 — Performance sheet for a MMM
Total Non-Volatile Memory Capacity Mbyte
Total Volatile Memory Capacity Mbyte
Rate per Network Link – for each type Gbytes/s
Number of Input Network Links – for each type Integer
Number of Output Network Links – for each type Integer
Network Support Module
This sheet provides a performance parameter framework that may be used to indicate the capability of an implemented CFM
Table A.5 — Performance sheet for a NSM
Rate per Network Link – for each type Gbytes/s
Number of Input Network Links – for each type Integer
Number of Output Network Links – for each type Integer
Power Conversion Module
This sheet provides a performance parameter framework that may be used to indicate the capability of an implemented CFM
Table A.6 — Performance sheet for a PCM
Maximum Output Current per Output Power Link A
Number of Output Power Links Integer
Rate per Network Link – Type 1 Gbytes/s
Number of Input Network Links – Type 1 Integer
Number of Output Network Links – Type 1 Integer
Rate per Network Link – Type 2 Gbytes/s
Number of Input Network Links – Type 2 Integer
Number of Output Network Links – Type 2 Integer