看 AUTOSAR Classic 的分層圖，中間那條薄薄的 RTE（Runtime Environment） 常被當成裝飾。實際上它是整個架構的成立條件：應用層的軟體元件（SWC）之間不直接往來，一切通訊都經過 RTE。理解為什麼要多這一層，就理解了 AUTOSAR 一半的設計哲學。
RTE 解耦的是三件事
1. 位置。 SWC A 發訊號給 SWC B——B 在同一顆核心？另一顆核心？另一顆 ECU？A 完全不需要知道。A 只對自己的**埠（Port）**寫資料，RTE 負責把資料送到該去的地方：同核心就是記憶體複製，跨 ECU 就交給通訊堆疊上匯流排。部署改變（例如功能從一顆 ECU 搬到另一顆），SWC 的程式碼一行都不用動，改的是系統描述與 RTE 的重新生成。
2. 排程。 SWC 的可執行實體（Runnable）不自己決定何時跑，由 RTE 依組態把它們掛到作業系統的任務上：週期觸發、資料到達觸發、操作呼叫觸發。開發者寫的是「這個 Runnable 做什麼」，「何時、在哪個任務、什麼優先序」是整合階段的組態決定。
3. 資料一致性。 兩個不同優先序的 Runnable 存取同一筆資料，搶佔發生時會不會讀到寫到一半的值？RTE 依組態自動插入保護機制（複本、鎖），開發者不必在應用程式碼裡手寫臨界區——這也是為什麼「繞過 RTE 直接共享全域變數」會把並行問題重新引回來。
通訊的兩種語意
SWC 埠之間的介面主要兩類：
| Sender-Receiver（S/R） | Client-Server（C/S） | |
|---|---|---|
| 語意 | 資料流：我發布、你取用 | 服務呼叫：請求—回應 |
| 典型用途 | 感測值、車速、狀態 | 查詢、設定、計算服務 |
| 呼叫方式 | 非阻塞讀寫 | 同步或非同步呼叫 |
選錯語意是架構審查的常客：把「取最新車速」做成 C/S 呼叫，等於為一筆本來就持續更新的資料多付一次請求—回應的往返；反過來把「觸發自檢」做成 S/R，接收端就要自己輪詢狀態變化。
RTE 是生成出來的，不是寫出來的
RTE 的程式碼由工具依三份輸入自動生成：SWC 描述（埠、介面、Runnable）、系統描述（部署、網路訊號對應）、基礎軟體組態。流程大致是：
- 在 DaVinci Developer 這類工具裡建模 SWC 與介面 → 產出 ARXML
- 系統整合：訊號對應到匯流排（DBC/ARXML）、SWC 部署到 ECU
- DaVinci Configurator 這類工具配置 BSW 與 OS，一致性檢查在這裡把數千個參數之間的衝突攔下來
- 生成 RTE 與 BSW 程式碼，與應用程式碼一起編譯
這條鏈的價值在錯誤前移：介面型別不匹配、訊號沒有對應、任務排程矛盾，都在生成階段報錯，而不是燒進 MCU 之後查三天。
跳過 RTE 的代價清單
急起來直接 extern 一個全域變數，短期能動，代價之後付：
- 資料一致性保護消失，並行 bug 隨機出現
- 部署彈性歸零——功能搬移要改應用程式碼
- 追溯斷裂——介面不在模型裡，影響分析看不到它
- 量測與標定工具依 ARXML 找資料點，繞過模型的資料它們看不到
AUTOSAR 的成本花在建模與組態，換到的是這四件事。要繞過之前，先確認你願意用什麼換。
下一步
從 SWC 建模、BSW 配置到虛擬 ECU 上的早期驗證，歐特莫夫（Vector Informatik 合作夥伴）提供 AUTOSAR CP 與 AP 的導入與開發服務。
- 📄 解決方案：AUTOSAR 車用軟體解決方案：CP 與 AP 全方位開發服務
- 📬 預約一次現況盤點