高清可复制 HB/Z 422-2014(2017) 民用飞机综合模块化航空电子系统开发与认证指南

　　ICS 49.090 V 35

　　HB/Z 422-2014

　　民用飞机综合模块化航空电子系统

　　开发与认证指南

　　Development and certification guidance ofIMA for civil aircraft

　　2014-07-09 发布 2014-11-01 实施

　　中华人民共和国工业和信息化部 发 布

　　前 言

　　本指导性技术文件按照 GB/T 1. 1-2009 给出的规则起草。

　　本指导性技术文件由中国航空综合技术研究所归口。

　　本指导性技术文件起草单位：中国航空工业集团公司第六三一研究所、中国航空综合技术研究所。本指导性技术文件主要起草人：孔德岐、王卫东、朱晓飞、王纯委、黄永葵、赵根学、胡 辛。

　　民用飞机综合模块化航空电子系统

　　开发与认证指南

　　1 范围

　　本指导性技术文件规定了民用飞机综合模块化航空电子系统(IMA)的开发、综合、验证、认证过程与方法、参与者的职责以及关键特性的要求。

　　本指导性技术文件适用于民用飞机 IMA 研发全过程。

　　2 规范性引用文件

　　下列文件对于本文件的应用是必不可少的。凡是注日期的引用文件，仅所注日期的版本适用于本文件。凡是不注日期的引用文件，其最新版本(包括所有的修改单)适用于本文件。

　　CCAR-25-R4 运输类飞机适航标准

　　ARINC615A 软件数据加载(Software data loader using ethernet interface)

　　ARINC653 航空电子系统应用软件标准接口(Avionics application software standard interface)

　　ARINC664 飞机数据网络(Aircraft data network)

　　FAA AC20-148 可重用的软件组件(Reusable software components)

　　FAA TSO-C153 IMA 的硬件部件(Integrated modular avionics hardware elements)

　　FAA Order8110.49 软件批准指南(Software approval guidelines)

　　DO-160/EUROCAE ED-14 机载设备的环境条件和测试程序(Environmental conditions and test procedures for airborne equipment)

　　DO -178/EUROCAE ED -12 机载系统和设备认证中的软件考虑 (Software considerations in airborne systems and equipment certification)

　　DO-200/EUROCAE ED-76 航空数据处理标准(Standards for processing aeronautical data)

　　DO-201/EUROCAE ED -77 航空信息的工业要求(Standards for aerondards for aeronautical information)

　　DO-248/EUROCAE ED-94 说明 DO-178B《机载系统和设备合格审定中的软件考虑》的最终报告(Final report for clarification of DO-178B“Software considerations in airborne systems and equipment certification ”)

　　DO -254/EUROCAE ED -80 机载 电子硬件 的设计保证指南 (Design assurance guidance for airborne electronic hardware)

　　SAE ARP 4754/EUROCAE ED -79 高度综合或复杂飞机系统 的适航取证考虑 (Certification considerations for highly-integrated or complex aircraft systems)

　　SAE ARP 4761 民用飞机机载系统和设备安全性评估过程的指南和方法(Guidelines and methods for conducting the safety assessment process on civil airborne systems and equipment)

　　3 术语、定义和缩略语

　　3.1 术语和定义

　　下列术语和定义适用于本文件。

　　3.1.1

　　飞机功能 aircraft function

　　在飞机上由系统的硬件和软件为飞机提供的能力。飞机功能包括飞行指引、自动驾驶仪、刹车、燃油管理、飞行仪表等。

　　3.1.2

　　应用 application

　　软件和/或定义有一组接口的专用硬件，当这些软硬件与某个平台综合后能完成一种功能。

　　3.1.3

　　组件 component

　　自身含有硬件、软件、数据库或其组合，而且受配置管理的控制。组件本身不提供飞机功能。

　　3.1.4

　　核心软件 core software

　　管理平台资源以便为应用提供运行环境的操作系统和支持软件。核心软件是平台必需的组件， 通常由一个或多个模块组成。

　　3.1.5

　　IMA 系统 IMA system

　　由 IMA 平台和一组规定的宿主应用组成。

　　3.1.6

　　互操作能力 interoperable

　　几个综合在一块的模块一起运行来完成某个规定目标或功能的能力。这要求在模块之间定义接口边界，并允许使用其他可互操作的组件。为了用物理术语描述这一概念，IMA 平台可包括可互操作的模块和组件，如物理器件(处理器、存储器、电源、输入输出(I/O)器件)，逻辑元件(如操作系统)和通信软件。

　　3.1.7

　　模块 module

　　可以独自或在 IMA 语境下被认可的一个组件或一组组件的集合。一个模块可以由其他多个模块组成。模块可以是软件、硬件或软件和硬件的组合，这些软硬件能为 IMA 系统中宿主应用提供资源。模块既可以分布于整个飞机也可集中放在一起。

　　3.1.8

　　分区隔离 partitioning

　　一种结构化的技术，它为功能或应用提供必要的隔离和独立性，以保证只发生预期的耦合。在 IMA平台中提供保护机制是专门针对有完整性等级要求的情况。

　　3.1.9

　　平台 platform

　　包含核心软件在内的一个模块或一组模块，可管理资源以支持至少一种应用。IMA 的硬件资源与

　　核心软件能为至少一个宿主应用提供计算、通信和接口的能力。平台本身并不提供任何飞机功能， 平台只是建立了一个计算环境，能够支持服务，并提供与平台相关的能力，如健康监控和故障管理。IMA平台认可可独立于宿主应用。

　　3.1.10

　　资源 resource

　　由 IMA 平台或应用使用的任何对象(如处理器、存储器、软件、数据等)或组件。资源可以由多个应用共享，也可以由特定的应用专用。它可以是物理的(一个硬件设备)，也可以是逻辑的(一段信息)。

　　3.1.11

　　重用能力 reusable

　　先前认可的模块及应用的设计保证数据可以用于后续飞机系统的设计，能够减少所需要的重复设计或额外认可过程。

　　图 1 给出了上述术语间的关系。

　　图 1 IMA 设计术语的关系

　　3.1.12

　　认可 acceptance

　　认证机构对模块、应用或系统符合其规定要求的承认。认可就是由认证机构对所提交的数据、证据或等价声明满足适用的指南或要求，给出的正式承认(通常以信件或盖章的数据单等形式)。认可的目的是为认证项目未来的使用获取信用。

　　3.1.13

　　批准 approval

　　对符合规章给出正式或官方承认的行为或事例。在 IMA 语境中通常有两种批准形式：

　　a) 由认证机构对所提交的生命周期数据给出的批准(通常通过发布已盖章和签字的数据资料或信件来进行证明);

　　b) 通过发布飞机或发动机型号认证和/或适航认证来批准安装。

　　3.1.14

　　增量式认可 incremental acceptance

　　通过认可或找到 IMA 模块、应用、和/或未装机的 IMA 系统能够满足特定要求，为批准和认证获取信用的一个过程。增量式认可可分解为多项任务， 通过获得对单个任务的信任，最终实现认证整个系统的目标。在 IMA 系统中，增量式认可提供综合与认可新应用和/或新模块的能力，并能维持现有的应用和/或模块不需要重新认可。

　　3.2 缩略语

