61850典型報文解析說明

61850典型報文分析說明編寫：歐灶軍平臺現(xiàn)利用ethereal報文抓捕工具抓取部分典型報文分析說明。1.1報告類COS61850報告服務，是一項特別重要的ACSI服務，它經(jīng)過SCSM映照為MMS協(xié)議中的InformationReport服務，我們在調試過程中經(jīng)過捕包工具得到的61850報告報文，都是經(jīng)過編碼后的InformationReport數(shù)據(jù)。建好數(shù)據(jù)庫，連結好裝置后，啟動SCADA服務器，并用ethereal抓報文，依據(jù)報告格式進行分析。比如抓到的SOE報告ID號為BR03_brcbSOE01，此中03與模板中定義的各樣報告種類有關，比如在我使用的裝置模板中這么定義的：brcbREC、brcbCHK、brcbSOE分別為BR01、BR02、BR03，01表示該報告已經(jīng)實例化。因為InformationReport各成員的數(shù)據(jù)種類是確立的，依據(jù)編碼規(guī)則，各數(shù)據(jù)編碼后的數(shù)據(jù)也是確立的：RptID編碼后數(shù)據(jù)為：8aXXXXXX；OptFlds編碼后數(shù)據(jù)為：840307XXX0；SqNum編碼后數(shù)據(jù)為：86XXXXXX；TimeOfEntry編碼后數(shù)據(jù)為：8C06XXXXXXXXXXXX；DataSet編碼后數(shù)據(jù)為：8aXXXXXX；BufOvfl編碼后數(shù)據(jù)為：8301XX；EntryID編碼后數(shù)據(jù)為：89XXXXXX；ConfRev編碼后數(shù)據(jù)為：86XXXXXX；SubSeqNum編碼后數(shù)據(jù)為：86XXXXXX；MoreSegmentFollow編碼后數(shù)據(jù)為：8301XX；Inclusion-bitstring編碼后數(shù)據(jù)為：84XXXX；Data-Reference編碼后數(shù)據(jù)為：8aXXXX；Value取決于詳細數(shù)據(jù)種類；ReasonCode編碼后數(shù)據(jù)為：84XXXX；下邊以SOE報文為例，說明整個報告的含義，報文以下：8a0e425230335f62726362534f453031(RptID)8403071180(OptFlds)89080000000000000020(EntryID)860101(ConfRev)8406058000001000(Inclusion-bitstring)（Values,共2個）8402024084020240(ReasonCode，共2個)報告分析以下：RptID（BR03_brcbSOE01）：8a0e425230335f62726362534f453031，此中8a為tag，長度為0e，后邊的為ID編碼。OptFlds：8403075300，84為tag，長度為03，1180（分析為：0）決定各可選項能否出現(xiàn)，各位含義以下：ACSIValueofMMSBitRCBStatesPositionReserved0Sequence-number1Report-time-Stamp2Reason-for-Inclusion3Data-Set-Name4Data-Reference5Buffer-Overflow6EntryID7Conf-Rev8Segmentation9所以，分析后可知，第3、7、8位出現(xiàn)，即Reason-for-Inclusion、EntryID、Conf-Rev出現(xiàn)。EntryID：89080000000000000020，89為tag，長度為9，條目號為20Conf-Rev：860101，配置版本號，86為tag，01為長度，值為01，TRUE。Inclusion-bitstring：8406058000001000，84為tag，06為長度，同時已用的位共有：(Length-1)X8-5=35位。此中第1、28位有值，其余全0。Value：8a，此中a2為tag,12為長度，830101為stval（83代表bool種類，01為長度，01為值，合）；8403030000為q（84代表bitstring，長度為3，共有（3-1）X8-3=13位已使用，值全0）；910849f9700202d0e58a為時間t（91為UTC時間tag，長度為8，后邊的為時間的詳細值）。共有2個值，可依據(jù)這個方式分析。ReasonCode：84020240，此中84為tag，02為長度，原由為數(shù)據(jù)變化（DataChange）。圖1為ethereal分析出來的報文。解說以下：1、RPT服務2、報告的RptID為BR03_brcbSOE013、報告的選項vvvvvvvvvvvvvvvvvvvvvvvv域，報告中包含哪些選項，按位表記，0為不存在，1為存在。4、條目號5、配置版本信息6、InclusionBitstring（該報告中出現(xiàn)的數(shù)據(jù)集成員）7、數(shù)據(jù)集成員Value（該成員為SPS，value對應一個構造體，一一對應依據(jù)從上到下的次序）8、value的stval（狀態(tài)值）9、10、

