服務熱線
18971653633
-
風電場SCADA跨平臺軟件設計說明
發布時間： 2022-05-05 點擊次數： 2342次一、項目概況風場監控系統布置于風場監控室內，由風機監控系統、風電場功率管理系統（能量管理系統）、第三方接口系統組成。其主要包括風機監控、數據采集、數據存儲、數據查詢、數據呈現、Web發布、風機管理、風場調度、安全審計等功能。二、項目需求需求內容主要包括操作系統平臺要求、網絡結構模式要求、通訊接口要求、通訊協議要求、數據存儲記錄要求、數據挖掘要求、UI呈現要求、Web發布要求、調度要求等。乙方按照雙方協定的技術協議內容設計開發，主要設計方案應經過甲方的方案評審，若在開發過程中，甲方需求變更，雙方應協商需求的合理性及技術可行性并最終形成新增補協議，若涉及開發成本的增加，通過商務條款補充。具體需求請詳見《需求說明書》。三、項目部署風電場SCADA軟件系統是風電場遠程控制系統的組成部分，風電場遠程控制系統由網絡通訊系統、風電場SCADA軟件系統組成。風電場遠程控制系統的網絡通訊、服務器、操作員站、操作系統等由甲方提供，乙方保證在甲方提供的通訊網絡、服務器系統上能正常運行乙方所供的SCADA軟件系統。甲方所供網絡通訊及服務器部署如下圖1。
風電場網絡通訊采用光纜傳輸，風機與風機之間的網絡拓撲結構采用可自愈式以太環網結構，風場級拓撲結構為多環結構。風機機艙與塔基之間的連接光纜為多模光纜。風機與風機之間及風機與監控中心之間的連接均為單模光纜。風場通訊網絡環內采用100M光纖以太網絡。核心交換機與風場監控系統服務器的接口采用1000M以太網。
硬件系統包括數采服務器2臺、數據服務器2臺、應用服務器2臺（應用服務器通常與數采服務器合二為一）、發布機1臺、I/O機1臺，操作員站1臺、若干安全隔離設備。其中，數據服務器存放歷史數據，具體實施過程中，甲方可根據風場規模進行服務器配置，小規模風場可將數采服務器、數據服務器、應用服務器合而為一，對于大規模風場可部署多臺數采服務器、數據服務器及應用服務器，軟件采用模塊化設計，可部署于同一臺服務器也可分別部署。
服務器采用龍芯3C5000L服務器處理器芯片，2.2G/16核，基于*自主的LoongArch®龍芯指令系統，支持雙路、四路機架式及塔式、高密度等多種服務器及存儲產品形態。雙路32核服務器具備高性價比，四路64核服務器性能好，算力強。龍芯3C5000L完善支持Docker、KVM等虛擬化應用，適合數據中心、云計算以及高性能計算等領域廣泛應用。詳細參數如下。
四、軟件設計說明
將軟件分為三層，其組成和框架如下圖2。
關于該系統開發，軟件部署主要包括風機數采服務器程序、應用服務器程序、數據服務器程序、發布機程序、I/O機程序。
將該監控系統程序根據功能結構劃分為三層，采集層、服務層、前端網站，每部分均可根據服務器分布情況獨立安裝部署，程序之間均采用標準UDP或TCP協議。
I/O機主要完成協議轉換及第三方接口通訊功能，主要通訊協議均部署在該服務器，在實際應用中，各技術協議是以應用的方式呈現的，可根據系統程序框架，自由添加協議，可對每個協議進程進行添加、關閉和配置。按照程序開發架構方式，各通訊協議均可部署至任何一臺服務器。
發布機包含了完整的網站服務、UI、網閘通訊、歷史數據記錄及查詢功能，將風機數據發布至公網，可遠程訪問查看該風場狀態。
（一）軟件架構
根據軟件的三層結構，軟件的設計框架如圖3所示。
1、SCADA展示層，首先需通過“檔案管理”模塊，錄入風機模塊信息，并導入模塊點表；
2、根據模塊信息組合出風機類型，配置風機相關的通信參數；
3、數據服務的部分，根據配置的風機相關信息，生成數采所需的配置信息：如鏈路配置，IO點表信息，創建風機通信的模塊；
4、風機配置完成后，數采的部分開始工作：各個通信模塊通過點表信息，采集風機的數據，并將數據寫入實時數據緩存；
5、實時數據rtdb緩存將數據進行整理，分發給不同的應用模塊
6、實時數據模塊：指令通道，用于單獨處理SCADA下發的指令，并將指令下發給數采來控制風機；emqx主要用于SCADA頁面的實時數據訂閱/發布；redis主要用于緩存實時數據，并緩存一些統計信息；
7、能量管理算法模塊：處理風場本地調度、電網調度、集控調度；并將調度的過程進行記錄；
8、歷史數據的部分是通過實時數據的接口進行周期或者變位存盤；并定期做數據調度，處理統計信息；并需根據主控上傳的報警信息，處理報警數據的存盤；
9、SCADA展示層數據源從兩個方面獲?。簩崟r數據主要通過訂閱的方式從實時數據區獲?。粴v史統計信息主要從歷史數據庫中獲??；
（二）通信層設計
1、風機設備模型：如圖4所示。
1）.根據不同的風機類型點表，對點表進行抽象分類，并對分類的數據點進行編碼，并生成數據點表；
2）.數據點表可以在檔案管理里面進行相關的處理；
3）.展示層所有的標量數據顯示都是根據指標碼的形式反向查詢數據檔案進行顯示；
2、數據傳輸流程：如圖5所示。
1）.數采的部分采用成熟的QTouch采集軟件框架，里面涵蓋豐富的設備通信驅動，保證現場所有的設備能夠正常聯網通信；所有的數據進入實時共享內存區，供其它接口實時訪問；
2）.在數采服務器與數據服務器分離的情況下，前置服務器用于接收數采傳輸的實時數據，此部分需代碼重新開發調整
3）.報警引擎的部分：需在QTouch的報警體系下進行重定義代碼級開發調整；
4）.消息中間件：采集第三方emqx消息中間件，redis實時數據緩存；用做數據的實時訂閱和發布（此功能需代碼開發調整）；
5）.此部分會用到兩套emqx中間件：一套用作頁面實時展示的數據，一套用作控制下發的操作，確保控制的實時有效而不受其它模塊影響
6）.一套redis實時數據緩存服務：主要用于頁面的實時曲線數據緩存部分的數據；
7）.原始數據直接根據接收端的數據緩存直接存儲：此部分需代碼級開發
8）.根據業務邏輯，將數據進行分庫分表存儲：如，分鐘、小時、天、月、年進行分表存儲；業務邏輯存儲部分，單一個模塊，直接從實時數據庫中獲取數據；
9）.分表策略；仍然以風機為單位，單個風機分為模擬量表、開關量表（模擬量和開關量分開，主要是因為模擬量可以按照秒級存儲，開關量按照狀態變化來存儲）；以橫向存儲為原則，即單個風機在一個時刻存儲在數據庫中為一條數據；
10）.web發布：采用成熟的apache web服務器框架進行發布應用，前端采用的是SSM框架進行代碼開發；
11）.與第三方數據交互主要采用OPC UA、或者104等通信協議來進行交互；
（三）服務引用層
1.系統服務
整個系統提供七大服務：數采服務、消息中間件服務、存儲數據服務、數據服務、數據調度服務、數據推送服務、web服務，如圖6所示：
2.服務集群部署：如圖7所示
（四）數據庫層
1.功能與數據流向圖
從原始數據進入系統到數據輸出到前端供WEB系統應用，整個數據流向分為：原始數據、數據預處理、數據應用三個階段。
原始數據，即由前置通訊解析完成后所取得的設備數據，此數據不作任何二次計算。在原始數據中，由于數據存儲的頻率到秒級、要求存儲的周期至少3個月，設備數量在300臺左右，因此在原始數據的存儲上以設備為單位進行分表。則300臺設備其原始數據為300套數據單元表。
數據預處理：為提高系統訪問速度，給予前端應用良好的體驗效果，故應以最小的延時時間讓用戶盡快獲取到數據。在原始數據進入數據庫后，再根據應用功能的要求進行數據的二次計算，包括發電量、故障統計、風速統計，也包括最大值、最小值等數據的計算。整個數據的預處理，將會在后臺以不同的頻率時行調度執行，執行完成的結果寫入固定的數據表中，再給其它功能調度使用。
數據應用：數據應用的直接體現為用戶前端的數據查詢。根據分表的原則，以秒級為單位，則單臺風機的月累計數據量為：86400條，連續保存三個月，則為：26萬條。數據應用查詢以單臺風機查詢時，可以保持良好的體驗。
2.實體和屬性
實體是實體-關系模型的基本對象，是現實案例中各種事物的抽象。凡是可以相互區別并可以被識別的事、物、概念等對象均可認為是實體。本系統數據庫中，以單臺風機為基礎，按實體進行劃分如下：
數據分表
2.1原始表
①表命名規則：
fan_sto_風機編號_sec_201901 : 秒級存儲(按月、風機編號分表)
fan_sto_風機編號_min : 分級存儲(按月、風機編號分表)
fan_sto_風機編號_hour : 時級存儲(按月、風機編號分表)
fan_sto_風機編號_day : 天級存儲(按月、風機編號分表)
②外鍵關聯：
sto_field_id 風場編號 >>關聯>>dwf_field風場表的dwf_id
sto_fan_id 風機編號 >>關聯>>dgf_fan風場表的dgf_id
③取值方案：
原始表根據數據類型分為：模擬量。模擬量根據數據粒度分為：秒級、分鐘級、小時級，其中，秒級存儲原始值；分鐘級存儲整分時刻原始值；小時級存儲整點時刻原始值；
④原始數據存儲及自動創表原則：
原始數據儲存單風機一個月數據，自動創建數據表。自動創建數據表可以調用存儲過程，亦可以在代碼中創建。
⑤表數據容量估算：
秒級數據單月存儲量：60秒*60分*24小時*31天=268萬
分鐘級數據單月存儲量：60分*24小時*31天=4.46萬
原始數據表結構：
數字量存儲：
①表命名規則：
fan_std_風機編號_年份 : 開關量量化即儲存（按年、風機編號分表）
②外鍵關聯：
std_field_id 風場編號 >>關聯>>dwf_field風場表的dwf_id
std_fan_id 風機編號 >>關聯>>dgf_fan風場表的dgf_id
③取值方案：
開關量量化即儲存
④原始數據存儲及自動創表原則：
每臺風機每年一張表，自動創建數據表。自動創建數據表可以調用存儲過程，亦可以在代碼中創建。
⑤表數據容量估算：
單表一年數據：41次*365天*200開關量=299萬
即每天風機的所有開關量平均變化不超過41次時，單表一年數據不超成功300萬條
2.2實時表
實時表主要用來存儲單臺風機實時數據，單臺實時數據包括：實時值、狀態值、統計值和靜態檔案。
實時值：實時刷新風機的參數值由消息隊列推送于前端應用。另外一部分實時值包括氣象數據、箱變信息也一并由消息隊列推送于前端應用。
狀態值：風機運行狀態由設備端上送風機狀態，（變化上送和存儲）主動存儲到設備狀態數據表中。
統計值：由歷史數據進行統計，包括：日發電量、月發電量，報警數據量，累計運行時間、累計維護次數等統計值。
設備檔案：包括設備編號、設備類型等靜態信息。
2.3設備狀態
設備狀態，主要記錄風機通訊狀態變化。當風機發生故障，通訊中斷時通知系統用戶。當風機排除故障，通訊恢復正常后通知系統用戶。設備狀態以變位方式存儲。
2.4統計表
統計表主要針對37項統計項，分為自由統計和報表下載；自由統計由：普通統計、分段統計、風玫瑰圖報表、功率曲線報表組成；報表下載由：日報表、月報表、年報表、日分段報表、月分段報表、年分段報表、損失電量報表、時間可利用率報表、發電量可利用率報表組成。
37項統計方法說明如下：
發電量：查詢首尾時間的總發電量相減；
耗電量：查詢首尾時間的耗電量相減；
風機可以用率：1-（風機自身故障小時數/統計小時數）；
最小風速：查詢時間段內的瞬時風速取最小值；
最大風速：查詢時間段內的瞬時風速取最大值；
平均風速：查詢時間段內的瞬時風速進行累加/查詢到的記錄條數；
最小有功功率：查詢時間段內的有功功率取最小值；
最大有功功率：查詢時間段內的有功功率取最大值；
平均有功功率：查詢時間段內的有功功率累加/查詢到的記錄條數
最小無功功率：查詢時間段內的無功功率取最小值；
最大無功功率：查詢時間段內的無功功率取最大值；
平均無功功率：查詢時間段內的無功功率累加/查詢到的記錄條數
低環境溫度：查詢時間段內的環境溫度取最小值；
最高環境溫度：查詢時間段內的環境溫度取最大值；
平均環境溫度：查詢時間段內的環境溫度進行累加/查詢到的記錄條數；
有效風小時數：查詢首尾時間的有效風小時數相減；
有效風時率：有效風小時數/統計小時數*100%；
風機可用小時數：風機正常運行小時數+非風機自身故障停機小時數；
風機正常運行小時數：查詢首尾時間的風機正常運行時間相減；
發電小時數：查詢首尾時間的發電小時相減；
停運小時數：統計總時間-統計時間段的風機正常運行小時數；
故障停機小時數；查詢首尾時間的故障停機時間相減；
風機自身故障停機小時數：查詢首尾時間的風機自身故障停機時間相減；
非風機自身故障停機小時數：故障停機小時數-風機自身故障停機小時數；
維護小時數：查詢首尾時間的服務時間相減；
故障停機次數：查詢時間段內的故障為TRUE的記錄條數；
風機自身故障停機次數：查詢時間段內的風機自身故障停機為TRUE的記錄條數；
非風機自身故障停機次數：故障停機次數-風機自身故障停機次數；
維護次數：查詢時間段內的工作模式為維護的記錄條數；
并網次數：查詢時間段內的并網為TRUE的記錄條數；
偏航次數：左偏次數+右偏次數；
左偏次數：偏航在逆時針運行模式為TRUE的記錄條數；
右偏次數：偏航在順時針運行模式為TRUE的記錄條數；
滿發小時數：統計周期內風機發電量/風機容量；
人工停機小時數：查詢首尾時間的人工停機時間相減；
環境溫度過低停機小時數：查詢首尾時間的環境溫度過低停機時間相減；
風暴停機小時數：查詢首尾時間的風暴停機時間相減；
3.數據庫主從熱備
數據庫主從熱備目前行業通用的工具是使用:keepalive實現主從熱備，無縫切換。其配置簡單，實用性高。keepalived的作用是檢測后端TCP服務的狀態，如果有一臺提供TCP服務的后端節點死機，或者工作出現故障，keepalived會及時檢測到，并將有故障的節點從系統中剔除，當提供TCP服務的節點恢復并且正常提供服務后keepalived會自動將TCP服務的節點加入到集群中。這些工作都是keepalived自動完成，不需要人工干涉。
KeepAlive主機配置：
KeepAlive從機配置：
