ICS 49.090 V 41
HB 8433-2014
民用飞机飞行管理和通信管理功能的
航空电子接口要求
Avionics interface requirement for flight management and communications
management functions of civil aircraft
2014-05-19 发布 2014-10-01 实施
中华人民共和国工业和信息化部发布
前言
本标准按照 GB/T 1. 1-2009 给出的规则起草。
本标准由中国航空综合技术研究所归口。
本标准起草单位：中国航空无线电电子研究所、中国航空综合技术研究所。
本标准起草人：黄永葵、孙晓敏、袁晓晗、吴建民、朱晓飞、张国全、王利洲、朱占奎。
民用飞机飞行管理和通信管理功能的航空电子接口要求
1 范围
本标准规定了民用飞机飞行管理和通信管理功能的航空电子接口的协议要求和配置要求。
本标准适用于民用飞机飞行管理和通信管理功能的航空电子接口的设计。
2 规范性引用文件
下列文件对于本文件的应用是必不可少的。凡是注日期的引用文件，仅注日期的版本适用于本文件。凡是不注日期的引用文件，其最新版本(包括所有的修改单)适用于本文件。
HB 6096 SZ-01 数字信息传输系统
ARINC 618 空-地面向字符协议(Air/ground character-oriented protocol specification)
ARINC 619 航空电子端系统的 ACARS 协议(Acars protocols for avionic end system)
ARINC 622 空中交通管制数据链在 ACARS 空-地网络中的应用(ATS data link applications over ACARS air-ground network)
ARINC 646 局域以太网(Ethernet local network (ELAN))
ARINC 664 飞机数据网络(Aircraft data network)
ARINC 702A 先进的飞行管理计算机系统(Advanced flight management computer system)
ARINC 741 航空卫星通信系统(Aviation satellite communication system)
ARINC 750 甚高频数据无线电通信设备(VHF data radio)
ARINC 758 通信管理单元 MARK 2(Communications management unit MARK 2)
IEEE 802.3 信息技术-系统间无线电通信和信息交互-局域网和主网络详细要求第三部分(IEEE standard for information technology-telecommunications and information exchange between systems- local and metropolitan area networks-specific requirements part 3)
ISO 8208 信息技术-数据通信-数据终端设备的 X.25 信息层协议(Information technology-data communications-X.25 packet layer protocol for data terminal equipment)
ISO 9542 信息处理系统 -系统间无线电通信和信息交互 (Information processing systems- telecommunications and information exchange between systems)
RTCA/DO -178B 机载系统和设备合格审定中的软件考虑(Software considerations in airborne systems and equipment certification)
RTCA/DO-212 机载 ADS 设备最低性能要求标准(Minimum operational performance standards for airborne automatic dependent surveillance (ADS)equipment)
RTCA/DO-219 ATC 双向数据链路通信最低性能标准(Minimum operational performance standards for ATC two-way data link communications)
3 术语、定义和缩略语
3.1 术语和定义
下列术语和定义适用于本文件。
3.1.1
自动相关监视 automatic dependent surveillance (ADS)
一种开放式系统互连(OSI)面向位的 ATS 应用，用于在机载和地面的端系统之间请求和报告导航信息。
3.1.2
空中交通服务设备通告 air traffic services facilities notification (AFN)
一种 ARINC 622 面向字符的 ATS 应用过程，用于在机载和地面端系统之间通报和交换地址。
3.1.3
应用 application
在 OSI 通信环境之外的程序;使用但不属于信息系统。
3.1.4
航空公司运营通信 airline operational communications (AOC)
面向字符的 ACARS 消息，用于飞行计划的更新、风向、风速和飞机位置的报告。
3.1.5
桥接器 bridge
一种链接了两个在数据链路层有相同传输协议的子网络的设备。
3.1.6
总线访问时间 bus access time
在 MAC 程序访问物理总线和第一位出现之间的时间。通过测量数据链、物理层以及总线之间的逻辑转换点获得。
3.1.7
客户 client
应用处理的发起方，“服务端”数据的接收方。
3.1.8
文本管理 context management (CM)
OSI 面向位的 ATS 应用程序，用于在机载和地面端系统之间通报和交换地址。
3.1.9
通信链路 communication links
数字通信设备，为一个端系统到另一个端系统的应用数据传输提供子网络和协议。
3.1.10
连接 connection
为了传输数据在两个(点到点)或者多个(多点)(N+1)实体之间建立的(N)层的交联。
3.1.11
管制员驾驶员数据链通信 controller-pilot data link communications (CPDLC)
一种 OSI 面向位的 ATS 应用，用于在飞行机组和管制员之间进行包括许可信息在内的消息交换。
3.1.12
数据链应用 data link application (DLA)
一个数据链数据的标准集合，通过执行特定的数据链服务在通信链路上实现。
3.1.13
数据链服务 data link service (DLS)
两边系统都支持的 ATM 相关处理的集合，在手册中清楚地定义了操作目标。每一种数据链服务从操作角度描述了它所推荐的使用方式。
3.1.14
端系统 end system
包含一个或多个应用程序的系统，其应用程序启动数据传输，发送数据给其他系统，以及/或者从其他系统接收数据，但是驻留了这个应用程序的设备不做系统之间的数据中继。飞机状态监视系统(ACMS)、飞行管理计算机(FMC)、中央维护计算机(CMC)和数字飞行数据采集单元(DFDAU)等都属于端系统。
3.1.15
实体 entity
在(N)子系统中的一个能起作用的元素，一层内的一个功能或功能组形成了一个功能单元。它接受一个或多个输入，根据功能特性产生输出。在每一层至少有一个活动实体执行支持通信的功能。在同层中邻近的实体之间的通信使用对等协议。垂直邻近层实体之间的交互以原始形式进行。
3.1.16
网关 gateway
连接不同的子网络的系统，以子网络端用户的形式出现。网关应该至少包含 OSI 参考模型的四个较低的层，也可能包含所有七层。
3.1.17
高级数据链路控制 high-level data link control (HDLC)
国际电信联盟(ITU)和国际标准组织(ISO)标准数据链层协议，相对于控制帧内信息，它使用了“位填塞”来描述在哪些是构成消息的位。
3.1.18
链路层内的子层 link protocol data unit (LPDU)
在一些局域网(LAN)系统中它和高层用户通信。
3.1.19
介质访问控制 media access control (MAC)
链路层内的子层，在一些 LAN 系统中它和物理层通信。
3.1.20
远程堆栈 remote-stack
系统配置，其协议堆栈驻留在与端系统应用程序不同的系统中。
3.1.21
系统地址标号 system address label (SAL)
用于识别接收方的 HB 6096 协议元素。
3.1.22
服务访问点 service access point (SAP)
一个实体(N)向另外一个实体(N+1)提供服务的节点(地址)。
3.1.23
服务器 server
对客户请求的响应者。服务器包含了被许多客户访问集中的信息。
3.1.24
子网接入点 subNetwork point of attachment (SNPA)
提供中继和路由的一个或多个中间系统的组合，端系统通过它可以建立网络互连，表示一个实际网络的实现，这个网络在集中控制下使用相似的协议和寻址计划。
3.1.25
子网 subnetwork
提供中继和路由的一个或多个中间系统的组合，端系统通过它可以建立网络互连，表示一个实际网络的实现，这个网络在一个权力的控制下使用相似的协议和寻址计划。
3.2 缩略语
下列缩略语适用于本文件。
CM——context management，文本管理;
DLA——data link application，数据链应用。
4 概述
本标准使用五层的开放式系统互联(OSI)参考模型来定义通用接口，每个上层实体需要相邻的下层的服务。OSI 堆栈的底部的物理总线要适应短期的和未来的通信增长。该总线初始定义为HB 6096 数字信息传输系统(DITS)或 ARINC 646 以太网。为了以最大速度传输数据， 使用高效的数据链路层协议和物理总线。其次，使用因特网工程任务小组网络协议(IETF IP)作为机载系统总线或网络数据交互和路由的规范。使用 IETF 用户数据包协议(UDP)来进行终端系统之间无连接消息的交换，通过定义 SNMP代理，来支持 ATS 通信或基于应用程序的其他消息。设计的 SNMP 代理用于通信通道的一边，另一边则执行 SNMP 管理器进程。两边都可以支持代理和管理器， 如客户端和服务器。最后， 定义 CMU/FMC信息代理(CFIB)应用程序用于交换 ATS 数据，如飞行计划信息、飞机航迹、飞机位置和其他导航或飞行计划数据。
采用何种几种层协议或者全部层协议取决于系统的结构，在 8.6 节中明确了获得与本标准一致所需要的必要协议。
CFIB 和 ATS 应用程序用“事件驱动”传输消息，它对可用带宽的利用比“广播”或“周期”的传送更有效。因此，HB 6096 高速总线或 ARINC 646 总线比传统低速 HB 6096 广播总线提供更灵活和更高增长的能力。
附录 A 的图 A. 1 提供了本标准接口框图，以太网总线用点线显示。
注：推荐用 HB 6096 高速总线(见附录 A 的图 A.2)或 ARINC 646 10BaseT 以太网总线(双绞屏蔽)连接。定义的协议原理是独立于底层物理总线的，因而未来可以使用其他总线和网络。
5 要求
5.1 概述
本章定义了在不选择特定总线或数据链路协议条件下，支持接口的物理总线和数据链路层应该满足的性能。可保证未来总线结构的扩展不会影响本标准接口。
注：本标准预计由物理总线及其相应数据链路层提供的性能超出了 HB 6096 低速总线及其相应的面向位的数据链路层协议所提供的能力。
5.2 物理层
能够支持本标准接口的物理总线应当具有下列特性：
—— 数据速率大于或等于 100 kbps;
—— 全双工运行;
—— 支持异步通信;
—— 适当的位误差率;
—— 能够透明地传输 8 位数据。
注：系统综合人员要确保由 FMC/CMU 接口总线提供的位误差率能支持所要求的完整性级别。目前认为 HB 6096 高速总线和 ARINC 646 以太网总线都是适合用于本标准的总线类型。
5.3 数据链路层
5.3.1 概述
本节依据数据链路层使用的协议以及 IETF IP 所提供的原语来描述数据链路层的性能。数据链路层相当于 IEEE 802.3 第 3 部分的介质访问控制(MAC)子层服务。数据链路层的帧由用户数据和MAC 子层的协议头组成。
为了满足扩展要求，无论数据链路层协议工作在 HB 6096 高速总线、ARINC 646 以太网总线还是任一兼容的航空电子总线上，原语都应该提供与上层的基本服务(例如：到/来自IETF IP 协议)的交互。
MAC 层服务满足传递周期和非周期的 SNMP 代理参数以及传递完整数据链消息的要求。此外， 这些数据链路层服务提供了一个公共原语集，不受物理总线限制，可以像 IETF IP(或其他上层)协议下面的数据链路服务(DLS)提供者一样进行标准操作。
注：这个 MAC 服务对于在如 ARINC 646 的物理总线上的数据链路层工作已经被标准化，但是如果一个给定的航空电子数据链路层和总线不支持 MAC 服务，则必须对它进行修改，以便能像本标准数据链路层和物理总线一样使用。
5.3.2 高速数据总线的数据链路层协议
本标准允许不同的数据链路层支持本标准的接口，能支持本标准的接口的数据链路层服务应该具有下列特性：
—— 必须是面向位的;
—— 支持 MAC 服务;
—— 误差检测;
—— 全双工工作;
—— 链路协议数据单元(LPDU)最大 1500 字节(最少);
—— 支持批选址;
—— 能透明地通过 8 位数据;
—— 每个方向每秒 6 个 MAC 最大量帧的最小持续吞吐量;
—— LPDU 发送延迟少于[待定];
—— LPDU 接收延迟少于[待定];
—— 总线超额延迟少于[待定]。
为了满足 MAC 接口性能标准，数据链路层子层可能需要应用分段。
为了满足 FMC 与 CMU 接口的性能要求，数据链路层协议可以用于 HB 6096 高速总线上。ARINC
646 MAC 协议可以用于 ARINC 646 以太网总线上，以满足 FMC 与 CMU 接口或航空电子局域网(LAN)性能和扩展要求。附录 N 给出了两个高速数据总线上常用数据链路层协议。
5.3.3 数据链路层和 IETF IP 之间的原语
MAC 定义包括了与 MIB 的接口，假设这个 MIB 含有一个表示此数据链路层服务健康的参数(无论这个数据链路服务是“可用”或“不可用”的)。在数据链路层和 MIB 之间有一个管理事件，记录数据链路健康状况。当数据链路服务不可用时，有另一个管理事件通报 IETF IP。
下面的条款基于 ARINC 646 MAC 数据链路服务(见 IEEE 802.3 第 2 部分)，定义了 IETF IP 和数据链路层之间原语的一个通用集合。这些原语输入到数据链路层协议状态机或从其输出。
—— MA_DATA.request (source_address, destination address, data, service_class)
注：当要求批寻址时，数据链路层发送一个“广播”数据包给所有适用的数据链路层服务访问点(LSAP)地址。 —— MA_DATA.indication (source_address, destination_address, data, reception_status,service_class) —— MA_CONTROL.request (Command_type, destination_address, PAUSE opcode, Request_operand) —— MA_CONTROL.indication (Command_type, destination_address, PAUSE opcode, Request_ operand)
5.4 网络层
本标准接口包含 IETF IP，由 ARINC 664 规范“基于因特网的飞机协议和服务”第 2 部分定义，它规定了机上航空电子局域网(LAN)或点到点链路上数据包的中继、路由和转发。附录 B 的图 B. 1 和图 B.2描述了作为 IP 的网络层。
5.5 传输层
在本标准接口中传输层协议参考 RFC 768 注释中规定的IETF UDP。这个接口提供给客户-服务器类请求-回答的询问和应用程序，在这里，对于机载航空电子 LAN 或点到点链路，提示发送比准确发送更重要。附录 B 的图 B. 1 和图 B.2 描述了 UDP 的传输层。
注：UDP 是无连接协议，它可能是不可靠的。
5.6 网络管理接口
目前的网络管理组件包括网络管理器、网络管理协议、管理代理和 MIB 等。
a) 网络管理器通常用一台适当的计算机或一组计算机实现。
b) 网络管理协议支持网络管理器和管理代理之间进行通信，这些协议已根据管理器/代理关系的本地特性，把两个主要的通信层标准化：
1) 局部受 LAN 限制的数据链路层;
2) LAN 和 WAN 的应用层。
c) 管理代理提供访问参数集或管理对象的服务。在实现上主要的差别在于这些服务： 有的只对请求(轮询)提供服务，而有的也对事件提供指示(事件指示)。
d) MIB 基于一个规定了通信系统特定部分的特性的参数集或基于一个管理对象集。管理对象通
过增加行为和访问权限的特征，增强了用参数集表示的范例。
5.7 性能要素
5.7.1 系统完整性
FMC/CMU 接口的完整性应能支持在系统实现中维持其接口的应用程序要求的整个系统的完整性。 FMC/CMU 接口要求应包含以下几个方面：
—— 物理总线位误差率(见 5.2);
—— 数据链路层协议的位误差检测，以及它对终端-终端的位误差检测的影响(也就是终端系统到终端系统)(见 5.3.2);
—— 软件开发级别(见 RTCA/DO-178B)。
5.7.2 定时/处理延迟
当获得服务的数据链路应用程序含有终端到终端的定时要求或消息响应要求时，系统综合者应确保简单网络管理协议(SNMP)应用程序的使用不会影响定时要求。
5.8 对维护功能的支持
FMC/CMU 接口的维护包括硬件故障报告和软件配置管理。硬件故障可通过机内测试设备(BITE)检测，专用的 BITE 需求在 FMC、GNLU 和CMU 适用的 ARINC 规范中定义。
6 简单网络管理协议(SNMP)
6.1 概述
SNMP 应向用户应用程序提供“数据访问”服务。
附录 F 的图 F. 1 给出了实现 SNMP 的典型结构。
SNMP 提供了在两个或更多的应用程序之间传递信息的机制，图 F. 1 举例说明了 SNMP 能够向几个不同的应用程序提供“数据访问”服务。“公司名称”用来作为用户选择器，起到与 UDP 端口、IP 协议号、IP 地址或以太网的以太类型相同的作用。
通常情况下，SNMP 可通过交换协议消息实现实体之间的信息通信。SNMP 提供一个“客户-服务器”关联，这样同等应用程序既可作为客户和管理者(插入或请求数据)，又可作为服务器或代理(提供请求的数据)。SNMP 作为一种无连接的通信协议，它能同时支持多个会话。
SNMP 能支持客户或服务器角色之一或同时支持这两个角色，但在大多数情况下一个应用程序只作为代理或管理器。
该协议提供两种类型的数据访问：
—— 第一种类型是“请求-响应”交互，就是当一个在管理器中的 SNMP 实体发送一个请求给在代理中的 SNMP 实体，后者的 SNMP 实体则响应这个请求。这种类型用于恢复或修改与代理设备关联的信息。
—— 第二种类型是“未经认可的交互”，就是在代理中的 SNMP 实体发送一个称为陷阱的未被请求的消息给管理器中的 SNMP 实体，而没有响应返回。这种类型用于通告异常情况， 它的作用是改变与代理设备关联的管理信息。
术语“管理信息或变量”提到一个非聚合的对象(通俗地说就是简单标量数据)的实例，它是根据在管理信息结构(SMI)中的规定定义的。
这些变量被视为是受控对象的集合，驻留在一个虚拟信息存储器中，称为 MIB。相关对象的集合在 MIB 模块中定义，这些模块用一个 OSI 抽象语法符号 1(ASN. 1)的子集描述，称为 SMI。
6.2 MIB 概述
MIB 包含以下特点：
—— 管理信息库(MIB)是一个数据集，它能够被本地应用程序或远程应用程序使用。
—— MIB 的典型应用是网络管理，即需要获得设备状态并设置这个设备的内部值的动作。
—— MIB 的特性之一是与给定设备相关的数据能被通用库识别。
—— 在 MIB 中定义的数据通过它们在命名树中的位置来确定。
附录 F 的图 F.3 举例说明了 ARINC (xxx)命名树在 ISO 标准对象识别命名树中的位置。
命名为子树的与应用关联的 MIB 位于 ARINC(xxx)下面。
定义与 CMU 和 FMU 运行相关数据的子树位于 ARINC(xxx)下面(见附录 F 的图 F.4)。例如，为 CMU/FMC 信息中介应用服务的CFIB 就在这里定义，这个子树名为“a656 ”。
在 ARINC(xxx)下定义的第二个子树是为了采集所有陷阱 PDU，这些 PDU 是针对应用程序的，在其他 ARINC 标准中叙述。
6.3 ASN.1 编码
SNMP PDU 根据 ASN. 1 基本编码规则(BER)编码，ASN. 1 简述如下：
不支持打包编码规则(PER)，但因为按照 RTCA/DO-219，所有 CFIB 变量可以有不同的类型，并且这些类型只和 CFIB 应用相关，所有 CFIB 变量编码按照纯二进制编码，即按 ASN. 1 语法是八位串(OCTET STRING)，ASN. 1 的编码提供了能被计算机解释的定义数据的通用方法，ASN. 1 的普通格式见图 1：
图 1 ASN.1 格式
“Identifier_field ” 包含一个或多个八位位组，它定义了数据的类型。Identifier_field 反应了该数据的原始的或构建的特性，它也反应了这个类型的范畴：全局的、受限于应用程序的、上下文专用的或私有的。
“Length_field”包含一个或多个八位位组，它定义了下一个字段的长度。
“Content_field”是数据本身，Content_field 可以是原始(primitive)数据或创建(constructed)数据。原始数据很像编程语言中的“类”，而创建数据很像 C 语言的结构。在此， Content_field 以一个Identifier_field 开始。
SNMP 认可下列“全局”数据类型：
—— INTEGER：整数;
—— OCTET STRING：其范围为 0-65535 八位位组;
—— SEQUENCE：定义由几种类型组成的数据;
—— OBJECT IDENTIFIER：见下面对 MIB 的论述;
—— NULL：无效对象。
其他可以专用于 SNMP 应用的数据类型：
—— IpAddress;
—— Counter32。
这些类型根据其各自的分类，采用数值(标签)来识别，见表 1。
表 1 各类数据标签
如果长度小于 127，Length_field 编码为一个八位组;长度大于 127，根据特定规则(详见 ISO/IEC 8824 8825)用更多的八位组来表示。
示例：
整数 20987 编码为[02，03，01，E2，40]，表示的是：
Identifier_field =Primitive Universal 2,
length_field=3,
Content_field=01 E2 40
无效编码[05,00]，表示的是：
Identifier_field =Primitive Universal 5,
Length_field=00。
对象标识符编码为 ASN. 1 类型全局量 6(编码为 0x06)，content_field 是子标识符序列;每个子标识符的编码为整数(大于 127 的整数遵循在 ISO/IEC 8825 中定义的规则)。最前面两个子标识符(也就是{ISO org})是为了节省一个八位组而压缩的，这里给出{ISO org}=[0x2B]。因此， 这个对象标识符是相关联的，例如“SysObjectId”{1 3 6 1 2 1 1 2}其编码就是[06 07 2B 06 01 02 01 01 02]。
6.4 协议定义
SNMP 的特征特性可参见以下文件：
—— RFC 1157 描述了“SNMP”简单网络管理协议;
—— RFC 1212“SMI”管理信息结构以及和它配对的文件“Concise-MIB”简明 MIB 定义;
以下这些文件包含了 SNMP 相关信息和示例：
—— RFC 1213 定义了管理信息库Ⅱ(MIB Ⅱ);
—— RFC 1215 为使用 SNMP 定义了陷阱协定;
—— RFC 1908 描述了网络管理架构协议标准第一二版共性;
消息在 SNMP 同等实体之间交换的基本数据。SNMP 消息由版本号、“公司名称”和形成协议数据单元本身的控制/数据字段组成。“公司”是一个 ASCⅡ字符串，它可以用作口令以准许访问CFIB 变量。
6.5 SNMP 版本 1 消息格式定义
6.5.1 SNMP 消息
SNMP 消息按下面定义：
Message :: =
SEQUENCE {
Version -- version-1 for this RFC
INTEGER {
version-1(0)
},
community -- community name OCTET STRING,
data -- e.g., PDUs if trivial ANY -- authentication is being used
}
通常将 SNMP 消息压缩在包含 IP 和 UDP 的以太网的封装中，生成如附录 F 的图 F.2 中描述的字段序列。
6.5.2 SNMP 协议数据单元
SNMP 协议数据单元定义如下：
PDUs ::
=
CHOICE {
get-request
GetRequest-PDU,
get-next-request
GetNextRequest-PDU, get-response
GetResponse-PDU, set-request
SetRequest-PDU, trap
Trap-PDU }
6.5.3 共用部分
共用部分用来请求或响应 PDU：
RequestID :: =
INTEGER ErrorStatus :: =
INTEGER {
noError(0),
tooBig(1),
noSuchName(2),
badValue(3),
readOnly(4),
genErr(5)
}
ErrorIndex :: =
INTEGER
-- variable bindings
VarBin d
::
=
SEQUENCE { name
ObjectName, value
ObjectSyntax }
VarBindList :: =
SEQUENCE OF
VarBind
6.5.4 GetRequest-PDU
GetRequest PDU 字段由下列 ASN. 1 定义：
GetRequest-PDU ::
=
[0]
IMPLICIT SEQUENCE { request-id
Request ID, error-status --
always 0
ErrorStatus,
error-index – always 0
ErrorIndex, variable-bindings VarBindList
}
本节剩余部分选择下面的协定来表示每个 SNMP PDU 的不同字段。
getRequest-PDU 可以表示为： get (
request-id =x ,
error-status=0 ,
error-index=0 ,
varName.instance =varValue
varName.instance =
varValue , )
这里 request-id 代表一个其值为 x 的字段，error-status 是值为 0 的字段，而 varName.instance 是变量名称，或由这个变量和实例确认的对象类型标识符(OID)。
VarValue 是变量的值，在 getRequest-PDU 中这个值是 NULL。
因为 SNMP 只能访问标量变量，表中的元素必须用列名称或行的值来确定，列 A 和行 B 的交叉处即访问变量 A.B，如图 2 所示。
图 2 cFIBTable 实例
这里 name 1到 name 4是表项目的各字段名称，其中一个或多个字段名称已作为索引(INDEX)声明。如果想访问 name 1 的 value5 值的列 name3，就必须确定要瞄准的对象为 name3.value5。
6.5.5 GetNextRequest-PDU
下面给出 GetNextRequest PDU 用 ASN. 1 和 API-like 协定的描述：
GetNextRequest-PDU :: = [1]
IMPLICIT SEQUENCE {
request-id
RequestID,
error-status -- always 0
ErrorStatus,
error-index -- always 0
ErrorIndex,
variable-bindings
VarBindList
}
next (
request-id =x,
error-status=0,
error-index=0,
varName.instance =NULL,
varName.instance =NULL, )
6.5.6 GetResponse-PDU
下面给出 Geresponse-PDU 用 ASN. 1 和 API-like 协定的描述：
GetResponse-PDU :: = [2]
IMPLICIT SEQUENCE {
request-id
RequestID,
error-status
ErrorStatus, error-index
ErrorIndex, variable-bindings
VarBindList }
resp (
request-id =x , error-status =y , error-index =z ,
varName.instance =varValue
varName.instance =varValue
6.5.7 SetRequest-PDU
下面给出 SetRequest PDU 用 ASN. 1 和 API-like 协定的描述： SetRequest-PDU :: =
[3]
IMPLICIT SEQUENCE { request-id
Request ID,
error-status -- always 0
ErrorStatus,
error-index -- always 0
ErrorIndex,
variable-bindings
VarBindList }
set (
request-id =x ,
error-status=0 ,
error-index=0 ,
varName.instance =varValue ,
varName.instance =varValue , )
6.5.8 Trap-PDU
下面给出 Trap PDU 用 ASN. 1 和 API-like 协定的描述：
Trap-PDU :: = [4]
IMPLICIT SEQUENCE {
Enterprise -- type of object generating
-- trap
OBJECT IDENTIFIER,
agent-addr -- address of object generating NetworkAddress, -- trap
generic-trap -- generic trap type
INTEGER {
coldStart(0), warmStart(1), linkDown(2),
linkUp(3),
authenticationFailure(4),
egpNeighborLoss(5),
enterpriseSpecific(6)
},
specific-trap -- specific code, present even
INTEGER, -- if generic, trap is not enterprise Specific time-stamp -- time elapsed between the last
TimeTicks, -- (re)initialization of the network
-- entity and the generation of the
trap
variable-bindings -- “interesting” information
VarBindList }
trap (
enterprise =x ,
agent-address =IPaddress ,
generic-trap =x ,
specific-trap =y ,
time-stamp =z ,
varName.instance =varValue ,
varName.instance =varValue , )
RFC 1215 建议了一个定义陷阱的文本协定并提供了使用陷阱的指南。本标准建议以某种方式实现特定的 AEEC 陷阱，这将简化 SNMP 版本之间的移植。
enterprise 字段里含有一个对象标识符(OID)。如果这个陷阱是一个普通陷阱，则 enterprise 字段取OID{SNMP}({mid-2 11}的值)，且普通陷阱字段收到代表陷阱原因的值。
如果这个陷阱是一个由 ARINC 标准应用程序，如本标准 CFIB 产生的特殊陷阱，则 enterprise 字段取 OID{ARINC(xxx)}的值，普通陷阱字段收到值 INTEGER(6)，这个字段的 specificTrap 字段为 0 并且增加一个变量捆绑到这个清单中，这个变量捆绑接收对应该应用程序发送的特殊陷阱的 OID。
这些变量全都位于 OID 节点{ARINC(xxx)ARINC (xxx)SNMPTrap}下面。
举例来说，由本标准 CFIB 应用程序产生的陷阱称为{ARINC(xxx)SNMPTrap cFIBStatus(1)}，并且所有产生陷阱的 CFIB 接收这个节点下的一个 OID：
意思是“能遵守”的陷阱接收 OID ableToComply::={cFIBStatus 1};
意思是“不能遵守”的陷阱接收 OID unableToComply::={cFIBStatus 2}。
因此，当一个代理想要用信号通知管理者它不能遵守，它就发送下面的陷阱： trap (
enterprise =ARINC (xxx),
agent-address=10.23.45.67,
generic-trap=6,
specific-trap=0,
time-stamp=489012,
contractID.22=123456789
cFIBStatus.0=unableToComply)
在这个与本标准 CFIB 相关的例子中，看起来是在 IP 地址 10.23.45.67 的 LRU 中的 CFIB 应用程序
产生了加电后 4890. 12 秒的陷阱，在变量捆绑清单中的另一个变量“contractID.22”出现，因为它的价值在于能知道这个陷阱涉及到在 CFIB 表的第 22 行中列出的契约。
6.6 MIB 定义
6.6.1 概述
系统综合者负责显示、报错或其他 MIB 版本标识符与飞机系统的综合，用户负责 UDP 和 SNMP应用的软件配置管理。
注 1：应用程序的配置表提供了一个允许在不同时间更新 LRU 的动态同等应用发现机制。为了未来的访问， 对这个接口的数据链路失效可以在 MIB 中做记录。
注 2：在以前实现复杂数据链路系统时，已经证明了在这些系统中有必要建立数据记录机制，它便于工程上发现接口协议和/或通信联系问题。
6.6.2 应用配置 MIB
表 2 包含了受系统支持的所有应用程序清单，每个应用程序用它的名称和它的版本号来识别。
表 2 应用程序清单
注 1：AppliConfMIB DEFINITIONS:: =BEGIN
注 2：以下列出的定义还没有用实际的 MIB 编译器检测过。
ARINC (xxx)OBJECT IDENTIFIER
::={ ???????? } -- the root location
is [TBD] a656 OBJECT IDENTIFIER
::={ ARINC (xxx)1 }
附录 G 提供了 SNMP 用来访问FMC 和CMU 变量的 MIB 定义。应用配置表定义：
appliConfTable OBJECT-TYPE
SYNTAX SEQUENCE OF AppliConfEntry
ACCESS not accessible
STATUS mandatory
DESCRIPTION
“A list of all applications available in the current system configuration”
::={ a656 1 }
appliConfEntry OBJECT-TYPE SYNTAX AppliConfEntry ACCESS not accessible
STATUS mandatory DESCRIPTION
“An application configuration description” INDEX { applicationName }
::={ appliConfTable 1 }
AppliConfEntry :: = SEQUENCE {
applicationName
DISPLAY STRING , applicationVersion
INTEGER }
END
6.6.3 特殊陷阱定义
AppliConfMIB DEFINITIONS :: =BEGIN
-- definition of specific trap issued by CFIB
ARINC (xxx)SNMPTrap OBJECT IDENTIFIER
::={ a656 1 }
cFIBStatus OBJECT IDENTIFIER
::={ ARINC (xxx)SNMPTrap 1}
ableToComply OBJECT IDENTIFIER ::={ cFIBStatus 1}
unableToComply OBJECT IDENTIFIER ::={ cFIBStatus 2}
unableToDecode OBJECT IDENTIFIER ::={ cFIBStatus 3}
notReady OBJECT IDENTIFIER
::={ cFIBStatus 4}
accepted OBJECT IDENTIFIER
::={ cFIBStatus 5}
erased OBJECT IDENTIFIER
::={ cFIBStatus 6}
modified OBJECT IDENTIFIER
::={ cFIBStatus 7}
partialLoad OBJECT IDENTIFIER ::={ cFIBStatus 8}
noLongerAbleToComply OBJECT IDENTIFIER ::={ cFIBStatus 9}
reset OBJECT IDENTIFIER
::={ cFIBStatus 10}
unexpectedData OBJECT IDENTIFIER
::={ cFIBStatus 11}
eventOccurred OBJECT IDENTIFIER
::={ cFIBStatus 12}
periodElapsed OBJECT IDENTIFIER
::={ cFIBStatus 13} END
7 CMU/FMU 信息中介(CFIB)
7.1 概述
CMU/FMC 信息中介应用程序(CFIB)的目的是为FMC 和 CMU 间访问信息提供服务。
CFIB 提供 “代理-管理器”关联，这样 FMC 和 CMU 都能作为管理器发起一个操作，或作为代理响应这个管理器请求的操作。CFIB 支持在两个同等或多个同等应用程序之间同时进行多个会话。
为了重用，CFIB 依赖于由ARINC 664 规范定义的几个标准通信协议，所有这些协议之间的关系如下：
—— CFIB 本身作为一个应用程序负责 FM 和 CMU 的参数交换，这些参数以后称为“CFIB 变量”，并且存贮在专门的管理信息库(MIB)中。在 FMC 一边，FM MIB 在 FM 应用程序和 FM CFIB之间共享;在 CMU 一边，CMU MIB 在一个 ATC 终端系统应用程序和 CMU CFIB 之间共享。
—— SNMP 负责两个 CFIB 应用程序之间的通信。(在 OSI 术语中，SNMP 可被命名为一个应用服务单元(ASE));
CFIB 既可作为一个代理或一个管理器工作，所以 CFIB 同时实现和使用 SNMP 代理和管理器。
—— 传输层可根据实现对象进行不同的定义：
UDP 是 IETF 首选的传输层，它应该用于与 ARINC 664 规范只要求无连接通信兼容的实现中。可在点到点的实现中采用简单以太网 MAC(也就是一个无效传输/网络)层。这个协议配置应该只用在一个特定时间一个终端系统作为 SNMP 代理而另一个作为 SNMP 管理器的情况下采用。
附录 D 的图 D. 1 显示了在 FMC 和CMU 之间这些不同协议的关系。
所有这些在 CFIB 变量上定义的功能都得到在 MIB 中定义的数据结构的支持。由 SNMP 提供的服务限于传输 CFIB 之间的请求和响应消息。
注：当前，SNMP 版本 1 规定只提供信息中介应用程序之间的通信。因为它限于预定义和固定类型的受控对象，所以 SNMP 很难处理动态变化参数集(如飞行计划或故障报告)。对于这种情形， SNMP 可用来发起采用 TFTP 的数据传递，但是这种功能要在以后由 SNMP 新版本提供。
7.2 CFIB 服务定义
7.2.1 概述
CFIB 依靠下面的 SNMP 访问其同等 CFIB 应用程序中的数据。
CFIB 运作方式如下：
—— 对 CFIB 变量上直接操作位于同等 CFIB 应用程序内;
—— 基于契约操作，允许实时定义对 CFIB 变量的操作。
当作为代理的某一个同等 CFIB 请求一个主动提供的操作(例如复位)时，采用由 SNMP 提供的陷阱服务。
7.2.2 直接操作
直接操作(命令)，其操作是：
—— 找回 CFIB 变量，也就是管理器从代理存储器读取数据;
—— 加载 CFIB 变量，也就是管理器向代理存储器写入数据。
直接操作由“取得(get)”和“设置(set)”这样的基本 SNMP 服务提供。
注：这些服务由 get-request 和 set-request SNMPPDU 支持。
7.2.3 契约操作
基于契约的操作是：
—— 周期发送 CFIB 变量，也就是管理器想要周期性接收数据;
—— 事件发送 CFIB 变量，也就是当特定事件发生时，数据从代理发送到管理器;
—— 确认 CFIB 变量，也就是管理器想要代理检查数据集。
基于契约的操作用表格的手段来控制，在表中指示了契约发起者 CFIB 想要同等 CFIB 执行的操作类型。
附录 F 的表 6-4 给出了在 AEEC 根下的 a656 节点的图示，这个 a656 组由几个数据组构成：
—— 一组数据定义名为“appliConfTable”的表格。这个表格维护了在一个系统中所有可用的应用程序的状态，它用于自动应用程序发现过程;
—— 两组数据定义名为“cFIBpartialTable ” 和“cFIBTable”表格，维护分配给 CFIB 的当前契约的定义;
—— 一组数据定义集中了 “fmGroup”名下所有 FM 变量的表格;
—— 一组数据定义集中了 “cmuGroup”名下所有 CMU 变量的表格;
—— 有全部和部分两种运作模式。部分模式允许开发商预加载一些操作并通过调用它们的标识符来触发它们。对于全部模式，开发商定义在运行时要执行的所有操作。
在附录 H 中给出了 AEEC 根的 ASN .1 定义，附录 F 的表 F.3 和 F.4 显示了 AEEC MIB 的树形图。
7.3 FMC/CMU MIB 定义
7.3.1 应用配置表
包含所有系统支持的应用程序清单，每个应用程序用其名称和版本号来识别。
表 2 显示了输入一些记录后的典型的 AppliConfTable。
7.3.2 全部格式操作表
7.3.2.1 概述
契约消息可以是全部模式或部分模式。在全部模式中， 管理器明确规定动作、触发器和变量; 在部分模式中，管理器通过使用一个索引隐含了对动作、触发器和变量的规定。两种契约消息模式可以同时得到支持。
注：在一个给定的实现中，系统综合者要确定是支持一种还是两种消息模式。
名为“cFIBTable”的全部模式表是向CFIB 请求并由这个 CFIB 维护的一个操作清单，它最多可有32 个记录输入。它与一个名为“cFIBNextEntry ” 的指针关联，这个指针用于指示下一个可用的记录输入。CFIB 管理器使用这个指针在代理的 cFIBTable 中写入一个新的契约。
代理 CFIB 控制这个“cFIBNextEntry”指针，由代理返回一个“NULL”值意味着没有更多的契约占位符可用。
注 1：如果请求一个新的契约，SNMP 版本 1 代理不见得能产生一个新的“概念行”。
注 2：对于实现需求来说，静态动作表和指向下一个有用记录的指针的这个提议机制是比较安全的方法。RFC 1212论述了动态行的产生，SNMP 剩下的作用是执行的决策，此外会产生一个互作用问题。这静态动作表和下个可用记录指针的提议机制可以降低风险，提供了一个可以避免互作用问题的较安全的实现方法。
在每个 cFIBEntry 中包含的信息有：
“entryIndex”：用于识别每个记录输入的索引;
“contractID”：契约的标识符;
“soutceID”：CFIB 发起者的地址;
“action”：动作的标识符;
“trigger”：动作的触发器。
7.3.2.2 记录索引
entryIndex 是一个序列递增的数字。
7.3.2.3 契约标识符
契约标识是这个契约的发起者给定的一个数字，用来维护与这个给定契约相关的动作序列。
7.3.2.4 源识别符
采用契约的 CFIB 发起者的 IP 地址。在点到点接口中，使用IP 广播地址。
7.3.2.5 动作
能够执行的动作是：
—— 发送周期数据(periodicRequest);
—— 发送事件性数据(evenRequest);
—— 接收并确认数据(validate);
—— 加载预先用 contractID 确认了的变量(load);
—— 取消契约(cancelRequest)。
7.3.2.6 触发器
7.3.2.6.1 概述
触发器及其类型有：
attime, Time
atposition Position
atspeed Speed,
ataltitude Altitude,
tANPgreaterRNP NULL,
waypointchange Waypointchange,
crosslatitude Latitude,
crosslongitude Longitude,
atdistfrom DistancePosition,
abeamof Position,
vertratechange Verticalrate,
departaltrange AltitudeAltitude,
latdevchange Lateraldeviation,
flightcomplete NULL,
out NULL,
off NULL,
on NULL,
in NULL,
commlost NULL,
commavail NULL,
subnetstatuschange NULL,
atsmessage NULL,
aocmessage NULL,
7.3.2.6.2 与时间相关事件
与时间相关的事件定义：
PERIOD ELAPSED
AT TIME：当服务器的系统时间与该触发器参数中规定的时间匹配时。
7.3.2.6.3 FMC 相关事件
FMC 相关事件如下：
—— AT POSITION：当飞机位置与触发器参数中规定的位置匹配(相差在 0.01 度内)时;
—— AT ALTITUDE：当飞机高度与触发器参数中规定的高度匹配时;
—— AT SPEED：当飞机速度与触发器参数中规定的速度匹配时;
—— ANPRNP：当导航仪的 ANP 超过飞机的 RNP 时;
—— WAYPOINT CHANGE：当航路点的改变类型是《next》，则下一个航路点是按顺序交替时;当航路点的改变类型是《specific》，且飞机按照触发器参数规定的位置交替时;当航路点改变的类型是《continuous》，且在飞行计划中定义的任一航路点上(例如不是浮动点)已经有过改变时，这包括了航路点交替，插入航路点和删除航路点。
—— CROSS LATTITUDE：当飞机达到了触发器参数中规定的纬度边界时;
—— CROSS LONGITUDE：当飞机达到了触发器参数中规定的经度边界时;
—— AT DISTANCE FROM POSITION：当飞机距指定位置达到了触发器参数中规定的距离(DTG)
(相差在 0.01 度内)时;
—— PASSING ABEAM OF POSITION：当飞机与在触发器参数中规定的位置成直角经过时;
—— VERTICAL RATE CHANGE：如果在触发器参数中规定的垂直速率是正的，而飞机的爬升速率超过了这个垂直速率，或者在触发器参数中规定的垂直速率为负，当飞机的下降速率超过了这个垂直速率时;
—— DEPART ALTITUDE RANGE：当飞机通过了在触发器参数中规定的高度的最高限度或高度的最低限度，服务器用气压高度来进行比较;
—— LATERAL DEVIATION CHANGE：当飞机的横向误差超过了在触发器参数中规定的横向偏离极限时;
—— FLIGHT COMPLETION：当系统综合者定义的服务器的飞行完成条件被满足时。 7.3.2.6.4 CMU 相关事件
CMU 相关事件如下：
这些事件是当通信管理单元作为 CFIB 代理时一般适用的：
—— OUT：当飞机离开了大门，转出了《IN》状态， 通常是当所有飞机门都关闭并且松开停机制动时发生。
—— OFF：当飞机起飞并转出了《OUT》状态时，通常当起落装置伸出时发生。
—— ON：当飞机已着陆并转出了《OFF》状态时，通常当起落装置收起时发生。
—— IN：当飞机到达大门并转出了《ON》状态，通常飞机的门打开或停机制动设置好时发生。
—— COMM LOST：当最后的空-地子网链路(VHF、HFDL 和 SATCOM)不能使用并且 CMU 进入《NO COM》状态时。
—— COMM AVAIL：当至少一个空-地子网链路(VHF、HFDL 和 STACOM)变为可用并且 CMU离开《NO COM》状态时。
—— SUBNET STATUS CHANGE：当任一空-地子网络状态从可用变为不可用或从不可用变为可用时。
—— ATS MSG：当 CMU 接收到要处理的空中交通服务消息时。
—— AOC MSG：当由 CMU 接收要处理的航线操作控制消息时。
7.3.2.7 CFIB 表
一般的 CFIB 表(cFIBTable)格式见图 3：
图 3 cFIBTable 实例
注 1：一旦契约停止(也就是执行了请求动作后)，cFIBTable 和 cFIBNextEntry 指针就更新;
注 2：“加载”动作不应包含触发器;
注 3：“cancelrequest”动作不应含有任何其他参数。
7.3.3 部分模式运行表
部分模式运行表提供了一种在请求动作时可以减少发送的数据量的手段。这个表格最多可有 32 个记录输入，与定位下个可用记录的指针相关联。CFIB 管理器使用这个指针在代理的 cFIBpartiaTalbe 中写入一个新协议。
代理 CFIB 维护这个名为“cFIBpartialNextEntry”的指针。如果代理返回一个“NULL”值，意思是没有契约代理可用，这个当前动作的清单由 cFIBpartialTable 中的 CFIB 代理维护。
一个可最多可有 32 个记录的专有全部模式动作表被预先加载到服务器，每个记录由名为“partialEntryIndex”的索引指派。
在每个 cFIBpartialEntry 中的包含的信息是：
—— “partialEntryIndex”：用于查找可用记录的索引;
—— “partialCONtractID”契约标识符;
—— “partialIndex”：引用预先加载表的索引;
—— “inputData”：发送给变量的输入数据，这些数据以所有权协定的八位组字串给出，可采用加密来传递这些值。
通用的 CFIB 表(cFIBpartialTable)的格式见图 4：
图 4 cFIBpartialTable 的实例
一旦契约停止，这个 CFIBpartialTable 和 cFIBpartialNextEntry 就被更新。
7.3.4 FM 组和 CMU 组 CFIB 变量表
FM 组和CMU 组有同样的表格结构。
这些 CFIB 变量通过编号来识别，这些 CFIB 变量和它们的 variableID 编号的清单在附录 I 中给出。对于每个 CFIB 变量，contractID 的标示和 CFIB 变量的值一样。
在 Fm CFIB 变量表的每个记录输入中所包含的信息是：
—— “fmVariableID”：FM CFIB 变量的标识符;
—— “fmContracRef”：用于这个变量的当前契约 ID 的编号;
—— “fmVariableValue”：变量的值;
—— 在 CMU CFIB 变量表的每个记录输入中所包含的信息是：
—— “cmuVariableID”：CMU CFIB 变量的标识符;
—— “cmuContractRef”：用于这个变量的当前契约 ID 的编号;
—— “cmuVariableValue”：变量的值。
一个通用的 CFIB 变量表(FM CFIB 变量表)的格式见图 5：
图 5 Fm CFIB 变量表的实例
根据 RTCA/DO-219，所有 CFIB 变量可以有不同的类型，而且这些类型只与CFIB 应用是相关的，所以所有的 CFIB 变量按照 ASN. 1 语法编码为纯二进制(也就是八位组字串)。
这个 CFIB 应用程序负责契约引用的解释，为了做到这一点，CFIB 代理从 cFIBTable 获得指令。当没有激活的契约或一个契约停止时，这个契约引用收到 NULL 值。
7.4 CMU-FMS 信息中介(CFIB)程序
7.4.1 概述
本条描述 SNMP 消息如何执行 CFIB 操作，CFIB 成员有以下基本的通信方式：
—— 一个请求-一个响应;
—— 主动提供的响应;
—— 一个请求-多个周期响应;
—— 一个请求-多个非周期响应。
7.4.2 初始化
CFIB 管理器用 CFIB 代理初始化通信。CFIB 管理器首先发送“reset ”陷阱来通报代理消除所有契约，确保在新的请求发送之前在代理中的所有资源都是可用的。
7.4.3 信息传递
7.4.3.1 契约请求消息
CFIB 管理器可以请求 CFIB 代理一次地、周期地或当定义的事件在代理中发生时发送一个专用的数据清单，管理器也可以请求要确认并加载到代理中的数据。这些交易类型称为“契约”。
当管理器需要来自代理的“契约的”消息集时，它首先通过读取 cFIBNexEntry 值来问询在cFIBTable 中的下一个可用的位置，然后发送 set-request PDU 到 cFIBTable，其字段是用变量捆绑的清单完成的。
resp (cFIBNextEntry =k)
这个符号的意思是第一个取回的 cFIBNextENtry 给的值是“k”。
CFIB 继续发送下列 PDU：
set (contractID.k =a,
sourceID.k =b,
action.k =c,
trigger.k =d,
fmContractRef.n =a,
fmVariableValue.n =f, fmContractRef.m =a,
fmVariableValue.m =f)
这个符号意思是管理器已把值 a、b、c、d 写入契约表 cFIBTable 的第 k 个位置，并且把 a、f 写入了 CFIB 变量契约的引用和数值的第 n 和第 m 位置。(假设 n 和 m 是我们想写入的 CFIB 变量的编号)。
如果正确完成了操作，代理送回一个 get-response PDU，如果产生了错误，代理返回 trap-PDU，这个陷阱的原因在变量捆绑的清单中给出了。以上可以写为：
resp (error-status=0
contractID.k =a ,
sourceID.k =b ,
action.k =c ,
trigger.k =d ,
fmContractRef.n =a,
fmVariableValue.n =f fmContractRef.m =a,
fmVariableValue.m =f)
或
trap (enterprise =ARINC (xxx)
generic-trap =entreprisesSpecific time-stamp =t
contractID.k =a
cFIBStatus.0=unableToComply)
附录 D 的图 D.4 举例说明了 PDU 交换来完成一个“契约请求”消息。
7.4.3.2 数据取回
当管理器需要一个数据集时，将发送一个 get-request-PDU 给代理。在接收这个 get-resquest-PDU 后，接收协议实体向所接收到的消息的发起者发送 get-response-PDU。对于在接收消息的变量捆绑字段中命名的每个目标，其 get-response-PDU 相应的内容表示这个变量的名称和数值。
get-response-PDU 的 error-status 字段的值是 noError，它的 error-index 字段的值是 0， 其GetResponse-PDU 的 request-id 字段的值是接收到的消息。服务器将由于 GetResponse-PDU 对这样的问题进行回答。
在接收这个 get-response-PDU 后，该接收协议实体向 SNMP 应用实体呈现其内容。附录 D 的图 D.4举例说明了 PDU 交换到完成一个单一的请求消息。
7.4.3.3 周期数据传输
当管理者需要来自代理的一个周期数据集时，它发送给 cFIBTable 一个用下列值组成字段的set-request PDU：
—— ContractID 是用于该动作的契约的值，是参照 CFIB 变量写进契约;
—— “action”取值“periodicRequest”;
—— “trigger”取用一个整数以秒来表示其周期的值“period”;
—— 变量捆绑清单其余的部分是 CFIB 变量集，是必须每个“period”(秒)发送。
然后代理周期地发送具有下列值的 trap-PDU 给管理器：
—— ContractID 是预先设置的契约的值;
—— “status”是设置给“periodElapsed”的值;
—— Variable-bindings 是周期变量清单。
附录 D 的图 D.6 举例说明了如何交换 PDU 完成一个“Periodic Request”消息的过程。
7.4.3.4 事件请求
当管理器想要知道在代理中指定事件何时发生， 或当这个事件发生时想要一个数据集， 它向cFIBTable 发送一个用下列值组成字段的契约请求消息：
—— CFIBEntry 是一个目标标识符，它指向一个 CFIBTable 的记录输入;
—— ContractID 是这个动作要采用的契约的值;
—— “action”取值“requestdata”;
—— “trigger”取对应于这个用位置作为值的事件的值(例如 “waypointchange”)。
下面则是当这个事件发生时要发送的变量清单。
当事件发生时，代理发送一个有下列字段的 trap-PDU 给管理器：
—— ContractID 是这个契约预先设置的值;
—— “status”取值 eventOccured;
—— Variable-binding 是变量清单;
如果这个变量清单是空的，则在该 trap-pdu 中没有变量捆绑清单。
附录 D 的图 D.7 举例说明了如何交换 PDU 完成一个“ON Event”发送消息的过程。
7.4.3.5 确认请求
当管理器需要在加载前确认数据集，它产生一个由下列值组成的契约：
—— ContractID 是这个动作要采用的契约的值;
—— “action”取值“validate”;
—— Variable-bindings 是要确认的变量清单。
正常情况，代理发送一个无错误指示的响应。如果确认失败， 该代理向管理器送回一个设置失败原因的状态值的陷阱和拒绝 CFIB 变量的清单。
附录 D 的图 D.8 举例说明了如何交换 PDU 到完成一个“Validate Request”消息的过程。
7.4.3.6 加载请求
当客户需要加载一个先前确认了的数据集，它发送一个引用先前确认契约的 loadRequest 消息。 ContractID 是先前设置的契约的值，动作取值“load”。
附录 D 的图 D.9 举例说明了如何交换 PDU 到完成一个“Load Request”消息的过程。
正常情况，代理发送一个无错误指示的响应。
如果确认失败，该代理向管理器送回一个设置失败原因的状态值的陷阱以及拒绝CFIB 变量的清单。
7.4.3.7 取消请求
当客户不再要求一个有效的契约时，它向服务器发送一个有下列值的 set-request-pdu：
—— ContractID 是先前设置动作的契约的值取值 “cancelRequest”。
附录 D 的图 D. 10 举例说明了如何交换 PDU 到完成一个“Cancel Request”消息的过程。
8 协议配置
8.1 概述
本节将对本标准接口的四个候选结构在每一层的特殊需求做出定义，这四个结构是 FMC 作为终端系统(参照 8.2 节)、CMU 作为单个终端系统(参照 8.3 节)、远程堆栈(参照 8.4 节)和综合结构(参照 8.5节)等。本标准直接考虑了 ATS 应用程序的分区。如果要使用混合系统(一些应用程序驻留在 FMC 而另一些应用程序驻留在 CMU)，则在 FMC 和 CMU 中都必须实现每个适用结构的需求。
对于 CMU 作为单个终端系统，需要一个应用网关，这个网关是 CMU 内部功能，不在本接口标准中定义。
8.2 FMC 作为终端系统
8.2.1 概述
FMC 作为终端系统与本标准中论述的其他可选结构不同，它这个结构不要求用UDP 或 SNMP，但可实现所有这些功能。在这个结构中， FMC 作为终端系统，CMU 功能作为一个路由器，应用程序仍可以驻留在 CMU 中。
8.2.2 ACARS 环境
8.2.2.1 概述
根据 ARINC 622 规范，作为 ACARS 环境中的终端系统的 FMC 可以提供 ATS 应用程序和协议。在这种情况下，FMC 包含了整个应用处理、终端到终端通信的 ARINC 622 规范 ACP 协议和 ACARS 619路由协议。
8.2.2.2 物理层
作为 ACARS 终端系统的 FMC 应该使用HB 6096 规范低速总线与 ACARS 管理单元(ACARS MU)通信。
8.2.2.3 数据链路层
作为 ACARS 终端系统的 FMC 应该使用HB 6096 威廉斯堡版本 3 协议与 ACARSMU 的通信。
8.2.2.4 网络层
作为 ACARS 终端系统的 FMC 应该使用 ARINC 619 规范协议作为到 ATS 终端系统的空/地消息路由。
8.2.2.5 传输层
作为 ACARS 终端系统的 FMC 应该使用ARINC 622 规范 ACP 进行寻址、bit-to-hex 转换和 ATS 应用程序消息的终端到终端 CRC。
8.2.2.6 应用层
作为 ACARS 终端系统的 FMC 应该支持以下 ATS 应用程序的要求：
—— RTCA/DO-212“ADS 的最低操作性能标准(MOPS) ”;
—— RTCA/DO-219“ATC 控制员驾驶员数据链路通信(CPDLC)的最低操作性能标准(MOPS) ”;
—— ARINC 622 规范“基于 ACARS 空-地网络的 ATS 数据链路应用程序”-用于 ATS 设备通告。
8.2.3 ATN 环境
8.2.3.1 物理层
作为 ATN 终端系统的 FMC 需要一个能够适应系统综合者确定的 ATN 通信量的物理层。一般来说，可以用 HB 6096 高速总线连接 CMU 或机上路由器。
8.2.3.2 数据链路层
作为 ATN 终端系统的 FMC 需要一个能够通过二进制信息的数据链路层，系统综合者要确保所选择的数据链路层能够适应通过此接口的预期的 ATN 通信量。
一般地，以高速运行的 HB 6096 规范应该能够适应 ATN 的通信量。由于要定义并支持新数据链路层协议，所以作为 ATN 终端系统的 FMC 应该能移植使用这些新的数据链路层协议。
这个数据链路层用来与 CMU 或机上路由器通信。
8.2.3.3 网络层
作为 ATN 的终端系统，FMC 参照采用 ISO/IEC 8473 网络层协议的终端系统规定，以及由 CNS/STM
-1 数据包
