基于Agent 的變電站通信研究

傅軍棟，陳 康，黃揚海

（華東交通大學電氣與電子工程學院，江西 南昌330013）

傳統電力系統中繼電保護存在比較突出的問題，主要表現為：即使在系統運行方式發生變化時，繼電保護的整定值不能跟隨變化，沒有自適應性[1]；保護切除故障是按照本身的保護邏輯動作，保護之間缺乏足夠的配合[2]；保護僅考慮到切除相關設備的故障，沒有考慮到對系統的影響[3]；只是獲取就地信息，沒有獲取充分的全局或局部信息，綜合做出保護動作[4]。 這些問題對繼電保護的可靠性、穩定性、靈敏性等有著嚴重的影響。

人工智能技術對模型的依賴程度較低，且適合于解決非線性和離散型優化問題，依據被廣泛應用于電力系統的各類優化問題中[5]。 以多智能體系統（multi-agent system，MAS）為代表的技術通過協作解決分布式問題的能力受到研究人員的關注。 智能體不僅自身具備解決問題的能力和明確的行為模板，而且智能體之間能夠相互配合，通過協調實現更優化的目標效果[6]。 將智能變電站繼電保護與多智能體技術相結合，實時計算和設置參數，用于改善現有的保護技術。為了能快速切除故障，變電站的線路、母線、變壓器等部分都安裝了保護繼電器，因此，變電站的保護和控制是分布式的。變電站的結構復雜，運行狀態總是動態變化，多智能體技術正是適合運行在這樣的環境中。

在變電站中應用多智能體技術，通信是需要考慮的首要問題。 目前，國外把Agent 技術與IEC 61850 結合的研究，主要有以下幾個方向：在Agent 間通信的FIPA 標準中拓展IEC 61850 中的相關概念[7]；用本體實現IEC 61850 標準和Agent 通信的映射[8]；利用Agent 的定義構建系統，實現分布式控制[9]。

國內在IEC 61850 標準和Agent 技術的結合上做了許多研究。 主要實現方式包括： 使用本體實現IEC 61850 標準和Agent 消息的映射；資源描述框架（resource describtion framework，RDF）實現IEC 61850 和Agent 間的映射；利用Agent 定義，設計IED 設備的邏輯結構。 其中，文獻[10]提出為了解決配電網中設備信息共享和互操作問題，引入了IEC 61850 標準，同時，為了配電網中解決分布式問題應用MAS 系統。將IEC 61850 與MAS 結合起來，需要把標準中定義的信息模型映射到ACL 本體，設備優化問題通過多Agent 系統技術解決，設備跨平臺通信問題通過Web 服務解決。 文獻[11]針對DER 大量接入電網后，配電網故障恢復的控制問題，提出了IEC 61850 的ADN 故障自恢復MAS。 通過代理之間的通信與協商完成故障定位、隔離和供電恢復。 文獻[12]在交直流混合電網中，在多端直流的端子上設置智能體，智能體包含信息獲取模塊和自主決策模塊，通過智能體之間的多智能體與系統間的交互、協調，實現各端換流站間有功功率的合理分配。

文獻[10]和[11]將IEC 61850 中的數據模型和服務映射為ACL 語言的本體元素，使Agent 作為IED 設備的決策機構。 Agent 之間和Agent 與IEC 設備間通信，增加了通信開銷，Agent 的本體與IEC 61850 元素映射并沒有統一標準，本體設計的不合理或不完善，可能會造成通信上的混亂。 文獻[12]利用多智能體理論來設計，添加智能決策模塊，以IEC 61850 標準通信，不能充分利用多智能體的優勢。

目前，國內外的研究主要集中于用多Agent 系統的定義構建系統，而通信方式完全采用Agent 通信或者IEC 61850 標準；通過中間文件，如本體，實現IEC 61850 標準與Agent 通信的映射。 沒有把兩者結合在一起，既利用IEC 61850 模型和通信實現相分離的優點，也可以使用Agent 的自治性、移動性等特性。 本文把IED 設備封裝為Agent，把Agent 通信技術與IEC 61850 結合，利用Agent 獨立自治性和協作性，提高變電站運行的穩定性和可靠性，增強了IEC 61850 的互操作性。

1 Agent 與IEC 61850

1.1 Agent 通信

