搜尋
- 葡萄酒 | 威士忌 | 白兰地 | 啤酒 -
- 葡萄酒 | 威士忌 | 白兰地 | 啤酒 -

去年,在為一家物流公司建立車隊管理系統時,客戶希望能即時監控每輛卡車的油耗、引擎轉速和冷卻劑溫度。他們不只想要將資料儲存在本機,還需要將所有資料串流到雲端平台,以便調度員可以監控車輛狀態。.
聽起來很簡單。但當我們開始操作後,從車輛內部取得資料的過程卻比預期複雜得多。所有車輛資訊都是透過 CAN 匯流排傳送,但不同車款的訊息格式差異很大。讀取一汽卡車與東風卡車的引擎轉速,意味著要處理完全不同的 CAN 訊息 ID、資料欄位位置和轉換因子。.
我們最終使用雙 5G 車用閘道器來解決這個問題。閘道器透過 CAN 介面連接至車輛匯流排,解析所有訊息,然後透過 5G 網路將資料上傳至雲端。整個專案讓我深深體會到車輛閘道器和 CAN 匯流排需要如何協同運作。.
我們先來看看 CAN 匯流排實際上是什麼。CAN 是 Controller Area Network(控制器區域網路)的縮寫。博世早在 1980 年代就設計了這種通訊匯流排供汽車使用。.
為什麼我們需要 CAN 匯流排?現代車輛包含數十甚至數百個電子控制單元。引擎 ECU、變速箱 ECU、ABS ECU、儀錶板 ECU、車身控制 ECU,不勝枚舉。這些 ECU 需要進行通訊。如果您在每對 ECU 之間都鋪設獨立的電線,那麼線束將會是一場惡夢。.
CAN 匯流排將所有 ECU 連接到共用的匯流排。將其想像成一條地鐵線 - 所有車站都位於同一條路線上。任何 ECU 都可以傳送訊息給所有其他 ECU 接收。每個 ECU 都會選擇性地處理與其功能相關的訊息。.
商用車輛通常會運行 2-3 個獨立的 CAN 匯流排。動力總成 CAN 連接引擎、變速箱、ABS 及其他動力總成 ECU,通常以 500 kbps 或 250 kbps 的速度運作。車身 CAN 用於處理車燈、車鎖、氣候控制和舒適系統,通常以 125 kbps 的速度運行。也可能有專用的診斷 CAN 匯流排。.
車輛閘道器需要接入這些 CAN 匯流排來讀取資料。以 SV910 為例 - 它配備 3 個 CAN 連接埠,可同時連接到多個車輛 CAN 匯流排。.

究竟如何讀取這些資料?讓我們以讀取引擎轉速為例。.
第一步是物理連接. .將網關的 CAN 介面連接到車輛的 OBD 診斷埠或直接連接到 CAN 匯流排。商用車輛一般都有標準的 OBD 連接埠,通常位於儀表板下方或駕駛座旁邊。連接器為梯形,有 16 個接腳。.
CAN 匯流排使用兩條線的差動信號:CAN_H 和 CAN_L。在 OBD 連接器上,針腳 6 是 CAN_H,針腳 14 是 CAN_L。閘道器的 CAN 介面也有相對應的接線 - 只要將它們配對即可。重要注意事項:CAN 匯流排末端需要 120 歐姆的終端電阻,以防止訊號反射。有些閘道器內部整合了端接電阻,可透過軟體設定。.
第二步是設定波特率. .CAN 匯流排通訊速度必須匹配,否則您將無法接收任何資料。商用車動力總成 CAN 通訊速度通常為 250 kbps 或 500 kbps - 您需要先驗證。查看車輛維修手冊或使用專業 CAN 分析儀進行測試。.
將網關的 CAN 介面設定為相同的鮑率。SV910 等閘道器支援多種鮑率,可透過組態檔案或管理介面調整。.
第三步是監控和解析 CAN 訊息. .CAN 匯流排以訊框的方式傳輸資料。每個訊框包含幾個部分:訊息 ID、資料長度、資料內容、校驗和。.
訊息 ID 是識別每個訊息內容的關鍵。對於引擎轉速,GB/T 27930 和 SAE J1939 等標準定義了 ID。J1939 常用於商用車輛 - 引擎轉速使用 ID 0x0CF00400,資料位於第 4 和第 5 位元組。.
閘道器持續監控 CAN 匯流排,擷取具有特定 ID 的訊框,然後從資料位元組中抽取 RPM 值。提取的值是原始資料,需要使用公式轉換為實際 RPM。在 J1939 標準中,引擎轉速解析度為 0.125 rpm/bit,因此原始值乘以 0.125 即為真正的轉速。.
第四步是打包和上傳資料. .解析 RPM 值後,閘道會將其包裝成適當的格式,以便透過 5G 網路上傳至雲端。常見格式包括 JSON、Protobuf 和 MQTT 訊息。.
上傳頻率視需求而定。即時監控可能需要每秒更新一次,而一般車隊管理則可能需要每 10 或 30 秒更新一次。更高的頻率意味著更高的資料成本。.