　　下列缩略语适用于本指导性技术文件。

　　API——应用程序接口(application programming interface)

　　ASTC——修改的补充型号合格证(amended supplemental type certificate)

　　ATC——修改的型号合格证(amended type certificate)

　　BIT (E)——自测试(设备) (built-in Test (equipment))

　　CCA——共因分析(common cause analysis)

　　CEH——复杂电子硬件(complex electronic hardware)

　　CIA——更改影响分析(change impact analysis)

　　CM——配置管理(configuration management)

　　CMA——共模分析(common mode analysis)

　　COTS——商用货架(产品)(commercial off-the-shelf)

　　CPU——中央处理单元(central processing unit)

　　CRC——循环冗余检查(cyclic redundancy check)

　　CS——认证规范(certification specification)

　　EQTP——环境鉴定试验计划(environmental qualification test plan)

　　EQT——环境鉴定试验(environmental qualification test)

　　ETSO——欧洲技术标准指令(european technical standard order)

　　FAA——(美国)联邦航空局(federal aviation administration)

　　FHA——功能危害度评估(functional hazard assessment)

　　FLS——现场可加载软件(field-Loadable software)

　　FM——故障管理(fault management)

　　HAS——硬件完成总结(报告)(hardware accomplishment summary)

　　HIRF——高强度辐射场(high intensity radiated field)

　　HM——健康监控(health monitor)

　　H/W——硬件(hardware)

　　ICAW——持续适航的指导说明(instructions for continued airworthiness)

　　IEL——间接闪电影响(indirect effects of lightning)

　　IMA——综合模块化航空电子(integrated modular avionics)

　　IMAS——综合模块化航空电子系统(integrated modular avionics system)

　　IMASAS——综合模块化航空 电子系统的完成总结(报告)(integrated modular avionics system accomplishment summary)

　　IMASCI——综合模块化航空电子系统的配置索引(integrated modular avionics system configuration index)

　　IMASCMP——综合模块化航空 电子系统的配置管理计划(integrated modular avionics system configuration management plan)

　　IMASCP——综合模块化航空电子系统的认证计划(integrated modular avionics system certification

　　plan)

　　IMASQAP——综合模块化航空电子系统质量保证计划(integrated modular avionics system quality assurance plan)

　　I/O——输入和/或输出(input and/or output)

　　LRU——现场可更换单元(line replaceable unit)

　　MAP——模块认可计划(module acceptance plan)

　　MMEL——主最低设备清单(master minimum equipment list)

　　MMU——存储器管理单元(memory management unit)

　　MAAS——模块认可完成总结(报告)(module acceptance accomplishment summary)

　　MADS——模块认可的数据手册(module acceptance data sheet)

　　MRS——模块需求规范(module requirements specification)

　　MTTR——平均维修时间(mean time to repair)

　　MTFF——平均首次失效时间(mean time to first failure)

　　OS——操作系统(operating system)

　　PHAC——硬件方面的认证计划(plan for hardware aspects of certification)

　　PSAC——软件方面的认证计划(plan for software aspects of certification)

　　PSSA——初步系统安全性评估(preliminary system safety assessment)

　　QA——质量保证(quality assurance)

　　SAS——软件完成总结报告(software accomplishment summary)

　　SCI——软件配置索引(software configuration index)

　　SEU——单粒子翻转(single event upset)

　　SSA——系统安全性评估(system safety assessment)

　　STC——补充的型号认证(supplemental type certification)

　　S/W——软件(software)

　　TC——型号认证(type certification)

　　TSO——技术标准指令(technical standard order)

　　V&V——确认与验证(validation and verification)

　　4 一般要求

　　4.1 架构考虑

　　IMA 系统架构由一个或多个平台构成，包括与其他飞机系统和用户(如飞行机组、维护人员等)的接口。飞机功能的分配应纳入 IMA 系统架构中考虑，以确保其能够满足适用的可用性、完整性和安全性的要求。下面列出并描述需要考虑的主要内容：

　　a) 可用性考虑

　　功能的性能——分配宿主的飞机功能到 IMA 系统架构中。

　　资源管理——IMA 平台资源的分配，共享资源和专用资源的控制，由多个宿主飞机功能或应用使用的 IMA 平台资源的保护。

　　可靠性和维护性——为确保持续适航性，影响主最低设备清单、飞机的派遣率、维修、替换以及维护活动便捷性。

　　健康监控——对系统的状态、运行和维护问题进行监控。

　　b) 完整性考虑

　　设计保证、IMA 安全和保护特性、故障检测和分区隔离——为宿主功能和应用提供保护能力，

　　当使用共享资源时确保其独立性并防止非期望的相互作用。

　　c) 安全性考虑

　　安全性评估——确保适宜的架构、设计保证、失效保护，定位共模和飞机功能组合失效的影响，以及适航性。

　　d) 故障管理、故障报告与恢复活动——进行故障、失效和异常行为的检测与识别， 并提供适当的响应。

　　e) 组合性考虑

　　如果在综合新应用时不会导致在已经综合的应用中验证过的需求的无效，则 IMA 平台就是可组合的。

　　在一个可组合的架构中，系统需求来源于分配给各个 IMA 应用的需求。接口边界定义完好的IMA 平台对于已经综合的、被部分认可的应用是可组合的。健壮分区隔离是迈向这一目标的第一步。

　　4.2 关键特性

　　4.2.1 概述

　　IMA 平台与宿主应用的关键特性会影响 IMA 系统架构、详细系统设计，并最终影响 IMA 平台与系统的认证过程。4.2.2～4.2.6 总结了影响认证过程的 IMA 平台的特性。

　　4.2.2 平台与宿主应用

　　IMA 系统的两个基础组成部分是平台与宿主应用。IMA 平台的关键特性如表 1，IMA 宿主应用的关键特性如表 2。

　　表 1 IMA 平台的关键特性

　　表 2 IMA 宿主应用的关键特性

　　4.2.3 共享资源

　　IMA 系统可以宿主多个共享资源的应用。例如， 可以通过访问时间的方式来共享资源。这种情况适用于处理资源和硬件。每一种共享资源都可能成为单点失效，该失效能影响所有使用该资源的应用，应采用由系统安全性评估过程所确定的合适的缓解技术。

　　处理资源是指可能包含有 CPU、存储器和相关接口的物理元素。存储器能够存储机器可读的计算机程序和相关数据。IMA 宿主应用使用IMA 平台提供的共享资源(例如，I/O 设备、数据总线、共享存储器等)来进行通信。资源或资源的一部分可以按照时间单位(例如，处理器的周期或通信带宽)来分配。

　　IMA 平台能对共享资源提供资源管理、健康监控以及故障管理的能力，以支持共享资源的保护。IMA系统可以有多个共享的供电电源。

　　4.2.4 健壮分区隔离

　　健壮分区隔离保证对各独立飞机功能和应用进行预期隔离。这些功能和应用宿主在 IMA 的共享资源上，在出现设计错误和硬件失效时，问题能够对应到唯一的分区或与应用相关的硬件上。如果某不一般的失效能够导致健壮分区隔离特性丧失，那么这种失效应可探测，并应采取适当的措施进行处理。健壮分区隔离的目的就是提供与联合式系统实现的物理隔离和保护等级相同的功能隔离和保护。这就意味着健壮分区隔离应支持宿主在处理器上且使用共享资源的核心软件与应用的协作共存，同时要确保防止未授权或非预期的干扰。健壮分区隔离应满足下列要求：

