AMC 20-170 Integrated modular avionics (IMA)

ED Decision 2018/008/R

1.         Introduction

1.1.     Purpose

This Acceptable Means of Compliance (AMC) provides a means that can be used to demonstrate that the safety aspects of integrated modular avionics (IMA) systems comply with the airworthiness requirements when such systems are integrated in a product, a part, or an appliance submitted to EASA for approval.

Compliance with this AMC is not mandatory and hence an applicant may elect to use alternative means of compliance. However, those alternative means of compliance must meet the relevant certification specifications, ensure an equivalent level of safety, and be accepted by EASA on a product basis.

1.2.     Scope and applicability

The guidance contained in this AMC applies to any type certificate (TC) or supplemental type certificate (STC) applicants seeking approval from EASA for IMA systems installed in aircraft or rotorcraft.

IMA is a shared set of flexible, reusable and interoperable hardware and software resources that, when integrated, form a system that provides computing resources and services to hosted applications performing aircraft functions [ED-124].

An IMA architecture may integrate several 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 line replaceable units (LRUs).

This AMC addresses certification considerations for IMA systems, and should apply when:

—            hosted applications* on the same platform are designed, verified and integrated independently (at application level**) from each other; and

—            the platforms/modules provide shared resources (typically designed, verified and integrated independently from the hosted applications),

OR

—            a process for obtaining incremental certification*** credit is anticipated or applied.

*          A single application hosted on an independently developed platform is considered to be a traditional federated architecture and thus is not subject to this AMC. However, if additional application(s) that is (are) independently developed is (are) hosted on the same platform at a later stage (e.g. through a major change), this AMC should be applied.

**       Software integration/verification activities are not performed on the whole set of integrated software as in a federated architecture.

***     Credit for incremental certification in an IMA context as detailed in Section 4.

An applicant may choose to apply this AMC for a system which would not fulfil the conditions above. In that case, early discussions should take place between the applicant and EASA in order to confirm whether this AMC should be followed or not.

1.3.     Document overview

This document:

(a)       provides an overview of and background information on IMA systems and on concerns related to their certification (Section 2);

(b)       presents the EASA policy for IMA certification by recognising the use of EUROCAE document ED-124, Integrated Modular Avionics (IMA) Development Guidance and Certification Considerations, as an acceptable means of compliance for the development and certification of IMA systems. It also clarifies and amends the intent, scope, and use of that document (in Section 3);

(c)       introduces the incremental certification approach, and introduces the link to ETSO authorisations (ETSOAs) (in Section 4);

(d)       complements ED-124 with additional considerations on dedicated topics, such as environmental qualification, open problem reports (OPRs), and configuration files (in Section 5).

1.4.     Documents to be used with this AMC

This AMC should be used together with the following documents. The applicable version of the documents for a given project will be established in the certification basis or in the applicable CRIs.

*          ED-79A should be used, unless ED-79 is the applicable document in a given project.

**       Recommendations for software are developed in AMC 20-115().

1.5.     Referenced material

1.5.1. Certification specifications (CS) and acceptable means of compliance (AMC)

The applicable version of the documents for a given project will be established in the certification basis or in the applicable CRIs.

1.5.2. Referenced documents

1.6.     Definitions and abbreviations

1.6.1. Definitions

1.6.2. Abbreviations

2.         Background

The use of IMA has rapidly expanded in the last two decades and is expected to progress even more in the future in all types of products, parts and appliances. Additional guidance is hence needed to address specific aspects at the application, component, platform, system, and aircraft levels.

2.1.     IMA overview

A representation of a simple IMA architecture is illustrated in Figure 1:

—            Applications implementing several aircraft functions are hosted on the same platform. Several applications (e.g. Applications 1.1 & 1.2) may contribute to the same aircraft function.

—            The platform consists of:

—             a hardware layer offering resources shared by the applications; and

—             a software layer, also known as ‘middleware’, including the operating system, health monitoring, various kinds of services and hardware drivers (core software [ED-124] and support software [ETSO-2C153]).

—            Through the middleware, the platform mainly:

—             provides services to the software applications;

—             manages the interfaces between software applications;

—             manages the internal/external resources shared between software applications; and

—             ensures isolation between applications.

—            External inputs/outputs (I/Os) may encompass a wide scope of interfaces such as discrete data, various data buses or analogue signals.

