ARINC 665-4标准深度解析及应用

围绕ARINC665-4标准展开深入探讨。首先阐述其背景，ARINC665-4标准旨在规范航空电子设备交互数据格式与传输机制，提升系统集成度、互操作性、可靠性及安全性。接着分析其意义，统一的格式使供应商能使用通用流程与工具，确保不同系统间兼容性。随后详细剖析标准内容，涵盖结构框架，包括LSPs、MSPs、CRC及完整性检查方法定义；核心条款解读，如重要约定、头文件格式定义、数据与支持文件可选项、可选文件定义、介质集定义等。最后介绍其应用，某民用航空软件供应商采用该标准管理机载软件，提高了软件的可扩展性、可移植性与可管理性，保证了高可靠性与安全性。一、引言航空航电系统从早期仅实现简单数据交换到如今构建起复杂精密的综合航电系统，机载设备及其软件的数量呈指数级增长，复杂度更是大幅提升，这就使得航空电子设备间的数据交互与协同工作变得极为关键，任何兼容性或互操作性的缺失都可能引发严重的安全隐患。ARINC665-4标准作为规范航空电子设备基于ARINC664网络交互数据格式和传输机制的核心准则，旨在确保不同供应商生产的设备能够无缝对接，实现高效的数据交互。该标准与国际航空适航法规深度融合，有力保障了航空电子系统在全球范围内的通用性与合规性。深入剖析ARINC665-4标准的结构框架、核心条款，探究其在民用航空领域的实际应用，对于进一步推动航空电子系统的技术进步，提升航空业的整体安全性与可靠性具有重要意义。二、ARINC665-4标准背景在现代航电系统中，机载软件通常通过数据加载系统被上传到机载计算机上，有时也通过数据加载系统从机载计算机下载软件部件或数据。这就意味着机载软件与数据加载系统之间必须具备很强的兼容性和互操作性。ARINC665-4标准的全称为可加载软件标准（LoadableSoftwareStandards），旨在规范航空电子设备之间基于ARINC664网络的交互数据格式和传输机制，确保不同供应商生产的设备能够实现数据的无缝交互，提高航空电子系统的集成度和互操作性。三、ARINC665-4标准内容剖析3.1

结构框架ARINC665-4标准（后文简称“标准”）主要由可加载软件部件（LoadableSoftwareParts，LSPs）定义、介质集部件（MediaSetParts，MSPs）定义、循环冗余校验码（CyclicRedundancyCodes，CRC）定义、完整性检查方法定义等部分构成。其中LSPs定义部分主要包括头文件格式定义、可选文件定义、数据文件和支持文件的可选项定义等；MSPs定义部分包括介质集内容和结构定义、介质集成员构成及限制等；CRC定义部分包括CRC的计算原理及参数；完整性检查方法定义部分包括完整性检查方法的枚举及对应类型定义。3.2

核心条款解读由于标准明确数据文件和支持文件的内容和格式由各机载软件供应商自行定义，标准并不进行限制，因此后文只对标准中的头文件格式定义、可选文件定义、数据文件和支持文件的可选项定义和MSPs定义进行重点剖析。同时，标准在定义上述各文件内容和格式时，使用了一些前置的非常重要但容易被忽视的约定，后文也将进行强调和阐述。3.2.1