在JADE 平臺中，每個Agent 都需要從父類jade.core.Agent 類派生，并實現其setup（ ）方法。 每個Agent類必須包含setup（ ）方法，由setup（ ）方法啟動Agent 并完成一些初始化的工作。 通過setup（ ）函數，程序類對應的Agent 可以在AMS 上注冊Agent 名字，格式為＜Agent 稱呼＞@＜IP 地址:端口+”/JADE”＞，Agent 在主容器上創建成功。 如果AMS 已經注冊過這個Agent 名字后，Agent 不能被創建成功，這樣保證了Agent 的命名是唯一的，Agent 發送消息的過程如圖1 所示。

圖1 Agent 發送消息的過程圖Fig.1 The process diagram of Agent message sending

在JADE 平臺上，Agent 之間的通信采用的是ACL 消息，ACL 消息遵循FIPA 標準。在Agent 被成功創建后，要發送ACL 消息，首先應設置好接受者的全局唯一標識符，消息內容，內容語言等。 然后，消息封裝層把ACL 消息封裝為有效負載payload 后，加入到消息的傳輸隊列。 最后，根據Agent 傳輸消息的底層協議，如HTTP，TCP/IP 等，對消息進行編碼發送。

以上是客戶端的Agent 創建和信息發送過程，服務端Agent 創建過程和客戶端一樣。 服務端Agent 創建后，需要創建消息模板（設定發送者、通信動作等），對收到的消息進行選擇性的接受，也可以發送消息給客戶端，之后，服務器繼續等待接收消息。 客戶端可以設置消息模板對消息選擇性的接收[13]。

1.2 IEC61850 的MMS 通信服務

IEC61850 協議中，核心的服務是MMS 服務（manufacturing message specification，MMS）。 如圖2 所示為MMS 服務的通信過程圖。

圖2 MMS 服務的通信過程圖Fig.2 The communication process of MMS service

左側為客戶端，右側為服務器。 客戶端設置套接字Socket 的參數為服務器的IP 地址和端口Port，服務器以端口Port 為參數，創建Socket，監聽到客戶端的連接請求后，建立連接。 客戶端有兩種獲取服務端的SCL 模型文件方式：離線和在線。 獲取到SCL 模型后，以Java 語言為基礎，利用JDOM 方式實現對SCL 文檔的解析，將SCL 文檔以節點樹的形式顯示出來[14]。 離線方式是直接得到存儲在本地的SCL 文件，接著對SCL模型進行解析；在線方式是通過發送讀目錄的ACSI 服務給服務器，服務器返回自身SCL 模型。 根據數據模型， 得到含路徑名和功能約束參數的對象， 將對象和ACSI 服務映射為MMS 對象和服務。 MMS 編碼采用ASN.1 的基本編碼規則（basic encoding rules，BER），對得到的MMS 的域、變量、數據類型、服務等進行編碼。MMS 服務底層使用TCP/IP 協議，用Socket 輸出流把編碼數據發送出去。

服務端在建立連接后，一直等待接收輸入流的數據。 對接收的數據，進行BER 方式解碼后，轉為MMS對象和服務，最后，映射為含有路徑名和功能約束的對象，以及ACSI 服務。 當需要反饋數據時，服務端可以把含路徑名和功能約束的對象，經過MMS 映射和BER 編碼后，發送給客戶端。

1.3 Agent 與IEC 61850 結合的理論分析

基于IEC 61850 協議，智能變電站把物理設備的具體功能抽象為邏輯節點（logical node，LN），根據具體需求劃分邏輯節點在不同的邏輯設備（logical device，LD）中，邏輯設備屬于智能電子設備（intelligent electronic device，IED），智能電子設備就是對應物理設備數據模型和服務的集合體。

IEC 61850 的通信協議確定了四種通信服務，即制造報文規范（MMS），通用變電站對象事件（GOOSE）/采樣（SV），通用變電站事件模型（GSSE）和時鐘同步（SNTP）。 MMS 服務的底層是依靠TCP/IP 協議實現的，在利用MMS 服務進行通信時，需要先對指定端口和IP 地址進行Socket 連接，然后，使用讀寫數據值，讀目錄等ACSI 服務時，輸入參數應該是路徑名唯一，即智能電子設備名，邏輯設備名，邏輯節點名，數據對象名，數據屬性名這個從上到下的樹形結構，在根節點名唯一，根節點下子節點名字唯一，依次類推。 這樣可以確定每次通信對象是否正確，避免在通信過程中，向錯誤的對象請求數據或發布控制命令。 在變電站內部通信或不同變電站通信時，設備進行配置前，要保證配置文件滿足上述需求。

