想像你正在倒車入庫。
車外攝影機持續送入影像，停車感測器回報距離，車身系統則確認倒車檔與車速。
中央運算平台接著產生環景畫面，再把結果顯示在中控螢幕上。
這些資料的需求差異很大：
如果把所有資料都塞進同一條 CAN Bus，不只頻寬不夠，也很難同時滿足成本、時序與架構需求。
所以，現代汽車通常會讓多種車載網路各自負責適合的工作，再透過 Gateway 或中央運算平台連接起來。
今天要認識的三種技術是 LIN、FlexRay 與 Automotive Ethernet，並回答一個比「誰最快」更重要的問題：它們為什麼會出現在同一台車裡？
讀完這篇文章，你應該能夠：
選擇車載網路時，不能只看最高速率。
至少要同時回答五個問題：
| 問題 | 要評估的內容 |
|---|---|
| 資料量 | 是一個開關狀態，還是多路攝影機影像？ |
| 時序 | 可以偶爾延遲，還是必須在可分析的時間內送達？ |
| 成本 | 每個節點能承擔多少控制器、收發器與線束成本？ |
| 拓樸 | 節點共用 Bus、按照時槽傳送，還是經由 Switch 連接？ |
| 失效影響 | 丟失或延遲資料後，會影響舒適功能、營運，還是可能造成安全損害？ |
這些條件不會因為某一種網路「比較新」就自動消失。
例如，車窗按鍵不需要 Gigabit Ethernet 才能工作。
攝影機也不可能靠 20 kbit/s 的 LIN 傳送即時影像。
圖 1：同一台車可同時包含 LIN 子網路、CAN Bus、FlexRay 與交換式 Automotive Ethernet。實際配置依車款而異
這張圖不是特定車款的線路圖，而是一張概念地圖。
它要表達的是：每個網路先解決局部需求，Gateway 再管理跨網路資料流。
LIN 是 Local Interconnect Network 的縮寫，可以翻成區域互連網路。
它的定位不是取代 CAN，而是以較低成本連接局部的機電節點，例如：
這些是常見使用情境，不代表每一款車都採用相同配置。
LIN 採用一個 Commander 搭配多個 Responder 的架構。
較早的文件常使用 Master／Slave，2025 年版 ISO 17987 則使用 Commander／Responder。
兩組名詞描述的是相同角色關係，閱讀舊資料時不要誤以為它們是不同版本的拓樸。
Commander 依照 **Schedule Table（排程表）**決定 Frame 順序，並送出每一筆 Frame 的 Header。
預先定義的 Publisher 再送出 Response，其他 Subscriber 可以接收這筆資料。
Publisher 可能是 Commander 或某個 Responder，取決於該 Frame 的設定。
一筆正常 LIN Frame 可以先簡化成：
Commander：Break + Sync + Protected Identifier
↓
預定的 Publisher：Data + Checksum
重要的是，Responder 不會像 CAN 節點那樣看到 Bus 空閒就自行開始一筆普通 Frame。
每次傳輸都由 Commander 的 Header 啟動，所以系統設計者可以預先計算排程中的傳送順序與週期。
LIN 的 12 V／24 V 實體層使用單線並以 Ground 為參考，最高 bit rate 為 20 kbit/s。
它也可以利用常見的 UART／SCI 類介面，讓 Responder 的硬體需求保持簡單。
這讓 LIN 很適合資料量不大、成本敏感的局部功能，但也代表它不適合大量感測資料或影像串流。
可以把 LIN 理解成：
用清楚的排程與較低成本，交換局部控制所需的小量資料。
Schedule Table 可以讓傳送時間更可預測，Checksum 也能協助發現部分傳輸錯誤。
但基礎 LIN Frame 不會因為「按照排程出現」，就具有密碼學上的來源驗證。
如果未受信任的節點已經取得 LIN 子網路的傳送能力，仍要分析它能否：
因此低速、局部與低成本都不是「自然安全」的同義詞。
FlexRay 是為車載控制需求設計的通訊系統，最高支援每個通道 10 Mbit/s。
它重視可預測的傳送時間、時鐘同步與可調整的故障容錯能力。
典型使用情境可能包括底盤、動力與線控功能等時間敏感控制，但實際採用範圍會依車款與世代而異。
看到新車或安全關鍵功能時，不應直接假設它一定使用 FlexRay。
FlexRay 的通訊按照重複的 **Communication Cycle（通訊週期）**運作。
每個週期包含四個主要區段：
| 區段 | 作用 |
|---|---|
| Static Segment | 使用預先分配的固定時槽，提供可預測的同步傳輸 |
| Dynamic Segment | 使用 minislot 機制處理較具彈性的非同步傳輸 |
| Symbol Window | 傳送特定網路管理符號 |
| Network Idle Time | 保留給週期與時鐘校正的無 Frame 區段 |
Static Segment 可把重要 Frame 放進已知時槽。
只要排程、Frame 大小與同步條件都正確，設計者就能分析它何時有傳送機會，而不是每次都和其他 ID 重新做 CAN 式仲裁。
Dynamic Segment 則提供彈性，但它也不是任意搶占 Bus。
節點會依 minislot 與優先順序決定是否啟動傳送。
FlexRay 可以使用單通道，也可以使用 Channel A 與 Channel B 兩個通道。
雙通道常見兩種設計方式：
所以「FlexRay 有兩條通道」不代表所有系統都自動獲得雙倍頻寬，也不代表任何單一故障都能被容忍。
必須查看實際通道配置、拓樸與失效處理策略。
FlexRay 可以採用 Bus、Star 或混合拓樸。
與 CAN 相比，它的時序與同步機制更複雜，硬體、線束與系統整合成本也要一起考量。
FlexRay 的固定時槽能提供時間上的確定性，雙通道也能支援故障容錯設計。
但這些能力主要處理通訊時序與故障，不能直接證明傳送者身分或資料授權。
資安分析仍要問：
一筆 Frame 準時抵達，只能證明它符合當下的時序觀察，不能證明內容真實。
Automotive Ethernet 不是一條單一速率的協定，而是一組針對車載環境設計的 Ethernet 技術與上層協定生態系。
常見的實體層名稱包括：
| PHY | 名目速率 | 連接概念 |
|---|---|---|
| 10BASE-T1S | 10 Mbit/s | 支援短距離 point-to-point 或 shared-medium 模式 |
| 100BASE-T1 | 100 Mbit/s | 單一平衡雙絞線、point-to-point full-duplex |
| 1000BASE-T1 | 1 Gbit/s | 單一平衡線對、雙向同時傳輸 |
| 2.5／5／10GBASE-T1 | 2.5／5／10 Gbit/s | 車用單一平衡線對 Multi-Gigabit Ethernet |
這張表的重點不是背下所有型號，而是不要把 Automotive Ethernet 簡化成「100 Mbit/s 的車用網路」。
實際速率、線材、距離與拓樸要看採用的 PHY 規格。
兩者都沿用 IEEE 802.3 Ethernet 的 Frame 與 MAC 概念，也能搭配 Switch、VLAN 與 IP 協定。
差異主要出現在車載環境的要求：
以常見的 100BASE-T1 與 1000BASE-T1 為例，兩個節點會透過單一平衡線對建立 point-to-point link，再由 Ethernet Switch 把多條 link 連成網路。
10BASE-T1S 的 shared-medium 模式則是值得記住的例外。
所以「Automotive Ethernet 一定是星狀 point-to-point」和「它就是 CAN 式共享 Bus」都不夠精確。
Ethernet 位於較低的網路層次，IP、UDP 與 TCP 可以運行在它上面，但不是每一個 Ethernet Frame 都必然承載 IP。
車內常見的上層用途可能包括：
其中 SOME/IP 是 Scalable service-Oriented MiddlewarE over IP，可支援 Remote Procedure Call、事件通知與資料序列化。
DoIP 則會在 Day 09 配合 UDS 再完整介紹。
100 Mbit/s 或 1 Gbit/s 看起來遠高於 CAN，但 Frame 仍可能在 Switch queue 中等待，也可能受到其他流量與網路壅塞影響。
若要承載時間敏感資料，架構還要搭配：
IEEE 802.1DG 提供車內 Ethernet 使用 TSN 的設定檔，但採用 Ethernet 本身，不等於已經完成 TSN 設計。
Ethernet／IP 生態系讓車輛能使用成熟的工具與協定，也會把更多需要保護的元件帶進車內：
MAC Address 或 VLAN tag 主要用於轉送與分區，不能單獨當成可信身分證明。
Ethernet Frame Check Sequence 也和 CAN CRC 類似，主要用於錯誤偵測，不是密碼學上的訊息驗證。
實際防護要依威脅模型分區網路，在 Switch 實作 ingress filtering，並限制服務權限。
需要保護的資料還要搭配安全通訊及監控機制。
把速率放到一旁，LIN、FlexRay 與常見交換式 Automotive Ethernet 的核心差異，可以從「誰能開始傳送」看出來。
圖 2：LIN 由 Commander 的 Header 啟動傳輸，再由預定 Publisher 回應。FlexRay 依重複週期分配機會，交換式 Ethernet 則由 Switch 轉送 Frame
| 網路 | 傳送安排 | 主要特性 |
|---|---|---|
| LIN | Commander 依 Schedule Table 送 Header | 低成本、局部、可預先安排 |
| CAN | 多個節點以 Identifier 做逐 bit 仲裁 | 共享 Bus、事件反應直接、固定優先權 |
| FlexRay | 依 Communication Cycle 的 static／dynamic segment | 可預測時槽、時間同步、可選雙通道 |
| Automotive Ethernet | 常由 Switch 依 MAC／VLAN／QoS 轉送 | 高頻寬、可擴充上層服務、需管理 queue 與流量 |
這張表比較的是典型架構，不是所有版本的完整規格。
例如 10BASE-T1S 可以使用 shared-medium，FlexRay 也可以採用單通道。
| 網路 | 代表性最高速率 | 適合的資料型態 |
|---|---|---|
| LIN | 20 kbit/s | 按鍵、開關、低速感測與小型致動器狀態 |
| Classical High-Speed CAN | 1 Mbit/s | 週期狀態、控制訊息與診斷資料 |
| FlexRay | 每通道 10 Mbit/s | 需要可預測時序的控制資料 |
| Automotive Ethernet | 10 Mbit/s 到 Multi-Gigabit，依 PHY 而定 | 影像、感測資料、骨幹、診斷與軟體服務 |
速率高不代表任何情境都比較好。
LIN 的節點成本、FlexRay 的固定時槽、CAN 的仲裁，以及 Ethernet 的交換與服務生態，各自處理的是不同問題。
真正的選擇題通常是：
這筆資料需要多少頻寬、多久內送達、可以承受什麼故障，又願意付出多少系統複雜度？
混合網路一定會遇到跨網路資料流。
假設一個 LIN 車門子網路要把門鎖狀態提供給 Ethernet 上的中央運算平台，概念路徑可能是：
LIN Responder
→ LIN Commander／Body ECU
→ CAN 或 Ethernet Gateway
→ Central Computer
→ IVI 顯示門鎖狀態
Gateway 在這條路徑上可能執行：
但協定轉換不會自動提升資料可信度。
如果 Gateway 只是把未驗證的 LIN signal 包進 Ethernet packet，錯誤資料仍然只是換了一種外包裝。
相反地，從 Ethernet 進入低速控制網路的服務，也不能因為通過 Switch 就取得所有 LIN 或 CAN 功能的操作權。
這就是混合車載網路最重要的資安邊界：跨網路時要重新確認資料能去哪裡、能做什麼，以及失敗後如何限制影響。
回到文章開頭，可以建立一張教學用的混合架構：
| 功能 | 候選網路 | 原因 |
|---|---|---|
| 車門或後視鏡內的小型致動器 | LIN | 資料量小、節點成本敏感，可由局部 ECU 排程 |
| 車速、倒車檔與車身狀態 | CAN | 多個 ECU 需要接收週期性狀態，資料量不大 |
| 特定底盤控制資料 | FlexRay | 若系統需要已規劃的時槽與通道容錯，可納入設計 |
| 多路攝影機與環景影像 | Automotive Ethernet | 需要較高頻寬並連到運算平台與顯示系統 |
這不是任何特定車款的實際實作，也不是唯一答案。
有些車輛可能不用 FlexRay，有些感測器使用專用連線，未來架構也可能讓更多低速節點進入 Ethernet 生態系。
重點是先從需求出發，再選擇網路，而不是看到功能名稱就套用固定答案。
假設你要設計一個概念性的倒車輔助功能，包含：
請先回答：
先停在這裡，不要急著往下滑！
請先畫出資料來源、網路、Gateway 與使用資料的 ECU，再往下對照作者的示範答案。
| 元件或資料 | 作者的安排 |
|---|---|
| 四路攝影機 | 透過 Automotive Ethernet 或其他符合頻寬需求的專用影像連線送往中央運算平台 |
| 倒車檔與車速 | 由既有控制 ECU 經 CAN 提供，再由 Gateway 限定只轉送必要 signal |
| 後視鏡角度 | 由 Body ECU 擔任 LIN Commander，排程後視鏡 Responder 的狀態與控制資料 |
| 中央運算平台 | 整合影像與車輛狀態，產生環景或警示結果 |
| 中控螢幕 | 經 Automotive Ethernet 或內部顯示介面取得處理後的畫面與狀態 |
| Gateway 限制 | 不讓一般顯示服務任意送出車身控制命令，只允許必要方向、頻率與資料範圍 |
在這個安排中，影像走高頻寬路徑，小型致動器留在低成本子網路，CAN 則提供既有車身狀態。
錯誤偵測可以由各協定的 Checksum、CRC 或 Frame Check Sequence 協助完成，但來源身分、操作權限與防重放仍需要額外的安全設計。
這份答案是教學用概念架構，不代表任何特定車款採用相同網路，也不代表相關介面存在弱點。
安全與法律提醒： 網路量測與訊息傳送只應在模擬環境、隔離測試台或明確取得授權的設備上進行。
不要對道路車輛、他人的設備或公共基礎設施進行未授權測試。
知道車內不只有 CAN，而且不同網路會經由 Gateway 連接之後，下一步要找到維修工具進入這些系統的入口。
Day 07 將介紹 OBD-II 與 16-pin DLC，看看診斷工具如何讀取車輛資料，以及「接上診斷接口」和「取得所有 ECU 權限」為什麼不是同一件事。
iThome鐵人賽
看影片追技術