TECH ARTICLE

dSPACE VEOS：
嵌入式 Linux 模擬架構解析

從三層巢狀執行環境、兩種時間同步模式，到 vECU / FMU 與 Embedded Linux Guest 之間的資料交換設計（Gateway SIC 與 Ethernet BSC），完整拆解 VEOS QEMU Coupling 的架構與導入要點。

隨著車輛電子架構往 Zonal / Central Compute 演進，ECU 軟體不再只是 MCU 上的 Classic AUTOSAR，而是同時存在執行完整 POSIX 作業系統的高效能運算節點。當開發團隊希望在沒有實體硬體的階段就驗證這類節點，挑戰在於：Embedded Linux 上的應用程式必須與 plant model、其他虛擬 ECU、以及 restbus 在同一條模擬時間軸上一起執行，而不是各跑各的。

dSPACE VEOS 透過 VEOS QEMU Coupling（配套執行檔為 veos-qemu，dSPACE 自行 fork 的 QEMU）解決這個問題，並將被模擬的對象定義為 POSIX-based V-ECU。本文以 VEOS 2026-A、veos-qemu 26.1（基於 QEMU 9.2.3）為基礎，說明其架構、環境與授權需求、兩種時間同步模式的差異，以及與 vECU / FMU 整合時的資料交換設計。

本文適用對象：正在評估或導入 SIL / 虛擬驗證平台的系統架構師、ECU 軟體整合工程師，以及需要在 CI 環境中執行 Embedded Linux 軟體回歸測試的驗證團隊。

1. VEOS QEMU Coupling 在工具鏈中的定位

VEOS 本身是離線模擬平台，可同時承載多種 Virtual Processing Unit（VPU）。QEMU Coupling 的作用，是讓其中一個 VPU 不再是編譯後的模型程式碼，而是一整套真實的作業系統映像：您自己的 Linux Kernel、rootfs、middleware 與應用程式，全部照原樣執行。

VPU 型態 承載內容 典型來源
Classic V-ECU AUTOSAR Classic 的 BSW + RTE + SWC，以主機碼編譯執行。 SystemDesk / TargetLink
FMU 符合 FMI 標準的 plant model 或 ECU 行為模型。 Simulink / SystemDesk / 第三方
SIC Simulink Implementation Container，由 Simulink 模型產生的容器。 MATLAB / Simulink + MIPS
BSC Bus Simulation Container，依通訊矩陣模擬 restbus 節點。 Bus Manager（CAN/LIN）、ETHCP（Ethernet）
POSIX-based V-ECU
（本文主題）		 完整的 Embedded Linux 映像：Kernel（bzImage）＋ rootfs（ext2/ext4 raw image）＋ 應用程式。 Buildroot / Yocto 等自建 BSP
  • 支援的 Guest 架構： x86 與 arm64。實際安裝目錄提供 veos-qemu-system-x86_64 / i386 / arm / aarch64 四個執行檔。
  • 授權需求： QEMU Coupling 需要 VEOS_AAP module license（VEOS – AUTOSAR Adaptive Platform），詳見第 3 節。
  • 官方認可的資料通路只有一條： dsQEMU Guest 與 VEOS 之間以虛擬 Ethernet 交換資料。CAN / LIN / FlexRay 必須經由 Gateway 元件或 BSC 做協定轉換 —— 這一點決定了第 5、6 節的整體設計。

2. 三層巢狀執行環境

導入初期最容易混淆的，是「Linux 到底跑在哪一層」。VEOS 的 Embedded Linux 模擬牽涉三層巢狀環境，每一層都有各自的 Kernel、各自的資源限制，也各自需要不同的組態。

