高清可复制 HB 8691-2023 机载维护系统通用要求

　　ICS 49.060 V 40

　　HB 8691-2023

　　机载维护系统通用要求

　　General requirements of onboard maintenance system

　　2023-12-29 发布 2024-07-01 实施

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

　　前 言

　　本文件按照 GB/T 1.1-2020《标准化工作导则 第 1 部分：标准化文件的结构和起草规则》的规定起草。

　　请注意本文件的某些内容可能涉及专利。本文件的发布机构不承担识别专利的责任。

　　本标准由中国航空工业集团有限公司提出。

　　本标准由中国航空综合技术研究所归口。

　　本标准提出单位：中国航空无线电电子研究所、中国航空综合技术研究所。

　　本标准主要起草人：张竞凯、潘 震、颜 瑾、马慧敏、徐晓东、郑宇翔、张起睿、张 英、姜 盼、姚 冰。

　　机载维护系统通用要求

　　1 范围

　　本标准规定了机载维护系统(以下简称 OMS)的要求和验证。

　　本标准适用于民用运输类飞机，其他飞机可参考使用。

　　2 规范性引用文件

　　下列文件中的条款通过本标准的引用而成为本标准的条款。凡是注日期的引用文件，其随后所有的修改单(不包含勘误的内容)或修订版均不适用于本标准。凡是不注日期的引用文件，其最新版本适用于本标准。

　　CCAR-25-R4 中国民用航空规章 第 25 部〈运输类飞机适航标准〉

　　GB/T 16251-2008 工作系统设计的人类工效学原则

　　GJB 451A 可靠性维修性保障性术语

　　GJB 3385A-2020 测试与诊断术语

　　HB 5940-1986 飞机系统电磁兼容性要求

　　HB 6167-2014 机载设备环境条件和试验方法

　　HB/Z 295-1996 机载系统和设备合格审定中的软件考虑

　　HB/Z 402-2013 民用飞机综合模块化航空电子系统设计指南

　　HB/Z 415-2014 民用飞机机载电子设备通用指南

　　HB/Z 420-2014 民用飞机机载电子硬件合格审定保证指南

　　HB/Z 422-2014 民用飞机综合模块化航空电子系统开发与认证指南

　　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-254 机载电子硬件设计保证指南(Design assurance for airborne electronic hardware)

　　SAE ARP 4754A 高度综合或复杂飞机系统的适航取证考虑(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

　　级联效应 cascaded effect

　　由于发生故障的单元或模块的输出因故障出现异常继而影响下游单元或模块功能正常执行的效应。 3.1.2

　　机载维护系统 onboard maintenance system

　　机载维护系统以综合显示方式为机组维护人员提供飞机维护信息的显示，以集中化的控制方式为机载维护人员提供飞机维护操作的触发。主要完成飞机上成员系统的故障状态信息、构型信息、状态监视信息的采集(可借助 ARINC664、ARINC429 等总线);根据故障诊断模型，解算故障状态数据，生成、存储故障报告数据;识别构型信息的更改状态，生成、存储构型报告数据; 根据状态监控模型，解算状态监视数据，生成、存储状态监视记录数据、状态监视报告数据; 支持维护记录数据的打印、下载; 支持成员系统的交互式维护测试(IBIT);支持符合现场加载规范要求的成员系统可加载项的现场加载;通过维护访问终端，为用户提供维护操作的人机交互接口，用以支持维护信息的查询、维护操作的触发。

　　3.1.3

　　扩展维护 extended maintenance

　　识别或证实故障状态，隔离故障到单个 LRU/LRM，更换、调整或修理有故障的单元或模块， 验证系统恢复正常运行，用比通常更多的时间完成维护。

　　3.1.4

　　容错 fault tolerance

　　系统或 LRU/LRM 的内置能力，允许系统带一定数量的故障继续履行规定的功能。故障的数量取决于系统的冗余和可靠性要求，但引起失效的故障至少为 2 个。

　　3.1.5

　　驾驶舱效应 flight deck effect

　　用于向飞机机组成员告知飞机功能失效状态的视觉或听觉指示。

　　3.1.6

　　地面测试 ground test

　　操作员通过中央维护功能的控制面板输入启动的规程。

　　3.1.7

　　隔离 isolation

　　把故障确定到实施修理所要求的产品层次的过程。

　　[来源：GJB 3385A-2020，2.1.9，有修改] 3.1.8

　　航线维护 line maintenance

　　识别或证实故障状态，隔离故障到单个 LRU/LRM，更换、调整或修理有故障的单元或模块， 验证系统恢复正常运行。

　　3.1.9

　　成员系统 member system

　　直接或通过数据网关向中央维护功能进行报告的系统。

　　3.2 缩略语

　　下列缩略语适用于本文件。

　　ACARS——飞机通信寻址和报告系统(aircraft communications addressing and reporting system);

　　ACMF——飞机状态监控功能(aircraft condition monitoring function);

　　ACRF——飞机构型报告功能(aircraft configuration reporting function);

　　ADN——飞机数据网络(aircraft data network);

　　AMI——飞机/航线可更改信息(aircraft/airline modifiable information);

　　ARINC——航空无线电公司(aeronautical radio incorporation);

　　ATA——航空运输协会(air transport association);

　　BIT——机内测试(built-in test);

　　BITE——机内自检测设备(built-in test equipment);

　　CDA——驾驶舱显示应用(cockpit display application);

　　CMF——中央维护功能(central maintenance function);

　　DAM——数据访问管理器(data access manager);

　　DLF——数据加载功能(data load function);

　　ELS——电子库系统(electronic library system);

　　FDE——驾驶舱效应(flight deck effect);

　　FLS——现场可加载软件(field loadable software);

　　GBSS——地面支持软件(ground based support software);

　　HIRF——高强度辐射区域(high intensity radiated fields);

　　HTTPS——超文本传输安全协议(hyper text transfer protocol over secure socket layer); IBIT——启动 BIT (initiated BIT);

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

　　LRM——航线可更换模块(line replaceable module);

　　LRU——航线可更换单元(line replaceable unit);

　　MAT——维护访问终端(maintenance access terminal);

　　MCM——维护通信管理器(maintenance communication manager);

　　MFD——多功能显示器(multi-function display);

　　MS——成员系统(members system);

　　MTBF——平均故障间隔时间(mean time between failures);

　　NVM——非易失性存储器(non-volatile memory);

　　OMD——机载维护文档(onboard maintenance documentation);

　　OMS——机载维护系统(onboard maintenance system);

　　OMSF——机载维护支持功能(onboard maintenance support function);

　　PAA——参数存取应用(parameter access application);

　　PDA——维护数据提供显示应用(PMAT display application);

　　PMAT——便携式维护访问终端(portable maintenance access terminal);

　　PMD——维护数据提供(provision of maintenance data);

　　SATCOM——卫星通信(satellite communication);

　　SRU——内场可更换单元(shop replaceable unit);

　　SSM——标志状态矩阵(sign status matrix);

　　UTC——世界标准时(coordinated universal time)。

　　4 要求

　　4.1 尺寸

　　系统各部件的尺寸应满足专用规范要求。

　　4.2 重量

　　应结合具体设计需求，在保证强度、刚度要求和安全性相关的功能、性能的条件下， 使系统和各部件的重量最小。

　　4.3 外观质量

　　系统各部件的外表面不应有目视可见的影响外观质量的锈蚀、划伤、压痕、漆层脱落、变形、气孔、裂纹等缺陷，且无锐边、棱角及尖锐凸起，引出线及连接器应完整无损。

　　4.4 材料

　　材料的选用应根据以下原则：

　　a) 当某些材料都能满足设备要求时，应选择使用特性范围最广和允许公差最大的材料;

