一種基于FPGA的網(wǎng)絡(luò)串口管理系統(tǒng)的設(shè)計

陳 晨，饒 卿，胡文斌

(中國船舶重工集團(tuán)公司第七二四研究所，南京 211153)

0 引 言

在雷達(dá)系統(tǒng)中網(wǎng)絡(luò)串口是系統(tǒng)內(nèi)部各設(shè)備間傳遞控制命令、狀態(tài)參數(shù)及接收信號的主要方式，需要構(gòu)建以交換機(jī)為中心的雷達(dá)系統(tǒng)內(nèi)部信息交換網(wǎng)絡(luò)。雷達(dá)在執(zhí)行各項功能任務(wù)時由雷達(dá)終端通過網(wǎng)絡(luò)串口向系統(tǒng)各信息處理單元發(fā)送命令報文，各單元依據(jù)接收到的命令報文執(zhí)行各項操作，同時向雷達(dá)終端反饋執(zhí)行結(jié)果和設(shè)備狀態(tài)參數(shù)。因此，信息傳輸?shù)姆€(wěn)定性直接影響雷達(dá)系統(tǒng)各項功能任務(wù)的可靠實現(xiàn)。

某型號雷達(dá)系統(tǒng)內(nèi)部通信網(wǎng)絡(luò)系統(tǒng)由雷達(dá)終端計算機(jī)、網(wǎng)絡(luò)交換機(jī)以及前端設(shè)備配置的多路輸入輸出板(MIO)組成，實現(xiàn)雷達(dá)終端與前端設(shè)備之間的通信。原設(shè)計采用報文即收即回的方式，由于網(wǎng)絡(luò)發(fā)送報文速度快，而串口發(fā)送報文則需要一定時間。在實際應(yīng)用中，當(dāng)終端臺發(fā)送的相鄰兩個報文之間間隔時間過短時，在串口處會出現(xiàn)第1條報文尚未回復(fù)完即需回復(fù)下一條報文的情況，從而導(dǎo)致串口在同一時間發(fā)送兩條報文、出現(xiàn)相互干擾的問題，嚴(yán)重影響了系統(tǒng)工作的穩(wěn)定性。本文通過深入分析該問題的產(chǎn)生機(jī)理，針對問題根源，合理利用系統(tǒng)原有硬件資源，通過對各信息處理單元MIO板內(nèi)部軟件進(jìn)行更改，設(shè)計了一種網(wǎng)絡(luò)串口管理系統(tǒng)。該系統(tǒng)有效解決了報文沖突的問題，實現(xiàn)了雷達(dá)系統(tǒng)內(nèi)部高可靠、高靈活度的報文通信。

1 系統(tǒng)工作原理及問題機(jī)理分析

1.1 系統(tǒng)硬件組成及工作原理

在雷達(dá)內(nèi)部，用于報文傳遞的通信系統(tǒng)主要由3部分組成：雷達(dá)終端、交換機(jī)和雷達(dá)前端。雷達(dá)終端發(fā)出報文經(jīng)交換機(jī)傳送給前端，由前端內(nèi)的MIO板處理。

多路輸入輸出板(簡稱MIO板)主要用于報文的接收處理。板上主要搭載有1塊FPGA和1塊USR-TCP232-ED2網(wǎng)口模塊。FPGA采用Xilinx公司的xc2s200，用于解碼及串并轉(zhuǎn)換等數(shù)據(jù)處理。網(wǎng)口模塊搭載ARM處理器，用來將TCP/UDP數(shù)據(jù)包通過S232/RS485接口實現(xiàn)數(shù)據(jù)透明傳輸。

在系統(tǒng)的普通工作方式下，局域網(wǎng)以交換機(jī)為中心連接終端和前端。在每個前端內(nèi)都配有1塊MIO板。每塊MIO板有不同的IP地址。終端發(fā)送的報文經(jīng)交換機(jī)發(fā)送到MIO板，由網(wǎng)口模塊接收后經(jīng)網(wǎng)絡(luò)串口轉(zhuǎn)換進(jìn)行解碼、報文識別，并校驗無誤后根據(jù)收到的報文類型進(jìn)行處理：(1)將狀態(tài)或故障信息回復(fù)終端，(2)根據(jù)解出的報文內(nèi)容執(zhí)行相關(guān)操作。

