61850典型报文解析说明.docx

1、61850典型报文解析说明-CAL-FENGHAI.-(YICAI)-Company One161850典型报文解析说明61850典型报文解析说明编写：欧灶军1 平台 现利用ethereal报文抓捕工具抓取部分典型报文解析说明。1.1报告类 COS 61850报告服务，是一项非常重要的ACSI服务，它通过SCSM映射为MMS协议中的InformationReport服务，我们在调试过程中通过捕包工具得到的61850报告报文，都是经过编码后的InformationReport数据。建好数据库，连接好装置后，启动SCADA服务器，并用ethereal抓报文，根据报告格式进行解析。例如抓到的SOE报

2、告ID号为BR03_brcbSOE01，其中03与模板中定义的各种报告类型有关，例如在我使用的装置模板中这么定义的：brcbREC、brcbCHK、brcbSOE分别为BR01、BR02、BR03，01表示该报告已经实例化。由于InformationReport各成员的数据类型是确定的，根据编码规则，各数据编码后的数据也是确定的：RptID编码后数据为： 8a XX XX XX；OptFlds编码后数据为： 84 03 07 XX X0；SqNum编码后数据为： 86 XX XX XX；TimeOfEntry编码后数据为：8C 06 XX XX XX XX XX XX；DataSet编码后数据

3、为： 8a XX XX XX；BufOvfl编码后数据为： 83 01 XX；EntryID编码后数据为： 89 XX XX XX；ConfRev编码后数据为： 86 XX XX XX；SubSeqNum编码后数据为：86 XX XX XX；MoreSegmentFollow编码后数据为：83 01 XX；Inclusion-bitstring编码后数据为： 84 XX XX；Data-Reference编码后数据为： 8a XX XX；Value取决于具体数据类型；ReasonCode编码后数据为： 84 XX XX；下面以SOE报文为例，说明整个报告的含义，报文如下：8a 0e 42 52

4、 30 33 5f 62 72 63 62 53 4f 45 30 31 (RptID) 84 03 07 11 80(OptFlds) 89 08 00 00 00 00 00 00 00 20 (EntryID) 86 01 01 (ConfRev)84 06 05 80 00 00 10 00 (Inclusion-bitstring)a2 12 83 01 01 84 03 03 00 00 91 08 49 f9 70 02 02 d0 e5 8a a2 13 84 02 06 40 84 03 03 00 00 91 08 49 f9 70 02 05 1e b8 8a （Valu

5、es,共2个）84 02 02 40 84 02 02 40 (ReasonCode，共2个)报告解析如下：RptID（BR03_brcbSOE01）：8a 0e 42 52 30 33 5f 62 72 63 62 53 4f 45 30 31，其中8a为tag，长度为0e，后面的为ID编码。OptFlds：84 03 07 53 00 ，84为tag，长度为03，11 80（解析为：0 0 0 1 0 0 0 1 1 0 0 0）决定各可选项是否出现，各位含义如下：ACSI Value of RCBStatesMMS Bit PositionReserved0Sequence-number

6、1Report-time-Stamp2Reason-for-Inclusion3Data-Set-Name4Data-Reference5Buffer-Overflow6EntryID7Conf-Rev8Segmentation9因此，解析后可知，第3、7、8位出现，即Reason-for-Inclusion 、EntryID、Conf-Rev出现。EntryID：89 08 00 00 00 00 00 00 00 20，89为tag，长度为9，条目号为20Conf-Rev：86 01 01，配置版本号，86为tag，01为长度，值为01，TRUE。Inclusion-bitstring：8

7、4 06 05 80 00 00 10 00，84为tag，06为长度，同时已用的位共有：(Length-1)X8-5=35位。其中第1、28位有值，其余全0。Value：a2 12 83 01 01 84 03 03 00 00 91 08 49 f9 70 02 02 d0 e5 8a，其中a2为tag,12为长度，83 01 01 为stval（83 代表bool类型，01为长度，01为值，合）；84 03 03 00 00为q（84代表bitstring，长度为3，共有（3-1）X8-3=13位已使用，值全0）；91 08 49 f9 70 02 02 d0 e5 8a为时间t（91为

8、UTC时间tag，长度为8，后面的为时间的具体值）。共有2个值，可根据这个方式解析。ReasonCode：84 02 02 40，其中84为tag，02为长度，原因为数据变化（DataChange）。图1为ethereal解析出来的报文。解释如下：1、RPT服务2、报告的RptID为BR03_brcbSOE013、报告的选项 vv vvvvvv vvvvvvvvvvvvvvv v 域，报告中包含哪些选项，按位标识，0为不存在，1为存在。4、条目号5、配置版本信息6、InclusionBitstring（该报告中出现的数据集成员）7、数据集成员Value（该成员为SPS，value对应一个结构体

