龔禹生，洪權(quán)，李振文，吳晉波，張若宸

(1.國網(wǎng)湖南省電力有限公司電力科學(xué)研究院，湖南 長沙410007；2.國網(wǎng)湖南省電力有限公司，湖南 長沙410004；3.北京科東電力控制系統(tǒng)有限責(zé)任公司，北京100000)

0 引言

隨著電網(wǎng)的全面建設(shè)提升，電網(wǎng)運行特性也發(fā)生了重大變化，更強(qiáng)調(diào)調(diào)度運行模式的轉(zhuǎn)變，不斷提高調(diào)度創(chuàng)新能力，尤其是需要提升對跳閘等事故處理的智能化、在線化水平，有力保障大電網(wǎng)安全穩(wěn)定運行[1－4]。

各級調(diào)控中心需要實現(xiàn)調(diào)控一體化的運行管理模式，并建立相應(yīng)的設(shè)備監(jiān)控支撐功能。告警系統(tǒng)對保障電網(wǎng)安全運行起著舉足輕重的作用[5－7]，從現(xiàn)場應(yīng)用來看，調(diào)控云平臺對調(diào)度自動化系統(tǒng)的智能化應(yīng)用起了較大作用[8]，但云上綜合智能告警準(zhǔn)確率還處于較低水平，主要體現(xiàn)在以下幾個方面:一是硬件配置不足，調(diào)控云平臺接收的數(shù)據(jù)量過大，現(xiàn)有數(shù)據(jù)采集與處理服務(wù)器難以承受如此密集的數(shù)據(jù)量；二是調(diào)控云平臺告警程序還不夠完善，對于某些跳閘信息匹配成功率不高，未能達(dá)到現(xiàn)場應(yīng)用級別的要求；三是省、地公司之間數(shù)據(jù)傳輸通道不穩(wěn)定，對數(shù)據(jù)質(zhì)量有比較嚴(yán)重的影響。許多學(xué)者也在此方面進(jìn)行了深入研究，文獻(xiàn)[9]針對綜合智能告警無法有效區(qū)分機(jī)組跳閘和人工停機(jī)而造成誤告警的問題，采用一種人工合成停機(jī)信號的方案，優(yōu)化機(jī)組診斷邏輯。文獻(xiàn)[10]提出了一種云邊協(xié)同技術(shù)，解決了集中計算帶來的調(diào)控云網(wǎng)絡(luò)帶寬占用過大、數(shù)據(jù)時效性不強(qiáng)的問題，緩解了調(diào)控云中心的計算、存儲壓力，對于基礎(chǔ)數(shù)據(jù)的傳輸起了較大的作用。文獻(xiàn)[11]針對500 kV主變壓器告警邏輯、誤推圖等情況進(jìn)行分析并提出改進(jìn)建議。

為了解決云上綜合智能告警準(zhǔn)確率較低的問題，本文從調(diào)控云數(shù)據(jù)平臺結(jié)構(gòu)、云上綜合智能告警優(yōu)化措施、示范應(yīng)用以及問題分析4個方面展開分析，明確湖南地區(qū)相應(yīng)的解決方案。結(jié)果顯示，規(guī)范化、標(biāo)準(zhǔn)化地應(yīng)用本文的策略能夠有效提升云上綜合智能告警準(zhǔn)確率。

1 調(diào)控云數(shù)據(jù)平臺結(jié)構(gòu)

1.1 電網(wǎng)模型架構(gòu)

調(diào)控云平臺在遵循調(diào)控云結(jié)構(gòu)化設(shè)計的基礎(chǔ)上，設(shè)計適用于實時應(yīng)用計算的電網(wǎng)模型結(jié)構(gòu)，從模型數(shù)據(jù)平臺獲取全省電網(wǎng)模型采用存量下載、增量同步的方式，實現(xiàn)電網(wǎng)模型從模型數(shù)據(jù)平臺到實時數(shù)據(jù)平臺Ⅲ區(qū)，再到實時數(shù)據(jù)平臺Ⅰ區(qū)，全過程實現(xiàn)自動流轉(zhuǎn)。通過模型數(shù)據(jù)平臺與D5000模型間的ID映射，實現(xiàn)模型數(shù)據(jù)平臺、實時數(shù)據(jù)平臺、D5000系統(tǒng)間的模型關(guān)聯(lián)。