理論上聽起來很簡單。現實是,適應不同的車輛型號最令人頭痛。.
國家標準 GB/T 32960 定義了新能源汽車的資料格式,但僅涵蓋電動汽車。傳統燃油動力商用車大多遵循 SAE J1939 標準,但具體實施仍有差異。.
更棘手的是,許多汽車製造商使用標準定義以外的專屬 CAN 訊息。有些品牌將故障代碼和維修提醒放在私人訊息中,但格式卻沒有說明。讀取這些資料需要逆向工程或從汽車製造商取得技術文件。.
在專案期間,我們會針對每種車輛型號進行個別調整。首先收集該型號的 CAN 通訊協定文件。如果沒有文件,則使用 CAN 分析儀記錄總線資料,並手動分析訊息格式。然後在閘道器中設定相應的解析規則。.
SV910 等閘道器支援彈性配置。您可以定義自訂的解析規則,指定訊息 ID 中的哪些位元組代表哪些資料,以及要應用哪些轉換公式。不同的車輛型號只需要不同的組態檔案,不需要修改程式碼。.
我們建立了一個車輛型號資料庫,儲存不同品牌和型號的 CAN 通訊協定配置。新專案會先檢查配置是否已經存在。如果不存在,我們會進行一次調整,然後將其加入資料庫。該資料庫現在擁有四五十種車輛型號的配置。.
使用車輛閘道讀取 CAN 資料需要良好的即時效能。特別是在自動駕駛或 ADAS 情境中,資料延遲會影響安全性。.
CAN 匯流排本身的延遲非常低,以微秒為單位。但是閘道處理、封裝和上傳會增加額外的延遲。如何控制這一點?
首先,盡量減少處理步驟. .接收 CAN 訊框後,立即在中斷處理程式或高優先順序任務中進行解析,而不需要排隊。解析完成後,直接放入傳輸緩衝區,並透過 5G 網路傳送。.
第二,使用硬體加速. .某些先進的車輛閘道器整合了具有硬體過濾功能的 CAN 控制器。在硬體層級設定過濾規則,僅接受感興趣的訊息 ID,捨棄其他訊息 ID。這可降低 CPU 負載,並提高處理速度。.
第三,小心管理時間戳記. .每個 CAN 訊框應在閘道接收後立即取得時間戳記。這個時間戳需要微秒級的精確度。上傳到雲端的資料應附有此時間戳記,以便雲端知道資料是何時收集的。.
SV910 支援 PTP/GPTP 時間同步通訊協定,可確保閘道器與其他裝置之間的高精度時鐘同步。對於需要多裝置協調的情境來說非常重要。.
還必須保證資料的準確性。雖然 CAN 匯流排已內建錯誤檢查功能,但偶爾仍會出現損壞的資料。閘道需要二次驗證。對於引擎轉速,正常操作不可能突然從 1000 轉跳到 5000 轉再回來。將這些異常資料標示為可疑資料,而不是直接使用。.
也可處理匯流排無訊息的情況。如果長時間未收到特定訊息,對應的 ECU 可能發生故障或匯流排斷線。閘道器必須偵測到此狀況並回報異常。.
SV910 具有雙 5G 架構,搭配兩個 5G 模組。為何要採用雙 5G?
第一個原因是備援. .長途行駛的商用車輛可能會經過信號較差的地區。使用單 5G,信號丟失意味著沒有數據傳輸。雙 5G 使用不同運營商的 SIM 卡 - 中國電信和中國聯通,或中國移動和中國聯通。當其中一個信號衰減時,切換到另一個信號。.
可以自動切換。閘道會即時監控兩個 5G 連線的訊號強度和延遲,並使用品質較佳的連結。或同時使用兩個連結進行連結聚合,將頻寬加倍。.
第二個原因是流量分佈. .車輛應用通常涉及多個資料串流 - CAN 匯流排資料、攝影機視訊、定位資料、V2X 通訊。這些資料類型具有不同的特性和不同的頻寬/延遲需求。.
透過一條 5G 連線路由關鍵控制資料,透過另一條 5G 連線路由高流量視訊。這可以防止干擾,並確保重要資料的即時傳送。.
第三個原因是安全隔離. .有些車隊管理平台需要將車輛控制通道與資料收集通道實體分離,以確保安全性。雙 5G 可完美滿足這項需求。控制指令使用專用連結,收集的資料則使用另一個連結。即使黑客入侵資料通道,也無法篡改控制指令。.