在某種型號產(chǎn)品的實際要求中，要求MIO板串口進(jìn)行兩種報文通信串口不僅需回復(fù)收到的報文，每隔一定時間還需主動發(fā)送一條心跳報文至終端，以確認(rèn)所在的信息處理單元處于正常工作的狀態(tài)，工作流程如圖1所示。

圖1 MIO交互式通信流程原理圖

為滿足通信要求，MIO板的工作方式分為以下幾步：(1)接收到控制報文后，對報文進(jìn)行校驗和解碼；(2)當(dāng)校驗成功后，對收到的報文進(jìn)行回復(fù)，(3)每隔1 s，主動向終端臺發(fā)送心跳報文，(4)每次發(fā)送完成后退出發(fā)送狀態(tài)，等待下一次發(fā)送。

1.2 問題機(jī)理分析

由于之前都是采用即發(fā)即收模式，即收到報文后立即發(fā)送，此次采用這種模式通信時終端有時會出現(xiàn)報文識別失敗的情況。通過用抓包軟件在發(fā)送口抓取報文，發(fā)現(xiàn)發(fā)送的回復(fù)報文和心跳報文有時會出現(xiàn)報文混雜。究其原因如下：由于收到報文即回復(fù)，回復(fù)報文具有時間上的不確定性；另一方面，在串口處接收和發(fā)送報文需要一段時間，若在串口回復(fù)報文期間同時開始進(jìn)行心跳報文的發(fā)送，則在發(fā)送串口處就會出現(xiàn)前條報文未發(fā)完就開始發(fā)后條報文的情況，造成報文覆蓋，如圖2所示。

圖2 報文覆蓋示意圖

2 網(wǎng)絡(luò)串口管理系統(tǒng)實現(xiàn)

針對上述問題設(shè)計的網(wǎng)絡(luò)串口管理系統(tǒng)，可以通過對MIO板網(wǎng)口發(fā)送的心跳報文、狀態(tài)報文等的發(fā)送時序進(jìn)行合理控制，以避免報文覆蓋。通過綜合考慮資源優(yōu)化以及降低對終端操作反應(yīng)時間的影響等因素，管理系統(tǒng)由前端內(nèi)的MIO板實現(xiàn)。這樣，一方面可以方便地在不同前端內(nèi)的MIO板中進(jìn)行更改，從而根據(jù)實際要求實現(xiàn)不同前端與終端的傳送，而且彼此之間不會互相影響，提高了通信的獨立性和靈活性；另一方面，它并不占用終端資源，實現(xiàn)了資源的優(yōu)化配置，提高了工作效率。

2.1 報文時序控制設(shè)計

由于在設(shè)計要求中心跳報文每隔1 s發(fā)送一次，發(fā)送周期要求固定，而回復(fù)報文時間相比之下允許有一定范圍內(nèi)的彈性，所以可以對回復(fù)報文時間進(jìn)行設(shè)計：在一個發(fā)送周期1 s內(nèi)，只有在心跳報文發(fā)送的時間段內(nèi)才會占用串口，影響報文回復(fù)。所以，可以將這一時間段作為繁忙時間段，進(jìn)行專門處理：即在這期間，串口只用于發(fā)送心跳報文，若接收到報文，暫時禁止使用串口回復(fù)，直到繁忙時間段過后進(jìn)入空閑時間段再進(jìn)行回復(fù)。

在程序中，可以用回復(fù)使能實現(xiàn)：設(shè)心跳報文發(fā)送周期為T，心跳報文的周期零點為0，一條報文通過串口完整發(fā)送出去的時間為t，則在每個周期T里[0，t]為當(dāng)前周期報文發(fā)送期，[T-t，T]為下一周期報文發(fā)送準(zhǔn)備期。將這兩個時間段作為繁忙時間段。在這期間，將回復(fù)使能置0，在其他時間段，將回復(fù)使能置1。當(dāng)報文接收結(jié)束后，若發(fā)送使能為1，在進(jìn)行回復(fù)之前判斷回復(fù)使能，若為0則不回復(fù)，若為1則正?；貜?fù)。這樣，整個發(fā)送步驟為：(1)判斷接收使能：為1則接收報文開始校驗，若校驗成功則進(jìn)入步驟2，失敗則丟棄報文；為0則不接收報文；(2)判斷發(fā)射使能：為1則進(jìn)入步驟3，為0則停留在步驟2繼續(xù)等待；(3)判斷回復(fù)使能：為1則執(zhí)行回復(fù)，為0則停留在步驟3繼續(xù)等待。程序框圖如圖3所示。

