智能變電站二次設(shè)備在線故障運(yùn)維平臺(tái)架構(gòu)研究

，，，，

(國(guó)電南自自動(dòng)化有限公司，南京 211153)

0 引言

隨著變電站智能化、無(wú)人化政策的落地，傳統(tǒng)二次設(shè)備運(yùn)行維護(hù)系統(tǒng)(以下簡(jiǎn)稱(chēng)運(yùn)維)容量已無(wú)法滿(mǎn)足數(shù)字化裝置的增長(zhǎng)速度，伴隨著國(guó)家電網(wǎng)“互聯(lián)網(wǎng)+”“智慧電力”規(guī)劃實(shí)施的深入，大量的智能二次設(shè)備上線，裝置數(shù)量、轉(zhuǎn)出信號(hào)呈現(xiàn)井噴式增加[1]，從而引發(fā)了一系列問(wèn)題：(1)巡檢任務(wù)量成倍增加，運(yùn)檢人員無(wú)法承受；(2)問(wèn)題反復(fù)出現(xiàn)，疲于在某幾個(gè)變電站間重復(fù)檢修，導(dǎo)致其他變電站長(zhǎng)時(shí)間無(wú)人檢修；(3)故障得不到及時(shí)解決，只知道故障告警，對(duì)可能產(chǎn)生告警的原因無(wú)法推斷；(4)二次回路“黑匣子”問(wèn)題難以智能化運(yùn)檢，耗費(fèi)大量人力物力去應(yīng)付。以上問(wèn)題的發(fā)生也間接反映出目前傳統(tǒng)運(yùn)維系統(tǒng)已無(wú)法滿(mǎn)足新時(shí)期對(duì)智能變電站運(yùn)維的要求。容量單一，轄區(qū)內(nèi)變電站信號(hào)不能統(tǒng)一接入與存儲(chǔ)，不能生成全方位對(duì)比分析；計(jì)算能力有限，很難在線生成故障問(wèn)題定位與專(zhuān)家推薦[2]。

針對(duì)以上問(wèn)題，本文提出了一種基于分布式大數(shù)據(jù)技術(shù)的運(yùn)維支撐平臺(tái)架構(gòu)方案。利用該架構(gòu)實(shí)現(xiàn)變電站虛擬化、可視化需求；實(shí)現(xiàn)監(jiān)測(cè)、預(yù)警、在線故障定位等業(yè)務(wù)需求。在保證系統(tǒng)可靠性、安全性、穩(wěn)定性的基礎(chǔ)上，結(jié)合Hadoop開(kāi)源組件及其他大數(shù)據(jù)組件，結(jié)合IEC 61970/61968模型擴(kuò)展技術(shù)[3]，實(shí)現(xiàn)運(yùn)維主站對(duì)智能變電站的數(shù)字化、精細(xì)化、智能化運(yùn)維，實(shí)現(xiàn)運(yùn)維人員在運(yùn)維主站對(duì)所轄變電站的全景把握。

1 大數(shù)據(jù)運(yùn)維平臺(tái)架構(gòu)

智能化二次設(shè)備主站運(yùn)維涉及的電壓等級(jí)多、變電站數(shù)量多，站內(nèi)涉及的智能化二次設(shè)備種類(lèi)多、數(shù)量也多，而業(yè)務(wù)需求要達(dá)到板卡、網(wǎng)絡(luò)端口級(jí)運(yùn)維，首先面臨的是數(shù)據(jù)統(tǒng)一化接入問(wèn)題，其次是多站數(shù)據(jù)并發(fā)阻塞鏈路問(wèn)題，再次是高并發(fā)數(shù)據(jù)量持久化存儲(chǔ)與在線即時(shí)查詢(xún)問(wèn)題，而且在不影響業(yè)務(wù)需求的情況下要做到系統(tǒng)穩(wěn)定、可靠且具有一定的容錯(cuò)能力[4]。

1.1 架構(gòu)思路

