GB/T 33602-2017 电力系统通用服务协议

　　ICS 29 . 020 F 2 1

　　中 华 人 民 共 和 国 国 家 标 准

　　GB/T 33602—2017

　　电力系统通用服务协议

　　Generalserviceprotocolforelectricpowersystem

　　2017-05-12 发布 2017-12-01 实施

　　中华人民共和国国家质量监督检验检疫总局中 国 国 家 标 准 化 管 理 委 员 会

　　发

　　布

　　GB/T 33602—20 17

　　GB/T 33602—20 17

　　前 言

　　本标准按照 GB/T 1 . 1—2009 给出的规则起草。

　　本标准由中国电力企业联合会提出。

　　本标准由全国电网运行与控制标准化技术委员会(SAC/TC 446)归口 。

　　本标准起草单位：国家电网公司国家电力调度控制中心、中国南方电网电力调度控制中心、中国电力科学研究院、北京科东电力控制系统有限责任公司、国电南瑞科技股份有限公司、国家电网公司华东分部、国网福建省电力有限公司、国网冀北电力有限公司、国网浙江省电力公司、广东电网有限责任公司电力科学研究院、南京南瑞继保电气有限公司、许继集团有限公司、东方电子股份有限公司、积成电子股份有限公司、北京四方继保自动化股份有限公司、国电南京自动化股份有限公司、武汉中元华电科技股份有限公司、长园深瑞继保自动化有限公司。

　　本标准主要起草人：辛耀中、黄海峰、张鸿、严亚勤、梅峥、邓兆云、陶洪铸、陈宁、梁寿愚、姚志强、李军良、杜鹏、郑锐、万书鹏、方文崇、屈刚、宋磊、张昊、叶海明、顾博川、代小翔、温东旭、慈国兴、许文波、刘俊红、蒋衍君、熊磊、黎强。

　　GB/T 33602—20 17

　　电力系统通用服务协议

　　1 范围

　　本标准规定了电力系统通用服务的体系结构、交互方式、服务原语及通信协议。

　　本标准适用于各级电网调度控制中心，各类发电厂、变电站内部及相互间的预定义和自定义的服务数据交互，适用于各类电力监控系统及设备的设计、开发、建设、运行、维护各个环节。

　　2 规范性引用文件

　　下列文件对于本文件的应用是必不可少的。 凡是注 日期的引用文件，仅注 日期的版本适用于本文件 。凡是不注日期的引用文件，其最新版本(包括所有的修改单)适用于本文件。

　　GB/T 18700. 1 远动设备和系统 第 6 部分：与ISO标准和ITU-T建议兼容的远动协议 第 503 篇： TASE. 2 服务和协议

　　GB/T 33601 电网设备通用模型数据命名规范

　　GB/T 33603—2017 电力系统模型数据动态消息编码规范

　　GB/T 33604 电力系统简单服务接口规范

　　DL/T 476 电力系统实时数据通信应用层协议

　　DL/T 634 . 5104 远动设备及系统 第 5-104 部分：传输规约采用标准传输协议集的 IEC 60870-5 - 101 网络访问

　　DL/T 667 远动设备及系统 第 5 部分 传输规约 第 103 篇 继电保护设备信息接口配套标准

　　DL/T 719 远动设备及系统 第 5 部分 传输规约 第 102 篇 电力系统电能累计量传输配套标准

　　DL/T 860 . 71 电力 自动化通信网络和系统 第 7-1 部分：基本通信结构 — 原理和模型

　　DL/T 860 . 72—2013 电力 自动化通信网络和系统 第 7-2 部分：基本信息和通信结构 — 抽象通信服务接口 (ACSI)

　　DL/T 860 . 73 电力 自动化通信网络和系统 第 7-3 部分：基本通信结构 — 公用数据类

　　DL/T 860 . 74 电力 自动化通信网络和系统 第 7-4 部分：基本通信结构 — 兼容逻辑节点类和数据类

　　3 术语和定义

　　下列术语和定义适用于本文件。

　　3.1

　　通用服务协议 generalserviceprotocol

　　规定了基于面向服务架构(SOA)的、适用于各级电网调度控制中心和各类发电厂及变电站的通用服务，包括二进制的服务描述和服务访问以及相应的二进制通信协议。

　　3.2

　　协议兼容服务模式 protocolcompatibilityservicemode

　　采用兼容原有通信协议(如：DL/T 860、DL/T 634 . 5104、GB/T 18700 . 1、DL/T 476 等)的特定服务

　　GB/T 33602—20 17

　　模式，以便尽可能利用原有通信程序资源。

　　3.3

　　服务原语 serviceprimitive

　　对服务原型名称和调用接口参数进行的标准化准确描述，服务原语的标准名称采用英语动宾短语的形式命名，在软件程序和服务列表中都可直接使用，类似于软件程序中的函数原型。 服务原语的中文(或其他文字)名称，一般只在服务列表中使用。

　　3.4

　　预定义服务 predefinedservice

　　已提供的服务原语和公共数据类定义，服务提供者和服务消费者在遵循本文件规定的前提下，可直接进行服务的实现和调用。

　　3.5

　　自定义服务 custom service

　　在已有定义范围之外的服务，由服务提供者自行定义的服务原语和数据类型，服务消费者按照服务提供者或服务代理提供的服务定义信息，在解析后进行服务的调用。

　　3.6

　　服务代理 serviceproxy

　　代表多个服务提供者或服务消费者实现跨越广域(或局域)边界的服务交互的特殊网络服务，服务代理位于服务提供者和服务消费者之间，允许服务的消费者通过代理与服务的提供者进行非直接的连接。

　　3.7

　　服务域 servicedomain

　　按物理或逻辑关系划分服务所属域，位于服务代理后端，通过服务代理提供或获取相关的服务。

　　3.8

　　域管理 domainmanagement

　　监控和管理区域内所有服务域，并提供域注册管理、域名查询等功能。

　　3.9

　　服务管理 servicemanagement

　　管理服务域内部所有服务，提供服务的注册、定位(发现)及服务信息查询服务。

　　4 缩略语

　　下列缩略语适用于本文件。

　　AC：属性个数(Attribute Counter)

　　APCH：应用协议控制头(Application Protocol Control Header)

　　APDU：应用协议数据单元(Application Protocol Data Unit)

　　ASDB：应用服务数据单元体(Application Service Data-unit Body)

　　ASDH：应用服务数据单元头(Application Service Data-unit Header)

　　ASDU：应用服务数据单元(Application Service Data Unit )

　　CC：控制码(Control Code)

　　CH：频道(Channel)

　　CI：类标识 (Class Identifier)

　　GB/T 33602—20 17

　　CT：编码类型(Coding Type)

　　DS：数据集(Data Set)

　　EF：扩展标志(Extension Flag)

　　FL：帧长度(Frame Length)

　　GSP：通用服务协议(General Service Protocol)

　　IP：互联网协议(Internet Protocol)

　　M0：兼容 ASN.1 编码方式(Compatible with ASN.1 coding mode)

　　M1：带名字的 ASN.1 编码方式(ASN.1 coding mode with name )

　　M2：对象编码方式(Object coding mode)

　　M3：类编码方式(Class coding mode)

　　M编码：电力系统模型数据动态消息编码规范(Coding Specification of Dynamic Message)

　　OC：对象个数(Object Counter)

　　OS：对象尺寸(Object Size)

