一種基于云平臺的風(fēng)機(jī)故障數(shù)據(jù)中心的制作方法
【技術(shù)領(lǐng)域】
[0001] 本發(fā)明屬于信息技術(shù)領(lǐng)域，涉及風(fēng)電場信息化控制領(lǐng)域，具體是一種基于云平臺 的風(fēng)機(jī)故障數(shù)據(jù)中心。
【背景技術(shù)】
[0002] 隨著新能源的大力發(fā)展，風(fēng)能已成為全球電力能源中不可或缺的一部分。截至 2010年，風(fēng)力發(fā)電占世界供電總量的2%。風(fēng)電行業(yè)迅猛發(fā)展，但風(fēng)電機(jī)組在線監(jiān)測和故障 診斷系統(tǒng)相對滯后，造成風(fēng)電機(jī)組事故多發(fā)，維護(hù)成本升高。
[0003] 截至2011年，我國已有約4.5萬臺風(fēng)電機(jī)組需要20-30年的后續(xù)維護(hù)。對于工作壽 命為20年的機(jī)組，運(yùn)行維護(hù)成本估計占風(fēng)場收入的10%~15%;對于海上風(fēng)場，用于風(fēng)力機(jī) 運(yùn)行維護(hù)的成本高達(dá)風(fēng)場收入的20%~25%。2011年底，我國風(fēng)電裝機(jī)總量已超過6200萬 千瓦，這意味著約4.5萬臺風(fēng)電機(jī)組需要20-30年的后續(xù)維護(hù)。
[0004] 傳統(tǒng)的機(jī)組維修以計劃維修和事后維修為主，計劃檢修帶有較大的盲目性，據(jù)統(tǒng) 計1/3的費(fèi)用屬于維修過剩，而事后檢修容易造成故障的擴(kuò)大化。至2020年將有約10萬臺風(fēng) 電機(jī)組向上級監(jiān)控中心傳送機(jī)組狀態(tài)數(shù)據(jù)。風(fēng)電場遠(yuǎn)程故障診斷中心將面臨海量的數(shù)據(jù)處 理和數(shù)據(jù)安全存儲問題。
[0005] 風(fēng)力發(fā)電機(jī)組主要由風(fēng)輪及變槳距系統(tǒng)、輪轂、傳動裝置、齒輪箱、發(fā)電機(jī)、電氣系 統(tǒng)、控制系統(tǒng)、剎車系統(tǒng)、液壓系統(tǒng)和偏航系統(tǒng)等構(gòu)成。作為大型低速旋轉(zhuǎn)設(shè)備，風(fēng)力發(fā)電機(jī) 組的故障主要集中在葉片、齒輪箱和發(fā)電機(jī)，常見的故障有：葉片斷裂、齒輪損傷、軸承磨 損、軸系不平衡、不對中以及電氣故障等。
[0006] 傳統(tǒng)的模式不能最大限度地發(fā)揮計算機(jī)和網(wǎng)絡(luò)的優(yōu)勢，主要體現(xiàn)在：
[0007] (1)現(xiàn)場工作站的計算機(jī)是一個信息的孤島；
[0008] (2)數(shù)據(jù)的安全性沒有保障；
[0009] (3)現(xiàn)有風(fēng)場的SCADA系統(tǒng)已實(shí)現(xiàn)了電氣參數(shù)、過程參數(shù)和少數(shù)振動參數(shù)的集中監(jiān) 測，其中振動信號僅用于超幅報警，數(shù)據(jù)采樣間隔一般在秒級，不能用于故障診斷；
[0010] (4)振動測點(diǎn)一般采用高頻采樣，一臺機(jī)組一天的數(shù)據(jù)總量約32G，雖然可以對設(shè) 備進(jìn)行間歇采樣和數(shù)據(jù)壓縮處理，但仍面臨海量數(shù)據(jù)的存儲和傳輸問題。
[0011]把云平臺引入到風(fēng)電機(jī)組故障診斷，在云平臺的模式中，遠(yuǎn)程故障診斷由"服務(wù) 器、客戶端"向"云服務(wù)平臺、客戶端"轉(zhuǎn)變。對于風(fēng)電企業(yè)，其風(fēng)場分布范圍廣，企業(yè)內(nèi)檢測 系統(tǒng)的計算機(jī)數(shù)量龐大，設(shè)計一種能夠把這些計算機(jī)整合到一個云平臺下的方法，有效地 利用系統(tǒng)內(nèi)的計算機(jī)，形成強(qiáng)大的故障診斷、數(shù)據(jù)挖掘平臺，達(dá)到數(shù)據(jù)共享、資源共享。

