ARINC665-4標(biāo)準(zhǔn)深度解析及應(yīng)用

0 引言

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

1 ARINC665-4標(biāo)準(zhǔn)背景

在現(xiàn)代航電系統(tǒng)中，機載軟件通常通過數(shù)據(jù)加載系統(tǒng)被上傳到機載計算機上，有時也通過數(shù)據(jù)加載系統(tǒng)從機載計算機下載軟件部件或數(shù)據(jù)。這就意味著機載軟件與數(shù)據(jù)加載系統(tǒng)之間必須具備很強的兼容性和互操作性。ARINC665-4標(biāo)準(zhǔn)的全稱為可加載軟件標(biāo)準(zhǔn)（LoadableSoftwareStandards），旨在規(guī)范航空電子設(shè)備之間基于ARINC664網(wǎng)絡(luò)的交互數(shù)據(jù)格式和傳輸機制，確保不同供應(yīng)商生產(chǎn)的設(shè)備能夠?qū)崿F(xiàn)數(shù)據(jù)的無縫交互，提高航空電子系統(tǒng)的集成度和互操作性。

2 ARINC665-4標(biāo)準(zhǔn)內(nèi)容剖析

2.1 結(jié)構(gòu)框架

ARINC665-4標(biāo)準(zhǔn)（后文簡稱“標(biāo)準(zhǔn)\"主要由可加載軟件部件（LoadableSoftwareParts，LSPs）定義、介質(zhì)集部件（MediaSetParts，MSPs）定義、循環(huán)余校驗碼（CyclicRedundancyCodes，CRC）定義、完整性檢查方法定義等部分構(gòu)成。其中LSPs定義部分主要包括頭文件格式定義、可選文件定義、數(shù)據(jù)文件和支持文件的可選項定義等；MSPs定義部分包括介質(zhì)集內(nèi)容和結(jié)構(gòu)定義、介質(zhì)集成員構(gòu)成及限制等；CRC定義部分包括CRC的計算原理及參數(shù)；完整性檢查方法定義部分包括完整性檢查方法的枚舉及對應(yīng)類型定義。

2.2 核心條款解讀

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

2.2.1 標(biāo)準(zhǔn)中的重要約定

標(biāo)準(zhǔn)中各文件的數(shù)據(jù)結(jié)構(gòu)由標(biāo)準(zhǔn)的十六進(jìn)制整數(shù)和ASCI字符表示。一個數(shù)據(jù)字節(jié)（databyte）指的是一個8位的bit串，一個以0xFF的形式表示的databyte，其中每個F代表一個值為（1）的4位bit串，描繪了一個8位值均為（1）的bit串。一個數(shù)據(jù)字（dataword）指的是一個16位的bit串，一個以0xFFFF形式表示的dataword，其中每個F代表一個值為（1）的4位bit串，描繪了一個16位值均為（1）的bit串。

除非另有規(guī)定，標(biāo)準(zhǔn)中數(shù)據(jù)字段應(yīng)被識別為數(shù)字類型，文本字段被標(biāo)識為ASCII字符串。根據(jù)檢查值類型（CheckValueType）定義，檢查值（CheckValue）字段可以是數(shù)字或字符。

擴(kuò)展點（ExpansionPoint）是文件中預(yù)定義的位置，這樣設(shè)計是為了在未來版本的標(biāo)準(zhǔn)中為文件添加新字段，且ExpansionPoint在文件中只作為標(biāo)記，并不占位。LSPs或MSPs的創(chuàng)建者不應(yīng)該在ExpansionPoint上插入任何自定義的字段，因為這將導(dǎo)致文件與遵循標(biāo)準(zhǔn)的工具或過程不兼容。

指針類型的字段分為絕對指針（AbsolutePointer）和相對指針（RelativePointer）兩種。AbsolutePointer是指從文件開頭到所指向字段的16bit字的數(shù)量。值得特別注意的是，所指向字段的第一個16bit字不應(yīng)被包含在計數(shù)中。例如，根據(jù)標(biāo)準(zhǔn)中確切的頭文件格式定義，指向加載部件號長度（LoadPNLength）字段的指針應(yīng)為無符號整數(shù)值20，即十六進(jìn)制數(shù) 0x0014 。而RelativePointer是代表該指針與所指向字段的第一個16bit字之間的16bit字?jǐn)?shù)量。值得特別注意的是，該RelativePointer字段本身需包含在計數(shù)中，而所指向字段的第一個16bit字不能包含在計數(shù)中。

