欢迎访问学兔兔标准下载网，学习、交流 分享 ！
返回首页 |
ICS 49.090 V 35
HB/Z 402-2013
民用飞机综合模块化航空电子系统
设计指南
Design guidance for integrated modular avionics of civil aircraft
2013-04-25 发布 2013-09-01 实施
中华人民共和国工业和信息化部 发 布
前 言
本指导性技术文件按照 GB/T 1.1-2009 给定的规则起草。
本指导性技术文件由中国航空综合技术研究所归口。
本指导性技术文件起草单位：中国航空无线电电子研究所、中国航空综合技术研究所。
本指导性技术文件主要起草人：谢振球、黄永葵、刘 雁、程春姬、孔德强、张起睿、朱占奎、朱晓飞。
民用飞机综合模块化航空电子系统设计指南
1 范围
本指导性技术文件为民用飞机综合模块化航空电子系统(IMA)设计提供指南，主要包括容错、数据网络、系统结构、软件结构、认证、测试性和维修性、数据源和目的、标准 IMA 模块等，还包括设计目标、成本目标及航空电子系统的互换性、可靠性和维修性等。
本指导性技术文件适用于 IMA 的设计和认证。
2 规范性引用文件
下列文件对于本文件的应用是必不可少的。凡是注日期的引用文件，仅注日期的版本适用于本文件。凡是不注日期的引用文件，其最新版本(包括所有的修改单)适用于本文件。
HB 6167 民用飞机机载设备环境条件和试验方法
HB 7704-2001 民用飞机综合模块化航空电子系统封装与接口
HB/Z 295-1996 机载系统和设备合格审定中的软件考虑
HB/Z 400-2013 民用飞机航空电子软件管理指南
3 术语和定义
下述术语和定义适用于本文件。
3.1
可用性 availability
航空电子系统或设备在工作状态的预期概率。
3.2
背板 backplane
机架资源与外界及综合化航空电子模块的接口，包括电气连接点的实际电路板和部件。 3.3
背板数据总线 backplane data bus
——实际背板的通道，用于传输航空电子机箱内模块间的数据;
——用于综合机箱内模块的数据总线的逻辑和协议(网络和数据链层)。
3.4
总线桥 bus bridge
一个模块或模块功能，它在同一种类型的数据总线间传输数据(例如高速总线到高速总线)。
3.5
机箱 cabinet
IMA 中的一个物理结构，用于提供环境与屏蔽，并且容纳航空电子模块、机箱资源和背板。
3.6
共用基本单元 common element
航空电子系统机箱内的共享资源，包括核心处理模块、I/O 模块、低压电源(LVP)和背板等。
3.7
共模故障 common mode failure
一个发生在公共单元并会引起相联系单元同时故障的故障。
3.8
置信度 confidence
经过正式确认、验证和分析推定一个系统或设备的适合工作的程度。
3.9
核心处理机(器) core processor
一个至少包括处理资源和存储器的模块。
3.10
核心软件 core software
在核心处理机中不属于应用软件的所有软件和固件。它包括操作系统(OS)和硬件接口系统(HIS)。
3.11
覆盖率 coverage
容错装置检测故障能力的度量，以百分数表示。
3.12
关键度等级 criticality level
在 HB/Z 295-1996 中定义。
3.13
数据集中器 data concentrator
远程采集飞机上各种类型的数据并输出高速总线上数据的部件。
3.14
确定性 deterministic
基于预先操作产生一个可预期输出的能力。这个输出在规定的时间内以某种重复程度出现。
3.15
非相似 dissimilar
在软件中，用以达到相同的结果有目的不同的设计方法。这通常用于减少设计中的固有错误的影响，因此提高整个系统的完整性等级。
3.16
事件驱动 event driven
一个导致结果动作的异步离散行动的发生。
3.17
失效工作 fail operational
在出现失效后，系统能连续地不中断地运行的特性。
3.18
失效安全 fail passive
系统检测出失效，并转换到被动状态以避免对系统工作造成不利影响的一种特性。
3.19
失效 failure
失效是一个系统无能力执行所需的一种功能或一些功能，失效是由于一个失效而引起功能特性的非有效。
a) 硬故障：从其发生开始就一直存在的故障;
b) 间歇故障：发生在有限时间后故障，其后功能能力恢复。
3.20
故障包容 fault containment
确保所有的故障被限制在发生错误的单个模块内以等待维修。
3.21
故障检测 fault detection
确定地识别出一个故障已经发生的能力。
3.22
故障隔离 fault isolation
一旦故障出现后，系统能识别出故障位置的能力。
3.23
故障传播 fault propagation
一个故障进入一个非故障发生源的其他设备。
3.24
容错 fault tolerance
在出现有限数量的硬件和软件故障时，系统提供继续正常运行的能力。
3.25
容错恢复 fault tolerance renewal
使一个容错部件恢复到正常使用状态。
3.26
功能 function
一项功能相当于一个子系统(例如自动油门、自动着陆等)，通常需硬件和软件两者来实现。
3.27
普遍性错误 generic fault
主要由于规范或系统设计的缺陷而引起的故障，在实现时就暴露出来。
3.28
硬故障 hard failure
不可恢复的失效，通常需进行维修。
3.29
完整性目标 integrity goal
基于统计分析描述一个系统使用、性能和可靠性等指标的目标。
3.30
潜在失效 latent failure
发生后未被检测，但在一段时间后可证实存在的失效。
3.31
存储器管理 memory management
允许系统存储器按某种方式分区的特性，以使不同应用软件可以不通过交互作用而共享大容量存储器设备的核心处理模块的特性。
3.32
模块 module
<硬件>按 HB 7704-2001 进行封装的部件。
<软件>一组执行专门过程或任务的功能程序。
3.33
N 版本编程 N-version programming
为提高系统的完整性，使用多种非相似版本的软件执行同一任务的活动。
3.34
分区 partition
<航空电子系统> 一种系统结构概念，允许对航空电子功能进行分离，使某一功能发生故障时不影响其他功能。
<软件> 在软件中对应某一具体应用的一部分代码。它通常与存储器管理硬件的使用有关， 以防止相邻存储器空间的数据由于疏忽而造成的破坏。
3.35
过程 process
包含在一个分区中的一个编程元件，它与在同一分区中的其他过程一起执行。一个过程相当于一个任务。
3.36
射频 radio frequency (RF)
用于描述到达或来自飞机的无线电发射和接收的任何频率。
3.37
随机失效 random failure
不可控的硬件故障。
3.38
重构 reconfiguration
设备故障后自动使用其他资源、逻辑或计算路径以不中断系统工作的能力。
3.39
恢复块 recovery block
在出现错误时执行的专门用于错误恢复的那部分软件。
3.40
转发器 repeater
一个功能或设备，在同一种类型的介质中不做修改地转发数据。
3.41
软故障 soft failure
可以自动恢复的故障。
3.42
标准 I/O standard I/O
一组模块化的 I/O 模块，它们通过机柜内总线及提供的接口连接机箱和外部的系统、传感器、作动器。
3.43
任务 task
在同一分区中，与其他过程同时执行的程序元件。一个任务相当于一个过程。
3.44
终端 terminal
由协议电路、存储器、晶体振荡器和串行接口模块组成的一个完整的总线收发装置。
3.45
确认 validation
软件研制过程最终阶段的评估过程，以确保软件与需求相符合。
4 缩略语
下列缩略语适用于本文件。
AMU——Avionics Module Unit，航空电子模块单元;
APEX——APplication/EXecutive interface，应用/执行;
ATCRBS——Air Traffic Control Radar Beacon System，空中交通管制雷达信标系统;
ATE——Auto Test Equipment，自动测试设备;
ATN——Aeronautical Telecommunication Network，航空无线电通信网络;
AVPAC——Aviation VHF Pakage Communication，航空 VHF 包通信;
BIT——Built-In Test，机内测试;
BITE——Built-In Test Equipment，机内测试设备;
CMF——Communication Management Function，通信管理功能;
COEX——COre/EXecutive interface，核心/执行接口;
DME——Distance Measure Equipment，测距仪;
EMI——ElectroMagnetic Interface，电磁干扰;
FADEC——Full-Authority Digital Engine Control，全权数字式发动机控制;
FMEA——Failure Modes and Effects Analysis，故障模式及影响分析;
HIS——Hardware Interface System，硬件接口系统;
HF——High Frequency，高频;
HOL——High Order Language，高级语言;
ILS——Instrument Landing System，仪表着陆系统;
IMA——Integrated Modular Avionics，综合模块化航空电子系统;
LAN——Local Area Network，局域网;
LRM——Line Replaceable Module，现场可更换模块;
LRU——Line Replaceable Unit，现场可更换单元;
MAT——Maintenance Access Terminal，维修访问终端;
MEL——Minimum Equipment List，最低限度设备清单;
MLS——Macrowave Landing System，微波着陆系统;
MOPS——Minimum Operational Performance Stands，最低性能标准;
MTBF——Mean-Time Between Failure，平均故障间隔时间;
MTBMA——Mean-Time Between Maintenance Alert/Action，平均维修告警/活动间隔时间;
MTBUR——Mean-Time Between Unscheduled Removal，非定期拆卸间隔时间;
MTTR——Mean-Time To Repair，平均修复时间;
OSI——Open System Interconnection，开放系统互连;
SATCOM——SATellite COMmunication，卫星通信;
SEMA——Single Executive/Multiple Application，单个执行/多个应用;
SESA——Single Executive/Single Application，单个执行/单个应用;
SRU——Shop Replaceable Unit，内场可更换单元;
VOR——VHF Omnidirectional Radio Range ，VHF 全向无线电测距;
VHF——Very High Frequency ，甚高频。
5 容错
5.1 概述
IMA 体系结构应体现容错设计。容错是设备在一个或多个故障出现时，以预定的方式继续工作的能力。错误可以是硬件部件的故障， 也可能是在进行硬件或软件设计时的缺陷。继续工作的性能范围覆盖了从所有功能的全部工作到不同级别的降级工作。
容错是为满足高可靠性的要求而产生的。在容错系统中， 模块或模块中的功能失效时，系统应可以
自动地重构，容纳故障，以继续满意地工作，直到定期维修时修理或更换模块。
为达到容错需进行三个过程。
a) 查找出故障;
b) 识别和定位故障元件;
c) 进行系统资源重构，以消除故障的有害影响。
功能容错的需求对设备的设计有重大影响。为了继续工作，既需资源冗余，又需降低任务的等级。同时还需监控或通/断设备，来诊断故障和提供重构路径。
注：假设技术水平相当，由于增加了一些部件，容错的实现比非容错设计的实现出现第一个故障的时间早。所以应由系统设计人员来权衡设备复杂度的增加是否与获得的成本节省相抵消。
5.2 应用
5.2.1 目标
具有容错能力的功能可以实现两个不同的目标：
a) 提高工作的完整性，以便飞行关键功能可以安全地运行;
b) 提供足够的设备可用性以从定期维修中取得好的经济效益。
以上目标客观上完全不同，并可能影响容错设计的实现。
应制定航空电子系统功能需求的规范。必要时， 应明确达到的容错要求。通常必须规定允许的降级工作模式，由于错误被化解而未导致功能故障的时间，及未达到功能失效时故障消除时间的间隔。
5.2.2 功能完整性
当要求功能具有高的完整性时，应考虑下列因素：
a) 单个错误不应引起严重的功能故障。这要求适用于整个系统，从传感器到数据源，到它的计算，到它的作动器与告警器。同样也适用于软件设计中的缺陷。
b) 应对设备的电路提供足够的监控范围，以确保引起严重灾难的故障不被漏诊。监控器执行这些功能和使系统重构的能力不应受到错误本身的影响。
c) 应分析引起多发错误的序列，以确保潜在的、诊断不出的灾难性的情况足够少。应综合考虑故障率、诊断范围及暴露时间(暴露时间是指功能在上次确定的错误之后的工作时间)。
d) 对于执行飞行关键性功能的系统，全部功能故障的概率应极小。
注：达到低的概率依赖于低故障率，高监控范围及短的暴露时间。
e) 一旦要求一个系统中具有连续安全工作的能力，应确保达到要求的完整性。这需通过认证测试来实现，通过测试表明在预期的操作条件与环境下，实现符合规范。
5.2.3 功能可用性
如果出于经济性原因虑功能的可用性，一组不同的因素影响设计。
设计的高可用性设备可经受多发故障并继续工作，但它并不要求彻底消除缺陷。这种类型的设备容忍影响功能的单个故障，或者对一些故障漏检，前提是这种情况不经常出现。
具体实现主要由购置成本和维修费用之间进行权衡。就象高完整性的情况一样，必须提供希望连续工作的时间和可接受的降级性能的规范。
5.3 设计考虑
5.3.1 概述
容错设计可以通过硬件和(或)软件设计技术的多种组合来实现。对于硬件， 最基本的方法是检查同类型或不同类型多处理器和输入/输出信号的正确性。对于软件， 一种相似的方法是使用多版本(有可能
不同)的编码来执行同样的功能，然后对输出进行比较或投票表决。
容错功能的设计将由规定完整性和可用性目标的整套规范来指导。这些要求与设备工作性能息息相关。
容错规范通过不同的参数表示。部分参数如下，其他的由定义的功能来确定：
a) 对于正常工作模式，发生错误后可接受的工作需定义;
b) 需定义功能故障，并以低于最低级别的能力缺失的方式来表述;
c) 应确定由单点缺陷引起功能故障的风险容限;
d) 需定义检测缺陷并完成重构的系统反应时间;
e) 需定义复合错误或错误序列导致的功能故障所允许的风险;
f) 功能容错并按指定工作的时间需定义。
5.3.2 高完整性设计
随着设备资源的消耗，继续工作的完整性裕度消失。在进行执行主要功能的设备资源设计中需考虑以下的限制性因素：
a) 采用功能冗余，来证明提供在单点故障出现后的连续工作能力。如果要求在任何单点错误情况下工作，并且具有维持大多数或全部功能的能力，功能冗余是必须的。虽然缺陷任务的屏蔽不会有助于自身的高完整性，但是如果一个功能是以不同级别完整性的多个功能实现，这样做还是有益处的。
b) 资源的隔离。各种冗余的部件应相互独立工作。功能监控应独立于功能本身。这种独立性应使正常、异常或故障事件在冗余资源或在一个功能或它的监控器上不产生共模故障。
c) 监控应高度有效。它需覆盖所有工作部件， 并应能诊断出所有严重故障。它应周期地进行， 以确保诊断异常的能力并与重构装置保持联络。
d) 高完整性功能的实现应满足性能要求，并且它的容错设计规范应确保设计缺陷被减少到可接受的程度。设计要实现预期功能， 而不产生非预期功能。对此的验证是通过对设备的测试和分析以证实正确的方式来完成。
e) 随着资源接近使用寿命期限，连续工作的完整性消失。到一定程度，应告知机组人员，尽管功能正常，但功能故障的风险在增加，需限制使用或开始维修活动。
注：如需要，应提供所容错系统自动重构的信息。机组需知道系统出现一个故障，并且可进行人工控制，于是他们可以作好准备。但是，连续点亮警示灯或连续显示注意标志将很快丧失它们的有效性。
设备持续服役，错误不断累积，将逐渐降级。到一定程度，飞机不能派遣，需维修。维修最好是有计划的，而非在功能丧失时维修。为使维修有效， 必须使累积的故障对于维护人员可见。因此必须保留故障记录，并且提供查询能力。一旦提供了故障记录，在设备部分或完全修复后需有方法来更新历史记录。
许多系统包括各种完整性要求不同的功能，当各种不同等级完整性的功能综合在一个系统中时，设备需按最高等级的完整性来处理。但如果采用按资源和功能完整性级别进行分区则是例外。如果采用功能分区，将由系统最高完整性的资源来管理分区。
5.3.3 高可用性设计
类似于高完整性功能，要求达到高可用性设备的实现有它独特的因素。进行主要功能的资源设计时应考虑如下因素：
a) 采用设备冗余来增加可用性。在某些情况下， 它也许是基本的方法。然而， 在某些情况下，如果功能与飞行关键功能不相关，任务隔离也许都会非常有用。有了任务隔离， 由于故障导致资源消耗，设备承担的任务将减少，并以一种特定的方式，将剩余资源集中在最希望的工作上。
b) 如果功能性失效并不都具有危害性，则不需确保冗余资源的隔离。然而， 应将监控器与被监控的功能隔离。
c) 有效的监控器要求具有健壮性，以极大程度地提高可用性。覆盖范围小的偏离和对不敏感状态的未检测出，不影响可用性。
d) 由于主要的目标是提高可用性，尽可能地提高设备的平均无故障间隔时间是一个实现的策略。这意味着尽量减少复杂性，同时提供尽可能多的实现路径，这就需在失效率和冗余级别中权衡。对于非常可靠的设备，选择单个设备实现，只对那些本身不具有高可靠性的部件采取冗余方法实现高可用性。
5.4 实现技术
5.4.1 概述
IMA 设备由硬件和软件资源组成，与功能的工作特性类似，容错可以在这些资源里分配。硬件和软件可以在执行故障检测、识别和重构时互补。
5.4.2 硬件实现技术
5.4.2.1 输入检查
在飞行关键功能中很少使用单个输入源，此时需进行合理性检查(也就是说，在通过计算过程前判断是否落在规定的极限内)。比较两个输入的情况，如果相差值超过预定值，则拒绝输入，而使用先前的输入。对于三个或三个以上的输入，对输入进行表决，接受多数值。
如果连续输入无效，认为输入源失效，请求更换输入源。
5.4.2.2 计算性能监控
计算性能监控应通过看门狗计时器监视执行时间来实现。如果时间超过规定的极限，处理器离线，并进入诊断测试。如果处理器通过诊断测试， 重新与系统连接。此时， 可以使用减少了执行时间和计算能力的不同版本的软件。
5.4.2.3 输出检查
容错系统中也采用输出检查。同单个输入一样，从单个处理器的输出也要进行合理的检查。对于一对处理器，按类似于输入比较的方式比较输出。如果输出不匹配，两个处理器应断开，进行诊断测试，在重新连接系统前识别出有故障的处理器。对于多个处理器， 对输出结果进行表决，多数的值在系统中传输。被拒绝输出的处理器应与系统断开，并进行诊断检查。
5.4.2.4 分区
应对系统进行功能的物理和系统分区，用于限制系统的错误扩散，因此减少了系统故障的概率。分区还减少执行硬件和(或)软件修改所需的系统测试工作和时间。
5.4.2.5 中值选择
只要在系统中有同样的三个或更多的信息源，通过一个简单的算法，可以使系统容许任何一个信息源的单点错误。基本方法是忽略任何输入参数的最大值和最小值。在假设只有一个源失效的情况下，其余的值应在可接受的容差范围内。特别地， 如果它与合理性测试相结合，或者有多于三个的信息源，这个方法也提供容忍两个故障的概率。
对于两个或更多的冗余输入源，都通过了合理检查，如果没有其他条件控制选择最高或最低值，应使用平均(中值)信号。
5.4.2.6 多数表决
这项技术使一个至少三余度的系统应允许单个输出故障。如果将所有的输出相加， 并且如果所有的输出具有有限的权重，那么无论哪一个输出值失效，该系统都能保持正常功能。类似于中值技术， 多数表决可以允许一定级别的故障。
5.4.2.7 冗余
因超时、超期服务而引起的故障能是硬件故障， 应提供设备硬件冗余，但随着增加硬件冗余，整个系统的故障率也相应增加。对于高完整性的功能， 这是必须付出的一部分代价。对于高可用度功能， 应仔细地权衡增加部件数量的成本和与之相关的整个功能损失的代价。
注：已经建立了数学模型和公式，在给定的可靠性下，预期使用多个部件以提高可用性的可能性。结果表明， 通过增加冗余部件来获益有一个明确的极限存在。
无论采用冗余电路，还是处理来自冗余信息源的数据，应提供隔离。如果单个的事件或故障对几个或所有的电路有相同的影响，这会引起即使使用最精密的监控器也监测不到的设备故障，那么多个源的益处就无法实现。
可使用分析性冗余来代替容错系统中的失效传感器。在传感器失效的情况下， 算法可以使用其他传感器的数据计算出失效传感器可能的信号。计算的信号被当作系统其余部分的有效输入。类似于飞行控制作动器的故障，其余的作动器及控制定律将自动重构，以补偿故障。
5.4.2.8 非相似硬件
对于需以高完整性工作的功能，可以考虑用非相似硬件法来实现，以避免一定类型的设计缺陷。这样的系统具有独特的优点及缺点。
非相似实现也许是避免冗余电路中由于设计缺陷引起或导致的共模故障的唯一途径。故障可以通过简单的监控器检测出来，减少了潜在故障的危险。
采用非相似硬件取决于几个其他因素：
a) 最重要的是倍增的研制费用和多种电路的设计及其验证的工作量;
b) 每一种方案都具有完整的工作能力;
c) 更困难的是验证非相似性本身，如果功能的保护是来自于非相似性，则非相似性必须证明其不会产生任何的共模失效。
5.4.2.9 监控
通常监控器分为三类：过程的比较、与固定门限相关参数的比较和事件的检测。每一个监控器应按它所监控功能一致的完整性级别来实现。这才能使监控器失效安全，或者可以重复，以确保检测实施。
硬件实现的监控器典型地专用于它们监控的特定电路。然而硬件实现的监控器也可用于监控软件实现功能的性能。另外， 除了检测出一个事件或者超过极限之外，监控器也应检测异常状态。如一个处理源的中断、一个被其他过程访问的标志、重构的触发器，或者是用于机组成员处理的信号报警。
5.4.2.10 重构
重构是变换设备中使用的资源的过程或行为。硬件重构方案的例子如表决器、复位脉冲、中断及数据操纵开关等。当在硬件中实现时， 这些重构设备通常专用于特定的单个参数或数据路径。由于这类型电路的复杂性，所以实现时需折衷考虑。
一旦发生重构，设备以较低的可靠性水平工作。故障被系统吸收， 但可能下一个故障发生时不再具有容错能力。对恢复到初始系统状态需仔细地考虑。从瞬态错误恢复与维持一个特定的环境以便检测出故障应找到一个平衡点。
5.4.2.11 容错恢复
容错恢复保证一个部件在一定置信度上正常工作。预测错误概率的计算提供了从容错恢复到最后置信度点的估计。
如果没有方法来保证部件是无故障的，则暴露时间接近于无穷大，且故障概率将趋向 1。为检测出其他潜在的故障，容错恢复过程可能要包括在设备内部，以限制暴露时间并减少故障概率。
容错恢复可以由定期自检测、周期维护检查或测试， 条件维修测试或制造商测试完成。每项技术都对暴露时间有限制。设备的所有的硬件部件需确定一个暴露时间，以计算危害概率。
5.4.3 软件实现技术
5.4.3.1 概述
软件不会磨损，故不存在操作时间函数的失效率，而是设计缺陷的可能性。复杂的系统通过软件实现复杂性，这就导致了即使在认证试验后仍留存有设计缺陷。在软件上应用容错技术可尝试消除任何残余缺陷的影响。
5.4.3.2 N-版本编程
N-版本编程是广泛应用的软件容错技术。这种容错方法中， 为完成相同的任务，按照共同的软件规范，独立开发两个或更多版本的软件。这些版本的软件可以在相同的处理器中顺序运行， 然而作为增强的容错方式，通常它们在不同类型的处理器中并行运行。然后对它们输出进行表决， 多数值作为系统输出。
注：并行处理比串行处理快，但增加了硬件成本，并可能影响系统的可靠性。N-版本编程的目的是通过代码的独立开发来减少故障，但独立程度有时与需解决的问题相关。
不同的软件版本应完整地经过验证。否则， 可能留有较大的错误，随着错误的检测，功能的完整性及可用性将大幅减少。由于成本的原因，仅在最高完整性要求时考虑 N-版本编程。
注：如果 N-版本编程或其他形式的非相似冗余作为减少功能设计缺陷的保护手段，达到的非相似性应被证实。研究表明，由于规范的含糊性及复杂性，相似的错误可能会在不同编程版本出现。
5.4.3.3 恢复块
容错软件的最简单形式是恢复块。在该容错方法中， 代码的输出经过接收检验。如果没有通过接收检验，则重新执行或者执行不同版本的其他程序，直到得到一个可接收的输出。如果没有得到可接收的输出，软件则被认为失效。
注：恢复块所关注的是附加的执行和重新执行时间，验收测试的完整性及恢复块成功所需重复计算时输入的存储。 5.4.3.4 多数表决
第三种容错软件技术是多数表决，它综合了上述两种方法。比较 N-版本编程的输出，如果两个或更多输出一致，则通过系统输出。如果没有两个版本一致，则从最信任版本开始，连续地进行测试直到产生一个可接收的输出。如果没有可接收的输出产生，则软件失效。
注：尽管 N-版本编程软件在飞行关键系统中广泛应用，设计并不应总认为这是适宜的方法。另一个观点是如果研制 N-版本所需的资源被用于单个版本软件的仔细设计和彻底的认证，则单一版本可能更为合适。
5.4.3.5 异常处理器
容错软件应包括一个异常处理器来处理非法操作，例如被零除，或计算 90˚正切值。
5.4.3.6 监控
许多基于硬件的监控功能同样适用于软件的实现。另外， 软件编程允许对复杂边界值及参数进行合
理检查。
软件监控器可以通过顺序和定时检查，确认软件运行是否正确。另外， 对于高完整性应用需一种独立确认 CPU 操作有效性的方法。这可以通过组合硬件和软件实现功能来得到。
软件监控器还可用于确认硬件功能是否正常。诸如输出到输入的回送，在数据路径上的跟踪信号，而且例行的周期诊断程序能够达到高水平的监控覆盖。
5.4.3.7 重构
由于监控的使用，软件编程比硬件具有更复杂的重构功能。可对大量参数采用信号选择逻辑， 用中值或加权表决法来表决。对源之间的均衡， 可提供对时差或系统容差的适应性。除了对信号控制， 各种过程也可以被激发或挂起。异常处理器通过一段特殊的程序和动作应对专门事件。在执行一个重复尝试时，数据可重新进行初始化。
5.4.3.8 容错恢复
由于软件不会磨损，不需容错恢复。软件可以看作是连续地提供它的目标功能。
对于软件，在修改和校正过程中有一个降级使用的趋势。这是由于在进行修改的程序内出现错误而造成的。
对此应适当的注意，以确保对现有程序的每一个外延版本的验证。
5.5 监控器/显示器的作用
典型容错系统需非常高的故障检测率和识别率。
注：为满足这个目标，需仔细的设计自检测设备(BITE)，执行的测试，及报告机制。BITE 的设计应以故障树分析和(或)失效模式及影响分析(FMEA)为基础。
6 数据网络
6.1 概述
飞机数据通信环境是一个非常特殊的通信网络，它管理来自多个传感器的实时数据流。这些数据是按优先级处理，以确保飞机工作安全可靠。数据链协议基于 OSI(开放系统互连)参考模型，通过将大量计算元件连接到不同的数据总线、局部网络(LANs)和其他介质，方便过程间通信。数据网络概念确保用户系统中通信的内部可操作性。信息由一个终端产生，并直接送到其他的终端，例如飞机中央维修系统到中心维修站，是通过各种物理链传递到几千英里以外，而对最终用户完全透明。
典型的数据源包括(但不限于这些)卫星通讯(SATCOM)、S 模式雷达收发机、航空 VHF 包通信(AVPAC)设备。这些系统通过作为全局网络一部分的通信系统与地面和空中通信。这些通信系统共同称作航空电信网络(ATN)。
本章为飞机上的以 OSI 方式进行数字数据交换协议的开发和使用提供设计指南。OSI 参考模型为不同系统间的通信提供大量的功能和服务。IMA 为基础的系统提供了透明的 OSI 协议，包括对用户和应用程序编制者提供的功能和服务。OSI 参考模型参见附录 A。
6.2 网络互连
显然，机载航空电子系统和地面设备象各种机载航空电子系统间一样的需通信，而且与日俱增。IMA为基准的系统的重要设计目标是使互连机制对机载的和地面的最终用户透明。为了达到用户透明性， 在实现两个网络互连所需的协议时应遵循标准化过程。AEEC 采用了ISO 协议作为各种各样的地面和航空电子网络互连的标准。
在航空电信网络环境下的网络互连，是通过使用 OSI 协议，实现不同计算机网络的互联，航空通
信网络构型见图 1。符合 ISO 标准确保了不同计算机网络的相互操作性。OSI 网络原理的应用满足以下目标：
a) 满足不同性能设备通信的需要;
b) 允许技术过渡;
c) 提高增长能力及互换性;
d) 与飞机外部现有的网络互连;
e) 提供与网络容错和分配限制相一致的通信结构。
图 1 航空远程通信网(ATN)
6.3 连网的例子
6.3.1 概述
IMA 系统中高度的综合需各航空电子系统和它们的子系统进行通信。一些系统互相依赖或安装在同一个区域自然形成一个网络组。这些组与其他的系统以组间联网或单个方式进行连接。这导致在这些网络间需互连机制。根据互连网络的不同特性，可以采用许多互连方法。采用 OSI 参考模型的 ATN 的相关联网构型见图 2。
6.3.2 中继器功能
中继器是最简单的扩展相似计算机网络覆盖范围的设备。中继器的功能是接收一个信息以它原来的强度重新产生该信号并重新发送它。
6.3.3 桥接器功能
总线桥互连物理上不同的网络，这些网络具有不同的物理层，但具有公共的数据链路和上层。桥接器作为每个计算机网络的一部分接收所有的信息。它检查目的地址， 当识别出信息需送给不同网络中的一个站时，桥接器将该信息传送到那个网络。由于信息暂时存储在桥接器里，然后发送到另一个网络，所以桥接连接实现存储转发功能。在局域网(LAN)的情况下，桥接器也可以解决任何在两个介质访问控制方法的帧格式或其他不一致的问题。用桥接器连接两个物理上独立的飞机主总线(ARINC629)的简单的例子见图 3。只有物理和数据链层需连接类似的总线。
a) 用物理层和数据链路层的网桥作为总线/计算机网络 1 和 2 的互联
b) 各种网络互联方法协议的定义
图 2 OSI 参考模型的 ATN 的相关联网构型
图 3 网桥功能举例
6.3.4 路由器功能
路由器连接不同的物理及数据链层、但具有公共网络协议和上层的网络。路由器的功能是通过中间节点传递信息。当一个信息通过中间节点进行传输时，它必须伴有两个地址。第一个是最终节点地址，信息在网络中传输时该地址保持不变，第二个是路由中下一个节点的地址。这一个地址信息根据路由从一个节点传到下一个节点，相应的地址信息也改变。路由器连接一个 HB 6096-1986 总线和一个ARINC629 总线的例子见图 4。在这种情况下，不同类型数据总线间连接需三个较低的层。
图 4 路由器功能举例
6.3.5 网关功能
最高级的网络互连是网关。网关提供完全不同结构及不同协议的计算机网络互连所需的灵活性。网关的典型功能包括：
a) 消息格式协议;
b) 地址转化;
c) 协议转换。
图 5 给出了完全不同的 X.25 分组交换网络与 ARINC629 总线通信连接的例子。应用互联需 OSI协议的所有层参与。
图 5 网关功能举例
7 系统结构
7.1 IMA 系统结构
一套 IMA 系统能适应许多现役飞机系统，并且最终适用于所有飞机系统。典型 IMA 配置的飞机基本组成的示例见图 6。遍及整个飞机的航空电子机箱提供了大部分功能。
图 6 采用 IMA 配置的飞机基本组成示例
IMA 系统由一组机箱组成，这些机箱中的设备执行大部分处理和到任何位置的传感器、作动器和指示器的输入输出(I/O)。机箱与机箱之间、机箱与其他的作动器、传感器和指示器之间通过ARINC629数据总线连接在一起。系统组成见图 7 所示。
图 7 IMA 系统组成概貌
IMA 的基本目标是开发满足规定认证要求的航空电子设备。根据系统结构、综合的方法以及被综合的飞机系统的数量，需一定级别的容错来满足适航规定的要求。
为了满足适航性要求，需进行高完整性设计。航空电子系统也应具有高可用性。高完整性设计对飞机工作的安全性有很好的作用。可能危及飞机可靠性的所有功能应采用容错。这个应作为确定系统结构、容错级别要求及确定综合化候选系统的设计准则。
为了使 IMA 机箱中的系统满足它们的完整性要求，机箱应提供一种引入非相似性的方法。非相似性应应用到软件和硬件上。高完整性推荐用于所有的 IMA 设备。
应注意即使是在同一架飞机中，不同机箱内部的结构，由于每个机箱功能的相异性、复杂性和关键性的不同而会有所不同。不同 IMA 结构的例子见附录 B。
7.2 IMA 设备布局
应按飞机全寿命周期费用最少的原则把设备分布在整个飞机中。本指导性技术文件主要考虑两种类型的设备：即机箱和远程部件。
机箱位置可以在权衡性方便和接近传感器/作动器两者后确定。机箱 I/O 需求会受机箱位置选择的影响。适当的设备位置将减少布线长度、连接器数量和生产成本。完全由软件完成的任务可以安装在飞机中任何地方机箱内。推荐使用一个机箱为附近的传感器提供 I/O，并通过飞机主总线为其他机箱提供数据可大大地减少整个飞机系统的布线。
对于含有网关作为它们的唯一 I/O 的机箱，没有安装位置的限制，可以安装在任何方便维修的地方。某些应用由于不同的成本原因，将导致其他 I/O 模块驻留在本机箱内。在这种情况下， 与 I/O 相关的布线将严格限制机箱位置;因而须将其安装在使机身布线最少的位置。
建议将远程电子部件与相关设备组合在一起。而其他设备由远程数据集中器进行管理。远程数据集中器为一组物理位置相近的设备服务。远程数据集中器的位置应方便安装和维修。如果以上方案都不易实现的话，I/O 应放置在机箱内。
设计者应考虑将主要 IMA 设备安装在座舱、舱壁、高架舱内等没有有效载荷的地方，同时要方便维修时的装卸。与天线相关的传感器设备以及其他远程电子设备可以安装在机身的蒙皮内。现代的飞机，除了极远程的飞机，相比重量限制来说更多的受到空间的限制。目前那种将宝贵的货物空间用于放置航空电子设备机架的状况，在完全采用 IMA 系统的状况中将不再出现。
与其他设备相比，MTBF 值预期较低的设备应安装在便于维修的地方。在所有情况下，每个 LRU或者 LRM 应在根据各自的位置完成更换时间分析。只要更换时间与失效率分析在一个可接受的范围内， MTBF 值较高的设备可以安装在维修受限的地方，按“可接受的拆装困难程度”方式安装。对于已知高MTBF 的设备可以使用专用的工具来拆卸和固定设备。
7.3 IMA 设计建议
7.3.1 概述
IMA 系统可能长期使用，在此期间，很多模块设计技术将会改进。技术进展可能在不同模块的不同时间阶段产生，因此对系统兼容不同技术的能力提出了要求。这可通过模块边界的定义和各模块间的松耦合来实现。
数字接口标准的使用提高了设备的互操作性。这使设备可以相互独立地定义、生产和认证， 然后与系统中其他模块进行功能综合。
7.3.2 系统的部件
实现飞机功能所需的部件通常有控制器、传感器、作动器、指示器及将数据转换为适合驱动作动器和指示器的格式所需的处理装置。IMA 系统将这些部件作为独立实体，这些实体通过数据总线网络进行相互通信。IMA 的另一个目标是通过对许多功能被处理位置的优化来减少成本。
考虑上述所有因素后，IMA 系统的部件包括：
a) 带背板总线和模块的机箱;
b) 数据总线(ARINC 629、HB 6096-1986);
c) ARINC 629 兼容设备;
d) 数据集中器(与 ARINC 629 等数据总线兼容)。
7.3.3 机箱
7.3.3.1 机箱安装架和背板组件
机箱安装架为安装的一组功能模块提供机械和电气环境，为模块和机身间提供接口。机箱总体尺寸可以灵活多变，以便厂商将多种模块综合在特定的飞机上。各机箱设计可能不一样，以使它能适应不同的环境。这样机箱在机身中安装时具有最大的灵活性。
机箱内还有背板，它作为功能模块和其他航空电子系统的接口。背板可以分为三个区域。第一个区域是飞机布线与物理背板的接口;第二个区域专用于传输所有内部模块的通信，即背板总线;第三个区域用于配电。背板总线是机箱中一个重要的功能组成部分。
7.3.3.2 机箱设计
机箱设计由系统综合者负责。一般应是飞机制造商。每个机箱应能提供容错环境。根据对 I/O 的要求、数据吞吐量和存储器要求以及与其他功能间的关联性， 在机箱中分配各功能。机箱应符合 HB 6167和 HB 7704-2001 相关章条的要求。
机箱本身为模块提供基本的机械结构和环境控制/隔离。它不提供任何电气支持如电源变换/调节及总线控制/监控。因此，各自模块为航空电子功能提供这些服务。
应设计多种机箱以允许按单一环境规范设计的 LRM 承受不同的飞机环境。机箱可以是开放的或封闭的结构，以使它们的安装位置不受潮湿、微粒及 HIRF(高强度辐射场)的影响。不同的机箱可以使用相同的模块。不同类型的机箱，不应增加额外的维修过程。典型的机箱部件装配示意见图 8。
图 8 常用机箱部件装配
7.3.4 各种现场可更换模块
7.3.4.1 概述
各功能模块按 HB 7704-2001 的要求封装为现场可更换模块。IMA 的目标是飞机接口对大多数模块是公用的，或是可配置的，以便模块的数量和它们在机箱中的位置在飞机设计中不需固定，允许在服役期内调节和附加功能，而不必付出昂贵代价地改变机箱和飞机布线。电源模块为机箱内其他模块供电。
组成 IMA 的功能模块见图 9。这些功能模块是：
a) 核心处理器;
b) 标准 I/O;
c) 特殊 I/O;
d) 电源模块;
e) 总线桥;
f) 网关;
g) 大容量存储器。
背板数据总线
注：所有机柜中各单元的数目与分布取决于其位置、各种功能的多少、其类型以及所要求的余度/容错的等级。
图 9 常用机箱组成结构
这些模块既可一起工作，又可互换。因此应对接口进行严格的接口定义。这些接口定义包括连接器定义、引脚输出及信号特性等。作为机箱容错的一部分，冗余等级影响互换性。因此需定义冗余等级以确保符合同一个标准。
每个模块的功能及其与背板接口在各自的规范中定义。这一点确保由不同厂商设计和安装的设备具有互操作性。同时也提高了设备的互换性。实现模块化后， 航空电子系统的研制、认证、试验和维修就变得容易了。
模块内部的冗余由模块供应商确定。系统综合单位应根据系统要求对模块的性能进行取舍， 并确定选择哪些模块。
7.3.4.2 核心处理器
核心处理器为机箱提供计算能力。机箱可以包括一个或一些处理器以及它们的存储器和冗余管理需的所有电路，如监控器、BITE 和隔离电路。在 IMA 中，根据机箱内应用软件的不同可以改变核心处理模块的设计。
为了执行不同的功能，核心处理器需提供一个保护功能的方法，以确保一个功能不会对另外一个功能造成有害影响。这种隔离方法对应用软件来说是不透明的。
每个系统的实现应确定使用多少个处理器和多少个不同的设计。核心处理器的设计应提高实现的独立性，允许与机箱中其他的核心处理器间的真正互换，以便与机箱中其他核心处理器间的协作，这样使供应商协作成为可能。
应用软件可以加载到机箱内的任何一个核心处理器中，核心处理器对应用软件的硬件支持是透明的。软件应参照 HB 5357-2005 及本规范第 8 章设计。考虑采用一定方式的硬件方法，支持各个具体执行程序的各个方面：
a) 存储器分配和时间的划分;
b) 采用特许访问以避免应用软件间干涉;
c) 核心处理或机箱的冗余管理。
7.3.4.3 标准 I/O 模块
7.3.4.3.1 概述
应研制一系列 I/O 模块，将一组标准的传感器模拟和离散数据转换为数字数据，并通过背板总线将数据传送到核心处理器，反之亦然。每个模块可以包括一种类型信号或一些优化组合的信号接口。
I/O 模块的标准化将提高通过背板总线传送到处理模块的数据采集的有效性。具体到单独 I/O 模块的标准化应考虑重构。I/O 模块由应用软件配置以满足机箱的要求。这个配置可以存储在 I/O 模块的存储器中。
7.3.4.3.2 数据总线接口模块
除飞机的主总线外，飞机中还可能采用其他的数据总线。因此，应研制一系列总线桥模块和网关，以满足不同总线混用和不同性能要求。
数据网关为机箱提供数据转换服务。通过使用单独的网关将总线硬件和协议与机箱的其他部分隔离开来。总线桥接器可用于同一种类型数据总线的数据发送和接收。
IMA 系统设计者应考虑机箱的全部数据总线接口。为了适应机箱功能或模块技术的发展，网关用于转换不同数据总线的协议。典型的网关将飞机全局总线协议转换为机箱背板总线协议， 或将机箱背板总线协议转换为飞机全局总线协议。
当一个网关是机箱与其他飞机系统的唯一接口时，它的设计应考虑整个系统的安全性和可用性。
网关应考虑推荐的 OSI 参考模型。该模型的目标是为模块提供所需的灵活性。网关应是可配置的，并且包含一定的处理能力。
中继器、桥接器和路由器是其他一些在系统设计中应考虑的数据总线接口技术。数据网络的规定见第 8 章，有关 OSI 基准模式的应用参见附录 A。
7.3.4.3.3 同步 I/O 模块
同步 I/O 模块根据应用的要求(也就是说它们与应用同步)在 I/O 模块和核心处理器之间交换数据。模块按照机箱中应用的要求执行数据采集、预处理和块存储。
在机箱配置确定后，每个应用立即配置它们所用的 I/O。此后， 预处理单元周期地刷新每个应用的存储器。这样相同的数据能在指定给应用的 I/O 模块的存储器中找到。
7.3.4.3.4 异步 I/O 模块
在异步操作模式中，I/O 模块主动完成 I/O 模块及核心处理器间的数据传输。这些传输相对于应用是异步的。这些模块为机箱中当前的多种应用提供数据采集、预处理和块存储功能。
在机箱的配置确定后，每个应用通知 I/O 模块它所需的的信号特性，例如信号类型、电气值-物理值转换，背板上信号刷新率。在 I/O 模块完成配置和初始化后，它将所有采集的信息发送给相关模块。
在同步和异步通信中，预处理元件应能够处理数据，例如滤波、转换。另外， 它应能够采集和存储
I/O 信号。处理特性应按通道特性相同的方式加载。
7.3.4.4 专用 I/O 模块
当标准 I/O 模块不能满足特殊的信号类型或特殊接口的要求时，需研制专用I/O 模块。这一点仅在绝对必要时才进行，例如标准化不能带来的成本的优势。
7.3.4.5 电源模块
电源模块为飞机电源与其他用户模块的电源需求之间提供电源隔离和转换。每个机箱中电源模块组的冗余应适合机箱中其他功能完整性的要求。
机箱中每个电源模块的输入常常来自于独立的标准飞机电源。相对于该输入电源而言， HB 6167中规定了传导产生的噪声及电磁干扰的敏感度。一个电源模块的输出功率是一调整过的电压电平。每个电源模块应对它所连的每个用户模块有单独的输出线。这些输出线应有相互独立的故障保护， 以便一个用户模块的故障不会影响对其他用户模块供电的完整性。
用户模块通常至少与两个电源模块相连。每个用户模块自动的使用其中一个(或两个)电源，完成的模块功能。
注：电源模块的噪声要求至少与现有 LRU一样严格。要求更严格地减少背板噪声。相反地， 敏感性要求相对容易。
机箱本身对电源输入线的预滤波，再一次减少了背板的噪声。
7.3.5 背板总线
建议串行数据总线用于机箱内通信。与并行总线相比， 串行总线具有很多优点，包括最少的插针数量及机箱中相关的互连。对那些需多个背板总线来满足完整性目标的关键性系统还提供了扩展结构的灵活性。
7.3.6 测试和维护总线
推荐使用一个单独的数据总线进行测试和维护。推荐的接口在 GJB 5440-2005 中规定。
7.3.7 飞机总线
飞机总线用于传输包括关键数据在内的所有数据。特定飞机的整个系统的需求决定了总线的数量。总线的初始设计应只使用不超过 50%的容量，以允许足够的增长余量。
在适当的情况下，HB 6096-1986 总线也可以用于特殊的应用。
7.3.8 总线兼容设备
与传感器、作动器和指示器等的接口， 可能包含用来执行信号调理、缓冲、转换和低级别控制的远程组件。从实际出发， 远程航空电子组件也可以合并在如大气数据探测器等设备中。这样的设备包括具有总线输入/输出的作动器及转换器、惯导传感器、大气数据传感器和RF 元件等。
在 IMA 系统中鼓励研制总线兼容设备，因为它们允许系统实现和修改的更大自由度。通过对飞机的电缆，以及多路访问总线进行多点监控，增加了系统的可维修性。
非兼容设备可以采用 7.2.11 和 11.6 中描述的远程数据集中器。
7.3.9 简单设备
不能直接与总线相连的设备称为简单设备。这并不是指设备的内部复杂度低。它们也许可以输出原始数据，也许具有非常复杂的内部处理来执行信号调理、缓冲、转换和低级别控制。输出数据是除了总线以外的模拟或数字形式。推荐简单设备直接通过标准 I/O 模块与机箱连接。
当存在特殊信号类型或不能满足特殊接口要求时，需设计飞机特殊设备。这仅在没有其他切实可行的解决方法时才这么做。如果考虑到成本效益比，则应考虑整个飞机的成本，而不仅仅是设备的成本。
7.3.10 显示设备
一般地，飞机主总线应与显示设备相连。然而， 通过权衡显示结构与成本之间的关系可能会有更好的改进。例如， 一些显示设备也许会通过高速视频总线接到机箱上。若机箱设计者选择将显示图形的生成综合到机箱硬件并将视频数据传送到显示设备时需这种类型的接口。这些显示设备由机箱中特殊的I/O 连接。
当考虑采用高速视频接口时需评估一些问题。系统设计者应考虑用户希望增加设备的可靠性。最大限度的减少显示设备的复杂性以提高驾驶舱设备的可靠性。这种可靠性的提高要求增加机箱和显示设备之间的带宽。另一个设计考虑是希望减少部件的数量，减少驾驶舱的电源消耗，以及通过多种重构路径来增加部件的可用性。
7.3.11 远程数据集中器
远程数据集中器为一组相似的简单设备提供服务。作为输入设备， 远程数据集中器将模拟、离散或其他形式的量转换为总线数据格式。作为输出设备，远程数据集中器数据将总线数据格式转换为模拟、离散或其他形式的量。远程数据集中器可负责监控相关简单设备的健康状况。远程数据集中器技术要求见 11.6。
7.3.12 射频(RF)调节器
RF 调节器是飞机天线与机内数据总线系统间的接口。一些 RF 调节器可以输入或输出除飞机主总线接口格式外的模拟或数字量。
作为信号源，RF 调节器处理来自专用天线的 RF 信号，并按功能要求的格式提供数据，一般地不需进一步的计算处理。例如，卫星导航接收机提供纬度、经度、高度、卫星三轴向的数据速度及时间。
作为接收器，RF 调节器使用自带的处理器将总线功能数据转换为经调制的 RF 能量，并由专用的飞机天线发射。
一些 RF 调节器可以同时提供信号源和接收功能。例如 DME(测距仪)，其通道选择是接收动作，而到台距离是信号源动作。
RF 调节器可以将它们基本的功能与飞机天线部件综合，并通过非标准数据互连与相关的计算部件互连。例如 SATCOM(卫星通信)，高增益天线是通过 SATCOM 处理机进行控制。
采用 IMA 结构，可将 RF 调节器设计为与飞机主总线兼容的设备。
7.3.13 音频功能
即使将来数据链通信占主导地位，飞机中仍然需语音通信与语音分配。
航空电信网络(ATN)可利用批准的物理链路(就象现在的 SATCOM 链路的那样)，传输数字化语音。 IMA 的通讯管理功能(CMF)通过数字 I/O 接口处理这类数据。
公共访问、机舱及飞机内话系统建议在 IMA 以外。无论是否使用数字化语音进行分配和控制，都需专用的硬件和布线。只要切实可行，数字化语音分配应采用数据总线方式。
商用电话系统建议不作为 IMA 功能，除非他们使用CMF 控制的链路。
乘客娱乐及灯光/呼叫控制可以是 IMA 外的独立功能，但可能会使用 IMA 中的数据库和其他信息。
8 软件体系结构
8.1 通则
IMA 中的航空电子系统功能由应用软件提供，软件本身也为功能的增强提供极大的灵活性。
然而，应用软件的研制费用在 IMA 中一般占主导地位，需采用现代化方法进行设计、实现和测试，
以节省费用。
当前的航空电子软件通常与硬件捆绑在一起，成为一个完整的、可操作的航空电子系统。IMA 软件由一个团队提供而不是硬件生产商。这样，可能改变了航空软件的采购方法。HB/Z 400-2013 提供了航空电子软件管理的指南。
此外，在 IMA 体系结构中，软件应用任务作为一个功能单元，以构件块的方式提供。为了使这种方式成功，需全盘考虑与系统和硬件形式相一致的软件体系结构。
注：随着嵌入式软件系统大小和复杂度的增长，现代软件工程技术(如面向分析和设计的对象，结构设计的功能分解， 自底向上设计等等)希望能辅助过程的开发和提高效率。有一种观点是主张用组合技术实现最佳效果。但是，技术的选择应考虑通过明确的软件分割和功能封装的益处。系统应按照单元间有明确接口的易管理单元进行分解。
航空电子功能或硬件部件的标准化不足以为应用功能提供明确的接口。例如， 新功能的增加。应全盘考虑软件体系结构，以把航空电子应用的构造块综合起来。
IMA 概念鼓励综合多个软件功能。从软件观点来看， IMA 系统的这个特性使 IMA 在功能上是一个分布式系统。需的机制是：
a) 管理系统中应用和它操作的数据间的通信流;
b) 在影响飞机运行的系统级故障发生时，提供需执行的例行控制程序;
c) 在 IMA 体系结构中，存在其他单元时，就需明确接口，不仅仅是软件体系结构本身的各要素间，而且在软件和其他物理要素间。
8.2 软件结构
模块化综合航空电子软件结构见图 10。
图 10 模块化综合航空电子软件结构
系统由以下部件组成：
a) 完成航空电子功能的应用软件。
b) 为应用软件的执行提供的标准和通用环境的核心软件。核心软件可进一步划分为：
1) 操作系统──管理应用要求的逻辑响应。它的功能包括分配处理时间、通信通道及存储器资源。通过此功能将应用需求映射到系统级的逻辑机制，为应用提供统一的逻辑接口。系统健康监控器功能启动错误恢复或者重构策略执行指定恢复行动。
2) 硬件接口系统(HIS)──它代表操作系统管理物理硬件资源。HIS 将操作系统产生的逻辑要求映射到核心处理模块特定的物理配置。
为达到 IMA 目标，软件体系结构扮演着一个关键的角色。GJB 5357-2005 定义了软件应用级的通用用户接口，该接口最大限度的减少专用硬件实现的影响。
通过背板总线、存储器管理和其他分区的功能，硬件提供了访问 IMA 系统的物理方法，该方法确保应用软件之间或应用软件与操作系统之间不会相互干扰。
构成 HIS 的软件将特殊的硬件实现映射到操作系统。因此对硬件的实现来说它是唯一的。我们熟悉的 BITE(机内测试设备)和 BIT(机内测试)功能也处于这一层。就像作为任何硬件级别的容错机制一样，对于特殊的硬件实现这也是唯一的。
IMA 系统是一个分布式系统，它的设计目标是它能够在它的全寿命期内改进。一些部件，特别是应用功能，具有标准化的功能，可能要求某些单元对于整个飞机及特殊硬件实现两者都是可配置的。在所有的情况下，IMA 部件相互间采用标准的接口。
软件在飞机上是可加载的。这个特性对于应用软件是透明的。应采用一些接口定义明确的小块程序。另外，设计者应适当地注意维修性、可修改性及可认证性。
8.3 展望(观点)
应将航空电子软件分解为适当分区单元，而不仅仅只是将其简单的按方便管理的方式进行分解。这可能包括将那些很有可能改变的单元组合，将依赖于特定的暂时特性的单元组合等。而且， 这些对于易受影响的单元可以进一步分为受功能加强影响的单元和那些针对专门的物理环境执行的单元。通过这样分组和组合，可以将功能增强和完成其他物理实现对其他软件的影响进行限制和分别解决。
在 IMA 概念中，功能和相应应用软件的位置在处理中心的网络中分配。在每一个处理中心中驻留有几个应用。这些应用可以是来自不同的航空电子资源， 并综合到所选择的核心处理器硬件中实现。需确保可靠的软件分区在应用之间构筑“砖墙”，特别是对那些不同软件关键性级别的应用软件。
