機器資料採集軟體:2026 年該買什麼(以及該躲什麼)
機器資料採集軟體是產線和任何想用產線動作做點什麼的系統之間的那一層。它從 PLC、感測器、視覺系統、MES,以及最近從對著機器拍的相機裡讀訊號,把這些訊號轉成資料庫、儀表盤、AI 模型能消費的資料流。
這個品類在五年裡從一兩家主導玩家擴充套件到了大約 20 家。一半人在解一些 2020 年還不存在的問題。另一半人在解過去由大 MES 廠商解、現在它們不再願意碰的問題。這篇文章面向需要把候選工具拉短名單、並希望有一張清晰地圖的運營或 IT 負責人。
機器資料採集軟體真正在做什麼
核心就三件事。接到資料來源(PLC、感測器、相機、MES、ERP、手工錄入的日誌)。把資料規整成帶時間戳、帶工程單位的一致格式。把資料交給消費它的系統(歷史資料庫、儀表盤、雲資料倉儲、AI 模型、製程工程師的電子表格)。
廠商之間的差異主要集中在第 1 步和第 3 步。中間那一段是大宗化的。廠商比拼的是原生支援多少協議(西門子 S7、Allen-Bradley、Modbus、OPC UA、MQTT、EtherNet/IP、Profinet,以及一長串各家專有協議),以及對接多少種消費端(SQL、時序資料庫、Snowflake、BigQuery、Azure Data Explorer、Power BI、Grafana、自定義 REST 端點)。
在中小型工廠裡,連線層比消費層重要。在已經有完整分析棧的大型工廠裡,情況反過來。
2026 年五類工具
下面五個桶基本能覆蓋 2026 年市場的大多數選擇。
1. 經典 SCADA 鄰接中介軟體
這類工具從歷史資料庫和 SCADA 工作流裡長出來:AVEVA PI、Inductive Automation Ignition、Wonderware/AVEVA System Platform、GE Proficy。在大體量 PLC 資料上很強,在現代雲對接和相機資料上很弱。價格高(按 tag 或按連線計價的許可費會很快堆起來)。可靠性高。在油氣、大型化工、大型離散製造裡是預設選擇。
什麼時候選它:你已經執行了多年的 PLC 與歷史資料庫資產,工廠 IT 團隊能放心運維,且短期內不準備引入相機式監控或雲端分析。
2. 現代開源棧
Node-RED + InfluxDB + Grafana,常常再加一個用來 MQTT 經紀的 Mosquitto。更有主張的開源捆綁:United Manufacturing Hub。正經的 MQTT 需求用 HiveMQ。總持有成本以工程師時間為主,不是許可費。天花板很高,門檻也很高(需要有人能運維)。
什麼時候選它:你有一支熟悉自託管的內部團隊,想避開廠商鎖定,願意用工程師時間而不是許可證美元買單。
3. 雲原生商業平臺
Tulip、Litmus Edge、HighByte、Cognite、Element、Cumulocity、AVEVA Data Hub。它們的銷售故事幾乎是同一份:比 SCADA 鄰接老棧更低的 TCO,更短的首個儀表盤上線時間,原生雲部署,給採購部門看的乾淨 IT 故事。計價方式是按裝置或按資料流,堆得比廠商口頭說的快。UX 和 AI 整合在不同廠商之間差距很大。
什麼時候選它:你想要現代化工具,不想自託管,願意為按裝置的訂閱費用列預算,12 個月內有一組明確要接的資料來源。
4. 相機·AI 優先的系統
新品類。把相機當作一等資料來源,而不是事後掛上去的東西。相機把畫面餵給計數零件、分類缺陷、檢測製程異常的視覺模型,產生的事件流和 PLC 資料走同一條管道。Enao Vision 屬於這一類。其他玩家包括 Augmentir、MakinaRocks,以及若干面向視覺的專用 MES 外掛。
什麼時候選它:你的瓶頸是想看清產線到底在做什麼(而不是 PLC 以為它在做什麼),希望一個工具能把相機資料和 PLC 資料放在同一層級。
5. 自建整合
很多工廠依賴一段調 OPC UA 客戶端的 Python 指令碼、把 CSV 倒到網路共享、再在上面掛幾張 Power BI 報表。這其實不是一類工具,而是沒有工具;但在小規模上它確實能跑,值得給它命個名。當指令碼凌晨兩點崩、又沒人會修的時候,它就不能再跑了。
什麼時候選它:1 到 2 條產線,一個負責維護指令碼的工程師,沒有預算。一旦複雜度上來,或者出現第二個需要維護這套系統的人,就立刻切到第 1 到第 4 類裡的某一種。
各類工具會在哪裡崩
經典 SCADA 鄰接中介軟體在相機資料和雲部署上崩。給 PI 伺服器接視覺系統感覺像在做 hack。把資料導到雲資料倉儲裡,會額外產生大多數團隊都低估的許可與工程成本。
現代開源棧不是被技術壓垮,是被人壓垮。當那位特定的工程師還在公司時,它跑得很漂亮;那個人一離職,它就跑不起來。第二個工程師學會這一套的成本,幾乎總是高於一年的商業許可費。
雲原生商業平臺在價格透明度上崩。掛牌價很少是真實價格,真實價格會隨用量以 PoC 裡看不到的方式增長。它們也會在邊角案例上崩:廠商還沒支援的長尾 PLC 協議,本地 IT 禁止雲出網的政策,執行在 1998 年沒有乙太網口的控制器上的產線。
相機·AI 優先系統會在 PLC 資料本來就夠用、相機只是徒增噪聲沒產生價值的時候崩。產線的照明和安裝做錯了,它們也會崩(任何視覺系統都一樣)。
自建會在那個寫指令碼的人第一次休假那一週崩。
在你這家工廠怎麼挑
按順序問三個問題。今天必須接的資料來源是哪些,18 個月之後還得接哪些?資料要落到什麼地方(歷史資料庫、雲資料倉儲、BI 工具、AI 模型)?誰負責維護這套系統,他們對自託管複雜度的耐受度有多少?
一家有 20 臺連了 PLC 的機器、一套已有 PI 歷史資料庫、一個小型 IT 團隊的工廠,大機率應該擴充套件現有的東西。有 5 條產線、沒有歷史資料庫、想要雲分析、願意按裝置付費的工廠,應該看雲原生商業那一類。最大的可視性缺口是 PLC 之外產線到底在發生什麼的工廠,應該看相機·AI 優先那一類。只有一個工程師、一條產線的工廠,在他沒去休假之前用自建也行。
錯誤的做法,是不按這三個問題、而按品牌知名度去挑。答案和隔壁工廠一樣的情況其實很少。
2026 年的成本
中型工廠(10 到 30 臺連了線的機器)各類成本的數量級。
經典 SCADA 鄰接:一次性投入 10 萬到 40 萬歐元,加上每年 15% 到 25% 的維保。
現代開源:許可 0 歐元,加 1 到 2 名全職工程師(全負載成本每年 10 萬到 20 萬歐元)。
雲原生商業:按裝置或資料流分檔,年訂閱 3 萬到 15 萬歐元。
相機·AI 優先:每條產線年訂閱 5,000 到 2 萬歐元,加上讓相機跑起來需要的硬體,每條產線 1,000 到 5,000 歐元的一次性安裝成本。
自建:那一個工程師的時間成本,加上他離開時整套東西塌掉的災難風險。
這些區間之所以寬,是因為真實數字取決於談判、量級、季末折扣。當方向參考用,別當報價用。
現場入門:資料採集系統的真實內部
2026 年能跑的資料採集系統不是單一產品,是一摞東西。當你跟廠商對坐、Demo 把一半東西糊掉的時候,能按部件名一個個點出來,會很有用。
在感測器層,輸入通常是幾種混合:測溫的熱電偶和 RTD、壓力變送器、振動變送器、流量變送器、做電力分析用的電流/電壓變送器。每路感測器訊號都要先做訊號調理(調理通常包含放大、隔離、濾波),再由模數轉換器從模擬轉成數字。轉換後的資料流會帶著訊號源序列號、時間戳、工程單位,被傳給下一級。
做這個轉換的 DAQ 硬體大致有三種形態。把讀數存到內部儲存、之後再下載的獨立資料記錄儀和錄波器(最簡單的資料記錄工作流,在遠端泵、發電機、HVAC 站房裡還很常見)。在乙太網或 USB 主幹上向主機流式上傳的模組化 DAQ 硬體(測試實驗室和研發臺架裡的主流形態)。以及把一小段 DAQ 棧和控制邏輯放進同一臺裝置的可程式設計邏輯控制器前端(生產線上的主流形態)。
硬體之上是 DAQ 軟體。它做的三件事,正好和工廠層面機器資料採集工具做的事有重疊。配置通道(取樣率、量程、濾波)。記錄並儲存過程資料(經常和歷史資料庫一起跑在同一臺 Linux 主機上)。透過即時曲線、儀表盤、報警給操作員展示讀數。面向使用者那一層用各種程式語言搭建:老棧裡用 C 和 C#,現代 Web 儀表盤用 Python 和 JavaScript,以及一長串廠商指令碼環境(LabVIEW、Codesys 結構化文字、Beckhoff TwinCAT)。
這段入門對工廠層面買家之所以重要,是因為同一個詞在不同尺度上意思不一樣。在電池研發實驗室裡說 "DAQ" 的測試工程師,通常指的是 National Instruments 的 PXI 機箱、一摞模擬輸入模組,加上面上的 LabVIEW。在包裝工廠裡說 "機器資料採集" 的運營負責人,通常指的是從 20 臺 PLC 把資料抽出來、送到儀表盤和 AI 模型的一段中介軟體。兩邊都對,兩邊都在用同一組詞,而同時賣給這兩個細分市場的廠商,會有意把術語說得含糊。銷售一上來聊 DAQ,先問他指的是 "感測器·轉換器棧" 還是 "PLC·儀表盤層"。這個回答會決定這件工具合不合適。
質量管理團隊比任何部門都更積極地在用 DAQ 資料。這些資料是每一次 CAPA、每一次供應商審計、每一個要求可追溯的客戶投訴裡的證據。用手寫日誌執行質量管理的工廠,和用資料採集系統執行的工廠,根本不在同一個十年裡。從前一種走到後一種的那一步,才是這類軟體真正在賣的東西,即使它對外打的招牌是 "生產力" 或 "視覺化" 也一樣。
FAQ
MQTT 跟機器資料採集工具是同一類東西嗎?不是。MQTT 是一種傳輸協議。機器資料採集工具通常會把 MQTT(或 OPC UA,或某家專有協議)作為它的某一種傳輸層。工具和協議是兩回事。
歷史資料庫和機器資料採集工具是不是兩個都要有?小型工廠不用。有大體量 PLC 資料的大型工廠要。歷史資料庫為高頻時序資料的存與查做了最佳化。採集工具為把資料送到那裡、以及送到其他消費端做了最佳化。
OPC UA 是什麼,需要嗎?OPC UA 是一種用於機器間資料交換的現代開放標準。絕大多數採集工具都支援它。如果你的機器支援(大多數新 PLC 都支援),那就需要。對老機器,通常要退回到廠商專有協議。
和 MES、ERP 怎麼銜接?採集工具把即時機器資料餵給 MES。MES 把彙總後的生產資料餵給 ERP。採集工具在這兩層的最上游。
從可視性缺口開始
選什麼工具,取決於缺口在哪。缺口是基於 PLC 資料的儀表盤,就選雲原生商業或開源。缺口是大批次機器佇列的企業報表,就留在經典棧裡繼續擴充套件它。缺口是 "PLC 給出的口徑之外、產線到底在發生什麼",就從相機·AI 優先這一類入手,其他事情之後再操心。
想更深入看相機式監控帶來什麼,參考另一篇 "攝影機生產監控"。想看這件事如何嵌入更寬的視覺化專案,參考另一篇 "生產監控系統"。
