ETSO-C153a

This Appendix provides:

Chapter 1: an overview of Integrated Modular Avionics (IMA);

Chapter 2: applicable definitions;

Chapter 3: a definition of the Minimum Performance Standard (MPS) classes; and Chapter 4: examples of IMA platforms using IMA modules.

Chapter 1: Integrated Modular Avionics overview

In this ETSO, Integrated Modular Avionics (IMA) is defined according to EUROCAE ED-124 (equivalent to the RTCA document DO-297):

Integrated modular avionics (IMA): is a shared set of flexible, reusable, and interoperable hardware and software resources that, when integrated, form a platform that provides services, designed and verified to meet a defined set of safety and performance requirements, to host applications performing aircraft functions.

The IMA architecture integrates many aircraft functions on the same platform. Those functions are provided by several hosted applications that have historically been contained in functionally and physically separated ‘boxes’ or LRUs.

IMA platforms are composed of modules which are designed to be reusable in order to reduce development costs and occasionally facilitate certification programmes. Some modules provide only mechanical, possibly cooling and electrical power supply functions. Others include core software and the associated computing capabilities.

IMA modules are usually both generic and configurable, therefore, the same platform could be used on different aircraft models.

Chapter 2 — Applicable definitions

Legend

[ED-124]: Definitions from EUROCAE ED-124 (equivalent to RTCA document DO-297).

[C153a]: Definitions provided or adjusted in the frame of the ETSO.

Aircraft function [ED-124]: The capability of the aircraft that may be provided by the hardware and software of the systems on the aircraft.

Application [ED-124]: Software and/or application-specific hardware with a defined set of interfaces that, when integrated with the platform, performs a function.

Cabinet [C153a]: Result of the integration of hardware modules mounted within one rack.

Characterisation item [C153a]: Identified module characteristics towards which the IMA module developer needs to determine the module performance, with full verification and documentation in the user guide/installation manual as appropriate.

Component [ED-124]: A self-contained hardware, software part, database or combination thereof that is configuration-controlled. A component does not provide an aircraft function by itself.

Configuration data [ED-124]: See Paragraph 3.7.1.

Core Software [ED-124]: The operating system and support software that manage resources to provide an environment in which applications can be executed. Core software is a necessary component of a platform and is typically comprised of one or more modules (such as, for example, libraries, drivers, kernel, data-loading, boot, etc.).

IMA Platform [ED-124]: A module or group of modules, including core software, which manage resources in a manner sufficient to support at least one application. IMA hardware resources and core software are designed and managed in a way that provides computational, communication and interface capabilities for hosting at least one application. Platforms by themselves do not provide any aircraft functionality. The IMA platform may be accepted independently of hosted applications.

IMA System [ED-124]: It consists of (an) IMA platform(s) and a defined set of hosted applications.

LRM (Line Replaceable Module) [C153a]: An IMA platform element identified in aircraft configuration and replaceable by aircraft line maintenance to restore the aircraft into an operational ready condition. An IMA LRM is a stand-alone item of equipment which does not provide any aircraft function until hosted applications are integrated.

LRU (Line Replaceable Unit) [C153a]: An element supporting an aircraft function identified in aircraft configuration and replaceable by aircraft line maintenance to restore the aircraft into an operational ready condition. An LRU is usually a stand-alone item of equipment such as a radio, a Flight Management Computer or any kind of functional equipment.

IMA Module [C153a]: A component or collection of components that may be hardware or a combination of hardware and software, which provide resources to the IMA-hosted applications. Software application and module configuration data are not covered by this definition. Modules may be distributed across the aircraft or may be co-located.

Operating System[ED-124]:

1) The same as executive software.

2) The software kernel that services only the underlying hardware platform.

3) Software that directs the operations of a computer, resource allocation and data management, controlling and scheduling the execution of computer-hosted applications, managing memory, storage, input/output, and communication resources.

Rack [C153a]: A physical package able to contain at least two hardware modules, which may provide partial protection from environmental effects (shielding) and may enable installation on and removal of the mounted modules from the aircraft without physically altering other aircraft systems or equipment.

Resources/Shared resources [ED-124]: Any object (processor, memory, software, data, etc.) or component used by an IMA platform or application. A resource may be shared by multiple applications or dedicated to a specific application. A resource may be physical (a hardware device) or logical (a piece of information).

Support software [C153a]: Embedded software necessary as a complement to the operating system to provide general services such as contributing to the intended function of resources sharing, handling hardware, drivers, software loading, health monitoring, boot strap, etc.

Unit [C153a]: Set of physical components (hardware and/or software) inside an item of equipment in charge of providing a resource.

Usage Domain [C153a]: The usage domain of an IMA module is defined as an exhaustive list of conditions (such as configuration settings, usage rules etc.) to be respected by the user(s) to ensure that the IMA module continues to meet the performance characteristics and requirements of the ETSO Minimum Performance Standard. Compliance with usage domain ensures that:

the module is compliant with its functional, performance, safety and environmental requirements specified for all implemented intended functions;

the module characteristics documented in the User Guide (as required by Appendix 2) are guaranteed by manufacturer; and the module is compliant with the applicable airworthiness requirements (including continuing airworthiness aspects). (*) (*) Note: In the context of this IMA modules/platforms ETSO standard, this last sentence refers to requirements as described in Section 2 of CS-ETSO Subpart A.

Chapter 3 — Definition of intended function classes

To apply for an ETSO-C153a authorisation, the IMA module shall comply with applicable common requirements and implement at least one Intended Function Class. If a manufacturer applies for an ETSO-C153a authorisation, all the classes for which the Intended Function is implemented shall be compliant.

CLASS RH: Rack Housing

For ETSO-C153a Class RH:

1.3.RH.1: The IMA module is a physical package able to contain at least two hardware modules that may provide protection from environmental effects (shielding, etc.) and enable the installation and removal of those module(s) from the aircraft without physically altering other aircraft systems or equipment.

1.3.RH.2: The IMA module may be a simple mechanical enclosure, or it may incorporate communication interfaces, backplanes for data and power supplies, active cooling or any combination of these features.

1.3.RH.3: The IMA module does not offer the capability to host applications unless combined with a Class PR approval.

1.3.RH.4: The IMA module may be configurable.

CLASS PR: Processing

For ETSO-C153a Class PR:

1.3.PR.1: The IMA module contains a processing component, a memory component, interface devices and the associated Core Software which constitute one or several Processing Unit(s).

Note: Containing memory components or interfaces devices does not lead automatically to having class DS and/or IF in the certification basis; DS or IF classes need to be applied for only if concurrent access to these interface or data storage resources is offered as a shared resource (as described in Class DS and IF).

1.3.PR.2: The intended function of such an IMA module is to share Processing, Data and Information between at least two hosted applications, modules and/or components.

1.3.PR.3: The IMA module offers the capability to host applications.

1.3.PR.4: The IMA module may be an association of hardware and Core Software.

Hardware may (or may not) contain resident (not field-loadable) software to enable electronic part marking and/or future loading of Field-Loadable Software parts.

Core Software may be resident or a Field-Loadable Software part.

1.3.PR.5: The IMA module may be configurable.

CLASS GP: Graphical Processing

For ETSO-C153a Class GP:

1.3.GP.1: The IMA module contains a graphical engine component and an optional video engine component, memories, interfaces and potentially associated Core Software which constitute one or several Graphical Unit(s).

1.3.GP.2: The intended function of such an IMA module is to share graphics and optional video signal processing between at least two hosted applications, modules and/or components.

1.3.GP.3: The IMA module does not offer the capability to host software applications unless combined with a Class PR approval.

1.3.GP.4: The IMA module may be an association of hardware and Core Software.

Hardware may (or may not) contain resident (not field-loadable) software to enable electronic part marking and/or future loading of Field-Loadable Software parts.

Core Software may be resident or a Field-Loadable Software part

1.3.GP.5: The IMA module may be configurable.

CLASS DS: Data Storage

For ETSO-C153a Class DS:

1.3.DS.1: The IMA module contains memory (volatile or non-volatile), an interface component and potentially associated Core Software which constitute one or several Data Storage Unit(s).

1.3.DS.2: The intended function of such an IMA module is to share stored data (e.g. databases, files, etc.) between several applications, modules and/or components.

1.3.DS.3: The IMA module does not offer the capability to host applications, unless combined with a Class PR approval.

1.3.DS.4: The IMA module may be an association of hardware and a Core Software.

Hardware may (or may not) contain resident (not field-loadable) software to enable electronic part marking and/or future loading of Field-Loadable Software parts.

Core Software may be resident or a Field-Loadable Software part.

1.3.DS.5: The IMA module may be configurable.

CLASS IF: Interface

For ETSO-C153a Class IF:

1.3.IF.1: The IMA module contains input/output component(s) and potentially associated Core Software which constitute one or several Interface Unit(s). These interfaces can be discrete, analogue, a serial interface, a digital bus, etc..

1.3.IF.2: The intended function of such an IMA module is to share information between several aircraft functions or applications.

1.3.IF.3: The IMA module does not offer the capability to host applications unless combined with a Class PR approval.

1.3.IF.4: The IMA module may be an association of hardware and a Core Software.

Hardware may (or may not) contain resident (not field-loadable) software to enable electronic part marking and/or future loading of Field-Loadable Software parts.

Core Software may be resident or a Field-Loadable Software part.

1.3.IF.5: The IMA module may be configurable.

CLASS PS: Power Supply

For ETSO-C153a Class PS:

1.3.PS.1: The IMA module contains a set of components (hardware and/or software) which constitute one or several Power Supply Unit(s) in charge of managing electric power.

1.3.PS.2: The intended function of such an IMA module installed into a rack (Class RH module) is to provide power supplied from an airborne electrical network to one or more hardware modules embedded into the same rack.

1.3.PS.3: The IMA module does not offer the capability to host applications unless combined with a Class PR approval.

1.3.PS.4: The IMA module may be configurable.