标准中的重要约定标准中各文件的数据结构由标准的十六进制整数和ASCII字符表示。一个数据字节（databyte）指的是一个8位的bit串，一个以0xFF的形式表示的databyte，其中每个F代表一个值为（1）的4位bit串，描绘了一个8位值均为（1）的bit串。一个数据字（dataword）指的是一个16位的bit串，一个以0xFFFF形式表示的dataword，其中每个F代表一个值为（1）的4位bit串，描绘了一个16位值均为（1）的bit串。除非另有规定，标准中数据字段应被识别为数字类型，文本字段被标识为ASCII字符串。根据检查值类型（CheckValueType）定义，检查值（CheckValue）字段可以是数字或字符。扩展点（ExpansionPoint）是文件中预定义的位置，这样设计是为了在未来版本的标准中为文件添加新字段，且ExpansionPoint在文件中只作为标记，并不占位。LSPs或MSPs的创建者不应该在ExpansionPoint上插入任何自定义的字段，因为这将导致文件与遵循标准的工具或过程不兼容。指针类型的字段分为绝对指针（AbsolutePointer）和相对指针（RelativePointer）两种。AbsolutePointer是指从文件开头到所指向字段的16bit字的数量。值得特别注意的是，所指向字段的第一个16bit字不应被包含在计数中。例如，根据标准中确切的头文件格式定义，指向加载部件号长度（LoadPNLength）字段的指针应为无符号整数值20，即十六进制数0x0014。而RelativePointer是代表该指针与所指向字段的第一个16bit字之间的16bit字数量。值得特别注意的是，该RelativePointer字段本身需包含在计数中，而所指向字段的第一个16bit字不能包含在计数中。3.2.2

头文件格式定义一个LSP包含一个头文件、一个或多个数据文件，根据需要也可包含一个或多个支持文件[1]。标准明确对数据文件和支持文件的内容和格式不做限定，由各厂商自行定义，但值得注意的是，标准要求数据文件和支持文件的大小必须是8bit的整数倍。对于头文件的文件名，前三个字符必须是其供应商的MMM码，其余字符应保证在所有与该MMM码有关的文件名范围内具有唯一性，且其后缀必须为“.LUH”。标准对数据文件和支持文件的文件名后缀不做限制，但建议数据文件后缀名为“.LUP”，实际工程中也存在不同扩展名格式的数据文件，常见的数据文件扩展名格式有“.BIN”和“.DAT”等[2]。另需注意，后缀名的命名不能与标准3.2.2章节定义的保留扩展名列表中的后缀名相同。每个LSP都应有一个部件号（PartNumber，PN），并且飞机制造商和软件供应商双方就该PN应已达成一致。值得注意的是，标准要求一个LSP中如发生内容变化，哪怕只是1bit位发生变化，都应为该LSP分配一个新的PN。如果为两个LSP分配了相同的PN，那么在LSP的管理上就会有出错的风险。为了保证最大程度的向后兼容性，标准不对LSP的PN取值做限制，但强烈建议采用MMMCC-SSSS-SSSS的格式。其中MMM是分配给每个开发软件的组织的唯一标识符，可由大写字母或数字组成。CC是由PN中除去CC之外的其他字符（例如MMM-SSSS-SSSS）生成的CRC-8校验码。SSSS-SSSS是由软件供应商定义的唯一产品标识符。对于一些长度值类型的字段，其计数范围也常容易被误解，例如加载部件长度（LoadPNLength）字段，其值应为加载部件号（LoadPN）所包含的字符个数，计数不应包含LoadPN字段中末尾处补充的NUL（如适用）。对于加载类型标识（LoadTypeID）和加载类型描述（LoadTypeDescription）字段，二者应一一对应，即每个LoadTypeID应分配唯一的LoadTypeDescription。对于将被加载到某特定目标硬件上的每一种LSP类型，都应具备唯一的LoadTypeID。LoadTypeID用于方便地识别软件部件类型，这使得目标硬件能够识别待加载项应替换哪个加载项以及应将其放置于内存中的哪个位置。LoadTypeDescription则用于描述加载项或其功能（例如“EECOperationalSoftware”“FMSNavigationDataBase”等）。对于带有位置信息的目标硬件码（TargetHWIDwithPositions），需要特别注意的是TargetHWIDwithPositions中的硬件码必须已经在TargetHWID列表中被定义过。其中位置（Position）字段由系统集成商自定义，可以是“L”“R”等表明位置的字符串。3.2.3

