近些年，基于模型的系统工程（ Model-based Systems Engineering, MBSE）的概念，已在制造业逐渐普及，许多MBSE项目也在航空航天和国防、汽车、医疗和运输等行业实施及开展。MBSE的核心是模型在执行系统工程的所有活动中的正规化应用，以解决复杂系统的需求、设计、验证等挑战。

为了充分发挥 MBSE的作用，必须具备专门用于建模的系统工程方法论，包括适当的流程、方法和工具。系统建模语言（System Modeling Language, SysML）一直是许多企业MBSE项目的关键推动力量，SysML能够通过从各种视角，展示系统的不同视图。但采用SysML实现MBSE的过程并不轻松，常见的障碍包括：

• SysML基于的是软件工程特性，对于不具备软件工程背景的、跨行业的工程师难于掌握。使用SysML开发一个系统架构模型，对许多人来说仍然很有挑战。
• SysML缺少模型结构元素和行为元素之间适当的集成，易导致不一致性，从而增加系统开发的复杂度。

针对上述问题，架构分析和设计集成方法（ Architecture Analysis and Design Integrated Approach, ARCADIA）方法应运而生。它是一种以系统架构为中心、以基于模型的工程活动为基础的系统和软件架构工程方法。而Capella/系统建模工作台（System Modeling Workbench, SMW）是基于ARCADIA方法的系统架构建模工具。ARCADIA方法深受SysML的启发，旨在简化和丰富SysML。如果应用得当，ARCADIA方法可以有效地开发系统架构模型，解决传统SysML应用所面临的挑战。

一、架构定义: ARCADIA/Capella vs.SysML

1. 利益攸关者（Stakeholders）需求分析

从利益攸关者需要转换来的需求，通常在需求库中管理。 ARCADIA和SysML方法之间的主要区别之一是，ARCADIA侧重于功能驱动的建模，而SysML通常使用需求驱动的建模。

ARCADIA方法

由于采用功能驱动的建模方法， ARCADIA侧重对功能及其接口建模，并将需求与功能联系起来。当使用 系统建模工作台（ system modeling workbench, SMW），即将Capella工具集成到Teamcenter这样的集成PLM环境中 时，创建的需求规范可以从同一用户界面中直接链接到Capella的建模工件。或者，可以在SMW中创建新的需求，也可以从ReqIF（需求交换格式）标准的外部需求管理库中导入。导入方法灵活、易操作。

图1. 系统建模工作台（SMW）中的需求管理

运行分析（ Operational Analysis, OA）

在 ARCADIA方法的四个层级中，第一层级是运行分析（OA）。运行分析是为了捕获系统用户希望通过系统完成什么任务，此时不考虑系统本身，只关注用户想做什么。由于利益攸关者的需求通常不足以充分描述最终用户的期望、工作背景、条件和约束等完整信息。因此，运行分析放在功能分析之前或与功能分析并行开展。

这需要系统架构师对所需的高层级运行能力进行建模，并在不定义系统的情况下更好地分析运行需求。这样做，有助于了解用户真正想要什么，然后决定最佳的系统可能是什么，识别利益攸关者的面临的挑战，了解系统将如何 更好地 支持他们或提供解决方案。

TOGAF、DODAF和NAF等架构框架，高度支持运行需求分析。然而，大多数与SysML相关的架构构建模方法，都是从“ 黑盒系统 ”开始的。因此，ARCADIA的运行分析，允许找到备选方案来定义所感兴趣的系统实际上可能是什么， 对于开发创新产品极有价值 。

该阶段的主要步骤包括：

· 定义运行参与者和实体

· 定义运行能力

· 描述运行活动和能力场景

· 定义运行模式和状态

· 将活动分配给运行参与者和实体

定义运行参与者和实体

在系统的生命周期中，系统将在运行期间与各种参与者和实体交互。因此，必须确定可能与系统交互的所有运行实体和参与者，以便更好地理解问题并确定系统的运行需求。

图2. 运行实体分解

定义运行能力

运行能力是一个或多个运行实体为完成一个或多个任务所需的能力。运行能力细化了运行需求，可以由一个运行参与者和一个运行实体执行的若干运行活动来描述。运行场景表示参与者和实体之间活动的顺序，以便及时描述特定的能力场景。

与 SysML不同的是，Capella/SMW没有提供一个特定的图对需求建模，但是需求可以显示在任何图中，就像图3的运行能力图（OCB）中显示的需求一样。通过使用Capella/SMW中的需求附件，需求也可以链接起来创建各种关系。这样做是因为ARCADIA是一种功能驱动的方法，不同的功能元素允许有效地体现需求，而对需求建模的关注并不重要。