value的q（質量）value的t（時標）11、報告的觸發(fā)原由種類為：數(shù)據(jù)變化（按位為保存、數(shù)據(jù)變化、品質變化、數(shù)據(jù)更新、完好性、總呼喚，0為無1為有）圖1InformationReport1.2定值類定值服務能夠分為SGCB控制塊有關服務和定值有關服務。SGCB服務在邏輯設施中有一個定值組控制塊SGCB，SGCB包含若干屬性，SGCB有關服務可歸納為對SGCB屬性的讀寫操作，SGCB構造定義以下：此中wNumOfSG為定值組數(shù)，wActSG為目前運轉定值組，wEditSG為編寫定制組，sCnfEdit為確認編寫定值組。SGCB有關服務主要有讀取定值組數(shù)和切換定值組，切換定值組時需要確認切換。此中讀取定值組數(shù)為讀取SGCB的wNumOfSG值，而切換定值組，則是將要切換的定制組設置為目前運行組。圖2SGCB服務圖3讀定值組數(shù)圖3為讀定值組數(shù)，讀取的是SGCB的NumofSG變量值。報文內容：

1a144c4c4e30以上報文分析為：ISA351GLD1/LLN0$SP$SGCB$NumOfSG，邏輯設施名LDName為ISA351GLD1，LLN0是邏輯節(jié)點LNName，功能拘束FC為SP，該功能拘束表示數(shù)據(jù)屬性的初始值來至配置，其值不行變。數(shù)據(jù)對象DOName為SGCB，數(shù)據(jù)屬性DaName為NumOfSG。此中藍色部分報文為ISA351GLD1，1a為tag，0a為長度，共10個字符，495341333531474c4431為ISA351GLD1的ASCII碼，節(jié)余部分報文為LLN0$SP$SGCB$NumOfSG各個字符的ASCII碼值，在61850中均經(jīng)過這類方式來表記各數(shù)據(jù)引用。圖4裝置答復共9組定值裝置答復共有9組定值，在HMI上能夠看到各定值組號以及目前定值組。圖5懇求讀取目前運轉的定值組讀取目前運轉定值組經(jīng)過讀取SGCB的wActSG變量值來實現(xiàn)，報文內容如下：分析為ISA351GLD1LLN0$SP$SGCB$ActSG，方法如上文所述。圖5裝置答復為第2組圖6懇求切換第4組為目前運轉定值組切換第

4組定值為目前運轉組，方法是將第

4組定值設置為

ActSG，報文以下與讀取目前運轉定值組差別是，多出來一段報文a003860104，此中a0為tag，03為長度，01為目前運轉定值組，04為待切換定制組，這段報文意思是將目前運轉定制組從01組切換到04組。圖7裝置答復切換成功定值服務定值有關服務主要有呼喚定值以及下裝定值，只有目前運轉組的定值才能供給定值服務。將目前定制組定值呼喚上來后，即可改正定值，改正達成后需要下裝定值，為防備誤操作，需要確認下裝，若撤消下裝，則不會改正裝置定值。圖8定值有關服務點擊呼喚定值，裝置會將目前定值組定值一一上送，圖9為主站要求讀取該定值組中的第1個定值，該值的數(shù)據(jù)引用為ISA351GLD1/SETGGIO1$SG$Dz01IXDLYX$setMag，邏輯設施名$fLDName為ISA351GLD1，SETGGIO1是邏輯節(jié)點LNName，功能拘束FC為SG，帶有功能拘束SG的數(shù)據(jù)屬性的值應是目前激活值，數(shù)據(jù)屬性的初始值來至其配置，其值不行變。數(shù)據(jù)對象DOName為Dz01IXDLYX，數(shù)據(jù)屬性DaName為可見，該值數(shù)據(jù)屬性為setMag（模制定值），且該值為浮點數(shù)，對應裝置模板中的相電流越限電流定值。圖10裝置返回該值為。圖11為主站要求讀取該定值組中的第2個定值，該值的數(shù)據(jù)屬性為setVal，為狀態(tài)量，對應裝置模板中的剎時電流速斷保護投退，裝置返回該值為FALSE。圖9讀取目前定值組的第1個定值圖10裝置返回目前定值組第1個定值圖11讀取目前定值組第2個定值圖12裝置返回目前定值組第2個定值改正定值時，第一需要呼喚定值，將呼喚上來的定值改正為需要值，而后下裝定值。下裝定值前需要經(jīng)過讀取SGCB的EditSG變量來獲得可編寫定值組號（即目前運轉定值組號，圖13），數(shù)據(jù)引用為ISA351GLD1/LLN0$SP$SGCB$EditSG，功能拘束SP表示數(shù)據(jù)屬性初始值來至配置，其值不行變。而后下裝定值，如圖14，為下裝第一個定值，該值下裝為10。其數(shù)據(jù)引用為ISA351GLD1/SETGGIO1$SE$Dz01IXDLYX$setMag，$f與圖9的差別是，功能拘束變?yōu)榱薙E，表示該數(shù)據(jù)屬性可被編寫。若下裝成功則裝置將答復DataWriteSuccess，而后經(jīng)過寫SGCB的CnfEdit變量確認下裝，如圖15，該變量值為TRUE，表示下裝成功。能夠經(jīng)過呼喚測量值查察下裝能否成功。圖13讀取可編寫定值組號圖14下裝定值圖15確認下裝定值1.3控制類ACSI控制服務映照為MMS的讀寫服務，經(jīng)過MMS讀寫出名變量服務來接見控制模型，帶有可控數(shù)據(jù)屬性(從帶有FC=CO和FC=SP屬性的公用數(shù)據(jù)類所派生出的)的數(shù)據(jù)對象必定的規(guī)則進行映照。MMS出名變量組件表示FC=CO和FC=SP的數(shù)據(jù)對象，有以下通用引用：<LDname>/<LNname>$CO$<DOname><LDname>/<LNname>$SP$<DOname>控制模型到MMS控制組件的映照有慣例安全體制的選擇和直接操作、加強安全體制的選擇和直接操作，慣例安全和加強安全的DaName分別為SBO、SBOW，遙控選擇實質上就是經(jīng)過寫SBO、SBOW屬性的MMS服務來實現(xiàn)。操作的DaName為oper，相同的道理，操作服務也是經(jīng)過MMS寫操作屬性來實現(xiàn)，裝置則相應的答復寫響應，往常是DataWriteSuccess（寫成功），或許DataWriteFailure。關于選擇、操作的屬性則一定都賦值，若沒有值可寫默認值，可是一定要有相應的屬性，不然寫失敗。遙控的流程是這樣的：1、客戶端讀服務器SBOW的目錄構造，GetDataDirectory，映照為mms的GetVarAccessAttributes服務，獲得服務器端SBOW擁有的屬性，如圖16為客戶端懇求RCS923A1PROT$PTRC1$CO$VEBI1$的目錄SBOW構造。2、服務器端答復SBOW的目錄構造。圖17答復的SBOW目錄構造，包括ctlval、origin（包含orCat、orIdent）、ctlnum、T、Test、Check，意思分別是：控制值（Bool種類）、命令倡始者、控制編號、時間、測試、檢查。目前大多數(shù)廠家都只寫控制值，其他的屬性均賦默認值，控制值TRUE代表合，F(xiàn)ALSE代表分。3、客戶端發(fā)送寫SBOW懇求ConfRequest:write（這類服務表示需要服務器端答復，不然沒法持續(xù)交互報文，而裝置上送的報告為Unconfirmed,即無需確認的服務），如圖18寫RCS923A1PROT$PTRC1$CO$VEBI1$，此中SBOWctlval為TRUE，為合，其他各屬性值為客戶端默認賦值，所有控制報文均這樣，能夠不用管。4、裝置答復寫懇求（ConfResponse:Write）：DatawriteSuccess，即寫數(shù)據(jù)成功，如圖19.5、6、

