你開車接近一座十字路口，右側的大型車剛好擋住視線。
本車的攝影機還看不到橫向來車，但另一台車可以先送出自己的行駛狀態。
路口設備也能提供號誌與道路事件資訊，附近的行人裝置則可能讓系統提早注意到視線死角裡的道路使用者。
這段互動可以先簡化成：
其他車輛 ────────┐
路側設備／號誌 ───┼→ 本車 V2X 應用 → 驗證與情境判斷 → 提醒駕駛
行人或單車裝置 ───┤
網路與交通中心 ───┘
車輛不再只依靠自己「看見」的環境，而是能和其他道路參與者及交通系統交換資訊。
這就是 **V2X（Vehicle-to-Everything，車輛對萬物通訊）**想建立的合作式感知環境。
今天的核心問題是：V2V、V2I、V2P 與 V2N 分別在和誰溝通，它們又如何成為智慧運輸系統的一部分？
讀完這篇文章，你應該能夠：
V2X 是車輛和周圍實體或網路服務交換資料的總稱。
在 3GPP 的 V2X 服務需求中，常把應用關係分成四類：
這四個名稱先回答的是「車輛和誰交換資料」，不是指定唯一的無線技術，也不是四種固定的訊息格式。
圖 1：V2V、V2I、V2P 與 V2N 依通訊對象分類，同一項服務也可能組合多條路徑
使用 Mermaid 繪製
先記住三個邊界：
Day 11 才會比較 DSRC／ITS-G5／C-V2X／5G-V2X，Day 12 再打開 BSM／CAM／DENM 等訊息概念。
今天先把焦點留在系統角色與資料流。
ITS 是 **Intelligent Transport Systems（智慧運輸系統）**的縮寫。
它不是只有車上的一個盒子，而是運用資訊與通訊技術，結合感測及控制來改善交通安全、運輸效率與移動服務的整體系統。
ITS 可以包含：
C-ITS 則是 Cooperative Intelligent Transport Systems（合作式智慧運輸系統）。
其中的「合作」表示車輛、道路設施、道路使用者與交通管理端會交換資訊，再由各自的應用程式協調判斷。
可以把三者的關係整理成：
ITS
→ 智慧運輸的整體系統與服務
C-ITS
→ ITS 中強調不同參與者交換資訊並協同運作的部分
V2X
→ 支援車輛與其他參與者交換資料的通訊關係與服務
因此，V2X 是 C-ITS 的重要能力，但完整服務還需要感測與應用邏輯、人機介面，以及交通管理與維運機制。
只讓兩個裝置成功收到封包，還不等於整套 ITS 服務已經安全、可靠地運作。
V2V 是 Vehicle-to-Vehicle（車輛對車輛）。
它讓附近車輛交換與行駛相關的狀態或事件資訊，例如：
假設前車緊急煞車，後方車輛即使隔著大型車，也可能先收到通訊訊息，再由車內應用程式評估是否產生警示。
這裡的重點是「先取得對方宣告的資訊」，不是直接取得對方感測器的原始畫面，也不是允許另一台車控制本車煞車。
圖 2：V2V 能讓附近車輛在彼此視線受限時交換行駛資訊，接收端仍要判斷訊息是否與自身路徑相關
圖片來源：U.S. Department of Transportation，Public domain Wikimedia Commons
V2V 應用仍要回答：
V2I 是 Vehicle-to-Infrastructure（車輛對基礎設施）。
這裡的 Infrastructure 通常指道路環境中的交通設施，例如：
部分標準也會把服務特定地理區域的應用伺服器納入 V2I 應用關係。
本文先用 RSU 與道路設施建立基礎概念。
分析實際系統時，仍要回到該專案採用的標準與架構定義。
RSU 是放在固定道路位置的 V2X 通訊節點，可以和附近車輛或相容的道路使用者裝置交換訊息。
但 RSU 不一定就是號誌控制器。
一座智慧路口可能是：
號誌控制器
→ 提供號誌狀態
→ RSU 封裝並傳送允許公開的 V2X 資訊
→ 車輛端應用程式判斷是否需要提醒駕駛
反方向也可能成立：RSU 收到車輛或大眾運輸工具的請求，再交由交通控制系統依政策評估。
所以 V2I 是雙向關係，但「可以傳送請求」不等於車輛能直接改變號誌。
真正的控制權仍要由號誌控制器、交通政策、授權規則與安全條件決定。
V2P 是 Vehicle-to-Pedestrian（車輛對行人）。
實際應用也常把單車騎士、輪椅使用者與其他 Vulnerable Road User（VRU，弱勢道路使用者）納入考量。
參與 V2P 的端點可能是：
不過，「行人帶著手機」並不代表車輛一定能精確知道行人在車道上的位置。
V2P 設計還要處理：
因此 V2P 可以補充本車感測器的視野，但不能取代駕駛注意義務、道路設計與攝影機或雷達等車載感測能力。
V2N 是 Vehicle-to-Network（車輛對網路）。
在 3GPP 的分類中，V2N 可讓車輛經由行動網路與 V2X Application Server 等服務端互動。
常見概念情境包括：
V2N 和 V2I 都可能把道路資訊送進車輛，但對端角色不一樣：
| 比較項目 | V2I | V2N |
|---|---|---|
| 主要對端 | RSU、號誌或其他道路基礎設施 | 行動網路與應用伺服器等網路服務 |
| 常見範圍 | 路口、道路施工區或特定路段附近 | 可跨越較大地理區域 |
| 典型路徑 | 車輛與附近路側設備交換資訊 | 車輛經營運商網路到後端服務 |
| 主要限制 | 路側設備涵蓋與現場配置，以及互通性 | 網路涵蓋與端到端延遲，以及後端可用性及資料治理 |
兩條路徑可以互相配合。
例如交通管理中心先透過後端網路把道路施工資訊送到 RSU，再由 RSU 向附近車輛傳送。
車輛也可能直接透過 V2N 向服務端取得較大範圍的資訊。
所以一個應用不一定只能貼上一個 V2X 標籤。
分析時應畫出真正經過的端點與網路，不要只看到「雲端交通資訊」就籠統稱為 V2I。
上面的比較是方便初學者建立資料流的簡化方式。
不同標準對中介基礎設施與區域應用伺服器的分類可能有交疊，專案文件才是最後判斷依據。
| 類型 | 車輛的通訊對象 | 教學情境 | 第一個要問的問題 |
|---|---|---|---|
| V2V | 其他車輛 | 前車傳送緊急煞車或行駛狀態 | 如何確認訊息與相對路徑仍然有效？ |
| V2I | RSU、號誌與道路設備 | 路口提供號誌或道路施工資訊 | RSU 的資料來源與控制權限在哪裡？ |
| V2P | 行人、單車騎士等道路使用者裝置 | 視線死角中的 VRU 提供位置資訊 | 定位誤差與未攜帶裝置者如何處理？ |
| V2N | 行動網路與應用伺服器 | 後端彙整廣域道路事件再提供給車輛 | 網路與後端失效或資料過期時怎麼辦？ |
這張表比較的是通訊關係，不是傳輸技術。
同一種 Radio 技術可能支援多種 V2X 關係，同一項應用也可能同時使用直接通訊與網路型路徑。
只畫車輛和車輛之間的無線箭頭，會漏掉真正決定資料能不能使用的系統元件。
OBU 是 On-Board Unit（車載單元）。
它通常負責 V2X 通訊與訊息處理，可能整合在 TCU、Gateway 或其他車載運算平台，也可能是獨立設備。
圖 3：V2X 車載通訊設備的外觀示例，實際 OBU 的尺寸、介面與整合方式會因產品及車輛架構而異
圖片來源：Spielvogel，CC BY-SA 4.0 Wikimedia Commons
OBU 需要從車內取得允許提供給 V2X 應用的資料，也要把收到的外部資訊交給 HMI 或其他車內功能。
這裡會形成兩個信任邊界：
車內 ECU／感測資料 → OBU → 外部 V2X 環境
外部 V2X 訊息 → OBU → 車內應用／HMI
外部訊息不應因為進入 OBU，就自動取得車內控制網路的權限。
RSU 是 Roadside Unit（路側單元）。
它可以從號誌控制器、道路感測器或交通管理端取得資料，再向附近 V2X 裝置提供服務，也可以把收到的資料送回管理端。
RSU 的固定位置有助於提供路口與路段資訊，但固定安裝不等於資料天然可信。
還要確認它的實體防護、憑證及軟體更新機制。
時間與定位來源是否可靠，以及它和號誌控制器之間的介面也很重要。
Traffic Management Center（TMC，交通管理中心）可以監控道路與設備狀態，並和路側設備交換交通管理資訊。
應用伺服器則可能彙整車輛、RSU 與其他資料來源，產生區域性的交通服務。
這些後端角色能看見更大範圍，卻也會形成規模效應：錯誤設定、過期資料或遭入侵的共用服務，可能同時影響許多裝置。
HMI 是 Human-Machine Interface（人機介面）。
收到 V2X 訊息後，車輛還要判斷：
V2X 只提供資訊來源之一，最後的系統行為仍要由車內應用與安全架構決定。
理解 V2X 時，可以先把資料路徑分成兩個概念。
車輛／道路使用者裝置
↔ 附近車輛或 RSU
直接通訊適合把附近且時間敏感的資訊送給周圍節點，路徑不必先繞到遠端應用伺服器。
但它仍會受到通訊範圍與遮蔽、頻道干擾與負載，以及裝置滲透率影響。
車輛
↔ 行動網路
↔ V2X Application Server／交通管理端
網路型通訊適合彙整較大區域的資訊與後端服務，但端到端路徑更長，也多了營運商網路、伺服器與資料治理等依賴。
這兩種概念不是「一個新、一個舊」，也不是只能二選一。
真正的系統可能同時使用兩者，讓附近警示走直接路徑，廣域資訊與管理服務則經由網路提供。
Day 11 會再把這兩條概念路徑放進 DSRC／ITS-G5 與 C-V2X 的技術架構中。
車載感測器觀察的是本車周圍的真實環境，V2X 收到的則是其他參與者對環境或自身狀態的數位描述。
| 資訊來源 | 優勢 | 主要限制 |
|---|---|---|
| 攝影機／雷達等本車感測器 | 可由本車直接觀察周圍物體與道路 | 可能受到視線、遮蔽、天候與感測範圍影響 |
| 直接 V2X | 可提早取得視線外或其他節點主動提供的資訊 | 需要相容裝置、互通性與可信訊息處理 |
| V2N／後端服務 | 可以彙整較大區域與較長時間範圍的資料 | 依賴網路、後端、資料時效與治理品質 |
V2X 最有價值的地方之一，是把本車感知範圍延伸到轉角、遮蔽物後方或較遠的道路事件。
但通訊資訊不應被當成不會出錯的「遠端感測器」。
合理的系統仍要做 Sensor Fusion（感測融合）或至少進行情境交叉檢查，並在資訊彼此衝突時採取可預期的處理方式。
假設本車收到「前方道路有危險」的訊息，處理流程不應直接從接收封包跳到車輛動作。
圖 4：接收端需要先驗證訊息，再檢查內容與目前情境是否合理，最後才由應用程式決定如何呈現或處理
使用 Mermaid 繪製
這條鏈上至少有四種不同問題：
| 檢查 | 要回答的問題 | 仍不能證明什麼 |
|---|---|---|
| Authenticity | 訊息是否來自獲准參與系統的裝置？ | 裝置觀察到的內容一定正確 |
| Integrity | 訊息在傳輸途中是否遭竄改？ | 來源端沒有產生錯誤資料 |
| Freshness | 時間戳記與訊息序列是否仍然有效？ | 位置與事件在現場一定合理 |
| Plausibility | 位置、速度與事件是否符合道路情境及其他觀察？ | 系統在所有極端情況都不會誤判 |
這裡最重要的觀念是：
通過密碼學驗證，可以提高對來源與訊息完整性的信心，但不等於內容必然符合真實世界。
一個合法但故障的感測器可能回報錯誤狀態，遭入侵且仍持有有效憑證的裝置也可能產生格式正確的假訊息。
因此 V2X 資安不能只停在「訊息有沒有簽章」，還要配合新鮮度、位置與移動合理性、資料來源多樣性及異常行為偵測。
沿用 Day 01 的資產與信任邊界觀念，可以先盤點：
對應的保護目標包括：
| 保護目標 | V2X 情境中的問題 |
|---|---|
| 機密性 | 個人與車輛的行駛軌跡是否被不必要地蒐集或關聯？ |
| 完整性 | 位置、速度、號誌與道路事件是否遭竄改？ |
| 可用性 | 頻道、RSU、網路或後端失效時，重要服務如何退化？ |
| 真實性 | 接收端如何確認訊息來自獲准的 V2X 裝置？ |
| 新鮮度 | 過期或被重送的訊息能否被辨識？ |
| 授權 | 車輛、RSU 與後端各自可以發布或操作哪些資料？ |
Safety 仍然是可能的損害面向，不是和 CIA 並列的另一項資安屬性。
例如假位置訊息破壞的是資料完整性與真實性，若接收端因此做出不適當警示，最後才可能影響行車安全、交通效率或使用者信任。
回到文章開頭的大型車遮蔽情境，可以建立一張教學用資料流：
| 資訊來源 | V2X 關係 | 本車可能取得的資訊 | 仍要檢查的限制 |
|---|---|---|---|
| 橫向來車 | V2V | 位置、方向與移動狀態 | 時間、相對路徑與內容合理性 |
| 路口 RSU | V2I | 號誌或路口道路事件資訊 | RSU 資料來源、時效與路口對應關係 |
| 行人／單車裝置 | V2P | VRU 的位置或移動狀態 | 定位誤差、裝置攜帶狀態與隱私 |
| 交通管理服務 | V2N | 較廣區域的壅塞與施工資訊 | 後端來源、網路延遲與資料更新時間 |
本車 V2X 應用收到資料後，可以依序：
驗證訊息來源與完整性
→ 檢查時間與位置是否仍有效
→ 對照本車路徑、感測器與其他訊息
→ 評估是否存在衝突風險
→ 決定是否在 HMI 顯示警示
這個案例只說明資料如何協助本車增加情境感知，不代表任何特定車款已實作相同功能，也不代表 V2X 訊息可以直接控制車輛。
Day 30 的主線情境是一座智慧十字路口：一台惡意車輛送出錯誤位置或交通事件資訊，使其他車輛做出錯誤判斷。
今天先不要急著把「V2X 無線介面」直接叫作漏洞。
可以先拆成：
| 分析項目 | 智慧十字路口案例 |
|---|---|
| 攻擊面 | 車輛、RSU、VRU 裝置與後端服務接收 V2X 資料的介面 |
| 資產 | 位置與事件資料、裝置身分、警示邏輯及交通管理資訊 |
| 假設弱點 | 例如缺少新鮮度檢查，或只驗證憑證卻不檢查位置合理性 |
| 假設攻擊路徑 | 惡意節點取得傳送能力 → 送出可被接受的假資訊 → 接收端產生錯誤判斷 |
| 可能損害 | 交通效率下降、駕駛誤判，嚴重時可能造成安全影響 |
這只是一條待驗證的威脅假設。
Day 21 會正式分析位置欺騙、假訊息與 Sybil Attack，Day 24 到 Day 29 再用 ISO/SAE 21434 與 TARA 評估風險及處理方式。
今天我們先按照通訊對象，分清楚 V2V、V2I、V2P 與 V2N，也看見直接通訊和網路型通訊可以共同支援一項服務。
Day 11 將把通訊技術放上桌，比較 DSRC／ITS-G5／C-V2X／5G-V2X，並釐清 IEEE 802.11p、PC5 與 Uu 各自位於哪一條路徑。
iThome鐵人賽
看影片追技術
