---

基于模型的系統工程MBSE的三大支柱，大家都非常熟悉：語言、方法和工具。這里，我們介紹的ARCADIA，同時提供了一種建模語言和一種建模方法。

圖1: 基于ARCADIA/Capella的MBSE三大支柱

ARCADIA建模方法

ARCADIA（架構分析和設計集成方法）是一種基于模型的系統、硬件和軟件架構設計工程方法。由Thales公司于2005年至2010年期間開發，該方法經過了一個迭代過程，涉及Thales公司所有業務領域（交通、航空電子、航天、雷達等）的運行架構。

根據IEEE 1220標準，它實施了一種基于連續工程階段的方法，明確分離了需求（運行需求分析和系統需求分析）和解決方案（邏輯架構和物理架構）。

ARCADIA建議開展三項具有同等重要性的強制性相關活動：

• 需求分析和建模
• 架構構建和驗證
• 需求工程

圖2: ARCADIA方法中的三種相互關聯的活動

該方法的步驟和活動已經被準確地定義，并在Thales內部的實際項目中進行了多年的測試。簡而言之，主要信息如下：

• 除需求工程外，驅動操作需求分析，描述最終用戶期望、使用條件和實際的IVVQ（Integration, Validation, Verification, Qualification）條件，以及系統需求分析，描述正在研究的系統的請求行為及其外部接口；

• 通過尋找設計驅動因素和非功能約束之間的最佳折衷，構建系統并構建邏輯架構。每個觀點都涉及一個特定的關注點，例如功能一致性、接口、性能、實時性、安全性、安全性、集成、重用、成本、風險、進度和易適應性；

• 通過處理技術和開發問題的物理架構確保開發和IVVQ的安全，有利于分離關注點、效率和安全的組件的交互。

ARCADIA方法把系統工程活動分成多個工程層級：運行分析層、系統分析層、邏輯架構層、物理架構層和最終產品分解結構層，如圖3所示。

圖3: ARCADIA 工程層級活動

• 運行分析是ARCADIA方法中的最高層級工程活動，主要定義“系統的用戶需要完成什么”。主要活動是識別與系統交互的參與者，參與者的活動和活動間的交互關系，來分析操作用戶的需要和需求問題。

• 系統分析是ARCADIA方法中的第二層級工程活動，主要定義“系統必須為用戶完成什么”。主要活動是開展系統外部功能分析，包括在非功能性屬性的限制下，識別用戶需要的系統功能（如“計算最佳路徑”，“檢測威脅”）。

• 邏輯架構是ARCADIA方法中的第三層級工程活動，主要定義“系統如何工作才能滿足客戶期望”。主要活動是內部系統功能分析，包括必須執行哪些子功能，并將這些子功能進行組合，來滿足上一層級中確定的用戶需要的系統功能。以及考慮非功能性約束下，識別出邏輯組件來執行這些內部子功能。

• 物理架構是ARCADIA方法中的第四層級工程活動，主要定義“系統將如何開發和建造”。物理架構層級的目標和邏輯架構層級是一致的，主要目的是定義系統內部如何工作才能滿足客戶期望，但除此之外，該層級還定義將要建造的系統最終物理架構。它增加了實施和某些技術選擇所需的功能，并突出執行這些功能的行為組件（如軟件組件）。進一步地，這些行為組件由實施組件（如處理器板卡）來實現，實施組件為行為組件實現提供必要的材料資源。

• 最終產品分解結構（EPBS）和集成合同是ARCADIA方法中的最低層級工程活動，主要定義“期望從每個組件的提供者得到什么”。該層級的流程活動從物理架構層級導出每個組件必須要滿足的條件，以滿足在前幾個層級中建立的架構設計約束和限制。

ARCADIA特定領域建模語言

ARCADIA DSML是ARCADIA Domain Specific Modeling Language的簡稱，是Thales公司開發的特定領域建模語言。ARCADIA DSML主要是受到UML、SysML和NAF標準啟發，基于功能分析和將功能分配給組件的思想，為了方便不熟悉軟件領域術語的系統工程師使用的一種特定領域建模語言。

