這幾年做物聯(lián)網(wǎng)項目我最大的感觸是設(shè)備臺賬、組態(tài)、運(yùn)維這三件事聽著都是設(shè)備管理的一部分但真正把它們做成一個流暢閉環(huán)的平臺十個里面有八個是瘸腿的。有的平臺臺賬做得漂亮組態(tài)確是一堆死圖有的組態(tài)交互驚艷設(shè)備一出故障又退回Excel報修的老路還有的把設(shè)備管理做成了數(shù)據(jù)看板只管顯示不管處理。這篇文章想聊聊從實際項目里摸出來的物聯(lián)網(wǎng)平臺設(shè)備管理功能設(shè)計思路圍繞**設(shè)備臺賬資產(chǎn)建模、組態(tài)可視化聯(lián)動、運(yùn)維工單閉環(huán)**三條主線拆開講附帶貫穿全文的三泵排水泵站案例。無論你是在選型現(xiàn)成平臺還是打算自研設(shè)備管理模塊或者只是想把平臺的設(shè)備功能用透這篇文章的實操細(xì)節(jié)都可以直接拿去用。1. 先把設(shè)備管理拆開看臺賬、組態(tài)、運(yùn)維各管哪一段在很多人的認(rèn)知里物聯(lián)網(wǎng)平臺的設(shè)備管理就是一個設(shè)備列表點(diǎn)進(jìn)去能看到在線狀態(tài)、數(shù)據(jù)曲線最多再加個遠(yuǎn)程控制按鈕。但從真正跑過生產(chǎn)項目的角度看這種理解會直接導(dǎo)致平臺建成后沒人用。設(shè)備管理不是一張表而是一條完整的資產(chǎn)閉環(huán)設(shè)備從采購入庫、安裝調(diào)試、接入平臺、運(yùn)行監(jiān)控、故障維修到報廢退場每個階段都有數(shù)據(jù)要管、有操作要做。1.1 三個模塊的職責(zé)邊界我習(xí)慣用三個詞來概括這個閉環(huán)底賬、臉面、命脈。模塊核心職責(zé)一句話描述對應(yīng)角色設(shè)備臺賬管理設(shè)備的靜態(tài)信息、組織結(jié)構(gòu)、物模型定義給設(shè)備建立數(shù)字戶口設(shè)備管理員、實施工程師組態(tài)將設(shè)備數(shù)據(jù)投射為可視化圖形界面把設(shè)備畫出來并動起來項目經(jīng)理、組態(tài)設(shè)計人員運(yùn)維承載告警、工單、巡檢、維修等日常運(yùn)行動作保證設(shè)備持續(xù)可用運(yùn)維工程師、值班人員很多人都搞混了組態(tài)和看板看板是數(shù)據(jù)的匯總展示偏統(tǒng)計組態(tài)是設(shè)備的狀態(tài)復(fù)現(xiàn)偏控制與模擬。泵站里的三臺潛污泵看板告訴你今天1號泵運(yùn)行了6小時組態(tài)畫面上1號泵在轉(zhuǎn)、電流有波動、管路的顏色隨液位變化這兩種信息密度完全不一樣。同樣運(yùn)維也不是簡單發(fā)告警短信而是把告警、工單、處理結(jié)果和設(shè)備檔案連起來形成可追溯的處理記錄。1.2 常見的設(shè)備管理功能設(shè)計偏差我見過的失敗案例問題幾乎都出在模塊割裂上。第一種是臺賬獨(dú)立和實際運(yùn)行脫節(jié)。臺賬里設(shè)備狀態(tài)是在用可平臺的監(jiān)控數(shù)據(jù)早在三天前就沒有這條設(shè)備的上報了。第二種是組態(tài)炫技按鈕一大堆但點(diǎn)了之后沒有任何動作記錄控制操作不可追溯這在泵站這種有人審核機(jī)制的工業(yè)場景里會造成管理混亂。第三種是運(yùn)維全靠人工平臺只負(fù)責(zé)彈告警告警之后的搶修派單、處理結(jié)果記錄又回到微信群里進(jìn)行時間一長數(shù)據(jù)就斷鏈了。這三條功能線必須綁定在同一套設(shè)備檔案數(shù)據(jù)之上前端的操作和后臺的狀態(tài)同步更新。這個思想會貫穿后面所有設(shè)計細(xì)節(jié)。2. 設(shè)備臺賬表面是填表本質(zhì)是給設(shè)備建數(shù)字戶口設(shè)備臺賬是整個過程的地基。地基如果打得草率后續(xù)組態(tài)綁點(diǎn)會綁錯、運(yùn)維工單沒法關(guān)聯(lián)設(shè)備、統(tǒng)計報表的數(shù)據(jù)也對不上。做臺賬前務(wù)必先回答三個問題設(shè)備唯一標(biāo)識用什么設(shè)備的組織結(jié)構(gòu)怎么分層每臺設(shè)備有哪些動靜態(tài)屬性2.1 設(shè)備標(biāo)識的設(shè)計不要只用設(shè)備編號做主鍵很多平臺把設(shè)備編號當(dāng)成唯一標(biāo)識這個編號通常是設(shè)備類型流水號的短字符串。實際跑起來會發(fā)現(xiàn)一個致命問題設(shè)備的物理位置變化后編號要不要跟著變泵站里3號泵這個稱呼是它在泵房的位置工程人員習(xí)慣這樣叫。但在平臺里假設(shè)3號泵維護(hù)之后換了一臺新泵如果臺賬把新泵直接頂替3號泵的記錄那這臺泵的歷史曲線和維修記錄全都斷了如果給它一個新編號工程人員又不認(rèn)識了。踩過這個坑之后我現(xiàn)在的設(shè)計固定采用三層標(biāo)識體系物理資產(chǎn)ID平臺內(nèi)部生成的全局唯一IDGUID一物一ID終身不變業(yè)務(wù)編碼也就是3號泵1號液位計允許隨位置、用途變化調(diào)整物聯(lián)標(biāo)識設(shè)備與平臺通信的鑒權(quán)標(biāo)識如設(shè)備ID/API Key跟隨網(wǎng)關(guān)或模組綁定三者分離通過臺賬的關(guān)系表映射。物理資產(chǎn)ID保證資產(chǎn)歷史連續(xù)業(yè)務(wù)編碼保證人可讀可交流物聯(lián)標(biāo)識保證通信獨(dú)立。新泵替換舊泵只需要在臺賬中將業(yè)務(wù)編碼重新映射到新的物理資產(chǎn)ID再掛接通信通道歷史記錄可以隨業(yè)務(wù)編碼延續(xù)同時新設(shè)備也有自己的獨(dú)立檔案。2.2 組織結(jié)構(gòu)與設(shè)備樹項目-站點(diǎn)-設(shè)備-部件的層級設(shè)計設(shè)備臺賬必須支持樹形組織模型。以泵站項目為例有城市A泵站、城市B泵站兩個站點(diǎn)每個站點(diǎn)下有3臺潛污泵、1臺液位計、1臺流量計、1套PLC控制柜控制柜里又包含CPU模塊、模擬量輸入模塊、繼電器輸出模塊。樹形結(jié)構(gòu)設(shè)計時至少要預(yù)留五層項目層整個工程的一級分組比如某市排水設(shè)施智能化項目站點(diǎn)/區(qū)域?qū)游锢砦恢梅纸M比如城西泵站設(shè)備層可獨(dú)立運(yùn)維的最小完整設(shè)備比如1號潛污泵部件層設(shè)備內(nèi)部的可替換部件比如1號泵電機(jī)1號泵軸承通道層設(shè)備的通信通道比如1號泵的PLC AI_3模擬量通道這個層級不是擺設(shè)它直接決定了運(yùn)維工單該派給誰、備品備件該關(guān)聯(lián)到哪一級。比如電機(jī)軸承損壞工單關(guān)聯(lián)到的是部件層維修需要換的備件是SKF 6319深溝球軸承兩者通過層級關(guān)系聚合到1號潛污泵的維修記錄里后續(xù)做單臺設(shè)備的故障統(tǒng)計分析時才能算得清。2.3 臺賬字段設(shè)計靜態(tài)屬性與動態(tài)屬性必須分表設(shè)備屬性建表時很多新手把設(shè)備型號、安裝日期、當(dāng)前電壓、上次維修時間塞在一個大寬表里。這會產(chǎn)生嚴(yán)重問題運(yùn)行數(shù)據(jù)高頻變化、歷史值沒有留痕下次出問題連什么時候開始異常的都查不到。正確做法是分三類存屬性類型特征典型字段存儲方式靜態(tài)屬性極少變化設(shè)備型號、廠家、安裝日期、保修期臺賬主表動態(tài)屬性高頻變化實時電流、液位、流量、運(yùn)行狀態(tài)時序數(shù)據(jù)庫運(yùn)維屬性低頻變化但有歷史上次檢修時間、維修次數(shù)、更換的備件變更履歷表動態(tài)屬性不是臺賬要存的別往臺賬里寫定時任務(wù)上報的液位值臺賬只管配置這個設(shè)備有哪些測點(diǎn)測點(diǎn)的數(shù)據(jù)歸到時序庫。運(yùn)維屬性則需要記錄每次變更前后值例如上次檢修時間從5月1日改成9月10日要留存修改人、修改時間、原因備注保證臺賬回溯能力。2.4 物模型讓臺賬成為組態(tài)和運(yùn)維的數(shù)據(jù)字典做物聯(lián)網(wǎng)平臺設(shè)備管理不做物模型的話后面組態(tài)和運(yùn)維寸步難行。物模型就是把設(shè)備的每個可感知、可控制的能力形式化定義包括屬性、服務(wù)、事件三類。以1號潛污泵為例屬性模擬量電流、功率、繞組溫度枚舉量運(yùn)行模式、故障代碼布爾量運(yùn)行狀態(tài)服務(wù)啟動、停止、遠(yuǎn)程切手動/自動事件過載報警、堵轉(zhuǎn)報警、跳閘事件這些定義寫在臺賬里組態(tài)時的圖元綁定數(shù)據(jù)源、運(yùn)維時告警規(guī)則的設(shè)定都從同一份物模型里取。有一次我在組態(tài)里綁定數(shù)據(jù)源時發(fā)現(xiàn)綁定列表里能選到泵機(jī)電流也能選到PLC模塊的原始寄存器地址就是物模型起了作用。如果沒有物模型層組態(tài)和運(yùn)維只能各寫各的點(diǎn)表一旦點(diǎn)位表變更兩個模塊都得重新配置還容易出現(xiàn)漏改。3. 組態(tài)畫面讓數(shù)據(jù)活在圖形里而不是躺在曲線圖里組態(tài)的價值在于把設(shè)備運(yùn)行狀態(tài)還原成操作員能一眼看懂的圖形。光給用戶看折線圖現(xiàn)場工人還是得自己去腦補(bǔ)設(shè)備狀態(tài)。組態(tài)就是把設(shè)備狀態(tài)翻譯成視覺語言泵轉(zhuǎn)不轉(zhuǎn)、管子里有沒有水、閥門開度多大、報警燈亮沒亮。3.1 組態(tài)引擎選型FUXA、MCGS還是自研拿泵站項目來說市面上的組態(tài)軟件很多這里重點(diǎn)對比三類主流方案方案典型代表優(yōu)點(diǎn)缺點(diǎn)適用場景傳統(tǒng)工控組態(tài)MCGS、組態(tài)王協(xié)議全、穩(wěn)定、工業(yè)界認(rèn)可度高授權(quán)貴、Web發(fā)布弱、界面風(fēng)格老本地觸摸屏/HMI開源Web組態(tài)FUXA、Node-RED Dashboard免費(fèi)、開源、基于Web發(fā)布、輕量復(fù)雜動畫效果要自己寫SVG/CSS、大型項目性能一般中小型物聯(lián)網(wǎng)平臺自研組態(tài)引擎基于Canvas/SVG自研完全可控、可深度集成鑒權(quán)與數(shù)據(jù)研發(fā)成本高、周期長大型平臺或特殊行業(yè)我在做泵站項目時由于要同時滿足手機(jī)端查看和Web端大屏最終選了FUXA作為Web組態(tài)引擎把畫面嵌入物聯(lián)網(wǎng)平臺。選它的原因是社區(qū)活躍、支持工業(yè)協(xié)議Modbus、OPC UA而且它能通過HTTP API實現(xiàn)自定義數(shù)據(jù)源。MCGS適合做本地的觸摸屏但在遠(yuǎn)程Web發(fā)布和物聯(lián)網(wǎng)平臺集成上明顯吃力。3.2 FUXA里的圖元與數(shù)據(jù)綁定邏輯用組態(tài)工具畫設(shè)備界面很多人都習(xí)慣先畫畫再綁數(shù)據(jù)。我的建議反過來先把數(shù)據(jù)點(diǎn)表列清楚再開始畫圖。以泵站組態(tài)畫面為例我把畫面拆成三層第一層是工藝流程背景進(jìn)水管、泵坑、出水管、閘門、水池輪廓這些元素不綁數(shù)據(jù)只作為底圖。畫這層時線寬、顏色要規(guī)范水管用藍(lán)色系、泥水用棕色系統(tǒng)一圖例。第二層是設(shè)備狀態(tài)圖元三臺潛污泵各用一個圖元表示綁定物模型里的運(yùn)行狀態(tài)屬性。FUXA中旋轉(zhuǎn)動畫綁定布爾量運(yùn)行狀態(tài)為TRUE時葉輪圖形旋轉(zhuǎn)顏色動畫綁定告警等級正常綠色、預(yù)警黃色、故障紅色。液位計綁定液位高度屬性水位圖形的高度和顏色隨數(shù)值變化。第三層是操作與告警爆發(fā)區(qū)域每臺泵后面放一個啟動/停止按鈕綁定物模型服務(wù)組態(tài)頂部放一組告警指示燈綁定三個泵的故障事件。綁點(diǎn)時最容易踩的坑是數(shù)據(jù)格式不一致。FUXA里綁定的數(shù)據(jù)源如果返回的是字符串類型的1和0而動畫要求布爾型會導(dǎo)致畫面不刷新。我在對接PLC時用Node-RED做數(shù)據(jù)清洗將線圈狀態(tài)轉(zhuǎn)為JSON布爾值將寄存器數(shù)值縮放為工程值再推給FUXA的WebSocket接口。清洗規(guī)則全部維護(hù)在平臺里組態(tài)盡量只消費(fèi)干凈的數(shù)據(jù)。3.3 組態(tài)聯(lián)動與告警的最后一公里組態(tài)畫面本身畫得好不好只算完成了60%剩下40%取決于和平臺告警、控制的聯(lián)動深度。我給泵站設(shè)計的聯(lián)動規(guī)則是液位超過2.8米時水池圖元顯示橙色閃爍組態(tài)界面頂部彈出預(yù)警條液位超過3.2米時畫面切換為紅色色調(diào)同時觸發(fā)告警事件自動創(chuàng)建緊急工單操作員點(diǎn)擊泵圖元彈出操作確認(rèn)框確認(rèn)后調(diào)用服務(wù)操作結(jié)果成功/失敗會以Toast形式反饋聯(lián)動上有兩個細(xì)節(jié)值得注意控制反轉(zhuǎn)確認(rèn)。遠(yuǎn)程啟動泵不是點(diǎn)一下按鈕泵就轉(zhuǎn)要有一個下發(fā)指令→PLC執(zhí)行→狀態(tài)回讀→畫面刷新的閉環(huán)。FUXA按鈕綁定的微調(diào)服務(wù)是異步的如果畫面只在下發(fā)成功后就顯示泵已啟動實際因為PLC處于手動模式啟動失敗操作員會誤判。所以我的實現(xiàn)是下發(fā)后延遲5秒回讀設(shè)備運(yùn)行狀態(tài)狀態(tài)為TRUE才顯示運(yùn)行狀態(tài)否則顯示指令已下發(fā)未響應(yīng)。告警閃爍的抑制機(jī)制。報警閃爍往往需要操作員確認(rèn)/消音才會停止。FUXA的告警橫幅如果沒人確認(rèn)會一直占領(lǐng)畫面前端影響其他操作。我設(shè)計了告警彈窗與告警列表分離彈窗等確認(rèn)才消失列表保留告警直到恢復(fù)。整個流程基于平臺運(yùn)維模塊的告警級別和工單狀態(tài)來驅(qū)動。4. 運(yùn)維閉環(huán)設(shè)備上線才是開始后面拼的是故障響應(yīng)能力物聯(lián)網(wǎng)平臺如果只管設(shè)備接入和數(shù)據(jù)展示那就只是個高級網(wǎng)管談不上運(yùn)維。好的設(shè)備管理必須能夠回答三個問題設(shè)備現(xiàn)在處于什么狀態(tài)如果出問題誰負(fù)責(zé)處理處理過程怎么留痕4.1 告警規(guī)則不是所有數(shù)據(jù)異常都值得發(fā)工單告警規(guī)則的設(shè)計決定運(yùn)維團(tuán)隊會不會被狼來了式的垃圾告警淹沒。泵站項目剛上線時電流波動稍微大一點(diǎn)就告警一晚上彈出上百條消息值班員很快就開始無視告警——這是典型的告警疲勞。后來我調(diào)整了告警策略核心是組合條件 持續(xù)時間 確認(rèn)機(jī)制。一條告警規(guī)則不再僅僅是數(shù)值閾值而是包含多個條件電流 額定電流的120%并且持續(xù)超過10秒才觸發(fā)過流告警液位 2.8米并且持續(xù)超過60秒才觸發(fā)高液位預(yù)警若超過3.2米立即觸發(fā)緊急告警設(shè)備心跳丟失超過3個周期觸發(fā)離線告警但級別設(shè)成提示因為泵站的網(wǎng)關(guān)可能有計劃內(nèi)重啟這里的時間窗口非常關(guān)鍵。PLC采集的數(shù)據(jù)本身有一定抖動直接閾值判斷會產(chǎn)生大量瞬態(tài)告警。而告警持續(xù)字段判定本質(zhì)上是給設(shè)備一個恢復(fù)機(jī)會能濾掉多數(shù)毛刺。觸發(fā)告警后還必須有恢復(fù)機(jī)制數(shù)據(jù)回到正常范圍并持續(xù)穩(wěn)定30秒告警自動置為已恢復(fù)并不再參與未處理告警統(tǒng)計。4.2 工單狀態(tài)機(jī)運(yùn)維工單系統(tǒng)的核心骨架告警產(chǎn)生后需要對應(yīng)工單來承載處理全過程。工單系統(tǒng)做得好不好狀態(tài)機(jī)的設(shè)計是決定性因素。我用的工單狀態(tài)機(jī)是待處理 → 已受理 → 處理中 → 已完成 → 已關(guān)閉加入兩個輔助節(jié)點(diǎn)已掛起等待備件到貨、等待停電窗口、等待外部配合已退回運(yùn)維員判斷非本崗位職責(zé)退回重新派單工單流轉(zhuǎn)過程中的每一步都要記錄操作人、操作時間、操作備注。我在泵站項目中遇到過這樣的場景值班員看到1號泵過流工單直接點(diǎn)擊受理然后趕到現(xiàn)場發(fā)現(xiàn)泵已經(jīng)燒了就把工單狀態(tài)改成已完成備注寫等待更換新泵。這個工單其實沒有解決根本問題但因為狀態(tài)是已完成平臺判定問題閉環(huán)了備件采購流程沒有被觸發(fā)。后來工單新增了一個字段是否真正恢復(fù)正常只有設(shè)備運(yùn)行數(shù)據(jù)在工單關(guān)閉后持續(xù)穩(wěn)定24小時才允許從已完成變?yōu)橐殃P(guān)閉。這個機(jī)制逼著運(yùn)維人員把問題處理干凈。4.3 巡檢與保養(yǎng)計劃把被動救火變成主動免疫運(yùn)維模塊還應(yīng)該支持巡檢和保養(yǎng)計劃。泵站的潛污泵屬于旋轉(zhuǎn)類設(shè)備廠家要求每500小時進(jìn)行例行檢查每半年更換一次潤滑油。如果人工管理這些周期很容易遺漏尤其泵站通常無人值守。我實現(xiàn)的保養(yǎng)計劃模塊包含以下數(shù)據(jù)計劃類型日常巡檢、周期保養(yǎng)、定期校驗執(zhí)行周期按小時數(shù)泵累計運(yùn)行500小時、按日歷每月1日、按次數(shù)每3次排水周期關(guān)聯(lián)設(shè)備可關(guān)聯(lián)到站點(diǎn)、單臺設(shè)備或部件關(guān)聯(lián)工單生成規(guī)則到期后自動生成相應(yīng)類型的工單之前的泵站項目中由于運(yùn)維人員的流動比較大新任人員不太清楚哪些設(shè)備做過保養(yǎng)臺賬的數(shù)據(jù)質(zhì)量變得很關(guān)鍵。工單執(zhí)行完畢填寫的維修保養(yǎng)記錄會回寫到設(shè)備臺賬的運(yùn)維屬性累計運(yùn)行小時數(shù)從泵的PLC側(cè)讀取。平臺會在即將到達(dá)保養(yǎng)窗口前7天生成預(yù)防性工單運(yùn)維人員在手機(jī)端就能看到1號泵累計運(yùn)行486小時預(yù)計14小時后到達(dá)保養(yǎng)周期這種主動提醒比事后的故障維修要讓人省心得多。4.4 備品備件與設(shè)備檔案的關(guān)聯(lián)備品備件管理是運(yùn)維模塊里容易忽略但非常實用的功能。維修工單里經(jīng)常要填更換了什么零件如果備件庫存和工單打通平臺就能自動扣減庫存并在庫存水位線以下時提醒采購。在泵站項目里我建了這樣一個關(guān)聯(lián)模型設(shè)備部件 ? 備件清單 ? 庫存批次臺賬里1號泵的電機(jī)部件關(guān)聯(lián)到備件清單5.5kW三相異步電機(jī)庫存中當(dāng)前有2臺該型號電機(jī)分別記錄采購日期和供應(yīng)商維修工單選擇更換電機(jī)操作時自動從庫存中占用一個批次檢修完成、工單關(guān)閉后庫存減去對應(yīng)數(shù)量臺賬中該部件的更換記錄新增一條這套機(jī)制跑順以后設(shè)備管理就不再只是IT系統(tǒng)里的一堆數(shù)據(jù)而是實實在在幫助項目降低了故障處理時長。備件周轉(zhuǎn)情況、故障率統(tǒng)計、設(shè)備全生命周期成本都可以通過累計的數(shù)據(jù)回答。5. 打通三者的數(shù)據(jù)聯(lián)動一個典型故障處理全流程現(xiàn)在把臺賬、組態(tài)、運(yùn)維串起來走一遍看看整個鏈路怎么互相配合。就以泵站最典型的故障場景——1號泵過流跳閘為例。5.1 從告警觸發(fā)到工單派發(fā)平臺做了什么某天凌晨3點(diǎn)1號泵電流突然從正常值爬升到150%額定值持續(xù)超過10秒。平臺側(cè)的動作按照預(yù)設(shè)的規(guī)則同步執(zhí)行臺賬側(cè)從物模型中讀取1號泵的定義確認(rèn)電流是一個模擬量屬性關(guān)聯(lián)到PLC的AI_3通道時序庫將電流數(shù)據(jù)標(biāo)記為越限記錄開始時間戳告警引擎觸發(fā)過流告警級別為緊急寫入告警列表與歷史記錄同時推送站內(nèi)消息組態(tài)側(cè)泵圖元變紅色頁面右上角彈出緊急告警提示工單引擎根據(jù)設(shè)備與運(yùn)維班組的路由關(guān)系自動生成緊急工單派給值班組通知服務(wù)通過短信/App推送通知值班員整個過程不需要任何人點(diǎn)擊按鈕告警到工單的轉(zhuǎn)換無需人工干預(yù)保證夜間也能在30秒內(nèi)進(jìn)入處理流程。5.2 運(yùn)維人員處理過程現(xiàn)場和平臺如何協(xié)同值班員在手機(jī)上看到工單顯示1號潛污泵過流告警已持續(xù)12分鐘請盡快處理。他點(diǎn)了受理工單狀態(tài)變?yōu)橐咽芾砥脚_記錄受理時間。到現(xiàn)場判斷是葉輪卡阻造成的堵轉(zhuǎn)過流按操作規(guī)程將泵切換為備用泵運(yùn)行隨后填寫處理記錄故障現(xiàn)象電流升高、泵體振動大處理方式切換至2號泵隔離1號泵診斷結(jié)論疑似葉輪卡阻需提泵檢查遺留事項已生成保養(yǎng)工單待白天提泵清理工單狀態(tài)被置為已掛起等待第二天白天的維修保養(yǎng)工單執(zhí)行。這個掛起動作在原來的工單設(shè)計里是沒有的后來加了這道狀態(tài)是為了區(qū)分處理完但沒根治和徹底解決兩種情況。掛起工單不能直接關(guān)閉有效的防止了看似處理完、實則還等著后續(xù)動作的工單被遺忘。5.3 處理完成后臺賬檔案如何自動歸檔第二天白天維修工單執(zhí)行完畢提泵檢查后發(fā)現(xiàn)葉輪確實卡了一個塑料袋清理后重新安裝試運(yùn)行30分鐘正常。維修人員在平臺中完成以下操作關(guān)閉保養(yǎng)工單填寫處理結(jié)果臺賬里的事件與維修記錄自動追加一條記錄包含故障現(xiàn)象、處理方式、耗時、更換備件1號泵的累計運(yùn)行小時數(shù)和維護(hù)履歷聯(lián)動存儲關(guān)聯(lián)的過流告警標(biāo)記為已處理原因繞性卡阻涉及備件清點(diǎn)無更換備件只消耗人工至此整個閉環(huán)才算真正閉合。三天后值班員從平臺的故障統(tǒng)計報表里能看到葉輪卡阻類故障本月已發(fā)生3次建議在進(jìn)水口增加格柵,這就是數(shù)據(jù)積累帶來的運(yùn)維增值。5.4 權(quán)限模型誰可以改臺賬、畫組態(tài)、處理工單三模塊打通后權(quán)限模型如果沒跟上平臺會變成誰都能改的大鍋飯出了問題責(zé)任不清。我建議的權(quán)限分為三套角色角色臺賬權(quán)限組態(tài)權(quán)限運(yùn)維權(quán)限系統(tǒng)管理員可增刪改、可導(dǎo)入導(dǎo)出可設(shè)計、可發(fā)布可查看所有模塊設(shè)備管理員可修改運(yùn)維屬性、變更履歷只讀可處理工單組態(tài)設(shè)計員只讀可編輯、可發(fā)布新版本無工單處理權(quán)限值班運(yùn)維員只讀只讀可受理、處理工單這個設(shè)計最重要的細(xì)節(jié)是變更權(quán)限歸屬留痕。設(shè)備臺賬的任何修改即使是管理員操作都會在日志里記錄并且組態(tài)發(fā)布新版本前必須經(jīng)過預(yù)覽與確認(rèn)防止一個不小心把正在運(yùn)行中的泵站畫面改壞。發(fā)布后如果操作員發(fā)現(xiàn)畫面有問題還可以基于之前的版本快速回滾。6. 分階段落地小團(tuán)隊如何一步步把平臺用起來最后聊聊實施落地。很多團(tuán)隊拿到物聯(lián)網(wǎng)平臺上來就把臺賬、組態(tài)、運(yùn)維三個模塊一次性鋪開結(jié)果運(yùn)維流程沒人用組態(tài)畫了一堆沒人看的圖。我的建議是分三個階段走目標(biāo)逐步升級。6.1 第一階段臺賬 數(shù)據(jù)可視化先把底賬立起來第一個周期只做兩件事把全部設(shè)備臺賬錄入平臺打通組態(tài)的數(shù)據(jù)實時刷新。目的在于讓設(shè)備和數(shù)據(jù)在平臺上先對齊讓工程人員習(xí)慣從平臺看設(shè)備狀態(tài)。這個階段不追求遠(yuǎn)程控制和復(fù)雜自動化先積累設(shè)備檔案的數(shù)據(jù)質(zhì)量。數(shù)據(jù)質(zhì)量太差的情況下就直接上運(yùn)維自動化后續(xù)會面臨工單關(guān)聯(lián)錯設(shè)備、備件對不上型號之類的連鎖問題。實操上我建議先做一件事清點(diǎn)現(xiàn)場設(shè)備統(tǒng)一命名規(guī)范。有條件的話打印臺賬二維碼貼到設(shè)備上手機(jī)掃碼就能看到這臺設(shè)備的檔案信息和最近狀態(tài)。我用過第三方二維碼模版方案直接在平臺通過統(tǒng)一接口生成設(shè)備驗收時掃碼核對物模型和點(diǎn)位表能省掉大量后期返工。6.2 第二階段告警 - 工單聯(lián)動把運(yùn)維動作跑起來第二階段核心是建立運(yùn)維的告警和工單閉環(huán)。先圈定重要設(shè)備的部分關(guān)鍵測點(diǎn)設(shè)置合理的告警規(guī)則確保生產(chǎn)環(huán)境比較關(guān)鍵的報警都能覆蓋到位。工單流程從一個班組試點(diǎn)值班員手機(jī)上安裝APP端并讓所有人的操作都在平臺上留痕。這一步跑順以后再逐步擴(kuò)展告警測點(diǎn)范圍。容易栽的坑是運(yùn)維人員習(xí)慣打電話報修不愿意在App點(diǎn)來點(diǎn)去。解決方法是把派單邏輯盡可能自動化讓平臺直接生成工單推給值班員減少手動錄入環(huán)節(jié)手機(jī)端按鈕盡量精簡。用戶使用一個操作繁瑣的系統(tǒng)時沒有足夠的動力很快就會回去用微信報修系統(tǒng)自然就荒廢了。6.3 第三階段維護(hù)計劃與備品備件把資產(chǎn)管理做實第二階段穩(wěn)定后再引入巡檢保養(yǎng)計劃與備品備件管理。這個階段的難點(diǎn)在數(shù)據(jù)維護(hù)而非開發(fā)需要設(shè)備管理員定期更新累計運(yùn)行時間、庫存余額、保養(yǎng)記錄。系統(tǒng)上線三個月后積累的數(shù)據(jù)就能支撐備件采購決策比如哪臺泵的軸承連續(xù)換了3次、備件供應(yīng)商的平均到貨時間等這些數(shù)據(jù)對預(yù)算申請非常有用。最后補(bǔ)充一點(diǎn)個人小經(jīng)驗物聯(lián)網(wǎng)平臺的設(shè)備管理功能永遠(yuǎn)都是在越用越好用的過程中迭代出來的別總想著一步到位的完美方案。先把臺賬這張底圖畫清楚組態(tài)就會順運(yùn)維就能閉環(huán)平臺才不會淪為擺設(shè)。項目做多了你會發(fā)現(xiàn)設(shè)備的數(shù)字底座扎實比任何炫酷大屏都重要。