IEC 61850 新型網絡冗余報文捕獲解析工具開發

王 嬌，張惠剛，李廣華，許家浩，遲 翔

(1．南京工程學院，南京市211167;2．南瑞繼保電氣有限公司，南京市211100)

0 引 言

IEC 61850 標準作為變電站自動化領域最為完善的通信標準，推動了一次設備智能化和二次設備集成化的快速發展［1-5］。其最大程度上實現了系統信息模型的統一，通信服務的統一和傳輸過程的統一。但是其未對網絡冗余、安全等重要應用領域做出明確的規定。2008年，IEC SC65WG15 發布了IEC 62439 高可用性自動化網絡協議，提出了幾種典型的網絡冗余技術，包括跨網冗余協議、分布冗余協議、媒介冗余協議、信標冗余協議、并行冗余協議和高可用性無縫冗余協議［6］。隨著IEC 61850 第2 版引入IEC 62439－3 標準中高可用性無縫環網(high seamless ring，HSR)和并行冗余雙網(parallel ring protocol，PRP)，為數字化變電站的通信可靠性、安全性提供了參考性的實現方案［7-8］。目前，大量基于該種協議的網絡構架層出不窮，文獻［9］提出了PRP 的網絡構架，在站控層網絡和過程層網絡均布置為星型雙網。文獻［10］根據HSR技術抵抗單點故障，實現無縫恢復的優勢，設計了應用HSR 的變電站三層通信網絡結構。文獻［11］詳細闡述了PRP 在站級總線中的組網方式，根據冗余丟棄算法、冗余檢測和冗余管理的工作原理設計了PRP 的處理模塊。文獻［12］提出了站內信息網絡結構簡化技術路線和骨干、終端通信網框架建設方案。但是這些設計方案的可行性是否能夠通過驗證，需要一個強有力的監測工具來支撐。本文以Wireshark 開源代碼為基礎，以Visual Studio 2008 為開發平臺，利用C+ +語言編碼，融合GTK 界面設計工具，開發一個捕獲、解析PRP 報文的插件。并通過WinPcap 庫模擬相關設備發包，來驗證PRP 報文插件開發的正確性。

1 并行冗余雙網

1.1 原理分析

并行冗余雙網協議執行冗余的功能指的是在節點處實現雙備用，而不是指網絡，通常利用雙連接節點(double attached node implementing，DANP)可達到冗余效果。

PRP 的環形拓撲結構如圖1 所示。由圖1 可知，一個DANP 連接到2個獨立、并列的局域網，當其作為源端節點發送數據幀到各個局域網中時，發送的數據幀結構中帶有冗余控制監測(redundancy check trailer，RCT)，為目的DANP 節點處的鏈路冗余單元(link redundancy entity，LRE)識別重復報文提供幫助。然后目的DANP 節點在一定的時間內接收各個局域網傳來的數據幀，并通過LRE 處理重復數據幀和管理冗余。

圖1 含有單節點和雙節點的PRP 環形拓撲結構Fig.1 PRP ring topology of with SANs and DANPs

圖1中PRP網絡中含有2 種連接方式:雙連接節點(DANP)和單連接節點(SAN)。其中單連接節點的使用情況和PRP 網絡有很大的不同。PRP 網絡中的SAN 有2 種連接方式:(1)直接連接到局域網中，可通信的范圍只限定在連接在本局域網中的單節點和所有的雙節點;(2)通過冗余盒連接到2個局域網中，它可以和所有的DANP 和SAN 通信。

PRP 網絡中每個節點包含2個以太網總線控制器，具有相同的MAC 地址和IP 地址，因此PRP 基于第2 層網絡協議的網絡拓撲結構，非常適用于GOOSE 報文和SV 報文的傳輸，工程配置相對簡單。

1.2 報文結構

在第二版IEC 61850 －9 －2 中，國際電工委員會第15 工作組提出將網絡冗余配置添加到過程層網絡中。其中，PRP 幀是映射到數據鏈路層，采用ISO/IEC 8802 －3 版本的以太網數據幀，幀的左側標注了字節數，具體格式如表1 所示［13］。

表1 ISO/IEC 8802 －3 幀結構－鏈路冗余:并行冗余雙網Tab.1 ISO/IEC 8802－3 frame format-link redundancy:PRP

