銳碁資訊 JUI-CHI Information

SYSML V2 · MIGRATION READINESS · MBSE

SysML v2 已成正式標準：企業既有 SysML v1 模型該如何準備？

從語言差異、文字表示、API、客製模型到分階段試點，建立可驗證的 SysML v2 移轉準備計畫。

v2.0FORMAL STANDARD

FORMAL STANDARD · 查閱日期 2026／10／14

標準已發布，企業要開始準備；但不等於現在就全面轉換

OMG 規格目錄將 SysML 2.0、KerML 1.0 與 Systems Modeling API and Services 1.0 列為 2025 年 9 月的正式版本。現行 SysML 2.0 Language Specification 文件編號為 formal/2026-03-02，日期為 2026 年 3 月；這代表正式規格文件仍可能透過後續發布整理，但不能把標準成熟度直接等同於每一套工具、每一個模型及每一項客製都已可投入正式移轉。

SYSML2.0 正式規格
KERML1.0 語意與語法基礎
STANDARD API1.0 模型服務介面
核心原則：「標準已正式發布」與「企業模型可直接轉換」是兩件事。OMG 也預期 SysML v1 仍會在產業過渡期間持續使用。

01 · OFFICIAL STATUS

先把標準、工具與企業環境分成三個層次

OMG SysML v1 官方識別圖
SysML v1.7 仍是正式規格，OMG 認為 v1 將在過渡期持續使用。圖片來源：OMG SysML 官方網站。
OMG SysML v2 官方識別圖
SysML v2.0 已成正式規格，但工具支援範圍仍須逐項核對。圖片來源：OMG SysML 官方網站。
STANDARD

OMG 規格

定義語言、Transformation、機器可讀模型、文字表示及標準 API。

IMPLEMENTATION

工具供應商

各產品的圖形、文字、API、轉換及協作支援範圍可能不同。

ENTERPRISE

企業模型

Profile、Plugin、Template、整合與治理方式決定實際移轉風險。

EVIDENCE

測試結果

官方聲明只能作為輸入，仍須以代表性模型及驗收條件確認。

02 · V1 AND V2

SysML v2 不是只替 SysML v1 增加文字語法

SysML v1 與 SysML v2 主要概念差異示意圖
自製示意圖：SysML v2 建立在 KerML 語意基礎上，並加入標準文字表示與 API；實際轉換仍需驗證模型語意及客製內容。
面向SysML v1SysML v2企業準備重點
語言基礎以 UML Profile 延伸系統工程概念。以 KerML 提供共同語意與語法基礎。不可只用圖形名稱做一對一對照。
型別與使用常以 Block、Property、Part Property 表達。Definition 與 Usage 清楚區分定義和具體使用。盤點型別、實例、繼承及重用方式。
表示方式實務多以工具圖形介面為主。圖形與文字表示對應同一底層模型。建立文字、圖形及版本差異的治理規則。
交換與整合常依賴 XMI、工具 API 或專屬 Connector。提供 Systems Modeling API and Services。標準 API 不代表所有工具已達相同 Conformance。
分析與驗證依 Profile、Plugin 與工具能力組合。分析、驗證案例與跨領域關係納入更一致的語意。重建驗證基準，不能只確認檔案可開啟。

03 · TEXTUAL NOTATION AND API

文字表示與 API 帶來自動化機會，也帶來新的治理責任

SysML v2 的文字表示可讓模型內容更容易進行差異比較、審查、自動產生、版本控制及 CI／CD 整合；圖形表示則持續支援溝通和系統理解。兩者是同一模型的互補呈現，不應形成彼此失去同步的兩套來源。

TEXTUAL

可讀、可比較

適合差異檢視、自動化與規則檢查，但仍需要格式、命名及審查規範。

GRAPHICAL

視覺溝通

支援跨角色理解複雜關係，圖形配置與觀點仍需納入驗收。

API & SERVICES

查詢與更新模型

標準涵蓋 Project、Commit、Element、Query 等服務及不同 Conformance。

INTEROPERABILITY

不是無條件互通

供應商實作範圍、版本及延伸能力仍會影響跨工具結果。

04 · CAN V1 MODELS CONVERT DIRECTLY?

OMG 提供 Transformation Model，不代表企業模型能一鍵無損完成

SysML 2.0 正式資源包含 SysML v1 to v2 Transformation Model，這是建立轉換規則的重要基礎；但企業模型通常還包含圖形布局、工具專屬元素、Profile、Stereotype、Tagged Value、報表、模擬、腳本及外部整合。這些內容是否被支援，要由工具文件與實際測試共同證明。

最低驗證基準：轉換前後至少比較 Package、Element、Relationship、Requirement、Interface、Port、Parameter、Trace、Validation Result 與未解析參照；不能只以「檔案成功開啟」作為驗收。

05 · CUSTOMIZATION RISK

Profile、Stereotype 與工具客製是最容易被低估的範圍

項目要盤點的內容主要風險
ProfileURI、版本、Metaclass、繼承、Constraint 與依賴。v1 Metamodel 相依無法直接映射至 v2 語意。
Stereotype套用範圍、Tagged Value、預設值及驗證規則。轉換後名稱存在，但語意或約束不一致。
Library／Template共用模型庫、專案範本、報表與文件樣式。參照、版型、欄位或輸出結果改變。
Plugin／ScriptAPI、JDK、第三方函式庫、Macro 與自動化。原 API 或元素型別不再相容。
Integration需求、PLM、ALM、測試、模擬、OSLC 與資料橋接。識別碼、同步方向及追溯關係中斷。
CollaborationRepository、Branch、Merge、權限、版本及稽核。多人流程可用，但歷史及治理規則不完整。