站端運(yùn)維轉(zhuǎn)變?yōu)橹髡具\(yùn)維是一種新的運(yùn)維思路，隨著分布式大數(shù)據(jù)技術(shù)的成熟，這種人力運(yùn)維轉(zhuǎn)變?yōu)闄C(jī)器自動(dòng)化運(yùn)維成為可能。把傳統(tǒng)業(yè)務(wù)需求、站端數(shù)據(jù)、平臺(tái)框架技術(shù)松耦合考慮，發(fā)揮彼此的優(yōu)勢(shì)再整合為統(tǒng)一的大數(shù)據(jù)運(yùn)維平臺(tái)不失為一個(gè)好的思路。

設(shè)備統(tǒng)一建模技術(shù)是傳統(tǒng)業(yè)務(wù)的優(yōu)勢(shì)，各種智能電子設(shè)備(IED)能力描述(ICD)文件、變電站配置描述(SCD)文件、變電站配置描述語(yǔ)言(SCL)文件等模型文件已經(jīng)在變電站應(yīng)用多年，如果把這些模型文件與設(shè)備本身物理結(jié)構(gòu)或虛回路物理結(jié)構(gòu)相結(jié)合[5]，通過(guò)抽取相關(guān)有用屬性，生成新的模型文件為二次設(shè)備運(yùn)維服務(wù)是可能的，而這將能解決站端復(fù)雜數(shù)據(jù)的統(tǒng)一化接入問(wèn)題。統(tǒng)一建模后對(duì)平臺(tái)框架設(shè)計(jì)而言就不存在變電站與設(shè)備的情況，統(tǒng)一歸為帶身份標(biāo)志(mRid)的一條條信息。模型實(shí)例化后變?yōu)閿?shù)據(jù)，把數(shù)據(jù)從站端生成開(kāi)始進(jìn)行全局唯一性身份標(biāo)志，這樣就實(shí)現(xiàn)了數(shù)據(jù)與平臺(tái)框架的解耦，不管平臺(tái)框架如何變化，數(shù)據(jù)在自己全生命周期內(nèi)永遠(yuǎn)采用生成時(shí)的標(biāo)志不變，那么數(shù)據(jù)就會(huì)像血液一樣在平臺(tái)內(nèi)自由流動(dòng)，產(chǎn)生的每條事件信息就如血液中的細(xì)胞一樣，都存在自己的身份標(biāo)志，平臺(tái)將很容易捏取到每一條數(shù)據(jù)。例如，獲取220 kV×××變電站××交換機(jī)××板卡第3個(gè)網(wǎng)口的溫度或流量異常數(shù)據(jù)。而血管的粗細(xì)與擴(kuò)張度以及心臟跳動(dòng)的強(qiáng)度是影響血液流動(dòng)最重要的兩個(gè)因素，這部分將是大數(shù)據(jù)技術(shù)的優(yōu)勢(shì)所在。支持高并發(fā)、高吞吐量的可擴(kuò)展消息隊(duì)列、支持?jǐn)?shù)據(jù)sql查詢(xún)、并行內(nèi)存計(jì)算、實(shí)現(xiàn)數(shù)據(jù)互通功能的Presto、構(gòu)建數(shù)據(jù)倉(cāng)庫(kù)，實(shí)現(xiàn)數(shù)據(jù)無(wú)限存儲(chǔ)的分布式文件系統(tǒng)都是可以選用的[6-7]。

整個(gè)大數(shù)據(jù)運(yùn)維平臺(tái)的架構(gòu)過(guò)程就像構(gòu)建人體血液循環(huán)系統(tǒng)一樣，每個(gè)App應(yīng)用就像血液循環(huán)流經(jīng)的器官，不同的器官利用血液中細(xì)胞承載氧氣和營(yíng)養(yǎng)物質(zhì)發(fā)揮不同的作用，共同維護(hù)人的正常生命特征。

1.2 基礎(chǔ)架構(gòu)設(shè)計(jì)

