賈海航,，趙霞

　?。ㄍ瑵髮W 電子與信息工程學院，上海 201804）

       摘要：RS485總線經(jīng)常被用做主從系統(tǒng)各節(jié)點間的通信方式,，系統(tǒng)中主從機的通信狀態(tài)是整個系統(tǒng)正常工作的前提,。文章設計了一種基于RS485總線的從機故障檢測方法。首先根據(jù)需求設計了一套穩(wěn)定的網(wǎng)絡通信協(xié)議和接口函數(shù),，并提出了一種基于RS485網(wǎng)絡通信協(xié)議的輪詢方法,，可實現(xiàn)一個主機可靠、穩(wěn)定地輪詢訪問多個從機,。主機能夠檢測各個從機的通信狀況,，并及時將從機通信故障信息上報到上位機。文章提出的在輪詢基礎上進行故障檢測的方法,，大大提高了系統(tǒng)的實時性,。

　　關鍵詞：RS485；輪詢,；故障檢測

　　中圖分類號：TP29文獻標識碼：ADOI： 10.19358/j.issn.1674-7720.2017.07.001

　　引用格式：賈海航,，趙霞.基于RS485總線的GSM-R從機故障檢測設計及實現(xiàn)［J］.微型機與應用，2017,36（7）：1-4,，8.

0引言

　　圖1GSM-R鐵路無線數(shù)字通信系統(tǒng)隨著鐵路列車運行速度的不斷提升,，通信系統(tǒng)對于鐵路的安全運行越來越重要。鐵路綜合數(shù)字移動通信系統(tǒng)（Global System for Mobile Communications-Railway,，GSM-R）是一種基于當前世界最成熟,、最通用的公共無線通信系統(tǒng)GSM平臺，專為滿足鐵路應用而設計開發(fā)的無線數(shù)字通信系統(tǒng)［1］,。圖1為GSM-R鐵路無線數(shù)字通信系統(tǒng)結(jié)構(gòu)示意圖,，該系統(tǒng)包括遠端機和近端機兩部分。近端機由時間分布控制單元 (Time Distributed Master Unit,TDMU)及射頻模塊組成,，遠端機由射頻拉遠單元（Radio Remote Unit,，RRU）和射頻模塊組成。TDMU和RRU不僅需要獲取各自射頻模塊的實時信息,，以了解各個射頻模塊的運行狀態(tài),，同時還需將各個射頻模塊的故障信息及時上報到上位機，使射頻模塊得到及時的維護。因此,，TDMU和RRU與各自的射頻模塊之間穩(wěn)定可靠的通信是非常重要的,。

　　常用的串口通信方式包括RS232和RS485。RS232串行通信總線屬于全雙工工作方式,，數(shù)據(jù)的收發(fā)可以同時進行,，但傳輸距離短，且只適合點對點的通信方式,。RS485串行通信總線采用半雙工工作方式,，數(shù)據(jù)的收發(fā)不能同時進行，任何時刻只能有一個主機處于主動發(fā)送狀態(tài),，其他所有從機處于被動接收狀態(tài),，非常適用于一主多從的通信要求［2］。RS485作為一種構(gòu)造簡單,、技術(shù)成熟,、傳輸距離遠的通信方式，得到了廣泛的應用,。

　　在本系統(tǒng)中,，要求TDMU和RRU可以主動訪問射頻模塊，而射頻模塊只能被動接收并響應,。根據(jù)上述需求，采用RS485串行總線作為TDMU和RRU訪問射頻模塊的通信方式,。將TDMU和RRU作為主機,，射頻模塊作為從機，構(gòu)成RS485主從通信系統(tǒng),。上位機通過TDMU來監(jiān)控整個系統(tǒng),。

　　在一些相關文獻中關于RS485總線通信方式的設計都只提到了RS485輪詢過程的實現(xiàn)，但均未考慮從機故障的處理問題,。本文針對在輪詢過程中的從機故障檢測問題,，提出了RS485總線輪詢與從機故障檢測相結(jié)合的實現(xiàn)方法。在本文的設計中,，主機通過RS485總線輪詢各個從機,，獲取從機信息，同時實時檢測從機故障狀態(tài),。

1RS485通信協(xié)議和接口函數(shù)的設計

　　1.1通信協(xié)議

　　RS485接口標準通信協(xié)議需要用戶自己根據(jù)實際情況而設計［3］,。設計一套結(jié)構(gòu)簡單、功能完備,，并且盡量標準化的通信協(xié)議是RS485通信最基本的通信要求,。

