dSPACE MCP Hub：
AI 代理驅動的工程工作流程完整指南

dSPACE MCP Hub 是 dSPACE 官方推出的 Model Context Protocol（MCP）Server 統一集合，透過開放的 MCP 標準協定，將 GitHub Copilot、Claude、ChatGPT 等 AI 助理直接連接至 dSPACE 工具鏈。它解決了車用軟體開發中「工具鏈碎片化」的痛點——讓 AI 代理能夠橫跨需求（Requirements）、架構（Architectures）、軟體開發（Software Development）、模擬（Simulation）與驗證（Validation）等多個工程階段，自主發起並執行完整的工作流程，同時保持工程師在迴路中（Engineer-in-the-Loop）的審查與核准機制。

1. dSPACE MCP Hub 架構總覽

dSPACE MCP Hub 目前包含四個核心 MCP Server，全部以 Apache License 2.0 開源授權發佈於 GitHub（dspace-group 組織），各自透過 COM 自動化介面或 CLI 控制對應的 dSPACE 工具：

2. 安裝前準備（共同先決條件）

四個 MCP Server 的安裝流程高度一致，開始前請確認以下環境需求：

安裝 uv 套件管理器（PowerShell）：

# 於 PowerShell 中執行官方安裝指令
powershell -ExecutionPolicy ByPass -c "irm https://astral.sh/uv/install.ps1 | iex"

# 驗證安裝
uv --version

3. 通用安裝流程（五步驟）

dSPACE MCP Hub 官方定義的標準安裝流程如下，適用於全部四個 Server：

3.1 MCP 客戶端配置範例（VS Code + GitHub Copilot）

在工作區建立 .vscode/mcp.json，以下為同時註冊四個 dSPACE MCP Server 的完整範例：

{
  "servers": {
    "controlDesk": {
      "type": "stdio",
      "command": "C:/repos/ControlDeskMCP/ControlDeskMCP.exe",
      "args": [],
      "env": { "CONTROLDESK_VERSION": "2026-A" }
    },
    "VeosMCP": {
      "type": "stdio",
      "command": "C:\\repos\\VeosMCP\\VeosMCP.cmd",
      "args": ["--veos-version", "26.1"]
    },
    "configurationdesk-mcp": {
      "type": "stdio",
      "command": "C:\\repos\\ConfigurationDeskBusManagerMCP\\ConfigurationDeskMCP.cmd",
      "args": []
    },
    "SystemDeskMCP": {
      "type": "stdio",
      "command": "C:\\repos\\SystemDeskMCP\\SystemDeskMCP.cmd",
      "args": []
    }
  }
}

4. 各 MCP Server 安裝配置細節

4.1 ControlDesk MCP

• 版本需求：ControlDesk 2025-A 以上（官方建議 2026-A）；開發模式需 64 位元 Python 3.11+。
• 安裝方式 A（建議）— 預編譯執行檔：從 GitHub Releases 下載 ControlDeskMCP.exe 與 ControlDeskMCP.exe.sha256，執行檔已內建 Python 執行環境與所有相依套件，無需另行安裝。
• 安裝方式 B — 原始碼：clone 儲存庫後執行 uv sync（開發用途加 --extra dev）。
• 版本指定：透過環境變數 CONTROLDESK_VERSION（例如 2026-A）指定要操作的 ControlDesk 安裝版本；未設定時自動偵測最新版本。
• 工具清單驗證：執行 ControlDeskMCP.cmd --list-tools 可離線列出全部工具。

下載後建議驗證檔案完整性：

# 計算 SHA256 並與 .sha256 檔案內容比對
(Get-FileHash .\ControlDeskMCP.exe -Algorithm SHA256).Hash

4.2 VEOS MCP