在自适应巡航控制系统（ ACC）中，我们可能已经知道系统所期望的能力是“保持目标车辆的速度”和“保持与领先车辆的恒定差距”。然而，在决定开发ACC之前，可以考虑高层级的运行能力，例如“在高速公路上行驶时提供帮助”，以便探索类似自适应巡航控制的备选方案。基于此，可以定义系统行为的系统级任务和能力。

图3. 在SMW中使用集成的Teamcenter环境进行需求跟踪

描述运行活动和能力场景

一种运行能力可以用多种运行场景来描述。运行场景用于定义每个参与者和实体在场景中要执行的活动及其交互顺序。或者，可以通过运行活动交互图（ OAIB）来描述能力，以表示特定能力的交互，而不暂时考虑给参与者和实体分配。

图4. 运行活动交互

定义运行模式和状态

运行实体或参与者可以具有各种状态和模式，这些状态和模式可以由模式和状态机图（ MSM）来描述。Capella/SMW提供不同的模型元素的模式和状态，来表示模式和状态，而在SysML中，只能使用状态元素对状态或模式进行建模。

在 ACC的示例中，车辆系统充当ACC系统的参与者，因为它将考虑“驱动”和“人机界面”功能，而“传感”和“决策”功能将由ACC系统执行。这是因为系统架构师仅从ACC架构师的角色出发。同时，车辆架构师可能负责为整车及其负责执行ACC运行的子系统开发系统架构。

图5. 车辆系统状态图

将活动分配给运行参与者和实体

运行分析阶段的主要输出之一是描述预期系统运行架构的运行架构图（ OAB）。在图6中，对驾驶员、车辆系统及其实体和环境进行建模，其中包括主要参与者和将发生相互作用以实现预期目标的实体，并对其各自的活动进行了定义和分配。

运行分析的目的是从用户的角度理解用户的需求。把用户需要转化为需求，由需求工程师 /系统工程师团队验证，在分析过程中定义特定目标并识别新的需求。需求库中更新了以前记录的需求。同样，新确定的需求将被创建，以进入下一阶段的需求分析。

SysML方法

在进行系统架构设计之前，任何 SysML方法的一个重要部分就是使用SysML中包（Package）的结构来组织模型。建模项目需要以打包的形式来组织，以便使模型一致、可读并保持对模型基线的控制。而ARCADIA方法没有这个步骤，是因为Capella/SMW工具自带了方法论指导，所以在Capella/SMW中，模型的组织是以一致的方式自动完成的。

在 SysML中，对利益攸关者需求分析的主要步骤是：

· 定义运行领域

· 识别系统上下文

· 定义任务 /系统用例

· 细化利益攸关者的需求，并链接到模型工件

使用 SysML建模，是一种基于需求的系统架构方法。因此，需求被认为是SysML规范的关键工件。SysML提供了一个称为需求图（req）的专用图来建模需求及其关系。一些SysML工具提供需求导入选项，从外部需求库工具和电子表格导入需求。这些需求在SysML中被转换成需求对象，并可以在所需的图中使用。需要注意的是，SysML可用性受用户使用的工具的影响。来自不同供应商的许多不同工具根据其对语言、api的自定义而提供的功能各不相同，并非所有工具都提供了需求导入特性和其他类似特性。SysML需求可以链接到SysML中的其他模型元素，这样就可以在跨图的SysML模型中实现可跟踪性。

定义运行领域

在用用例（ Use case）定义系统功能之前，可以使用块定义图（bdd）识别系统的运行领域。图7显示了“运行领域”框图，其中可能在整个系统生命周期中与系统交互的运行参与者被建模为块（block）。

图7. 运行领域bdd

识别系统上下文

系统外部上下文定义了系统边界以及与开发中的系统交互的所有系统参与者。建模系统上下文图和运行领域图的选择完全取决于用户和所遵循的方法。系统上下文在 SysML中使用块定义图（bdd）定义，如图8所示，其中感兴趣的系统及其直接环境中的实体和参与者由块表示，参与者由块或参与者元素（这里表示为块）表示。而Capella/SMW为运行参与者的 表示 提供了一个参与者元素，运行活动可以分配给这些参与者。

图8. 系统上下文bdd

定义任务 /系统用例

图 9显示了SysML中的需求图（req）和一个链接到类似于Capella/SMW的典型用例的需求。SysML运行用例可以用类似的方式定义。在本文的自适应巡航控制的例子中，已经为系统定义了系统用例，以优化利益攸关者的需求。

图9. SysML需求图和链接到用例的需求