　　a) 某一软件分区不允许破坏其他分区的代码、I/O 或数据储存区;

　　b) 某一软件分区只允许在分配给它的时间段中使用共享的处理器资源;

　　c) 某一软件分区只允许使用分配给它的共享 I/O 资源;

　　d) 属于某一软件分区的硬件失效，不能对其他软件分区造成有害影响。

　　在所有使用共享资源的各种飞机功能和宿主应用情境下(包括硬件失效、软硬件设计错误或异常行为)，健壮分区隔离是一种确保实现预期隔离和独立的一种方法。

　　健壮分区隔离的目的是提供一种与联合式系统(即应用程序各自宿主在分离的 LRU 中)级别相同的功能隔离和独立性。这就是说， 健壮分区隔离应支持使用共享资源的应用软件协同共存，同时要确保能够探测到、并能化解任何试图进行未授权或非预期的交互。

　　平台的健壮分区隔离保护机制独立于任何宿主的应用，即应用不能改变由平台提供的分区保护措施。

　　4.2.5 应用软件接口(API)

　　API 定义了平台和宿主应用之间的标准接口，且对应用之间的通信和使用 I/O 的能力提供了实现方法。

　　4.2.6 健康监控和故障管理

　　由于多个应用的综合和资源的共享，健康监控和故障管理(HM/FM)功能应给予特别的关注。IMA系统管理平台的故障、硬件的失效、分区的冲突， 以及宿主应用的错误和异常行为，包括共模故障和级联失效。用于管理平台故障的方法与宿主应用是独立的， 故障管理由故障、失效和错误的检测、发生时正确地识别以及执行适当的响应等方面组成。故障管理和故障报告的指南参 5.7。

　　IMA 平台为平台和宿主应用提供了健康监控和故障管理的能力。IMA 系统必须要提供更高级别(飞机功能)的健康监控和故障管理能力，以支持可用性和完整性的要求。

　　4.3 利益相关方

　　4.3.1 概述

　　在 IMA 系统研制过程中，需要进行角色和职责的分配，并且角色和职责应涵盖从概念设计到退役的整个 IMA 系统生命周期范围。对角色和职责的分配可基于基本的 IMA 系统架构，并应包括选择和提供工具的职责，这些分配应该在 IMA 系统的项目计划中说明，如 IMA 系统的认证计划和支持的低级别计划。

　　对于装在飞机上的 IMA 系统，本节确定了一些典型数据，这些数据用来支持 IMA 系统的开发、批准和持续安全地运行。对于某些活动、数据产生以及符合性证明的责任， 应尽早地在项目的各利益相关方中得到协调、沟通和解决。需要积累数据来支持 IMA 模块和宿主应用的增量认可。

　　一个小组或组织可能能够执行所描述的所有活动(除了认证授权)，不过预期将会有多个组织牵涉其中。强力支持取证申请人尽早地与认证机构协调其计划，并在 IMA 系统开发的整个过程中保持与认证机构的协调。

　　不管何处(产生)的失效或故障，只要影响了用于跨项目和飞机产品中的公共 IMA 组件，都应设置一个适当过程，将所提供的信息(资料)传给所有使用公共组件的人员。这种信息沟通的过程不仅要对用户，还要对认证机构以及那些负责飞机产品持续安全运行的部门。对于记录所做出的决策、纠正的途径，以及任何认证机构活动达成的协议，都应有清晰和定义完备的沟通渠道与规程。

　　4.3.2 认证机构

　　认证机构是一种代表国家，负责对飞机和/或发动机认证授权批准的组织。

　　4.3.3 取证申请人

　　取证申请人负责对符合适用的航空规章进行证实， 并寻求进行型号认证(TC)、修改的型号认证(ATC)、补充的型号认证(STC)、或修改的补充型号认证(ASTC)。取证申请人负责生成和确认所有的飞机级需求，并分配给子系统、提供所配置 IMA 系统的安装说明、将 IMA 系统与飞机的其他系统进行综合，并且会在适当时负责将 IMA 系统安装到飞机上。对所安装的 IMA 系统和飞机，取证申请人最终负责确保符合适用的规章，且确保它们具有适航性。

　　取证申请人要进行必要的开发活动，来定义所要实现的飞机级功能，并在系统安装到飞机上后，进行必要的确认与验证(V&V)活动。取证申请人还要负责进行持续适航。

　　注：取证申请人不需要在飞机上对 IMA 系统进行实际安装，但仍要对上述条目负责。

　　4.3.4 IMA 系统综合者

　　IMA 系统综合者完成把平台和宿主应用综合起来形成 IMA 系统。在 IMA 系统综合过程中，生成的主要数据包括：

　　a) 系统配置，包括模块和宿主应用的数量、类型与特定版本;

　　b) IMA 系统的共享资源的分配和配置表;

　　c) IMA 系统确认与验证(V&V)的结果(包括 IMA 系统的性能数据)与分配需求的一致性。

　　4.3.5 平台和模块供应商

　　IMA 平台和模块的供应商提供处理硬件和软件资源，包括核心软件。为了支持 IMA 平台和模块的使用，需要提供开发和配置工具，在平台和模块开发过程中，生成的主要数据包括：

　　a) IMA 平台和模块的接口规范;

　　b) 共享资源分配与配置表的规范;

　　c) IMA 平台所需的资源和配置数据，包括核心软件;

　　d) 模块和/或平台确认与验证(V&V)的结果(包括性能数据)与分配需求的一致性。

　　4.3.6 应用供应商

　　应用供应商负责开发宿主应用，并在 IMA 平台上对其验证。应用供应商应确保唯一分配给宿主应用的任何硬件或软件资源能满足完整性和可用性的要求，这些完整性和可用性需求要与由飞机安全性评估所确定的失效状态分级一致。在应用开发中，生成的主要数据包括：

　　a) 应用所需的外部接口规范;

　　b) 宿主应用所需的资源和配置数据;

　　c) 应用/平台综合确认与验证(V&V)的结果(包括性能数据)与分配需求的一致性。

　　4.3.7 维护组织

　　维护组织遵循取证申请人获得批准的规程，保持 IMA 系统和飞机处于适航状态。在第 8 章中提供了有关持续适航的附加信息。

　　5 开发考虑综述

　　5.1 概述

　　IMA 系统是基于 IMA 平台开发的，该平台包含的软硬件组件是公用的，并能由宿主应用共享。

　　图 2 给出了一种典型设计范例，它强调潜在共享资源，阴影区为可以共享的模块。

　　图 2 强调潜在共享资源的典型设计范例

　　IMA 的开发过程应确保以下方面：

　　a) 分配到特定 IMA 系统的飞机功能应与系统设计一致。

　　b) 应确定分配到具体IMA 系统的飞机安全性和信息安全性需求，并通过IMA 系统设计得到满足。它应包括该系统的开发保证、硬件的设计保证以及软件的级别的分配。这些级别的确定要通过飞机级安全性评估来进行的，确定这些级别可支持由宿主应用实现的飞机功能，并支持系统的可用性和完整性需求，以及针对工具评估和鉴定的各种需求。