　　OSI：开放系统互联(Open System Interconnection)

　　PC：参数个数(Parameter Counter)

　　PI：协议标识 (Protocol Identifier )

　　SC：服务码(Service Code)

　　SEQ：序列编号(2 个八位位组)(Sequence)

　　SOA：面向服务架构(Service Oriented Architecture)

　　SQ：短序号(1 个八位位组)(Short Sequence)

　　SS：子服务(Sub-Service)

　　TCP：传输控制协议(Transport Control Protocol)

　　UDP：用户数据报协议(User Datagram Protocol)

　　UI：单元标识(Unit Identifier)

　　UT：单元类型(Unit Type)

　　5 面向服务的体系架构和协议

　　5 . 1 体系结构

　　面向服务的体系架构(SOA),通过一系列的接口服务实现服务消费者和服务提供者间的信息交换 。本文件使用的面向服务架构应由域管理、服务管理、服务代理、服务提供者及服务消费者构成，其构成如图 1 所示。

　　在进行本地通信时，数据交互通过服务消费者和服务提供者之间的通道直接进行。 在进行远程通信时，通过本地服务代理和远方服务代理间的配合，在服务消费者和服务提供者之间建立起逻辑的数据连接，进行服务通信。

　　其中域管理可采用与服务代理结合的分布式部署方式，也可采用集中式的域管理中心方式。 从安全及容错性方面考虑，建议使用分布式部署方式。

　　GB/T 33602—20 17

　　图 1 面向服务的体系架构构成图

　　5 . 2 协议结构

　　为实现面向服务体系架构的服务数据交互，本文件基于 OSI 参考模型，构建了电力系统通用服务协议(GSP),基于连接方式的数据交互采用 TCP/IP,基于无连接方式的数据交互采用 UDP、IP 或以太网 。通用服务协议的层次结构如图 2 所示。

　　图 2 通用服务协议的层次结构

　　本标准采用了 DL/T 860 的通信服务和数据结构，以及其自描述和动态维护等特性，用面向对象的M编码(GB/T 33603—2017)方式取代原面向数据的 ASN. 1 编码方式，吸收 DL/T 476 和 DL/T 634 等高效实时数据通信的技术特点，支持面向对象的高效实时数据通信服务。 通过服务原语和报文数据结构的自描述机制，支持预定义或自定义的创建、维护、扩充服务原语及报文数据结构(类)，将简单高效的实时数据通信服务与灵活方便的离线维护服务分离，功能互补，不相互影响。

　　5 . 3 服务交互流程

　　5 . 3 . 1 交互流程

　　通用服务的数据通信过程如图 3 所示，包含代理注册、服务注册、服务查询、服务定位等过程。

　　GB/T 33602—20 17

　　图 3 通用服务交互流程图

　　交互流程中的关键步骤说明如下：

　　a) 代理注册：远程通信过程，服务代理是服务域对外的唯一出口，新增一个服务域时，应首先向域管理进行服务代理注册，登记代理的服务域名(DomainName)和 IP 地址;

　　b ) 服务注册：本地通信过程，服务域内部的服务提供者应向本地服务管理注册服务，登记服务提供者 IP地址、端口、服务提供者标识(ProviderID)及服务名称(ServiceName)等;

　　c) 服务查询：为服务消费者提供服务域、服务部署以及服务信息等内容，以满足服务访问的需要。服务查询包括远程和本地通信过程;

　　d) 服务定位：服务消费者用于获取服务的通信地址和端口 。在获取本地服务的定位信息时，定位服务由服务管理提供，在获取远方服务的定位信息时，通过本地代理向远方代理进行服务查询获得。

　　5 . 3 . 2 域管理

　　域管理位于指定区域内的服务代理后端，监控并管理所有接入该区域的服务域，其主要功能包括：

　　a) 管理所有服务域中服务代理的注册请求;

　　b ) 维护服务域的 DomainName 和对应服务代理 IP地址的映射关系;

　　c) 监控区域内所有服务代理的运行状态;

　　d) 为服务消费者提供域名查询服务;

　　e) 对区域范围内的数据交互提供安全管控。

　　域管理模块宜分布部署，以对等冗余方式进行工作，可实现负载均衡。

　　5 . 3 . 3 服务管理

　　服务管理负责管理服务域内部所有服务的注册、定位(发现)及服务信息，其主要功能包括：

　　GB/T 33602—20 17

　　a) 服务提供者的服务注册及删除服务;

　　b ) 服务提供者运行状态监视;

　　c) 服务列表管理及服务查询、定位功能;

　　d) 向域管理进行服务域(包括域名和服务代理地址)注册;

　　服务管理模块以对等冗余方式进行部署和工作，可实现负载均衡。

　　5 . 3 . 4 服务代理

　　服务代理是跨服务域(含广域网或局域网)边界进行服务数据交互的唯一出口，其主要功能应包括：

　　a) 通过域管理获取域名和服务代理模块的通信地址;

　　b ) 建立并维护服务消费者和服务提供者之间的链路关系;

　　c) 转发服务消费者的服务请求到远方代理;

　　d) 接收并转发远方服务消费者代理发来的服务请求到本地服务提供者;

　　e) 转发服务提供者的服务应答到远方代理;

　　f) 接收并转发远方服务提供者代理发来的服务应答到本地服务消费者。

　　服务代理宜分布部署，以对等冗余方式进行部署和工作，可实现负载均衡。

　　5 . 4 服务模式

　　本标准基于面向服务的体系架构，支持请求响应式服务和订阅发布式服务两种模式：

　　a) 请求响 应 式 服 务 适 用 于 单 次 服 务 请 求 的 场 景，交 互 流 程 如 图 4 所 示，服 务 交 互 流 程 为

　　“-request”、“-indication”、“-response”、“-confirm”4 个典型阶段。本标准描述的大多数通用服

　　务为请求响应式服务。

　　图 4 请求响应式服务流程

　　b ) 订阅发布式服务适用于一次提交服务注册，多次返回服务结果的场景，交互流程如图 5 所示，服务原语同服务请求响应模式，典型应用如：变电站告警事件的远程订阅。

　　GB/T 33602—20 17

　　图 5 订阅发布式服务流程

　　5 . 5 服务描述和访问方法

　　5 . 5 . 1 服务描述

　　服务的描述应采用 S语言(GB/T 33604) 。

　　在该规范基础上，本标准的广域服务描述采用如下三段式服务名结构：

　　Domain.Provider.Service(参数);

　　Domain：服务所属域名，用于区分服务所属服务域，通常为一个变电站或调控主站;

　　Provider：服务提供者标识，用于区分同一域内不同对象提供的相同服务;

　　Service：服务名。

　　5 . 5 . 2 服务原语使用

　　本机(或本服务域)可直接引用、组合引用、嵌套引用服务原语，也可扩展服务原语：

　　a) 直接引用方式，服务使用者可以直接引用附录 H 中的通用服务原语。

　　b ) 组合引用方式，服务使用者可以将附录 H 中的多个通用服务原语组合使用，形成新的服务原语，需要创建新的服务。

　　c) 嵌套引用方式，服务使用者可以在自己创建的专用服务中，嵌入附录 H 中的通用服务原语，总体形成专用服务原语，需要创建专用服务。

　　5 . 5 . 3 服务访问方式

　　服务访问方式包含二进制和文本访问方式：

　　a) 文本访问方式：按照 GB/T 33604 规定以字符串形式进行服务访问，适应于访问频率不高、对响应时间无特殊要求的场合。

