基于Mule的IEC61968信息交互總線的研究與應(yīng)用

許穩(wěn)堂　閆紅漫　張弘

摘要：針對(duì)目前配電網(wǎng)領(lǐng)域信息交互、信息共享問(wèn)題，提出了一個(gè)基于Mule的IEC61968信息交互總線的功能架構(gòu)，深入分析了信息交互總線的主要功能模塊，并實(shí)現(xiàn)了一個(gè)總線服務(wù)原型系統(tǒng)，最后通過(guò)對(duì)總線上發(fā)布模型數(shù)據(jù)場(chǎng)景的集成分析，解決了因數(shù)據(jù)模型不一致導(dǎo)致的信息交互問(wèn)題。

關(guān)鍵詞：IEC 61968；Mule；信息交互總線；模型驗(yàn)證

中圖文分類(lèi)號(hào)：TP311.52文獻(xiàn)標(biāo)識(shí)碼：A文章編號(hào)：2095-2163（2016）01-

Abstract： According to the problem of information exchange and information sharing in the field of distribution network， this paper proposes a functional architecture of IEC61968 information exchange bus based on Mule， and deeply analyzes the main function modules of the information exchange bus， then implemented a prototype system of bus service. Finally， this paper solves the information exchange problem caused by inconsistent data model through an integrated analytical scenario of publishing model data on bus.

Key words： IEC 61968；Mule；information exchange bus；model validation

0引言

由于各電力企業(yè)在系統(tǒng)的設(shè)計(jì)及實(shí)現(xiàn)方面都相互獨(dú)立，依據(jù)各自的平臺(tái)和標(biāo)準(zhǔn)進(jìn)行建設(shè)，而且信息交互的數(shù)據(jù)模型通常為各應(yīng)用系統(tǒng)私有，導(dǎo)致各系統(tǒng)間的信息交互、信息共享非常困難，形成了很多“信息孤島”。為了整合電力企業(yè)中的各電力系統(tǒng)，使企業(yè)中的所有電力設(shè)備能夠互聯(lián)互通，國(guó)際電工委員會(huì)制定了IEC61968標(biāo)準(zhǔn)，為電力企業(yè)內(nèi)系統(tǒng)集成提供指導(dǎo)，以減少各應(yīng)用軟件提供商在集成過(guò)程中由于各系統(tǒng)模型不一致所產(chǎn)生的問(wèn)題[1]。

傳統(tǒng)的系統(tǒng)集成過(guò)程大多采用點(diǎn)對(duì)點(diǎn)的通信方式，這種通信方式存在接口數(shù)量多、系統(tǒng)擴(kuò)充性差等缺點(diǎn)。面向服務(wù)架構(gòu)SOA（Software Oriented Architecture）是一種以服務(wù)為中心的分布式軟件集成方法，通過(guò)采用平臺(tái)獨(dú)立的方式定義服務(wù)間交互的接口，能夠使軟件平臺(tái)松散耦合、動(dòng)態(tài)可擴(kuò)展。基于SOA思想構(gòu)建的信息交互總線，采用松耦合的內(nèi)容進(jìn)行企業(yè)應(yīng)用集成，解決了企業(yè)各系統(tǒng)間信息交互、信息共享問(wèn)題。

1 IEC61968標(biāo)準(zhǔn)

IEC61968 標(biāo)準(zhǔn)，為配電管理系統(tǒng)（DMS）制定了統(tǒng)一的接口參考模型（IRM）和詳細(xì)的消息格式規(guī)范，是實(shí)現(xiàn)配電網(wǎng)領(lǐng)域分布式應(yīng)用系統(tǒng)集成的基礎(chǔ)和參考。接口參考模型從整體功能上將DMS分為一些抽象的業(yè)務(wù)組件，而且定義了各組件的接口規(guī)范，注重于不同組件間的交互，但并不關(guān)心各組件具體如何實(shí)現(xiàn)。只要第三方廠商依據(jù)接口參考模型實(shí)現(xiàn)抽象組件規(guī)定的功能，由其提供的應(yīng)用程序或系統(tǒng)就是符合IEC61968標(biāo)準(zhǔn)的應(yīng)用程序組件。

