基于1394網絡的分布式組合導航系統時序建模與仿真

梁兆鑫，王濤，趙喆，陳銀超，楊朝旭

(航空工業成都飛機設計研究所 飛控部， 成都 610073)

0 引 言

分布式組合導航系統伴隨著分布式網絡拓撲結構的發展而產生，是現代航空電子系統的重要組成部分。與傳統的集中式導航系統相比，分布式導航系統將多個不同種類的導航測量系統分散地安裝在載體的不同位置，并通過總線連接，進行融合解算，這樣既提高了系統的冗余度，又能夠為飛行器提供更加精準且更為可靠的位置、姿態和航向信息。

分布式組合導航系統采用1394b總線網絡進行通信。IEEE 1394總線又被稱為火線(Fire Wire)，是Apple公司于1985年提出的一個串行總線技術標準，1995年被美國電氣和電子工程師協會(IEEE)正式認可，進而確立為通用標準。隨著時間的推移，該標準被不斷地修訂、完善和改進，依次形成了IEEE 1394a、IEEE 1394a-2000以及IEEE 1394b-2002等標準。為了提高總線的可靠性、確定性以及總線網絡的安全性，增強總線網絡的管理手段，降低總線系統的消息延時，SAE(Society of Automotive Engineers)組織在IEEE 1394協議的基礎上，從應用層角度考慮，對協議提出了進一步的限定和約束，形成了新的SAE AS5643協議。

常見的1394總線網絡故障模式有3種：節點可達性故障、總線可用性故障以及數據可靠性故障。對于分布式組合導航系統，組合導航計算機通過總線實時獲取各類傳感器數據，是實現傳感器信息融合算法的基礎，倘若某傳感器節點由于物理連接斷開而出現不可達的情況，那么組合導航功能就無法實現。因此，為了保證分布式系統的總線網絡拓撲的完整，避免可達性故障的出現，同時具備容忍一次網絡斷線故障的能力，必須在系統工作前對各節點的線纜連接情況進行檢查。

針對1394總線網絡測試的研究工作有很多。王仲杰等搭建了一套1394總線網絡系統測試平臺，實現了對1394總線網絡的線纜特性、誤碼率、信號質量以及總線協議符合性等測試；楊峰等對1394線纜的結構及差分阻抗進行了理論分析，并使用專用設備對1394線纜的差分阻抗進行了測試；N.Takashi等利用建模和數值仿真手段，對兩種隊列模型下，1394總線網絡異步流包的平均等待時間等性能進行了測試和分析。但現有的研究工作尚未涉及1394總線網絡的完整性測試，且針對1394總線網絡在完整性測試過程中時序問題的研究也未見報道。

針對上述問題，本文首先給出基于1394總線網絡的分布式組合導航系統總線完整性檢查方法，并以某次檢查過程中出現的虛警故障為切入點，通過建模與仿真等手段，對總線完整性檢查過程的時序問題進行研究。

1 1394總線網絡完整性檢查方法

SAE AS5643協議中給出了3種不同的總線拓撲結構，分別是：基本拓撲、帶環的基本拓撲、帶環的多余度拓撲。本文研究的分布式組合導航系統采用帶環的基本拓撲結構，一個簡單的環狀1394總線網絡，如圖1(a)所示，其中Node1和Node2的兩端分別與CC的端口P0和P1相連，構成總線環。在各個節點正確連接的情況下，端口P0的狀態為active，即正常工作狀態，而P1的狀態為loop disable，處于環斷開狀態，CC通過端口P0與Node1和Node2進行通信。

帶環的1394b總線網絡具備環斷開特性，即容忍一次網絡斷線故障，若總線環上某兩個相鄰節點間的線纜斷開，CC的另一端口將被自動激活，確保節點能夠通過另一個端口與CC進行通信。若Node1與Node2間的線纜斷開，端口P1將被自動激活，從loop disable狀態變成active，從而使Node2能夠通過P1與CC進行通信，如圖1(b)所示。不成環的基本拓撲結構，不具備環斷開特性，一旦有線纜連接故障，該節點以后的所有節點都將掉線，無容錯能力。

(a) 帶環的基本拓撲 (b) 帶環的多余度拓撲

