基于RS485總線的起落架控制系統實時通信算法實現

，

(中航飛機起落架有限責任公司，長沙 410200)

0 引言

隨著全新的多電/全電飛機技術的深入研究及其在多種機型中的驗證與實際應用，推動了飛機起落架系統的收放裝置、前輪轉彎以及機輪剎車等重要功能部件從傳統的液壓機械式控制向數字電子控制的方式轉變。數字電子控制方式有效的實現了飛機重量減負，同時也提升了起落架控制系統的響應速率和靈活性。研究實現具有高可靠、高安全性的機載起落架控制系統成為迫切需要解決的問題。

數字電子控制系統由于其電子器件固有的失效概率，在實際系統的設計中主要采用功能部件的冗余部分及有效管理來彌補其不足。系統工作時，冗余部件分別正常的獨立工作，任意時刻僅有一個部件完成系統輸出控制。冗余部件間能夠對彼此間的重要信息進行共享、監控及功能故障時重構，必然要求有高效、可靠的數據通信作為基礎支撐。

RS485作為一種串行通信接口，具有傳輸距離較長、速度較高、低成本、可靠度高等特點，已在智能管理[1]、在線控制[2]等眾多領域中都有著廣泛的應用[3]。RS485提供并保障了硬件層面Bit位數據傳輸的可靠性，應用系統則可以在利用RS485總線組建主從式或總線式通信網絡的基礎上，再進行應用邏輯層面的通信協議/算法的設計和實現，可以有效提高應用系統的靈活性，同時也滿足了實際應用需求的便捷性。

本文以AG600水陸兩棲飛機的起落架系統綜合試驗平臺為基礎，針對多路傳感器信息采集與傳輸、主備單元之間信息重構、邏輯解算和驅動控制的信息共享需求，組建了一種RS485主從式通信網絡，實現了以幀為單位的數據解析算法，并在此基礎上進行了以幀元為單位的算法優化設計和實現。試驗驗證表明，該算法具備較好的實時性，滿足起落架控制系統的實時通信控制需求。

1 控制系統總體架構

起落架控制系統總體架構設計如圖1所示。

圖1 起落架控制系統總體架構

控制系統主要由主控單元(主控1路、備控1路)、驅動單元(前起驅動主驅1路、前起驅動備驅1路、左主起驅動主驅1路、左主起驅動備驅1路、右主起驅動主驅1路、右主起驅動備驅1路)共8路組成。

1.1 主控單元

作為控制系統的核心調度部件，主控單元實現的主要功能及工作原理：

1)負責接收和響應飛控主機下達的收放控制及系統工作狀態監控指令；

2)將接收的控制指令轉化為實際需要執行的驅動指令，下達給各相關驅動單元；

3)接收各驅動單元反饋的邏輯解算及狀態信息；

4)對各驅動單元的反饋信息進行綜合，執行起落架系統級控制邏輯解算；

5)將飛控主機的指令執行及控制系統的健康狀態通過ARINC429總線反饋給飛控主機；

6)默認狀態下，主控單元正常工作輸出，備控單元正常工作但不輸出控制信號，僅在主控單元出現故障時才接管輸出控制。

1.2 驅動單元

作為控制系統的執行驅動部件，驅動單元實現的主要功能及工作原理：

1)負責接收主控單元下達的驅動指令和單元工作狀態監控指令；

2)將接收的驅動指令轉化為實際需要執行的驅動指令；

3)負責完成所連接的位置傳感器信息采集及傳感器校準，連接的傳感器包括前起驅動主/備單元各7路，左主起驅動主/備單元各6路、右主起驅動主/備單元各6路，共38路(7×2+6×2+6×2)；

4)進行驅動單元級邏輯解算，驅動作動部件完成驅動功能；

5)將主控單元下達指令的執行情況及驅動單元自身的健康狀態通過RS485總線反饋給主控單元；

6)默認狀態下，主驅單元正常工作輸出，備驅單元正常工作但不輸出控制信號，僅在主驅單元出現故障時才接管輸出控制。

1.3 數據通訊與共享

1)主控單元與飛控主機之間通過ARINC429總線(采用總線及通信協議由飛控主機方確定)進行通信，具體的ARINC429總線信息可參考文獻[4]做進一步的詳細了解；

2)主控單元與各驅動單元通過RS485總線進行控制命令(包括起落架收指令、起落架放指令、應急放指令)及健康狀態(包括傳感器工作狀態、系統上電自檢測PBIT、周期/連續自檢CBIT等)以及系統告警指示等信息的傳輸；

3)主控單元和驅動單元各自的主、備單元之間通過共享RAM方式進行信息的重構且互為備份；

4)系統設置主位置(硬件板塊插接位置)、單元工作有效兩個狀態標識位用以識別主/備單元，當系統識別出兩個標識位都有效時才確定其為主單元，否則識別為備份單元，具體的有效性由相應的CPLD硬件仲裁確定。

2 通信算法設計