　　b) 当某些材料的质量高于设备所要求的质量时，在不增加成本时，可以采用这些材料;

　　c) 尽量不采用聚氯乙烯(PVC)材料;

　　d) 尽量采用阻燃材料;

　　e) 在符合可靠性，安全性的前提下，尽量选用无铅材料;

　　f) 不得采用有毒和含有其他危险物质的材料;

　　g) 应根据 HB/Z 415-2014 中 4.3 e 的优先次序选用标准材料。

　　4.5 设备指示灯

　　如果在驾驶舱内装有和 OMS 相关的警告灯、戒备灯和提示灯， 除适航当局另行批准外，灯的颜色应符合下列规定：

　　a) 红色，用于警告灯;

　　b) 琥珀色，用于戒备灯;

　　c) 绿色，用于安全工作灯;

　　d) 任何其他颜色，用于本条 a)至 c)未作规定的灯，该颜色要足以同 a)至 c)规定的颜色相区别，以避免混淆。

　　注：警告灯、提示灯和戒备灯与 CCAR-25-R4.1322 的规定相一致。

　　4.6 安装

　　OMS 设备安装的要求有：

　　a) OMS 必须保证在各种可预期的运行条件下能完成预定功能;

　　b) 飞机系统与有关部件的设计，在单独考虑以及与其他系统一同考虑的情况下，符合以下规定;

　　1) 发生任何妨碍飞机继续安全飞行与着陆的失效状态的概率为极不可能;

　　2) 发生任何降低飞机能力或机组处理不利运行条件能力的其他失效状态的概率为不可能;

　　c) 必须通过分析，必要时通过适当的地面、飞行或模拟器试验，来表明符合 b)的规定;

　　d) 在表明设备的设计和安装符合 a)和 b)的规定时，必须考虑临界环境条件;

　　e) 必须按照 CCAR-25-R4.1709 条的要求对电气线路互联系统进行评估。

　　注：OMS 安装符合 CCAR-25-R4.1309(a)、(b)、(d)、(e)和(f)的要求。

　　4.7 供电

　　OMS 应满足：当由于电源供电瞬变或其他原因产生的瞬变时，不会导致重要负载不工作。注：此条要求与 CCAR-25-R4.1431(d)的相关内容一致。

　　4.8 组成及架构

　　4.8.1 联合式航电系统中 OMS 的组成

　　联合式航电系统中的 OMS 组成一般包括：

　　a) 中央维护计算机，驻留 CMF 、ACMF 和ACRF;

　　b) 每个 MS 的 LRU 中故障检测与机内自检测设备(BITE)的硬件及软件;

　　c) MS 和中央维护计算机间的接口;

　　d) 驾驶舱的维护访问终端(MAT);

　　e) 电子库系统(ELS);

　　f) 机载打印机;

　　g) 可选择的一个或多个远程 PMAT。

　　典型航电系统的 OMS 架构如图 1 所示。

　　图 1 联合式航电系统中的 OMS 架构

　　4.8.2 IMA 系统中 OMS 的组成

　　IMA 系统可由以下设备组成：

　　a) 驻留了 4.8.1 中功能 a)至 e)的多个通用处理模块;

　　b) 每个 MS 的 LRU/LRM 中故障检测与 BITE 的硬件及软件;

　　c) 将 MS 的数据进行处理和传输的远程数据接口单元和网络交换机;

　　d) 其他设备要求与 4.8.1 中 d)至 g)要求相同。

　　IMA 中机载维护系统架构如图 2 所示。

　　BITE成员系统

　　图 2 IMA 系统中的OMS 架构

　　4.9 功能要求

　　4.9.1 功能概述

　　机载维护系统一般包括以下功能：

　　a) 中央维护功能(CMF);

　　b) 飞机状态监控功能(ACMF);

　　c) 维护数据提供(PMD);

　　d) 飞机构型报告功能(ACRF);

　　e) 数据加卸载功能(DLF);

　　f) 成员系统(MS)机内自检测;

　　g) 机载维护支持功能(OMSF)。

　　4.9.2 中央维护功能(CMF)

　　4.9.2.1 基本功能

　　CMF 应实现如下功能：

　　a) 自动测试和隔离：CMF 应持续地监控每个 MS，接收 MS 故障报告，分类、综合故障和失效数据，结合维护文档和 MS 失效信息格式化故障和失效数据，生成失效报告，形成维护建议，可用于存储、显示和下传;

　　b) 地面测试：请求指定的成员系统进行地面测试，例如 LRU/LRM 替换验证测试、系统运行测试、系统功能测试、调整和锁定，接收并显示从成员系统反馈的硬件和软件构型识别数据;

　　c) CMF 配置;

　　d) 其他附加功能，包括 CMF 相关的存储、CMF 的运行监控、CMF 与 MS 的接口以及信息交互。

　　4.9.2.2 自动测试和隔离

　　4.9.2.2.1 不间断的 BITE 监测和数据收集

　　不间断的 BITE 监测和数据收集需满足以下要求：

　　a) 不断监测所有的 MS 输入及自身的故障状态;

　　b) 从上电自检后一直到断电一直保持不间断监测(MS 状态发送速率通常在 0.5Hz 左右)，CMF应包含上电自检功能，这个过程也可以由操作员命令启动;

　　c) CMF 用于检测和记录所有的内部故障及接口故障(输入/输出故障);

　　d) 应收集的数据内容包括：

　　1) 从 MS 收集的故障数据;

　　2) 从 MS 收集到的构型信息;

　　3) 驾驶舱告警系统显示的故障指示或 FDE;

　　4) 飞行阶段和航段;

　　5) 时间和日期;

　　6) 航班编号和来往城市或航线编号;

　　7) 飞机标识;

　　8) 支持驾驶员报告和/或故障分析的飞行参数，例如高度、空速等;

　　9) 电源中断状态(如果可用)。

　　e) 数据收集应具备只读数据的功能，从而实现对中央维护的输入监测。

　　4.9.2.2.2 BITE 数据综合和处理

　　BITE 数据综合和处理需满足以下要求：

　　a) MS 的故障检测和 BITE 是 CMF 检测隔离 LRU/LRM 内部故障、系统内部故障和外部接口故障时所用数据的主要来源;

　　b) 故障数据综合的程度直接决定 CMF 的复杂性;

　　c) CMF 应处理所有 MS 的 BITE 输入的数据，通过解析会引起歧义的故障报告，实现 MS 发送数据的综合、故障数据存储以及驾驶舱效应与失效数据的关联;

　　d) 剔除冗余信息(移除级联效应);

　　e) 可通过 CMF 对部分非 MS 执行故障和失效自动隔离;

　　f) 针对不同系统故障提供特定维护消息;

　　g) 当对故障报告的简单分析无法明确维修建议时，CMF 可利用其他分析技术来细化相关建议。如：可以结合与可能原因相关的背景数据进行概率推理，从而对维护操作进行排序;

　　h) 基于飞行阶段确定故障是否应被存储和处理，由于飞机制造商对不同飞行阶段 MS 上报的故障信息的存储和处理要求不一样，需要供应商划分不同的飞行阶段，以决定 MS 上报的故障信息可否被存储，或处理该故障信息时采取何种模型或算法进行处理;

　　i) CMF 应有足够的 NVM，用来存储多次飞行中从各 MS 传送来的经过综合的故障数据，数据包括：

　　1) 驾驶舱效应;

　　2) 失效 LRU/LRM 的部件号和序列号，或接口;

