點擊上方藍字談思實驗室

獲取更多汽車網絡安全資訊

OSI（Open Systems Interconnection，開放式系統互聯參考模型）是國際標準化組織（ISO）制定的一套通信分層標準。它的核心思想是：把完整的數據通信流程拆分成 7 個獨立層級，每層只干自己分內的事，上下層之間僅通過標準接口交互。這樣一來，不同廠商的硬件和軟件只要遵守同一套分層規范，就能實現互聯互通。

OSI 七層模型自上而下依次為：

根據 ISO 11898 系列標準（CAN 2.0A/B、CAN FD），CAN 協議本身僅定義了第 1 層（物理層）和第 2 層（數據鏈路層）。但在實際車載診斷場景中，UDS 診斷不能直接跑在裸 CAN 上，還需要在上層疊加 ISO 15765-2（DoCAN）來封裝分段重組、流控等機制。因此，一套完整的 UDS on CAN 通信棧，自上而下分為如下四層：

數據鏈路層介于硬件和上層應用之間，是 CAN 協議的核心。它又進一步拆分為兩個子層：MAC 子層（Media Access Control，媒介訪問控制） 和 LLC 子層（Logical Link Control，邏輯鏈路控制）。

兩個子層的分工各有側重：

• LLC 子層：作為上層（DoCAN / 應用）與 MAC 之間的橋梁，負責幀類型發起、ID 管理、報文過濾等邏輯控制；

• MAC 子層：直接操作總線比特流，負責幀的物理組裝、總線傳輸、自動重發等底層操作。

數據鏈路層的MAC和LLC子層

在日常車載診斷工作中，99% 的情況下我們看到的數據幀，就是在第 2 層干活兒的。因此，吃透數據鏈路層的仲裁機制、幀格式、錯誤處理等內容，對于打好 CAN 總線基礎非常關鍵。

ISO 11898 定義了 4 種幀類型，外加一個用于幀間分隔的 幀間隔：

其中，數據幀和遙控幀是最常打交道的兩類；錯誤幀和過載幀由 CAN 控制器硬件自動處理，平時我們很少直接感知到它們，但理解其原理對于排查總線故障至關重要。

CAN 2.0 規范由 Bosch 于 1991 年發布，最初規定標識符（ID）為 11 位，也就是所謂的標準幀。后來 ID 資源不夠用了，Bosch 又在 CAN 2.0B 中把 ID 擴展到了 29 位，這就是擴展幀。

日常使用 Vector 等工具時，看到 Standard 就知道是標準幀，看到 Extended 就知道是擴展幀。

標準幀 ID 的范圍

標準幀 ID 范圍是 0x000 ~ 0x7FF。為什么最大值不是 0xFFF？

因為 11 位二進制數的最大值 = 211 ? 1 = 2047，換算為十六進制就是 0x7FF。

為什么診斷報文都是 0x7xx 開頭？

在車載診斷中，物理尋址和功能尋址都以 0x7xx 開頭，而不是 0x1xx、0x2xx、0x3xx。原因很簡單：

CAN 總線的仲裁規則是——ID 越小，優先級越高。 把 0x000 ~ 0x6FF 留給更重要的業務報文（動力系統、底盤安全等），診斷報文統一使用 0x7xx 段，可以確保診斷通信不會搶占高優先級業務報文的帶寬。

數據幀和遙控幀都分別有標準格式和擴展格式兩種，但它們在結構上有一些差異。下面逐一拆解。

5.1 數據幀的標準格式與擴展格式

數據幀由 7 個段組成：

數據幀結構

在深入細節之前，先回顧一下上一篇學過的邏輯電平：

CAN 總線通過"線與"機制實現仲裁：顯性電平會覆蓋隱性電平。

① 幀起始（SOF，Start of Frame）

一幀的開始標志。發送方發出1 位顯性電平 0，打破總線空閑狀態，告訴總線上所有節點："我要開始發數據了！"

SOF 之后緊接著就是 ID 字段（標準幀 11 位，擴展幀 29 位）。

② 仲裁段

仲裁段的結構在標準幀和擴展幀中有所不同：

幾個關鍵位的含義：

仲裁段結構

為什么要區分標準幀和擴展幀？

因為標準幀和擴展幀可能共存于同一總線。節點通過 IDE 位來識別當前幀的 ID 是 11 位還是 29 位，從而正確解析后面的字段。

③ 控制段

控制段包含保留位、IDE 位（僅擴展幀需要再次出現）和 DLC。

控制段結構

④ 數據段（Data Field）

