面向服务端的变电站自主可控站控层服务协议一致性测试技术

郑明忠，卜强生，高 磊，彭志强，张琦兵，盛 福

（1. 国网江苏省电力有限公司电力科学研究院，江苏 南京 211103；2. 国网江苏省电力有限公司，江苏 南京 210024；3. 东方电子股份有限公司，山东 烟台 264000）

0 引言

IEC 61850 是智能电网以及智能变电站的核心标准，在我国的智能输变配电领域得到了广泛的应用［1-2］。IEC 61850标准中定义的抽象通信服务接口ACSI（Abstract Communication Service Interface）可以映射到许多的协议［3-4］，目前我国的变电站站控层通信协议映射到制造报文规范MMS（Manufacturing Message Specification），但是存在很多的问题［5-6］，例如：MMS 的开发包严重依赖国外收费的软件包，导致核心技术受制于人；MMS 的设计复杂，导致传输以及开发效率低。针对上述问题，文献［7］提出了变电站二次系统通信报文规范CMS（Communication Message Specification），实现了IEC 61850 通信协议栈的完全自主可控。在通信服务映射的实现方面，CMS 协议直接将ACSI 映射到传输控制协议／网际协议TCP／IP（Transmission Control Protocol／Internet Protocol）协议栈，以提升服务的性能；基于IEC 61850-7-2 标准化ACSI的语法定义［8］，增加了安全认证，保证了客户端与服务端双方通信的安全，弥补了服务端对主站的支撑服务。在编码方面，CMS 协议采用抽象记法1 ASN.1（Abstract Syntax Notation dot one）的压缩编码规则PER（Packed Encoding Rule）方式，以增强编／解码以及数据传输的效率［9］。

CMS 与MMS 都是基于IEC 61850-10［10］进行一致性测试的。与MMS 软件包类似，前期我国检测机构较依赖于国外的MMS一致性测试工具（如DNV公司的UniCA sim61850simulator），该工具的使用成本高，同时所有测试用例采用VB 编写且完全开源，测试用例不包含硬件设备的调用接口，自动化程度不足，被测智能设备和测试软件系统之间没有形成完全闭环，测试过程中需要测试人员手动调整多种物理量，影响了测试的效率。据此，我国开展了基于MMS 的一致性测试系统的研究与开发［11-12］，基于Python 脚本开发，封装了测试用例库，实现了一致性软硬件的闭环测试，所涉及的软件框架主要包括模型解析、测试用例模块、系统配置模块等［13］。在已有关于MMS 一致性测试工具研究的基础上，本文根据CMS 的报文编码规则特点，研究基于协议插件的CMS一致性测试技术。

CMS 与MMS 是ACSI 在底层通信协议映射的不同实现，本文分析了CMS 与MMS 协议的重要区别；对于部分扩展服务进行测试用例设计；同时，复用已有MMS 基于Python 开发的测试用例脚本，设计了基于协议插件的CMS 一致性测试方法，减少二次代码开发，该方法利用基于第三方开源库的协议插件，更完整地对CMS 语法结构进行校验，实现了从用例逻辑到语法、语义的全面测试；最后，基于该软件框架，研发了CMS 一致性测试工具，为变电站站控层CMS实用化提供技术保障。

1 MMS与CMS的区别

MMS 与CMS 都是基于IEC 61850 标准将ACSI信息模型和服务映射到底层的通信协议［14］。在实践与应用过程中，IEC 61850 映射到MMS 与映射到CMS有较大的不同。

1.1 特定通信服务映射与模型映射

ACSI 自身不具备通信功能，没有特定的报文格式和编／解码语法，不能直接用于信息交换，需通过特定通信服务映射SCSM（Specific Communication Service Mapping）映射到底层通信协议。CMS 对于MMS的替代，两者之间的最大区别体现在如下方面。

MMS协议需要对IEC 61850原有的模型与服务分别进行映射，需要对多个ACSI 中的服务与IEC 61850 中的模型进行分解并分别映射到某几个服务与模型上。CMS 则是实现ACSI服务一一映射，在底层通信协议上将ACSI 直接映射到TCP／IP，在信息模型上则是直接应用IEC 61850信息模型，无需进行转换。MMS需要通过服务+模型的方式区分ACSI服务，而CMS 则通过应用协议控制头APCH（Application Protocol Control Header）的服务码SC（Service Code）进行服务区分。例如：MMS需要通过有名变量中的路径形式（如逻辑节点LN（Logical Node）路径或数据对象DO（Data Object）路径）与MMS 自身的读服务实现ACSI 的GetLogicNodeDirectory 与GetData-Directory 服务；在控制类的服务中，需要新增SBOw、Oper、Cancle 等DO，与MMS 的写服务共同实现ACSI中的Select-WithValue、Operate、Cancel等服务。