　　b ) 二进制访问方式：按照服务编码 SC 和相应类编码 CI 直接进行二进制访问，适应于访问频率高、响应速度快的场合。

　　通用二进制服务访问调用接口如下：

　　INT32CallService( //通用二进制服务访问调用接 口

　　GSP_ServiceRef: service, //服务描述，包括服务域标识、提供者标识、服务编码等

　　GSP_ProtocolUnit: protocol, //协议单元，包括协议标识、单元标识、类标识等

　　GSP_Mode: mode, //服务模式，包括同步或异步方式、连接方式等

　　GB/T 33602—20 17

　　GSP_Buffers: buffers //服务缓冲区，包括输入、输出缓冲区的大小及指针

　　)

　　调用接口的参数由调用方式决定。 服务消费者通过 CallService将服务请求转换成为通信报文，传输给服务提供者，服务提供者执行所请求的服务，将结果通过通信报文返回，由 CallService将结果传递给服务消费者，若返回值为 0 表示服务执行正确，否则表示出现异常。 在采用兼容模式时，所兼容的标准服务编码内容见附录 A 至附录 D。 附录 E规定了在访问调用接口及服务定义中所使用的基本数据类型。 调用接 口 CallService 的参数定义见 F. 4,服务响应错误原因见 F. 4 . 6 。

　　6 应用协议数据单元 APDU

　　6 . 1 应用协议数据单元结构

　　应用协议数据单元(APDU)是通用服务协议的基本报文数据单元，由应用协议控制头(APCH) 和应用服务数据单元(ASDU)组成，其中 APCH 由 4 个八位位组组成，包含控制码(CC)、服务码(SC)、帧长度(FL) 。APDU 的结构如图 6 所示。

　　图 6 应用协议数据单元结构

　　6 . 2 应用协议控制头 APCH

　　6 . 2 . 1 控制码 CC

　　控制码是 1 个八位位组，位于 APDU 的首部，控制码的结构如图 7 所示，含义见表 1 。

　　图 7 控制码 CC结构

　　GB/T 33602—20 17

　　表 1 控制码 CC含义说明

　　“适用协议 PI”定义了 ASDU使用的协议类型，其中 PI=0 表示通用服务协议，PI为其他值时，表示兼容模式协议。 此处“兼容”是指与原通信协议功能的兼容，兼容模式如 PI=2 时，可采用 DL/T 634. 5104 协议服务编号(附录 B)解析 APCH 的服务码 SC,其后的帧长度 FL 为对应 DL/T 634 . 5104 协议 APDU的长度。

　　6 . 2 . 2 服务码 sC

　　服务码占 1 个八位位组，用于标识预定义服务，表 2 列出了本标准定义的服务，清单中包括了服务的功能组、名称、服务码、单元类型、编码类型、类标识、连接方式等。 其中：

　　—“功能组”和“序号”是为描述方便清晰而设置;

　　—“服务原语标准名称”采用英语动宾短语的形式命名，在软件程序中和服务列表中都可直接使用;

　　—“服务原语中文名称”是描述性的，可在文本型服务列表中使用;

　　—“服务码 SC”为该服务原语的二进制代码，当 APCH 的控制字 CC 的“适用协议”字段置为“0000”(通用服务协议)时，其后的服务编码 SC字段为该服务的“服务码”;服务码采用分段连续编码方式，在编码 26~47 区间、110~127 区间和 169 之后留有备用，以方便扩充，服务码为0 表示不采用 SC识别的服务;

　　—“单元类型 UT”为该服务所对应的数据单元类型，UT取值从 0~5,分别对应：对象单元、参数单元、数据流单元、类描述单元、数据集扩展单元、通用宽扩展单元。 详见第 8 章;

　　—“编码类型 M”指适用于该服务的报文数据结构的 M 编码方式，选择编码方式的基本原则为：对于一次性的或临时性的服务，可采用自描述的数据编码 M1(或 M0),灵活方便;对于实时持续性的服务，可采用面向对象的数据块编码 M2,简洁高效;对于其参数为复杂数据结构的服务，可采用能够描述对象结构的类描述编码 M3,支持动态维护;

　　—“类标识 CI”为该服务所对应预定义数据类标识，类标识的具体描述见第 8 章，CI 取值见附录

　　GB/T 33602—20 17

　　F,类结构定义见附录 G ;

　　—“连接方式”指该服务对低层通信连接的要求，选择连接方式的基本原则为：对于一次性的或临时性的服务，可采用短连接，即先建立临时连接(用 Associate),待该服务完成之后，再释放临时连接(用 Release);对于长期持续性的服务，可采用长连接(用 Associate), 即建立连接后，长期保持，以便随时支持后续的服务;对于广播或组播型以及测试类的服务，可采用无连接方式，该方式的服务无需用关联(Associate)原语建立连接，但每帧报文都需携带通信地址。

　　其中标注“* ”号的服务原语，应使用带身份标签和授权信息的调度数字证书。

　　表 2 电力系统通用服务协议服务码

　　GB/T 33602—20 17

　　表 2(续)

　　GB/T 33602—20 17

　　表 2(续)

　　GB/T 33602—20 17

　　表 2(续)

　　GB/T 33602—20 17

　　表 2(续)

　　当采用其他通信协议兼容模式时，其服务编码分别见：附录 A“兼容 DL/T 860 . 72 协议服务编号”、附录 B“兼容 DL/T 634 . 5104 协议的服务编号”、附录 C“兼容 GB/T 18700 . 1 (TASE. 2) 协议的服务编号”、附录 D“兼容 DL/T 476 协议的服务编号”。

　　6 . 2 . 3 帧长度 FL

　　帧长度 FL( Frame Length) 占 2 个八位位组，最大取值为 65535,默认位序为低位在前，高位在后。通用服务协议规定帧长度 FL等于应用服务数据单元 ASDU 长度。

　　7 应用服务数据单元 ASDU

　　7 . 1 应用服务数据单元结构

　　应用服务数据单元(ASDU)紧跟在应用协议控制头部(APCH, 4 个八位位组)之后，由服务数据单元头(ASDH)和数据单元体(ASDB)构成，如图 8 所示。 应用服务数据单元 ASDU 的编码规则取决于APCH 中 CC 的适用协议 PI字段：当 PI=0 时，采用电力系统动态消息编码规范;当 PI 为其他值时，为通信协议兼容模式，其 ASDU可直接采用原有通信规约的应用协议数据单元(APDU)内容。

　　各服务根据需要采用不同的编码类型，具体参照表 2 中的“编码类型”。通用服务模式的 ASDB 数

　　GB/T 33602—20 17

　　据帧结构采用 GB/T 33603—2017 中 5 . 2 . 1 的内容。

　　图 8 应用服务数据单元(ASDU)结构

　　数据单元头部的单元标识 UI(UnitID)字段是相对固定的，其他字段在 6 种数据单元中的含义各不相同。

　　单元标识 UI位于数据单元头的第 1 个八位位组，与 GB/T 33603—2017 中 M 编码头部兼容，此处

　　采用原 3 个预留比特作为服务数据单元类型 UT ( Unit Type), 结构如图 9 所示，其中编码类型 CT (Coding Type)、单元类型 UT、高位标志 H(High)是必选的。

　　图 9 应用服务数据单元的单元标识定义

