石文江，隋 珺，朱亮亮

(大連供電公司電網調度中心，遼寧 大連 116011)

采用數(shù)據集以“發(fā)布/訂閱”方式進行公共數(shù)據交換的GOOSE在智能變電站過程總線上被用于跳合閘命令及狀態(tài)信息的快速傳遞，它工作于以太網鏈路層，直接服務于應用層保護測控等裝置。因此GOOSE報文的正確解析是智能變電站過程層調試和應用軟件開發(fā)的重要基礎;是故障定位的依據;是保障智能變電站可靠運行的重要技術手段。圖1是通過MMSEthereal抓包的GOOSE實例報文。

圖1 PCS978主變保護裝置GOOSE跳閘報文

1 GOOSE信息傳輸流程

發(fā)布者 (如 PCS978主變保護裝置)的GOOSE控制塊GoCB［1］定時根據虛端子映射表更新與IECGoossePdu［2］變量列表成員相對應的數(shù)據集，依據 GOOSE 的應用協(xié)議描述，經 ASN.1［3］BER［4］編碼后將數(shù)據以FIFO方式壓入發(fā)送緩沖區(qū)，由網絡適配器通過以太網交換機采取多播或單播的形式發(fā)送給訂閱者 (如主變主一次智能操作箱)。特定事件發(fā)生后，立刻啟動上述流程，并以先密后疏(2 ms至10 s)的形式，快速重傳以提高可靠性［5］。訂閱者根據新數(shù)據通知讀取接收緩沖區(qū)中的GOOSE數(shù)據，經MAC過濾、ASN.1 BER解碼、GOOSE報文狀態(tài)號 (StNum)和順序號 (SqNum)的效驗等解析出合法的應用數(shù)據［6］。實現(xiàn)正確解析的一個重要的前提是訂閱者必須獲得發(fā)布者的ICD自描述文件，以獲得多播MAC地址、APPID、數(shù)據集成員順序等重要參數(shù)，這些參數(shù)可抽取并歸納到發(fā)布者的GOOSE配置文件中。圖2對GOOSE信息傳輸流程進行了概括描述。本文主要研究的對象是以太網鏈路層GOOSE報文。

圖2 GOOSE信息傳輸模型

2 GOOSE報文的TLV編碼

2.1 ASN.1 BER編碼規(guī)則

正確理解抽象語法記法 (ASN.1)及其基本編碼規(guī)則 (BER)才能對GOOSE報文的應用協(xié)議數(shù)據單元 (APDU)和應用服務數(shù)據單元 (ASDU)進行編解碼。

2.1.1 TLV三聯(lián)碼結構

ASN.1 BER采用大端編碼的8位組 (octet字節(jié))，既從左到右分別是bit 7至bit 0。信息元由Tag、Length、Value三部分組成，每部分由1個及以上字節(jié)組成，因此又稱TLV三聯(lián)碼，它可以嵌套，既其Value部分可以包含其它的TLV三聯(lián)碼。Tag部分用來標識信息元的結構和類型，Tag的高2位 (bit 7、bit 6) 為 tag class，00表示 “UNIVERSAL通用”;01表示“APPLICATION應用”，如GOOSE;10表示“context-specific上下文”，所描述信息的結構、順序和含義需由雙方事先約定，它在GOOSE報文中應用的十分廣泛;11表示“PRIVATE私有”。Tag的bit 5為tag form，0表示“Primitive基本類型”，如布爾型、整型、字符串等;1表示“Constructed組合類型”，既數(shù)據單元中含有2種以上基本類型的數(shù)據元，GOOSE報文就屬于這種情況。Tag的其余位Bit 0～Bit 4主要定義為數(shù)據類型，其中UNIVERSAL Tag的數(shù)據類型為ASN.1標準所規(guī)定，不能改變，APPLICATION Tag的數(shù)據類型可由具體應用決定，如可作為Tag的編碼序號。如圖3中的“goosePdu［APPLICATION 1］”表示數(shù)據類型為1，Tag編碼為0x61。Length部分用來表示Value部分的字節(jié)數(shù)。

2.1.2 TLV的Tag及Length的編碼方法