这里要注意的一个重要区别是语言规范中的模型元素用例。用例图（ uc）用于描述系统的用法。它表示通过系统（主体）及其参与者（环境）之间的交互来实现目标功能的高层级描述。用例用于定义系统或任务提供的高层级功能或能力，以细化利益攸关者和系统需求。虽然可以在SysML中进行运行分析，但通常在SysML中定义系统的运行上下文，同时将感兴趣的系统视为黑盒实体，并且确定了系统边界。这与ARCADIA方法的运行分析不完全一致，因为在ARCADIA的运行分析中没有考虑系统边界。此外，在进行运行分析时，运行用例是使用相同的用例元素来定义的，而Capella/SMW提供了一个称为能力（Capacity）的单独模型元素来对系统级能力建模，以清楚区分抽象的运行层级和系统层级。

细化利益攸关者的需求，并链接到模型工件

最后，定义和细化利益攸关者需求，并将其链接到必要的模型工件，以确保各层级之间的可追溯性。

2. 系统需求规范/分析

如前所述，系统需求分析阶段是在分析和细化系统需求。但是， ARCADIA方法建议在系统分析阶段识别系统上下文背景。因此，为了与该方法保持一致，在这里讨论系统上下文的标识。

ARCADIA方法

系统分析（ System Analysis, SA）

运行分析的目的是定义系统对用户需求的预期贡献，系统分析阶段的目标是定义系统必须完成什么才能满足用户需求。在这个阶段，系统有了边界，但仍被认为是一个黑盒。这一阶段 /层级的主要活动是：

· 能力权衡分析

· 功能性和非功能性需求分析

· 系统需求的正规化和综合表达

系统分析的主要步骤是：

· 定义系统上下文背景

· 定义系统能力并通过功能优化系统行为

· 将功能分配给系统和参与者

· 定义系统级运行模式或状态

· 定义系统场景

· 定义系统需求

定义系统上下文

此时，可以创建一个系统上下文图来理解系统边界和与系统交互的外部参与者。这提供了基本信息，有助于确定嵌入系统环境（系统功能）时从系统请求的服务，而不提供这些服务的技术细节。确定不同的系统参与者可以在系统的不同利益相关者之间进行非常有效的沟通。图 10显示了表示系统运行上下文的系统参与者（CSA）图。这个图可以被认为与图8中SysML中的系统上下文bdd图是同一类图。

图10. 系统背景CSA

定义系统功能并通过功能优化系统行为

图 11显示了ACC系统的系统功能。考虑“保持距离和控制速度”的系统能力。在Capella/SMW中，系统能力通过描述系统功能及其特性的系统数据流图来阐述提供能力所需的交换。

图11. ACC系统能力

在识别系统功能时，可以描述这些系统功能的数据流。 Capella/SMW提供了各种模型加速器，支持建模者通过模型元素的自动转换来减少建模时间。其中一个加速器是运行活动到系统功能的转换。由于这种转换，一种能力可以由一组现有的功能来定义，这些功能的数据流继承了运行活动及其交互的关系。通过在Capella/SMW类图中创建交换项和数据类型，可以很容易地将不同类型的交换项分配给功能交换和功能接口。此外，运行参与者和实体可以转换为系统参与者。此时，系统功能（运行活动）可以分解并分配给新创建的系统及其参与者。如果需要，可以根据系统功能分解确定新的参与者。

图12. 保持距离和控制速度功能数据流

图 12显示了执行“保持距离和控制速度”功能所需的全局/顶层功能。系统级功能分为外部参与者执行的参与者功能（蓝色）和系统功能（绿色）。在系统数据流图中，系统级功能必须被分解，因为它们部分地分配给了系统。例如，在图13（a）中，运行参与者“驾驶员”执行的活动“控制ACC”与“车辆系统”执行的“保持距离”活动相互作用。然而，在系统分析阶段，引入了ACC系统，它将继承“保持距离”功能。理想情况下，驾驶员和ACC系统之间没有交互，因为驾驶员-车辆接口将接收驾驶员输入并向ACC系统发送命令。因此，在图13（b）中，“控制ACC”功能将被分解为两个功能，即“控制ACC”和“监控驾驶员输入”，两者实现相同的运行活动。“控制ACC”（控制附件）功能的输出现在将从“保持距离”移到“监控驾驶员输入”，后者现在分配给“转向控制”执行器，“监控驾驶员输入”的输出将流到“保持距离”。此外，“控制ACC”功能被分解为几个子功能，接口直接分配给子功能。

图13. 运行级到系统级的功能分解

将功能分配给系统和参与者

一旦确定了所有系统级功能，这些功能就被分配给系统和外部参与者，以生成具有分配功能的系统架构视图。系统架构师可能更喜欢对系统级状态和功能场景进行建模，以便在创建系统架构图之前更好地理解系统行为。图 14显示了ACC系统的系统级架构图（SAB）。

图14. 系统层架构图SAB

