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客户端请求关闭文件
升级会员 