在過去十年中，由于認證規(guī)則（DO-178B）在軍事項目上的更廣泛應用，以及不斷推動在更短的期限內交付，創(chuàng)建飛機駕駛艙顯示器的任務變得越來越困難。更復雜的是，行業(yè)中的許多參與者使用自己的開發(fā)方法，除了開發(fā)人員和人為因素工程師的說明外，幾乎沒有關于內容的指南。

由于缺乏基于標準的方法，導致內部開發(fā)或通過使用商業(yè)工具開發(fā)的單一應用程序激增。無論進行哪種類型的更改，這些應用程序始終需要作為一個整體重新認證。在商業(yè)工具之間交換數據通常也很困難，這使得飛機制造商在飛機的生命周期內考慮更換系統的供應商或在使用不同軟件架構構建的項目之間重用顯示元素是一項挑戰(zhàn)。

在90年代后期，成立了一個由行業(yè)代表組成的委員會來解決這些問題，并為飛機航空電子設備的創(chuàng)建制定了標準和靈活的架構，該架構成為ARINC規(guī)范661：駕駛艙顯示系統與用戶系統的接口。今天，ARINC 661被用于空中客車A380和A400M，波音787和AgustaWestland Merlin直升機升級等項目。

在了解了ARINC 661標準及其架構之后，我們將了解ARINC 661的駕駛艙顯示系統（CDS），用戶應用程序（UA）和小部件，以及它們帶來的好處 - 特別是對于需要認證的項目。

ARINC 661 架構概述

雖然駕駛艙顯示軟件傳統上被編寫為獨立的可執(zhí)行文件，根據內部數據、規(guī)則和邏輯呈現信息和渲染圖形，但 ARINC 661 在繪制圖形的代碼和管理邏輯以及所有可視元素的位置和狀態(tài)的代碼之間引入了明確的分離。這兩個組件是 CDS 和 UA。

此外，ARINC 661 將 CDS 定義為運行時解釋器，能夠根據外部布局文件中包含的信息顯示來自稱為小部件的有限構建塊庫中的一個或多個元素。最后，ARINC 661定義了CDS和UA交換消息的標準通信協議。圖 1 顯示了 CDS 和 UA 之間的關系，以及它們的典型執(zhí)行環(huán)境和這兩個應用程序之間的通信。它還顯示多個 UA 可以與 CDS 通信。在這種情況下，每個 UA 可以單獨開發(fā)，并負責更新和響應顯示器特定部分的事件。

圖1：ARINC 661架構的主要組件：駕駛艙顯示系統（CDS）和用戶應用（UA）

此體系結構的一個直接好處是，對顯示組合的更新是通過創(chuàng)建新的布局文件來完成的，而不是在統一應用程序中修改代碼。在認證環(huán)境中，這意味著無需重新編譯或重新認證 UA 和 CDS 代碼即可進行視覺布局更改，例如重新定位或更改顯示元素的視覺屬性。同樣的好處也適用于對應用程序邏輯流的更改，這只會導致對特定用戶應用程序的更改，而 CDS 代碼庫和其他用戶應用程序不受影響。

除了隔離的好處之外，這種方法還簡化了組織內不同團隊之間或分包商之間應用程序開發(fā)的分布。

近距離觀察：CDS 和 UA

仔細觀察典型的 ARINC 661 應用程序執(zhí)行流程，CDS 會基于一個或多個稱為定義文件 （DF） 的布局文件加載和顯示小部件。每個 DF 都包含一個或多個圖層，這些圖層是需要加載的所有微件的分層列表及其初始參數，例如位置、大小和可見性。它們以二進制格式本機存儲，該格式在運行時加載到 CDS 應用程序中。該標準還定義了XML交換格式，以促進DF檢查，修訂控制和共享。

向下移動一個級別，附加到 CDS 的物理顯示器分為一個或多個子部分，簡稱為窗口，每個子部分可以渲染一個或多個圖層。這些窗口不能有任何重疊，并將堆疊指定的圖層以創(chuàng)建最終結果，該結果將在屏幕上顯示給飛行員或操作員。圖 2 說明了此層次結構。

圖2：CDS 視覺層次結構

在運行時，CDS 處理試點輸入并確定這些交互是否可以在本地處理（例如，當光標放在小部件上時需要突出顯示 CheckButton）和/或是否應將它們傳輸到 UA（例如，按下 CheckButton）。在后一種情況下，事件將發(fā)送到相應的 UA，以根據當前系統狀態(tài)和事件類型確定響應。UA（s）通常還會向CDS發(fā)送穩(wěn)定的消息流，以更新向飛行員提供信息的所有屏幕元素的位置。

在認證方面，這種詳細的顯示架構大大簡化了高低級要求的創(chuàng)建。對定義文件使用標準XML交換格式也使內容開發(fā)人員可以靈活地使用來自多個供應商的CDS系統，因為他們認為合適的工作可以加載到任何符合ARINC 661標準的CDS中。還可以通過僅更改 CDS 庫中小部件的視覺外觀，在新項目中重用定義文件和系統用戶應用程序的大部分內容。

標準小部件庫

ARINC 661 規(guī)范沒有綁定到特定工具的應用程序構建組件，也沒有在內部為項目創(chuàng)建自定義組件架構，而是引入了 42 個可用于創(chuàng)建顯示的小部件。隨著標準的第一次更新，這個數字上升到50，在補充2中上升到57，在修訂版3中上升到65，在今年早些時候發(fā)布的最新版本上升到68。

小部件的復雜性各不相同，從基本的圖形元素（如 GpLine 和 GpRectangle 小部件）到復雜對象（如顯示來自各種數據源的地圖的 MapHorz 小部件）。還有一些小部件沒有任何可視化表示，用于將其他元素組合在一起并對其應用轉換。最后一個類別中的一個示例是互斥容器小部件，它將多個元素分組到單個父元素下，但一次只顯示其直接子元素之一。

雖然 ARINC 661 描述了小部件應該如何工作以及它們的參數是什么，但它并沒有定義它們的視覺外觀。這使顯示器制造商可以完全自由地為給定項目實現自己的外觀和感覺。標準中還有一項規(guī)定，允許開發(fā)人員創(chuàng)建具有定制功能和參數的自定義小部件，這些功能和參數仍遵循通用小部件創(chuàng)建模式。

擁有一組標準的小部件來開發(fā)顯示器，使開發(fā)人員可以輕松熟悉 ARINC 661 標準并快速了解如何開發(fā)新顯示器。此外，與直接與高級需求相關的整體ARINC 661架構類似，擁有一組具有良好記錄功能的標準小部件有助于加速認證項目的低級詳細功能需求的文檔記錄。

ARINC 661 的未來

雖然此體系結構的實現可能看起來有點令人生畏 - 考慮到需要建立一個兼容的CDS運行時軟件體系結構，遵守規(guī)范的功能小部件庫，以及促進創(chuàng)建定義文件及其輸出到標準二進制文件的工具 - 應該注意的是，COTS工具可用于提供這些功能開箱即用。在某些情況下，這些工具甚至是合格的開發(fā)工具，可以在DO-178B下生成合格的代碼。在看到一些大型商用飛機引領潮流后，許多商業(yè)和軍用項目正在考慮或已經在其即將開展的項目中采用ARINC 661，以確保該標準的成功。

審核編輯：郭婷