9、，一一对应按照从上到下的顺序）8、value的stval（状态值）9、value的q（品质）10、value的t（时标）11、报告的触发原因类型为：数据变化（按位为保留、数据变化、品质变化、数据更新、完整性、总召唤，0为无1为有）图1 InformationReport1.2定值类定值服务可以分为SGCB控制块相关服务和定值相关服务。1.2.1SGCB服务在逻辑设备中有一个定值组控制块SGCB，SGCB包含若干属性，SGCB相关服务可归结为对SGCB属性的读写操作，SGCB结构定义如下：其中wNumOfSG为定值组数，wActSG为当前运行定值组，wEditSG为编辑定制组，sCnfEdit为

10、确认编辑定值组。SGCB相关服务主要有读取定值组数和切换定值组，切换定值组时需要确认切换。其中读取定值组数为读取SGCB的wNumOfSG值，而切换定值组，则是将要切换的定制组设置为当前运行组。图2 SGCB服务图3读定值组数图3为读定值组数，读取的是SGCB的NumofSG变量值。报文内容：1a 0a 49 53 41 33 35 31 47 4c 44 31 1a 14 4c 4c 4e 30 24 53 50 24 53 4743 42 24 4e 75 6d 4f 66 53 47 以上报文解析为：ISA351GLD1/LLN0$SP$SGCB$NumOfSG，逻辑设备名LDName为

11、ISA351GLD1，LLN0是逻辑节点LNName，功能约束FC为SP，该功能约束表示数据属性的初始值来至配置，其值不可变。数据对象DOName为SGCB，数据属性DaName为NumOfSG。其中蓝色部分报文为ISA351GLD1，1a为tag，0a为长度，共10个字符，49 53 41 33 35 31 47 4c 44 31为ISA351GLD1的ASCII码，剩余部分报文为LLN0$SP$SGCB$NumOfSG各个字符的ASCII码值，在61850中均通过这种方式来标识各数据引用。图4 装置回复共9组定值 装置回复共有9组定值，在HMI上可以看到各定值组号以及当前定值组。图5 请求

12、读取当前运行的定值组读取当前运行定值组通过读取SGCB的wActSG变量值来实现，报文内容如下：解析为ISA351GLD1LLN0$SP$SGCB$ActSG，方法如上文所述。图5 装置回复为第2组图6 请求切换第4组为当前运行定值组切换第4组定值为当前运行组，方法是将第4组定值设置为ActSG，报文如下与读取当前运行定值组区别是，多出来一段报文a0 03 86 01 04，其中a0为tag，03为长度，01为当前运行定值组，04为待切换定制组，这段报文意思是将当前运行定制组从01组切换到04组。图7 装置回复切换成功1.2.2定值服务定值相关服务主要有召唤定值以及下装定值，只有当前运行组的定

13、值才能提供定值服务。将当前定制组定值召唤上来后，即可修改定值，修改完成后需要下装定值，为防止误操作，需要确认下装，若取消下装，则不会修改装置定值。图8 定值相关服务点击召唤定值，装置会将当前定值组定值一一上送，图9为主站要求读取该定值组中的第1个定值，该值的数据引用为ISA351GLD1/SETGGIO1$SG$Dz01IXDLYX$setMag$f，逻辑设备名LDName为ISA351GLD1，SETGGIO1是逻辑节点LNName，功能约束FC为SG，带有功能约束SG的数据属性的值应是当前激活值，数据属性的初始值来至其配置，其值不可变。数据对象DOName为Dz01IXDLYX，数据属性D

14、aName为可见，该值数据属性为setMag（模拟定值），且该值为浮点数，对应装置模板中的相电流越限电流定值。图10装置返回该值为。图11为主站要求读取该定值组中的第2个定值，该值的数据属性为setVal，为状态量，对应装置模板中的瞬时电流速断保护投退，装置返回该值为FALSE。图9 读取当前定值组的第1个定值图10 装置返回当前定值组第1个定值图11 读取当前定值组第2个定值图12装置返回当前定值组第2个定值修改定值时，首先需要召唤定值，将召唤上来的定值修改为需要值，然后下装定值。下装定值前需要通过读取SGCB的EditSG变量来获取可编辑定值组号（即当前运行定值组号，图13），数据引用为I

15、SA351GLD1/LLN0$SP$SGCB$EditSG，功能约束SP表明数据属性初始值来至配置，其值不可变。然后下装定值，如图14，为下装第一个定值，该值下装为10。其数据引用为ISA351GLD1/SETGGIO1$SE$Dz01IXDLYX$setMag$f，与图9的区别是，功能约束变成了SE，表示该数据属性可被编辑。若下装成功则装置将回复 Data Write Success，然后通过写SGCB的CnfEdit变量确认下装，如图15，该变量值为TRUE，表示下装成功。可以通过召唤测量值查看下装是否成功。图13 读取可编辑定值组号图14 下装定值图15 确认下装定值1.3控制类ACSI

16、控制服务映射为MMS的读写服务，通过MMS读写有名变量服务来访问控制模型，带有可控数据属性(从带有FC=CO和FC=SP属性的公用数据类所派生出的)的数据对象一定的规则进行映射。MMS有名变量组件表示FC=CO和FC=SP的数据对象，有如下通用引用：/$CO$/$SP$控制模型到MMS控制组件的映射有常规安全机制的选择和直接操作、增强安全机制的选择和直接操作，常规安全和增强安全的DaName分别为SBO、SBOW，遥控选择实际上就是通过写SBO、SBOW属性的MMS服务来实现。操作的DaName为oper，同样的道理，操作服务也是通过MMS写操作属性来实现，装置则相应的回复写响应，通常是Dat

