洞見｜低空航電系統軟件適用ARINC 653標準的必要性和優勢分析

▌沒有標星的朋友們有時可能會錯過【通航圈】的推送或是看不到部分推送文章的封面，歡迎新老朋友給【通航圈】點個星標，以便及時收到最新推文、避免錯過更多精彩*
加星標方法：點擊上方藍字“通航圈”，然后點擊右上角...，設為星標

在新一輪科技革命、產業升級和政策驅動的共同作用下，低空經濟正加速成為戰略性新興產業的重要組成部分。伴隨應用場景不斷拓展、飛行器類型持續豐富以及產業鏈能力逐步完善，低空飛行器的發展正在從單點突破走向體系化演進。隨著飛行平臺不斷走向復雜化，其背后的核心系統能力也日益成為決定產品安全性、可靠性和可持續演進能力的關鍵。作為支撐飛行控制、通信、導航、監視和顯示等關鍵功能的核心系統，低空經濟飛行器航電系統（低空航電系統）正越來越成為低空飛行器能力建設的重要基礎。

低空航電系統，主要應用于無人機（包括消費級和工業級無人機，貨運無人機等）、城市空中交通飛行器（包括eVTOL和各種電動載人飛行器等）和傳統通用航空器（包括運動飛機，直升機等）。與大型民航飛行器相比，這類航電系統在硬件形態和軟件系統設計上往往更具多樣性，但本質上仍屬于飛行器核心系統，承擔著飛行控制、通訊、導航、監視和顯示等功能。

針對這類航電系統架構問題，民航領域其實早已有較成熟的標準化方法。 ARINC 653 就是航空電子領域的重要軟件標準，它定義了操作系統如何管理飛機計算機內部運行的應用程序。該標準支持集成式模塊化航電（IMA）架構，允許同一硬件設備中實現不同層級航電軟件的集成，提供故障保護運行層級，使得分區內的故障不應影響其他分區的執行。當前，采用ARINC 653標準的集成模塊化航電（IMA）架構，已經在 A380、B787、C919等新一代民航飛機航電系統中得到廣泛應用。

當前，低空經濟飛行器的研制仍處于快速發展和路線探索階段，是否采用ARINC 653標準作為低空航電系統架構，并沒有統一結論。基于此背景，我們將嘗試從分析ARINC 653標準的目標和技術實現出發，探討低空航電系統采用該標準的必要性和優勢所在。

ARINC 653標準實現的目標在低空航電系統上是否必要

首先，正如ARINC 653標準Part 0所描述的，ARINC 653標準的主要目標，是在航電計算機的核心軟件（Core Software）與應用軟件（Application Software）之間定義一個通用的APplication/EXecutive (APEX) 接口規范，其中包括API的列表，以及與調度、通訊和狀態信息相關的各類服務。通過實現這套接口規范，ARINC 653 旨在支持可移植性、可復用性、模塊化和集成多安全級別等軟件的目標。

可移植性，是指在理想情況下，為特定機型開發的應用軟件能夠以最小的重新認證工作量，移植到其他機型或者其他平臺上運行。APEX接口通過降低應用代碼對編程語言和硬件的依賴，為軟件移植提供了基礎。

可復用性，是指基于APEX接口開發的應用代碼能夠在IMA系統中實現更高程度的復用，從而減少不同項目、不同平臺之間重復開發和重復適配的工作量。通過標準化接口，應用軟件在復用時所需的定制工作也可相應降低。

模塊化，是指APEX接口在開發應用軟件時提供了模塊化的優勢，通過消除硬件和軟件依賴性，減少了系統修改對應用軟件的影響。

集成多安全級別的軟件，是指APEX 接口支持將不同安全級別的應用程序軟件在統一系統架構下協同部署。

顯然，上述目標的達成，已經為新型民航飛機航電系統提供了關鍵的優勢。它不僅使得昂貴的認證應用軟件更易于在不同硬件平臺和機型之間復用與遷移，也為多安全級別的模塊化集成提供了可行路徑。

