張雙悅，王 紅，楊士元，胡 喜

（1.清華大學 自動化系，北京 100084；2.西門子（中國）研究院，北京 100080）

0 引言

隨著智能電網(wǎng)技術的發(fā)展，國內的變電站數(shù)字化工作正在迅速發(fā)展中[1-2]。IEC61850系列標準是由國際電工委員會57號技術委員會（IEC TC 57）所制定的、面向變電站相關網(wǎng)絡通信需求的標準。IEC61850標準中定義了設備抽象通信服務接口（ACSI），并通過具體通信服務映射SCSM（Specific Communication Service Mapping）將其中抽象數(shù)據(jù)結構及大部分抽象服務都映射到制造報文規(guī)范MMS（Manufacturing Message Specification）來進行實現(xiàn)，使得MMS協(xié)議成為智能設備設計中的一個技術關鍵。

由于MMS并不能完備地提供IEC61850標準所需要的數(shù)據(jù)類型和服務功能，在SCSM中存在著不少定義模糊甚至映射偏差的現(xiàn)象，很可能出現(xiàn)使用者對標準的理解不一致的情況。國家電力調度通信中心曾經(jīng)組織開展互操作實驗，結果并不是很理想[3]。

目前IEC61850標準的通信系統(tǒng)的實現(xiàn)得到了廣泛關注，但在工程中大多是直接使用第三方開發(fā)工具。在第三方開發(fā)工具中已對SCSM進行了封裝，使設計者不再需要考慮上述問題。然而隨著變電站設備的專用性越來越強，在一些應用場合需要對標準進行裁剪和簡化實現(xiàn)，在這種需求下，由于第三方開發(fā)工具帶來的種種限制，需要在通用平臺上進行開發(fā)。

對于上述問題，之前的研究大多著眼于如何成功完成映射[4-7]，而對映射過程中產(chǎn)生的偏差和矛盾的研究并不多。為盡量保證設備的互操縱性，之前一般都是使用完備、高兼容性的開發(fā)方案，但這也帶來了一定的冗余和浪費。同時，在目前的一些方案中，還存在著與IEC61850標準要求不太一致的地方。

本文在使用MMS實現(xiàn)IEC61850服務的過程中，就偏差和矛盾比較突出的設備數(shù)據(jù)結構、目錄服務及數(shù)據(jù)讀取服務三方面出現(xiàn)的問題進行分析，提出既滿足相關標準要求、又能有效地減小資源浪費的開發(fā)方案，在此基礎上使用C語言實現(xiàn)了一個基于MMS的IEC61850服務器模型，并完成與第三方客戶端軟件的通信。

1 設備數(shù)據(jù)結構模型的實現(xiàn)

在IEC61850中定義了ACSI用于設備數(shù)據(jù)結構和服務的建模[8-9]，然后根據(jù)標準中定義的SCSM將這些抽象模型使用 MMS 數(shù)據(jù)結構[10]及服務[11]進行具體的實現(xiàn)[12]。

ACSI中定義了5層數(shù)據(jù)結構模型：SERVER、LD（Logical Device）、LN（Logical Node）、DATA 和CB（Control Block）、DA（Data Attribute）和 CBA（CB 屬性），其中DATA和DA存在由自嵌套產(chǎn)生的層內再次分層的現(xiàn)象。

如圖1所示，只有3種MMS數(shù)據(jù)類型被用在設備數(shù)據(jù)結構中：SERVER被映射到 VMD（Virtual Manufacturing Device），LD 被映射到 Domain，而 LN以及其中所包含的DATA、DA、CB和CBA全部被映射到一系列有嵌套關系的NV（Named Variable）。根據(jù)IEC61850-8-1中的描述，只有LN、DA和CB被映射為NV，但同樣據(jù)其所述在具體映射過程中包含了2次映射：第一次映射先將LN映射為獨立的NV，根據(jù)拓撲結構的映射關系將該LN之中所有DATA及其DA、CB及其屬性映射為該LN的相互之間具有嵌套關系的組件；第二次映射將上述LN所映射的NV及其中所有組件映射到其所屬Domain中的一組平等關系的NV。所以原本在MMS定義中不具有自嵌套關系的NV類型實際上被當作一個自嵌套的數(shù)據(jù)結構使用，且DA和CBA也被映射為NV?？芍粋€LN的數(shù)據(jù)結構被映射為一棵NV樹。