CMS 将ACSI 直接映射到TCP／IP 传输协议子集，无需进行中间的协议转换（如MMS），所有设备厂家均可按照ASN.1语法文件以及PER进行协议开发，无需依赖国外的MMS 软件开发包。CMS 进行ACSI的直接映射，所有服务都与ACSI中的服务一一对应，包括关联、服务器／逻辑设备LD（Logical Device）／LN、数据、数据集、定值、报告等，同时为了提高通信效率并实现远程调用，进行了部分服务的扩展。

将模型DO 共同映射到MMS 中的有名变量，在生成有名变量结构体时，映射算法会根据功能约束FC（Functional Constraint），对LN 中所有相同的FC数据属性进行重组，构成结构体成员，即在树形结构上FC 高于DO。关于CMS 没有数据模型映射的问题，为了提高通信效率，扩展读所有数据定义的服务，可以实现某个LD 或者LN 下全部数据定义的一次性上送，此时在树形结构上FC 低于DO。在线初始化的过程中，通过Wireshark 进行报文解析时，CMS 数据结构更贴近ACSI 原始模型结构。MMS 与CMS映射上的具体区别如图1所示。

图1 MMS与CMS映射上的具体区别Fig.1 Specific differences in mapping between MMS and CMS

1.2 控制服务

MMS 进行了控制FC 的扩展，通过write 服务+信息模型扩展（对Pos 进行扩展，增加了SDI SBOw）实现了ACSI中带值选择服务映射；而CMS无需进行控制FC 扩展，其自身具备SelectWithValue 等控制服务，而控制服务本身的控制对象为DO（如Pos），在执行服务时无法确认Pos.ctlVal的数据类型，为此，需要通过读数据定义GetDataDefinition 服务的response+中返回CDCType获取ctlVal的数据类型。

1.3 心跳报文

在MMS 中，只有客户端能够监视服务端的通信是否中断，具体方式是通过某些读服务（如读数据值服务）实现的，客户端每隔一段时间发送读服务检查服务端是否返回；而CMS 扩展了TEST 服务，该服务仅有APCH，不包含应用服务数据单元ASDU（Application Service Data Unit），同时能够供服务端进行客户端当前通信状态的判断。

1.4 远程过程调用

CMS 定义了一组扩展服务用于实现远程调用，该组服务是一种通用化、自描述的接口和方法调用机制，可由客户动态获取接口和方法定义，根据定义动态组织发送数据并对返回的结果进行自动解析。主要包括读远程调用接口目录服务、读远程调用方法目录、读远程调用接口定义等。

1.5 关联协商

MMS 将ACSI 中的关联服务直接映射到MMS 的Initiate 服务中，在Initiate 服务中进行PDU size 以及所支持服务的协商；而CMS 中拆分了关联服务和关联协商服务，关联协商服务不返回所支持服务类型，仅进行客户端与服务端之间APDUsize 与ASDUsize的协商。

1.6 其他区别

1）CMS 还扩展了其他少量服务，提高了交互效率，如：读所有控制块值服务GetAllCBValues，列文件目录服务GetFileDirectory。

2）CMS 的Reference 采用LD／LN.DO.DA 形式，而非MMS的LD／LN$FC$DO$DA形式。

3）CMS无扩展的控制块DO。

4）CMS 无扩展的控制FC、缓存报告FC、非缓存报告FC、日志FC、通用面向变电站事件对象控制FC、通用变电站状态事件控制FC、采样值FC、多播采样值控制FC、单播采样值控制FC。

5）CMS 中SeriveError、AddCause 等ENUMER ATED类型数据的取值不同。

2 CMS一致性测试

IEC 61850 服务器一致性测试是智能电网中产品检测的必测项目，能否通过服务器一致性检测也是所有厂家互操作的基本要求。我国厂家主要根据《电力自动化通信网络和系统 第10 部分：一致性测试》开展一致性测试。

一致性测试面向不同通信服务（如关联协商、关联、服务器／LD／LN、数据、数据集等）中的业务逻辑（可以是服务参数，也可以是服务交互逻辑）开展测试。除了关联协商等扩展服务，一致性测试主要是面向ACSI 的一致性测试，与具体的SCSM 是弱相关的，但CMS 通信协议还需要验证传输应用层协议语法、语义的正确性。

2.1 基于Python asn1tools的底层编码／解码调用

CMS 在遵循PER［15］的基础上对ACSI 进行具体实现，ACSI 原生接口与PER 构成了CMS 的语法，基于变电站的信息模型（包括全站系统配置SCD（Substation Configuration Description）文件、IED 实例配置CID（Configured IED Description）文件、IED 能力描述ICD（IED Capability Description）文件等）传递具体信息内容以构成CMS的语义。