為了便于對總線完整性檢查方法和原理進行描述，首先介紹本文研究的分布式組合導航系統的組成和結構。該分布式系統如圖2所示，總線控制器CC位于組合導航計算機(INC)中，并通過內部總線與CPU進行通信，其他遠程節點總線網絡接口子卡分別位于GPS、INS、CNS以及ADS之中，各個節點通過符合1394b標準的銅制雙絞線相互連接，組成了帶環的1394總線網絡。總線網絡中相鄰兩節點之間的信道被分別命名為Cable1～Cable5。需要說明的是，上文中所述信道包括線纜及其兩端連接的電連接器。

圖2 分布式組合導航系統示意圖

1.1 基于SAE AS5643協議的總線收發數原理

SAE AS5643協議規定了1394總線網絡具有初始化和常規總線操作兩個階段。當總線上有任意節點斷開或者上下電，都會使得總線進入初始化階段，重新標識網絡拓撲。在初始化階段完成后，進入常規總線操作階段，SAE AS5643標準對此階段進行了詳細規范，基本通信過程如圖3所示。

圖3 常規總線操作[10]

圖3中STOF到STOF+1之間的時間稱為一個完整的幀周期，幀周期可以與系統應用的任務周期相關聯，實現總線上模塊間同步。STOF稱為幀起始包，只能由CC發起，每個RN節點都有唯一預定義的相對于STOF的發送偏移和接收偏移時間，節點僅在到達發送偏移時啟動異步流包發送。總線上數據的傳輸行為由總線配置表進行定義，分布式組合導航系統采用的總線配置表如表1所示。

表1 分布式組合導航系統總線配置表

1.2 總線完整性檢查方法

總線完整性檢查可通過軟件檢查來實現，也可通過硬件檢查來實現。分布式組合導航系統采用基于軟件的總線完整性檢查方法，具體步驟如下。

Step

1

向CC端口發送禁止指令，命令CC的端口P1處于禁止(disable)狀態，人為地將總線環斷開，在此情況下，若總線網絡中存在故障信道，故障信道之后連接的節點都無法將數據繼續向前傳輸。

Step

2

由組合導航計算機軟件對數據包更新情況進行檢查，由近及遠地依次檢查遠程節點發送至CC的數據包是否更新，若數據包更新，則表明該節點離CC近端的信道是完好的；若檢查到數據包未更新，則表明該節點離CC近端的信道故障。結合圖2，若檢查到INS發送的數據包已更新，則說明信道Cable1正常，否則說明Cable1故障，若檢查到CNS發送的數據已更新，則說明信道Cable2正常，否則說明Cable2故障，以此類推。本步驟可對信道Cable1～Cable4進行檢查，但無法覆蓋到Cable5。

Step

3

向CC端口P1發送使能指令，命令CC端口P1恢復active正常工作狀態，向CC端口P0發送禁止指令，命令CC端口P0處于禁止狀態，使得GPS只能通過Cable5與CC進行通信，并通過檢查GPS向CC發送的數據包是否更新來判斷信道Cable5是否正常。

1.3 組合導航計算機獲取數據包更新標志的系統運行時序

在分布式組合導航系統中，當CC接收到總線節點在規定時刻發送過來的數據包后，會將該數據包更新標志置“1”，導航計算機軟件將數據包信息讀走后，會清除該數據包的更新標志。導航計算機軟件通過檢查該更新標志是否置位來判斷數據包是否更新。

以CNS為例，組合導航計算機獲取數據包更新標志的系統運行時序如圖4所示。CC在組合導航計算機軟件的控制下實現二者的同步運行，幀周期同為15 ms，根據總線配置表的定義，CNS在每周期開始后的第4 850 μs向CC傳輸其最新數據包。組合導航計算機軟件在每周期開始后約1 350 μs讀取CNS數據包中的信息，同時獲取數據包更新標志。

若總線連接完好且CNS工作正常，那么按照上述時序，組合導航計算機每一拍獲取的數據包更新標志都將為1。當系統運行總線完整性檢查程序時，軟件檢查數據包更新標志為1，確認數據包已更新，判斷該總線節點連接正常，信道完好。若數據包更新標志為0，則可以說明CNS與INS連接的信道Cable2故障。

圖4 總線完整性檢查時序(a)

2 虛警故障現象和原因分析

在某次試驗過程中，組合導航計算機軟件在運行總線完整性檢查程序時，報出CNS與INS間信道故障，即采集到CNS的數據包更新標志為0，但總線分析儀記錄的數據顯示該節點通信正常，可確認該故障為虛警。在不改變總線網絡的硬件連接狀態下，進行多次重復試驗，發現該故障無法穩定復現，屬于偶發現象。