　　c) 通过 IMA 平台的设计，任何宿主应用的行为都要避免对其他任何应用或功能的行为带来不利的影响。IMA 平台具有健壮分区隔离、资源管理以及能适用于飞机功能与宿主应用的其他保护措施。

　　d) 提供给平台的健康监控、失效报告过程以及故障管理功能，要满足宿主应用和 IMA 系统所规定的需求。

　　e) 建立并维护给 IMA 平台、应用、综合者和取证申请人使用的配置管理。

　　f) 实现并验证分配给 IMA 系统的需求。

　　g) 实现并验证 IMA 系统所固有的人为因素需求。

　　5.2 IMA 系统的开发过程

　　5.2.1 概述

　　IMA 系统的整个开发过程应按照结构化的过程(如 SAE ARP 4754-79)进行，并且应考虑 IMA 的一些主要特征：灵活性、重用性和互操作性，这些特征会影响到开发过程，开发过程至少包括：

　　a) IMA 平台——定义可重用的、可共享的模块与资源(包括应用程序接口与健康监控策略);

　　b) 宿主应用——定义接口和系统的协议，以使某个宿主应用宿主在指定的平台上;

　　c) IMA 系统——把一组特定的宿主应用综合到某个指定的 IMA 平台上。

　　5.2.2 IMA 平台的开发过程

　　IMA 平台的定义与开发可以与专用的飞机功能和宿主应用的开发分开进行，如果这一目标能够达到，已开发的 IMA 平台的数据就有可能在一组不同的宿主应用中重用。

　　IMA 的一个主要目标就是开发出一个 IMA 平台，这种平台能够与不同宿主应用一起在不同飞机上重用。一种可重用的 IMA 平台应利用下列描述的过程目标进行开发。模块的认可过程将在第 6 章中进行描述。

　　a) 策划和定义 IMA 平台，这种定义应包括：

　　1) 架构定义，它包含各种 IMA 模块、资源与组件的类型和一般功能，以及他们是如何交互的(如，是分布式的还是集中式的架构);

　　2) 将宿主应用、软件和硬件综合到 IMA 平台的方法;

　　3) IMA 平台的认可方法;

　　4) IMA 系统的认证方法，它包括支持宿主应用和开发符合性数据的各相关方的角色与责任;

　　5) 能够提供给宿主应用的一组平台服务;

　　6) 飞机功能所需的可用性与完整性的预期等级、平台对其支持的能力，以及支持的方法;

　　7) 健康管理和故障管理的方法(不包括外部的真实接口，因为这部分接口是依赖于飞机的HM 和机组告警系统);

　　8) 平台和 IMA 系统的配置管理方法。

　　b) 定义 IMA 平台的需求，包括：

　　1) 安全性能力

　　□ ——确定顶层平台的失效事件，这种事件能够影响宿主应用;

　　□——定义与每个失效事件相关的可接受的失效率(对平台硬件模块的可靠性要求);

　　□——使用上述数据进行开发的指南，这些数据能满足飞机和潜在宿主功能的可用性与完整性要求;

　　□——定义安全性的要求，包括健壮分区隔离、健康监控、故障管理、资源管理、其他安全特性与其他保护措施。

　　2) 操作性能。

　　3) 配置管理方法。

　　4) 环境条件，在这种条件下平台模块能按预期情况运行。这里各个模块共享公用的环境， 如公用电源、公用数据总线。应描述对公用环境的定义。

　　5) 故障管理与故障报告的方法和要求，需要考虑的内容包括：容错、模块的故障隔离以及单点失效的检测与隔离(例如，导致能力丧失的失效，如内部电源的失效，冗余的模块间通信通道，以及其他类似资源都应予以考虑)。

　　6) 对各方面概念定义的详细需求。

　　7) IMA 平台的结构，这种架构已按照所需要的安全性能力进行了定义和验证。

　　c) 开发并实现 IMA 平台的设计。软件和硬件的开发过程应分别按照 DO-178/ED-12 和DO-254/ED-80 进行，同时要符合各类补充规章文件的要求，在相应的安全级别上满足所需的安全性要求。另外，应该进行共因分析(CCA)，并应针对该平台所定义的各种顶层事件进行定量的失效分析。

　　d) 验证并确认 IMA 平台，涉及到以下活动：

　　1) 针对特定的环境条件进行环境鉴定试验。

　　2) 进行分区分析和验证试验;验证其他的保护能力与安全性特性(即，资源管理、健康监控、故障管理、启动自测试和连续自测试等)。

　　3) 完成共因分析 CCA。

　　4) 完成数值分析，证明 IMA 平台满足可靠性需求与能力。

　　5) 专注于同时共享环境和资源的模块。共享同一环境的非 IMA 模块也应专注。如果只有 IMA模块共享环境，并且模块的配置是固定的，那么就能在进行机上完全综合前完成部分组合的环境鉴定。

　　e) 使用第 6 章描述的模块认可方法来获得 IMA 平台的认可。应开发、提交第 6 章和第 7 章中描述的模块认可数据或使其可用。IMA 平台的所有需求应得到确认和验证。应开发和维护需求、实现和验证等活动之间的追踪性。

　　5.2.3 宿主应用的开发过程

　　开发宿主应用遵循的过程与非 IMA 系统中所用的开发宿主应用的过程相同，但应达到如下目标：

　　a) 确定需要使用的 IMA 平台资源(包括部分接口的定义);

　　b) 量化所需的 IMA 平台资源(包括部分接口的定义);

　　c) 把宿主应用的安全性评估映射到 IMA 平台的安全性评估和能力上(即初步的系统安全性评估(PSSA)、功能危害评估(FHA)以及共因分析(CCA));

　　d) 定义宿主应用的 HM/FM 需求，并确定与 IMA 平台 HM/FM 功能的交互关系;

　　e) 确定 IMA 平台专用资源接口(例如，专用硬件);

　　f) 规定专用资源的环境鉴定等级;

　　g) 将应用综合到平台上，并进行软件/平台的综合测试;

　　h) 对照 IMA 平台的性能，评估人员因素的需求。

　　5.2.4 IMA 系统的开发过程

　　IMA 系统的开发过程有以下目标：

　　a) 确定飞机功能，包括功能、性能、安全性、可用性和完整性的需求。

　　b) 在考虑飞机级 FHA、资源需求(接口规范)、IMA 平台的安全性能力以及 MMEL 等情况下，把IMA 平台的资源分配到飞机的功能上。确定出哪些宿主应用或飞机功能需要与其他的宿主应用和功能进行隔离和/或保护，并确定出所需的其他保护机制或安全特性。

　　c) 开发 IMA 系统的架构，涉及到以下方面：

　　1) 根据飞机的需求、宿主应用以及 IMA 系统的认证方法，编制 IMA 系统的认证计划。

　　2) 确定所需 IMA 平台模块和资源的数量、质量和类型，以满足所有应用需求，包括功能、性能、安全性、可用性、完整性和余度的需求。

　　3) 确定由 IMA 平台模块的能力决定的各种飞机功能需求，例如：

　　□——对可用性的需求超过了单个 IMA 模块或平台能够达到的可用性，这种情况能促使应用宿主到多个模块或平台上;