1.3.PS.5: The IMA module may be an association of hardware and a Core Software.

Hardware may (or may not) contain resident (not field-loadable) software to enable electronic part marking and/or future loading of Field-Loadable Software parts.

Core Software may be resident or a Field-Loadable Software part.

CLASS DH: Display Head

For ETSO-C153a Class DH:

1.3.DH.1: The IMA module contains a set of components (hardware and/or software) in charge of managing a displayed area which constitutes one or several Display Unit(s).

1.3.DH.2: The intended function of such an IMA module is to offer the capability to depict graphical information received from IMA Application(s), component(s) and/or module(s) on one Display Area.

1.3.DH.3: The IMA module does not offer the capability to host applications unless combined with a Class PR approval.

1.3.DH.4: The IMA module may be an association of hardware and a Core Software.

Hardware may (or may not) contain resident (not field-loadable) software to enable electronic part marking and/or future loading of Field-Loadable Software parts.

Core Software may be resident or a Field-Loadable Software part.

1.3.DH.5: The IMA module may be configurable.

Chapter 4 — Example of an IMA platform using IMA modules

EUROCAE ED-124/RTCA document DO-297 contains some examples relating to the definition of the IMA module and platform, which can be completed by some additional examples related to Chapter 3 ‘Definitions’.

Example 1: Single LRU platform (as per EUROCAE ED-124/RTCA document DO-297)

This example illustrates the sharing of computational and Input/Output (I/O) resources within a single Line Replaceable Unit (LRU). Such IMA system key characteristics include:

hosting of multiple applications (not part of the IMA platform);

platform configuration data and data loading; and a defined API between the IMA platform and hosted applications.

[Figure or form omitted from this preview — available in the Avioverse workspace library.]

Figure 1: Single LRU platform (as per EUROCAE ED-124/RTCA DO-297)

At one level, this example illustrates a single platform providing core computational resources. At another level, it illustrates a module to be used within a larger IMA platform.

If sharing of processing, memory, and I/O resources is implemented within the LRU, such a single LRU platform will be eligible for CLASS PR, DS and IF.

Example 2: Single LRU A664 switch equipment

This example illustrates the sharing of ARINC Specification 664 I/O resources within a single Line Replaceable Unit (LRU).

[Figure or form omitted from this preview — available in the Avioverse workspace library.]Virtual link (see ARINC 664) between two subscribers, switched by the *C153* class IF modules Virtual link (see ARINC 664) between two subscribers, switched by the *C153* class IF modules

Figure 2: Example of an architecture based on two ETSO-*C153* class IF modules each implementing an ARINC 664 switch

Note: ETSO-*C153* is intended to identify any existing amendment of this ETSO including its first release as ETSO-2C153.

In this architecture, the two ETSO-C153a class IF modules switch A664 frames, providing each of the subscribers shared access to the network. Network subscribers can be other ETSO-C153a modules as the lower row of modules shows, or non-IMA equipment (top row) such as displays/radio transceivers.

If sharing of ARINC Specification 664 I/O resources is implemented within the LRU, such a single LRU platform shall be eligible for CLASS IF.

Example 3: IMA modules installed in a Rack Module (Line Replaceable Module)

[Figure or form omitted from this preview — available in the Avioverse workspace library.]

Figure 3: IMA modules installed in a Rack Module

This example illustrates the sharing of resources within several single Line Replaceable Modules (LRMs) installed in a Rack:

a Rack is an IMA module and will be eligible for CLASS RH;

LRM 1 provides shared Processing and Input/Output and shall be eligible for CLASS PR+IF;

LRM 2 provides shared Graphical Processing and shall be eligible for CLASS GP;

LRM 3 provides shared a Power Supply to LRMs embedded into the same rack, and shall be eligible for CLASS PS; and LRM 4 does not provide shared resources. This module shall be considered as a non-ETSO-C153a module.

All these modules are considered to be parts.

[Amdt ETSO/10]

[Amdt ETSO/16]

This Appendix provides a Specific Minimum Performance Standard for IMA modules.

Principle

An IMA module is composed of hardware components or hardware and software components performing the intended function(s) whose minimum performance requirements are specified in this Appendix.

This Minimum Performance Standard (MPS) is structured as a common-requirements section and a set of classes specifying IMA module intended functions:

COMMON: Minimum Performance Standard applicable whatever IMA module and whatever the implemented intended function class(es);

CLASS RH: Rack Housing intended function;

CLASS PR: Processing intended function;

CLASS GP: Graphical Processing intended function;

CLASS DS: Data Storage intended function;

CLASS IF: Interface intended function;

CLASS PS: Power Supply intended function; and CLASS DH: Display Head intended function.

To apply for an ETSO-C153s authorisation, the IMA module shall comply with a common Minimum Performance Standard and implement at least one Intended Function Class as defined in this Appendix.

When applying for an ETSO-C153a authorisation, the applicant shall include in the certification basis all classes for which the intended function is implemented in the IMA module/platform.

Naming convention

This document contains ‘shall’, ‘should’ and ‘may’ statements with the following meanings:

the use of word ‘shall’ indicates a mandated criterion, i.e. compliance with the criterion is mandatory and no alternative may be applied;

the use of word ’should’ (and phrases such as ‘It is recommended that...’, etc.) indicate that though the procedure or criterion is regarded as the preferred option, alternative procedures, specifications or criteria may be applied, provided that the manufacturer, installer or tester can provide information or data to adequately support and justify the alternative;

the use of word ‘may’ indicates that though the criterion is regarded as the preferred option, alternative criteria may be applied. In such cases, alternatives should be identified in appropriate approval plans and agreement sought from the approval authority.

Verification Procedures

For verification procedures, the following definitions and symbols are used in this Appendix:

Analysis (A)

Analysis is the method of verification which consists in comparing design with known scientific and technical principles, technical data, or procedures and practices to validate that the proposed design will meet the specified functional or performance requirements.

Demonstration (D)

Demonstration is the method of verification where qualitative versus quantitative validation of a requirement is made during a dynamic test of the system/equipment. In general, software functional requirements are verified by demonstration since their functionality must be observed through some secondary media.

Inspection (I)

Inspection is the method of verification to determine compliance with requirements and consists primarily of visual observations or mechanical measurements of the system/equipment, physical location, or technical examination of the engineering support documentation.

Test (T)

Test is the method of verification that will exercise equipment functions and measure system/equipment performance under a specific configuration and load conditions and after the controlled application of known stimuli. Quantitative values are measured, compared against previously predicated success criteria, and then evaluated to determine the degree of compliance.

Y

The test is mandated under the indicated conditions.

m/n

Either verification method ‘m’ or verification method ‘n’ may be used to verify the requirement (i.e. D/A can be verified by Demonstration or Analysis).

m+n

Both verification methods must be used to verify the requirement (i.e. D+A means that the requirement must be verified by Demonstration and Analysis).

[Amdt ETSO/10]

[Amdt ETSO/16]

COMMON: Applicable to all IMA modules

1.Purpose and scope

This Appendix contains a set of Minimum Performance Standards (MPS) applicable to any IMA module and to any implemented intended function class(es).

In the following, the term ‘concurrent items’ designates the items (applications, for example) that use the shared resource of the IMA module. Depending on the module class, it means ‘processing element’ for PR class, ‘thread’ for GP, IF and DH class, ‘data storage element’ for DS class, and ‘power rail’ for PS class.

2.Requirements

2.1. Functional requirements common to all classes

CO.a) The IMA shall implement at least one Function Class.

The following requirements of this paragraph are applicable to all classes with some exception as described below:

CO.b) Except for the housing function (F1) of class RH (see Appendix 2.2, paragraph 2.1.1), the IMA module shall provide at least the following control features to react to detected failures:

a. disable, and b. reset.

CO.c) Except for the Housing function (F1) of class RH (see Appendix 2.2, paragraph 2.1.1), each IMA module shall provide a health management and reporting capability.

CO.d) Except for the housing function (F1) of class RH (see Appendix 2.2 , paragraph 2.1.1), the health management and reporting function shall detect, isolate, contain and report faults (in the shared resources and other resources) that could adversely affect applications using the module resources or the resources themselves.

CO.e) Except for class RH, robust partitioning (as per EUROCAE ED-124/RTCA DO-297) between ‘concurrent items’ sharing the resource shall be ensured by the IMA module.

CO.f) Except for class RH, robust partitioning shall not rely on any required behaviour of any aircraft function or hosted application (as per EUROCAE ED-124/RTCA DO-297, Section 3.5c).

CO.g) Except for class RH, the potential breaches in robust partitioning shall be identified. An appropriate process and means should be implemented to ensure that such failures which result or may result in an unsafe condition are detected and reported.

CO.h) Except for class RH, the IMA module shall implement a fault containment mechanism to prevent fault propagation between ‘concurrent items’ using the shared-resource elements and between other IMA modules.

CO.i) Reserved.

CO.j) Except for the housing function (F1) of class RH (see Appendix 2.2, paragraph 2.1.1), the interface between the ‘concurrent items’ and the shared resource should conform to the characteristics as described by a standard (ARINC specifications 653, 664, and 600, for example).

2.2. Characterisation requirements

CO.k) Each item of the characterisation shall be documented in the User Guide/Installation Manual as appropriate.

CO.l) The IMA module specification shall be characterised based on items in the table below (Figure 4: IMA module Characterisation Categories) and on the characterisation requirements identifying additional characterisation items specific to each functional class (defined in Appendix 2 — Class RH, PR, GP, DS, IF, PS, and DH).

CO.m) Quantifiable characterised items shall be quantified in terms of minimum, typical (when relevant) and maximum values and the associated accuracy.

Note: The influence of environmental or abnormal conditions should be considered when relevant.

CO.n) The characterisation of the IMA module shall be correct and complete. Completeness is achieved when all the shared features of the IMA module have been characterised.

CO.o) The characterisation shall identify the valid usage domain of the IMA module.