　　高低字节序标志 H 表示发送方计算机的字节序，大端点的计算机设置为“1”,小端点的计算机设置为“0”,接收侧据此进行字节序转换。

　　EF 为扩展标志(Extention Flag),扩展标志 EF 用于对类描述和头部扩展进行分类，在 M2 和 M3时有效。 M0 和 M1 不进行头部扩展，类描述采用短描述。 当 EF. 7 =0 时，ASDH 为 4 个八位位组的标准数据单元头部，此时 ASDH 头部 4 个成员各占 1 个八位位组，其最大取值为 256 ;当 EF. 7 = 1 时 ， ASDH为 8 个八位位组的扩展数据单元头部，此时单元标识 UI 占 1 个八位位组，后续 2 个成员各占 2 个八位位组，最后一个成员占 3 个八位位组;EF. 6 =0 时表示类描述为短描述，EF. 6 = 1 时表示类描述为长描述。

　　UT用于表示不同的数据单元，各位取值说明见表 3 。

　　GB/T 33602—20 17

　　表 3 数据单元头类型

　　应用服务数据单元有 6 种类型，为叙述方便，以下主要描述 EF. 7 = 0 时的标准单元头部 ASDH(4、 8、12 个八位位组)情况。 对于 EF. 7 = 1 时的扩展单元头部 ASDH 的情况，需要将 6 种单元头部 ASDH中的前 4 个八位位组扩充为 8 个八位位组，即：类标识 CI、对象尺寸 OS、对象个数 OC、参数个数 PC、属性个数 AC、子服务 SS、短序号 SQ等，由各占 1 个八位位组扩展为各占 2 个八位位组，序列编号 SEQ从 2 个八位位组扩展为 4 个八位位组，但是，数据集扩展单元(UT=4)头部的后 4 个八位位组和通用宽扩展单元(UT=5)头部的后 8 个八位位组保持不变，则其数据单元头部长度分别为 8+4 和 8+ 8 个八位位组。

　　7 . 2 对象单元

　　对象单元(UT=0),用于传输结构化的对象数据，适用于通信双方已知服务报文数据结构的情况，应优先使用对象单元或数据集扩展单元。 在 ASDU标准头部，单元标识 UI 占 1 个八位位组，其中单元类型 UT=0,编码类型 CT=2;类标识 CI 占 1 个八位位组;对象尺寸 OS 占 1 个八位位组，表示单个对象数据块的大小，以八位位组为单位;对象个数 OC 占 1 个八位位组，表示后面对象数据中包含的对象个数。 对象单元编码结构如图 10 所示。

　　4 个八位位组 1 个八位位组 1 个八位位组 1 个八位位组 1 个八位位组 N个八位位组

　　图 10 标准单元的对象单元编码结构

　　类标识(ClassID)位于 ASDU 标准头部的第 2 个八位位组，表示该服务直接对应的报文数据类的编号，取值从 0 到 255 。类标识定义范围见表 4,其中：

　　CI=0 表示本侧尚没有与该服务对应的报文数据类的定义，需要先传送报文数据类描述;仅用于服

　　务响应报文(CC 中的 Resp=1) 。

　　CI= 1 表示本侧支持与该服务对应的报文数据类的所有属性，用于服务响应报文(CC 中 Resp=1)。

　　CI= 2 ~ 191 表示公共预定义数据类型，可离线定义，也可从在线临时定义的数据类型转存为公共预定义数据类型，由服务管理统一维护。

　　CI= 192~244 表示用户预定义的数据类型，可离线定义，也可从在线临时定义的数据类型转存为用户预定义数据类型，由服务提供者自行维护。

　　CI= 245~255 表示用户临时定义的数据类型，其生命周期为一次完整的服务请求响应过程，应先

　　GB/T 33602—20 17

　　使用类描述单元(UT=3, CT=3)传输类描述，再用对象单元(UT=0, CT=2)等传输对象数据。

　　表 4 类标识定义

　　对象数据结构如图 11 所示，其中的对象尺寸 OS通过类定义获得。

　　OS个八

　　位位组

　　OS个八

　　位位组

　　OS个八

　　位位组

　　图 1 1 对象数据结构

　　对象单元 ASDH 中的对象尺寸 OS、对象个数 OC、帧长度 FL,有 3 种组合模式：

　　一是正常多对象模式。 帧长度 FL=对象尺寸 OS *对象个数 OC+ASDU 头长。

　　注：其中 ASDH 长又有多种取值，对于标准 ASDH,其长可能为 4、8、12 个八位位组，对于扩展 ASDH,其长可能为

　　8、12、16 个八位位组;以下与此相同。

　　二是单个超大对象模式。 当对象尺寸超过 255 个八位位组或对象长度无法预先确定时，可将 OS置为 0, OC置为 1,则：超大对象长度=帧长度 FL-ASDU 头长。

　　三是用户 自定义头部模式。 用户应优先选用本标准规定的 6 种服务数据单元，其中留有相当大的扩展余地，当仍不满足需求时，用户可自定义头部数据结构，插在标准的对象单元头部 ASDH 和对象数据之间，如图 12 所示。 此时，用户自定义头部的长度只能隐式表达，可由下式计算导出：

　　用户 自定义头部长度=帧长度 FL-对象尺寸 OS *对象个数 OC+ASDH 长 。

　　图 12 标准单元的自定义用户头部的对象单元结构

　　7 . 3 参数单元

　　参数单元(UT=1),用于传输各类服务的参数数据。 在标准 ASDH 中，单元标识 UI 占 1 个八位位组，其中单元类型 UT=1,编码类型 CT=0 或 1,分别表示采用兼容 ASN. 1(M0) 或带名字 ASN. 1 编码方式(M1);子服务 SS( Sub-Service) ,为服务码 SC 的扩展，其编码和含义由服务提供者定义;短序号 SQ占 1 个八位位组，取值范围从 0 到 255,达到最大值 255 后自动归 0;在发送报文中表示本数据包在缓冲区中的相对报文序号，在接收确认报文中表示正确接收到的相对报文序号。 参数个数 PC 占 1 个八位位组，表示该报文中包含的参数个数。 参数单元编码结构如图 13 所示。

　　GB/T 33602—20 17

　　4 个八位位组 1 个八位位组 1 个八位位组 1 个八位位组 1 个八位位组 N个八位位组

　　图 13 参数单元头编码结构

　　参数数据采用 TLV 编码方式，或 N-TLV 编码方式。 N-TLV 编码方式即在 TLV 编码方式的基础上加入名字一项，名字以 ASCII 值为 0 的字符结束，采用 N-TLV 编码方式的参数数据结构如图 14所示。

　　多个八

　　位位组

　　…

　　多个八

　　位位组

　　图 14 采用 N-TLV编码方式的参数数据结构

　　7 . 4 流数据单元

　　流数据单元(UT=2),用于传输多帧流式数据，如大文件或图像等。 标准单元的流数据编码结构见图 15 所示。 在 ASDU标准头部，单元标识 UI 占 1 个八位位组，其中单元类型 UT=2,可不使用编码类型;子服务 SS( Sub-Service) ,为服务码 SC 的扩展，其编码和含义由服务提供者定义。 相对序号 SEQ占 2 个八位位组，取值范围从 0~65 535,达到最大值 65 535 后自动归 0;在发送报文中表示本数据包在缓冲区中的相对报文序号，在接收确认报文中表示正确接收到的相对报文序号。