表1 ISO/IEC 8802 －3 數據幀中部分字段的含義如下。

(1)目的地址:目的地址長度為6個字節。根據規定，對PRP 的目的地址的前5個字節固定為“01 －15 －4E－00 －01”。

(2)標簽協議標識符:8 位，由802.1Q 標準以太網編碼幀來確定，一般設定為0X8100。

(3)標簽控制信息:8 位，主要涉及到優先級和虛擬局域網。如果數據單元是SV 或GOOSE 報文的話，則優先級為4，其他的報文優先級為1。

(4)應用標識符:16 位，它是由APPID 類型和實際ID 值組成。對于SV 報文APPID 取值范圍為0X40000 ～0X70000。GOOSE 報文分配的取值范圍為0X0000 ～0X3FFF［14］。

(5)長度:16 位，從APPID 開始到APDU 結束。

(6)保留位:保留位1 最高為simulate，當該值設置為1 時，表示采樣值的報文是由測試裝置產生的，而不是來自裝置的配置文件。后面3 位為將來標準設置，一般為0。剩下的12 位與保留位2 合起來構成28 位的“保留安全性”，它是由標準IEC/TS62351－6 定義的。

(7)序列號:16 位，用以標識重復幀。每次從高層發送一幀，序列號加1。

(8)路徑標識符:4 位，由網絡標識符和局域網標識符構成。其中局域網標識符占1 位，確定冗余盒兩端口的接收情況(端口A 為0，端口B 為1)。

(9)幀大小:12 位，前4 位與路徑標識符結合，計算長度從APDU 數據單元開始，一直到PRP 類型結束。

(10)PRP 以太網類型:PRP 報文的以太網類型是由IEEE 的著作權注冊機構進行了注冊，一般是唯一的。PRP 報文的以太網類型為0X88FB。

PRP 報文中的鏈路冗余控制單元由(7)～(10)構成。由于PRP 鏈路冗余控制單元(LRE link redundancy trailer)的加入，可能會超過IEEE801.1D規定的數據最大長度1 522 字節，因此需要網絡內交換節點單元的內部結構支撐這種協議，目前該類裝置研究處于起步階段，開發測試報文的平臺可以為裝置研發提供強有力的支撐。

2 PRP 報文測試工具開發

2.1 開發平臺介紹

Wireshark 是一款強大的網絡協議分析開源的跨平臺軟件［15］，具有簡潔友好的用戶界面。由于軟件底層和界面涉及到許多LINUX 環境配置項，在Windows 系統中編譯Wireshark 還需要以下軟件來輔助:Visual Studio、Python、Cygwin，且采用C + +語言作為主要開發語言。

Wireshark 源代碼的基本結構邏輯上是由5 部分組成［16］。(1)WinPcap 庫文件中數據包監聽設備驅動程序(netgroup packet filter，NPF)在操作系統核心內與網絡接口驅動交互，調用用戶級的packet．dll 和wpacp．dll 來實現報文的捕獲，將捕獲結果傳遞給Capture;(2)Capture 將捕獲的數據儲存在Wiretap 部分;(3)GTK1/2 提供圖形窗口工具，將用戶的輸入信息傳遞出去;(4)Core 綜合協調用戶傳入、傳出的信息;(5)Epan 接收來自Core 傳達的命令，指揮協議解析器，將結果傳送到Core，最后調用GTK1/2 庫文件在界面上顯示［17-18］，如圖2 所示。

2.2 開發測試流程

開發協議解析器主要目標是針對協議部分的各個字段的信息，以一個樹形的結構來劃分各層結構，進行詳細展示。同時，通過過濾規則篩選顯示到數據包列表的主窗口中［19］。將表1 的協議分成4 層:

(1)解析以太網層。前12個字節，包括目的MAC 地址和源MAC 地址，并判斷是否有上層協議封裝。

圖2 Wireshark 結構模塊Fig.2 Wireshark structure block

(2)解析虛擬局域網層。第12 到第14個字節，分析數據優先級和虛擬局域網標識符等。

(3)解析SV 層。數據結構根據裝置發出的類型分辨來解析。同時需要在最后判別是否存在上層協議，通過全局性指針變量跳轉到下一層協議解析引擎句柄。