—            The software applications and the platform may be independently provided by different stakeholders (i.e. different system suppliers, or entities pertaining to the same company/group).

Figure 1 — Illustration of an IMA architecture

Note: Examples of different classes of electronic hardware parts constituting a platform/module can be found in ETSO-2C153.

Figure 2 shows a functional projection of an IMA architecture at aircraft level:

—            Each aircraft function may have its own set of LRUs connected to the platform (which provides/gets the data to/from the application).

—            The set of I/O may cover a large range of items, such as:

—             input items: data from sensors, control panels, data received from other applications/systems;

—             output items: data to actuators, displays, and data transmitted to other applications/systems.

Figure 2 — Functional projection of an IMA architecture at aircraft level

An example of an IMA architecture is illustrated in Figure 3.

Figure 3 — Illustration of an IMA architecture

2.2.     IMA system breakdown into aircraft systems (ATA chapters)

The organisation of an IMA system into aircraft systems (e.g. ATA chapters) provides structure to a certification project and to the methods used to demonstrate compliance. This breakdown may depend on (this list is not exhaustive):

—            the aircraft and systems’ architecture;

—            the industrial organisation and work sharing;

—            the applicant’s development methods; and/or

—            the aircraft maintenance principles and procedures (closely linked to ATA-XX chaptering).

Note: Applicants may elect to address the IMA items and activities (not the hosted functions) within an ATA chapter dedicated to IMA systems such as ATA-42.

2.3.     IMA certification concerns

From a certification viewpoint, the use of an IMA architecture raises the following concerns:

—            failures or faults of the IMA platforms (including hosted applications) or LRUs connected to the communication network and the associated interfaces may cause the malfunction, loss or partial loss of more than one function;

—            the potential for some failures to propagate and create multiple failure conditions;

—            the lack of design independence among common hardware resources;

—            susceptibility to common mode failures, faults or design errors, within several identical modules or within the communication network;

—            a lack of assurance that the system will behave as intended once all the hosted applications are integrated onto the platform/modules, when software and electronic hardware items have been independently developed and verified;

—            inappropriate resource management leading to potential access conflicts and a lack of determinism or unexpected system behaviour; and

—            improper isolation mechanisms or configuration not ensuring correct partitioning between functions.

2.4.     Functional isolation and independence

From a safety perspective, the primary purpose of the IMA design and certification activities is to demonstrate that the level of functional isolation and independence between the aircraft functions hosted in the IMA system is equivalent to that which would be achieved in a federated architecture.

Functional isolation mostly relies on three pillars:

—            proper allocation of shared resources, to prevent adverse interference between hosted applications;

—            robust partitioning, concretely assuring the isolation and detection/mitigation of partitioning violations;

—            fault containment, to prevent the propagation of faults between hosted applications.

3.         Policy for IMA system certification

This section provides guidance to be used for the certification of an IMA system. Considering the IMA architecture, industrial organisation, and the experience in IMA system development of the applicant, several approaches are considered:

—             use of the ED-124 standard;

—             use of an alternative means to demonstrate compliance;

—             use of previously recognised IMA certification processes.

3.1.     Use of ED-124

3.1.1. Recognition of ED-124

EUROCAE document ED-124 on Integrated Modular Avionics (IMA) Development Guidance and Certification Considerations, published in July 2007 (equivalent to the RTCA document DO-297), provides guidance for the development and certification of IMA systems.

The use of ED-124 is acceptable to EASA to support the certification of IMA systems when it is used in conjunction with the additional considerations described in this AMC.

3.1.2. Scope of this AMC with respect to ED-124

ED-124 encompasses various aspects and some concepts which are not compatible with the EASA system or which are considered to be outside the scope of this AMC:

—             It is not the intent of this AMC to cover the development processes for aircraft functions, even if they are implemented by applications hosted in an IMA system.

—             In relationship with ED-124, it is not the intent of this AMC to cover:

—             operational aspects of master minimum equipment lists (MMELs) (ED-124 Chapter 3.9);

—             considerations for continued airworthiness (ED-124 Chapter 6);

—             the safety assessment process (ED-124 Chapter 5.1).

—             The cybersecurity aspects (ED-124 Chapter 5.1.5.8) are not adequate, and should be superseded by the applicable cybersecurity standards as defined in the project certification basis.