　　4 个八位位组 1 个八位位组 1 个八位位组 2 个八位位组 N个八位位组

　　图 15 标准单元的流数据单元结构

　　数据流的传输方法如下;

　　a) 数据发送方根据关联时协商的流数据切片长度及确认窗口大小，进行数据包的组织和发送，对每帧数据赋予一个发送序号(SEQ或 SQ),发送序号连续递增，达到最大值后，自动归 0 ;

　　b ) 数据发送方每发送等于确认窗口的数帧数据包后，等待数据接收方应返回确认信息;

　　c) 数据接收方每接收等于确认窗口的数帧数据包后，应发送接收确认报文，其序号 SEQ(或 SQ)表示已正确收到第 SEQ(或 SQ)号报文;

　　d) 数据发送方从接收方收到确认报文后，释放发送缓冲区，继续发送，直到送满确认窗口，或完成全部数据发送。

　　在使用流数据方式传输时，可按照实际传输需求，合理设置需要传送的信息切片长度及确认窗口大小，具体可在关联服务中进行协商。 若未进行协商设置，则默认切片长度为 1024 个八位位组，确认窗口大小为 8 。

　　为了提高数据传输效率，减少网络数据分包，建议包含流数据包的 APDU加上代理头部 12 个字节后的大小不超过当前网络传输最大传输单元(MTU)值。

　　7 . 5 类描述单元

　　类描述单元(UT=3),用于描述报文数据结构或数据类。 在 ASDU标准头部，单元标识 UI 占 1 个八位位组，其中单元类型 UT=3,编码类型 CT=3;类标识 CI 为所描述的数据类分配标识，详见参数单元中的 CI描述;类尺寸 CS为所描述的数据类编译后的二进制尺寸，推荐使用长字(4 个八位位组)对齐

　　GB/T 33602—20 17

　　和紧凑编译;属性个数 AC表示所描述类包含的原子属性个数，推荐采用扁平化无嵌套的报文数据结构 。类描述单元应与 6 . 2 . 2 中创建类服务(CreateClass)、获取类服务(GetClass) 配合使用，可以预先定义类，也可以由通信双方动态定义数据类。 标准单元的类描述单元编码结构见图 16 所示。

　　4 个八位位组 1 个八位位组 1 个八位位组 1 个八位位组 1 个八位位组 N个八位位组

　　图 16 标准单元的类描述单元结构

　　类描述数据详细结构如图 17 所示。

　　多个八

　　位位组

　　多个八

　　位位组

　　1 个八

　　位位组

　　1 个八

　　位位组

　　多个八

　　位位组

　　1 个八

　　位位组

　　1 个八

　　位位组

　　图 17 标准单元的类描述数据结构

　　7 . 6 数据集扩展单元

　　数据集扩展单元(UT=4),主要用于传输成组的结构化对象数据，适应于通信双方已知服务报文数据结构和数据集(通信索引表)的情况，但作为 ASDU 头部扩展 4 个八位位组的通用模式，也可支持非数据集类的其他服务，应优先使用对象单元或数据集扩展单元。 在 ASDU标准头部，单元标识 UI 占1 个八位位组，其中单元类型 UT=4, 编码类型 CT=2;类标识 CI、类尺寸 OS 和对象个数 OC 的含义与在对象单元中相同;ASDU 头部共增加了 4 个八位位组：数据集标识 DS(或频道 CH) 占 1 个八位位组，子服务标识 SS 占 1 个八位位组，相对序列号 SEQ 占 2 个八位位组，数据集扩展单元结构如图 18 。

　　图 18 标准单元的数据集扩展单元结构

　　数据集(索引表)标识 DS用以区分不同的数据集合，DS= 1 表示接收遥测索引表，DS= 2 表示接收遥信索引表，DS= 3 表示接收遥控索引表，DS= 4 表示接收遥调索引表，DS= 5 表示发送遥测索引表， DS= 6 表示发送遥信索引表，DS= 7 表示发送遥控索引表，DS= 8 表示发送遥调索引表;其他编码留作扩充。 在非数据集类的其他服务中，该字段为频道 CH , 占 1 个八位位组，表示逻辑的通信渠道，可用于服务代理之间长连接的分享管理，或无连接情况下分频道组播，其值由服务提供者定义。

　　数据索引表的内容至少包括：顺序号、数据点标准名称、数据点本地标识等，其中的顺序号和数据点标准名称必须在通信双方之间保持一致;数据点本地标识(一般为数据库地址)仅由本侧使用，不需传给对侧。

　　子服务 SS 为服务码 SC 的扩展，当与数据集单元配合使用时，SS= 0 表示变化数据传送，SS= 1 表示全数据传送，其他编码和含义由服务提供者定义。 在非数据集的其他服务中，该字段可由服务提供者定义。

　　相对序列号 SEQ在数据集全数据传送子服务(SS=1)时，表示本帧数据在数据集(索引表)中的起始位置序号;其他情况下与流数据单元中的 SEQ相同，在发送报文中表示本数据包在缓冲区中的相对报文序号，在接收确认报文中表示正确接收到的相对报文序号，当 SEQ达到最大值 65 535 后自动归 0 。

　　GB/T 33602—20 17

　　7 . 7 通用宽扩展单元

　　通用宽扩展单元(UT=5),作为 ASDU 头部扩展 8 个八位位组的通用模式可支持多种服务，在通用宽扩展单元标准头部与对象数据之间，预留 8 个八位位组作为对象数据信息扩展使用。 其中：通用宽扩展单元标准头部定义同对象单元的 ASDU 标准头部定义;频道 CH 占 1 个八位位组，表示逻辑的通信渠道，可用于服务代理之间长连接的分享管理，或无连接情况下分频道组播，其取值可由服务提供者定义;子服务 SS(占 1 个八位位组)和序号 SEQ( 占 2 个八位位组)的定义与对象数据集单元中相同;预留扩展 EX 占 4 个八位位组，为服务提供者预留，其具体结构和含义由服务提供者定义。 通用宽扩展单元结构如图 19 所示。

　　4 个

　　八位位组

　　4 个

　　八位位组

　　1 个

　　八位位组

　　1 个

　　八位位组

　　2 个

　　八位位组

　　4 个

　　八位位组

　　N个八位位组

　　图 19 标准单元的通用宽扩展单元结构

　　8 服务数据传输

　　8 . 1 简单类型数据交换法

　　通信双方所交换的数据类型为基本数据类型，且数据个数较少的情况下可采用参数数据单元进行数据交换。 在应用服务数据单元中将每个交换的数据描述信息与数据值都包含在内。 以关联服务请求为例，其具体参考格式如图 20 所示：

　　图 20 简单类型数据交换的 APDU(标准单元)

　　8 . 2 公共预定义数据类型交换法

　　通信双方所交换的数据为单一数据类型或结构性数据，且其类型包含在公共类里面时可采用对象单元进行数据的交换和解析。

　　由于公共数据类型是双方都已知的，交换时可以直接使用类型标识 CI作为双方的编解码依据。 以注册事件(RegisterEvent)请求为例，具体参考格式如图 21 所示，其中 CI= 13 为公共数据类型：

　　图 2 1 公共数据类型交换的 APDU(标准单元)

　　GB/T 33602—20 17

　　8 . 3 用户自定义数据类型交换法

　　通信双方所交换的数据为单一数据类型或结构性数据，但不包含在公共类里面时，通信双方可通过类管理服务定义或交换类定义，然后使用相应的类标识 CI进行服务数据的的交换和解析。

