0 引言

    魚雷罐的主要作用是運輸鐵水, 對煉鐵、煉鋼的生產起著銜接-匹配和協調-緩沖的作用^[1]，是鐵水運輸工作中的重要工具。鋼鐵企業鐵水運輸工作流程包括從高爐出鐵直至鐵水運往煉鋼廠翻完罐，空罐被運回高爐等待出鐵水為止的全過程，需要鐵水運輸調度能夠及時響應生產運行的瞬息變化。然而鐵水調度工作因其工作強度異常大、所需掌控信息量繁多、業務流程復雜、生產波動性大等原因，一直是許多鋼廠信息化工作的難點，特別是對魚雷罐的實時跟蹤問題，更是難點中的重點^[2]。目前，國內對于機車及車輛的準確跟蹤定位主要有兩種方案，一是通過地面物流信息系統推斷車輛位置，該方案需要大量人工干預，成本較低，但是無法準確定位車輛位置，對摘掛鉤數量出現錯誤不能及時發現；二是通過在地面軌道鋪設大量的無源標簽，在每節車輛上安裝標簽閱讀器及無線通信設備，該方案雖然能較準確地定位車輛的位置，但造價成本極其高昂，只有在小型的企業鐵路站才有可能使用這種跟蹤定位方案，無法進行大規模推廣。

    某鋼鐵企業魚雷罐車調度運輸的各種過程數據信息分散于各個系統中，相關各系統獨立運行，需要專業的魚雷罐跟蹤定位系統對現有信息進行有效整合，現有的鐵路物流跟蹤管理系統大部分是靠人工完成，機車的位置通過GPS定位，而每個魚雷罐罐體是無源個體，導致魚雷罐的位置和摘掛情況不明確，不利于提高魚雷罐周轉率和減少人工操作。

    針對以上問題，本文提出了一種基于電子掛接器和車列檢測器（自研設備）的魚雷罐跟蹤算法。通過電子掛接器和車列檢測器把魚雷罐和機車聯系在一起，并使用電子掛接器的自動摘掛算法和點名上傳算法把魚雷罐的當前摘掛情況上傳給車列檢測器，車列檢測器進行點名信息整合，并上傳到機車內信息平臺，機車信息平臺結合多次點名結果得到車列信息，并定位到出故障的電子掛接器。再結合機車的位置信息，推斷出魚雷罐的位置信息，實現魚雷罐的跟蹤和摘掛故障自排查定位。使用C#的windows窗體應用程序^[3]和MapInfo 9.5工具^[4]設計并實現魚雷罐跟蹤系統仿真軟件，以驗證算法的正確性，并找出算法中的不足之處加以修正，使魚雷罐自動掛接和點名上傳過程更加形象地表現出來。

1 算法中的物理模型和相關定義

1.1 電子感應裝置

    電子掛接器(用字母S表示)：S是一種電子感應裝置，具有近距感知、遠距點對點傳輸和廣播的射頻通信功能，并可實現自組網傳輸功能。近距感知距離為0.5 m到2 m之間，遠距傳輸距離大于50 m。實驗室環境下，對兩個掛接器遠距模塊之間和近距模塊之間進行通信測試，采用CRC校驗，丟包率小于1%。S平時處于休眠狀態，收到喚醒信號后，轉為正常工作狀態，如果3個點名周期接收不到喚醒命令，就進入休眠狀態，S進入休眠狀態之后，內部保存的機車信息和掛接信息全部清空。

    車列檢測器(用字母J表示)：J也是一種電子感應裝置，具有遠距傳輸和廣播的射頻通信功能，它通過點名方式對所掛車輛進行判斷，自動采集電子掛接器的掛接信息數據并最終形成一組車列信息，發給機車信息平臺以便實現對機車和魚雷罐的準確定位、跟蹤。

    J和S信息傳遞過程如圖1所示。

    JCt.J表示機車t上安裝的車列檢測器編號。

    JCt.T.S表示機車t上靠近魚雷罐一端安裝的電子掛接器。

    JCt.H.S表示機車t遠離魚雷罐一端的S編號。

    CPi.H.S表示魚雷罐s上靠近機車一端安裝的S的編號。

    CPi.T.S表示魚雷罐s上遠離機車一端安裝的S的編號。

    N(ij)是CPi.T.S和CPj.H.S通過近距感知方式形成的半雙工射頻通信鏈路。

    Fi是魚雷罐CPj上的CPj.H.S和CPj.T.S通過遠距點對點形成的半雙工射頻通信鏈路。

    其中每個魚雷罐和機車兩端的電子掛接器是完全一樣的，只有在啟動點名的時候，根據數據傳輸鏈路方式不同進行標識，把機車t靠近魚雷罐一端的S標識為JCt.T.S，魚雷罐j靠近機車的一端的S標識為CPj.H.S，另一端安裝的S標識為CPj.T.S。一輪點名結束，這些標識清空。