CMS 无需考虑向其他协议进行映射，在实现方面主要考虑语法的编码／解码，据此可以应用Python 中的第三方库asn1tools 实现底层服务协议开发，应用库中返回的错误原因进行语法的一致性测试，具体步骤如下：

1）根据CMS组装ASN.1文件模块；

2）导入ASN.1文件；

3）调用asn1tools进行数据编码／解码。

将数据传入Python，将其映射到Python 相应的数据类型，最终实现数据的解析。在CMS 中存在大量的数据结构，例如sequence、sequence of、bit string、octer string 等，将其映射到Python 相应的数据结构［16-17］，如表1所示。

asn1tools 能够实现语法、语义的测试，当编码／解码失败时，会返回Ecoderror／Decoderror以及失败原因。在CMS 的语法一致性测试的基础上，根据导入的信息模型，解析配置文件，并对模拟器与被测设备信息交互报文进行语义一致性测试，语义一致性测试ACSI传递参数是否与信息模型完全一致。

目前，CMS 还在不断地更新迭代，通过ASN.1 语法文件导入+第三方库asn1tools 这种方式可大幅减少底层代码的重复开发。

2.2 CMS一致性测试用例

目前，MMS 一致性测试用例主要参照文献［18］设计，CMS 一致性测试用例与MMS 的主要区别在于底层编码，而上层业务逻辑与交互机制并未发生变化，因此可以复用多数公用事业通信架构（UCA）测试用例，对于少量扩展的服务而言，需要重新设计测试用例。

对于读所有数据定义服务、读所有控制块值服务、列文件目录服务、远程过程调用系列服务以及Test 服务，虽然均为扩展后的服务，但是根据一致性测试用例的设计思想，可以套用其他测试用例的设计思路进行测试用例设计。

对于关联协商服务，其涉及应用协议数据单元（APDU）与ASDU是否协商生效以及协商如何设计能使其进行分帧传输问题，需要对其测试用例进行设计。关联协商服务测试用例的设计流程图见图2。图中：条件①是为了保证最终的报文能够分帧传输；条件②和条件③是为了保证客户端去协商是有效的协商，是一个边界条件。具体步骤如下：

图2 关联协商服务测试用例的设计流程图Fig.2 Flowchart of designing association negotiation service test case

1）在线用APDU、ASDU 最大值在线协商方式获取被测设备（DUT）所支持的APDU 与ASDU 大小APDU_DUT、ASDU_DUT；

2）通过不同大小的APDU（APDU_new1、APDU_new2）、ASDU 与DUT 进行协商，检查协商结果是否正确；

3）通过读所有数据定义服务，获取某LD下的所有数据定义，并获取当前的ASDU_SUM大小；

4）应用ASDU_new1、APDU_new3与DUT关联协商，其中30＜APDU_new3＜ASDU_new1＜ASDU_SUM；

5）通过读所有数据定义服务（当APDU＜ASDU时，应分帧传输），获取该LD 下的所有数据定义，检查DUT是否按要求进行分帧传输。

3 一致性测试工具

根据《电力自动化通信网络和系统第10 部分：一致性测试》，一致性测试工具的最小功能配置包括：①客户端模拟器，用于关联和产生双边应用关联TPAA（Two Party Application Association）报文；②测试主机，用于启动／停止测试用例、分析和记录测试结果；③协议分析仪，用于存储所有测试用例的通信网络的信息；④信号发生器，用于由测试主机或测试工程师控制产生数字量和模拟量的事件。基于此，设计一致性测试工具。

目前已有基于Python 脚本实现MMS 的一致性测试工具的应用与一致性检测。测试用例脚本库经过IEC 61850的大量检测，应用已相对成熟。

3.1 支持协议插件的一致性测试工具设计

CMS 测试用例脚本应用协议插件设计思路，可复用多数MMS 一致性测试用例脚本［12］，减少用例脚本的重复开发。

目前，MMS 一致性测试主要采用跨平台语言QT、Python 脚本、动态链接库实现，其中动态链接库封装了MMS，即对MMS 的映射以及基本编码规则BER（Basic Encoding Rule）的解码与编码进行封装［11-13］。通过协议插件的软件框架复用了Python 脚本库，可实现测试用例脚本的逻辑调用。软件开发上重新应用ACSI抽象服务设计思维，在底层通过协议选择开关选择不同的协议插件进行一致性测试。基于协议插件的一致性测试切换过程见图3。

图3 基于协议插件的一致性测试切换过程Fig.3 Switching process of consistency testing based on protocol plugins

基于协议插件的形式对ACSI 与具体映射进行解耦，满足支持不同版本产品同时测试的需要。支持协议插件的通信协议测试技术以测试用例为对象，采用面向对象技术开发的测试代码，利用系统引擎控制测试流程完成自动测试。对于功能相同而协议版本不同的被测设备而言，只需开发1 次测试代码，代码的重复利用率高，当通信协议进行升级时，只需针对新增功能进行代码开发和系统引擎维护，可扩展性强。