收集資料後,車輛閘道會上傳至車隊管理平台。平台通常是雲端服務,提供車輛監控、路線回放、統計報告、故障警告及其他功能。.
資料上傳有多種通訊協定選項。. MQTT 最常見. .它是專為 IoT 設計的輕量級訊息佇列通訊協定。閘道器扮演 MQTT 客戶端,連接至雲端 MQTT 伺服器並定期發佈訊息。.
MQTT 支援不同的 QoS(服務品質)等級。QoS 0 是最多一次 - 啟動並遺忘,可能會遺失。QoS 1 至少一次 - 保證傳送,但可能會重複。QoS 2 恰好是一次 - 保證傳送,不會重複。根據資料重要性選擇適當的 QoS。.
HTTP/HTTPS 也被廣泛使用. .閘道會定期將收集到的資料打包,並透過 HTTP POST 請求上傳至雲 API。此方式簡單直接,相容性佳。缺點是 HTTP 開銷超過 MQTT,不太適合高頻小資料傳輸。.
也有一些專門的通訊協定. .例如 JT/T 808 是交通部針對道路運輸車輛衛星定位系統終端所制定的標準通訊協定。許多商用車隊管理平台都使用此標準。支援 JT/T 808 需要實作完整的通訊協定堆疊。.
資料格式需要與平台達成協議。JSON 很常見 - 人類可讀且容易除錯。但 JSON 會佔用空間,所以如果對資料成本很敏感,請使用二進位格式,例如 Protobuf 或自訂的精簡格式。.
除了讀取即時資料外,車輛閘道還能執行診斷。.
車輛 ECU 會產生診斷故障代碼 (DTC)。當引擎發生故障時,會產生 P0001、P0002 等代碼。這些代碼會儲存在 ECU 中,並可透過 CAN 匯流排讀取。.
標準診斷通訊協定為 ISO 14229 (UDS - 統一診斷服務) 和 SAE J1939-73。閘道作為診斷用戶端,向 ECU 發送診斷請求,ECU 回傳故障代碼和相關資訊。.
讀取故障代碼後,將其轉換成可讀的描述。P0001 表示什麼意思?燃油量調節器控制電路/開路。此轉譯需要故障碼資料庫。閘道器可在內部儲存常見代碼的描述,或上傳至雲端進行翻譯。.
透過故障代碼,車隊管理平台可以提供早期警告。例如,偵測到冷卻液溫度過高的代碼時,會立即通知駕駛員和維修部門,防止引擎過熱造成損害。.
先進的應用程式可執行預測性維護。分析各種車輛參數的趨勢以預測潛在故障。例如,逐漸下降的引擎機油壓力尚未觸發故障碼,但卻顯示出警告跡象 - 提示駕駛員檢查機油。.
經過無數的專案後,我們遇到了許多挫折。.
第一課:妥善保護 CAN 匯流排. .車輛 CAN 匯流排非常重要。如果閘道故障將總線拉低或傳送錯誤的訊息,可能會影響車輛的正常運作。.
閘道 CAN 介面需要電氣隔離,以防止故障傳播。匯流排保護電路應在過電壓或過電流時自動斷開。軟體也需要保護機制 - 在偵測到異常時停止傳輸,以避免匯流排干擾。.
第二課:車輛改裝必須符合法規. .在商用車輛上安裝車輛閘道構成車輛改裝。必須符合國家和地方的法規要求,同時不影響車輛的安全性能。某些地區要求在改裝後向車輛管理機關登記。.
第三課:資料安全與隱私權保護非常重要. .車輛行駛路線和行為涉及隱私。加密資料傳輸、匿名儲存。雲端平台存取需要權限控制 - 不能隨便洩露給第三方。.
總體而言,透過 CAN 匯流排與車用閘道讀取車輛資料,形成了連網車輛應用的基礎。這項技術本身並不複雜,但要做好它需要注意許多細節。適應不同的車輛型號、確保即時效能、資料準確性、通訊可靠性 - 每個層面都需要仔細改進,才能提供穩定可靠的服務。.
Mo