1.2 算法中的相關定義

    定義1： N是近距感知通信鏈路，N(i，j)是CPi.T.S和CPj.H.S通過近距感知方式形成的半雙工射頻通信鏈路，感知距離為2 m。N(i，j)與N(j，i)指同一條鏈路。

    定義2：F是遠距點對點鏈路，Fj是魚雷罐CPj上的CPj.H.S和CPj.T.S通過遠距點對點形成的半雙工射頻通信鏈路，感知距離為20 m。

    定義3：LM是在CPi.T.S的N(i，j)和Fi出現故障時，進行廣播射頻通信鏈路，感知距離為50 m。只用于點名信息的傳輸，且只有CPi.T.S具有LM，CPi.H.S不具有。

    定義4：CM是基于N鏈路的一種近距感知數據傳輸方式，其用于點名信息和掛接信息包的傳遞。

    定義5：LS是基于F鏈路或者LM鏈路的一種遠距點對點數據傳輸方式。

    定義6：Waked_info是由JCt.J通過LM發出的用于喚醒S的喚醒信號。

    定義7：Named_info是由JCt.J發出在各個S之間進行傳遞的點名信息。其格式是m_n，m表示點名類型，m=1代表確認點名(通過CM或LS方式傳遞的點名信息)，m=2代表疑似點名（通過LM傳遞的點名信息）。n表示發出點名信息的J所在機車ID。

    定義8：I是指掛接信息包，I(i，j)是CPi.T.S經過N(i，j)與CPj.H.S形成的掛接信息包，存儲在CPi.T.S內。與其對應的I(j，i)是CPj.H.S經過N(i，j)與CPi.T.S形成的掛接信息包，存儲在CPj.H.S內。每T1時間CPi.T.S與CPj.H.S進行一次N(i，j)握手鏈接，如握手成功，則CPi.T.S和CPj.H.S各自內部形成I(i，j)和I(j，i)，表明CPi(魚雷罐i)和CPj（魚雷罐j）物理上掛接在一起。CPi.T.S與CPj.H.S經過3次握手鏈接都失敗，則更新掛接信息包為I(i，0)和I(j，0)，表示CPj摘鉤作業離去。

    定義9：JC_info是指S從Named_info中提取的機車信息。其格式是m_n，其中m代表機車類型，m=1表示確認機車（從確認Named_info中提取出來的機車信息），m=2表示疑似機車（從疑似Named_info中提取出來的機車信息），n表示機車ID。一個S內部可以保存兩個機車信息。

2 算法設計與分析

2.1 魚雷罐跟蹤算法設計

    如圖2所示，機車開動后，J每0.2 s遠距廣播一次Waked_info，總共發送10次，S收到Waked_info之后，轉為喚醒狀態，并立即通過遠距廣播轉發8次Waked_info。J發送完Waked_info之后等待6 s再發送Named_info。S接收到點名信息后，根據Named_info處理算法來處理Named_info。Named_info經過下傳Named_info算法向列車尾部傳遞下去，直至車尾。同時I通過上傳I算法向列車頭部傳遞到J上，J通過對I的處理，得到車列信息,J將車列信息上傳至機車信息平臺，至此，一個點名周期結束。機車信息平臺結合幾次點名結果得到最終車列信息，并定位出出故障的S。再結合機車的位置信息，推斷出魚雷罐的位置信息，實現魚雷罐的跟蹤和摘掛故障自排查定位。

2.2 點名算法設計

2.2.1 Named_info處理算法

    一個S內可以保存兩個JC_info，記為m1_n1，m2_n2。Named_info處理算法偽代碼如下：

    Begin（算法開始）

    輸入Named_info： p_q；

    IF（m1_n1==0_0）則m1_n1=p_q，并下傳Named_info，同時上傳自身的I；End （算法結束）；

    ELSE IF(m2_n2==0_0)則m2_n2=p_q，并下傳Named_info，同時上傳自身的I；End（算法結束）；

    ELSE IF（n1==q or n2==q）則下傳Named_info，同時上傳自身的I；End （算法結束）；

    ELSE IF(p==2)則拒絕此次點名；End （算法結束）；

    ELSE IF(m1==1 and m2==1) 則拒絕該次點名；End （算法結束）；

    ELSE下傳Named_info，同時上傳自身的I；End（算法結束）。