　　3) 机载维护文档参考和 ATA 参考;

　　4) 航班编号和来往城市或航线编号;

　　5) 飞行阶段;

　　6) 飞机标识;

　　7) 故障或失效发生的日期和时间;

　　8) 电源中断状态(如果可用);

　　9) 其他飞行参数，如：高度、空速、姿态数据。

　　4.9.2.3 地面测试(用户启动测试)

　　4.9.2.3.1 基本要求

　　地面测试的基本要求包括：

　　a) 地面测试是由操作员通过 CMF 的控制面板输入，且由人工启动的测试规程;

　　b) CMF 应提供启动全部 MS 地面测试的能力;

　　c) “地面测试”选项应为每一个 MS 提供可用的测试，按照便于维护的 ATA 章节进行组织;

　　d) 所有的地面测试都应按照模块化方式进行设计，以支持每一种类型的地面测试，并允许为 MS和通信链路选择特定的测试;

　　e) 所有地面测试的设计都应使地面支持设备的数量最少化，这将对减少飞机维护时间和后勤需求产生影响;

　　f) 地面测试应支持在外场维护及扩展维护情况下进行快速的系统完整性判断;

　　g) 地面测试应通过 CMF 用户界面的选择来决定可否执行，次一级的选择项应允许操作员选择飞机系统、地面测试的类型、以及具体的测试;

　　h) 只有飞机停在地面上并且满足适当的互锁，才可以进行地面测试。互锁因系统而异， MS 应在CMF 错误发出地面测试命令时保护自己;

　　i) 对每一个测试来说，测试的参数和“通过/失败”的标准应包含在 MS 内部;

　　j) 地面测试应是自动的，以增加准确性、有效性， 减少测试时间及费用。必须由操作员评估“通过/失败”标准的情况应减到最少;

　　k) 针对手动测试结果，通过或不通过由测试人员确定，该类测试通常包括人机接口部件(如旋钮、开关、按键和显示设备)，要求维护人员评估物理项的性能，并确定性能可否被接受;

　　l) 可由用户启动的地面测试相关功能详细规定见 4.9.2.3.2-4.9.2.3.8。

　　4.9.2.3.2 操作测试

　　操作测试应确定系统已安装其所有组件(包括冗余通道和通信链路)，并且能做出正常响应。通常，测试由系统内的操作监控完成。具体特点如下：

　　a) 简单扼要(机组飞行前测试相比较);

　　b) 不需要地面支持设备;

　　c) 自动化(如果有可能)。

　　4.9.2.3.3 LRU/LRM 替换验证测试

　　LRU/LRM 替换验证测试应验证被替换的或修理过的 LRU/LRM 的基本运行能力和接口的完整性。

　　4.9.2.3.4 系统测试

　　系统测试应证明系统满足规定的设计规范和容差要求，适用于初次安装或大修。

　　注：系统测试旨在判定具体的参数是否在系统设计容限之内。当对比真实系统操作与设计规范时， 一定要记住维护是在一个与工厂制造或设计实验室完全不同的环境下进行的。一架运营的飞机的系统操作规范应允许连续使用条件下合理的降级使用，允许由于温度、压力、湿度、震动和类似因素等环境不同因素而产生的容差变化。

　　检验操作“符合规范”的测试也许更复杂，有些情况下，也许需要独立的、校准过的测量标准。为了完成系统测试，必要时可以使用地面支持设备，尽管目标仍然是最少使用。

　　如果使用地面支持设备，则不应要求任何的设备拆卸。

　　4.9.2.3.5 交互式故障定位和测试结果确认

　　交互式故障定位和测试结果确认包含：

　　a) 在自动 BITE 无法定位故障组件的多组件系统中，需要定位故障的组件时，CMF 应提供方法来选择和执行交互式测试;

　　b) 在显示器上向维护人员提供反馈，从而实现逐步的故障隔离;

　　c) 对于手动测试，其测试结果的通过与否由测试人员确定。该类测试通常包括人机接口部件(如旋钮、开关、按键和显示设备)。

　　4.9.2.3.6 调整和锁定测试

　　调整和锁定测试要求：

　　a) CMF 应通过 MS 提供驱动输出和反馈位置，在不需要特殊测试设备的条件下，能调整和锁定;

　　b) MS 应针对需要调整和/或锁定的系统组件进行适当的测量并把限制数据传送给 CMF。

　　4.9.2.3.7 接口监控

　　CMF 应提供可选择的能力，监控、解码和显示从与CMF 所驻留的计算机交联的任何数字总线上所选择的数据字。

　　4.9.2.3.8 硬件和软件构型识别

　　MS 可以按请求向 CMF 传送硬件及软件构型识别的数据。这些数据应包括硬件和软件的部件号或组合部件号、序列号、修改状态和可编程的选项(例如引脚的可编程选项)。

　　4.9.2.3.9 地面测试中的 LRU/LRM 故障存储

　　地面测试中的 LRU/LRM 故障存储包含：

　　a) 内部故障和失效应被存储在 MS 自己的 NVM 中以便恢复;

　　b) CMF 可查询 MS 的 NVM 中的故障历史信息内容进行发送，并存储到 CMF 数据存储中以便进一步从飞机层消除故障。

　　4.9.2.4 CMF 配置

　　CMF 配置要求包含：

　　a) 无需拆卸 CMF 所驻留的计算机，就可以对其操作软件进行更新;

　　b) 故障数据处理软件应为可加载的;

　　c) CMF 应通过修改可加载的故障处理算法定义内部功能的运行;

　　d) 航线运营商可通过地面软件工具修改航线可更改信息(AMI)，并将软件重加载至飞机(利用机载数据加卸载功能)来对 CMF 的某些功能进行重配置;

　　e) 配置数据应提供给 ACRF。

　　4.9.2.4.1 CMF 相关的存储要求

　　CMF 应有足够的 NVM 来存储失效 LRU 的软硬件配置识别以及航线特有的数据，例如航线特殊装备的部件号和说明。注意：CMF 的 NVM 与 MS 中的 NVM 存储内容是不同的(见 4.9.7.6.4)，每个NVM 域中的信息都是独特的。像 CMF 一样，每个 MS 都应按先进先出方法收集内部的故障数据存储在 NVM 中。

　　4.9.2.5 CMF 的运行监控

　　CMF 的运行监控要求包含：

　　a) CMF 所驻留的计算机应自含机内自检测能力;

　　b) CMF 所驻留计算机的 BITE 设计应遵守 MS 的 BITE 的通用要求;

　　c) 相关要求可参考 4.9.8。

　　4.9.2.6 CMF 与 MS 的接口

　　CMF 与各 MS 之间通信，推荐的方法是使用数据总线。CMF 应提供下列数据供 MS 使用：

　　a) 飞行阶段和航段;

　　b) 时间和日期;

　　c) 航班编号和来往城市或航线编号;

　　d) 飞机标识;

　　e) 支持驾驶员报告和/或故障分析的飞行参数，例如高度、空速等;

　　f) 事件功能激活。

　　CMF 应从所有的 MS 接收编码数据。CMF 应对这些编码数据进行解释，并翻译成预先定义的简明消息显示给维护人员。应允许 CMF(操作员)删除指定的 MSNVM 中存储的故障数据。

　　CMF 也应可以读取 MSLRU 的内场故障数据，使这些数据不仅能在车间里，也能在飞机驾驶舱上使用。最好 CMF 还能查询 MS 中存储的软件捕获信息，使扩展维护和工程故障分析不仅能在车间内完成，也能在飞机上完成。

　　4.9.2.7 故障数据备份