CO.p) The characterisation shall provide all constraints on the usage domain and on the installation (including limitations and activities) to be respected by the users.

CO.q) The characterisation shall provide the list of types of shared-resource elements, the associated attributes, their configurability and their performances, and their associated limit of use.

CO.r) The characterisation shall include at least the following characteristics of the core software/programmable hardware:

a. the identification of the core software component(s)/programmable hardware (if any);

b. the IMA module functionality, performance and safety requirements supported by the core software/programmable hardware;

c. external interfaces and associated data coupling/control-coupling information;

d. integration and loading procedure(s); and e. the development assurance level(s).

CO.s) When the IMA module offers the capability to host software, the characterisation shall provide any data needed to evaluate the worst-case execution time (WCET) of each concurrent item sharing the IMA module resource.

CO.t) The performances of each shared-resource management mechanism including monitoring shall be characterised, in particular the range, timing aspects, transients, etc.

CO.u) For at least the following failure modes, the failure rate shall be provided:

a. a loss of the IMA module;

b. erroneous behaviour of the IMA module;

c. a loss of the shared-resource element; and d. erroneous behaviour of the shared-resource element.

CO.v) The characterisation shall include the monitoring coverage rate (PBIT, CBIT, etc.) for the identified failure modes of the IMA module (including shared and unshared resources, sharing mechanisms and robust partitioning mechanisms).

CO.w) The characterisation shall address the safety aspects of bad sequencing, delay, corruption and impersonation, where applicable.

CO.x) The following health monitoring items shall be included in the characterisation:

a. interface rules, constraints (including limitations) to be respected by the users;

b. list of Health Monitoring services;

c. list of monitored components, monitored services, monitored interfaces;

d. response to each type of fault;

e. fault reporting attributes (reporting refers to internal logging, indication to applications using the shared resources, indication outside of the module); and f. the configuration attributes, if any.

CO.y) If the IMA module is configurable, the characterisation shall include, in addition, the following items:

a. the authorised configuration parameters (including range, type and definition of combined parameters) in the usage domain; and b. the configuration activities to be conducted (including configuration procedures, means and tools) by the user during application development (EUROCAE ED-124 — Task 2) and IMA system integration (EUROCAE ED-124 — Task 3 and 4).

CO.z) If some tools are required for installation, these tools shall be characterised according to the following:

a. identification;

b. the user’s manuals of the tools;

c. the activities related to those tools to be conducted during application development (EUROCAE ED-124 — Task 2) and IMA system integration (EUROCAE ED-124 — Task 3 and 4);

d. the proposed associated qualification credits that could be granted to the user of the tools;

e. the category of the tool and the Development Assurance Level of the tool (if any) as defined in the applicable Software Development assurance guidance (see Section 2.2 of CS-ETSO, Subpart A,); and f. limitations and Open Problem Report (if any) on tools that could affect the tool qualification credit and require analysis by the user.

CO.aa) The compatibility and mixability information between hardware, software, tools and usage domain shall be part of the characterisation. This characterisation shall address at least the following:

a. how the authorised mixed combinations are verified;

b. the compatibility assessment process with authorised mixed combinations of interfacing modules (external mixability);

c. any preventative measures (design or procedures) to be developed by the user to prevent incorrect module combinations or software loads; and d. information to be provided to maintenance personnel.

CO.bb) The control features (disable, reset, reload, etc.) of the IMA module for reacting to detected failures shall be characterised.

Figure 4: IMA module Characterisation Categories

The following list of terms summarises the terminology used in the characterisation items defined in Figure 4 that are applicable to this ETSO, in the development of hardware elements, and in the application of the Appendix 1 MPS development criteria. The terms are segregated into eight categories according to the performance of the appropriate hardware element.

(1)General Terms

Air Flow Characteristic: specific requirements to provide air movement into or onto a cabinet, LRU, or module (e.g. air temperature, volume rate, and pressure).

Analogue/Digital Conversion Speed: the time to perform one Analogue-to-Digital (A-to-D) conversion. Typically, this is expressed as either the time for one analogue conversion performed by the A/D converter device or the frequency at which all analogue inputs are converted.

Circuit Protection Techniques: the electrical isolation or circuitry included in inputs or outputs to protect the functional circuits from external environments(for example solutions to protect circuits from the indirect effects of lightning).

Current Source/Sink: the maximum current drawn by the output while pulling the signal to a zero-volt (ground) level.

Current Source: the maximum current supplied by the output while driving the signal to a voltage level.

Clearance Characteristics: additional spacing requirements in specific directions from the cabinet or rack beyond the outline dimensions (e.g. additional clearance is the area to allow proper airflow).

Design Assurance: all planned and systematic actions and data used to substantiate that hardware correctly performs its intended function(s) and that design errors have been identified and corrected such that the hardware satisfies the applicable certification basis.

Development Assurance: all planned and systematic actions and data used to substantiate that the system performs its intended function(s) and that development errors have been identified and corrected such that the system satisfies the applicable certification basis.

Functional Software: software applications that will be approved as part of a functional TSO authorisation or as part of a type certification effort. This software is sometimes referred to as operational software, application software, or flight software.

Functional ETSO: an ETSO with defined functionality (for example, Airborne Weather Radar, ETSO-C63). ETSO-C153a is not considered a functional ETSO, because IMA hardware elements typically do not have system-level functionality.

Grounding/Shielding Provisions: the electrical and/or mechanical details of the design which provide grounding of the element or shield connections. These are the design details usually associated with the Radio Frequency emission and susceptibility protection of the system.

Hardware element: in this ETSO, a hardware element is (1) a hardware module, or (2) cabinets or racks that host hardware modules.

Note: This definition may differ from the terminology used in other documents (e.g. ED-80/RTCA DO-254).

Inter-Element Connections: the connector type specification and connector pin assignments specified to allow modules to be installed interchangeably in the cabinets or racks.

Inter-Element Interfaces: the definition of the electrical signals, timing requirements, and protocols used to communicate among modules or elements with the cabinet or system.

Module Extraction Means: the details of the mechanical design to enable removal of the module from the cabinet.

Module Mounting Scheme: the details of the mechanical design used to secure each module into the cabinet or rack.

Mounting Mechanism: the details of the mechanical mechanism(s) used to secure the module into the cabinet or rack of the aircraft.

Multiplexing: the design technique where multiple inputs are individually switched to one receiver (for example, multiple digital communication buses switched to a serial receiver) or multiple outputs are individually supplied by the same circuit (for example, multiple analogue outputs driven by one Digital-to-Analogue converter through multiple sample-and-hold).

Separation/Isolation Provisions: the electrical and/or mechanical details of the design which provide physical or electrical means of reducing interference from one element to another.

Steady State Voltage Rating: the maximum voltage range that can be applied continuously to an input or output without resulting in damage.

Transient Voltage Rating: the maximum voltage that can be applied for a short period of time to an input or output without resulting in damage. The maximum duration of the transient must be included.

(2)Analogue Input/Output Terms

Accuracy: the degree of conformity to the true value of the signal. This is usually expressed as a percentage of the reading or a percentage of the full-scale value of the signal.

Current Capacity: the maximum amount of current that can be sinked or sourced by the circuit.

Linearity: the error from the directly proportional expected signal value as the signal values vary over the entire range.

Null: the signal value(s) for which a value of zero is identified. This is usually shown as positive and negative voltage values.

Offset: the indicated signal value (usually non-zero) when zero volts are applied.

Range: the least and greatest operating voltage extremes (full scale) of the signal; the voltage extremes between which the signal value is valid.

Resolution: the smallest measurable division of the numerical expression of the signal. This is usually identified as the number of binary bits used to express the signal value and/or the value in volts of the least significant binary bit (LSB).

(3)Discrete Input/Output Terms

Discrete Input: this is an input with only two states. Typical examples are ‘ground or open’ and ’28-volt and open’ inputs.

Discrete Output: this is an output with only two states. Typical examples are ‘ground or open’ and ’28-volt and open’ outputs.

(4)Input Terms

Hysteresis: the value of the input voltage lag when changing states. For example, if an input circuit has 0.2 volts of hysteresis and if the trip point is 2.0 volts, then the circuit will change state as the input voltage reaches 2.0 volts but will not revert back to the original state until the input voltage drops below 1.8 volts.

Logic Sense: this is the functional interpretation of the discrete input states. A true or positive logic sense may identify the ‘ground’ state as ‘low’ or binary ‘0’. An inverse or negative logic sense may identify a ‘ground’ state as ‘high’ or binary ‘1’.

Maximum Logic–High Level: the largest voltage value that can be applied to the input and that the circuit will interpret as ‘high’.

Maximum Logic–Low Level: the largest voltage value that can be applied to the input and that the circuit will interpret as ‘low’.

Minimum Logic–High Level: the smallest voltage value that can be applied to the input and that the circuit will interpret as ‘high’.

Minimum Logic–Low Level: the smallest voltage value that can be applied to the input and that the circuit will interpret as ‘low’.

Trip Point: this is the input voltage value at which the input circuitry changes state.

(5)Output Terms

Current Sink Capacity: the maximum current by the output while pulling the signal to a zero-volt (ground) level (current flowing in the direction from the load to the element output).

Current Source Capacity: the maximum current supplied by the output while driving the signal to a voltage level (current flowing from the element output to the load).

Voltage Levels: the minimum and maximum voltages for each state of the output. The ground point that is to be used as reference must be identified.

(6)Processor Terms

Backplane Interface: the definition of the electrical signals, buses, timing requirements, and protocols used to communicate among elements installed in a cabinet or rack.

Interrupts: the signals to the processor that stops execution of an ongoing process or application. These signals indicate that there is a higher priority request of task or that an asynchronous event is occurring.

Memory Management Unit: a specialised control circuitry, sometimes integrated within the microprocessor, which performs predictive reads of instruction (prefetch) for use by the processor. It also may perform structured or prioritised control of specific sections of the memory.