2.1 原因探究

通過查看記錄到的故障數據發現，由于組合導航計算機軟件幀周期的起始階段會進行同步等事務處理，其實際運行周期略小于15 ms，約為14.876 ms，而總線運行周期約為14.998 ms。實際上，總線完整性檢查是分布式組合導航系統檢查程序的一部分，組合導航計算機軟件在執行系統檢查程序時，總線控制器時鐘源發生了切換，CC的運行周期不再由組合導航計算機軟件控制，組合導航計算機與CC的運行分別采用不同的時鐘，并且不同的時鐘其精度也不相同，那么隨著時間的推移，上述偏差逐漸累積，在某一時刻必然會出現時序，如圖5所示。即在新的數據包到來之前，導航計算機讀取了上一拍的數據包，并獲取了已經被清零的數據包更新標志，故本文懷疑正是上述原因引起的虛警。

圖5 總線完整性檢查時序(b)

2.2 故障數據分析

為了對上述懷疑進行確認，進行多次試驗，并對總線分析儀采集的試驗數據進行詳細分析。為了增大報故概率，還縮短了組合導航計算機軟件的工作周期。

在故障數據中，本文最關注的是組合導航計算機軟件進行總線完整性檢查當拍的時序情況。在運行系統檢查程序的第0拍，組合導航計算機與CC仍然是同步的，以該時刻作為起始參考點，并根據參數說明(如圖6所示)，按照以下步驟繪制時序圖。

圖6 時序圖繪制參數說明

Step

1

繪制總線檢查當拍(第

n

拍)組合導航計算機軟件運行時序。首先確認導航計算機軟件進行總線完整性檢查的那一拍相對于起始參考點的拍序號

n

，并計算其相對時間

T

。設

P

為上位機軟件運行周期，

i

為拍次，總線檢查拍次

n

使用JTAG讀取，同時還要使用JTAG獲取數據包更新標志時刻的小幀偏移

φ

。其中：

(1)

Step

2

繪制總線檢查當拍(第

n

拍)CC運行時序。在總線分析儀記錄的數據中，將切換時鐘后CC發送的第一個STOF包選為參考點，找到發送偏移最接近

T

時刻的STOF包，并記錄其發送時間

T

，同時觀察STOF包的實際發送周期

P

。

Step

3

比較分析。同時繪制導航計算機和CC在檢查拍的前一拍(第

n

-1拍)時序，觀察相鄰兩拍中上位機軟件獲取數據包更新標志的時刻與CC接收到CNS發送最新數據包CNS_DATA時刻的相對位置關系，將時序分析結果與故障清單進行比較，判斷系統功能是否正確。

對試驗過程中出現的故障數據和正常數據進行記錄，并按照上述步驟進行分析。結果表明：當出現如圖5所示的時序時，軟件會報出總線連接故障，而當未出現如圖5所示時序時，軟件不會報故，這也印證了之前的懷疑。其中兩次試驗的試驗數據如表2所示，第一組數據報故障，第二組數據正常。

表2 試驗數據及結果

3 建 模

為了說明故障的偶發性，使用Inchron工具對系統進行建模和仿真。

3.1 時序建模

(2)

式中：

T

為組合導航計算機軟件運行第

n

個周期的起始時刻；

φ

=1 352 μs，為獲取數據包更新標志時刻的小幀偏移；

J

∈(-1 000 ps,1 000 ps)，為服從均勻分布的抖動。

為實現精確建模，對式(1)進一步展開，可得：

(3)

式中：

P

=14.876 ms；Δ

P

,～

N

(0,100 μs)，為第

i

個周期的組合導航計算機軟件運行周期偏差，該偏差服從正態分布。同樣的，對CC的運行時序進行建模，設數據包發送時刻為

t

，則總線上第

m

個周期的數據包發送時刻為

(4)

式中：

T

為CC運行第

m

個周期的起始時刻；

φ

=4 850 μs，為CNS_DATA最新數據包發送時刻的小幀偏移；

J

∈(-1 000 ps,1 000 ps)，為服從均勻分布的抖動。

類似地：

(5)

用函數

R

來表示總線完整性檢查結果，當出現虛警時函數值為1，否則為0。根據上文分析及總線完整性檢查原理，函數

