61850典型报文解析说明.docx
《61850典型报文解析说明.docx》由会员分享,可在线阅读,更多相关《61850典型报文解析说明.docx(18页珍藏版)》请在冰豆网上搜索。
61850典型报文解析说明
61850典型报文解析说明
编写:
欧灶军
1平台
现利用ethereal报文抓捕工具抓取部分典型报文解析说明。
1.1报告类COS
61850报告服务,是一项非常重要的ACSI服务,它通过SCSM映射为MMS协议中的InformationReport服务,我们在调试过程中通过捕包工具得到的61850报告报文,都是经过编码后的InformationReport数据。
建好数据库,连接好装置后,启动SCADA服务器,并用ethereal抓报文,根据报告格式进行解析。
例如抓到的SOE报告ID号为BR03_brcbSOE01,其中03与模板中定义的各种报告类型有关,例如在我使用的装置模板中这么定义的:
brcbREC、brcbCHK、brcbSOE分别为BR01、BR02、BR03,01表示该报告已经实例化。
由于InformationReport各成员的数据类型是确定的,根据编码规则,各数据编码后的数据也是确定的:
RptID编码后数据为:
8aXXXX…XX;
OptFlds编码后数据为:
840307XXX0;
SqNum编码后数据为:
86XXXX…XX;
TimeOfEntry编码后数据为:
8C06XXXXXXXXXXXX;
DataSet编码后数据为:
8aXXXX…XX;
BufOvfl编码后数据为:
8301XX;
EntryID编码后数据为:
89XXXX…XX;
ConfRev编码后数据为:
86XXXX…XX;
SubSeqNum编码后数据为:
86XXXX…XX;
MoreSegmentFollow编码后数据为:
8301XX;
Inclusion-bitstring编码后数据为:
84XX…XX;
Data-Reference编码后数据为:
8aXX…XX;
Value取决于具体数据类型;
ReasonCode编码后数据为:
84XX…XX;
下面以SOE报文为例,说明整个报告的含义,报文如下:
8a0e425230335f62726362534f453031(RptID)
8403071180(OptFlds)
89080000000000000020(EntryID)
860101(ConfRev)
8406058000001000(Inclusion-bitstring)
a2128301018403030000910849f9700202d0e58aa213840206408403030000910849f97002051eb88a(Values,共2个)
8402024084020240(ReasonCode,共2个)
报告解析如下:
RptID(BR03_brcbSOE01):
8a0e425230335f62726362534f453031,其中8a为tag,长度为0e,后面的为ID编码。
OptFlds:
8403075300,84为tag,长度为03,1180(解析为:
000100011000)决定各可选项是否出现,各位含义如下:
ACSIValueofRCBStates
MMSBitPosition
Reserved
0
Sequence-number
1
Report-time-Stamp
2
Reason-for-Inclusion
3
Data-Set-Name
4
Data-Reference
5
Buffer-Overflow
6
EntryID
7
Conf-Rev
8
Segmentation
9
因此,解析后可知,第3、7、8位出现,即Reason-for-Inclusion、EntryID、Conf-Rev出现。
EntryID:
89080000000000000020,89为tag,长度为9,条目号为20
Conf-Rev:
860101,配置版本号,86为tag,01为长度,值为01,TRUE。
Inclusion-bitstring:
8406058000001000,84为tag,06为长度,同时已用的位共有:
(Length-1)X8-5=35位。
其中第1、28位有值,其余全0。
Value:
a2128301018403030000910849f9700202d0e58a,其中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个值,可根据这个方式解析。
ReasonCode:
84020240,其中84为tag,02为长度,原因为数据变化(DataChange)。
图1为ethereal解析出来的报文。
解释如下:
1、RPT服务
2、报告的RptID为BR03_brcbSOE01
3、报告的选项vvvvvvvvvvvvvvvvvvvvvvvv域,报告中包含哪些选项,按位标识,0为不存在,1为存在。
4、条目号
5、配置版本信息
6、InclusionBitstring(该报告中出现的数据集成员)
7、数据集成员Value(该成员为SPS,value对应一个结构体,一一对应按照从上到下的顺序)
8、value的stval(状态值)
9、value的q(品质)
10、value的t(时标)
11、报告的触发原因类型为:
数据变化(按位为保留、数据变化、品质变化、数据更新、完整性、总召唤,0为无1为有)
图1InformationReport
1.2定值类
定值服务可以分为SGCB控制块相关服务和定值相关服务。
1.2.1SGCB服务
在逻辑设备中有一个定值组控制块SGCB,SGCB包含若干属性,SGCB相关服务可归结为对SGCB属性的读写操作,SGCB结构定义如下:
其中wNumOfSG为定值组数,wActSG为当前运行定值组,wEditSG为编辑定制组,sCnfEdit为确认编辑定值组。
SGCB相关服务主要有读取定值组数和切换定值组,切换定值组时需要确认切换。
其中读取定值组数为读取SGCB的wNumOfSG值,而切换定值组,则是将要切换的定制组设置为当前运行组。
图2SGCB服务
图3读定值组数
图3为读定值组数,读取的是SGCB的NumofSG变量值。
报文内容:
1a0a495341333531474c44311a144c4c4e302453502453474342244e756d4f665347
以上报文解析为:
ISA351GLD1/LLN0$SP$SGCB$NumOfSG,逻辑设备名LDName为ISA351GLD1,LLN0是逻辑节点LNName,功能约束FC为SP,该功能约束表示数据属性的初始值来至配置,其值不可变。
数据对象DOName为SGCB,数据属性DaName为NumOfSG。
其中蓝色部分报文为ISA351GLD1,1a为tag,0a为长度,共10个字符,495341333531474c4431为ISA351GLD1的ASCII码,剩余部分报文为LLN0$SP$SGCB$NumOfSG各个字符的ASCII码值,在61850中均通过这种方式来标识各数据引用。
图4装置回复共9组定值
装置回复共有9组定值,在HMI上可以看到各定值组号以及当前定值组。
图5请求读取当前运行的定值组
读取当前运行定值组通过读取SGCB的wActSG变量值来实现,报文内容如下:
解析为ISA351GLD1LLN0$SP$SGCB$ActSG,方法如上文所述。
图5装置回复为第2组
图6请求切换第4组为当前运行定值组
切换第4组定值为当前运行组,方法是将第4组定值设置为ActSG,报文如下
与读取当前运行定值组区别是,多出来一段报文a003860104,其中a0为tag,03为长度,01为当前运行定值组,04为待切换定制组,这段报文意思是将当前运行定制组从01组切换到04组。
图7装置回复切换成功
1.2.2定值服务
定值相关服务主要有召唤定值以及下装定值,只有当前运行组的定值才能提供定值服务。
将当前定制组定值召唤上来后,即可修改定值,修改完成后需要下装定值,为防止误操作,需要确认下装,若取消下装,则不会修改装置定值。
图8定值相关服务
点击召唤定值,装置会将当前定值组定值一一上送,图9为主站要求读取该定值组中的第1个定值,该值的数据引用为ISA351GLD1/SETGGIO1$SG$Dz01IXDLYX$setMag$f,逻辑设备名LDName为ISA351GLD1,SETGGIO1是逻辑节点LNName,功能约束FC为SG,带有功能约束SG的数据属性的值应是当前激活值,数据属性的初始值来至其配置,其值不可变。
数据对象DOName为Dz01IXDLYX,数据属性DaName为可见,该值数据属性为setMag(模拟定值),且该值为浮点数,对应装置模板中的相电流越限电流定值。
图10装置返回该值为。
图11为主站要求读取该定值组中的第2个定值,该值的数据属性为setVal,为状态量,对应装置模板中的瞬时电流速断保护投退,装置返回该值为FALSE。
图9读取当前定值组的第1个定值
图10装置返回当前定值组第1个定值
图11读取当前定值组第2个定值
图12装置返回当前定值组第2个定值
修改定值时,首先需要召唤定值,将召唤上来的定值修改为需要值,然后下装定值。
下装定值前需要通过读取SGCB的EditSG变量来获取可编辑定值组号(即当前运行定值组号,图13),数据引用为ISA351GLD1/LLN0$SP$SGCB$EditSG,功能约束SP表明数据属性初始值来至配置,其值不可变。
然后下装定值,如图14,为下装第一个定值,该值下装为10。
其数据引用为ISA351GLD1/SETGGIO1$SE$Dz01IXDLYX$setMag$f,与图9的区别是,功能约束变成了SE,表示该数据属性可被编辑。
若下装成功则装置将回复DataWriteSuccess,然后通过写SGCB的CnfEdit变量确认下装,如图15,该变量值为TRUE,表示下装成功。
可以通过召唤测量值查看下装是否成功。
图13读取可编辑定值组号
图14下装定值
图15确认下装定值
1.3控制类
ACSI控制服务映射为MMS的读写服务,通过MMS读写有名变量服务来访问控制模型,带有可控数据属性(从带有FC=CO和FC=SP属性的公用数据类所派生出的)的数据对象一定的规则进行映射。
MMS有名变量组件表示FC=CO和FC=SP的数据对象,有如下通用引用:
/$CO$
/$SP$
控制模型到MMS控制组件的映射有常规安全机制的选择和直接操作、增强安全机制的选择和直接操作,常规安全和增强安全的DaName分别为SBO、SBOW,遥控选择实际上就是通过写SBO、SBOW属性的MMS服务来实现。
操作的DaName为oper,同样的道理,操作服务也是通过MMS写操作属性来实现,装置则相应的回复写响应,通常是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类型)、命令发起者、控制编号、时间、测试、检查。
目前大部分厂家都只写控制值,其它的属性均赋默认值,控制值TRUE代表合,FALSE代表分。
3、客户端发送写SBOW请求ConfRequest:
write(这种服务表示需要服务器端回复,否则无法继续交互报文,而装置上送的报告为Unconfirmed,即无需确认的服务),如图18写RCS923A1PROT$PTRC1$CO$VEBI1$SBOW,其中ctlval为TRUE,为合,其余各属性值为客户端默认赋值,所有控制报文均如此,可以不用管。
4、装置回复写请求(ConfResponse:
Write):
DatawriteSuccess,即写数据成功,如图19.
5、客户端发送写oper请求ConfRequest:
write,如图20写RCS923A1PROT$PTRC1$CO$VEBI1$Oper,其属性值和SBOW一致。
6、装置回复写成功,整个遥控过程结束。
认真分析可以发现,61850遥控的过程和非61850遥控过程是一样的,写SBOW相当于遥控选择,而写oper值则相当于遥控执行,无论是选择还是执行都需要遥控返校。
图16客户端请求SBOW目录机构
图17服务器端回复SBOW目录结构
图18客户端发送写SBOW请求
图19服务器回复写成功
图20客户端发送写oper请求
1.4读目录服务
读目录服务用于后台与装置之间长时间没有报文交互时,测试网络是否正常。
图21主机向装置发送请求读目录
图22装置回复读出ISA351G,且没有后续报文
1.5文件服务
保信子站需要召唤录波文件,就是通过文件服务来实现,那么客户端怎么知道是否有录波文件呢目前有两种做法:
一是,服务器初始化时就将Rcdmade置1,开始录波时Rcdmade被置成0,录波完成后Rcdmade又被置成1,因此只要Rcdmade为1就可以去召唤录波文件,我公司、四方以及中元华电等厂家都是这种处理方式;另一种方法是,服务器初始化时Rcdmade被置成0,只要有新的录波产生即将Rcdmade置成1,这个时候就可以去召录波文件。
召录波文件的流程是这样的:
1、客户端向服务器端发送读录波文件目录请求(ConfRequest:
FileDirectory),如图23所示,标准中规定,录波文件应为COMTRADE格式,COMTRADE格式又有1997和1999版,录波文件可通过我公司保护工程师站中的故障分析工具查看,但只能查看符合COMTRADE格式1999版的录波文件。
此外标准中还规定录波文件在服务器中应包含在“COMTRADE”的文件目录内。
2、服务器端返回录波文件目录列表,如图24。
在客户端内存中会维护一张录波文件目录表,客户端如果发现此次召唤的目录列表和内存中的不一致,则代表有新的录波产生,这样,客户端就会去调取新的录波文件。
图23和24的InvokeID均为43,表示这是同一个请求和回复。
3、客户端发送打开文件请求(ConfRequest:
Fileopen),按照尚未读取的文件的时间顺序,最新产生的录波文件优先打开并读取。
如图25,打开COMTRADE目录下的122M文件,
4、服务器端响应打开文件请求,这其中包含了资源ID,文件大小,以及最后修改时间如图26。
5、客户端发送读文件请求,读取的数据就是资源ID为文件中的数据,图27.
6、服务器端通过COTP服务读文件中的数据,如图28.一般情况下,录波文件很大,一帧报文无法将其中的数据全部上送,因此需要多次读操作,标准中通过moreFollows位来确定是否还有数据尚未读完,如果moreFollows为TRUE,则代表还有数据需要读取,客户端再次请求读文件服务,若moreFollows为FALSE则代表数据已经全部读取完毕,引发客户端关闭文件的操作。
7、客户端发送关闭资源ID为的文件。
8、服务器端关闭文件,至此122M文件读取完毕,然而对于一个完整的录波文件,还包括.cfg,.hdr文件,这两个文件也需要读取,过程和.dat文件一致,三个文件都读取完毕,则一个录波文件读取完成。
图23客户端发送读文件目录请求
图24服务器端返回录波文件目录列表
图25客户端发送打开文件请求
图26服务器端响应打开文件请求
图27客户端发送读文件请求
图28服务器端读文件
图29客户端请求关闭文件