自 50 多年前推出第一架渦輪直升機 Ka-225 和改進型海軍 HTK-1 以來，直升機人機界面 （HMI） 發生了巨大變化。最初由機械燃油表和高度計組成的系統已被計算機和多功能顯示器的集成飛行數據系統所取代，該系統為飛行員提供關鍵的導航、天氣和其他關鍵飛行信息。今天，直升機航空電子設備繼續快速發展，增加了其發展的復雜性。

將下一代顯示器和新信息源集成到飛行員友好的HMI中并不是當今航空電子設備開發人員面臨的唯一挑戰。開發人員還必須管理項目并考慮開發成本。當渦輪直升機被引入時，只有5%的成本用于航空電子設備。如今，航空電子設備約占飛機成本的60%。

現在，HMI 開發更加復雜和昂貴，編碼錯誤、項目超支和設計缺陷的風險更大。但是，通過一些先進的規劃和正確的工具，直升機開發人員可以保持領先地位，并為客戶提供最用戶友好、最復雜的HMI，而不會產生巨大的開發成本和風險。COTS軟件的進步為航空電子設備開發人員提供了利用軟件工具的機會，這些工具可以自動化流程，支持行業標準，并提供一個平臺，以便在設計部署到駕駛艙之前對其進行有效測試。

通過自動生成代碼降低風險

為了節省時間并降低項目超支的風險，設計人員應密切關注他們如何處理低級需求，這些需求指示如何在編碼級別編寫軟件，而無需任何進一步的指導。低級測試的示例包括對象和邏輯的編碼。雖然這些功能可以手動開發，但手動編碼需要手動修復和優化錯誤，這在項目開始時可能會消耗大量時間。通過使用具有自動代碼生成的軟件，可以在軟件模型中捕獲低級需求，并且幾乎消除了低級測試。雖然仍然需要高級測試，但通常會減少，因為代碼是自動生成的，并且很少或不需要低級測試。由于使用建模工具創建顯示器，因此在早期原型中捕獲需求并盡早完成審查。這可以進一步減少對高級測試的需求。

隨著HMI從原型設計進入生產，開發人員必須格外小心，以減少編碼錯誤。手動編碼本質上可能是不可預測的，并且可能會在每次迭代時產生意外的結果和錯誤。自動代碼生成有助于避免在對顯示器進行更改時修訂數百萬行代碼 - 即使在項目后期或測試階段 - 通過提供具有可預測結果的可重復過程。例如，使用手動編碼創建具有特定大小的簡單藍色框可以通過數百甚至數千種不同的方式完成。這增加了整個項目中使用的代碼變體數量出錯的風險。為了降低這種風險，自動代碼生成器將始終以完全相同的方式為藍框生成相同的代碼，無論重復多少次。

選擇在項目開始時使用具有自動代碼生成的工具至關重要，最終將在開發過程中提高生產力。隨著強制性的安全關鍵標準（如DO-178B）在航空電子認證中占據中心位置，跟蹤和記錄HMI開發的能力至關重要。FAA 要求開發人員提供冗長的文檔跟蹤軟件開發，作為認證申請流程的一部分。該文檔可以手動創建，但符合DO-178B的代碼生成器附帶許多認證文檔和測試用例，以表明HMI已經過FAA要求水平的重大測試。當客戶使用符合DO-178B的自動代碼生成器時，他們可以將已經完成的大部分測試和文檔歸功于他們，并減少認證的時間和成本。

通過標準化降低成本

新的航空電子系統、顯示功能和小部件與直升機生命周期內的硬件過時管理相結合，可能會導致項目開銷飆升。為了管理這些成本，開發人員可以選擇遵循ARINC 661。ARINC 661 允許開發人員訪問一組標準的小部件，這些小部件是符號、圖片、面板和按鈕等對象。這些是將在HMI中顯示的定義文件（DF）的基本構建塊。DF包含頁面或“圖層”，由將在駕駛艙顯示系統（CDS）上顯示的不同小部件組成。使用標準化小部件可以減少項目啟動所需的時間，因為它使開發人員很容易了解如何開發新顯示器。如果沒有適當的標準，每當選擇不同的供應商組合以滿足各種文件格式要求時，開發人員都必須重新設計編碼。這組標準的預先批準的構建塊使開發人員能夠靈活地使用來自多個供應商的系統：文件遵循標準格式，不需要數據復制或其他編碼。最后，還可以通過修改小部件的視覺外觀，在新項目中重用DF的大部分內容，而無需每次從頭開始。

