dSPACE VEOS on Linux：
VMware + Ubuntu 模擬環境建置指南

dSPACE VEOS 自 Release 2026-A 起提供原生 Linux 版本，可在 Ubuntu 24.04 LTS 上執行離線模擬應用（OSA），並透過 VEOS QEMU Coupling 模擬 POSIX-based V-ECU（嵌入式 Linux 受測系統）。對多數以 Windows 為主的開發團隊而言，最務實的導入方式是在既有 Windows 工作站上以 VMware Workstation 建立一台 Ubuntu 虛擬機，讓 VEOS 執行於虛擬機內，而 ControlDesk、SystemDesk、MATLAB/Simulink 等工具仍留在 Windows 端。

這個架構本身可行且已被廣泛採用，但其中有兩個環節特別容易在建置階段被忽略：浮動授權的驗證層次，以及 idle-detect 模式所依賴的巢狀虛擬化授權鏈。兩者的共同特徵是「前段檢查全部通過，卻在真正啟動模擬時才失敗」。本文以逐步操作的形式說明完整流程，並在每個關鍵設定處說明其原因，而非僅列出指令。

1. 部署拓撲與三層巢狀執行環境

1.1 先確定拓撲，它決定後續兩項設定

建置前的第一個決策是「ControlDesk 與 VEOS 是否在同一個作業系統內」。這個答案會直接決定是否需要啟用 Simulator 遠端存取，以及虛擬機該用哪種網路模式。

判斷準則只有一條：只要 ControlDesk 不是以 127.0.0.1 連線至 VEOS，VEOS 對它而言就是「遠端 Simulator」，即需啟用遠端存取。dSPACE Real-Time Testing on Linux 手冊在「How to Register a Platform」一節亦明列，於虛擬機上執行 Linux 時建議將網路設為 NAT——該建議正是針對本文的拓撲 B。

1.2 三層巢狀執行環境

若模擬對象包含 POSIX-based V-ECU，實際上會形成三層巢狀結構。理解這張圖，後續 idle-detect 的設定要求就會變得直觀——因為最內層的 guest 需要硬體虛擬化，而它位於一層虛擬機之內。

2. 環境需求：主機、虛擬機與作業系統

2.1 Windows 主機需求

2.2 Guest 作業系統需求

dSPACE 對 Release 2026-A 的 Linux 支援聲明極為明確，僅列出一個作業系統版本：

3. VMware 虛擬機建立與參數設定

3.1 建議規格

3.2 逐步設定

4. Ubuntu 24.04 安裝要點與 kernel 變體

4.1 Server 版或 Desktop 版

原廠對 Desktop、Server、Cloud 三種版本均明文支援。就 VEOS 模擬主機的用途而言，建議選用 Server 版，理由有三：

• 
  自動落在原廠支援的 kernel 組態Server ISO 預設安裝 GA kernel，Desktop ISO 預設安裝 HWE kernel（見 §4.2）。
• 
  釋放主機 CPU 資源icount 模式是純 TCG 單執行緒模擬，主機 CPU 被桌面環境與背景服務佔用時會直接反映在模擬加速比上。
• 
  整條工作流程不需要 GUIVEOS Simulator / Build / Model Console 均為 CLI；ControlDesk 由 Windows 端連入；XIL API 為網路服務；GDB 與 NMI Profiler 亦皆可經由 CLI 操作。

4.2 GA kernel 與 HWE kernel

這是一個不會產生任何症狀的偏離，也正因如此特別容易被忽略。

實務上，HWE kernel 通常可正常執行全部功能。真正的風險出現在需要向 dSPACE 開立技術支援案件時——原廠可能要求先換回 GA kernel 重現問題。因此建議在安裝 dSPACE 產品之前先確認：

若結果出現 linux-generic-hwe-24.04，代表使用的是 HWE。變更 kernel 屬系統層級調整，須一併處理 GRUB 預設開機項，並在變更後確認 kvm_intel 模組仍能正常載入——idle-detect 完全依賴它。

5. 安裝包需求與軟體清單

5.1 產品安裝包

