TCN 項目中基于RS-485通信的工程應用研究

徐蔚中

（株洲中車時代電氣股份有限公司，湖南 株洲 412001）

當今列車通信網絡（TCN，Train Communication Network）正朝著高速率、多功能、大數據量等方向飛速發展，與現代社會互聯網應用和信息科技領域的發展趨勢相吻合。目前行業內的TCN 主要是基于多功能車輛總線（MVB，Multifunction Vehicle Bus）和絞線式列車總線（WTB，Wire Train Bus）來實現[1]，并且正朝著基于列車實時數據協議（TRDP，Train Real-time Data Protocol）的以太網通訊網絡（ECN，Ethernet Consist Network）方向發展和推廣。與此同時，在實際的TCN 應用中，由于技術、成本等原因，還可能存在著其他形式的現場總線網絡介質和接口。RS-485 通信就是其中一種，由于其雙絞線式總線成本低廉、抗干擾力較強、傳輸速率較高、便于實現等特點，仍有著較為廣泛的應用。本文將結合工程項目中的實踐經驗，對RS-485主從通信接口轉換技術要點進行研究和分析，形成公式，便于理解其技術要點，并助力于工程應用設計開發。

1 基本原理和項目實踐介紹

實際項目運用的接口示意簡化圖如圖1 所示，主設備Master 和從設備Slave 均有兩個冗余接口（Port1和Port2），接口均為UART（通用異步收發器）。主、從設備上的每個接口均通過RS-485 總線與對方設備的對應接口連接，總線為差分數據傳輸方式，半雙工通信。主、從設備間通過Port1 連接組成通道1，通過Port2連接組成通道2。

圖1 RS-485 主從通信接口示意

需要主從通信雙方協商確定的接口設置主要有表1所示幾項（參數為示例值）。

表1 通信接口主要參數設置

示例為半雙工主從通信機制，僅Master 設備能夠根據應用層協議，輪詢周期每50ms 主動發出一個數據幀，作為通信請求。Slave 設備在收到Master 設備的請求數據幀后，經過呼吸時間延時，根據應用層協議發出響應數據幀進行回復響應[2]。Master 的請求數據幀將同時從通道1 和通道2 發送至Slave 設備，Slave 設備默認從通道1 進行響應回復。Slave 設備如果連續5 個輪詢周期（250ms）內均未收到Master 設備的請求數據幀，則切換至通道2 進行回復響應。若Master 設備在連續10 個輪詢周期（500ms）內均未收到Slave 設備的響應回復，則視為通信異常。

上述UART 接口配置中的數據格式即為RS-485 通信的數據層協議。每次即將開始傳送一個字符時，先發出一位邏輯“0”信號作為起始位，隨后開始數據傳輸（本示例項目為8 位）。奇偶校驗位通過將該bit 位置位為邏輯“1”或“0”，來控制數據中的邏輯“1”的數量為偶數（偶校驗）或奇數（奇校驗），本示例項目不配置奇偶校驗位。

本字符傳輸結束后，隨即發出1 位、1.5 位或2 位高電平，作為字符傳輸結束的標志。由于數據是在傳輸線上定時的，并且每一個設備都有其自己的時鐘，很可能在通信中兩臺設備間會出現細微的不同步現象。因此停止位不僅僅是表示傳輸的結束，并且提供設備收發接口校正時鐘同步的機會，適用于停止位的位數越多，不同時鐘同步的容忍程度越大，但是數據傳輸率同時也越慢。

實際項目中應用層另需雙方定義應用層的數據通信協議，示例Master 設備發送至Slave 設備的請求數據幀協議為30 個字節，Slave 設備發送至Master 設備的響應數據幀協議為10 個字節，幀頭和幀尾標識均為固定值，數據幀的序號為0-255 逐幀增加，累計至255后重新賦值為0，以便區分不同數據幀。CRC 校驗結果為針對B1 至B26/B6 數據的循環冗余校驗結果（具體校驗算法可結合實際確定）。

2 存在的問題與初步分析