IEC 61968-1定義了通用的消息格式，包含消息頭（Header）、請(qǐng)求選項(xiàng)（Request）、應(yīng)答選項(xiàng)（Reply）和消息體（Payload）[2]。消息頭，記錄了消息的屬性，用于控制消息的傳遞，主要包括：主題（由動(dòng)詞Verb和名詞Noun構(gòu)成）、異步傳輸標(biāo)志位、消息ID、關(guān)聯(lián)ID等；請(qǐng)求選項(xiàng)用于描述具體的請(qǐng)求參數(shù)；應(yīng)答選項(xiàng)表示請(qǐng)求成功、失敗；消息體，使用XML Schema的any元素定義，可以存放任何格式良好的XML文檔，通常是待傳輸?shù)哪Ｐ蛿?shù)據(jù)。IEC61968第3～10部分為每個(gè)信息交互需求特別定義了消息類(lèi)型，一個(gè)消息類(lèi)型是基于CIM的規(guī)范數(shù)據(jù)模型[3]，可以從CIM模型的UML類(lèi)圖中導(dǎo)出消息類(lèi)型的XML模式（XSD）文件，用于約束、校驗(yàn)消息體中的模型數(shù)據(jù)。

2基于Mule的IEC61968信息交互總線

信息交互總線是配電網(wǎng)信息集成的核心部分，遵循IEC61968標(biāo)準(zhǔn)，采用面向服務(wù)架構(gòu)（SOA）的企業(yè)服務(wù)總線（ESB）技術(shù)，各應(yīng)用系統(tǒng)通過(guò)信息交互總線實(shí)現(xiàn)數(shù)據(jù)共享和交互，是一個(gè)松散耦合集成框架。參與集成的各方應(yīng)用并不直接交互，請(qǐng)求方只需與總線交互，總線收到消息后，通過(guò)消息路由過(guò)程確定服務(wù)提供方，并把該消息交付給服務(wù)提供方進(jìn)行處理，這樣實(shí)現(xiàn)了請(qǐng)求方和服務(wù)提供方的解耦，各方可以采用不同的技術(shù)進(jìn)行實(shí)現(xiàn)[4]。如圖1所示，就是本文提出的一個(gè)信息交互總線的功能架構(gòu)，使用Mule ESB作為底層基礎(chǔ)服務(wù)功能層，由其設(shè)計(jì)給出的連接器、消息轉(zhuǎn)換、消息處理、消息路由等，為快速構(gòu)建信息交互總線提供了基礎(chǔ)組件功能。用戶(hù)管理、適配器身份認(rèn)證、服務(wù)注冊(cè)中心、主題配置、消息狀態(tài)管理，是信息交互總線必備的管理控制功能，其中除適配器身份認(rèn)證模塊外都應(yīng)提供基于瀏覽器的配置頁(yè)面，以方便運(yùn)行時(shí)維護(hù)?；谥黝}的消息路由、信息交互模式、應(yīng)用適配器，是信息交互總線與信息交互過(guò)程相關(guān)的核心功能模塊，提供了消息在總線中準(zhǔn)確流轉(zhuǎn)、基于總線的異構(gòu)應(yīng)用信息交互、異構(gòu)應(yīng)用接入總線等功能。

2.1服務(wù)注冊(cè)中心

服務(wù)注冊(cè)中心作為服務(wù)元數(shù)據(jù)的集成點(diǎn)，建立了一個(gè)中心位置，將分散在企業(yè)中的服務(wù)元數(shù)據(jù)聚集在一起，提供了靈活的服務(wù)注冊(cè)、查找等功能。服務(wù)注冊(cè)中心實(shí)現(xiàn)方案通常有3種，對(duì)其可給出如下概述：