圖1 ACSI數(shù)據(jù)結構模型的映射Fig.1 Mapping of ACSI data structure

在ACSI中，每個DA實例都有一個確定的功能約束（FC），一個帶有FC的DA被稱為FCDA，與之類似每個CBA也都有一個確定的FC，并且同一個CB的所有屬性FC相同。

FC表征了某個數(shù)據(jù)實例可以支持的服務類型，用于對外部訪問的控制，對于CB而言其屬性FC同時表征了該控制模塊的類型。

由于FC在外部通信服務處理中的重要作用，所以其在映射后的數(shù)據(jù)結構中非常重要。如圖2所示，將DATA中所有FC相同的DA組成一個FCD，CB直接作為一個FCD，然后一個LN中所有FC相同的FCD組織在一起作為LN的一個成員，根據(jù)LNFC-FCD-FCDA的拓撲關系在NV樹中組織數(shù)據(jù)。

圖2 ACSI和MMS數(shù)據(jù)拓撲結構的差異Fig.2 Difference of data topology between ACSI and MMS

在NV樹中，所有的LN、FC、FCD和FCDA是同等地位的變量，每個節(jié)點用構成方式為LNFCFCDFCDA的字串作為名字被MMS服務用作節(jié)點的訪問，節(jié)點在映射前的具體類型在映射過程中被消除。

由于MMS的拓撲結構和ACSI的拓撲結構并不一致，所以在數(shù)據(jù)結構的實現(xiàn)中，至少存在完全基于MMS、完全基于ACSI、混合模式及冗余模式這4類數(shù)據(jù)結構的實現(xiàn)方式[13]。

在完全基于MMS的模式中，樹形數(shù)據(jù)結構的最上層是VMD，第2層是Domain，下面每層都是NV。該結構便于MMS服務對其進行成員的定位，卻完全破壞了ACSI的拓撲結構。根據(jù)ACSI規(guī)范，在沒有FC的條件下訪問DATA需要忽略第2層NV直接對第3層進行訪問，原本的一個DATA被拆成了若干FCD來進行訪問，會增加搜索開銷。文獻[13]在此基礎上進行了一些改進，但仍使用MMS的數(shù)據(jù)拓撲結構，將多層NV根據(jù)實際ACSI含義進行單獨的類型定義以體現(xiàn)層間的區(qū)別，沒有本質上的變化。

完全基于ACSI的模式利于設備內部系統(tǒng)的訪問，但是該結構中缺少FC。一個簡單的處理方式就是文獻[14]中提出的ACSI-FC混合模式，除了基本信息外，每個DA再添加一個FC信息，在通過MMS的拓撲結構訪問FCD時需要遍歷該DATA的所有DA，然后對葉節(jié)點根據(jù)FC進行過濾。訪問時必須遍歷所有DA才能確定某個FC在LN或DATA中是否存在。文獻[15]的解決方法則是在LN和DATA中添加一個FC列表來記錄其所包含的FC類型。

本文使用基于ACSI的混合模式，如圖3所示。因為設備的內部智能系統(tǒng)與數(shù)據(jù)結構聯(lián)系更加緊密，數(shù)據(jù)組織的邏輯性也更好。

圖3 基于ACSI拓撲的數(shù)據(jù)結構設計Fig.3 Data structure design based on ACSI topology