在 Capella/SMW的系统架构图中，可以将系统功能分配给系统参与者和系统。将功能分配给参与者之后，功能交换会自动发生。Capella/SMW可生成图表的简化视图、上下文视图，以及图表克隆特性。在功能分配之后，在ARCADIA的每个层级，分配给两个行为组件的两个功能之间的功能交换必须分配给这两个组件之间的单个组件交换。这个组件交换将引用它所实现的所有功能交换。为了简单起见，可以隐藏功能以获得仅显示组件的架构视图。此外，也可以隐藏子功能，只显示父功能，如图14，SAB中所示的“控制 ACC”父功能。

Capella还提供了一种通过分组功能列表来创建功能链的能力，以表示全局数据流中的一组路径。参与者之间的交换场景可以在场景图中描述，以显示他们交互的顺序。

定义系统场景

图 15显示了“启动ACC”场景，显示了系统和参与者之间的交换。场景可以调用“子场景”，中间模式和状态也可以在这些图中显示。

图15. 交换场景

定义系统层级运行模式和状态

与运行层级的状态类似，可以使用模式和状态机图对系统的预期行为进行建模，特别是当系统必须以设定的顺序对来自参与者的事件作出反应时。 ARCADIA提出了两个概念：状态和模式。状态（或模式）通过过渡连接在一起。图16显示了ACC系统的各种状态。建立系统状态是一个迭代过程，通常与场景相结合来描述复杂的系统场景。

图16. ACC系统状态

这些流程共同构成了系统级功能分析。在这些步骤中，基于不同的场景、运行状态和模式，识别各种系统功能及其交互。最后，在需求库中修改或新建系统功能和接口需求，这些需求可能是 Capella/SMW本地的，也可能是外部的。

定义系统需求

需求规范流程也可以发生在流程之间，最终的需求验证在需求评审结束时完成。

SysML方法

大多数 SysML方法中的系统需求分析阶段非常相似。此阶段的目标是分析先前收集的系统输入，并从描述问题转移到形成抽象解决方案。与ARCADIA类似，这个阶段是将系统的需求指定为一个黑盒，包括输入和输出行为以及其他外部可观察的特性。对系统场景进行建模，以描述系统如何使用活动图或序列图，与其外部参与者进行交互。使用运行领域的内部框图对系统上下文图进行建模，以定义系统和外部参与者之间的接口。识别影响有效性度量（MOE）的关键系统特性，在此基础上，从功能、接口、存储和性能方面规定了系统需求。定义系统状态以指定系统必须基于所有场景中的运行执行的综合行为。

这一阶段的主要步骤包括：

· 定义任务 /系统场景

· 使用内部框图定义系统上下文

· 规定系统功能和接口要求

· 识别和定义系统级状态

定义任务 /系统场景

在这一步中，为参与者定义一个或多个场景，以提供指定系统行为需求的基础。图 17显示了使用SysML序列图（sd）的“启动ACC”场景的场景描述。

图17. 启动ACC序列图

与 Capella/SMW不同，SysML序列图不允许在时间线上表示系统功能。而且，没有任何类似Capella/SMW中的功能交换场景的序列图。但是，可以使用SysML活动图来描述涉及参与者及其功能交换的场景。

活动场景

SysML活动图用于使用动作和活动定义系统基于“流”的行为。活动交换可以由两种类型定义：允许指令从一个动作的输出传递到另一个动作的输入的对象流，以及提供额外约束的控制流，这些约束限制了活动将在何时以及以何种顺序执行。图18显示了代表参与者和系统的泳道图，泳道图中的活动显示了参与者和系统执行的功能。这就是SysML中结构和行为的关联方式。在SysML中，系统功能也可以用块来表示。SysML中的功能树被捕获为块的层级结构，数据流被表示为内部框图。Capella/SMW目前不提供功能之间的控制流，因为它认为控制流应该与数据流分开，并且不应该使用相同的端口作为描述方式。

图18. “保持距离和控制速度”活动描述

定义系统上下文

系统上下文如图 19所示，在内部框图中用于描述系统及其与外部系统和用户的外部接口。在Capella/SMW中也可以使用上下文外部接口（CEI）图获得类似的表示。然而，ARCADIA中的系统架构精确地捕捉了系统及其参与者之间的接口细节。另一个需要注意的区别是，在每个抽象层次上，用于建模系统结构的图是块定义图和内部框图。系统参与者“车辆系统”在此阶段可以特别分解为其子系统，如果尚未在运行领域中定义，因为这些子系统也将充当系统的参与者。接口的定义通过定义接口的行为，或通过使用描述接口之间交换信息的接口块键入接口来详细说明。关键性能需求和设计约束可以作为系统黑盒的值属性或接口中的流来捕获。还要分析满足需求的其他关键属性在SysML参数图中捕获。

图19. 系统外部接口说明-黑盒

定义系统状态