雖然這不是強制性的，但直升機制造商AgustaWestland等行業領導者正在受益于ARINC 661的指導方針。AgustaWestland選擇了Presagis的VAPS XT ARINC 661模塊，因為它使公司能夠快速開發HMI概念，并通過為DO-178B認證提供未來途徑來降低風險。

支持 ARINC 661 開發的工具可用于開發完整小部件庫的外觀和感覺，而無需在實際硬件上工作。這些小部件可以使用工具提供的低級構建塊以圖形方式創建，也可以通過編程創建。通過編程創建的對象需要使用傳統的軟件編碼工具從頭開始編碼，但是當使用建模工具以圖形方式創建它們時，不涉及編碼。開發人員使用建模工具從用戶界面中選擇線條、顏色和文本等方面，該工具會自動生成已完成對象的代碼。這支持在迭代開發過程中快速更改其外觀，而無需修改或創建任何代碼。為了定義對象的行為，開發人員隨后將使用狀態圖來選擇設計元素，以在應用程序邏輯中創建觸發器和操作。通過使用 ARINC 661 支持的軟件，無需在多個小部件上重復手動代碼行為。相反，狀態圖邏輯可以應用于客戶對象的每個實例，從而節省時間并消除人為錯誤的風險。

在模擬環境中對 HMI 進行測試

在將HMI部署到駕駛艙之前，測試其功能至關重要。沒有人希望在飛行員培訓期間發現，以特定順序激活顯示功能的組合會導致嚴重的系統故障。沒有人愿意被迫回到繪圖板，也不得不重復整個開發過程。因此，HMI根據許多標準進行評估。例如，HMI是否允許飛行員直觀地采取行動，幫助他們快速做出和執行正確的決策？為了正確進行此評估，設計人員需要在模擬環境中測試HMI。

為了確保新的HMI能夠按預期運行，它們必須在各種條件下進行測試，例如當空氣中的灰塵或沙子降低飛行能見度時發生的掉電。通過模擬豐富的沉浸式環境，設計人員可以在逼真的3D場景中測試HMI，測試HMI處理和呈現飛行信息的能力。從長遠來看，創建模擬測試環境有助于節省資金，允許開發人員在將HMI嵌入駕駛艙之前了解HMI的功能。如果發現對齊、可用性和性能問題等異常情況，自動代碼生成器將變得特別方便，因為它允許開發人員輕松進行更改并重復該過程。

使用 COTS 工具進行仿真和測試的一個優點是，該軟件可以開箱即用地在多個平臺上使用。航空電子設備開發人員可以利用 COTS 工具來設計 HMI 并為 HMI 測試創建模擬環境。在開發的最初階段使用仿真來測試原型概念并接收最終用戶的早期反饋，航空電子設備開發人員可以消除創建飛行員認為不直觀的HMI的風險。通過利用模擬環境，他們還可以測試最終的HMI并測試其最大閾值。借助 COTS 仿真軟件，開發人員可以在飛行員在模擬虛擬環境中執行不同任務時測試 HMI。

最終結果：復雜、易于駕駛的人機界面

直升機駕駛艙已經從電子飛行儀表系統演變為集成飛行數據系統。因此，HMI開發項目的復雜性增加，帶來了獨特的挑戰和風險，例如編碼錯誤，項目超限和設計缺陷。為了降低這些風險，航空電子設備開發人員可以利用有用的功能，例如自動代碼生成、支持行業標準和仿真，這些功能由具有廣泛市場訪問權限的 COTS 供應商整合。這使得航空電子開發人員能夠利用已經在大量系統中得到驗證的工具，這意味著他們可以最大限度地減少開發工具所花費的時間，并專注于他們最擅長的事情：開發有效的、飛行員友好的 HMI。

審核編輯：郭婷