想像車身 ECU 正準備送出一筆燈光狀態，儀表 ECU 也在同一個瞬間要更新顯示。

兩個節點都看到 CAN Bus 處於空閒狀態，也都送出 Start of Frame。
如果這是一條一般通訊線路，兩筆訊息可能直接碰撞，接著只能一起重送。

CAN 的處理方式不同：每個傳送端一邊送出 bit，一邊監看 Bus 上真正出現的狀態。
若兩筆訊息使用不同 ID，優先權較低的節點會在 Identifier 的第一個不同 bit 主動退出，讓獲勝的 Frame 繼續傳完。

這個過程稱為 CAN Arbitration，也就是 CAN 的匯流排仲裁。

今天要把兩個 11-bit Identifier 排在一起，真正看懂：為什麼 dominant 0 能覆蓋 recessive 1，又為什麼 ID 數值越小，通常具有越高優先權。

今天的學習目標

讀完這篇文章，你應該能夠：

1. 分辨 dominant bit 與 recessive bit
2. 說明 CAN 如何一邊傳送、一邊監看 Bus
3. 用兩個 11-bit Identifier 判斷仲裁結果
4. 解釋 Non-destructive Bitwise Arbitration 的意義
5. 說明「ID 越小越優先」的適用條件與例外
6. 從即時性與資安角度理解固定優先權的限制

先限定今天討論的範圍

本文的主要例子使用 Classical CAN 的 11-bit Standard Data Frame。
這樣可以先把仲裁機制看清楚，不必同時處理 29-bit Extended ID 的所有欄位。

不過，實際仲裁不只看工具畫面上的 Identifier 數字。
相關 bit 包括 RTR（Remote Transmission Request，遠端傳送請求）、SRR（Substitute Remote Request，替代遠端請求）與 IDE（Identifier Extension，識別碼延伸）。
它們也可能影響 Standard／Extended Frame 或 Data／Remote Frame 之間的結果，後半段會再補上這些條件。

本文提到的 ID 與訊息用途都是教學範例，不代表任何特定車款的真實通訊定義。

Dominant 與 Recessive：Bus 上不是普通的 0 和 1

Day 03 曾經介紹 High-Speed CAN 的兩種匯流排狀態：

Dominant 中文常稱顯性，Recessive 則稱隱性。

這種關係常以 Wired-AND（線與） 描述：

所以 dominant 不是「比較大」，而是它在電氣與邏輯結果上可以覆蓋 recessive。

當 Bus idle 時，線路維持 recessive 狀態。
節點要開始傳送 Frame，會先送出 dominant 的 SOF，再從最高有效位元開始送出 Identifier。

仲裁的關鍵：傳送端同時也是監聽者

CAN 節點傳送 Identifier 時，不是把資料丟出去就不管了。
它會在每個 bit 的取樣點比較兩件事：

我剛才送出的 bit
        對照
Bus 上實際讀到的 bit

仲裁期間可能出現三種情況：

退出的節點不會送出 Error Frame，因為這不是傳輸錯誤。
它會停止傳送並改為接收目前獲勝的 Frame，等 Bus 再次空閒後重新嘗試。

把 0x180 與 0x188 排成 bit sequence

假設兩個節點同時傳送 11-bit Standard Data Frame：

節點 A：ID 0x180 = 0011000｜0｜000
節點 B：ID 0x188 = 0011000｜1｜000
                       ↑
                 第一個不同 bit：ID3

Identifier 會從 Most Significant Bit（MSB，最高有效位元）開始傳送。
兩個節點在 ID10 到 ID4 送出的內容完全相同，因此都繼續傳送。

到了 ID3：

• 節點 A 送出 dominant 0
• 節點 B 送出 recessive 1
• Bus 上的結果是 dominant 0
• 節點 A 送出與讀回相同的 bit，因此繼續傳送
• 節點 B 送出 1 卻讀回 0，因此知道自己輸掉仲裁

圖 1：0x180 與 0x188 從 MSB 開始比較，0x180 在 ID3 送出 dominant 0 並取得 Bus 使用權，使用 Mermaid 繪製

最後，節點 A 繼續送完 0x180 的 Frame。
節點 B 轉為接收者，等這筆 Frame 結束且 Bus 再次可用後，才重新競爭 0x188 的傳送機會。

為什麼數值越小，優先權越高？

答案不是 CAN 額外查了一張優先權表，而是二進位數值與 dominant 0 的關係自然產生了這個結果。

