61850规约之二-----有关GOOSE的个人理解

有关GOOSE的个人理解

GOOSE是英文Generic Object Oriented Substation Event的缩写，即面向变电站事件的通用对象。用于在变电站的IED（智能电气设备）之间进行快速水平通讯。IEC61850-5 所定义的报文类型如下
-类型1（快速报文）
-类型1A（跳闸报文）
-类型2（中等速度报文）
-类型3（低速报文）
-类型4（原始数据报文）
-类型5（文件传输功能）
-类型6（时间同步报文）
GOOSE就用于传递类型1和类型1A两种类型的报文，即传递速度最快的两种报文。

表7 – 用于GSE管理和GOOSE通信A-协议子集的服务和协议

表8 – GOOSE/GSE 传输协议子集

GOOSE报文是直接映射到专门的以太网类型，这样可以提高速度，即报文直接发到链路层。

前导同步信号由0与1交替的一个序列。

目的MAC地址指此报文要发送的的目的主机MAC地址，在GOOSE报文中，此地址为组播地址，即此地址不是任何一个主机的地址，而是此组中的成员都可以收到此报文，按IEC61850-8标准如下，
本标准所使用的多播地址（6个字节）应有如下结构：
-前3个字节被IEEE定为01-0C-CD；
-第4个字节，对于GOOSE，为01；为GSSE，为02；对多播采样值，为04；
-最后2个字节应为单独地址，其范围如表B1所定义。

源MAC地址指发出此GOOSE报文的主机地址。

由于GOOSE报文封装在802.1Q中，因此此处的报文类型为802.1Q报文类型，即0x8100

CRC校验为对整个帧的校验。

具体报文对于GOOSE如下

优先级标志TCL，
用户优先级：BS3；用户优先级值被配置设置用于将采样值和对时间要求苛刻的保护相关GOOSE报文与低优先级的网络负荷分开。如果该优先级未配置，将使用表C.1的缺省值。
CFI：BS1[0]；如果该数值为TRUE，嵌入资源标识域（RIF）按照ISO/IEC8802-3标志帧的长度/类型域的值。值应该为FALSE（例如，0）。
注1：如果设置值为1，嵌入式资源标志域（E-RIF）按照ISO/IEC8802-3长度/标志域。
VID：虚拟LAN支持是可选的。如果这个机制被使用，VID将被配置设置。如果不用，将被设置为0。
注2：IEEE802.1Q允许实现带有优先级设置，高优先级的帧应该具有优先级4-7，低优先级具有1-3。为标记的优先级为1，0应避免使用，可能由于正常网络流量，引起不可预测的延迟。此外，采样值需要部分带宽的分配，其缺省的VID应与GOOSE和GSE的不同。
表C1定义了优先级和VID的缺省值。

IEEE802.1Q实际就4个字节，前两个字节为报文类型，固定为0X8100,后两个字节为优先级标志TCL，如上所述。

按现在的理解，
1、若IED发出的GOOSE报文是没有这4个字节的，因为要实现优先传送需要在交换机中进行处理，交换机中收到的报文首先是放入缓存队列中，然后才转发，对于支持GOOSE报文的交换机，就会将此GOOSE报文增加IEEE802.1Q的4个字节并进行优先处理，在发送时，若发出的端口为一般端口，说明接的是IED设备，则将IEEE802.1Q的4个字节去掉并发送，若发出的端口为TAG AWARE端口，即可能是另外一个交换机，则不删除IEEE802.1Q的4个字节而发送。此处有几个问题，一是交换机怎么识别这是GOOSE报文，当然，对于GOOSE报文，在源MAC地址后的报文类型为0X88B8,但这个就对交换机有了要求，需要能识别出此报文的交换机才能成为支持GOOSE的交换机，而一般的交换机就做不到。二是对于优先级的安排，若交换机不能配置，即每次加到GOOSE报文前的优先级是一样的，则优先级只能固定。

2、若IED发出的GOOSE报文就是有这个4个字节的，则交换机只需要能支持802.1Q就行了，对于收到的报文，交换机判断其优先级，进行优先处理，发送到端口时，同1一样，根据端口类型发出不同的报文。但问题是ABB的SPAZC400发出的报文是不带802.1Q这4个字节的。因此SPAZC400-CET中即使有VID的配置，也没有任何作用。

优先级标志TCL后面的报文类型及APPID分配如下：