　　□——使用多个模块的应用应确定应用的余度管理需求;

　　□——对完整性的需求超过了一个 IMA 模块或平台能够达到的完整性，这种情况促使宿主多种实例的应用和/或数据，通过比较来达到所需要的完整性。

　　4) 对于每个要使用 IMA 平台安全性需求的宿主应用，都要进行初步系统安全性评估(PSSA)。

　　5) 根据平台、宿主应用和共享资源失效的组合情况，来评估飞机的影响。

　　6) 对 IMA 平台资源的分配，确定出所需进行的变更，以纠正由单独和组合 PSSA 活动所确定的任何问题。

　　d) 实现 IMA 系统，包括下列活动：

　　1) 开发应用软件，并进行部分验证。

　　2) 将所有应用综合到平台上，并对 IMA 系统进行确认与验证活动。

　　3) 利用 IMA 平台的顶层事件作为宿主应用失效分析的基本事件，进行初始 IMA 系统的失效分析。

　　4) 评估 IMA 平台组件失效的组合对宿主应用的影响，这些失效可能导致对飞机级产生影响，在必要时调整资源分配和/或应用的实现。需要注意，IMA 平台组件的失效应有唯一的顶级事件。

　　5) 进行飞机的地面和飞行试验，以确认 SSA 中的假设、需求和环境定义。

　　e) (未装在飞机上的)IMA 系统的综合、确认、验证， 并获得认可。对 IMA 系统中应用的特定配置，应证明能满足其需求(包括性能、余度管理以及 IMA 平台的接口需求)，应该对每一种宿主应用进行分析，以表明其符合自己的 FHA。另外， 对宿主应用的分析应该与 IMA 系统硬件的定量分析结合起来，以表明事件的组合能满足飞机级安全性和可靠性的需求。

　　f) 适当时，对装在飞机上的 IMA 系统进行综合、确认、验证，并获得认可。

　　表 3 给出了综合活动与认可任务的关系。这些活动都是通用的， 并能按照开发的规模进行适当的范围调整。IMA 认可过程有六项任务。

　　表 3 综合活动与认可任务之间的关系

　　表 3 综合活动与认可任务之间的关系(续)

　　5.3 IMA 系统的资源分配活动

　　飞机的功能和性能需求会影响 IMA 宿主功能的分配，除专用的飞机功能外，还有几个问题需要专注，包括提供可用的计算资源、专用 I/O 资源、网络带宽， 并满足安全性、完整性和可靠性的要求。代表特定应用的平台服务应运行在该应用所限制的资源范围内。

　　a) IMA 系统的处理吞吐量应该详述应用所需的执行时间、上下文切换时间、平台运行管理开销以及总处理需求。例如， 应用及其相关服务应在其分配的时间内运行，并且不能占用分配给其他应用的时间。这也包括由平台提供的服务， 如资源管理、健康监控、故障管理、分区隔离实施以及其他有效的保护方法。

　　b) 计算资源和网络带宽的总量(包括分区隔离实施、处理以及数据总线的抖动和流量)应对与上下文切换、数据调度以及其他限制相关的开销进行说明。

　　c) 为了满足飞机的安全性需求，IMA 平台和宿主应用应定义所分配功能的完整性与可用性需求以及 IMA 系统的配置。对于飞机功能和宿主应用， IMA 系统的架构应能支持最高级别的完整性和可用性。

　　5.4 飞机的安全性和信息安全

　　IMA 系统需求中应说明安全性需求，这些需求影响系统的配置和功能与宿主应用在 IMA 资源中的分配，并对实现飞机功能的宿主应用提出独立性、可用性和完整性的需求。另外的安全性考虑在第 7.1节中描述的安全性评估过程中进行说明。从安全性评估和信息安全分析中派生出的需求也不同于功能需求。

　　信息安全的需求应在飞机级安全性评估中进行说明。IMA 的机制可以用来处理涉及信息安全的问题。

　　5.5 开发保证与工具保证

　　IMA 系统和组件应按最高保证等级的要求进行设计和开发，以支持飞机功能和 IMA 系统要执行的宿主应用的安全性、完整性和可用性需求， 这些需求是由 IMA 系统的安全性评估所确定的。要确定“通用”IMA 平台(的需求)可能是困难的，这种“通用”IMA 平台可用于多种型号的飞机上，而这些型号飞机的飞机功能和宿主应用都是不定的(不知道的)。因此， 为了减小特定飞机型号和宿主应用配置所带来的风险，IMA 系统的开发商就想要按某个特定的保证级别来开发他们的系统。

　　针对宿主应用的 IMA 平台用户指南和描述 IMA 平台与外部系统接口需求的接口规范，都应该是完整的和无二义性的。飞机功能和 IMA 系统上的宿主应用可能源于多个供应商，所有的应用供应商都应能得到 IMA 平台用户指南。

　　由 IMA 平台开发商提供的工具以及用于开发和/或验证符合接口规范的工具应进行鉴定。例如， 某些用来产生或验证配置表的工具或验证健壮分区隔离的工具需要由IMA 平台的开发商和/或系统综合者

　　进行鉴定，而不需要由应用开发商进行鉴定。

　　5.6 分区隔离与资源管理活动

　　5.6.1 概述

　　IMA 的一个主要目的就是把飞机的多个功能和应用综合到一起，并宿主到一个或多个计算平台上，同时确保任意一个飞机功能都不能以未定义的或不可接受的方式影响其他的功能。而且， 强制实施并维持这种独立性的机制的失效应是可检测的和能缓解的，以确保所要求的安全性和完整性的等级。

　　对于“不可接受”的标准只能通过安全性评估来确定。这要求对飞机功能和宿主应用之间的行为封闭和隔离有可分析的机制。这种技术就是通常所说的分区隔离，在 DO-178B/ED-12 中有如下定义：

　　“分区隔离是一种在功能独立的软件组件之间提供隔离，以包容和/或隔离故障，并且可能减少软件验证过程工作量的技术。”

　　IMA 系统中的分区隔离应允许相互独立的应用共享资源，且不产生任何非预期的交互作用。分区隔离的概念用于很多基于商用计算机的系统中，通常实现上不提供安全相关系统所需要的保护等级，因此，“健壮分区隔离”为针对 IMA 系统专门定义的分区隔离。

　　健壮分区隔离的特点有：

　　分区隔离的服务应当对共享平台资源的飞机功能和宿主应用提供适当的分离和隔离，分区隔离的服务是由平台提供的服务，这种服务定义和维护分区之间的独立性和分离性。这些服务确保在一个分区内功能或应用的行为不能对其他任何分区功能或应用的行为构成不可接受的影响。这些服务应能防止对飞机产生任何不利的影响，这种有害影响 是指所有功能和应用分区共享受影响的资源而同时产生检测不到的破坏;

　　具有适当可信等级，能够实时确定分区隔离服务按照规定的安全等级执行的能力;

　　分区隔离的服务不应该依靠任何飞机功能或宿主应用的任何行为，建立并维护分区隔离所需的所有保护机制都由 IMA 平台提供。

　　其他保护机制(例如，高级的故障检测与识别、专用的安全监控， 或错误检测与纠错能力)可以作为宿主应用的一部分宿主在 IMA 上，或可以宿主在飞机的其他系统上。