06 · TOOL SUPPORT

工具支援要用「能力矩陣＋代表性模型」驗證

OMG 2025 年公告收錄多家工具供應商對 SysML v2 的公開說明，其中達梭系統表示將透過 CATIA Magic 推進 SysML v2；這屬於原廠方向聲明，不能直接推導為特定版本已支援完整轉換、所有圖形、所有 API 或既有 Cameo／MagicDraw 客製。

評估欄位正式依據實測證據
產品與版本產品頁、Release Notes、支援矩陣。安裝版本、授權及環境清冊。
語言範圍支援的 SysML v2 功能與已知限制。代表性結構、行為、需求、分析案例。
圖形／文字支援表示方式及同步規則。雙向編輯、差異、布局與版本控制。
APISystems Modeling API Conformance 聲明。Query、Commit、Update、權限及效能測試。
v1 轉換轉換工具、支援來源版本及限制。元素、關係、追溯、客製與錯誤報告。
協作與整合Repository、Connector 及部署文件。多人、分支、稽核、PLM／ALM／V&V 整合。

07 · CONTROLLED PILOT

分階段試點：先證明可行，再擴大範圍

企業 SysML v2 分階段移轉與驗證流程圖
自製示意圖：以可回復的模型副本及明確驗收條件，降低語意、客製、整合及協作流程的移轉風險。
  1. 建立工具、版本、模型、Profile、Plugin、Template、整合與協作環境清冊。
  2. 選擇範圍有限、關係明確，但能代表真實風險的試點模型。
  3. 建立 SysML v1 基線，包括元素數量、關係、追溯、驗證結果與圖形清單。
  4. 只在隔離環境使用模型副本進行轉換或重建，保留備份和回復點。
  5. 比較結構、行為、需求、介面、參數、圖形、文字、API、報表及整合結果。
  6. 由建模人員、系統管理員、整合團隊及業務使用者共同驗收。
  7. 記錄需人工判讀、重新建模或延後處理的項目，形成 Migration Backlog。
  8. 建立 SysML v2 建模規範、角色、審查方式及教育訓練。
  9. 依試點數據決定 Go／No-Go、下一批範圍及新舊模型共存方式。
  10. 正式切換時保留唯讀保存、稽核、問題追蹤與回復方案。

08 · READINESS CHECKLIST

企業現在應先盤點的十類資料

  1. SysML v1 工具、正式版本、Refresh、Edition、作業系統與執行環境。
  2. 模型數量、容量、重要性、負責人、用途及法規交付要求。
  3. Package、Module、Library、Usage、Proxy 與跨專案依賴。
  4. 自訂 Profile、Stereotype、Tagged Value、Constraint 及 Metamodel 相依。
  5. Plugin、Script、Macro、Open API、Template 與 Report Template。
  6. 需求、PLM、ALM、模擬、測試、資料分析及 CI／CD 整合。
  7. 使用者、群組、權限、分支、版本、基線、審查與協作方式。
  8. 模型驗證錯誤、未解析參照、重複元素、命名及現有技術債。
  9. 轉換前後的元素、關係、追溯、圖形、報表及效能驗收指標。
  10. 備份、測試資料、試點範圍、唯讀保存、正式切換及回復條件。

09 · CONCLUSION

現在最重要的不是「何時全面轉」，而是建立可驗證的準備能力

SysML v2 已具備正式標準地位，企業應開始建立知識、清冊、工具評估與試點能力；但開始準備不等於立即全面轉換。先盤點、再試點、以基線驗證差異，才能把語言更新轉化為真正可治理的 MBSE 能力。

工具版本、SysML v1 轉換、Profile、Plugin、Template、API、Repository 及授權支援，均應依供應商最新正式文件與實際環境測試確認。

RELATED CONTENT

延伸閱讀與解決方案

PRODUCT NAMESCATIA Magic、Cameo、MagicDraw 是什麼關係？SOLUTIONCATIA Magic／Cameo 導入服務MBSE模型化系統工程解決方案TRACEABILITYMBSE 需求追溯與驗證管理RELIABILITYMBSE 可靠性設計READINESS預約 SysML 模型盤點說明

SYSML V2 READINESS

先選一個代表性模型，建立可量測的試點

從版本、模型、客製、協作與整合盤點開始，定義轉換前後的驗收基準與風險清單。

預約說明 ↗

OFFICIAL SOURCES

官方資料來源

OMG：SysML 2.0 Specification — 正式版本、Language／Transformation 文件及機器可讀資源。

OMG：KerML 1.0 Specification — SysML v2 的語意與語法基礎。

OMG：Systems Modeling API and Services 1.0 — 模型 Repository、Project、Commit、Element、Query 與服務 Conformance。

OMG：Final Adoption of the SysML V2 Specification — 正式採納、文字與圖形表示、API 及工具供應商公開說明。

OMG SysML 官方網站 — SysML v1 與 v2 的過渡說明。

本文整理日期為 2026 年 10 月 14 日。工具功能、版本相容、模型轉換及授權狀態，應以供應商最新正式文件、客戶合約及實際環境驗證為準。