對比目前低空航電系統的研發現狀，多數平臺仍處于首代系統開發階段，因此對于可復用性的要求不高。但是隨著第二代以及后續系統的迭代更新，系統仍將面臨軟件復用、架構遷移等挑戰，可復用性的設計仍有必要。

而對于可移植性目標要求，主要是針對單獨應用軟件是否可以做到標準統一化，從而方便移植到不同的ARINC 653標準的航電系統上，真正實現關鍵應用的一次設計，多次應用。目前，部分低空航電系統研發廠商已經開始考慮未來軟件設計的復用問題，從而最大化關鍵安全應用的適用范圍。因此，統一的應用API規范也同樣具有現實需求。

在IMA模塊化設計方面，其突出優點在于盡量將應用與硬件解耦，從而實現一套應用設計能夠盡可能多地適用不同的硬件平臺。當前，低空航電系統已經面臨需要使用冗余硬件設計，甚至是異構硬件設計來提高安全等級。若來自不同供應商、不同的硬件平臺也采用統一的IMA模塊化設計，就能夠更好地實現軟硬件解耦，提升應用向不同硬件平臺移植的能力，這也恰好契合了低空航電系統的發展要求。

至于不同安全級別軟件集成的問題，在當前低空航電系統上也同樣存在。若不采用IMA模塊化設計隔離應用，很多廠商往往只能將所有應用都采用其中最高安全級別的設計，以此化解不同等級應用互相融合的問題。這樣的設計雖然在表面上降低了系統管理復雜度，但實際上會抬高低安全等級應用的研發成本，犧牲系統靈活性，也增加整體開發負擔。

綜上所述，實際上ARINC 653標準所實現的目標，同樣適用于低空航電系統。隨著項目數量增加、平臺類型擴展以及型號持續迭代，標準化架構設計的優勢將逐步顯現。因此，從長期演進和工程化發展的角度看，在低空航電系統中引入 ARINC 653 具有較強的現實意義。

ARINC 653標準實現的目標關鍵技術及實現

前面提到了ARINC 653標準實現的目標和必要性，那么，該標準是如何通過其規范的標準，通過什么技術去實現其關鍵目標的呢？這一部分將圍繞其參考架構與關鍵機制展開說明。

圖 ARINC 653標準參考系統架構

通過ARINC 653標準Part 0中參考系統架構圖中，我們可以知道，標準主要定義了支撐分區（Partition）應用軟件架構的APEX服務和核心操作系統功能以及服務。通過對分區架構和相關服務進行規范，來自不同軟件供應商的分區應用都可以運行在符合標準的核心軟件平臺之上。而由核心操作系統適配不同的硬件，從而實現應用軟件與硬件解耦。在標準的Part 1，Part 2和Part 5部分中，分別對APEX服務層以及核心軟件層需要提供的服務提供了標準化規范，使得應用接口標準化。另外，Part 4是Part 1的子集，允許更輕量化核心操作系統只實現子集功能，Part3則是定義了兼容測試規范。所以，我們可以看到ARINC 653標準是通過規范系統架構，中間層接口以及核心軟件服務達到其規范統一的目標。

在此基礎上，進一步分析這些關鍵核心軟件服務在具體硬件平臺上的實現方式，有助于更清楚地理解 ARINC 653 所采用的技術路徑，以及這些技術在工程實踐中能夠帶來的實際價值。

分區（Partitioning）

ARINC 653標準的核心思想是分區概念，即通過空間分區（內存分區）和時間分區（時域分區）對集成模塊中的應用程序進行隔離。因此，分區可以理解成是為滿足這些隔離約束而設計的應用單元。

為了實現空間分區（內存分區）的能力，在傳統單核處理器上，采用的是芯片內存管理單元（Memory Management Unit）技術。系統通過為每個分區配置不同的內存管理單元配置表，定義其每個分區能夠訪問的物理內存，并將物理內存轉換成分區看到的虛擬地址。這樣，每個分區就單獨訪問自己的物理內存，而互不影響，從而實現空間分區能力。

