李繼東,李斌,劉宇,何瀟,劉拓英良
(國網北京豐臺供電公司北京100073)
在電力系統中,配電網負責從降壓配電站到用戶端的電力傳輸,多種配電設備如架空線路、塔桿、電纜、配電變壓器、無功補償電容等設備組成了配電網絡[1-3]。配電網在電力系統中,扮演著電能分配的重要角色。在電網建設初期,發電和輸電過程更受重視。近年來隨著電網建設的成熟,配電和用電的安全性、穩定性得到了更多的關注。隨著國家在配網建設中的大力投入,傳輸線路、開關和變電設備等得到了長足的改進,電網運行條件也取得了較大程度的改善[4-6]。但配電網中仍存在著亟待解決的難題:1)配電網運行狀況無法實時監控:配電網輸電線路是一個由主干和多條分支相互糾結的復雜網絡。在運營中,需要及時檢測各個關鍵節點的運行狀態。這依賴于各種監測設備的數據采集,而目前監測設備的數量遠無法達到有效監控的最低需求[7]。此外,監控設備采集的現有數據也沒有得到有效的利用。2)線路故障定位困難:配電網中的架空線路由于自身特性使然是電網系統中最容易發生故障的位置。目前的故障定位還依賴于人工排查,該過程消耗了大量的人力和時間成本[8]。因此,配電網的運行監測與故障定位勢在必行。
基于以上分析,本課題研究并設計了面向配電網中架空線的監控和故障定位系統。該系統包括了監控設備、故障指示器和系統主站,本文主要介紹系統主站信息系統的實現。其中,包括系統的前臺界面設計、后臺數據使用和處理方法、數據庫的設計。整個故障監測和定位信息系統包括配置管理、告警處理、故障監控、數據統計和系統管理五大模塊。在系統實現中采用基于B/S的架構,涉及到了JSP、Spring等技術框架,數據庫使用Oracle。
信息系統設計基于軟件工程的思想。在軟件工程中,需求分析是系統設計的首要環節。需求分析將系統面臨的使用場景、不同場景下需要達到的效果加以概括、拆解、歸類、抽象成可實現的功能[9-11]。在需求分析中,既要考慮到系統的功能需求也要考慮到系統的非功能性需求。
整個系統的建設目的是為了解決10 kV線路的實時監測,從而保證在故障發生時快速定位,以確保配電網供電的穩定性。根據此需求,本系統在建設時劃分成兩類,即軟件平臺和硬件平臺[12]。其具體組成,如圖1所示。

圖1 系統總體架構
硬件部分由故障檢監終端、傳輸系統、系統主站組成。故障監測終端負責檢測短路、接地故障、負荷電流和電壓;傳輸系統負責傳輸檢測終端獲取的各種數據;系統主站上實現接收數據的接口,并存儲傳輸系統傳遞來的數據[13]。
軟件部分是本文介紹的重點。在技術架構上采用B/S結構,由監控中心、客戶端和數據庫3個部分組成。軟件系統的功能架構,如圖2所示。包括五大功能模塊:配置管理、告警處理、系統監控、數據統計和系統管理。

圖2 系統總體架構
1.2.1 配置管理
配置管理是對報警信息數據結構的定義。由于本軟件系統面向的是多個省市的配電網系統,每個區域對于報警信息的定義是不同的,具體體現在變電站名稱、線路、位置等信息的不同。用戶可以在本模塊中配置不同的位置、站點信息,同時配置自身所在監控中心的監控范圍。本模塊保證了用戶對于有用信息的篩選和報警信息的可讀性。該模塊既是整個監控系統的基礎,又提高了監控過程的用戶體驗。
1.2.2 告警處理
告警處理是系統的核心模塊,具體包括警報提示、警報記錄、警報消除、警報記錄管理等子功能模塊。警報提示是根據終端采集的數據和數據根據配置管理模塊的配置信息,對可能發生故障的線路進行提示。告警算法融合了當下流行的機器學習算法,告警提示后,若警告有人處理,警報可以消除。同時,處理方法和處理人員將記錄在系統中。警報記錄管理提供了查詢功能,相關工作人員可以根據發生過故障的線路、站點及原因進行查詢,以方便配電網的后續建設。
1.2.3 故障監控
故障監控是軟件系統的另一個核心功能模塊,主要實現了故障監控指示圖、數據定時記錄和監控終端自我檢測等監控功能。其中,故障監控指示圖是指當故障發生時,軟件系統可通過矢量圖的方式記錄故障類型和故障位置[14-16]。同時,按照用戶的配置信息顯示在系統中。故障監控過程融合了地理信息系統,監控效果可以以地圖的方式進行可視化展示,該功能保證了配網工作人員的辦事效率。數據定時記錄是指終端監測設備根據系統預設的數據抓取頻率讀取監測點的電流、電壓、溫度等表征配網運行狀態的數據信息,之所以定時抓取考慮到了系統數據的吞吐量限制,需要在系統的性能和運行穩定性上做出取舍。監控終端自我檢測是指終端定時將自身的運行狀態、運行日志反饋到信息系統中,后臺通過評估模型評估終端的運行狀態,同時判別終端采集數據的準確性。
1.2.4 數據統計
數據統計模塊接收數據傳輸網絡傳送的數據信息[17],并對數據進行運算。然后再根據后臺配置的數據模型,來判別配網運行狀態。此外,數據統計模塊還有一部分的數據可視化功能,即描繪各個監控站點的各種電網運行狀態信息,方便及時監測。
1.2.5 系統管理
系統管理包含了用戶管理、變電站管理、線路管理、終端管理。用戶管理主要是對用戶信息和權限的管理,包含用戶在數據庫中的訪問權限、新用戶的增加、信息的編輯、用戶的刪除等功能[18]。其余的硬件設備管理功能模塊主要實現對各種設備,在數據庫中信息的增加、刪除、修改、查詢。
故障監測與定位系統的軟件部分采用的是B/S架構,該架構的原理如圖3所示。B/S架構是時下被廣泛應用的網絡結構模式,是典型的三層應用架構,分為表示層、業務邏輯層及數據存儲層??蛻舳撕头掌髦g的通信依靠中間件完成,中間件是三層應用結構的基礎平臺,Web應用和數據庫之間的連接也是由中間件完成的。在應用的部署上,以Web瀏覽器作為客戶端,將核心功能部署在服務器上。用戶在瀏覽器上,借助服務器和瀏覽器的通信完成所需的功能。即對于B/S架構,客戶機上只需一個瀏覽器即可。因此,B/S架構相較于傳統的C/S架構,更適合于本系統的開發與實現。

