鉆井現(xiàn)場(chǎng)的設(shè)備數(shù)據(jù)接入一直是自動(dòng)化工程師最頭疼的一塊。井隊(duì)里電控系統(tǒng)、泥漿泵、頂驅(qū)、固控設(shè)備來自不同廠家PLC品牌五花八門通訊協(xié)議各說各話。想把這些數(shù)據(jù)統(tǒng)一匯集到一塊大屏上傳統(tǒng)做法是上SCADA但價(jià)格貴、實(shí)施周期長(zhǎng)、后期想加一個(gè)測(cè)點(diǎn)還得找原廠折騰一圈下來一線工程師往往連只讀權(quán)限都拿不到。這幾年我一直在用開源技術(shù)棧做現(xiàn)場(chǎng)數(shù)據(jù)接入有了一些沉淀就想把它整理成一個(gè)相對(duì)通用的方案取名叫 openrig定位是一套面向鉆機(jī)設(shè)備的開源數(shù)據(jù)接入與監(jiān)控中間件。這篇文章把整個(gè)設(shè)計(jì)思路、核心細(xì)節(jié)、實(shí)操過程和踩坑記錄都攤開講適合鉆井工程師、自動(dòng)化人員、油氣行業(yè)信息化從業(yè)者參考也適合剛接觸工業(yè)物聯(lián)網(wǎng)的開發(fā)者理解一套真實(shí)的數(shù)據(jù)鏈路是怎么搭起來的。1. 項(xiàng)目定位與整體設(shè)計(jì)思路1.1 現(xiàn)場(chǎng)痛點(diǎn)鉆機(jī)電控系統(tǒng)的數(shù)據(jù)孤島鉆井現(xiàn)場(chǎng)的自動(dòng)化程度其實(shí)很高絞車、轉(zhuǎn)盤、泥漿泵、頂驅(qū)都有獨(dú)立的電控系統(tǒng)PLC里面存著大量實(shí)時(shí)數(shù)據(jù)——大鉤載荷、鉆壓、扭矩、泵沖、泵壓、轉(zhuǎn)盤轉(zhuǎn)速這些都是鉆井作業(yè)最核心的參數(shù)。問題是這些數(shù)據(jù)散落在不同的控制系統(tǒng)里每套系統(tǒng)都有自己的上位機(jī)軟件界面風(fēng)格不一樣數(shù)據(jù)格式不統(tǒng)一工程師想看全井場(chǎng)的綜合數(shù)據(jù)往往要在幾個(gè)屏幕之間來回跑。更麻煩的是這些系統(tǒng)的數(shù)據(jù)接口大多不開放。設(shè)備廠家為了保護(hù)商業(yè)利益不輕易把點(diǎn)位表給你就算給了也是PDF格式的幾百頁文檔地址映射靠人工對(duì)照效率極低。傳統(tǒng)SCADA系統(tǒng)雖然能做集成但授權(quán)費(fèi)、組態(tài)費(fèi)、現(xiàn)場(chǎng)服務(wù)費(fèi)加在一起一臺(tái)井幾十萬很常見而且部署周期長(zhǎng)后期擴(kuò)展困難想對(duì)接MES系統(tǒng)或者做遠(yuǎn)程監(jiān)控又得簽新合同。這就是我啟動(dòng)openrig的直接原因——用開源組件搭一套足夠輕量、足夠透明的數(shù)據(jù)接入平臺(tái)讓一線工程師自己就能掌控設(shè)備數(shù)據(jù)。1.2 openrig的核心設(shè)計(jì)思路分層解耦與標(biāo)準(zhǔn)協(xié)議先行openrig不是一個(gè)單體的軟件而是一整套數(shù)據(jù)鏈路的組合方案核心思路是分層解耦。采集層解決“怎么把數(shù)據(jù)從PLC里讀出來”傳輸層解決“數(shù)據(jù)怎么安全地流動(dòng)”存儲(chǔ)層解決“時(shí)序數(shù)據(jù)怎么高效保存”展示層解決“數(shù)據(jù)怎么直觀呈現(xiàn)”。每一層都用成熟的開源組件實(shí)現(xiàn)層與層之間采用標(biāo)準(zhǔn)接口對(duì)接這樣任何一個(gè)環(huán)節(jié)出了問題都可以單獨(dú)替換不牽一發(fā)動(dòng)全身。協(xié)議選擇上我堅(jiān)持“標(biāo)準(zhǔn)優(yōu)先”。老設(shè)備走M(jìn)odbus TCP西門子PLC走S7comm羅克韋爾走EtherNet/IP新系統(tǒng)能支持OPC UA的盡量統(tǒng)一到OPC UA。這些協(xié)議都是行業(yè)公開標(biāo)準(zhǔn)有現(xiàn)成的開源庫(kù)可以用不需要依賴廠家私有SDK。上層數(shù)據(jù)模型則統(tǒng)一采用基于JSON Schema的標(biāo)簽結(jié)構(gòu)不管底層是寄存器地址還是對(duì)象節(jié)點(diǎn)到了openrig里都?xì)w一化成同樣的數(shù)據(jù)格式。這個(gè)設(shè)計(jì)讓整個(gè)系統(tǒng)具備了很強(qiáng)的兼容性現(xiàn)場(chǎng)加一臺(tái)新設(shè)備只需要配置一個(gè)新的采集任務(wù)不需要改上層邏輯。2. 核心技術(shù)方案拆解2.1 數(shù)據(jù)接入層多協(xié)議適配策略與網(wǎng)關(guān)選型數(shù)據(jù)接入是整個(gè)openrig最核心的一層難點(diǎn)在于協(xié)議適配。我結(jié)合現(xiàn)場(chǎng)經(jīng)驗(yàn)把鉆井設(shè)備常見的通訊協(xié)議分成四類Modbus TCP/RTU、S7comm西門子私有協(xié)議、EtherNet/IP羅克韋爾、OPC UA。其中Modbus TCP最普及幾乎所有PLC和儀表都支持寄存器地址分保持寄存器和輸入寄存器兩種讀寫屬性不同接入時(shí)要區(qū)分清楚。網(wǎng)關(guān)硬件選擇上我走過一段彎路。最早用普通工控機(jī)直接插網(wǎng)線跑采集程序結(jié)果現(xiàn)場(chǎng)震動(dòng)大、粉塵多硬盤半年就報(bào)廢了后來換成無風(fēng)扇工業(yè)網(wǎng)關(guān)情況才穩(wěn)住。目前在用的配置是CPU賽揚(yáng)J6412以上四核處理器跑Modbus輪詢毫無壓力內(nèi)存16GB DDR4考慮到邊緣計(jì)算和消息緩存內(nèi)存盡量留足存儲(chǔ)128GB SSD建議用工業(yè)級(jí)固態(tài)掉電不容易損壞網(wǎng)口至少3個(gè)千兆網(wǎng)口一個(gè)接辦公網(wǎng)一個(gè)接設(shè)備網(wǎng)一個(gè)預(yù)留做級(jí)聯(lián)系統(tǒng)Ubuntu 22.04 LTS長(zhǎng)期維護(hù)穩(wěn)有了網(wǎng)關(guān)硬件采集程序我推薦用Node-RED做快速原型生產(chǎn)環(huán)境則建議直接用Telegraf加自定義插件。Node-RED調(diào)試方便拖拽連線就能看到數(shù)據(jù)流很適合在現(xiàn)場(chǎng)摸點(diǎn)位。但正式穩(wěn)定運(yùn)行還是Telegraf這種常駐服務(wù)更可靠資源占用低、崩潰自動(dòng)重啟、日志也規(guī)范。openrig默認(rèn)采用Telegraf作為采集主引擎用Modbus插件做寄存器輪詢用OPC UA插件做節(jié)點(diǎn)訂閱配合MQTT插件把數(shù)據(jù)推送到消息總線。2.2 點(diǎn)位表設(shè)計(jì)數(shù)據(jù)建模與歸一化映射點(diǎn)位表是整個(gè)openrig的“圖紙”比采集程序本身還重要。點(diǎn)位表設(shè)計(jì)得不好后面所有環(huán)節(jié)都會(huì)跟著遭殃。我見過太多項(xiàng)目現(xiàn)場(chǎng)工程師隨便拿Excel列了幾行地址就開始采集結(jié)果數(shù)據(jù)上來了卻不知道哪個(gè)點(diǎn)對(duì)應(yīng)哪個(gè)設(shè)備單位也不統(tǒng)一報(bào)警閾值更是無從談起。openrig采用一套相對(duì)嚴(yán)謹(jǐn)?shù)狞c(diǎn)位建模方式。每個(gè)測(cè)點(diǎn)必須包含以下信息tag編號(hào)全局唯一比如PUMP_01_DISCHARGE_PRESSURE設(shè)備編號(hào)所屬設(shè)備比如MUD_PUMP_01信號(hào)名稱中文描述比如“1號(hào)泥漿泵排出壓力”數(shù)據(jù)類型INT16、UINT32、FLOAT32等字節(jié)序大端還是小端這個(gè)經(jīng)常被忽略但錯(cuò)了數(shù)據(jù)全是亂的寄存器地址Modbus地址或OPC UA節(jié)點(diǎn)ID縮放系數(shù)原始值乘以多少得到工程量比如壓力變送器量程0到60MPa對(duì)應(yīng)4到20mA要換算成實(shí)際壓力值偏移量一般配合縮放系數(shù)使用單位MPa、r/min、kN等報(bào)警閾值高報(bào)、低報(bào)、高高報(bào)、低低報(bào)點(diǎn)位表本身用JSON格式存儲(chǔ)放在網(wǎng)關(guān)的/etc/openrig/tags/目錄下一個(gè)設(shè)備一個(gè)文件方便管理。下面是一段實(shí)際的點(diǎn)位配置示例{ tag_id: PUMP_01_DISCHARGE_PRESSURE, device: MUD_PUMP_01, description: 1號(hào)泥漿泵排出壓力, protocol: modbus, plc: { host: 192.168.10.11, port: 502, unit_id: 1 }, register: { address: 30001, type: INT16, byte_order: BIG_ENDIAN }, conversion: { scale: 0.01, offset: 0 }, unit: MPa, alarm: { high: 35.0, low: 5.0, high_high: 40.0, low_low: 2.0 } }這樣設(shè)計(jì)的好處是一個(gè)測(cè)點(diǎn)的所有屬性都在同一個(gè)文件里采集程序、報(bào)警引擎、可視化平臺(tái)都可以直接讀取不用維護(hù)三套不同的配置。而且點(diǎn)位文件支持版本管理用Git存放誰改了啥一目了然這個(gè)習(xí)慣我強(qiáng)烈推薦。2.3 邊緣計(jì)算與數(shù)據(jù)清洗讓原始數(shù)據(jù)變得可分析PLC里讀出來的原始數(shù)據(jù)是不能直接進(jìn)數(shù)據(jù)庫(kù)的中間必須經(jīng)過數(shù)據(jù)清洗和邊緣計(jì)算。鉆井現(xiàn)場(chǎng)的電氣環(huán)境惡劣變頻器干擾、通訊抖動(dòng)都會(huì)讓數(shù)據(jù)出現(xiàn)毛刺和跳變。如果把這些臟數(shù)據(jù)直接存進(jìn)時(shí)序庫(kù)后面做趨勢(shì)分析、報(bào)警判斷都會(huì)被帶偏。openrig在邊緣網(wǎng)關(guān)層面做了三層處理。第一層是去毛刺采用中值濾波算法對(duì)連續(xù)五個(gè)采樣點(diǎn)取中值能有效消除偶發(fā)跳變。第二層是死區(qū)判斷只有變化超過設(shè)定閾值的數(shù)據(jù)才寫入數(shù)據(jù)庫(kù)比如泵壓變化大于0.1MPa才記錄這樣既能保留真實(shí)趨勢(shì)又能減少無效數(shù)據(jù)量。第三層是變化率限制鉆井參數(shù)都有物理極限比如大鉤載荷不可能在0.1秒內(nèi)從0升到200噸超出物理上限的變化率直接丟棄防止程序錯(cuò)誤導(dǎo)致的異常值混入。邊緣計(jì)算還承擔(dān)了報(bào)警預(yù)判的功能。傳統(tǒng)的做法是把所有數(shù)據(jù)傳到服務(wù)器再由服務(wù)器統(tǒng)一判斷報(bào)警這樣延遲高而且斷網(wǎng)期間完全失去監(jiān)控能力。openrig把報(bào)警規(guī)則下發(fā)到邊緣網(wǎng)關(guān)網(wǎng)關(guān)本地就能判斷是否超限產(chǎn)生報(bào)警事件后立即通過MQTT推送即使和上位機(jī)失去連接報(bào)警記錄也會(huì)先緩存在本地網(wǎng)絡(luò)恢復(fù)后自動(dòng)補(bǔ)傳。這個(gè)機(jī)制在現(xiàn)場(chǎng)很實(shí)用特別是偏遠(yuǎn)井隊(duì)網(wǎng)絡(luò)不穩(wěn)定的時(shí)候。2.4 傳輸與存儲(chǔ)選型MQTT消息總線和時(shí)序數(shù)據(jù)庫(kù)數(shù)據(jù)傳輸我選MQTT協(xié)議原因很簡(jiǎn)單——輕量、可靠、生態(tài)成熟。網(wǎng)關(guān)采集到的數(shù)據(jù)以JSON格式發(fā)布到MQTT主題主題命名采用層級(jí)結(jié)構(gòu)比如openrig/rig001/mud_pump_01/discharge_pressure這樣下游訂閱方可以直接按主題過濾數(shù)據(jù)。MQTT Broker選擇了EMQX開源版功能足夠支持WebSocket、規(guī)則引擎、數(shù)據(jù)橋接還能做簡(jiǎn)單的認(rèn)證授權(quán)防止無關(guān)設(shè)備接入。存儲(chǔ)層選用云原生時(shí)序數(shù)據(jù)庫(kù)目前在openrig中默認(rèn)支持兩款I(lǐng)nfluxDB 2.7和TDengine 3.x。InfluxDB生態(tài)成熟Grafana支持好適合數(shù)據(jù)量中等的單井監(jiān)控場(chǎng)景。TDengine則在超大規(guī)模數(shù)據(jù)存儲(chǔ)和聚合查詢上更有優(yōu)勢(shì)適合做多井集群后端的統(tǒng)一數(shù)據(jù)平臺(tái)。兩者的數(shù)據(jù)模型在openrig中被抽象成統(tǒng)一的時(shí)序標(biāo)簽結(jié)構(gòu)measurement作為測(cè)點(diǎn)名稱tag攜帶設(shè)備號(hào)、井號(hào)、數(shù)據(jù)類型等維度信息這樣上層應(yīng)用不用關(guān)心底層用的是什么數(shù)據(jù)庫(kù)。寫入策略上我吸取了一個(gè)教訓(xùn)不要高頻寫入原始數(shù)據(jù)。普通PLC的掃描周期是幾十毫秒到幾百毫秒如果每次變化都寫庫(kù)一臺(tái)井一天就能產(chǎn)生幾百萬條記錄存儲(chǔ)和查詢壓力都很大。openrig默認(rèn)按一秒一個(gè)采樣點(diǎn)落庫(kù)這個(gè)頻率既能完整還原作業(yè)過程曲線又不會(huì)把磁盤寫爆。非得需要更精細(xì)數(shù)據(jù)的場(chǎng)景比如錄井分析再單獨(dú)開高頻通道低頻通道和高頻通道分開存儲(chǔ)互不影響。3. 實(shí)操過程從零搭建一套o(hù)penrig監(jiān)控系統(tǒng)3.1 第一步現(xiàn)場(chǎng)設(shè)備盤點(diǎn)與點(diǎn)位梳理搭建openrig的第一步不是安裝軟件而是帶著筆記本和網(wǎng)線去井場(chǎng)做設(shè)備盤點(diǎn)。你需要搞清楚現(xiàn)場(chǎng)到底有哪些PLC、分別是什么品牌型號(hào)、各自掛在哪個(gè)IP地址段、有哪些數(shù)據(jù)值得采集。這個(gè)過程看起來簡(jiǎn)單實(shí)際上最費(fèi)精力因?yàn)楝F(xiàn)場(chǎng)文檔經(jīng)常和實(shí)際不符IP地址改了沒更新、寄存器地址描述模糊這類問題很常見。我每次盤點(diǎn)都會(huì)制作一張?jiān)O(shè)備清單表字段包括設(shè)備名稱、PLC型號(hào)、通訊協(xié)議、IP地址、端口號(hào)、寄存器起始地址、數(shù)據(jù)類型、數(shù)據(jù)長(zhǎng)度、采集優(yōu)先級(jí)、備注。以一口常規(guī)鉆井井隊(duì)為例主要設(shè)備大概是這幾類設(shè)備系統(tǒng)PLC型號(hào)主要采集參數(shù)電控系統(tǒng)絞車/轉(zhuǎn)盤Siemens S7-1500絞車轉(zhuǎn)速、大鉤高度、鉆壓、扭矩、轉(zhuǎn)盤轉(zhuǎn)速泥漿泵組獨(dú)立控制柜Modbus從站泵沖、泵壓、油溫、油壓頂驅(qū)系統(tǒng)專用控制器OPC UA頂驅(qū)轉(zhuǎn)速、扭矩、傾角固控系統(tǒng)分布式IO站液位、振動(dòng)篩狀態(tài)發(fā)電房發(fā)電機(jī)控制器功率、電壓、電流點(diǎn)位梳理完成后用前面講的JSON格式建好點(diǎn)位文件每個(gè)設(shè)備一個(gè)文件。這一步千萬別偷懶寧可多花一天時(shí)間把點(diǎn)位核對(duì)清楚也不要等數(shù)據(jù)采集上來了再返工。實(shí)測(cè)告訴我點(diǎn)位表核對(duì)到位后續(xù)整個(gè)系統(tǒng)搭建通常一次就能跑通。3.2 第二步采集網(wǎng)關(guān)部署與容器化配置設(shè)備盤點(diǎn)完就可以部署采集網(wǎng)關(guān)了。我習(xí)慣用Docker Compose來編排所有服務(wù)好處是部署速度快、環(huán)境隔離、依賴管理省心。網(wǎng)關(guān)上一共跑四個(gè)容器telegraf采集、emqx消息總線、nodered調(diào)試用、tailscale遠(yuǎn)程維護(hù)。時(shí)序數(shù)據(jù)庫(kù)InfluxDB我放在服務(wù)器上不放在井場(chǎng)網(wǎng)關(guān)這樣讀取歷史數(shù)據(jù)不影響采集性能。下面是一份精簡(jiǎn)版的docker-compose配置實(shí)際使用時(shí)按現(xiàn)場(chǎng)情況調(diào)整version: 3.8 services: telegraf: image: telegraf:1.29 container_name: telegraf volumes: - ./telegraf/telegraf.conf:/etc/telegraf/telegraf.conf:ro - ./tags:/etc/openrig/tags:ro network_mode: host restart: unless-stopped emqx: image: emqx:5.3 container_name: emqx ports: - 1883:1883 - 8083:8083 - 18083:18083 volumes: - ./emqx/data:/opt/emqx/data restart: unless-stopped nodered: image: nodered/node-red:3.1 container_name: nodered ports: - 1880:1880 volumes: - ./nodered/data:/data restart: unless-stoppedTelegraf的配置是采集的命脈。Modbus插件采用輪詢模式輪詢頻率我一般設(shè)成500毫秒太快怕PLC扛不住太慢又怕實(shí)時(shí)性不夠。每個(gè)PLC站號(hào)單獨(dú)建一個(gè)采集任務(wù)打成獨(dú)立線程避免一個(gè)設(shè)備卡住拖垮其他設(shè)備。配置里還要注意寄存器步長(zhǎng)按32位、16位對(duì)齊不然讀出來的數(shù)據(jù)是錯(cuò)位的。Telegraf采集到數(shù)據(jù)后通過MQTT插件將結(jié)果發(fā)布到EMQX主題。MQTT的QoS我選級(jí)別1至少一次這樣至少不會(huì)丟數(shù)據(jù)配合邊緣緩存能保證大部分場(chǎng)景下的數(shù)據(jù)完整性。每個(gè)測(cè)點(diǎn)發(fā)布頻率默認(rèn)1秒這和落庫(kù)頻率保持一致。3.3 第三步數(shù)據(jù)落庫(kù)與可視化看板搭建數(shù)據(jù)從MQTT到InfluxDB我用的是EMQX的數(shù)據(jù)橋接功能直接在EMQX規(guī)則引擎里寫了一條SQL把openrig/#主題的JSON消息解析成時(shí)序數(shù)據(jù)再調(diào)用InfluxDB的寫入API保存。這么做比在Telegraf里配兩個(gè)插件更順因?yàn)镋MQX把消息去重、排序、格式化一把梭了Telegraf只負(fù)責(zé)采集職責(zé)更清晰。InfluxDB里我按“井號(hào)設(shè)備號(hào)”建立Bucket一個(gè)井一個(gè)Bucket方便做數(shù)據(jù)隔離和備份。測(cè)量點(diǎn)命名直接用點(diǎn)位文件里的tag_id標(biāo)簽則攜帶device、unit、description等元信息。這里有個(gè)經(jīng)驗(yàn)千萬別把中文描述放進(jìn)標(biāo)簽值時(shí)序數(shù)據(jù)庫(kù)查詢時(shí)中文容易出編碼問題統(tǒng)一用拼音或英文標(biāo)簽中文描述放到單獨(dú)的字典表里維護(hù)?？梢暬瘜又苯佑肎rafana接入InfluxDB數(shù)據(jù)源后我創(chuàng)建了一塊鉆井值班看板分為三個(gè)區(qū)域?qū)崟r(shí)報(bào)警區(qū)、設(shè)備運(yùn)行狀態(tài)區(qū)、歷史趨勢(shì)區(qū)。實(shí)時(shí)報(bào)警區(qū)采用表格面板按報(bào)警級(jí)別排序高報(bào)、高高報(bào)設(shè)備運(yùn)行狀態(tài)區(qū)用狀態(tài)面板展示泥漿泵、頂驅(qū)、絞車的運(yùn)行/停車狀態(tài)歷史趨勢(shì)區(qū)則用時(shí)間序列面板展示鉆壓、泵壓、大鉤高度的歷史曲線。整套看板做下來大概花費(fèi)兩個(gè)工作日比傳統(tǒng)組態(tài)軟件的開發(fā)周期短得多。Grafana的報(bào)警規(guī)則配置同樣值得講。除了按點(diǎn)位閾值直接判斷外我配置了持續(xù)報(bào)警超過閾值連續(xù)30秒才觸發(fā)有效避免了瞬間干擾毛刺導(dǎo)致的誤報(bào)警。報(bào)警通知走Webhook推到企業(yè)微信或短信網(wǎng)關(guān)都行值班人員的手機(jī)能立即收到。前提是做好報(bào)警分級(jí)普通報(bào)警只在看板顯示緊急報(bào)警才推送到手機(jī)不然天天半夜被吵醒誰也受不了。4. 常見問題與排查技巧實(shí)錄4.1 數(shù)據(jù)“漂移”和點(diǎn)位錯(cuò)位的隱性殺手現(xiàn)場(chǎng)調(diào)試時(shí)最詭異的現(xiàn)象是數(shù)據(jù)讀出來看著合理但數(shù)值對(duì)不上。有一次采集泥漿泵壓力讀出來的數(shù)值忽高忽低跟現(xiàn)場(chǎng)壓力表差了將近一倍。排查了半天發(fā)現(xiàn)不是通訊問題而是Modbus的字節(jié)序配置錯(cuò)了。這個(gè)泵的PLC是西門子S7-1200內(nèi)部以WORD為單位存儲(chǔ)但寫入連續(xù)區(qū)域時(shí)采用了“高字節(jié)在前”的排列方式。Telegraf默認(rèn)按大端解析FLOAT32讀出來的數(shù)值自然不對(duì)。后來把字節(jié)序改成BIG_ENDIAN數(shù)據(jù)立刻恢復(fù)正常。另一個(gè)容易踩坑的點(diǎn)是寄存器地址的起始位不一樣。有的PLC廠家從0開始編號(hào)有的從1開始Modbus協(xié)議里也有“0基地址”和“1基地址”的區(qū)分。現(xiàn)場(chǎng)最穩(wěn)妥的辦法是先用Modbus Poll這類調(diào)試工具手動(dòng)讀一遍已知值的點(diǎn)確認(rèn)地址、數(shù)據(jù)類型、字節(jié)序都對(duì)上了再正式接入openrig。這一步能幫你省下后面一星期的排查時(shí)間。4.2 采集頻率過高把PLC“拖死”剛搭建系統(tǒng)時(shí)我為了追求數(shù)據(jù)實(shí)時(shí)性把Modbus輪詢頻率調(diào)到了100毫秒。結(jié)果運(yùn)行一個(gè)小時(shí)現(xiàn)場(chǎng)PLC的反應(yīng)明顯變慢電控系統(tǒng)的邏輯掃描都受了影響——絞車剎車反應(yīng)延遲這對(duì)鉆井安全來說是非常嚴(yán)重的事。后來才明白很多老型號(hào)PLC的通訊處理器性能有限Modbus從站每個(gè)掃描周期只能處理有限個(gè)請(qǐng)求高頻輪詢占用了大量資源。解決辦法有兩個(gè)。一是降低輪詢頻率普通參數(shù)500毫秒到1秒足夠二是把我的采集點(diǎn)拆分成多個(gè)采集任務(wù)每個(gè)任務(wù)負(fù)責(zé)不同的寄存器區(qū)間分時(shí)輪詢避免高頻率連續(xù)請(qǐng)求同一個(gè)從站。實(shí)在需要高頻數(shù)據(jù)的點(diǎn)位單獨(dú)建一條獨(dú)立通訊鏈路用帶多網(wǎng)口的網(wǎng)關(guān)分擔(dān)流量。需要再次強(qiáng)調(diào)任何數(shù)據(jù)采集系統(tǒng)都絕不能影響被采設(shè)備的正常運(yùn)行這條底線必須守住。4.3 無線傳輸導(dǎo)致的隨機(jī)丟包和數(shù)據(jù)空洞井隊(duì)現(xiàn)場(chǎng)經(jīng)常用到無線網(wǎng)橋做數(shù)據(jù)回傳雷雨天氣或者設(shè)備移動(dòng)時(shí)容易丟包。MQTT的QoS 1雖然會(huì)重傳但實(shí)時(shí)數(shù)據(jù)對(duì)時(shí)效性敏感重傳過來的舊數(shù)據(jù)反而會(huì)干擾趨勢(shì)判斷。我為此加了一套時(shí)間戳機(jī)制Telegraf在采集到數(shù)據(jù)時(shí)立刻打上設(shè)備本地時(shí)間戳EMQX或InfluxDB側(cè)不再覆蓋這個(gè)時(shí)間只按這個(gè)時(shí)間來做存儲(chǔ)排序。這樣即使數(shù)據(jù)因?yàn)榫W(wǎng)絡(luò)延遲晚到幾分鐘數(shù)據(jù)庫(kù)里的時(shí)序邏輯也是正確的。對(duì)于長(zhǎng)時(shí)斷網(wǎng)的情況我在Telegraf側(cè)配置了本地緩存插件斷網(wǎng)期間采集數(shù)據(jù)先寫入磁盤中的隊(duì)列文件等網(wǎng)絡(luò)恢復(fù)后再按序補(bǔ)發(fā)。實(shí)際驗(yàn)證下來斷網(wǎng)兩個(gè)小時(shí)內(nèi)的數(shù)據(jù)基本能完整補(bǔ)回來超過兩個(gè)小時(shí)則對(duì)數(shù)據(jù)做降采樣壓縮只保留關(guān)鍵趨勢(shì)點(diǎn)防止積壓數(shù)據(jù)過多導(dǎo)致內(nèi)存暴漲。這套補(bǔ)傳機(jī)制對(duì)偏遠(yuǎn)井隊(duì)特別實(shí)用現(xiàn)場(chǎng)網(wǎng)絡(luò)中斷一兩天也沒關(guān)系歷史曲線不會(huì)出現(xiàn)大面積空洞。4.4 時(shí)鐘不同步讓報(bào)警記錄錯(cuò)亂有一次現(xiàn)場(chǎng)報(bào)警記錄的時(shí)間順序是亂的高報(bào)出現(xiàn)在低報(bào)之前調(diào)取歷史曲線也對(duì)不上。排查后發(fā)現(xiàn)網(wǎng)關(guān)和服務(wù)器的時(shí)間差了整整三分鐘原因是網(wǎng)關(guān)斷電重啟后BIOS時(shí)間回退而NTP服務(wù)沒有配置。工業(yè)現(xiàn)場(chǎng)設(shè)備斷電重啟很頻繁如果時(shí)間不同步所有數(shù)據(jù)的時(shí)序分析都會(huì)失真。解決方案是在每臺(tái)網(wǎng)關(guān)上強(qiáng)制啟用NTP時(shí)間同步指向一個(gè)公共NTP服務(wù)器或者井隊(duì)局域網(wǎng)內(nèi)的時(shí)鐘源。同時(shí)所有采集程序啟動(dòng)時(shí)都做一次時(shí)間較對(duì)Grafana服務(wù)器也同步到相同NTP源。時(shí)間同步這個(gè)細(xì)節(jié)往往是小項(xiàng)目最不受重視但影響最大的點(diǎn)。記住一句話時(shí)序數(shù)據(jù)庫(kù)里時(shí)間戳不對(duì)再好的數(shù)據(jù)都是垃圾。5. 運(yùn)維安全底線與擴(kuò)展方向5.1 網(wǎng)絡(luò)隔離絕不能把OPC UA直接暴露在辦公網(wǎng)很多人搭建數(shù)據(jù)采集系統(tǒng)后為了方便看數(shù)據(jù)直接把網(wǎng)關(guān)的OPC UA端口映射到辦公網(wǎng)甚至映射到公網(wǎng)。這是極其危險(xiǎn)的做法現(xiàn)場(chǎng)只要有人接入辦公網(wǎng)做了端口掃描就有可能會(huì)觸達(dá)到生產(chǎn)控制網(wǎng)絡(luò)。我從一開始就把設(shè)備網(wǎng)、辦公網(wǎng)、監(jiān)控網(wǎng)做了物理或邏輯隔離三個(gè)網(wǎng)絡(luò)之間用工業(yè)防火墻做策略控制只放行一條數(shù)據(jù)通道設(shè)備網(wǎng)到監(jiān)控網(wǎng)的單向傳輸而且只開放MQTT的1883端口和NTP的123端口。網(wǎng)關(guān)自身也做了訪問白名單只允許PLC主動(dòng)建立連接外部無法直接發(fā)起對(duì)網(wǎng)關(guān)的訪問。安全這個(gè)話題在工業(yè)現(xiàn)場(chǎng)很容易被忽略但一旦出了事代價(jià)往往非常大。openrig的設(shè)計(jì)里網(wǎng)絡(luò)安全不是后續(xù)加上的補(bǔ)丁而是從一開始就內(nèi)置的一層約束。即使現(xiàn)場(chǎng)規(guī)模很小我也建議至少把設(shè)備網(wǎng)和辦公網(wǎng)分開不要為了省一個(gè)交換機(jī)把風(fēng)險(xiǎn)留在身邊。5.2 從數(shù)據(jù)接入到設(shè)備健康管理的擴(kuò)展方向openrig目前解決的是“把數(shù)據(jù)接上來”的問題但數(shù)據(jù)接上來之后能做的事情遠(yuǎn)不止實(shí)時(shí)監(jiān)控。我正在做的擴(kuò)展方向有兩個(gè)一是設(shè)備健康評(píng)估基于歷史數(shù)據(jù)訓(xùn)練頂驅(qū)軸承、泥漿泵泵閥壽命的預(yù)測(cè)模型結(jié)合振動(dòng)和溫度特征提前預(yù)警故障二是鉆進(jìn)參數(shù)優(yōu)化把實(shí)時(shí)采集的參數(shù)和錄井?dāng)?shù)據(jù)關(guān)聯(lián)起來用簡(jiǎn)單規(guī)則引擎分析機(jī)械鉆速與鉆壓、轉(zhuǎn)速的關(guān)系給司鉆提供參數(shù)建議。這兩個(gè)方向的難度一個(gè)比一個(gè)大但基礎(chǔ)都是可靠的數(shù)據(jù)接入。如果你正準(zhǔn)備往這個(gè)方向走我的建議是從小處著手先把一套esp32或樹莓派搭最小可用的數(shù)據(jù)采集原型跑通再慢慢擴(kuò)充到完整鏈路。哪怕只采集一個(gè)泵壓只要觸發(fā)報(bào)警能準(zhǔn)時(shí)推送、掉線能自動(dòng)重連、數(shù)據(jù)能連續(xù)存三個(gè)月這套系統(tǒng)就算立住了?；氐介_頭說的那個(gè)痛點(diǎn)鉆井現(xiàn)場(chǎng)的數(shù)據(jù)孤島本質(zhì)上不是技術(shù)壁壘而是流程和認(rèn)知的問題。openrig的初衷就是把數(shù)據(jù)接入的主動(dòng)權(quán)還給一線工程師用開源組件和公開協(xié)議讓每個(gè)井隊(duì)都有能力搭建屬于自己的一雙“眼睛”。后續(xù)這個(gè)項(xiàng)目我還會(huì)繼續(xù)迭代點(diǎn)位建模那塊我想做成可視化的配置界面讓不熟悉JSON的工程師也能輕松維護(hù)點(diǎn)位表。如果你在搭建過程中遇到現(xiàn)場(chǎng)設(shè)備協(xié)議或系統(tǒng)設(shè)計(jì)方面的問題歡迎一起探討這些真實(shí)的現(xiàn)場(chǎng)經(jīng)驗(yàn)比任何技術(shù)方案本身都更有價(jià)值。