1）將服務(wù)元數(shù)據(jù)信息存儲(chǔ)到靜態(tài)的服務(wù)注冊(cè)文件中，通常采用手工編輯的方式，在系統(tǒng)運(yùn)行時(shí)不能修改；

2）將服務(wù)元數(shù)據(jù)信息存儲(chǔ)到一個(gè)關(guān)系數(shù)據(jù)庫(kù)中，利用數(shù)據(jù)庫(kù)提供的數(shù)據(jù)一致性功能，在運(yùn)行時(shí)能夠進(jìn)行動(dòng)態(tài)配置，較為靈活方便；

3）基于UUID標(biāo)準(zhǔn)來(lái)設(shè)計(jì)呈現(xiàn)一個(gè)服務(wù)注冊(cè)中心，該方法的實(shí)現(xiàn)較為復(fù)雜。本文采用方案2來(lái)構(gòu)建信息交互總線的服務(wù)注冊(cè)中心，如圖2所示。在總線運(yùn)行過(guò)程中，為了方便用戶(hù)對(duì)服務(wù)信息的動(dòng)態(tài)管理，服務(wù)注冊(cè)中心采用B/S架構(gòu)設(shè)計(jì)，用戶(hù)可以通過(guò)瀏覽器對(duì)服務(wù)元數(shù)據(jù)信息進(jìn)行集中配置管理，如注冊(cè)服務(wù)信息、更新服務(wù)信息、查詢(xún)服務(wù)信息和刪除服務(wù)信息。信息交互總線的消息路由模塊在解析出入站消息待轉(zhuǎn)發(fā)的目標(biāo)服務(wù)后，可以通過(guò)調(diào)用服務(wù)信息查詢(xún)Web服務(wù)獲取服務(wù)的詳細(xì)信息，取出目標(biāo)服務(wù)的端點(diǎn)地址，完成消息的轉(zhuǎn)發(fā)。

2.2適配器身份認(rèn)證

適配器身份認(rèn)證，是應(yīng)用適配器與總線服務(wù)間交互的重要過(guò)程，每個(gè)適配器都有用戶(hù)名和密碼，應(yīng)用適配器只有通過(guò)總線的身份認(rèn)證后才能與總線進(jìn)行數(shù)據(jù)交互，阻止了非法用戶(hù)的連接。適配器身份認(rèn)證過(guò)程如圖3所示。

由圖3可知，適配器身份認(rèn)證的具體實(shí)現(xiàn)過(guò)程可描述如下：

1）建立連接階段。應(yīng)用適配器向總線發(fā)送包含用戶(hù)名和密碼的建立連接請(qǐng)求消息，總線收到消息后從中取出用戶(hù)名和密碼驗(yàn)證應(yīng)用適配器身份。密碼驗(yàn)證通過(guò)后，總線為該適配器創(chuàng)建一個(gè)上下文對(duì)象并生成一個(gè)Token與之關(guān)聯(lián)，之后把該Token放入響應(yīng)消息中返回給應(yīng)用適配器。

2）數(shù)據(jù)交互階段。應(yīng)用適配器把Token作為消息的一部分發(fā)送給總線，總線從消息中取出Token與認(rèn)證信息庫(kù)中的Token進(jìn)行比對(duì)，驗(yàn)證通過(guò)后方可執(zhí)行其它消息處理過(guò)程，總線根據(jù)身份驗(yàn)證結(jié)果向應(yīng)用適配器返回是否投遞成功的響應(yīng)消息。

3）關(guān)閉連接階段?？偩€從關(guān)閉連接請(qǐng)求消息中取出Token，銷(xiāo)毀該Token和與之關(guān)聯(lián)的上下文對(duì)象。如果應(yīng)用適配器與總線建立連接后長(zhǎng)時(shí)間處于空閑狀態(tài)，總線可以自主銷(xiāo)毀Token，并斷開(kāi)與應(yīng)用適配器的連接。

2.3基于主題的消息路由

2.3.1 主題及主題配置