• 版本需求：本機已安裝 dSPACE VEOS；開發模式需 Python 3.12+。
• 安裝方式 A — 預編譯發行版（僅 Windows）：從 GitHub Releases 下載 veos-mcp-windows.zip，解壓縮取得 veos-mcp.exe 後直接註冊至 MCP 客戶端。
• 安裝方式 B — 開發者模式（Windows / Linux）：clone 儲存庫後執行 uv sync（完整開發環境用 uv sync --extra dev）。
• 啟動參數：--veos-version <版本>（如 26.1 或 26-A）指定目標 VEOS 安裝；或以 --veos-bin-path <路徑> 直接指向 VEOS 的 /bin 資料夾。

4.3 ConfigurationDesk & Bus Manager MCP

• 版本需求：64 位元 Windows 10/11；ConfigurationDesk 已安裝、具有效授權並註冊 COM 自動化；Python 與 ConfigurationDesk 的版本相容性請參照儲存庫內的相容性矩陣文件。
• 安裝指令：此儲存庫採 monorepo 結構，需使用完整同步參數。

# 一般使用（不含開發工具）
uv sync --frozen --all-packages --no-dev

# 貢獻者模式（含 Ruff、pytest 等開發工具）
uv sync --frozen --all-packages

4.4 SystemDesk MCP

• 版本需求：本機已安裝且具有效授權的 SystemDesk；Python 3.10+。
• 安裝指令：於儲存庫根目錄執行 uv sync（開發用途加 --extra dev）。
• 啟動順序：所有工具呼叫前必須先執行 start_systemdesk()，否則後續操作會失敗。

5. ControlDesk MCP 能力詳解（14 個功能域、93 個工具）

ControlDesk MCP 透過 COM 自動化完整驅動 ControlDesk 的實驗與量測校調工作流程，並採用獨特的「兩層工具模型」（Two-Tier Tool Model）：主要工具（Main Tools，涵蓋應用程式生命週期、專案／實驗、平台連線）永遠可見；附加工具（Add-On Tools）透過各域的 *_discover 探索工具按需動態載入，以維持 AI 代理精簡的上下文視窗。閒置的附加工具域在 120 秒後自動卸載，但有狀態的工具域（匯流排、量測、記錄器）在活動期間絕不自動卸載。完整目錄亦可透過 MCP Resources controldesk://server/tool-catalog 與 controldesk://server/tool-groups 查詢。以下為全部 14 個功能域、93 個工具的完整清單：

5.1 應用程式生命週期（5 個工具）

5.2 專案與實驗管理（8 個工具）

5.3 平台與線上連接（7 個工具）

5.4 量測管理（9 個工具）

5.5 線上校調（7 個工具）

5.6 變數管理（7 個工具）

5.7 儀表管理（5 個工具）

5.8 佈局管理（5 個工具）

5.9 主記錄器（Recorder Main，7 個工具）

5.10 匯流排記錄（Bus Logging，9 個工具）

5.11 匯流排監控（Bus Monitoring，7 個工具）

5.12 匯流排回放（Bus Replay，6 個工具）

5.13 ECU 診斷（6 個工具）

5.14 工具視窗管理（5 個工具）

• 
  結構化錯誤回報： 每個工具呼叫都回傳含錯誤碼、可重試指標（Retryability）與復原提示（Recovery Hints）的結構化結果，讓 AI 代理能自主判斷後續動作。
• 
  典型工作流程： 啟動／附掛 ControlDesk → 開啟專案 → 管理並連接平台 → 執行量測／校調／記錄 → 停止進行中的操作 → 斷開平台 → 關閉應用程式。

6. VEOS MCP 能力詳解（10 個工具）

VEOS MCP 讓 LLM 以自然語言直接控制 dSPACE VEOS PC-based 模擬器，全部 10 個工具涵蓋模擬生命週期、系統拓撲檢視、訊號連接修改與日誌分析：

7. ConfigurationDesk & Bus Manager MCP 能力詳解（77 個工具）