2.2.2 下傳點名信息算法

    基本思想：當S的N和F鏈路都正常時，Named_info被逐級向下傳遞，否則被廣播出去。算法關鍵部分流程如圖3所示。

    其中注意點是：S以廣播的形式接收到的Named_info時要保存廣播地址，以便上傳I的時候使用LS傳輸方式。

2.2.3 上傳掛接信息包算法

    基本思想：當S的N和F鏈路都正常時，I被逐級向上傳遞。否則通過LS將I廣播至源地址，算法流程如圖4所示。

2.3 算法中的關鍵點以及難點分析

    (1)當N鏈路出現故障時，廣播傳遞Named_info和上傳I的過程中特殊情況處理方案。

    如圖5所示，CPi與CPj之間的N(i，j)鏈路中斷，CPi.T.S進行廣播點名，這樣能保證把點名信息繼續向下傳遞下去，CPj.H.S和CPj.T.S會收到Named_info。但是，CPm.H.S和CPm.T.S也會收到Named_info，若此時 CPm.H.S和CPm.T.S滿足被點名條件，則會接受此次廣播點名，下傳Named_info和上傳I(m，0)、I(m，n)、I(n，m)等掛接信息包，如圖6所示。CPi.T.S不僅會收到I(j，0)、I(j，k)、I(k，j)等掛接信息包,還會收到I(m，0)、I(m，n)、I(n，m)。這些掛接信息包上傳至JCt.J，JCt.J會得到錯誤的車列信息。但是由于機車是一直處于向前運動的狀態，在第2輪或者第3輪點名過程中，CPm.H.S和CPm.T.S就不會被點到名，所以要綜合多次點名結果來提取車列信息中的重復部分，推算出最終的機車掛接信息隊列和是否到達車尾。

    (2)當F鏈路出現故障時，廣播傳遞Named_info和I包的過程中特殊情況處理方案。

    當某個魚雷罐CPj的CPj.H.S和CPj.T.S之間的Fj出現中斷的時候，則通過N(i，j)鏈路要求CPi的CPi.T.S進行廣播點名，接下來就與2.3.1中的處理方法一致了。

    (3)由于點名故障，導致S內部保存的JC_info出現問題的處理方案。

    如圖4所示，當CPm.H.S被兩次錯誤點名之后，再被其自身所在車列的機車廣播點名時，它就不會響應。因為根據Named_info處理算法，其內部保存了兩個JC_info，不再響應其他疑似Named_info，導致CPm.H.S不會被點名。當這種情況出現時，經歷3次點名周期之后即可被解決，因為每個S在3個點名周期之內不處理點名信息，則進入休眠狀態，內部保存的JC_info和I(i，j)被清零。這樣在經過3個點名周期之后，此CPm.H.S又可以重新接收Named_info了。

3 算法仿真

3.1 仿真軟件設計

    本算法仿真軟件是利用C#的Windows窗體應用程序和MapInfo 9.5工具設計出魚雷罐跟蹤系統仿真軟件來進行算法仿真，鐵路鐵軌站場圖由MapInfo軟件繪制而成，MapInfo 含義是“Mapping+Information（地圖+信息）”，即：地圖對象+屬性數據^[5]，是一種數據可視化、信息地圖化的桌面解決方案^[6-8]。本軟件主要采用多線程技術^[9-10]來實現射頻信號的互相傳遞。其系統功能如圖7所示。

    算法仿真界面如圖8所示：圖中第一部分為S各個參數實時顯示結果和Named_info的傳遞過程；其中S編號的格式為r_c_t，其中r代表車輛類型，r=1為此S安裝在魚雷罐上，r=2為其安裝在機車上；c為S所在魚雷罐ID，t為S接收點名時刻的位置編號，t=1為目前S在魚雷罐的H端，t=2為在T端。如1_165_2號S為此S安裝在165號魚雷罐上，目前處于魚雷罐的T端。故障信息格式為e_f，e為故障類型，e=1為N鏈路故障，e=2為F鏈路故障，f為故障魚雷罐ID。如故障信息2_165，為165號魚雷罐上的S出現F鏈路故障。第二部分為系統各個參數預留接口，管理員可以為系統中的參數設置各種值；第三部分為界面的開關控制；第四部分為軟件的核心部分，包括機車放置功能，機車掛接、喚醒、點名等命令發送控制；魚雷罐放置、S障礙預設功能。第五部分是點名結果實時顯示模塊，這些點名結果是需要J向機車信息平臺上傳。第六部分是機車和魚雷罐掛接過程在站場圖中動態顯示部分。

3.2 仿真結果分析