多Agent 系統中不需要考慮上面的問題，由于在創建Agent 的時候，每個Agent 的名字在環境中必須是唯一的，否則，不能被創建。 而且即使Agent 被轉移到其他地方，也能被其他Agent 辨識出來，對于IED 設備來說，并不需要重新更改和交換配置信息，加強了互操作性。Agent 通信時，只需要知道對方的全局唯一標識符（globally unique identifier，GUID），就可以與對方通信。MMS 服務通過TCP/IP 協議通信時，首先，需要進行三次握手建立連接，直接發送信息即可；建立Socket 連接后，長時間不發信息，要發送心跳包，保持連接；Socket 結束通信時，要四次握手斷開連接，不然會導致數據傳輸錯誤，Socket 不能關閉而報錯。 Agent 通信時，不需要建立連接，保持或斷開連接，在要發送信息時，只要確認對方的全局唯一標識符就可以發送消息。這樣Agent 通信時，減小了通信所需時間，增強了通信的穩定性。

在智能變電站中，各保護設備、檢測單元和控制執行等設備組成的繼電保護系統，在結構上是分布離散的，很多時候解決繼電保護問題是分布式的問題。 多Agent 系統與此類似，把分布的設備作為Agent，利用Agent 的協作，來求解分布式的問題，完成繼電保護的檢測、分析、判斷、動作過程，迅速和有選擇性的切除故障，使系統穩定運行，提高可靠性。 同時，把相關的算法和保護方案加入多Agent 系統，提高保護方法的性能[15]。

2 Agent 與IEC 61850 的結合

2.1 IEC61850 中的MMS 服務實現過程

制造報文規范（MMS）是應用層的協議，通過對實際設備在邏輯上建立模型，解決了不同廠家生產的IED 設備的互操作性問題。在IEC 61850-7 部分提供了，IEC 61850 中的信息模型和ACSI 服務到MMS 協議的具體映射。 IEC 61850 實現到MMS 的映射，有兩種方式：應用框架和傳輸框架。 現在，TCP/IP 協議已經在LAN/WAN 得到了廣泛的應用，成為事實上的標準，因此，本文實現是IEC 61850 到MMS 的映射，采用的是MMS 基于TCP/IP 的以太網通信模型。 下面是具體的實現過程。

首先通過解析ICD 文件保存在serverModel 類中，從本地獲取的方式代碼為：ServerModel serverModel =clientAssociation.getModelFromSclFile(“src/test/resources/testmm.icd”)，獲取的模型信息全面且可以永久保存。

在線獲取的方式代碼為：ServerModel serverModel = clientAssociation.retrieveModel（ ）。通過ACSI 服務讀取服務器的各層的信息模型，獲取信息不全且只能暫時保存，

獲取到SCL 模型后，使用下面程序：

BdaFloat32 amp1 =(BdaFloat32) serverModel.findModelNode("IC011/phsTCTR1.Amp.instMag.f", Fc.MX)；

clientAssociation.getDataValues(amp1)；

先把數據屬性的路徑和功能約束作為輸入參數，建立對應對象。 在ClientAssociation 類中，通過以下程序：

ConfirmedServiceRequest serviceRequest=constructGetDataValuesRequest(modelNode)；

ConfirmedServiceResponse = encodeWriteReadDecode(serviceRequest)；

decodeGetDataValuesResponse(confirmedServiceResponse, modelNode)；

先把前面建立對象作為輸入參數， 轉為MMS 的BER 編碼的數據結構， 將其解析為MMS 的讀數據請求。再對MMS 讀請求進行編碼，轉為MMSpdu 數據，存在BerByteArrayOutputStream 中，AcseAssociation 類的send (ByteBuffer) 和receive (ByteBuffer) 發送和接受MMSpcu 數據單元。 下面是AcseAssociation 類的send(ByteBuffer)方法內容：

encodePresentationLayer(payload, ssduList, ssduOffsets, ssduLengths)；

encodeSessionLayer(ssduList, ssduOffsets, ssduLengths)；

把MMSpdu 數據單元進行表示層和會話層的編碼，再通過底層協議發送數據。

2.2 Agent 與IEC 61850 結合的過程分析與實現