主題是IEC61968消息頭中的名詞和動(dòng)詞的組合，消息名詞標(biāo)識(shí)了消息體中存放的模型數(shù)據(jù)的類(lèi)型，消息動(dòng)詞用于表示該消息的發(fā)送者希望服務(wù)執(zhí)行的動(dòng)作。名詞和動(dòng)詞根據(jù)具體的業(yè)務(wù)場(chǎng)景和采用的信息交互模式而給出相應(yīng)設(shè)定。如獲取拓?fù)鋽?shù)據(jù)業(yè)務(wù)，該業(yè)務(wù)場(chǎng)景是典型的請(qǐng)求/應(yīng)答信息交互模式，消息動(dòng)詞使用GET，由于從總線上獲取的是拓?fù)鋽?shù)據(jù)，名詞取Topology，該業(yè)務(wù)場(chǎng)景的主題命名為“TopologyGET”。

主題配置的一般流程可表述如下：

1）業(yè)務(wù)場(chǎng)景分析，擬定動(dòng)名詞主題，確定每個(gè)主題的信息交互模式；

2）登錄主題配置頁(yè)面，錄入主題信息，并授權(quán)給相應(yīng)的應(yīng)用適配器服務(wù)。請(qǐng)求主題，通常只需配置一個(gè)服務(wù)提供者，若配置了多個(gè)，則其他的服務(wù)提供者作為備用服務(wù)。當(dāng)?shù)谝粋€(gè)服務(wù)提供者運(yùn)行壓力較大或調(diào)用失敗時(shí)，總線把請(qǐng)求消息轉(zhuǎn)發(fā)給備用服務(wù)進(jìn)行處理；響應(yīng)主題，不需要在主題配置頁(yè)面中進(jìn)行配置，而是由總線運(yùn)行時(shí)自己維護(hù)。總線接收到請(qǐng)求消息后創(chuàng)建一個(gè)關(guān)聯(lián)到該請(qǐng)求者的響應(yīng)主題。服務(wù)提供者發(fā)回實(shí)際響應(yīng)后，總線根據(jù)該響應(yīng)主題把響應(yīng)消息轉(zhuǎn)發(fā)給請(qǐng)求者；事件主題，配置一個(gè)或多個(gè)訂閱者，經(jīng)過(guò)授權(quán)的應(yīng)用適配器服務(wù)都可以向該事件主題發(fā)布事件消息，總線必須把事件消息成功地交付給該事件主題的每一個(gè)訂閱者。

2.3.2基于主題的消息路由

基于主題的消息路由，主要完成接入信息交互總線的各應(yīng)用適配器間消息的準(zhǔn)確傳輸，實(shí)現(xiàn)把應(yīng)用適配器服務(wù)發(fā)送到總線的IEC61968消息按照主題路由布設(shè)到目標(biāo)應(yīng)用適配器服務(wù)的規(guī)劃調(diào)度過(guò)程?？梢园言撨^(guò)程抽象為一個(gè)三元組。在此，給出三元組中各成員項(xiàng)的功能實(shí)現(xiàn)內(nèi)容分別如下：

1）Message，表示總線接收到的IECT61968消息，消息頭中的名詞和動(dòng)詞元素明確表征了該消息將要發(fā)生關(guān)聯(lián)到總線上的哪個(gè)主題。

2）Repository表示總線的主題庫(kù)，Repository={Topic1， Topic2， …}，Topic表示一個(gè)主題。主題Topic可以抽象為一個(gè)四元組，其中Noun為消息名詞，Verb為消息動(dòng)詞，兩者組合構(gòu)成主題名TopicName，Pattern表示總線的信息交互模式（發(fā)布/訂閱，請(qǐng)求/響應(yīng)），Services表示目標(biāo)適配器服務(wù)列表。