　　RS485通信協(xié)議的設計主要包括物理層和數(shù)據(jù)鏈路層［4］。本文使用的VxWorks操作系統(tǒng)通過串口驅(qū)動程序已經(jīng)實現(xiàn)了物理層的所有功能［5］。只需調(diào)用操作系統(tǒng)提供的發(fā)送和接收函數(shù)就可以實現(xiàn)數(shù)據(jù)通信,。本文設計的RS485總線通信協(xié)議主要完成數(shù)據(jù)鏈路層的功能,。

　　數(shù)據(jù)鏈路層的通信協(xié)議［5 6］包括開始結(jié)束標志、設備的類型及地址,、數(shù)據(jù)校驗等,。設置一個開始、結(jié)束標志來表明每一段數(shù)據(jù)幀的開頭和結(jié)尾,。設置一個標志來標識數(shù)據(jù)幀是請求數(shù)據(jù)幀還是應答數(shù)據(jù)幀,。用設備類型和設備地址兩個標志位來區(qū)分不同的從機。數(shù)據(jù)校驗位用來保證數(shù)據(jù)幀的正確性,。除上述單元,，通信協(xié)議還應包括命令標識、數(shù)據(jù)長度等,。

　　根據(jù)以上描述,，設計的通信協(xié)議如圖2所示。

　　開始標志,、結(jié)束標志：表示一幀數(shù)據(jù)的開始和結(jié)束,，本文均用0x7f表示。

　　設備類型：本文中用0x01表示功放,，用0x02表示低噪放,。

　　設備地址：對于同一種從機類型，用設備地址區(qū)分不同設備類型下的不同從機,。例如：對于4個功放（設備類型為0x01）,，設備地址分別為0x00、0x01,、0x02,、0x03。

　　命令標識：表示主機對從機發(fā)送的命令類型,。

　　響應標識：主機主動向從機發(fā)送數(shù)據(jù)用0xff表示,，從機被動響應主機用0x00來表示。

　　數(shù)據(jù)長度：表示具體數(shù)據(jù)的長度,。

　　數(shù)據(jù)校驗：為保證數(shù)據(jù)傳輸?shù)恼_性和完整性,，本文采用CRC校驗碼。CRC校驗碼具有唯一性,。若發(fā)送端與接收端的校驗碼不一致,，則表明數(shù)據(jù)幀的傳輸有誤［7］。

　　1.2接口函數(shù)

　　數(shù)據(jù)鏈路層需為高層提供統(tǒng)一的RS485接口函數(shù),，而接口函數(shù)的設計需要按照上述的網(wǎng)絡通信協(xié)議組包,，調(diào)用底層串口驅(qū)動將數(shù)據(jù)發(fā)送到目的從機并等待接收響應消息。對接收到的數(shù)據(jù)解析，若此響應數(shù)據(jù)完整無誤,，則將需要的數(shù)據(jù)從中解析出來,。在接口函數(shù)的設計中需要考慮數(shù)據(jù)幀的轉(zhuǎn)義、數(shù)據(jù)幀發(fā)送和接收,、接口函數(shù)的保護三方面的內(nèi)容,。

　　（1）在數(shù)據(jù)接收端,，若具體數(shù)據(jù)中出現(xiàn)0x7f的數(shù)據(jù),，在接收端就會影響對完整一幀數(shù)據(jù)的判斷。因此,，在數(shù)據(jù)發(fā)送端要對發(fā)送數(shù)據(jù)進行轉(zhuǎn)義處理,。本文的方法是用0x5f和0x7d兩個字節(jié)的數(shù)據(jù)來代替0x7f，用0x5f和0x5d兩個字節(jié)的數(shù)據(jù)來代替0x5f,；在數(shù)據(jù)接收端進行反轉(zhuǎn)義處理,，與轉(zhuǎn)義處理相反。

　?。?）接口函數(shù)中最重要的就是數(shù)據(jù)的發(fā)送和接收,，本文使用的VxWorks操作系統(tǒng)已經(jīng)完成了底層RS485串口的配置，只需要調(diào)用操作系統(tǒng)提供的發(fā)送和接收函數(shù)就可以實現(xiàn)數(shù)據(jù)通信,。數(shù)據(jù)的發(fā)送函數(shù)Tx485就是將組包好的數(shù)據(jù)發(fā)送到RS485總線上,。RS485接收任務一直監(jiān)聽總線上的數(shù)據(jù)，通過監(jiān)聽數(shù)據(jù)幀中的開始和結(jié)束標志來接收一條完整的RS485數(shù)據(jù),。將一幀完整數(shù)據(jù)發(fā)送到消息隊列,，msgQReceive則從消息隊列中接收數(shù)據(jù)。RS485接口函數(shù)如下：

　　STATUS Port485Send (……)

