ARINC665-4標準深度解析及應用

0 引言

航空航電系統從早期僅實現簡單數據交換到如今構建起復雜精密的綜合航電系統，機載設備及其軟件的數量呈指數級增長，復雜度更是大幅提升，這就使得航空電子設備間的數據交互與協同工作變得極為關鍵，任何兼容性或互操作性的缺失都可能引發嚴重的安全隱患。ARINC665-4標準作為規范航空電子設備基于ARINC664網絡交互數據格式和傳輸機制的核心準則，旨在確保不同供應商生產的設備能夠無縫對接，實現高效的數據交互。該標準與國際航空適航法規深度融合，有力保障了航空電子系統在全球范圍內的通用性與合規性。深入剖析ARINC665-4標準的結構框架、核心條款，探究其在民用航空領域的實際應用，對于進一步推動航空電子系統的技術進步，提升航空業的整體安全性與可靠性具有重要意義。

1 ARINC665-4標準背景

在現代航電系統中，機載軟件通常通過數據加載系統被上傳到機載計算機上，有時也通過數據加載系統從機載計算機下載軟件部件或數據。這就意味著機載軟件與數據加載系統之間必須具備很強的兼容性和互操作性。ARINC665-4標準的全稱為可加載軟件標準（LoadableSoftwareStandards），旨在規范航空電子設備之間基于ARINC664網絡的交互數據格式和傳輸機制，確保不同供應商生產的設備能夠實現數據的無縫交互，提高航空電子系統的集成度和互操作性。

2 ARINC665-4標準內容剖析

2.1 結構框架

ARINC665-4標準（后文簡稱“標準\"主要由可加載軟件部件（LoadableSoftwareParts，LSPs）定義、介質集部件（MediaSetParts，MSPs）定義、循環余校驗碼（CyclicRedundancyCodes，CRC）定義、完整性檢查方法定義等部分構成。其中LSPs定義部分主要包括頭文件格式定義、可選文件定義、數據文件和支持文件的可選項定義等；MSPs定義部分包括介質集內容和結構定義、介質集成員構成及限制等；CRC定義部分包括CRC的計算原理及參數；完整性檢查方法定義部分包括完整性檢查方法的枚舉及對應類型定義。

2.2 核心條款解讀

由于標準明確數據文件和支持文件的內容和格式由各機載軟件供應商自行定義，標準并不進行限制，因此后文只對標準中的頭文件格式定義、可選文件定義、數據文件和支持文件的可選項定義和MSPs定義進行重點剖析。同時，標準在定義上述各文件內容和格式時，使用了一些前置的非常重要但容易被忽視的約定，后文也將進行強調和闡述。

2.2.1 標準中的重要約定

標準中各文件的數據結構由標準的十六進制整數和ASCI字符表示。一個數據字節（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字不能包含在計數中。

2.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應分配唯一的Load TypeDescription。對于將被加載到某特定目標硬件上的每一種LSP類型，都應具備唯一的LoadTypeID。LoadTypeID用于方便地識別軟件部件類型，這使得目標硬件能夠識別待加載項應替換哪個加載項以及應將其放置于內存中的哪個位置。Load TypeDescription則用于描述加載項或其功能（例如\"EECOperationalSoftware”“FMS NavigationDataBase\"等）。

對于帶有位置信息的目標硬件碼（TargetHWIDwithPositions），需要特別注意的是TargetHWIDwithPositions中的硬件碼必須已經在TargetHWID列表中被定義過。其中位置（Position）字段由系統集成商自定義，可以是“L”“R\"等表明位置的字符串。

2.2.3 數據文件和支持文件的可選項

為了節省介質空間、減少加載時間或保密，數據文件和支持文件可以被壓縮或加密，但頭文件不能被壓縮或加密，因為加載器和其他工具均需直接從頭文件中獲取信息。如果使用文件壓縮或加密，頭文件創建者應考慮在UserDefinedData字段中嵌入壓縮前文件的CRC值，這樣目標硬件就可以使用該CRC值檢查解壓或解密后的文件是否完整有效，同時要求目標硬件在將文件加載到程序存儲區前必須對文件進行解壓或解密并進行完整性校驗。另外值得注意的是，頭文件中所有CRC字段和CheckValue字段的計算均應基于壓縮或加密后的文件內容。

2.2.4 可選文件定義