预期状态是使用状态机图建模的，如图 20所示。而Capella/SMW继承并改进了SysML状态机图的表示，在状态和模式之间有了更清晰的区分。每个场景的活动图定义了系统必须执行的动作。状态机指定系统何时执行特定动作。

图20. ACC状态机图

指定“黑盒”需求

需求分析结果将应用在基于场景分析和其他行为分析的系统黑盒规范中。黑盒规范定义了系统的外部可观察的行为和物理特性。系统需求以所需的功能、外部接口、性能和质量特征、控制和系统必须存储的项的形式被捕获。需求通常使用 SysML需求图（req）创建，并直接链接到相关的模型元素。无论如何，需求总是可以导出为所需的格式。

3. 逻辑架构定义

逻辑架构设计和定义的目的在于，基于已识别的系统功能创建系统架构的抽象表示，为后面在物理架构阶段进行的组件和技术选择提供基线。换句话说，这个阶段的目标是捕获解决方案的主要架构驱动因素，确定高层级组件及其预期功能，提供系统如何工作的愿景，而不必过多地关注技术细节。

ARCADIA方法

逻辑架构（ Logical Architecture, LA）

逻辑架构定义是从问题域转移到解决方案域的阶段。运行分析（ OA）和系统分析（SA）阶段有助于更好地了解用户和系统需求，逻辑架构（LA）和物理架构（PA）阶段有助于找到抽象和具体的解决方案来满足这些需求。

为定义逻辑架构而开展的主要活动如下：

· 定义影响架构的因素并分析视角；

· 定义系统行为的原理；

· 构建基于组件的系统结构备选方案；

· 选择提供最佳权衡方案的架构备选方案。

这一阶段的主要步骤是：

· 定义逻辑组件

· 逻辑功能分解

· 定义逻辑组件场景和状态

· 为组件分配逻辑功能

定义逻辑组件

系统的逻辑组件是根据分配给系统的功能来标识的。获得最终逻辑架构可以采用多种方式，如：

1. 将系统功能细化为解决方案功能，然后将这些功能分组为组件，以保持自动跟踪；

2. 定义面向解决方案的逻辑功能分解，在此基础上在系统和逻辑功能之间创建手动跟踪；

3. 将系统功能分配给逻辑组件，然后将功能细化为解决方案功能。

系统数据流图（ SDFB）中标识的系统功能必须分配给各种逻辑组件，这些逻辑组件将满足系统功能的逻辑功能实现以及功能交换的实现。转换是为简化建模任务而开发的工具。也可以选择创建手动跟踪，并通过模型验证来检查跟踪的完整性。与系统功能分析类似，逻辑功能分析使用逻辑数据流图来识别系统的各种逻辑级功能。根据逻辑功能定义逻辑架构，然后进行功能分配。例如，在图21中，“保持距离”和“保持速度”功能分配给系统组件“ACC控制器”，而“定位目标”功能分配给“传感器”。这样，所有系统逻辑功能都分配给所有标识的逻辑组件。

图21. 功能分配到逻辑组件

逻辑功能分解

确定了逻辑功能，就可以进行功能分解以确定内部组件功能。功能分解将产生可以执行的多个子功能。例如，“定位目标”功能可以分解为两个功能，即“定位摄像机对象”和“定位雷达对象”，因为可以使用多个传感器来定位目标。基于此，可以识别出两个新的逻辑组件，即“摄像机”和“雷达”。图 22显示了在Capella/SMW中完成的功能分解。

图22. 逻辑功能分解

定义逻辑组件场景和状态

基于系统场景，可以对逻辑场景进行建模，以显示功能和逻辑组件之间的顺序交换。同样，这三种场景主要是功能、交换和接口，可以在逻辑层进行建模。场景的目的主要是细化在 SA视图中创建的场景，并理解其行为。系统状态和模式基本保持不变，但对状态和模式的功能分配及过渡条件至关重要。

图23. 具有分配功能的逻辑架构

为组件分配逻辑功能

Capella/SMW逻辑架构提供了逻辑架构视图（LAB）来表示对组件的分配。此外，分配特性可以使用简单的拖放来执行。功能之间的交换可以很容易地分配给定义接口的组件交换。允许在同一图表中同时显示功能交换和组件交换、功能接口和组件接口之间的分配等，允许根据功能内容调整组件接口。此外，使用Capella/SMW中的各种图表显示了组件和功能的简化视图和上下文视图。

SysML方法

SysML中的逻辑架构定义包括使用结构图将系统分解为逻辑组件。使用序列图（sd）创建逻辑场景，以描述逻辑组件如何交互，从而使用活动图和序列图实现系统块的每个动作。内部框图描述了组件之间的互连。然后将逻辑组件进一步分解为子组件，并且可以再次将父组件指定为黑盒，如前一步骤中所述。

这一阶段的主要步骤是：

· 识别逻辑组件