其中，（1）～（3）語(yǔ)句實(shí)現(xiàn)了從總線接收到的消息中解析出主題名；（4）～（7）語(yǔ)句實(shí)現(xiàn)了在主題庫(kù)中迭代解析出的主題名，匹配出消息主題名對(duì)應(yīng)的主題路由規(guī)則，并從中獲取目標(biāo)適配器服務(wù)列表；（8）～（11）語(yǔ)句進(jìn)一步實(shí)現(xiàn)了把消息轉(zhuǎn)發(fā)給目標(biāo)適配器服務(wù)列表中的每一個(gè)適配器服務(wù)。

2.5信息交互模式

信息交互模式，指集成到總線上的應(yīng)用適配器間信息交互的方式，發(fā)布/訂閱與請(qǐng)求/響應(yīng)是兩種基本交互模式。在信息交互模式設(shè)計(jì)中使用了隊(duì)列，進(jìn)入總線的消息先保存到總線的隊(duì)列中，而不是直接路由到目標(biāo)適配器服務(wù)進(jìn)行處理，然后由總線的消息路由后臺(tái)進(jìn)程取出消息完成消息到目標(biāo)適配器服務(wù)的轉(zhuǎn)發(fā)。把消息的接收和消息的處理進(jìn)行分離，能夠減少請(qǐng)求負(fù)載峰值帶來(lái)的過(guò)度資源消耗所導(dǎo)致的系統(tǒng)級(jí)錯(cuò)誤，提高總線的并發(fā)處理能力。

2.5.1 發(fā)布/訂閱

發(fā)布/訂閱模式，是基于事件推送機(jī)制的消息發(fā)布方式，總線依據(jù)事件主題將事件消息分發(fā)給相應(yīng)的訂閱者，如圖4所示。交互過(guò)程可描述為：

1）應(yīng)用適配器A，為事件發(fā)布者，調(diào)用總線的事件發(fā)布接口向總線發(fā)布事件消息；

2）當(dāng)總線收到消息后，首先對(duì)應(yīng)用適配器A進(jìn)行身份認(rèn)證，再?gòu)氖录⒅薪馕龀鲋黝}名驗(yàn)證該主題在總線主題庫(kù)中是否已經(jīng)配置，然后通過(guò)主題授權(quán)庫(kù)確認(rèn)應(yīng)用適配器A是否獲得了該主題的授權(quán)。如果適配身份認(rèn)證失敗、事件發(fā)布到了一個(gè)不存在的主題、或應(yīng)用適配器A沒(méi)有獲得主題的授權(quán)，那么總線將向應(yīng)用適配器A返回一個(gè)包含詳細(xì)錯(cuò)誤信息的錯(cuò)誤消息。如果驗(yàn)證通過(guò)，總線將轉(zhuǎn)發(fā)事件消息到消息隊(duì)列，轉(zhuǎn)發(fā)完成之后向應(yīng)用適配器A返回一個(gè)確認(rèn)消息（事件消息已被總線成功接收），至此應(yīng)用適配器A的事件發(fā)布過(guò)程結(jié)束；

3）總線中的消息路由后臺(tái)進(jìn)程，從隊(duì)列中取出事件消息，并依次轉(zhuǎn)發(fā)給該事件主題的每一個(gè)訂閱者（應(yīng)用適配器B、C），事件訂閱者收到事件消息后各自進(jìn)行事件處理。

2.5.2請(qǐng)求/響應(yīng)

請(qǐng)求/響應(yīng)模式，是總線上應(yīng)用適配器間最常見(jiàn)的信息交互方式。發(fā)起請(qǐng)求的應(yīng)用適配器A為服務(wù)請(qǐng)求者，提供服務(wù)處理的應(yīng)用適配器B為服務(wù)提供者，服務(wù)請(qǐng)求者與服務(wù)提供者并不直接交互，而是只與總線進(jìn)行信息交互。請(qǐng)求/響應(yīng)信息交互模式分為同步和異步兩種。具體地，給出各自分析如下。

