產線上很多東西都有人盯著：電機、變頻器、PLC、機器人。唯獨有一臺機器，平時最不起眼，出事卻最要命——那臺放在電柜里、或者掛在設備旁邊的工控機。

它一宕，整條線停。但很少有人提前盯著它。

很多車間里，工控機是“黑盒”。它平時不聲不響，出問題基本是突發：夏天高溫跳閘、內存越吃越緊最后卡死、硬盤用了幾年 SMART 已經報黃、半夜掉電系統起不來。等人發現，都是停機之后的事了。

其實這些故障在發生前，早就留了一堆痕跡：

1.CPU 溫度不是突然飆升的，是幾個月里一點點往上爬；

2.內存占用不是某天突然滿的，是每個班次之后都比上一個班次高一點；

3.硬盤 SMART 里的重映射扇區數、待映射扇區數，一直在漲，只是沒人去看；

4.頁錯誤率長期偏高，說明內存已經吃緊，離卡死不遠了。

問題從來不是“沒有數據”，是“沒人去看”。

它盯的是一臺機器，不是一條產線

先把定位說清楚，避免誤會。

成直PHM檢測系統監測的對象，是工控機這個計算節點本身，不是電機、減速機、主軸。它不測振動，不接 PLC，不采集轉速電流。如果你的需求是給設備做振動監測，那是另一類產品，這套不是干這個的。

為什么要單獨盯一臺工控機？因為在工業現場，工控機就是那個“單點”。它不是產線里最貴的設備，卻是最脆的那一環——它掛了，底下所有受它控制的東西一起停。電機壞一臺，產線還能降速頂一頂；工控機死機，是全停。

所以這套系統的邏輯很簡單：把那個最容易被人忽略、但停一次就全線癱瘓的節點，當成一等公民去管。

它到底采什么

具體到指標，采的是工控機主機自己的硬件狀態：

這些指標不是湊數的。每一類背后都對應一類真實故障：

1.CPU 溫度、功耗、頻率，對應的是散熱和供電問題。溫度爬升、降頻、掉壓，都是板子要出事的信號。

2.內存使用率和頁錯誤，對應的是內存泄漏和容量不足。很多工控程序跑久了會慢慢吃內存，掉不出來，最后就是越用越卡、越卡越死。

3.磁盤 SMART 是最典型的“提前量”。機械盤和 SSD 在徹底報廢之前，重映射扇區數會先漲，健康分先掉。這些數據不讀，盤就是突然壞的；讀了，就能提前換。

4.USB 插拔對應的是現場有人動硬件、或者接口接觸不良。1 秒一次輪詢，同型號的設備用“名稱 + PNP 設備 ID”區分，不會因為兩臺一樣的 U 盤插拔而漏報。

數據從哪來，為什么普通機器也能用

采這些數據，靠的不是外接傳感器，而是系統級的接口：

1.CPU 溫度，優先讀主板 MSR，讀不到回退 PDH，再不行走 WMI，最后還有一套 LibreHardwareMonitor 的兜底實現。

2.GPU 走 nvidia-smi，讀不到同樣有回退。

3.磁盤和 SMART，走 WMI。

這套四層回退的意義，說白了就是不挑硬件。不是非得某款高端主板、某個特定型號的傳感器芯片才能用，普通工控機、組裝機都能跑起來，只是能采到的指標多少有差別。現場最常見的機器往往是雜牌主板、老平臺，這種場景下，回退機制比“參數漂亮”實在得多。

數據怎么流，判斷在哪做

采集到之后，數據大致是這樣走的：

工控機本地采樣 → 寫進 CSV 和狀態文件 → AI 引擎讀 CSV 做分析和預測 → Server 出 API → 看板渲染。

這里有兩點值得單獨說。

第一，異常判斷在本地完成，不是全丟到云端再等回來。這樣外網斷了，本地照樣監測、照樣報警，過熱了該彈的警告當場彈，不用等網絡恢復。原始數據也不用全量上傳，省帶寬。

第二，它留雙份記錄：runtime 目錄和日志目錄各一份，留存 90 天。CSV 是 53 列、中文表頭、帶 BOM，用 Excel 直接打開不亂碼。這看著是小事，實際排查故障的時候，數據能直接打開、能看得懂，比什么都強。