由于DATA和DA都有復合的情況，且CB數(shù)據(jù)結構與它們相近，所以統(tǒng)一建模為IedData類型。IedData 類型是一個｛Name，F(xiàn)C，Type，Len，Value｝的五元組。Type除了用于NV樹葉節(jié)點的基本數(shù)據(jù)類型外，還包含了DATA、復合DA、CB等類型用于非葉節(jié)點；FC是這個節(jié)點的FC標識；Len在不同的類型中含義不同；Value是一個union類型，根據(jù)Type來確定被使用的是哪一個成員。使用這種方式的優(yōu)勢在于，LN之下的DATA、CB及其屬性的數(shù)據(jù)結構建立、搜索和訪問在程序實現(xiàn)可以統(tǒng)一進行。而對于SERVER、LD和LN都單獨建立數(shù)據(jù)結構模型，IedLogicalNode同樣用一個FC標識來表示LN的數(shù)據(jù)類型中的FC類型。圖4為使用IedData類型建立的DATA對象實例。

使用基于ACSI的模式時，最關鍵的問題是如何進行FC的實現(xiàn)。文獻[15]中使用鏈表來存儲FC，但存儲和搜索的開銷都會比較大，本文在此基礎上進行了改進。

由于一共只有17種FC，所以使用一個UINT32中的二進制位權來表示FC：每個單獨的FC標識都是一個2n的數(shù)值且n的取值不同，那么一個LN或DATA的FC標識只需用其所有成員的FC標識進行位或操作即可很方便地得到。

圖4 使用IedData類型建立的DATA對象實例Fig.4 Example of object constructed with IedData

而在對樹形數(shù)據(jù)結構進行搜索或遍歷時，如果有確定的一個或多個FC限制，則將它們進行位或操作后得到一個“過濾器”，與結構樹中每個節(jié)點的FC進行位與操作，如果結果為零則跳過這一節(jié)點。如果沒有FC限制，則使用0xFFFFFFFF進行搜索即可。在設備互操作需求的不斷發(fā)展中可能會出現(xiàn)對若干個FC同時進行訪問的情況，這種方式將會明顯比使用FC列表的方式更便捷。

在各種FC中，控制對象（CO）和SP（設定值）處理起來比較麻煩。

SP可能出現(xiàn)在CB中也可能出現(xiàn)在DATA中，而在標準中這2種情況的外部訪問限制并不相同，所以使用2個不同的FC值來標記：CB及其屬性為SPb，DATA或DA為SPd。以FC=SP為條件搜索時用上述2個FC值的位或結果作為“過濾器”，同時對它們進行搜索，將這個“過濾器”與當前IedData節(jié)點的FC值進行位與即可得到唯一的FC值。

控制對象特定用于ACSI控制服務，允許目錄而不允許讀取，結構固定，內部系統(tǒng)也沒有讀取的需要，所以在開發(fā)過程中選擇不實現(xiàn)控制對象，只進行FC值的標記以表示這個DATA包含控制對象，在目錄服務中對其FC進行特殊處理。

由于映射中數(shù)據(jù)類型及拓撲結構的變化，再加上服務功能本身的一些限制，導致在服務的映射中會出現(xiàn)偏差甚至矛盾，在目錄和數(shù)值讀取服務上表現(xiàn)的最為嚴重，下面將對其具體實現(xiàn)進行分析。

2 兩級目錄服務的實現(xiàn)

ACSI對5層數(shù)據(jù)結構模型中的上面4層都定義了目錄服務，用于獲取各節(jié)點包含的下一層節(jié)點信息。而在SCSM中，這一系列服務只映射為2種MMS服務。由于不同層上的服務被映射成同一種服務，加之數(shù)據(jù)組織拓撲結構的變化，在服務的實現(xiàn)中存在著一些矛盾[16]。