對于應用系統而言，RS485串行通訊標準定義了電壓、阻抗等內容，但不對軟件協議給予定義，它通過對起始、停止電平的檢測與轉換，加上奇偶校驗以及硬件握手信號等，實現并保障了通信的可靠性，其提供服務的僅僅是面向Bit位的基礎通信，要實現應用系統的業務邏輯，特別是在主從式、總線型通信架構中多設備之間進行通信時，必然需要通過自定義的通信協議來實現，即本文所指的面向應用系統業務邏輯的通信算法。

2.1 幀結構定義

針對起落架控制系統的通信需求，每次通信的數據長度為15個字節(包括數據的頭、尾標識信息)，本文在參考文獻[5-7]中幀格式設計的基礎上，簡化設計了如圖2所示固定長度的幀結構。

圖2 幀結構定義

幀結構主要由6部分組成：

1)幀頭：表示一幀數據的開始，用于同步控制，系統默認設定為0xAA，長度為1字節；

2)目的ID：表示各主備單元分配的ID號，表明該幀數據的接收者，取值范圍(0～7，255)，其中255為廣播ID，僅由主控單元發起單元BIT、故障復位等特殊指令時使用，長度為1字節；

3)源ID：表示各主備單元分配的ID號，表明該幀數據的發送者，取值范圍(0～7)，長度為1字節；

4)傳輸數據：內容為要傳輸的數據，長度固定為10個字節；

5)控制位：表示該源ID發送的數據是控制輸出/備份輸出的標識，長度為1字節；

6)幀尾：表示一幀數據的結尾，系統默認設定為0x55，長度為1字節。

2.2 單幀解析算法

所謂單幀解析算法是指在待解析數據中同時存在數據頭、數據尾且數據長度符合幀長度要求時，即為解析出完整的數據幀。

針對系統中每幀數據長度為15個字節，采用循環緩沖區結構(數據緩沖區大小64字節，最多同時緩存四幀數據)實現接收數據的存儲。設計使用的數據指針包括：新數據指針NIdx、數據訪問指針AIdx，幀有效標識Fflag(初始時為假)。

1)數據接收采用中斷方式，流程如圖3所示，基本思想如下。

圖3 中斷數據接收流程

a)接收到新數據，判斷幀頭標識，為假轉到b)，為真轉到c)；

b)判斷新數據是否為幀頭，是則置幀頭標識為真，轉到d)，否則轉到e)；

c)判斷單元ID檢測標識，為假則判斷該數據是否與當前單元ID或為255，是則單元ID檢測標識為真，轉到d)，否則轉到b)；

d)將新數據添加到數據緩沖區NIdx位置，NIdx增1，中斷返回；

e)丟棄當前新數據，中斷返回。

2)單幀解碼算法采用定時器方式周期處理，流程如圖4所示，基本思想是：

圖4 單幀解析流程

a)判斷緩沖區的有效數據長度≥15(幀長)?是則轉到b)，否則轉到e)；

b)判斷數據緩沖區AIdx增14處數據是否為幀尾標識，是則轉到c)，否則轉到d)；

c)置Fflag為真，返回實際數據，AIdx增15，轉到e)；

d)置Fflag為假，在數據緩沖區中檢索幀頭，存在則置AIdx增x(x為幀頭位置計數)，轉到a)，否則置AIdx為NIdx，轉到e)；

e)函數退出。

注：算法中增x操作是指數據加x后取模64的操作。

2.3 通訊策略

起落架控制系統中采用主控單元接收飛控機的指令(指令頻度10 Hz)，再下達給驅動單元執行的模式工作(控制頻度20 Hz)。控制系統設定任意一次通訊均由主控單元(主)發起，驅動單元(主、備)應答反饋的時間片輪轉方式，主要包括：

1)主控單元(主)向驅動單元(主/備)發起通信指令；

2)驅動單元(主/備)接收到主控單元(主)的通信指令后，進行信息打包并反饋。

采用時間片輪轉的主從應答方式，避免了通信總線的訪問沖突。

3 算法優化設計

3.1 單幀解析算法分析

采用時間片輪轉的主從應答方式，帶來了系統一定效率的損失。對主控單元而言，單次完整的通訊涉及驅動單元的主/備各3個共6次通信，按控制頻度20 Hz(50 ms)、通信3 ms/時間片來計算，用于通信的CPU實際占用率為6×3/50×100%=36%，對于系統本身的實時性要求而言，能夠滿足實際應用要求。

由單幀解析算法可知，算法處理的是定長數據，把整個通信數據的處理分成兩個環節：串口中斷數據接收和目的ID驗證、幀內傳輸數據的驗證提取。

改進思路是：將數據驗證提取歸并到串口數據接收的同時進行，即數據接收的同時進行幀元數據的驗證提取。此外，為了提高算法的靈活性，將定長數據變更為變長數據，同時加強了幀數據的有效性校驗方式。

3.2 變長幀結構定義

在圖2中幀結構定義的基礎上，設計的變長幀結構定義如圖5所示，由7部分組成。

圖5 變長幀結構定義