(4)解析PRP 層。單獨分裂出來，便于后面添加不同的數據報文，同時也有利于到達目的裝置后丟棄PRP 標簽算法的統計，本文主要開發該層解析器。下面介紹如何開發PRP 解析器。

2.2.1 協議注冊初始化

設計的插件與外部實現交互，需要特定的接口來承擔這項任務。其中一個就是函數proto_register_prp 接口，作用是注冊PRP 解析器的協議信息。該函數中囊括了PRP 協議的全名、PRP 協議的簡寫和PRP 協議過濾字符串以及該層字段信息。對字段信息初始化也必不可少，如static hf_register_info hf［］描述PRP 協議字段具體信息，包括路徑標識符、局域網標識符、序列號等，其定義如下:

static hf_register_info hf［］ = {

{＆hf _ prp _ sequence _ nr，{" Sequencenumber"，" prp．sequence_nr"，FT _UINT16，BASE_DEC，NULL，0x00，NULL，HFILL }}，//序列號

{＆hf_prp_path，{" Path"，" prp． path"，FT_UINT16，BASE_DEC，NULL，0xf000，NULL，HFILL }}，//路徑標識

{＆hf _prp_laneid，{" Lane id"，" prp． laneid"，FT _UINT16，BASE_DEC，VALS(prp_laneid_vals)，0x1000，NULL，HFILL }}，//局域網標識

{＆hf_prp_lsdu_size，{"LSDU size"，"prp．lsdu_size"，

FT_UINT16，BASE_DEC，NULL，0x0fff，NULL，HFILL}}，//PRP 幀大小

{＆hf_type，{" Type"，" prp． type"，FT_UINT16，BASE_HEX，VALS(etype_vals)，0x00，NULL，HFILL }}};//PRP類型

然后設置PRP 層報文詳細列表樹根節點static gint * ett［］=＆ett_prp_frame。最后通過函數proto_register_field_array(proto_prp，hf，array_length(hf))完成數組結構的注冊。

2.2.2 注冊切換器

注冊切換器，就是將PRP 解析器掛載到樹形節點中，并形成與外界交互的端口。通過采用函數proto_reg_handoff_prp()生成解析協議的句柄，關聯上下層解析器，根據唯一標識識別協議類型。首先通過create_dissector_handle(dissect_prp_frame，proto_prp)查找到解析該幀的句柄，句柄包含協議的名稱、協議類型和對應解析器等元素，其中dissect_prp_frame 是解析prp 協議報文的函數。利用dissector_add_uint("ethertype"，ETHERTYPE_PRP，prp_frame_handle)將句柄與協議類型關聯;最后根據類型名稱使用g_hash_table_lookup (dissector_tables，name)函數查找相應的解析器列表，準備開始解析。

2.2.3 實際解析處理

實際解析處理，就是對dissect_prp_frame 函數內容具體描述，具體解析如下。

首先設置Wireshark 界面中數據包列表中列protocol 和列Info 的內容。采用函數col_set_str(pinfo － ＞cinfo，COL_PROTOCOL，"PRP")在數據列表中的縱向欄中設置需要顯示的列表信息，之后創建協議樹的詳細信息。將PRP 標簽中的路徑標識符、網絡標識符和局域網通過proto_tree_add_item()函數添加到子協議樹，將給定報文大小與實際報文比較。如果兩者相等，則繼續將該節點添加到子協議樹中。反之，在子協議樹中添加判斷的結果，并顯示正確的數值。接著重復使用proto_tree_add_item()函數設置序列號、類型等，其代碼如下:

ti = proto_tree_add_item(tree，proto_prp，tvb，0，PRP_TOTAL_LENGTH，ENC_NA);

prp_tree = proto_item_add_subtree(ti，ett_prp_frame);

proto_tree_add_item(prp_tree，hf_prp_sequence_nr，tvb，2，2，ENC_BIG_ENDIAN);

proto_tree_add_item(prp_tree，hf_prp_netid，tvb，4，2，ENC_BIG_ENDIAN)。

3 開發結果驗證