在實際項目運用中，發現存在偶發性通信異常問題，導致應用業務故障，獲取實際總線數據發現數據存在錯亂的情況。

正常情況下在50ms 的輪詢周期中，應為Normal所示每個輪詢周期一幀請求數據后跟隨一幀響應數據的情況。而異常情況下，會出現Error 所示三種情形：1、請求數據后跟隨多幀響應數據；2、請求數據后無響應數據；3、數據錯亂，數據幀不完整。

結合基本原理和項目實際情況分析，由于RS-485半雙工通信的特點，總線上同一時間僅能夠供給1 個設備發送數據，所以需采用主從輪詢的方式進行通信[3]。某一設備在檢測到總線上有數據傳輸時，應不允許自身數據發送。若同一時間雙方或多方設備同時發送數據，則在總線上會出現數據碰撞的情況，導致數據錯亂。此處的異常情形3即為主從雙方設備同時發送數據，導致主設備的輪詢數據無幀頭（數據碰撞導致數據錯亂）。異常情形1 為從設備自身未考慮半雙工通信的特點，在收到主設備請求數據后多次重復發送響應數據。異常情形2 為從設備采樣檢測請求數據周期不滿足要求，以及接收到的主設備請求數據錯誤或不完整，導致無法正確發出響應數據。

因此在實際的運用實踐中，需結合通信方式和實際配置的特點，對涉及的接口參數和程序開發形成正確引導[4]，故對此類通信接口的特性展開研究是很關鍵的。

3 細化分析與研究

示例的半雙工主從通信過程示意圖如圖2 所示，描述了一個通用示例周期的主從通信過程。在每個通信輪詢周期中，主設備傳輸完一幀請求數據，且從設備正確接收后，應反饋且僅反饋一次響應數據幀。圖中標出了各個關鍵時間參數，其值為示例值。圖中參數具體含義如表2 所示。

圖2 RS-485 通信過程通用示意

表2 通信過程時間參數說明

由于實際的程序運行和數據傳輸時間等都存在難以避免的誤差，所以實際情況下上述所有參數都是理論值。尤其是主設備的tRound 與從設備的tCheck 之間不可能完全同步，導致二者時間會存在著各種程度的錯位（圖中體現為tCheck 與tRound 開始、結束時間點的錯位），因此需考慮最差情況下的通信情形，以明確tCheck 的參數設置要求。

分析可知，各參數之間應滿足以下關系：

tBlind+n*tCheck+tResponse≤tRound（n ≥1）

tResponse≥tBreath+tAck

另外，理論上tBlind≤tReq，最差情況下出于預留應考慮tBlind ≥tReq。

現擬定擬定tBlind=tReq tCheck，tResponse=tBreath+tAck，可得知tCheck 應滿足：

tCheck ≤（tRound-tBlind-tResponse）/n（n ≥1）

其中tReq 與tAck 需根據通信接口波特率設置、數據傳輸格式和應用層協議數據幀長度進行計算。例如示例項目波特率為38.4kbps，傳輸每個字符（Byte）需消耗1 個起始位，8 個數據位和1 個停止位，共計10bit。請求數據幀為30Byte，響應數據幀為10Byte，可得知傳輸請求數據幀和響應數據幀分別需要7.8125ms 和2.6042ms。

為便于計算與預留時間余量，設定tReq=10ms，tBreath+tAck=10ms，則示例中tCheck 最大設置值（n=1時）應滿足tCheck ≤30ms。且從設備應保證每次正確接收完請求數據后僅發送一幀響應數據。

4 結語

通過對RS-485 通信的原理及應用情景介紹和研究，深入了解了其在實際應用中的實現方式和技術要點，結合工程實踐指出了在工程項目實踐中需要避免的問題點，分析研究了通信接口應用參數的關系，最終以公式化的形式總結出其限制條件，對應用開發形成了引導性結論。在應用實踐中可參考本文內容進行設計和問題排查，避免工程應用中出現設計問題導致的通信故障和功能缺陷，提高應用工程的效率和穩定性，保障實踐應用的安全。