根據(jù)1.1中描述的建模、身份標(biāo)志、數(shù)據(jù)中繼、分布式計(jì)算與存儲(chǔ)思路，結(jié)合分布式系統(tǒng)獨(dú)立、分層、區(qū)域自治的架構(gòu)策略，可以得到如圖1所示的架構(gòu)方案。

1.3 架構(gòu)分析與比較

1.2中描述的架構(gòu)設(shè)計(jì)層次分明，數(shù)據(jù)流向清晰；部件相對(duì)獨(dú)立，耦合性差；每層關(guān)注的重點(diǎn)不一，層與層之間安全隔離[8]。該架構(gòu)相比傳統(tǒng)運(yùn)維系統(tǒng)架構(gòu)有以下優(yōu)點(diǎn)：

根據(jù)題意，題目中的函數(shù)定義域?yàn)榉帜覆荒転?，也就是x>0，所以與題目相關(guān)的選項(xiàng)就是A,即只有A選項(xiàng)中的函數(shù)f(x)=lnx定義域?yàn)閤>0，B中定義域?yàn)閤不等于0，C選項(xiàng)和D選項(xiàng)中的函數(shù)定義域?yàn)閷?shí)數(shù)集R，所以正確答案為A.

(1)通用性強(qiáng)。平臺(tái)框架與數(shù)據(jù)分離，只要設(shè)備按建模規(guī)范進(jìn)行建模都可以采用上述架構(gòu)方案；而傳統(tǒng)運(yùn)維平臺(tái)對(duì)不同類(lèi)型設(shè)備各自建模，自建一套數(shù)據(jù)流轉(zhuǎn)，各個(gè)系統(tǒng)獨(dú)立，數(shù)據(jù)無(wú)法實(shí)現(xiàn)統(tǒng)一存儲(chǔ)與利用。

(2)安全性高。主子站通信除了采用同一套模型外，還要穿透防火墻與縱向加密通信。在數(shù)據(jù)進(jìn)入主站前先經(jīng)過(guò)前置采集再進(jìn)行正向隔離裝置防護(hù)，可以達(dá)到限流限速防惡意攻擊的效果。

(3)穩(wěn)定性高。利用消息隊(duì)列對(duì)大數(shù)據(jù)突發(fā)流量進(jìn)行削峰削谷，解決大數(shù)據(jù)量對(duì)主站功能部件的沖擊；利用統(tǒng)一訪問(wèn)接口與數(shù)據(jù)中繼部件，有效控制訪問(wèn)并發(fā)與身份權(quán)限，防止個(gè)別應(yīng)用App對(duì)資源的浪費(fèi)，同時(shí)引發(fā)某些組件不穩(wěn)定問(wèn)題。

(4)擴(kuò)展性好。架構(gòu)中的任何一個(gè)部件都可能根據(jù)業(yè)務(wù)容量與性能的需求進(jìn)行動(dòng)態(tài)擴(kuò)展，這是分布式架構(gòu)的特點(diǎn)，也是傳統(tǒng)運(yùn)維平臺(tái)無(wú)法實(shí)現(xiàn)的。

(5)容災(zāi)與備份能力強(qiáng)。系統(tǒng)在穩(wěn)定運(yùn)行過(guò)程中，個(gè)別節(jié)點(diǎn)出現(xiàn)宕機(jī)現(xiàn)象或硬件損壞不影響整個(gè)系統(tǒng)的運(yùn)行。分布式系統(tǒng)采用多副本機(jī)制，自帶備份功能。

子站端只需處理統(tǒng)一建模，子站與前置之間主要解決主子站通信，前置采集服務(wù)層主要進(jìn)行負(fù)載均衡與數(shù)據(jù)規(guī)整和分發(fā)，正向隔離裝置阻斷主子站間的安全隱患，大數(shù)據(jù)采集消息隊(duì)列解決突發(fā)數(shù)據(jù)對(duì)整個(gè)平臺(tái)的流量沖擊與分離業(yè)務(wù)數(shù)據(jù)的作用，基于Presto的快速查詢(xún)引擎實(shí)現(xiàn)平臺(tái)組件的高內(nèi)聚使用與數(shù)據(jù)的無(wú)障礙流轉(zhuǎn)[9]，統(tǒng)一服務(wù)接口層解決高并發(fā)訪問(wèn)問(wèn)題，應(yīng)用層可以打造統(tǒng)一的應(yīng)用軟件架構(gòu)降低開(kāi)發(fā)成本與時(shí)間，從而實(shí)現(xiàn)區(qū)域自治的策略應(yīng)用。