Monitors: specific circuits which observe the normal operation of the processing system and alert the processor or user to an abnormal condition. Examples are power supply monitors, which reset the processor when a voltage is outside of its tolerance, and activity monitors, which reset the processor when the processor does not perform a prescribed sequence.

Reset Structure: the architectural details of the various signals that stop execution of an ongoing process, or software application and restarts the processor at a known state.

Central Processing Unit (CPU) Throughput: a measure of the number of processor instructions performed by the CPU per unit of time.

(7)Power Supply Terms

Hold-up Capacity: the capacity of the power supply to continue supplying output current after the input voltage drops below the minimum level. This is usually expressed as the time from the input voltage drop to the reset generated by the power supply.

Input Voltage & Current: the input voltage is specified as nominal and acceptable variation values. The input current is specified as maximum steady state current. For the peak current, please see the term ‘Maximum Start-up (Inrush) Current Rating’ below.

Maximum Start-up (Inrush) Current Rating: the maximum input current when the power supply first becomes active as a result of the input voltage increase to the minimum level.

Output Current Capacity: the continuously operating maximum current supplied for each output voltage.

Power Monitors & Status Outputs: separate circuitry which checks the output voltage levels and current loading of the power supply. This circuitry will generate one or more binary signals that may be connected to the processor to alert it to the ‘out of spec’ condition. These binary signals may also force the power supply to shut down to prevent damage to power supply components.

Power Resets: a binary signal output from the power supply that is asserted when the output voltages are outside acceptable tolerances.

Regulation: the percentage of variation of the output voltages when subjected to changes in load, changes in temperature, and all input voltage transients and deviations.

Restart: the ability of the power supply or other circuit to return to the normal operating mode when the input voltage returns to or above the minimum level or when the tripped monitor indicates that the ‘out-of-spec’ condition has ended and the operating condition is returned to normal.

Short Circuit Management: the circuitry that monitors for short circuits or overcurrent conditions in the power supply outputs. The results from this circuitry may shut down the affected output or the entire power supply.

Transient Immunity: the ability of the power supply to continue operating normally during variations in the input voltage. This is usually expressed as the length of time and voltage level of the transient.

Voltage Outputs & Tolerances: the voltage levels and tolerances of the outputs produced by the power supply.

(8)Digital Communication Terms

Data Rates: the number of data bits transmitted in a time period. This is usually expressed in thousands of bits per second (Kbps) or millions of bits per second (Mbps).

Integrity Checks: the process that uses additional data accompanying the message information to validate that the message data was received without corruption or contamination. Examples are parity checks, checksums, data validity checks, and cyclic redundancy checks.

Maximum Bit Error Rates: the largest number of bit errors allowed in a message transmission before the receiver invalidates its ability to receive data from that source.

Monitors: separate circuitry that checks either the continuing operation of a transmitter, or that the receiver responds to input data. This circuitry will generate one or more binary signals that may be connected to the processor, alerting it to the ‘failed’ condition.

Resets: conditions that result in the receiver or transmitter stopping operation, clearing all data, and restarting.

Signal Levels: the minimum and maximum voltages for each state of the input or output. Typically, tolerances, thresholds, and the reference ground point are also identified.

Signal Rise and Fall Times: the signal rise time is the time for the output to transition from 10 % to 90 % of the amplitude. The signal fall time is the time for the output to transition from the 90 % to the 10 % level.

Stub Length Limits: the minimum and maximum length requirements of the wiring connector from the main bus to the inputs of the element.

3.Verification requirements

CO.cc) Each requirement shall be verified.

CO.dd) Each characterisation item of IMA modules and functions, their associated attributes, their configurability and their performances shall be verified commensurately to the Development Assurance Level.

CO.ee) Each characterisation item of the IMA module shall be verified over the usage domain.

CO.ff) A set of verification procedures to demonstrate the compliance of the IMA module with the applicable MPS shall be developed and proposed as part of the certification data package.

CO.gg) There is a distinction between demonstrating the capability of sharing and demonstrating the performance of that sharing function. When demonstrating the performance of the IMA module, a subset of the characterisation items that allows the behaviour of the complete IMA module during environmental testing shall be defined and submitted together with the Qualification Test Plan.

Note that this functional subset should be detailed enough to sufficiently cover the performance of the complete IMA module.

4.Test Software representativeness

When embedded software is needed to test the IMA module, this module is authorised without the functional software (hosted applications) being installed and operating.

CO.hh) Engineering analysis performed by the design holder shall determine that the test software (not the target functional software) is representative of the overall usage domain envelope of the module and related to the verification procedures.

5.Verification procedures

The following table provides verification methods for each requirement; nevertheless, an alternative method may be proposed to the certification authority.

Table 1: Verification Acceptance Criteria

(A*) means that verification by the Analysis method is possible for items that cannot be tested.

Note (1): applicable for a functional subset as defined in CO.gg).

Note (2): the Usage Domain has to be taken into consideration during Environmental Qualification Testing in order to evaluate the robustness of the IMA module over the full Usage Domain (see Appendix 4, Chapter 1).

[Amdt ETSO/10]

[Amdt ETSO/16]

CLASS RH: Rack Housing

1.Purpose and scope

1.1. Introduction

This Appendix contains the Minimum Performance Standards (MPS) for the CLASS RH Intended Function: Rack Housing.

These standards specify module characteristics that should be useful to designers, manufacturers, installers and users of the IMA module.

1.2. Definitions

For ETSO-C153a CLASS RH, the IMA module is a physical package able to contain at least two hardware modules, which may provide partial protection from environmental effects (shielding, etc.) and enable the installation and removal of those module(s) from the aircraft without physically altering other aircraft systems or equipment.

These IMA modules may be simple mechanical enclosures, or they may incorporate passive communication interfaces, a passive interconnection of data and power, an active or passive cooling unit or any combination of these features.

The following definitions are used:

‘Mounted’ refers to another hardware module, installed and fixed inside the IMA rack module, after a human operation.

‘Slot’ is a physical space inside the rack module, allocated to one hardware module.

These definitions are independent of the design choices made by the IMA module manufacturer.

Note:

The IMA module compliant with ETSO-C153a CLASS RH MPS is only relevant in the case of an IMA platform architecture that uses a cabinet; and hardware modules mounted inside the Rack Housing will themselves be IMA modules (compliant with ETSO-C153a MPS classes other than RH) or non-IMA modules (i.e. non-IMA application specific hardware).

[Figure or form omitted from this preview — available in the Avioverse workspace library.]

Figure 5: Illustration of the IMA platform architecture based on a cabinet

1.3. Intended Function

For ETSO-C153a CLASS RH, the intended function is to provide the capability to share some of the housing services supplied by one mechanical unit.

This intended function can be divided into 4 sub-functions:

F1: Housing (mandatory);

F2: Shielding (optional);

F3: Interconnection (optional); and F4: Temperature control (optional).

Figure 6 provides an overview of the above-mentioned intended functions and definitions of the Rack Housing Module.

[Figure or form omitted from this preview — available in the Avioverse workspace library.]

Figure 6: IMA module overview for ETSO-C153a CLASS RH

2.Requirements

2.1. Requirements for Housing (F1)

For ETSO-C153a CLASS RH, the IMA module provides shared resources for the housing needs of hardware modules. This sub-function merges:

the capacity to host at least two hardware modules in at least two slots; and the capacity to mount and dismount a hardware module in its slot directly on the aircraft thanks to a human (potentially tooled) intervention.

[Figure or form omitted from this preview — available in the Avioverse workspace library.]

Figure 7: CLASS RH Housing function overview

2.1.1. Functional requirements for ETSO-C153a CLASS RH (F1): Housing

RH.a) The Rack Housing shall permit the installation and attachment of at least two hardware modules to be installed and attached, one of which (at least) is an IMA module, inside its mechanical structure.

RH.b) The Rack Housing shall ensure the physical partitioning between the different mounted hardware modules.

RH.c) For each type of slot, a means to avoid the installation of unintended hardware modules or inappropriate installation shall be implemented (e.g. a mechanical key).

RH.d) If compliance with the MPS requires any additional mechanical component, then if this component is separable, it shall be marked with its part number.

RH.e) The external mechanical interface(s) of the Rack Housing module should conform to the characteristics as described by a standard (e.g. ARINC 600). Some characteristics of the slots may be configurable.

[Figure or form omitted from this preview — available in the Avioverse workspace library.]

Figure 8: CLASS RH— the relationship between housing elements

2.1.2. Characterisation requirements for ETSO-C153a CLASS RH (F1): Housing

RH.f) The following housing performances or housing characteristics of the rack module shall be provided as part of the characterisation:

1.the size, mass and centre of gravity;

2.the clearance scheme;

3.the top-level drawings and mechanical interfaces;

4.the module mounting scheme;

5.the installation and extraction mechanisms;

6.the temperature control (e.g. airflow, cooling, etc.) performances if the function is implemented;

7.a list of the slots and their associated performances (physical scheme, temperature profile, connector, etc.).

Note: These characterisation requirements are additional to those applicable in Appendix 2.1 — COMMON).

RH.g) The characterisation shall include the description of the mounted hardware module installation and the extraction means and methods.

RH.h) The characterisation shall provide the list of types of slots, their associated attributes, their configurability (if any) and their sizing dimensions (drawings).

This characterisation shall include:

1.the list of authorised or predefined hardware modules (if any);

2.the list of minimum requirements that a hardware module shall comply with to be able to be inserted into the rack;

3.the slot mounting scheme (mechanical profile/drawings) and characteristics (torque, maximum number of insertions, etc.); and

4.the power dissipation and airflow profile.

RH.i) The characterisation, including the usage domain, shall be sufficiently accurate to permit specification and validation of the expected performance of the mounted hardware module.

RH.j) The characterisation shall include the configuration, weight and geometric data that are needed to evaluate the mass and centre of gravity of a populated rack and a partly populated rack.