此 Server 是四者中規模最大的，提供 77 個工具、11 個資源（Resources）與 15 個提示（Prompts），完整覆蓋 SCALEXIO / MicroAutoBox III 即時應用與 VEOS 虛擬驗證應用的配置與建置流程，以及 Bus Manager 的匯流排通訊配置。以下依官方 tool-map.md 文件分六大群組完整列出全部 77 個工具：

7.1 啟動與生命週期（7 個工具）

7.2 專案與應用管理（14 個工具）

7.3 通訊矩陣與匯流排配置（17 個工具）

7.4 模型與訊號鏈（12 個工具）

7.5 硬體與匯流排存取（19 個工具）

7.6 工作視圖與建置（8 個工具）

8. SystemDesk MCP 能力詳解（7 個工具）

SystemDesk MCP 將 SystemDesk 定位為 AI 生成 AUTOSAR 架構的驗證夥伴（Validation Partner）：AI 代理產出的 ARXML 架構檔案可直接匯入 SystemDesk 進行標準符合性驗證，形成「生成 → 匯入 → 驗證 → 修正」的閉環。全部 7 個工具如下：

9. 實務應用：控制器開發與測試場景

以下從資深 dSPACE 工程實務的角度，說明 MCP Hub 在控制器開發 V 模型各階段的具體應用方式。每個場景都標註了所使用的 MCP Server 與關鍵工具，可直接作為導入時的參考藍圖。

9.1 AUTOSAR 軟體架構開發：AI 生成 + 自動驗證閉環

使用：SystemDesk MCP

傳統上撰寫 SWC（Software Component）的 ARXML 描述檔費時且容易違反 AUTOSAR Schema 規則。導入 MCP 後的迭代流程：

1. 工程師以自然語言描述需求（例如「建立一個含 Sender-Receiver 介面的馬達控制 SWC，週期 10 ms Runnable」），AI 代理直接生成 ARXML。
2. AI 呼叫 start_systemdesk() → create_project() → import_autosar_file() 將生成的 ARXML 匯入 SystemDesk。
3. 呼叫 validate_autosar(output_format="json") 取得結構化驗證報告——JSON 格式讓 AI 能精確解析每一條違規（缺少的 Port Interface 參照、無效的資料型別對應等）。
4. AI 依報告自動修正 ARXML，重新匯入驗證，直到零錯誤——整個迭代無需人工開啟 SystemDesk GUI。
5. 同樣的流程也適用於供應商交付物驗收：收到 Tier-2 供應商的 ARXML 交付包時，AI 自動批次匯入驗證並產出驗收報告。

9.2 SIL / vECU 虛擬驗證：模擬冒煙測試自動化

使用：VEOS MCP（可搭配 ControlDesk MCP）

控制器軟體每日建置後的虛擬驗證是 Shift-Left 策略的核心，MCP 讓這個流程可以由 AI 代理全程駕駛：

1. 冒煙測試：AI 呼叫 veos_load 載入最新建置的 OSA（內含 vECU 與環境模型），以 veos_apply_config 設定 stop_time 與 acceleration_factor（加速因子讓回歸模擬跑得比即時更快），再 veos_start 執行。
2. 失敗自動診斷：模擬初始化失敗時，AI 透過 veos_list_all_available_log_files 與 veos_get_log_file 讀取日誌，判斷是授權問題、模型初始化錯誤還是訊號未連接——這正是過去最耗費資深工程師時間的除錯工作。
3. 整合檢查（ICD 比對）：veos_get_all_signals_and_ports 擷取整個系統的訊號連接矩陣，AI 將其與介面控制文件（ICD）比對，自動找出未連接的埠或錯接的訊號，並以 veos_add_signal_connections / veos_remove_signal_connections 修正。
4. 閉環量測：搭配 ControlDesk MCP 連接 VEOS 平台（controldesk_platform_connect 會自動啟動 VEOS），即可在虛擬環境中執行與 HIL 完全一致的量測與校調操作。

9.3 HIL 測試準備：從通訊矩陣到可執行即時應用