【發(fā)明內(nèi)容】

[0012] 本發(fā)明的目的在于提供一種基于云平臺的風(fēng)機(jī)故障數(shù)據(jù)中心，以解決上述背景技 術(shù)中提出的問題，為實(shí)現(xiàn)上述目的，本發(fā)明提供如下技術(shù)方案：
[0013] -種基于云平臺的風(fēng)機(jī)故障數(shù)據(jù)中心，包括云實(shí)時歷史數(shù)據(jù)庫系統(tǒng)、關(guān)系型數(shù)據(jù) 庫系統(tǒng)、風(fēng)機(jī)運(yùn)行狀態(tài)數(shù)據(jù)采集裝置、風(fēng)機(jī)運(yùn)行狀態(tài)數(shù)據(jù)并行計算模塊、風(fēng)機(jī)故障預(yù)警模 塊、風(fēng)機(jī)故障診斷模塊、人機(jī)交互接口；所述云實(shí)時歷史數(shù)據(jù)庫系統(tǒng)接收來自風(fēng)機(jī)運(yùn)行狀態(tài) 數(shù)據(jù)采集裝置采集的風(fēng)機(jī)運(yùn)行實(shí)時參數(shù)，云實(shí)時歷史數(shù)據(jù)庫系統(tǒng)向風(fēng)機(jī)運(yùn)行狀態(tài)數(shù)據(jù)并行 計算模塊提供風(fēng)機(jī)運(yùn)行數(shù)據(jù);所述關(guān)系型數(shù)據(jù)庫系統(tǒng)通過人機(jī)交互接口接收風(fēng)電場操作人 員手工錄入的風(fēng)機(jī)設(shè)備額定參數(shù)，以及故障預(yù)警有關(guān)參數(shù)，作為風(fēng)機(jī)運(yùn)行狀態(tài)數(shù)據(jù)并行計 算模塊提供設(shè)備基礎(chǔ)數(shù)據(jù);所述風(fēng)機(jī)運(yùn)行狀態(tài)數(shù)據(jù)采集裝置采集風(fēng)機(jī)運(yùn)行的實(shí)時參數(shù)數(shù) 據(jù)，并對數(shù)據(jù)進(jìn)行預(yù)處理，存入云歷史實(shí)時數(shù)據(jù)庫系統(tǒng)中；所述風(fēng)機(jī)運(yùn)行狀態(tài)數(shù)據(jù)并行計算 模塊對云歷史實(shí)時數(shù)據(jù)庫系統(tǒng)中的實(shí)時數(shù)據(jù)進(jìn)行運(yùn)算，抽取故障特征，并將結(jié)果存入云歷 史實(shí)時數(shù)據(jù)庫系統(tǒng)中；所述風(fēng)機(jī)故障預(yù)警模塊和風(fēng)機(jī)故障診斷模塊對云歷史實(shí)時數(shù)據(jù)庫系 統(tǒng)中的故障特征數(shù)據(jù)和關(guān)系型數(shù)據(jù)庫系統(tǒng)中的有關(guān)參數(shù)進(jìn)行處理，發(fā)出預(yù)警信息，并進(jìn)行 診斷。
[0014]作為本發(fā)明的進(jìn)一步方案:所述企業(yè)級私有云平臺能夠?qū)︼L(fēng)機(jī)運(yùn)行狀態(tài)數(shù)據(jù)并行 計算模塊、風(fēng)機(jī)故障預(yù)警模塊、風(fēng)機(jī)故障診斷模塊的并行計算集群和云實(shí)時歷史數(shù)據(jù)庫系 統(tǒng)、關(guān)系型數(shù)據(jù)庫系統(tǒng)所分配的軟硬件資源和應(yīng)用系統(tǒng)實(shí)現(xiàn)統(tǒng)一、自動化管理。
[0015]作為本發(fā)明的再進(jìn)一步方案:所述企業(yè)級云計算平臺是基于Hadoop(分布式系統(tǒng) 基礎(chǔ)架構(gòu))平臺建立的控制體系。
[0016] 作為本發(fā)明的再進(jìn)一步方案:其特征在于，所述企業(yè)級云計算平臺，作業(yè)調(diào)度采用 雙隊列調(diào)度器結(jié)構(gòu)。
[0017] 作為本發(fā)明的再進(jìn)一步方案：所述雙隊列調(diào)度器結(jié)構(gòu)，采用最早截止時間優(yōu)先 (m)F)的軟件實(shí)時調(diào)度算法，并不要求作業(yè)必須在截止時間以前完成，然后根據(jù)作業(yè)的優(yōu)先 級以及啟動時間來選擇作業(yè)，完成期限早的作業(yè)會被優(yōu)先執(zhí)行。
[0018]作為本發(fā)明的再進(jìn)一步方案:所述企業(yè)級云計算平臺，基于Hadoop平臺的推測執(zhí) 行機(jī)制，JobTracker (任務(wù)管理服務(wù)器，節(jié)點(diǎn))會定期地計算各個作業(yè)所有任務(wù)的執(zhí)行進(jìn)度， 只考慮同一個節(jié)點(diǎn)上的某一個任務(wù)，假定該任務(wù)為T，其在計算節(jié)點(diǎn)A上執(zhí)行；由于 JobTracker可獲知所有任務(wù)的執(zhí)行進(jìn)度，某作業(yè)的任務(wù)T在距離當(dāng)前時間最近的時刻teased 的進(jìn)度為progress[tci0sed] (tedosed時刻進(jìn)度），在tedosed- A h時刻的進(jìn)度為progress[tci0Sed-A h]，利用在最近一個A h內(nèi)任務(wù)進(jìn)度的平均增長量與該任務(wù)在0到tcdc^d- A h這段時間內(nèi) 的任務(wù)進(jìn)度的平均增長量進(jìn)行比較，用方差來探測任務(wù)的執(zhí)行情況，公式如下所示：
[0020]其中progressi代表某一段時間內(nèi)的進(jìn)度增長量（i = 1，2，i = 1時表示在0到 tclosed- A h時間內(nèi)的增長量，而i = 1表不在tclosed- A h到tclosed時間段內(nèi)的任務(wù)增長量），而 pr〇greSSavg表示從0時刻到tca_d時刻的任務(wù)平均增長進(jìn)度，也即這段時間內(nèi)的平均進(jìn)度增 長率。
[0021]作為本發(fā)明的再進(jìn)一步方案:基于Hadoop平臺的推測執(zhí)行機(jī)制，如果該方差超過 某一閥值時，則說明該任務(wù)運(yùn)行過慢，該任務(wù)所屬作業(yè)的完成時間就取決于該任務(wù)的完成 時間，需要為這個任務(wù)啟動一個備份任務(wù)，以加快該任務(wù)所處理數(shù)據(jù)分片的處理速度。 [0022] 作為本發(fā)明的再進(jìn)一步方案：雙隊列調(diào)度器結(jié)構(gòu)和SlowNode選擇策略，在一個 Hadoop集群中TaskTracker(任務(wù)執(zhí)行節(jié)點(diǎn)）的集合用S來表示，S= {Ti，T2，…，Tn}，其中Ti代 表TaSkTracker，Ti的性能C(Ti)主要從Slot的數(shù)量n、CPU的頻率C(f)、內(nèi)存容量C(m)、磁盤容 量 C(d)以及網(wǎng)絡(luò)帶寬 C(V)為指標(biāo)，以1\)=1^*11*(：出)+1?*(：(11〇+1?*(：((^)+1^(：(￥山其中沽 為各項指標(biāo)所占的比重，用來指定各項指標(biāo)在進(jìn)行負(fù)載計算時所占的比例，k越大，說明這 項指標(biāo)對負(fù)載的影響越大，其中，1^=(0.2,0.3,0,0.5)，在實(shí)際應(yīng)用過程中根據(jù)情況進(jìn)行適 當(dāng)?shù)恼{(diào)整;TaskTracker的負(fù)載L(Ti)主要依據(jù)Slot的使用率L(slot)，內(nèi)存使用率L(m)，磁 盤使用率L(d)以及網(wǎng)絡(luò)帶寬使用率L(v):
[0023] L(Ti) =ki X L(sloti)+k2 XL(mi)+k3 X L(di)+k4X L(vi