1.2 實時數(shù)據(jù)采集

省調(diào)及各地調(diào)實時數(shù)據(jù)云端匯集，為大電網(wǎng)廣域瀏覽和各類在線分析決策應(yīng)用提供基礎(chǔ)數(shù)據(jù)。如圖1所示，D5000系統(tǒng)側(cè)原始報文分組轉(zhuǎn)發(fā)方式，選取結(jié)果源鏈路上送實時數(shù)據(jù)。實時數(shù)據(jù)平臺側(cè)，采用分布式并行采集模式，支持多源處理；支持采集點表免維護(hù)；可動態(tài)擴(kuò)容，滿足海量數(shù)據(jù)采集需求。

圖1 實時數(shù)據(jù)平臺

1.3 實時數(shù)據(jù)服務(wù)

基于分布式實時數(shù)據(jù)庫的處理架構(gòu)按照地域范圍和量測數(shù)據(jù)量將全網(wǎng)模型分成由多節(jié)點組成的分布式數(shù)據(jù)處理集群，各節(jié)點分別進(jìn)行實時數(shù)據(jù)處理。實時云平臺部署Ⅰ區(qū)數(shù)據(jù)處理服務(wù)器、數(shù)據(jù)采集服務(wù)器、數(shù)據(jù)庫服務(wù)器、Ⅲ區(qū)數(shù)據(jù)交互服務(wù)器，共計12臺服務(wù)器。智能告警應(yīng)用部署于Ⅲ區(qū)，通過反向隔離裝置獲取Ⅰ區(qū)的電網(wǎng)運行數(shù)據(jù)及設(shè)備事件信息，根據(jù)擬定的判斷邏輯實現(xiàn)故障跳閘事件的判定，生成告警文本等進(jìn)行展示[12－15]。為了提升云上綜合智能告警研判準(zhǔn)確率，并提高調(diào)控云平臺基礎(chǔ)數(shù)據(jù)可靠性，對云上綜合智能告警和OMS中人工填報的數(shù)據(jù)進(jìn)行匹配后，對誤、漏告警數(shù)據(jù)進(jìn)行分析，并對源端數(shù)據(jù)的參數(shù)進(jìn)行結(jié)構(gòu)化、規(guī)范化、標(biāo)準(zhǔn)化治理。

2 云上綜合智能告警優(yōu)化措施

2.1 程序研判體系優(yōu)化

2.1.1 10 kV線路告警研判優(yōu)化

平臺原方案采取“開關(guān)分位”＆(“本間隔保護(hù)動作”‖“本間隔事故總”)作為遙信判據(jù)。根據(jù)湖南地區(qū)運行數(shù)據(jù)，在10 kV這一電壓等級中，一方面站端事故總合成邏輯不完善，由于“事故總”合成信號中將非保護(hù)動作信號引入合成邏輯，導(dǎo)致正常分合斷路器時誤發(fā)“事故總”信號，觸發(fā)故障跳閘推送，導(dǎo)致誤告警較多。另一方面湖南電網(wǎng)老舊設(shè)備較多，遠(yuǎn)動機(jī)老化容易漏發(fā)信號，導(dǎo)致跳閘“事故總”難以準(zhǔn)確觸發(fā)，且短時間內(nèi)難以全部整改完成，會產(chǎn)生漏告警。綜合分析運行數(shù)據(jù)后，現(xiàn)階段由“事故總”造成的誤告警數(shù)量較多，因而暫對由“事故總”誤告警邏輯進(jìn)行優(yōu)化。

因此10 kV線路跳閘匹配邏輯修改為“開關(guān)分位”＆“本間隔保護(hù)動作”作為遙信判據(jù)， “本間隔事故總”和“全站事故總”僅作為關(guān)聯(lián)顯示，并在地市公司同時開展事故總臺賬排查工作，提高10 kV線路跳閘研判的準(zhǔn)確率。