ARCADIA DSML定義了多種不同的視圖，豐富程度和SysML相當，主要視圖有：數據流圖（Data Flow diagrams）、架構視圖（Architecture diagrams）、場景圖（Scenario diagrams）、模式與狀態圖（Mode and State diagrams）、分解視圖（Breakdown diagrams）、類圖（Class diagrams）、能力視圖（Capability diagrams）等DSML視圖。

數據流圖（Data Flow diagrams）

數據流圖在ARCADIA方法中定義的多個工程層級都有應用，它用于表達功能間的依賴信息。數據流圖為管理復雜性提供了一組不同的機制：簡化高層級功能間的連接，定義交換類別等。

圖4 系統頂層數據流圖示例

架構視圖（Architecture diagrams）

架構視圖可以應用在 ARCADIA 方法中定義的各個工程層級，主要目的是展示功能分配給組件的過程。功能鏈可以在視圖中高亮顯示，展示功能傳遞路徑。在運行架構層級，這些視圖用于展示業務需要和用戶活動等。

圖5 運行層級架構視圖示例

在系統架構層級，這些視圖用于展示系統功能等。

圖6 系統層級架構視圖示例

在邏輯架構層級，這些視圖用于展示系統的組成元素。

圖7 邏輯層級架構視圖示例

在物理架構層級，這些視圖用于展示行為組件在節點組件上的部署。

圖8 物理層級架構視圖示例

場景圖（Scenario diagrams）

場景圖用于展示元素（“生命線”）間傳遞消息的豎直順序，類似于UML/SysML的順序圖。“生命線”表示參與相關場景的模型元素的存在，它的名稱是引用的模型元素的名稱，并用一條豎直虛線以圖形方式表示。場景圖中的消息代表觸發接收器的行為，表示“生命線”之間的單向通信。

圖9 系統層級交換場景視圖示例

模式與狀態圖（Mode and State diagrams）

模式與狀態圖是受UML/SysML啟發而發明的一種狀態機的圖形化表達視圖。

圖10 模式與狀態圖示例

分解視圖（Breakdown diagrams）

分解視圖用于表示各個工程層級中的功能或組件的層級結構。

圖11 邏輯層級組件分解視圖LCBD示例

類圖（Class diagrams）

ARCADIA DSML定義的類圖類似于UML的類圖，用于對數據結構進行建模，并將其連接到功能交換、組件或功能端口和接口等。

圖12 類圖示例

能力視圖（Capability diagrams）

能力視圖用于表示任務、能力和參與者之間的關系，可以應用在各個工程階段，但在運行分析和系統分析階段應用較多。

圖13 系統層級中的能力視圖示例

實現ARCADIA方法的工具——Capella

Capella不僅僅是一個建模工具，它是一個基于模型的工程解決方案，已經成功地部署在各種各樣的工業環境中。基于圖形建模工作臺，它為系統、軟件和硬件架構師提供了豐富的方法論指導，依賴于基于模型的綜合工程方法ARCADIA：

• 通過共享相同的參考體系結構，確保工程范圍內的協作
• 掌握系統和架構的復雜性
• 通過權衡分析定義最佳架構
• 通過自動轉換和信息細化，掌握不同的工程級別和可追溯性

Capella基于Eclipse的工具平臺，不僅提供了特定領域建模語言，還提供了一個工具集。

Capella一個非常有吸引力的特征是內嵌了一個MBSE方法的瀏覽器，為用戶提供ARCADIA的基本原則和方法指引。這個活動瀏覽器提供了Capella中關鍵活動的方法入口，可以幫助用戶逐層地創建主要的視圖，對初學者和高級用戶都非常有價值。

圖14 Capella內嵌MBSE方法導航

由于元素的圖形化表達在溝通中扮演重要的角色，Capella提供了一致的顏色組合 。特別是所有的功能相關的元素都是綠色，組件相關的元素都是藍色。這個有利于增強所有的利益攸關者（包括架構師、VV參與者、專業工程師、項目經理等）對模型的可讀性。

圖15 Capella語義顏色圖