航空公司希望能夠定義一個批處理類型的文件，維護人員只需為加載器選擇一個批處理文件，就能定義一系列加載到一個或多個目標硬件位置的LSP。標準中的批處理文件部件（BatchFileParts，BFPs）使得維護人員不必一一選擇所有需加載到每個目標硬件位置的LSPs。BFP基于加載列表塊（Load-ListBlock）概念，即一個Load-ListBlock定義屬于一個目標硬件位置的所有LSPs，一個BFP可包含多個Load-ListBlock。BFPs的文件名需以MMM碼開頭，后綴名必須為“LUB”。BFPs的PN必須在供應商范圍內所有LSPs和BFPs的PN中具有唯一性。

2.2.5 介質集定義

介質集是對LSPs的進一步整合和管理方法。介質集有助于對LSPs進行受控分發，從而確保安全交付該介質上所含的LSPs和批處理部件，確保收到的部分與發送的部分完全一致。介質集本身也被視為部件進行交付。如此，物理介質可以作為發送介質的精確副本重新創建，從而保持介質上所含LSPs的完整性。

一個MSP由 個介質項構成，這些介質項應該屬于同一種類型（例如所有3.5\"磁盤、所有PCCard等）。每個介質項都應包含一個完整的LSPs清單（LOADS.LUM文件、一個完整的所有文件清單（FILES.LUM）文件和一個完整的BFP清單（BATCHES.LUM）文件。

介質集是一種可選結構，當創建者需要介質集時，通常應該按照下面的順序創建：首先創建數據文件，如有需要也可以創建支持文件；其次創建頭文件，由數據文件、支持文件和頭文件共同構成一個LSP；第三創建介質項，每個介質項可包含多個LSPs；最后創建MSP，一個MSP可以至多包含255個介質項。

3 ARINC665-4標準的應用

某民用航空軟件供應商在創建和管理機載軟件時使用了ARINC665-4標準，所有機載軟件依據標準打包、發布和升級。由于該供應商開發的機載軟件需運行在現代化綜合模塊化航電系統平臺之上，機載軟件數量大、種類多、功能復雜。實踐證明，采用ARINC665-4標準組織和管理機載軟件，大大提高了機載軟件的可擴展性、可移植性和可管理性，同時，滿足了機載軟件的高可靠性和高安全性需求。

綜合模塊化航電系統平臺通常由多個通用處理器、遠程交換機和遠程數據轉換單元等設備構成，各設備均需相應的多個機載軟件來實現功能。因此機載軟件以設備類型分類打包，創建了多個MSPs，每個MSP中包含同一類型硬件的機載軟件。比如，對于若干個通用處理器創建一個MSP，該MSP中包含若干介質項，每個介質項對應一個通用處理器，每個介質項中包含該通用處理器上需要加載的若干LSPs，每個LSP包含一個或多個機載軟件或數據，具體如圖1所示。圖中DFs指數據文件，SFs指支持文件。遠程交換機和遠程數據轉換單元及其他設備均按照以上方式創建各自的MSPs。

4 結束語

從ARINC665-4標準自身架構來看，其精心設計的結構框架和細致入微的核心條款，為航空電子設備之間的數據交互提供了精確且嚴謹的規范。無論是LSPs和MSPs的定義，還是文件格式、重要約定等方面的詳細規定，都確保了不同供應商設備之間的兼容性和互操作性，這對于構建復雜而可靠的航空電子系統至關重要。在實際應用中，由民用航空軟件供應商的實踐成果可知，ARINC665-4標準切實有效地提升了機載軟件的可擴展性、可移植性和可管理性，有力保障了航空電子系統的高可靠性和高安全性需求。這不僅為航空公司降低了運營風險，也為乘客的安全出行提供了堅實保障。展望未來，隨著航空技術的持續創新，如新型飛行器設計、更先進的航電系統研發以及航空網絡通信技術的升級等，ARINC665-4標準有望在應對新挑戰的過程中不斷演進。深入研究和廣泛推廣該標準的應用，對于促進全球航空業的互聯互通、提升航空運輸的整體質量和效率具有深遠意義，值得業內持續關注與深入探索。

[參考文獻]

[1] ARINC.Loadable Software Standards：ARINC 665-4 [S]，2016.

[2]楊軍祥，田澤，湛文韜，等.新一代分布式IMA核心系統技術研究［J].微電子學與計算機，2019，36（12）：36-41.