　　CMF 应能把所有的故障数据转储到电子存储设备中，这适用于存储在 CMC 驻留的计算机和成员系统的 BITE 内存中的数据。

　　4.9.2.8 信息交互

　　4.9.2.8.1 当前故障信息显示

　　CMF 的当前故障信息显示包括以下内容：

　　a) 如果用户请求显示“当前故障”信息，那么所有被 MS 的 BITE 检测到并报告给 CMF 的当前故障应在相应页面显示，显示信息应包括：

　　1) 故障指示或驾驶舱效应(如果有);

　　2) 失效的功能;

　　3) 失效的 LRU/LRM、部件号和序列号或接口;

　　4) ATA 编号;

　　5) 机载维护文档。

　　b) 如果需要打印、备份或下传，应增加以下信息：

　　1) 失效日期和时间;

　　2) 飞行阶段;

　　3) 飞机标识;

　　4) 航班编号和来往城市或航线编号。

　　从“当前故障”页，应可读取其他的维护数据和文档。

　　4.9.2.8.2 当前航段故障显示

　　在当前飞行中，每个 MS 的 BITE 检测到的故障应已经传给 CMF。在用户选择时，CMF 应格式化并显示相应页(“当前航段故障”页)。其基本信息应包括：

　　a) 故障指示或驾驶舱效应(如果有);

　　b) 失效的功能;

　　c) 失效的 LRU/LRM、部件号和序列号或接口;

　　d) ATA 参考;

　　e) 机载维护文档参考;

　　f) 失效日期和时间;

　　g) 飞行阶段。

　　如果需要打印、备份或下传，应增加信息“飞机标识”和“航班编号和来往城市或航线编号”。

　　故障应标识为硬故障或间歇性故障。从“当前航段故障”页，应可读取其他的维护数据和文档。

　　4.9.2.8.3 最近航段故障

　　在结束“当前航段”后，前一条所描述的信息应作为“最近航段故障”，该信息是可读取的。

　　4.9.2.8.4 故障历史

　　CMF 应显示所有 MS 的 BITE 报告的以往故障。在操作员要求时， 可以按系统(ATA 分类)、航段、日期和时间等不同分类方式提供这些故障数据。显示的数据应包括至少最后 100 个航段或总共 512 个故障的故障历史，以及采取的维护措施(如果有记录)。

　　4.9.2.8.5 地面测试交互信息

　　地面测试交互信息包括：

　　a) 根据来自驾驶舱显控系统的指令，CMF 请求来自数据访问管理功能可应用的 MS 测试页面，并将其发送至驾驶舱显控系统以便显示给飞机维护人员;

　　b) CMF 接收从驾驶舱显示功能到 MS 测试页的响应，并实施合适的行动，包括后续指令至 MS以执行触发测试;

　　c) MS 进行校验以确认没有阻碍测试的安全实施的情况，然后执行被请求测试;

　　d) CMF 接收测试结果，并将重新找回的数据发送至驾驶舱显控系统以便显示给维护者;

　　e) 在接到来自驾驶舱显控系统的指令时，CMF 向数据访问管理器请求失效数据，这些数据由 CMF接收并发送给飞机驾驶舱显示器中的一个进行显示或者驾驶舱打印机进行打印，如果数据用于显示，那么将发送给驾驶舱显控系统进行显示，即如果数据用于打印，那么将发送给信息系统进行打印。

　　4.9.3 飞机状态监控功能(ACMF)

　　4.9.3.1 基本功能

　　由地面支持软件(GBSS)支持的飞机及其飞行性能监控，监视和记录与飞机维护、性能、故障分析和趋势相关的有可选择的飞机数据;从飞机状态数据所确定的性能变化趋势，可以用来监视需要降级运行的系统的状况;提供必要的信息，以提前报告潜在的功能障碍，让用户及时安排维护行动，加快飞机再运行，避免非计划维护行动而影响飞机服务;面向个性化的工程分析，ACMF 必须允许每个用户提出定制特征;用户定义的应用可以通过数据加载器或数据链由 ACMF 加载;ACMF 应利用硬件和/或软件划分，确保遵守适用的认证指南。

　　ACMF 应包括如下功能：

　　a) 数据采集/处理;

　　b) 事件监控;

　　c) 数据记录;

　　d) 报告生成;

　　e) 报告管理;

　　f) 报告分发;

　　g) 报告显示;

　　h) 数据链通信;

　　i) 报告存取;

　　j) 输出;

　　k) ACMF 配置和更新。

　　4.9.3.2 数据采集/处理

　　数据采集/处理包括：

　　a) 可以读取模拟和离散的数据以及飞机数据总线，应有能力获取用于事件监控、数据记录和报告生成的有选择的多组数据;

　　b) 应能够判断数据的有效性，并将其作为来源的选择标准，应能以多个速率获得数据，它应将原始数据转变为工程单位，并执行基本过滤功能，例如去抖动、锁定和数据平滑;

　　c) 应能读取容错系统的冗余状态，由于保证系统运作的多层次功能冗余的工程应用，所以需要降级状态报告，基于此类数据，在最低限度冗余水平达到之前，操作员就可以为维护工作做准备;

　　d) 向数据存储实体请求已经存储的 MS 故障报告和配置信息。

　　4.9.3.3 事件监控

　　事件监控包括：

　　a) 应能监视一组选择后的飞机数据，用于布尔逻辑和算术计算;

　　b) 监控算法能用于判断计算，从而判断事件的发生，进而依次开始进一步的行动，例如数据记录、生成报告和分发报告，系统应能支持在不同速率上进行独立的算法评估;

　　c) 监控的具体内容包括：

　　1) 飞机性能监控;

　　2) 趋势分析，趋势分析的对象可包括发动机、飞机气动特性、辅助动力装置、发电机和环境控制系统;

　　3) 运行状态监控;

　　4) 重要事件分析;

　　5) 故障隔离分析协助。

　　d) 可进行增强 BIT 上报、检测异常行为和确定飞机系统总体健康状态;

　　e) 可以进行简单的基于逻辑的状态监测算法，用于确定飞机或其子系统的运行状态;

　　f) 监控可提供数据使航空公司能分析其整个飞机机队的运行状况，提高其运行效率。

　　4.9.3.4 数据记录

　　数据记录包括：

　　a) 应能记录得到的数据，应支持以用户定义的格式将数据记录到大容量存储设备，例如光盘、磁性或固态记录器;

　　b) 应能够对参数进行选择，并能连续记录所选参数集合;

　　c) 数据可存入信息系统中;

　　d) 由 AMI 定义的连续记录数据应存储在大容量存储设备中，以便后续下载;

　　e) 飞机上的电源开启时，ACMF 启动，将指令传送至数据收集子功能以便进行数据记录，并控制记录时间进行控制;

　　f) ACMF 依据定义好的触发器来记录数据，正常触发器，如发动机起飞推力触发、稳定巡航触发、下降顶点触发等;非正常触发器，如发动机超限触发、飞机过速触发等;

　　g) 数据记录功能本身不生成报告。

　　4.9.3.5 报告生成

　　报告生成包括：

　　a) ACMF 应搜集和存储数据，再分送到不同的输出设备(这些存储数据此后会当作一份报告来引用);

　　b) 应能够在指定时期内搜集涉及指定事件的数据，涉及的事件可能有以下含义：

　　1) 飞行剖面中一个常规的给定事件点;

　　2) 一个例外算法，由内部逻辑、乘员告警事件或者驾驶舱人工事件按钮触发。

　　c) 所提及的时期可能是一个瞬间，也可能是一段有始有终的持续时间，一段时期可能跨越事件，也可能出现在事件前或事件后;

