一致性测试优化方案

配电自动化系统主站的一致性测试包括模型及消息以及规约的两个方面测试。模型及消息的一致性测试主要测试不同厂家的应用系统对IEC 61968标准的贯彻情况。

2.2.4.1　模型及消息的一致性测试

随着电力信息标准化的逐步开展，电力企业开始构建基于企业服务总线（Enterprise Service Bus，ESB）的信息集成架构。然而各个系统提供商在实际应用中对IEC 61968标准制定的总线模型与消息规范的理解和贯彻执行差别较大，经常会出现信息交换双方的模型不匹配或者语义不一致导致互操作的失败，在同一条信息交互总线上传递的信息模型与消息类型混乱，以致应用间信息集成受阻，不利于企业内或企业间的信息集成。从技术上讲，缺少一种校验机制对总线信息模型与消息规范进行一致性约束，因此有必要在总线上部署模型与消息验证测试。需要引入一种能够校验模型自身错误的验证器，或者在企业总线上增加模型验证服务，也就是所谓的语义验证机制，即从实际的电网数据模型中解析出元数据信息，并将其与统一的信息模型做校验，实现语义层次的差异化分析。

IEC 61968定义的接口参考模型（IRM）规定，应用组件间的通信要求两个层次上的兼容性，图2-4给出了验证服务在IEC 61968消息总线上的工作流程，即部署在总线上的应用组件每进行一次模型更新（元数据），需要首先向验证服务器传递一条待发布的消息，验证服务器将验证结果返回给应用组件（专有信道）。若验证结果不兼容，则该组件不允许向总线上发布消息，需要根据提供的不兼容信息对模型做核实和修改。若验证通过，则可以向总线服务订阅方发布相应的业务消息，并且在下一次模型更新之前不必再向验证服务器传送消息。经过该验证环节，保证了总线上传输的消息符合定制的消息类型规范（XSD），并且信息模型符合特定子集协议（Profile）的约束。

图2-4　消息总线上的验证服务

SCADA—配电网数据采集和监控；PMS—生产管理系统；GIS—地理信息系统

总线验证机制包含了两个层面：一层是模型验证，即元数据层面的一致性校验；另一层是消息类型的规范性验证。所谓模型验证，是指从消息体（Message Payload）中解析出电网模型元数据信息，并将其与统一的信息模型（CIM及其扩展）做比对，分析语法格式的兼容性以及模型语义的一致性，筛选出不兼容信息，从而便于进行信息模型的管理与维护，从根源上保证总线语义的一致性。而消息类型的规范性验证则是校验总线上传输的消息（XML）是否符合特定的消息类型规范（XSD）（包括IEC 61968-3至IEC 61968-10定义的消息类型和扩展的消息格式）。

需要指出的是，这两个层面的验证并不是完全按照互操作框架中信息层区分，是由消息体（Payload）装载的消息格式决定的，消息构成中的消息体中可以装载如RDF、XSD、PDF等格式的文档，由于RDF和XSD在语法格式和语义定义方面具有各自的优势，如RDF可以表达资源之间的继承关系，因此可以应用于表达电网模型、拓扑连接等语义性需求较强的场景，而XSD使用嵌套方式描述元素之间的关系，在数据转换以及扩展方面具有很大的灵活性。针对以上特点，对基于RDF表达的消息体采用基于本体OWL的验证方法（即模型验证），而对于基于XSD规范的消息采用消息类型的有效性验证（即消息验证）。

模型验证首先是通过解析CIM/XML，抽取该数据模型的元数据信息，并将其与基于本体描述的语义模式做比对，该语义模式可以是基于标准CIM及其扩展的全模型，也可以是统一配置的子集协议，具体的模式选择需要结合实际应用需求。其验证原理如图2-5所示。

图2-5　模型验证原理