同步請(qǐng)求/響應(yīng)，如圖5所示。服務(wù)請(qǐng)求者向總線發(fā)出請(qǐng)求消息后阻塞并等待響應(yīng)，直到服務(wù)提供者處理完請(qǐng)求并通過(guò)總線把處理的結(jié)果原路返回給服務(wù)請(qǐng)求者為止。由于在請(qǐng)求過(guò)程中請(qǐng)求者被阻塞，同步請(qǐng)求/響應(yīng)模式適用于服務(wù)處理時(shí)間較短的業(yè)務(wù)場(chǎng)景。由于IEC61968信息交互總線采用粗粒度業(yè)務(wù)信息，服務(wù)處理時(shí)間多會(huì)較長(zhǎng)，如果讓服務(wù)請(qǐng)求者一直等待則浪費(fèi)系統(tǒng)資源而且有可能導(dǎo)致請(qǐng)求超時(shí)，因此同步請(qǐng)求/響應(yīng)在配電網(wǎng)業(yè)務(wù)集成中并不常用。

異步請(qǐng)求/響應(yīng)模式，如圖6所示。請(qǐng)求過(guò)程和響應(yīng)過(guò)程相互獨(dú)立，請(qǐng)求過(guò)程結(jié)束后，總線路由請(qǐng)求消息到服務(wù)提供者，服務(wù)提供者處理完請(qǐng)求后啟動(dòng)響應(yīng)過(guò)程。在響應(yīng)過(guò)程中響應(yīng)（請(qǐng)求的處理結(jié)果）通過(guò)回調(diào)的方式先返回給總線再返回給服務(wù)請(qǐng)求者，而不是按請(qǐng)求路線原路返回。異步請(qǐng)求/響應(yīng)模式交互過(guò)程的實(shí)現(xiàn)描述可展開(kāi)如下：

1）應(yīng)用適配器A向總線發(fā)送請(qǐng)求消息；

2）總線依次進(jìn)行適配身份認(rèn)證、主題驗(yàn)證、適配器權(quán)限驗(yàn)證過(guò)程，若都順利通過(guò)，則總線向服務(wù)請(qǐng)求者返回確認(rèn)消息，表示總線已成功收到請(qǐng)求消息，否則返回包含詳細(xì)錯(cuò)誤信息的錯(cuò)誤消息；

3）總線中的消息路由后臺(tái)進(jìn)程，從隊(duì)列中取出請(qǐng)求消息，并路由到服務(wù)提供者（應(yīng)用適配器B）；

4）服務(wù)提供者處理完請(qǐng)求后，啟動(dòng)響應(yīng)過(guò)程，服務(wù)提供者先調(diào)用總線的響應(yīng)接口把響應(yīng)消息返回給總線，而后總線再調(diào)用服務(wù)請(qǐng)求者的響應(yīng)接口把響應(yīng)消息返回給服務(wù)請(qǐng)求者。

3總線服務(wù)

總線服務(wù)，是信息交互總線的一個(gè)信息交互接口，在本文中是一個(gè)基于Mule構(gòu)建的Web服務(wù)，調(diào)用了mule的基礎(chǔ)組件和總線功能模塊，向外界推送了可與應(yīng)用適配器交互的請(qǐng)求、響應(yīng)、發(fā)布、建立連接、關(guān)閉連接等現(xiàn)實(shí)服務(wù)細(xì)分的操作接口。

3.1總線服務(wù)接口描述

如圖7所示，使用WSDL（Web Services Description Language）定義了總線服務(wù)的接口。共定義了5個(gè)操作，用于應(yīng)用適配器向總線建立連接的GetConnection操作、斷開(kāi)與總線的連接的CloseConnection操作、向總線發(fā)布事件的Publish操作、向總線發(fā)送請(qǐng)求的Request操作、處理完請(qǐng)求后向總線傳輸異步響應(yīng)的Response操作。

3.2 Mule應(yīng)用架構(gòu)