兩個相同長度的正整數從 MSB 開始比較時，第一個不同 bit 為 0 的數值一定比較小。
CAN 仲裁剛好又讓 dominant 0 覆蓋 recessive 1。

因此：

第一個不同 bit 送出 0
  → Bus 上仍是 0
  → 這個 Identifier 留在競爭中
  → 它的二進位數值也比較小

若只比較同一格式的 11-bit Standard Data Frame，可以整理成：

這裡的「最高」與「最低」只描述 CAN 仲裁順位。
實際系統還要依照高層協定與車輛架構分配 Identifier，不代表所有專案都能任意使用 0x000 或 0x7FF。

Non-destructive Bitwise Arbitration 是什麼？

CAN 的仲裁常被稱為 Non-destructive Bitwise Arbitration（非破壞性逐位元仲裁），可以拆成兩部分理解。

Bitwise：逐 bit 比較

節點不是先送完整個 ID 再比較，而是從 MSB 開始，每送一個 bit 就立即監看結果。
一旦送出 recessive 卻讀到 dominant，該節點便退出競爭。

Non-destructive：獲勝的 Frame 不會被碰撞破壞

輸掉的節點送出的 recessive bit 已被 dominant bit 覆蓋，而這個 dominant bit 正是獲勝者原本要傳送的內容。
因此獲勝 Frame 可以直接繼續，不必因為這次競爭而從頭重送。

要注意，「不破壞」不代表所有等待時間都消失：

• 獲勝 Frame 不因仲裁而損毀
• 輸掉的 Frame 仍要等待 Bus 再次可用
• 低優先權 Frame 可能多次輸掉，累積額外延遲

這種設計讓重要訊息能較快取得 Bus，但前提是 Identifier 與整體流量在系統設計階段已妥善規劃。

「ID 越小越優先」其實是一句簡寫

對相同格式的 Data Frame 來說，直接比較 Identifier 通常就能判斷結果。
但完整理解仲裁時，還要知道 Identifier 旁邊的控制 bit 可能繼續分出勝負。

情況一：相同 ID 的 Data Frame 與 Remote Frame

在 Classical CAN 中，RTR 是 Remote Transmission Request 的縮寫：

若兩者使用相同 Identifier 並同時競爭，前面的 ID bit 全部相同，Data Frame 會在 RTR 位置以 dominant 0 勝過 Remote Frame。

情況二：前 11 個 ID bit 相同的 Standard 與 Extended Frame

29-bit Extended Frame 會在前 11 個 Base Identifier 後加入 SRR 與 IDE，再傳送後續 18 個 Identifier bit。

當 Standard 與 Extended Frame 的前 11 個 ID bit 相同時，Standard Frame 會在 SRR／RTR 或 IDE 的格式分歧處取得優先權。
因此不能把一個 11-bit ID 與一個 29-bit ID 當成普通整數，直接比較畫面上的十六進位數字就下結論。

情況三：兩個節點使用相同的仲裁內容

CAN 仲裁的是訊息優先權，不是傳送端身分。
如果兩個節點送出相同 Identifier 與相同 Frame 類型，它們不會在仲裁階段分出勝負。

若後續 Data 或其他受監看的 bit 不同，便可能被判定為 bit error，造成 Error Frame 與重送。
因此設計 CAN 網路時，應避免讓不同傳送者用相同 ID 發送不同內容。

把以上條件整理成一張表：

優先權不等於「插隊到一半」

假設低優先權 Frame 已經贏得仲裁並進入 Data Field，新的高優先權 Frame 不會在中途把它切斷。

高優先權節點必須等目前的 Frame 完成、經過必要的 Intermission，並再次看到 Bus 可用，才能開始下一輪競爭。

所以 CAN 的優先權代表：

多筆 Frame 同時等待 Bus 時，誰在下一次仲裁先取得完整 Frame 的傳送機會。

它不是作業系統裡可以中斷正在執行工作的搶占式排程。
Frame 長度、bit rate、錯誤重送與 Bus load 都會影響實際延遲。

固定優先權帶來即時性，也帶來延遲風險

CAN 的 Identifier 通常在系統設計階段分配，優先權也跟著固定。
這讓設計者可以把時間敏感的訊息放在較高順位，再分析它們的最壞情況延遲。

但「ID 小」不等於「一定準時」。
分析延遲時至少要一起考慮：

• Bus bit rate
• 每筆 Frame 的長度與 bit stuffing
• 週期訊息與事件訊息的發送頻率
• 目前 Bus load
• 更高優先權 Frame 的數量與最壞發送情況
• 錯誤發生後的重送