2 關(guān)鍵技術(shù)研究

特定領(lǐng)域的大數(shù)據(jù)平臺(tái)與傳統(tǒng)通用大數(shù)據(jù)平臺(tái)有很多差異之處。比如，本系統(tǒng)中的智能變電站二次設(shè)備運(yùn)維平臺(tái)結(jié)合了站端設(shè)備建模技術(shù)，把靜態(tài)設(shè)備虛擬化后存入大數(shù)據(jù)平臺(tái)，通過(guò)建模規(guī)則在平臺(tái)實(shí)現(xiàn)設(shè)備的動(dòng)態(tài)化，賦予設(shè)備新的生命，加速其在業(yè)務(wù)端的支撐能力；同時(shí)，對(duì)流入平臺(tái)的任何一個(gè)信號(hào)賦予全局的唯一性標(biāo)志，再實(shí)現(xiàn)虛擬信號(hào)到現(xiàn)實(shí)信號(hào)的轉(zhuǎn)化。這種基于信號(hào)本身自下而上的建模、存儲(chǔ)、計(jì)算、應(yīng)用一體化架構(gòu)方案使得系統(tǒng)有規(guī)可循，在不失靈活性的基礎(chǔ)上實(shí)現(xiàn)了信號(hào)本身應(yīng)用價(jià)值的提升。

圖1 平臺(tái)架構(gòu)Fig.1 Platform architecture

2.1 一體化建模技術(shù)實(shí)現(xiàn)數(shù)據(jù)的統(tǒng)一化接入

從設(shè)備制造階段開(kāi)始，經(jīng)過(guò)系統(tǒng)集成完成主子站統(tǒng)一化建模標(biāo)準(zhǔn)[10]。以IED為對(duì)象，在設(shè)備制造端根據(jù)ICD文件加IPD文件生成統(tǒng)一虛實(shí)對(duì)應(yīng)的變電站物理信息全景模型，再在系統(tǒng)集成階段融入SCD(IEC61850邏輯回路模型)文件和SPCD(物理回路模型)文件生成統(tǒng)一的公共信息模型(CIM)映射文件，實(shí)例化身份標(biāo)志后生成模型描述規(guī)范語(yǔ)言(CIM/E)格式的主子站交互模型文件(如圖2所示)，此模型設(shè)計(jì)遵循IEC 61970/61978規(guī)范[11-12]。

圖2 主子站交互模型CIM/E文件Fig.2 CIM/E file of master station and slave station interaction model

2.2 全局唯一性編碼設(shè)計(jì)實(shí)現(xiàn)子站到運(yùn)維主站的全域身份標(biāo)志

一體化建模規(guī)則解決了物理設(shè)備、虛回路、信號(hào)點(diǎn)到虛擬系統(tǒng)的映射和統(tǒng)一數(shù)據(jù)接入問(wèn)題，但無(wú)法解決數(shù)據(jù)的全域身份標(biāo)志問(wèn)題。把大數(shù)據(jù)運(yùn)維平臺(tái)(主站)當(dāng)作身體，那么數(shù)據(jù)就是流動(dòng)的血液，每個(gè)網(wǎng)口、板卡、網(wǎng)口流量等好比血液中的細(xì)胞，都應(yīng)該有自己的身份標(biāo)志，當(dāng)細(xì)胞出現(xiàn)問(wèn)題時(shí)，才能被平臺(tái)感知，精確定位，達(dá)到精細(xì)化運(yùn)維的目的。

圖3 全局唯一性身份識(shí)別碼Fig.3 Globally unique identification code