LAYER 1 · 實體主機 Windows 工作站 — ControlDesk、SystemDesk、MATLAB、VMware Workstation LAYER 2 · VEOS 模擬主機 Ubuntu 24.04 LTS 虛擬機 — VEOS Simulator 安裝於此 VEOS Simulator（veoskernel） FMU · Classic V-ECU · SIC · BSC 與模擬時間軸的主控者 主機資源需求 idle-detect 模式需 /dev/kvm → 必須開啟巢狀虛擬化 LAYER 3 · veos-qemu 行程 QEMU 9.2.3 的 dSPACE fork，受 VEOS 時間軸控制 POSIX-based V-ECU（Guest） Guest Kernel（依模式而不同） icount：您自建的 Kernel（Buildroot / Yocto） idle-detect：dSPACE 提供的 veos-linux Kernel Root Filesystem（兩種模式相同） 單一 raw ext2 / ext4 映像，以 virtio-blk 掛載 內含 middleware 與受測應用程式（SUT） 關鍵限制 網卡必須為 virtio-net-pci；idle-detect 下 Guest 的 /lib/modules 因 Kernel 版本不符而失效，virtio 驅動需 built-in。 虛擬化需穿透兩層

2.1 名稱釐清：「veos-linux」有兩個意思

這是文件閱讀與團隊溝通上最常見的誤解來源，建議在專案初期就統一用詞：

用語 實際指涉 所在層級 提供者
VEOS 模擬主機 安裝 VEOS Simulator 的 Ubuntu 24.04 LTS 主機（實體或虛擬機）。 Layer 2 由使用者自行建置
veos-linux Kernel 一顆 Linux Kernel 二進位檔，內含 VEOS 時脈注入與 Profiling 支援；僅在 idle-detect 模式下作為 Guest Kernel。 Layer 3（Guest） dSPACE 隨 VEOS 安裝

為什麼需要巢狀虛擬化：idle-detect 模式要求 Layer 3 的 veos-qemu 以 hypervisor 方式執行，因此 Layer 2 的 Ubuntu 必須具備可用的 /dev/kvm。若 Layer 2 本身是虛擬機，就必須在 hypervisor 設定中開啟巢狀虛擬化（VMware 的「Virtualize Intel VT-x/EPT」或 vhv.enable = "TRUE"），並完整關機再開機才會生效 —— Guest 內部執行 reboot 無效。

3. 環境與授權準備

Embedded Linux 模擬的導入成本，多半不在 VEOS 本身，而在周邊環境是否到位。以下依角色拆解三類主機的職責，再說明各項授權的用途與適用情境。

3.1 三類主機的職責分工

01

開發／控制端

Windows 工作站。負責建模（SystemDesk、TargetLink、Simulink）、通訊矩陣製作（ETHCP）、以及執行時的量測與標定（ControlDesk）。

02

VEOS 模擬主機

Ubuntu 24.04 LTS。安裝 VEOS Simulator、Bus API、RTT 與 XIL API；所有 veos build / model / sim 指令與 veos-qemu 行程都在這裡執行。

03

BSP 建置主機

Buildroot 或 Yocto 的編譯環境，產出 bzImage 與 rootfs 映像。可與模擬主機共用，但實務上建議分離以縮短建置週期。

3.2 VEOS 模擬主機的環境要點

項目 要求 未滿足時的後果
作業系統 Ubuntu 24.04 LTS，General Availability Kernel；Desktop、Server、Cloud 版本皆在支援清單內。 使用 HWE Kernel 或其他發行版雖多半可執行，但落在原廠支援範圍外，回報問題時可能被要求以支援組態重現。
CPU / 記憶體 建議 8 vCPU 以上、32 GB RAM；icount 模式為單執行緒 TCG，單核效能比核心數更關鍵。 模擬加速比下降，長時間測試的牆鐘時間顯著拉長。
/dev/kvm idle-detect 模式的必要條件。虛擬機部署時需開啟巢狀虛擬化，並以原廠 configure.sh 建立 kvm 群組與 udev 規則。 僅能使用 icount 模式；載入時直接回報無法存取 KVM 模組而中止。
網路可達性 需連得到 CodeMeter License Server（TCP 22350）；若使用 ControlDesk 或 XIL API 遠端存取，對應埠亦須放行。 授權伺服器不可達時，veos build、veos model、veos sim 全數停擺。
Guest 映像規格 單一 raw ext2 / ext4 磁碟映像；網卡 virtio-net-pci、磁碟 virtio-blk；Console 僅保留 ttyS0。 Guest 看不到網卡或無法掛載 rootfs；使用 squashfs / overlay 等型態則無法開機。

3.3 授權項目：用途與適用情境