AI 在干什么，以及它什么時候不說話

AI 引擎做兩件事：異常檢測，和趨勢預測。

檢測用的是 ADTK + PyOD 這套組合，預測用 statsforecast 的 AutoARIMA / AutoETS。它的價值不在“現在多少度”，而在“按這個爬升速度，還能撐多久”。CPU 溫度、內存占用、磁盤健康分，都能出預測曲線和剩余壽命估算。

但有一點要提前說清楚，這也是刻意設計的：數據不夠的時候，預測寧可留空，也不瞎報。剛上線前一兩個月，主要是狀態監控；要做到有意義的壽命預測，得攢一段真實運行數據，尤其是故障樣本。這期間看到預測曲線是空的，不是壞了，是它知道自己還沒把握。對一套要做“預測性維護”的系統來說，“不裝懂”比“瞎給數”重要。

告警怎么發，為什么不會刷屏

告警機制也是這套系統里下了功夫的地方。

健康分是統一打分的，不是哪個指標超了就報哪個。分數分優秀、良好、警告三檔，異常分級處理，每一條告警都帶原因，不是給個數字就完事。

防誤報做了幾件事：

1.持續時長門控：不是瞬時超標就報警，要持續一段時間才觸發，濾掉毛刺。

2.遞增冷卻：同一類告警報了之后，冷卻時間從 5 分鐘逐漸拉長到 2 小時，避免同一個問題反復刷屏。真的事態升級了，可以繞過冷卻強制再報。

3.合并通知：環形緩沖區攢 16 條，桌面彈窗和事件頁統一呈現，而不是一條一條往外蹦。

目標是：該報的一條不漏，不該報的不煩人。現場最怕的就是告警系統天天“狼來了”，報多了人就麻木了，真出事反而沒人看。

從異常到修完，能不能串起來

能。預警觸發之后，系統會生成維保工單：指派人員、跟蹤備件、記錄檢修結果。這樣“發現異常”到“完成維修”這一段，是有記錄的，不是彈一條報警就結束。

這個能力決定了它到底是“監測工具”還是“運維系統”。單點監測工具只告訴你“出事了”，然后就沒下文了；成套方案把后面的處置也接上。這也是它和那種只看溫度的小工具，最本質的區別。

它自己能活下來嗎

一個監測系統，最尷尬的是自己先崩了。所以它對自己的穩定性是有要求的：

授權和守護是分開的。有個看門狗進程，每分鐘自拉起，鏈上的采集、Server、AI 任何一個掛了，都會被打起來。停電重啟之后，靠計劃任務也能自己恢復。

掉電前會存傳感器快照，真遇到 BSOD，事后能知道“死之前是什么狀態”，排查不用全靠猜。

授權方式有兩種：加密狗綁定，或硬盤序列號綁定，二選一或兩者都認。token 有 300 秒有效期，拔了狗或授權失效，5 分鐘內關停。

一句話：它是按“7×24 常年不關機、且掛了要能自己爬起來”這個標準來做的。

它管不了的事，也提前說清

第一，前面反復強調的：不測振動、不接 PLC、不測電機主軸。定位就是工控機主機監控。

第二，模型需要數據。上線初期是狀態監控，精準預測要攢數據，這是物理規律，不是軟件能跳過的。

第三，硬件得選對。車間高溫、多塵、電壓不穩的地方，工控機本身要工業級寬溫、冗余存儲、防掉電設計。軟件再好，硬件拖后腿，監測系統自己先趴下，就談不上保護產線。

第四，管理要跟上。系統給出維保建議，現場沒有執行機制，建議就等于沒給。軟件解決“看得到”，解決不了“有人去修”。

怎么落地，建議分三步

真要上，別一上來就全廠鋪開。穩妥的做法是：

1. 先挑一條關鍵產線試點。選那條停一次損失最大的線，把工控機裝上，跑一到兩個月。

2. 這段期間看兩件事：一是看它報的東西準不準，有沒有漏報、誤報；二是攢數據，讓預測慢慢長出來。

3. 跑通了再擴。試點驗證過告警邏輯、工單流程都順了，再往其他工位、其他廠區鋪。