目錄服務映射關系如表1所示。在MMS中，GetNameList請求的參數(shù)包括特定類型和數(shù)據(jù)類型，結合設備數(shù)據(jù)結構的特點，只有部分請求參數(shù)有對應的ACSI含義，對于其他請求情況可以回復服務錯誤或者根據(jù)實際情況進行回復。通過GetNameList（Domain，VMD-specific）實現(xiàn) GetServerDirectory 時，服務的功能在映射時沒有出現(xiàn)改變，但是對于5層數(shù)據(jù)結構中下面4層的目錄服務會出現(xiàn)一些問題。GetNameList（NV，Domain-specific）服務可以獲取一個Domain中的所有NV對象的名字，即在ACSI中所提出的分類型、分層次的目錄獲取實際上是同時進行的；此外，由于FCDA也被當作NV來處理，按照MMS其也會被包含在獲取結果中，但是按照ACSI規(guī)范則屬于無效信息。

表1 目錄服務映射關系Tab.1 Mapping of directory service

在MMS中，GetVariableAccessAttribute用于NV對象的類型定義，在返回的完整結構的樹形類型定義描述中，每個節(jié)點都包含了其名字，即該服務一次性返回2個ACSI服務原型所需要的結果。此外，在ACSI規(guī)范中，被獲取對象只要求返回最高層子節(jié)點的信息，而被請求被限制為FCD和FCDA。

在目錄服務的映射過程中，共同點是MMS服務覆蓋了ACSI服務的需求，但有可能超出ACSI范圍的功能，或者返回多余的ACSI所請求的信息。同時，映射之后的2層服務的覆蓋范圍之間存在著重疊。

根據(jù)MMS，僅使用單一的GetNameList請求即可獲得除葉節(jié)點的數(shù)據(jù)類型外的完整設備結構，但是根據(jù)這個服務的返回結果進行數(shù)據(jù)結構重建的單位工作量和總工作量都很大，通?？蛻舳思词公@取了全部的名字，仍然需對其進行過濾來選取需要的部分，而之后如果需要下層數(shù)據(jù)結構則再次發(fā)送GetVariableAccessAttribute請求，如SIEMENS公司的IEC Browser對收到的名字列表過濾到頂層FCD，而OMICRON公司的IEDScout則過濾到LN。ACSI樹形數(shù)據(jù)結構的特點導致被過濾的無效信息占據(jù)了大部分返回結果。這些無效信息的傳輸浪費了一定的網(wǎng)絡帶寬，而且即使目錄服務并不被頻繁調用，在服務器端也需要為目錄服務的響應提供更多的資源，如目錄列表的存儲空間等。

基于客戶端的上述應用特性，服務器實現(xiàn)時可以不依循MMS，而主動對名字列表進行過濾，只發(fā)送其中位于樹形結構上部的部分[16]。但是使用這種方法后，如果客戶端不接受服務器的主動過濾，可能會出現(xiàn)互操作性問題。

雖然進行主動過濾并不滿足MMS，但是根據(jù)ACSI的服務規(guī)范，服務器是可以進行主動過濾的。由于所實現(xiàn)的是基于IEC61850標準的通信系統(tǒng)，雖然適應性可能會降低，但MMS只是實現(xiàn)ACSI的一個工具，進行主動過濾仍然是一種合理的選擇。主動過濾后，只要服務器能夠對兩級目錄服務覆蓋整個數(shù)據(jù)結構，那么整個目錄服務就是完備的。

如果依循 ACSI規(guī)范，GetLogicalNodeDirectory所返回的最小單元應該是DATA，但在真實的數(shù)據(jù)結構中沒有這一層，那么這個過濾的分界線可以選擇FCD（保留 3～4層 NV）、頂層 FCD（保留 3層 NV）或者 FC（保留 2層 NV）。