消息验证将消息体规范文档导入至Message.xsd这个模式（Schema）中来，构成一个完整的总线消息格式。利用合并的消息规范构建验证的模式，从而实现与消息的比较。在信息技术领域，消息验证就是指XML文档的有效性验证，即提取出XML实例的组织结构和内容类型，并与消息类型定义相比较，若符合消息类型定义的整体结构（包括元素内容、属性，以及出现的顺序、次数等），则表明该XML实例文档是与其模式相一致的。其验证原理如图2-6所示。

图2-6　消息验证原理

2.2.4.2　IEC 61968消息一致性测试

1.IEC 61968消息一致性测试方法

元数据（Metadata）是描述数据的数据，可以描述数据的编码方式或数据交换的格式，也可以描述一种数据如何映射为另外形式的数据。

IEC 61968的消息实例是一种标准化的数据，因此必然存在描述它的元数据。基于一致性测试的需求，本书将IEC 61968消息的元数据分为以下两类。

（1）消息信封元数据（Message Envelope Metadata）。消息信封由消息头、请求组件、应答组件及消息体的“Format”字段组成，4种消息类型的消息信封包含的组成部分有一定差异。消息信封元数据是指描述消息信封结构的XSD文件，包含4种消息类型及其各组成部分的结构定义。前文已介绍了部分该XSD中定义的消息结构，完整文件可在IEC 61968-1第2版[15]或IEC 61968-100[16]中获取。

（2）消息体子集元数据（Payload Profile Metadata）。IEC 61968消息的实际业务数据一般会用于替换消息体的“any”字段，而消息体的“Format”字段仅用于标记实际数据的格式，属于消息信封范畴，因此从某种意义上说，用于替换“any”字段的数据才是真正的消息体。为避免混淆，我们将其称为消息体子集实例。消息体子集元数据即消息体子集实例所对应的XSD文件，由IEC 61968-3至IEC 61968-10部分制定，也可由用户自行根据需求基于CIM模型抽取子集并利用CIM Tool等软件生成。

2.IEC 61968消息一致性测试规则

一致性测试是基于IEC 61968标准以及实际的应用需求，建立一致性测试规则，并通过一定的测试流程比对待测消息与规则的一致性。建立合适的一致性规则是实现一致性测试的基础。本书提出以下两个层次的一致性测试规则。

（1）格式层规则。格式层规则用于测试IEC 61968消息的格式是否符合对应的元数据定义。对于一条完整的IEC 61968消息实例，其信封格式应符合消息信封元数据的定义，其消息体子集实例格式应符合消息子集元数据的定义。因此，IEC 61968消息一致性测试的格式层规则应分为两个并行部分，即消息信封格式层规则和消息体子集格式层规则。

1）XSD于2001年成为万维网联盟（W3C）推荐使用的标准，它用于定制一个XML文件的结构，对该文档中的元素（Element）和属性（Attribute）的层次、顺序、类型、值域、基数、命名空间等进行约束。对于一个XML文件而言，它如果需要被正确地识别和解析，则它不仅仅应该是良构的（Well-Formed，指符合基本的XML语法），更应该是有效的（Valid，指与对应的XSD匹配）。

2）XML有效性规则是W3C标准[17]。对于IEC 61968消息而言，其消息信封元数据是XSD文件，大多数情况下的消息子集元数据也是XSD文件，因此消息信封格式层规则和消息体子集格式层规则，均可等同于W3C的XML有效性规则。实际测试时，IEC 61968消息实例的消息信封部分，应通过XML有效性规则与消息信封元数据（即消息信封XSD）进行比对，而消息体子集实例部分则应通过XML有效性规则与消息体子集元数据（即消息体子集XSD）进行比对。不同版本的消息信封元数据、消息体子集元数据或对应不同业务的消息体子集元数据，可通过命名空间加以区分（由XSD文件根元素的目标命名空间“targetNamespace”属性标识）。

一条IEC 61968错误消息如图2-7所示。

图2-7　IEC 61968错误消息实例