VEOS 的授權以 CodeMeter 管理，可採本機 dongle 或網路授權伺服器。實務上建議同時保留一份本機授權作為退路——當網路授權伺服器不可達時，整條模擬工具鏈會同時失效。

授權項目 用途 什麼情境下需要
VEOS – Base VEOS Simulator 本體：建置容器、組裝 OSA、載入與執行模擬。 一律需要。任何 veos build / model / sim 操作都會檢查。
VEOS_AAP
AUTOSAR Adaptive Platform		 啟用 QEMU Coupling 擴充，讓 VEOS 能載入 POSIX-based V-ECU。 Embedded Linux 模擬的必要授權。缺少時，含 DsVeosQemu 型態 VPU 的 OSA 會在載入階段失敗。
Model Interface Package for Simulink 將 Simulink 模型建置為 SIC 容器；Gateway 元件若以 Simulink 實作即需此項。 採用 Gateway SIC 路線時需要（第 6 節）。純 FMU / vECU 組合則不需要。
Ethernet Configuration Package
（ETHCP）		 由 AUTOSAR 通訊矩陣（ARXML）產生 Ethernet BSC；Ethernet restbus 只能由它產生。 採用 Ethernet BSC 路線時需要（第 7 節）。需搭配特定版本的 MATLAB 完成最終合併。
SystemDesk / TargetLink 產生 Classic V-ECU（.vecu）與 ECU 行為模型（.fmu）。 需要與既有 AUTOSAR ECU 一起做整合模擬時需要。
ControlDesk 執行時的量測、標定與視覺化，透過 XCP on TCP 連入模擬中的 ECU。 需要人機介面觀測時使用。若僅需自動化驗證，可改用隨附的 ASAM XIL API 以程式讀寫變數。

導入實務提醒：授權 seat 數會直接影響工作流程。當授權僅有單一 seat 時，模擬載入期間會佔用該 seat，導致同時進行的容器建置作業失敗。建議在自動化腳本中，於每次建置前先確保前一輪模擬已完全卸載。

4. 兩種時間同步模式

VEOS QEMU Coupling 的核心價值在於時間同步：讓 Guest 內部的時鐘由 VEOS 的模擬時間驅動，而不是主機的真實時間。它提供兩種同步機制，適用情境完全不同。

4.1 icount 模式：指令計數，不需要 KVM

MODE A · icount CPU 指令模擬（TCG 單執行緒）— 不需要硬體虛擬化支援 VEOS Simulator Plant / Environment FMU　·　Classic V-ECU　·　BSC（Restbus）　·　SIC 模擬時間軸的主控者：以 StepSize 為單位推進 模擬時間 虛擬 Ethernet veos-qemu（Emulator 模式） 您自建的 Guest Kernel Buildroot / Yocto 產出的 bzImage，版本不受限制 rootfs ＋ 應用程式 Guest 內的 /lib/modules 可正常使用 VEOS 自動加入的參數 -icount（指令計數）　·　-accel tcg,thread=single　·　-rtc clock=vm　·　-veos sync-mode=icount,step-size=<StepSize>

運作原理是以指令數截斷時間：VEOS 讓 Guest 執行完落在目前時間步長內的所有 CPU 指令後將其凍結，等模擬時間推進到下一步再解凍。因此 Guest 內部可見的時間解析度上限即為 StepSize，屬於部分同步。由於完全以軟體模擬 CPU，它不需要任何硬體虛擬化支援，也因此可以使用您自己的 Kernel——這是它最大的實務價值。

4.2 idle-detect 模式：閒置偵測，必須具備 KVM

MODE B · idle-detect 硬體虛擬化（KVM）— Guest 以原生速度執行 VEOS Simulator 偵測到 Guest 進入 idle 才推進模擬時間 → 完全時間同步 支援中斷點凍結模擬時間、NMI Profiler 取樣 模擬時間（lockstep） 虛擬 Ethernet veos-qemu（Hypervisor 模式，強制單核） Guest Kernel 由 VEOS 指定 veos-linux Kernel（內含時脈注入介面）取代您的 Kernel rootfs ＋ 應用程式（不變） 但 /lib/modules 版本不符 → virtio 驅動須 built-in VEOS 自動加入且不可自訂的參數 -veos sync-mode=idle-detect　·　-S　·　-enable-kvm　·　-smp 1　·　-kernel <veos-linux>　·　-nodefaults　·　-no-reboot