2.1.2 重復(fù)告警研判優(yōu)化

針對線路跳閘存在首末端變電站均告出的情況，以線路名稱＋編號的雙重命名為匹配關(guān)鍵字進(jìn)行合并，僅推出一端變電站告警。

由于部分廠站省、地調(diào)名稱命名方式不統(tǒng)一，如“某某站”“某某變”均為統(tǒng)一廠站，程序中則以廠站名(不區(qū)分“站”“變”的命名方式)、設(shè)備雙重命名為匹配依據(jù)進(jìn)行合并處理。

2.1.3 新增母線跳閘研判功能

母線關(guān)聯(lián)多個斷路器，因此無法參照線路、變壓器等采用“單一開關(guān)分位＆本間隔保護(hù)動作”的研判方式?？紤]以母線跳閘保護(hù)動作信號作為觸發(fā)，同時以同廠站、同電壓等級的其他設(shè)備跳閘信息為輔助，二者結(jié)合作為母線跳閘的研判判據(jù)。當(dāng)母差保護(hù)區(qū)內(nèi)動作時，會首先出現(xiàn)母聯(lián)分閘信號，系統(tǒng)會首先判斷為母聯(lián)跳閘，不會出現(xiàn)漏報的情況。

2.1.4 滑窗技術(shù)實現(xiàn)故障研判策略

目前調(diào)控云程序?qū)τ谔l研判采用固定周期計算，每1 min啟動一次計算，選取時段為當(dāng)前時刻前5 min的1 min數(shù)據(jù)進(jìn)行研判，將程序研判基于固定時刻觸發(fā)，每次按照固定周期劃分計算區(qū)間，會造成某次跳閘信息被劃分到兩個計算周期，造成重合閘動作情況研判錯誤，或者分閘信號無法與保護(hù)信號進(jìn)行關(guān)聯(lián)導(dǎo)致漏判。

考慮程序運行內(nèi)存中滾動緩存2 min的原始信號，以1 min為間隔啟動計算，每次計算選取緩存內(nèi)1 min的斷路器分閘信號作為研判觸發(fā)，確保與該分閘信號關(guān)聯(lián)的保護(hù)動作信號也在緩存中，以此實現(xiàn)計算原始信號的重疊，解決事故信息跨固定時間間隔的問題，如圖2所示。具體步驟如下:

圖2 變時間窗技術(shù)研判策略

1)計算周期1 min。

2)保持緩存2 min的原始信號，每周期滾動增加1 min的新數(shù)據(jù)、刪除1 min的舊數(shù)據(jù)。

3)緩存2 min的告警研判結(jié)果，每周期滾動增加1 min的新數(shù)據(jù)、刪除1 min的舊數(shù)據(jù)。

4)每次計算，進(jìn)行研判的分閘信號的動作時間，處于緩存信號的中間位置，保證此分閘信號能夠關(guān)聯(lián)到其他分合閘、保護(hù)信號。

5)判斷完成后，從緩存中刪除關(guān)聯(lián)的分合閘信號。

6)每周期，從緩存中清除舊的原始信號和告警研判結(jié)果。

2.2 基礎(chǔ)數(shù)據(jù)治理