RH.k) The characterisation shall include the installation instructions of the additional mechanical component that is necessary in order to be compliant with the MPS.

2.2. Requirements for Shielding (F2)

F2 is an optional sub-function of ETSO-C153a CLASS RH.

In this case, the IMA module provides shared resources in terms of the protection of mounted hardware modules. This sub-function merges:

a level of protection of the mounted hardware modules from the aircraft environment (including, but not only, High Intensity Radiated Fields (HIRF) and Lightning effects); and a level of environmental isolation (shielding) between the mounted hardware modules inside the rack.

[Figure or form omitted from this preview — available in the Avioverse workspace library.]

Figure 9: CLASS RH shielding function overview

2.2.1. Functional requirements for ETSO-aC153a CLASS RH (F2): Shielding

RH.l) A level of environmental protection (shielding) for each mounted hardware module shall be ensured by the Rack Housing IMA Module. This protection shall take into account the level and severity retained for the EUROCAE ED-14/RTCA DO-160 qualification of the IMA module (see Appendix 4) (outside the rack), as well as the interactions between the mounted hardware modules themselves (inside the rack).

RH.m) The protection performance of the IMA module (Rack module) shall be quantified and guaranteed for each slot and for each EUROCAE ED-14/RTCA DO-160 Section.

RH.n) Reserved

[Figure or form omitted from this preview — available in the Avioverse workspace library.]

Figure 10: CLASS RH— the relationship between shielding elements

2.2.2. Characterisation requirements for ETSO-C153a CLASS RH (F2): Shielding

RH.o) The level of environmental protection (shielding) of each slot provided in Appendix 2.2, paragraph 2.1.1 shall be characterised, bounded and documented in the installation manual.

RH.p) The characterisation shall include the failure modes and rates of the protection features (such as lightning protections, etc.) to support the IMA system Safety Analysis (as per EUROCAE ED-124) at installation.

RH.q) The characterisation shall include the list of types of slots and the associated characteristics in terms of environmental protection (shielding).

This shall include:

1.the list of authorised or predefined hardware modules (if any);

2.the list of minimum requirements that a hardware module shall comply with in order to be mounted into the rack;

3.a slot Mounting Scheme (mechanical profile/isolation/drawings); and

4.the level of isolation and level of shielding per slot for each EUROCAE ED-14/RTCA DO-160 Section.

RH.r) The characterisation shall include the list of environmental tests that are used to qualify the hardware module (see Environmental Qualification Testing (EQT) in Appendix 4) mounted into the rack.

RH.s) The characterisation shall include all the possible configurations allowed for the configurable slot.

RH.t) If the 0 shielding objective is met thanks to any additional mechanical element(s), its installation shall be specified in the installation manual.

2.3. Requirements for Interconnection (F3)

F3 is an optional sub-function of ETSO-C153a CLASS RH.

In this case, the IMA module provides the capacity to interconnect hardware modules with each other inside the Rack Module. This interconnection allows the exchange of data or the distribution of power.

Note: To ensure the distribution of power to the mounted hardware modules, at least one ETSO-C153a CLASS PS module may be mounted into a slot to deliver electrical energy to the other hardware modules.

[Figure or form omitted from this preview — available in the Avioverse workspace library.]

Figure 11: CLASS RH Interconnection function overview

2.3.1. Functional requirements for ETSO-C153a CLASS RH (F3): Interconnection

RH.u) The IMA module shall provide the capacity to interconnect mounted hardware modules thanks to data or power supply buses available through (an) electrical interface(s) supplied by one or several interconnection unit(s). These buses shall be dedicated to:

a. data exchanges; and b. power distribution.

RH.v) If the IMA module provides more than one bus, the isolation between the buses used by mounted hardware modules shall be ensured by the IMA module. This isolation shall be substantiated by a Partitioning Analysis and by Environmental Qualification Testing.

RH.w) The interface(s) of the IMA module should conform to the characteristics as described by a standard (e.g. ARINC 600 or ARINC 664).

RH.x) The data and power supply buses shall not degrade the transmitted signals below the characterised performance.

RH.y) For ETSO-C153a CLASS RH, the IMA module shall ensure proper isolation of the interconnection function to prevent interference between signals (data, discrete I/O, power supply buses, etc.) that would affect data integrity, latency, and control.

[Figure or form omitted from this preview — available in the Avioverse workspace library.]

Figure 12: CLASS RH — the relationship between interconnection elements

2.3.2. Characterisation requirements for ETSO-C153a CLASS RH (F3) Interconnection RH.z) The characterisation shall include attenuation profiles, signal integrity, cross-talk and tolerance rates. These shall be measured and guaranteed.

RH.aa) The performances of each of the types of buses provided in RH.u a) shall be characterised, quantified and guaranteed.

RH.bb) For at least the following failure modes, the failure rate shall be provided:

a. a loss of the interconnection function; and b. erroneous behaviour of the interconnection function.

RH.cc) The characterisation shall address the safety aspects of sequencing, delay, corruption and impersonation.

RH.dd) The characterisation shall include the list of types of buses, their associated attributes, their configurability, and their sizing and performance.

2.4. Requirements for Temperature control (F4)

F4 is an optional sub-function of ETSO-C153a CLASS RH (F4): Temperature control

In this case, the IMA module provides the capability to control the temperature inside the rack for each mounted module.

This control may be realised by:

distributing airflow between the aircraft environment (outside the rack) and the mounted hardware modules inside the IMA module (rack);

enforcing airflow (convection) within the cooling generation unit;

facilitating conduction between mounted hardware modules and the heat sinkers part of the Rack module.

[Figure or form omitted from this preview — available in the Avioverse workspace library.]

Figure 13: CLASS RH cooling function overview

2.4.1. Functional requirements for ETSO-C153a CLASS RH (F4): Temperature control

RH.ee) The IMA module shall provide regulated temperature control of the mounted hardware module. This control shall be ensured per slot in a determined temperature range.

RH.ff) The IMA module may provide an active means (temperature control unit) to control the temperature between the aircraft environment and the mounted hardware modules.

[Figure or form omitted from this preview — available in the Avioverse workspace library.]

Figure 14: CLASS RH — the relationship between the cooling elements

2.4.2. Characterisation requirements for ETSO-C153a CLASS RH (F4)

RH.gg) The heat exchange performance of each slot provided shall be characterised, quantified and guaranteed in the installation manual.

RH.hh) For at least the following failure modes, the failure rate shall be provided:

a. a loss of the active temperature control function; and b. erroneous behaviour of the active temperature control function.

RH.ii) Reserved

RH.jj) Reserved

3.Verification procedures

The following table gives the verification method for each MPS; nevertheless, an alternative method may be proposed to the certification authority:

Table 2: Verification Acceptance Criteria

(A*) means that verification by the Analysis method is possible for the item that cannot be tested.

Note (1): applicable for a functional subset cf. CO.gg).

Note (2): test to be completed after environmental testing.

[Amdt ETSO/10]

[Amdt ETSO/16]

CLASS PR: Processing

1.Purpose and scope

1.1. Introduction

This Appendix contains the Minimum Performance Standards (MPSs) for the CLASS PR Intended Function: Processing (PR).

These standards specify characteristics that should be useful to designers, manufacturers, installers and users of the IMA module.

1.2. Definitions

For ETSO-C153a CLASS PR, the IMA module provides shared resources in terms of processing between hosted applications, modules and/or components.

The following definitions are used:

Processing Unit: a set of physical components (hardware and/or software) in charge of carrying out the instructions of a computer programme by performing the basic arithmetical, logical, and input/output operations of the Executable Object Code.

Executable Object Code (EUROCAE ED-12C/RTCA DO-178C): a form of code that is directly usable by the processing unit of the target computer and is, therefore, a compiled, assembled, and linked binary image, loaded into the target computing hardware.

Processing Element: a well-defined set of instructions which is a primary form of an Executable Object Code execution and for which a level of isolation would be guaranteed by the IMA module.

In the context of PR class, the ‘concurrent item’ defined in Appendix 2.1, paragraph 1 means ‘Processing Element’.

1.3. Intended Function

For ETSO-C153a CLASS PR, the intended function is to provide the capability to share the processing supplied by one or several processing unit(s).

The IMA module may include data storage and interfaces between hosted applications, modules and/or components; in this case, this class shall be combined with the DS and IF Classes.

The following figure provides an overview of the intended function of the above-mentioned IMA module and the associated definitions:

[Figure or form omitted from this preview — available in the Avioverse workspace library.]

Figure 15: IMA module overview for ETSO-C153a CLASS PR

2.Requirements

2.1. Functional requirements for ETSO-C153a CLASS PR

PR.a) The IMA module shall provide to hosted applications a Processing Resource which has the capacity to execute a set of instructions of a computer programme by performing the basic arithmetical, logical, and input/output operations of their Executable Object Code;

PR.b) The IMA module shall be able to host applications and/or Executable Object Code(s) components.

PR.c) The IMA module shall provide to hosted applications the capacity to share the Processing Resource thanks to Processing Elements managed through a logical interface, such as an Application Programme Interface (API).

[Figure or form omitted from this preview — available in the Avioverse workspace library.]

Figure 16: CLASS PR — the relationship between the processing elements

2.2. Characterisation requirements for ETSO-C153a CLASS PR

PR.d) All aspects of the processing performance of the shared Processing Unit of the IMA module shall be characterised, including, but not limited to, the following:

1.Processing Unit throughput (performance capacities and timings);

2.Performance of User Software/Software Interface (Core Software) Mechanism(s), Protocol(s), and Service(s);

3.Performance of User Hardware/Software Interface Mechanism(s), Protocol(s) and Service(s);

4.Performance of supported Processing Element Type (e.g. application, partition, process, thread, etc.);

5.Performance of Interrupt Mechanisms; and

6.Performance of Memory Management, including cache and Memory Management Unit (MMU).