idle-detect 的原理是偵測 Guest 是否進入閒置：只有當 Guest 沒有工作可做時，VEOS 才推進模擬時間。這使得模擬時間與 Guest 執行進度完全對齊，多個 Guest 之間也能維持 lockstep。代價是 Guest Kernel 必須換成 dSPACE 提供的 veos-linux，因為時脈注入需要 Kernel 端的配合。

4.3 兩種模式的差異對照

比較項目 icount idle-detect
Guest Kernel 您自己的 Kernel，版本不受限制 強制使用 dSPACE 的 veos-linux Kernel
硬體虛擬化需求 不需要 必須具備 /dev/kvm
時間同步精度 部分同步，解析度上限為 StepSize 完全同步，多 Guest 可維持 lockstep
執行效能 純軟體模擬，開機與運算較慢 原生執行，開機時間顯著縮短
CPU 核心數 可設定多核（建議單核以確保重現性） 由 VEOS 強制為單核
Guest 核心模組 可正常載入 版本不符而失效，virtio 驅動須 built-in
GDB 中斷點凍結模擬時間 不支援 支援
NMI Profiler 不支援 支援（可定位 Guest 內的忙迴圈與卡死）
建議使用時機 BSP 帶入初期、需要驗證自有 Kernel 組態、CI 環境不具巢狀虛擬化 需要精確時序、多節點 lockstep、原始碼層級除錯與效能剖析

選型建議：兩種模式使用同一份 rootfs，差別只在 Guest Kernel 與同步機制。因此務實的作法是——以 icount 完成 BSP 帶入與功能驗證，待需要時序精度或除錯能力時再切換到 idle-detect。切換成本主要落在「rootfs 不能依賴 Kernel 模組」與「init 流程不能依賴被替換掉的 Kernel 特性」這兩點，建議在映像設計階段就先滿足。

5. vECU、FMU 與 Embedded Linux 的整合模擬架構

真實的驗證場景很少只有一個 Linux 節點。典型的組合是：Plant / ECU 行為模型（FMU）、Classic AUTOSAR vECU、以及一個或多個 Embedded Linux Guest，三者放進同一個 OSA 一起執行。此時會遇到本架構最關鍵的一項限制。

核心限制：Embedded Linux Guest 對外只有虛擬 Ethernet一條資料通路；而由 SystemDesk / TargetLink 產生的 FMU 與 Classic vECU，通常只具備 CAN 控制器與訊號層 Port，沒有 Ethernet 控制器。兩者因此形成「Ethernet 島」與「CAN／訊號島」，無法直接對話 —— 必須有一個居中的橋接元件。

單一 OSA · 多 VPU 整合模擬 所有元件共用同一條模擬時間軸與同一個 StepSize CAN／訊號島 FMU ECU 行為 / Plant 模型 類比與數位 I/O Port Classic V-ECU AUTOSAR BSW + RTE + SWC CAN 通訊控制器 CAN Cluster（VEOS 虛擬匯流排） 訊號層連線：無需匯流排，直接對接 Port Ethernet 島 Linux Guest A Buildroot 映像 eth0 · virtio-net-pci Linux Guest B Yocto 映像 eth0 · virtio-net-pci Ethernet Cluster（VEOS 虛擬網段） Guest 之間只要宣告相同 Cluster 名稱即自動連線 橋接元件（Bridge VPU） 方案一：Gateway SIC　—　以 Simulink 實作，建置鏈短 方案二：Ethernet BSC　—　由通訊矩陣產生，具 byte 層級語意 訊號層連線 Ethernet 封包 橋接元件的職責：把 Guest 的 Ethernet 封包解析為訊號值，並把 ECU 的訊號值封裝回封包 —— 雙向、每個模擬步長各執行一次

5.1 資料交換的三種連線型態

訊號層連線

直接把兩個 VPU 的 Port 對接，不經任何匯流排。延遲最低、設定最簡單，是 FMU 與 vECU 之間、以及橋接元件與 ECU 之間的首選。但 Linux Guest 無法使用——Guest 內沒有對應的虛擬硬體。