在分區切換過程中，由內核模塊操作系統負責取消前一分區MMU配置并加載下一個分區的MMU配置，從而在技術上實現分區的切換和空間的隔離。

圖 內核模塊操作系統采用MMU實現分區的空間隔離

然而，隨著芯片技術的改變和性能提升，多核處理器成為了高性能處理器的主要提升方向，無論是x86，ARM和PPC架構，新一代處理器普遍采用了多核處理器架構。同時，為了發揮多核處理器的性能優勢，虛擬化（Virtualization）技術也被廣泛引入，用于支持多個虛擬機在多核處理器上運行。

以ARM架構為例，多核處理器支持虛擬化技術，允許一個Hypervisor系統運行在芯片EL2（Exception Level 2）級別上，負責對虛擬機的初始化和管理功能。Hypervisor系統可借助虛擬化地址轉換（VTT）技術或者系統內存管理單元（SMMU），完成對虛擬機進行虛擬地址到物理地址的轉換，從而劃分不同的地址，實現每個虛擬機的地址轉換和空間隔離。

因此，如何在多核處理器架構上實現ARINC 653標準的分區功能，實現標準的目標，并發揮處理器的性能，便成為了一個需要重點解決的技術問題。

圖 Hypervisor模塊操作系統采用SMMU實現虛擬化分區的空間隔離

以風河Helix Virtualization Platform（HVP）為例，其通過采用Type-1的Hypervisor作為核心模塊操作系統（MOS），將在Hypervisor上管理的每一個虛擬機作為一個個分區操作系統（POS）運行。分區隔離的實現，是直接采用ARM芯片的虛擬化技術，通過虛擬化地址轉換和SMMU實現不同分區的地址區間。

由于采用的是硬件的虛擬化能力，Hypervisor運行在EL2（Exception Level 2）上；而分區應用運行在EL1（Exception Level 1）上，Hypervisor模塊OS的完整性大大提高，不會受到分區應用的影響，因此Hypervisor模塊OS的魯棒性大為提高。與此同時，分區切換使用的虛擬化的切換，其切換性能也得到了硬件芯片的最好支撐，達到高性能的切換時效。

綜上，在多核處理器上采用Hypervisor的虛擬化，可以更好的達到ARINC 653標準的空間隔離分區要求，實現ARINC 653標準的目標，這也是目前多核處理器的主流技術實現方案。

調度（Scheduling）

關于調度的要求，在ARINC 653 Part 1標準中有明確提出，主要分為分區調度（Partition Scheduling）和進程調度（Process Scheduling）兩部分。

標準對于分區調度的要求，首先分區的調度在時間上是嚴格確定的。根據集成模塊內分區的配置、總體資源需求、可用性以及特定分區需求，生成基于時間的激活模塊調度表，該調度表確定了分配給各個分區的分區時間窗口。然后，系統根據每個分區各自的時間窗口（即其分區調度表）對每個分區進行調度。

主要特征包括：

1. 從應用程序開發人員的角度來看，調度單元是一個分區；

2. 分區沒有優先級；

3. 模塊調度算法是預先確定的，具有固定的周期性（主要時間框架），并且只能通過配置表進行配置。在主要時間框架的每個周期內，每個分區應至少分配一個分區時間窗口。

圖 ARINC 653分區調度

正如前文所述，在單核處理器上，Kernel模塊OS負責分區隔離，也負責分區的調度。而在多核處理器上，采用Hypervisor模塊OS負責分區調度，在精確的時間規劃點上進行虛擬化分區的切換，符合ARINC 653的標準要求。

不過，隨著多核處理器的應用，如何實現多核場景下的分區時間調度，也成為工程實現中的一個關鍵問題。這點在ARINC 653 Part 1的標準中仍然沒有明確規定。當前較常見的一類實現方式，是將每個處理器核單獨分開，每一個核都實現標準要求的時間分配分區調度。