　　这些特性应与所要求的可靠性和完整性等级相协调，可靠性和完整性的等级是由飞机安全性评估所确定出来的。对这些特性的分析可以在飞机平台或 IMA 系统综合级别中进行。

　　在设计中分配给分区内某个特定应用或应用功能独占的资源就是专用资源。专用资源的一个重要特征就是它的失效只影响使用这些资源的特定应用或分区。典型专用资源有专用存储器、专门硬件以及软件逻辑资源，如专用的缓冲。

　　由多个分区使用的资源就是共享资源。因此， 把某一分区内应用功能与另一分区的应用功能进行独立或隔离是必要的(例如，保护一个功能不受另一功能的失效或异常行为的影响)。共享资源的一个重要特性就是它的失效会影响使用该资源的所有应用和分区。不同的架构可以把同一种资源指定成专用的，也可以指定成共享的。

　　分区隔离的分析与设计应符合两个原则。第一，分配给某一分区的专用资源绝不能受到其他任何分区的应用或应用功能操作的影响，也绝不能影响到其他任何分区的应用或应用功能的操作。第二， 某一分区对共享资源的使用不能对共享该资源的任何其他分区的应用或应用功能的操作造成不可接受的影响。安全性评估应指出这些影响。

　　IMA 的执行环境应确保所有的宿主应用在运行方式上等同于联合式系统架构中的方式。每个宿主应用相对于与其一起宿主的其他应用应具有完全独立性。平台应保证对所有的宿主应用分配必需的资源，不管其他宿主应用的运行是正常还是出错。

　　IMA 系统及其架构的设计由许多因素决定(例如，系统需要的冗余、对共因失效的考虑，等等)。本节只说明与分区隔离有关的设计和架构方面的问题。在出现可能需要专门的飞行机组人员或维护人员

　　采取行动的硬件失效或软件错误情况下，IMA 系统不能保证分区隔离。这些行动只能根据飞机实际的功能和宿主应用来确定，这些内容已经超出了本指导性技术文件的范围。然而，应识别可能与 IMA 系统分区隔离功能失效相关的确保分区隔离的任何机制以及这些失效对飞机功能和宿主应用的影响，并提供给系统开发过程和安全性评估过程。在某些情况下，IMA 系统的开发商可能提供与任何应用都无关的特殊安全属性，如，失效静默或失效运行的架构、提供附加的限制与保护， 这些能够简化整个系统的安全性评估，简化对健壮分区隔离和其他保护特性的验证以及对符合性的证明。

　　5.6.2 健壮分区隔离的设计

　　IMA 平台上的分区隔离设计是一个迭代过程。应该对提出的设计进行分析， 以确保 5.6 节中所确定的准则都能得到满足。如果发现有不足之处，就应修正这种架构，直到能够证明这些准则都得到满足。尽管采用的方法将依赖于具体实现，本节还是提供出一些通用指南。

　　应识别所有专用资源和共享资源，应确定对这些资源可能会产生任何非预期交互作用的所有传播路径。这些传播路径可能产生于硬件失效、硬件设计错误或软件设计错误， 这些传播路径也可以产生于正常的执行。确定出传播路径后， 应建立并确认抑制范围，以防止通过这些传播路径在分区间产生非预期的交互作用。健壮分区隔离的服务应对专用资源和共享资源提供保护， 这些分区服务的失效可能导致产生非预期的失效传播路径。传播路径的例子有：

　　a) 故障分区允许某个应用对存储器的某个单元进行写操作，而另一分区认定其对这个单元具有独有访问权;

　　b) 某个故障分区会导致共用的共享通信通道不能对另一分区提供服务;

　　c) 一个分区拒绝将处理器执行时间交给另一个分区;

　　d) 一个故障分区能毁掉一个共享闪存的文件系统;

　　e) 在上下文切换到一个新分区时，CPU 的高速缓存没有得到刷新;

　　f) 故障分区会引起某一事件在某一时刻发生或按顺序发生，而这种情况不是另一分区所希望的那样。

　　在有些情况下，对于给定的传播路径，可能需要一个以上的错误抑制边界。在另一些情况下，一个单一错误抑制边界可以保护一个以上的传播路径。

　　应完整地规定由分区隔离服务提供的分区功能之间所允许的交互和接口。完整的接口定义会方便传播路径的分析。在 IMA 平台中，应严格遵守及实施分区间接口规范，以避免非预期行为出现。

　　分区隔离机制应与 IMA 系统的完整性、可用性和可靠性的要求相协调。 IMA 系统设计应满足这些需求的最高等级，同时要识别隐含的各种宿主应用与飞机功能的组合。

　　5.6.3 分区隔离分析

　　5.6.3.1 概述

　　分区隔离分析应证明在分区中的任何应用或子功能都不会对其他任何分区的某个应用或子功能的行为产生不利的影响。应识别分区之间的所有传播路径，每个传播路径所带来的影响都应在文件中记录。应确认错误抑制范围内不可接受的交互作用的缓解措施。故障树分析、形式化方法和其他技术都会在分区隔离分析中用到。为了包括任何可能的多重失效要求， 在飞机系统安全性评估背景下，应涉及分区隔离分析。换句话说， 这种分析可对上述的要求做出假设。针对如何进行分区隔离和其他保护方案的验证和确认，分区隔离分析应说明相关的计划、规程和要求。

　　下面的几节给出了分区隔离分析应包含的内容。

　　5.6.3.2 顶层分区隔离的特性

　　分配给顶层分区隔离属性的需求应基于飞机的安全性评估，这部分的分析应描述主要属性、或者可

　　以使健壮分区隔离得以实现和维护需要建立的属性。这些内容既可以从正面来描述属性， 也可以从防止不期望的影响来描述属性。

　　5.6.3.3 分区隔离特性的分解

　　这部分分析是由顶层属性到低层属性的分解。低层属性是为满足顶层属性而必需要达到的， 低层属性可以进一步分解，直到最底层的属性，这一过程能够表明平台的一个或多个设计特性得到完全满足。

　　注：一个顶层属性分解的例子(任何应用决不会对在其他分区中的任何应用行为造成负面的影响)可能按以下步骤进行，在一个分区中任何应用功能决不能：

　　a) 以某种有害的方式访问其他任何分区中的存储器;

　　b) 以某种有害的方式影响其他任何分区中的定时;

　　c) 对其他任何分区所用的资源造成有害的影响。

　　上述三个属性满足顶层的属性，可能还会用到其他方法。

　　如果某设计特性使用了存储器保护单元(MMU)和对 MMU 进行设置的一组配置文件，这些配置文件确保分配给一个分区功能的存储器只能由该功能来访问，存储器保护可认为是最底层的属性。

　　5.6.3.4 生命周期数据

　　对于每个与最底层属性相关的设计特性，应提供对生命周期数据和相关验证数据的追踪能力。如果这些设计特性和相关生命周期数据是另一验证过程的一部分，则只需要追踪到这一设计特性和相关的需求。

　　5.6.3.5 分区隔离的脆弱性评估

　　对于每个分区隔离的属性，都要进行脆弱性评估。当需要进行安全性评估和危害性分析时， 这种评估能检查外部系统和人机接口的所有可能行为，以及硬件失效的影响。

