2021年我接手了一個老車間的數(shù)采項目那是第一次真正意識到“工業(yè)數(shù)據(jù)”這幾個字的重量。車間里有一臺2006年出廠的注塑機(jī)、兩條2009年的裝配線主控是西門子S7-200和臺達(dá)DVP系列通訊口只有RS485串口沒有以太網(wǎng)模塊更談不上OPC-UA。生產(chǎn)經(jīng)理想要設(shè)備OEE、報警記錄和能耗曲線但設(shè)備本身就像個啞巴——數(shù)據(jù)明明在PLC內(nèi)存里跑著卻沒有任何辦法把它拿出來。剛開始我覺得這事簡單不就是用Modbus協(xié)議去讀寄存器嗎真做起來才發(fā)現(xiàn)從“能讀到數(shù)據(jù)”到“穩(wěn)定、可靠、不丟數(shù)地拿到數(shù)據(jù)”中間隔著一整套工程問題輪詢周期怎么定、數(shù)據(jù)怎么壓縮、斷網(wǎng)怎么辦、重啟之后怎么補(bǔ)。這篇文章就把這套“工業(yè)遺留設(shè)備非侵入式數(shù)采架構(gòu)”完整講一遍重點(diǎn)落在三個技術(shù)點(diǎn)上Modbus/OPC-UA邊緣適配網(wǎng)關(guān)、時序數(shù)據(jù)差分壓縮、斷網(wǎng)自愈。如果你正在做工廠數(shù)據(jù)采集、MES對接、設(shè)備上云這類項目這篇應(yīng)該能幫你少踩不少坑。1. 車間里的三代設(shè)備混戰(zhàn)這個項目要解決的真實(shí)痛點(diǎn)1.1 非侵入式的定義不改邏輯、不改硬件、不承擔(dān)停機(jī)風(fēng)險“非侵入式”這四個字先要掰開揉碎講清楚。它不是技術(shù)選型的偏好而是業(yè)務(wù)層面的硬約束。改造一個用了十幾年的老設(shè)備工廠最怕兩件事一是改PLC程序改掛了生產(chǎn)線停擺停產(chǎn)一小時可能就虧掉幾個網(wǎng)關(guān)的錢二是改造驗收時能跑后續(xù)維護(hù)升級要加點(diǎn)位又得動原廠邏輯廠商配合度低、周期長。所以項目啟動會上跟車間定了三條紅線不修改任何PLC原有程序、不更改設(shè)備硬件接線、不停機(jī)實(shí)施。這意味著數(shù)采網(wǎng)關(guān)只能“寄生”在設(shè)備已有的通訊端口上。具體到本項目大部分設(shè)備走的是RS485串口通過Modbus RTU協(xié)議從PLC的從站寄存器里讀數(shù)據(jù)少量新一點(diǎn)的設(shè)備有以太網(wǎng)口走M(jìn)odbus TCP。整個過程不需要在PLC上增加硬件模塊也不需要改電氣柜里的走線。這里有一個非常關(guān)鍵的前提要查清楚設(shè)備里的PLC從站功能是不是已經(jīng)激活了。很多老設(shè)備默認(rèn)用的是編程口協(xié)議比如西門子S7-200的PPI協(xié)議它本身不是Modbus。如果PLC程序里沒有初始化Modbus從站指令塊你光把通訊線接上發(fā)Modbus請求過去設(shè)備是不會理你的。我們這個項目里有三臺設(shè)備最后是請廠商過來在程序里加了一段Modbus初始化指令MBUS_INIT相當(dāng)于在一大段邏輯里塞了一個子程序調(diào)用主體邏輯完全沒動這算最小程度的侵入大多數(shù)用戶能夠接受。但這個動作必須在停產(chǎn)窗口期做而且要提前跟設(shè)備廠商確認(rèn)寄存器地址表和從站站號分配不然現(xiàn)場就是一團(tuán)亂麻。1.2 數(shù)據(jù)撈出來只是開始采集鏈路不等于數(shù)據(jù)鏈路把Modbus寄存器讀出來之后很多人覺得任務(wù)就完成了。其實(shí)不是這樣。裸寄存器讀出來的是“一個地址、一堆十六進(jìn)制數(shù)”要變成MES能用的“設(shè)備狀態(tài)、產(chǎn)量、良品率、瞬時能耗”中間還有一串活數(shù)據(jù)清洗、單位換算、位拼接比如兩個寄存器拼一個32位浮點(diǎn)數(shù)、協(xié)議轉(zhuǎn)換、本地緩存、斷點(diǎn)續(xù)傳、壓縮上傳。這些工作在邊緣端做完比在云端做要合理得多。第一現(xiàn)場數(shù)據(jù)量大采樣周期到秒級的話一臺設(shè)備一天就是86400條記錄幾十臺設(shè)備全量往云端推帶寬和云端存儲都吃不消第二現(xiàn)場網(wǎng)絡(luò)沒有辦公室網(wǎng)絡(luò)那么可靠一旦斷網(wǎng)邊端必須有本事把數(shù)據(jù)先存下來第三很多老設(shè)備通信能力弱只支持串口輪詢你不可能讓云端直接去輪詢一個RS485總線上的從站。所以這套架構(gòu)的核心思路是邊緣網(wǎng)關(guān)做“翻譯官倉庫管理員”云平臺只負(fù)責(zé)“看報表和發(fā)指令”。翻譯官解決的是協(xié)議不通的問題把Modbus的裸寄存器翻譯成OPC-UA信息模型和MQTT消息倉庫管理員解決的是數(shù)據(jù)可靠性的問題先把數(shù)據(jù)穩(wěn)穩(wěn)當(dāng)當(dāng)落在本地再想辦法傳到云端。后面每一章講的具體環(huán)節(jié)本質(zhì)上都是這兩個角色里的一部分。2. 邊緣網(wǎng)關(guān)的硬件選型與軟件架構(gòu)為什么必須在現(xiàn)場放一臺“翻譯官”2.1 為什么不用DTU直接透傳協(xié)議、緩存、安全三道坎做項目的時候有人問我現(xiàn)在市面上的DTU數(shù)據(jù)傳輸單元那么便宜把RS485轉(zhuǎn)成4G/以太網(wǎng)透傳不就行了何必放一臺邊緣網(wǎng)關(guān)這個問題問得很好我用實(shí)際項目里的三筆賬回答。第一筆是協(xié)議賬。DTU做的是物理層的透傳它不管上層跑什么協(xié)議。如果云平臺要讀到Modbus數(shù)據(jù)云平臺還得自己實(shí)現(xiàn)一個Modbus主站去輪詢而Modbus輪詢是有時序要求的RS485總線上同一時刻只允許一個主站發(fā)送請求延時、超時、重試這些邏輯放在公網(wǎng)鏈路上做基本不靠譜。DTU解決不了“設(shè)備說Modbus、平臺說OPC-UA/MQTT”這種協(xié)議轉(zhuǎn)換問題。第二筆是緩存賬。DTU斷網(wǎng)之后就是傻等數(shù)據(jù)在設(shè)備端沒有被采集出來等網(wǎng)絡(luò)恢復(fù)再去讀已經(jīng)來不及了——PLC的寄存器是瞬態(tài)值過了這個時間點(diǎn)你就永遠(yuǎn)拿不到那條數(shù)據(jù)了。而邊緣網(wǎng)關(guān)在本地把數(shù)據(jù)落盤斷網(wǎng)幾個小時、幾天數(shù)據(jù)都在本地倉庫里躺著網(wǎng)絡(luò)恢復(fù)后可以按時間順序補(bǔ)傳。第三筆是安全賬。如果設(shè)備直接暴露在公網(wǎng)IP上那等于把PLC的通訊端口開到了互聯(lián)網(wǎng)上一旦出安全問題后果不敢想。邊緣網(wǎng)關(guān)作為唯一的數(shù)據(jù)出口對外只主動連接平臺不對公網(wǎng)開放任何入站端口這是最樸素的邊界防護(hù)邏輯。2.2 軟件技術(shù)棧的選擇驗證過的穩(wěn)定組合硬件方面我選的是無風(fēng)扇工業(yè)嵌入式工控機(jī)CPU不用高Atom級別或者賽揚(yáng)J系列就夠關(guān)鍵是必須有原生或者硬件隔離的RS485串口、雙網(wǎng)口、寬溫固態(tài)盤電源支持9到36V寬壓輸入直接接到設(shè)備控制柜的DC24V回路上。網(wǎng)上那些幾十塊的USB轉(zhuǎn)RS485模塊短時間調(diào)試可以長期放現(xiàn)場大概率會出現(xiàn)丟幀、驅(qū)動不穩(wěn)定、串口丟失的麻煩不建議用。軟件棧我用的是Python 3.8 pymodbus串口/網(wǎng)口Modbus主站 asyncuaOPC-UA服務(wù)端 SQLite本地緩存 自研MQTT上傳模塊。有人會覺得Python干工業(yè)采集不靠譜但實(shí)際上對這個場景是完全夠用的——Modbus輪詢是毫秒級的慢速IO幾百個點(diǎn)位每秒也就幾百次操作Python并發(fā)模型里的asyncio足夠應(yīng)付真正要關(guān)注的瓶頸在磁盤IO和網(wǎng)絡(luò)。Python的好處是開發(fā)快、協(xié)議庫完整、后面要接什么數(shù)據(jù)服務(wù)都方便。網(wǎng)關(guān)內(nèi)部按數(shù)據(jù)流向分了五層設(shè)備接入層各種串口/網(wǎng)口的Modbus信道、協(xié)議解析層寄存器映射、字節(jié)序轉(zhuǎn)換、單位換算、本地存儲層SQLite緩存隊列、服務(wù)開放層OPC-UA Server、MQTT Client、本地Web調(diào)試頁面、管理維護(hù)層時鐘同步、日志、看門狗。每一層之間用簡單的隊列解耦Modbus采集線程只管把數(shù)據(jù)寫進(jìn)本地數(shù)據(jù)庫上傳線程只管從數(shù)據(jù)庫拿數(shù)據(jù)推給平臺兩個線程互不阻塞這也是斷網(wǎng)自愈能成立的基礎(chǔ)。3. Modbus輪詢詳解寄存器勘察、掃描周期計算與讀寫沖突規(guī)避3.1 用Modbus Poll做寄存器勘察先畫出地圖再上路上現(xiàn)場前最重要的一件事是把每臺設(shè)備的Modbus點(diǎn)位表摸清楚。我一般用Modbus Poll這個工具它就是個Modbus主站模擬器接上RS485轉(zhuǎn)USB線就能跟PLC說話?？辈斓臅r候要做三件事確認(rèn)通訊參數(shù)波特率、數(shù)據(jù)位、停止位、校驗位、確認(rèn)從站站號、確認(rèn)每個點(diǎn)位對應(yīng)的功能碼和寄存器地址。這里最容易出問題的是寄存器地址的“基址偏移”。Modbus協(xié)議層的地址是0開始的Protocol Address很多PLC廠商的文檔里寫的是1開始的Logical Address中間差1。比如臺達(dá)DVP的D寄存器文檔里說“D100”你發(fā)Modbus請求時的實(shí)際地址可能是99或者100這個必須拿Modbus Poll親手測看哪個地址能讀到預(yù)期值再在點(diǎn)表里記錄。勘察完要產(chǎn)出一張點(diǎn)表這是整個項目的“地圖”。字段包括設(shè)備ID、從站站號、寄存器地址協(xié)議層地址、功能碼03讀保持寄存器、04讀輸入寄存器、數(shù)據(jù)類型INT16、UINT16、INT32、FLOAT、字節(jié)序、量程、單位、縮放系數(shù)、輪詢分組、描述。這張表后面要用來生成邊緣網(wǎng)關(guān)的配置文件也是OPC-UA信息模型和差分壓縮模塊的數(shù)據(jù)字典。順序別搞反我就是因為前期點(diǎn)位表錄入時漏了一項字節(jié)序?qū)е乱粭l溫度數(shù)據(jù)整整錯了兩天。3.2 掃描周期怎么算RS485總線是典型的時序預(yù)算問題Modbus RTU在RS485上是半雙工輪詢同一時刻只能有一個主站說話所以掃描周期是個實(shí)打?qū)嵉臅r序預(yù)算問題不算清楚要么總線沖突要么數(shù)據(jù)刷新太慢。先給個計算模型。以9600波特率為例傳輸一個字節(jié)大約需要1.04ms包含起始位、數(shù)據(jù)位、停止位。你發(fā)一條“讀10個保持寄存器”的請求報文是8個字節(jié)從站號1 功能碼1 起始地址2 寄存器數(shù)量2 CRC校驗2。如果讀取的10個寄存器里放的是5個FLOAT每個占2個寄存器響應(yīng)報文是25個字節(jié)從站號1 功能碼1 字節(jié)數(shù)1 數(shù)據(jù)20 CRC2。再加上Modbus協(xié)議要求的3.5個字符時間間隔約3.6ms請求前、響應(yīng)前、響應(yīng)后各一次單筆事務(wù)的總耗時大約是41ms。假如一臺設(shè)備有50個FLOAT點(diǎn)位一條報文最多讀125個寄存器所以可以在一條事務(wù)里把這50個FLOAT100個寄存器全部讀完實(shí)際上一筆事務(wù)就夠了周期大約41ms。但如果點(diǎn)位分布零散比如每隔幾十個寄存器才有一個有用的點(diǎn)你就得發(fā)好幾條事務(wù)。比如分成5筆事務(wù)那周期就變成5×41ms約等于205ms。串口波特率再低一點(diǎn)比如4800時間直接翻倍。所以設(shè)計的思路是點(diǎn)表規(guī)劃時盡量把同一設(shè)備的連續(xù)寄存器放在一個輪詢組里一條事務(wù)能讀完的絕不分兩筆。8臺設(shè)備掛在同一條RS485總線上每臺周期200ms合計輪詢一遍就是1.6秒左右。對大多數(shù)設(shè)備狀態(tài)監(jiān)控、產(chǎn)量統(tǒng)計場景1到2秒的刷新率完全夠用。如果你要1秒以內(nèi)的實(shí)時性要么提高波特率到38400甚至115200要么把設(shè)備拆到多條總線上。3.3 讀寫沖突和HMI共存別讓你的網(wǎng)關(guān)變成攪局者M(jìn)odbus不光是讀設(shè)備常有需要寫的場景比如設(shè)定溫度、切換配方。這里有個大坑如果邊緣網(wǎng)關(guān)周期性地去寫一個保持寄存器而設(shè)備HMI或PLC內(nèi)部邏輯也在寫同一個寄存器就會產(chǎn)生互相覆蓋的問題。我的處理原則是網(wǎng)關(guān)只讀不寫除非收到上位平臺下發(fā)的明確指令寫操作只做“命令觸發(fā)”不做“周期刷新”。讀取和寫入共用同一條總線的代價是寫入時總線會被占用讀周期會有抖動所以寫操作要加互斥鎖并且盡量放在采樣間隙。另一個容易被忽略的問題是HMI共存。老設(shè)備的RS485總線上通常已經(jīng)掛著一個HMI觸摸屏HMI本身就是一個Modbus主站。你再把網(wǎng)關(guān)并上去就變成了雙主站兩條輪詢請求在總線上打架現(xiàn)場表現(xiàn)為數(shù)據(jù)偶爾跳變、HMI畫面刷新變慢。解決思路有三種把HMI換到PLC的另一個通訊口上把網(wǎng)關(guān)節(jié)點(diǎn)設(shè)置為只在HMI輪詢周期的間隙發(fā)送請求需要摸清HMI的輪詢規(guī)律或者如果PLC支持把網(wǎng)關(guān)接到單獨(dú)的主站端口。我們項目里最省事的做法是給PLC加了一個通訊擴(kuò)展板HMI和網(wǎng)關(guān)各走各的口總線沖突的問題直接從物理上消除。4. OPC-UA地址空間建模把Modbus裸寄存器變成標(biāo)準(zhǔn)信息模型4.1 為什么網(wǎng)關(guān)要“說”O(jiān)PC-UA而不是直接交裸數(shù)據(jù)前面數(shù)據(jù)采集用的是Modbus但整個系統(tǒng)的對外接口我選了OPC-UA而不是單純讓云平臺來讀Modbus或收原始報文。原因不只是“OPC-UA更現(xiàn)代”這種口號而是三個實(shí)打?qū)嵉墓こ汤碛?。第一上層系統(tǒng)集成成本低。MES、SCADA、能源管理平臺這些系統(tǒng)基本都內(nèi)置OPC-UA客戶端接到一個標(biāo)準(zhǔn)OPC-UA服務(wù)端上配置一下連接字符串和節(jié)點(diǎn)路徑就能讀到數(shù)據(jù)。如果上層系統(tǒng)要去讀Modbus它就得自己實(shí)現(xiàn)Modbus主站還得知道每臺設(shè)備每個寄存器地址的映射關(guān)系集成成本高得多。第二信息模型自帶語義。Modbus寄存器就是一個編號一個數(shù)它不告訴你這是溫度還是壓力單位是什么。OPC-UA的地址空間可以定義成“設(shè)備對象下面掛著變量節(jié)點(diǎn)”每個變量節(jié)點(diǎn)帶描述、工程單位、數(shù)據(jù)類型等屬性。上層系統(tǒng)拿到節(jié)點(diǎn)就知道這個值的含義不用在平臺側(cè)再維護(hù)一張映射表。第三網(wǎng)絡(luò)安全模型成熟。OPC-UA支持TLS加密和證書認(rèn)證允許你只授予MES系統(tǒng)某些設(shè)備的讀取權(quán)限。這在制造業(yè)客戶那里比較好交代審計的時候也能說清楚數(shù)據(jù)通道是受控的。4.2 信息模型設(shè)計設(shè)備、點(diǎn)位、屬性三層結(jié)構(gòu)OPC-UA的地址空間建模我這套分成三層。第一層是設(shè)備對象節(jié)點(diǎn)Object Node。比如ObjectFolder/Devices/InjectionMolding_01對應(yīng)物理世界里那臺注塑機(jī)。設(shè)備節(jié)點(diǎn)的屬性包含設(shè)備編號、型號、廠商、上線時間、當(dāng)前通信狀態(tài)。第二層是點(diǎn)位變量節(jié)點(diǎn)Variable Node。掛在設(shè)備節(jié)點(diǎn)下面比如InjectionMolding_01/Temperature_Barrel1。每個變量節(jié)點(diǎn)設(shè)置DataType為Double或Int16設(shè)置EngineeringUnit屬性為攝氏度或百分比加上Description描述“1區(qū)料筒溫度”。變量節(jié)點(diǎn)的BrowseName和NodeId要穩(wěn)定因為上層系統(tǒng)配置好之后如果你的節(jié)點(diǎn)路徑變了對接就要重新來過。第三層是服務(wù)與診斷節(jié)點(diǎn)。這個是我自創(chuàng)的在每個設(shè)備下掛一個Diagnostics文件夾放幾個只讀變量LastPollTime最近一次輪詢時間、CommStatus通信狀態(tài)、TotalCommunicateErrors累計通信錯誤次數(shù)。這些診斷數(shù)據(jù)平時沒人看一旦出問題排查起來是救命稻草。具體實(shí)現(xiàn)上用Python的asyncua庫啟動一個Server注冊一個自定義namespace然后遍歷點(diǎn)表配置用代碼批量生成這些節(jié)點(diǎn)。幾百個點(diǎn)位用循環(huán)建節(jié)點(diǎn)就好不要手寫維護(hù)NodeId容易亂。這里要提醒一句OPC-UA Server加載完節(jié)點(diǎn)之后最好做一次地址空間的快照導(dǎo)出留作版本比對防止網(wǎng)關(guān)程序升級時節(jié)點(diǎn)結(jié)構(gòu)漂移。4.3 部署驗證UA Expert連上去看真實(shí)數(shù)據(jù)模型建好之后驗證工具我推薦官方免費(fèi)的UA Expert。它就是個OPC-UA客戶端填上網(wǎng)關(guān)的IP和端口就能瀏覽地址空間。驗證時主要看三件事節(jié)點(diǎn)樹結(jié)構(gòu)是否符合設(shè)計、每個變量能否訂閱到實(shí)時值、數(shù)據(jù)類型和工程單位是否顯示正確。這里有個實(shí)戰(zhàn)細(xì)節(jié)UA Expert訂閱的點(diǎn)位多了之后網(wǎng)關(guān)CPU占用會明顯上升因為每個訂閱都要進(jìn)行值變更檢測和推送。解決方法是把訂閱的采樣間隔調(diào)大默認(rèn)100ms改成1000ms對絕大多數(shù)工藝監(jiān)控足夠了。另外OPC-UA協(xié)議本身也有心跳機(jī)制客戶端和服務(wù)端之間的會話要保持連接如果網(wǎng)絡(luò)抖動客戶端會報“BadSessionIdInvalid”之類的錯誤這種時候要找網(wǎng)絡(luò)原因不要急著懷疑網(wǎng)關(guān)程序。5. 時序數(shù)據(jù)差分壓縮從“存全量”到“存變化”的工程實(shí)現(xiàn)5.1 工業(yè)時序數(shù)據(jù)的統(tǒng)計特征為什么值得做差分做壓縮之前我先分析了一下這些數(shù)據(jù)的特征。工業(yè)現(xiàn)場采上來的數(shù)據(jù)跟互聯(lián)網(wǎng)日志、金融行情有本質(zhì)區(qū)別。設(shè)備溫度、壓力、速度這些量在穩(wěn)態(tài)生產(chǎn)階段變化非常緩慢相鄰兩個采樣點(diǎn)的差值往往很小。比如注塑機(jī)料筒溫度設(shè)定在220攝氏度實(shí)際溫度在219.5到220.5之間波動一秒鐘采一次相鄰兩次的差值常常只有0.1到0.3攝氏度。如果直接存絕對值的32位浮點(diǎn)每個點(diǎn)固定4字節(jié)一天就是345600字節(jié)幾十臺設(shè)備一年下來就是好幾個GB存儲和傳輸成本都很可觀。但如果我存的是“差值”大部分差值用1到2個字節(jié)就能裝下少數(shù)劇烈變化的時刻才需要多字節(jié)。這就是差分編碼能省空間的基本盤。它不是要替代通用壓縮算法而是先用領(lǐng)域知識把數(shù)據(jù)變成“更好壓”的形態(tài)后面再疊加通用編碼效果才明顯。5.2 差分編碼ZigzagVarint的完整編碼流程具體編碼流程我拆成五步每一步都有明確的理由。第一步是定點(diǎn)化。浮點(diǎn)數(shù)直接做差分會遇到精度問題所以先把原始浮點(diǎn)按物理量綱乘一個縮放系數(shù)轉(zhuǎn)成整數(shù)。比如溫度保留一位小數(shù)就乘以10轉(zhuǎn)成整數(shù)2205然后做后續(xù)所有的差分運(yùn)算?？s放系數(shù)放在點(diǎn)位表的元數(shù)據(jù)里解壓時再除回去。第二步是分塊。把同一個點(diǎn)位的連續(xù)256個采樣點(diǎn)組成一個塊塊內(nèi)才做差分。分塊的好處是壓縮和解壓都局部化要查某段時間的數(shù)據(jù)只需要解壓包含那個時間段的塊不用把整年數(shù)據(jù)全解一遍。塊的大小對壓縮率和隨機(jī)訪問性能都有影響256是我試下來比較平衡的值。第三步是差分。塊內(nèi)第0個采樣點(diǎn)存原始值的絕對整數(shù)后面的每個點(diǎn)都跟前一個點(diǎn)做差得到delta[i] value[i] - value[i-1]。這些delta有正有負(fù)直接用無符號Varint編碼不了負(fù)數(shù)。第四步是Zigzag編碼。它把有符號整數(shù)映射成無符號整數(shù)映射規(guī)則是n大于等于0時變成2nn小于0時變成2|n|-1。比如0變成0-1變成11變成2-2變成32變成4。這樣處理后所有delta都變成了非負(fù)整數(shù)而且絕對值小的delta編碼出來依然很小。第五步是Varint編碼。Varint的原理是用每個字節(jié)的低7位存數(shù)據(jù)最高位表示后面還有沒有續(xù)字節(jié)。0到127之間的數(shù)用一個字節(jié)就完事128到16383用兩個字節(jié)以此類推。經(jīng)過差分和Zigzag之后大部分delta都落在127以內(nèi)所以大部分點(diǎn)只用一個字節(jié)。而原始存儲一個浮點(diǎn)要4個字節(jié)這一下就省了75%。時間戳也有壓縮空間。如果采樣周期是固定的1秒那時間戳不需要逐點(diǎn)存儲塊首存一個起始Unix時間戳后面按周期推算就行。如果采樣間隔不固定就對時間間隔做同樣的差分Varint編碼效果也不錯。5.3 存儲結(jié)構(gòu)塊索引與隨機(jī)訪問怎么配合壓縮完的數(shù)據(jù)不能糊里糊涂塞進(jìn)去得有一個可查詢的存儲結(jié)構(gòu)。我在SQLite里建了兩張表。第一張是數(shù)據(jù)塊表ts_data_block字段包括塊ID、設(shè)備ID、點(diǎn)位ID、起始時間、結(jié)束時間、采樣點(diǎn)數(shù)、塊編碼數(shù)據(jù)BLOB、塊內(nèi)首值絕對值、縮放系數(shù)版本。查詢某個時間段的數(shù)據(jù)時先用起始時間和結(jié)束時間在這個表上做索引查詢拿到相關(guān)塊的ID再按塊解壓。這張表是只追加的永遠(yuǎn)不修改、不刪除單條記錄只在滾動淘汰時按塊ID整塊刪除。第二張是塊索引表ts_block_meta記錄每個塊對應(yīng)的時間范圍和校驗值用于快速定位和完整性校驗。查詢邏輯是先查塊索引確定要解壓哪些塊再讀塊數(shù)據(jù)解壓回原始時序值。實(shí)測下來查詢一天的壓縮數(shù)據(jù)解壓耗時基本在幾十毫秒級別完全可用。5.4 實(shí)測壓縮率和CPU開銷數(shù)據(jù)比感覺更誠實(shí)我拿一條實(shí)際溫度曲線做了個測試。原始數(shù)據(jù)是每秒采樣一次、32位浮點(diǎn)、一天86400個點(diǎn)原始大小約345.6KB。經(jīng)過“定點(diǎn)化分塊差分ZigzagVarint”這一套壓縮后平均每個點(diǎn)1.2字節(jié)一天的數(shù)據(jù)大約103.7KB壓縮率70%。再疊加LZ4快速壓縮可以把每個點(diǎn)壓到0.9字節(jié)附近壓縮率接近78%。要注意的是LZ4解壓會帶來額外的CPU開銷而且對隨機(jī)訪問不太友好所以我只在定期歸檔時疊加LZ4實(shí)時存儲只做差分編碼。CPU開銷方面在Atom級別的工控機(jī)上一秒采樣32個點(diǎn)位、每256點(diǎn)編碼一個塊編碼耗時可以忽略不計峰值CPU占用增加不到3%。真正的開銷在解壓和網(wǎng)絡(luò)上傳但這兩個操作都可以異步做不影響采集線程的實(shí)時性。這個數(shù)據(jù)說明對工業(yè)時序數(shù)據(jù)做領(lǐng)域定制的差分壓縮性價比是很高的。6. 斷網(wǎng)自愈本地緩存、補(bǔ)傳機(jī)制與掉電保護(hù)6.1 工業(yè)網(wǎng)絡(luò)的真實(shí)可靠性先做最壞打算做工業(yè)項目久了我對網(wǎng)絡(luò)可靠性的信任度很低。現(xiàn)場環(huán)境里交換機(jī)重啟、光纖被叉車碰斷、配電房停電導(dǎo)致整個機(jī)柜掉電、施工誤拔網(wǎng)線這些事我都遇到過。斷網(wǎng)不是“可能不發(fā)生”的黑天鵝而是“什么時候發(fā)生”的灰犀牛。所以斷網(wǎng)自愈不是加分項是必備項。設(shè)計目標(biāo)定得很明確哪怕網(wǎng)絡(luò)斷開72小時網(wǎng)關(guān)也要繼續(xù)按秒級周期采集所有點(diǎn)位數(shù)據(jù)并存到本地網(wǎng)絡(luò)恢復(fù)后在不丟數(shù)據(jù)、不重復(fù)數(shù)據(jù)的前提下把離線期間的數(shù)據(jù)補(bǔ)傳到平臺。整個過程中采集線程和上傳線程完全解耦。6.2 本地緩存實(shí)現(xiàn)SQLite WAL模式滾動淘汰本地緩存我沒有用內(nèi)存緩存加定時落盤的方案因為現(xiàn)場最怕的就是進(jìn)程崩潰或掉電導(dǎo)致緩存丟失。直接的做法是每采到一個點(diǎn)值就寫一條記錄到SQLite數(shù)據(jù)庫。SQLite在這種“單進(jìn)程寫、批量讀”的場景下表現(xiàn)穩(wěn)定關(guān)鍵是要開啟WAL模式并設(shè)置synchronousNORMAL。WAL模式的好處是寫操作不阻塞讀操作而且崩潰恢復(fù)能力好。synchronousNORMAL的意思是事務(wù)提交時不需要等數(shù)據(jù)刷到物理磁盤才返回但WAL文件本身保證了崩潰時最多丟最近一小段數(shù)據(jù)不至于把整個數(shù)據(jù)庫搞壞。對于秒級采樣的數(shù)據(jù)丟掉最后幾毫秒的數(shù)據(jù)完全可以接受而寫入性能比全同步模式提升明顯。為了避免本地磁盤被無限增長的數(shù)據(jù)撐爆緩存表做滾動淘汰保留最近7天的數(shù)據(jù)超過7天按塊自動刪除。這個天數(shù)要根據(jù)平臺側(cè)容忍度和磁盤容量來定64G固態(tài)盤存7天秒級數(shù)據(jù)綽綽有余。淘汰邏輯用定時任務(wù)在低峰期執(zhí)行不要在采樣循環(huán)里做刪除操作。6.3 補(bǔ)傳邏輯與冪等性別讓數(shù)據(jù)重復(fù)捅出亂子網(wǎng)絡(luò)恢復(fù)后的補(bǔ)傳要比“把所有數(shù)據(jù)倒過去”復(fù)雜一些。我采用的策略是“實(shí)時優(yōu)先、補(bǔ)傳靠后”網(wǎng)絡(luò)恢復(fù)的前5分鐘只傳實(shí)時數(shù)據(jù)保證平臺看到的是“設(shè)備現(xiàn)在還活著”5分鐘之后再啟動補(bǔ)傳任務(wù)按時間正序把本地緩存里未上傳的數(shù)據(jù)批量推給平臺。補(bǔ)傳時的關(guān)鍵設(shè)計是冪等性。平臺側(cè)接收數(shù)據(jù)不能簡單地“來一條存一條”因為補(bǔ)傳和實(shí)時傳輸在時間上可能交錯同一條數(shù)據(jù)可能因為網(wǎng)絡(luò)超時被重傳兩次。解決辦法是在每條數(shù)據(jù)上帶上設(shè)備ID點(diǎn)位ID采樣時間戳這個三元組平臺側(cè)在存儲層對這個三元組做唯一索引重復(fù)插入直接忽略。這樣不管補(bǔ)傳任務(wù)重試多少次平臺數(shù)據(jù)都不會出現(xiàn)重復(fù)記錄。另一個細(xì)節(jié)是時間戳對齊。網(wǎng)關(guān)在斷網(wǎng)期間如果本地時鐘漂移補(bǔ)傳的數(shù)據(jù)時間戳就可能是錯的輕則曲線出現(xiàn)毛刺重則上報的數(shù)據(jù)被邊緣計算任務(wù)當(dāng)成異常值。所以網(wǎng)關(guān)必須能聯(lián)網(wǎng)校時。我在網(wǎng)關(guān)里加了NTP客戶端開機(jī)時校時之后每4小時校時一次如果NTP不可達(dá)就把本地時鐘和一個“未校時標(biāo)志”一起上報平臺側(cè)可以根據(jù)這個標(biāo)志對數(shù)據(jù)做降級處理。6.4 重連策略指數(shù)退避抖動防止“羊群效應(yīng)”網(wǎng)關(guān)斷網(wǎng)重連要特別注意“羊群效應(yīng)”——如果整條線路的十幾個網(wǎng)關(guān)同時斷網(wǎng)、同時恢復(fù)所有網(wǎng)關(guān)會同時發(fā)起連接平臺端口一下就被打滿了。所以重連不能做成“網(wǎng)絡(luò)一恢復(fù)就立刻連”要采用帶隨機(jī)抖動的指數(shù)退避策略第一次重連等待1秒第二次2秒第三次4秒逐步增大到最大值60秒并且每次等待時間加上一個0到1000毫秒的隨機(jī)抖動。這樣即使幾十個網(wǎng)關(guān)同時恢復(fù)它們的重連請求也會均勻散開平臺側(cè)的壓力會小很多。重連的探活也不能只靠TCP連接狀態(tài)因為TCP連接斷沒斷有時候要很久才能感知到。我在MQTT層用keepalive心跳默認(rèn)60秒超過兩個心跳周期沒收到的服務(wù)器響應(yīng)就判定連接失效主動斷開重建。同時監(jiān)控上傳隊列長度如果隊列持續(xù)增長說明網(wǎng)絡(luò)可能已經(jīng)出問題提前打日志而不是傻等連接超時。7. 上線半年踩過的坑字節(jié)序、時鐘漂移、假斷網(wǎng)與PLC干擾7.1 字節(jié)序與字序工業(yè)數(shù)據(jù)里最陰間的錯位Modbus協(xié)議本身是大端傳輸?shù)?2位浮點(diǎn)或者32位整數(shù)由兩個16位寄存器構(gòu)成時不同廠商的排列方式完全不一樣。常見的有ABCD大端、CDAB字交換、BADC字節(jié)交換、DCBA雙端反轉(zhuǎn)四種。癥狀表現(xiàn)為讀出來的溫度值是幾百甚至幾萬或者兩個數(shù)值在小數(shù)點(diǎn)位置亂跳。這個東西光看文檔經(jīng)常不準(zhǔn)最穩(wěn)的辦法是造一個已知值比如把PLC里的某個D寄存器手動寫入一個特定浮點(diǎn)數(shù)然后看網(wǎng)關(guān)讀出來是什么字節(jié)序把那臺設(shè)備的字節(jié)序參數(shù)定下來。7.2 時鐘漂移時間戳穿越導(dǎo)致的數(shù)據(jù)錯亂有段時間平臺側(cè)發(fā)現(xiàn)某臺設(shè)備的能耗曲線每天都有個奇怪的尖峰查了半天發(fā)現(xiàn)是網(wǎng)關(guān)的實(shí)時時鐘RTC電池沒電了。設(shè)備斷電重啟之后系統(tǒng)時間變成了出廠默認(rèn)的2015年等網(wǎng)絡(luò)恢復(fù)校時又突然跳回當(dāng)前時間中間這十幾分鐘“穿越”的數(shù)據(jù)全被存了下來補(bǔ)傳上去之后平臺側(cè)就把這段時間算成了異常尖峰。后來我在網(wǎng)關(guān)程序里加了開機(jī)檢測如果系統(tǒng)時間比編譯版本時間還早說明RTC不可靠啟動后阻塞數(shù)據(jù)上傳直到NTP校時成功才放開。這個機(jī)制雖然簡單但后面再沒出現(xiàn)過“穿越數(shù)據(jù)”。7.3 假斷網(wǎng)與PLC通信干擾網(wǎng)關(guān)把某臺設(shè)備標(biāo)記為離線但是現(xiàn)場看設(shè)備明明在正常運(yùn)行。排查下來發(fā)現(xiàn)這臺設(shè)備的PLC程序正在被工程師用編程軟件下載程序下載期間PLC的Modbus從站通信是被暫停的連續(xù)好幾次輪詢超時網(wǎng)關(guān)就判定設(shè)備離線了。從那以后判定離線的策略從“單次超時”改成了“連續(xù)5次超時或者10秒內(nèi)無有效響應(yīng)”并且把通信錯誤單獨(dú)記錄成診斷數(shù)據(jù)不直接參與離線狀態(tài)計算。這樣既能容忍設(shè)備側(cè)臨時干擾又不會讓故障被掩蓋。還有一次比較隱蔽的問題是RS485總線上的接線問題。使用了劣質(zhì)USB轉(zhuǎn)485模塊發(fā)送方向切換時RTS信號控制不干凈總線上經(jīng)常出現(xiàn)雜散字節(jié)導(dǎo)致CRC校驗錯誤率高。排查時用Modbus Poll抓包對比才找到原因網(wǎng)關(guān)發(fā)的請求報文和Modbus Poll發(fā)的一模一樣但網(wǎng)關(guān)這邊收到的響應(yīng)就是偶爾壞一幀。后來換成了帶自動流向控制的工業(yè)級串口卡錯誤率直接歸零。寫在最后的實(shí)戰(zhàn)心得這套架構(gòu)從2021年底上線到現(xiàn)在穩(wěn)定運(yùn)行了兩年多最深的體會是工業(yè)數(shù)采的項目難點(diǎn)從來不在某個單點(diǎn)技術(shù)上而在所有環(huán)節(jié)的咬合。Modbus輪詢調(diào)得再快斷網(wǎng)數(shù)據(jù)丟了等于白調(diào)差分壓縮省下來的空間如果補(bǔ)傳冪等性沒做好平臺側(cè)數(shù)據(jù)亂成一團(tuán)反而更麻煩。每當(dāng)你覺得某個環(huán)節(jié)“差不多行了”的時候它八成會在你最不希望的時間出問題。如果再做一個類似項目我會在前期多花一倍時間在點(diǎn)位勘察和點(diǎn)表維護(hù)上字節(jié)序、縮放系數(shù)、功能碼這些字段錄入越規(guī)范后面的OPC-UA建模、壓縮編碼、斷網(wǎng)補(bǔ)傳就越順暢。項目落地之后點(diǎn)表也要留版本管理設(shè)備改造過、PLC程序升過級點(diǎn)表必須跟著更新不然某個點(diǎn)位數(shù)據(jù)突然不對了你根本不知道是網(wǎng)關(guān)的問題還是現(xiàn)場那邊變了。技術(shù)方案可以有多種選擇但工程交付拼的是誰能把細(xì)節(jié)管住。這套架構(gòu)里的每一個模塊都不算高深合在一起就具備了處理真實(shí)工廠數(shù)據(jù)采集問題的能力這也是它到現(xiàn)在還在穩(wěn)定跑著的原因。