1. 邊緣算力升級背后的真實需求1.1 為什么工控機突然成了AI落地的香餑餑這兩年跟做工業(yè)自動化的朋友聊天話題繞來繞去最后總會落到同一個點上算力到底放在哪。以前大家習慣了兩種模式要么把所有數據傳到云端服務器處理要么在設備端用單片機做點簡單的邏輯判斷。但這兩種方式在當下的項目里越來越不夠用了。云端方案的問題在于延遲和帶寬。一條產線上的視覺檢測設備每分鐘要拍幾百張高清圖片全部往上傳網絡稍微抖動一下產線就得停。而且很多工廠的現場環(huán)境根本不允許把生產數據往外傳數據必須留在本地。單片機方案的問題更直接算力太弱跑個簡單的閾值判斷還行一旦涉及到圖像識別、振動分析、預測性維護這些AI任務根本帶不動。工控機站上AI風口本質上是因為它卡在了一個非常微妙的位置上。它比單片機強太多有完整的x86或ARM架構能跑完整的操作系統(tǒng)能裝GPU或NPU加速卡同時它又比云端服務器更貼近現場可以放在產線旁邊的電控柜里直接接傳感器和執(zhí)行器數據不出廠區(qū)就能完成推理。這種“邊緣算力”的定位恰好滿足了當前工業(yè)場景對實時性、數據隱私和成本控制的綜合需求。我見過一個典型的案例某汽車零部件工廠在質檢環(huán)節(jié)部署了基于工控機的AI視覺系統(tǒng)。以前用人工目檢一個班次需要四個質檢員漏檢率在百分之三左右。換成工控機加工業(yè)相機加輕量級深度學習模型之后單臺設備就能覆蓋整條產線推理延遲控制在五十毫秒以內漏檢率降到了千分之五以下。這個項目里用的工控機并不是什么高端型號就是一臺搭載了AMD嵌入式處理器的無風扇機型外加一張入門級推理卡。整套方案的成本比租用云端GPU實例三年的費用還低。1.2 邊緣算力升級到底升的是什么很多人一聽到“邊緣算力升級”第一反應就是換更好的CPU、加更貴的顯卡。這個理解不能說錯但太片面了。邊緣算力的升級是一個系統(tǒng)工程至少包含四個層面。第一層是計算架構的升級。以前工控機主要跑PLC邏輯或者簡單的HMI界面CPU性能過剩但AI算力為零。現在需要在保持低功耗的前提下集成專門的矩陣運算單元。AMD的7730U這類處理器之所以被頻繁提及就是因為它在十五瓦到二十五瓦的功耗區(qū)間里提供了八核十六線程的計算能力同時集成的顯卡也具備一定的并行計算能力可以分擔輕量級推理任務。第二層是接口與擴展能力的升級。邊緣AI設備需要接的東西太多了工業(yè)相機走USB3.0或GigE激光雷達走網口傳感器走RS485或CAN總線執(zhí)行機構走GPIO。工控機如果接口不夠就得外掛一堆轉換器穩(wěn)定性直線下降。所以現在選型的時候串口數量、網口數量、USB口數量都是硬指標。第三層是軟件棧的升級。以前工控機上跑個組態(tài)軟件就完事了現在要裝Docker、要跑Python推理腳本、要支持TensorRT或ONNX Runtime。操作系統(tǒng)從Windows CE換成了Ubuntu或者Windows 10 IoT開發(fā)方式從梯形圖變成了Python加C混合編程。第四層是運維方式的升級。邊緣設備分散在各個現場不可能每臺都接顯示器鍵盤去調試。遠程部署、遠程監(jiān)控、OTA升級這些能力在邊緣AI項目里是剛需。我見過太多項目因為沒做好遠程運維設備出問題之后工程師要開車幾百公里去現場插U盤重裝系統(tǒng)。1.3 哪些場景最適合用工控機做AI推理不是所有AI任務都適合放在工控機上跑。根據我這幾年接觸的項目以下幾類場景的匹配度最高。工業(yè)視覺檢測是最大的應用場景。包括表面缺陷檢測、尺寸測量、字符識別、裝配驗證等。這類任務的特點是模型相對固定輸入是圖像輸出是分類或回歸結果對延遲要求高但對模型復雜度要求不高。用YOLO系列或者MobileNet系列的小模型在工控機上配合入門級推理卡就能跑到實時。設備預測性維護是另一個快速增長的方向。通過振動傳感器、溫度傳感器、電流傳感器采集設備運行數據在工控機上跑異常檢測算法提前發(fā)現軸承磨損、電機失衡等問題。這類任務的數據量不大但需要長期穩(wěn)定運行對工控機的可靠性和散熱設計有要求。邊緣側的語音交互也開始出現在工業(yè)場景里。比如工人戴著降噪耳機通過語音指令查詢設備狀態(tài)或者錄入質檢結果。這需要在本地完成語音喚醒和命令詞識別不能依賴云端因為車間里網絡覆蓋不一定好。AGV和移動機器人的本地決策同樣依賴邊緣算力。AGV上的工控機需要實時處理激光雷達點云、攝像頭圖像和里程計數據完成SLAM和路徑規(guī)劃。這類場景對功耗和體積的要求比固定式設備更苛刻。注意如果你的AI模型參數量超過一億或者需要跑大語言模型做復雜推理工控機的邊緣算力大概率不夠用。這時候要么用更強大的邊緣服務器要么采用云邊協(xié)同的架構把重任務放云端輕任務放邊緣。2. 工控機選型與AI部署的核心細節(jié)2.1 處理器怎么選從AMD 7730U說起選工控機做AI推理處理器是第一個要過的關。市面上主流的方案有Intel的酷睿系列、AMD的銳龍嵌入式系列、還有各種ARM架構的芯片。最近被頻繁問到的AMD 7730U我專門拿了一臺樣機做了兩周的測試這里把真實感受說一下。7730U是一顆八核十六線程的移動端處理器基礎頻率兩吉赫茲加速頻率能到四點五吉赫茲集成Radeon顯卡TDP默認十五瓦可以配置到二十五瓦。放在工控機里這個功耗水平意味著可以用無風扇或者小風扇的散熱方案整機體積能控制得很小。實際測試中我用它跑了幾個典型的邊緣AI任務。圖像分類方面ResNet-50模型在ONNX Runtime下的單張推理時間大約是四十毫秒換算下來二十五幀每秒對于大部分質檢場景夠用了。目標檢測方面YOLOv5s模型輸入六百四十乘六百四十推理時間約六十五毫秒十五幀每秒如果產線速度不快也能接受。如果是更輕量的YOLOv5n能跑到三十幀以上。跟同價位的Intel方案比7730U的優(yōu)勢在于多核性能和集成顯卡的并行計算能力。劣勢在于某些工業(yè)軟件對AMD平臺的兼容性不如Intel比如一些老版本的Halcon或者VisionPro在AMD平臺上偶爾會出現指令集不兼容的問題。所以如果你的項目要用到特定的商業(yè)視覺軟件選型前一定要確認兼容性。選處理器的核心邏輯是先確定你的AI模型需要多少算力再倒推處理器型號。不要反過來先買機器再想跑什么模型那樣很容易翻車。2.2 推理加速卡需不需要需要什么樣的工控機自帶的集成顯卡能跑一些輕量模型但如果你要跑稍微大一點的網絡或者對幀率有更高要求就需要加一張推理加速卡。目前主流的選擇有三類。入門級獨立顯卡比如英偉達的T400或者A2000。這類卡的優(yōu)勢是CUDA生態(tài)成熟TensorRT支持好幾乎所有主流深度學習框架都能無縫對接。T400的功耗只有三十瓦半高半長能塞進大部分工控機的擴展槽里。實測跑YOLOv5s能到一百幀以上比集成顯卡快好幾倍。專用推理加速棒比如英特爾的神經計算棒或者谷歌的Coral USB加速器。這類設備的優(yōu)勢是即插即用不需要額外的供電和散熱設計適合已經部署好的工控機做后期升級。劣勢是算力有限而且對模型格式有要求需要先做轉換。國產NPU模組比如瑞芯微或者寒武紀的加速卡。這類方案在特定場景下性價比很高但軟件生態(tài)相對封閉模型部署的靈活性不如英偉達方案。如果你的項目對國產化有要求可以重點考慮。實操心得加裝推理卡之前一定要確認工控機的電源功率是否夠用。我遇到過一臺工控機額定電源只有六十瓦加了一張三十瓦的卡之后滿載運行時電源過熱保護系統(tǒng)頻繁重啟。后來換了九十瓦的電源才穩(wěn)定下來。2.3 操作系統(tǒng)與軟件環(huán)境搭建工控機上跑AI操作系統(tǒng)的選擇直接影響后續(xù)的開發(fā)效率和運行穩(wěn)定性。目前主流的選擇是Ubuntu和Windows 10 IoT Enterprise。Ubuntu的優(yōu)勢在于對深度學習框架的支持最友好Docker、CUDA、TensorRT這些工具鏈在Linux下的性能和穩(wěn)定性都更好。而且Ubuntu可以裁剪得很精簡去掉圖形界面之后系統(tǒng)資源占用極低適合長期無人值守運行。缺點是現場調試不如Windows方便很多工控現場的工程師習慣了Windows環(huán)境。Windows 10 IoT的優(yōu)勢在于兼容性好大部分工業(yè)軟件和組態(tài)軟件都能直接跑遠程桌面調試也方便。缺點是系統(tǒng)更新不可控而且Windows下的推理性能通常比Linux低百分之十到二十。我的建議是如果項目允許優(yōu)先選Ubuntu。如果甲方或者現場運維團隊強烈要求Windows那就用Windows但一定要關閉自動更新并且做好系統(tǒng)鏡像備份。軟件環(huán)境搭建的步驟以Ubuntu為例大致是這樣的# 更新系統(tǒng)包 sudo apt update sudo apt upgrade -y # 安裝Docker curl -fsSL https://get.docker.com | sh sudo usermod -aG docker $USER # 安裝NVIDIA容器工具包如果使用NVIDIA推理卡 sudo apt install nvidia-docker2 sudo systemctl restart docker # 拉取推理鏡像 docker pull nvcr.io/nvidia/pytorch:23.10-py3這套流程我在多臺工控機上重復過基本不會出問題。唯一需要注意的是如果工控機沒有聯網需要提前把Docker鏡像和依賴包下載好用U盤拷貝過去。2.4 模型轉換與推理優(yōu)化在工控機上跑AI模型跟在服務器上跑是兩碼事。服務器上你可以直接用PyTorch加載模型推理工控機上必須做優(yōu)化否則性能差得遠。第一步是模型量化。把FP32的模型轉成FP16或者INT8推理速度能提升兩到四倍精度損失通常在百分之一以內。用TensorRT或者ONNX Runtime的量化工具都能做。第二步是算子融合。把卷積、批歸一化、激活函數這些連續(xù)的操作合并成一個算子減少內存訪問次數。TensorRT會自動做這個優(yōu)化ONNX Runtime也有類似的圖優(yōu)化。第三步是輸入尺寸調整。如果你的模型輸入是六百四十乘六百四十但實際場景中目標只占圖像的一小部分可以考慮降低輸入分辨率或者用滑動窗口的方式處理大圖。輸入尺寸從六百四十降到四百八十推理速度能提升將近一倍。第四步是批處理策略。如果工控機需要同時處理多路視頻流可以把多幀圖像拼成一個批次一起推理提高GPU利用率。但批處理會增加延遲需要根據實際場景權衡。# ONNX Runtime推理示例 import onnxruntime as ort import numpy as np # 加載量化后的模型 session ort.InferenceSession(model_int8.onnx) # 準備輸入 input_name session.get_inputs()[0].name input_data np.random.randn(1, 3, 640, 640).astype(np.float32) # 推理 outputs session.run(None, {input_name: input_data})這段代碼在7730U的工控機上跑YOLOv5s量化模型能穩(wěn)定在二十幀以上。3. 從零搭建邊緣AI工控機的完整實操3.1 硬件組裝與系統(tǒng)安裝拿到工控機之后第一步是硬件組裝。如果是準系統(tǒng)需要自己裝內存和硬盤。內存建議至少十六吉如果跑多個模型或者多路視頻三十二吉更穩(wěn)妥。硬盤建議用NVMe固態(tài)容量根據項目需求定一般五百吉起步。安裝Ubuntu系統(tǒng)的時候有幾個坑要注意。工控機通常沒有光驅需要用U盤啟動。制作啟動盤的時候用Rufus或者balenaEtcher都行但要注意分區(qū)格式選GPT還是MBR取決于工控機的BIOS模式?，F在大部分工控機都支持UEFI選GPT就行。系統(tǒng)安裝過程中建議選擇最小化安裝不要裝桌面環(huán)境。如果確實需要圖形界面裝完之后再單獨安裝輕量級的桌面比如XFCE或者LXDE。Ubuntu Server版本默認沒有圖形界面資源占用最低。安裝完成后第一件事是配置網絡和遠程訪問。工控機通常放在電控柜里沒有顯示器和鍵盤所以SSH是必須的。# 安裝SSH服務 sudo apt install openssh-server sudo systemctl enable ssh sudo systemctl start ssh # 查看IP地址 ip addr show配置好SSH之后就可以通過網絡從開發(fā)機遠程登錄工控機了。如果現場網絡環(huán)境復雜還可以配置一個反向隧道或者內網穿透工具方便遠程維護。但要注意任何遠程訪問方案都要做好安全加固修改默認端口、禁用密碼登錄、只允許密鑰認證。3.2 串口數據采集與AI推理的配合工控機在工業(yè)現場經常需要同時處理串口數據和AI推理。比如一個場景是工控機通過RS485讀取PLC的寄存器數據同時通過網口接收工業(yè)相機的圖像把兩者結合起來做判斷。Ubuntu下查看和配置串口常用的命令有這些# 查看所有串口設備 ls /dev/ttyS* ls /dev/ttyUSB* # 查看串口參數 stty -F /dev/ttyUSB0 -a # 配置串口參數 stty -F /dev/ttyUSB0 115200 cs8 -cstopb -parenb # 讀取串口數據 cat /dev/ttyUSB0Python下用pyserial庫操作串口import serial import time ser serial.Serial( port/dev/ttyUSB0, baudrate115200, bytesizeserial.EIGHTBITS, parityserial.PARITY_NONE, stopbitsserial.STOPBITS_ONE, timeout1 ) while True: if ser.in_waiting 0: data ser.readline() # 處理數據送入AI模型 process_data(data) time.sleep(0.01)注意工控機的串口設備名可能會因為USB轉串口芯片的不同而變化。建議用udev規(guī)則給串口設備綁定固定的名稱避免每次重啟后設備名改變導致程序找不到串口。3.3 時間同步問題的排查與解決沒有聯網的工控機時間不準確這個問題在邊緣設備里非常常見。原因通常有三個主板電池沒電了、系統(tǒng)沒有配置時間同步源、或者時區(qū)設置錯誤。主板電池沒電是最常見的原因。工控機斷電之后RTC時鐘靠主板上的紐扣電池維持。電池電壓低于二點七伏之后RTC就會走不準甚至停走。解決辦法很簡單換一顆CR2032電池就行。但要注意有些工控機的電池是焊死的需要拆機更換。如果電池沒問題那就是系統(tǒng)層面的配置問題。Ubuntu下可以用timedatectl檢查時間狀態(tài)timedatectl status如果顯示“System clock synchronized: no”說明沒有同步源。在沒有外網的環(huán)境下可以在局域網內搭一個NTP服務器讓所有工控機都從這個服務器同步時間。如果連局域網都沒有那就只能靠RTC但RTC的精度會隨時間漂移需要定期手動校準。還有一個容易被忽略的點是時區(qū)。有些工控機默認是UTC時間但現場操作人員看的是本地時間差八個小時。用下面的命令設置時區(qū)sudo timedatectl set-timezone Asia/Shanghai3.4 遠程部署與OTA升級方案邊緣設備部署之后最頭疼的事情就是升級。如果只有幾臺設備手動操作還能接受。如果有幾十上百臺必須有一套自動化的部署和升級方案。我的做法是用Docker Compose管理應用用Watchtower或者自己寫的腳本做鏡像更新。每臺工控機上跑一個輕量的Agent定期從內網的鏡像倉庫拉取新版本鏡像然后重啟容器。# docker-compose.yml version: 3 services: ai-inference: image: registry.local/ai-inference:latest restart: always devices: - /dev/ttyUSB0:/dev/ttyUSB0 volumes: - ./models:/app/models - ./logs:/app/logs environment: - MODEL_PATH/app/models/yolov5s.onnx - CONFIDENCE_THRESHOLD0.5這套方案的好處是升級回滾都很方便。新版本有問題把鏡像標簽改回舊版本重啟容器就行。而且Docker隔離了運行環(huán)境不會因為系統(tǒng)庫的變動導致應用跑不起來。OTA升級的時候要注意一定要做灰度發(fā)布。先升級一兩臺設備觀察二十四小時確認沒問題再全量推送。我見過一次全量升級導致所有設備同時重啟產線停了兩個小時損失很大。4. 常見問題與排查技巧實錄4.1 推理速度不達標的排查思路模型在開發(fā)機上跑得好好的部署到工控機上就慢得不行這是最常見的問題。排查的時候按下面的順序來。先確認工控機是否真的在用推理卡。有時候程序默認用了CPU推理GPU在一邊閑著。用nvidia-smi或者radeontop查看GPU利用率如果一直是零那就是沒用上。再確認模型是否做了優(yōu)化。直接拿PyTorch的FP32模型去推理速度肯定慢。檢查是否轉成了ONNX或者TensorRT是否做了量化。然后看輸入預處理是否成了瓶頸。圖像解碼、縮放、歸一化這些操作如果放在Python里做速度會很慢。盡量用GPU做預處理或者用OpenCV的CUDA加速版本。最后看散熱。工控機如果散熱設計不好處理器溫度上去之后會降頻性能直接砍半。用sensors命令查看溫度如果超過八十五度就要考慮加強散熱了?，F象可能原因排查方法解決措施GPU利用率零程序用了CPU推理查看代碼中device設置改為cuda或指定GPU推理速度只有開發(fā)機一半模型未優(yōu)化檢查是否用量化模型轉TensorRT或ONNX INT8運行幾分鐘后變慢處理器過熱降頻用sensors查看溫度加強散熱或降低功耗配置幀率波動大內存不足用free查看內存占用增加內存或減小批處理大小4.2 工控機穩(wěn)定性問題的獨家避坑技巧工控機在實驗室跑得好到了現場就各種問題這個我踩過的坑太多了。說幾個最典型的。電源問題是第一大坑?，F場的電控柜里通常有變頻器、接觸器這些干擾源電源質量很差。工控機如果直接用開關電源供電很容易受到干擾導致重啟或者死機。解決辦法是加一個隔離電源模塊或者用帶濾波功能的工業(yè)電源。我現在的項目里一律用明緯的工業(yè)電源雖然貴一點但穩(wěn)定性好太多。接地問題是第二大坑。工控機的金屬外殼一定要可靠接地否則靜電積累到一定程度會打壞接口芯片。我遇到過一臺工控機運行了三個月之后USB口全部失效拆開一看USB保護芯片被打穿了就是因為沒接地。灰塵問題在粉塵環(huán)境里特別嚴重。無風扇工控機靠外殼散熱灰塵積在散熱鰭片上之后散熱能力急劇下降。建議每半年清理一次用壓縮空氣吹。如果環(huán)境粉塵特別大考慮用帶正壓防塵設計的機箱。振動問題在移動設備或者沖壓設備旁邊很常見。工控機里的內存條、硬盤、擴展卡在長期振動下可能松動。解決辦法是用帶鎖扣的內存插槽硬盤用M.2接口的擴展卡用螺絲固定死。4.3 AI模型部署中的兼容性問題工控機跑AI模型兼容性問題主要集中在幾個地方。CUDA版本與驅動版本不匹配是最常見的。TensorRT對CUDA版本有嚴格要求CUDA版本又對驅動版本有要求。裝之前一定要查兼容性矩陣不要隨便裝最新版。我的經驗是用NVIDIA官方提供的Docker鏡像里面已經把版本都配好了省心。ONNX算子不支持是第二常見的。有些模型用了比較新的算子ONNX Runtime或者TensorRT不支持轉換的時候會報錯。解決辦法是用ONNX Simplifier做一下圖簡化或者把不支持的算子替換成等價的組合。Python版本沖突也很煩人。工控機上可能已經裝了Python 3.8但你的代碼需要Python 3.10。不要直接升級系統(tǒng)Python會搞壞系統(tǒng)工具。用conda或者pyenv創(chuàng)建一個獨立的環(huán)境。實操心得部署之前先在開發(fā)機上用跟工控機相同的Docker鏡像跑一遍確認沒問題再往工控機上推。這樣可以排除百分之九十的環(huán)境問題。4.4 邊緣設備遠程運維的實用方案最后說一下遠程運維。邊緣設備分散在各個現場運維成本很高。我目前用的方案是組合拳?；A層用SSH加密鑰認證所有工控機統(tǒng)一配置禁用密碼登錄。中間層用Ansible做批量命令執(zhí)行和配置管理幾十臺設備同時操作也沒問題。應用層用Docker Compose加Watchtower做自動更新。監(jiān)控層用Prometheus加Grafana每臺工控機上跑一個Node Exporter采集CPU、內存、溫度、磁盤這些指標在Grafana上統(tǒng)一展示。如果現場網絡不穩(wěn)定可以在工控機上跑一個輕量的MQTT客戶端把關鍵狀態(tài)數據發(fā)到內網的MQTT Broker這樣即使SSH連不上也能通過MQTT了解設備狀態(tài)。這套方案我在多個項目里用過管理幾十臺邊緣設備基本不需要去現場。唯一的要求是現場網絡要通哪怕帶寬很小也行MQTT的消息量很小每秒幾KB就夠了。我個人在實際操作中的體會是邊緣AI工控機的項目硬件選型只占三成剩下七成都在軟件部署和運維上。選一臺性能夠用的工控機不難難的是讓它在現場穩(wěn)定跑一年不出問題。所以前期在散熱、電源、接地這些基礎工程上多花點心思后期能省下大量的運維時間。另外模型優(yōu)化的工作一定要做不要指望工控機能直接跑開發(fā)機上的原始模型量化、剪枝、算子融合這些步驟省不得。