错误消息不包含消息体，仅包含消息信封的应答组件。根据根元素节点中标识的命名空间，可知该条消息对应的消息信封元数据XSD的目标命名空间为“http：//iec.ch/TC57/2011/schema/message”，根据W3C的XML有效性规则，上述实例有几处与规则不符：①应答组件的节点顺序错误，“Result”节点应最先出现，然后是“ID”节点，最后是“operationId”节点；②“Result”节点基数错误，根据元数据定义，“Result”节点只能有且只有一个，而实例中出现了两个；③“Result”节点值与元数据定义不符，“Result”节点在元数据中通过枚举约束限制其值只能为“OK”“FAILED”或“PARTIAL”“YES”显然并不在其有效范围内。

（2）应用层规则。格式层规则只能测试IEC 61968消息与其元数据的一致性，但因元数据本身的通用性，使得在针对具体应用时，一些特殊的一致性需求无法通过元数据表达，这也使得仅满足格式层规则的一致性测试并不完备。因此，针对具体的应用场合，还应制定一系列应用层规则作为补充。

与格式层规则相仿，需分别制定消息信封和消息体子集实例的应用层一致性规则。

1）消息信封应用层规则。消息信封包含了交互双方的协议和参数，对于交互一致性至关重要。但是由于不同的应用场合及不同系统间的交互会有其特殊性，交互协议不可能完全相同，因此消息信封的应用层一致性测试应该是开放式的、可扩展的，可根据具体场景下的具体需求设计不同的规则。

本书制定两条适用于所有应用场景的消息信封应用层一致性基本规则，其余与业务绑定的规则（如某项业务的消息请求组件必须包含哪些参数等）可根据具体业务需求扩展，不作为必要测试内容。

定义1：动词匹配规则。所有应用场景下，消息头中的动词都必须与消息类型匹配。请求消息的消息头仅可使用以下动词之一：get、create、change、cancel、close、delete、execute。应答消息的消息头仅可使用以下动词：reply。事件消息的消息头仅可使用以下动词之一：created、changed、canceled、closed、deleted、executed。

在消息信封元数据XSD中，消息头中的动词被定义为一个string类型的枚举类，可能的值域为：get、create、change、cancel、close、delete、execute、reply、created、changed、canceled、closed、deleted、executed。然而，不同的消息类型虽然共用这个动词定义，但在实际使用时不同类型的消息仅应使用值域中的一部分值以明确动词语义。在格式层校验时，只要动词字段的值落在该值域范围内，即符合XML有效性规则，无法测试出不同消息类型的动词是否符合实际的应用要求。因此需在应用层建立该规则作为补充。

一条IEC 61968应答消息如图2-8所示。该应答消息中，动词为“deleted”，虽然符合格式层的W3C的XML有效性规则，但是不符合动词匹配规则，应修正为“Reply”。

图2-8　IEC 61968应答消息实例

定义2：信封根元素定义规则。所有应用场景下，消息信封的根元素名仅可为RequestMessage、ResponseMessage、EventMessage、FaultMessage四者之一。消息信封根元素所在命名空间必须与消息信封元数据库中的至少一个元数据XSD的目标命名空间相同。

假设信封元数据库中仅有一个XSD，其目标命名空间为“http：//iec.ch/TC57/2011/schema/message”，此时下述消息：

<Event xmlns="http://iec.ch/TC57/2008/">

该消息信封根元素定义是与规则不一致的，其根元素名和所在命名空间均错误，应修正如下：

<EventMessage xmlns="http://iec.ch/TC57/2011/schema/message">

2）消息体子集实例应用层规则。与消息信封一样，对于消息体子集实例而言，每个不同的业务场景都对应不同的子集，也有不同的子集XSD，每个不同的业务对数据会有不同的特定需求，很难通过一个统一的规则来描述其应用层一致性规则。因此消息体子集实例的应用层一致性规则也应该和消息信封一样，是开放式、可扩展的。