使用：ConfigurationDesk & Bus Manager MCP

HIL 專案啟動階段最繁重的工作是把 DBC/ARXML、Simulink 模型與 SCALEXIO 硬體「接」起來。AI 代理可執行的完整配置鏈：

1. 專案建立：create_project() → add_application() 建立即時應用骨架。
2. 殘餘總線模擬（Restbus Simulation）配置：add_communication_matrix() 匯入整車 DBC/ARXML → create_bus_configuration() → assign_ecu_to_bus_config() 指定哪些 ECU 由 HIL 模擬、哪些是真實待測件 → add_feature_to_bus_element() 為需要測試操作的訊號加上 BusISignalValueAccess（讓測試腳本能覆寫訊號值）→ generate_bus_containers() 產生 BSC。
3. 植物模型整合：add_model() 載入 Simulink 植物模型 → analyze_models() → add_model_to_signal_chain() 曝露模型埠。
4. 硬體 I/O 對應：add_hardware_platform() 以 IP 註冊 SCALEXIO → scan_hardware() 掃描實際板卡 → add_io_function_block() 建立類比／數位／CAN I/O 功能塊 → set_io_function_block_property() 設定鮑率等電氣參數 → auto_assign_channel_set() 或 assign_hardware_automatically() 自動配通道 → auto_connect_matching_io_function_blocks_to_model_ports() 依命名規則自動接線。
5. 建置：check_conflicts() 檢查配置衝突 → build_application() 產生 RTA → get_build_result() 取得產出路徑。

9.4 HIL 實驗執行：量測、記錄與測試操作自動化

使用：ControlDesk MCP

1. 實驗準備：controldesk_app_start_or_attach → controldesk_project_open → controldesk_platform_connect 上線平台，並以 controldesk_variable_description_manage 掛載 A2L 變數描述檔。
2. 量測配置：controldesk_variable_find 依名稱（或模糊搜尋）定位待測訊號 → controldesk_measurement_raster_manage 指定取樣柵格（例如控制迴路訊號用 1 ms、溫度類用 100 ms）→ controldesk_recorder_signal_manage 將訊號加入記錄清單。
3. 條件觸發記錄：controldesk_measurement_trigger_manage 設定觸發規則（例如「車速 > 100 km/h 且 ABS 介入時開始記錄」），controldesk_recorder_main_start 後記錄器進入 WaitingForTrigger 狀態，事件發生時自動寫入 MF4——特別適合捕捉偶發異常。
4. 測試激勵：controldesk_variable_write 對工作頁寫入測試值（如注入感測器故障值、改變駕駛需求扭矩），配合 controldesk_variable_read 驗證控制器反應，實現「寫入-等待-驗證」的測試模式。
5. 操作面板自動生成：AI 依測試規範以 controldesk_layout_manage 建立佈局、controldesk_instrument_manage 放置儀表、controldesk_instrument_signal_manage 連接訊號——「幫我建一個含轉速表、扭矩曲線圖和故障注入開關的除錯面板」一句話完成。
6. 收尾：controldesk_measurement_stop → controldesk_platform_disconnect → 以 controldesk_project_backup_manage 備份整個實驗專案供追溯。

9.5 控制器參數線上校調

使用：ControlDesk MCP（校調 + 變數 + 記錄域）

1. controldesk_calibration_start 在所有平台同時啟動線上校調工作階段。
2. AI 依據量測回饋迭代調整參數：讀取控制誤差（controldesk_variable_read）→ 修改增益／查找表（controldesk_variable_write 寫入 Working Page）→ 以 MF4 記錄驗證步階響應。
3. controldesk_proposed_calibration_manage 管理建議校調工作階段——AI 提出的參數變更先進入「建議」狀態，由工程師審核後才套用，完全符合校調流程的職責分離要求。
4. 調校滿意後以 controldesk_calibration_page_manage 執行頁面複製（Working Page → Reference Page），並以 controldesk_variable_data_set_manage 管理資料集，將成果固化。
5. 典型應用：PID 增益整定、扭矩限制查找表調整、診斷閾值標定——AI 可依「超調量 < 5%、安定時間 < 200 ms」這類量化目標自主迭代。