数据文件和支持文件的可选项为了节省介质空间、减少加载时间或保密，数据文件和支持文件可以被压缩或加密，但头文件不能被压缩或加密，因为加载器和其他工具均需直接从头文件中获取信息。如果使用文件压缩或加密，头文件创建者应考虑在UserDefinedData字段中嵌入压缩前文件的CRC值，这样目标硬件就可以使用该CRC值检查解压或解密后的文件是否完整有效，同时要求目标硬件在将文件加载到程序存储区前必须对文件进行解压或解密并进行完整性校验。另外值得注意的是，头文件中所有CRC字段和CheckValue字段的计算均应基于压缩或加密后的文件内容。3.2.4

可选文件定义航空公司希望能够定义一个批处理类型的文件，维护人员只需为加载器选择一个批处理文件，就能定义一系列加载到一个或多个目标硬件位置的LSP。标准中的批处理文件部件（BatchFileParts，BFPs）使得维护人员不必一一选择所有需加载到每个目标硬件位置的LSPs。BFP基于加载列表块（Load-ListBlock）概念，即一个Load-ListBlock定义属于一个目标硬件位置的所有LSPs，一个BFP可包含多个Load-ListBlock。BFPs的文件名需以MMM码开头，后缀名必须为“.LUB”。BFPs的PN必须在供应商范围内所有LSPs和BFPs的PN中具有唯一性。3.2.5

介质集定义介质集是对LSPs的进一步整合和管理方法。介质集有助于对LSPs进行受控分发，从而确保安全交付该介质上所含的LSPs和批处理部件，确保收到的部分与发送的部分完全一致。介质集本身也被视为部件进行交付。如此，物理介质可以作为发送介质的精确副本重新创建，从而保持介质上所含LSPs的完整性。一个MSP由1～255个介质项构成，这些介质项应该属于同一种类型（例如所有3.5"磁盘、所有PCCard等）。每个介质项都应包含一个完整的LSPs清单（LOADS.LUM）文件、一个完整的所有文件清单（FILES.LUM）文件和一个完整的BFP清单（BATCHES.LUM）文件。介质集是一种可选结构，当创建者需要介质集时，通常应该按照下面的顺序创建：首先创建数据文件，如有需要也可以创建支持文件；其次创建头文件，由数据文件、支持文件和头文件共同构成一个LSP；第三创建介质项，每个介质项可包含多个LSPs；最后创建MSP，一个MSP可以至多包含255个介质项。四、ARINC665-4标准的应用某民用航空软件供应商在创建和管理机载软件时使用了ARINC665-4标准，所有机载软件依据标准打包、发布和升级。由于该供应商开发的机载软件需运行在现代化综合模块化航电系统平台之上，机载软件数量大、种类多、功能复杂。实践证明，采用ARINC665-4标准组织和管理机载软件，大大提高了机载软件的可扩展性、可移植性和可管理性，同时，满足了机载软件的高可靠性和高安全性需求。综合模块化航电系统平台通常由多个通用处理器、远程交换机和远程数据转换单元等设备构成，各设备均需相应的多个机载软件来实现功能。因此机载软件以设备类型分类打包，创建了多个MSPs，每个MSP中包含同一类型硬件的机载软件。比如，对于若干个通用处理器创建一个MSP，该MSP中包含若干介质项，每个介质项对应一个通用处理器，每个介质项中包含该通用处理器上需要加载的若干LSPs，每个LSP包含一个或多个机载软件或数据，具体如图1所示。图中DFs指数据文件，SFs指支持文件。远程交换机和远程数据转换单元及其他设备均按照以上方式创建各自的MSPs。五、结束语从ARINC665-4标准自身架构来看，其精心设计的结构框架和细致入微的核心条款，为航空电子设备之间的数据交互提供了精确且严谨的规范。无论是LSPs和MSPs的定义，还是文件格式、重要约定等方面的详细规定，都确保了不同供应商设备之间的兼容性和互操作性，这对于构建复杂而可靠的航空电子系统至关重要。在实际应用中