3.2 一致性测试工具的架构

一致性测试工具包括软件平台与硬件平台。其中：软件平台面向测试用例进行软件功能设计；硬件平台提供模拟量与开关量输出，也支持面向通用对象的变电站事件GOOSE（Generic Object Oriented Substation Event）等提供数字量输出，并向软件平台提供调用接口。同时，软件平台接收外部对时，实现与被测设备的时间同步。软件和硬件平台架构见图4。

图4 软件和硬件平台架构Fig.4 Architecture of software and hardware platform

软件平台主要包括测试用例模块、实时测试信息打印模块、状态序列模块、模型文件解析模块、测试日志模块、报文解析模块以及客户端模块，具体架构如图5所示。

图5 软件平台架构Fig.5 Architecture of software platform

测试用例模块对测试用例库与服务接口进行抽象，以供MMS与CMS复用，测试用例脚本开放共享，使用者基于高度抽象化函数接口根据需求进行测试用例二次开发设计，构建良好的测试用例开发生态。测试用例库基于IEC 61850 Ed 2.0 一致性测试用例进行扩展设计，同时复用同类型测试用例。实时测试信息打印模块不再单纯打印测试过程信息，而是将测试过程的报文与测试步骤紧密耦合，便于快速定位测试问题。状态序列模块与传统测试仪中输出序列化的电压、电流信号不同，其将通信服务接口加入测试仪输出序列中，基于此设计可灵活实现部分开环测试用例。模型文件解析模块实现对CID 文件的解析与校验，在生成模型树的前提下，根据配置参数的需要对模型文件中的路径、数据类型进行分类，实现配置参数的快速检索。测试日志模块将测试日志与测试错误信息自动插入测试报告模板，实现测试报告的自动生成。报文解析模块包括MMS报文解析与CMS 报文解析功能模块。客户端模块包括MMS客户端与CMS客户端，同时通过多线程设计实现至少16 个客户端并发运行，根据测试用例的需要并发不同的服务。

CMS一致性测试工具根据被测设备厂家填写的标准协议实现一致性陈述PICS（Protocol Implementation Conformance Statements）、测试用协议实现额外信息PIXIT（Protocol Implementation eXtra Information for Testing）、模型实现一致性陈述MICS（Model Implementation Conformance Statements）及技术情况一致性陈述TICS（Technology Implementation Conformance Statements）文件自动生成不同测试用例的测试参数，并将其导入软件中，测试用例脚本库根据被测设备选择协议类型并调用相关协议库进行测试，根据测试用例的需要调用相关硬件进行闭环测试，在测试过程中实时抓取报文，并进行测试问题跟踪定位，最终生成标准模板测试报告。一致性测试的具体流程如图6所示。

图6 一致性测试的具体流程Fig.6 Specific process of consistency testing

3.3 现场应用

目前，CMS 一致性测试工具已被应用于完成我国首套全自主可控变电站监控系统出厂验收测试，搭建的变电站监控系统出厂验收测试环境如图7 所示，被测设备包括测控装置、保护装置等间隔层设备。测试用例涵盖了应用关联测试、服务器LD／LN的DO 测试、数据集测试、定值组测试、报告测试、日志测试、控制测试、文件测试、取代测试。

图7 测试环境Fig.7 Test environment

应用CMS 一致性测试工具开展100多项测试用例测试，通过标准化的测试来保证支持CMS 协议被测设备的一致性、规范性，排除测试的随机性和盲目性，并降低冗余、减少遗漏；同时CMS 一致性测试工具能使测试用例多次运行，具有可重复性，能完成人工测试因时间、运行环境而无法进行的测试，大幅提升测试效率。

但是经测试发现存在如下问题。

1）在进行应用关联测试时，客户端释放关联后，还能正常响应其他服务；客户端关联必须使用IEDname.S1进行；APDUsize与ASDUsize的协商逻辑有误。

2）在进行服务器LD／LN 的DO 测试时，读LD目录服务未指定ldName 的情况下，返回的是LN 的名称，而不是LN的引用。

3）在进行报告测试时，timeOfEntry 的格式错误没有按标准要求进行编码。

4 结论

目前，CMS协议在我国已被逐步推广应用，但是我国厂商在进行CMS 协议开发时仍会受MMS 通信协议的影响。为此，本文详细介绍了CMS 协议与MMS 协议的区别，为设备厂商的开发提供参考，同时利用模块化开发的设计思想，设计了支持协议插件的一致性测试工具，该测试工具复用了MMS 的测试用例，对于基于Python 的MMS 一致性测试工具开发者而言，可以大幅减少抽象测试用例的重复开发工作量，为一致性测试工具开发提供了良好的设计思路。