—             Regarding the incremental certification process presented in ED-124:

—             the ‘letter of acceptance’ concept is not feasible in the EASA context. The certification given by EASA is limited to only a specific aircraft type certification (TC), or to a subsequent aircraft level certification of a system change or in the frame of a supplemental type certificate (STC), or granted through an ETSOA;

—             the alternate concept of ‘reusable software component (RSC)’ acceptance as described in ED-124 Chapter 4, Table 4, with reference to FAA AC 20-148, is not feasible in the EASA context as it makes use of acceptance letters for software parts.

3.1.3. Clarification and use of ED-124

ED-124 defines a complete ‘end-to-end’ framework and a set of objectives to support the certification of IMA systems, i.e. from the development of software/airborne electronic hardware (SW/AEH) items to aircraft integration.

As it covers the complete development and certification of IMA systems, ED-124 may contain some objectives, activities and life cycle data similar to those that apply to a federated architecture, and which may not be IMA-specific. Additionally, some considerations in ED-124 may overlap or may be considered to be addressed by other applicable guidance documents (e.g. ED-79).

The way in which ED-124 was written, e.g. by allocating objectives, activities and life cycle data to the various ‘tasks’, should therefore not be interpreted:

—             as imposing a unique scheme in terms of the project organisation, sequencing of activities and expected life cycle data required to meet the objectives; or

—              as requesting the duplication of activities or life cycle data.

The following sections further explain the flexibility which is inherent in the ED-124 approach and which is fully recognised by EASA.

3.1.3.1. The ED-124 task framework

ED-124 structures the IMA development activities by tasks and objectives to be achieved at the AEH/SW/module item level. This framework also suggests a definition of roles and responsibilities of the different stakeholders involved in the IMA system development (e.g. application supplier, IMA system integrator).

Figure 4 illustrates a mapping between an IMA system breakdown and the certification tasks of ED-124:

Figure 4 — Mapping between an IMA system and the ED-124 certification tasks

Among the considerations detailed in the ED-124 tasks, the key IMA specificities are:

—             Task 1: the need to develop resources/services to be shared by applications and the adequate associated mechanisms (partitioning, health monitoring, etc.), and the need to document these resources, services and mechanisms for the IMA platform users;

—             Task 2: the need to characterise the applications in terms of their resource usage and execution constraints, and the need to verify that the applications satisfy the usage domain of the platform;

—             Task 3: the need to verify that the whole set of applications complies with the platform usage domain, and the proper implementation of the resource allocation and platform configuration requests from the applications;

—             Task 4: has little specificity in comparison with non-IMA systems.

3.1.3.2. Relationship with other guidelines

In order to maximise the credit taken from other standards and existing processes, two certification approaches based on the ED-124 tasks and objectives are considered eligible to support an IMA system certification:

(a)       an IMA system perspective: by considering the application of ED-124 as a complete and consistent set of objectives;

(b)       an aircraft perspective: where the IMA system certification and its specificities are addressed within the global framework of the aircraft certification and its related processes. This means that ED-124 considerations/objectives may be covered by other aircraft system processes and activities.

As ED-79 provides guidance and acceptable means of compliance for the development of systems, ED-79 processes may be used to cover ED-124 objectives and activities. However, the use of ED-79 will not ensure exhaustive coverage of the ED-124 objectives. Consequently, the IMA-specific objectives and activities of ED-124 will remain to be addressed separately from the ED-79 objectives.

These two approaches are suitable because they would ensure the completeness of the activities supporting an IMA system certification.

Figure 5 — Links between ED-124 tasks and other guidelines

3.1.3.3. Tailoring of ED-124 tasks

A task framework is proposed by ED-124, but it is not the purpose of AMC 20-170 to enforce this division of tasks. The allocation of the ED-124 objectives to the ED-124 tasks can be tailored by the applicant.

For instance, an IMA specificity is the need to coordinate verification activities such that the performance of the integrated IMA system can be guaranteed without requiring the reverification of each hosted application on the entire integrated system:

—             ED-124 Chapter 3.1.3 d.2 may be interpreted as requesting that IMA integration should be performed with the full set of applications. However, the applicant may integrate and verify applications independently on the IMA platform, taking into account the platform properties (e.g. robust partitioning and resource management).

—             Some Task 3 objectives may be already anticipated and accomplished during Task 2, or they may be deferred to Task 4.