如果只考慮服務器端，為了較高的兼容性，可以選擇過濾到FCD。如果同時考慮通信雙方，一種比較理想的實現(xiàn)方式如圖5所示?？蛻舳司哂幸欢ǖ淖儎有裕谑褂肎etNameList獲取上層目錄結構后，根據(jù)服務器端的返回結果來選擇合適的GetVariableAccessAttribute獲取下層目錄結構，使得兩級目錄服務沒有交疊的部分或盡量減小交疊的部分；而服務器端則根據(jù)具體的數(shù)據(jù)結構特點來選擇合適的過濾分界線，如在測量和計算等功能的LN中，DATA和DA的復合很普遍，分界線的選擇可以偏低一些，而如果DATA、DA均較簡單，則分界線的選擇可以偏高一些，如以FC為分界線。當然這需要服務器端和客戶端雙方的配合。

圖5 需要通信雙方配合的兩級目錄服務實現(xiàn)Fig.5 Implement of 2-level directory service

GetVariableAccessAttribute同時關系到數(shù)據(jù)讀取服務的實現(xiàn)，將在下一節(jié)中進行進一步分析。

3 數(shù)據(jù)讀取服務及下層目錄服務的聯(lián)合實現(xiàn)

很多ACSI服務都被映射到了MMS的Read服務。這些服務中的GetDataSetValues、GetLogStatus-Value和Select比較特殊，其他服務本質上都是對NV的數(shù)據(jù)讀取，可同時實現(xiàn)。如表2所示，ACSI服務的被讀取對象的范圍涵蓋了所有映射到NV的類型。

表2 被映射到NV讀取的全部ACSI服務Tab.2 All ACSI services mapped to NV reading service

Read服務在實現(xiàn)過程中應該提供對所有映射到NV類型的數(shù)據(jù)結構的支持，但是需要加入一些限制，以更好地貼合ACSI的功能及限制。

在ACSI規(guī)范中，GetAllDataValues服務要求同時返回成員的引用和成員的值，但是Read服務并不支持引用的返回。如果客戶端想要獲取成員的引用，就只能通過GetVariableAccessAttribute這一目錄服務變通地實現(xiàn)，例如IEC Browser就使用了這一方法。這個請求有時是在IEC61850目錄服務范圍之外的，但是服務器在設計時應當要考慮到客戶端的這種需求，將其認為是數(shù)據(jù)讀取服務的一部分。

如表3所示，IEC61850中存在只允許目錄而不允許讀取的情況。嚴格按照MMS進行的請求響應可能會違反ACSI規(guī)范，如在讀服務的響應中出現(xiàn)了FC=CO的控制對象；如果嚴格按照IEC61850的服務功能和訪問限制來進行請求響應，則可能會出現(xiàn)某個實例對應的目錄服務響應和讀服務的響應中樹結構不一致，如對一個邏輯節(jié)點分別進行GetVariable-AccessAttribute請求和Read請求，F(xiàn)C=CO的對象應該包含在前者的結果中而不包含在后者的結果中，這種情況可能會引起誤解，實現(xiàn)過程中需要基于ACSI規(guī)范對服務請求的響應進行一定的改動來避免這一問題。下面針對不同的被請求對象類型對這2個服務的具體實現(xiàn)方法進行分析。

表3 FC的訪問限制Tab.3 Access constraint of FC

a.對LN的請求。由于ACSI對LN服務模型的GetAllDataVaules這一服務的功能描述是返回一個LN中的全部DATA或者某FC的全部DATA的值，而CB的值不應包含在返回結果中。所以在服務實現(xiàn)時，只返回 FC 值為 ST、MX、CF、DC、EX、SG、SE、SPd的IedData實例對象的值，在具體程序實現(xiàn)過程中使用這些FC值的位或結果作為“過濾器”對數(shù)據(jù)結構樹進行搜索并生成結構相同的回復報文即可。而對應的GetVariableAccessAttribute請求并不在IEC61850目錄服務范圍內，所以在其回復中也只返回這些對象的結構，這樣這2個服務的回復結果的樹結構就是一致的。