虛擬匯流排

CAN / LIN / FlexRay / Ethernet Cluster。同型態的通訊控制器只要接到同一個 Cluster 即可互通，且全程位於模擬時間軸內。Linux Guest 唯一官方認可的通路就是其中的 Ethernet Cluster。

主機側 Socket

透過 QEMU 的使用者模式網路（slirp）將 Guest 封包導向主機 Socket，再由橋接元件接收。設定極為簡便、不需特權，代價是該段路徑落在模擬時鐘之外。

6. 橋接方案一：Gateway SIC

Gateway SIC 的作法，是以 Simulink 建立一個具備 UDP 收送能力的模型，建置為 SIC 容器後放入同一個 OSA。它一側以主機 Socket 與 Guest 溝通，另一側以訊號層連線接到 FMU 與 vECU 的 Port。

方案一 · Gateway SIC 以 Simulink 實作的橋接器，經主機 Socket 與 Guest 交換 UDP 封包 VEOS 模擬時間軸之內 FMU 類比 / 數位輸入 Port Gateway SIC UDP 收送 ＋ 位元組解析 Classic V-ECU 訊號 Port ＋ CAN 控制器 訊號 訊號 FMU ↔ V-ECU 之間另可經 CAN Cluster 交換 PDU，與本路徑並行不衝突 ▲ 模擬時鐘邊界：以下路徑由主機作業系統排程，不受模擬時間控制 ▼ 主機 UDP Socket QEMU 使用者模式網路（slirp） Embedded Linux Guest 應用程式以標準 BSD Socket 收送 關鍵技巧 slirp 可將主機偽裝成 Guest 期望的對端位址 Guest 端零修改 不需重建映像、不需特權、不需 TAP 裝置

6.1 建置與連線流程

01

建立 Simulink 模型

以 UDP 收發模組與位元組拆解邏輯組成，根層以 Inport / Outport 暴露要與 ECU 交換的訊號，並設定與 VEOS 相同的固定步長。

02

建置為 SIC 容器

透過 Model Interface Package for Simulink 產生 .sic，再以 veos build sic 匯入 OSA，成為一個獨立的 VPU。

03

訊號層接線

將 SIC 的 Port 與 FMU / vECU 的 Port 對接。Guest 側則在 JSON 組態中設定 slirp 網段，使主機在 Guest 眼中即為預期的對端位址。

實務優勢：整條建置鏈只需要一個 Simulink 模型，不必製作 AUTOSAR 通訊矩陣；Guest 端完全不需修改或重建映像；反向回覆的週期可自由調整。適合應用層資料交換、以及控制迴路週期較長的驗證情境。

7. 橋接方案二：Ethernet BSC

Ethernet BSC 是原廠對 Ethernet restbus 的指名作法。它由 AUTOSAR 通訊矩陣（ARXML）出發，經 ETHCP 產生初始容器與對應的 Simulink 模型，補上根層訊號 Port 後合併為最終 BSC，再由 VEOS 載入。最大的差別在於：它直接掛在 VEOS 的虛擬 Ethernet Cluster 上，整條路徑都在模擬時鐘之內。

方案二 · Ethernet BSC 由通訊矩陣產生的 restbus 節點，全程位於模擬時鐘之內 執行時架構 — 無主機 Socket、無 slirp、不需特權 FMU 類比 / 數位 Port Ethernet BSC 依矩陣拆解 PDU / ISignal Classic V-ECU 訊號 Port ＋ CAN 控制器 訊號 訊號 Ethernet Cluster（VEOS 虛擬網段） Embedded Linux Guest（eth0 · virtio-net-pci） 建置流程 ① 通訊矩陣 ARXML（PDU / ISignal） ② ETHCP 產碼 initial BSC ＋ 模型資料 ③ 產生模型 MATLAB 產生 Simulink 模型 ④ 補訊號 Port 根層 Inport / Outport 接線 ⑤ 合併並載入 final BSC → veos build bsc 導入時最容易忽略的三件事 ① 產碼工具可能在丟棄部分矩陣元素的情況下仍回報成功 —— 必須逐項核對產出的訊號清單，不能只看回傳碼。 ② 矩陣中的埠號需避開通訊協定的保留埠；③ 反向目的位址寫死在矩陣內，每個 Guest 位址需各自產生一份 BSC。