1)數據長度：表示該幀傳輸數據的字節數，長度為1字節；

2)幀尾：將系統默認設定的0x55變更為傳輸數據的校驗和(累加，取反，加1，取低7位；或為數據字節的異或操作)，長度為1字節。

3)其余各字段與圖2中所述的含義相同。

3.3 幀元解析算法

幀元解析算法采用串口中斷函數實現，在串口數據接收的同時進行幀元數據的校驗和提取，算法用到的數據結構與單幀解析算法相同，當前驗證標識Vtag初始化為幀頭，流程如圖6所示。

圖6 幀元解析算法流程

基本思想是：

a)接收到新數據，將其添加到數據緩沖區NIdx位置，NIdx增1；

b)判斷數據緩沖區是否有新數據(AIdx≠NIdx)，有則轉到c)，否則轉到l)；

c)臨時存儲AIdx到TIdx；

d)判斷Vtag是否為幀頭，是則轉到e)，否則轉到f)；

e)在數據緩沖區中檢索幀頭，存在則置AIdx增x+1(x為幀頭位置計數)，置Vtag為目的ID，轉到f)，否則置AIdx為NIdx，轉到l)；

f)判斷Vtag是否為目的ID，是則轉到g)，否則轉到h)；

g)判斷數據緩沖區AIdx位置數據是否為本單元ID或255，是則置Vtag為數據有效性，AIdx增2，轉到h)，否則置Vtag為幀頭，轉到b)；

h)判斷Vtag是否為數據有效性，是則轉到i)，否則置Vtag為幀頭，轉到b)；

i)按照設定的校驗方式對當前數據進行校驗處理，AIdx增1，判斷是否完成該幀中指定數據長度的數據，是則轉到j)，否則轉到b)；

j)判斷實際校驗結果與校驗位是否一致，是則轉到k)，否則置Vtag為幀頭，置AIdx=TIdx+2，轉到b)；

k)置Fflag為真，返回實際數據，AIdx增2；

l)中斷返回。

3.4 試驗驗證

試驗驗證以AG600水陸兩棲飛機起落架系統的綜合試驗平臺為基礎，由主控、驅動共8個單元的冗余控制結構組成，組建了RS485主從式通信網絡，采集處理的信號包括傳感器38路、電磁閥3路驅動控制、前起落架和左右主起落架共3路電機驅動控制信號以及各主控和驅動單元的電壓、CPU工作狀態、流程關鍵環節的監測及系統周期BIT等。

對主控單元而言，單次完整的通訊涉及驅動單元的主/備各3個共6次通信。

1)系統控制頻度設定為20 Hz(50 ms周期)時：

a)單幀解析算法采用通信3 ms/時間片輪轉，用于通信的CPU實際占用率為6×3/50×100%=36%，消耗時間實際為固定時間片輪轉所需間隔周期；

b)幀元解析算法用于通信的時間主要為中斷響應和處理時間，其消耗的時間為指令取指、譯碼及存貯等指令執行周期，無時間片輪轉等待周期，實時性自然好得多。

經在實際的硬件平臺中加以驗證比較后，兩種算法均滿足實時性要求。

2)系統控制頻度設定為50 Hz(20 ms周期)時：

a)單幀解析算法采用通信改為2 ms/時間片輪轉，用于通信的CPU實際占用率為6×2/20×100%=60%，嚴重影響了傳感器數據采集、電機驅動控制的周期執行，系統實時性無法保證；

b)幀元解析算法保持性能不變，滿足實時性要求。

經在實際的硬件平臺中加以驗證比較后，幀解析算法出現數據包丟失，系統控制響應慢等現象，幀元解析算法保持了較好的實時性。

顯然，從兩種算法的實現思想進行分析比較，幀解析算法采用固定時間片、固定數據長度，且數據通信和數據提取處理相互單獨，順序進行，系統效率過多的消耗在時間片輪轉等待中，而幀元解析算法則采用在數據接收的同時完成了數據的驗證提取，通訊時間基本上是物理鏈路所需的信息傳輸時間，且兩次通信間無等待間隔，對傳感器數據采集、電機驅動控制的周期執行無影響，系統實時性較好，滿足系統裕度要求。

4 結論

本文通過以AG600水陸兩棲飛機起落架系統的綜合試驗平臺為基礎，組建了RS485主從式通信網絡，設計和實現了幀解析的通信算法，并在此基礎上進行了分析和優化，實現了基于幀元數據的解析通信算法，在實際的綜合試驗平臺上進行了驗證，結果表明滿足實際的應用需求。其中，在主備單元之間的信息傳輸重構上，采用了文獻[8]中類似的硬件支持的共享RAM方式，在后續的工作中可以考慮直接采用主從網絡通信來實現，如參考文獻[7]中1-堅持型退避算法、文獻[9]中類似于以太網的載波監聽多路訪問/沖突檢測協議(CSMA/CD)來解決通信總線的沖突檢測問題，借鑒文獻[10]中所述BIT可靠性的軟硬件設計方法來進一步提高通信的可靠性。