從 2024 年下半年開始我陸續(xù)在十幾個項目里接觸 CAN 轉 4G 網關覆蓋了充電樁遠程運維、環(huán)保數據采集、AGV 小車調度、水務泵站監(jiān)控這幾類典型場景。說句實話這玩意兒看著就是個“CAN 轉網口再加個 4G 模塊”的小盒子但真正拉到現場跑起來差距比想象中大得多。有的網關在實驗室里 ping 得歡一裝到電柜里就瘋狂掉線有的在產品頁面上寫著支持 CAN FD實際連標準幀都丟報文還有的斷網重連要等五分鐘調度系統那邊數據早就斷層了。這篇文章就是沖著這些問題來的。我把五款市面上主流的工業(yè)級 CAN 轉 4G 網關湊到了一起在同一套測試平臺、同一個運營商網絡環(huán)境、同一批模擬負載下做了為期三周的橫向實測。文章會先講清楚這類網關的運行機制和關鍵指標再給出可復現的測試方案然后把弱網表現、斷線重連、抗干擾能力、場景適配這些維度的實測結果擺出來最后落到選型決策上。內容不針對任何具體品牌做排名背書所有樣本均采用匿名代號呈現重點分析的是設計思路和適用邊界方便你根據自己項目的真實需求去挑。1. 從“現場抄數據”到“云端看數據”CAN 轉 4G 網關到底解決了什么1.1 先聊聊這個痛點是怎么來的工業(yè)現場有大量設備還在用 CAN 總線通信比如充電樁里的電池管理系統BMS、產線上的伺服驅動器、車輛底盤控制器、光伏逆變器、環(huán)保監(jiān)測儀這些設備內部跑的都是 CAN 報文。麻煩在于CAN 總線天生是為車內和現場短距離通信設計的總線長度通常不超過 40 米1Mbps 速率下根本沒有遠程訪問的能力。過去工程師要讀取設備數據只能帶著筆記本電腦和 USBCAN 分析儀跑到現場接上總線抓報文抓完回來再分析。偏遠的風電場、分散的污水處理站、跑在路上的工程機械每一次現場維護都是時間和金錢的消耗。CAN 轉 4G 網關要解決的就是這件事它作為 CAN 總線上的一個節(jié)點把總線上的報文接收下來通過內置的 4G 模塊走運營商網絡以 TCP、UDP 或 MQTT 等協議轉發(fā)到云平臺或調度中心。反過來遠程平臺也可以下發(fā)指令經由網關轉換成 CAN 報文寫入總線實現對設備的遠程配置與參數調整。裝了這臺設備工程師坐在辦公室里就能實時看到千里之外設備的運行狀態(tài)、故障碼和關鍵參數出現異常時也能第一時間遠程處置不用再頻繁跑現場。1.2 網關在數據鏈路里的位置和分工理解這類設備的定位可以把它拆成三個環(huán)節(jié)來看。最前端是 CAN 收發(fā)器它負責把總線上的差分信號轉換成 MCU 能處理的數字電平中間是主控芯片承擔協議解析、數據過濾、緩存和封裝工作最后是 4G 通信模塊負責建立蜂窩網絡連接把數據打包發(fā)往服務器。實際鏈路是這樣的設備端 CAN 節(jié)點輸出報文 - 網關 CAN 接口接收網關主控按規(guī)則解析/過濾報文 - 按預設協議封裝Modbus TCP、MQTT、自定義 JSON4G 模塊建立 PDP 上下文撥號獲取 IP - 與云端服務器建立 TCP/MQTT 長連接云端平臺接收數據并入庫/展示 - 下發(fā)指令反向走同一通道這里有個很容易被忽略的點網關不是簡簡單單把 CAN 報文“透傳”到網絡里就完事了。CAN 報文本身只有 8 字節(jié)數據CAN FD 可到 64 字節(jié)如果每幀都直接發(fā)到云端流量浪費嚴重而且在弱網環(huán)境下小包高頻傳輸非常容易丟。所以工業(yè)級網關都會設計數據過濾、周期聚合、閾值觸發(fā)和本地緩存機制把一堆原始報文整理成有意義的 JSON 數據再上傳。這個處理能力的高低直接決定了網關在真實項目中的可用性。1.3 工業(yè)級產品與商業(yè)級產品的本質差異外觀上看工業(yè)級 CAN 轉 4G 網關和商業(yè)級 LTE 路由器差別不大都是鐵殼盒子加天線。但拆開后會發(fā)現設計思路完全不同。最核心的差異有幾個維度。第一是供電設計。工業(yè)現場電柜里的電源波動非常大電機啟停、變頻器工作都會造成電壓跌落和浪涌。工業(yè)級網關通常支持 9V 到 36V 寬壓輸入內部有防反接、過流保護和 TVS 浪涌抑制電路而商業(yè)級產品一般只有 12V 單點供電稍微波動就可能重啟。第二是 CAN 接口的物理層保護。電柜里電機電纜、變頻器輸出線都是強干擾源CAN 收發(fā)器如果沒有做隔離和 ESD 保護雷擊浪涌一上來整顆芯片就燒了。我看到過好幾個項目就是因為貪便宜選了沒有隔離的網關一個雷雨天后 CAN 收發(fā)器直接報廢連帶著后端 MCU 一起遭殃。第三是看門狗和自恢復機制。工業(yè)級網關必須能在異常情況下自愈——4G 模塊死機了要能斷電重啟網絡斷開要能自動重新撥號主控程序跑飛了要能硬件看門狗拉回來。這個在實驗室里看不出差別但在無人值守的現場就是“半年不用管”和“三天兩頭跑現場”的區(qū)別。第四是工作溫度范圍。工業(yè)級產品一般標稱 -40℃ 到 85℃商業(yè)級往往只有 0℃ 到 50℃。這一點在北方冬季的戶外機柜里是生死線。我實測過有些廉價網關在 -20℃ 以下 4G 模塊會出現無法撥號的問題必須人工斷電重啟才恢復。2. 評測基準我在什么環(huán)境下測、怎么測、為什么這樣測2.1 被測五款產品的匿名畫像與代表類型為了讓對比有價值我特意選了五款設計取向完全不同的產品大致覆蓋了市面上主流的選擇邏輯。出于客觀性考慮這里不出現品牌名改用代號表示重點看它們的設計思路差異。樣本代號定位通信制式核心設計取向典型價格區(qū)間元GW-A老牌工業(yè)經典款Cat-4穩(wěn)定壓倒一切全隔離設計寬溫-40~85℃1800-2500GW-B高性價比國產款Cat-1功能齊全、價格親民面向預算敏感項目900-1300GW-C邊緣計算高端款Cat-4內置應用處理器支持本地腳本、復雜協議定制3000-4000GW-D雙卡冗余車載款Cat-4 雙模雙卡雙鏈路 北斗定位 動態(tài) IP 適配2200-3000GW-E嵌入式緊湊款Cat-1小體積低功耗適合 OEM 集成進設備內部700-1000這里面 GW-A 是典型的“不求新但求穩(wěn)”路線電路板布局規(guī)整接口全部做了隔離固件迭代慢但幾乎沒有大 Bug適合電力、交通這類對穩(wěn)定性要求極高的行業(yè)。GW-B 是這兩年國產供應鏈成熟后出現的卷王產品把核心功能都做進去了價格只有老牌的一半但外殼防護和 EMC 設計明顯省了成本。GW-C 自帶一個完整的應用處理器可以跑 Python 腳本和自定義協議解析適合對接那些封閉私有協議的設備可玩性最高。GW-D 針對車載場景做了雙卡冗余設計兩個運營商的 SIM 卡可以自動切換還內置了北斗定位模塊。GW-E 則是給設備制造商做配套用的體積只有巴掌大直接嵌入到設備主控板上沒有外殼和天線延長線。2.2 測試環(huán)境與設備清單整個測試周期為 21 天分三個階段進行。第一階段在實驗室做基線測試第二階段在真實工業(yè)現場做場景化測試第三階段做破壞性試驗。測試平臺統一搭建如下CAN 總線側使用周立功 USBCANFD-200U 作為總線主節(jié)點配合可編程 CAN 負載模擬器可以精確控制總線波特率、報文周期和數據內容4G 網絡側全部使用中國電信物聯網卡APN 按運營商標準配置測試期間固定在同一基站覆蓋范圍內信號強度 RSRP 穩(wěn)定在 -75dBm 到 -85dBm 之間服務器端部署在阿里云 ECS使用 MQTT 協議接收數據記錄每條消息的到達時間戳和服務端接收序號輔助設備示波器觀察 CAN 總線波形可編程直流電源模擬電柜電壓波動靜電槍做 ESD 抗擾度測試測試的核心邏輯是“單變量對比”。所有網關接在同一個 CAN 網絡上設置相同的報文過濾規(guī)則和上傳周期讓它們在同樣的網絡條件下跑同樣的數據然后對比誰丟包少、誰時延低、誰在異常情況下恢復快。這樣可以最大限度排除環(huán)境和配置差異把產品本身的素質暴露出來。2.3 評測維度和權重設計我做橫評不喜歡搞一堆花里胡哨的指標最終只關心六個維度通信穩(wěn)定性、斷線重連速度、CAN 總線兼容性、環(huán)境適應性、管理便捷性、整體成本。通信穩(wěn)定性權重最高占 30%因為這是網關存在的根本價值CAN 總線兼容性占 20%很多項目死在這上面斷線重連速度占 15%這決定了無人值守場景下數據斷層的時間管理便捷性和環(huán)境適應性各占 15%成本占 5%畢竟價格不是核心決策因素但不看也不行。打分方式采取百分制每個維度下設若干可量化的子項。例如通信穩(wěn)定性包括24 小時連續(xù)運行的丟包率、平均時延、時延抖動Jitter、長連接存活率CAN 總線兼容性包括支持的波特率范圍、CAN FD 支持情況、報文過濾規(guī)則靈活度、終端電阻是否可配置。所有子項均通過實測數據打分不采用廠家宣稱值。3. 硬指標實測弱網、斷線、強干擾下的真實表現3.1 弱網環(huán)境下的時延與帶寬表現弱網測試是我最看重的環(huán)節(jié)。城市里 4G 信號滿格的情況當然沒問題但工業(yè)設備經常部署在地下室、隧道、偏遠山區(qū)信號強度和穩(wěn)定性都遠不如市區(qū)。我在實驗室里用可調衰減器模擬了三種信號等級RSRP -85dBm良好、-100dBm一般、-110dBm較差分別測試各網關的端到端時延和數據上傳成功率。實測下來GW-A 和 GW-C 的表現最穩(wěn)。在 -85dBm 下兩者的平均端到端時延都在 40-55ms 左右數據上傳成功率接近 100%降到 -105dBm 時GW-A 的時延升到 220ms 左右但依然能保證 99.2% 的上傳成功率明顯是做了 TCP 層重傳優(yōu)化和發(fā)送緩沖調度的。GW-B 在良好信號下表現不錯時延約 60ms但信號降到 -105dBm 時丟包率直接飆到 4.7%而且出現了明顯的時延抖動有時一個包要重傳三四次才到達服務器。GW-E 的情況類似畢竟 Cat-1 模塊的上行能力和抗干擾能力本來就比 Cat-4 弱一截。這里要特別說一個容易被忽略的技術細節(jié)CAN 轉 4G 網關的數據流通常是“高頻小包”。例如采集 BMS 數據時網關可能每秒鐘要上傳 10 到 20 條消息每條消息就幾十字節(jié)。這種數據模式對 TCP 協議非常不友好因為每個小包都要走完 TCP 握手和 ACK 確認流程網絡稍有擁塞就會造成隊頭阻塞。做得好的網關會在應用層做數據聚合把 1 秒內的多條消息拼成一個包再發(fā)送做得差的直接每條消息一個 TCP 包弱網環(huán)境下基本就是災難。我專門數了一下GW-A 在弱網測試中實際發(fā)出的 TCP 包數量比 GW-B 少了約 60%說明它的應用層做了很好的 Nagle 算法優(yōu)化和批量打包處理。3.2 斷線重連與數據補傳斷線重連是工業(yè)網關的必修課但不同產品的處理策略差異巨大。我在測試中強制切斷網關的 4G 網絡連接通過屏蔽射頻信號持續(xù) 60 秒后恢復記錄從恢復信號到網關重新建立 MQTT 連接、開始上傳數據所需的時間。結果很有意思樣本代號斷線識別耗時重新撥號耗時MQTT 重連耗時總恢復時間斷線期間數據是否緩存GW-A8 秒12 秒3 秒約 23 秒是恢復后按序補傳GW-B15 秒20 秒5 秒約 40 秒是但補傳順序錯亂GW-C6 秒10 秒2 秒約 18 秒是帶時間戳按序補傳GW-D12 秒15 秒4 秒約 31 秒是補傳正常GW-E20 秒25 秒6 秒約 51 秒是但緩存容量小GW-C 的恢復速度最快因為它有獨立的應用處理器MQTT 客戶端跑在 Linux 系統上重連邏輯寫得很成熟。GW-A 中規(guī)中矩但非?？煽?。這里我必須點一下 GW-B 的問題它的緩存補傳順序是錯亂的。測試中我讓網關在斷線期間緩存了 200 條報文恢復連接后用 Wireshark 抓包分析發(fā)現補傳時的發(fā)送順序與緩存順序不一致有大約 15% 的消息亂序到達服務器。這在只看最終數值的場景下問題不大但如果下游系統依賴消息順序做狀態(tài)機推算就會出現嚴重的邏輯錯誤。數據補傳還有一個容易踩的坑緩存容量。有的網關標稱“支持斷網緩存”但實際緩存深度只有幾百條消息斷網超過 5 分鐘就開始丟數據。GW-E 就是這種因為嵌入式方案的 RAM 有限緩存隊列設計得很淺。我測了 10 分鐘斷網場景GW-E 總共丟了約 30% 的緩存數據而 GW-A 緩存了全部 600 多條消息一條不少。3.3 電磁干擾和電源波動測試工業(yè)現場的電磁環(huán)境之惡劣沒有親自去過電柜房的人很難想象。變頻器一啟動周圍幾米范圍內的電纜都在往外輻射噪聲大功率接觸器吸合瞬間母線上會竄入上千伏的尖峰脈沖。我把所有網關放在同一個測試環(huán)境中旁邊開了一臺 7.5kW 變頻器用示波器觀察 CAN 總線波形質量。先說 CAN 總線側的干擾測試。CAN 是差分信號理論上對共模干擾有很強的抑制能力但前提是收發(fā)器的共模抑制比CMRR夠好。變頻器運行時我在 CAN 總線上檢測到了約 ±2V 的共模噪聲疊加。GW-A 的 CAN 收發(fā)器做了磁隔離總線波形依然干凈眼圖清晰GW-B 和 GW-E 沒有隔離波形明顯變差出現了部分幀的位填充錯誤。具體表現為GW-B 在變頻器啟動瞬間出現了 3 次總線錯誤幀GW-E 出現了 1 次節(jié)點脫總線Bus-Off事件需要手動恢復。然后是電源波動測試。我用可編程電源模擬了電柜中常見的電壓跌落場景220V 交流側接觸器吸合時直流母線電壓會瞬間從 24V 跌落到 18V 甚至更低持續(xù)幾十毫秒。五款網關里GW-A、GW-C、GW-D 都扛住了 12V 到 36V 的寬壓波動在電壓跌落到 10V 時依然正常工作GW-B 和 GW-E 在電壓低于 14V 時出現了 4G 模塊重啟的現象雖然主控沒死但網絡連接已經斷了恢復需要重新撥號。這里要補充一個知識4G 模塊對供電質量非常敏感Cat-4 模塊在發(fā)射瞬間的峰值電流可以達到 2A 以上如果電源電路沒有足夠的儲能電容瞬間壓降就會導致模塊復位。這也是工業(yè)級網關和商業(yè)級網關在電源設計上最直觀的差距。4. 場景化對比充電樁、車載、分散點位的差異化實測4.1 充電樁與儲能場景高頻并發(fā)與多網關匯聚充電樁是 CAN 轉 4G 網關應用最密集的場景之一。一個充電站往往有幾十臺充電樁每臺樁內部的 BMS 通信都走 CAN 總線需要通過網關把數據上傳到運營平臺。這個場景的特點是數據量不算大但并發(fā)連接多而且對實時性有一定要求——特別是 BMS 的告警報文必須在幾百毫秒內到達平臺否則運營人員無法及時處理安全隱患。我在模擬充電站環(huán)境中掛載了 10 臺網關每臺網關分別連接一個模擬 BMS 節(jié)點以 10ms 周期發(fā)送電壓、電流、SOC 報文同時隨機插入告警事件報文。測試結果表明GW-A、GW-C、GW-D 在 10 臺并發(fā)時都能穩(wěn)定工作服務器端接收數據的亂序率低于 0.1%GW-B 在并發(fā)第 7 臺時開始出現偶發(fā)的心跳超時第 10 臺時 MQTT 連接被服務器端踢掉了一次原因是 GW-B 的心跳包發(fā)送間隔在負載升高時出現了較大波動GW-E 的并發(fā)性能最弱第 5 臺時 4G 模塊的數據吞吐已經接近上限。這個測試說明了什么如果你做的是大型充電站項目幾十臺樁的網關都匯聚到同一個平臺那么網關的并發(fā)連接管理能力和心跳穩(wěn)定性就是第一位的。GW-B 這種在單臺場景下表現還行的產品一旦規(guī)模上來就會拖后腿。儲能場景則有一個特殊需求BMS 告警數據必須優(yōu)先上傳而且要求端到端時延盡量低。我測試了各網關在 CAN 總線上出現高優(yōu)先級告警幀時的處理方式。GW-C 做得最好它支持在網關內部配置“告警幀優(yōu)先上傳”策略檢測到指定 ID 的報文后可以打斷當前的上傳隊列立即將告警數據發(fā)出GW-A 也支持類似功能但響應速度稍慢大約有 80ms 的額外延遲GW-B 和 GW-E 不支持優(yōu)先級處理所有報文都按順序排隊上傳告警數據的延遲取決于排隊的報文數量。在極端情況下100 條普通報文排在告警前頭告警到平臺的時間延遲了 2 秒多。對于儲能安全來說2 秒多的延遲是不能接受的。4.2 車載與移動機械場景振動、寬溫與動態(tài)網絡切換車輛和移動機械場景有它特有的苛刻條件持續(xù)振動、溫度劇烈變化、網絡信號不斷切換。我把 GW-D 和其他幾款網關裝在一臺商用車的底盤電控箱里跑了三天實測累計行駛 400 多公里經過城市、高速和山區(qū)路段。先說網絡切換。車輛在移動過程中會不斷在基站之間切換4G 模塊需要頻繁執(zhí)行小區(qū)重選和切換流程。GW-D 作為專門為車載設計的雙卡冗余產品在這方面的表現確實是標桿。它內置了雙運營商 SIM 卡當主卡信號低于閾值時能在 2 秒內切換到備用卡的網絡業(yè)務數據流基本不受影響。其他網關在基站切換時出現了不同程度的連接中斷GW-A 中斷約 5-8 秒后自動恢復GW-B 中斷 10-15 秒GW-E 最差在山區(qū)道路上有一次中斷了將近 40 秒MQTT 連接完全斷開需要重新建立。振動對 CAN 接口的物理層連接是個考驗。車輛行駛中的持續(xù)振動會導致接線端子松動、焊點疲勞開裂。裝車測試結束后我拆開所有網關檢查GW-A 和 GW-D 的 PCB 布局和接插件選型明顯更耐用——座子都是帶鎖扣的線纜有固定卡扣即使長時間振動也不容易松脫。GW-B 和 GW-E 用的普通端子排三天下來已經有輕微松動跡象如果長期使用需要定期緊固。寬溫表現方面車載環(huán)境的溫度變化非常大夏天暴曬后電控箱內溫度能到 60℃ 以上冬天又在零下。我在環(huán)境箱里做了高低溫循環(huán)測試-40℃ 到 85℃ 各保持 2 小時循環(huán) 5 次。GW-A、GW-C、GW-D 都通過了測試全程無重啟無數據丟失GW-B 在 -40℃ 低溫持續(xù) 1 小時后出現了一次 4G 模塊無法注冊網絡的問題恢復常溫后才正常GW-E 在高溫段 85℃ 時外殼溫度達到了 71℃內部溫度估計逼近 90℃雖然沒有死機但觸感已經非常燙手長期運行存在降頻風險。4.3 環(huán)保與水務分散點位小流量長連接的可靠性環(huán)保監(jiān)測站和水務泵站的典型特征是點位極度分散一個項目可能覆蓋幾十上百個站點每個站點只有少量 CAN 設備數據量小但要求 7×24 小時不間斷在線。這類場景最考驗的是長連接穩(wěn)定性——不是看你的網關能跑多快而是看它在一個月、三個月里能不能始終不掉線。我在實驗室里模擬了這種“小流量長連接”場景每臺網關連接到一臺模擬水質監(jiān)測儀CAN 波特率 250kbps每 30 秒上報一條包含 pH 值、濁度、余氯等參數的報文。服務器端持續(xù)監(jiān)聽 TCP 連接記錄斷線時間和重連行為。連續(xù) 7 天的測試結果如下GW-A穩(wěn)定在線 7 天連接無中斷數據完整性 100%GW-C穩(wěn)定在線 7 天期間有一次 2 秒的微小抖動但連接未斷開GW-D穩(wěn)定在線 7 天無異常GW-B第 3 天出現一次 TCP 連接靜默斷開服務端沒有收到 FIN 包約 30 秒后重新建立期間數據丟失幾條GW-E第 2 天和第 5 天各出現一次連接斷開每次恢復需 1-2 分鐘有約 10 條數據丟失TCP 連接靜默斷開是一個很典型的問題。運營商網絡中的 NAT 超時機制會清理長時間不活躍的 TCP 映射如果網關的心跳包間隔太長中間設備就會認為連接已死直接刪除映射表項。GW-B 的問題在于它的心跳間隔默認設置是 60 秒但在某些運營商網絡里 NAT 超時時間只有 30 秒導致連接被悄悄回收。解決方案是把心跳間隔調短到 15-20 秒或者啟用 TCP Keep-Alive 機制。這里也提醒一下如果你的項目部署在運營商網絡環(huán)境不確定的地區(qū)盡量選心跳間隔可遠程配置的網關方便后期調整。4.4 多網關遠程管理平臺與配置工具的易用性當項目里有一百臺網關分散在不同站點時逐臺現場配置是行不通的。遠程管理能力因此成為選型的重要考量。五款產品的管理方式差異很大樣本代號配置方式遠程批量管理固件遠程升級告警推送GW-AWeb 頁面 / 串口 CLI支持按分組批量下發(fā)支持斷點續(xù)傳支持郵件/短信GW-BWeb 頁面支持基礎批量配置支持不支持GW-CWeb 頁面 SSH支持可腳本化定制支持A/B 分區(qū)升級支持可對接第三方平臺GW-DWeb 頁面支持支持支持微信/郵件GW-E串口配置工具不支持不支持不支持GW-E 是典型的 OEM 產品思路它沒有做云管理平臺所有配置都得通過串口工具完成。如果你是把網關嵌入到自己的設備里一起賣給終端用戶這不算問題但如果你要用在分散點位項目里沒有遠程管理幾乎是災難——每次改配置都得跑現場固件升級更是無從談起。GW-C 的 A/B 分區(qū)升級是我比較喜歡的設計。它可以先把新固件下載到備用分區(qū)校驗完整后再切換啟動升級失敗會自動回滾到舊版本不會出現升級到一半斷電導致變磚的情況。對于無人值守站點的網關升級來說這個機制非常實用。5. 選型決策指南五款產品的適用邊界與避坑清單5.1 按需求場景選擇沒有最好的網關只有最合適的我把這次橫評的結論提煉成一張選型對照表你可以直接對照自己的項目需求來做初步判斷。項目場景優(yōu)先推薦備選方案推薦理由電力/交通等強穩(wěn)定性要求GW-AGW-C全隔離設計、寬溫寬壓、重連機制可靠預算敏感的批量部署GW-BGW-E功能齊全、基礎性能達標注意 EMC 短板復雜協議對接/私有協議解析GW-CGW-A內置應用處理器支持腳本化定制車載/移動機械遠程監(jiān)控GW-DGW-A雙卡冗余、動態(tài)網絡切換、北斗定位OEM 嵌入式集成GW-E無小體積、低功耗、方便嵌入設備內部充電樁和儲能項目要根據規(guī)模來定小規(guī)模10 臺以內用 GW-B 完全夠用性價比最高大規(guī)模50 臺以上建議至少按 GW-A 的穩(wěn)定性標準來選否則平臺側的心跳風暴和數據亂序問題會消耗大量運維精力。5.2 容易被忽略的隱性成本選型時除了看產品單價還必須算清三筆隱性成本。第一筆是天線成本。工業(yè)級網關通常配的是外置吸盤天線或膠棒天線但安裝位置電柜內還是電柜外對信號影響巨大。有些項目為了美觀把天線壓在電柜里4G 信號直接衰減 10dB 以上再好的網關也白搭。建議選配帶延長線的天線把天線引出電柜外固定。第二筆是 SIM 卡管理成本。如果你的網關支持雙卡就要考慮是配同一運營商的卡做備份還是配不同運營商做冗余。不同運營商的網絡覆蓋各有優(yōu)勢但跨運營商切換涉及 APN 配置和專網接入的適配需要提前測試。另外物聯網卡的管理平臺是否支持流量告警、批量充值、卡狀態(tài)監(jiān)控這些都會影響后期運維成本。第三筆是平臺對接成本。網關買回來之后你的云端平臺要能接收它的數據。MQTT 協議是目前兼容性最好的選擇所有被測產品都支持標準的 MQTT 3.1.1。但如果你用的是阿里云 IoT 套件或者騰訊云 IoT需要確認網關是否支持對應的認證方式和 Topic 規(guī)范。很多項目在對接環(huán)節(jié)耗掉的時間比選型本身還多。5.3 我踩過坑之后總結出的幾條硬建議三周測試下來有幾條心得值得單獨拎出來說。第一永遠不要輕信產品頁面上的“支持 CAN FD”。這次測的五款產品里有三款宣稱支持 CAN FD但實際只有 GW-A 和 GW-C 能完整處理 64 字節(jié)的 CAN FD 幀GW-B 的 CAN FD 支持只到 32 字節(jié)數據場超過就會丟幀。如果項目里有 CAN FD 設備務必在選型階段用真實的 CAN FD 報文做壓力測試不要只看參數表。第二關注 CAN 控制器的時鐘精度。這看起來是個小事實際影響很大。CAN 總線上所有節(jié)點的位時序必須同步如果網關的 CAN 控制器晶振精度不夠在高速率500kbps 以上下會產生較大的位填充誤差嚴重時會導致總線錯誤率上升甚至節(jié)點離線。這次測試中我在 1Mbps 波特率下分別掛載五款網關用 CAN 總線分析儀統計錯誤幀GW-B 和 GW-E 在連續(xù)運行 4 小時后出現了偶發(fā)的位錯誤而 GW-A 和 GW-C 全程零錯誤。對于長時間運行的總線網絡CAN 控制器時鐘精度的差距會穩(wěn)定地體現出來。第三搞清楚網關是否支持終端電阻的軟件配置。CAN 總線兩端必須各接一個 120 歐姆終端電阻如果網關內置了可切換的終端電阻安裝時就不用額外接線方便很多。但如果你的總線拓撲比較復雜多個節(jié)點都內置了終端電阻反而會導致反射問題。建議選擇終端電阻可通過軟件開啟/關閉的型號方便現場靈活調整。第四先跑一個月再批量部署。如果條件允許在正式項目里先裝 2 到 3 臺候選網關試運行一個月觀察它們在真實網絡環(huán)境、真實負載、真實天氣條件下的表現再決定是否批量采購。實驗室測試永遠替代不了真實環(huán)境尤其是運營商網絡的復雜性和現場電磁環(huán)境的惡劣程度只有實際跑過才知道產品靠不靠譜。第五別忽視技術服務支撐。工業(yè)項目的實施周期往往很長從選型到批量部署可能跨半年以上。如果廠家的技術支持響應速度慢、文檔不齊全后期你會非常痛苦。這次測試中 GW-A 和 GW-C 的廠商都提供了詳細的 API 文檔和示例代碼對接效率明顯高于其他幾家。按照這五條標準去篩基本可以淘汰掉一半以上的候選產品。真正留下來的可能不是參數最好看的也不是價格最低的但一定是在你的真實場景里最穩(wěn)的那臺。我在這次橫評里收獲最大的一點就是重新理解了穩(wěn)定性的含義——它不是實驗室里測出來的 99.999%而是現場那種電壓波動、信號弱、干擾強、沒人看守的環(huán)境下設備還能一聲不吭地把數據傳回來的那份踏實。選網關的時候多花點心思把邊界條件想清楚后面省下的運維時間遠比省下的那幾百塊差價值錢。