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