在Mule應(yīng)用中，流（flow）是最為重要的方法元素，代表一個(gè)特定意義的工作單元。如圖8可見(jiàn)，即是描述了一個(gè)常規(guī)的Mule應(yīng)用架構(gòu)。運(yùn)行Mule應(yīng)用時(shí)，系統(tǒng)在入站端點(diǎn)指定的端口上啟動(dòng)流服務(wù)，外部應(yīng)用向入站端點(diǎn)上發(fā)送消息觸發(fā)流服務(wù)進(jìn)行消息處理，消息在流內(nèi)經(jīng)過(guò)一系列消息處理器的變換實(shí)施處理后，通過(guò)出站端點(diǎn)發(fā)給外部應(yīng)用。在Mule中，消息處理器是一個(gè)已封裝好的功能單元。消息處理器包括連接器（入站端點(diǎn)和出站端點(diǎn)）、業(yè)務(wù)邏輯組件、消息轉(zhuǎn)換器、消息過(guò)濾器等。

3.3總線服務(wù)實(shí)現(xiàn)

AnypointStudio是基于Eclipse定制的Mule集成開(kāi)發(fā)工具，提供了可視化的編程設(shè)計(jì)界面。如圖9所示，則是總線服務(wù)的主流結(jié)構(gòu)。主流服務(wù)通過(guò)HTTP連接器把總線服務(wù)綁定到主機(jī)的一個(gè)端口上，主流啟動(dòng)后在該端口上接收應(yīng)用適配器服務(wù)發(fā)送的消息。當(dāng)消息進(jìn)入主流后，調(diào)用“DOM to XML”消息轉(zhuǎn)換器把消息轉(zhuǎn)換為XML格式，執(zhí)行“Expression”組件抽取消息屬性保存到流變量flowVars中，而后將執(zhí)行“Choice”消息路由器根據(jù)流變量中的屬性值匹配到相應(yīng)的子流進(jìn)行處理；處理完成后，則會(huì)將消息的處理結(jié)果返回給指定的應(yīng)用適配器服務(wù)。

4應(yīng)用

IEC61968標(biāo)準(zhǔn)甫一面世推出后，各電力企業(yè)和系統(tǒng)提供商就在依據(jù)自身對(duì)IEC61968標(biāo)準(zhǔn)的理解相繼研發(fā)構(gòu)建了信息交互總線和IEC61968應(yīng)用程序組件。通常情況下，因其對(duì)標(biāo)準(zhǔn)在理解和執(zhí)行上不可避免地存在一些差異，導(dǎo)致各廠商提供的IEC61968應(yīng)用程序組件使用的數(shù)據(jù)模型并不會(huì)完全一致[5]，即會(huì)使得配電管理領(lǐng)域的各類(lèi)應(yīng)用在信息交互總線上必將無(wú)法實(shí)現(xiàn)預(yù)期中的正常信息交互。針對(duì)該問(wèn)題的主要解決辦法則是在信息交互總線上集成模型校驗(yàn)服務(wù)[6]，各應(yīng)用組件在交互模型數(shù)據(jù)前，就要先請(qǐng)求模型校驗(yàn)服務(wù)校驗(yàn)?zāi)Ｐ蛿?shù)據(jù)的一致性，而后再依據(jù)校驗(yàn)結(jié)果執(zhí)行后續(xù)操作。

如圖10所示，其中給出了一個(gè)集成著模型校驗(yàn)服務(wù)的發(fā)布模型數(shù)據(jù)場(chǎng)景。配電應(yīng)用A（模型數(shù)據(jù)源）通過(guò)應(yīng)用適配器服務(wù)A接入總線，在應(yīng)用適配器服務(wù)A中將會(huì)完成從配電應(yīng)用A中獲取模型數(shù)據(jù)、調(diào)用模型校驗(yàn)服務(wù)驗(yàn)證模型數(shù)據(jù)、向配電應(yīng)用B、C（模型數(shù)據(jù)訂閱者）發(fā)布模型數(shù)據(jù)等功能。交互過(guò)程可做完整描述如下：

1）啟動(dòng)發(fā)布模型數(shù)據(jù)過(guò)程，調(diào)用配電應(yīng)用A的導(dǎo)出模型數(shù)據(jù)模塊獲得模型數(shù)據(jù)，轉(zhuǎn)換標(biāo)準(zhǔn)CIM版本，然后向請(qǐng)求主題發(fā)布模型校驗(yàn)請(qǐng)求；