客戶端發(fā)送寫oper懇求ConfRequest:write，如圖20寫RCS923A1PROT$PTRC1$CO$VEBI1$，其屬性值和OperSBOW一致。裝置答復寫成功，整個遙控過程結束。仔細剖析能夠發(fā)現(xiàn)，61850遙控的過程和非61850遙控過程是相同的，寫SBOW相當于遙控選擇，而寫oper值則相當于遙控履行，不論是選擇仍是履行都需要遙控返校。圖16客戶端懇求SBOW目錄機構圖17服務器端答復SBOW目錄構造圖18客戶端發(fā)送寫SBOW懇求圖19服務器答復寫成功圖20客戶端發(fā)送寫oper懇求1.4讀目錄服務讀目錄服務用于后臺與裝置之間長時間沒有報文交互時，測試網(wǎng)絡能否正常。圖21主機向裝置發(fā)送懇求讀目錄圖22裝置答復讀出ISA351G，且沒有后續(xù)報文1.5文件服務保信子站需要呼喚錄波文件，就是經(jīng)過文件服務來實現(xiàn)，那么客戶端怎么知道能否有錄波文件呢目前有兩種做法：一是，服務器初始化時就將Rcdmade置1，開始錄波時Rcdmade被置成0，錄波達成后Rcdmade又被置成1，所以只需Rcdmade為1就能夠去呼喚錄波文件，我企業(yè)、四方以及中元華電等廠家都是這類辦理方式；另一種方法是，服務器初始化時Rcdmade被置成0，只需有新的錄波產(chǎn)生馬上Rcdmade置成1，這個時候就能夠去召錄波文件。召錄波文件的流程是這樣的：1、客戶端向服務器端發(fā)送讀錄波文件目錄懇求（ConfRequest:FileDirectory），如圖23所示，標準中規(guī)定，錄波文件應為COMTRADE格式，COMTRADE格式又有1997和1999版，錄波文件可經(jīng)過我企業(yè)保護工程師站中的故障剖析工具查察，但只好查察切合COMTRADE格式1999版的錄波文件。別的標準中還規(guī)定錄波文件在服務器中應包含在“COMTRADE”的文件目錄內。2、服務器端返回錄波文件目錄列表，如圖24。在客戶端內存中會保護一張錄波文件目錄表，客戶端假如發(fā)現(xiàn)此次呼喚的目錄列表和內存中的不一致