有一種比派遣工程師數(shù)千英里進行遠程 MIL-STD-1553 總線分析更具成本效益的解決方案。

對于 MIL-STD-1553 設備或線路可更換單元 （LRU） 或任何 I/O 的制造商來說，接到現(xiàn)場報告問題的電話，問題是如何有效響應。一種方法是派遣經(jīng)驗豐富的工程師或技術人員上飛機，同時配備測試儀器盒和隨行診斷軟件，在現(xiàn)場運行診斷。另一種選擇是遠程進行測試。

盡管測試設備已經(jīng)遠程使用了一段時間，但傳統(tǒng)上數(shù)據(jù)總線分析是在現(xiàn)場進行的。顯然，如果有同樣有效的更便宜的替代方案，沒有人愿意在抵達時將昂貴的工程師捆綁在旅途中運行診斷。

幸運的是有。如今，航空電子數(shù)據(jù)總線接口（ADBI）可以在相距數(shù)萬英里的LRU上執(zhí)行各種任務 - 就好像所有LRU都連接到同一個主機測試臺一樣。

1553 通過互聯(lián)網(wǎng)

在案例 I 中，假設有人開發(fā)了代碼或擁有基于 MIL-STD-1553 的商用現(xiàn)成 LRU 產(chǎn)品，可以在遠程操作站點進行檢查。在這種情況下，可以安排讓該代碼在互聯(lián)網(wǎng)上運行。整個應用程序將駐留在測試計算機上并運行。但是，應用程序正在與ADBI通信，ADBI被編程為通過以太網(wǎng)連接在Internet上充當1553以太網(wǎng)橋接控制器。反過來，1553以太網(wǎng)橋接控制器正在與被測單元（UUT）通信。在這種情況下，遠程 LRU 是遠程終端 （RT）。

診斷由制造商總部的專家精心策劃，該專家運行診斷程序，并可以根據(jù)需要動態(tài)引入一系列新程序功能，直到遠程站點的問題得到解決。

案例 II展示了將診斷程序從 1553 以太網(wǎng)橋接控制器運行到另一個控制器（一個本地，另一個遠程）的能力。兩個ADBI共同構成了一座橋梁，通往可能數(shù)萬英里外的操作現(xiàn)場的遠程故障箱。兩個 1553 以太網(wǎng)橋接控制器通過以太網(wǎng)電纜、路由器盒或無線插入模塊互連到萬維網(wǎng)，并由測試計算機控制，使操作員能夠執(zhí)行編程和診斷任務 - 無論情況如何。

全局診斷提供多種經(jīng)濟高效的應用

ADBI可用于簡單地使用其以太網(wǎng)鏈路。例如，客戶在一棟建筑物中擁有五個 LRU，其支持 ADBI，在另一棟建筑物中擁有 1553 總線控制器 （BC） 及其 ADBI。客戶在兩座建筑物之間采用以太網(wǎng)鏈路。另一個很好的選擇是正在開發(fā)的 LRU 將在某個站點長時間存在，并且 LRU 離開該站點是不切實際的。通過案例II安排，居住在測試站點（可能遠離操作站點）的BC仍可以通過萬維網(wǎng)維護操作站點的命令和控制。

可能有許多公司合作開發(fā)MIL-STD-1553系統(tǒng)。也許他們不想與其他人分享他們的 LRU - 或者不能。場景如圖 1 所示。當然，每個ADBI都可以選擇將主機連接到它 - 或者所有站點都可以由單個主機控制。

此外，制造商或集成商可能已將開發(fā)軟件的任務分配給分包商。然后是時候在盒子上測試該軟件了。測試不是將盒子運送給軟件公司，而是簡單地通過互聯(lián)網(wǎng)執(zhí)行。因此，案例II場景對于在多個地點進行開發(fā)和測試的任何人來說都是無價的 - 所有這些都是通過ADBI進行的。