　　自定义的数据类由服务端使用 CreateClass 创建新的数据类定义，在创建后客户端可通过 List- Classes 服务获取到当前服务所有相关类的列表，使用 GetClass 服务可获取指定数据类的描述信息。

　　常见的自定义数据交换分为以下两种应用情况：

　　a) 用户预定义的数据类：服务端先使用 CreateClass 为服务创建新的数据类定义，类标识范围为该服务下的 192~244(依据表 4 定义内容)，在创建后客户端可通过 ListClasses 服务获取到当前服务所有相关类的列表，使用 GetClass 服务可获取指定数据类的描述信息，并可在后续的服务请求、响应中使用该数据类实例化的对象单元直接进行数据交换;

　　b ) 用户临时定义的数据类：服务端在响应客户端请求时临时创建符合客户端要求的数据类定义并在本次会话中使用，类标识范围为该服务下的 245~255(依据表 4 定义内容)，服务端先使用类描述单元告知数据接收方后续数据类的定义信息，再使用对象数据单元直接进行数据交换。

　　8 . 4 流数据交换法

　　通信双方在进行比较复杂的数据交换时，如文件传输等，难以使用一个类表达的服务时，可使用流数据单元进行数据交换。

　　在使用数据流传输服务时，数据流的编码方法通过数据流单元的子服务(SS) 参数进行约定。 流数据的编解码应依据服务参数的 S描述实现。

　　流数据交换服务的过程如下：

　　a) 在服务的 Request过程，逐个对 IN参数，按照参数的编码方法把数据编码后，通过简单的按顺序合并形成请求服务的数据流;

　　b ) 在服务的 Indication过程则按照 Request 的逆向进行解码;

　　c) 在服务的 Response过程，逐个对 OUT参数，按照参数的编码方法把数据编码后，通过简单的按顺序合并形成服务响应数据流;

　　d) 在服务的 Confirm 过程则按照 Response 的逆向进行解码。

　　9 服务交互和服务代理

　　9 . 1 概述

　　服务消费者、服务代理和服务提供者间的交互过程包括关联(Associate)、服务传输、主动释放(Re- lease)或中止关联(Abort)、通信异常处理。

　　9 . 2 关联的建立

　　关联 Associate是指服务消费者到服务提供者之间的端到端的连接，包括本地服务关联、通过代理的远方服务关联。 关联过程包含底层的套接字(Socket)层面的连接，包含安全认证过程。 关联的建立是在每个服务交互过程隐含的，即在每次服务会话时建立关联，会话结束时根据情况应释放关联，由客户端通知服务端，服务端释放与关联有关的资源。 服务端应为每个已建立的关联创建一个定时器，如果长时间未收到客户端的服务请求，视为会话已结束，并释放有关的资源。 如果客户端需要长时间保持关联，应定时发送 Test请求。 如果检测到通信异常或服务端拒绝释放关联，应使用 Abort服务中止关联。关联建立过程中的关键技术点说明如下：

　　GB/T 33602—20 17

　　a) 服务关联 Associate 的建立服务关联的建立原则如下：

　　1) 在一对客户、服务端之间，当使用 SC 的服务时，可共享一个 AssociateID,系统设立特定 As- sociateID供使用 SC的服务共享，若不使用 SC的服务，每个服务对应一个 AssociateID;

　　2) 通信关联关系谁建谁拆，连接发起者负责链路的保持和销毁，服务端只在链路长期未收到数据时通过 Abort终止关联。

　　b ) 长连接和短连接服务交互过程

　　服务的长连接通过 Associate 和 Release显式建立，短连接的 Associate 和 Release采用隐式建

　　立 。具体方法是：

　　1) 在需要长连接时需在服务传输过程前通过 Associate 建立链接，在过程中通过 test 维持链接，在结束时用 Release拆除链接;

　　2) 只需短连接时，在服务调用前不做任何关联操作;

　　3) 在服 务 调 用 时(包 括 长、短 连 接)，首 先 判 断 是 否 已 有 链 接(关 联)，如 果 没 有 则 使 用Associate建立链接，并在收到返回后用 Release 拆除链接。 如果在服务调用时发现已经有链接则直接使用已有链接，不做任何关联操作。

　　c) 无连接服务交互过程

　　无连接服务适用于广播或组播型的服务，以及测试维护型的服务。 该类服务低层协议采用无连接的通信协议(如：以太网、IP、UDP等)，不需建立连接，但每帧报文都需带收发地址，可采用频道(CH) 机制优化支持分组广播型服务。 典型应用如：变电站的采样值服务用以太网协议广播发送。

　　9 . 3 服务代理交互过程

　　服务代理交互用于支持跨服务域的关联的建立，实现链路的管理、服务请求和服务应答的转发。 服务代理可通过在 APDU 之前增加包含关联 ID(AssociateID) 的代理帧头的方式来实现。 代理帧头结构见附录 F 的 F. 3 。关联 ID 包括全局和局部两种，全局 AssociateID 在端到端的范围内保持唯一，局部AssociateID在分段连接中保持唯一 。 图 22 为服务通过代理实现交互的过程。

　　图 22 服务代理交互过程图

　　GB/T 33602—20 17

　　图中客户端 A 与客户端 B共同使用服务代理 X 与远方服务通信，客户端 C单独使用服务代理 Y与远方服务通信，服务代理 Z 为服务端的服务代理。 * As * 表示各个客户端与服务代理之间，服务代理与服务代理之间，服务代理与服务端之间建立的 Associate 关联;实粗线表示为实际 socket 连接，虚细线表示为关联关系。 服务代理之间的实际 socket 连接中可能会存在多个 Associate 关联(即共享TCP 连接)，服务代理与客户端或服务代理与服务端之间的实际 socket连接中只存在一个 Associate关联(即独享 TCP 连接);关联对应表为服务代理中存在的映射表，用来锁定连接关系。 其交互过程如下：

　　a) 建立 Associate关联

　　服务关联过程的详细流程见图 23 所示，以客户端 A连接服务端 B作为例子来说明其过程：

　　1) 客户端 A 向客户端以 目的服务的三段式服务名为参数，向代理 X 发关联请求，客户端代理 X产生值为 CA-As1 的 AssociateID,并记录此 ID到关联对应表当中，并用来标记客户端 A ;

　　2) 客户端服务代理 X解析目的服务的 DomainName,并通过域管理获取对应域代理服务 Z的 IP地址;判断与其是否存在物理连接，如果不存在，则建立物理连接;

　　3) 代理 X将为收到的关联数据帧加代理帧头，并将代理帧头的 AssociateID 设为 CA-As1后发送给代理 Z ;

　　4) 代理 Z产解析代理帧头 CA-As1,生成值 CA-As2(在使用全局 AssociateID 时 CA-As2 值直接使用 CA-As1 的值)的 AssociateID,记录 CA-As1 与 CA-As2 的关联关系;

　　5) 代理 Z去代理帧头，解析服务参数并以本地客户端的形式，通过 Associate 的 ProviderID和 ServerID参数建立与服务 B 的关联关系，服务 B 产生值为 CA-As3 并通过 Associate的 AssociateID参数返回 CA-As3 给代理 Z;

　　6) 代理 Z接收到服务 B返回的建立链路成功帧，将 CA-As3 和当前与服务 Bsocket 连接参数一并记录到关联对应表中，与 CA-As2 构成 CA-As2、CA-As3 以及 socket关联关系;

