VEOS-Linux · Ethernet BSC：
vECU / FMU 與 Embedded Linux 聯合模擬

在虛擬驗證平台上，把 Classic V-ECU、plant model（FMU） 與 Embedded Linux Guest 放進同一場模擬並不困難；真正困難的是讓三者之間的資料交換全程留在同一條模擬時間軸上。dSPACE VEOS 的 QEMU Coupling 只提供虛擬 Ethernet 一條官方資料通路，而 Classic V-ECU 與 FMU 通常沒有 Ethernet 通訊控制器 —— 兩者之間因此需要一個「翻譯者」。

Ethernet BSC（Bus Simulation Container） 就是原廠指名的翻譯者：它一端持有 Ethernet 控制器、可掛上 VEOS 的虛擬 Ethernet Cluster，另一端以純訊號 port 直接連到 vECU 與 FMU 的輸入輸出，而且中間的 byte 版面由 AUTOSAR 通訊矩陣明確描述。本文以 VEOS 2026-A 與 dSPACE Ethernet Configuration Package（ETHCP）26.3 為基礎，完整說明這條路線的環境準備、授權需求、框架設計理由，以及從通訊矩陣到可執行 OSA 的逐步建置流程。

1. 為什麼需要 BSC：先釐清問題

導入前必須先接受三個既成事實，它們共同決定了整個框架的形狀。

1.1 中介元件的兩種選擇

實務上有兩條可行路線，兩者都能讓 Guest 的資料進到 ECU 內部，差別在於那一段資料通路是否留在模擬時鐘內，以及資料版面由誰定義。

2. 模擬框架設計

下圖是本文要建置出來的目標框架。四個 VPU 位於同一個 OSA（Offline Simulation Application）內，由 VEOS 統一推進模擬時間。

2.1 每個元件為什麼必須存在

• 
  虛擬 Ethernet Cluster —— 因為這是唯一的官方通路： Guest 的網路卡必須掛在 VEOS 的 Ethernet Cluster 上，資料才會在模擬時間軸內傳遞。實作上只要 Guest 的 JSON 組態與 BSC 的通訊控制器宣告相同的 Cluster 名稱，VEOS 在匯入時就會自動建立 Cluster、Channel 並完成接線。
• 
  BSC —— 因為需要一個同時懂兩種語言的節點： 它是整個框架中唯一同時具備 Ethernet 通訊控制器與訊號 port 的元件。少了它，Guest 的封包無處可去；多了它，ECU 完全不需要修改就能收到 Guest 的資料。
• 
  通訊矩陣 —— 因為 byte 版面必須是規格，不是約定： Guest 送出的位元組要對應到哪一個訊號、佔幾個 bit、什麼位元組序、以什麼週期發送，全部由 ARXML 描述並由工具產生程式碼。這讓通訊行為可以被審查、被版本控管，也讓後續改版不必翻閱模型內部。
• 
  CAN Cluster —— 因為 ECU 之間的既有通訊要保留： FMU 與 Classic V-ECU 之間原本就以 CAN 交換訊號，這一段不受 BSC 影響，維持原樣即可。BSC 只是額外注入 Guest 來的資料。

2.2 資料通路在時間軸上的位置

下圖對照兩條路線的通路。理解這張圖，才能判斷自己的測試目的究竟需不需要 BSC。

3. 環境需求

BSC 路線橫跨三類主機，缺少任何一類都無法完成整條鏈。以下依角色說明職責與規格要求。

3.1 三類主機的職責分工

3.2 各主機的規格與組態要求

4. 安裝包需求

下表列出 BSC 路線所需的軟體套件、安裝位置與用途。「必要性」欄位以本文的目標框架（BSC + Guest + FMU + vECU）為準；若您的組合較簡單，部分項目可省略。

5. 授權需求

dSPACE 產品以 CodeMeter 管理授權，可採本機 dongle 或網路授權伺服器。BSC 路線牽涉的授權比單純的 Embedded Linux 模擬多，建議在專案啟動前一次盤點完畢。

6. BSC 建置流程總覽

從通訊矩陣到可執行的 OSA 共分十個步驟，橫跨兩台主機。下圖是整條工具鏈與各步驟的產出物。

7. 逐步操作：從通訊矩陣到可執行的模擬

以下每一步都包含操作內容、預期輸出、以及失敗時應返回的步驟。指令中的 <PROJECT> 代表您的專案根目錄，~/dsqemu 代表 VEOS 主機上的工作目錄。

矩陣定義了 Guest 與 BSC 之間交換的每一個位元組。至少需描述：一個 Ethernet Cluster 與 Physical Channel、兩個 ECU 實例（Guest 節點與 BSC 節點）、雙向各一個 PDU 與其 ISignal 對映，以及兩端的 socket 端點（IP 位址與 UDP 埠）。

矩陣可由 SystemDesk 等系統設計工具匯出，也可由腳本產生。建議以腳本產生並納入版本控管：矩陣是規格，改版頻繁，手改 XML 極易產生懸空參照。