圖3 網(wǎng)絡(luò)串口管理系統(tǒng)程序框圖

對于繁忙時間段的確定，需要計算一段心跳報文完整的發(fā)送時間t。在圖4的時序圖中可以看出，可以將這個過程分為兩個階段：周期零點到寫命令下降沿的時間t1，串口發(fā)送報文字節(jié)串的時間t2。而t1又分為兩個時間段：發(fā)送使能置1之前的時間t11，發(fā)送使能置1之后的時間t12。t11包含了延遲的多個工作時鐘耗時，延遲的脈沖數(shù)為N1，t12包含了網(wǎng)口模塊的寫信號使能的延遲時間，延遲的脈沖數(shù)為N2。若系統(tǒng)中工作時鐘的頻率為f，則t11=N1/f，t12=N2/f。對于t2，設(shè)報文總字節(jié)數(shù)為L，波特率為B，則t2=L/B。這樣，可計算出：

t=t1+t2=(N1+N2)/f+L/B

(1)

圖4 報文發(fā)送時序圖

在此通信系統(tǒng)中，心跳報文發(fā)送周期為1 s，F(xiàn)PGA的工作時鐘為153.6 K，N1=3，N2=5，L=17，B=9 600，代入公式(1)，計算出t=1 823 μs?？蓳?jù)此確定，在一個周期內(nèi)，繁忙時間段為{[0～1.823 ms]，[998.177～1 000 ms]}。

2.2 延時影響

在整個通信系統(tǒng)中，網(wǎng)絡(luò)串口管理系統(tǒng)僅對一個發(fā)送周期內(nèi)繁忙時間段的報文回復(fù)進(jìn)行了延時，其余時間段均完成實時回復(fù)。在繁忙時間段內(nèi)，延時會使得終端的報文接收時刻滯后，因此需要分析其造成的影響。

經(jīng)計算，在每個1 s內(nèi)，繁忙時間段為3.646 ms，占總時間長為3.65%；在繁忙時間段內(nèi)，最長延時時間為3.65 ms。由于在終端臺上，對MIO板的控制報文的發(fā)送是通過按鍵完成。據(jù)統(tǒng)計，人類單次按鍵反應(yīng)時間基本在100 ms左右，故此網(wǎng)絡(luò)串口管理系統(tǒng)造成的回復(fù)報文的延時時間遠(yuǎn)小于報文發(fā)送的按鍵反應(yīng)時間。所以，無論從延時時間段還是最長延時時間來看，網(wǎng)絡(luò)串口管理系統(tǒng)的延時都不會影響報文通信質(zhì)量。

3 系統(tǒng)驗證

用改進(jìn)后的網(wǎng)絡(luò)串口系統(tǒng)進(jìn)行報文通信，使用TCP&UDP測試工具驗證其效果：由計算機(jī)模擬雷達(dá)終端計算機(jī)前端設(shè)備MIO板模擬發(fā)送控制命令報文，采用自動發(fā)送的方式每隔10 ms發(fā)送一次狀態(tài)檢測報文，同時MIO板自動發(fā)送心跳報文，時間間隔1 s。在TCP&UDP測試工具接收區(qū)觀察測試工具監(jiān)測到的串口的報文發(fā)送情況。結(jié)果顯示，連續(xù)發(fā)送1 000條控制命令報文均發(fā)送成功，并未與心跳報文出現(xiàn)混雜，成功率為100%。之后，在接入雷達(dá)通信系統(tǒng)后該系統(tǒng)能正常工作，再未出現(xiàn)報文混雜覆蓋情況。

4 結(jié)束語

本文從實際雷達(dá)網(wǎng)絡(luò)串口通信系統(tǒng)入手，根據(jù)雷達(dá)對內(nèi)部交互式通信的高可靠性要求，在系統(tǒng)原有資源基礎(chǔ)上利用前端設(shè)備包內(nèi)MIO板設(shè)計實現(xiàn)了一種網(wǎng)絡(luò)串口管理系統(tǒng)，為進(jìn)一步提升交互式通信穩(wěn)定性提供了設(shè)計思路。