· 使用活动定义逻辑组件交互

· 分解要执行的活动

· 定义组件之间的逻辑接口

识别逻辑组件

在 SysML中，在使用内部框图（ibd）定义接口之前，逻辑组件标识在块定义图（bdd）中完成。或者，可以将新的内部组件添加到内部框图中。SysML bdd自动继承分解。系统组件和逻辑组件之间的可追溯性也会自动维护。SysML提供了定制特性，这样就可以创建原型（stereotype）来区分系统黑盒、逻辑和物理级元素。图24显示了使用块定义图的逻辑分解，其中系统逻辑组件由原型<<logical>>指定，但是SysML块仍然是相同的模型元素。

图24. 逻辑组件bdd

定义逻辑组件交互

与 Capella/SMW不同的是，SysML不允许使用相同的结构图显示组件功能交互，除非功能到块的非常规映射已经完成。使用活动图（act）创建一个单独的场景来显示逻辑组件的功能分配。图25显示了逻辑组件交互的活动图。可以添加新的泳道图来表示组件，并将动作分配给各个组件，以保持动作之间的交换。

图25. 逻辑组件功能交互

分解要执行的活动

功能分解不能在同一个视图中完成。 SysML允许使用接口委托的概念进行活动分解。子功能不能显示在父功能的包含中，并且会创建一个新的活动图来表示子功能的交换。图26显示了在单独的活动图中创建的“定位目标”的功能分解。

图26. SysML中的功能分解

定义组件之间的逻辑接口

最后，可以使用内部框图（ ibd）显示系统的内部组件，以显示互连。图27显示了ACC系统的内部逻辑结构。与系统级黑盒类似，系统内部接口的定义将产生新的接口需求规范。SysML活动图之间的信息流可以映射到内部框图。当为一个特定系统的数百个接口建模时，接口管理会变得很棘手。在逻辑架构定义之后，每个逻辑组件的指定与在黑盒级完成的系统需求规范类似。如果逻辑组件状态机具有依赖于输入事件和条件的基于状态的行为，则会创建逻辑组件状态机。

图27. 系统内部接口描述

4. 物理架构定义

物理架构定义的目的是，开发一个由技术相关的物理组件或实现逻辑组件功能所需的部分组成的架构。

ARCADIA方法

物理架构（ Physical Architecture, PA）

物理架构定义是两个解决方案定义阶段中的第二个阶段。这一阶段的主要活动是：

· 定义架构和行为的结构原理；

· 详细说明并最终确定预期的系统行为，

· 建立和合理化一个或多个可能的系统架构；

· 选择、完成并验证保留的系统架构。

与逻辑架构阶段类似，系统的物理组件基于分配给系统组件的逻辑功能进行标识。 Capella/SMW通过使用两个元素来提供物理组件的概念：行为组件，负责执行移交给系统的一些功能；托管（节点）物理组件，负责托管多个行为组件，并为它们提供运行所需的资源。行为或节点组件可以是硬件或软件。节点组件使用物理链接进行关联，以指定两个组件之间的通信方式，以支持行为交换。

这一阶段的主要步骤（不一定按固定顺序）是：

· 定义节点物理组件以支持行为组件

· 将物理组件的行为分配给节点组件

· 将行为组件分配给节点组件并定义物理接口

· 将物理 /创建功能分配给行为组件，并在必要时确定子功能

定义节点物理组件

这一步的重点是定义节点物理组件，以定义一个或多个反映结构化的解决方案。节点组件在物理架构视图（ PAB）中创建。节点物理组件本身通过物理链路连接，反映了行为组件（例如有线网络、卫星链路、管道或机械轴）之间通道交换的介质。组件交换分配给组件之间的各个物理链路。

行为组件分配

Capella/SMW从逻辑组件转换，自动实现行为物理组件。物理组件的行为是在逻辑组件的基础上定义的。构建行为组件的方法与LA中构建系统的方法非常类似。一个节点组件可能包含一个或多个行为组件，但是，默认情况下，一个行为组件只能分配给一个节点组件（用户可以禁用此默认选项）。例如，当用户希望在同一个模型中为多个部署建模时，这非常有用。在最终确定行为之前，使用场景、状态和模式等进行动态行为分配，有可能细化需求并分配到所涉及的组件。行为组件之间的组件交换是从SA定义或实现的，功能交换是分配给它们的。

物理功能分配

最后，将物理功能分配给行为组件。架构评估可以在 ARCADIA中进行，通过向模型元素添加约束和执行特定视角分析来完成。

图 28显示了“ACC控制器”的行为组件，其中隐藏了功能、组件和物理交换。“ACC控制器单元”节点组件由实现三个物理功能的“ACC控制器软件”行为组件组成。

图28. 节点物理组件（黄色）、行为物理组件（蓝色）和物理功能（绿色）

