曾小輝,陳小惠,朱慶,李明娟,杜沐恩
(國網湖南省電力有限公司信息通信分公司,湖南 長沙 410004)
電力光傳輸系統承載電網安全生產和發展運營等業務通道,是電網安全穩定運行的基礎。隨著國民經濟的不斷發展和電網規模的不斷擴大,一方面電力光傳輸系統組網日趨復雜,系統運行故障處置復雜度增加;另一方面,電力光傳輸系統承載的電網業務日益增長,系統運行故障的影響范圍增大,對電力光傳輸系統的運維方式方法提出了挑戰。
傳統電力光傳輸系統主要采用設備廠商專業網管系統進行運維管理,該類網管架構主要參照電信管理網的分層管理結構,從上到下包含網絡管理層、網元管理層和網元層[1],其強大的操作維護管理功能是通過SDH網元之間的嵌入控制通道(Embedded Control Channel,ECC)協議來傳遞其豐富的D1-D12再生段和復用段開銷字節,包括帶內和帶外兩種數據通信通道(Data Communication Channel,DCC)物理通道[2]。設備廠商專業網管系統主要用戶仍為設備廠商技術支持人員和電力光傳輸系統運維的高級維護人員,對電力光傳輸系統的智能運維支持程度不高。另一方面,電力光傳輸系統運維人員也只能使用設備廠商專業網管系統進行實時告警監控,缺乏對系統性能的預警,難以支持系統運維從被動故障搶修轉變為主動預警處置。
電力光傳輸系統設備公共核心板件多采用主備冗余配置,因此主要影響業務的系統故障和缺陷為光路中斷。除采用設備廠商專業網管系統實現光路性能實時告警的監視外,另一種具備提前預警效果的智能運維方法為光纜在線監測系統的應用[3]。為盡量減小對在線業務造成的影響,光纜在線監測系統通常對光纜的剩余纖芯進行性能監測[4],繼而對光纜上承載的光傳輸系統光路等性能進行一定程度的監視和預警。然而,光纜在線監測系統通常以光纜為監測主體,輔助光傳輸系統性能分析存在以下問題:一是光纜在線監測系統監測纖芯的性能數值未與光傳輸系統光路基礎數據進行映射綁定,運維人員需要從光纜在線監測系統中獲取監測數據后,采用線下臺賬比對方式確定應分析的光傳輸系統光路,智能程度較低;二是光纜在線監測系統監測性能主體為光纜的空閑纖芯,同一條光纜的多根纖芯本身就存在性能差異,難以準確反應光傳輸系統光路的真實性能;三是大部分光傳輸系統光路需要由多段光纜的跳接承載,而光纜資源極其寶貴,為光纜在線監測系統分配大量纖芯資料不切實際[5]。此外,光纜在線監測系統設備價格昂貴,難以形成規模應用。
綜上分析,傳統的電力光傳輸系統運維方式在光路性能的預警及時性、性能準確性和應用推廣等方面存在不足。本文以電力光傳輸系統主動預警處置為目標,基于專業網管開放接口設計和開發電力光傳輸系統自動巡檢工具,實現電力光傳輸系統光路性能數據的采集、分析和預警,提升電力光傳輸系統運維效率。
通信網管系統除各類別廠商獨立的專業網管系統,還有同樣基于電信管理網的綜合管理系統[6],一般指各行業根據行業需求,基于專業網管的北向開放接口進行定制功能的開發,構建適合行業應用的運維支撐系統。如國家電網有限公司統一開發的電力通信管理系統[7],接入了多廠家的傳輸、交換、電源、動環等不同類別通信設備的專業網管,有實時監視、資源管理、運行管理和專業管理四大功能模塊,其采集體系結構如圖1所示[8]。

圖1 綜合網管系統采集體系結構
根據上北下南規則,專業網管通過北向接口向上提供數據調用接口,綜合網管系統正常運行的基礎是數據采集功能。專業網管再通過南向接口直接連接到網關網元進而與網元設備交互[8],從而采集網元的告警、配置、性能等數據信息,以提供告警展示和性能查詢、業務配置等功能。
由于廠商專業網管面向多行業的專業運維工程師,通常不支持定制功能開發,涉及產品專利等方面的要求,第三方也難以對專業網管進行升級開發。而電力綜合管理系統為統一開發的系統,面向全國“總部分地”多層級單位,定制化需求開發時間長。因而本文借鑒綜合網管的開發方式,基于專業網管的北向開放接口對自動巡檢工具進行開發。
對電力光傳輸系統的光路性能進行巡檢,如圖2所示,一條光路的完整信息包括傳輸段名稱、源宿網元名稱、光板槽位端口、收發光功率值、光模塊類型。

圖2 光路組成示意圖
光模塊主要用于獲取光功率門限值,因為北向接口不直接提供讀取門限值。光路兩端使用的模塊類型是必須從專業網管中采集的參數,原因是光模塊包含傳輸速率、波長、適用距離等關鍵參數,即使傳輸速率相同,其光路的性能閾值也存在較大差異,以某一2.5G光模塊為例,見表1。