拓?fù)渲珨?shù)據(jù)表示設(shè)備的帶電狀態(tài)，利用拓?fù)渲梢杂行У剡^濾如現(xiàn)場試驗操作引起的跳閘誤告警。各地區(qū)在核查調(diào)控云智能告警誤告、漏告數(shù)據(jù)過程中，發(fā)現(xiàn)在部分出線開關(guān)為手車開關(guān)的線路中，現(xiàn)場試驗時已斷開手車的刀閘，但調(diào)控云智能告警未能通過拓?fù)渲珜⒃囼炚`發(fā)的告警進(jìn)行過濾。

地調(diào)D5000系統(tǒng)圖形編輯器在對手車開關(guān)進(jìn)行節(jié)點入庫時，將手車開關(guān)中的斷路器連至了母線，刀閘連至線路。當(dāng)?shù)堕l斷開時，由于與斷路器相連的母線仍帶電，所以拓?fù)涑绦驅(qū)嗦菲髋袛酁閹щ?，誤發(fā)信號無法通過拓?fù)溥M(jìn)行過濾。對手車開關(guān)拓?fù)洳捎昧艘惶讬z測及整改方案。

1)存量模型。查看母線、手車開關(guān)上，可以看到設(shè)備連接點號。如果點號順序為母線—斷路器—刀閘，則需要進(jìn)行調(diào)整

2)增量模型。對節(jié)點入庫規(guī)則進(jìn)行更改，增加判斷手車節(jié)點號是否正確的判斷邏輯，在廠站圖點節(jié)點入庫進(jìn)行提示，如果手車開關(guān)連接錯誤會出現(xiàn)告警。

3)整改方案。選中有問題的手車，屬性編輯器的“旋轉(zhuǎn)角度”填寫180°，將手車首尾的連接線重新連接正確，將手車首尾連接線重新拖到首尾端。

2.3 數(shù)據(jù)傳輸提升措施

2.3.1 主備調(diào)機(jī)數(shù)據(jù)同步策略

目前調(diào)控云Ⅲ區(qū)僅支持固定的某一臺服務(wù)器接收地調(diào)拓?fù)湮募?，?dāng)主備調(diào)機(jī)服務(wù)器運行狀態(tài)切換時，只有主調(diào)機(jī)服務(wù)器在接受拓?fù)湮募?，而切換中的備機(jī)服務(wù)器因缺少拓?fù)湮募?dǎo)致誤報、漏報。由于主備服務(wù)器切換時間約為4～8 h，會造成比較嚴(yán)重的誤、漏告警情況。

設(shè)計一種主備機(jī)文件數(shù)據(jù)同步工具，工具部署在固定接收地調(diào)文件的服務(wù)器上，當(dāng)檢測到文件傳輸?shù)街鞣?wù)器上時，自動將文件同步傳輸?shù)狡渌?wù)器，確保每臺服務(wù)器上拓?fù)湮募囊恢滦?，進(jìn)而確保每臺服務(wù)器上的智能告警程序都能獲取最新的拓?fù)渲畔ⅰ?/p>

2.3.2 數(shù)據(jù)傳輸通道監(jiān)視

在調(diào)控云平臺運行過程中，由于數(shù)據(jù)輸送量大，會發(fā)生傳輸通道斷鏈等情況，影響基礎(chǔ)數(shù)據(jù)的質(zhì)量，但采用人工監(jiān)視通道的方式效率很低，因此針對可能發(fā)生的三種情況，采用不同的監(jiān)視方法。

1)e文件鏈路監(jiān)視。地調(diào)每分鐘上送以時間戳命名的心跳文件(如cs＿h(yuǎn)eartbeat20210620＿080100.txt)，程序自動獲取系統(tǒng)當(dāng)前時間并檢測是否接收到該時間心跳文件，如果出現(xiàn)中斷，調(diào)控云平臺會自動發(fā)出告警信號，并標(biāo)注相應(yīng)斷鏈時間。

2)拓?fù)湮募O(jiān)視。針對拓?fù)湮募? min進(jìn)行一次監(jiān)控，由于地調(diào)拓?fù)湮募甲詣訋в袝r間戳(以某地市公司為例，5月29日8:00的拓?fù)湮募Q為cd＿202105292000＿breaker)，出現(xiàn)時間中斷的情況時，調(diào)控云平臺會自動發(fā)出告警信號，并標(biāo)注相應(yīng)斷鏈時間，某地市公司出現(xiàn)拓?fù)湮募噫湹捻撁妫趫D中會呈現(xiàn)紅色告警信號。

3)數(shù)據(jù)庫監(jiān)視。數(shù)據(jù)傳輸?shù)秸{(diào)控云平臺的過程中會出現(xiàn)數(shù)據(jù)堵塞的情況，導(dǎo)致部分地調(diào)基礎(chǔ)數(shù)據(jù)在調(diào)控云中丟失，因此針對數(shù)據(jù)庫也采用了相應(yīng)監(jiān)視軟件，每5 min對基礎(chǔ)數(shù)據(jù)進(jìn)行檢查，如果在此周期內(nèi)無數(shù)據(jù)上送數(shù)據(jù)庫中，則平臺也會自動發(fā)出告警信號。

3 應(yīng)用成效及展望

通過采取程序研判體系優(yōu)化、基礎(chǔ)數(shù)據(jù)治理和數(shù)據(jù)傳輸提升等三大措施，有效提升了云上綜合智能告警的研判準(zhǔn)確率。根據(jù)統(tǒng)計，每個統(tǒng)計周期的10 kV及以上主設(shè)備跳閘情況和云上告警誤、漏告警情況如圖3所示。可以看出，云上告警研判準(zhǔn)確率從1季度的86.07%升至4季度97.06%，事故跳閘告出率從1季度的81.78%升至4季度93.76%，有效提升了云上綜合智能告警的總體水平。

圖3 云上告警準(zhǔn)確率統(tǒng)計

云上告警研判準(zhǔn)確率＝1－誤報數(shù)/云上告警總數(shù)×100%。

事故跳閘告出率＝1－漏報數(shù)/真實跳閘數(shù)×100%。

如圖4所示，消除了由于手車開關(guān)拓?fù)渲e誤、重復(fù)告警、主備調(diào)機(jī)切換導(dǎo)致拓?fù)湮募G失等情況，并加強(qiáng)了地調(diào)至省調(diào)實時云平臺之間鏈路的監(jiān)視。

圖4 1—6月手車開關(guān)拓?fù)渲卫砬闆r

現(xiàn)階段還存在如下問題:1)省調(diào)實時云服務(wù)器配置不夠，處理壓力過大，造成遙測數(shù)據(jù)堵塞，保護(hù)信號與分閘信號入庫延時過大，導(dǎo)致程序匹配失??；2)雙重化名稱填寫不規(guī)范，研判過程中無法觸發(fā)關(guān)鍵字匹配，導(dǎo)致漏告警；3)程序會根據(jù)斷路器拓?fù)渲珌砼袛嗍欠襁M(jìn)行研判，只有在斷路器前5～10 min為帶電狀態(tài)時，程序才會對上送的分閘信號進(jìn)行研判，當(dāng)線路試送前，斷路器為不帶電狀態(tài)，導(dǎo)致試送跳閘時分閘信號會被程序濾除，不會與保護(hù)信號關(guān)聯(lián)，導(dǎo)致漏告警。

針對上述問題，擬通過以下方式解決:1)增配省調(diào)控云平臺實時云服務(wù)器，提升省調(diào)端數(shù)據(jù)處理能力，降低由于通道阻塞造成的漏告警；2)組織地市公司開展雙重化名稱排查工作，確保每個分閘信號和保護(hù)信號中雙重化命名一致且正確，并在每半月的云上綜合智能告警核查中進(jìn)行排查；3)設(shè)計云上綜合智能告警結(jié)果與OMS交互的功能，如出現(xiàn)OMS中進(jìn)行填報而云上綜合智能告警沒有研判的情況，則把OMS填報結(jié)果導(dǎo)入云上綜合智能告警中，并加強(qiáng)對地調(diào)填報信息的規(guī)范與管理，保證基礎(chǔ)數(shù)據(jù)的可靠性。

4 結(jié)語

本文在調(diào)控云平臺建設(shè)的大背景下，分析云上綜合智能告警準(zhǔn)確率較低的問題并給出治理措施，進(jìn)一步優(yōu)化了調(diào)控云平臺的告警信息功能，提升了平臺數(shù)據(jù)的可靠性。通過數(shù)個月的運行，驗證了提出的方案能解決相關(guān)問題，驗證了方案的有效性。