If the applicant intends to develop an IMA system and the supported aircraft functions by tailoring the ED-124 tasks or by following another framework, the applicant should detail the division of tasks, the objectives of each work package, and the associated activities.

The applicant should describe how the work package objectives are mapped to the ED-124 objectives in order to ensure that the objectives of ED-124 are met within the alternative framework presented by the applicant. The ED-124 life cycle data can be also adapted to the division of tasks and work packages defined by the applicant.

Moreover, ED-124 Task 4 may have few IMA specificities compared to a federated architecture. The achievement of Task 4 to support compliance demonstration in the frame of this AMC could be deemed to be outside the scope of this AMC, provided that:

—             the aircraft integration activity is covered through other guidance and its related applicant processes (to be clarified in the certification plan);

—             Task 3 is complete: meaning that no objectives, activities, or life cycle data are deferred to or covered by Task 4.

Another area where tailoring can be performed is requirement validation. ED-124 Chapter 5.3.a. considers that each level of requirements within the hierarchy should be validated prior to validating the next lower level. A strict interpretation of this statement would not allow the development of a platform based on the assumptions for the intended use without consideration of the final aircraft functions (as suggested in Chapter 4.2.1.b). Also, it would imply a top-down approach from the aircraft functions to the level of hardware and the core/support software, which may not be relevant. A bottom-up approach is also feasible, which involves ensuring that the platform usage rules and constraints identified in the platform user guide/manual (Chapter 4.2.12.e.) are fulfilled, and that they satisfy the IMA system requirements.

3.1.4. Use of alternative means to demonstrate compliance

If an applicant elects to comply with an alternative means to demonstrate compliance with the CS, consistency with the ED-124 acceptance objectives in Annex A tables [A1-A6] (IMA module/platform development process objectives) should be demonstrated.

Early coordination with EASA should be ensured.

3.2.     Use of previously recognised means of compliance

Applicants who did not use this AMC in their past IMA certifications and who successfully used other means of compliance that were:

—            discussed in specific CRI(s);

—            previously recognised as equivalent to the ED-124 objectives; and

—            previously accepted by EASA for covering IMA certification concerns,

may use the same means of compliance for their certification project, provided that the IMA system is similar to the previously certified one (i.e. with a similar architecture, the same design concepts, the same development process, and the same certification approach).

Early coordination with EASA to confirm the use of the applicant’s previously recognised means of compliance should be ensured.

3.3.     Role of the IMA system certification plan

ED-124 objectives can be met by using various industrial mappings, based on the sharing of roles, activities and life cycle data. The strategy selected for demonstration of compliance with this AMC should be defined by the applicant in their certification plans.

An IMA system certification plan should introduce the planning, the organisation, the work share, work packages, and the development, validation, integration, and verification activities of the IMA system.

Considerations regarding the content of an IMA system certification plan can be found in ED-124 Chapter 4.4.3. The certification plan should particularly emphasise the following topics:

—            The scope covered by the IMA system certification plan and its relationship with other certification plans, including the certification plans of the aircraft functions hosted (totally or partially) on the IMA system.

—            The strategy proposed by the applicant to demonstrate compliance with this AMC, including:

—             the certification approach selected (see paragraph 3);

—             the relationship and credit potentially taken from other standards or processes to satisfy the objectives of ED-124;

—             the nature and extent of credit claimed from previously approved components (i.e. having obtained an ETSOA) or from activities performed on components reused from previous certification projects (see paragraph 4);

—             the identification of modules, platforms and applications for which full or partial incremental compliance credit is sought.

—            The industrial organisation supporting the IMA system development and certification, including the roles, responsibilities and work share between the stakeholders, with, in particular:

—             the sharing of activities related to aircraft functions hosted on the IMA platform and the IMA system integration activities;

—             when applicable, the tailoring and scope of the ED-124 tasks, or ED-124 life cycle data;

—             the work package allocated to each IMA stakeholder, including the design, validation, verification and integration activities, including environmental qualification under their responsibility and the credit claimed for the incremental certification.

—            The activities planned for the integration of the IMA system and its installation on an aircraft with an emphasis on:

—             the establishment of full or partial incremental credit gained from the integration, validation and verification activities conducted at each stage of the development, with their associated transition criteria. If a future step cannot be planned by a stakeholder, who for instance would