显示组件交换和组件之间物理链接的物理架构如图 29所示.

图29. 物理架构图PAB

终端产品分解结构（ End-Product Breakdown Structure, EPBS）

ARCADIA还提供了EPBS层级，旨在使用物理架构来推断每个组件必须满足的条件，以满足前面阶段中确定的设计约束和架构选择。它有助于定义“每个组件的提供者期望得到什么”。

SysML方法

SysML中的物理架构阶段类似于逻辑架构阶段。同样，该阶段的主要目标是获得一个物理架构，该架构包含将满足逻辑架构中定义的内部功能的部件或组件，使用为组件所做的特定于技术的选择。

物理架构定义阶段的主要步骤是：

· 定义物理架构组件

· 开发和完善系统组件接口和交互

· 为组件分配逻辑功能

· 定义多个架构视图

· 更新组件需求

· 执行系统设计评审

定义物理架构组件

可以使用块定义图对系统物理组件进行类似于逻辑组件的建模。为了区别于逻辑组件，物理组件是用 <<physical>>或<<part>>等原型定制的。可以在SysML中创建一个节点组件分区，允许跨系统节点分发功能。可以在SysML模型中进行类似的分区，其中创建系统的节点逻辑架构在整个系统中部署逻辑功能，然后定义相应的节点物理架构。面向对象的系统工程方法（ OOSEM ）中创建了一个专用的SysML概要文件来支持这种方法。图30显示了bdd的物理结构。通过使用原型，可以在bdd中区分系统<<hardware>>和<<software>>组件。

图30. 物理结构bdd

定义系统内部接口

为了补充 bdd中的系统结构，创建了内部框图来定义系统内部组件之间的接口。同样，使用各种SysML构造的信息流来详细说明接口。可以为由重要内部组件组成的不同系统组件创建各种内部视图，以避免单个图表过于复杂。图31显示了ACC系统的内部接口图。

图31. 物理内部结构

分配功能到组件

使用活动图或功能分配矩阵将逻辑系统功能分配给系统组件。可以为某些组件定义组件场景，这些组件需要进行重大改进，以解决特定的问题，并充分指定相关需求。活动交互场景可以显示为使用泳道图的最低层级功能，泳道图上的物理组件分配到泳道。物理层的序列图是从上一层细化而来的，并且创建了多条可以表示系统组件的时间线。因此，系统物理行为最终确定，需求得到细化。

定义多个架构视图

基于组件的原型，可以在 SysML中定义各种架构视图。例如，创建软件架构视图，使用方框定义图和内部方框图来显示所有系统软件组件及其相互关系。类似地，可以定义硬件架构视图来表示硬件组件及其相互关系。可以创建数据架构视图来显示物理架构的视图，以表示持久数据、数据的使用方式以及数据的存储位置。可以使用活动图定义运行流程，以详细说明特定流程的内部和外部参与者之间的交互。

指定组件需求 &架构评估

最后，基于各种组件架构视图，在模型中定义组件需求并将其链接到 SysML工件。利用SysML参数图（par）可以从安全性、可靠性、成本和性能等角度对系统架构进行评估。

二、 ARCADIA/Capella与SysML方法的主要区别

1. Capella/SMW中各层级视图之间的自动转换

Capella/SMW提供了使用四种不同建模视角的功能，这些视角具有不同的目标，并指导建模工程师使用。Capella/SMW有一个便捷功能，这就是不同视图的元素之间可以自动转换。例如，运行活动可以在SA中转换为系统功能，然后在LA中实现为逻辑功能，随后在PA中实现为物理功能。这在这些组件之间创建了自动实现链接，从而在不同抽象级别之间创建了自动跟踪。功能、组件、参与者和实体、状态、交换项和数据类型等元素也可以转换。图32显示了应用于“保持距离”运行活动到物理功能的转换。

图32. 功能转换

2. “系统-子系统”转换

Capella/SMW提供系统到子系统的转换。允许将每个子系统的建模委托给不同的团队或组织。架构模型中的子系统可以转换为逻辑或物理组件，这些转换将根据需要在SA阶段或LA阶段产生新的系统组件。子系统可以作为Capella/SMW的新项目导出，也可以作为同一项目的一部分（前提是子系统转换已经应用过一次），这样新形成的子系统的接口在任何情况下都与总体系统保持一致。

图33. 系统到子系统的转换（摄像机）

图 33显示了应用于“摄像机”逻辑组件的系统到子系统的转换。新“摄像机”项目的系统架构（SAB）继承了作为系统功能的组件功能、其交换和来自总体系统的外部参与者。这样，领域工程师可以分别对其子系统建模，而不必导航到全局系统模型。系统到子系统转换的好处之一是，系统和子系统的利益攸关者能够以不同的速度工作，并且管理不同的模型；每个利益攸关者只管理对自己有意义的信息级别，子系统利益攸关者在集成来自系统的更新时可选择信息级别，等等。