本书制定两条适用于所用场景的消息体子集应用层一致性基本规则，其余与业务绑定的规则（如电网拓扑模型子集的拓扑连接一致性[18]等），可根据具体业务需求扩展，不作为必要测试内容。(www.xing528.com)

定义3：引用有效性规则。所有应用场景下，凡消息体子集实例中的对象关联使用“ref”属性字段进行外部引用，则在该条消息内必须存在具备与该字段值相等的mRID子元素的元素节点。

IEC 61968消息体子集实例中，为了降低数据冗余，对于有多对一关联的数据对象，会使用外部引用的方式来构建对象关联。IEC 61968-9部分的抄表消息体子集实例如图2-9所示。

图2-9　抄表消息体子集实例

该实例中，“Readings”元素节点与“ReadingType”元素节点存在关联关系。正常情况下两个“Readings”元素节点都应该包含一个完整的“ReadingType”子节点，但由于两个“Readings”节点与同一个“ReadingType”节点相关联，包含两次完整节点会造成数据冗余，因此将“ReadingType”节点移到外层，并在“Readings”节点内添加一个仅含“ref”属性字段的“ReadingType”子节点，其值引用外部“ReadingType”节点的mRID字段，以此构建对象关联。根据引用有效性规则，显然上述实例与规则不一致，因为没有一个“ReadingType”元素节点的mRID子元素值为“0.0.1.0.2.13.2.0.0.0.111”，造成了引用无效。

定义4：消息体子集实例根元素定义规则。所有应用场景下，消息体子集实例的根元素名必须与消息体子集元数据库中的至少一个元数据XSD名相同，且根元素所在命名空间必须和与其同名的元数据XSD中的一个目标命名空间相同。

IEC 61968的业务子集名和其对应的XSD是相同的，如IEC 61968-9部分的“Meter-Readings”子集，其对应的XSD名就为“MeterReadings.xsd”。另外，同一个子集可能会有不同的版本，这些不同版本的XSD文件名相同，但目标命名空间不同。

假设子集元数据库中仅有一个XSD，其目标命名空间为“http：//iec.ch/TC57/2009/MeterReadings#”，文件名为“MeterReadings.xsd”，此时下述消息：

<Meters xmlns="http://iec.ch/TC57/2009/Meters#">

该消息体子集实例的根元素定义是与规则不一致的，其根元素名和所在命名空间均错误，应修正如下：

<MeterReadings xmlns="http://iec.ch/TC57/2009/MeterReadings#">

3.元数据及规则驱动的一致性测试方法框架

IEC 61968消息的元数据版本处于不断更替当中，其中消息信封元数据XSD从2010年年底至2012年年底进行了20余次修改，而各消息子集元数据XSD也在不断更新，许多子集甚至尚未发布。各系统开发商遵循不同版本元数据进行开发，会导致系统间互操作的失败。与元数据类似，一致性测试规则也具有很大的可扩展性，将会处于不断完善之中。

图2-10　元数据及规则驱动的一致性测试方法框架

为了保证一致性测试方法的鲁棒性（Robustness），应设计一套元数据及规则驱动的框架。所谓元数据及规则驱动，即一致性测试的主过程不受元数据及规则变化的影响，彼此独立。该框架如图2-10所示。

一致性测试主引擎接收待测试IEC 61968消息，并调用规则实现模块库中的各模块，这些模块加载元数据库中的相关元数据用以实现格式层及应用层的规则推理，最终由主引擎输出一致性测试报告。

当元数据版本和内容发生变化时，只需修改元数据库，无需修改各规则实现模块和主引擎；当一致性测试规则发生变化或扩充时，只需修改或增加对应的规则实现模块，无需修改其他规则实现模块、主引擎和元数据库。这就保证元数据存储、规则推理与一致性测试主流程三者独立性，便于维护升级。

规则实现模块库中的各模块的物理封装粒度可根据实际情况调整，可以一条规则对应一个模块，也可以一类规则对应一个模块，较为灵活。

4.IEC 61968消息一致性测试的软件实现