—             only perform the development of a function, the interface to future steps and the assumptions made (e.g. on resources used) need to be identified;

—              the credit expected from the characteristics of the IMA platform to independently verify aircraft functions allocated or partially allocated to the IMA system;

—             the activities to be completed for the installation of an ETSO-2C153 or C214 article;

—             the rationale for not performing some ground or flight tests when the IMA system is installed on the aircraft.

—            A description of the development and verification environments, with emphasis on the tools used to generate data or automate the activities and the rationale for the qualification or non-qualification of the tools.

Note: A dedicated IMA system certification plan may not be required provided that its role is equivalently performed by a comprehensive set of documents in the applicant’s data package.

4.         Incremental certification process

As indicated in Section 3.1.2, the concepts of ‘letters of acceptance’ and of ‘reusable software components (RSCs)’ are not compatible with the EASA system.

Furthermore, within the EASA system, there is currently no means to benefit from the certification credit granted within a TC or an STC in the frame of another product certification. Formal compliance credit can only be claimed from an ETSOA.

However, the lack of an ETSOA, or the absence of a letter of acceptance, does not prevent an applicant from incrementally building confidence and demonstrating compliance of IMA components during the development flow (as per the ED-124 task framework), nor does it prevent the reuse of previous certification artefacts and activities for a new demonstration of compliance.

The incremental certification process is the process to certify a product for which EASA agrees to grant some credit to a component/module, application or system, before that module, application or system is configured, integrated and certified as part of the final product. The incremental certification process applies to the following approaches:

(a)       Incremental component qualification: credit is taken from activities performed during various steps of the development in order to reduce the effort during a subsequent phase (e.g. verification activities). This qualification is mainly built up using the incremental verification approach.

(b)       Reuse: credit is taken from activities performed on components (modules, platforms, applications) reused from other projects. This approach encompasses the components reused from a previously approved TC or from legacy IMA systems.

(c)        Compliance credit: formal credit is claimed from an ETSOA.

In all cases, the applicant should evaluate and substantiate the suitability and level of the credit sought. Early coordination with EASA should be ensured.

Note: An ETSOA is not a mandatory step in the certification of an IMA system.

Incremental certification evidence table

*          Applicant stands for the applicant developing and/or installing the IMA system.

**       Discussions held on a case-by-case basis based on the information provided through the certification plan.

Whatever the approach selected for the recognition of credit and the level of credit granted, the applicant remains responsible for ensuring and for demonstrating that each component is integrated and installed consistently with its function, interfaces, usage domain, and limitations.

4.1.     Incremental component qualification

One main characteristic of IMA systems and the ED-124 task framework is that they allow a high level of independence in the design and verification activities:

—            between the functional level (application) and the resource level (module/platform);

—            between different applications (except for possible functional coupling between applications).

In addition, Chapter 2.2.e of ED-124 introduces the concept of ‘composability’, where the integration of a new application does not invalidate any of the verified requirements of an already integrated application. When an IMA system is ‘composable’, credit can be taken from its properties (e.g. robust partitioning) regarding two aspects:

—            during the development of the application itself: credit may be taken from module/platform development activities;

—            during the integration and verification activities: credit may be taken from the integration of the application and from the absence of impact on other already verified and installed applications.

These principles drive a modular approach, which can be used to support an incremental component qualification process, provided the following considerations are fulfilled:

—            The applicant should define criteria and supporting evidence to demonstrate the achievement of all objectives for which credit is sought.