如圖3全局唯一性編碼規(guī)范所示，定制一套信息編碼規(guī)范數(shù)據(jù)字典，通過(guò)數(shù)據(jù)字典構(gòu)建統(tǒng)一的全局身份標(biāo)志。區(qū)域編碼參考國(guó)家出版的行政區(qū)域編碼，分隔標(biāo)志符采用“$”格式，廠站標(biāo)志有運(yùn)維公司統(tǒng)一分發(fā)，電壓等級(jí)標(biāo)志按實(shí)際電壓等級(jí)進(jìn)行數(shù)字編碼，間隔、小室、屏柜采用統(tǒng)一編碼，設(shè)備標(biāo)志采用設(shè)備出廠碼，板卡標(biāo)志采用板卡號(hào)，測(cè)點(diǎn)標(biāo)示根據(jù)測(cè)點(diǎn)類(lèi)型.測(cè)點(diǎn)名稱(chēng)進(jìn)行字典編碼，比如MX.LigIntes1R描述為自測(cè)量第1個(gè)光口的收功率，可以用Event標(biāo)志事件、Alm標(biāo)志告警等，實(shí)例號(hào)標(biāo)志為數(shù)字編碼，比如圖3的實(shí)例號(hào)1表示為第1塊CC板。

分隔符用“$”標(biāo)志，可以滿(mǎn)足對(duì)每個(gè)域的靈活編碼，生成的身份標(biāo)志碼采用字符串類(lèi)型進(jìn)行系統(tǒng)全局使用?？紤]到數(shù)據(jù)上送過(guò)程中冗余數(shù)據(jù)太多，占用帶寬太大，影響整個(gè)系統(tǒng)數(shù)據(jù)的采集、存儲(chǔ)與查詢(xún)效率，在主子站交互模型中生成的身份編碼刪除了設(shè)備編碼標(biāo)志前的編碼，刪除的部分作為基礎(chǔ)數(shù)據(jù)保存在關(guān)系模型庫(kù)中。

全局唯一性編碼標(biāo)志作為數(shù)據(jù)采集(上送)的key(主鍵)，Value(值)采用易于擴(kuò)展的Json格式。

2.3 基于Presto技術(shù)實(shí)現(xiàn)一體化數(shù)據(jù)中繼

Presto是專(zhuān)門(mén)為大數(shù)據(jù)實(shí)時(shí)查詢(xún)計(jì)算而設(shè)計(jì)和開(kāi)發(fā)的并行內(nèi)存計(jì)算產(chǎn)品，彌補(bǔ)了Hive實(shí)時(shí)查詢(xún)的空白。無(wú)論是對(duì)多數(shù)據(jù)源的支持，還是易用性、高性能、可擴(kuò)展性等方面，Presto都是大數(shù)據(jù)實(shí)時(shí)查詢(xún)計(jì)算產(chǎn)品中的佼佼者，它具有多數(shù)據(jù)源、支持 SQL、混合性計(jì)算、高性能、流水線等特點(diǎn)，并且具有很好的擴(kuò)展性[13]。

智能變電站二次設(shè)備在線故障運(yùn)維平臺(tái)采用Presto大數(shù)據(jù)搜索引擎作為平臺(tái)數(shù)據(jù)中繼主要有以下方面的考慮。

(1)Presto大數(shù)據(jù)查詢(xún)引擎可以非常容易地連接消息隊(duì)列Kafka、內(nèi)存數(shù)據(jù)庫(kù)Redis、關(guān)系模型庫(kù)Mysql及數(shù)據(jù)倉(cāng)庫(kù)Hive，這些組件是構(gòu)建智能變電站二次設(shè)備在線故障運(yùn)維平臺(tái)的主干，具有不可替代的作用?；赑resto catalog配置可以平滑地實(shí)現(xiàn)跨組件、跨庫(kù)統(tǒng)一接口訪問(wèn)，實(shí)現(xiàn)數(shù)據(jù)在彼此間的無(wú)任何阻礙流轉(zhuǎn)。