Note: These performance requirements are additional to those applicable in Appendix 2.1 — COMMON.

3.Verification procedures

The following table gives the verification method for each MPS; nevertheless, an alternative method may be proposed to the certification authority:

Table 3: Verification Acceptance Criteria

(A*) means that verification by the Analysis method is possible for the item that cannot be tested.

Note (1): applicable for a functional subset cf. CO.gg).

[Amdt ETSO/10]

[Amdt ETSO/16]

CLASS GP: Graphical Processing

1.Purpose and scope

1.1. Introduction

This Appendix contains the Minimum Performance Standard (MPS) for the CLASS GP Intended Function: Graphical Processing.

These standards specify characteristics that should be useful to designers, manufacturers, installers and users of the IMA module.

1.2. Definitions

For ETSO-C153a CLASS GP, the IMA module provides shared resources in terms of graphical conversion and graphical laying out between hosted applications, modules and/or components based on commands coming from these hosted applications, modules and/or components.

The following definitions are used:

Graphical Thread: a set of graphical (displayable) information for which a level of isolation would be guaranteed by the IMA module.

Data Thread: a well-defined set of data which is a primary form of the drawing directives received as input by the IMA module from hosted applications, modules and/or components.

Command Thread: a well-defined set of command directives received as input by the IMA module from hosted applications, modules and/or components in order to change the conversion and laying out settings.

Graphical conversion: a transformation of a set of data information that is the primary form of drawing directives (data thread) into a set of displayable basic information.

Laying out: an operation consisting of a combination of merging or/and splitting actions of displayable basic information in order to build the final Graphical Thread to be rendered.

Conversion Unit: a set of physical components (hardware and/or software) in charge of graphical conversion.

Laying out Unit: a set of physical components (hardware and/or software) in charge of laying out.

Note:

both units can be merged in one unit; and the final rendering of the graphical thread(s) is out of the scope of this module (refer to CLASS DH).

In the context of GP class, the ‘concurrent item’ defined in Appendix 2.1, paragraph 1 means ‘Graphical and/or Command Thread’.

1.3. Intended Function

For ETSO-C153a CLASS GP, the intended function is to provide the capability to share graphical conversion and graphical laying out supplied by one or several graphical conversion and graphical laying out unit(s).

The function of the Graphical Processing Module is to receive commands from hosted applications, modules and/or components and optionally receive video from external analogue or digital sources to process them and to generate an image to display.

This intended function is Graphical Conversion and Laying out resource sharing composed of:

information acquisition and control;

information conversion and laying out; and information forwarding & control.

The following figure provides an overview of the above-mentioned IMA module intended function and associated definitions:

[Figure or form omitted from this preview — available in the Avioverse workspace library.]

Figure 17: IMA module overview for ETSO-C153a CLASS GP

2.Requirements

2.1. Functional requirements for ETSO-C153a CLASS GP

GP.a) The IMA module shall provide, to hosted applications, a Graphical Conversion Resource which has the capability to transform a set of drawing directives into a set of displayable basic information.

GP.b) The IMA module shall provide, to hosted applications, a Graphical Laying out Resource which has the capability to merge or/and split displayable basic information to build the final Graphical Thread(s) to be rendered.

GP.c) The IMA module shall provide to hosted applications, modules and/or components, the capability to change the graphical conversion and laying out settings through command threads.

GP.d) The IMA Module shall provide to hosted applications, modules and/or components, the capability to share a Graphical Conversion Resource and a Graphical Laying out Resource based on command threads managed through (a) logical and/or physical interface(s).

[Figure or form omitted from this preview — available in the Avioverse workspace library.]

Figure 18: CLASS GP — the relationship between the Graphical Processing (GP) elements

2.2. Characterisation requirements for ETSO-C153a CLASS

GP.e) The following aspects of the performance of the Graphical Unit(s) performance of the IMA module shall be quantified and guaranteed:

1.Graphical Unit(s) throughput (performance capacities and timings: response time, graphical update);

2.Performances of User Software/Software Interface (Core Software) Mechanism(s), Protocol(s), and Service(s);

3.Performance of User Hardware/Software Interface Mechanism(s), Protocol(s) and Service(s);

4.Establishment of Worst-Case Graphical Elaboration Time;

5.Performance of Interrupt Mechanisms;

6.Performance of supported Data Thread types;

7.Performance of supported Graphical Thread types; and

8.Performance of supported Command Thread types.

Note: These performance requirements are additional to those applicable in Appendix 2.1 — COMMON.

GP.f) In addition to the Common Requirement 0, particular emphasis shall be given to precluding or mitigating failures which could result in hazardously misleading information. Undetected loss of information or frozen information could contribute to hazardously misleading information.

Note: This is applicable to all the GP module functionality, including the implementation of image windowing, superimposition etc.

3.Verification procedures

The following table gives the verification method for each MPS; nevertheless, an alternative method may be proposed to the certification authority:

Table 4: Verification Acceptance Criteria

(A*) means that verification by the Analysis method is possible for the item that cannot be tested.

Note (1): applicable for a functional subset cf. CO.gg).

[Amdt ETSO/10]

[Amdt ETSO/16]

CLASS DS: Data Storage (DS)

1.Purpose and scope

1.1. Introduction

This Appendix contains the Minimum Performance Standard (MPS) for the CLASS DS Intended Function: Data Storage.

These standards specify characteristics that should be useful to designers, manufacturers, installers and users of the IMA module.

1.2. Definitions

For ETSO-C153a CLASS DS, the IMA module provides shared resources in terms of data storage between hosted applications, modules and/or components.

Data Storage refers to the storage of data in a continuing and machine-readable mode. A Data Storage module that records data may access both the separate portable (removable) recording component and/or a permanent component to store and retrieve data.

The following definitions are used:

Storage Unit: a set of physical components (hardware and/or software) in charge of supplying and managing recorded data resources (e.g. memory components and the associated interfaces, etc.)

Data Storage Element: a completely defined set of data storage which is a primary form of recorded data and for which a level of isolation would be guaranteed by the IMA module.

In the context of DS class, the ‘concurrent item’ defined in Appendix 2.1, paragraph 1 means ‘Data Storage Element’.

1.3. Intended Function

For ETSO-C153a CLASS DS, the intended function is to provide the capability to share recorded data or data storage space supplied by one or several storage unit(s).

2.Requirements

2.1. Functional requirements for ETSO-C153a CLASS DS

DS.a) The IMA module shall provide to hosted applications, modules and/or components, a Data Storage Resource which has the capacity to record or to retrieve a set of data on/from a storage unit by performing data-retaining operations.

DS.b) The IMA module shall provide to hosted applications, modules and/or components, the capacity to use shared recorded data resources thanks to data storage elements accessible through (a) logical and/or physical interface(s).

[Figure or form omitted from this preview — available in the Avioverse workspace library.]

Figure 19: CLASS DS — the relationship between the data storage elements

2.2. Characterisation requirements

DS.c) All aspects of the Data Storage performance of the shared Storage Unit of the IMA module shall be characterised, including but not limited to the following:

1.performances of Memory Management functionality, including the cache and Memory Management Unit (e.g. storage capacity, cache performance, etc.);

2.performance of (a) User Interface Mechanism(s), Protocol(s) and Service(s) (e.g. access timings and throughputs, etc.); and

3.performance of a supported Data Storage Element Type (e.g. namespace, address scheme, arbitrary principles for multiple access, throughputs, timings, data space, etc.).

Note: These performance requirements are additional to those applicable in Appendix 2.1 — COMMON.

3.Verification procedures

The following table gives the verification method for each MPS; nevertheless, an alternative method may be proposed to the certification authority:

Table 5: Verification Acceptance Criteria

(A*) means that verification by the Analysis method is possible for the item that cannot be tested.

Note (1): applicable for a functional subset cf. CO.gg).

[Amdt ETSO/10]

[Amdt ETSO/16]

CLASS IF: Interface

1.Purpose and scope

1.1. Introduction

This Appendix contains the Minimum Performance Standards (MPS) for the CLASS IF Intended Function: Interface.

These standards specify characteristics that should be useful to designers, manufacturers, installers and users of the IMA module.

1.2. Definitions

For ETSO-C153a CLASS IF, the IMA module provides shared resources in terms of interfaces between hosted applications, modules and/or components.

The following definitions are used:

Interface Unit: a set of hardware and/or software components in charge of supplying and managing a shared information resource.

Data Thread: a well-defined set of data which is a primary form of information and for which a level of isolation would be guaranteed by the IMA module.

Each data thread handled by the Interface, if so wished by the applicant, may be bidirectional or symmetrical between interconnected components, modules, or hosted applications.

In the context of IF class, the ‘concurrent item’ defined in Appendix 2.1, paragraph 1 means ‘Data Thread’.

1.3. Intended Function

For ETSO-C153a CLASS IF, the intended function is to provide the capability to share information supplied by one or several interfaces units.

This intended function is Information Sharing composed of:

information acquisition and control;

information conversion and; and information forwarding and control.

The information-forwarding and control function is the means that allows sharing information between components, modules and/or hosted applications.

The following figure provides an overview of the above-mentioned intended function and the associated definitions:

[Figure or form omitted from this preview — available in the Avioverse workspace library.]

Figure 20: IMA module overview for ETSO-C153a CLASS IF

2.Requirements

For ETSO-C153a CLASS IF, the IMA module provides shared resources for the communication needs of hosted applications, modules and/or components.

2.1. Functional requirements for ETSO-C153a CLASS IF:

IF.a) The IMA module shall provide to hosted applications, modules and/or components, an Information Resource which has the capacity to acquire from or to forward to an interface unit a set of data by performing information coding and decoding operations.

IF.b) The IMA module shall provide to hosted applications, modules and/or components, the capacity to use shared Information Resource thanks to Data Threads handled through logical and/or physical interface(s).

[Figure or form omitted from this preview — available in the Avioverse workspace library.]

Figure 21: The relationship between CLASS IF interface (IF) elements

