基於模型的系統工程（MBSE）改變了複雜系統定義、設計與驗證的方式。它將重點從以文件為中心的流程轉向以模型為中心的工作流程。系統建模語言（SysML）是這一轉變的基礎，提供了一種標準化的方法來表示系統結構、行為與需求。然而，從概念圖轉換為功能模型的過程中，常常會暴露出靜態文件所隱藏的缺口。
本指南探討了一個涉及電梯系統的實際案例研究。雖然概念看似簡單，但使用SysML進行建模的過程卻揭示了複雜的行為問題、時序限制以及介面模糊之處。透過剖析此範例，我們檢視嚴謹的建模實務如何揭示對安全性與可靠性至關重要的隱藏複雜性。
🏗️ 理解系統結構
SysML建模的第一步是定義系統的邊界與組成。對於電梯而言，其結構不僅僅是一輛上下移動的車廂，還包含多個透過明確介面互動的子系統。
1.1 模塊定義圖（BDD）🧩
模塊定義圖用於建立系統內物件的類型。在此情境中，我們定義以下主要模塊：
- 電梯系統： 最上層的容器。
- 車廂： 乘客空間。
- 門： 進入機制。
- 電機： 推進單元。
- 控制器： 管理運作的邏輯單元。
- 呼叫按鈕： 用於輸入的使用者介面。
這些模塊透過泛化與組合關係相互關聯。例如，電梯系統由車廂、門與電機組成。這種結構定義確保每個實體元件都有對應的模型元素。
1.2 內部模塊圖（IBD）🔄
雖然BDD定義的是類型，但內部模塊圖則定義了實例與連接。這正是指定資料與能量流動的地方。
- 介面： 定義互動點。例如，電機需要電力介面，而控制器需要信號介面。
- 流動屬性： 定義介面之間傳遞的內容。電氣信號從呼叫按鈕流向控制器，機械動力則從電機流向車廂。
- 參考： 將零件連結至其對應的模塊。
建立詳細的IBD迫使工程師明確指定控制器與門之間的通訊方式。是直接的物理連接，還是邏輯信號？這種區別在文字需求中經常被忽略，但在模型中卻變得清晰明確。
🧠 使用狀態機進行行為建模
僅有結構並不能定義功能。SysML 使用狀態機圖來模擬系統的動態行為。這正是電梯案例研究開始顯現出顯著複雜性的地方。
2.1 定義狀態 ⏸️
狀態機代表特定模塊或整個系統的生命周期。電梯常見的狀態包括：
- 閒置：等待呼叫。
- 門打開：可供乘客使用。
- 門關閉中：轉換至關閉狀態。
- 向上移動：上升至某樓層。
- 向下移動：下降至某樓層。
- 停止：抵達樓層，門已關閉。
每個狀態代表一種穩定狀態，在此系統會執行特定活動或等待事件發生。
2.2 轉移與事件 ⚡
當觸發事件時，就會發生轉移。事件可以是外部的（按鈕按下）或內部的（感應器信號）。守衛條件決定轉移是否允許。
考慮從門打開到門關閉中:
- 事件：定時器到期或門關閉信號。
- 守衛：門口未檢測到障礙物。
- 動作：啟動門馬達。
在此，模型揭示了一個潛在問題。如果守衛條件僅依賴定時器，系統可能會在乘客身上關閉門。如果僅依賴障礙物感應器，而感應器故障，門可能永遠無法關閉。模型迫使工程師定義這些衝突輸入之間的優先邏輯。
🕸️ 複雜性陷阱：時序與互動
此案例研究最重要的價值在於發現時序問題。簡單的狀態機通常假設轉移是瞬間完成的，但現實世界中的系統是在連續時間中運作的。
3.1 競態條件 ⏱️
當系統的行為取決於事件的順序或時序時，就會發生競態條件。在電梯模型中，請考慮乘客在門關閉時按下樓層按鈕的情境。
情境 A： 按鈕按壓在門完全關閉前被處理。系統會打開門，並移動到所要求的樓層。
情境 B： 門在按鈕按壓被註冊前已完全關閉。系統只有在當前行程結束後才會移動到所要求的樓層。
若模型中沒有模擬或精確的時序約束，這兩種結果將無法區分。SysML活動圖有助於視覺化動作的順序，但狀態機必須標註時序約束，以避免歧義。
3.2 死結情境 🚫
當系統進入一個無法進行任何進一步轉移的狀態時，就會發生死結。這是一種關鍵的失敗模式。
在電梯模型中，若出現以下情況，就可能發生死結：
- 電梯車廂位於樓層之間。
- 門被鎖住。
- 馬達已斷電。
- 尚未註冊緊急呼叫。
若在此狀態下電力中斷，系統將無法移動。模型必須包含「緊急電源狀態」或「救援模式」以覆蓋標準邏輯。在建模階段早期識別此需求，可避免後續昂貴的硬體變更。
3.3 介面不匹配 📡
複雜行為通常源自子系統之間的不匹配。控制器會向馬達發送信號，而馬達期望特定的電壓範圍。模型必須定義介面合約。
| 介面元件 | 預期值 | 現實世界中的變異 | 風險 |
|---|---|---|---|
| 信號延遲 | 小於 50 毫秒 | 因接線而產生的變異 | 門安全延遲 |
| 電源電壓 | 24V 直流 | 20V – 28V | 馬達停轉 |
| 門感應器 | 二進位（開/關） | 類比雜訊 | 偽開信號 |
透過在 IBD 中映射這些介面，工程師可以觀察到訊號衰減可能發生的位置。這種可見性在平面的需求文件中是無法實現的。
🔍 驗證與可追溯性
MBSE 的核心承諾之一就是可追溯性。模型中的每個元素都應連結至一個需求，並延伸至一個測試案例。電梯模型展現了這種連結的強大功能。
4.1 需求分配 📋
需求不僅僅是文字；它們是對模型的約束。例如：
- REQ-01： 電梯必須在 3 秒內回應呼叫。
- REQ-02： 若偵測到障礙物，門不得關閉。
在模型中，REQ-01 約束狀態機的轉移時間。REQ-02 約束門關閉轉移上的 Guard 條件。若模型無法滿足約束，該需求將被標示為未驗證。
4.2 模擬與驗證 🎮
靜態模型是靜態的。為了驗證行為，必須對模型進行模擬。模擬使工程師能夠注入事件並觀察系統回應。
模擬步驟：
- 將系統初始化為 閒置 狀態。
- 觸發一個 呼叫請求 事件於三樓。
- 觀察轉移到 上行.
- 注入一個阻塞事件期間門關閉中.
- 確認系統恢復至門打開.
如果模擬在第5步失敗，表示模型邏輯有誤。此反饋迴路可在任何實體硬體建構前，進行迭代優化。
🛠️ 常見的建模陷阱
即使有明確的案例研究，工程師仍經常在SysML模型中引入錯誤。識別這些陷阱對於維持模型完整性至關重要。
5.1 過度抽象 🌫️
過於抽象的模型會隱藏關鍵細節。如果將馬達模塊視為無內部行為的黑箱，工程師將無法驗證其響應時間。模型必須具備足夠的細節，以支援所需的分析層級。
5.2 欠乏抽象 🧱
相反地，對每個螺絲和螺栓進行建模是低效的。模型應專注於當前開發階段相關的系統層級行為。細節程度必須與專案階段相符。
5.3 不一致的符號 📝
使用不同的命名規範來命名狀態或模塊會造成混淆。採用標準化的命名規範至關重要。例如，始終以現在式命名狀態（例如，門關閉而非門關閉中作為狀態本身）。
📈 從電梯模型中學到的教訓
此案例研究突顯了系統工程中的幾個關鍵教訓。
- 結構定義行為：若無明確的結構，便無法建模行為。內部結構圖（IBD）決定了可進行的互動。
- 狀態機揭示邏輯缺口：明確定義狀態，迫使工程師考慮邊界情況，例如電力中斷或感測器故障。
- 可追溯性確保覆蓋範圍：將需求與模型元件連結，可確保不會遺漏任何安全限制。
- 模擬即驗證：執行模型是驗證時序與互動邏輯的唯一方法。
- 介面合約至關重要：定義介面與資料流可避免子系統之間的整合問題。
🚀 在MBSE中持續前進
電梯範例是大型系統的縮影。無論是設計太空船、汽車煞車系統，還是醫療設備，這些原則都相同。抽象並不會消除複雜性；而是透過嚴謹的建模來管理複雜性。
隨著專案規模擴大，SysML的紀律變得更加關鍵。它提供了一個單一的真理來源，使工程、軟體與硬體團隊保持一致。透過將模型視為活的實體而非靜態圖表，組織能夠降低風險並提升產品品質。
從簡單的圖表到經過驗證的模擬，這段旅程需要耐心與精確。然而，關於行為、時序與互動所獲得的洞見無可估量。它們將工程流程從猜測與驗證的作法，轉變為可預測且可驗證的工作流程。
最終，目標不僅是建構一個能運作的系統，更是建構一個能被理解的系統。模型即是理解，模擬即是證明，而需求則是承諾。