WinPcap 網絡開發包是一個免費的，基于Windows 平臺下的工業標準工具。它可以實現網絡報文監聽、抓捕、過濾、發包以及網絡流量統計［20］。利用WinPcap 發送數據幀模擬裝置發包，利用已開發好的工具捕捉該類報文，最后可以驗證工具的可行性，具體流程如圖3 所示。通過pcap_findalldev()函數獲取設備列表，根據列表顯示的內容選擇合適的網卡序列號。利用pcap_open_live()打開網卡，其中內部延遲參數設定要稍長些，因為工具使用的是主線程抓包。按照報文格式設置主要數據后，最后利用pcap_sendpacket()發送出去。查看測試工具中是否有該類報文。其中，數組packet 中數據組字符為16進制編碼，編碼分解結果如表2 所示。

表2 編碼分解結果Tab.2 Coding decomposition results

發送報文后，從軟件截取到解析報文的測試結果如圖4 所示。

由圖4 可知，該結果符合圖2 要求的格式。因此，解析報文工具設計正確。

圖3 發送報文流程圖Fig.3 Flow chart of packet sending

圖4 PRP 數據包解碼示意圖Fig.4 Analysis of PRP data packet

4 結 語

本文根據IEC 61850 最新發布的網絡冗余方案預先設計出解析該類報文的插件，詳細地分析該類報文產生機理和最新IEEE802－3 報文格式(含有PRP 的LRE)，采用分層解決思路，簡單概括解析報文的流程。通過在Visual Studio 平臺下搭建以WinPcap 庫文件為核心的模擬裝置，并利用其設備驅動(NPF)和一組動態連接庫(DLL)發送報文來驗證測試工具設計的可行性，為未來設計相關類裝置提供強有力的監測工具。

［1］梁俊斌，張煒，鄧雨榮，等． 智能化變電站監測數據現場并行處理技術研究［J］． 電力建設，2013，34(2):35-40．

［2］李敬如，宋璇坤，張祥龍，等． 智能變電站一、二次設備集成技術［J］． 電力建設，2013，34(6):16-21．

［3］曹亮，陳小衛，肖筱煜． 新一代智能變電站二次設備集成方案［J］． 電力建設，2013，34(6):26-30．

［4］高磊，張鵬，陳久林，等． 智能變電站一體化集成測試平臺設計［J］． 電力建設，2013，34(6):31-35．

［5］宋璇坤，劉穎，孫佳，等． 新一代智能變電站一體化信息平臺設計［J］． 電力建設，2013，34(9):21-25．

［6］謝志迅，鄧素碧，臧德揚．數字化變電站通信網絡冗余技術［J］．電力自動化設備，2011，31(9):100-103．

［7］International Electro Commission． IEC 62439 SC 65C High availability automation networks［S］． Switzerland:International Electro Commission，2008．

［8］International Electro Commission． IEC 61850 Communication network and systems in substations［S］． Switzerland:International Electro Commission，2005．

［9］李俊剛，宋小會，狄軍峰，等．基于IEC 62439 －3 的智能變電站通信網絡冗余設計［J］．電力系統自動化，2011，35(10):70-73．

［10］陳原子，徐習東．基于并行冗余網絡的數字化變電站通信網絡構架［J］． 電力自動化設備，2011，31(1):105-108．

［11］許鐵峰，徐習東．高可用性無縫環網在數字化變電站通信網絡的應用［J］．電力自動化備，2011，31(10):121-125．

［12］辛培哲，閆培麗，肖智宏，等． 新一代智能變電站通信網絡技術應用研究［J］． 電力建設，2013，34(7):17-23．

［13］International Electro Commission． IEC 61850 Communication network and systems in substations［S］． Switzerland:International Electro Commission，2011．

［14］何磊．IEC 61850 應用入門［M］． 北京:中國電力出版社，2012:279-300．

［15］陳俊，閻慧，王宇．基于wireshark 的協議分析插件開發［C］//第十六屆全國青年通信學術會議集．杭州:中國通信學會，2011:74-76．

［16］彭城．基于Wireshark 的協議分析研究與擴展實現［D］．成都:電子科技大學，2007．

［17］Wireshrk Developer ’ s Guide ［EB/OL ］． http://www．wireshark． org/．

［18］呂雪峰，張春芳． Wireshark 協議解析原理與新協議添加方法［J］．軟件導報，2011，11(12):105-107．

［19］羅青林，徐克付，臧文羽，等．Wireshark 環境下的網絡協議解析與驗證方法［J］．計算機工程與設計，2011，32(3):770-775

［20］范建忠，馬千里．GOOSE 通信與應用［J］．電力系統及其自動化，2007，31(19):85-90．