TLV的Tag的低五位 (Bit0～Bit4)用來表示數(shù)據類型 (或編碼序號)，因此應用協(xié)議描述中不同數(shù)據類型的個數(shù)如果超過30個，或采用自動Tag編碼的個數(shù)超過30個，則Tag的字節(jié)數(shù)將由1個擴展為多個，既第1個字節(jié)的低五位為全1碼，中間字節(jié)的bit7為1，最后字節(jié)的bit7為0，Tag的數(shù)據類型 (或編碼序號)由中間字節(jié)和最后字節(jié)的bit6～bit0從左向右合并而得，根據圖3的應用協(xié)議描述，Tag的編碼序號最大為11，因此GOOSE報文中的Tag只有一個字節(jié)。Tag的低五位(Bit0～Bit4)被用來表示數(shù)據類型還是編碼序號，由該類型的Tag在模塊定義中是否聲明隱式 (IMPLICIT TAGS)或者在模塊定義中標識為自動編碼(AUTOMATIC TAGS)，如果是，則數(shù)據集成員IMPLICIT左側［］中的數(shù)字為Tag編碼序號，或由ASN.1編解碼器對SEQUENCE、SET和CHOICE類型自動從0開始，步長為1進行各成員Tag的自動編碼;否則為數(shù)據類型，如IECGoosePdu中allData數(shù)據集內成員的Tag編碼。GOOSE報文采用context-specific的Tag編碼序號，即圖3中的成員從gocbRef到 numDatSetEntries的 Tag編碼為0x80到0x8a，由于allData屬于SEQUENCE OF數(shù)據結構，因此其bit5=1(Constructed組合類型)，Tag編碼為Oxab。

TLV的Length有兩種表達方式:定長 (Definite Form)和不定長 (Indefinite Form)。采用定長方式時，當長度不大于127個字節(jié) (8位)時，Length只有1個字節(jié);當長度大于127個字節(jié)時，Length需在多個字節(jié)中編碼，此時第一個字節(jié)的低7位表示的是Length本身的長度，后續(xù)Length字節(jié)表示Value的長度。采用不定長方式時，Length只有一個字節(jié)，固定編碼為0x80，但在編碼結束后需以連續(xù)兩個0x00結尾，這種方式的一個好處是，在編碼沒有結束的情況下，發(fā)布者可以先發(fā)送部分消息給訂閱者。GOOSE報文的TLV的Length采用定長方式。

2.2 Tag的數(shù)據類型

根據 MMS:ISO 9506－2:2003 的規(guī)定［7］，GOOSE報文中主要采用4種數(shù)據類型:BOOLEAN(布爾)、BIT－STRING(字符串)、INTEGER(32位整數(shù))、UtcTime(UTC時間類型)，相應APPLICATION Primitive Tag編碼分別為 0x83、0x84、0x85，0x91，這些APPLICATION Primitive Tag編碼將在圖3中allData數(shù)據集序列中出現(xiàn)。

2.3 GOOSE的應用協(xié)議描述及數(shù)據類型

GOOSE的應用協(xié)議描述文件采用ASN.1語法規(guī)則，共有12個部分，本文摘取與GOOSE報文解析相關的模塊定義和IECGoosePdu部分，見圖3。

在圖3中，SEQUENCDE為由不同類型的值組成一個有序結構:SEQUENCDE OF類似于C語言中的動態(tài)數(shù)組，所有成員都屬于一個類型，數(shù)目不定;CHIOCE為在類型中選擇。allData數(shù)據集成員序列的內容將由發(fā)布者GOOSE的工程配置文件中確定，該文件為發(fā)布者ICD自描述文件的一部分。

2.4 GOOSE的工程配置文件

GOOSE的工程配置文件是從發(fā)布者的ICD自描述文件抽取出來的，主要用于描述以太網鏈路層基本參數(shù);VLAN號、優(yōu)先級、AppID應用標識、報文傳送的時間要求等，以及allData數(shù)據集序列的具體成員。如圖4中數(shù)據集序列的第一個成員指向主變智能操作箱 (LD:PT6601API_BCU)的斷路器控制邏輯節(jié)點 (LN:CK_GOIN CSWI1)的主變主一次斷路器分閘位置控制繼電器 (B04．highout．Obj1．OUT_RELAY_F)。$ST$OpO-pn$general用于屬性描述，含義為:狀態(tài)量、分閘操作、通用。