表1 2.5G光模塊的光功率閾值
其中光接收靈敏度和最小過載點為俗稱的收端光功率的下門限值和上門限值。
從圖1可見,廠商傳送域專業網管通過北向接口為運行支撐系統(Operation Support Systems,OSS)提供豐富的告警、性能、存量等網絡監控信息,同時支持配置、測試診斷等網絡管理、控制分析功能,如電力通信管理系統采集專業網管的告警、配置和性能等數據[9]。其中存量包含網元、槽位、單板端口、交叉、路徑等物理和邏輯存量信息;告警包含告警查詢和確認等功能;配置表示對業務通道進行創建、刪除、修改等操作;性能包含當前和歷史的收發光功率、工作溫度、誤碼等性能參數數據。
為滿足不同的OSS系統集成需求,專業網管的北向接口通常分為公共對象請求代理體系結構(Common Object Request Broker Architecture,CORBA)、可擴展標記語言(Extensible Markup Language,XML)、簡單網絡 管 理 協議(Simple Network Management Protocol,SNMP)、文件傳輸協議(File Transfer Protocol,FTP)和描述性狀態遷移(Representational State Transfer,REST)。
CORBA是由國際標準組織對象管理組(Object Management Group,OMG)定義的一種標準的面向對象的標準化建模接口,因其開放性、平臺和語言的無關性可實現網絡管理系統與不同網元管理系統的通信,廣泛應用在傳輸網北向接口中,此時采用的是TMF814協議[10]。
XML是一種可以自描述的標記語言,因其固有的靈活性和可擴展性,被廣泛應用于跨系統跨平臺的數據存儲和數據共享[11],XML接口適合綜合網管系統。
SNMP是管理進程和代理進程之間的通信協議,是一種應用層協議,能管理支持代理進程的網絡設備[12]。在此,管理進程特指綜合網管系統,代理進程指專業網管。
FTP協議是TCP/IP協議組的協議之一,采集程序以定期輪詢方式通過FTP協議登陸網管服務器采集數據,不滿足數據采集實時性要求[13]。
REST描述了一個架構樣式的網絡系統,使用REST架構的服務被稱為RESTful服務,建立在HTTP協議基礎上,數據傳輸采用明文方式,數據安全性不能完全保證[9],是目前主流的一種Web服務交互方案。
除接口性能、參考標準的不同,各種接口開放數據類型方面也存在一定差異,某傳送域的各北向接口開放的數據類型對比見表2。其中,RESTful僅支持OTN和WDM設備的存量查詢、配置管理功能。

表2 北向接口開放數據
綜合巡檢工具開發目的及對設備廠商北向接口文檔的對比,選擇CORBA和XML兩類采集接口,其中CORBA接口采集傳輸段、源端和宿端的傳輸網元、傳輸網元端口、收發光功率等性能數據;而XML接口采集端口光模塊類型,用于光路性能閾值的準確匹配。
電力光傳輸系統自動巡檢工具包含4個模塊,分別為權限管理模塊、數據采集模塊、性能分析模塊和輸出展示模塊。
為減少部署成本,光傳輸系統的專業網管多采用集中化部署,即多級多域設備均采用同一套專業網管進行維護管理,其中級包含總部、分部、省、地四級,域包括SDH、PTN、OTN。如湖南地區電力NCE光傳輸網管共管轄了湖南省和所有地市的SDH、PTN和OTN網絡。由于各級傳輸設備的運維主體不同,集中部署模式要求自動巡檢工具具備分權分域的設計,與設備的運維主體保持一致,不同運維主體應分配不同的管理權限,保證用戶數據的安全性。
數據采集模塊除簡單地從北向接口采集巡檢所需字段信息,還包括數據加工,如按照適配協議進行數據解析和根據開發目的設計合并數據對象[13]。由于傳輸段名稱包含源宿端網元和端口信息,以傳輸段為中心遍歷所有傳輸段,解析出所有源宿兩端的網元名稱和端口,并將網元名稱和端口綁定,進而采集該端口的收發光功率性能參數和光模塊類型,并根據廠家模塊工具書定義該端口的收發光上下門限值。最后以傳輸段為維度,將傳輸段、速率、源宿兩端的網元、端口、性能數據、門限關聯成一個完整的光路對象數據,如圖3所示。

圖3 數據采集處理流程
性能分析模塊是巡檢工具的核心,主要通過光路劣化規則來判斷光路狀態,以及異常嚴重程度、持續周期。其中劣化規則包括收端光功率與門限值和設定值的判斷、收端光功率與上一周期的巡檢結果對比,比設備廠商專業網管的只與門限值判斷更精準;光路狀態包括光路中斷、光路異常、光路正常;嚴重程度包括嚴重、一般;更精準多周期地衡量光路性能,具體如圖4所示。超出門限值,或在門限設定值內但連續與上一周期光功率浮動超過2 dBm,都被判定為嚴重的光路異常。只有當收端光功率處于門限設定值內,且與上一周期的光功率浮動未超過2 dBm,才認為是光路正常。