　　{

　　semTake(sem485RdDone,WAIT_FOREVER);

　　//根據(jù)自定義的數(shù)據(jù)結(jié)構(gòu)進行組包

　　……;

　　//進行轉(zhuǎn)義處理

　　Escape(SendBuf,OutBuf);

　　//發(fā)送數(shù)據(jù)

　　Tx485(OutBuf);

　　//接收響應數(shù)據(jù)

　　msgQReceive (Rx485QId, (char *)RespBuf, LEN_MAX , timeout);

　　//處理響應數(shù)據(jù)

　　Port485_Handle(RespBuf, MsgLen);

　　semGive(sem485RdDone);

　　return OK;

　　}

　　(3)在RS485總線通信中,，同一時刻，只能有一個主機處于發(fā)送狀態(tài),，其他所有從機處于被動接收狀態(tài),，并且從機之間不能相互通信，否則將會引起總線沖突,，無法正常工作［7］,。RS485總線屬于半雙工的通信方式，數(shù)據(jù)的收發(fā)不能同時進行,，數(shù)據(jù)的發(fā)送必須等到上一次數(shù)據(jù)接收完成之后才能進行,。為了滿足上述RS485總線通信的特點，本文需要對RS485接口函數(shù)進行保護,。

　?、賀S485是一主多從的串行總線，每一時刻只能有一個主機發(fā)送數(shù)據(jù)，也即每一時刻RS485接口函數(shù)只能被調(diào)用一次,。為了防止接口函數(shù)被同時調(diào)用,，在接口函數(shù)中增加了信號量的保護。主機在調(diào)用接口函數(shù)時,，必須首先獲取信號量,。如果沒能獲取信號量，說明此刻有其他任務在調(diào)用接口函數(shù),。主機必須等到發(fā)送數(shù)據(jù)結(jié)束釋放信號量后,，才能獲取信號量，調(diào)用接口函數(shù)來發(fā)送數(shù)據(jù),。

　?、赗S485通信屬于半雙工的通信方式，數(shù)據(jù)的收發(fā)不能同時進行,。在實際的需求中,，除了主機不斷輪詢從機之外，上位機也會通過主機向目標從機發(fā)送一些查詢從機數(shù)據(jù)或配置從機參數(shù)的數(shù)據(jù)幀,。主機的輪詢是一直進行的,，而上位機下發(fā)的數(shù)據(jù)幀是隨機的。為了避免輪詢數(shù)據(jù)和上位機下發(fā)的數(shù)據(jù)幀在485總線上沖突,，本文設置一個全局變量作為主機輪詢的開關,。在上位機下發(fā)RS485數(shù)據(jù)幀時，關閉輪詢開關,，主機輪詢從機暫時停止,。當目標從機響應了上位機之后，打開輪詢開關,，主機繼續(xù)輪詢從機,。

2基于輪詢機制的從機故障檢測的設計

　　2.1從機故障檢測的流程

　　圖3是基于輪詢機制的從機故障檢測的設計流程圖。主機每隔800 ms調(diào)用一次RS485接口函數(shù)輪詢從機設備,。若800 ms內(nèi)未收到從機的響應,，則認為此從機通信異常。若連續(xù)異常次數(shù)達到上限,，則主機需要將此從機通信故障信息上報到上位機,。

　　2.2從機故障檢測的實現(xiàn)

　　為了實現(xiàn)主機在輪詢從機過程中檢測從機通信狀況，本文將輪詢機制嵌套于故障檢測任務中,。從機故障檢測任務包括輪詢時間間隔的設計,、故障上報設計、輪詢過程中的從機故障檢測設計,。其中,，輪詢過程中的從機故障檢測是本文的重點,。

　　（1）輪詢時間間隔的設計,。通過看門狗定時器和信號量來實現(xiàn)800 ms的主機輪詢從機的時間間隔,。在一個800 ms的看門狗定時器中，每隔800 ms釋放一次信號量,。

　?。?）故障上報設計。在故障檢測任務中,，Rs485AlmReport是根據(jù)當前狀態(tài)和同步狀態(tài)進行故障上報的函數(shù),。當前狀態(tài)表示從機當前的狀態(tài)，而同步狀態(tài)表示從機的歷史狀態(tài),。若某一從機的當前狀態(tài)是故障狀態(tài),，同步狀態(tài)是正常狀態(tài)，則主機就會向上位機上報此從機故障,。故障檢測任務部分代碼如下：

　　LOCAL void Rs485AlarmManTask(void)

　　{

　　wdStart(TimerId, (int) Timer, (FUNCPTR) Rs485TimerFun, 0); //輪詢時間間隔

　　While(1){

　　semTake(semAlmSampleT, WAIT_FOREVER) ;

　　if(RS485UseSwitch == 0){

　　Rs485AlmCheck( );}//從機故障檢測

　　Rs485AlmReport( );}//故障上報

　　}