1.1. Characterisation requirements for ETSO-C153a CLASS IF:

IF.c) All performances of the shared Interface Unit of the IMA module shall be characterised, including but not limited to the following:

1.performance of each Interface, including its throughput, acquisition speed, forwarding speed, latency, jitter, coding rate and decoding rate;

2.performance of (a) User Interface Mechanism(s), Protocol(s) and Service(s) (e.g. socket timing, communication port timing, technological time delay, etc.); and

3.performance of supported Data Thread Type (e.g. virtual link, channel, pipe-and-filter, physical connection pin, etc.).

Note: These performance requirements are additional to those applicable in Appendix 2.1 — COMMON.

IF.d) In addition to the Common Requirement 0, the characterisation shall address the safety aspects of frozen data.

2.Verification procedures

The following table gives the verification method for each MPS; nevertheless, an alternative method may be proposed to the certification authority:

Table 6: Verification Acceptance Criteria

(A*) means that verification by the Analysis method is possible for the item that cannot be tested.

Note (1): applicable for a functional subset cf. CO.gg).

[Amdt ETSO/10]

[Amdt ETSO/16]

CLASS PS: Power Supply (PS)

1.Purpose and scope

1.1. Introduction

This Appendix contains the Minimum Performance Standard (MPS) for the CLASS PS Intended Function: Power Supply (PS).

These standards specify module characteristics that should be useful to designers, manufacturers, installers and users of the module.

1.2. Definitions

For ETSO-C153a CLASS PS, the IMA module is a module, mounted into a rack or the rack itself, able to supply power received from the aircraft electrical network to one or more hardware modules mounted in the same rack.

The following definitions are used:

Power supply unit: a set of physical components (hardware and or software) in charge of managing a power supply (or a part of the power supply) resource.

Power supply resource: obtained electrical energy from the aircraft electrical network to be distributed to electrical loads which are modules mounted into the rack.

Power rail: a part of supplied electrical energy for which a level of isolation is guaranteed by the IMA module.

Mounted: it refers to another hardware module installed and fixed inside the IMA Rack Module after a manual operation.

Slot: a physical space inside the Rack Module allocated to one hardware module.

Hold-up Capacity: The capacity of the power supply to continue supplying output current after the input voltage drops below the minimum level. This is usually expressed as the time from the input voltage drop to the reset generated by the power supply to the processor.

Output Current Capacity: the continuously operating maximum current supplied for each output voltage.

Power Monitors & Status Outputs: a separate circuitry which checks the output voltage levels and current loading of the power supply. This circuitry will generate one or more binary signals that may be connected to the processor to alert it to the ‘out of spec’ condition. These binary signals may also force the power supply to shutdown to prevent damage to power supply components.

Power Resets: a binary signal output from the power supply that is asserted when the output voltages are outside acceptable tolerances.

Regulation: the percentage of variation of the output voltages when subjected to changes in load, changes in temperature, and changes in all input voltage transients and deviations.

Transient Immunity: the ability of the power supply to continue operating normally during variations in the input voltage. This is usually expressed as the time duration and the voltage level of the transient.

Voltage Outputs and Tolerances: the voltage levels and tolerances of the outputs produced by the power supply.

In the context of PS class, the ‘concurrent item’ defined in Appendix 2.1, paragraph 1 means ‘Power Rail’.

1.3. Intended Function

For ETSO-C153a CLASS PS, the intended function is to provide the capability to share the Power Supply resource supplied by one or more Power Supply unit(s).

The following figure provides an overview of the above-mentioned intended function and definitions:

[Figure or form omitted from this preview — available in the Avioverse workspace library.]

Figure 22: IMA module overview of ETSO-C153a CLASS PS

2.Requirements

2.1. Functional requirements for ETSO-C153a CLASS PS

PS.a) The IMA module shall provide to hardware modules mounted in the same rack Power Supply Resource which has the capacity to deliver a quantity of electrical energy from power supply unit(s) to the hardware modules while performing the regulation operations.

PS.b) The IMA module shall provide to hardware modules mounted into the same rack the capacity to share the power supply resource thanks to power rails accessible through physical interface(s).

[Figure or form omitted from this preview — available in the Avioverse workspace library.]

Figure 23: CLASS PS (PS) — the relationship between the elements

2.2. Characterisation requirements

PS.c) All aspects of the performance of the Power Supply of the shared Power Supply Unit of the IMA module shall be characterised, including but not limited to the following:

1.The needed input power budget characteristics (e.g. as a function of temperature and load)

2.The performance of Output Currents and Tolerances;

3.The performance of Hold-up Capacity;

4.The performance of Power Monitors and Status Outputs;

5.The performance of Power Resets;

6.The performance of Power Regulation;

7.The performance of Transient Immunity;

8.The performance of Voltage Outputs and Tolerances;

9.The performance of User Interface Mechanism(s), Protocol(s) and Service(s);

10.The performance of a supported Power Rail Type;

11.The Input and Output impedance; and

12.The capacitive load.

Note: These performance requirements are additional to those applicable to and dictated by the design of the IMA module itself (according to the ‘COMMON’ requirement of Appendix 2.1).

PS.d) In addition to the Common Requirement 0, the characterisation shall address the safety aspects of events such as a too low voltage or current, and a too high voltage or current. The transient, as well as permanent effects, shall also be characterised, if relevant.

PS.e) The characterisation shall provide any data needed to evaluate the power profile characteristics (e.g. Maximum Value, InRush Current) of managed power rails, and the IMA module power on/power off behaviour characteristics.

3.Verification procedures

The following table gives the verification method for each MPS; nevertheless, an alternative method may be proposed to the certification authority:

Table 7: Verification Acceptance Criteria

(A*) means that verification by the Analysis method is possible for the item that cannot be tested.

Note (1): applicable for a functional subset cf. CO.gg.

[Amdt ETSO/10]

[Amdt ETSO/16]

CLASS DH: Display Head

1.Purpose and scope

1.1. Introduction

This Appendix contains the Minimum Performance Standards (MPS) for the CLASS DH Intended Function: Display Head.

These standards specify characteristics that should be useful to designers, manufacturers, installers and users of the module.

1.2. Definitions

For ETSO-C153a CLASS DH, the IMA module provides shared resources in terms of a display area between hosted applications, components and/or modules.

The following definitions are used:

Display Unit: a set of physical components (hardware and/or software) in charge of managing a display area (or a part thereof).

Display Area: a surface where some visual information can be depicted by one or several Display Unit(s) based on received Graphical Threads.

Graphical Thread: a set of graphical information received as input by the Display Head from one or more IMA application(s), component(s) and/or module(s).

Display Thread: a set of depiction information for which a level of isolation on the Display Area is guaranteed by the Display Head.

In the context of DH class, the ‘concurrent item’ defined in Appendix 2.1, paragraph 1 means ‘Display Thread’.

1.3. Intended Function

For ETSO-C153a CLASS DH, the intended function is to provide the capability to share one display area supplied by one or several display unit(s).

The intended function of such an IMA module is to offer the capability to depict graphical information received from (an) IMA application(s), component(s) and/or module(s) on one Display Area.

The following figure provides an overview of the above-mentioned intended function and the associated interfaces:

[Figure or form omitted from this preview — available in the Avioverse workspace library.]

Figure 24: IMA module overview of ETSO-C153a CLASS DH

2.Requirements

2.1. Functional requirements for ETSO-C153a CLASS DH

DH.a) The IMA module shall provide to hosted applications, modules and/or components, a Display Area Resource which has the capability to render visual graphical information.

DH.b) The IMA module shall be fully or partially compliant with the MPS as from the applicable release of ETSO-C113.

Note 1: these performance requirements are additional to those applicable in Appendix 2.1 — COMMON.

Note 2: for Display Head modules without a Graphics generation function, compliance demonstration to some ETSO-C113 requirements might not be possible. In such cases, the applicant shall submit in the compliance data package the list of requirements that need further demonstration with regard to the C113 requirements providing a relevant justification.

DH.c) The IMA module shall provide to hosted applications, modules and/or components the capability to share a Display Area resource managed through a logical or physical interface.

[Figure or form omitted from this preview — available in the Avioverse workspace library.]

Figure 25: The relationship between CLASS DH Display Head elements

2.2. Characterisation requirements for ETSO-C153a CLASS DH

DH.d) In addition to the Common Requirement 0, the characterisation shall address the safety aspects of delay and/or frozen information.

DH.e) In addition to Common Requirement 0, the characterisation shall include any data needed to evaluate the Worst-Case Display Elaboration Time of managed threads, and the characteristics required by the applicable release of SAE AS8034 (as per the applicable revision of ETSO-C113).

DH.f) The additional activities to be performed by the user related to the applicable release of ETSO-C113 for complete compliance demonstration shall be included in the characterisation for gap identification.

3.Verification procedures

The following table gives a verification method for each MPS; nevertheless, an alternative method may be proposed to the certification authority:

Table 8: Verification Acceptance Criteria

(A*) means that verification by the Analysis method is possible for the item that cannot be tested.

Note (1): for the functional subset, see CO.gg.

Note (2): an applicable revision of ETSO-C113 defining the verification requirements of a display function.

[Amdt ETSO/10]

[Amdt ETSO/16]

For an IMA module authorisation, as mentioned in paragraph 2.2 of the ETSO-C153a main body document, additional technical data shall be available or submitted. This data will be documented into a set of documents for the ETSO authorisation (qualification plans, compliance evidences, etc.) and for the IMA module users such as Application developers, Integrators or type certificate applicants (User Guide, Usage domain, etc.):

Chapter 1 — IMA module ED-124 documentation;

Chapter 2 — Specific User Guide and Installation Manual contents;

Chapter 3 — Core software;

Chapter 4 — Health management and reporting;

Chapter 5 — Usage domain;

Chapter 6 — Configuration;

Chapter 7 — Tools; and Chapter 8 — Compatibility & mixability information.