3.2.1 機車喚醒過程

    當機車開動后，首先發起Waked_info，Waked_info得到很快傳播，能使本列魚雷罐都處于喚醒狀態。仿真結果如圖9和圖10，圖9是機車開動之后JCt.J沒有發送Waked_info，各個S的狀態。圖10表示JCt.J發送完Waked_info之后，各個S的狀態。從圖中可以看出，此時各個S的近距和遠距感應都正常，說明每個S都已經被喚醒，且沒有出故障，N狀態為true時，N掛接信息即為S自身的I，N狀態為false時， S自身的I為ID+0_000_0；F掛接信息為參考作用，不會上傳給車列檢測器。圖10中電子掛接器2_035_1的N狀態為false是因為此電子掛接器位于機車車頭部位，即不靠近魚雷罐的一端。

3.2.2 Named_info處理過程

    如圖11和圖12中的JC_info欄所示，在不設定故障的時候，按照Named_info處理算法，JC_info正常處理Named_info。若接收這次點名就把Named_info加入JC_info里面。

3.2.3 Named_info下傳過程

    給系統預設一些在實際運行過程中可能出現的故障，這些故障主要包括魚雷罐T端S近頻故障和遠頻故障、H端S近頻故障和遠頻故障。這些故障出現后，系統會根據下傳Named_info算法和上傳I算法中的故障處理方法進行處理。

    如圖11所示，在不設定故障時，Named_info一步步向下傳遞。如圖12所示，在設定故障時，提前設定1_034_1近頻感知故障， 1_165_2會出現N鏈路故障，進而廣播點名，點名信息變成2_035，當1_034_2收到廣播點名時，繼續向下傳遞Named_info。

3.2.4 掛接信息包上傳過程

    如圖13所示，正常點名時，I經過JCt.J處理顯示車列信息，圖中表明035號機車掛接165號魚雷罐，165號魚雷罐掛接034號魚雷罐，034號魚雷罐掛接078號魚雷罐，078號魚雷罐掛接132號魚雷，132號魚雷罐是車尾。但是當點名過程中，與車輛所在軌道并列的軌道上放置的車輛被車尾廣播點名點到后，傳回來的I經過JCt.J處理顯示車列信息如圖14所示，此時應結合多次點名結果來得到車列信息。

    在點名的過程中設置078號魚雷罐H端S近頻感知故障，導致1_078_1號電子掛接器和1_034_2號電子掛接器N鏈路故障，處理后的點名結果如圖15所示。當N鏈路出現故障時，得到的掛接信息包如圖16所示，得到的車列信息也可能是與魚雷罐所在軌道并列的軌道上放置的魚雷罐被車尾廣播點名點到后造成的，所以通過幾次點名結果就可以推斷出車列信息。經過測試電子掛接器的丟包率為1%，電子掛接器的傳輸為高頻通信，機車信息平臺處理掛接信息包的時間基本上不用考慮，所以每個點名周期都是秒級的，基本上可以實現魚雷罐的實時跟蹤。

4 結語

    本文結合電子掛接器和車列檢測器的各種射頻通信方式，提出了一種魚雷罐跟蹤算法，并設計仿真軟件以驗證算法的正確性。本文算法不僅能得到列車信息，還可以自動排查、定位電子掛接器通信故障和掛摘故障，節省了人力，使鐵水運輸更加方便快捷。列車員實時得到車列信息后，可以對魚雷罐實施合理調度，提高魚雷罐周轉率。目前該算法正在某鋼廠大力推廣使用中，運行穩定。

參考文獻

[1] 黃幫福，賀東風，田乃媛.魚雷罐管理系統的設計與實現[J].冶金自動化，2010，34(4)：16-21.

[2] 楊小燕，崔炳謀.鋼鐵企業鐵水運輸調度優化與仿真[J].計算機應用，2013，33（10）：2977-2980.

[3] JESSE L.Programming C＃3.0[M].USA：O′Reilly Media，2007.

[4] 吳秀琳，劉永革，王利軍.MapInfo 9.5中文版標準教程[M].北京：清華大學出版社，2009.

[5] 鄭貴洲，晁怡.地理信息系統分析與應用[M].北京：電子工業出版社，2010.

[6] 陸垚，孫宏聲，牛立軍，等.基于MapXtreme2005和C#的GIS圖形實現[J].計算機輔助設計，2008，17(6)：38-41.

[7] 彭剛，王艷琴，王濤，等.基于MapInfo與MapX的電子地圖[J].計算機系統應用，2011，20(9)：153-156.

[8] 鹿浩，羅周全.基于MapInfo的礦山通風安全信息系統開發[J].中國安全科學學報，2008，18(2)：125-129.

[9] 許涮，馮山.使用C#語言進行多線程程序設計[J].計算機工程，2003，29(5)：1-3.

[10] 鄭宇生，趙長勝.C#多線程編程技術在數控測井軟件中的應用[J].國外測井技術，2012(4)：71-74.