　?。?）輪詢過程中的從機故障檢測設計。在故障檢測任務中,，Rs485AlmCheck函數(shù)調(diào)用RS485接口訪問從機設備,。為了便于管理所有從機設備，建立如下從機設備信息的數(shù)據(jù)結(jié)構(gòu)：

　　typedef struct alarm_info{

　　UINT8 AlmIndex;/* index of the device */

　　UINT8 AlarmEna;/* device enable */

　　UINT8 CurAlmState;/* current alarm state */

　　UINT8 SyncAlmState;/* synced alarm state */

　　UINT8(*CommChk) (void); /*detect function */

　　UINT8 AlmRaiseCnt;/* device raise counter */

　　UINT8 AlmIdleCnt;/* device clear counter */

　　} ALARM_INFO;

　　從機設備信息包括從機序列號,、故障檢測使能,、當前狀態(tài)、同步狀態(tài),、故障檢測函數(shù)（輪詢函數(shù)）,、故障統(tǒng)計、正常統(tǒng)計等,。根據(jù)從機設備信息數(shù)據(jù)結(jié)構(gòu)建立ALARM_INFO Rs485Devices［MAX_DEV_NUM］所有從機的信息,。每隔800 ms執(zhí)行一次從機故障檢測函數(shù)，并統(tǒng)計故障的次數(shù),。若故障次數(shù)達到上限,，則等待Rs485AlmReport故障上報函數(shù)將信息上報到上位機。

3故障檢測的優(yōu)化及結(jié)果

　　在實際情況中,，一次從機通信異常不能認為此從機通信故障。在本文中,，規(guī)定某從機連續(xù)4次通信異常,，才能認為此從機通信故障。當從機數(shù)量較多時,，若某一從機通信故障,，主機需要將所有的從機設備輪詢4次后,，才能將從機通信故障檢測出來并上報到上位機。在這種情況下,，主機不能及時將從機通信故障上報到上位機,，造成上位機獲取從機通信狀況非常滯后，系統(tǒng)實時性較差,。主機為了能夠及時將從機發(fā)生故障上報到上位機,，在輪詢下一設備前需做如下判定條件：當主機訪問某一從機時，如果從機通信異常,，則繼續(xù)訪問此從機,，而不是訪問下一個從機設備；當連續(xù)4次通信異常,，主機將此從機的當前狀態(tài)改為故障狀態(tài),，繼續(xù)訪問下一個從機設備。輪詢條件代碼如下：

　　void Rs485AlmCheck(void)

　　{

　　//保持不變

　　……

　　//輪詢條件

　　if(TmpState==Rs485Devices［DevOrder］.CurAlmState）

　　DevOrder+=1;

　　}

　　在從機故障檢測函數(shù)中,，如果實際狀態(tài)與當前狀態(tài)一致,，表明主機已將從機的實際狀態(tài)反饋到從機的當前狀態(tài)，則繼續(xù)輪詢下一個從機設備,。

　　為了說明基于輪詢的從機故障檢測的輪詢條件的優(yōu)化效果,，作如下假設：某一主機下共有7個從機，最壞的情況下,，這7個從機同時發(fā)生了通信故障,。在不加輪詢條件的從機故障檢測中，檢測出第一個從機故障需要0.8×7×3+0.8=17.6 s,，在加上輪詢條件后的從機故障檢測中,，檢測出第一個從機故障需要0.8×4=3.2 s。如圖4是在7個從機同時故障的情況下,，加上輪詢條件前后,，主機檢測出這7個從機故障所需要的時間對比。加上輪詢條件后的檢測方法大大減少了從機故障檢測所需的時間,。

4結(jié)論

　　基于RS485總線的通信協(xié)議和接口函數(shù)的設計保證了主機穩(wěn)定可靠地訪問從機,。從機故障檢測的輪詢機制一方面可以不斷地獲取各個從機的設備信息，另一方面可以檢測從機通信故障,。但是,，當從機數(shù)量較多時，輪詢周期就會變長,，從機的通信故障不能被及時檢測出來,，系統(tǒng)實時性變差。加上了輪詢條件優(yōu)化后的輪詢機制相比傳統(tǒng)的輪詢機制,，實現(xiàn)了快速檢測從機通信故障,。上位機可以及時獲取各個從機的通信狀況,，提高了系統(tǒng)的實時性。

　　參考文獻

　?。?］ 胡威.基于GSM-R的列車無線定位方法探索 ［J］.鐵路通信信號工程技術(shù),2016,13(5):21-23.

　?。?］ 胡文濤. 一種基于協(xié)議的提高RS485實時性的方法 ［J］.現(xiàn)代電子技術(shù),2013,36(18):10-12.

　　［3］ 周鵬,，李艷艷. 提高RS485總線主從通信效率的軟件設計［J］.單片機與嵌入式系統(tǒng)應用,2008,，8(8):70-73.