dSPACE Linux 版產品以 tar.gz 形式提供，可自 dSPACE 官方網站的 Products for Linux 頁面下載。每個壓縮包內含 packages.tar（deb 套件集合）與 install-*.sh 安裝腳本；實際安裝邏輯以腳本為準。

5.2 VEOS 的 deb 套件組成

了解套件組成有助於依需求裁剪安裝範圍——尤其是是否需要 idle-detect 與 POSIX V-ECU 支援。

共用元件方面，所有 dSPACE Linux 產品皆共用 dspace-base、dspace-installationmanager 與 CodeMeter。這代表授權伺服器只需設定一次，四項產品一體適用。

5.3 安裝結果的目錄配置

6. VEOS 逐步安裝流程

官方提供安裝腳本與手動 apt 兩種方法，建議採用安裝腳本。以下為完整步驟。

步驟 1 — 安裝 .NET 8

VEOS 為 .NET 應用，須先具備 .NET 8 執行環境。

步驟 2 — 解壓安裝包並設定權限

步驟 3 — 依情境設定環境變數

安裝腳本以環境變數控制安裝範圍與初始設定。在執行腳本前 export，可省去安裝後的補設定作業。

步驟 4 —（非互動模式才需要）預先接受 EULA

步驟 5 — 執行安裝腳本

步驟 6 — 安裝其他選用產品

Bus API、XIL API、RTT 的安裝流程與 VEOS 相同（解壓 → 權限 → 環境變數 → 執行腳本），建議安裝於同一台機器以共用基礎套件與 CodeMeter。

步驟 7 — 啟用 VEOS 環境（選用但建議）

啟用後可在任何目錄直接使用 veos 指令並支援 Tab 補全，提示字元會出現 (dspace-veos) 前綴。

7. 授權準備：CodeMeter 與浮動授權

dSPACE Linux 產品的授權由 CodeMeter（WIBU-SYSTEMS） 管理。浮動網路授權的運作核心是：讓 VEOS 主機透過網路連到授權伺服器的 TCP 22350 埠，並將該伺服器加入 CodeMeter 的 server search list。

7.1 授權需求盤點

7.2 設定授權伺服器（三選一）

7.3 授權驗證四層法

授權問題之所以難以定位，是因為前面幾層全部通過，仍然可能借不到授權。建議依下列層次逐層確認，可快速判斷問題落在哪一段。

7.4 授權席位的佔用與釋放

浮動授權是「借用制」。實務上有三點需要納入日常作業流程：

• 
  被掃描到 ≠ 佔用授權ControlDesk 的「Scan Local Network for Platforms」走的是同子網探測，不需授權；真正借用授權的是載入並執行模擬的那一刻。
• 
  測試結束務必執行 veos sim down否則授權席位會持續被佔用。共用授權池時，關閉後建議於 License Monitoring 頁面確認席位已釋放。
• 
  以 WebAdmin 的 License Monitoring 判斷可用量顯示每個授權的總數 / 使用中 / 剩餘。即使網路連得到，0 free 時仍然借不到授權。

8. 安裝後驗證與最小啟動測試

8.1 服務狀態

未啟動時以 sudo systemctl start <service> 啟動。若採用 dSPACE portmapper，改以 /opt/dspace/common/portmapper/bin/portmapper -d 執行。

8.2 啟用 Simulator 遠端存取

8.3 最小啟動測試

這一步同時驗證兩件事：授權是否真正可用，以及 Windows 端能否探測到此 Simulator。

9. ControlDesk 從 Windows 端連入

Windows 端操作步驟（實際 UI 以所使用的 ControlDesk 版本為準）：

1. 於 Windows 端 CodeMeter 加入相同的授權伺服器。
2. 確認網路可達 Guest：Test-NetConnection <GUEST-IP> -Port 111，應回報 TcpTestSucceeded : True。Guest 的 IP 可於 Guest 內以 hostname -I 取得（NAT 模式下取 VMnet8 網段位址）。
3. ControlDesk → Platform Manager → Register Platforms → Scan Local Network for Platforms，選取該 VEOS 平台並套用。
4. 若掃描不到，回頭確認：Simulator 遠端存取是否已啟用、rpcbind 是否運作、Guest 防火牆是否放行。

10. icount 模式所需的調整與原因