自我檢查：ARXML 內保留埠出現次數應為 0；PDU 長度（<LENGTH>）與您規劃的封包版面一致；每個 PDU 都有對應的 socket connection 與遠端端點。

GUI 操作：

1. 啟動 dSPACE Ethernet Configuration Tool，File → New Project，建立專案檔（.ethprj）。
2. File → Import Communication Matrix…，選擇步驟 A 的 ARXML。
3. 檢查訊息視窗：應出現 Finished import of file '….arxml'.，且不應出現任何關於「remote endpoint information is missing」而移除元素的訊息。
4. 在左側 Communication Matrix 樹中展開 Cluster，找到要被模擬的節點（即 BSC 要扮演的那個 ECU；Guest 是真實節點，不要選它），右鍵 → Add to Configuration。
5. 檢查 Configuration Data 面板：該 ECU 下應同時列出 Rx 與 Tx 兩個 PDU。若顯示 Corresponding ECU(s) = No items，代表矩陣在匯入時已被丟棄元素 —— 返回步驟 A。

為什麼要在這裡停下來檢查：ETHCP 的匯入與產碼是兩個階段。匯入時被丟棄的元素不會讓產碼失敗，工具會拿「還活著的東西」繼續產碼並回報成功。唯一可靠的判準是配置樹上看得到正確的 ECU 與 PDU。

1. Configuration → General Properties → Code Generation，設定 Base path 與 BSC file path 至您的產碼輸出目錄。
2. 確認 Tx PDU 的週期發送屬性已啟用（見下方警告）。
3. File → Save Project，然後點選工具列的 Code Generation 圖示（此功能沒有對應的選單項）。

自我檢查：打開 ethcpcom\*.trc（純文字），確認矩陣中規劃的每一條 ISignal 都在裡面。EXITCODE = 0 不是成功判準，.trc 的內容才是。

以正確版本的 MATLAB 開啟（版本錯誤會在步驟 F 才失敗，且訊息不會指向版本），切換到產碼輸出目錄後執行模型產生函式：

判準是 Model generation was successful。回傳碼非 0 未必是錯誤 —— 當 PDU 較小、未達使用 Simulink Bus Object 介面的門檻時，工具會逐條展開訊號而非包成 bus，並以回傳碼反映這件事。模型檔會自動開啟並存放於同一目錄。

理解 ETHCP 留下的接點（這是下一步的基礎）：往下鑽進 ECU 子系統的 PDU 層，會看到兩組對映區塊 ——

操作步驟：

1. File → Save As，另存為與自動產生的模型不同的名稱（例如 veosgw_bsc.slx）。後續合併以這個模型為輸入。
2. 正向（RX → ECU）：鑽進 RX 對映層，在目標訊號的 Gain 輸出接上 Goto 區塊，Tag Visibility 設為 global；回到根層，以 From 接一個 Outport。Outport 的名稱就是 VEOS 中看到的 port 名稱，請採用可辨識的命名。
3. 反向（ECU → TX）：在根層新增 Inport 並接 Goto；鑽進 TX 對映層，刪除佔位用的 Constant，改以 From 接到原本的輸出線。
4. 回音訊號（建議）：若要在 Guest 端量測往返延遲，可在模型內把收到的序號與時間戳直接回拷到反向 PDU 的對應欄位。這樣回音全程在模擬時鐘內完成，量到的是純粹的模擬時間往返。
5. 設定模型組態：System Target File 設為 dSPACE 目標（dsrt.tlc），Solver 設為固定步長，步長與其他 VPU 的基礎步長一致（常用 1 ms）。

預期結果：根層可以看到您新增的所有 Outport 與 Inport，數量與訊號對照表一致，且型別正確。

把步驟 C 的 initial BSC 與步驟 E 的模型合併，產生 VEOS 可接受的最終容器：

為什麼一定要合併：VEOS 在匯入時會檢查 BSC 是否包含由 Simulink 模型產生的程式碼。未經合併的 initial BSC 雖然已宣告 Ethernet 介面，仍會被明確拒絕。這是強制要求，不是建議。

將 final BSC 傳送至 VEOS 主機後執行：

立即驗證 port 是否存在（這是步驟 E 是否生效的唯一客觀證據）：

若 Ports : 0，代表步驟 E 沒有做或沒有生效，返回步驟 E。

接線分兩類，處理方式不同：

驗收接線：重新匯出 OSA 的模型描述，確認連線數與訊號對照表一致，且 ECU 端原本的「訊號未連接」警告已消失。刻意保留不接的觀測用 port 會留下警告，屬預期行為，應在文件中記錄下來以免誤判。

sim start 不會阻塞，需等待模擬時間走完後再查詢狀態：

驗收必須雙重判定 —— 只看其中一項都可能得出錯誤結論：

8. 失敗症狀對照表

BSC 路線的失敗絕大多數不會在發生的當下報錯。下表整理實際遭遇過的症狀與對應根因，可作為除錯時的第一份檢查清單。

9. 導入建議

依測試目的選擇路線，避免為了架構的「純度」而付出不必要的建置成本。

關於本文