3 鏈路層以太網報文解析及工程調試要點

圖4 GOOSE的工程配置文件

根據表1，鏈路層以太網幀頭由PRE(先導字節(jié)，7個 10101010)和 SFD(幀開始標志，10101011)組成，這一部分和最后4字節(jié)的幀檢查序號由網絡適配器自動濾掉。圖1報文中01 0c cd 01 01 61為目的MAC地址，它為多播地址，根據IEC 61850－9－2標準［8］，推薦的范圍為01－0ccd－01－00－00到01－0c－cd－01－01－ff。00 10 00 00 00 61為源MAC地址，為單播地址。 “源MAC地址”報文后沒有緊跟著4字節(jié)的802.1q的TAG標簽［9］。TAG由2字節(jié)802.1q的報文類型標識碼TPID(0x8100)和2字節(jié)TCI組成，其中TCI中的高3位 (bit7～bit5)為優(yōu)先級標識 (根據圖4，Priority=4)，后12位為VLAN的標識碼VID(根據圖4，VID=0)，bit4位為公認格式標識CFI，對于過程總線而言CFI=0，由此TAG報文段應為81 00 80 00。圖1實例報文中沒有TAG報文段的原因為以太報文信息通過交換機access口下路時，TAG標識將被脫去，否則普通網卡無法識別該報文而棄之。88 b8為GOOSE以太網報文類型。01 61為APPID應用標識 (十進制353)，GOOSE APPID的取值范圍為0～ox3fff，不同應用的APPID在一個系統(tǒng)中應具有惟一性。00 f7為報文長度 (247字節(jié))，它是從APPID開始至幀檢查序號前的PDU報文長度。隨后的00 00 00 00為保留字節(jié)。緊接著的是IECGoosePdu應用層數(shù)據［10］。

通過這段報文解析，作為保證GOOSE報文實時傳輸?shù)亩右蕴W交換機的優(yōu)先級、VLAN、多播等配置情況通過正常的報文抓包是無法看出的，必須對交換機的當前配置進行認真核對，并通過嚴格的試驗手段加以測試，以保證信息的有效隔離和高優(yōu)先級報文的快速傳輸。但多播地址、GOOSE報文類型、APPID應用標識需要結合報文解析加以嚴格印證，如保證APPID的惟一性、多播規(guī)劃符合設計要求等。

4 IECGoosePdu應用層數(shù)據解析及工程調試要點

根據圖3的模塊定義部分“goosePdu［APPLICATION 1］IMPLICIT IECGoosePdu…”及 “IECGoosePdu∷=SEQUENCE”可知，整個GOOSE塊采用 tag class=context－specific(上下文)、tag form=constructed、編碼序號=1的Tag標識，即0x61。由此可以摘取出IECGoosePdu的以太網報文部分，見表2。

IECGoosePdu以太網實例報文的解析需要重點集中在:事件序號StNum、發(fā)送序號sqNum、測試狀態(tài)test、配置版本變更 confRev、需要配置 ndsCom、allData所有成員的實時狀態(tài)是否正確。

表1 以太網幀結構

表2 IECGoosePdu以太網實例報文解析

事件序號StNum應在新的GOOSE事件出現(xiàn)時，既allData數(shù)據集成員的實時狀態(tài)有變化，發(fā)布者應將StNum加1。發(fā)布者每發(fā)出1個GOOSE報文，應將發(fā)送序號SqNum加1，上電運行或復位時SqNum和StNum的初始值為1，0為保留值。訂閱者接收到的StNum、SqNum的記錄應是連續(xù)的，StNum的增加還要和allData的本次和上次記錄對比有變化相一致，訂閱者發(fā)現(xiàn)異常應產生報警并拒絕執(zhí)行發(fā)布者的GOOSE命令或采用其狀態(tài)信息。

