當工業工程遇見系統工程 (下)  

✎【Mealcourt LLC】陳宏毅 總裁  |   2026-03-10

       在這樣的高速而多元的發展之下，系統工程的概念與視角，只會是越來越重要，不是因為它聽起來比較「高大上」，而是因為它更是各部門以及各個系統的點線面協作的共同語言：把需求、架構、介面、風險、驗證、維運、改版，拉回同一條主線，讓每一次決策都有依據、可追溯、有邊界。

為什麼「當代工程生態系統」會讓系統工程變成剛性需求？

1. 複雜度的來源變了：不是「零件多」，而是「關係多」

相較於傳統工程系統，自動化 (Automation) 與數字化 (Digitization) 大多只在部分子系統上設置。而現代的工程系統，由於更優的數字化技術，更強大的 數位化 (Digitalization) 模型，與智能化 ( Intelligentization )的突破，導致系統的複雜度，已經不是在元件的數量上；而是在各個元件，以及子系統之間的互動與耦合連結。以下舉幾個例子說明

1. • 當代的汽車不再只是機械的產品，而是由軟體定義（Software-Defined） + OTA* 更新 + 感測器資料回饋 + 充電網路 + 供應鏈韌性。

   • 醫療器材也不再只是硬體合規，而是資料獲取與使用與管理、病人隱私、預判推測、資安，以及臨床流程的整合等。

   • 製造現場更不是只有 OEE（Overall Equipment Effectiveness）、稼動率、良率，而是「工廠 — 供應商 — 物流 — 門店」端到端的協作能力。

       當代的系統模型的關係是越來越複雜的，圖1為示意圖。 關係越多，就表示介面越多、更新越頻繁。這時候，問題的最大風險就是「整合評估」，也就是說改一個地方，連鎖反應可能一路炸到看不到盡頭。 系統工程的價值就在這裡：用系統化的方法，把介面管理、需求追溯、風險控制、驗證模式 等等，從一開始就建起來，避免被「整合地獄」整個吞掉。

2. 工程生態系Engineering Ecosystem從「交付一次」變成「持續演進」

       過去工程領域的人群，常常把系統工程的V 模型（請參考上期關於Ｖ模型的介紹）流程理解成：需求→ 設計 → 實作 → 驗證 → 交付(deliver)，像是一條單行道。  然而，當代系統的「交付 」只是一個啟用的起點：後續的版本演進、資安修補、模型更新、營運優化、法規變更、供應商更替等等，都要算是交付的一部分。而且這些措施的複雜程度，並不亞於原系統的設計，甚至會更有挑戰。 例如：如何讓系統活得久、運行得穩、還能一直根據周邊系統的更新，讓使用者的使用體驗不斷的優化。

       所以更精準的說法是：V 模型不是消失，而是被「迭代」與「數位化與智能化的閉環」包住了。 也因此，模型化系統工程（Model-Based Systems Engineering，MBSE ）、數位線程(Digital Thread)、數位孿生(Digital Twin)、AI 這幾個詞才會在近年一起變成工程學上的顯學。