17、a Write Success（写成功），或者Data Write Failure。对于选择、操作的属性则必须都赋值，若没有值可写默认值，但是必须要有相应的属性，否则写失败。遥控的流程是这样的：1、客户端读服务器SBOW的目录结构，GetDataDirectory，映射为mms的GetVarAccessAttributes服务，获取服务器端SBOW具有的属性，如图16为客户端请求RCS923A1PROT$PTRC1$CO$VEBI1$SBOW的目录结构。2、服务器端回复SBOW的目录结构。图17回复的SBOW目录结构，包括ctlval、origin（包括orCat、orIdent）、ctlnu

18、m、T、Test、Check，意思分别是：控制值（Bool类型）、命令发起者、控制编号、时间、测试、检查。目前大部分厂家都只写控制值，其它的属性均赋默认值，控制值TRUE代表合，FALSE代表分。3、客户端发送写SBOW请求Conf Request:write（这种服务表示需要服务器端回复，否则无法继续交互报文，而装置上送的报告为Unconfirmed,即无需确认的服务），如图18写RCS923A1PROT$PTRC1$CO$VEBI1$SBOW，其中ctlval为TRUE，为合，其余各属性值为客户端默认赋值，所有控制报文均如此，可以不用管。4、装置回复写请求（Conf Response:Wr

19、ite）：Data write Success，即写数据成功，如图19.5、客户端发送写oper请求Conf Request:write，如图20写RCS923A1PROT$PTRC1$CO$VEBI1$Oper，其属性值和SBOW一致。6、装置回复写成功，整个遥控过程结束。认真分析可以发现，61850遥控的过程和非61850遥控过程是一样的，写SBOW相当于遥控选择，而写oper值则相当于遥控执行，无论是选择还是执行都需要遥控返校。图16 客户端请求SBOW目录机构图17 服务器端回复SBOW目录结构图18 客户端发送写SBOW请求图19 服务器回复写成功图20 客户端发送写oper请求1.

20、4读目录服务读目录服务用于后台与装置之间长时间没有报文交互时，测试网络是否正常。图21主机向装置发送请求读目录图22 装置回复读出ISA351G，且没有后续报文1.5文件服务保信子站需要召唤录波文件，就是通过文件服务来实现，那么客户端怎么知道是否有录波文件呢目前有两种做法：一是，服务器初始化时就将Rcdmade置1，开始录波时Rcdmade 被置成0，录波完成后Rcdmade又被置成1，因此只要Rcdmade为1就可以去召唤录波文件，我公司、四方以及中元华电等厂家都是这种处理方式；另一种方法是，服务器初始化时Rcdmade被置成0，只要有新的录波产生即将Rcdmade置成1，这个时候就可以去召

21、录波文件。召录波文件的流程是这样的：1、客户端向服务器端发送读录波文件目录请求（Conf Request:File Directory），如图23所示，标准中规定，录波文件应为COMTRADE格式，COMTRADE格式又有1997和1999版，录波文件可通过我公司保护工程师站中的故障分析工具查看，但只能查看符合COMTRADE格式1999版的录波文件。此外标准中还规定录波文件在服务器中应包含在“COMTRADE”的文件目录内。2、服务器端返回录波文件目录列表，如图24。在客户端内存中会维护一张录波文件目录表，客户端如果发现此次召唤的目录列表和内存中的不一致，则代表有新的录波产生，这样，客户端就

22、会去调取新的录波文件。图23和24的InvokeID均为43，表示这是同一个请求和回复。3、客户端发送打开文件请求（Conf Request:File open），按照尚未读取的文件的时间顺序，最新产生的录波文件优先打开并读取。如图25，打开COMTRADE目录下的122M文件，4、服务器端响应打开文件请求，这其中包含了资源ID，文件大小，以及最后修改时间如图26。5、客户端发送读文件请求，读取的数据就是资源ID为文件中的数据，图27.6、服务器端通过COTP服务读文件中的数据，如图28.一般情况下，录波文件很大，一帧报文无法将其中的数据全部上送，因此需要多次读操作，标准中通过moreFoll

23、ows位来确定是否还有数据尚未读完，如果moreFollows为TRUE，则代表还有数据需要读取，客户端再次请求读文件服务，若moreFollows为FALSE则代表数据已经全部读取完毕，引发客户端关闭文件的操作。7、客户端发送关闭资源ID为的文件。8、服务器端关闭文件，至此122M文件读取完毕，然而对于一个完整的录波文件，还包括.cfg，.hdr文件，这两个文件也需要读取，过程和.dat文件一致，三个文件都读取完毕，则一个录波文件读取完成。图23 客户端发送读文件目录请求图24 服务器端返回录波文件目录列表图25 客户端发送打开文件请求图26 服务器端响应打开文件请求图27 客户端发送读文件请求图28 服务器端读文件图29 客户端请求关闭文件