—            The applicant should assess, and record through a formal review, the achievement and acceptance of a set of objectives for a given component. For instance, a final software and hardware review (SOI#4) on the components of a module and the acceptance of the corresponding software and hardware accomplishment summaries could support the completion of ED-124 Task 1.

Depending on the framework and organisation, strict AMC 20-115() or ED-80 compliance may not, on its own, be sufficient to show the achievement of a given task. Complementary accomplishment summaries should be provided and encompassed in the applicant’s review.

4.2.     Reuse of components

The applicant remains fully responsible for the contents of the associated data, which have to be assessed through the applicant’s activities as being reusable in the context of the current certification project.

4.2.1. Reuse from a legacy IMA system

Components that were previously approved may be reused provided that the applicant shows that the reuse of the component is appropriate. If changes are necessary, a change impact analysis should be performed to identify the scope of the changes and the necessary activities to re-engage in to cover the changes.

4.2.2. Reuse from a previous ED-124 project

The management of reused components is addressed through ED-124 Task 6 (ED-124 Chapter 4.7). If changes are intended, they should be managed through ED-124 Task 5 (ED-124 Chapter 4.6).

Note: To facilitate the reuse of a component, ED-124 recommends developers to anticipate such reuse during the initial development through dedicated objectives that are part of Tasks 1 & 2 (e.g. the module acceptance plan providing the data listed in Chapter 4.2.3.h).

4.3.     Compliance credit

In the frame of this AMC, formal certification credit is offered from an ETSOA granted to:

—            platform(s)/module(s): ETSO-2C153;

—            application(s) integrated with an ETSO-2C153 module/platform: ETSO-C214.

4.3.1. Use of an ETSO-2C153 authorisation

An ETSO-2C153 can be granted to a platform(s)/module(s) in order to facilitate its (their) use in an IMA system. As per ETSO-2C153 paragraph 3.2.2.1, the IMA module or platform should meet the ED-124 Task 1 objectives. Compliance credit could be hence claimed by an applicant for the demonstration of compliance with ED-124 Task 1, provided the platform(s)/module(s) had obtained an ETSO-2C153 authorisation beforehand.

Nevertheless, the ETSOA does not by itself ensure that the platform(s)/module(s) is (are) technically adequate to be integrated into the IMA system. The applicant remains responsible for all the activities to ensure the proper integration of the ETSO-2C153 platform(s)/module(s) into the IMA system, and the applicant should:

—             substantiate the scope of the ETSOA compliance credit, and define the complementary certification activities based on the data provided (e.g. user/installation manuals);

—             demonstrate the correct use of the platform(s)/module(s), including compliance:

—             with the platform/module integration requirements/user requirements, and the IMA system and safety requirements;

—             of the use, the partitioning, the health monitoring, the configuration of the resources and the installation of the items with the platforms/modules user guide/manual, installation manual, or equivalent data (as documented per ETSO-2C153 Appendix 3). This also includes the deactivation or disabling of unused ETSO-2C153 functions/modules, when available, or the means to ensure that the intended function is performed without any interference from unused ETSO-2C153 functions/ modules.

This section only addresses the use of EASA ETSO-2C153, and its use cannot be extended to any other authority TSO standards on IMA platforms and modules that are not equivalent in their technical requirements.

4.3.2. Use of a functional ETSO-C214 authorisation

Through a functional ETSO-C214 (F-ETSO), an authorisation can be granted to application(s) integrated with an ETSO-2C153 module/platform. As per ETSO-C214, compliance with the ED-124 Task 2 & 3 objectives has to be demonstrated. Compliance credit could hence be claimed by an applicant for the demonstration of compliance with ED-124 Tasks 2 & 3, provided that the F-ETSO-C214 authorisation had been obtained beforehand.

Nevertheless, the functional ETSOA does not by itself ensure that the ETSO article is technically adequate to be installed in the product. The applicant remains responsible for all the activities to ensure the proper integration of the application(s)/module(s)/platform(s) into the IMA system, and the applicant should:

—             substantiate the scope of the ETSOA compliance credit, and define the complementary certification activities;

—             complete the demonstration that the function covered by the F-ETSO article complies with the IMA system and safety requirements.

If the F-ETSO article is in the ‘open’ class and the applicant intends to perform incremental development on the ETSOA article (e.g. to add an application), the considerations of this AMC apply to the new and affected items. The applicant should ensure the integrity and continuity of the system configuration, and in particular should show that the resource allocation, partitioning, and health monitoring are not impaired by the intended changes to the ETSOA article. The level of credit that can be obtained from the F-ETSO article, and the certification activities to be completed in the frame of this AMC, will hence vary depending on the scope of the changes made to the initial F-ETSO article.

If the F-ETSO article is in the ‘closed’ class, it no longer offers any capability for IMA development. Credit can be taken for ED-124 Tasks 2 and 3. This closed F-ETSO article is equivalent to a conventional ETSO article.

4.3.3. Summary of ETSO compliance credit

The following table summarises the credit that can be claimed from ETSO-2C153 and ETSO-C214, and the remaining certification activities to support the demonstration of compliance with AMC 20-170:

ETSOA	Credit	Remaining activities
ETSO-2C153	Acceptance of the platform/module (ED-124 Task 1)	Substantiation of the scope of ETSOA compliance credit. All subsequent activities (ED-124 Tasks 2 and 3, plus those deferred to Task 4).
ETSO-C214 ‘open’ class	Acceptance of the platform/module (ED-124 Task 1) Acceptance of the non-impacted hosted application(s) (ED-124 Task 2)	Substantiation of the scope of ETSOA compliance credit. Demonstration that the F-ETSO article complies with the IMA system and safety requirements. All activities impacted by the incremental development, such as on the modified or new hosted application (ED-124 Tasks 2), and IMA configuration and integration (ED-124 Task 3 plus those deferred to Task 4.)
ETSO-C214 ‘closed’ class	Acceptance of the platform/module (ED-124 Task 1) Acceptance of the hosted application(s) (ED-124 Task 2) IMA configuration and integration (ED-124 Task 3)	Substantiation of the scope of ETSOA compliance credit.

ETSO compliance credit table for AMC 20-170

5.         Additional recommendations for IMA system certification

5.1.     Fault management and human factors

ED-124 Chapter 3.6.5 deals with the annunciation of failures to the crew. CS XX.1322 and the associated AMC address flight crew alerting systems and warning, caution, or advisory lights. In any case where an inconsistency is identified between the text in ED-124 and the text in CS XX.1322 and the associated AMC, the text in CS XX.1322 and the associated AMC should prevail.

Similarly, for any inconsistency between the text in ED-124 Chapter 3.10 dealing with human factors and the text in CS XX.1302 and the associated AMC, the text in CS XX.1302 and the associated AMC should prevail.

5.2.     Configuration data/parameter data items

Guidance on IMA configuration data is provided in ED-124 Chapter 3.7.1.1 at the IMA system level and in Chapter 3.7.1.2 at the application level. These data items are nowadays described as ‘parameter data items’ as defined in ED-12C and should be treated in the same way as other elements of the software. Depending on how a parameter data item is to be used in the IMA system or application, it needs to be defined, managed and documented at the appropriate level (platform, module, application) and to comply with the AMC 20-115()[50] guidance, including the process to ensure intermixability and compatibility during the post-TC period as indicated in ED-124. In particular, any parameter data item should be assigned the same software level as the component using it.

5.3.     Use of tools and the need for qualification

IMA system development may be supported by the use, at the system level, of tools in order to eliminate, reduce, or automate the activities associated with the ED-124 objectives. If a tool could introduce an error or could fail to detect an error, and there are no other alternative means to detect the issue, qualification of the tool is needed.

For instance, a tool may be used to generate and/or verify IMA configuration data and may produce an erroneous configuration that is not necessarily easily detectable at a subsequent integration/verification step.

The objectives of tool qualification are to:

—            ensure an equivalent level of confidence to the non-automated process/activities;

—            demonstrate that the tool complies, and its qualification is commensurate, with the intended use.

Adequate guidance for tool qualification is provided in ED-215, Software Tool Qualification Considerations, and should be followed when a tool is intended to be qualified to support the IMA system development.

The following criteria should be used to determine the appropriate tool qualification level (TQL), according to its intended use:

(a)       Impact of the tool:

(1)       Criterion 1: a tool whose output is part of the IMA system and thus could introduce an error.

(2)       Criterion 2: a tool that automates verification process(es) and thus could fail to detect an error, and whose output is used to justify the elimination or reduction of:

—             verification process(es) other than that (those) automated by the tool; or

—             development process(es) that could have an impact on the IMA system.

(3)       Criterion 3: a tool that, within the scope of its intended use, could fail to detect an error.

(b)      IDAL of the IMA component supported by the tool:

5.4.     Change management

This section deals not only with changes to components that were previously accepted through a TC, STC or ETSOA, but also with changes during the development as soon as components are delivered for use in a subsequent stage of the process and a formal baseline is established for these components.

The main objectives of the change management process are to conduct and document a change impact analysis and to reintegrate the changed component into the IMA system, performing all the necessary verification, validation, and integration activities (including regression analysis and testing).

(a)       Since there are various levels of development and integration in an IMA system, and potentially various stakeholders (the module/platform developer, application developer, IMA system integrator, aircraft designer), agreements should be concluded between stakeholders to establish the way to communicate changes and to perform impact analyses at each level.

(b)       A change impact analysis should consider the possible impacts to be reported at each relevant level:

—             changes at the resource allocation level;

—             changes at the module/platform level;

—             changes at the application level.

(c)       Impacts on incremental compliance credit (if applicable) also need to be considered.

(d)       The changes should be documented in the appropriate life cycle data, including the trace data, configuration indexes and accomplishment summaries.

5.5.     Management of problem reports

IMA systems contain multiple applications hosted on the same IMA module/platform, therefore any OPR related to a module/platform or application, collected at any level, could affect one or several aircraft functions directly or indirectly.

Considering the diversity of stakeholders in an IMA system, the management of problem reports can be more complex than with federated systems. In addition to the applicable guidance on OPR management, for IMA systems, the applicant should organise the management of OPRs, focusing on:

—            the evaluation of the potential effect of each OPR on any shared resources and IMA services, and the evaluation of those OPRs for impact on any aircraft function that uses the affected shared resources and IMA services;

—            the verification that necessary workarounds, including limitations, at the application and/or system levels, are documented within the IMA documentation (e.g. user guide/manual). In such cases, the efficiency of a workaround should be substantiated and the successful (i.e. complete and correct) deployment of the workaround should be ensured.

NOTE: In order to facilitate the assessment and the communication between stakeholders, the use of a harmonised classification scale for OPRs is recommended.

5.6.     Environmental qualification

The scope of this section is to provide environmental qualification guidance complementary to ED-124 Chapter 5.2.6 for the environmental qualification of an IMA system. It can be an IMA platform composed of only one LRU, or various modules in a given configuration. The platform is qualified in conditions of the same severity as those expected when installed on the aircraft, interfaced with its peripherals through the aircraft (or equivalent) harnesses, and loaded with its set of applications. The acceptance criteria to qualify the platform are driven by the operational requirements of a given aircraft.

Level of qualification testing activities: The modularity of an IMA platform makes it possible to conduct qualification testing activities at various stages:

—            IMA module testing: the testing is performed on an IMA module, involving the shared resources (hardware and/or software), and when relevant, with a representative set of software applications loaded onto the module. In the case of a cabinet, the module can be a chassis and/or a backplane.

—            IMA platform testing: the testing is performed on the platform or cabinet (chassis and backplane) equipped with its modules, and when relevant, loaded with a representative set of software applications.

—            System testing: the testing is performed on a set of modules and/or the backplane installed in the cabinet, with system peripherals interfaced with the cabinet, and with representative software applications loaded onto the modules.

—            Aircraft testing: the testing is performed with the systems installed on the aircraft.

The modularity of the IMA platform, combined with the variety of its possible configurations, leads to the establishment of principles to reuse qualification credit for IMA modules in the context of qualifying a desired IMA platform for a given aircraft:

(a)       The environmental usage domain of an IMA module is the set of environmental conditions for which it is qualified. This is documented in the module user guide/manual.

(b)       For an IMA module integrated within a cabinet, its environmental qualification conditions should consider:

—             its environmental conditions (i.e. the envelope of thermal, electromagnetic, vibration, lightning, etc., conditions) encountered inside the cabinet when in use on the aircraft;

—             all its possible arrangements in the cabinet (i.e. different IMA platform configurations).

Incremental environmental qualification is an approach used in qualifying a cabinet populated with modules in a known configuration for a given aircraft, relying on existing qualification credit for IMA modules in their environmental usage domain, and identifying any complementary qualification substantiation that would be necessary to cover the envelope of the environmental conditions of the aircraft. Thus it provides the latitude to populate a cabinet with already qualified modules, to qualify it without having to perform a full reassessment of the qualification of each module, and the capability to reuse its existing qualification dossier.

All the substantiation data recorded in the qualification plan should be based on dedicated tests or on equivalence with the reuse of existing qualification results, or existing authorisations such as ETSO-2C153. The representativeness of the substantiation should consider the testing configuration, the testing conditions (including electrical, thermal, mechanical interfaces, etc.), the qualification testing level, the application software used for the testing, the test scenario and the level of stress applied.

When an IMA system change is implemented, a change impact analysis should be conducted against the qualified configuration to assess the complementary qualification substantiation to be provided for each of its modules.

[Amdt 20/15]