數據段內容長度由 DLC 決定，0 ~ 8 字節。CAN 2.0 標準幀/擴展幀最大有效載荷均為 8 字節（CAN FD 之后擴展到了最多 64 字節，后續文章再聊）。

DLC 與實際數據字節數的對應關系：

DLC與數據字節數的對應關系

?? DLC 的值可以超過 8（CAN FD），但在經典 CAN 中，DLC > 8 視為無效，按 8 字節處理。

數據段在標準幀和擴展幀中結構完全相同：

數據段結構

⑤ CRC 段（Cyclic Redundancy Check）

用于校驗數據傳輸是否出現錯誤。標準幀和擴展幀格式相同。

CRC段結構

CRC 校驗算法是什么？

CAN 協議使用的 CRC 多項式為：x1? + x1? + x1? + x? + x? + x? + x3 + 1（CRC-15）。

發送方按位流計算 CRC 值并填入 CRC 段；接收方用同樣的多項式重新計算，若結果不一致，說明數據在傳輸中受損，觸發CRC 錯誤。

⑥ ACK 段（Acknowledgment，應答段）

用于確認數據是否被至少一個接收方正確接收。標準幀和擴展幀格式相同。

ACK 的工作流程：

1. 發送方在 ACK 槽發送隱性 1；

2. 所有接收到正確 CRC 校驗的節點，會在 ACK 槽回應顯性 0 拉低總線；

3. 發送方在 ACK 槽位置采樣總線電平：

• ? 讀到了 0 → 至少有一個節點正確接收，傳輸成功。

• ? 讀到了 1 → 無應答（ACK Error），觸發錯誤處理機制。

模板ACK段結構

⑦ 幀結束（EOF，End of Frame）

連續發送 7 位隱性 1，標志本幀數據傳輸完畢。有始有終，SOF 用 0 開頭，EOF 用 7 個連續的 1 收尾。

幀結束結構

5.2 遙控幀的標準格式與擴展格式

遙控幀在實際應用中極少使用，它的作用僅僅是：請求擁有相同 ID 的節點發送數據。

遙控幀的結構與數據幀幾乎一致，但沒有數據段，只有 6 個部分：

遙控幀結構

最關鍵的區別在于仲裁段中的 RTR 位：遙控幀的 RTR = 1（隱性），而數據幀的 RTR = 0（顯性）。由于顯性電平會覆蓋隱性電平，如果同一 ID 的數據幀和遙控幀同時發送，數據幀會因仲裁勝出而優先發送。

5.3 數據幀 vs 遙控幀：一張表搞懂

當總線上的任一節點檢測到通信錯誤時，會立刻發送錯誤幀，通知所有節點"本次傳輸出了問題"。

錯誤類型（5 種）

錯誤幀的結構

錯誤幀由兩段組成，中間間隔 8 位隱性分隔：

主動錯誤與被動錯誤是 CAN 控制器的兩種錯誤狀態，由內部的 TEC（發送錯誤計數器）和 REC（接收錯誤計數器）決定。這個會在后續文章中詳細展開。

錯誤幀結構

當接收單元內部緩存已滿、來不及處理后續報文時，會發送過載幀，通知發送方"我還沒準備好，先別發"。

過載幀的結構與錯誤幀類似：

• 過載標志：在總線"線與"機制下，任一節點發出 6 個顯性位即可拉低總線，打斷所有待發送報文，為接收節點爭取緩沖時間。

• 過載標志重疊：多個節點同時發送過載標志時，顯性位疊加，過載標志段的總長度可能超過 6 位，這屬于正常行為。

• 過載界定符：8 位隱性 1，釋放總線，等待總線恢復空閑。

過載幀結構

幀間隔是數據幀和遙控幀之間的分隔單元，位于前一幀的 EOF 之后、下一幀的 SOF 之前。

幀間隔結構

注意：錯誤幀和過載幀不需要幀間隔。它們緊貼在前一幀之后直接發送，結束后接自身的界定符，不需要完整的幀間隔。

本文從 OSI 七層模型出發，梳理了 CAN 協議在整個通信棧中的定位，并逐一拆解了 4 種幀類型的結構與用途：

• 數據幀是主力選手，承載了幾乎所有的業務通信；

• 遙控幀用得極少，但在特定場景下依然存在；

• 錯誤幀和過載幀是 CAN 總線健壯性的保障機制；

• 幀間隔承擔著幀與幀之間的"呼吸"作用。

理解了幀的結構，對后續排查總線故障、分析 Trace 將大有幫助。

來源：喵嶼