圖4 光路性能分析流程
其中根據運維經驗,設定值為“+3/-5”[14],即下門限加3 dBm,上門限減5 dBm,也是工程實施對光功率余量需滿足“高3低5”的原則。
將光路對象數據中的網元、傳輸段、收發光功率和分析結果中的光路狀態、異常嚴重程度、持續周期合并為一條光路的完整輸出信息。并根據異常嚴重程度顯示為不同顏色,代表需干預的緊急程度,“嚴重”顯示為紅色,“一般”為“黃色”,分別督促運維人員立即和盡快處理來實現自動預警,化被動消缺為主動進行隱患治理。
開發工具類程序主流的開發語言有Java、C++、Python等。Java是一門面向對象的編程語言,因其優越的跨平臺可移植性,在Web開發中是主流語言,且簡單易用、語法規范、開源軟件多。C++是一種最廣泛支持范式的編程語言,擅長面向對象程序設計的同時,還可以進行基于過程的程序設計。Python是動態形的靈活的解釋性語言,從軟件開發到Web開發,Python都有被使用,因其解釋性,適合輕量級開發。
根據本項目需求綜合分析,采用Java語言開發,使用springboot框架,重點介紹數據采集模塊的實現。
4.1.1 CORBA采集接口的實現
CORBA接口開發通常采用對象請求代理(Object Request Broker,ORB)實現,商業ORB主要包 括Orbix、VisiBroker,開 源ORB主 要 包 括JacORB、TAO。考慮實現工具較為簡單,開源ORB即可支持,選擇JacORB作為中間件進行開發。利用JacORB對專業網管的接口描述語言(Interface description language,IDL)進行編譯,形成了Java編程語言可使用的庫文件,各參數獲取方法如下:
1)獲取網元列表,用ManagedElementMgr_I數據接口類的getAllManagedElements方法;
2)獲取網元命名,用ManagedElementMgr_I數據接口類的getAllManagedElementNames方法;
3)獲取網元端口信息,調用ManagedElement Mgr_I數據接口類的getAllPTPNames方法;
4)獲取光路拓撲列表,調用EMSMgr_I數據接口類的getAllTopologicalLinks方法;
5)獲取光路拓撲具體名稱,調用EMSMgr_I接口類的getAllTopLevelSubnetworkNames方法;
6)獲取光路所在端口的性能信息,調用PerformanceManagementMgr_I數據接 口 類 的getAll CurrentPMData方法。
4.1.2 XML接口的實現
XML接口開發通常采用簡單對象訪問協議(Simple Object Access Protocol,SOAP)中間件實現,商 業ORB主 要 包 括IBM Websphere、IBM Weblogic,開 源ORB主 要 包 括Apache CXF、Apache AXIS。考慮實現工具較為簡單,開源SOAP即可支持,選擇Apache CXF中間件進行開發。利用Apache CXF對專業網管的Web服務描述語言(Web Services Description Language,WSDL)進行編譯,形成了Java編程語言可使用的庫文件,并通過調用EquipmentInventoryRetrievalRPC數據接口類的getAllEquipment方法來獲取端口光模塊類型。
利用該工具對省網某SDH光傳輸系統所有光路進行自動巡檢,部分光路段的巡檢結果見表3。

表3 SDH光傳輸系統部分光路段巡檢結果
表3中,SW-黔城#15-1至SW-飛山#14-1速率為STM4的光路,源宿兩端收入光功率分別是-23.5 dBm和-25.7 dBm,雖然都在門限(上門限-5,下門限+3,即-13/-5 dBm,-34/+3 dBm)以內,但由于宿端SW-飛山#14-1的收光功率比上一巡檢周期的結果降低了2.5 dBm,因而光路狀態是異常,因為是第一次出現,所以是黃色預警。
而SW-紫霞2#12-1至SW-瑤都#8-1段速率為STM16的光路,源宿兩端收入光功率分別是-18.1 dBm和-23.8 dBm,雖然都在設定門限以內(上門限-5,下門限+3,即-9/-5 dBm,-28/+3 dBm)以內,但由于宿端SW-瑤都#8-1的收光功率比上一巡檢周期的結果降低了5.7 dBm,因而光路狀態是異常;且第二次收光功率降低超過2 dBm,即持續惡化,是紅色預警。
監控人員復核專業網管的當前收光功率值和歷史記錄的收光功率值,發現巡檢工具的分析結果正確,及時通知運維人員進行處理,發現故障原因是SW-紫霞2#12-1至SW-瑤都#8-1光路所經過的光纜段在紫霞站內受鼠咬導致部分纖芯受損,將有鼠泛的光纜提前進行業務迂回;而SW-黔城#15-1至SW-飛山#14-1所承載的光纜纖芯是因為某次檢修調整時未將飛山側纖芯擦拭干凈。
通過分析電力光傳輸系統現有運維方式的不足,基于專業網管北向接口和光路異常預判規則設計電力光傳輸系統自動巡檢工具,并應用到實際生產運行的電力光傳輸系統。實用效果表明該工具能夠準確高效地巡檢光路性能而降低人工巡檢的成本,并依據實際運維要求進行合理分析預警,避免電力光傳輸系統光路的非計劃中斷,提升自主化運維水平。