R

可以表示為

(6)

其中，case*為

(7)

若在總線完整性檢查當拍及前一拍，上位機時序與總線時序存在式(7)所示關系，系統就會出現虛警故障。總線檢查結果

R

為Δ

P

s,、Δ

P

CC,、

J

和

J

的函數，而上述參數均存在一定的隨機性，這也從根本上解釋了該虛警故障偶發的原因。

3.2 DPRAM雙端口緩沖區讀寫邏輯建模

總線上各節點發送到CC的數據被存儲在CC的DPRAM中，DPRAM存儲器結構如圖7所示。

圖7 DPRAM存儲器結構

雙端口緩沖區存在兩塊存儲區域，分別為緩沖區0和緩沖區1，FPGA第一次接收到消息后，默認將數據填入緩沖區0，同時將緩沖區0中數據包對應的更新標志置為1。第二次接收到消息后將數據存放在緩沖區1中，之后邏輯采用乒乓操作依次向緩沖區0和緩沖區1中寫入數據。CPU獲取總線數據時，將數據從DPRAM中搬運到SDRAM。由于DPRAM首先向緩沖區0中寫入數據，為了避免讀寫沖突，主機在讀取數據時，首先對緩沖區1進行操作，在讀取完數據及其對應的數據更新標志后，將更新標志清零。

4 仿真與分析

使用Inchron工具對3.2節描述的DPRAM讀寫機制進行建模，并根據CC時序與組合導航計算機軟件時序，對系統檢查程序的運行進行100次仿真。在仿真過程中使用真實的系統參數，其中

n

=120。

在100次試驗中，有28次出現了如圖8～圖9所示的情況，由于下個周期的數據包尚未到來，上位機軟件連續兩次讀取DPRAM中同一片緩沖區，導致第二次讀取緩沖區數據更新標志為0，引起虛警。

圖8 單次總線完整性檢查試驗結果(a)

圖9 單次總線完整性檢查試驗結果(b)

為了避免在總線完整性檢查過程中因時序問題導致虛警故障，可以采用如下辦法。

方法一：延長組合導航計算機軟件運行周期或縮短CC總線運行周期。只要節點向總線上傳數據的頻率大于導航計算機獲取數據包的頻率，就可以避免虛警問題。但此方法引起的軟件架構變動較大。

方法二：在現有的總線完整性檢查過程中，CPU每一周期都讀取數據包信息及其更新標志，并在讀取之后對更新標志進行清零操作，而實際上，在執行系統檢查過程中，無需對數據包信息進行處理，因此可以延遲獲取數據包更新標志。具體方法為：在禁止端口后，將DPRAM中的數據讀走，使得兩片緩沖區域中的數據包更新標志均為0，同時只在數據包進行總線完整性檢查當拍讀取DPRAM中的總線數據。如此，假如總線線纜連接故障，那么總線數據包在禁止端口后就無法更新，總線完整性檢查當拍讀到的數據包更新標志為0，即可判斷總線連接故障；如果總線連接完好，那么將DPRAM中的數據讀走后，仍然會有新的數據包發送過來，新的數據包會將數據包更新標志重新置1，在總線完整性檢查當拍讀到數據包更新標志為1，判斷總線連接完好。由于在總線完整性檢查過程中，數據包只讀取一次，虛警可以避免。

方法三：從仿真試驗結果可以看出，連續兩次讀取同一片緩沖區的現象也呈現周期性變化，目前的檢查方法只信任單次數據包更新標志的檢查結果，難以避免偶然性，可以通過多次獲取數據包更新標志的方式，在第一次檢查結束后，延遲5拍第二次獲取數據包更新標志，緊接著再延遲5拍，進行第三次數據包更新標志的獲取，將多次檢查結果進行綜合，只要有一次檢查到數據更新即可認為總線連接完好。

5 結 論

在進行總線完整性檢查時，組合導航計算機與總線控制器時鐘異步導致組合導航計算機軟件相鄰兩周期讀取DPRAM中同一片緩存是系統報出虛警的根本原因。由于總線控制器周期與組合導航計算機的理想運行周期相同，因此在設計初期，此類問題較難發現。本文對基于1394總線網絡的分布式組合導航系統的時序建模與仿真工作對1394總線網絡完整性檢查以及異步系統的時序問題研究具有一定的借鑒意義。