ICS 49.090 V 45
HB/Z 424-2015
民用飞机综合模块化航空电子系统(IMA)中实时操作系统及组件综合指南
Real-time operating system integration guidance and component
integration consideration for IMA of civil aircraft
2015-07-14 发布 2016-01-01 实施
中华人民共和国工业和信息化部发布
前言
本指导性技术文件按 GB/T 1.1-2009 给出的规则起草。
本指导性技术文件由中国航空综合技术研究所归口。
本指导性技术文件起草单位：中国航空工业集团公司第六三一研究所、中国航空综合技术研究所。
本指导性技术文件主要起草人：孔德岐、王纯委、朱晓飞、王卫东、黄永葵、刘文学、田莉蓉、胡辛、刘文。
民用飞机综合模块化航空电子系统(IMA)
中实时操作系统及组件综合指南
1 范围
本指导性技术文件对民用飞机综合模块化航空电子系统(以下简称 IMA)开发过程中实时操作系统(以下简称 RTOS)综合及组件综合过程中的部分问题、实践和活动进行了考虑，重点关注 IMA 系统开发者、综合者、审定申请人以及批准人的活动。
本指导性技术文件适用于民用飞机 IMA 开发过程，可在 IMA 系统开发综合阶段初期为工业界和审定机构提供帮助和参考。
2 规范性引用文件
下列文件对于本文件的应用是必不可少的。凡是注明日期的引用文件，仅所注日期的版本适用于本
标准。凡是未注明日期的引用文件，其最新版本(包括所有的修改单)适用于本文件。
HB/Z 420 民用飞机机载电子硬件合格审定保证指南
HB/Z 421 民用飞机机载系统和设备软件合格审定保证指南
HB/Z 422 民用飞机综合模块化航空电子系统开发与认证指南
ARINC 615A 采用以太网接口的软件加载器(Software data loader using ethernet interface)
ARINC 651 综合模块化航空电子系统设计指南(Design guidance for integrated modular avionics) ARINC 653 航空电子应用软件标准接口(Avionics application software standard interface)
FAA AC 20-148 可重用软件组件(Reusable software components)
FAA TSO-C153 综合模块化航空电子系统硬件(Integrated modular avionics hardware elements)
(Guidelines for communication，navigation，surveillance，and air traffic management systems software integrity assurance)
SAE ARP 4754 高度综合或复杂飞机系统的适航审定考虑(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
应用 application
软件和/或定义有一组接口的专用硬件，与某个处理平台综合后能执行某种功能。
3.1.2
应用供应商 application supplier
为软件和/或专用硬件提供确定的一组接口的开发者，当这些软硬件与某个平台(处理平台或 IMA平台)综合后能执行某种功能。
3.1.3
背板 backplane
由电气连接点组成的物理电路板卡和组件，用于把机箱内的资源连接到机箱外和综合化航空电子模块上。
3.1.4
基线 baseline
已批准的、记录有一个或多个配置项的配置。它作为进一步开发的基础，且只能通过更改控制程序才能对其进行更改。
3.1.5
板级支持包 board support package
在硬件和 RTOS 之间的一层软件，其允许 RTOS 在不同的硬件配置上运行。
3.1.6
通道 channel
在分区之间进行通信的路径，由一组有逻辑连接关系的端口组成。
3.1.7
约定 commitment
由模块或组件提供的一种假设、限制规定、性能约束、行为约束、配置或功能。为了正确地操作这些模块或组件，用户必须要关注的内容。
3.1.8
组件 component
自身含有硬件、软件、数据库或其组合，且受配置管理的控制。
3.1.9
核心软件 core software
用于管理处理平台资源的操作系统和支持软件，为应用提供运行环境。
3.1.10
可构成性 composability
为满足特定用户的需求，在各种组合中选择和组装系统组件来构成有用系统的能力。
3.1.11
循环的 cyclic
以固定的、重复的规则出现的活动，不要求固定的时间间隔。
3.1.12
数据库 database
至少由一个文件组成的数据集(另一个数据集的部分或全部)，对于确定的目的或给定的数据处理系统，其是充分的。
3.1.13
截止时间 deadline
一个过程必须完成某种规定活动的一个时间点。
3.1.14
确定性/确定性的 determinism/deterministic
基于之前的操作来产生预期结果的能力。这种结果发生在规定的时间范围内，具有一定的可重复性。
3.1.15
失效 failure
在规定的范围内，系统或系统组件不能执行(完成)所要求的功能。当故障发生时，可能产生失效。
3.1.16
故障 fault
在硬件或软件中的错误的一种表现。故障可以引起失效。
3.1.17
故障，共模 faults, common mode
在几个构型相同的、有余度的硬件或软件组件中， 由一个错误导致多个重复故障。典型情况是“所设计进去的故障 ”。
3.1.18
故障检测 fault detection
正确确定失效发生(例如故障被触发)的能力。
3.1.19
故障隔离 fault isolation
一旦失效发生，系统确定故障位置的能力。
3.1.20
联合式系统 federated system
由现场可更换单元(LRU)组成的一种飞机设备架构，这些 LRU 能执行特定的功能，并通过专用接口或飞机系统数据总线相互连接。
3.1.21
增量式认可 incremental acceptance
获得审定局方信任的一种过程，这一过程要通过认可或确定 IMA 模块、应用和/或未安装在飞机上
IMA 系统符合特定要求来进行批准或审定。对每个单项任务的信任能实现整个审定目标。
3.1.22
独立性 independence
第一种解释——职责的分离，这种分离能确保达到客观的评价。
a) 对于软件验证过程活动，独立性的实现就是，验证活动由被验证项的开发者之外的一个或几个人进行，且工具可用来完成与人工验证活动等效的活动。
b) 对于软件质量保证过程来说，独立性还包括能确保纠正活动的权威机构。
第二种解释——一种设计理念，它能确保一个项的失效不会引起另外一个项的失效。
3.1.23
初始化 initialization
一个活动序列，该活动能把系统或其组件引导到操作就绪的状态。
3.1.24
综合模块化航空电子 integrated modular avionics (IMA)
能够共享的一组可变化的、可重用的、可互操作的硬件和软件资源。这些资源能够创建一个平台(即IMA 平台)，该平台针对所定义的一组安全和性能要求，能为执行飞机功能的应用提供所设计的和已验证的服务。
3.1.25
链接程序 linker
能够把多个独立的目标码模块装配到一起的程序，这些模块通过相互调用形成一个可执行的目标码模块。
3.1.26
加载程序 loader
能够把目标程序和数据从一些外部介质上传送到目标系统非易失存储器中的一段程序。
3.1.27
消息 message
一个有固定长度的连续数据块，它由系统进行传输(既可以通过网络，也可以在模块内)。
3.1.28
模块 module
自相容或者在 IMA 系统的环境下相容的一个组件或一组组件的集合。一个模块可以由其他多个模块组成。模块可以是软件、硬件或软件和硬件的组合，这些软硬件能为 IMA 系统中宿主的应用提供资源。
3.1.29
分区 partition
一种资源的分配，资源具有得到处理平台保证和保护的属性，不会受到来自分区外不利的作用或影响。
3.1.30
周期的 periodic
以固定的时间循环地发生。
3.1.31
处理平台 processor platform
由一个或一组模块组成的一个处理单元，其内部包含有核心软件，可对资源进行管理以支持至少一个应用的运行。
3.1.32
端口 port
一个由分区定义的资源，用于在某一特定的通道上接收或发送消息。端口的特性确定了消息的要求和控制传输所需要的特征。
3.1.33
抢占 pre-emptive
采取或启动，用来阻止或延迟一个正在参与的过程。正在执行的过程可以被挂起以允许更高优先级的过程来执行。
3.1.34
优先级翻转 priority inversion
设定一个比其分配的优先级更高或更低的过程。这可能引起以下问题：低优先级的任务 L 和高优先级的任务 H 共享一个资源，在任务 L 得到此资源不久，任务 H 就变成了运行就绪，但任务 H 必须要等待任务 L 完成对此资源操作，因此任务 H 将处于挂起状态。在任务 L 完成对此资源的操作之前，任务 M 变成运行就绪，并抢占任务 L，在任务 M 运行时(且也许还有另外的中等优先级任务出现)，系统中的最高优先级任务——任务 H 仍保留在悬挂状态。
3.1.35
进程 process
一个包含在分区内的程序编程单元，它与同一分区的其他进程能同时运行。进程等同于任务。
3.1.36
余度 redundant
为完成一个给定的功能，而结合在一起的多条途径。
a) 下列余度架构工作原理之间有所不同：
1) 相似余度(具有相同类型的多条途径);
2) 非相似余度(具有不同类型的多条途径);
3) 时间余度(通过进行重复操作来实现余度)。
b) 余度架构的操作可分类如下：
1) 主动余度(多条途径执行例行操作，并参与执行任务);
2) 被动余度(只有在故障或失效的情况下，新增的途径才参与执行任务);
3) 热被动余度(新增的途径总是打开的);
4) 冷被动余度(新增的途径只是在故障或失效的情况下才打开)。
3.1.37
健壮分区 robust partitioning
一种在任何环境下，包括硬件和编程出现错误时，宿主在共享计算资源中的独立飞机操作功能保证能够保持隔离的机制。健壮分区的目标就是提供与联合式方式等级相同的功能隔离。
3.1.38
挂起 suspended
处于等待状态下的过程。执行暂时停止，等待其他活动完成或某一事件发生。
3.1.39
系统分区 system partition
一种需要由 ARINC 653 定义的服务以外的接口分区，受强空间和时间分区化的限制。系统分区可以执行这类功能，如管理来自硬件设备的通信或故障管理(FM)机制。系统分区是可选的，且特定于核心模块的实现。
3.2 缩略语
下列缩略语适用于本文件。
AC——咨询通告(advisory circular)
APEX——应用与执行(application/executive)
API——应用程序接口(application programming interface)
ASP——架构支持包(architecture support package)
ASTC——改型的补充型号审定(amended supplemental type certificate)
ATC——改型型号审定(amended type certificate)
BSP——板级支持包(board support package)
CCA——共因分析(common cause analysis)
CIA——更改影响分析(change impact analysis)
CM——配置管理(configuration management)
CPU——中央处理单元(central processing unit)
COTS——商用货架产品(commercial off-the-shelf)
CRC——循环冗余检查(cyclic redundancy check)
EEROM——电可擦除只读存储器(electrically erasable read only memory)
FM——故障管理(fault management)
HIRF——高强度辐射场(high intensity fadiated field)
HM——健康监控(health monitor)
IMA——综合模块化航空电子(integrated modular avionics)
IMAS——综合模块化航空电子系统(integrated modular avionics system)
IMASAS — — 综合模块化航空电子系统完成情况总结(integrated modular avionics system accomplishment summary)
IMASCI——综合模块化航空电子系统配置索引(integrated modular avionics system configuration index)
IMASCP——综合模块化航空电子系统审定计划(integrated modular avionics system certification plan)
IMASVA——IMA 系统脆弱性分析(IMA system vulnerability )
I/O——输入和/或输出(input and/or output)
IS——基础软件(infrastructure software)
LRU——现场可更换单元(line replaceable unit)
MAP——模块认可计划(module acceptance plan)
MMEL——主最少设备清单(master minimum equipment list)
MMU——存储器管理单元(memory management unit)
MAAS——模块认可的完成情况总结(module acceptance accomplishment summary)
OS——操作系统(operating system)
PHAC——硬件审定计划(plan for hardware aspects of certification)
PLD——可编程逻辑器件(programmable logical device)
PROM——可编程只读存储器(programmable read only memory)
PSAC——软件审定计划(plan for software aspects of certification)
PSP——安全性合作关系计划(partnership for safety plan)
PSSA——初步系统安全性评估(preliminary system safety assessment)
QA——质量保证(quality assurance)
RAM——随机存取存储器(random access memory)
RMA——速率单调分析(rate monotonic analysis)
RMS——速率单调调度(rate monotonic scheduler)
ROM——只读存储器(read only memory)
RTOS——实时操作系统(real-time operating system)
RSC——可重用软件组件(reusable software component)
SAS——软件完成总结(software accomplishment summary)
SCI——软件配置索引(software configuration index)
SEU——单粒子翻转(single event upset)
SI——系统综合者(system integrator)
SOI——阶段介入(stage of involvement)
SQA——软件质量保证(software quality assurance)
SSA——系统安全性评估(system safety assessment)
STC——补充型号审定(supplemental type certification)
SVP——软件验证计划(software verification plan)
TC——型号审定(type certification)
UVPROM——紫外线可编程只读存储器(ultra violet programmable read only memory)
V&V——确认与验证(validation and verification)
WCET——最坏情况执行时间(worst-case execution time)
WDT——看门狗定时器(watchdog timer)
4 综合活动概述
4.1 IMA 系统概述
4.1.1 IMA 系统的目标
IMA 系统的复杂性对研制者(如 RTOS、平台、模块和应用的供应商，以及系统和飞机的综合者)、使用者(如主机的开发者、航空公司、飞行机组以及维护人员)和审定机构都提出了挑战。在系统的开发、验证和审定过程中，各参与方需要密切合作，并需要对各因素进行仔细审查。但是 IMA 系统的总目标对于每一方来说几乎都是相同的，那就是，要研制一个安全的 IMA 系统，它必须是：
a) 完整的——与各模块、组件和应用相关的信息应包括相关的需求和假设， 需求和假设或来自于
其他的模块、组件和应用，或提供给其他的模块、组件和应用，并且应由参加 IMA 系统开发的各方所共享。
b) 可验证的——人工或工具能检查模块、组件和应用之间的操作和资料的正确性。
c) 相容的——一种协调统一的系统设计与方法，能维持信息和资源的共享，且解决了所有的冲突。
d) 可修改的——系统可进行更改，更改会对其他系统的模块、组件和应用产生可识别的、有限的和有因果关系的影响。如果可修改的信息是结构化的， 那么当保持这种结构时，变化就可以是完整的，相容的和正确的。
e) 可追踪的——信息从其产生者到其使用者都应该是可见的，以允许适当地确定信息的改变对相关产生者和使用者产生的影响。
f) 无二义的——信息应只允许有一种解释，必要时可利用辅助定义。
g) 可恢复的——在系统发生异常时，IMA 系统能够从任何事件中有效恢复，以继续进行安全的操作。
建议由 IMA 系统的开发者形成一种方法，能够度量实现上述 IMA 系统开发目标的效果。
把 IMA 系统设计成能接受模块或组件的系统，这些模块或组件可能是商用货架(COTS)产品。随着IMA 系统能力的增强，COTS 组件可能会含数百万行有不安全特性的代码。当越来越多的 COTS 硬件处理器被用于 IMA 系统时，IMA 系统的开发者应该考虑一个附加目标，即“可信系统的构建来自可信的组件 ”。
4.1.2 IMA 系统的目标链
HB/Z 422 详细地描述了参与者或利益相关者为了使 IMA 系统在飞机或发动机的安装中获得批准所需注意的问题。在 HB/Z 422 中列出的目标可以对应到开发特定 IMA 系统的不同角色中。在本指南中，并未给角色分配目标，原因是 IMA 系统架构的变化以及开发过程中角色的变化较大，不适合将目标映射到角色上，对目标的分配活动应在 IMA 系统提交计划中进行规定。目标的分配称为 IMA 系统的目标链，因为目标并没有传递到下一级的角色承担者，而却由下一级的角色承担者所使用，且对其具有一定的责任。目标的分配和责任的设定都必须全部写入到 IMA 系统所提交的计划中，特别是只能部分对应到角色承担者的那些目标。
角色承担者之间的沟通方式要在文件中予以规定，由于责任的设定可能跨越合同规定的义务或组织界限，且在系统开发中需要及早制定计划并达成一致，因此用文件规定沟通方式至关重要。虽然没有任何指南材料要求用文件规定，但相关人员认为需要创建一份 IMA 系统的安全性合作关系计划(PSP)，用它来详细描述 IMA 系统各参与方的义务。通常，PSP 以协议形式编写，描述审定机构和审定申请人如何开展产品审定并确定常规的时间节点和预期工作。它需要包含审定机构的规章、指南和政策， 以及当前现有的批准部门或机关。它还要记录审定申请人的代表和工作程序，以及产品审定的途径。IMA系统的安全性合作关系计划文件是一种用来在审定申请人和审定机构之间协调团队工作、沟通和责任的手段。
4.1.3 IMA 的角色
IMA 系统从根本上来说是由一组模块、组件和应用所构成的，它们被综合在一个系统中来提供航空功能。据此， 可单独开发系统的部件，然后再综合到一个功能系统中。该部件通常是由明确角色的不同团队或组织来管理的。在 HB/Z 422 中，定义了六种类型的利益相关方或角色：
a) 审定机构——代表国家制造业负责批准的组织或个人;
b) 审定申请人——寻求获得审定机构批准的个人或组织;
c) IMA 系统综合者(SI)——将处理平台、模块和带有宿主应用的组件综合到一起形成 IMA 系统，执行这些必要活动的开发者;
d) 平台和模块供应商——提供一个模块或一组模块，包括以某种方式来管理资源，充分支持至少一个应用资源的核心软件的开发者;
e) 应用供应商——提供软件和/或带有定义了接口的专用硬件的开发者，当这些软硬件与平台综合时，能够执行一种功能;
f) 维护组织——IMA 系统的拥有者或负责维护 IMA 系统和飞机的组织。
在 IMA 系统开发和认可的整个过程中，每个角色都起着重要作用，其中IMA 系统的综合者、应用的供应商以及平台和模块的供应商等角色是相对比较重要的。平台和模块的供应商要为 IMA 系统提供RTOS、硬件和其他支持软件。 RTOS 的供应商与平台与模块供应商的角色一样，对涉及 IMA 系统的空间、时间、输入和输出，以及其他共享资源的保护有重要的责任。
4.1.4 IMA 系统的架构
IMA 系统有多种不同的形式，本部分将描述 IMA 系统的形式和相关的角色。IMA 系统可包含有大量的功能，其范围可从一个简单的硬件平台与相关的操作软件到一种复杂系统的系统群。HB/Z 422 的附录 D 中描述了几种 IMA 系统的配置，称为简单的 LRU 平台、简单的分布式 IMA 系统、复杂的分布式 IMA 系统，以及能使用所存储的应用来进行重构的健壮分区系统。
ARINC 653 规定了在 IMA 系统中应用软件的基本操作环境。在航空电子系统计算机资源的 RTOS与应用软件之间，ARINC 653 提供了一种通用的 APEX(应用与执行)接口。
4.2 综合阶段活动的综述
4.2.1 概述
IMA 系统的开发要求所有参与方都要尽职尽责，以保证系统的开发、组装、验证、部署和维护具有完整性、可验证性、协调性、可修改性、可追踪性、无二义性以及从异常状态的可恢复性等属性。各参与方的角色已在 4.1.3 中提出。在任意一个特定的 IMA 系统的开发过程中，可为各角色分配不同的职责，职责的分配应该在整个 IMA 系统开发计划中进行描述。无论职责如何分配，以上提到的全部特性都要落实，且要求有保证活动，以使这些特性可以支持系统通过审定机构的批准。每个角色在 IMA系统的开发和部署中都是有一定关联的。每个角色都会对系统的某些部分产生或接受一些约定和符合性的义务，而这些部分是由该角色来负责的。在本指南中的约定被定义为 IMA 模块、应用或组件的任意一个项，且需要另一个 IMA 模块、应用或组件的通信或动作，其内容包括记入文件的模块或组件假设、限制、制约、性能约束、行为约束、配置，以及降低的能力。本指南中的符合性能够证明满足 HB/Z420、 HB/Z 421 或 HB/Z 422 目标所需的信任，对每一项目标的符合可以是完全地满足也可以是部分地满足。如果是部分地满足要求，那么所达到的目标应该列入文件之中，并且，需要由另一角色完成的其他目标也要列入文件之中，以完全满足目标的覆盖面与符合性要求。整个系统的开发和规定的特性、约定和活动与演示的相关保证最终都是由审定申请人负责的。
图 1 给出了一般的 IMA 系统开发的综合阶段，这些阶段以功能和复杂性的递增而增加，而且允许使用增量认可模块、平台、应用和系统的手段。增量认可定义为：
“获得信任的一种过程，这一过程要通过认可或证实 IMA 模块、应用， 和/或未安装在飞机上的 IMA 系统符合特定要求的来进行批准和审定。获取每个单项任务的信任有助于系统审定的全部要求。”
综合阶段的变化取决于所开发的 IMA 系统。综合的关键在于在这些阶段内和阶段之间，模块、组件和应用中的约定与符合性信任应该得到有效地识别、控制，且在所有相关角色之间能进行有效地沟通，确保 IMA 系统的完整性。
4.2.2 综合阶段 1——RTOS 与硬件平台的综合
综合阶段 1 把系统的核心软件模块或组件(RTOS、BSP 等)与硬件模块或组件结合到一起，形成一
个处理平台。这是最低级别的综合， 主要涉及处理平台或模块的供应商和 RTOS 的供应商，该过程对正确操作 IMA 系统是很必要的。
□ 综合阶段 1——把组件/模块综合到一起形成一个处理平台;
□ 综合阶段 2——把单个的应用综合到一个处理平台之中;
□ 综合阶段 3——把多个的应用综合到一个处理平台之中;
□ 综合阶段 4——把多个处理平台综合成一个 IMA 系统;
□ 综合阶段 5——把 IMA 系统综合到飞机中(飞机级综合)。
注 1：一个 IMA 系统有可能只包含一个应用或一个处理平台。
注 2：对于只有一个应用的 IMA 系统，则不需要综合阶段 3 和 4。
注 3：对于有多个应用但只有一个处理平台的 IMA 系统，则不需要综合阶段 4。
图 1 IMA 系统的综合阶段
处理平台和模块的供应商为 IMA 系统上运行的应用提供可用的资源，包括处理器、协处理器，以及相关的存储器、定时器和 I/O 设备等。硬件平台的来源可以是一个或一组定制的目标板，也可以是系统中的一套可组合的部件，这套部件可能已经具备了一定的鉴定级别或服务历史的符合信用证明。
在硬件和 RTOS 之间是一个定制的 BSP 或架构支持包(ASP)软件，这些软件通常是由 RTOS 供应商提供的一种接口软件包，可使通用的 RTOS 内核在各种不同的微处理器和硬件配置上运行。
ASP 可能包含附加组件，它们合起来称为基础软件(IS)。基础软件提供可由多个应用来使用的公共服务。这些服务通常由处理平台的供应商来提供，常与 RTOS 和 BSP 相结合来提供如文件系统、数据载入和上电自检等功能。在 RTOS 为软件的执行提供控制和管理，以及 BSP 为硬件组件提供直接访问时，基础软件与 BSP 和 RTOS 相结合为公共功能提供高级别的接口。
RTOS 的供应商必须遵守 BSP 和 ASP 的硬件规范。一般情况下，RTOS 的供应商应与处理平台的供应商共同协调其开发活动。明确定义处理平台正常运作所需要的角色和约定， 并在 RTOS 供应商和处理平台供应商之中得以实施是至关重要的，综合化的核心软件和处理平台必须提供 IMA 系统安装所需的服务和资源来支持 IMA 这个概念。RTOS 供应商和处理平台供应商并不能确保 IMA 系统本身正常运作，使 IMA 系统正常运作是 IMA 系统的综合者和审定申请人的责任和任务，由于这种角色定义，在 IMA系统的开发过程中，通常可以创建多个版本的核心软件。
平台、模块或者 RTOS 的供应商，可能会提供一些附加的功能以支持特定的 I/O 设备。设备驱动程
序可能需要直接访问特定的内存单元或寄存器，或者需要将存储器设置为阻止对专用于内存映射 I/O的内存地址进行高速缓存。这种 I/O 软件可能会自动地通过内存映射或有某种硬件支持的机制自动地来工作，而不需要 RTOS 的直接支持。
设备驱动程序可能在特定的系统分区中提供，这些分区可能会有一些附加的特权，但应与应用分区一起来调度。此外，IMA 系统可能提供健康监控(HM)、故障管理(FM)、资源管理和以及其他的一些通用平台服务，这些服务可宿主在系统分区内。作为处理平台的一部分，这些系统分区应作为综合阶段1 中系统的一部分来对待。
对综合阶段 1 中系统的验证应在综合阶段 1 的专用验证计划中进行策划，该计划将在处理平台上全面施行，包括测试核心软件的服务、模块上的资源、接口、通信、健壮分区、健康监控(HM)，以及其他平台提供的服务。
综合阶段 1 的详细输出在 HB/Z 422 中详述。
4.2.3 综合阶段 2——单个应用与处理平台的综合
综合阶段 2 将单个应用集成到一个处理平台中，以证实该应用能否满足其功能要求。可以采取多种IMA 系统开发方法来提高 IMA 系统开发的时间进度，如在综合阶段 2 中可以在多个处理平台上执行一个应用，进行并行测试以提高 IMA 系统开发的进度。
综合阶段 2 中的综合活动侧重于应用与处理平台的核心软件、服务、资源管理和硬件组件之间的接口，以确保其完整性和实施正确性。尽管可能需要某些特殊的链接机制来对内存使用进行安排以提供更大的灵活性，链接程序与加载程序还是被用来执行这种综合过程。某些特殊的链接机制可能是必要的，以允许代码重定位或要避开由硬件施加的寻址限制。因此，计划在最终 IMA 系统中要用到的编译程序和链接程序的选项，应该在这个综合阶段中加以使用。对每个分区和应用的初步时间和内存分配， 可以在本综合阶段中予以确认。
IMA 系统中模块、组件和应用的开发要具备一些内在的灵活性。几个内存区域可以组织到一起，并由几个加载到处理平台上的应用来共享。存储器区域可能映射到不同的存储器类型上，例如 FLASH存储器、随机存取存储器(RAM)或者只读存储器(ROM)，这些存储器可能具有不同的属性，例如共享的、非缓存的和映射 I/O 的等等。RTOS 应建立计算机访问的资源，以控制对受保护内存的访问、构造调度表和通信控制表以及其他的一些内容。配置数据必须要得到验证， 因为其控制着实际目标环境和分区的行为，而应用的任务是要在这些环境和分区中执行的。
一般地，要将应用的供应商和 IMA 系统的综合者的责任结合起来，以完成这个阶段的综合并验证其准确性和完整性。应用的供应商有其自己的专业知识， 能够验证其提供的应用在处理平台上是否可满足要求。当把应用加载到某个处理平台上后，平台供应商也能够验证其提供的处理平台是否可满足要求。为了确保在进行验证时使用的设置是真实的，应用的供应商应规定存储器、定时、 I/O 及其他共享资源的分配和配置。当处理平台要添加应用时，应利用处理平台资源和服务来描述应用所期望的配置情况。
为了确保上述情况是可行的，应用的供应商和 IMA 系统的综合者应商定应用所需的最少资源和服务，以在上述配置情况下进行验证。特别是应利用存储器、调度和定时的规定， 在应用所必需的配置设置下对其行为进行验证。
综合阶段 2 中对处理平台的验证应该在综合阶段 2 的专用验证计划中进行策划，该计划将全面地验证应用在处理平台上的使用情况以及其他相关的限制。
综合阶段 2 的测试以综合阶段 1 的测试为基础，且可能进行应用自身及其与处理平台交互行为的覆盖性分析。在这一阶段还应进行白盒测试(white-box tests),可用来验证处理平台在非常规情况下的行为，如健壮性测试与对故障的反应(不正常的运行状态或模式)。例如， 对调度程序进行白盒测试可确认所设计的定时分析和相关的定时是否异常。
如果处理平台提供有健壮分区，则在综合阶段 2 所获得的验证符合信任可能就足够了，没有必要在
一个平台上使用多个应用重复进行这种验证，或者将所有的宿主应用都安装到 IMA 系统中。
综合阶段 2 的详细输出在 HB/Z 422 中详述。
4.2.4 综合阶段 3——多个应用的综合
通常情况下，综合阶段 3 的活动应在综合阶段 1 和 2 完成后开始。综合阶段 3 是把另外的一个应用或一组应用综合进来。IMA 系统的综合者可以选择逐步增加应用进行综合，或选择以某种顺序综合相关的一组应用。随着应用的增加，这种综合过程将使得 IMA 系统的综合者能够识别和隔离问题。
综合阶段 3 建立在综合阶段 1 和 2 及其相关活动的基础上，且假定每个单独的应用已经在同一目标平台的处理器上通过了综合阶段 2 的验证，综合活动的目标就是要验证多个应用在单个处理平台上的运行情况是否正常。综合阶段 3 应能对资源管理、共享资源的分配，以及健康监控(HM)、故障管理(FM)和其他共享服务给予测试和确认。
如果提供了健壮分区环境，且使用的配置设置与之前测试应用时相同，并假设这些设置是正确的且能支持终端项系统，那么每个应用的行为都不会因增加其他应用和任务而受到影响。在这一阶段里，存在多个应用共享资源的情况，包括共享数据总线，I/O 端口等。因此， 数据总线的流量、中断的使用等可能会有所不同，这些都应作为综合验证的一部分来进行处理。在该阶段的一开始，需要先确认每个被测应用的配置是否与先前进行测试时所用的配置相同，随后，应该对负载、与 I/O 的交互、通信总线的争用、存储器的覆盖等进行测量。审定申请人和 IMA 系统的综合者需要适用审定机构承认的办法，以获得全部的合格信任。
对综合阶段 3 中系统的验证，应该在综合阶段 3 的专用验证计划中策划。该计划将全面地验证所有应用在使用 IMA 平台、服务、资源、假定以及相关的限制方面的情况。验证活动包括验证应用和分区之间的交互作用是否合适和受控。需要对数据总线和 I/O 消息的是否使用正确及其准确性进行测试。综合阶段 3 的验证应检查信息传输的时间规范是否能满足所有应用。对这些方面的分析会对工程项目和相关合格信用可以产生重大影响。例如， 时钟源可以有几种可能性，轻微地违反 RTOS 的约束可以很简单地予以更正，但如果一个 RTOS 的前提被忽略了，可能需要更具挑战性工作才能更正 IMA 系统的设计，或者在先前认可的 RTOS 中发现有调度问题，就可能使模块的认可信任完全无效。不仅要针对定时，对其他共享资源，如内存、高速缓存、缓冲器、I/O 及通信带宽也要进行分析。
综合阶段 3 的详细输出在 HB/Z 422 中详述。
4.2.5 综合阶段 4 和阶段 5
综合阶段 4 是针对由两个或两个以上处理平台构成的 IMA 系统所要进行的综合，这些平台都有宿主应用，其硬件、RTOS、核心软件服务、资源以及所宿主应用的配置可能有所不同，但对于有冗余和有可靠性要求的系统，则是相同的。
综合阶段 5 是把 IMA 系统与其他系统综合到飞机上或发动机上。与综合阶段 1、2 和 3 相同，综合阶段 4 和 5 应使用专用验证计划进行验证，该验证计划将全面验证需求和约定，并帮助证实系统的假设。对综合阶段 4(把多处理平台综合成一个 IMA 系统)和综合阶段 5(把 IMA 系统综合到飞机上)的进一步指导可从 HB/Z 422 参考文件获得。
综合阶段 4 和阶段 5 的特定输出在 HB/Z 422 中详述。
4.3 IMA 系统生命周期中阶段、结果和约定的综述
4.3.1 概述
IMA 系统开发的每个阶段都要产生一组可提交的文件，其目的是支持将最终的 IMA 系统安装到飞机上或发动机上，也支持 IMA 系统获得安装和飞机产品的审定批准。在开发 IMA 系统的整套数据和提交文件中，系统开发的各角色和责任方应该参与到 IMA 系统开发的所有阶段。这些阶段和活动包括联
合式系统开发生命周期中所有典型的过程和活动，如(但不限于)策划、飞机的安全性评估、系统安全性评估、需求、设计，实现、验证和生产。下列是系统级和组件级的现有行业指导文件：
软件开发指南(HB/Z 421);
硬件设计指南(HB/Z 420);
航空电子系统计算机资源指南(DO-255);
IMA 系统开发指南审定(HB/Z 422);
高度综合化系统的审定(SAE ARP 4754);
安全性评估过程指南(SAE ARP 4761);
可重用软件组件(RSC)指南(FAA AC-20-148);
IMA 硬件单元(FAA TSO-C153);
IMA 设计指南(ARINC 651)。
要有效地开发特定的 IMA 系统还需要增加其他考虑，尤其是当有许多不同的利益相关者负责 IMA系统开发的各个综合阶段的这种情况。
4.3.2 IMA 的策划阶段
审定机构对 IMA 系统的认可需要编制开发计划，包括 IMA 系统的审定计划(IMASCP)和相关的模块的认可计划、针对核心软件和各宿主应用软件的软件审定计划(PSAC)以及针对核心硬件和各宿主的应用硬件的硬件审定计划(PHAC)。这些计划可能是由许多不同的组织制订的， 因此它们的协调性、一致性和可视性对于 IMA 系统成功地获得安装批准来说是非常重要的。IMA 系统的策划阶段将产生一套计划，这些计划通常按层次化组织，包括针对硬件模块、核心软件、平台服务和资源、宿主应用、平台综合、模块综合、宿主应用的综合、IMA 系统的综合、验证与确认、限制、约定和合格信用等的一系列计划。
特定 IMA 的策划阶段的重点是确保 IMA 系统的完整性、协调性和可视性，以支持 IMA 系统的审定批准。
具体的策划活动和职责在 HB/Z 422 中详述。
4.3.3 特定 IMA 的需求阶段
在联合式系统中，将需求写到文件里，并对其进行追踪是比较困难的，对于 IMA 系统来说尤其如此。需求可能来自不同的组织，但所有的需求都应该是一致的、完整的和可验证的。在 IMA 系统的开发组织中，需求的来源、格式和需求的抽象等级更加困难，因此为建立和维持 IMA 系统的需求管理和追踪活动制定一个清晰的计划是必要的。
4.3.4 特定 IMA 的设计与架构阶段
特定 IMA 的设计需求和架构特点是从高级需求或安全目标产生出来的。这些需求和特点往往是派生出来的，且是 IMA 系统开发阶段的一部分，许多约定，制约因素和假设都是在开发阶段做出的。确定 IMA 系统的设计和架构以及 IMA 系统的每一个模块、组件和应用的设计和架构， 并以文件形式加以管理是至关重要的。在 IMA 系统开发过程中，任何相关参与者都能明确其设计特点、先进之处和限制要求。派生需求应该反馈到系统安全性评估过程，以确保对系统的安全目标没有任何不利的影响。
4.3.5 特定 IMA 的组件综合阶段
一般来说，IMA 系统的构建都采用分阶段或增量方式进行，包括使用现有的产品、通用模块或组件。在开发低级别的组件(如带有核心硬件模块的平台、核心软件服务和 RTOS)和高级别模块(如已宿主的应用)过程中，可能需要采用多种不同的技术。
注意，并非前面所述的所有角色(如机械或电气)都要采用这些技术，在综合策划以及综合验证的策
划与过程中，所有的角色、组织和开发领域之间都应该建立明确的沟通和协调渠道。
4.3.6 特定 IMA 的完备阶段——验证
如果在开发阶段没有很好地执行计划和进行协调，将不利于对 IMA 系统的验证。以审查、分析和测试等方式进行的验证，应该列入计划之中，并按增量方式进行，这样开发过程中的问题就容易被发现，并能在项目的早期得到更正。验证 IMA 系统的其他方面还需要更多的工作，例如 IMA 系统的脆弱性分析以及对假设、约定和制约因素的验证。
4.3.7 特定 IMA 的完备阶段——问题追踪
一般情况下，在 IMA 系统的开发过程中，对问题根源的准确辨认是非常必要的。应对问题的确定和解决制定计划，因为在 IMA 系统开发过程中和 IMA 系统部署后，这将会不时地涉及到所有角色的成员。这些活动导致角色成员之间的商业约定的改变。例如，在 IMA 系统的运行过程中，综合已有的 RTOS可能需要签订单独的维护合同，否则，IMA 系统运行中所产生的问题，就可能需要来自不同组织的角色成员所构成的综合团队才能有效地追踪，并查明问题的来源，尽管这些角色成员提供的组件可能没有问题。
当 IMA 系统在开发和运行过程中出现问题时，角色成员之间建立的约定能够确保获得问题的资源。如果所有的角色工作在一家公司，那么很可能只要一个问题报告、追踪和处理系统就能解决问题。在一个 IMA 系统中却可能有许多公司参与，因此很可能存在许多不同的问题汇报系统，这样只有达成协定才能使 IMA 系统综合者(SI)能够对照着平台来追踪所报告的问题，这样做也可使应用开发商能够追踪那些与平台相关的影响应用的问题。
4.3.8 特定 IMA 的完备阶段——配置管理
配置数据的协调要与追踪性的协调相一致，配置管理(CM)包括开发阶段的配置管理和生产阶段的配置管理。每个处理平台、模块和应用的供应商都要有 CM 系统，且每一个角色都必须对他们所产生和交付的产品建立基线，反过来，每个接收模块、组件和应用的角色也必须对他们所接收的产品以及综合到待交付产品中的内容建立基线。
4.3.9 约定与信任阶段
每个组件的开发都要经历策划、需求、设计等典型的开发阶段。当一个阶段完成后，该组件对 IMA系统的其余部分才能产生其约定与合格信任的影响。因此，约定与合格信任的开发将会改变整个项目，对约定和合格信任的开发应该进行策划、控制和追踪，直到最终 IMA 系统完成交付。
5 对综合角色的考虑
5.1 平台与模块的供应商以及 RTOS 的供应商
5.1.1 引言
依照 HB/Z 422，RTOS 的供应商起到平台与模块供应商的作用，RTOS 的供应商负责保护平台和系统中的重要共享资源，如存储器、吞吐量和调度表、I/O 设备和协议，以及其他共享资源。
平台供应商和模块或 RTOS 的供应商需要提供数据,并对其提供的组件进行详细描述。例如，要将这些组件的需求、设计、编码、配置定义以及相关审定机构的认可数据提供给 IMA 系统综合者(SI)，如果适用的话，还要提供给应用的开发者，以支持应用的认可。相关模块的认可计划、配置索引、认可完成情况总结以及数据手册必须提供给 IMA 系统综合者(SI)。模块及模块开发过程中的经历可为合格信任提供深入理解。部分的合格信任以及 IMA 系统综合者(SI)需要做的总结都应予以展示，以获得全
部的合格信任。
电子元器件技术的迅速发展使大多数模块和平台的组件处于持续变化状态。功能方面的变化在开发过程中及在以后的安装及审定后的维护中都会发生。平台和模块的供应商应该开放有关平台或模块的问题报告，以及其在功能性、操作性、性能或安全性方面的影响情况。模块或平台的供应商必须对功能、假设、限制以及给出的使用配置、潜在的安全问题、公开的问题和综合问题等进行详细描述， 必须提供与硬件和软件资源要求或限制有关的所有模块的接口描述数据。平台供应商和模块与 RTOS 的供应商还应提供安装方法说明，包括设备的规范、初始化和模块的验证活动。这些都应提供给审定申请人和/或维护组织。
验证的结果和分析资料都应予以提供，并应包括在最后提交批准的数据资料中。对定时、调度、存储器、数据耦合、控制耦合等内容的分析也应当提供。对软件综合的测试方法、硬件/软件综合测试和健壮性测试等的描述也应包含在提供的资料之内，特别是在安全和有保护要求的领域尤其需要予以提供。平台供应商和模块与 RTOS 的供应商可能不能完全满足 HB/Z 421 和 HB/Z 420 在可追踪性和符合性以及与系统和派生需求一致性方面的目标。因此， 平台供应商和模块与 RTOS 的供应商部分地完成符合性目标是必要的，且必须记录到文件中。
5.1.2 平台与模块的供应商
平台和模块的供应商可能是单独的组织商业实体，平台的供应商提供带有核心软件的硬件处理资源。模块的供应商可独立于平台供应商，为 IMA 系统提供一个或一组组件。平台的供应商应确保所有共享硬件和软件元素以及为平台提供的资源，满足 IMA 系统失效状态分类中的最严酷等级，以保证满足安全性、完整性和可用性的要求。平台供应商的主要责任是对平台的系统安全负责，包括评估 IMA的硬件组件(如网络设备、计算机资源、I/O 设备等)和 IMA 系统的支持软件(如操作系统、核心服务，等等)，但不包括那些运行于 IMA 系统的、执行特定飞机功能的应用软件。因为它关系到其应用的功能，应用供应商的重点是系统安全性。
平台供应商需要承担具体的平台安全评估活动。为评估潜在的失效模式及影响，需要对 IMA 系统特有的一些特征进行检查分析，主要包括(但不限于)健壮分区、健康监控(HM)、通讯、故障管理(FM)和共享的数据与资源(资源管理)。
在飞机功能级别上，一些与软件相关的危害可能直到把平台和所加载的应用程序综合成为一个 IMA 系统时才出现。有些与 IMA 的物理模块和组件相关的失效模式仍需要加以解决，如过热或功率耗尽。如果不了解飞机上平台的配置或平台安装环境的详细情况，就很难评估这些失效模式后果的严重性。利用传统的安全评估技术还是可以确定潜在的失效模式，并能推导出平台要产生的行为，可以依靠潜在的 IMA 系统配置和环境来进行这些评估。软件也会带来一些薄弱点，因此，平台、模块和 RTOS 的供应商需要将限制、对故障模式的响应以及相关的保护机制等写入文件中， 这样相似的安全评估就可以在考虑软件属性的情况下进行。
5.1.3 RTOS 的供应商
本指南将 RTOS 供应商与平台供应商分开对待。一般情况下，RTOS 都与 BSP 综合在一起来为 RTOS提供对某些平台或目标计算机资源的访问与控制。这些资源包括对存储器管理组件(MMU)、时钟或递减计数器、缓存和其他资源与服务进行控制。
为顺利开发并把 RTOS 与平台综合在一起，RTOS 供应商和平台与模块的供应商要密切合作，负责确定从平台到 RTOS 中的硬件特性约定。RTOS 供应商为健壮调度和存储器分区以及其他共享资源的管理提供服务。
5.1.4 保护与分区
一般情况下，平台和模块的供应商与 RTOS 供应商进行基础开发来支持 IMA 系统。他们的主要作
用就是协调 IMA 系统中的共享资源，使其不会产生资源冲突或竞争，并为平台提供其他基本服务，如健康监控(HM)和故障管理(FM)。已开发的平台分区目标就是为综合在一起的模块和应用提供保护，使这些模块和应用在 IMA 系统环境下的运行就能像在自己的专用系统内运行一样。这样设计的保护方式不仅要适应存储器方面的操作，而且还要适应时间、通信以及接口保护等方面的操作。健壮分区是为IMA 系统提供保护的典型方法。
应明确由系统安全性评估所分配的需求，并考虑可能的分区方法来完成所需要的保护。这些方法需要对空间、时间、通信和接口的分区特性进行分解，以适应由系统安全评估所确定的危害和失效状态。需要把用来减缓危害和失效状态的方法反馈到系统安全性评估中，以确保从系统的角度来看，危害和失效状态确实得到了减缓，并且保证该方法不会引入任何新的基于 IMA 系统的危害和失效状态。这个过程是迭代的，且一旦确定要用，则对每个保护属性都要进行详细的分区脆弱性评估。
在脆弱性评估中，对所有可能产生错误的来源都需要加以考虑，包括评估资源的限制、边界条件和假设，以及任务调度、通信、任务队列和 I/O 与中断的错误来源等。对于所有的共享内存类型，包括ROM 和 RAM 内存，高速缓存，队列以及在板的片上寄存器，存储器分区机制都需要检测分区的冲突。 IMA 系统硬件故障对共享硬件组件和非共享硬件组件的影响也是一种错误来源。此外， 所有的共享资源都应该利用追踪分析工具对模块、组件和应用对其的依赖关系进行追踪。这是对 IMA 系统进行共因分析(CCA)的基础，而 CCA 保证可以检查到每一个 IMA 模块、组件和应用的共模失效。由于要避免共模失效，所以需要对 IMA 系统的配置加以限制，这就可能会影响到设计或架构。共模式分析应与应用供应商和 IMA 系统综合者(SI)合作才能支持飞机级的共因分析。
一般而言，平台、模块和 RTOS 供应商对所有的活动都负有联合的责任，并且 IMA 系统综合者(SI)和应用供应商也是这些活动的主要成员。
5.2 应用供应商
应用供应商负责开发平台中的一个或多个应用模块，如飞行控制功能或燃油管理功能。对应用的开发应按模块在系统中扮演角色的约定来进行。一般情况下，应用的开发并不考虑其他的应用功能，除非这些功能是与应用相关的、相互依赖的，或者是经常与其他应用有相互影响的。
应用供应商需要参照应用活动来进行详细的系统安全评估。这些活动的输出要反馈到综合活动中，如约定的开发。对此的分析需要与平台安全性分析的失效模式和假定条件结合到一起，并在配套的报告中作以叙述。作为综合活动的一部分，应用供应商要确保应用的行为和属性与系统的安全性要求相一致，并且要生成相关的生命周期数据与合格证据。
应用供应商必须考虑 IMA 系统的整个健康监控(HM)和故障管理(FM)体系，对检测到的故障需要有适当的响应，这取决于故障的位置与严重程度。在应用中检测到的故障不应直接影响任何其他应用或IMA 的系统服务。由于此应用可能为其他应用提供输入，所以可能会带来一些间接的影响，引起数据的丢失。当设计和综合这些应用时，对这种耦合与这些依赖关系必须要有所处理。
5.3 IMA 系统的综合者
IMA 系统的综合者需要执行一些必要的活动，以提供一个或多个系统功能。IMA 系统由平台(硬件与核心软件)、资源、服务、模块， 以及确定的一组宿主应用及其配置组成。IMA 系统的综合者有义务将系统安全性评估的信息转换成更高一级的 IMA 系统安全性评估(SSA)过程，IMA 系统的综合者要访问到 IMA 系统的所有接口，包括来自飞机的其他接口和数据总线接口。这包含在系统配置中的有已选择的宿主应用、资源分配、配置表、系统综合以及系统的整个性能。
综合者通常负责最初的系统安全性评估过程，包括基于飞机功能危险评估的 IMA 系统的初步安全性评估(PSSA)活动。同样，IMA 系统综合者(SI)通常也负责综合各项系统安全性评估活动的结果。IMA系统综合者(SI)还要评估故障减弱、保护机制和派生需求， 以确保与飞机的安全性、完整性和可靠性一
致。作为综合活动的一部分，IMA 系统综合者(SI)要保证 IMA 系统的行为和特性要与 IMA 和飞机的安全性需求一致。
具体地说，IMA 系统综合者(SI)负责保证平台要由合适的应用配置来加载，协商建立沟通渠道并正确分配功能，以及配置系统以向使用它们的各个应用提供资源和模块与平台的服务。IMA 系统综合者(SI)也必须编写文件，用于记录或描述未用的特性或机制，以便在将来的使用中再重新配置。
注：IMA 系统综合者(SI)可能没有所有应用的专业知识，IMA 系统综合者(SI)应负责确保所有应用可获得所协商的资源和服务，并负责确保网络、数据总线和 I/O 设备，能将与接口规范一致的适当的输入和输出量提供给各应用。在系统综合与测试之前， 应用供应商应单独验证各独立应用的功能，并编写文件，记录与适当的软件指南、指导原则和适用协议的符合性(是全部符合、部分符合还是不符合)。
5.4 审定申请人
审定申请人负责表明与适航条例的符合性，并寻找型号审定(TC)、改型型号审定(ATC)、补充型号审定(STC)或改型的补充型号审定(ASTC)。该角色可以由飞机制造商或原始设备制造商来承担，且可能需要依靠 IMA 系统综合者(SI)进行的活动和提供的数据。需要验证并提供记录在文件中的符合要求的证据与 IMA 系统综合者(SI)所负责的约定，或由审定申请人提交给审定机构。同样， 所有在HB/Z 422 提到的相关完成情况总结也要审查，并由审定申请人提交给审定机构。在达成符合审定的过程中，审定申请人可能需要与平台、模块或组件的开发者进行沟通， 同样，当寻求最终审定机构的批准时，应该建立某种协议使供应商能够尽力支持。
5.5 审定机构
审定机构即为批准 IMA 系统和整架飞机和/或发动机审定的组织，在 HB/Z 422 中的工作帮助可能就是由审定机构来开发的，以便在 IMA 系统的审定中提供帮助。
5.6 维护组织
维护组织负责保持 IMA 系统和飞机的适航(持续适航)。IMA 系统的开发商应考虑以下几个方面：
a) 应该编制用于持续适航的 IMA 系统维护程序和指导说明，并应包括在维护说明和维护手册中。该手册应包括预防性维护、故障诊断和工具、维修和恢复服务的说明以及长期维护的流程。内容应包括软件、现场可编程硬件与数据库(含配置文件)的更新说明、车间加载以及现场机上加载。在识别失效、故障和异常情况、执行诊断和隔离原因以及确保进行适当维修或更正方面， IMA 系统内置错误检测的健康监控(HM)和故障管理(FM)能力应该都有用处。
b) 应该规定飞行机组培训和维护组织培训的内容，这与对现在对 LRU 的期望是类似的，但由于IMA 系统的综合特性、故障报告、诊断和问题确认等方面的原因，在实施时可能会困难些。此外，应用通常为 LRU 诊断问题提供各种的方法。这些方法可能不容易延伸到 IMA 系统，因为对于 IMA 系统和应用本身，维护需要有一个标准的方法。
c) 在维护体系中，最根本的活动就是确认 IMA 的系统、平台、模块、 RTOS，以及相关受控的应用配置，以进行 IMA 系统的一致性检查(例如，IMA 系统的配置和其所有组件要符合批准系统和飞机的型号设计)。许多 IMA 系统都有标准的配置控制方法：有些是自动的，有些是在飞机层面上的。一旦经过审定的配置得到确定和验证，就可能有必要对 IMA 系统中的单独模块、核心软件(包括 RTOS)和应用进行升级。对于维持组织， 加载过程必须要设计好、验证好并规定好，因为有些加载可能需要多个步骤，如上传加载程序、执行加载程序以接受更新， 删除最初的加载程序以及验证和确认上传模块、组件或应用的操作。此外， 对允许的混合配置必须予以规定和批准(例如，替换组件以及所规定和验证的硬件和软件组件的不同版本要彼此兼容)。
d) 审定后的修改要以硬件、软件或相关数据库的形式提出， 并且对涉及整个系统和飞机安全的修改必须进行评估。由于共享资源的相关性和 IMA 系统的复杂性，审定后的修改可能是困难的。
虽然审定后的修改不是维护组织的责任，审定申请人必须考虑到对维护组织所用的问题诊断技术和工具的影响，以保持飞机的适航。人素方面也必须加以考虑， 并且维护界面的开发需要在系统维护中进行有效的培训。
5.7 IMA 系统生命周期的阶段、结果和约定
5.7.1 概述
在该标准中，“进程(process)”一词用来描述一段程序单元。因此，用“阶段(phase)”来代替了HB/Z 421 中的“过程(process)”一词，以描述能产生确定输出或可交付实物的一组活动。
IMA 系统开发的每个阶段都要生产一组可提交的目标物，以支持最终系统的认可与批准。在开发整套的交付物中，各责任方必须参与到 IMA 系统开发生命周期的所有阶段。这些阶段包括联合式系统开发生命周期的所有典型阶段，如包括(但不限于)策划、飞机安全性评估、系统安全性评估、需求、设计、编码、验证、确认、生产和维护。除此之外，要有效地开发特定的 IMA 系统，还需要增加生命周期阶段。
5.7.2 特定 IMA 的生命周期——策划
IMA 系统的审定计划(IMASCP)和相关模块的认可计划、PSAC 和 PHAC 对审定机构认可 IMA 系统是至关重要的。
IMA 系统通常由平台、模块、资源、核心软件服务(RTOS)、数据总线和应用构成。为了减少它们之间的依赖关系，RTOS 的开发很可能要独立于支持符合特定平台或特定应用的软件生命周期数据。一般来说，RTOS 供应商为平台或模块的开发者提供操作系统和支持生命周期的数据。为了协调交付， 需要编制一个适合的计划。随着每个综合阶段的完成， 计划要持续进行。因此， 在 IMA 系统开发结束时，要有一整套计划文件，通常这些文件是层次结构的，如图 2 所示。
图 2 IMA 系统的策划数据
RTOS 供应商要编制一个 PSAC 文件，该文件叙述 RTOS 本身与基本 BSP/ASP 的 PSAC，通常，在获得实际 IMA 系统目标计算机或环境之前，该文件就要在通用平台上进行编制。
平台或 RTOS 的供应商把 RTOS 和 BSP/ASP 与特定的设备驱动程序综合在一起，以支持 IMA 系统
的接口设备。平台和模块的供应商应将 RTOS、BSP/ASP 与专用设备驱动综合在一起来支持 IMA 系统的接口设备，并且应参照 RTOS 和BSP/ASP 的 PSAC，编制一个能覆盖平台的 PSAC，并产生能将 RTOS与其数据综合到平台的方法。PSAC 应描述平台和模块供应商可满足的所有符合性目标，也要描述留给使用平台和模块的供应商来满足的符合性目标。
平台和模块的供应商可以考虑发布一个模块认可计划(MAP)的模板，描述由应用所看到的虚拟目标环境，其中包括平台和模块的功能、服务、资源、限制、约定与合格信任。该计划还要描述由平台供应商和各模块供应商要满足(可以是全部、部分或不要)并遵守的目标，以及要留给应用开发者与 IMA系统综合者(SI)要完成或满足的目标。各应用供应商可以使用PSAC 模板，来帮助完成该应用或模块的特定 PSAC。在 IMA 系统的开发过程中，已找出的开发与验证活动的合格信任提议，必须列入该计划中，并要标识这些目标以及用来满足这些目标的途径。
IMA 系统具有一套完整的审定计划，但还必须足够详细地进行描述，才能确定出所要包括的系统安全评估所述的全部系统危害与相关系统安全性的属性。从系统生命周期的观点出发， 所覆盖的危害和所提出的缓解措施，也包括 HB/Z 420、HB/Z 421、HB/Z 422 和 SAE ARP-4754 最新版本