在上述所有情況下，全球診斷解決方案提供了一種方便有效的方法來開發(fā)和測試產(chǎn)品，同時將費用降至最低。通過互聯(lián)網(wǎng)鏈接比購買一個或多個用于測試或開發(fā)目的的 LRU 的成本要低得多。

案例I和案例II之間的區(qū)別在于：案例I允許工程師更加臨時 - 也就是說即興。可以將一個盒子運送到站點，并且技能最少的人可以連接它，從而可以從測試計算機運行測試。然而，案例II更像是一種半永久性的操作類型，工程師實際上是在嘗試將數(shù)據(jù)總線擴展到世界各地。在這種情況下，很可能已經(jīng)編寫了在測試計算機上運行的特定代碼。

滿足卑詩省

重要的是滿足總線控制器（BC）的要求，以便正常的總線行為不受阻礙。根據(jù)該標準，測試站點的 BC 必須在 14 微秒 BC 響應時間內(nèi)收到對其傳輸?shù)娜魏蜗⒌幕貜汀＿@通常需要測試站點的ADBI鏡像操作站點的MIL-STD-1553總線。通過“鏡像”，我們的意思是遠程站點的 LRU 必須出現(xiàn)在測試站點的 BC 中，就好像它們實際上在操作站點一樣。原因是數(shù)據(jù)往返的實際時間可能是幾秒鐘，甚至更長。

除了滿足 BC 的要求外，數(shù)據(jù)本身可能處于絕對的時間依賴關系中。如果這是真的，可能需要賠償。在這種情況下，測試程序協(xié)調(diào)員有責任編排或說明對 LRU 可能很重要的任何數(shù)據(jù)時間延遲。圖 3 顯示了兩個充當橋接器的 ADBI，以便測試站點的 BC 由 RT 提供數(shù)據(jù)。這種安排還確保BC能夠處理通過萬維網(wǎng)傳輸?shù)臄?shù)據(jù)包所遇到的擴展傳播延遲，ADBI以非時間關鍵的方式發(fā)送和接收互聯(lián)網(wǎng)數(shù)據(jù)包，同時適應MIL-STD-1553的4至14微秒延遲范圍。

處理過時數(shù)據(jù)

如果存在過時數(shù)據(jù)問題，則必須對BC/RT和/或ADBI進行編程以適應這種情況。BC如何處理到達的數(shù)據(jù)可以通過多種方式處理。如果 BC 無法忍受過時的數(shù)據(jù)，則有以下幾種選擇：

每次發(fā)送不同的東西時，BC 都會決定它是否不同。如果接收到的數(shù)據(jù)沒有不同，則只需丟棄它。

BC或RT可以在數(shù)據(jù)電文中嵌入計數(shù)器或當前時間。

過時數(shù)據(jù)也可以解釋為檢測到問題，進而可以設置控制臺標志。為了避免錯誤的控制臺標志，ADBI 程序可能會稍微調(diào)整數(shù)據(jù)字值，以便不會發(fā)出錯誤故障信號。

無論如何，數(shù)據(jù)傳輸都會及時延遲。但是，如果工程師正在運行測試或非時間相關的模擬，工程師可能不會關心。

遠程診斷節(jié)省時間和金錢

從更廣泛的意義上講，案例II的情況建立了一個全球MIL-STD-1553網(wǎng)絡，使每個供應商能夠參與航空電子網(wǎng)絡中互連LRU的開發(fā)和全功能測試。ADBI的一個例子是巴拉德科技的OmniBusBox。它的一些強大和不尋常的功能包括用戶生成的應用程序代碼，這些代碼駐留在主機或 BC 和/或 RT 的盒子本身中。或者，用戶可以購買行業(yè)軟件，如巴拉德科技的CoPilot，它可以作為模擬器以及分析儀或診斷工具執(zhí)行多種角色。該軟件提供了許多臨時功能和腳本資源來執(zhí)行更多自定義過程。

最后，重要的是要記住，遠程操作站點的人員不需要了解MIL-STD-1553的任何信息。他們需要知道的只是如何將他們的 LRU 連接到 ADBI。

審核編輯：郭婷