7.1 兩種橋接方案的對照

比較項目 Gateway SIC Ethernet BSC
資料通路 QEMU slirp → 主機 Socket → SIC VEOS 虛擬 Ethernet Cluster（全程在模擬時鐘內）
建置鏈長度 短：一個 Simulink 模型即可 長：ARXML → 產碼 → 產生模型 → 接線 → 合併
位元組層級語意 由模型自行拆解，需人工維護版面一致性 由通訊矩陣定義，PDU 版面與位元位置可追溯
多 Guest 擴充 同一份容器可服務多個位址 反向目的位址寫在矩陣內，每個 Guest 位址需各建一份
主機權限需求 不需特權（slirp 為使用者模式網路） 不需特權
原廠架構認可 屬工程實作手法 原廠對 Ethernet restbus 的指名作法
端到端往返延遲 兩者實測相當。在相同映像、相同同步模式下比較，主導往返延遲的並非「傳輸是否位於模擬時鐘內」，而是兩端週期取樣的相位關係——Guest 的送出週期與橋接元件的回覆週期。傳輸層本身的抖動被此效應完全掩蓋。

選型建議：若目的是應用層資料交換（感測值、設定值、狀態回報），Gateway SIC 的投入產出比明顯較佳。若專案要求以通訊矩陣為單一事實來源、需要 byte 層級的 restbus 語意與可追溯性，或必須符合原廠參考架構，則應選擇 Ethernet BSC。

若目標是降低往返延遲，兩者都不是答案——應調整的是兩端的週期設計，而非傳輸層。此外，單純提高橋接元件的回覆頻率可能適得其反：當回覆速率遠高於 Guest 的讀取速率時，會在 Guest 端形成接收積壓，反而拉高延遲尾端。

8. 導入路徑建議

綜合前述架構，建議以下列順序分階段導入，每一階段都有明確且可驗證的產出：

  • 階段一：單一 Guest 於 icount 模式開機 確認映像規格符合要求（virtio、單一 raw 映像、ttyS0 console、靜態 IP）。驗證點是 Guest Console 出現預期的開機訊息與應用程式啟動記錄。
  • 階段二：多 Guest 於虛擬 Ethernet Cluster 互通 僅需在各自的 JSON 組態中宣告相同的 Cluster 名稱，即可驗證官方認可的資料通路確實可用，且不依賴任何主機側設定。
  • 階段三：導入橋接元件，與 FMU / vECU 整合 先以 Gateway SIC 取得端到端可用的資料流，確認訊號值確實進入 ECU 內部（可透過 XIL API 或 ControlDesk 佐證），再依專案需求評估是否升級為 Ethernet BSC。
  • 階段四：切換至 idle-detect，取得時序精度與除錯能力 在主機具備 /dev/kvm 後啟用，可獲得完全時間同步、多節點 lockstep，並解鎖 GDB 中斷點凍結模擬時間與 NMI Profiler 等進階能力。

結語

VEOS 的 Embedded Linux 模擬能力，讓 POSIX-based V-ECU 得以與既有的 AUTOSAR vECU、Plant 模型在同一條模擬時間軸上驗證，是高效能運算節點導入虛擬驗證的關鍵拼圖。導入成敗的關鍵不在單一工具，而在於映像規格、時間同步模式、以及跨島資料交換設計三者的整體規劃。捷策動能具備完整的 dSPACE 工具鏈導入與客製整合經驗，可協助貴公司完成從環境建置、BSP 調校到自動化驗證的落地。

關於本文

本文內容依據 dSPACE VEOS 2026-A 與 veos-qemu 26.1（基於 QEMU 9.2.3）之官方文件，並結合捷策動能實際導入 Buildroot 與 Yocto 映像、整合 FMU 與 Classic V-ECU 的專案經驗整理而成。文中所述之行為與限制可能隨產品版本演進而調整，實際專案請以對應版本之原廠文件為準。

若需要針對貴公司的 ECU 架構與驗證需求進行可行性評估，歡迎與我們聯繫：info@jotactic.com