　　注： 由于配置文件可能超出平台设计者的控制范围，可能存在这样一种脆弱性情况，例如，配置文件中的一个错误可能导致分区功能间的存储器区域覆盖。这就要求 IMA 系统综合者应提供验证数据，该验证数据能确保存储器区域不相重叠。

　　5.6.3.6 可能的错误源

　　在分区隔离分析中应包括的可能错误源，对每个要进行分析的系统都是唯一的。尽管不需要列出一套完整的问题清单，但下面这些设计错误源都会影响分区隔离的分析：

　　a) 中断和中断屏蔽(软件和硬件);

　　b) 循环(例如，无限循环或无法终止的间接调用循环);

　　c) 实时响应(例如，帧超限、与实时时钟冲突、计数器/定时器损坏、流水线和高速缓存、确定性调度);

　　d) 控制流(例如，不正确的分支进入一个已分区的或受保护的区域、跳转表的损坏、处理器队列控制的损坏、返回地址的损坏、不可恢复的硬件状态受损坏(如，屏蔽和停止));

　　e) 存储器、输入和/或输出争用;

　　f) 数据标记的共享;

　　g) 软件陷阱(例如，被零除、未实现的指令、专用软件中断指令、不能识别的指令和递归终止);

　　h) 阻止命令(Hold-up commands);

　　i) 输入或输出数据的丢失;

　　j) 输入或输出数据的损坏;

　　k) 内部数据的损坏(例如，直接或间接的存储器写入、表越界、不正确的链接、与时间相关联的计算、CACHE 存储器被破坏);

　　l) 被延迟的数据;

　　m) 程序覆盖;

　　n) 缓冲序列;

　　o) 外部设备的交互(例如，数据的丢失、延迟的数据、不正确的数据、协议停止)。

　　对于系统来说，分区隔离分析和不同设计步骤之间存在一种反复的过程。当所有的分区隔离属性都已得到满足和验证，而且所有已确定的脆弱性都得到了减轻并有相关的验证数据，这种分析才算是完整的。

　　5.7 健康监控与故障管理

　　5.7.1 概述

　　在 IMA 平台可以支持一组不同的飞机功能实现的共识下，IMP 平台应提供健康监控和故障管理(HM/FM)的功能。IMA 平台应向IMA 平台的模块提供基本的健康监控和故障管理的能力，这种能力应该独立于各宿主应用。

　　健康监控应解决运行与维护两方面关注的问题。

　　要制定出解决下列问题的策略：

　　a) 确定需要监控的组件和内容;

　　b) 确定各个应用健康状况;

　　c) 确定 IMA 系统整体的健康状况;

　　d) 对各类失效或异常行为的响应;

　　e) 对飞行机组的通告与消息提示;

　　f) 对维护活动及其报告的控制;

　　g) 冗余管理;

　　h) 单粒子翻转。

　　5.7.2 需要监控的组件与内容

　　健康监控是 IMA 平台负责对失效进行检测、隔离、限制与报告的部分， 这种失效对使用IMA 平台资源的应用或者资源本身都会产生不利的影响。该功能应能检测出宿主应用所用共享资源中的故障， 专用资源也可以通过 IMA 平台来监控，例如，专门用于某个应用分区的存储器可以由IMA 平台来监控，而不是由应用监控。

　　共享资源中的故障可能会对使用该资源的所有应用产生有害的影响。系统架构应设计成能在尽可能低的架构等级上，进行故障检测。理想的情况是在组件级上进行故障检测，这会减少可能产生的模糊。这种检测可通过自监控、平台监控或其某种组合来完成。故障通常是通过征兆来检测的， 这可能对将故障定位到一部件引起一些模糊。对于某一故障，模糊范围越小，就能越容易地在 IMA 系统级别上确定出安全的解决方法。健全的架构通常能减少模糊区域到单个孤立区域。这在确定 IMA 平台中的故障检测责任时，是一个重要的考虑方面。相对 IMA 平台的健壮分区隔离服务来说，这甚至更重要。这些服务的失效能够直接影响维持分离和独立的能力。如果需要宿主应用参与检测这些服务(例程)中的失效，就几乎不可能隔离这些失效到分区机制。因此，IMA 平台应执行分区隔离服务的健康监控。

　　IMA 平台应该监控其服务和接口的健康状况。

　　5.7.3 每个应用的健康状况确定

　　应用的供应商应确定应用的可能失效模式，特别是要确定对平台有操作要求的应用失效模式。例如，这可能包括分区重启、关闭或者其他特定的平台操作。

　　应提供记录、监控并管理影响平台失效的 HM 设施，这包括为应用记录并通告维护状态与失效情

　　况的设施。应用供应商对其应用也可以在应用级别上提供特定的健康监控能力， 这种信息不依赖所用的方法，应确定并综合到 IMA 系统整体健康监控策略中。

　　5.7.4 确定整个 IMA 系统的健康状况

　　确定 IMA 系统的健康需要专注 IMA 平台级的失效状态，并要对在应用中没有处理的、潜在的分区隔离失效与应用失效模式进行处理。应规定综合的 HM 策略，并记入文件之中，这种策略应与 IMA 系统的安全性评估相协调。

　　综合的 HM 策略还要规定以下内容：

　　a) 确定系统失效的方法，并向宿主应用与其他平台服务报告状态;

　　b) 控制分区重启和关闭的规则;

　　c) 若适用，给出降级运行的规则;

　　d) 支持 MMEL 的指南;

　　e) IMA 系统健康状态的报告、内容与频度。

　　5.7.5 各种失效类型的响应

　　除了能检测并隔离故障外，还需要有报告和抑制故障的能力。报告故障就是指对所存在的故障或失效进行内部登记，指示给宿主应用与平台服务、飞行机组和维护机组。故障抑制是指使失效不要对限制区域之外的任何方面造成影响而采取的一种响应，本小节重点是故障抑制，故障报告的内容将在以后进行叙述。

　　在 IMA 平台上所有可检测的故障都应该有确定的响应。应用中那些不会影响 IMA 平台资源的失效应该由应用负责处理。该应用要对这些失效提供正确的响应，包括提供应用的健康状态。IMA 平台应对应用违反平台分区隔离服务的任何企图进行监控与检测，并采取适当的措施。IMA 平台对这些故障的响应是可以配置的。

　　能把故障限制到某个隔离区域的能力，极大地方便了宿主应用综合到 IMA 平台上，这里假定分区是所有故障抑制的区域，并且平台服务也是故障抑制的区域。

　　5.7.6 飞行机组的通告与通信

　　一般来说，在处理飞行机组通告与通信方面，IMA 系统和传统的联合式系统应没有区别。在飞行提醒与维护消息系统的框架内，飞行机组关心的重点是功能的可用性。虽然维护系统提供的是飞机维护方面和飞机派遣(MMEL)的信息，这些信息对改进维护报告的效率与效力有某种程度的关联，但在帮助飞行机组做出决策的过程中，还是飞行提醒/告警系统负责提供主要的信息源。通过系统监控相关的中央提醒/告警功能，包括消息提醒和语音提醒，就能完成这一过程。飞行提醒/告警系统连同 MMEL 清单中的项目一起，能为飞行机组和维护人员提供决定飞机派遣状态的基本信息。

