賈海航，趙霞

　　（同濟(jì)大學(xué) 電子與信息工程學(xué)院，上海 201804）

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

　　關(guān)鍵詞：RS485；輪詢；故障檢測

　　中圖分類號：TP29文獻(xiàn)標(biāo)識碼：ADOI： 10.19358/j.issn.1674-7720.2017.07.001

　　引用格式：賈海航，趙霞.基于RS485總線的GSM-R從機故障檢測設(shè)計及實現(xiàn)［J］.微型機與應(yīng)用，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）是一種基于當(dāng)前世界最成熟、最通用的公共無線通信系統(tǒng)GSM平臺，專為滿足鐵路應(yīng)用而設(shè)計開發(fā)的無線數(shù)字通信系統(tǒng)［1］。圖1為GSM-R鐵路無線數(shù)字通信系統(tǒng)結(jié)構(gòu)示意圖，該系統(tǒng)包括遠(yuǎn)端機和近端機兩部分。近端機由時間分布控制單元 (Time Distributed Master Unit,TDMU)及射頻模塊組成，遠(yuǎn)端機由射頻拉遠(yuǎn)單元（Radio Remote Unit，RRU）和射頻模塊組成。TDMU和RRU不僅需要獲取各自射頻模塊的實時信息，以了解各個射頻模塊的運行狀態(tài)，同時還需將各個射頻模塊的故障信息及時上報到上位機，使射頻模塊得到及時的維護(hù)。因此，TDMU和RRU與各自的射頻模塊之間穩(wěn)定可靠的通信是非常重要的。

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

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

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

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

　　1.1通信協(xié)議

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

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

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

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

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

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

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

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

　　響應(yīng)標(biāo)識：主機主動向從機發(fā)送數(shù)據(jù)用0xff表示，從機被動響應(yīng)主機用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ù)的設(shè)計需要按照上述的網(wǎng)絡(luò)通信協(xié)議組包，調(diào)用底層串口驅(qū)動將數(shù)據(jù)發(fā)送到目的從機并等待接收響應(yīng)消息。對接收到的數(shù)據(jù)解析，若此響應(yīng)數(shù)據(jù)完整無誤，則將需要的數(shù)據(jù)從中解析出來。在接口函數(shù)的設(shè)計中需要考慮數(shù)據(jù)幀的轉(zhuǎn)義、數(shù)據(jù)幀發(fā)送和接收、接口函數(shù)的保護(hù)三方面的內(nèi)容。

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

　　（2）接口函數(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接收任務(wù)一直監(jiān)聽總線上的數(shù)據(jù)，通過監(jiān)聽數(shù)據(jù)幀中的開始和結(jié)束標(biāo)志來接收一條完整的RS485數(shù)據(jù)。將一幀完整數(shù)據(jù)發(fā)送到消息隊列，msgQReceive則從消息隊列中接收數(shù)據(jù)。RS485接口函數(shù)如下：

　　STATUS Port485Send (……)

　　{

　　semTake(sem485RdDone,WAIT_FOREVER);

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

　　……;

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

　　Escape(SendBuf,OutBuf);

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

　　Tx485(OutBuf);

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

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

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

　　Port485_Handle(RespBuf, MsgLen);

　　semGive(sem485RdDone);

　　return OK;

　　}

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

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

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

2基于輪詢機制的從機故障檢測的設(shè)計

　　2.1從機故障檢測的流程

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

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

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

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

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

　　LOCAL void Rs485AlarmManTask(void)

　　{

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

　　While(1){

　　semTake(semAlmSampleT, WAIT_FOREVER) ;

　　if(RS485UseSwitch == 0){

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

　　Rs485AlmReport( );}//故障上報

　　}

　?。?）輪詢過程中的從機故障檢測設(shè)計。在故障檢測任務(wù)中，Rs485AlmCheck函數(shù)調(diào)用RS485接口訪問從機設(shè)備。為了便于管理所有從機設(shè)備，建立如下從機設(shè)備信息的數(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;

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

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

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

　　void Rs485AlmCheck(void)

　　{

　　//保持不變

　　……

　　//輪詢條件

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

　　DevOrder+=1;

　　}

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

　　為了說明基于輪詢的從機故障檢測的輪詢條件的優(yōu)化效果，作如下假設(shè)：某一主機下共有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ù)的設(shè)計保證了主機穩(wěn)定可靠地訪問從機。從機故障檢測的輪詢機制一方面可以不斷地獲取各個從機的設(shè)備信息，另一方面可以檢測從機通信故障。但是，當(dāng)從機數(shù)量較多時，輪詢周期就會變長，從機的通信故障不能被及時檢測出來，系統(tǒng)實時性變差。加上了輪詢條件優(yōu)化后的輪詢機制相比傳統(tǒng)的輪詢機制，實現(xiàn)了快速檢測從機通信故障。上位機可以及時獲取各個從機的通信狀況，提高了系統(tǒng)的實時性。

　　參考文獻(xiàn)

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

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

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