　　d) 每份报告都应有一个标题，可以包含下列内容：

　　1) 报告标识符;

　　2) 飞机标识符;

　　3) 日期和时间;

　　4) 航班编号;

　　5) 出发地和目的地;

　　6) 飞行阶段;

　　7) 软件编号。

　　e) 应能够生成含有其他存储报告(例如趋势报告)数据的报告;

　　f) ACMF 应有方法标记无效的数据，该功能应能区分不同类型的无效数据，并提供该信息作为报告的一部分;

　　g) ACMF 可对报告进行格式化，并向指定目标发送报告，目标可以由AMI 进行设置;

　　h) 报告可用于地面分析，从而监控发动机、辅助动力单元和其他飞机系统异常事件， 实现性能和趋势分析;

　　i) 报告生成可以由 GBSS 设置。

　　4.9.3.6 报告管理

　　报告管理包括：

　　a) ACMF 应能将报告存储在 NVM 中，并且按规定的参数来管理报告的保存，如：

　　1) 每个航段存储的一个报告出现的数目;

　　2) 保留最先产生或者最后出现的报告;

　　3) 保留一个报告每次出现的航段数目;

　　4) 每个报告出现的最大数目。

　　b) ACMF 应可以根据用户请求从 NVM 中删除报告。

　　4.9.3.7 报告分发

　　报告分发包括：

　　a) ACMF 应能将报告发送到指定的输出设备。输出设备包括：

　　1) MAT;

　　2) 机载打印机;

　　3) 通过数据链(例如 ACARS 、SATCOM 等)发送至相应终端;

　　4) 数据/软件加载器;

　　5) 海量存储设备(例如：快速存取记录器)。

　　b) 应有能力响应维护访问终端、数据链命令、或者监控事件的请求而发送文件， 报告的格式可以由 GBSS 编程或定制;

　　c) 可通过 AMI 配置报告管理的运行，如报告格式、报告输出路径、报告输出条件等。

　　4.9.3.8 报告显示

　　报告显示包括：

　　a) ACMF 菜单、显示和命令的机上控制通过 MAT 完成。像 OMS 其他功能一样，显示由菜单驱动;

　　b) 显示的分析结果包括：

　　1) 软硬件异常告警;

　　2) 系统/设备的健康状态和性能趋势;

　　3) 对各类失效和异常行为的响应;

　　4) 各种报告和数据。

　　c) 显示接口为：

　　1) 电子飞行包显示单元;

　　2) PMAT;

　　3) ACMF 的菜单显示包括了 ACMF 的软件部件号、ACMF 的下拉菜单选择;

　　4) ACMF 的显示内容包括了报告浏览和实时数据浏览。

　　d) 当飞机在地面时，显示控制功能软件为机组提供了查看 ACMF 结果的接口;

　　4.9.3.9 数据链通信

　　可以通过数据链传送数据。ACMF 应输出用户选择的报告，并应符合约定的协议：

　　a) 在通信系统准备就绪时传送;

　　b) 在驾驶员检査后传送;

　　c) 数据链上传获取下一个可用报告的请求。

　　4.9.3.10 报告存取

　　ACMF 提供存储器中报告的显示手段。该系统可以按访问优先权控制用户访问所选择的显示。通过显示画面，报告可以发送到输出设备或从存储器中删除。

　　4.9.3.11 输出

　　输出途径包括：

　　a) 维护显控功能，接口见 4.9.3.8;

　　b) 主干网络(信息系统);

　　c) 飞机通信寻址和报告系统(ACARS);

　　d) 终端无线局域网单元(TLWU)。

　　4.9.3.12 ACMF 配置和更新

　　功能配置和更新包括：

　　a) ACMF 应能修改用户定义的参数，这些参数一般用于事件监控算法;

　　b) ACMF 也允许第三方供应商以可执行模块的形式，提供更复杂的算法;

　　c) 通过 MAT 或数据链，提供机上可编程性;

　　d) ACMF 应有能力创建机上可编程报告，报告中可由用户控制的属性包括：

　　1) 事件监控能力;

　　2) 要采集的参数;

　　3) 数据采集速率;

　　4) 数据采集周期及其开始/结束逻辑;

　　5) 数据记录的启动;

　　6) 输出设备的选择，包括数据的存储和显示;

　　7) 报告有效期。

　　e) 以上属性的修改可通过 AMI 进行配置;

　　f) 可通过 GBSS 修改AMI;

　　g) 可以根据用户请求在 MAT 上静态或动态地显示信号和用户定义的参数，该系统提供缺省显示格式和显示更新速率，工程单位和二进制数都可以被有效的显示。

　　4.9.3.13 GBSS

　　GBSS 功能包括：

　　a) GBSS 支持定制用户定义的应用功能，包括：参数定义、控制逻辑、报告生成、数据记录和 PMAT显示;

　　b) 参数定义功能使得用户能对用户定义的应用及组成部分进行配置管理。每一次软件更新都要用软件版本号标识，版本号在的菜单首页可见;

　　c) GBSS 应执行输入数据和语法的检查;

　　d) GBSS 支持对有效输入信号的定义，并提供这些信号显示;

　　e) 每个输入信号都已包含了 ACMF 和用户定义应用要求的信号处理属性，部分属性可以由用户修改;

　　f) 除了输入信号，GBSS 还提供创建用户定义参数的手段，用户定义的参数可以提供计算数值、存储中间结果、或从输入信号提取数据字段;

　　g) 输入信号和用户定义的参数可用于事件监控、报告生成、数据记录和数据显示;

　　h) 控制逻辑设定由 ACMF 提供的工具实现，从而使用户可以规定事件监控需要的算法，也可以控制其他 ACMF 功能;

　　i) 定制工具有下列特征：

　　1) 支持布尔逻辑和算术运算的语法和运算符;

　　2) 数学和统计函数库;

　　3) 数据记录控制;

　　4) 报告生成、分发和删除控制;

　　5) 调试功能。

　　j) 报告生成功能可以规定一个报告的特征，报告特征包括：

　　1) 输入信号和用户定义参数的清单;

　　2) 数据采集的时期;

　　3) 报告保留标准;

　　4) 报告格式，包括输出设备、数据及嵌入式正文的布局和形式、报告标题、ASCII 控制符、数据链路由信息以及数据中小数点的移除选择。

　　k) GBSS 应能规定海量存储设备的记录格式;

　　l) GBSS 应提供为 MAT 定制显示画面的能力;

　　m) 显示画面允许以文字或图像的格式进行：

　　1) 数据显示;

　　2) 菜单显示;

　　3) 报告显示;

　　4) ACMF 功能选择(例如，生成和分发报告、修改用户定义的参数)。

　　n) GBSS 允许用户为每个画面建立相应的安全级别;

　　o) 为了实现整个飞机的 ACMF，应考虑在飞机上安排必要的、专用的状态监控传感器，特别应着重关注设备区域，例如发动机、辅助动力装置，或是环境控制系统设备例如空调器。

　　4.9.4 维护数据提供(PMD)

　　4.9.4.1 基本功能

　　维护数据提供的主要目的是允许机载维护系统终端用户通过信息访问操作获得维护数据。为此， 应包含如下功能：

　　a) 驾驶舱显示应用;

　　b) 维护通信管理器;

　　c) PMAT 显示应用;

　　d) 数据访问管理器;

　　e) 参数访问应用;

　　f) 机载维护文档。

　　此外，机载维护文档(OMD)是驾驶舱显示应用和 PMAT 显示应用的重要信息源，其基本功能需求在 4.9.4.7 中作出规定。