　　对于 IMA 系统作为一个整体所给出的状态以及单独的组件与宿主应用所给出的状态，有一些与系统降级相关的状态需要通告给机组人员。飞行提醒/告警系统可以有选择地禁止一些告警以减少来自级联失效的影响，通常来说，对所有的失效和系统降级以及重构的活动都要报告。

　　哪些故障、失效和错误需要进行登记、报告或显示给飞行机组都要适当地确定出来。这些通知可以只限于这些情况：系统不能恢复的失效(如，硬件失效)、导致性能降级或降级模式的失效、可能降低飞机或系统安全边界的失效(如，丧失了冗余或完整性)、潜在的不安全状态或功能性丧失的告知。对显示给飞行机组的 IMA 系统故障信息应进行分析，以确保它们没有歧义，并给它们分配适当的优先级，所显示的信息和语音提醒都应该以清晰且优先的方式提供给机组人员。

　　5.7.7 维护活动与报告的管理

　　维护人员应能够分析健康监控数据，确定出已失效的或已表现出异常行为的系统组件，并且决定采

　　取最合适的维护活动(例如，延期、测试、修理、替换， 等)。IMA 系统的综合等级、相关性和 IMA 系统的复杂性所导致的潜在失效模式，与联合式系统架构相比可能更独特并且更多(例如，所有的功能都会受到单个共享资源丧失的影响)。电源瞬变、级联失效或影响共享资源的失效，都能导致多个功能和宿主应用同时失效，并且会有多个失效、告警、提醒或警示消息被记录和通告给飞行机组。虽然这里描述的许多特性起源于传统的联合式系统，但为了减少故障的传播，并区分出问题是与平台相关还是与应用相关，应特别重视与 IMA 系统内自测试设备(BITE)故障报告的故障关联关系。

　　一般来说，机载系统的维护性也应与飞机的安全性、可靠性和保障性目标一起考虑，对这些相关目标的分析也可确定出预防性维护活动的特有方面。

　　5.7.8 冗余管理

　　冗余用来改善飞机功能的可靠性与可用性，IMA 平台和/或系统可包含支持宿主应用冗余管理的机制，IMA 系统应建立冗余管理的规则，只要有可能，冗余的管理应独立于宿主应用，以支持应用和平台各自的分析与开发。

　　有些宿主应用可能需要专用的冗余管理，对于这种情况，IMA 系统应该对平台资源的健康以及与应用交互的其他模块的健康提供正确和相协调的信息。

　　5.7.9 单粒子翻转(SEU)故障

　　通过资源共享，如电源、计算机处理能力、存储器以及数据总线等，IMA 系统能在一台计算机环境中宿主若干飞机功能和应用。共享资源中可能发生单粒子翻转， 会对多个不同飞机功能、应用和分区产生有害影响。IMA 平台设计和故障管理策略应处理潜在的单粒子颠覆并提供相应的恢复能力。

　　5.8 IMA 系统的配置管理

　　5.8.1 概述

　　取证申请人应为飞机运营者提供强壮的且易于维护的配置管理系统，IMA 平台的开发者应为取证申请人提供相关的能力和方法，来确定 IMA 系统、平台、模块、资源、功能与宿主的应用和数据库的配置。IMA 系统由多种通用的共享资源组成，这些资源可以用传统的方式标记，也可以用电子部件编号来标记。在维护飞机和 IMA 系统的配置过程中，飞机运营者的任务与行为应该简单并可验证。应给飞机的运营者提供操作规程，以便在维护 IMA 系统时能简化工作任务，并减少操作者错误和过失的可能性。应给飞机的运营者提供一种方法，以便能验证飞机和 IMA 系统的配置与所认证的配置是一致的，且符合型号的设计。

　　所要处理的问题有：

　　a) IMA 系统软件和硬件部件的编号所需的配置数据范围。

　　b) 作为受控配置项中的配置数据。

　　c) 配置数据之间的一致性。

　　d) 没有得到认证机构监管的用户可修改的硬件、数据库和软件。

　　e) 重新获取模块和应用部件编号，用于一致性检查的能力。

　　f) 有多种、可选的配置(可选模块的选用情况)。

　　g) 现场可加载的模块(硬件、软件、数据库)。

　　h) 完成变更操作后，配置数据的维护。

　　i) 用于提供验证方法的配置实践：

　　1) 安装在系统中的所有硬件部件编号和序列号;

　　2) 对硬件修改的所有状态标识;

　　3) 安装在系统中所有软件(包括宿主应用与核心软件)部件编号的标识;

　　4) 安装在系统中所有配置数据的标识;

　　5) 安装在系统中所有数据库文件的标识;

　　6) 对于特定的飞机，所有硬件、软件和数据库文件的部件编号都要正确;

　　7) IMA 模块、资源与宿主应用融合在一起的兼容性，特别是与现场可加载部件有关。

　　5.8.2 配置数据

　　5.8.2.1 概述

　　IMA 系统和宿主应用都应该维护系统中的配置数据。这些配置数据组是飞机认证的符合项(型号设计的数据)并应包括在认证数据包之中。对这些配置数据要证明可以追溯到派生出它们的应用和模块需求上。通过评审、分析和测试等方法的组合可以对这些文件的正确性的验证进行证明。

　　IMA 系统应管理宿主应用及其配置数据的现场加载，IMA 系统可以使用这些文件中的信息来确定应用、应用的资源需求或应用状态的正确配置。应用开发者负责设计并保证宿主应用所用的配置数据，配置数据的获取应独立于 IMA 系统的设计与保证活动。

　　5.8.2.2 IMA 系统的配置数据

　　IMA 系统的特有配置数据受具体认证指南的影响，例如，期望 IMA 系统能包括应用调度和资源分配的配置数据。这种数据能够以一组建立的配置表或文件在构建时实现，或者以独立加载的数据来实现。

　　在本节中所描述和讨论的配置数据，由 IMA 系统用来：

　　a) 在飞机的 IMA 系统安装时，定义或选择 IMA 系统的正确配置;

　　b) 使能配置控制，并支持 IMA 系统、平台、模块、资源和应用的一致性检查;

　　c) 激活或解除模块、资源或功能， 例如，利用有可选择项目的软件或数据，使软件适应飞机的几种配置;

　　d) 确定分配给宿主应用的 IMA 系统资源;

　　e) 确定分区间通信端口的特性与分配情况;

　　f) 确定影响综合系统的其他参数(例如，调度、性能、模块的部件号)。

　　IMA 系统的配置数据可以相互依赖，这样就能考虑用一组配置数据来构成一整套 IMA 系统的配置。这种整套的配置可以作为一个最终要提供的认证数据条目来控制。

　　5.8.2.3 应用的配置数据

　　由 IMA 系统中宿主应用使用的其他类型的配置数据可以：

　　a) 激活或解除某些功能或专用应用资源(例如，利用宿主应用的有可选择项目的软件或数据，使软件适应飞机的几种配置);

　　b) 使应用适应飞机的配置;

　　c) 为宿主应用提供数据。

　　5.9 共享数据库的使用指南

　　包括在飞机系统中的数据库给应用提供静态