用于传输保护信息和跳闸的GOOSE通信宜采用双星型网。

4.3 网络冗余机制

变电站层与间隔层间的冗余通信机制可采用双网单IP通信或双网双IP通信方式。工程实施时应根据实际需要选择其中一种，具体的说明见附录A。采用双网双IP通信方式时，宜统一采用热备用模式进行MMS通信，即只在主网进行通信，备网仅保持TCP链接，双网切换时应重新使能报告，装置应保证BRCB数据不丢失

GOOSE通信宜采用双发双收方式，具体收发机制见附录B。

5.配置文件、配置工具及声明文件

5.1 配置文件

5.1.1 Schema补充

本规范采用DL/T860.6规定的SCL标准语法，并根据DL/T860.81在SCL_Enums.xsd文件的“tPredefinedAttributeNameEnum”类型中，增加“SBO”、“SBOw”、“Oper”、“Cancel”四种属性名。 5.1.2 配置文件

系统应具备的配置文件包括： ?

ICD文件：IED能力描述文件，由装置厂商提供给系统集成厂商，该文件描述IED提供的基本数据模型及服务，但不包含IED实例名称和通信参数。ICD文件应包含模型自描述信息，如LD和LN实例应包含中文“desc”属性，通用模型GAPC和GGIO实例中的DOI应包含中文“desc”属性，数据类型模板LNType中DO应包含中文“desc”属性。ICD文件应包含版本修改信息，明确描述修改时间、修改版本号等内容。 ?

SSD文件：系统规范文件，应全站唯一，该文件描述变电站一次系统结构以及相关联的逻辑节点，最终包含在SCD文件中； ?

SCD文件：全站系统配置文件，应全站唯一，该文件描述所有IED的实例配置和通信参数、IED之间的通信配置以及变电站一次系统结构，由系统集成厂商完成。SCD文件应包含版本修改信息，明确描述修改时间、修改版本号等内容； ?

CID文件：IED实例配置文件，每个装置有一个，由装置厂商根据SCD文件中本IED相关配置生成；

5.1.3 配置文件一致性要求

6

装置厂家提供的ICD文件应与装置实际能力严格一致。装置最终配置应与SCD文件完全一致。

5.2 配置工具

配置工具分为系统配置工具和装置配置工具，配置工具应能对导入导出的配置文件进行合法性检查，生成的配置文件应能通过SCL的schema验证，并生成和维护配置文件的版本号和修订版本号。

系统配置工具是系统级配置工具，独立于IED。它负责生成和维护SCD文件，支持生成或导入SSD和ICD文件，其中应保留ICD文件的私有项。系统配置人员根据工程实际配置的需要，对一次系统和IED的关联关系、全站的IED实例、以及IED间的交换信息进行配置，完成系统实例化配置，并导出全站SCD配置文件，提供给客户端及装置配置工具使用。

装置配置工具负责生成和维护装置ICD文件，并支持导入SCD文件以提取需要的装置实例配置信息，完成装置配置并下装配置数据到装置。同一厂商应保证其各类型装置ICD文件的数据模板DataTypeTemplates的一致性。

装置配置工具应能导入并识别SCD文件中以下实例配置内容： ? ? ? ? ? ?

通信参数，如通信子网配置、网络IP地址、网关地址等 IED名称

GOOSE配置，如GOOSE控制块、GOOSE数据集、GOOSE通信地址等 DOI实例值配置 数据实例名称

数据集和报告的实例配置

5.3 配置流程

工程实施过程中，系统集成商提供系统配置工具，并根据用户的需求负责整个系统的配置及联调，装置厂商提供装置配置工具，并负责装置的配置及配合系统集成商进行联调，具体流程见图1。

7

图1 工程配置流程

当配置数据修改时，为实现全站配置统一管理，按如下原则处理： ? ?

如果只是装置私有功能数据的修改，则直接由装置配置工具修改后下装；

如果是系统组态实例化数据的修改，则由系统配置工具统一修改，然后生成新的SCD文件，由装置配置工具导入后进行下装； ?

如果是装置ICD模板数据的修改，则由装置配置工具生成新的ICD文件，系统配置工具导入后进行新的实例配置，生成新的SCD文件，再由装置配置工具导入后进行下装。

5.4 声明文件

工程实施时，声明文件应由装置厂商提供给系统集成厂商，除ICD文件外，至少还应包括以下三种：

?