圖3 B/S架構示意圖
在系統的實現上,涉及了 Spring、ibatis、DWR、ExtJS等多個編程框架,系統使用的數據庫是Oracle。
Spring框架:Spring框架實現了系統業務邏輯層業務對象的管控。該框架簡化了編碼過程中的“對象管理”工作,明確定義了對象生命周期、對象之間的交聯關系。在本系統的實現過程中,借助了Spring框架中的控制反轉(IOC),將原本的“對象之間自身掌控關系”轉變為外部容器對對象進行控制,從而大幅降低了系統中代碼的耦合性,保證了代碼運行的穩定性和后期的可維護性。
ibatis:ibatis是一種用于“半自動化”對象映射的框架,完成業務邏輯到數據存儲的映射,其相對于Hibernate的“一站式”對象關系映射。對于Hibernate這種封裝了完整的POJO到數據庫映射的框架,開發過程中只需關注映射關系的完整性即可。但對于本監控系統而言,系統中存在著大量數據亟待處理。因此,必須要對對象映射過程中的SQL代碼進行優化。此時,便需要使用ibatis該種“半自動化”的映射框架。所以,ibatis相較于Hibernate更適合本系統的實現。
DWR:Direct Web Remoting用于前端Web瀏覽器和后臺Java類之間的交互,是一個開源的Ajax框架,實現變現層和業務邏輯間的分離。通過該框架,在網頁中編寫的JS代碼可以轉換成直接在Web服務器上編寫的函數,這大幅縮短了開發所需的時間,而這在本系統交互頻繁的場景下尤為明顯。此外,該框架下Web瀏覽器無需刷新便可從服務器上讀取數據,對于網頁的響應時間也是較大地優化。
ExtJS:ExtJS是一個實用的 Ajax框架,由JavaScript所編寫,完全脫離于后端邏輯。該框架擁有豐富的UI組件,可以提高開發效率,使表現層更為美觀。此外,該框架對于不同的瀏覽器也有良好的兼容性,可以在任意的瀏覽器上使用。
Oracle:Oracle數據庫是目前應用最廣泛的企業級數據庫,是以關系數據模型為基礎的數據庫系統,具備完備的數據管理功能,且支持高并發、多用戶的使用場景。此外,對于配電網這種國家級項目,Oracle數據庫的數據安全性優點也是被選用的重要原因之一。
基于2.1的技術框架,系統進行了實現。下面以故障定位模塊的實現為例,展示系統的實現。
故障定位模塊通過讀取系統后臺線路圖的方法,實時顯示各條配網運行線路中的運行情況。具體實現過程包括:MonitorLineSevice負責對后臺各條線路的數據監測,該服務可以讀取變電站的信息表、配電線線路的數據表、故障監測的數據表等數據。通過數據計算,判斷是否判別為故障。該類當中的getSubstationTreeList可以按照系統后臺寫好的數據樹讀到故障點的站點信息,getLineNameTreeList可以讀到該點的線路信息。用戶在瀏覽器中的行為,會觸發MonitorLineService實現對于固定區域的監控。
此外,本信息系統在實現故障定位功能時,結合了GIS(地理信息)平臺。GIS平臺[19]的引入,可以幫助工作人員快速定位到故障點的地理位置。同時,工作人員可以提前通過配置模塊,配置好顯示的信息。如圖4所示,故障發生后系統立刻定位了故障位置。同時顯示了故障信息,包括了故障的設備、設備的維護部門、所屬的線路、設備型號等信息。從而減少了配電網運維人員的工作壓力,保證了配電網工作人員的對于故障的快速響應。

圖4 故障定位功能頁面
文中描述了配電網故障監測和定位項目中信息系統的實現,系統實現前按照軟件工程的理論進行了詳盡的需求分析,保證了系統功能上的完整性。系統在實現上基于B/S框架,采用了多種Spring、ibatis等多個軟件框架,保證了系統運行的穩定性和可維護性。此外,系統在故障定位功能的實現上融入了GIS信息系統,以可視化的方式展示監控效果,大幅提高了配網人員的故障定位效率。