Agent 之間通信使用的是基于FIPA 協議的語言。 JADE 為了方便Agent 之間交互，提供了一些框架，如協商，拍賣，任務代理等。 把Agent 技術與IEC 61850 結合目的是把IED 設備封裝為Agent，使多Agent 系統的分布性、協作性等滿足變電站的需要，同時，在IED 設備中實現了Agent 的優勢。 在各IED 設備組成的多Agent 系統中，Agent 之間處于平等地位，Agent 根據自身的行為程序實現自治。后文的輪詢Agent 協調Agent之間的通信，當自身不能滿足需求時，通過輪詢Agent 與其他Agent 通信，共享自身的信息，獲取區域或全局信息， 經過決策分析， 給相關Agent 發送控制命令或參數。 Agent 管理平臺參考模型如圖3 所示。 它包括Agent 管理系統（agent management system，AMS）、目錄服務（directory facilitator，DF）和信息傳輸服務（message transport service，MTS），所有這三個組成都在Agent 平臺啟動時自動激活。 當把IED 設備封裝為Agent，就可以與Agent 一樣，當Agent 的AID（agent identifier）的標識符為唯一時，在創建時即可在AMS 上注冊。此時，其他Agent 就可以通過DF 服務發現這個Agent。 由于Agent 通信只需要確定對方的AID 標識即可，因此，當設備檢修或更新信息后，用原來AID 注冊，就可以被其他Agent 識別并可以互相通信，這增強了IEC 61850 的互操作性。

圖3 Agent 管理平臺參考模型圖Fig.3 Reference model diagram of Agent management platform

如圖4 所示，為Agent 與IEC 61850 結合的通信流程圖。 首先通過SetUp（ ）方法創建Agent，在AMS 上創建成功后，就可以把IED 設備封裝為Agent，Agent 之間通過GUID 確定通信對象。 因此，把IED 設備封裝為Agent 后，ICD 文件不需要重新配置，即可由GUID 確定對象，增強了設備間的“互操作性”。 AID 標識符可以唯一確定Agent，在IEC 61850 中，許多設備可能處于同一地址中，對這些設備進行操作時，需要客戶端對服務器Socket 連接，相同地址處不同設備對客戶端來說無法區分，每一次對服務器設備進行操作，都需要指明具體的哪個IED 設備，IED 設備的具體邏輯節點，這影響了IEC 61850 的互操作性。 而Agent 的標識符是唯一確定的，將Agent 接入到一個新的地址，能被唯一識別，將Agent 通信技術與IEC61850 結合起來，可以增強IEC 61850 的“即插即用”的特性。

圖4 Agent 與IEC61850 結合的通信流程圖Fig.4 The combined communication flow diagram of Agent and IEC61850

然后，添加Agent 的行為（Agent 如何動作），獲取到通信對象的SCL 模型文件，根據SCL 模型，得到包含路徑名和功能約束等參數的對象，把這個對象和ACSI 服務映射為MMS 對象和服務，再經過BER 編碼后得到數據，數據的傳輸主要是依靠Agent 之間ACL 消息的發送和接收。 根據FIPA 標準，設置ACL 消息參數，把經過MMS 協議映射及采用BER 編碼的數據，作為消息內容，設置好接受者的標識符和通信動作。 最后，通過輪詢者確定是否可以通信，如果是由于在不同局域網，可以轉發信息給BridgeAgent，用它實現ACL 消息和TCP/IP 協議之間轉換，通過Socket 流把數據發送過去。 輪詢者對服務器通信，確定服務器狀態，判斷是否客戶端是否可以連接，發送反饋信息給客戶端。根據接收到的反饋信息判斷，Agent 行為是否執行完畢，否則重新發送信息，行為執行完，結束運行。

本設計是在IEC 61850 的MMS 服務的基礎上與JADE 平臺的Agent 通信相結合，創建所需的服務器和客戶端。

圖5 客戶端Agent 通信程序執行圖Fig.5 Client Agent communication program execution diagram

如圖5 為客戶端Agent 通信程序執行圖。 通過ClientAgent 類的SetUp 方法啟動Agent，在AMS 上注冊。調用ClientSap 類的associate 方法，其中傳遞參數客戶端和服務器的Agent 名字。 調用AcseAssociation 類的startAssociation 和startSConnection 方法，把應用層和會話層的連接請求數據放在緩存器里，調用ClientTSap的connectTo 方法創建TConnection 類的實例，在TConnection 類中，使用senoperate 方法，給輪詢Agent 發送信息，確認服務端Agent 的狀態可以通信后，用send（ ）方法把緩存器的數據發送給服務端Agent，receive（ ）方法接受返回數據。