icount 是 VEOS QEMU Coupling 的預設時間同步模式。它以 QEMU 的 TCG（Tiny Code Generator）進行純軟體指令模擬，並依指令計數推進模擬時間：VEOS 每個同步步長內，讓 Guest 執行完該區間應執行的指令數。

10.1 環境層面：幾乎不需要調整

icount 模式不需要 KVM，也不需要巢狀虛擬化。這是它最重要的實務價值——在無法開啟巢狀虛擬化的環境（例如受管制的公司筆電、雲端執行個體、或啟用了 VBS 的 Windows 主機）中，icount 是唯一可用的模式。因此，本文 §3 中與虛擬化相關的設定對 icount 而言均非必要。

10.2 Guest 映像層面：必須完成的調整

雖然 icount 對主機環境要求寬鬆，但對 Guest 映像（bzImage + rootfs）仍有明確要求。這些調整的共同原因是：VEOS 會接管命令列的一部分參數，且模擬時間由 VEOS 控制。

10.3 VEOS 自動接管的參數

撰寫 POSIX-based V-ECU 的 JSON 設定檔時，需要知道哪些參數由 VEOS 控制。重複設定會造成衝突並被拒絕。

11. idle-detect 模式所需的調整與原因

idle-detect 以 KVM 硬體虛擬化執行 Guest，並透過偵測 Guest 進入 idle 狀態來推進模擬時間。其結果是完整的時間同步：Guest 時間與 VEOS 模擬時間一致，多個 Guest 之間處於 lockstep。代價是它對執行環境有一連串硬性要求。

11.1 虛擬化授權鏈：五個環節缺一不可

在 VMware 上執行 idle-detect，本質上是在虛擬機內再執行一層 hypervisor。VT-x 必須從實體 CPU 一路透傳到 Guest 內的 KVM。任一環節斷裂，結果都是 idle-detect 無法啟動——但錯誤訊息會因斷點位置不同而不同，這正是快速定位的關鍵。

11.2 安裝層面的要求

11.3 /dev/kvm 權限：本模式最常見的失敗點

Ubuntu 預設情況下，/dev/kvm 帶有 uaccess 標籤，其存取權是由 systemd-logind 以 ACL 的形式授予「持有本機 seat 上 active session 的使用者」。這代表：在有圖形登入的桌面環境下，一切正常；但一旦離開該情境，權限就會消失。

正確且與 session 無關的做法，是執行 dSPACE 隨附的權限設定腳本：

該腳本會依序呼叫三個子腳本，其作用如下：

上述腳本會變更系統設定（群組成員與 udev 規則），請依貴司的系統變更管理程序執行。

11.4 Guest 映像層面的額外要求

idle-detect 對 Guest 映像的要求比 icount 更嚴格，根本原因只有一個：Guest kernel 被替換成 VEOS Linux kernel。使用者自備 rootfs 內的 /lib/modules 版本與之不符，因此無法載入任何核心模組。

11.5 VEOS 自動接管的參數

idle-detect 下 VEOS 接管的參數比 icount 更多，撰寫 JSON 設定時不應自行指定 -kernel、-cpu、-smp、-enable-kvm 與 -rtc。

12. 兩種模式的對照與選用建議

13. 錯誤訊息判讀對照表

建置階段最耗時的往往不是修正本身，而是定位。下表整理實務上高頻出現的訊息與其對應斷點。

14. 上線前檢查清單

結語

以 VMware 搭配 Ubuntu 24.04 建置 dSPACE VEOS 模擬環境，技術上並不困難，但其中幾個環節具有「設定看似正確、行為卻不正確」的特性——巢狀虛擬化需要完整 power-cycle 才生效、/dev/kvm 的權限可能綁定於登入 session、codemeter.service 運作不等於已取得授權、遠端存取必須在啟動 Simulator 之前啟用。這些環節無法透過單一檢查涵蓋，需要依層次逐一驗證。

建議的導入路徑是：先以 icount 模式打通完整鏈路，此時環境依賴最少、問題最容易定位；待流程穩定後再處理虛擬化授權鏈，切換至 idle-detect 以取得完整的時間同步與除錯能力。由於兩種模式對 Guest 映像的要求高度重疊，這條路徑不會造成重工。