圖 多核時間分區調度

采用這個多核時間分區調度策略，可以兼容單核和多核應用的設置，如果只啟動其中一個核使用時，完全兼容單核時間調度的設計；而開放多核進行調度的時候，可以充分發揮多核處理器的性能優勢。

標準對于進程調度的要求，主要是定義了分區應用里面進程的調度要求，其要求與分區調度不同，需要根據進程的處理器內核親和性分配、各自的優先級和當前狀態來調度和搶占進程。進程的調度以一個APEX進程為調度單元，需要實現每個進程設置一個優先級，進程根據優先級進行調度。

其實進程的調度，與我們熟悉的POSIX調度一致，因此在每個分區OS上的調度，除了使用ARINC標準之外，也常有使用POSIX調度或者其他優先級調度的情況。

圖 分區內采用ARINC或者POSIX等優先級進程調度

采用這種兼容的分區內進程調度方法，可以更大兼容應用工程師編寫應用程序的兼容性，若嚴格根據ARINC API標準進行編程，可以輕松切換到同樣符合ARINC標準的不同軟件平臺上，實現應用程序的兼容開發。

健康監控（Health Monitor）

在 ARINC 653 標準中，除分區機制、調度設計和接口規范外，還專門定義了健康監控（Health Monitor，HM）相關內容，這也是該標準的重要特征之一。總體而言，健康監測（HM）功能負責響應和報告硬件、應用程序和操作系統（O/S）軟件錯誤和故障。

ARINC 653通過提供健康監測配置表和應用程序級錯誤處理程序來支持健康監測。健康監測（HM）有助于隔離錯誤并防止故障傳播，監控來自系統不同等級軟件的錯誤信息。標準將模塊系統的錯誤分為三個等級，分別為進程等級錯誤（Process Level Error）、分區等級錯誤（Partition Level Error）以及模塊等級錯誤（Module Level Error）。

進程級錯誤包含分區中的一個或多個進程，甚至整個分區進程的影響，例如應用程序進程引發的應用程序錯誤、非法操作系統請求錯誤以及進程執行錯誤（堆棧溢出、內存違規等）。

分區級錯誤包含對分區有影響的錯誤，例如分區初始化過程中的分區配置表錯誤、分區初始化錯誤以及進程管理過程中出現的錯誤等。

模塊級錯誤包含影響整個集成模塊系統的錯誤，例如集成模塊初始化過程中的模塊配置表錯誤、系統特定功能執行過程中的錯誤、分區切換過程中的錯誤以及電源故障等。

針對不同等級的錯誤，系統可以通過配置表，對其配置對應的恢復措施（Recovery actions）。

對于模塊級錯誤（Module Level Error），可在模塊 HM 配置表中根據系統狀態指定恢復措施，可能的處理方式包括：忽略、關閉集成模塊、重置集成模塊，以及執行依賴于操作系統實現的自定義恢復措施。

對于分區級錯誤（Partition Level Error），可在分區 HM 配置表中進行配置。針對每個分區，錯誤響應會結合其行為能力進行處理，例如是否支持重置、是否存在降級模式等。其可能的恢復操作包括：忽略、停止分區（IDLE）、重啟分區（COLD_START 或 WARM_START），以及執行依賴于操作系統實現的自定義恢復操作。

對于進程級錯誤（Process Level Error），應用供應商可以為分區定義相應的進程級錯誤處理程序。其可能的恢復操作包括：忽略、在采取恢復措施前忽略錯誤 n 次、停止出錯進程、停止出錯進程并從入口地址重新初始化、停止當前出錯進程并啟動另一個進程、重啟分區（COLD_START 或 WARM_START）、停止分區（IDLE）等。

通過上述三級錯誤健康監控和恢復措施，符合ARINC 653標準的集成模塊系統便有了較為完整的錯誤檢測和恢復能力。以下是在多核處理器下，HM的具體技術實現：

圖 健康監控（HM）錯誤和配置表