　　4.9.4.2 驾驶舱显示应用(CDA)

　　CDA 功能要求包括：

　　a) 正常模式：当飞机在该模式时，CDA 可提供接口便于机组查看 ACMF 结果;

　　b) 维护模式：当飞机在该模式时，维护模式只能通过人工授权启动，在该模式下，CDA 提供飞机维护人员能够执行相关任务的接口。

　　针对 OMS 的目的，CDA 连接到称为 MFD(可由ARINC661 驱动)的显示装置，每个装置包含一组用户应用定义文件。CDA 功能通过 ADN(可通过 A664p7 实现)与显示器交互，CDA 提供给飞机维护人员能够执行相关任务的接口如下：

　　a) 查看并清除 CMF 的失效消息;

　　b) 执行启动机内自测和锁定测试;

　　c) 查看 ACMF 结果;

　　d) 查看参数和离散数据;

　　e) 查看 OMD;

　　f) 查看 ACRF 的航电构型;

　　g) 查看可用的保存的 FLS;

　　h) 执行数据加载;

　　i) 执行数据保存。

　　4.9.4.3 维护通信管理器(MCM)

　　MCM 的基本功能包括：

　　a) 空中模式：在该模式下，MCM 将只服务于传输 OMS 数据的请求，所有写入数据存储的数据实体都要进行传输属性检查, 对建立了飞行配置规则的实体，MCM 将实体按优先级进行排列，并传送这些数据到飞机通信管理应用以通过飞机数据无线电进行传输;

　　b) 地面模式下，有三个功能要求：

　　1) 下传，对那些建立了地面配置规则的实体，MCM 将其按优先级进行排列，从数据存储提取必需的数据并按配置规则，从而实现到远程用户接口的传送;

　　2) 网络服务请求，MCM 会处理授权的 HTTPS 请求，并传回用于传送的所选数据;

　　3) 上传，MCM 会处理授权的文件传输请求，MCM 会确保只有一个连接到 PMAT 的以太网可以传输 FLS 至数据存储。根据安全需要，MCM 可禁止借助无线数据网络从 PMAT 传输 FLS。

　　c) MCM 对于 OMS 输出信息传输，实现适当的通信服务和必要的通信配置所需要的优先级排序、格式化和信息分发;

　　d) 对于输入传输，MCM 提供了数据优先存储的证明和确认，或决定对数据存储的数据请求优先回复的访问权限。

　　4.9.4.4 PMAT 显示应用(PDA)

　　PMAT 显示应用基本功能包括：

　　a) 正常模式：在该模式下，无功能要求;

　　b) 维护模式：当飞机在地面时，维护模式只能够通过人工授权启动。在该模式下，PDA 提供飞机维护人员能够处理任务的接口如下：

　　1) 查看并清除 CMF 的失效信息;

　　2) 查看 ACMF 结果;

　　3) 查看参数和离散数据;

　　4) 查看 OMD;

　　5) 查看 ACRF 的航电配置;

　　6) 查看可用的存储 FLS;

　　7) 管理数据存储(不含删除)。

　　c) PMAT 显示应用将为 PMAT 提供图形用户接口服务。

　　4.9.4.5 数据访问管理器(DAM)

　　OMS 具有其自身的数据存储能力，也就是数据存储功能，它用于存储大量的 OMS 相关的产品例如 FLS、交互式电子技术手册以及 OMS 功能数据。通过 DAM ，OMS 提供了严格的存储管理和数据获取管理功能。数据存储和数据获取管理器提供了在 OMS 的地面阶段功能，包括无线网络和 PMAT，与机上和航电系统交联的 OMS 功能之间的隔离。OMS 的地面功能是向数据存储(Data Store)功能中存放或获取数据，OMS 的机载功能也一样。但是， 数据不能从 OMS 地面功能直接向OMS 机载功能发送或获取，反之亦然。

　　DAM 功能要求包括：

　　a) DAM 功能要求由操作的当前模式进行判定;

　　b) 访问 DAM 的操作有两种模式，即正常模式和维护模式;

　　c) DAM 能够自动或由飞行平台显示器、PMAT 和无线网络的用户请求存储数据。

　　4.9.4.6 参数访问应用(PAA)

　　PAA 功能要求包括：

　　a) PAA 从 ADN 持续接收参数数据，并且往 DAM 持续发送过滤数据用于存储供某些功能的使用(如 ACMF 等功能);

　　b) 在 IMA 系统中，参数获取应用是一个驻留软件应用，驻留在 IMA 中的每个 GPM 上，它监测GPM 上的可用参数数据并将选取的部分参数数据传送到 CMF 所驻留的模块或单元上;

　　4.9.4.7 机载维护文档(OMD)

　　OMD 应具备如下基本功能：

　　a) 按规则存储数据的手段;

　　b) 通过操作员人员控制的直接信息检索;

　　c) 通过与其他系统之间接口的间接数据库检索;

　　d) 在一个或多个 MAT 上显示信息;

　　e) 打印需要的信息;

　　f) OMD 可存在于 ELS 中，其具体组成可由一个或多个 MAT 、ELS 计算机、海量存储设备和高分辨率打印机构成。

　　OMD 具体内容和OMS 提供的两类索引具体如下：

　　g) OMD 应具有如下具体内容：

　　1) 飞机维护手册和维护说明书;

　　2) 图解零件目录手册;

　　3) 飞机线路图;

　　4) 飞机原理图;

　　5) 放飞偏离指南;

　　6) 维护记录;

　　7) 操作员需要的其他维护数据。

　　h) 基于 OMS 隔离故障的能力，OMS 应能向OMD 所在的 ELS 提供两类索引，如下：

　　1) 航线可更换单元(LRU)的更换信息

　　如果 OMS 能隔离到单个 LRU，那么 OMS 应向OMD 所在的 ELS 提供唯一的识别该 LRU的方法。当 OMD 收到这个唯一的识别标志后，OMD 所在的 ELS 应根据命令显示或打印下列信息：

　　(1) 需要的工具;

　　(2) 接近的方法：需要的梯子或平台、用图样或图片定位、必需移开的任何障碍， 否则会遮挡被维修项目;

　　(3) 拆卸规程，包括适当的警告、提示和记录;

　　(4) 安装规程，包括必要的调整、锁定和再标定等;

　　(5) 必要的恢复测试。

　　2) 故障隔离信息

　　如果 OMS 不能将故障隔离到一个具体的LRU，那么 OMS 应向OMD 所在的 ELS 提供一个唯一的故障分析规程标志。当 OMD 所在的 ELS 收到这个唯一的故障分析规程标志时， OMD 根据命令应显示或打印下列信息：

　　(1) 有助于隔离到单个 LRU 的详细故障分析规程;

　　(2) 需要的工具;

　　(3) 接近的方法：需要的梯子或平台、用图样或图片定位、必需移开的任何障碍， 否则会遮挡被维修项目。

　　注：a)中 1)的维护手册和维护说明书应与 CCAR-25-R4H25.3 中的维护文档内容要求一致。

　　4.9.4.8 信息交互

　　PMD 信息交互的要求如下：

　　a) CDA 功能与 OMS 的 ACRF 、ACMF 、DLF 和 CMF 交互;

　　b) MCM 的信息交互包括：

　　1) MCM 与 DAM 的进行信息交互以便从数据存储中存储和提取数据;

　　2) MCM 与无线数据网络进行信息交互以便进行向上传输和向下传输数据;

　　3) MCM 与飞机数据无线电进行信息交互，用于数据传输。