2.2.2頭文件格式定義

一個LSP包含一個頭文件、一個或多個數(shù)據(jù)文件，根據(jù)需要也可包含一個或多個支持文件1。標(biāo)準(zhǔn)明確對數(shù)據(jù)文件和支持文件的內(nèi)容和格式不做限定，由各廠商自行定義，但值得注意的是，標(biāo)準(zhǔn)要求數(shù)據(jù)文件和支持文件的大小必須是8bit的整數(shù)倍。對于頭文件的文件名，前三個字符必須是其供應(yīng)商的MMM碼，其余字符應(yīng)保證在所有與該MMM碼有關(guān)的文件名范圍內(nèi)具有唯一性，且其后綴必須為“.LUH”。標(biāo)準(zhǔn)對數(shù)據(jù)文件和支持文件的文件名后綴不做限制，但建議數(shù)據(jù)文件后綴名為“.LUP”，實際工程中也存在不同擴(kuò)展名格式的數(shù)據(jù)文件，常見的數(shù)據(jù)文件擴(kuò)展名格式有“.BIN\"和“.DAT\"等[2]。另需注意，后綴名的命名不能與標(biāo)準(zhǔn)3.2.2章節(jié)定義的保留擴(kuò)展名列表中的后綴名相同。

每個LSP都應(yīng)有一個部件號（PartNumber，PN），并且飛機制造商和軟件供應(yīng)商雙方就該PN應(yīng)已達(dá)成一致。值得注意的是，標(biāo)準(zhǔn)要求一個LSP中如發(fā)生內(nèi)容變化，哪怕只是1bit位發(fā)生變化，都應(yīng)為該LSP分配一個新的PN。如果為兩個LSP分配了相同的PN，那么在LSP的管理上就會有出錯的風(fēng)險。為了保證最大程度的向后兼容性，標(biāo)準(zhǔn)不對LSP的PN取值做限制，但強烈建議采用MMMCC-SSSS-SSSS的格式。其中MMM是分配給每個開發(fā)軟件的組織的唯一標(biāo)識符，可由大寫字母或數(shù)字組成。CC是由PN中除去CC之外的其他字符（例如MMM-SSSS-SSSS）生成的CRC-8校驗碼。SSSS-SSSS是由軟件供應(yīng)商定義的唯一產(chǎn)品標(biāo)識符。

對于一些長度值類型的字段，其計數(shù)范圍也常容易被誤解，例如加載部件長度（LoadPNLength）字段，其值應(yīng)為加載部件號（LoadPN）所包含的字符個數(shù)，計數(shù)不應(yīng)包含LoadPN字段中末尾處補充的NUL（如適用）。

對于加載類型標(biāo)識（LoadTypeID）和加載類型描述（LoadTypeDescription）字段，二者應(yīng)一一對應(yīng)，即每個LoadTypeID應(yīng)分配唯一的Load TypeDescription。對于將被加載到某特定目標(biāo)硬件上的每一種LSP類型，都應(yīng)具備唯一的LoadTypeID。LoadTypeID用于方便地識別軟件部件類型，這使得目標(biāo)硬件能夠識別待加載項應(yīng)替換哪個加載項以及應(yīng)將其放置于內(nèi)存中的哪個位置。Load TypeDescription則用于描述加載項或其功能（例如\"EECOperationalSoftware”“FMS NavigationDataBase\"等）。

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

2.2.3 數(shù)據(jù)文件和支持文件的可選項

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

2.2.4 可選文件定義

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

2.2.5 介質(zhì)集定義

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

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

介質(zhì)集是一種可選結(jié)構(gòu)，當(dāng)創(chuàng)建者需要介質(zhì)集時，通常應(yīng)該按照下面的順序創(chuàng)建：首先創(chuàng)建數(shù)據(jù)文件，如有需要也可以創(chuàng)建支持文件；其次創(chuàng)建頭文件，由數(shù)據(jù)文件、支持文件和頭文件共同構(gòu)成一個LSP；第三創(chuàng)建介質(zhì)項，每個介質(zhì)項可包含多個LSPs；最后創(chuàng)建MSP，一個MSP可以至多包含255個介質(zhì)項。

3 ARINC665-4標(biāo)準(zhǔn)的應(yīng)用

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

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

4 結(jié)束語

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

[參考文獻(xiàn)]

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

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