測試狀態(tài)test在實際使用時，常用于反應試驗把手、檢修壓板等的位置狀態(tài)，訂閱者接收到test=TRUE的報文，可接收其狀態(tài)信息但應拒絕執(zhí)行發(fā)布者的GOOSE命令，因此它在設備檢修試驗，尤其是不動一次設備情況下的遙控實驗中具有重要意義。相關功能需按照設計要求在test真假值變化時進行嚴格測試。

發(fā)布者在allData數(shù)據集成員發(fā)生變化時，如:增加或減少成員數(shù)目、改變成員的先后順序等，應將配置版本變更confRev加1。訂閱者發(fā)現(xiàn)confRev發(fā)生變化時應產生報警，并重新讀取發(fā)布者的ICD自描述文件，取得allData數(shù)據集相應的變化配置。目前國內大部分廠家的IED設備需要人工干預才能進行配置修改。confRev初始值建議為1，0保留。

發(fā)布者在接收訂閱者數(shù)據請求時數(shù)據集中只有部分成員實時數(shù)據，或allData數(shù)據集中存在無法獲得當前值的成員 (如某些inputs)時，也就是說allData中存在NULL或老數(shù)據，應將NdsCom設為TRUE，告知數(shù)據集需要進一步更新。此時訂閱者需要判斷是否采用發(fā)布者的數(shù)據。allData中NULL編碼結構為 ［Tag 0空］，如:83 00_。

5 結束語

在采用IEC 61850－9－2標準過程層設備的實際測試中，發(fā)現(xiàn)過程總線上除了GOOSE和SV多播、單播等報文外，還存在著大量 TCP、ARP、UDP、ICMP等協(xié)議的數(shù)據報文，大部分是不需要的數(shù)據，亟待進一步規(guī)范過程總線上IED設備網絡適配器的配置，以消減這部分垃圾數(shù)據，從而保證過程總線上的數(shù)據進行清晰有序地流動。另一方面，調試中使用的MMSEthereal軟件功能很強大，但沒有中文界面且不夠直觀，不便于供電企業(yè)維護人員的使用，需要研發(fā)具有自主知識產權、針對性強且界面友好的IEC 61850過程總線以太網報文解析工具。

［1］ IEC 61850－7－2:Communication networks and systems in substation－Part 7－2:Basic communication structure for substation and feeder equipment-Abstract communication service interface(ACSI)．

［2］ IEC 61850－8－1:Communication networks and systems in substations－Part 8－1:Specific communication service mapping(SCSM) －Mappings to MMS(ISO/IEC 9506－1 and ISO/IEC 9506－2)and to ISO/IEC 8802－3．

［3］ ISO/IEC 8824－1:1999，Information technology－Abstract Syntax Notation One(ASN.1)

［4］ ISO/IEC 8825－1，Information technology－ASN.1 encoding rules:Specification of Basic Encoding Rules(BER)，Canonical Encoding Rules(CER)and Distinguished Encoding Rules(DER)．

［5］ 段吉泉．變電站GOOSE報文在IED中的實時處理 ［J］．電力系統(tǒng)自動化，2007，31(11):65－69．

［6］ 殷志良．基于IEC 61850的通用變電站事件模型［J］．電力系統(tǒng)自動化，2005，29(19):45－50．

［7］ ISO 9506－2:2003，Industrial automation systems－Manufacturing Message Specification－Part 2:Protocol specification．

［8］ IEC 61850－9－2:Communication networks and systems in substations－Part 9－2:Specific Communication Service Mapping(SCSM) －Sampled values over ISO/IEC 8802－3．

［9］ 王 松．數(shù)字化變電站繼電保護的GOOSE網絡方案 ［J］．電力系統(tǒng)自動化，2009，33(3):51－54．

［10］ 王 松．GOOSE報文過濾方法研究［J］．電力系統(tǒng)自動化，2008，32(19):54－57．

［11］ 黃少雄．智能變電站GOOSE網配置方案研究 ［J］．東北電力技術，2010，31(10):47－49．

［12］ 周 滿．基于數(shù)字化變電站的繼電保護改進方案［J］．東北電力技術，2010，31(4):29－37．