b.對FC的請求。在數(shù)據(jù)讀取中，該請求仍然屬于GetAllDataVaules服務，而在目錄獲取中沒有對應的IEC61850服務。所以對控制對象及CB，即FC=CO、RP、BR、LG、GS、GO、MS、US、SC 的讀數(shù)據(jù)請求予以拒絕，但是對目錄服務請求可以按照MMS來回復；對FC=SP的情況在目錄請求和讀請求的回復中都只返回FC值為SPd的IedData對象的值；其余FC的讀請求和目錄請求均按照MMS進行。

c.對FCD或FCDA的請求。在這種情況下不存在訪問對象一部分屬性允許讀取而另一部分屬性不允許讀取的情況，而目錄獲取也有對應的IEC61850服務。所以直接按照FC訪問權限的要求進行服務的設計，讀服務只拒絕對控制對象的讀?。‵C=CO的請求），其余請求都根據(jù)MMS來進行，而所有目錄請求都根據(jù)MMS來進行。

在這個實現(xiàn)方案中，首先依據(jù)的是ACSI的服務規(guī)范，在沒有ACSI規(guī)范要求的部分則以減少誤解為目的并兼顧MMS進行設計。這種處理方法并不完全滿足MMS，與上層目錄服務的實現(xiàn)方案相同，是有理論依據(jù)的。

4 實驗驗證

本文在PC環(huán)境中，基于TCP套接字、使用C語言進行了通信系統(tǒng)的實現(xiàn)，并以變壓器溫度傳感器為背景建立了一個數(shù)據(jù)結構來進行仿真。

所實現(xiàn)的通信系統(tǒng)與2款第三方客戶端軟件——SIEMENS公司的IEC Browser和OMICRON公司的IEDScout成功進行了通信，從而驗證了方案的可行性，并在一定程度上證明了所提方案的兼容性。

在所實現(xiàn)的通信系統(tǒng)中，在GetNameList（NV，Domain-specific）的響應中，分別測試了3種不同的過濾分界線及其對應的返回列表長度。過濾分界線為FC、FCD和不過濾3種情況下，報文長度分別為9、21和59。所使用的2款客戶端軟件只有IEC Browser在過濾到FC的情況下可能會出現(xiàn)一些兼容性問題，但對實際功能沒有太大影響；其他情況下都能夠非常順利地在客戶端建立服務器數(shù)據(jù)結構。

在這個測試中，報文的響應速度主要取決于網(wǎng)絡傳輸速度。但是即使對于這樣簡單的數(shù)據(jù)結構，在不進行列表主動過濾時所產(chǎn)生的響應報文已經(jīng)需要分片傳輸，在增加了網(wǎng)絡傳輸量的同時，也增加了近1倍的響應時間，這說明進行主動過濾是必要的。

5 結語

本文對IEC61850通過SCSM映射到MMS過程中出現(xiàn)的一些矛盾進行了分析，并提出了可行的解決方案，且在通信服務器模型中進行了實驗驗證，并與2款第三方軟件成功通信。

對設備數(shù)據(jù)結構而言，一個好的數(shù)據(jù)結構應該能同時滿足來自內部系統(tǒng)和外部通信方的數(shù)據(jù)訪問需求，而在該過程中如何處理FC是一個關鍵問題。

對于通信服務而言，由于映射過程中出現(xiàn)的功能偏差，使得一些服務基于ACSI服務規(guī)范和MMS服務規(guī)范可以產(chǎn)生完全不同的實現(xiàn)方案，所以也不存在唯一的“正確方法”。本文所提實現(xiàn)方案的核心思想是以ACSI規(guī)范為基本出發(fā)點，兼顧MMS且盡可能降低通信中的誤解和資源浪費，并根據(jù)這一思想對目錄服務及數(shù)據(jù)讀取服務進行了實現(xiàn)。

由于通信過程必須由服務器和客戶端協(xié)作完成，本文提出的方案也需要通信雙方共同遵守才能起到應有的作用。本文所提方案能夠完全滿足ACSI規(guī)范所涉及的范圍，即其在通信雙方都以ACSI規(guī)范為根本的情況下不會出現(xiàn)兼容性問題。