　　c) PDA 功能与 OMS 的三个功能 DAM 、CMF 和 MCM 进行信息交互。

　　d) DAM 与 OMS 的 CMF 、ACMF 、DCA 、DLF 、MCM 和 PDA 功能进行交互。

　　e) PAA 主要将参数和离散数据信息发送给 OMS 的 DAM，从而便于 CMF 和 ACMF 的使用。

　　f) 在不同情况下，OMS 应提供以下交互信息：

　　1) OMS 的其他功能与 OMD 所在的 ELS 之间进行交互时，维护或故障分析规程的确认和选择;

　　2) 当 OMS 隔离到单个失效部件时，OMS 应提供“维修选项”;

　　3) 当 OMS 不能隔离到单个失效部件时，OMS 应提供“隔离”选项。

　　4.9.5 飞机构型管理功能(ACRF)

　　4.9.5.1 基本功能

　　ACRF 应报告从飞机各系统中收集的构型数据，并检测构型的改变。ACRF 功能应包括以下功能：

　　a) 接收 MS 发送的设备识别状态，其中应包括每个 MS 的硬件/软件状态;

　　b) 通过显示系统向维护人员显示各系统构型状态，并提供构型管理接口;

　　c) 向 DAM 发送硬件/软件构型信息，并存至数据存储器;

　　d) 能够识别 MS 构型改变。

　　4.9.5.2 信息交互

　　ACRF 的信息交互的要求如下：

　　a) 和 MS 的交互-ACRF 应接收 MS 的设备识别状态信息，包括硬件/软件状态;

　　b) 和显控系统的交互-ACRF 应接收并响应显控系统的命令，并将数据存储中飞机构型报告发送显控系统便于维护人员查看;

　　c) 和数据存储的交互-ACRF 应能识别构型改变，并向数据存储发送改变后的构型信息。

　　4.9.6 数据加卸载功能(DLF)

　　4.9.6.1 基本功能

　　DLF 功能要求如下：

　　a) 加载到飞机上的所有 MS 的数据将通过 OMS 的 DLF 执行加卸载;

　　b) DLF 还应负责CMF 和 ACMF 的数据及报告下载;

　　c) 数据加载应只在地面维护模式下有效，由维护人员通过人机界面(如 CDA 等)发出命令;

　　d) OMS 应支持不同的 MS 使用不同的加载协议实现 FLS 的加载;

　　e) 加载结果也应发送给 OMS，供维护人员查看。

　　f) 数据加载的中止条件为：

　　1) OMS 发出的数据包超时;

　　2) 出现了 LRU 或 LRM 内部失效;

　　3) 软件部件被毁坏或不兼容。

　　4.9.6.2 信息交互

　　DLF 和OMS 其他功能间应该至少包括如下交互信息：

　　a) DLF 和 MS 之间进行 FLS 加卸载、故障数据传输等信息的交互;

　　b) DLF 需要访问 DAM 获取可用的 FLS;

　　c) DLF 通过显示应用(如CDA)启动数据加卸载操作。

　　4.9.7 成员系统 BIT(MS)

　　4.9.7.1 故障检测

　　MS 的 BITE 应负责识别 MS 的任何故障状况，以及与其他 MS 和传感器之间外部接口的故障状况。

　　利用正常的不间断运行监测的结果可以完成上述识别，这是每个 MS 的基本操作功能之一。为提高故障检测的完整性，可以增加上电自检和用户启动测试。对于容错的 MS，应能评定其降级使用的状况。 BITE 应能使用降级数据。

　　对于有多个 LRU/LRM 的系统，最好能监测所有的单元/模块。这可由每个 LRU/LRM 自监测系统独自完成，也可由一个中心 LRU 对一些不复杂的外围设备同时监测来完成。

　　4.9.7.2 故障隔离

　　在多 LRU 系统中，BITE 应能准确指示发生故障的 LRU/LRM。如果开始时信息不够充分，为提高故障隔离准确率，需要 BITE 有运行自检的能力。

　　4.9.7.3 恢复运行测试

　　设计 BITE 应有助于更换 LRU/LRM 后飞机快速的恢复服役。LRU/LRM 更换后进行的 LRU/LRM或系统测试，应充分表明飞机系统的可用性。MS 上电测试的设计目标应足以作为恢复服役测试。在不需要定期工作的电路断路器的条件下，CMF 应能启动相同或相似的测试。如果飞机状态不允许这样的测试，那么 MS 应确保不会进人恢复服役测试模式(即使 CMF 发出命令)。

　　在不从飞机拆除 LRU/LRM 的情况下，MS 应有足够的适应性参与相关的测试。所需的专用地面支持设备应尽可能少。

　　4.9.7.4 飞机构型支持

　　MS 应向CMF 提供构型数据，用于机上 LRU/LRM 的配置管理。这部分信息详见第 4.9.2.3.8。

　　4.9.7.5 地面支持功能

　　为支持系统测试 4.9.2.3.4，MS 应考虑必要的地面支持设备接口，但应尽量减少专用接口的使用。

　　4.9.7.6 BITE 的 NVM

　　4.9.7.6.1 基本要求

　　航空电子 LRU/LRM 应装有 NVM，用于存储各种内部的故障/失效数据，包括容错 LRU/LRM 内的故障数据和软件异常数据。在维修车间可以读出这些数据，或飞机停飞时在飞机上读出这些数据。

　　注：LRU/LRM 的 BITE 存储内容的显示并不是一种外场维护工具，而是作为一种收集数据的工程工具用于了解难以诊断的故障以及辨别可能存在的设计缺陷。

　　4.9.7.6.2 详细故障数据存储

　　详细故障数据存储要求如下：

　　a) 发生故障的航段的标题应存储，包括：

　　1) 来往城市或航线编号;

　　2) 航班编号;

　　3) 日期;

　　4) 飞机标识;

　　5) 航段编号;

　　6) LRU/LRM 位置;

　　7) 软件部件号;

　　8) 选中的选项。

　　b) 下列信息应与每个故障同时存储：

　　1) 检测故障的监测设备的标识和相应的故障代码;

　　2) 硬故障或间歇性故障的分类;

　　3) 每个航段故障发生的次数，至少要预留 4 次的存储空间;

　　4) 故障发生对应的飞行阶段和 UTC;

　　5) 故障隔离到一个 SRU 的水平;

　　6) 用于故障分析的辅助参数，例如，发现故障时系统的状态。

　　MS 应利用CMF 发送的飞行阶段信息，提供选择的故障存储数据。

　　4.9.7.6.3 软件异常

　　MS 的软件发现错误状态已经发生时，应尽量捕捉必要的信息以分析错误发生的原因。被监测的错误包括：

　　a) 软件复位;

　　b) 看门狗超时;

　　c) 处理器陷阱(例如：除以 0、非法地址等)。

　　捕获数据应作为工程数据自动触发并存储在 NVM 中。软件错误捕获 NVM 数据至少要有存储 5 个“捕获”事件的空间。这种软件功能必须不影响系统其他功能的正常运行。

　　注：如果设计不当，增加的用于检测软件和/或系统异常的软件，可能会引起其他异常现象(例如，超越程序执行时间监测)。增加监测任何异常的技术必须避免这类问题发生的可能。

　　4.9.7.6.4 系统事件监测

　　已觉察到的系统异常经常在系统使用时被报告出来。导致这些事件的原因可能是： 设计错误、软件错误、偶发事件、或误解系统设计和操作。用户希望 MS 在这样的事件中具备捕获软件数据的性能。这种功能可由驾驶舱的事件按钮的激活来触发，或由 MS 中预设某种条件自动的触发，或由于响应 CMF命令来触发。这种功能必须不影响系统其他任何功能的正常运行。