3. 功能分解

功能分解是 ARCADIA和SysML的主要区别之一。如前一节所述，可以使用SysML活动图将功能建模为动作/活动，或者将其建模为数据流表示为内部框图的块层次结构。

Capella/SMW和SysML的功能分解有本质的不同。在Capella/SMW中，子功能可以在同一视图中显示为其所属功能中的包含，而在SysML中，活动分解是使用单独的活动图完成的，这样两个级别之间的子功能只能通过其所属块委派的接口进行通信。

例如，在图 34（a）中，“保持距离”功能被分解为单独活动图中的两个子功能，通过委托接口管理数据流，而图34（b）显示了在Capella/SMW中完成的功能分解。Capella/SMW只允许功能数据流通过子功能。

图34. 功能分解

4. 实例驱动的建模

Capella/SMW和SysML建模的另一个主要区别是Capella/SMW中实例驱动建模的本质，而不是SysML中的类型驱动建模。SysML内部框图使用部件属性的概念来建模系统的内部部件和接口。但是，这些部分必须由在块定义图中创建的块定义来键入。定义组件的块是“类型”，实例化类型的部分是其“实例”或“用法”。但系统工程师不像软件工程师那样习惯于首先考虑类型，然后再实例化它们。Capella/SMW则是基于实例建模，其中创建的每个零件都是组件的新实例。如果一个零件需要重用， Capella/SMW提供了可复制元素集合（REC）和副本（RPL）的概念。

例如，考虑一个摄像系统，它有两个具有不同像素等级的相机组件。 SysML对此建模的方法是在SysML中创建一个块，并通过Camera块在内部框图中键入部分。Capella/SMW对此建模的方法是首先创建两个摄像头组件，然后自动创建对用户隐藏的部分。如果需要重用一个模型元素或一组元素，可以创建一个REC，该REC可以在给定的上下文中实例化为RPL。当键入不同的元素（如功能、端口等）时，而SysML中类型和实例的概念变得太复杂。

5. 功能链和场景

Capella/SMW提供了一种通过分组功能列表来创建功能链的能力，这些功能表示全局数据流中的一组路径。功能链特别用于描述给定上下文中系统的预期行为，因此也用于试验验证/确认（V&V）测试。功能链还经常用于表示功能路径中的非功能约束，如延迟、关键性、机密性、冗余等。功能链可以在数据流图中表示，也可以在所有视图中表示架构。还可以使用功能场景图来描述功能链，以显示使用生命线的功能之间的顺序交互。图35（a）显示了一个功能链（以蓝色突出显示），图35（b）显示了为“启动ACC”过程执行的功能交换的功能场景图。

图35. 功能链和场景

三、总结

通过初步比较 ARCADIA/Capella和SysML的架构开发方法。可以发现，ARCADIA/Capella拓宽了MBSE的范围，并确保系统建模活动不会与产品开发的其他部分隔离，还可通过与PLM主干集成（System Modeling Workbench, SMW）实现数字线索（Digital Thread）在产品生命周期早期阶段的实现。

ARCADIA是一种基于功能分析的方法，它关注架构的定义和验证。同时，ARCADIA简化了结构和行为之间的集成。从可用性的角度，Capella/SMW提供了一些便捷功能，如自动转换、功能链、用于模型共享的系统到子系统转换以及模型检查功能，另外， Capella/SMW 提供了基于实例的建模，简化了在模型中创建冗余部件的任务。这些都有助于系统建模效率的提升。

目前， Capella/SMW 在“V”模型的验证方面似乎面临挑战。SysML工具提供了为需求验证生成RVTM（需求验证跟踪矩阵）的能力。使用Capella/SMW无法演示这种能力。尽管RVTM已经成为系统工程从业者的一个方便工具，但是Capella/SMW自动化转换和功能链能够填补这一空白，这就要求人们逐渐改变对验证方法和工具的看法。另外，与SysML不同，Capella/SMW不支持功能之间的控制流。根据来自Thales的信息，Capella/SMW的开发人员正研究在ARCADIA的功能链中添加的控制行为。另外，ARCADIA也没有像SysML那样包含参数分析，根据Thales的说法，这是不必要的，如果需要的话，也很容易开发。但是，Capella/SMW提供了一种约束建模和创建特定视角的能力。

最后，必须认识到， ARCADIA/Capella关注于工程和架构定义，而不是架构探索；而SysML的范围超出了架构定义，包括架构探索和方案权衡。总的来说，Capella/SMW有望成为模型驱 动工程的完整解决方案，而不仅仅是一个架构建模者，其成熟度和开源性还有很大的提升和完善空间。