(2)Presto組件是Facebook開(kāi)發(fā)出來(lái)專(zhuān)門(mén)解決Hive查詢(xún)效率低問(wèn)題的，是Hive的升級(jí)版本，查詢(xún)效率是Hive的10倍以上，且有京東、美團(tuán)等大公司商業(yè)化應(yīng)用[14]，穩(wěn)定可靠，切合在線故障運(yùn)維業(yè)務(wù)的需求，能在用戶(hù)可接受的時(shí)間內(nèi)實(shí)現(xiàn)數(shù)據(jù)的查詢(xún)與流轉(zhuǎn)。

(3)Presto大數(shù)據(jù)查詢(xún)引擎可以作為消息中間件Kafka的查詢(xún)引擎，通過(guò)配置文件的方式可以使消息進(jìn)行結(jié)構(gòu)化，利用sql完成查詢(xún)與計(jì)算，對(duì)于故障事件發(fā)生前后6 s內(nèi)的時(shí)間有序消息序列的獲取起到非常關(guān)鍵的作用，可以滿(mǎn)足故障事件還原的業(yè)務(wù)需求。同時(shí)，由于數(shù)據(jù)域確定，數(shù)據(jù)量較少，可以基于Kafka的存儲(chǔ)功能實(shí)現(xiàn)T+0業(yè)務(wù)與即時(shí)查詢(xún)業(yè)務(wù)的快速響應(yīng)。

(4)解決大數(shù)據(jù)量并發(fā)接入與即時(shí)存儲(chǔ)速度不匹配的問(wèn)題。系統(tǒng)雖然采用周期+突發(fā)數(shù)據(jù)上送方式，也無(wú)法避免隨時(shí)的數(shù)據(jù)阻塞問(wèn)題，追其根源是高并發(fā)高吞吐量的消息隊(duì)列與hadoop分布式文件系統(tǒng)(HDFS)寫(xiě)入能力不匹配問(wèn)題，大量的故障告警事件擁堵在消息組件中無(wú)法實(shí)現(xiàn)持久化，就會(huì)導(dǎo)致數(shù)據(jù)無(wú)法使用。當(dāng)App得到故障告警通知后進(jìn)行故障事件還原時(shí)查詢(xún)不到數(shù)據(jù)，嚴(yán)重影響了系統(tǒng)的可靠性。

(5)解決Hive查詢(xún)中partition分區(qū)失效問(wèn)題。對(duì)于傳統(tǒng)大數(shù)據(jù)系統(tǒng)而言，事件發(fā)生時(shí)的時(shí)間戳為數(shù)據(jù)進(jìn)入平臺(tái)時(shí)的平臺(tái)時(shí)間，而智能變電站二次設(shè)備維護(hù)對(duì)故障告警的時(shí)間戳具有嚴(yán)格的時(shí)間序列性，這就導(dǎo)致數(shù)據(jù)必須采用站端監(jiān)控系統(tǒng)的時(shí)間戳；由于網(wǎng)絡(luò)環(huán)境等原因?qū)е聰?shù)據(jù)延遲上送或跨天數(shù)據(jù)分區(qū)時(shí)，就會(huì)導(dǎo)致本應(yīng)該在今天分區(qū)中的數(shù)據(jù)跑到了明天的分區(qū)中，直接導(dǎo)致Hive查詢(xún)效率大幅降低；系統(tǒng)對(duì)處理時(shí)間的不可控性導(dǎo)致在線業(yè)務(wù)的不穩(wěn)定，從而影響整個(gè)系統(tǒng)的穩(wěn)定性。

以上5點(diǎn)奠定了Presto技術(shù)在智能變電站二次設(shè)備在線故障運(yùn)維平臺(tái)中作為數(shù)據(jù)中繼的可行性與可用性。

3 支撐在線二次設(shè)備故障定位與智能檢修策略典型場(chǎng)景應(yīng)用