元数据及规则驱动框架可有多种实现方式，本节论述一种可扩展松耦合一致性测试Web服务体系用以实现该框架，如图2-11所示。

（1）本节基于.NET Framework，使用C#语言实现该Web服务体系。其主要软件流程如下：

1）主服务接收客户端发送的待测消息，解析主服务配置文件后创建与子服务数量相同的子线程，并行调用子服务并转发待测消息（并行化可充分提高测试效率），主线程循环等待。

2）子服务分别封装消息信封和消息体子集实例的格式层、应用层规则，并与对应的元数据库实现对接。规则的实现需要加载和解析元数据库中所有元数据的目标命名空间及元数据内容，并根据规则逐行遍历待测试消息，记录各规则的测试结果，生成测试子报告返回给主服务。

3）主服务接收到所有子报告后，结束等待并合并所有子报告，生成总测试报告，返回给客户端。

图2-11　一致性测试Web服务体系

（2）该Web服务体系的松耦合性和可扩展性主要由统一服务接口和可扩展主服务配置文件保证。

1）统一服务接口。主服务与所有子服务均使用同一个Web服务描述语言（Web Services Description Language，WSDL）文件来定义服务接口，如图2-12所示。该WSDL文件包含一个接口（方法），接口（方法）名为“Test”，输入参数类型为“Input”，输出参数类型为“Output”，格式分别如图2-13和图2-14所示，其中虚线框表示可选项，实线框表示必选项。

图2-12　统一服务接口的WSDL文件结构

待测试的IEC 61968消息用于替换输入参数的“any”字段，“TimeStamp”字段用于记录请求时间；测试报告存放在输出参数的“TestReport”字段中，测试报告由测试项（TestItem）组成，每个测试项包含测试类型（TestClass）、所使用的规则（Rule）、测试结果（Result）以及错误列表（ErrorList），错误列表由错误项（Error）组成，错误项中包含该错误所在行号（RowNumber）和该错误的描述（Description）。

图2-13　服务接口输入参数结构

图2-14　服务接口输出参数结构

2）可扩展主服务配置文件。由于本方案是元数据及规则驱动框架的一种实现，因此必须保证元数据和规则的更新不影响测试的主过程，即子服务的改动或增加不会影响主服务。通过将子服务的信息设计成一种可扩展的配置文件，由主服务在启动时加载和解析，自动配置其与子服务的关联，可充分保证子服务的独立性和可扩展性。配置文件结构如图2-15所示，其中虚线框表示可选项，实线框表示必选项。

图2-15　主服务配置文件结构

子服务的名称和地址存放在“name”和“URL”字段。

如需增加子服务，则增加“SubService”节点并填充相应的“name”和“URL”字段即可，无需修改主服务；如需屏蔽某些子服务，则去掉相应“SubService”节点。

通过统一接口，可使各个服务间保证松耦合性，即无需知道对方的功能如何实现，只需遵从该接口与对方交互；当需要扩展子服务时，仅需使用该统一接口进行开发，并修改主服务配置文件即可，保证了功能的可扩展性。

5.一致性测试服务的部署与应用模式

测试服务的部署与应用模式有以下两种。

（1）在线测试模式。在线测试模式指将一致性测试主服务与所有子服务均部署于IEC 61968信息交换总线/企业服务总线上，当实际业务系统通过总线向其他系统发送消息时，由总线适配器实时调用一致性测试主服务转发该消息，并将收到的测试结果返回给消息发送方或推送到监控平台上，便于及时修正。为应对在线测试可能面临的实时海量数据，可将主服务与各子服务分散在不同服务器上，以减轻测试压力，充分体现主服务并行调用子服务的效率优势。

（2）离线测试模式。离线测试模式指将一致性测试的主服务与所有子服务均部署在本地或局域网内的Web服务器上，供系统开发人员进行离线自测试，修正系统错误，待全部通过后该系统才可接入IEC 61968信息交换总线/企业服务总线与其他系统进行信息交互。