通過ClientAssociation 類的getModelFromSclFile 方法， 將指定路徑的SCL 文件以DOM 方式進行解析，返回服務器的模型，存在ServerModel 類中。 將對需要操作的數據對象的路徑名和功能約束作為參數，調用ServerModel 的findModelNode 方法生成對應類的實例。 如果ACSI 服務是讀目錄或讀數據值， 調用ClientAssociation 類的constructGetDataValuesRequest 方法， 把對應的類的參數和ACSI 服務映射到MMS 對象和服務，用encodeWriteReadDecode 方法把MMS 請求經過BER 編碼后，調用acseAssociation 類的send（ ）方法發送給服務器， 以及用receive （ ） 方法接受服務器的反饋信息， 調用ClientAssociation 類的decodeGet-DataValuesResponse 方法，把接受的數據，經BER 解碼和MMS 映射，存儲在模型中。 圖6 為服務器的Agent通信程序執行圖。 Agent 啟動后，調用ClientServerITest 類的runServer（ ）方法，通過ServerSap 類的getSaps-FromSclFile 方法，把自身的SCL 模型解析并保存在ServerModel 類中。 調用ConnectionHandler 類的operate（ ）方法，執行TConnection（ ）類的senoperate（ ）方法，一直阻塞性的等待接收消息，通過輪詢者傳送信息，確定通信對象的名字。 調用AcseAssociation 類的listenForCn 方法，對客戶Agent 發送的應用層和會話層連接數據作出響應。 在ServerAssociation 類中，執行handleNewAssociation 方法，一直接受ACL 信息，用handle-Connection（ ）方法解析ACL 消息為ACSI 服務和IEC61850 對象，對服務請求用sendAnMmsPdu 方法把響應數據發送客戶Agent，之后重新運行handleConnection（ ）方法，進行監聽。

圖6 服務端Agent 通信程序執行圖Fig.6 Server Agent communication program execution diagram

在Agent 類中，需要確定自身的名字，下面是設置名字和地址的過程。 ACL 消息需要首先初始化，設置ACL 消息的通信動作。Agent 發送消息，要知道對方的IP 地址和port 端口，使用AID 類設置Agent 的名稱和地址，使用該類的構造方法設置接收方的名稱，使用addAddresses()方法設置接收方的地址，即

ACLMessage acl = new ACLMessage(ACLMessage.INFORM);//初始化ACL 消息

AID dest = new AID(“IC01@192.168.43.86:1099/JADE”)；//設置名稱

dest.addAddresses(“http:// 192.168.43.86:7778/acc”)；//設置地址

acl.addReceiver(dest)；//設置接受者

發送者默認為創建的Agent 名字，或者指定接受者，即acl.setSender(dest)。

從ACSI 對象和服務采用MMS 協議，編碼方式采用ANS.1，后面的傳輸用Agent 方式發送編碼。 相對于MMS 協議映射后，用Socket 方式傳輸，Agent 直接發送映射后的編碼，對方無法識別。 對于編碼后的字節數組byte[ ]，使用緩存器的這個方法ByteBuffer.put（byte[ ] src, int offset, int length)，先把編碼存在緩存器中中，ByteBuffer.flip（ ）把緩存器位置置位0，用方法ByteBuffer.get(byte[ ] dst, int offset, int length)把緩存器內容存在數組中，再轉為字符串，用方法ACLMessage.setContent(String content)把字符串存在內容中，發送出去。

2.3 通過Agent 對IEC61850 消息進行過濾的實現

Agent 通信時，只要知道對方Agent 的名字和地址，就能直接發送消息給對方。 當Agent 使用receive（ ）方法時，能接受到所有發給自己的信息，并沒有對發送者或者內容篩選，如果在和其他Agent 通信過程中，還有Agent 對它發送消息，有可能會接受不到原有通信對象的消息，甚至會使Agent 做出錯誤的判斷。 因此，Agent 接收消息時，為了對通信對象發送的消息有選擇性，需要對消息的發送者或者消息內容進行篩選。

每次發送的消息內容不是相同的，只能對通信的發送方進行篩選，接收消息時使用數據類型模板，即方法MessageTemplate.MatchSender(AID aid)，以此得到相應的模板，再使用Agent.blockingReceive(mt)方法來接受特定發送對象發送的消息。

2.4 基于Agent 的IEC61850 IED 設備間通信機制

