1. 從“設(shè)備孤島”到“協(xié)同作戰(zhàn)”能源互聯(lián)網(wǎng)接入平臺(tái)到底在解決什么問(wèn)題做過(guò)能源項(xiàng)目的人都有一個(gè)共同感受現(xiàn)場(chǎng)設(shè)備五花八門(mén)光伏逆變器、儲(chǔ)能BMS、充電樁、智能電表、環(huán)境傳感器每一家廠商都有自己的通信協(xié)議和數(shù)據(jù)格式。光伏逆變器用Modbus TCP儲(chǔ)能BMS走CAN總線充電樁可能用OCPP電表又是DL/T 645。這些設(shè)備各自為政數(shù)據(jù)上不來(lái)指令下不去運(yùn)維人員只能一個(gè)個(gè)平臺(tái)切換著看效率低不說(shuō)出了故障排查起來(lái)更是要命。能源互聯(lián)網(wǎng)統(tǒng)一接入平臺(tái)要干的事情說(shuō)白了就是把這些“方言”翻譯成“普通話”讓所有設(shè)備在一個(gè)平臺(tái)上說(shuō)同一種語(yǔ)言。但這件事遠(yuǎn)沒(méi)有聽(tīng)起來(lái)那么簡(jiǎn)單。它不是裝一個(gè)協(xié)議轉(zhuǎn)換網(wǎng)關(guān)就完事了而是要從**信息物理系統(tǒng)CPS**的視角重新思考物理設(shè)備怎么映射到數(shù)字空間數(shù)據(jù)怎么在設(shè)備之間流轉(zhuǎn)控制指令怎么保證可靠送達(dá)設(shè)備之間的協(xié)同怎么做到自適應(yīng)我參與過(guò)幾個(gè)類似的平臺(tái)搭建項(xiàng)目從最初的兩三臺(tái)設(shè)備接入到后來(lái)上百臺(tái)設(shè)備同時(shí)在線踩過(guò)的坑可以說(shuō)覆蓋了從協(xié)議適配到數(shù)據(jù)建模再到協(xié)同調(diào)度的全鏈路。這篇文章就把這些經(jīng)驗(yàn)系統(tǒng)地梳理一遍重點(diǎn)講清楚CPS理念下設(shè)備協(xié)同與智能管理的核心設(shè)計(jì)思路和實(shí)操要點(diǎn)。如果你正在做能源管理平臺(tái)、物聯(lián)網(wǎng)接入網(wǎng)關(guān)、或者工業(yè)設(shè)備數(shù)據(jù)采集相關(guān)的項(xiàng)目這篇文章的內(nèi)容應(yīng)該能幫你少走不少?gòu)澛?。即便你是剛接觸這個(gè)領(lǐng)域的新手我也會(huì)盡量用生活化的類比把關(guān)鍵概念講透讓你能快速建立起對(duì)能源互聯(lián)網(wǎng)接入平臺(tái)的完整認(rèn)知。2. CPS理念落地物理設(shè)備如何映射到數(shù)字空間2.1 為什么傳統(tǒng)SCADA思路在能源互聯(lián)網(wǎng)場(chǎng)景下不夠用了傳統(tǒng)SCADA系統(tǒng)的核心邏輯是“采集-展示-告警”設(shè)備是啞終端平臺(tái)是大腦所有決策都在平臺(tái)側(cè)完成。這套思路在單一類型的設(shè)備場(chǎng)景下沒(méi)問(wèn)題比如一個(gè)光伏電站里全是同一品牌的逆變器SCADA完全夠用。但能源互聯(lián)網(wǎng)的場(chǎng)景要復(fù)雜得多。一個(gè)典型的園區(qū)能源系統(tǒng)可能同時(shí)包含光伏、儲(chǔ)能、充電樁、空調(diào)系統(tǒng)、照明系統(tǒng)這些設(shè)備來(lái)自不同廠商運(yùn)行邏輯各不相同。更關(guān)鍵的是它們之間需要協(xié)同——光伏發(fā)電多了儲(chǔ)能該充電還是該放電充電樁的功率要不要根據(jù)光伏出力動(dòng)態(tài)調(diào)整這些決策如果全部上傳到平臺(tái)再下發(fā)延遲不說(shuō)一旦網(wǎng)絡(luò)中斷整個(gè)系統(tǒng)就癱了。CPS的理念恰恰是要解決這個(gè)問(wèn)題。它的核心思想是在物理設(shè)備和數(shù)字空間之間建立一個(gè)雙向映射每個(gè)物理設(shè)備在數(shù)字空間里都有一個(gè)對(duì)應(yīng)的“數(shù)字孿生體”這個(gè)孿生體不僅包含設(shè)備的實(shí)時(shí)狀態(tài)還包含設(shè)備的能力描述、約束條件和協(xié)同規(guī)則。設(shè)備之間的協(xié)同可以在邊緣側(cè)完成不需要事事都請(qǐng)示平臺(tái)。2.2 設(shè)備數(shù)字孿生體的建模方法給設(shè)備建數(shù)字孿生體不是簡(jiǎn)單地存一個(gè)設(shè)備ID和幾個(gè)遙測(cè)點(diǎn)就完事了。一個(gè)完整的設(shè)備孿生體至少包含四層信息第一層是身份標(biāo)識(shí)。設(shè)備ID、廠商信息、型號(hào)、固件版本、安裝位置。這些信息看起來(lái)簡(jiǎn)單但在實(shí)際項(xiàng)目中經(jīng)常出問(wèn)題。比如同一型號(hào)的設(shè)備固件版本不同支持的寄存器地址可能就不一樣。我遇到過(guò)一批逆變器固件從V1.2升級(jí)到V1.3之后有功功率的寄存器地址從40001變成了40003如果沒(méi)有記錄固件版本數(shù)據(jù)采集就會(huì)出錯(cuò)。第二層是能力描述。這個(gè)設(shè)備能做什么能上報(bào)哪些數(shù)據(jù)能接受哪些控制指令每個(gè)數(shù)據(jù)點(diǎn)的類型、單位、量程、精度是多少控制指令的參數(shù)范圍是什么這些信息必須結(jié)構(gòu)化地描述出來(lái)平臺(tái)才能知道怎么跟設(shè)備交互。第三層是實(shí)時(shí)狀態(tài)。設(shè)備的當(dāng)前運(yùn)行數(shù)據(jù)、告警狀態(tài)、通信狀態(tài)。這一層是動(dòng)態(tài)變化的需要持續(xù)更新。第四層是協(xié)同規(guī)則。這個(gè)設(shè)備和其他設(shè)備之間的聯(lián)動(dòng)關(guān)系。比如儲(chǔ)能BMS需要知道光伏逆變器的實(shí)時(shí)出力才能決定充放電策略。這些規(guī)則可以配置在邊緣側(cè)也可以由平臺(tái)統(tǒng)一下發(fā)。建模的時(shí)候有一個(gè)容易忽略的點(diǎn)設(shè)備的能力描述要支持繼承和擴(kuò)展。比如所有逆變器都有“有功功率”這個(gè)數(shù)據(jù)點(diǎn)但不同型號(hào)的逆變器可能還有各自特有的數(shù)據(jù)點(diǎn)。如果每個(gè)型號(hào)都從頭定義一遍工作量巨大且容易出錯(cuò)。合理的做法是定義一個(gè)“逆變器基類”包含通用數(shù)據(jù)點(diǎn)然后各型號(hào)繼承基類并擴(kuò)展特有數(shù)據(jù)點(diǎn)。2.3 物模型設(shè)計(jì)中的幾個(gè)關(guān)鍵決策物模型是設(shè)備數(shù)字孿生體的具體實(shí)現(xiàn)形式。在設(shè)計(jì)物模型時(shí)有幾個(gè)決策會(huì)直接影響后續(xù)的開(kāi)發(fā)和運(yùn)維效率。第一個(gè)決策數(shù)據(jù)點(diǎn)用枚舉還是用字符串枚舉的好處是傳輸效率高、校驗(yàn)方便壞處是新增數(shù)據(jù)點(diǎn)需要改代碼。字符串的好處是靈活壞處是容易拼寫(xiě)錯(cuò)誤。我的經(jīng)驗(yàn)是核心數(shù)據(jù)點(diǎn)用枚舉擴(kuò)展數(shù)據(jù)點(diǎn)用字符串。核心數(shù)據(jù)點(diǎn)是指那些平臺(tái)邏輯強(qiáng)依賴的比如有功功率、SOC、通信狀態(tài)。擴(kuò)展數(shù)據(jù)點(diǎn)是指那些只用于展示和分析的比如設(shè)備溫度、累計(jì)發(fā)電量。第二個(gè)決策控制指令用同步還是異步同步指令是下發(fā)后等設(shè)備返回結(jié)果異步指令是下發(fā)后不等結(jié)果設(shè)備執(zhí)行完再上報(bào)。能源場(chǎng)景下大部分控制指令應(yīng)該用異步因?yàn)樵O(shè)備執(zhí)行需要時(shí)間同步等待會(huì)阻塞平臺(tái)。但有些緊急指令比如急停必須用同步確保指令送達(dá)。第三個(gè)決策數(shù)據(jù)上報(bào)用推還是用拉推模式是設(shè)備主動(dòng)上報(bào)拉模式是平臺(tái)定時(shí)查詢。推模式的實(shí)時(shí)性好但設(shè)備多的時(shí)候平臺(tái)壓力大。拉模式的可控性好但實(shí)時(shí)性差。實(shí)際項(xiàng)目中通常是混合模式關(guān)鍵數(shù)據(jù)用推非關(guān)鍵數(shù)據(jù)用拉。3. 協(xié)議適配層的工程實(shí)踐從Modbus到MQTT的完整鏈路3.1 南向協(xié)議適配的常見(jiàn)坑與解決方案南向協(xié)議適配是接入平臺(tái)最繁瑣的部分沒(méi)有之一。我做過(guò)統(tǒng)計(jì)一個(gè)中等規(guī)模的能源互聯(lián)網(wǎng)項(xiàng)目協(xié)議適配的工作量能占到總開(kāi)發(fā)量的40%以上。下面這張表列出了常見(jiàn)協(xié)議的特點(diǎn)和適配要點(diǎn)協(xié)議典型設(shè)備傳輸層數(shù)據(jù)模型適配難點(diǎn)Modbus TCP逆變器、電表TCP寄存器地址寄存器地址不統(tǒng)一字節(jié)序有大小端問(wèn)題Modbus RTU電表、傳感器串口寄存器地址需要串口服務(wù)器轉(zhuǎn)換輪詢效率低DL/T 645智能電表串口/紅外數(shù)據(jù)標(biāo)識(shí)協(xié)議版本多1997版和2007版差異大CAN總線儲(chǔ)能BMSCAN報(bào)文ID需要CAN轉(zhuǎn)以太網(wǎng)網(wǎng)關(guān)報(bào)文解析復(fù)雜OCPP充電樁WebSocketJSON協(xié)議版本多1.6和2.0差異大MQTT各類IoT設(shè)備TCPJSON/自定義主題設(shè)計(jì)要合理QoS等級(jí)要選對(duì)IEC 104電力自動(dòng)化設(shè)備TCP信息對(duì)象地址協(xié)議復(fù)雜調(diào)試工具少M(fèi)odbus的字節(jié)序問(wèn)題值得單獨(dú)說(shuō)一下。Modbus協(xié)議本身只定義了寄存器是16位的但沒(méi)有定義多個(gè)寄存器組成一個(gè)32位浮點(diǎn)數(shù)時(shí)哪個(gè)寄存器是高字哪個(gè)是低字。不同廠商的實(shí)現(xiàn)不一樣有的用大端有的用小端有的用混合端。我遇到過(guò)最離譜的情況是同一臺(tái)設(shè)備的不同數(shù)據(jù)點(diǎn)用了不同的字節(jié)序。解決辦法是在物模型里為每個(gè)數(shù)據(jù)點(diǎn)單獨(dú)配置字節(jié)序不要假設(shè)同一設(shè)備的所有數(shù)據(jù)點(diǎn)字節(jié)序一致。DL/T 645的版本差異也是個(gè)大坑。1997版和2007版的數(shù)據(jù)標(biāo)識(shí)定義完全不同而且2007版還有多個(gè)子版本。更麻煩的是很多電表廠商在標(biāo)準(zhǔn)協(xié)議基礎(chǔ)上做了私有擴(kuò)展。我的建議是先確認(rèn)電表的協(xié)議版本和廠商私有擴(kuò)展文檔不要拿著標(biāo)準(zhǔn)協(xié)議文檔就去調(diào)試大概率對(duì)不上。3.2 邊緣網(wǎng)關(guān)的選型與配置要點(diǎn)邊緣網(wǎng)關(guān)是連接現(xiàn)場(chǎng)設(shè)備和云平臺(tái)的橋梁。選型的時(shí)候不能只看價(jià)格和接口數(shù)量以下幾個(gè)參數(shù)必須重點(diǎn)關(guān)注CPU性能和內(nèi)存。如果網(wǎng)關(guān)需要同時(shí)處理幾十臺(tái)設(shè)備的協(xié)議解析和數(shù)據(jù)轉(zhuǎn)發(fā)低端ARM芯片可能扛不住。我建議至少選四核Cortex-A53以上、內(nèi)存1GB以上的網(wǎng)關(guān)。如果需要在網(wǎng)關(guān)側(cè)跑協(xié)同邏輯性能還要再往上提。協(xié)議支持能力。有的網(wǎng)關(guān)只支持Modbus和MQTT有的支持十幾種協(xié)議。但要注意支持協(xié)議多不代表每個(gè)協(xié)議都實(shí)現(xiàn)得好。有些網(wǎng)關(guān)的DL/T 645實(shí)現(xiàn)只支持讀不支持寫(xiě)有些網(wǎng)關(guān)的OCPP只支持1.6不支持2.0。選型時(shí)要針對(duì)項(xiàng)目實(shí)際需要的協(xié)議做驗(yàn)證。斷網(wǎng)續(xù)傳能力?，F(xiàn)場(chǎng)網(wǎng)絡(luò)不穩(wěn)定是常態(tài)網(wǎng)關(guān)必須支持?jǐn)嗑W(wǎng)時(shí)本地緩存數(shù)據(jù)網(wǎng)絡(luò)恢復(fù)后自動(dòng)補(bǔ)傳。緩存容量至少要能存24小時(shí)的數(shù)據(jù)否則網(wǎng)絡(luò)中斷時(shí)間長(zhǎng)一點(diǎn)數(shù)據(jù)就丟了。遠(yuǎn)程運(yùn)維能力。網(wǎng)關(guān)部署在現(xiàn)場(chǎng)出了問(wèn)題不可能每次都跑現(xiàn)場(chǎng)。網(wǎng)關(guān)要支持遠(yuǎn)程配置下發(fā)、遠(yuǎn)程重啟、遠(yuǎn)程固件升級(jí)。但遠(yuǎn)程升級(jí)有個(gè)坑升級(jí)過(guò)程中如果斷電網(wǎng)關(guān)可能變磚。所以網(wǎng)關(guān)要支持雙分區(qū)升級(jí)升級(jí)失敗自動(dòng)回滾。配置邊緣網(wǎng)關(guān)的時(shí)候有一個(gè)經(jīng)驗(yàn)值得分享采集周期不要設(shè)得太短。我見(jiàn)過(guò)有人把Modbus輪詢周期設(shè)成100ms結(jié)果網(wǎng)關(guān)CPU跑滿數(shù)據(jù)還丟包。實(shí)際上大部分能源設(shè)備的數(shù)據(jù)變化沒(méi)那么快光伏逆變器的有功功率1秒采集一次足夠了電表的電量數(shù)據(jù)5秒采集一次也沒(méi)問(wèn)題。采集周期要根據(jù)數(shù)據(jù)變化速率來(lái)定不是越短越好。3.3 北向數(shù)據(jù)上云的格式設(shè)計(jì)與傳輸優(yōu)化數(shù)據(jù)從邊緣網(wǎng)關(guān)傳到云平臺(tái)格式設(shè)計(jì)和傳輸策略直接影響平臺(tái)的性能和成本。格式設(shè)計(jì)方面JSON是最常用的但JSON的冗余比較大。如果設(shè)備多、數(shù)據(jù)量大可以考慮用MessagePack或者Protobuf。我做過(guò)對(duì)比測(cè)試同樣的數(shù)據(jù)量Protobuf的傳輸體積只有JSON的30%左右解析速度也快不少。但Protobuf的缺點(diǎn)是調(diào)試不方便需要額外的工具才能看懂?dāng)?shù)據(jù)內(nèi)容。傳輸策略方面MQTT是最主流的選擇。用MQTT有幾個(gè)關(guān)鍵決策QoS等級(jí)怎么選QoS 0是最多一次QoS 1是至少一次QoS 2是恰好一次。能源數(shù)據(jù)大部分可以用QoS 1允許少量重復(fù)但不能丟?？刂浦噶罱ㄗh用QoS 2確保不重復(fù)執(zhí)行。QoS 0只適合那些丟了也無(wú)所謂的數(shù)據(jù)比如環(huán)境溫度。主題怎么設(shè)計(jì)主題設(shè)計(jì)要兼顧可讀性和查詢效率。我常用的格式是{產(chǎn)品ID}/{設(shè)備類型}/{設(shè)備ID}/{數(shù)據(jù)類型}比如energy/inverter/INV001/telemetry。這樣訂閱的時(shí)候可以用通配符批量訂閱比如energy/inverter//telemetry訂閱所有逆變器的遙測(cè)數(shù)據(jù)。心跳和遺囑怎么配MQTT的心跳間隔要合理設(shè)置。太短了浪費(fèi)流量太長(zhǎng)了設(shè)備離線檢測(cè)不及時(shí)。我一般設(shè)60秒心跳配合遺囑消息設(shè)備離線后平臺(tái)能及時(shí)感知。4. 設(shè)備協(xié)同調(diào)度的核心機(jī)制從規(guī)則引擎到自適應(yīng)策略4.1 規(guī)則引擎的設(shè)計(jì)與實(shí)現(xiàn)設(shè)備協(xié)同的基礎(chǔ)是規(guī)則引擎。規(guī)則引擎要解決的核心問(wèn)題是當(dāng)某個(gè)條件滿足時(shí)自動(dòng)觸發(fā)某個(gè)動(dòng)作。比如“當(dāng)光伏出力大于儲(chǔ)能充電功率時(shí)降低充電樁充電功率”。規(guī)則引擎的設(shè)計(jì)有幾個(gè)關(guān)鍵點(diǎn)規(guī)則的表達(dá)方式。最簡(jiǎn)單的做法是用JSON描述規(guī)則比如{ name: 光伏余電充電, condition: { type: comparison, source: inverter.INV001.activePower, operator: , target: storage.BMS001.chargePower }, action: { type: set, target: charger.CH001.maxPower, value: ${inverter.INV001.activePower - storage.BMS001.chargePower} } }這種方式的優(yōu)點(diǎn)是靈活不需要改代碼就能新增規(guī)則。缺點(diǎn)是復(fù)雜規(guī)則表達(dá)起來(lái)很啰嗦而且容易寫(xiě)錯(cuò)。規(guī)則的執(zhí)行時(shí)機(jī)。規(guī)則是在邊緣側(cè)執(zhí)行還是平臺(tái)側(cè)執(zhí)行邊緣側(cè)執(zhí)行響應(yīng)快但規(guī)則更新麻煩。平臺(tái)側(cè)執(zhí)行更新方便但依賴網(wǎng)絡(luò)。我的建議是實(shí)時(shí)性要求高的規(guī)則放邊緣側(cè)比如安全聯(lián)鎖策略性規(guī)則放平臺(tái)側(cè)比如經(jīng)濟(jì)調(diào)度。規(guī)則的沖突處理。多條規(guī)則同時(shí)觸發(fā)時(shí)可能產(chǎn)生沖突。比如一條規(guī)則說(shuō)“儲(chǔ)能充電”另一條規(guī)則說(shuō)“儲(chǔ)能放電”。解決沖突的方法有兩種一是給規(guī)則設(shè)優(yōu)先級(jí)高優(yōu)先級(jí)的規(guī)則覆蓋低優(yōu)先級(jí)的二是做規(guī)則合并把沖突的規(guī)則合并成一個(gè)綜合決策。實(shí)際項(xiàng)目中優(yōu)先級(jí)方案更簡(jiǎn)單可靠。4.2 多設(shè)備協(xié)同的場(chǎng)景拆解能源互聯(lián)網(wǎng)場(chǎng)景下的設(shè)備協(xié)同可以歸納為幾種典型模式主從協(xié)同。一臺(tái)主設(shè)備指揮多臺(tái)從設(shè)備。比如儲(chǔ)能BMS作為主設(shè)備指揮多臺(tái)PCS儲(chǔ)能變流器協(xié)同充放電。這種模式的關(guān)鍵是主設(shè)備的決策邏輯要可靠從設(shè)備的執(zhí)行要一致。對(duì)等協(xié)同。多臺(tái)設(shè)備地位平等通過(guò)協(xié)商達(dá)成一致。比如多臺(tái)充電樁之間分配總功率限額。這種模式的關(guān)鍵是協(xié)商算法要收斂不能出現(xiàn)死循環(huán)。層級(jí)協(xié)同。設(shè)備分組組內(nèi)協(xié)同組間再協(xié)同。比如一個(gè)園區(qū)有多個(gè)微電網(wǎng)每個(gè)微電網(wǎng)內(nèi)部先協(xié)同然后微電網(wǎng)之間再協(xié)同。這種模式的關(guān)鍵是層級(jí)之間的信息傳遞要高效。以光儲(chǔ)充協(xié)同為例一個(gè)典型的協(xié)同邏輯是這樣的光伏優(yōu)先供負(fù)荷余電給儲(chǔ)能充電儲(chǔ)能充滿后余電給充電樁。如果光伏出力不足儲(chǔ)能放電補(bǔ)充充電樁功率降低。這個(gè)邏輯看起來(lái)簡(jiǎn)單但實(shí)際實(shí)現(xiàn)時(shí)要考慮很多邊界條件儲(chǔ)能SOC過(guò)高或過(guò)低怎么處理充電樁沒(méi)有車(chē)在充怎么辦光伏出力波動(dòng)大怎么平滑4.3 協(xié)同策略的自適應(yīng)優(yōu)化固定規(guī)則的協(xié)同策略在簡(jiǎn)單場(chǎng)景下夠用但在復(fù)雜場(chǎng)景下往往不是最優(yōu)的。比如峰谷電價(jià)場(chǎng)景下儲(chǔ)能應(yīng)該在谷時(shí)充電、峰時(shí)放電但具體充多少、放多少固定規(guī)則很難給出最優(yōu)解。自適應(yīng)優(yōu)化的思路是讓系統(tǒng)根據(jù)歷史數(shù)據(jù)和實(shí)時(shí)狀態(tài)動(dòng)態(tài)調(diào)整策略。常用的方法有基于規(guī)則的動(dòng)態(tài)調(diào)整。規(guī)則不變但規(guī)則中的參數(shù)根據(jù)狀態(tài)動(dòng)態(tài)調(diào)整。比如儲(chǔ)能充電閾值不是固定的而是根據(jù)次日光伏預(yù)測(cè)出力和負(fù)荷預(yù)測(cè)來(lái)動(dòng)態(tài)計(jì)算。基于模型的優(yōu)化。建立系統(tǒng)的數(shù)學(xué)模型用優(yōu)化算法求解最優(yōu)策略。比如用線性規(guī)劃求解儲(chǔ)能充放電計(jì)劃目標(biāo)函數(shù)是電費(fèi)最小化。這種方法的優(yōu)點(diǎn)是理論最優(yōu)缺點(diǎn)是需要準(zhǔn)確的模型參數(shù)而且計(jì)算量大?；趶?qiáng)化學(xué)習(xí)的優(yōu)化。讓系統(tǒng)通過(guò)試錯(cuò)學(xué)習(xí)最優(yōu)策略。這種方法的優(yōu)點(diǎn)是不需要精確模型缺點(diǎn)是訓(xùn)練時(shí)間長(zhǎng)而且在實(shí)際系統(tǒng)中試錯(cuò)有風(fēng)險(xiǎn)。實(shí)際項(xiàng)目中我建議先用基于規(guī)則的動(dòng)態(tài)調(diào)整等系統(tǒng)運(yùn)行穩(wěn)定、數(shù)據(jù)積累夠了再考慮引入更復(fù)雜的優(yōu)化方法。上來(lái)就搞強(qiáng)化學(xué)習(xí)大概率會(huì)翻車(chē)。5. 平臺(tái)側(cè)智能管理的幾個(gè)關(guān)鍵能力5.1 設(shè)備全生命周期管理設(shè)備從接入到退役整個(gè)生命周期都需要管理。這包括接入管理。設(shè)備第一次接入時(shí)要完成注冊(cè)、認(rèn)證、物模型綁定。注冊(cè)時(shí)要校驗(yàn)設(shè)備身份防止非法設(shè)備接入。認(rèn)證可以用證書(shū)或者密鑰。物模型綁定是把設(shè)備的實(shí)際上報(bào)數(shù)據(jù)和物模型定義關(guān)聯(lián)起來(lái)。狀態(tài)監(jiān)控。實(shí)時(shí)監(jiān)控設(shè)備的在線狀態(tài)、通信質(zhì)量、數(shù)據(jù)質(zhì)量。通信質(zhì)量可以用丟包率、延遲、誤碼率來(lái)衡量。數(shù)據(jù)質(zhì)量可以用數(shù)據(jù)完整性、合理性、時(shí)效性來(lái)衡量。告警管理。設(shè)備異常時(shí)產(chǎn)生告警告警要分級(jí)、去重、關(guān)聯(lián)。分級(jí)是按嚴(yán)重程度分比如緊急、重要、次要、提示。去重是避免同一故障反復(fù)告警。關(guān)聯(lián)是把相關(guān)告警合并成一個(gè)故障事件方便排查。運(yùn)維管理。包括遠(yuǎn)程配置、遠(yuǎn)程升級(jí)、遠(yuǎn)程診斷。遠(yuǎn)程配置要支持配置模板批量下發(fā)。遠(yuǎn)程升級(jí)要支持灰度發(fā)布先升級(jí)少量設(shè)備驗(yàn)證沒(méi)問(wèn)題再全量升級(jí)。退役管理。設(shè)備退役時(shí)要解綁物模型、清理數(shù)據(jù)、回收資源。退役設(shè)備的歷史數(shù)據(jù)要保留但可以降冷存儲(chǔ)。5.2 數(shù)據(jù)質(zhì)量治理的實(shí)操方法數(shù)據(jù)質(zhì)量是智能管理的基礎(chǔ)。數(shù)據(jù)質(zhì)量不好再好的算法也白搭。數(shù)據(jù)質(zhì)量問(wèn)題主要有幾類數(shù)據(jù)缺失。設(shè)備離線、通信中斷、采集失敗都會(huì)導(dǎo)致數(shù)據(jù)缺失。處理方法是插值補(bǔ)全或者標(biāo)記缺失。插值可以用線性插值、均值插值、或者基于模型的預(yù)測(cè)插值。標(biāo)記缺失是把缺失時(shí)間段的數(shù)據(jù)標(biāo)記出來(lái)分析時(shí)排除。數(shù)據(jù)異常。數(shù)據(jù)超出合理范圍、變化率異常、長(zhǎng)時(shí)間不變都可能是異常。處理方法是檢測(cè)和修正。檢測(cè)可以用閾值法、統(tǒng)計(jì)法、機(jī)器學(xué)習(xí)法。修正可以用替換、平滑、或者標(biāo)記異常。數(shù)據(jù)不一致。同一數(shù)據(jù)在不同來(lái)源不一致比如電表讀數(shù)和逆變器讀數(shù)對(duì)不上。處理方法是校驗(yàn)和對(duì)齊。校驗(yàn)可以用能量守恒、功率平衡等物理約束。對(duì)齊可以用時(shí)間對(duì)齊和單位對(duì)齊。我做過(guò)一個(gè)數(shù)據(jù)質(zhì)量治理的項(xiàng)目發(fā)現(xiàn)最有效的方法不是復(fù)雜的算法而是建立數(shù)據(jù)質(zhì)量規(guī)則庫(kù)。把常見(jiàn)的質(zhì)量問(wèn)題歸納成規(guī)則比如“有功功率不能為負(fù)”、“SOC必須在0到100之間”、“數(shù)據(jù)變化率不能超過(guò)量程的10%每秒”。這些規(guī)則簡(jiǎn)單但有效能解決80%以上的數(shù)據(jù)質(zhì)量問(wèn)題。5.3 從數(shù)據(jù)到?jīng)Q策智能分析能力的構(gòu)建平臺(tái)積累了數(shù)據(jù)之后要能從中提取價(jià)值。智能分析能力包括幾個(gè)層次描述性分析。發(fā)生了什么比如發(fā)電量統(tǒng)計(jì)、用電量統(tǒng)計(jì)、設(shè)備利用率統(tǒng)計(jì)。這是最基礎(chǔ)的分析大部分平臺(tái)都能做。診斷性分析。為什么發(fā)生比如設(shè)備效率下降的原因分析、發(fā)電量不達(dá)標(biāo)的原因分析。這需要建立設(shè)備模型和故障樹(shù)。預(yù)測(cè)性分析。將要發(fā)生什么比如光伏出力預(yù)測(cè)、負(fù)荷預(yù)測(cè)、設(shè)備故障預(yù)測(cè)。這需要用到時(shí)間序列分析、機(jī)器學(xué)習(xí)等方法。處方性分析。應(yīng)該怎么做比如儲(chǔ)能充放電策略優(yōu)化、設(shè)備維護(hù)計(jì)劃優(yōu)化。這需要用到優(yōu)化算法和決策模型。實(shí)際項(xiàng)目中大部分平臺(tái)停留在描述性分析階段能做到診斷性分析的就不多了。我的建議是先把描述性分析做扎實(shí)數(shù)據(jù)準(zhǔn)確、及時(shí)、完整然后再逐步往上走。不要一上來(lái)就搞預(yù)測(cè)性分析數(shù)據(jù)質(zhì)量不過(guò)關(guān)預(yù)測(cè)結(jié)果就是垃圾。6. 實(shí)戰(zhàn)中踩過(guò)的坑與應(yīng)對(duì)經(jīng)驗(yàn)6.1 協(xié)議適配中的“靈異事件”排查做協(xié)議適配最怕遇到“靈異事件”——數(shù)據(jù)時(shí)對(duì)時(shí)不對(duì)或者偶爾出現(xiàn)離譜的值。我遇到過(guò)幾次分享出來(lái)供大家參考。第一次是Modbus浮點(diǎn)數(shù)解析錯(cuò)誤。某臺(tái)逆變器的有功功率大部分時(shí)候讀出來(lái)是正常的但偶爾會(huì)讀出一個(gè)特別大的值。排查了半天發(fā)現(xiàn)是字節(jié)序問(wèn)題。這臺(tái)逆變器的浮點(diǎn)數(shù)用了混合端序高字在前但高字內(nèi)部又是小端。這種非標(biāo)準(zhǔn)的字節(jié)序在標(biāo)準(zhǔn)文檔里根本找不到只能靠試。第二次是DL/T 645的地址偏移。某批電表按照標(biāo)準(zhǔn)協(xié)議文檔數(shù)據(jù)標(biāo)識(shí)是00 00 00 00但實(shí)際讀出來(lái)全是零。后來(lái)發(fā)現(xiàn)這批電表用了私有擴(kuò)展數(shù)據(jù)標(biāo)識(shí)要加一個(gè)偏移量。這個(gè)偏移量在廠商的私有文檔里才有。第三次是MQTT消息亂序。邊緣網(wǎng)關(guān)用QoS 1上報(bào)數(shù)據(jù)平臺(tái)收到的數(shù)據(jù)偶爾會(huì)亂序。原因是QoS 1只保證至少一次不保證順序。解決辦法是在消息里加時(shí)間戳和序列號(hào)平臺(tái)側(cè)做排序。排查這類問(wèn)題的通用方法是先確認(rèn)協(xié)議版本和廠商私有擴(kuò)展再用抓包工具看原始報(bào)文最后用最小系統(tǒng)法逐步排除。不要一上來(lái)就懷疑代碼大部分問(wèn)題出在協(xié)議理解上。6.2 設(shè)備協(xié)同中的時(shí)序問(wèn)題與解決設(shè)備協(xié)同對(duì)時(shí)序很敏感。我遇到過(guò)這樣一個(gè)場(chǎng)景光伏出力下降時(shí)儲(chǔ)能應(yīng)該增加放電充電樁應(yīng)該降低功率。但實(shí)際運(yùn)行時(shí)儲(chǔ)能還沒(méi)開(kāi)始放電充電樁已經(jīng)降功率了導(dǎo)致負(fù)荷缺額。這個(gè)問(wèn)題的根源是指令下發(fā)和執(zhí)行有時(shí)延。儲(chǔ)能PCS從收到指令到實(shí)際出力變化有幾百毫秒到幾秒的延遲。充電樁的功率調(diào)整也有延遲。如果協(xié)同邏輯不考慮這些延遲就會(huì)出現(xiàn)時(shí)序錯(cuò)配。解決辦法有兩種一是加延時(shí)補(bǔ)償在指令里帶上預(yù)期執(zhí)行時(shí)間設(shè)備按時(shí)間執(zhí)行。二是做閉環(huán)反饋平臺(tái)檢測(cè)到實(shí)際出力變化后再下發(fā)下一步指令。第一種方法簡(jiǎn)單但精度有限第二種方法精度高但響應(yīng)慢。實(shí)際項(xiàng)目中我通常用第一種方法做粗調(diào)第二種方法做細(xì)調(diào)。6.3 平臺(tái)性能瓶頸的定位與優(yōu)化平臺(tái)設(shè)備多了之后性能問(wèn)題就來(lái)了。常見(jiàn)的瓶頸有數(shù)據(jù)庫(kù)寫(xiě)入瓶頸。每秒幾萬(wàn)條數(shù)據(jù)寫(xiě)入關(guān)系型數(shù)據(jù)庫(kù)扛不住。解決辦法是換時(shí)序數(shù)據(jù)庫(kù)比如InfluxDB、TDengine。時(shí)序數(shù)據(jù)庫(kù)針對(duì)時(shí)間序列數(shù)據(jù)做了優(yōu)化寫(xiě)入性能比關(guān)系型數(shù)據(jù)庫(kù)高一個(gè)數(shù)量級(jí)。消息隊(duì)列積壓。設(shè)備上報(bào)的數(shù)據(jù)量超過(guò)平臺(tái)處理能力消息隊(duì)列開(kāi)始積壓。解決辦法是增加消費(fèi)者、優(yōu)化消費(fèi)邏輯、或者做數(shù)據(jù)降采樣。降采樣是把高頻數(shù)據(jù)聚合成低頻數(shù)據(jù)比如把秒級(jí)數(shù)據(jù)聚合成分鐘級(jí)數(shù)據(jù)。規(guī)則引擎性能瓶頸。規(guī)則多了之后每次數(shù)據(jù)變化都要遍歷所有規(guī)則性能下降。解決辦法是做規(guī)則索引只檢查與當(dāng)前數(shù)據(jù)相關(guān)的規(guī)則。比如按設(shè)備ID索引規(guī)則數(shù)據(jù)變化時(shí)只檢查該設(shè)備的規(guī)則。定位性能瓶頸的方法先監(jiān)控再分析最后優(yōu)化。監(jiān)控要覆蓋CPU、內(nèi)存、磁盤(pán)IO、網(wǎng)絡(luò)IO、數(shù)據(jù)庫(kù)、消息隊(duì)列等關(guān)鍵指標(biāo)。分析要找到瓶頸點(diǎn)是CPU密集還是IO密集。優(yōu)化要針對(duì)瓶頸點(diǎn)不要盲目?jī)?yōu)化。7. 關(guān)于這個(gè)領(lǐng)域的一些個(gè)人體會(huì)做能源互聯(lián)網(wǎng)接入平臺(tái)這幾年最大的感受是技術(shù)不是最難的最難的是對(duì)業(yè)務(wù)的理解。協(xié)議適配、數(shù)據(jù)建模、規(guī)則引擎這些技術(shù)都有成熟的方案。但具體到某個(gè)項(xiàng)目光伏該怎么協(xié)同、儲(chǔ)能該怎么調(diào)度、充電樁該怎么分配功率這些需要深入理解能源系統(tǒng)的運(yùn)行邏輯。另一個(gè)感受是標(biāo)準(zhǔn)化和靈活性要平衡。物模型要標(biāo)準(zhǔn)化否則設(shè)備多了沒(méi)法管理。但標(biāo)準(zhǔn)化不能太死要留擴(kuò)展空間否則新設(shè)備接不進(jìn)來(lái)。我的經(jīng)驗(yàn)是核心數(shù)據(jù)點(diǎn)嚴(yán)格標(biāo)準(zhǔn)化擴(kuò)展數(shù)據(jù)點(diǎn)允許自定義。核心協(xié)同邏輯標(biāo)準(zhǔn)化特殊協(xié)同邏輯允許腳本擴(kuò)展。還有一個(gè)體會(huì)是邊緣和云端的職責(zé)要?jiǎng)澐智宄＿吘墏?cè)負(fù)責(zé)實(shí)時(shí)采集、協(xié)議轉(zhuǎn)換、安全聯(lián)鎖、本地協(xié)同。云端負(fù)責(zé)數(shù)據(jù)存儲(chǔ)、歷史分析、策略優(yōu)化、全局協(xié)同。不要把實(shí)時(shí)性要求高的邏輯放云端也不要把需要全局?jǐn)?shù)據(jù)的邏輯放邊緣。最后分享一個(gè)實(shí)用技巧在項(xiàng)目初期就建立設(shè)備接入的標(biāo)準(zhǔn)化流程。包括設(shè)備注冊(cè)模板、物模型定義模板、協(xié)議適配測(cè)試用例、接入驗(yàn)收清單。這個(gè)流程建立起來(lái)之后新設(shè)備接入的效率能提升好幾倍。我見(jiàn)過(guò)太多項(xiàng)目每接一臺(tái)新設(shè)備都要重新摸索一遍浪費(fèi)了大量時(shí)間。