你按下方向燈後，除了車外燈具開始閃爍，儀表板也會顯示箭頭並發出提示音。
這個動作看似簡單，背後可能有多個控制單元一起工作：
方向燈開關
→ 車身控制 ECU 判斷操作
→ 在車載網路送出方向燈狀態
→ 儀表 ECU 更新畫面與提示音
→ 燈具控制節點驅動方向燈
這些 ECU 不需要彼此拉一條專用線，也不一定要知道對方的硬體位址。
它們可以在共享的 CAN Bus 上發布與接收訊息。
今天要回答的核心問題就是：當多個 ECU 共用同一條通訊線路時，它們如何把資料交給需要的節點？
讀完這篇文章，你應該能夠：
CAN 是 Controller Area Network 的縮寫，中文常稱為控制器區域網路。
它是一種讓控制器透過共享匯流排交換訊息的通訊技術，常見於汽車與工業控制系統。
在汽車裡，CAN 可以承載許多類型的資料，例如：
這不代表所有資料都在同一條 CAN Bus 上。
現代車輛通常有多個 CAN 網路或其他車載網路，再由 Gateway 依照規則轉送必要訊息。
所以更精確的說法是：CAN 是車內常見的通訊方式之一，不是整台車唯一的一條線。
假設車速資料同時要提供給儀表、車門控制與駕駛輔助系統。
如果每個訊號都使用獨立線路，功能越多，線束與接頭也會跟著增加。
CAN 採用共享匯流排後，提供車速的節點只要發布一次訊息，其他需要這筆資料的節點就能各自接收。
| 比較項目 | 點對點專線 | CAN Bus |
|---|---|---|
| 連接方式 | 傳送端與接收端之間使用專用線路 | 多個節點連到共享匯流排 |
| 資料傳遞 | 通常送往特定接收端 | 訊息會出現在整個網路區段 |
| 新增接收者 | 可能需要增加線路或介面 | 可讓新節點接收既有訊息 |
| 同時傳送 | 各連線分開處理 | 需要決定誰先使用匯流排 |
| 故障影響 | 主要影響該條連線 | 異常節點可能影響共享網路 |
CAN 的價值不只是減少線路。
它還定義了訊息如何競爭匯流排、接收端如何檢查錯誤，以及節點發生大量錯誤時如何限制自己。
這些機制會在 Day 04、Day 05 與 Day 20 逐步拆開。
一個能連上 CAN Bus 的 ECU，可以先拆成三個部分：
| 元件 | 主要工作 | 可以怎麼理解 |
|---|---|---|
| Application／MCU | 執行車輛功能與應用邏輯 | 決定要送什麼資料，也使用收到的資料 |
| CAN Controller | 建立與解析 CAN Frame，處理仲裁及錯誤檢查 | 管理 CAN 通訊規則 |
| CAN Transceiver | 在數位訊號與 CAN_H／CAN_L 電氣訊號間轉換 | 讓控制器真正連上實體匯流排 |
部分微控制器已經內建 CAN Controller，但通常仍需要外部 CAN Transceiver 才能連接實體線路。
圖 1：CAN Transceiver 位於 CAN Controller 與雙線實體匯流排之間
圖片來源：NXP Semiconductors TJA1051 High-Speed CAN Transceiver
這張圖以 NXP TJA1051 為例。
不同產品的模式、保護功能與接腳配置不一定相同，但 Controller、Transceiver 與實體匯流排之間的關係相近。
以下先以常見的 High-Speed CAN 為例。
它通常使用 CAN_H 與 CAN_L 兩條線組成差動訊號，節點透過短支線連到主幹線，主幹線兩端則各有一個終端電阻。
圖 2：High-Speed CAN 的簡化 Bus Topology，實際線束與終端方式會依車輛設計而異
這張圖有四個觀察重點：
兩個 120 Ω 電阻並聯後，理想等效電阻約為 60 Ω。
這也是測試台除錯時常見的初步檢查，但必須在斷電且確認量測位置後進行。
不要直接在不熟悉的真實車輛上量電阻或接線，車內可能有多條 CAN、Gateway 與不同終端配置，錯誤操作也可能觸發故障碼或損壞元件。
CAN 接收器關心的不是某一條線相對地面的單獨電壓，而是 CAN_H 與 CAN_L 之間的電壓差。
以常見的 5 V High-Speed CAN Transceiver 為例，可以用下面的典型值建立概念：
| 匯流排狀態 | 邏輯 | CAN_H 典型概念 | CAN_L 典型概念 | 差動結果 |
|---|---|---|---|---|
| Recessive | 1 | 約 2.5 V | 約 2.5 V | 電壓差接近 0 V |
| Dominant | 0 | 約 3.5 V | 約 1.5 V | 形成明顯正電壓差 |
這些數值用來幫助理解，不應當成所有收發器與量測條件下的固定電壓。
實際允許範圍要以使用的 Transceiver 資料表與適用標準為準。
當外部雜訊同時影響兩條線時，CAN_H 與 CAN_L 可能一起偏移，但兩者的差值仍有機會保持可辨識。
這就是差動訊號比只看單一線路更能抵抗共模雜訊的原因之一。
Dominant 與 Recessive 還有另一個重要用途：多個節點同時嘗試傳送時，Dominant bit 可以覆蓋 Recessive bit。
CAN 會利用這項特性完成不破壞訊息的逐位元仲裁，詳細過程留到 Day 05。
CAN 是訊息導向的廣播網路。
某個節點送出 Frame 後，同一個網路區段上的其他節點都能看見它，再由各節點決定是否接收與處理。
假設動力 ECU 發布一筆「目前車速」訊息：
動力 ECU 發布車速訊息
│
├── 儀表 ECU：接收，用來顯示車速
├── 車身 ECU：接收，用來判斷自動上鎖
├── ADAS ECU：接收，提供功能判斷
└── 空調 ECU：看見後忽略
空調 ECU 不需要車速時，可以透過硬體 Acceptance Filter 或軟體規則忽略這筆訊息。
不過「忽略」不代表訊息沒有經過它所在的實體匯流排。
這和一般網路中「把封包寄到某個裝置地址」的思考方式很不一樣。
每個 CAN Frame 都有 Identifier，也就是識別碼。
它可以協助節點判斷訊息種類，也會影響訊息競爭匯流排時的優先順序。
初學 CAN 時最容易出現三個誤解：
| 常見誤解 | 正確理解 |
|---|---|
| Identifier 是傳送端 ECU 的地址 | 基礎 CAN Frame 沒有獨立的來源地址欄位 |
| Identifier 是接收端 ECU 的地址 | 訊息會廣播，由各節點自行篩選 |
| 相同 Identifier 在所有車款都代表相同資料 | 訊息定義通常與車廠、車系及網路設計有關 |
以下是一筆虛構的教學訊息：
Identifier：0x180
資料意義：車速
Data：以某種編碼表示 48 km/h
0x180 在這裡只是我們為範例設定的訊息識別碼。
不能看到其他車輛出現相同 ID，就直接判定它也代表車速。
Identifier 有 11-bit Standard Format 與 29-bit Extended Format，Frame 裡還有 DLC、Data、CRC 與 ACK 等欄位。
這些會是 Day 04 的主題。
CAN 是 Multi-master Bus，也就是不只一個節點有機會主動傳送訊息。
因此兩個 ECU 可能幾乎同時發現匯流排空閒，並開始送出資料。
CAN 不會讓兩筆訊息直接碰撞後一起損毀。
傳送端會一邊送出 Identifier，一邊監看匯流排上的實際狀態，優先權較低的訊息發現自己輸掉後便停止傳送。
這裡先記住結果即可：
為什麼數值越小反而優先權越高，要等 Day 05 把 Dominant／Recessive bit 排在一起才會真正看懂。
正確收到 CAN Frame 的節點，會在 ACK Slot 表示它看到了有效訊息。
但 ACK 只能告訴傳送端，至少有其他節點在通訊層正確接收 Frame。
它不代表某個指定 ECU 已經處理資料，也不代表車門已鎖上或煞車功能已執行。
可以把這三件事分開：
Frame 被其他節點正確接收
≠
目標應用程式接受這筆資料
≠
真實世界的功能已成功完成
如果功能需要確認執行結果，系統通常還要設計另一筆狀態訊息或應用層回應。
CAN 原本要解決的是可靠且即時的控制器通訊問題。
它具備錯誤偵測與錯誤限制機制，但基礎協定並沒有替每筆訊息提供密碼學上的來源驗證、加密與授權。
因此要特別分清楚：
| CAN 能協助的事情 | 不能直接證明的事情 |
|---|---|
| 檢查 Frame 是否出現特定傳輸錯誤 | 發送者真的是宣稱的 ECU |
| 讓節點確認有其他節點正確收到 Frame | 指定應用程式已接受或執行資料 |
| 讓接收端依 Identifier 篩選訊息 | 發送端具有執行該功能的權限 |
| 透過仲裁決定訊息優先順序 | 高優先權訊息一定可信 |
Acceptance Filter 主要用來決定節點要處理哪些 Identifier，不應直接當成安全授權機制。
如果未受信任的節點能連上同一個 CAN 區段，其他 ECU 也不能只靠 Identifier 判斷訊息來源。
這就是 Gateway 分區、訊息白名單、入侵偵測與更高層安全機制存在的原因。
Day 18 到 Day 22 會再從攻擊面與防禦角度回來檢視這些問題。
今天我們把 CAN Bus 當成一條共享道路，知道每個節點都能看見上面的訊息。
Day 04 將打開 CAN Frame，先認識 Identifier 與 DLC，再看看 Data Field、CRC 及 ACK 如何共同組成一筆訊息。
iThome鐵人賽
看影片追技術