9.6 匯流排測試：記錄、監控、過濾與回放

使用：ControlDesk MCP（Bus Logging / Monitoring / Replay 域）

1. 長時間匯流排記錄：controldesk_bus_logger_create 在 CAN/CAN FD 存取點建立記錄器，controldesk_bus_logger_configure 設定輸出路徑、時長與檔案滾動（File Rolling）——耐久測試中連續數天記錄也不會撐爆單一檔案。
2. 聚焦記錄：controldesk_bus_filter_create + controldesk_bus_filter_configure 以訊息 ID／遮罩設定通過或阻擋規則，只記錄與待測功能相關的診斷訊框或特定 PDU，大幅減少後處理負擔。
3. 即時監看：controldesk_bus_monitor_create 建立監控器觀察總線活動，controldesk_bus_monitor_save 將緩衝區存檔；分析歷史問題時用 controldesk_bus_monitor_load_data 重新載入檢視。
4. 現場問題重現（Replay 測試）：將路試或客戶現場記錄的總線日誌，以 controldesk_bus_replay_create → controldesk_bus_replay_configure（指定來源日誌與回放模式）→ controldesk_bus_replay_manage 在 HIL 台架上原樣重放給待測 ECU——這是重現「只在特定總線時序下出現」的疑難雜症最有效的手段，AI 可自動批次回放多段日誌並比對 ECU 反應。

9.7 ECU 診斷測試（UDS over ODX）

使用：ControlDesk MCP（ECU Diagnostics 域）

1. controldesk_ecu_diagnostics_setup 為 Diagnostic2 平台掛載 ODX 診斷資料庫，controldesk_ecu_diagnostics_db_manage 管理多個 ODX 檔案版本。
2. controldesk_ecu_diagnostics_vehicle_manage 選擇車輛變體、controldesk_ecu_diagnostics_link_manage 配置邏輯鏈路與診斷介面。
3. 結合故障注入場景：以 controldesk_variable_write 在植物模型中注入感測器故障 → 透過診斷平台確認 ECU 正確設置 DTC → 清除故障後驗證 DTC 老化邏輯——完整的診斷功能驗證循環。

9.8 端到端場景：夜間自動回歸與異常分診

使用：全部四個 MCP Server 協同

10. 安全性設計與已知限制

• 
  Engineers-in-the-Loop： 所有 MCP Server 均設計為工程師主導的工作模式——AI 代理提出的每個動作在虛擬驗證、量測與校調過程中都可由工程師逐一審查與核准，AI 不會繞過既有的工具操作流程。ControlDesk 的建議校調（Proposed Calibration）機制更將「AI 提議、人類核准」直接落實在參數層級。
• 
  平台限制： COM 自動化架構限定於 Windows；Server 以 STDIO 本機子行程執行，非網路服務、不支援多使用者。所有操作皆需本機安裝且授權的 dSPACE 產品。
• 
  COM 阻塞對話框： 若 dSPACE 工具中出現模態對話框（Modal Dialog），COM 呼叫會被阻塞。遇到工具逾時或呼叫失敗時，請先手動關閉對話框再重試；ControlDesk MCP 可透過 controldesk_app_get_logs() 取得診斷日誌。
• 
  早期版本： dSPACE MCP Hub 屬於「Early Release」階段，官方已規劃持續擴充工具、改善引導與支援更廣泛的工作流程；導入專案時建議鎖定版本並追蹤 GitHub Releases 更新。SystemDesk MCP 目前僅支援 .arxml 匯入；ControlDesk MCP 的變數查詢在名稱模糊時需透過 resolution_details 選取正確候選。

11. 參考資源