对于GOOSE报文，此报文类型就是0X88B8。

APPID： 应用标识。APPID用于选择含有GSE管理和GOOSE报文的ISO/IEC8802-3帧并能够区分应用关联。APPID值是APPID类型（最高2位，如表C2定义）和实际ID的综合。这导致了如下值：
GOOSE的预留值范围是0x000到0x3fff。如果APPID为配置，其缺省值为0x000。缺省值保留用于表示缺乏配置。强烈建议在一个系统中，使用面向源的、独立的GOOSE APPID。这应该被配置系统所实施。
GSE管理应该与GOOSE发出APPID一样，与被发出的GSE管理请求一致。GSE管理响应的APPID应该与GSE请求的一样。
APPID(Application Identifier)是用于一个整型数来标识发送端的GOOSE CB及其数据。它在整个系统中应该是唯一的。

长度：从APPID开始到报文结束的长度，APDU的长度是m。于是长度应该是8+m，其中m<1480。
与此不一致的帧或非法长度域的帧将被丢弃。

保留1和保留2为未来标准化的应用而保留，缺省值为0。

APDU（应用协议数据单元）八位组应定义在IEC61850-8-1附录A中。为具体的GOOSE报文。
Control Block Reference（gocbRef）
Time Allowed to Live（timeAllowedtoLive） = T0
DataSetReference（datSet）
GOOSEID（goID） 暂时不知道什么含义，见问题讨论
Event Timestamp（t） 事件发生的时间，类型见8-1 8.1.3.6及附录G.3.1，有待做试验验证qulity 需加上stNum加1的时间 7-2 15.2.3.5
StateNumber（stNum） 每发送一次GOOSE报文且由DatSet规定的DATA-SET内已经检出值的改变，计数器加1，初始值为1，0保留 7-2 15.2.3.6
Sequence Number（sqNum） 是发送一次GOOSE报文加1,初始值1，0保留，7-2 15.2.3.7
Test（test） 值为TRUE时表示报文的值不得用于运行，，7-2 15.2.3.8
Config Revision（confRev） 配置版本号，被DataSet引用的DATA-SET配置已改变的次数计数，7-2 15.2.3.9
Need Commissioning（ndsCom） 现在认为是配置数量若超过了SCSM的现在，就会发出TRUE
数据个数及数据
按DO还是DA方式发送接收还需要做实验。
对于GOOSE发送的时间控制，如下图：

也就是说当事件触发GOOSE报文时发出4个GOOSE报文，但现在对于T1,T2,T3的时间长短还不是很清楚，似乎是1，1，2，8，SPAZC400发出的T1有时比T2还长？平时通过重发相同数据来获得额外的可靠性，时间为T0，此时发送的GOOSE报文中的值应该是当前值。
在PCM600中，T0的配置为maxtime，T1的配置为minTime，也就是说，若T1配置为1ms，则T2为2ms，T3为8ms，为何如此，没有找到依据。

对于GOOSE APDU中的GOOSEID，接收方要检查接收到的此值与SCL配置文件的值是否相等，若不等，则不能接收此GOOSE报文。还需要检查的部分有待讨论

在配置文件中（ICD,CID,SCD）涉及GOOSE的部分
1、通讯配置
中有
有GSE的通讯配置，例如：

001

4

01-0C-CD-01-00-09

0001

10
2000

2、数据配置

LDDevice 指LD0
有GOOSE的数据集，（这是对于发送方）例如





同层下还有GSEControl，例如

对于输出方，导出的文件中同层下有Inputs，用于提供给接收方做配置，例如：

IED_0007/CTRL/siemenGGIO1/SPCSO1/q|GOOSE application2|Subnetwork|GooseSiemensApplication
IED_0007/CTRL/siemenGGIO1/SPCSO1/stVal|GOOSE application2|Subnetwork|GooseSiemensApplication



接收方根据Inputs到对方的IED section中查找对应的数据，其中PCM600还需要在Communication有对方的通讯配置，GOOSE数据集以及Substation section

Control Block Reference*: L220_2CTRL/LLN0$GO$Control_DataSet1的名称由来
L220_2CTRL为LDName，根据61850－6P29 Header中NameStructure=“IEDName” ，即LDName为IED的name拼接上LDevice的name，这里，IED的name为L220_2，LDevice的name为CTRL，根据标准，整个refrence中的GO为Function constrain