—前言—

我們知道，SysML是一種高度通用的系統建模語言，其9種視圖雖然具備高度的靈活性，但是往往也意味著無法在工程實踐中直接應用，必須進行一系列封裝。源自Thales多年工程經驗的MBSE建模工具Capella，就在SysML基礎上進行了一系列工程化封裝，是當前市面上最實用的MBSE技術路線之一。Capella對SysML的封裝可以概括為四個方面，下面將逐一說明。

一、功能分析方面的封裝

原生的SysML對功能分析的支持并不直觀，甚至沒有“功能”和“功能層級”的概念。而我們知道，功能分析是系統工程的核心內容，是復雜系統分析設計的主線之一。因此，Capella著重在功能分析方面對SysML進行了封裝擴展。

使用SysML進行功能分析，最常見的方式就是基于“活動圖”及其中的“動作”開展。這種方式主要的局限包括以下幾點：

• 無法在同一個視圖中展現多層嵌套的功能；

• 不同層級的功能之間必須通過端口的層層代理才能建立接口關系；

• 缺少完整的功能樹視圖。

為解決這些問題，Capella在SysML的基礎上封裝了“功能”模型元素，以及“功能數據流”視圖和“功能分解”視圖。這些模型元素和視圖可以更好地支撐功能分析工作。這種封裝的優點包括：

1）可以更簡潔地表達多層功能的嵌套關系

在Capella中，多層功能的嵌套關系可以用一張功能數據流視圖簡潔地展示出來，如下圖所示：

圖 1 Capella功能數據流視圖

相較而言，原生的SysML必須用四張活動圖才能完整表達同樣的信息，如下圖所示：

圖 2 原生SysML的活動圖

2）功能接口的建模工作量大幅降低

在Capella的功能數據流圖中，一般將功能接口定義在最底層的功能上（因為父功能通常都屬于抽象概括）。當設計師在視圖中隱藏低層級功能時，相應的功能接口會自動顯示在父功能上，如下圖所示：

圖 3 Capella功能接口的自動代理顯示

相較而言，原生的SysML需要構建大量的“Activity Parameter”才能表達同樣的功能接口，建模工作量要大得多，如下圖所示：

圖 4 原生SysML的代理端口機制

3）迭代修改更便捷

在Capella中，由于功能端口只需定義在底層功能上，因此在進行功能架構的修改時十分便捷，只需要進行功能或端口的簡單拖拽即可。

相較而言，在原生的SysML中，由于功能接口的定義機制復雜，因此迭代修改的工作量十分巨大，如下圖所示：

圖 5 原生SysML迭代修改工作量巨大

4）支持自底向上的建模方式

當我們在系統開發之初就已擁有充分完備的系統需求規格，或者是在開發一款成熟類型的產品時（這種場景很常見），往往會進行自下而上的功能分析建模。在進行自下而上的建模時，往往會先定義完備詳細的底層功能，然后再將這些它們分組抽象成上層功能。

這樣的建模場景在Capella中可以很自然地開展，因為功能接口本身就是定義在底層功能上的。

相較而言，在原生的SysML中，因為復雜的代理接口機制，在自底向上的建模過程中，每進行一層功能抽象就意味著所有活動圖的一次重構，如下圖所示：

圖 6 原生SysML自底向上建模的工作量巨大

5）可以完整地表達功能樹

功能樹是系統工程中常用的表達功能架構的視圖之一。在Capella中，專門封裝了“功能分解”視圖以支撐功能樹的表達，如下圖所示：

圖 7 Capella中的功能樹

相較而言，在原生的SysML中，雖然“活動圖”本身可以以節點的形式出現在BDD圖中，但是因為底層的“動作”無法在BDD圖中顯示，因此無法呈現完整的功能樹。

二、“實例”和“類型”方面的封裝

原生的SysML繼承自UML，因此在“實例”和“類型”的處理方面沿用了軟件工程師的使用習慣，即在定義設計對象時必須先定義“類型”，然后“實例化”，如下圖所示：

圖 8 原生SysML中的“類型”和“實例”

實際上對于大部分系統工程師而言，更習慣從“實例”的角度思考問題，所有東西默認都是“實例”，只有在需要重用的時候才引入“類型”的概念。為此，在Capella中，“類型”和“實例”的概念被隱藏起來，所有對象都被認為是“實例”，提供簡單的“實例建模”機制，如下圖所示：

圖 9 Capella中的“實例建模”機制

對于可重用的通用組件，Capella專門定義了“REC (Record)”和“RPL (Rplay)”的概念，進行顯式的“類型”定義與“實例化”機制，如下圖所示：

圖 10 Capella中顯式的“類型”和“實例”機制

三、系統結構與行為統一表達方面的封裝

如何統一系統結構與行為方面的設計，是系統工程領域的主要挑戰之一。系統工程師必須有效地理解系統結構組成與系統功能行為之間的相互影響，以便設計出成功的系統。

在原生的SysML中，系統結構主要通過BDD圖和IBD圖表達，其中系統的內外部接口主要通過IBD圖構建。與此同時，原生SysML主要通過活動圖表達系統行為，但活動圖與IBD圖無法統一顯示，即使是白盒活動圖也無法表達不同系統組件之間的接口設計。這種結構設計與行為設計之間的相對割裂，如下圖所示：

圖 11 原生SysML中的結構表達與行為表達

而在Capella中，專門封裝的“架構圖”視圖，使得系統的功能、組成、接口協議、物理連接方式等信息可以在一張視圖中直觀、統一地表達，如下圖所示：

圖 12 Capella中結構與行為的統一表達

四、模型元素與視圖的封裝

在原生SysML中，各類模型元素和視圖均相對通用，并沒有特指某個特定的工程層級。這種處理方式雖然具備高度的靈活性，但同時也使得SysML在實際工程中不夠落地。例如，如果系統工程師同時用“Block”來定義“分系統”和“物理組件”，就會使得整個系統模型表意含糊、令人困惑。因此，對SysML模型元素與視圖的工程化封裝勢在必行。

Capella對SysML中的大量模型元素進行了封裝。例如，Capella將SysML中的“Usecase”封裝為了“Operational Capability”和“Capability”，分別用于表達體系級的能力和系統級的能力，這樣在實際使用中就不至于發生混淆。同樣的，Capella也對SysML的視圖進行了封裝。例如，Capella將SysML中的“用例圖”封裝為了“運行能力圖”和“系統能力圖”，分別用于對體系級能力和系統級能力進行建模。Capella對SysML各類視圖的封裝如下圖所示：

圖 13 Capella對SysML視圖的封裝

綜上所述，Capella對SysML的封裝完全來自于工業界對SysML的工程實踐，是經過國內外成千上萬型號項目實際檢驗的技術路線。在看過上述技術細節的分析之后，相信大家都能感覺到，Capella正是國內工業界開展SysML工程化應用的很好的切入點。

更加驚喜的是，Capella還是一種完全開源的建模工具，可以直接從官網免費下載使用。那還等什么呢？趕緊動手試試吧！

文章來源：適途科技