進程級（Process Level）健康監控在分區中對分區進行錯誤進程監控。當發現錯誤時，首先由進程健康監控處理程序處理，按照可能的恢復措施操作。對于無法恢復的錯誤，則通過系統調用（System Call）上升到分區級別錯誤。

分區級別健康監控負責對所有來自分區的錯誤進行統一檢測，分區級錯誤恢復措施由HM配置表中對應處理措施進行處理。

模塊級健康監控則負責檢測除了分區之外，包括模塊OS（Module OS）自身的錯誤，并按照對應的HM配置表中恢復措施進行處理。

可以看到，健康監控（HM）機制是分區應用之外的一條錯誤管理生命線，為整個系統增加了錯誤檢測和修復能力，增強了整個系統的魯棒性。因此，健康監控（HM）是ARINC 653標準中非常重要的一環。

采用ARINC 653標準航電系統的優勢

綜上所述，ARINC 653標準作為航空電子領域的關鍵技術規范，其核心優勢在于通過時間分區和空間分區機制，實現高度安全可靠的系統架構。采用 ARINC 653 標準的航電系統，可以通過嚴格的時間分區（固定時間片分配）與空間分區（獨立內存空間）技術，實現不同安全等級應用的獨立運行。即便單個分區出現死鎖、異常或超時等故障，也能有效隔離，杜絕級聯失效，同時支持分區快速重啟，大幅提升系統整體可用性。

ARINC 653 中的健康監控機制，能夠在分區、模塊、系統多級實現故障的實時監測、隔離與處理，通過對應用、調度、通信及硬件狀態的統一管控，及時發現并定位異常，避免單個分區故障引發系統級聯失效。同時，健康監控機制還支持分區獨立重啟與故障上報，大幅提升航電系統的可靠性與可用性；它與時間、空間分區隔離機制協同工作，既保障不同安全等級應用的穩定運行，又簡化故障維護與適航認證，為 模塊架構下航電系統的安全、確定性與可維護性提供關鍵支撐。

因此，隨著低空經濟進一步發展，更多的不同級別飛行器研發和制造，其航電系統需要更統一的規范進行開發，以支撐更高效的移植和升級。如果在低空經濟飛行器航電系統中采用ARINC 653規范研制，實現分時分區的設計，采用健康監控等技術，就可以大幅提高系統安全性。與此同時，在經濟性方面，該標準支撐綜合模塊化航電架構，將傳統架構中分散的數十個獨立計算機整合為少數通用處理模塊，從而大幅降低機載設備的重量、功耗、散熱需求和全生命周期維護成本。典型案例包括波音787和空客A350，其航電系統均借此實現了航電系統的輕量化與高效能。總的來看，ARINC 653通過分區隔離、確定性調度和標準化接口，為現代民用航空提供了兼顧極致安全性與資源經濟性的技術基礎，是大型客機、EVTOL及先進無人機航電系統的首選架構標準。

任何一個新產業，最終比拼的都不只是創新速度，更是體系能力與發展質量。對低空經濟而言，唯有把安全、可靠與規范發展內化為底層共識，未來的空間才會真正打開。風河愿與產業伙伴攜手，共同推動低空經濟邁向更安全、更有序、更可持續的階段發展。

參考資料：

1、

https://aviation-ia.sae-itc.com/product-categories/product-category-lists/arinc-standards

2、https://www.windriver.com/products/embedded/helix

來源：風河開物

需要進入通航圈交流群的朋友，

在公眾號對話框回復關鍵詞：入群。

免責聲明：本文及本公眾號任何文章之觀點，皆為交流探討之用，不構成任何投資建議。本公眾號作者也不負有更新以往文章觀點之責任，一切以最新文章為準。用戶根據本文及本公眾號任何其他觀點進行投資，須風險自擔，責任自負。由此造成的一切后果，本公眾號不承擔任何責任。

⊙部分圖文源于網絡，僅用于學習交流，版權歸原作者所有，如有侵權請聯系我們刪除。

通航圈：一個行業的跌宕起伏