　　7) 代理 Z将建立链路成功帧中返回的 Associate 的 AssociateID参数由 CA-As3 替换为 CA- As2,然后添加 CA-As1 到代理帧头上，发送给代理 X ;

　　8) 代理 X 接收到代理 Z 返回的建立链路成功帧，解析出 CA-As1 和 CA-As2,然后将 CA- As1 和 CA-As2 记录到本代理中的关联对应表中;

　　9) 代理 X将收到返回数据包去掉添加的代理帧头，并将 Associate 的 AssociateID 参数值由CA-As2 替换为 CA-As1 后发送给客户端 A;

　　10) 客户端 A接收到代理 X返回的建立链路成功帧，记录当前的 CA-As1,通知上层应用链路以建立成功。

　　GB/T 33602—20 17

　　图 23 跨域服务关联过程流程图

　　b ) 服务传输

　　在建立好关联关系后，客户端和服务端服务之间才能进行服务数据传输，以客户端 B访问服务端 B的服务为例，其通信过程如下：

　　1) 客户端 B 向代理 X发送数据服务访问帧，代理 X接收到客户端 B 的访问请求，根据客户端 B 的标记 CB-As1 通过关联对应表来寻找代理 Z 的 CB-As2,然后将以 AssociateID 为CB-As2 的代理帧头添加到数据服务访问帧头部，发送给代理 Z ;

　　2) 代理 Z接收到代理 X 的数据服务访问帧，解析代理帧头，获得 CB-As2,通过关联对应表来寻找与其对应服务 B 的连接;代理 Z将帧头去掉，然后通过关联 CB-As3 的 socket转发数据服务访问帧给服务 B ;

　　3) 服务 B接收到数据服务访问帧后，返回数据服务访问结果帧给代理 Z ;

　　4) 代理 Z根据端口 Port2 和关联 CB-As3 通过关联对应表，寻找关联 CB-As2,然后将以 As- sociateID 为 CB-As2 的代理帧头添加到数据访问结果帧头部，发送给代理 X ;

　　5) 代理 X 接收到数据访问结果帧，解析代理帧头，获取 CB-As2, 根据关联对应表，寻找到CB-As1;代理 X去掉帧头，将数据访问结果帧通过关联 CB-As1 发送给客户端 B,同时复位此对关联的生命值。

　　c) 主动释放和终止关联

　　客户端与服务端通信结束或者需要中止，则发送 release 和 abort 帧，以客户端 C 和服务端 B 通信为例，并以发送 release 帧为例 ：

　　1) 客户端 C 向代理 Y发送 release 帧，代理 Y接收到客户端 C 的访问请求，根据客户端 C 的标记 CC-As1 通过关联对应表来寻找代理 Z 的 CC-As2, 然后将 AssociateID 为 CC-As2的代理帧头添加到 release 帧头部，发送给代理 Z ;

　　2) 代理 Z接收到代理 Y 的 release 帧，解析帧头，获得 CC-As2,通过关联对应表来寻找与其对应服务 B 的连接;代理 Z 将帧头去掉，然后通过关联 CC-As3、端 口 Port3 转发 release帧给服务 B ;

　　3) 服务 B接收到 release 帧后，返回关联释放确认帧给代理 Z ;

　　GB/T 33602—20 17

　　4) 代理 Z根据端口 Port3 和关联 CC-As3 通过关联对应表，寻找关联 CC-As2,然后将 CC- As2 添加到关联释放确认帧头部，发送给代理 Y;代理 Z 删除 CC-As3 的关联，删除端 口Port3 上的物理连接，同时删除关联对应表上的记录;

　　5) 代理 Y接收到关联释放确认帧，解析帧头，获取 CC-As2, 根据关联对应表，寻找到 CC- As1;代理 Y去掉帧头，将数据访问结果帧通过关联 CC-As1 发送给客户端 C;代理 Y 删除关联对应表中的数据，然后检测代理 Y 与代理 Z之间是否还存在 Associate关联，如果不再存在，则删除代理 Y 和代理 Z之间的物理连接;

　　6) 客户端 C接收到关联释放确认帧，释放客户端 C 和代理 Y之间的物理连接;

　　7) 通信流程中，省略了超时计时，超时计时与 a)建立关联时的超时计时相同，不再重复;对于 abort命令，直接结束当前的操作，不等待当前操作完成，其通信流程与 release 相同，不再重复。

　　d) 通信异常处理

　　通信通道异常等都会造成交互的中断导致关联失效，在通信过程中应采取相应措施，应包含的处理要求如下：

　　1) 在各环节采用生命计数器进行对通信过程进行监视，在超出预期时间后应采取相应措施，恢复通信并告警;

　　2) 通信空闲时发送测试帧监视通道和服务是否正常;

　　3) 在异常发生时，应尽可能发出 abort命令，通知相关服务释放资源;

　　4) 应设置关键资源使用情况监视，以发行异常资源消耗。

　　GB/T 33602—20 17

　　附 录 A

　　(规范性附录)

　　兼容 DL/T860 . 72 协议服务编号

　　根据电力系统通用服务协议编码规则对 DL/T 860 . 72 中的抽象通信服务接口进行服务编号，详见表 A. 1 。

　　表 A.1 DL/T860 . 72 服务编号

　　GB/T 33602—20 17

　　表 A.1(续)

　　GB/T 33602—20 17

　　附 录 B

　　(规范性附录)

　　兼容 DL/T634 . 5104 协议服务编号

　　根据电力系统通用服务协议编码规则对 DL/T 634. 5104 中常用的类型标识进行服务编号，详见表 B. 1 。

　　表 B.1 DL/T634 . 5104 服务编号

　　GB/T 33602—20 17

　　表 B.1(续)

　　GB/T 33602—20 17

　　附 录 C

　　(规范性附录)

　　兼容 GB/T 18700 . 1 协议服务编号

　　根据电力系统通用服务协议编码规则对 GB/T 18700 . 1 中的服务接口进行服务编号，详见表 C. 1 。

　　表 C.1 GB/T 18700 . 1 服务编号

　　GB/T 33602—20 17

　　表 C.1(续)

　　GB/T 33602—20 17

　　附 录 D

　　(规范性附录)

　　兼容 DL/T476 协议服务编号

　　根据电力系统通用服务协议编码规则对 DL/T 476 中的数据块进行服务编号，详见表 D. 1 。

　　表 D.1 DL/T476 服务编号

　　GB/T 33602—20 17

　　表 D.1(续)

　　GB/T 33602—20 17

　　表 D.1(续)

　　GB/T 33602—20 17

　　附 录 E

　　(规范性附录)

　　基本数据类型定义

　　电力系统通用服务协议中所使用到的基本数据类型的定义见表 E. 1 。

　　表 E.1 基本数据类型定义

　　GB/T 33602—20 17

　　附 录 F

　　(规范性附录)

　　基本数据结构定义

　　F.1 概述

　　电力系统通用服务协议中单元头部结构的定义如下，采用 C语言格式进行描述，应使用长字(4 个八位位组)对齐和紧凑编译。

　　F.2 单元头部结构定义

　　F.2 . 1 GSP_controlcode(协议控制码)

　　// 协议控制码定义