模型一致性说明文档，包括装置数据模型中采用的逻辑节点类型定义、CDC数据类型定义以及数据属性类型定义，文档格式采用DL/T860.73和DL/T860.74中数据类型定义的格式。 ?

协议一致性说明文档，按照DL/T860.72附录A提供协议一致性说明，包括ACSI基本一致性说明、ACSI模型一致性说明和ACSI服务一致性说明三个部分。 ?

协议补充信息说明文档，包含协议一致性说明文档中没有规定的装置通信能力的描述信息，如支持的最大客户连接数，TCP_KEEPLIVE参数，文件名的最大长度以及ACSI实现的相关补充信息等。

8

6 模型、建模及扩展

6.1建模总体原则

DL/T860.7规范了数据模型、服务以及建模方法。应基于面向对象的建模思想和分层次的总体原则对设备进行建模。

一般情况下，同一个功能对象相关的数据以及数据属性，应建模在该功能对象中（包括对该对象的扩展）；同多个功能相关，或同全系统功能相关的数据，应建模在公共的逻辑节点或者逻辑设备中。

6.1.1物理设备建模原则

一个物理设备即一个IED，应建模为一个装置对象。该对象是一个容器，应包含服务器对象，服务器对象中应包含至少一个LD对象，每个LD对象中应至少包含3个LN对象。

6.1.2服务器建模原则

服务器描述一个设备外部可见（可访问）的行为，每个服务器应有一个访问点。支持过程层自动化的间隔层设备，对上与变电站层设备通信，对下与过程层设备通信，可采用不同访问点分别与变电站层和过程层进行通信。

6.1.3逻辑设备建模总体原则

DL/T860标准中未规范具体LD如何划分，本规范规定宜把某些具有公用特性的逻辑节点组合成一个逻辑设备。

6.1.4逻辑节点建模总体原则

需要通信的每个最小功能单元应建模为一个逻辑节点对象，属于同一功能对象的数据和数据属性应放在同一个LN对象中，若标准的LN类不满足功能对象的要求，可进行LN类扩展或者新建LN类，扩展和新建原则见附录C。

9

6.2模型扩展原则 6.2.1扩展总体规则

装置功能分解后得到的需要通信的最小功能单元，根据DL/T860.74中规范的逻辑节点类列表，应选择合适的类对功能进行建模。

1） 判断标准已有的LN类是否满足功能要求，若满足则采用合适的LN类； 2） 若标准已有的LN类不满足功能要求，判断已有的LN类是否满足被建模功能的核心需求，如满足核心需求，则可向该LN类添加新的数据，以满足功能的需求；

3） 如标准已有的LN类不满足被建模功能的核心需求，则可扩展一个新LN类。

6.2.2逻辑节点扩展规则

1） 如有合适的LN类符合被建模功能的需求，则逻辑节点实例应具有该LN类所有必选的属性；

2） 基本数据相同的功能，应采用源于相同LN类的不同实例。； 3） 如有合适的LN类符合被建模功能的核心建模需求，则可通过添加若干数据满足被建模功能的建模需求，LN类的名字不变；

4） 如没有合适的LN类符合被建模功能的核心需求，则可根据以下规则新建LN类

? ? ?

LN类的名称首字母应符合DL/T860所规定的逻辑节点组相关前缀的要求； LN类的名称的其他字母应与功能英文名称有关；

新建LN类的名称不可与DL/T860中已存在的LN类名称冲突，应符合DL/T860

命名空间的要求。

6.2.3数据扩展规则

添加或扩展数据应遵循以下原则： 1） 如LN类中已有的可选数据能满足要求，则应使用可选数据； 2） 标准中定义的LN类中已有的数据，如在一个LN实例中存在该数据类的多个实例，可在数据后扩展数字后缀；

3） 标准中定义的LN类不满足建模需求，需要添加数据时，如DL/T860.74的第6节数据名称语义中规定的数据能满足需要添加的数据的需求，则应选择标准规定的数据添加到该LN类；

4） 标准中定义的LN类不满足建模需求，需要添加数据时，如DL/T860.74的第6节数据名称语义中规定的数据不能满足添加数据的需求，则可按照以下规定新建数据：

?

新建数据的名称，应尽量采用DL/T860.74的第4节规定的缩写，通过组合形成新

的数据名称； ?

新建数据应采用DL/T860.72规定的通用数据类和基本数据类型；

10