二、MBSE 是什麼：

       在傳統系統工程（Document-Based Systems Engineering, DBSE）中，工程活動的主要產出是文件。需求規格書、介面控制文件（(Interface Control Document, ICD）、設計說明書、測試計畫與驗證報告，各自以文件形式存在，透過人工方式進行審查與維護。這種方式在中小型系統中尚可運作，但在高度複雜、多團隊、多版本演進的系統中，文件之間的一致性、追溯性與變更控制的難度高，一有疏失，往往成為主要風險來源。

       而MBSE一個最大的優勢，就是將「系統規格」提升為系統工程的生態內容以模型化的方式來表現，模型本身就是系統需求規格的核心的產物 (Deliverables)。 更精確地說，MBSE 是一種以有語法規範的模型（formal models）為主體，支援需求分析、功能分解、行為建模、架構設計、介面定義、驗證與確認（V&V）等全生命週期活動的方法論與工程實踐框架。 

       進一步說明，可以表1對於傳統文件式系統工程與模型式系統工程方法的比較。

我們可以這樣總結：MBSE是一個具有語意一致性，與邏輯完整性的工程知識結構。讓跨部門溝通從「大家各寫各的」變成「同一份文件的各個章節」。

• 為什麼最近這幾年特別關鍵？

       當工程工具正在走向更強的互通與自動化。像 **SysML v2 的方向，就很明確強調：更精準的語意基礎、文字語法 + 圖形語法並存、標準 API 支援跨工具互操作，也更容易跟自動化與 AI 接軌。換句話說：MBSE 不只是方法論，它正在變成工程的基礎設施。 如果你的工作也是在大型系統管理或是相對多元而複雜的情境下，不妨瞭解一下MBSE 可以怎麼協助你更有效率的完成工作。

三、為什麼 Digital Twin 在 AI + 系統工程時代這麼關鍵？

       接下來，我們來簡單的說明大家經常聽到的工程名詞Digital Twin。

一般來說，工程設計或是執行的工程師或是技術人員，會認為Digital Twin就是搜集實體設備運行的數據，或是運作當中作為控制的一個節點。但從系統工程來說，它功能遠遠不止於此！

       如果說 MBSE 是把工程「模型化」，那 Digital Twin 是把工程「活化」的節點：它不只是一個系統設計上模型元件，而是跟真實系統在設計、驗證以及運行階段，透過資料的連結與同步，在系統管理的各個層面，變成一個「會呼吸的活動模型」。 我們從三個角度來說明：

• AI 需要資料數據，但更需要上下文：感測器數據如果沒有系統架構與需求語境，就只是雜訊；有了 Digital Twin，資料可以對應到功能、狀態、介面、失效模式。

• AI 需要驗證場域：Twin 提供安全的試驗場，你可以做 what-if、極端情境、資安/安全性演練，不必拿真系統冒險。

• AI 會不斷的迭代升級，Digital Twin 讓工程閉環：模型更新、策略更新、維修策略更新，都可以先在 Digital Twin 驗證後再回到真系統。

       更務實地說：Digital Twin 是把「運行」跟「工程」串回同一條線的關鍵節點。沒有Digital Twin，AI 的升級容易變成沒有驗證過的「黑盒升級」；有了Digital Twin，改版可以被追溯、被驗證、被管理。

四、AI 讓 系統工程變成「高速迭代的工程週期循環」

在傳統系統工程實務中，開發流程多半呈現為一種文件驅動的節奏：

         需求討論 → 撰寫文件 → 審查 → 修訂 → 簽核 → 進入下一階段

       這種模式以文件為主要產出，以會議與人工審查作為品質控制機制，並以階段性審核作為決策節點。問題並非方法錯誤，而是反應速度慢、變更成本高、錯誤通常在Ｖ型週期的後期才會被發現。 AI，尤其是生成式 AI 與機器學習，的出現，正在改變傳統系統工程的運行生態。

       但是，系統工程師需要理解，AI 並沒有改變了系統工程的基本原則，例如需求分解、架構設計、驗證與確認及風險管理。AI 改變的是工程知識處理的速度、範圍(scope) 與自動化程度。 因此，系統工程逐漸從文件驅動轉向模型與資料驅動，形成高速迭代的工程循環：

      模型建立 → 模擬與推演 → 驗證與確認→ 回饋修正 → 再次模擬

       關鍵不只是速度，而是 系統的變更能即時分析、假設能快速驗證、決策能基於更多方案進行模擬或是訓練之後來做比較。

下面用系統工程各階段來看，AI 能怎麼協作（也就是流程真正發生改變的地方）：

1. 需求與情境：從「被動收集」變成「主動生成 + 驗證」

        AI 可以協助把不同利害關係人(Stakeholders/CONOPS***) 的語言整理成一致的需求模型與情境腳本，還可以海量的補上「沒想到但會發生」的例外情境。  例如，需求的品質檢查：AI 很擅長找出「模糊詞」（例如：快速、友善、盡量、適當），並建議量化指標與驗證方式像是：延遲上限、可靠度、MTBF、資安等級等等。 還有就像是系統的一致性與可驗證性：把需求改寫成「可測、可追溯、可分配」的形式，大大降低了因為模稜兩可的狀況，所導致的種種補救措施。 這一步最重要的變化是：需求不再只是 Word 檔，而是「模型裡可以被計算的物件」。

2. 架構與設計：從「Baseline」變成「Continuous Exploring」

       大型系統的需求規格，經常需要有資深經驗的人，進行整體評估，曠日費時的討論與層層與所有相關責任單位的簽署。  有了AI之後，從開始討論的初期，就可以開始trade off以及多模態的分析 ：在性能、成本、能耗、可靠度、供應風險、可維修性之間快速比較多個方案。 決策責任仍在系統工程師：因為 trade-off 背後常涉及法規、安全、倫理與可接受風險，需要清楚的管理與責任歸屬的要求。

3. 驗證與確認：從「後期大規模檢測」變成「前期的大量模擬」

       MBSE 讓你在模型中定義驗證案例（Verification Cases），AI 則能協助自動生成測試組合、找出邊界條件、甚至產生更完整的意外或是矛盾的模式假設。 結果就是把錯誤的發現往開發的前面步驟轉移：在還沒做出完整實體之前，就可以利用需求模型與系統模擬把各種想得到，沒想到的大小的問題，例外可能性，甚至連補救措施都可以推論出來。

4. 維運與改版：從「維修」變成「持續學習」

       系統上線後，AI/ML 模型會面臨海量的資料產出、環境變遷、資安威脅等等實際的問題。這時 系統工程 的生命週期管理閉環就非常重要：Stakeholders要知道「哪些需求被破壞了」、「哪些假設不成立了」、「該改哪個介面或流程」。 這也正是數位孿生（Digital Twin）發揮最大作用的時機，而系統也因此成為了持續演進與學習的工程實體。

結語：IE 與 SE 的交會點

       以上簡要的說明了系統工程為何在當代將會更受到關注和重視，以及傳統與當代系統工程的演進與核心概念，像是MBSE, Digital Twins, ＆ AI。 而這三個層面，也就代表了當代系統工程的三大主體：Model, Data and Administration.    有了這樣的基本理念架構，進入到大型或是複雜的系統當中，（參考以上的插圖）就可以更清楚的分辨出，各個系統脈絡之間的狀態，與前後關係了！ 

       談到這裡，有一個相當重要的觀點需要提醒讀者。光是有AI 在推動系統工程的各個階段，很有可能的也是在盲目的放大系統的風險。  眾所周知，AI 的推論，在沒有給出清楚的邊界條件的時候，AI 是很有可能給出似是而非的推論結果。 對於大型系統而言，這就一個可想而知的風險。  所以，前置的MBSE的結構化的需求模型，反而給了AI 更明確的需求邊界限制來運作。  因此，所以MBSE，以及相對的Ｖ＆Ｖ， 是 AI 進入工程決策前的必要基礎相應舉措。 

       本期以及上一期的文章，希望讀者對系統工程的來龍去脈能有一個基本的認識和理解！  未來如果有機會，我會選出幾個案例，來拆解當代系統工程在各個開發與運行階段，在幾本原則下，不同方式的運用；或是因為系統開發前期，缺發系統啟動後多重因素交叉所發生的變化，造成系統運行的重大失誤，而發生的致命事件的案例！

<本文完>

• *OTA: Over the air. 一般來說是指汽車上不同部件的軟體，由系統商或是原廠直接更新的模式

• **SysML V2: (系統建模語言第 2 版），是一套用於模型化複雜系統的下一代標準語言，主要支援 MBSE（模型式系統工程）。它比 SysML v1 更強調精確性、表達能力、可用性與互通性，可用來描述系統的需求、結構、行為，以及分析與驗證。 想要進ㄧ步了解Sys ML V2, 請參考以下link. https://www.omg.org/sysml/SysML-2.htm?utm_source=chatgpt.com

• CONOPS***: Concept of Operations.  作業概念說明書或：運作構想。 一般是指系統在真實世界中「如何被使用」的文件或模型，但是這不是技術規格書。