　　typedef struct GSP_control_code {

　　INT8U protocol: 4 ; //协议标识 PI, 4 位，为 0 表示通用服务协议 GSP;

　　INT8U spare: 1 ; //备用， 1 位;

　　INT8U error: 1 ; //错误标志，1 位，0 表示无错，1 表示有错 ;

　　INT8U response: 1 ; //响应标志，1 位，0 表示请求，1 表示响应;

　　INT8U next: 1 ; //后续标志，1 位，0 表示无后续帧，1 表示有后续帧;

　　} GSP__ControlCode ;

　　F.2 . 2 GSP_APcH(应用协议控制帧头)

　　// 应用协议控制帧头结构

　　typedef struct GSP_application_protocol_control_header {

　　GSP_ControlCode CC; //协议控制，CC; 1 个八位位组;

　　INT8U service; //服务码，SC; 1 个八位位组;

　　INT16U lenth; //帧长度，FL=等于 ASDU 长度;2 个八位位组;

　　} GSP__APCH ;

　　F.2 . 3 GSP_unitID(服务数据单元标识)

　　// 服务数据单元标识定义

　　typedef struct GSP_application_service_data_unit_ID {

　　} GSP__UnitID ;

　　F.2.4 GSP_ASDH_object(对象单元头部结构)

　　// 对象单元头部结构(UT=0)

　　GB/T 33602—20 17

　　typedef struct GSP_service_data_unit_header_for_object {

　　GSP__APCH APCH ; //通用服务协议头，APCH ; 4 个八位位组;

　　GSP_UnitID unitID; //单元标识，UI; 1 个八位位组;

　　INT8U classID; //类标识，CI; 1 个八位位组;

　　INT8U objectSize; //对象尺寸，OS; 1 个八位位组;

　　INT8U objectCount; //对象个数，OC; 1 个八位位组; } GSP_ASDH_Object;

　　F.2.5 GSP_ASDH_Parameter(参数单元头部结构)

　　// 参数单元头部结构(UT=1)

　　typedef struct GSP_service_data_unit_header_for_parameter {

　　GSP__APCH APCH ; //通用服务协议头，APCH ; 4 个八位位组;

　　GSP_UnitID unitID; //单元标识，UI; 1 个八位位组;

　　INT8U subService; //子服务，SS; 1 个八位位组;

　　INT8U shortSequence; //短相对序号，SQ; 1 个八位位组;

　　INT8U parameterCount; //参数个数，PC; 1 个八位位组;

　　} GSP__ASDH__Parameter ;

　　F.2.6 GSP_ASDH_Flow(流数据单元头部结构)

　　// 流数据单元头部结构(UT=2)

　　typedef struct GSP_service_data_unit_header_for_flow {

　　GSP__APCH APCH ; //通用服务协议头，APCH ; 4 个八位位组;

　　GSP_UnitID unitID; //单元标识，UI; 1 个八位位组;

　　INT8U subService; //子服务，SS; 1 个八位位组;

　　INT16U sequence; //长相对序号，SEQ; 2 个八位位组;

　　} GSP__ASDH__Flow ;

　　F.2.7 GSP_ASDH_class(类描述单元头部结构)

　　// 类描述单元头部结构(UT=3)

　　typedef struct GSP_service_data_unit_header_for_class {

　　GSP__APCH APCH ; //通用服务协议头，APCH ; 4 个八位位组;

　　GSP_UnitID unitID; //单元标识，UI; 1 个八位位组;

　　INT8U classID; //类标识，CI; 1 个八位位组;

　　INT8U objectSize; //对象尺寸，OS; 1 个八位位组;

　　INT8U attributeCount; //属性个数，AC; 1 个八位位组;

　　} GSP__ASDH__Class ;

　　F.2.8 GSP_ASDH_DataSetExt(数据集扩展单元头部结构)

　　// 数据集扩展单元头部结构(UT=4)

　　typedef struct GSP_service_data_unit_header_for_dataset_ext {

　　GSP__APCH APCH ; //通用服务协议头，APCH ; 4 个八位位组;

　　GSP_UnitID unitID; //单元标识，UI; 1 个八位位组;

　　INT8U classID; //类标识，CI; 1 个八位位组;

　　GB/T 33602—20 17

　　INT8U objectSize; //对象尺寸，OS; 1 个八位位组;

　　INT8U objectCount; //对象个数，OC; 1 个八位位组;

　　INT8U dataSet; //数据集，DS;或频道 Channel; 1 个八位位组;

　　INT8U subService; //子服务，SS; 1 个八位位组;

　　INT16U sequence; //长相对序号，SEQ; 2 个八位位组;

　　} GSP__ASDH_DataSetExt ;

　　F.2.9 GSP_ASDH_GeneralwideExt(通用宽扩展单元头部结构)

　　// 通用宽扩展单元头部结构(UT=5)

　　typedef struct GSP_service_data_unit_header_for_general_wide_ext {

　　GSP__APCH APCH ; //通用服务协议头，APCH ; 4 个八位位组;

　　GSP_UnitID unitID; //单元标识，UI; 1 个八位位组;

　　INT8U classID; //类标识，CI; 1 个八位位组;

　　INT8U objectSize; //对象尺寸，OS; 1 个八位位组;

　　INT8U objectCount; //对象个数，OC; 1 个八位位组;

　　INT8U channel; //频道，CH ; 1 个八位位组;

　　INT8U subService; //子服务，SS; 1 个八位位组;

　　INT16U sequence; //长相对序号，SEQ; 2 个八位位组;

　　INT32U userExt; //用户扩展; 4 个八位位组;

　　} GSP__ASDH__GeneralWideExt ;

　　F.3 代理帧头结构

　　代理帧头是为了方便实现代理逻辑关系时用以标识关联关系的数据头，可在服务代理之间的APDU 之前加 12 个八位位组;当采用网络地址转换方式实现时，不需增加代理帧头。 其结构如下：

　　//代理帧头结构

　　typedef struct GSP_proxy_head {

　　} GSP_ProxyHead;

　　注 1 : associateID生成原则，由服务消费者端服务代理的外部 IP 地址和序列号组成，各占 4 个八位位组，其中高32 比特为 IP地址，低 32 比特为序列号。

　　注 2：头部结构采用小端点字节序。

　　F.4 服务调用参数

　　F.4. 1 GSP_ServiceRef(服务描述)

　　//服务描述

　　typedef struct GSP_service_reference{

　　GB/T 33602—20 17

　　INT8U ServiceCode; //服务编码 SC

　　INT8U SubService; //子服务码 SS

　　STRING *ServiceDesc; //服务的 S语言描述指针

　　}GSP__ServiceRef ;

　　F.4 .2 GSP_Protocolunit(协议单元)

　　//协议单元

　　typedef struct GSP_protocol_unit{

　　}GSP__ProtocolUnit ;

　　F.4 . 3 GSP_Mode(服务模式)

　　//服务模式

　　typedef struct GSP_service_mode{

　　INT8U

　　INT8U

　　INT8U

　　INT8U

　　INT32U

　　GSP_Asyn;

　　GSP__Link ;

　　GSP_ExtFlag;

　　GSP__Res1 ;

　　GSP__Res4 ;

　　//0：同步服务方式;1：异步服务方式//0：短连接;1：长连接;2：无连接

　　//报头扩展标志 EF,0：标准，1：扩展//保留备用 1 个八位位组

　　//回调函数入口地址索引

　　}GSP__Mode ;

　　F.4 .4 GSP_Buffers(服务缓冲区)