Capella另一個非常有用的特征是通過一個背景語義瀏覽器，提供了對模型中的元素（獨立于圖）進行導航的能力。比標準的模型層級結構視圖更具實操性的是，語義瀏覽器可以通過語義查詢實時提供模型元素的應用背景。這是一種在模型和圖之間進行導航的非常有價值的方式，可以快速分析模型元素之間的關聯關系。

圖16 Capella語義瀏覽器

由于Capella完全融合了ARCADIA方法，它可以提供傳統建模工具所不及的功能。比如，Capella可以在給定的工程層級上檢查當前層級的模型元素是否被下一層級所實現。Capella將模型檢查的規則分為以下幾類：完整性、設計、一致性、追溯性等。架構師可以根據不同的方面定義確認概要。因此，在任何時候都可以提供需要修改的問題以及自動的解決方案。

圖17 模型檢查功能

Capella的另一個先進特征是能夠創建可復用的模型元素，可以是類型或類的簡單對象，也可以是一個具有端口、功能的完整物理組件。一個可復制的元素集合（REC）就是個可以在多個背景或模型中被復用的元素的定義，一個復制品（RPL）就是一個REC的實例化。REC可以作為外部庫被打包，并在多個項目之間共享。

圖18 可復用的模型元素

為了拓寬視野，Capella并不孤立地工作，相反，它適合更廣泛的工程景觀，因為許多橋梁可以發展成：

• 從上游工程輸出（通常來自NAF等架構框架）初始化Capella模型；
• 將架構模型與專業工程工具（性能、安全等）對抗；
• 迭代填充下游工程（子系統、代碼生成等）。

圖19 Capella“大圖像”

SysML與ARCADIA/Capella的比較

如前所述，ARCADIA DSML受到UML/SysML和NAF標準的啟發，并與這些語言共享許多概念。但是，為了方便所有利益攸關者的使用，特別是通常不熟悉通用語言（UML或SysML）的利益攸關者，最好使用特定領域的建模語言。之前在Thales內部的實驗證明，不是來自軟件的系統工程師對UML（以及之后的SysML）提出的面向對象概念不放心。因此，ARCADIA主要基于功能分析，然后將功能分配給組件。事實證明，DSML的詞匯表很容易被系統工程師理解。

所以，基本上，ARCADIA是首先從Thales實際工程中遇到的工程問題所定義。然后，需要一個軟件工具來創建和管理ARCADIA模型。第一個實驗是使用現有的UML工具完成的，比如Rational Software Modeler、Objecteering和Rhapsody，并在它們上面定義UML文件。在這些第一次嘗試時，商業工具根本不容易定制，特別是很難刪除未使用的命令或菜單。因此，Thales決定創建自己的工具，專門用于ARCADIA。ARCADIA定義實際上可以看作是Capella建模工具的規范。

如果我們試圖與另一種可能的解決方案進行比較，即使用標準建模語言（如SysML）和現有的商業工具（如Rhapsody），我們可以發現幾個重要的區別。SysML和Rhapsody（作為其他的商業SysML工具）是基于UML的，這對于那些沒有接觸到面向對象概念的系統工程師來說是一個缺點，這些面向對象的起源顯然是不熟悉軟件開發世界的系統工程師采用的障礙。

另一個大問題是，SysML只是一種語言，每個公司都需要制定一個適應的建模策略。但是，如何將該方法傳授給建模工具呢？每一個商業工具都聲稱它提供了一個API來構建特定的附加組件，但這顯然代表了大量的工作。IBM提供了一個帶有Harmony for SE工具包的原型，但在泰雷茲的實驗證明，這個工具包僅僅是一個概念證明，很難在實際項目中使用。例如，建模階段之間的自動轉換并不像Capella那樣是迭代和增量的，而僅僅是一次。

圖20 MBSE三大支柱的實現比較

結論：

基于ARCADIA方法的Capella工具自2008年開發后，目前已廣泛應用于全球多個領域的項目（國防、航空航天、航天、交通、身份和安全等）。為復雜系統的設計和分析，提供高效、便捷、完整的架構定義支持。

文章來源Teamcenter黑帶