故障檢測(cè)與告警、故障事件還原、檢修策略推薦是智能變電站二次設(shè)備運(yùn)維中最核心的業(yè)務(wù)需求?；诒疚奶岢龅拇髷?shù)據(jù)運(yùn)維架構(gòu)來(lái)實(shí)現(xiàn)整個(gè)自動(dòng)化的過(guò)程如圖4所示。

圖4 故障定位與檢修策略Fig.4 Fault location and maintenance strategy

(1)劃分告警級(jí)別，確定故障告警。當(dāng)故障發(fā)生時(shí)，站端采集系統(tǒng)(監(jiān)控系統(tǒng))對(duì)告警事件進(jìn)行突發(fā)上送至消息隊(duì)列Kafka存儲(chǔ)(存儲(chǔ)最近2天的周期+突發(fā)數(shù)據(jù))。

(2)Consumer(實(shí)時(shí)消費(fèi)App)拉取Kafka消息主題(Topic)中的數(shù)據(jù)進(jìn)行按等級(jí)過(guò)濾，過(guò)濾出故障告警事件后推送給消息內(nèi)存庫(kù)Redis。

(3)應(yīng)用App訂閱內(nèi)存庫(kù)Redis中的信息通道，獲取故障告警事件推送給用戶(hù)，同時(shí)調(diào)用故障事件還原服務(wù)接口通過(guò)Presto數(shù)據(jù)查詢(xún)引擎獲取故障告警前后6 s的本站及相關(guān)站所有告警數(shù)據(jù)返回App。同時(shí)，復(fù)制一份數(shù)據(jù)存儲(chǔ)到數(shù)據(jù)倉(cāng)庫(kù)中作為檢修決策分析樣本源數(shù)據(jù)。

(4)調(diào)用機(jī)器學(xué)習(xí)服務(wù)接口，把分析樣本數(shù)據(jù)與專(zhuān)家知識(shí)庫(kù)中的訓(xùn)練結(jié)果集進(jìn)行分析，通過(guò)決策樹(shù)算法找出導(dǎo)致故障發(fā)生的可能原因，再通過(guò)關(guān)聯(lián)分析算法找出支持度與置信度最高數(shù)據(jù)集作為專(zhuān)家推薦內(nèi)容推送給檢修人員。

以業(yè)務(wù)為目標(biāo)，把傳統(tǒng)系統(tǒng)中的子系統(tǒng)設(shè)計(jì)為服務(wù)接口的方式，根據(jù)業(yè)務(wù)需求通過(guò)“順序調(diào)用，異步返回”的方式在一個(gè)應(yīng)用App中在線完成從故障告警到事件還原再到檢修策略的業(yè)務(wù)需求。

4 結(jié)論

在本文中，提出了對(duì)智能變電站二次設(shè)備本身建模的方法，并實(shí)現(xiàn)了主子站一體化交互模型；提出了對(duì)二次設(shè)備全生命周期身份標(biāo)志方案，實(shí)現(xiàn)了數(shù)據(jù)從子站到運(yùn)維主站的全域標(biāo)志，支撐了自動(dòng)化、精細(xì)化、智能化運(yùn)維業(yè)務(wù)，降低了運(yùn)維成本；找到了開(kāi)源大數(shù)據(jù)組件在智能變電站運(yùn)維業(yè)務(wù)中的實(shí)際應(yīng)用場(chǎng)景，通過(guò)工程證明其切實(shí)實(shí)現(xiàn)了傳統(tǒng)運(yùn)維系統(tǒng)無(wú)法實(shí)現(xiàn)的大數(shù)據(jù)統(tǒng)一接入、實(shí)時(shí)大數(shù)據(jù)量分析與數(shù)據(jù)挖掘算法的應(yīng)用等功能。本文中并沒(méi)有對(duì)每一個(gè)技術(shù)細(xì)節(jié)展開(kāi)描述，主要集中在業(yè)務(wù)到架構(gòu)的演變過(guò)程，提出了一些可行的方法和方案，難免存在不足之處，但可以在此平臺(tái)架構(gòu)基礎(chǔ)上擴(kuò)展到光伏電站、風(fēng)電站等運(yùn)維平臺(tái)。