典型報(bào)文解析說明資料

61850典型報(bào)文解析說明深圳南瑞科技有限公司第16頁61850典型報(bào)文解析說明1平臺現(xiàn)利用ethereal報(bào)文抓捕工具抓取部分典型報(bào)文解析說明。報(bào)告類61850報(bào)告服務(wù)，是一項(xiàng)非常重要的ACSI服務(wù)，它通過SCSM映射為MMS協(xié)議中的InformationReport服務(wù)，我們在調(diào)試過程中通過捕包工具得到的61850報(bào)告報(bào)文，都是經(jīng)過ASN.1編碼后的InformationReport數(shù)據(jù)。InformationReport相關(guān)數(shù)據(jù)結(jié)構(gòu)下表是InformationReport的數(shù)據(jù)結(jié)構(gòu)：InformationReport的數(shù)據(jù)結(jié)構(gòu)定義DL/T860.72報(bào)告格式參數(shù)名條件報(bào)告ID（RptID）始終存在報(bào)告中包括的選擇區(qū)域（ReportedOptFlds）始終存在順序編號（SeqNum）當(dāng)OptFlds.sequence-number或OptFlds中full-sequence-number為TRUE時(shí)存在入口時(shí)間（TImeOfEntry）當(dāng)OptFlds.report-time-stamp為TRUE時(shí)存在數(shù)據(jù)集（DatSet）當(dāng)OptFlds.data-set-name為TRUE時(shí)存在發(fā)生緩沖溢出（BufOvfl）當(dāng)OptFlds.buffer-overflow為TRUE時(shí)存在入口標(biāo)識（EntryID）當(dāng)OptFlds.entry為TRUE時(shí)存在子序號（SubSeqNum）當(dāng)OptFlds.segmentation為TRUE時(shí)存在有后續(xù)數(shù)據(jù)段（MoreSegmentFollow）當(dāng)OptFlds.segmentation為TRUE時(shí)存在包含位串（Inclusion-bitstring）始終存在數(shù)據(jù)引用（data-reference(s)）當(dāng)OptFlds.data-reference為TRUE時(shí)存在值（value(s)）始終存在原因代碼（ReasonCode(s)）當(dāng)OptFlds.reason-for-inclusion為TRUE時(shí)存在其中：RptID：作為不同報(bào)告間的唯一標(biāo)識符，在報(bào)文中是始終存在的。OptFlds：決定了報(bào)文拼裝中可選成員出現(xiàn)與否，該屬性值對于報(bào)文解析非常重要，在61850-7-2中BRCB.OptFlds和URCB.OptFlds定義不同，在標(biāo)準(zhǔn)-8-1中通過引入保留位，保證了OptFlds定義的一致性，整合后的OptFlds各位含義如下：OptFlds數(shù)據(jù)定義ACSIValueofRCBStatesMMSBitPositionReserved0Sequence-number1Report-time-Stamp2Reason-for-Inclusion3Data-Set-Name4Data-Reference5Buffer-Overflow6EntryID7Conf-Rev8Segmentation9ResonCode：決定了報(bào)告的觸發(fā)原因，61850標(biāo)準(zhǔn)規(guī)定了五種觸發(fā)類型：數(shù)據(jù)變化（DataChange）、數(shù)據(jù)更新（DataUpdata）、品質(zhì)變化（QualityChange）、完整性周期（IntegerPd）和總召喚（GI）。ResonCode也是Bitstring類型，觸發(fā)選項(xiàng)的存儲形式InformationReport報(bào)文解析建好數(shù)據(jù)庫，連接好裝置后，啟動SCADA服務(wù)器，并用ethereal抓報(bào)文，根據(jù)報(bào)告格式進(jìn)行解析。圖1為ethereal解析出來的報(bào)文。解釋如下：報(bào)告的RptID為BR04_brcbRelayDin03，其中03為報(bào)告實(shí)例號報(bào)告的選項(xiàng)域，報(bào)告中包含哪些選項(xiàng)，按位標(biāo)識，0為不存在，1為存在。順序編號SeqNum，由OptFlds決定其是否存在溢出標(biāo)志BufOvfl，由OptFlds決定其是否存在入口標(biāo)識EntryID，由OptFlds決定其是否存在InclusionBitstring（該報(bào)告中出現(xiàn)的數(shù)據(jù)集成員），由報(bào)文可知該數(shù)據(jù)集共有137個(gè)成員，其中只有第29個(gè)數(shù)據(jù)集成員上送報(bào)告數(shù)據(jù)集成員Value，數(shù)據(jù)集成員值為一個(gè)結(jié)構(gòu)value的stval（狀態(tài)值）value的q（品質(zhì)）value的t（時(shí)標(biāo)）報(bào)告的觸發(fā)原因類型為：數(shù)據(jù)變化（按位為保留、數(shù)據(jù)變化、品質(zhì)變化、數(shù)據(jù)更新、完整性、總召喚，0為無1為有）圖1InformationReport定值類定值服務(wù)可以分為SGCB控制塊相關(guān)服務(wù)和定值相關(guān)服務(wù)。SGCB服務(wù)在邏輯設(shè)備中有一個(gè)定值組控制塊SGCB，SGCB包含若干屬性，SGCB相關(guān)服務(wù)可歸結(jié)為對SGCB屬性的讀寫操作，SGCB結(jié)構(gòu)定義如下：其中wNumOfSG為定值組數(shù)，wActSG為當(dāng)前運(yùn)行定值組，wEditSG為編輯定制組，sCnfEdit為確認(rèn)編輯定值組。SGCB相關(guān)服務(wù)主要有讀取定值組數(shù)和切換定值組，切換定值組時(shí)需要確認(rèn)切換。其中讀取定值組數(shù)為讀取SGCB的wNumOfSG值，而切換定值組，則是將要切換的定制組設(shè)置為當(dāng)前運(yùn)行組。圖2SGCB服務(wù)圖3讀定值組數(shù)圖3為讀定值組數(shù)，讀取的是SGCB的NumofSG變量值。報(bào)文內(nèi)容：1a0a495341333531474c44311a144c4c4e302453502453474342244e756d4f665347以上報(bào)文解析為：ISA351GLD1/LLN0$SP$SGCB$NumOfSG，邏輯設(shè)備名LDName為ISA351GLD1，LLN0是邏輯節(jié)點(diǎn)LNName，功能約束FC為SP，該功能約束表示數(shù)據(jù)屬性的初始值來至配置，其值不可變。數(shù)據(jù)對象DOName為SGCB，數(shù)據(jù)屬性DaName為NumOfSG。其中藍(lán)色部分報(bào)文為ISA351GLD1，1a為tag，0a為長度，共10個(gè)字符，495341333531474c4431為ISA351GLD1的ASCII碼，剩余部分報(bào)文為LLN0$SP$SGCB$NumOfSG各個(gè)字符的ASCII碼值，在61850中均通過這種方式來標(biāo)識各數(shù)據(jù)引用。圖4裝置回復(fù)共9組定值裝置回復(fù)共有9組定值，在HMI上可以看到各定值組號以及當(dāng)前定值組。圖5請求讀取當(dāng)前運(yùn)行的定值組讀取當(dāng)前運(yùn)行定值組通過讀取SGCB的wActSG變量值來實(shí)現(xiàn)，報(bào)文內(nèi)容如下：解析為ISA351GLD1LLN0$SP$SGCB$ActSG，方法如上文所述。圖5裝置回復(fù)為第2組圖6請求切換第4組為當(dāng)前運(yùn)行定值組切換第4組定值為當(dāng)前運(yùn)行組，方法是將第4組定值設(shè)置為ActSG，報(bào)文如下與讀取當(dāng)前運(yùn)行定值組區(qū)別是，多出來一段報(bào)文a003860104，其中a0為tag，03為長度，01為當(dāng)前運(yùn)行定值組，04為待切換定制組，這段報(bào)文意思是將當(dāng)前運(yùn)行定制組從01組切換到04組。圖7裝置回復(fù)切換成功定值服務(wù)定值相關(guān)服務(wù)主要有召喚定值以及下裝定值，只有當(dāng)前運(yùn)行組的定值才能提供定值服務(wù)。將當(dāng)前定制組定值召喚上來后，即可修改定值，修改完成后需要下裝定值，為防止誤操作，需要確認(rèn)下裝，若取消下裝，則不會修改裝置定值。圖8定值相關(guān)服務(wù)點(diǎn)擊召喚定值，裝置會將當(dāng)前定值組定值一一上送，圖9為主站要求讀取該定值組中的第1個(gè)定值，該值的數(shù)據(jù)引用為ISA351GLD1/SETGGIO1$SG$Dz01IXDLYX$setMag$f，邏輯設(shè)備名LDName為ISA351GLD1，SETGGIO1是邏輯節(jié)點(diǎn)LNName，功能約束FC為SG，帶有功能約束SG的數(shù)據(jù)屬性的值應(yīng)是當(dāng)前激活值，數(shù)據(jù)屬性的初始值來至其配置，其值不可變。數(shù)據(jù)對象DOName為Dz01IXDLYX，數(shù)據(jù)屬性DaName為setMag.f可見，該值數(shù)據(jù)屬性為setMag（模擬定值），且該值為浮點(diǎn)數(shù)，對應(yīng)裝置模板中的相電流越限電流定值。圖10裝置返回該值為19.99。圖11為主站要求讀取該定值組中的第2個(gè)定值，該值的數(shù)據(jù)屬性為setVal，為狀態(tài)量，對應(yīng)裝置模板中的瞬時(shí)電流速斷保護(hù)投退，裝置返回該值為FALSE。圖9讀取當(dāng)前定值組的第1個(gè)定值圖10裝置返回當(dāng)前定值組第1個(gè)定值圖11讀取當(dāng)前定值組第2個(gè)定值圖12裝置返回當(dāng)前定值組第2個(gè)定值修改定值時(shí)，首先需要召喚定值，將召喚上來的定值修改為需要值，然后下裝定值。下裝定值前需要通過讀取SGCB的EditSG變量來獲取可編輯定值組號（即當(dāng)前運(yùn)行定值組號，圖13），數(shù)據(jù)引用為ISA351GLD1/LLN0$SP$SGCB$EditSG，功能約束SP表明數(shù)據(jù)屬性初始值來至配置，其值不可變。然后下裝定值，如圖14，為下裝第一個(gè)定值，該值下裝為10。其數(shù)據(jù)引用為ISA351GLD1/SETGGIO1$SE$Dz01IXDLYX$setMag$f，與圖9的區(qū)別是，功能約束變成了SE，表示該數(shù)據(jù)屬性可被編輯。若下裝成功則裝置將回復(fù)DataWriteSuccess，然后通過寫SGCB的CnfEdit變量確認(rèn)下裝，如圖15，該變量值為TRUE，表示下裝成功?？梢酝ㄟ^召喚測量值查看下裝是否成功。圖13讀取可編輯定值組號圖14下裝定值圖15確認(rèn)下裝定值控制類ACSI控制服務(wù)映射為MMS的讀寫服務(wù)，通過MMS讀寫有名變量服務(wù)來訪問控制模型，帶有可控?cái)?shù)據(jù)屬性(從帶有FC=CO和FC=SP屬性的公用數(shù)據(jù)類所派生出的)的數(shù)據(jù)對象一定的規(guī)則進(jìn)行映射。MMS有名變量組件表示FC=CO和FC=SP的數(shù)據(jù)對象，有如下通用引用：<LDname>/<LNname>$CO$<DOname><LDname>/<LNname>$SP$<DOname>控制模型到MMS控制組件的映射有常規(guī)安全機(jī)制的選擇和直接操作、增強(qiáng)安全機(jī)制的選擇和直接操作，常規(guī)安全和增強(qiáng)安全的DaName分別為SBO、SBOW，遙控選擇實(shí)際上就是通過寫SBO、SBOW屬性的MMS服務(wù)來實(shí)現(xiàn)。操作的DaName為oper，同樣的道理，操作服務(wù)也是通過MMS寫操作屬性來實(shí)現(xiàn)，裝置則相應(yīng)的回復(fù)寫響應(yīng)，通常是DataWriteSuccess（寫成功），或者DataWriteFailure。對于選擇、操作的屬性則必須都賦值，若沒有值可寫默認(rèn)值，但是必須要有相應(yīng)的屬性，否則寫失敗。遙控的流程是這樣的：客戶端讀服務(wù)器SBOW的目錄結(jié)構(gòu)，GetDataDirectory，映射為mms的GetVarAccessAttributes服務(wù)，獲取服務(wù)器端SBOW具有的屬性，如圖16為客戶端請求RCS923A1PROT$PTRC1$CO$VEBI1$SBOW的目錄結(jié)構(gòu)。服務(wù)器端回復(fù)SBOW的目錄結(jié)構(gòu)。圖17回復(fù)的SBOW目錄結(jié)構(gòu)，包括ctlval、origin（包括orCat、orIdent）、ctlnum、T、Test、Check，意思分別是：控制值（Bool類型）、命令發(fā)起者、控制編號、時(shí)間、測試、檢查。目前大部分廠家都只寫控制值，其它的屬性均賦默認(rèn)值，控制值TRUE代表合，F(xiàn)ALSE代表分?？蛻舳税l(fā)送寫SBOW請求ConfRequest:write（這種服務(wù)表示需要服務(wù)器端回復(fù)，否則無法繼續(xù)交互報(bào)文，而裝置上送的報(bào)告為Unconfirmed,即無需確認(rèn)的服務(wù)），如圖18寫RCS923A1PROT$PTRC1$CO$VEBI1$SBOW，其中ctlval為TRUE，為合，其余各屬性值為客戶端默認(rèn)賦值，所有控制報(bào)文均如此，可以不用管。裝置回復(fù)寫請求（ConfResponse:Write）：DatawriteSuccess，即寫數(shù)據(jù)成功，如圖19.客戶端發(fā)送寫oper請求ConfRequest:write，如圖20寫RCS923A1PROT$PTRC1$CO$VEBI1$Oper，其屬性值和SBOW一致。裝置回復(fù)寫成功，整個(gè)遙控過程結(jié)束。認(rèn)真分析可以發(fā)現(xiàn)，61850遙控的過程和非61850遙控過程是一樣的，寫SBOW相當(dāng)于遙控選擇，而寫oper值則相當(dāng)于遙控執(zhí)行，無論是選擇還是執(zhí)行都需要遙控返校。圖16客戶端請求SBOW目錄機(jī)構(gòu)圖17服務(wù)器端回復(fù)SBOW目錄結(jié)構(gòu)圖18客戶端發(fā)送寫SBOW請求圖19服務(wù)器回復(fù)寫成功圖20客戶端發(fā)送寫oper請求讀目錄服務(wù)讀目錄服務(wù)用于后臺與裝置之間長時(shí)間沒有報(bào)文交互時(shí)，測試網(wǎng)絡(luò)是否正常。圖21主機(jī)向裝置發(fā)送請求讀目錄圖22裝置回復(fù)讀出ISA351G，且沒有后續(xù)報(bào)文文件服務(wù)保信子站需要召喚錄波文件，就是通過文件服務(wù)來實(shí)現(xiàn)，那么客戶端怎么知道是否有錄波文件呢？目前有兩種做法：一是，服務(wù)器初始化時(shí)就將Rcdmade置1，開始錄波時(shí)Rcdmade被置成0，錄波完成后Rcdmade又被置成1，因此只要Rcdmade為1就可以去召喚錄波文件，我公司、四方以及中元華電等廠家都是這種處理方式；另一種方法是，服務(wù)器初始化時(shí)Rcdmade被置成0，只要有新的錄波產(chǎn)生即將Rcdmade置成1，這個(gè)時(shí)候就可以去召錄波文件。召錄波文件的流程是這樣的：客戶端向服務(wù)器端發(fā)送讀錄波文件目錄請求（ConfRequest:FileDirectory），如圖23所示，標(biāo)準(zhǔn)中規(guī)定，錄波文件應(yīng)為COMTRADE格式，COMTRADE格式又有1997和1999版，錄波文件可通過我公司保護(hù)工程師站中的故障分析工具查看，但只能查看符合COMTRADE格式1999版的錄波文件。此外標(biāo)準(zhǔn)中還規(guī)定錄波文件在服務(wù)器中應(yīng)包含在“COMTRADE”的文件目錄內(nèi)。服務(wù)器端返回錄波文件目錄列表，如圖24。在客戶端內(nèi)存中會維護(hù)一張錄波文件目錄表，客戶端如果發(fā)現(xiàn)此次召喚的目錄列表和內(nèi)存中的不一致，則代表有新的錄波產(chǎn)生，這樣，客戶端就會去調(diào)取新的錄波文件。圖23和24的InvokeID均為43，表示這是同一個(gè)請求和回復(fù)。客戶端發(fā)送打開文件請求（ConfRequest:Fileopen），按照尚未讀取的文件的時(shí)間順序，最新產(chǎn)生的錄波文件優(yōu)先打開并讀取。如圖25，打開COMTRADE目錄下的CSC122M1_RCD_14_20090515_162308_484.dat文件，服務(wù)器端響應(yīng)打開文件請求，這其中包含了資源ID24661816，文件大小1.4K，以及最后修改時(shí)間如圖26。客戶端發(fā)送讀文件請求，讀取的數(shù)據(jù)就是資源ID為24661816文件中的數(shù)據(jù)，圖27.服務(wù)器端通過COTP服務(wù)讀文件中的數(shù)據(jù)，如圖28.一般情況下，錄波文件很大，一幀報(bào)文無法將其中的數(shù)據(jù)全部上送，因此需要多次讀操作，標(biāo)準(zhǔn)中通過moreFollows位來確定是否還有數(shù)據(jù)尚未讀完，如果moreFollows為TRUE，則代表還有數(shù)據(jù)需要讀取，客戶端再次請求讀文件服務(wù)，若moreFollows為FALSE則代表數(shù)據(jù)已經(jīng)全部讀取完畢，引發(fā)客戶端關(guān)閉文件的操作?？蛻舳税l(fā)送關(guān)閉資源ID為24661816的文件。服務(wù)器端關(guān)閉文件，至此CSC122M1_RCD_14_20090515_162308_484.dat文件讀取完畢，然而對于一個(gè)完整的錄波文件，還包括.cfg，.hdr文件，這兩個(gè)文件也需要讀取，過程和.dat文件一致，三個(gè)文件都讀取完畢，則一個(gè)錄波文件讀取完成。圖23客戶端發(fā)送讀文件目錄請求圖24服務(wù)器端返回錄波文件目錄列表圖25客戶端發(fā)送打開文件請求圖26服務(wù)器端響應(yīng)打開文件請求圖27客戶端發(fā)送讀文件請求圖28服務(wù)器端讀文件圖29客戶端請求關(guān)閉文件報(bào)文分析SV報(bào)文分析工程實(shí)施過程中，9