架構會議上的經典僵局：自駕團隊說要用 DDS，平台團隊說 AUTOSAR 生態就是 SOME/IP。這題吵技術優劣通常吵不出結果，因為兩者的差異不在誰比較強，而在設計哲學與生態。
設計哲學：以服務為中心 vs 以資料為中心
SOME/IP 是「以服務為中心」：先定義服務（Service ID）、方法（Method ID）與事件，客戶端透過服務發現（SOME/IP-SD）找到提供者，然後呼叫方法或訂閱事件——思考方式接近 RPC。它誕生於 AUTOSAR 生態，Classic 與 Adaptive 平台都有原生支援。
DDS 是「以資料為中心」：系統裡流動的是主題（Topic）——名稱＋以 IDL 定義的型別＋QoS。DataWriter 往主題寫、DataReader 從主題讀，彼此不需要知道對方存在，探索由協定自動完成（RTPS）。這是 OMG 的標準，也是 ROS 2 的底層，因此在自駕與機器人生態裡是預設選項。
最實質的差異：QoS 的粒度
| SOME/IP | DDS | |
|---|---|---|
| 定址 | Service ID／Method ID | Topic ＋ QoS |
| 品質控制 | 相對簡單（TCP/UDP 的選擇、事件週期） | OMG 定義 22 項 QoS 政策 |
| 資安 | TLS | DDS Security |
| 生態 | AUTOSAR 原生 | ROS 2、自駕堆疊 |
DDS 的 QoS 政策包含 RELIABILITY（可靠或盡力）、DEADLINE（資料多久要更新一次）、DURABILITY（晚加入者能不能拿到歷史資料）、HISTORY、LIVELINESS 等。這帶來一個 SOME/IP 沒有的特性，也是 DDS 專案最常見的除錯點：
讀寫兩端的 QoS 必須相容，連線才會建立。 資料沒流動不一定是網路問題——很可能是兩端 QoS 對不起來，而這在封包層完全看不出異常。
選型的三個判斷軸
- 生態決定八成：車身、閘道走 AUTOSAR → SOME/IP 順理成章；感知、規劃堆疊要接 ROS 2 → DDS 幾乎是前提
- 需不需要細粒度的傳輸品質：需要對不同資料流各自定義時限、可靠度、歷史深度時，DDS 的 QoS 是真優勢；只是事件通知與方法呼叫，SOME/IP 就夠
- 誰來當橋：實務上大量車款是兩者並存，中間隔著閘道器。這時選型問題就變成閘道問題——轉換的延遲、欄位對應、QoS 語意的損失，都要有人驗
驗證重點（兩者共通）
- 服務發現的時序：開機風暴下，誰先誰後、逾時怎麼處理
- QoS／訂閱關係的驗證：尤其 DDS 的相容性矩陣
- 跨協定閘道：SOME/IP ↔ DDS 轉換後語意是否保留
- 負載下的行為：頻寬灌滿時，DEADLINE 類的保證還成不成立
CANoe 對兩邊都有原生支援（含 DDS 的模擬、分析與測試），意味著兩個世界可以在同一個時間軸上對照——這對閘道除錯特別重要。
下一步
選型不是技術優劣之爭，是生態與需求的選擇——但選完之後的驗證環境，兩邊都要接得住。歐特莫夫（Vector Informatik 合作夥伴）提供 SOME/IP 與 DDS 的模擬、測試與 QoS 分析。