Chapter 1 — IMA module ED-124 documentation

The IMA system approval can be made incremental by introducing some intermediate acceptance steps. An ETSO-C153a authorisation is the first intermediate step dedicated to authorising IMA platforms and/or IMA modules (independently of any specific aircraft installation).

EUROCAE ED-124/RTCA DO-297 contains guidance for Integrated Modular Avionics (IMA) developers, application developers, integrators, certification applicants, and those involved in the approval and continued airworthiness of IMA systems in civil certification projects.

As mentioned in paragraph 3.2.2.1 of the ETSO-C153a main body document, to prepare the integration of the ETSO-C153a IMA module, the development objectives are defined in the EUROCAE ED-124 guidance related to Task 1 (Table A-1 objectives).

For an ETSO-C153a approval, the following data are available (A) or submitted (S) to the competent authority:

Note (1): this Partitioning Analysis shall include the verification results obtained for demonstration of compliance of 0, 0, 0, and 0.

Note (2): only for User Guide content used for ETSO compliance demonstration.

Chapter 2 — Specific User Guide and Installation Manual contents

As per ED-124, the IMA module User guide shall be provided by the IMA module manufacturer to both the module users and the Airworthiness Authority.

This User Guide includes all the information for users, integrators, and certification applicants to successfully interface with or integrate the module, such as:

guaranteed behaviour and characteristics as per CO.k);

interfaces (incl. physical mapping of interfaces);

limitations and Open Problem Reports (OPRs)(1) (including tools);

the Worst-Case Execution Time (WCET) analysis elements;

the applicable Failure Mode Effect Analysis/Failure Mode Effect Summary (extracts) necessary for higher level safety analysis;

the Core Software (see Appendix 3, Chapter 3);

Fault Management and Health Monitoring (see Appendix 3, Chapter 4);

the Usage Domain (see Appendix 3, Chapter 5) ;

configuration aspects (see Appendix 3, Chapter6);

tools aspects (see Appendix 3, Chapter 7);

compatibility and mixability information (see Appendix 3, Chapter 8);

remaining activities to be conducted by the module user to complete the IMA module qualification (environment);

requirements recommendations for applications (e.g. data for the qualification of the application, service available for applications, etc.); and requirements recommendations for System Integration.

(1)An explicit description of the root cause and effects of an IMA module OPR is necessary to support the IMA module user and aircraft manufacturer in their assessment of the effects of the OPR on the aircraft function.

The Installation Manual includes all the data necessary for the proper installation and use of the IMA module (including marking aspects).

Each item of the characterisation and functional requirements is addressed in the User Guide (or possibly in the Installation Manual, if appropriate).

The User Guide defines the Usage Domain for which the module acceptance data is valid.

The information includes recommendations and may also include examples of the correct use of the module. In addition, the guide highlights any warnings or limitations to integrate or to interface with the module to prevent potential incorrect or unintended use.

The User Guide may be completed by the IMA module manufacturer with:

information on Single Event Upset (SEU) effects;

a Validation and Integration Kit for application developers and system integrators;

Development and In-Service support; and some training.

The Installation Manual includes information as required in the MPS Appendix or referenced subsequent applicable chapter of the User Guide. In this case, the User Guide chapter will be submitted to the Airworthiness Authority (see Note (*) above).

The User Guide may be included in the Installation Manual of the IMA module (e.g. Annexes) or a separated document referenced by the Installation Manual.

Chapter 3 — Core Software

As defined in Appendix 1 above, the IMA module may be an association of Hardware and Core Software.

Core Software is consists of the operating system and the support software that manage resources to provide an environment in which the intended function is performed. Core software is typically comprised of one or more component(s). Core Software may be resident or a Field-Loadable Software part.

If the IMA module contains Core Software, the Core Software characteristics required by 0 of Appendix 2 are documented in the IMA module User Guide.

Chapter 4 — Health management and reporting

The data requirements related to health management and reporting are listed in 0.

Chapter 5 — IMA module usage domain

An ETSO-C153a authorisation relies on the concept of a Usage Domain (as per Chapter 2 — Definitions of Appendix 1).

The usage domain is defined at the IMA module level and used at the Application level and the IMA system level.

The definition of the usage domain includes consideration of the module functionality, performance and safety requirements, as well as of the required environmental performance of the module.

The IMA module manufactured to comply with this ETSO may be used to support other ETSOs or systems approved under CS-23, CS-25, CS-27, CS-29, CS-E or CS-P. These ETSO authorisations, IMA system approvals and aircraft level approvals, are not covered by this ETSO but will rely on the fact that compliance with the Usage Domain as documented in the User Guide, is correctly implemented.

Chapter 6 — Configuration

The IMA module may need to be configured before installation in the IMA system (EUROCAEED-124, Tasks 2, 3 and 4).

The data requirements related to configurability are listed in 0 of Appendix 2.

Chapter 7 — Tools

Some tolls may need to be used during the installation of the IMA module in the IMA system (EUROCAE ED-124 Tasks 2, 3 and 4). These tools may be used by:

application developers;

(an)integrator(s); and type certificate (TC) or supplemental type certificate (STC) applicants.

These tools may address:

software development (hosted applications);

configuration development;

network architecture and configuration;

debug, data loading; and WCET analysis and measures.

In that case, the User Guide references each tool in the data listed in Appendix 2 0.

If qualification credit is expected from these tools(such as configuration tools), the qualification process and data requirements are defined in paragraph 2.2 of CS-ETSO Subpart A. Software standards as well as the Airborne Electronic Hardware Qualification data of paragraph 2.3 are considered to be data to be submitted to EASA in the frame of an ETSO-C153a authorisation.

Chapter 8 — Compatibility and mixability information

The IMA module manufacturer provides compatibility and mixability information between hardware, software, tools and the usage domain in the User Guide, as required per 0 of Appendix 2.

[Amdt ETSO/10]

[Amdt ETSO/16]

Section 2.3 of CS-ETSO Subpart A requires environmental testing to be performed according to the appropriate release of EUROCAE ED-14/RTCA DO-160.

For ETSO-C153a, some particularities have to be addressed:

the representativeness of the Test Software;

the Applicable Test Procedures; and the parameters to be monitored during the Environmental Qualification Test.

Chapter 1 — The representativeness of the Test Software

If the IMA module is qualified without the functional software installed and operating, engineering analysis from the manufacturer must determine that the Test Software (not the target functional software) is representative of the usage domain stress envelope for the environmental tests (i.e. dissipated temperature, power consumption, field radiation, etc.).

Test Software shall be developed to exercise the hardware in performing the environmental tests in the worst-case conditions and/or most sensitive configurations in order to evaluate the robustness of the IMA module over the full Usage Domain. For example, the Test Software should exercise all the physical interfaces with a maximum number of applications or inputs, and with filter values set to the domain boundary which would be the most transparent to any input electrical interference.

Chapter 2 — Applicable Test Procedures

For an ETSO-C153a authorisation, the IMA module may be a single Line Replaceable Unit (LRU) platform or may be a Line Replaceable Module (LRM) located in a Rack.

Depending on the characteristics of the IMA module, the applicant should consider one of the two following cases as appropriate:

Case 1: the IMA module is a single LRU platform; and Case 2: the IMA module is a module designed to be located in a Rack at installation.

Note: The Rack Housing module is not addressed in this generic Appendix but in the relevant Appendix 2.2 — Class RH: Rack Housing.

Chapter 2.1 — The IMA module is a single LRU platform

In this case, the environmental sections defined in the Table below (Figure ) are applicable to the IMA module.

The usage domain of the IMA module must be defined and maintained so that all the environmental qualification tests listed below produce a complete credit for all other functional ETSOs authorisations, or for the TC level.

Figure 26 — Environmental Qualification for ETSO-C153a in the case of a single LRU platform

Chapter 2.2 — The IMA module is a module designed to be located in a Rack at installation or the rack itself.

In this type of envisioned installation, only a minimal subset of environmental conditions is applicable to the IMA module. This minimal subset is defined as mandatory in the table below (Figure 27).

Test sections identified as optional are not required for an ETSO-C153a application. Nevertheless, the IMA module can be subjected to these test conditions on a voluntary basis. When optional sections are not tested, they shall be marked with ‘X’.

The Environmental Qualification Testing (EQT) will be completed after cabinet integration in the frame of some other functional ETSOs authorisation, or of a TC level.

The usage domain of the IMA module must be defined and maintained so that at least this subset of qualification tests produces some credit for other ETSOs authorisations and for the TC level.

Note: It is acceptable to perform the environmental qualification on the intended rack installation equipped with (a) mounted IMA module(s). The ETSO-C153a IMA module should be set in worst-case configurations. By doing so, the set of Qualification documents (Qualification Test Plans, Procedures and Reports) may be common to both the rack and the module ETSO-C153a authorisations. These documents should demonstrate that the considered configurations (which may differ depending on the different sections of EUROCAE ED-14/RTCA DO-160) are the worst-cases for the set of authorised modules configurations within the rack. Whatever the qualification method used, the authorised configuration should be specified in the installation manual(s).

Such documented authorised configurations include any installation limitations that are taken as hypotheses for the EQT (rack part number(s), slot number(s), blade neighbourhood(s), and temperature to be guaranteed), and need to be specified in the Installation Manual and respected by the integrator so that he/she can take credit for the EQT performed at module level.

Figure 27: Environmental Qualification Testing minimum subset for ETSO-C153a in for cabinet architectures

Chapter 3 — MPS compliance during EQT

When required by the test conditions and procedure (by the ‘DETERMINE COMPLIANCE WITH EQUIPEMENT PERFORMANCE STANDARDS’ statement), the IMA module manufacturer must determine compliance with the MPS as defined under the column ‘Test under environmental conditions’ of each individual class in Appendix 2:

Figure 28 — MPS verification under environmental conditions

[Amdt ETSO/10]

[Amdt ETSO/16]