MBSE架构设计分析方法和工具：使用ARCADIA方法和Capella工具的MBSE

---

基于模型的系统工程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黑带