　　4.9.7.6.5 NVM 的容量

　　LRU/LRM 应具备存储至少来自 100 个航段的数据的容量，每个航段可能会产生一个或多个故障或维护报告。要提供最少 512 个故障存储容量。每个故障要存储的数据在第 4.9.7.6.2 条中规定。

　　4.9.7.6.6 NVM 的擦除

　　NVM 中存储的数据可以在车间内擦除，也可以在有安全措施的条件下在飞机上擦除。

　　4.9.7.6.7 NVM 的先进先出数据存储

　　当存满时，最早存储的数据将被放弃。

　　4.9.7.7 系统 BITE 和 CMF 的通信

　　系统 BITE 通信协议应用编码发送故障数据。编码的定义见相应的 ARINC 规范(如果有)。CMF 翻译来自不同的 MS 的编码后，经过数据综合，最后用清晰的消息显示给维修工程师。

　　可以读取驾驶舱效应数据的MS 应能把这些信息发送给 CMF，以使与 CMF 检测到的故障相关联(见4.9.2.2.1)。

　　MS 监测到的故障应立即报告给 CMF。如果当前故障消失，也应立即向 CMF 报告。

　　4.9.7.8 内场维护中 BITE 的使用

　　BITE 的第二个目标是为了提高内场维修的效率和降低成本。在车间里， BITE 内存储的故障历史信息和 BITE 提供的自检功能可以加快故障 LRU/LRM 的修理和测试。

　　作为一个设计目标，LRU/LRM 的 BITE 应能确定 LRU/LRM 是可供使用的。

　　4.9.7.9 BITE 详细要求

　　MS 故障监测和 BITE 功能应能满足下列要求：

　　a) 导致系统功能丧失或严重降级的所有内部故障和失效都要被完整地监测;

　　b) 没有故障和失效存在时，不应产生错误或失效的指示;

　　c) 电源的瞬变过程不会引起故障的伪指示;

　　d) 尽可能通过不间断运行监测实现故障检测，当连续监测不可用时，为满足完整性要求，应增加系统上电 BITE 测试;

　　e) 外部故障或失效不应引起内部故障或失效的伪指示;

　　f) 故障监测设计应考虑容差和时间筛选，从而与需要的功能以及操作环境兼容;

　　g) BITE 的完整性应通过使用中的表现来证实;

　　h) 在对一个 LRU/LRM 不用的功能进行监测时，检测到的故障结果可以内部记录，但不应引起任何系统故障指示和不应向 CMF 报告;

　　i) 为满足测试完整性要求，轮回式测试应对 LRU/LRM 的输入和输出有必要的覆盖范围。

　　4.9.7.10 接口故障检测及其分类

　　接口故障检测主要有总线和模拟 2 类，其中总线类包括 ARINC429、ARINC629 信号、ARINC664信号，模拟信号不包括离散信号，具体内容如下：

　　a) ARINC429 信号输入故障应被检测、分类和报告如下：

　　1) 总线故障，如果 8 进制标号 377 没有收到;

　　2) 信号故障，表示其他系统故障，例如 SSM =FAIL，奇偶校验错误，合理性或对比监测。故障的 LRU/LRM 应通过在受影响的标志上发送 SSM =FAIL 指明这种状态。

　　b) ARINC629 信号数据故障应被检测、分类和报告如下：

　　1) 整个总线故障，如果没有从任何 LRU/LRM 收到输入信号;

　　2) 单个 LRU/LRM 总线故障，如果只有一个 LRU/LRM 信号没有收到;

　　3) 信号故障，表示其他系统故障。

　　c) ARINC664 信号数据故障类型通过每个 DS 对应的 FSB 标识：

　　1) 0x00：No Data 无效状态;

　　2) 0x03：Normal operation 有效状态-普通数据;

　　3) 0x0C：Functional Test 有效状态-功能测试;

　　4) 0x30：non-computed Data 无效状态-无计算数据。

　　d) 模拟信号(不包括离散信号)输入故障应检测、分类和报告如下：

　　1) 开路或接地;

　　2) 信号故障，表示其他检测到的故障，例如合理性或对比监测。

　　4.9.7.11 电源中断报告

　　MS 的 LRU/LRM 从一个电源中断恢复之后，应向CMF 报告。

　　注： 电源中断一般会导致许多的接口错误。通过让每个 MS 报告电源中断的恢复，CMF 可以较好地将其与从 MS

　　收到的接口故障相关联。这样可以发现引起问题的原因是电源中断，从而减少不合理的部件拆卸。

　　4.9.8 机载维护支持功能(OMSF)

　　4.9.8.1 基本功能

　　OMSF 的要求如下：

　　a) OMSF 功能提供了OMS 相关设备的 BIT 能力，该能力确定 OMS 是否正常运行;

　　b) OMS 相关设备的 BITE 设计应遵守 4.9.7 中 MS 的 BITE 设计准则;

　　c) IMA 系统中，OMS 应利用通用处理模块中驻留的 PAA 功能进行健康报告;

　　d) OMS 相关设备的 BIT 结果应持续上报至CMF;

　　e) 当 OMS 相关设备不在数据加载模式下运行时，其内部 BITE 作为一个 MS 提供给 CMF，除自检测状态报告外，该功能也可以根据需要将参数和离散数据传输给 ACMF，将设备构型数据提供给 ACRF。

　　4.9.8.2 信息交互

　　OMSF 的信息交互关系如下：

　　a) 作为一个 MS ，OMSF 与 CMF 、ACMF 和 ACRF 进行交互;

　　b) 交互内容见 4.9.2.5、4.9.3.3 和 4.9.6.2。

　　4.10 标识

　　a) 设备和零部件上的标志(包括文字、符号、代号、图形、颜色等)应按产品规范的规定，且简明、清晰、耐久、明显、易读，标识不应影响设备的机械和电气性能;

　　b) 应至少有一个主要设备和零部件上的标识是易读的和永久的，标识应包括序列号和与其功能相对应的功能设备等级;

　　c) 设备标识应标有设备名称、型号、生产厂、出厂编号、出场时间等内容;

　　d) 如果设备和零件包含替代或等效符合性方法造成与标准的偏离，标志应包括表明批准的偏离方法。

　　4.11 接口

　　OMS 应具备如下接口：

　　a) 与地面进行信息交互的接口-用于在飞行中向地面传输数据和报告，以提前启动和准备必要的维护措施，同时，也可接收来自地面的数据请求;

　　b) MS 向 OMS 报告故障信息的接口-故障信息为从ATA21 章至ATA80 章包含的电子可探测的、可传输的故障数据，某些飞机系统还提供补充的故障信息;

　　c) 提供信息显示输出接口。

　　4.12 通信

　　OMS 应满足如下通信要求：

　　a) OMS 内部通信-OMS 内各功能之间通信应符合已有航电通信网络要求;

　　b) 与 MS 或其他飞机系统的通信-应根据系统需求选取不同的网络通信协议;

　　c) OMS 的相关维护信息应能够借助数据链传输至地面站。

　　4.13 工作模式

　　为了更清晰的描述 OMS 实现的功能，对 OMS 的工作模式进行如下规定：

　　a) 正常的工作模式-OMS 主要的操作状态，当系统上电 BIT 以及初始化完成后，自动进入此模式，直到断电。在本模式下，OMS 实现故障的检测和定位、异常监测、健康状态的评估、性能趋势、故障预测和构型报告等功能;

　　b) 地面维护模式-飞机停在地面，且满足系统一些安全