Agent 之間的協作性和協調性，加強了多Agent 系統解決復雜問題的能力，而且把任務分解，有效的解決的分布式問題，提高系統的靈活性。 對于單個對象之間的通信，Agent 直接給對方發送消息就能實現通信的過程。當多個Agent 之間交換信息時，要把接收的信息和發送者進行對應，回應時還要確定接收者，可能會造成混亂。 使用輪詢機制可以有效避免這個問題，還可以查詢每個Agent 的狀態，及時發現有故障的Agent。

在通信系統中，采用輪詢方式，把輪詢者設計成一個Agent 來與其他Agent 交換信息。 如上圖3-5，是輪詢Agent 與其他Agent 的通信過程。 在用Agent 方式通信時，輪詢Agent 詢問每個Agent 是否需要通信，會發詢問信息，如果不需要通信，則回復確認；如果需要通信，則回復服務端的名字，輪詢Agent 先查詢服務端是否能通信，發送給服務端內容為客戶端名字，然后，服務端回復客戶端名字，表示確認收到，輪詢Agent 再把服務端名字發送給客戶端，最后，服務端和客戶端相互通信。 這樣客戶端得到確認回復，服務端知道與之通信的客戶端名字，并且不會造成服務端與其他Agent 通信時，致使客戶端發送消息得不到回復。

在數據庫中，存著每個Agent 的通信狀態，采用Agent 默認通信方式的狀態：空閑為0，請求通信為1，通信中為2，采用TCP/IP 傳輸信息的狀態：空閑為3，請求通信為4，通信中為5，故障狀態都為6。輪詢Agent 在與其他Agent 通信時，可以確定每個Agent 的狀態，即空閑，需要通信，正在通信，故障，把相應的狀態編號存在數據庫表中，每次通信時根據對方狀態更新數據，通信時直接查詢狀態就能判斷是否需要去聯系，對于通信中狀態Agent，也需要輪詢，及時確定狀態。 對于請求通信的Agent，直接把接受者名字存下來，當接收者為空閑時，再發送給它，減少重復詢問請求通信Agent 的時間。 當輪詢Agent 在及幾輪的輪詢過程中，詢問得不到回答時，會判斷這個Agent 可能處于故障狀態，通知檢修。

2.5 TCP/IP 在智能變電站中Agent 的通信實現

目前，Socket 是使用最廣泛的傳輸層的應用編程接口，在不同應用程序之間通信效率是比較高效的。 在IEC 61850 中， 客戶端和服務器之間通信就是采用的TCP/IP 協議進行通信。 在局域網中Agent 通信穩定可靠，面對不同局域網時，Agent 通信并不能實現，此時，需要在交互的過程中使用TCP/IP 協議。 Agent 之間通信是基于FIPA 規范的，可以通過一個中間Agent 接收Agent 的ACL 消息，寫入到輸出流中，發送給對方，同時也可以從輸入流里接收消息，再以Agent 的ACL 消息形式轉發給目標Agent。

中間Agent 接收ACL 消息，把消息轉為字符串發送到流中，監聽socket，接收流中的數據，轉為ACL 消息發送。 通過PrintWriter pw = new PrintWriter(socket.getOutputStream( ))；pw.write(msg.toString( ))，其中msg 為ACL 消息可以將Agent 消息寫到輸出流中，接收端在指定端口進行監聽。 通過ACL 解析器，可以將ACL 消息從輸入流中解析出來， 再ACL 消息進行具體操作，ACLParser parser = new ACLParser(BufferedReader(newInputStreamReader(socket.getInputStream( )))。

在不同變電站通信時，即不同局域網通信時，相互之間不能直接通信，此時，上述的基于TCP 傳輸協議的Agent 就可以作為橋接Agent， 一直等待接收局域網內Agent 發送消息， 將接收到的消息通過TCP/IP 傳輸，或者接收TCP/IP 上信息轉發給同一局域網內其他Agent。

3 結論

為了在基于IEC61850 標準的變電站中利用MAS 系統的分布式控制能力， 提出了將IEC61850 標準與Agent 相結合的通信方式，從而把IED 設備封裝為多智能體，同時，也增強了設備間的互操作性。

將IEC61850 標準與Agent 結合后，只需要確定對方名字即可實現通信，不需要在通信前進行連接或通信結束后斷開連接，并且Agent 的AID 標識確定通信對象，忽略了IED 設備間的不同之處，增強了設備的互操作性。 使用輪詢Agent 有效解決了多個Agent 之間通信，信息混亂的情況。 依靠中間Agent 實現的Agent通信方式和TCP/IP 通信的轉換，在未來變電站間協調控制也會有重要作用。