如果高優先權流量持續佔用 Bus，低優先權 Frame 可能反覆輸掉仲裁，延遲會愈來愈長，嚴重時甚至長時間得不到傳送機會。

因此 Identifier 不能只依功能名稱隨意編號。
它同時是通訊排程的一部分，需要配合時序需求、負載分析與錯誤情境一起設計。

從資安角度看 CAN Arbitration

仲裁可以決定誰先傳送，卻不會驗證誰有資格使用某個 ID。

一筆 Frame 因為 ID 較小而取得優先權，只代表它在仲裁規則中排得更前面，不代表：

• 傳送者是原本被分配這個 ID 的 ECU
• Data 內容真實且未遭偽造
• 傳送者已通過授權
• 這筆高優先權訊息符合目前車輛狀態

如果未受信任的節點已取得同一個 CAN 區段的傳送能力，它也可能送出低數值 ID 與其他節點競爭 Bus。
持續出現的高優先權流量還可能延遲其他訊息，影響可用性。

這裡先建立兩個觀念：

1. Priority 不是 Authenticity：優先權不能證明來源真實性
2. 仲裁也要納入可用性分析：異常高頻或不合理的低 ID 流量值得監控

實際是否能形成攻擊，仍取決於攻擊者能否接觸該網路、取得傳送能力，以及 Gateway、分區與其他防護是否有效。
Day 19 會再談 CAN Injection，Day 20 則會處理 Replay、DoS 與 Bus-Off。

今日實作：排出三筆 Frame 的傳送順序

在一個已授權的 CAN 測試台上，三個節點同時準備傳送 11-bit Standard Data Frame：

假設三筆 Frame 都沒有錯誤，而且輸掉的節點會在 Bus 再次可用時重試，請回答：

1. 第一輪由哪個節點獲勝？
2. 第一筆 Frame 完成後，剩下兩個節點誰先傳送？
3. 0x180 與 0x188 在哪一個 Identifier bit 首次不同？
4. 如果節點 A 改成持續高頻傳送 0x100，可能對其他兩筆訊息造成什麼影響？

先停在這裡，不要急著往下滑！
請先從每個 11-bit ID 的 MSB 向右比較，找到第一個不同 bit，再往下對照答案。

作者示範答案

第一輪的順序如下：

0x120 < 0x180 < 0x188

因此節點 B 的 0x120 優先權最高，先取得 Bus。
節點 A 與節點 C 退出仲裁並接收這筆 Frame。

等 0x120 傳送完成，節點 A 與節點 C 再次競爭：

0x180 = 0011000｜0｜000
0x188 = 0011000｜1｜000
                       ↑ ID3

0x180 在 ID3 送出 dominant 0，所以節點 C 第二個傳送，最後才是節點 A 的 0x188。

這個練習只是在模擬網路中觀察固定優先權，不代表可以把任意低 ID 訊息送進真實車輛。

安全與法律提醒： CAN 傳送測試只應在模擬環境、隔離測試台或明確取得授權的設備上進行。
不要對道路車輛、他人的設備或公共基礎設施進行未授權測試。

今日重點

• Dominant 通常表示邏輯 0，可以覆蓋 recessive 1
• CAN 節點在仲裁期間一邊傳送，一邊監看 Bus 上的實際狀態
• 送出 recessive 卻讀到 dominant 的節點會退出仲裁，改為接收獲勝 Frame
• Identifier 從 MSB 開始比較，所以同一格式下，數值較小的 ID 通常具有較高優先權
• 獲勝 Frame 不會被仲裁破壞，但輸掉的 Frame 仍須等待並重試
• RTR、SRR 與 IDE 也可能影響仲裁結果，不能只比較畫面上的十六進位 ID
• 固定優先權有助於安排即時訊息，也可能讓低優先權流量累積延遲
• 優先權不等於來源驗證，高優先權訊息仍可能是錯誤或未授權資料

明日預告

連續三天看完 CAN Bus、CAN Frame 與 Arbitration 後，下一步要把視野拉到其他車載網路。

Day 06 將介紹 LIN、FlexRay 與 Automotive Ethernet，看看它們的拓樸、頻寬與使用情境有何不同，又為什麼現代汽車通常不會只靠 CAN 完成所有通訊。

參考資料

• ISO：ISO 11898-1:2024 — CAN data link layer and physical coding sublayer
• CAN in Automation：CAN CC
• CAN in Automation：CiA glossary of terms
• Microchip：Core Protocol Mechanisms of Controller Area Network
• NXP：Controller Area Network Standard
• Linux Kernel Documentation：SocketCAN