2）應(yīng)用適配器服務(wù)D收到模型校驗(yàn)請(qǐng)求后，調(diào)用本地的模型校驗(yàn)服務(wù)，而后把校驗(yàn)報(bào)告通過(guò)響應(yīng)主題返回給請(qǐng)求者適配器服務(wù)；

3）應(yīng)用適配器服務(wù)A通過(guò)響應(yīng)主題獲取校驗(yàn)報(bào)告后，解析校驗(yàn)報(bào)告，判斷校驗(yàn)是否通過(guò)：若校驗(yàn)通過(guò)，則向配置的事件主題發(fā)布模型數(shù)據(jù)事件；否則通過(guò)錯(cuò)誤處理模塊把校驗(yàn)報(bào)告發(fā)送給用戶(hù)，由用戶(hù)根據(jù)校驗(yàn)報(bào)告給出的錯(cuò)誤提示修改模型數(shù)據(jù)。

5結(jié)束語(yǔ)

本文提出了一個(gè)基于Mule的IEC61968信息交互總線的功能架構(gòu)，重點(diǎn)對(duì)服務(wù)注冊(cè)中心、適配器身份認(rèn)證、基于主題的消息路由和信息交互模式模塊進(jìn)行了分析和設(shè)計(jì)，同時(shí)又根據(jù)總線服務(wù)接口描述（WSDL）在Mule的集成開(kāi)發(fā)工具AnypointStudio中實(shí)現(xiàn)了總線服務(wù)原型系統(tǒng)，最后在信息交互總線上對(duì)集成模型校驗(yàn)服務(wù)的發(fā)布模型數(shù)據(jù)場(chǎng)景進(jìn)行了應(yīng)用分析，解決了配電應(yīng)用間由于數(shù)據(jù)模型不一致導(dǎo)致的信息交互問(wèn)題，從而為今后其他業(yè)務(wù)場(chǎng)景應(yīng)用集成提供了現(xiàn)實(shí)有益的技術(shù)基礎(chǔ)。

參考文獻(xiàn)：

[1] 謝濤，余鵬，熊翌竹等.基于IEC 61968的配網(wǎng)系統(tǒng)應(yīng)用集成技術(shù)[J].電工技術(shù)，2014，（7）：77-78.

[2] 李傳健，陳炯聰，鄭文杰，等.基于IEC61968標(biāo)準(zhǔn)的配電網(wǎng)管理系統(tǒng)信息集成消息設(shè)計(jì)與實(shí)現(xiàn)[C]//[3] 顧建煒，中國(guó)電機(jī)工程學(xué)會(huì)電力系統(tǒng)自動(dòng)化專(zhuān)業(yè)委員會(huì)2012年學(xué)術(shù)交流會(huì). 廈門(mén)：中國(guó)電機(jī)工程學(xué)會(huì)，2012：44-48.

[3]顧建煒，周志芳.基于IEC61968標(biāo)準(zhǔn)智能電網(wǎng)信息集成的應(yīng)用研究[J].供用電， 2010， 27（5）：19-22.

[4] 陳真理，俞東進(jìn)，劉其群.一個(gè)基于Mule ESB的綜合業(yè)務(wù)處理平臺(tái)的設(shè)計(jì)和實(shí)現(xiàn)[J].計(jì)算機(jī)時(shí)代，2013（8）：8-10.

[5] 嚴(yán)小文，吳小娟，張朝龍，等.基于IEC61968的營(yíng)配一體化系統(tǒng)互操作研究[J].電氣應(yīng)用，2013（S2）：408-412.

[6] 于洋，劉東，陸一鳴，等. 基于本體的IEC61968標(biāo)準(zhǔn)信息模型一致性校驗(yàn)[J].電力系統(tǒng)自動(dòng)化，2012， 36（14）：46-51.