MagicGrid 知识手册(三)
1 方案域
1.1 简介
一旦完成问题域分析并将利益相关者的需求转移到模型中,就该开始考虑解决方案了。 解决方案架构定义了系统逻辑设计的精确模型,甚至是它的几个变体。 换句话说,这一抽象层为第一层抽象中定义的问题提供了一个或多个解决方案(包括黑盒和白盒的观点)。 有几种解决方案,可以进行权衡分析以选择最佳的解决方案来实现系统。
应该注意的是,问题域可以由一个组织指定,而解决方案架构可以由另一个组织指定。 此外,不同的组织可以提供不同的解决方案。

正如您在下表中看到的,构建解决方案架构包括指定设计中系统的需求、行为、结构和参数(不再是感兴趣的系统!)。 此外,构建解决方案架构的任务通常包括不止一次迭代,从系统级到子系统级,从子系统级到组件级架构,甚至更深,如果有需要的话。系统架构模型的精度取决于迭代次数。

1.2 部署方案域
解决方案架构可以在单个模型中指定,甚至可以在与问题域定义相同的模型中指定。 然而,在大多数情况下,解决方案架构的范围和复杂性超过了问题域定义的范围和复杂性达数倍之多,尤其是当它包含多个解决方案时。 在两个或多个单独的模型中定义解决方案架构有助于管理复杂性。 此外,这种模型划分能够实现更细颗粒度的模型所有权、变更分析和控制、访问控制、并发修改和模型重用。 以下材料描述了跨多个模型部署解决方案架构的方法。 尽管这不是 MagicGrid 方法的一部分,但如果您觉得值得,欢迎您熟悉它并在您的组织中采用它。
如前所述,可以为同一个问题提供不止一种解决方案架构。为了解释我们的方法,我们介绍了三种解决方案架构的案例:Solution Domain 1,Solution Domain 2和Solution Domain 3。虽然Solution Domain 1和Solution Domain 2的内容被抑制,但您应该认为它们与Solution Domain 3的内容相似。高级解决方案架构 (High-Level Solution Architecture HLSA) 模型是每个解决方案架构的核心。基于问题域分析的结果,它在单层层次结构中定义了所设计系统的子系统。如下图所示,在这种情况下,共有三个子系统:Subsystem 1,Subsystem 2和Subsystem 3。HLSA 模型还指定了每个子系统的接口,以确定它们如何相互操作并集成到所有的。下图中不包括接口,以免造成混乱。 HLSA 模型的所有者是系统工程师(也称为系统架构师),他对设计中的系统有“大局观”。换句话说,系统工程师就像管弦乐队的指挥:他/她确保每个人同时演奏相同的旋律。
HLSA 模型中子系统的定义有助于识别工作包并将它们分配给不同的工程团队。每个团队为分配的子系统开发一个或多个解决方案架构。它们可能会并行工作。如下图所示,三个子系统中的每一个都定义了多个解决方案:Solution 1在顶部可见,其他的则隐藏在下方。 Subsystem 1和 Subsystem Design 1.1 之间的泛化关系(实线带空心三角形箭头)意味着从事 Subsystem 1 模型的Solution 1 的工程团队知道(或用SysML 语言——继承)设计约束(例如HLSA 模型中定义的子系统的接口),并且必须遵循它们。其他概括传达适当的信息。不同子系统的解决方案架构,甚至同一子系统的不同解决方案架构,都可能包含不同数量的组件。子系统的解决方案架构定义了该子系统的需求、行为、结构和参数。
在工程团队完成子系统的解决方案架构后,系统工程师可以将它们集成到一个模型中。 他/她选择每个子系统中的首选,构建整个系统的集成解决方案架构。 实际上,可以提出不止一种解决方案。 如下图所示,我们称它们为System Configuration 1,System Configuration 2等。就像每个子系统的解决方案架构一样,设计中的整个系统的集成解决方案架构定义了行为、结构和参数,并且必须满足系统要求规范。
拥有正在设计的系统的完整模型,系统工程师可以进行权衡分析并选择最佳系统配置; 拥有多个解决方案架构的最佳系统配置,系统工程师可以首先选择最佳解决方案。下图中的权衡(Trade Off)分析说明了这一点。
值得一提的是,不仅可以在解决方案架构之间进行权衡,还可以在解决方案架构的每个颗粒度级别进行权衡。

1.2.1 S1.系统需求:initial
它是什么?
为了能够设计系统架构,您首先需要拥有系统需求规范才能遵循它。从黑盒和白盒的角度分析问题域的结果应该为您提供生成系统需求规范的输入。系统需求源自利益相关者的需求,它们还细化了单元格 B2-B4 和 W2-W4 中捕获的元素。
该单元中的建模包括两个阶段:initial阶段和final阶段。在initial阶段,捕获系统需求并建立以下可追溯关系:
- 从系统需求到利益相关者需求——明确哪个系统需求源自哪个利益相关者需求。
- 从系统需求到问题域模型的其余部分——明确哪些元素是由哪些系统需求改善的。
完成单元格 S2、S3.initial、S3.final 和 S4 中描述的系统架构后,您应该回到系统需求并建立从系统设计元素到系统需求的满足关系,以便明确哪个前者满足哪个后者。这是该单元中建模的final阶段。
建模和设置追溯关系的规则同样适用于子系统需求、组件需求,甚至更深层次的结构。 就像系统需求源自利益相关者需求一样,子系统需求也应该源自系统需求,组件需求源自子系统需求,等等。就像系统需求由系统设计元素满足一样,子系统需求应该由子系统设计元素满足,组件需求由组件设计元素满足,等等。
谁是负责的人?
在典型的多学科系统工程团队中,系统需求由需求团队指定。
如何建模?
在建模工具中,一项系统需求规范可以存储为 SysML 需求,它具有唯一的标识、名称和文本规范。 每个系统需求都必须涵盖特定的利益相关者需求。 为此,您可以使用从系统需求指向利益相关者需求的 «deriveReqt»(继承需求) 关系。此外,每个系统需求都必须从问题域模型中改善一个或多个元素。 为此,您可以使用从系统需求指向某个模块、活动或效能分析的 «refine» 关系,仅举几例。
与利益相关者需求的文本规范相反,系统需求的需求必须是正式的,并按照一定的指导方针写下来;例如,只写短而清晰的句子,避免使用条件关键字,如 if、except、as well;使用 shall 关键字;并包括表格。有关如何编写良好的文本需求的更多信息,请参阅 INCOSE 系统工程手册。
系统需求可以组织成一个或多个层次结构级别。 为此,请使用它们之间的包含关系。 引用系统需求规范的 SysML 需求必须位于层次结构的顶部。 它可能没有文字。
SysML 需求表或图表可以帮助可视化系统需求的层次结构。 它们也可以包含在需求报告中。 我们建议使用图表或表格来显示系统需求的层次结构(参见下面第一张图),并使用另一个图表或矩阵来建立和可视化各种可追溯性关系;例如,系统需求和利益相关者需求之间的推导(见下面第二张图)。


下一步是什么?
有了系统需求规范后,就可以开始构建系统架构了;也就是说,移动到 S3.initial。
Tutorial
Step 1. 为 S1.intial创建和梳理模型
要为指定系统要求做好准备,您需要事先建立适当的模型结构。按照 MagicGrid 框架的设计,捕获系统需求的模型工件应存储在下图中显示的包结构下。可以看到,上层包代表域,下层包代表单元。

然而,在实际项目中,将方案域模型与问题域模型分开是很常见的。 按照这种做法,我们建议在另一个模型(文件)中指定车辆气候控制系统(Vehicle Climate Control System VCCS) 的解决方案架构,通常称为设计中的系统。 问题域模型的内容应该在该模型中可用,因为问题域分析的结果应该作为系统需求规范的基础。就建模工具而言,问题域模型应该用在方案域模型中。为此,我们利用了建模工具的相关功能。
为 S1.initial创建和梳理模型:
1. 开始共享问题域模型。
注:有关此主题以及step 2和3中提及的主题的更多信息,请参阅您的建模工具的最新文档。
2. 创建一个新模型(文件)。它可以命名为 VehicleCCS_Solution.mdzip。
3. 在方案域模型中以只读方式使用问题域模型。这是系统的方案域模型。

注:灰色的名称表示元素不能被修改。 这是因为问题域模型在方案域模型中以只读方式使用。
4. 右键单击Model包(这是根包的默认名称)并选择Create Element。
5. 在搜索框中,输入 pa,即元素类型 Package 的前两个字母,然后按 Enter。
6. 键入2 Solution Domain以指定新包的名称,然后按 Enter。
7. 右键单击2 Solution Domain包并选择Create Element。
8. 重复step 5。
9. 键入 1 System Requirements 以指定新包的名称,然后按 Enter。

Step 2. 为系统需求创建图表
对于捕获和显示系统需求,我们建议使用 SysML 需求图或表格。在tutorial of the B1-W1.initial phase中介绍了使用表格,使用图描述如下。
创建用于指定系统要求的 SysML 需求图:
1. 右键单击 1 System Requirements 包并选择 Create Diagram。
2. 在搜索框中,输入rd,其中 r 代表需求,d代表图,然后双击 Enter。图已创建。
注:请注意,图以存储它的包命名。此名称也适用于图。您只需从其名称中删除序列号。

Step 3. 指定系统需求
Vehicle Climate Control Unit的白盒分析揭示了以下系统要求:

捕获模型中的系统需求:
1. 打开System Requirements图(如果尚未打开)。
2. 单击图面板上的 Requirement 按钮,然后单击图窗口上的空白部分。创建了一个空需求。
3. 直接在图块上键入上表中第一个需求的名称,然后按 Enter。
4. 重复单击图块上的 Text 属性值。属性切换到编辑模式。
5. 键入表中第一个需求的文本。
6. 完成后单击图块外部的某个位置。
7. 重复step 2到6以获取其余需求。
完成后,系统需求图的内容应该与下图非常相似。

此外,您需要一个分组需求来表示整个需求规范。step 4 of the B1-W1 initial phase tutorial描述了创建分组需求的最简单方法。按照程序创建分组需求VCC System Requirements Specification。
在系统需求图中显示需求层次结构:
1. 将需求 VCC System Requirements Specification 拖到该图窗口中。
2. 右键单击该需求的图块并选择Display > Display Paths。 需求之间的包含关系显示在图窗口上。
3. 在图工具栏(位于图窗口顶部)上,单击Quick Diagram Layout(快速图表布局)按钮。
为了将系统需求与利益相关者需求和组件需求区分开来,我们建议为它们的编号添加前缀。按照step 5 of the B1-W1 initial phase tutorial中描述的过程,将前缀 SR- 添加到您的系统需求中。随后,这些系统需求可以重构为更具体的需求。例如,Manual Temperature Control需求可以成为功能性需求,Total Mass需求是物理的,Sound Level需求是性能需求之一。为此,请按照step 6 of the B1-W1 initial phase tutorial中描述的程序进行操作。完成编号和分类后,系统需求图的内容应该与下图中的内容非常相似。

Step 4. 建立对利益相关者需求的可追溯性
从系统需求到利益相关者需求的可追溯性关系可以在 SysML 需求图或相关矩阵中建立。我们建议使用大规模的相关矩阵,因为它提供了比图更紧凑的模型视图。
在这种情况下,您需要断言哪些系统需求(更具体)源自利益相关者的需求(更通用),即建立派生关系,或者就 SysML 而言,它们之间的«deriveReqt»关系。因此,我们建议使用派生需求矩阵的基础设施,这是建模工具中预定义的相关矩阵之一。与常见的相关矩阵相反,它具有预定义的某些条件以加快构建视图的速度。
创建派生需求矩阵:
1. 在Model Browser中,右键单击 1 System Requirements 包并选择 Create Diagram。
2. 在搜索框中,键入预定义Derive Requirement Matrix的首字母缩写词 drm,然后按 Enter。
注:如果您没有看到任何结果,请单击搜索结果列表下方的Expert按钮。可用图表列表在Expert模式下展开。
3. 键入 System Requirements to Stakeholder Needs 指定新矩阵的名称并再次按 Enter。
4. 在Model Browser中,选择 1 System Requirements 包并将其拖到矩阵内容上方 Criteria 区域中的 Row Scope 框中。 1 System Requirements 包成为矩阵行的范围。
5. 在Model Browser中,选择 1 Stakeholder Needs 包(为此,您可能需要先展开 1 Problem Domain 和 1 Black Box 包)并将其拖到矩阵内容上方 Criteria 区域中的 Column Scope 框中。 1 Stakeholder Needs 包成为矩阵列的范围。
6. 单击Direction框并选择Row to Column,因为您需要建立从系统需求(行元素)到利益相关者需求(列元素)的派生关系。
7. 单击Criteria区域下方通知框中的Refresh超链接。更新矩阵的内容。目前所有的单元格都是空的。
下图显示了矩阵的 Criteria 区域,突出显示了step 4、5和6相关条件。

现在您已准备好建立派生关系。让我们在SR-1.1 Automatic Temperature Control和 SN-1.1 Setting Temperature之间创建一个,以传达前者源自后者,或者换句话说,该系统需需求是由利益相关者的需求而创建的。
指定矩阵中的派生关系:
1. 双击显示SR-1.2 Manual Temperature Control的行和显示SN-1.1 Setting Temperature的列交叉处的单元格。派生关系在适当的项目之间创建并显示在单元格中。

建立所有派生关系后,您的系统需求与利益相关者需求矩阵应类似于下图中的矩阵。 在理想情况下,每个系统需求都必须源自一个或多个利益相关者需求,并且每个利益相关者需求都必须由一个或多个系统需求覆盖。否则,必须修改和更新系统需求规范。

Step 5. 建立对问题域模型其余部分的可追溯性
从系统需求到问题域模型的其余部分的可追溯性关系可以在 SysML 需求图或相关矩阵中建立。我们建议使用大规模的相关矩阵,因为它提供了比图更紧凑的模型视图。
在这种情况下,您需要断言哪些问题域元素是由哪些系统需求改善的;也就是说,在它们之间建立改善或«refine»关系。因此,我们建议使用 Refine Requirement Matrix 的基础架构,它是建模工具中预定义的相关矩阵之一。与常见的相关矩阵相反,它具有预定义的某些条件以加快构建视图的速度。
假设您希望将捕获系统结构和接口的模块、捕获系统功能的活动以及捕获系统可计算特征的效能分析显示为列,而系统需求显示为矩阵的行。
创建改善需求矩阵:
1. 在Model Browser中,右键单击 1 System Requirements 包并选择 Create Diagram。
2. 在搜索框中,键入 rrm,这是预定义的 Refine Requirement Matrix 的首字母缩写词,然后按 Enter。
注:如果您没有看到任何结果,请单击搜索结果列表下方的Expert按钮。可用图表列表在专家模式下展开。
3. 键入 System Requirements to Problem Domain 以指定新矩阵的名称,然后再次按 Enter。
4. 在矩阵工具栏上,单击Change Axes按钮以将矩阵的行与列交换。需求成为矩阵行的类型。
5. 在Model Browser中,选择 1 System Requirements 包并将其拖到矩阵内容上方 Criteria 区域中的 Row Scope 框中。1 System Requirements 包成为矩阵行的范围。
6. 在Model Browser中,选择具有 «moe» 元类型的任何模块、活动和值属性,然后将选择拖到矩阵内容上方 Criteria 区域中的 Column Element Type 框。具有 «moe» 元类型的模块、活动和值属性成为矩阵列的类型。
注:要在结构树中选择一组不相邻的项目,请单击第一个项目,按 Ctrl,然后在按住它的同时逐个选择其他项目。这也适用于step 7。
7. 在Model Browser中,选择 4 Measurements of Effectiveness 包(为此,您可能需要先展开 1 Problem Domain 和 1 Black Box 包)和 2 White Box 包,然后将所选内容拖到矩阵内容上方 Criteria 区域中的 Column Scope 框上。这两个包都成为矩阵列的范围。
8. 单击Direction框并选择Row to Column,因为您需要建立从系统需求(即行元素)指向捕获问题域概念的工件(显示为列元素)的改善关系。
9. 单击Criteria区域下方通知框中的Refresh超链接。矩阵的内容被更新。目前所有的单元格都是空的。
下图显示了矩阵的Criteria区域,其中突出显示了step 5、6、7和8相关条件。

现在您已准备好建立改善关系。让我们在SR-1.6 Total Mass物理系统需求和Total Mass MoE之间创建一个,以明确前者改善了后者,或者换句话说,创建此系统需求是为了改善该 MoE。
指定矩阵中的改善关系:
1. 双击显示 SR-1.6 Total Mass 的行和显示 Total Mass 的列的交叉处的单元格。在适当的项目之间创建改善关系并显示在单元格中。

建立所有改善关系后,您的系统需求到问题域矩阵应类似于下图中的矩阵。在理想情况下,每个系统需求都必须改善问题域模型中捕获的一个或多个元素,并且每个元素都必须由一个或多个系统需求改善。否则,必须修改和更新系统需求规范。

1.2.2 S3.系统结构:initial
它是什么?
系统需求规范完成后,就可以开始构建所设计系统的解决方案架构了。通常它从捕获系统的 HLSA 开始。 HLSA 模型将设计中的系统的所有子系统指定为单级层次结构。 HLSA 模型还指定了接口,以确定这些子系统如何相互操作并集成到整体中。方案域的子系统可能与问题域中标识的子系统不同。这种情况经常发生,因为问题域定义不如解决方案架构精确。 为了在问题域模型中从解决方案架构的子系统追踪到逻辑架构的子系统,可以建立整合关系。 S3 单元中的第一阶段建模到此结束。
在 HLSA 模型中定义子系统有助于识别工作包并将它们分配给单独的工程团队。每个团队为分配的子系统开发一个或多个解决方案架构。它们可能会并行工作。在 SS3 和 SS2 单元中描述了单个子系统的解决方案架构的建模。
在工程团队完成子系统的解决方案架构后,系统工程师可以将它们集成到一个模型中。 事实上,可以提出不止一种解决方案;因此,系统工程师进行权衡研究以选择每个子系统中的首选,并构建整个系统的集成解决方案架构。这是 S3 单元中建模的第二阶段。
谁是负责的人?
在典型的多学科系统工程团队中,HLSA 模型的所有者是系统工程师(也称为系统架构师),即架构团队的负责人。系统工程师是对设计中的系统有“大局观”的人,负责将子系统顺利集成到整体中。
如何建模?
正如已经提到的,HLSA 是一个单级层次结构,它捕获正在设计的系统、其下一层的子系统以及确定这些子系统如何互操作的接口。可以在 SysML 模块定义图中创建和显示 HLSA 模型。可以将子系统捕获为模块,并将接口作为代理端口输入适当的接口模块。
在下图中,您可以看到车辆气候控制系统 (Vehicle Climate Control System VCCS) 的示例 HLSA 模型,其中显示了子系统模块:Cooling、Heating、Control、Sensors和 UI。它还显示Cooling System的接口。虽然没有显示其他子系统的接口,但我们假设它们也已定义。

下一步是什么?
- 有了逻辑子系统,您就可以开始研究他们的解决方案架构模型;因此,是时候转移到 SS3 单元了。
Tutorial
Step 1. 为 S3.initial梳理模型
您可以在step 1 of the S1 initial phase tutorial中创建的方案域模型中捕获 HLSA 模型。要为构建 HLSA 模型做好准备,您需要事先建立适当的模型结构。按照 MagicGrid 框架的设计,捕获系统 HLSA 的模型工件应存储在下图中显示的包结构下。

为 S3 梳理模型:
1. 打开您在step 1 of the S1 initial phase tutorial中创建的方案域模型(VehicleCCS_Solution.mdzip 文件)(如果尚未打开)。
2. 右键单击2 Solution Domain包并选择Create Element。
3. 在搜索框中,输入 pa,即元素类型 Package 的前两个字母,然后按 Enter。
4. 键入 3 System Structure 以指定新包的名称,然后按 Enter。
为了保持 3 System Structure 包的内部结构井井有条,您需要创建更多的包。它们是:
- 1 Interfaces
- 2 Exchange Items
- 3 Subsystems
当您自己创建它们时(按照前面的过程),您的方案域模型的Model Browser应该如下图所示。

Step 2. 创建用于捕获 HLSA 的 bdd图
要准备捕获 VCCS 的高级解决方案架构,您需要先创建一个 bdd。
创建用于捕获 VCCS 的 HLSA 的 bdd:
1. 右键单击 3 System Structure 包并选择 Create Diagram。
2. 在搜索框中,键入 bdd(SysML 块定义图的首字母缩写词),然后按 Enter。图已创建。
3. 键入 High-Level Solution Architecture 以指定新图的名称并再次按 Enter。
Step 3. 在 HLSA 中捕获子系统
假设系统需求规范显示 VCCS 包括:
- Cooling System
- Heating System
- Control System
- Sensors System
- UI System
可以将子系统捕获为您在上一步中创建的 bdd 中的模块。如前所述,HLSA 是一个单级层次结构。每个子系统的详细设计应随后由独立的工程团队在独立模型(文件)中执行。
捕获 HLSA 正在设计的系统的子系统:
1. 打开High-Level Solution Architecture图(如果尚未打开)。
2. 捕获设计中的系统:
a. 单击图面板上的Block按钮,然后单击图窗口。
b. 键入 VCCS 为模块命名,然后按 Enter。
3. 捕获子系统:
a. 单击 VCCS 模块的智能操纵器工具栏上的 Direct Composition 按钮,然后单击图窗口上的空白处。
b. 键入 Cooling System 以命名模块,然后按 Enter。
c. 重复step 3.a和3.b 以捕获上面列表中的其他子系统。
4. 在图工具栏上,单击快速图表布局(Quick Diagram Layout)按钮。

5. 在Model Browser中,选择子系统的所有模块并将它们拖到您在step 1 of the S3 initial phase tutorial中创建的 3 Subsystems 包中。这些模块被移动到 3 Subsystems 包。

Step 4. 建立对 W3 的可追溯性
可追溯性关系使您能够指定逻辑架构(问题域)中的哪些子系统决定在 HLSA 中创建哪些子系统。在这种情况下,我们使用«abstraction» 关系从方案域跟踪到问题域。
要准备好建立这些关系,首先您需要创建一个单独的 bdd 图并在其窗口中显示来自两个域的结构模块。该图应存储在 3 System Structure 包下并命名,例如,HLSA to Logical Architecture。假设您已经自己创建了该 bdd。在建立整合关系之前,您应该在图窗口上显示您需要链接的模块。
在HLSA to Logical Architecture图上显示模块:
1. 在Model Browser中,按以下顺序展开包的内容:1 Problem Domain > 2 White Box >3 Logical Architecture > 2 Logical Subsystems。
2. 选择 3 Logical Architecture 包中的 Climate Control Unit 模块和 2 Logical Subsystems 包中的所有模块:
a. 单击 Control System 模块(2 Logical Subsystems 包中的第一项)。
b. 按住Shift 并单击 UI System 模块(2 Logical Subsystems 包中的最后一项)。
c. 按住Ctrl 并单击Climate Control Unit 模块。

3. 将所选内容拖动到图窗口上。所选模块的图块显示在图上。
4. 右键单击这些图块并选择Display > Display Paths。
5. 确认您只想显示选定符号之间的路径。直接构图关系的路径显示在图块之间。
6. 单击图窗口上的空白区域以取消选择图块。
7. 在图工具栏上,单击快速图布局按钮。

8. 在 Model Browser 中,选择 3 Subsystems 包中的所有模块(您可能需要展开以下包的内容:2 Solution Domain > 3 System Structure > 3 Subsystems)
9. 执行step 3到6以在图上显示所选模块的图块和它们之间的路径。
10. 排列图块,使图的布局类似于下图中的布局。
注:您可以手动执行此操作,也可以使用调整命令执行此操作。单击图工具栏上调整(Adjust)按钮附近的箭头后,这些命令可用。

注:您可以使您的图表包含更多信息通过添加
- 图例(Diagram legend),有助于在视觉上区分来自不同域的概念。
- 水平分隔符(Horizontal separator),有助于分隔这些域。
有关如何使用这些功能的更多信息,请参阅建模工具的最新文档。
现在您已准备好建立抽象关系。让我们首先在捕获Control System的两个模块之间创建一个。
指定抽象关系:
1. 单击图面板上的 Abstraction 按钮。
2. 从方案域中选择Cooling System模块的图块(蓝色的),然后单击问题域中的Cooling System模块之一(浅橙色的)。这两个模块之间建立了«abstraction»关系。

创建所有抽象关系后,您的HLSA to Logical Architecture图应该非常类似于下图。请注意,Control System在方案域中已分为两个:Sensors System和Control System。这就是为什么捕获这些子系统的模块与问题域模型中的同一子系统相关。

Step 5. 在 HLSA 捕获接口
假设系统需求规范确定了Cooling System的以下接口:
- iElectricity
- iMechanical Power
- iControl
- iHeat
- iMoisture
这些接口派生自相应功能子系统的逻辑接口(参见 W3)。与step 3 of the W3 tutorial中确定的逻辑接口相比,HLSA 的接口更加精确。接口被捕获为在捕获子系统的模块上输入代理端口的接口模块。捕获单个接口的接口模块名称中的 i 前缀使您能够轻松地将捕获接口的接口模块与模型中的其他类型的模块区分开来。
要确定接口是接收子系统的输入还是从中产生输出,您应该为该接口指定至少一个流属性。
捕获Cooling System的接口:
1. 确保在High-Level Solution Architecture图中启用了Type Selection Mode。否则,代理端口的创建不会触发接口模块的创建以输入该代理端口。
2. 选择Cooling System模块的图块并在其智能操纵器上单击代理端口(Proxy Port)(参见下图)。一个新的代理端口出现在模块图块的边框上。

注:代理端口默认命名为 p1、p2、…、pn。没有必要重命名它们,因为它们在这个抽象级别中没有传达任何语义。
3. 在代理端口图块旁边的冒号 (“:”) 旁键入 iElectricity,然后按 Enter。
注:只有在图表中启用了Type Selection Mode(参见step 1)时,您才能执行此操作。
用于键入代理端口的新接口模块已创建并显示在Model Browser中,位于 3 Subsystems 包中,其中存储了Cooling System模块。
4. 在Model Browser中选择 iElectricity 接口模块并将其拖到图窗口中。接口模块的图块出现在图上。
5. 单击该图块上的创建元素按钮并选择Flow Property(流属性)。
6. 直接在接口模块的图块上,执行以下操作:
a. 移除流属性方向指示器的 out 部分以指定流属性的方向为 in。
b. 键入 DC(D 代表 Direct,C 代表 Current)以指定该流属性的名称。
c. Type :Electricity 指定流属性的类型,然后按 Enter。
结果,一个指向Cooling System模块内部的箭头出现在代理端口的图块上(见下图)。 这表明代理端口由只接收输入的接口模块输入。

7. 重复step 2到6以指定其他接口。从下图中了解您需要创建的接口模块和流属性。
注:如您所见,端口名称隐藏在图中。由于这些名称不传达重要信息,隐藏它们是提高图可读性的好习惯。要隐藏端口的名称,请在图窗口上右键单击其图块并取消选中Show Name复选框。如果要一次为所有端口设置此选项,请在按住Alt 键的同时选择任意端口的图块,然后继续执行与单个端口相同的操作。

注:如您所见,iHeat 接口模块输入了两个代理端口。它们之间的区别在于Cooling System模块左边界的一个用于将热空气引入Cooling System内部,而该模块右边界的一个用于将热空气排出到Cooling System甚至车辆的外部。后者是共轭的(conjugated)。要使代理端口共轭,请右键单击它并选择 Is Conjugated。

8. 在Model Browser中,在 3 Subsystems 包下,选择所有接口模块并将它们拖到您在step 1 of the S3 initial phase tutorial中创建的1 Interfaces 包中。接口模块被移动到 1 Interfaces 包中(参见step 9中的图)。
9. 在 Model Browser的 1 Interfaces 包下,选择所有输入接口模块的流属性的信号,并将它们拖到您在step 1 of the S3 initial phase tutorial中创建的 2 Exchange Items 包中。信号(signals)被移动到 2 Exchange Items 包中。

注:请注意,除控制信号外,所有交换项都已重构为模块。如果您以上述方式键入流属性,则建模工具默认创建信号,尽管某些交换项的性质意味着将它们定义为模块。这可以通过将信号重构为模块来轻松解决。只需选择要重构的所有信号,右键单击选中项,然后选择 Refactor > Convert To > Block。
在实际情况下,系统工程师还必须指定其他子系统的接口。他/她还可以创建一个ibd图来指定接口,以及这些子系统如何相互操作。
1.2.3 SS3.分系统结构
它是什么?
一旦系统工程师确定了设计中系统的子系统(在 HLSA 模型中)并将它们分配给单独的工程团队,这些团队就可以开始研究每个子系统的解决方案架构。构建子系统的解决方案架构可以从定义子系统的内部结构开始,并指定其部分如何协同工作,以及如何与子系统外部交互。
为了提供子系统的解决方案架构,负责的工程团队需要分析特定子系统的系统需求和问题域模型。如果有需要,也可以分解子系统结构的各个部分。这将是C3单元的关注点。
请注意,以下材料侧重于构建Cooling System的结构模型,这只是Vehicle Climate Control System的子系统之一。该材料还揭示了如何将解决方案集成到正在设计的系统的整体解决方案中(参见S3.final),尽管您应该想象,当您为Cooling System构建解决方案架构时,其他工程师/工程团队并行工作建立Heating System, Control System, Sensors System和UI System的结构模型。
谁是负责的人?
在典型的多学科系统工程团队中,所设计子系统的结构由架构团队的成员构建。虽然系统工程师(也称为系统架构师)是该团队的负责人,但对正在设计的系统拥有“全局视图”,而架构团队的其他成员(单独或成组,也称为工程组) 负责构建设计中不同子系统的结构。
如何建模?
在建模工具中,可以使用 SysML 模块定义图的基础结构来定义子系统的各个部分。 设计中的子系统和子系统的组件可以被捕获为模块,接口可以被捕获为接口模块块。为了指定设计中的子系统各部分如何协同工作以及如何与子系统外部交互,以及它们交换什么材料,可以使用 SysML 内部模块图的基础结构。下图以 SysML 内部模块图的形式展示了 Cooling System 不同部分的内部结构和相互作用。

下一步是什么?
一旦您完成了所设计子系统的结构,您就可以开始考虑并建模该子系统的行为。 因此,您可以移动到 S2/SS2 单元。
Tutorial
Step 1. 为 SS3 创建和梳理模型
在这一步中,我们为Cooling System创建一个单独的模型,它是 HLSA 模型中定义的 VCCS 的子系统之一。在实际情况下,这个模型应该交给被指定构建Cooling System解决方案架构的工程团队(而 VCCS 的其他子系统的解决方案架构应该由其他工程团队并行开发)。
VCCS 的方案域模型应用于Cooling System的方案域模型。这是必要的,因为假想工程组必须了解 VCCS 的系统需求和 HLSA 模型中定义的Cooling System接口(参见step 5 of the S3 initial phase tutorial)才能遵循它们。
为 SS3 创建和梳理模型:
1. 开始共享方案域模型。
注:有关此主题以及step 2和3中提及的主题的更多信息,请参阅您的建模工具的最新文档。
2. 创建一个新模型(file)。它可以命名为 Cooling System_Solution.mdzip。这是Cooling System的方案域模型。
3. 在Cooling System的方案域模型中,将设计中的整个系统的方案域模型用作read-only。 问题域模型也被自动使用。

注:灰色的名称表示元素不能被修改。这是因为问题域模型在方案域模型中以只读方式使用。
4. 右键单击Model包(这是根包的默认名称)并选择Create Element。
5. 在搜索框中,输入 pa,即元素类型 Package 的前两个字母,然后按 Enter。
6. 键入 2.1 Cooling System Solution Domain 以指定新包的名称,然后按 Enter(参见step 9 中的图)。
注:正在设计的其他子系统的软件包,例如Heating System和Sensors System等,其名称中应包括 2.2、2.3 等。
7. 右键单击2.1 Cooling System Solution Domain包并选择Create Element。
- 重复step 5。
9. 键入 3 System Structure 以指定新包的名称,然后按 Enter。

为了保持 3 System Structure 包的内部结构井井有条,您需要创建更多的包。它们是:
- 1 Interfaces
- 2 Exchange Items
- 3 Subsystems
当您自己创建它们时(按照前面的过程),您的方案域模型的Model Browser应该如下图所示。

Step 2. 准备建模Cooling System的结构
一旦创建了用于捕获Cooling System解决方案架构的模型,在将模型提供给指定的工程团队之前还需要做一件事。作为系统工程师,您必须在两个概念之间建立继承关系:HLSA模型中的Cooling System模块(作为超类型)和该子系统的方案域模型中表示相同子系统的一个概念(作为子类型)。继承使系统工程团队能够了解系统工程师在 HLSA 模型中确定的设计子系统的所有接口。
继承在模型中被捕获为上述模块之间的泛化关系。它可以通过利用 bdd 的基础结构来简单地创建。bdd可以在Cooling System的方案域模型中的3 System Structure 包下创建(在step 1 of the SS3 initial phase tutorial中创建)。
为Cooling System的结构建模做好准备:
1. 创建 bdd:
a. 右键单击 3 System Structure 包并选择 Create Diagram。
b. 在搜索框中,键入 bdd(SysML 模块定义图的首字母缩写词),然后按 Enter。图已创建。
c. 键入Cooling System Structure以指定新图的名称,然后再次按 Enter。
2. 在设计中创建子系统的模块:
a. 单击图面板上的Block按钮,然后单击图窗口。
b. 键入Cooling System Design以命名模块,然后按 Enter。
3. 在图上显示来自 HLSA 模型的Cooling System模块:
a. 在Model Browser中选择Cooling System模块。

b. 将选中项拖到图窗口中。Cooling System模块的图块在图上创建。
4. 在 Cooling System 模块(超类型)和 Cooling SystemDesign 模块(子类型)之间创建泛化关系:
a. 单击图面板上的 Generalization 按钮。
b. 选择Cooling System Design模块的图块。
c. 选择Cooling System模块的图块。

5. 在其图块上显示 Cooling System Design 模块的继承接口:
a. 在图窗口中选择Cooling System Design模块的图块。
b. 单击其智能操纵器工具栏上的显示所有端口(Display All Ports)按钮。

显示了继承的接口。插入符号 (“^”) 表示它们是继承的。
注:如您所见,端口名称隐藏在图中。由于这些名称不传达重要信息,隐藏它们是提高图表可读性的好习惯。要隐藏端口的名称,请在图窗口上右键单击其图块并取消选中Show Name复选框。如果要一次为所有端口设置此选项,请在按住 Alt 键的同时选择任何端口的图块,然后继续执行与单个端口相同的操作。

Step 3. 捕获Cooling System的组件
假设工程团队决定Cooling System应由以下部分组成:
- 蒸发器系统(Evaporator System)
- 压缩机系统(Compressor System)
- 冷凝器(Condenser)
- 接收器干燥器(Receiver Dryer)
请注意,Cooling System的某些组件的名称中包含关键字 System。这意味着它们有自己的组件,可以在 C3 单元格中指定。尽管我们使用在step 2 of the SS3 tutorial中创建的 bdd 图Cooling System Structure,但可以使用 bdd 或 ibd 捕获所有项目。当您需要表示组件之间的交互时,ibd 很有用。
捕获Cooling System的组件:
1. 如果尚未打开,请打开在step 2 of the SS3 tutorial中创建的Cooling System Structure bdd 图。
2. 选择 Cooling System Design 模块,单击其智能操纵器工具栏上的 Directed Composition 按钮(参见下图),然后单击图窗口上的空白空间。

在Model Browser中创建另一个模块,并在图窗口中选中其图块。
3. 直接在所选图块上键入Evaporator System以指定Cooling System的相应组件的名称,然后按 Enter。

4. 根据需要多次重复step 2和3,以创建Compressor System,Condenser和Receiver Dryer 模块。

5. 在Model Browser中,选择所有子系统/组件模块并将它们拖到您在step 1 of the S33 tutorial中创建的 3 Subsystems 包中。这些模块被移动到 3 Subsystems 包中。

请注意,directed composition(直接组合关联)表示一个模块在另一个模块中的使用。用法在模型中被捕获为封闭模块的part属性。例如,Cooling System Design模块是一个封闭模块,目前具有四个part属性,每个属性代表单个模块的使用,例如Condenser或Evaporator System。 就像在逻辑架构模型中一样(参见step 6 of the W3 tutorial),这些part属性不需要名称。但是,当需要传达组件在子系统上下文中的使用方式时,part属性可以具有名称。例如,当您要指定车辆具有一个左前轮和一个右前轮时,您需要在模型中定义 Front Wheel模块,然后在车辆上下文中创建由该模块输入的两个part属性。一个part属性可以命名为left,另一个命名为right。
Step 4. 创建用于指定交互的 ibd
虽然 bdd 最适合捕获组件,但当您需要指定这些组件之间的交互时,ibd 很有帮助。 这就是为什么我们需要为Cooling System Design模块创建一个 ibd。 要开始指定交互,您需要在该图中表示Cooling System的所有代理端口和直接使用的组件。它们都是使用Cooling System Structure bdd图捕获的。
创建用于指定Cooling System交互的 ibd图:
1. 在Cooling System Structure bdd图中,选择 Cooling System Design 模块并单击其智能操纵器工具栏上的 SysML Internal Block Diagram 按钮。

创建 ibd 并在其顶部打开 Display Parts/Ports 对话框。
2. 确保所有项目(代理端口和part属性!)都被选中,然后单击OK。对话框关闭,您可以看到:
- ibd 及其框架表示Cooling System的边界。
- 代表Cooling System接口的代理端口。
- 代表Cooling System所有直接组件的part属性。
3. 在Model Browser中,在编辑模式下自动选择新创建的图,键入Cooling System Components以指定其名称,然后再次按 Enter。

Step 5. 指定Cooling System与外部之间的相互作用
在这一步中,我们专注于指定Cooling System的子系统/组件与其外部之间的交互,即 VCCS 的其他子系统甚至车辆的其他系统。可以将交互指定为通过兼容的代理端口建立的连接器。通过连接器交换的信息、资源、消息等可以指定为流过这些连接器的项目。
假设工程团队确定了以下交互:
- Compressor System(压缩机系统)消耗电力和机械动力(来自整个车辆的其他系统,如发电机和发动机)并接受控制信号(来自车辆气候控制系统的控制系统)
- Evaporator System(蒸发器系统)从车厢吸收热量(实际上是通过冷却空气)
- Condenser System(冷凝器系统)向车辆外部提供热量(实际上是通过加热空气)
- Receiver Dryer(接收器干燥器)从冷却系统中去除与氟利昂分离的水分
指定压缩机系统从冷却系统外部消耗电力:
1. 在图框架上选择 p2 代理端口(由 iElectricity 接口模块输入),然后单击其智能操纵器工具栏上的连接器按钮。
2. 单击由 Compressor System 模块输入的part属性的图块。
3. 选择New Proxy Port。为part属性创建兼容的代理端口,并在图框架和选定的part属性之间建立连接器。

4. 在Model Browser中,展开以下只读包的内容:2 Solution Domain > 3 System Structure > 2 Exchange Items。
5. 选择 Electricity 模块(参见下图)并将其拖动到打开的图窗口上新创建的连接器。

注:根据 SysML,您要指定为通过连接器流动的项目的元素必须是接口模块所拥有的至少一个流属性的类型,该接口模块用于输入连接的代理端口。
6. 不要在打开的对话框中进行任何更改;单击OK。Electricity模块被指定为流过新创建的连接器的项目。

以同样的方式,指定前面描述的其余交互。完成后,您的 ibd 应该与下图中的类似。

注:如您所见,端口名称隐藏在图中。由于这些名称不传达重要信息,隐藏它们是提高图表可读性的好习惯。要隐藏端口的名称,请在图窗口上右键单击其图块并取消选中Show Name复选框。如果要一次为所有端口设置此选项,请在按住 Alt 键的同时选择任何端口的图块,然后继续执行与单个端口相同的操作。
Step 6. 指定Cooling System内的交互
在这一步中,我们继续指定交互——这一次,是在Cooling System的不同组件之间。与上一步一样,可以将交互指定为通过兼容代理端口建立的连接器。 通过连接器交换的信息、资源等可以指定为项目流。
假设工程团队确定了以下交互:
- 压缩机系统从蒸发器系统中获取低压氟利昂(Freon)
- 压缩机系统将氟利昂从低压气体转化为高压气体(几乎是液体)
- 冷凝器从压缩机系统中获取高压氟利昂,并通过接收器干燥器将其提供给蒸发器系统
- 蒸发器系统将氟利昂从高压气体转化为低压气体并将其提供给压缩机系统
上面的列表确定了Cooling System的另一个接口。它用于交换氟利昂或一般来说,制冷剂。它可以作为新的接口模块在模型中捕获。
捕获用于交换制冷剂(Refrigerant)的接口模块:
- 右键单击您在step 1 of the SS3 tutorial中创建的 1 Interfaces 包,然后选择 Create Element。
- 在搜索框中,键入 ib,其中i代表接口(interface),b代表模块(block),然后按Enter。
- 键入 iRefrigerant 以指定新接口模块的名称,然后按 Enter。
- 右键单击接口模块并选择Create Element。
- 在搜索框中,键入 fp,其中 f 代表流(flow),p 代表属性(property),然后按 Enter。
- 保留inout,流属性的默认方向,保持原样;键入 Refrigerant Flow:Freon 以指定其名称和类型,然后按 Enter。流属性与作为其类型的Freon信号一起创建。

如您所见,氟利昂在模型中被自动捕获为信号,这是不正确的,因为氟利昂的性质意味着它应该被定义为一个模块。这可以通过将 Freon 信号(signal)重构为模块(block)来轻松解决。
将 Freon 信号重构为模块:
1. 在Model Browser中,右键单击 Freon 信号并选择 Refactor > Convert To > Block。
2. 单击OK删除这两种类型之间不兼容的所有属性。
指定上述交互所需的下一件事是相关的交换项目。由于氟利昂可以是低压气体或高压气体,您需要在模型中定义这两个状态。每个状态都可以作为氟利昂模块的子类型来捕获。要创建子类型,可以使用 bdd 的基础结构。另请注意,氟利昂模块及其两个子类型应存储在 2 Exchange Items 包中。
捕捉氟利昂的状态:
1. 在Model Browser中,选择 Freon 模块并将其拖到您在step 1 of the SS3 tutorial中创建的 2 Exchange Items 包中。Freon模块被移动到该包中。
2. 右键单击 2 Exchange Items 包并选择 Create Diagram。
3. 在搜索框中,键入 bdd(SysML 模块定义图的首字母缩写词),然后按 Enter。图已创建。
4. 键入 Freon Conditions以指定图名称,然后再次按 Enter。
5. 将 Freon 模块拖到图窗口中。Freon 模块的图块在图上创建。
6. 单击其智能操纵器工具栏上的泛化(Generalization)按钮。
7. 单击图窗口上的空白处。
8. 直接在新图块上键入 Low Pressure Freon 以命名模块,然后按 Enter。
9. 再次选择Freon 模块并按照step 6到8创建High Pressure Freon模块。

现在您已准备好指定Cooling System组件之间的交互(在此步骤开始时确定)。
指定Compressor System从Evaporator System中获取低压Freon:
- 确保在Cooling System Components图中启用了Type Selection Mode。否则,代理端口的创建不会触发选择接口模块来输入该代理端口。
- 选择由 Evaporator System 模块输入的part属性的图块,然后单击其智能操纵器工具栏上的代理端口(Proxy Port)按钮。新的代理端口出现在part属性图块的边框上。
- 键入 ir 以在 Select Type 列表中找到 iRefrigerant 接口模块,按向下箭头(Down Arrow)键将其选中,然后按 Enter。
- 单击新创建的代理端口的智能操纵器工具栏上的连接器(Connector)按钮。
- 单击由 Compressor System 模块输入的part属性的图块。
- 选择New Proxy Port。为该part属性创建兼容的代理端口,并建立两个part属性之间的连接器。
- 在Model Browser中,展开 2 Exchange Items 包的内容(如果尚未展开),选择 Low Pressure Freon 模块,并将其拖到新创建的连接器上。注:根据 SysML,您要指定为通过连接器流动的项目的元素必须是接口模块所拥有的至少一个流属性的类型,该接口模块用于输入连接的代理端口。这也适用于子类型。这就是为什么不仅Freon模块,而且它的任何类型(在这种情况下,Low Pressure Freon 模块),都可以分配给连接器。
- 不要在打开的对话框中进行任何更改;单击OK。Low Pressure Freon 模块被指定为通过新创建的连接器流动的项目。

以同样的方式,指定前面描述的其余交互。完成后,您的 ibd 应该与下图中的类似。

1.2.4 S2/SS2.系统/分系统行为
它是什么?
设计中系统的行为集成了其子系统的行为,在 HLSA 模型中标识(参见 S3.initial)。 因此,首先,必须指定所设计子系统的行为。独立的工程团队,每个负责单个子系统的解决方案架构,为此目的并行工作。行为模型可以是相对抽象的,并且应该满足功能性系统需求(参见 S1.initial)。使用建模工具的功能,可以针对测试用例执行这些模型,以判断这些功能性需求是否得到满足。
之后,将设计中的所有子系统的行为模型集成为一个单一的——整个系统的行为模型。 行为模型集成的主要目的是检查这些子系统如何通过 S3 中定义的兼容端口相互发送信号来相互通信。因此,系统工程师的主要任务是测试从一个子系统发出的信号是否能被另一个子系统接受。同样,他/她可以为此目的利用建模工具的模拟能力。
请注意,以下材料侧重于构建Cooling System的行为模型,这只是Vehicle Climate Control System的子系统之一。但是,您应该设想,当您为Cooling System构建行为模型时,其他工程师/工程团队并行工作以构建Heating System, Control System, Sensors System, 和UI System的解决方案架构。
谁是负责的人?
在典型的多学科系统工程团队中,设计中的系统/子系统的行为是由架构团队产生的。工程团队为设计中的每个子系统构建独立的行为模型。系统工程师随后将它们集成到整体中。
如何建模?
设计中的系统或子系统的行为模型可以通过结合使用 SysML 状态机图、活动图或序列图的基础结构来捕获。前者允许捕获正在设计的子系统的状态以及它们之间的转换以响应随时间发生的事件。后者应该用于指定这些状态或转换效果的entry, do和exit行为。
下图显示了 SysML 状态机图,标识了Cooling System的主要状态。状态之间的转换可以由各种类型的事件触发。如您所见,它可以是信号事件,例如在 Off 和 On 状态之间的 Turn On,也可以是时间事件,例如 Idling 和 Operating 状态之间的 after (60s)。

状态可以具有一个或多个内部行为,这些行为以在模型中某处创建的 SysML 活动图的形式指定。如您所见,Initializing 状态将 Initializing System Components 活动指定为do行为。Initializing System Components 活动图如下所示。

在设计每个子系统的行为模型后,作为系统工程师,您可以创建一个 SysML 活动图来指定从Cooling System发送到例如Control System的信号通过兼容端口。发送信号动作应该指定发送信号的端口,而不是接受信号的端口。
下一步是什么
l 一旦有了子系统的行为,就可以开始将所有子系统的解决方案架构集成到整体中; 即,移至 S3.final。
Tutorial
Step 1. 为 SS2 梳理模型
冷却系统的状态可以在该子系统的方案域模型中捕获,该模型是您在step 1 of the SS3 tutorial中创建的。根据 SysML,状态只能存储在它们所代表的行为的模块下。在这种情况下,它是Cooling System Design模块。因此,您无需创建任何额外的包来在模型中存储状态。它们应该直接出现在Cooling System Design模块下,该模块存储在 3 System Structure 包中。
但是,如果您需要指定Cooling System在处于一种或另一种状态或从一种状态转换到另一种状态时执行的某些行为,则应在单独的包中指定该行为。 按照MagicGrid框架的设计,这个包应该存储在下图所示的包结构下。

为 SS2 梳理模型:
1. 如果尚未打开,请打开您在step 1 of the SS3 tutorial中创建的Cooling System的方案域模型(Cooling System_Solution.mdzip 文件)。
2. 右键单击2.1 Cooling System Solution Domain包并选择Create Element。
3. 在搜索框中,键入 pa,即元素类型 Package 的前两个字母,然后按 Enter。
4. 键入 2 System Behavior 以指定新包的名称,然后按 Enter。
Step 2. 创建用于捕获Cooling System状态的图
描述Cooling System状态的 SysML 状态机图应直接在捕获设计中的子系统的模块下创建。
创建用于捕获Cooling System状态的 SysML 状态机图:
1. 打开您在step 1 of the SS3 tutorial中创建的Cooling System的方案域模型(如果尚未打开)。
2. 在Model Browser中,选择Cooling System Design模块。为此,请使用快速查找功能:
a. 按 Ctrl + Alt + F。Quick Find对话框打开。
b. 键入 cooling s。
c. 当您看到在下面的搜索结果列表中选择了Cooling System Design模块时,请按 Enter。在Model Browser中选中了Cooling System Design模块。
3. 为 Cooling System Design 模块创建 SysML 状态机:
a. 右键单击Cooling System Design模块并选择Create Diagram。
b. 在搜索框中,键入 smd(SysML 状态机图的首字母缩写词),然后按 Enter。该图是使用初始状态和一个未命名的状态创建的,用于启动状态定义。

c. 键入 Cooling System States 以指定新图的名称,然后再次按 Enter。
Step 3. 捕获Cooling System的状态
假设从事Cooling System解决方案架构的工程团队已经确定了Cooling System在 VCCS 运行期间可以存在的以下状态集:
- Off
- On:
a. 初始化(Initializing)
b.诊断(Diagnosing)
c. 运转(Operating)
d. 空转(Idling)
以下规则描述了这些状态之间的切换:
- 子系统的第一个状态是Off。
- 子系统可以从Off状态切换到On状态并返回。
- 在 On 状态下,子系统首先进入 Initializing 状态。
- 从 Initializing 状态,子系统可以切换到 Operating 状态或 Diagnosing 状态。
- 从Operating状态,子系统可以切换到Idling状态并返回。
- 从Diagnosing状态,子系统可以切换到Operating状态或Off状态。
本教程后面将讨论触发状态之间切换的事件发生。这一步主要集中在创建状态和它们之间的切换。
指定Cooling System的状态:
1. 打开Cooling System States图(如果尚未打开)。该图已包含initial状态和unnamed状态。
2. 选择unnamed状态的图块,然后单击该图块中间的某个位置。图块切换到名称编辑模式。
3. 键入 Off 以指定名称,然后按 Enter。
4. 选择 Off 状态的图块并单击其智能操纵器工具栏上的Transition(转换)按钮。
5. 单击图窗口上的空白处。另一个状态被创建。
6. 直接在该状态的图块上键入On,然后按 Enter。
7. 拖动新创建的图块的边角以将其放大。这是在其中创建内部状态所必需的。

8. 单击图面板上的Initial按钮并将鼠标移到 On 状态的图块上。
9. 当您看到 On 状态图块周围的蓝色边框时,单击它。initial状态在On 状态的图块内创建,On 状态自动变为复合状态。
10. 选择initial状态的图块并单击其智能操纵器工具栏上的Transition按钮。
11. 右键单击复合状态图块上的空白位置,然后选择State。该复合状态的另一个内部状态被创建。
12. 直接在该状态的图块上键入 Initializing,然后按 Enter。

13. 按照给定的切换规则,从上面的列表中创建其余状态。完成后,您的状态机图应该与下图中的非常相似。

Step 4. 在切换中指定事件发生
状态之间的切换可以由各种类型的事件触发,例如时间、变化和信号事件等等。Cooling System状态之间的大部分切换是由信号事件触发的。例如,Cooling System在收到Turn On 信号后由Off状态进入On状态;收到Turn Off信号后,它会返回Off状态。
指定Cooling System On和Off状态之间切换的信号事件:
1. 选择从 On 到 Off 状态的切换。
2. 直接在路径上键入Turn On,然后按 Enter。Turn On信号在Model Browser中创建,并作为信号事件自动分配给从Off状态到On状态的切换。

3. 选择从Off状态到On状态的切换。
4. 直接在路径上键入Turn Off,然后按 Enter。Turn Off信号在Model Browser中创建,并作为信号事件自动分配给从 On 状态到 Off 状态的切换。

Turn On 和 Turn Off 信号以及随后创建的信号(见下图)应存储在单独的包中。这将在本教程后面讨论。

从Idling状态到Operating状态的切换由另一种类型的事件触发——相对时间事件。它允许建模者指定在Idling状态 60 秒后,Cooling System回到Operating状态。
指定在Idling状态和Operating状态之间切换的时间事件:
1. 选择从Idling到Operating状态的切换。
2. 直接在路径上键入after (60s)并按 Enter。 相对时间事件是在状态之间的切换上创建的。

Step 5. 将信号梳理成包
你已经创建了很多信号。现在是时候将它们移动到一个单独的包中,以使您的模型井井有条。
默认情况下,所有触发Cooling System状态切换的信号都放置在Cooling System States状态机下。与要交换的项目的所有定义一样,这些信号应移动到您在step 1 of the SS3 tutorial中创建的 2 Exchange Items 包中。只需将信号拖到Model Browser中的那个包上,就可以将信号移到那里。

Step 6. 指定状态的entry、do或exit行为
设计中的系统或子系统可以执行与其某些状态相关的一种或多种行为。假设Cooling System处于Initializing状态时,调用Compressor System启动,并等待 60 秒以响应调用信号。如果收到响应,则会将 Init OK 信号(参见step 3 of this tutorial)发送到Cooling System。否则,将发送 Init NOT OK 信号(参见step 3 of this tutorial)。这种行为可以被捕获为 SysML 活动并存储在Cooling System的方案域模型中,在您step 1 of this tutorial中创建的 3 System Behavior 包下。
无需创建 SysML 活动,然后创建图。在您选择创建 SysML 活动图后,它们都出现在模型中。
创建 SysML 活动图:
1. 右键单击 2 System Behavior 包并选择 Create Diagram。
2. 在搜索框中,键入 ad(SysML 活动图的首字母缩写词),然后按 Enter。创建一个 SysML 活动图。它归 SysML 活动所有。
3. 键入 Initializing System Components 以指定新图的名称,然后再次按 Enter。与该图所属的 SysML 活动具有相同的名称。

指定Initializing System Components活动:
1. 单击图面板上的 Initial Node 按钮,然后单击图窗口上的空白处。初始节点被创建并显示在图上。
2. 单击图面板上的Send signal Action按钮,然后再次单击图窗口上的空白位置。发送信号动作被创建并显示在图上。
3. 直接在创建的动作的图块上键入 Initialize Compressor System,然后按 Enter。在模型中直接在 3 System Behavior 包下创建了具有相同名称的新信号。
4. 选择初始节点的图块,单击其智能操纵器工具栏上的控制流(Control Flow)按钮,然后选择 Initialize Compressor System 发送信号动作的图块。在初始节点和发送信号动作之间建立控制流。
5. 选择 Initialize Compressor System 发送信号动作的图块,单击其智能操纵器工具栏上的 Control Flow 按钮,然后右键单击图窗口上的空白位置并选择 Fork Horizontal。 水平分支节点已创建并显示在图窗口上。

6. 单击图面口上的Time Event按钮,然后再次单击图窗口上的空白位置。时间事件动作被创建并显示在图上。
7. 直接在新创建的时间事件动作的图块上键入 60s,然后按 Enter。

8. 将时间事件动作的触发器从绝对转换为相对:
a. 双击时间事件动作的图块以打开其详述(Specification)。
b. 找到 Is Relative 属性并将其值设置为 true。
c. 关闭对话框。触发器的指示器从 at 变为 after。

9. 单击图面板上的 Accept Event Action 按钮,然后再次单击图窗口上的空白位置。接受事件动作被创建并显示在图上。
10. 为新创建的接受事件动作创建信号:
a. 在Model Browser中,右键单击 2 Exchange Items 包(参见step 4 of this tutorial)并选择 Create Element。
b. 在搜索框中,输入 si,即元素类型 signal 的前两个字母,然后按 Enter。
c. 键入 Compressor System Started 以指定新信号的名称,然后按 Enter。
d. 将信号拖到接受事件动作的图块。动作以该信号命名。
11. 创建用于发送 Init OK 信号的发送信号动作:
a. 在Model Browser中2 Exchange Items 包下(参见step 4 of this tutorial)),选中 Init OK 信号。
b. 将信号拖到图窗口中。带有信号名称的新动作的图块在图窗口中创建。
12. 以与step 11中所述相同的方式创建用于发送 Init NOT OK 信号的发送信号操作。

13. 单击图面板上的 Activity Final 按钮,然后单击图窗口上的空白处。最终节点被创建并显示在图表上。
14. 创建您在下图中看到的其余控制流。

一旦指定了Initializing System Components活动,就可以将其分配到Initializing状态作为其执行行为。
将Initializing System Components活动设置为Cooling System Initializing状态的do行为:
1. 打开Cooling System States图。
2. 在Model Browse中,选择 Initializing System Components活动并将其拖动到Initializing 状态的图块。
3. 当看到图块周围的蓝色边框时,单击该图块。
4. 选择Do Activity,如下图所示。do 行为已设置。

下图显示了将 SysML 活动分配为其do行为的 Initializing 状态。现在您可以考虑指定的Cooling System的行为,然后继续将Cooling System的方案域模型集成到整个系统的方案域模型中。

1.2.5 S3.系统结构:final
它是什么?
在工程团队完成子系统的解决方案架构后,系统工程师可以将它们集成到一个模型中。 事实上,可以提出不止一种解决方案;因此,系统工程师进行权衡研究,以选择每个子系统中的首选,并构建整个系统的集成解决方案架构。
结构设计集成的主要目的是验证所设计系统的子系统是否能够成功地相互通信。因此系统工程师的主要任务是检查各个子系统的接口是否兼容。如果系统工程师检测到一个或多个不兼容的接口,他/她会要求负责的工程团队适当地审查和更新他们的模型。在工程团队完成请求后,系统工程师再次尝试集成模型。
谁是负责的人?
在典型的多学科系统工程团队中,负责将子系统集成为整体的人是系统工程师,即架构团队的负责人。
如何建模?
对于结构集成和审查,我们建议使用建模工具中可用的预定义关系图之一——结构分解图(Structure Decomposition Map)。

对于接口兼容性可视化和验证,可以使用 SysML 内部模块图。

下一步是什么?
- 拥有集成解决方案架构模型后,您可以指定它如何满足系统需求。因此,您可以转到 S1.final。
- 集成解决方案架构模型使您能够计算整个系统的效能指标并根据系统要求验证它们(参见 S1.initial)。因此,您也可以转到 S4。
Tutorial
Step 1. 为 S3.final 创建和梳理模型
由于您已经有了Cooling System的解决方案架构(包括结构和行为模型),您可以作为系统工程师将其集成到整个 VCCS 的解决方案架构中(连同由虚构的工程团队同时开发的其他子系统的解决方案架构)。
为此,您必须创建一个模型(另一个file),该模型集成了 VCCS 的所有子系统的解决方案架构,包括Cooling System和Heating System等。一般来说,这种模型可以称为系统配置模型。请注意,单个方案域中可以有多个系统配置模型; 但是,我们只关注一个。
创建 VCCS 的系统配置模型:
1. 开始共享Cooling System的方案域模型。
注:事实上,VCCS 的所有子系统的方案域模型都应该在这一步共享。
有关此主题以及step 2和3中提及的主题的更多信息,请参阅您的建模工具的最新文档。
2. 创建一个新模型(file)。它可以命名为VehicleCCS_Configuration.mdzip。这是Vehicle Climate Control System的配置模型。
3. 在 VCCS 的配置模型中以只读方式使用Cooling System 的方案域模型。已经在Cooling System的方案域模型中使用过,问题域模型和 VCCS(HLSA 模型)的方案域模型也自动使用。

注:使用的模型中的灰色元素名称表示无法修改元素。这是因为在read-only下使用了外部模型。
4. 右键单击Model包(这是根包的默认名称)并选择Create Element。
5. 在搜索框中,键入 pa,即元素类型 Package 的前两个字母,然后按 Enter。
6. 键入 3 VCCS Configuration 以指定新包的名称并按 Enter(参见step 9中的图)。
7. 右键单击3 VCCS Configuration包并选择Create Element。
8. 重复step 5。
9. 键入3 System Structure 以指定新包的名称,然后按 Enter。

Step 2. 捕获系统配置的集成结构
对于结构集成和审查,我们建议使用建模工具中可用的预定义关系图之一——结构分解图。它可以在您在上一步中创建的 VCCS 配置模型中的 3 System Structure 包中创建。
捕捉 VCCS 配置的集成结构和Cooling System的结构:
1. 创建一个模块来捕获 VCCS 配置:
a. 在Model Browser中,右键单击您在step 1 of this tutorial中创建的 3 System Structure 包,然后选择Create Element。
b. 在搜索框中,键入 bl,即元素类型 Block 的前两个字母,然后按 Enter。
c. 键入 VCCS Configuration 以指定新模块的名称,然后按 Enter。
2. 创建结构分解图:
a. 右键单击 VCCS Configuration 模块并选择 Create Diagram。
b. 在搜索框中,键入 sdm,其中s代表结构,d代表分解,m代表图,然后按 Enter。 创建图,并将VCCS Configuration 模块设置为其上下文。
注:如果您没有看到任何结果,请单击搜索结果列表下方的Expert按钮。可用图表列表在专家模式下展开。
c. 键入 VCCS Configuration Structure 以指定新图的名称,然后再次按 Enter。
3. 为VCCS Configuration模块创建一个part属性,以将Cooling System的结构模型集成到整个系统配置中:
a. 在图窗口中选择 VCCS Configuration 模块,然后单击 Create Related Element 按钮(参见下图)。创建了一个未命名的part属性。

b. 键入:Cool,按 Ctrl +空格键,然后选择Cooling System Design模块。
注:如果您在列表中没有看到该模块,请单击以清除对话框左下角的应用过滤器(Apply Filter)复选框。默认情况下,过滤器排除存储在外部模型中的元素,Cooling System Design模块显然是其中之一——它来自Cooling System的方案域模型。
c. 按 Enter 完成。为VCCS Configuration模块创建了新的part属性(参见下图)。它的类型是Cooling System Design模块,这意味着由单独的工程团队在单独的模型中设计的Cooling System的结构现在集成到整个 VCCS 的结构模型中。

d. 单击Cooling System Design模块输入的part属性图块上的抑制/扩展(Suppress/Expand)按钮以显示Cooling System的更深层结构。

当负责另一个子系统设计的工程团队将该子系统的结构提供给系统工程师时,他/她会以与上述相同的方式将其集成到整体中。下图展示了一个更精细的 VCCS 结构模型与Heating System的集成结构。

Step 3. 验证子系统之间的接口兼容性
结构设计集成的主要目的是验证所设计系统的子系统是否能够成功地相互通信以及与系统外部通信。因此系统工程师的主要任务是检查各个子系统的接口是否兼容。
对于接口兼容性可视化和验证,可以使用 SysML 内部模块图。如下图所示(我们假设您是自己创建的),Cooling System可以成功与 VCCS 的另一个子系统 Control System 通信。 就 SysML 而言,通信是通过 iControl 接口类型的代理端口建立的。要检查Cooling System是否可以与 VCCS 外部成功通信(这由图边框上的代理端口的连接器说明),您需要看全局,即整个车辆系统的图。到目前为止,您只能假设车辆的整个系统具有为Cooling System提供机械动力的发动机和提供电力的交流发电机,等等。
另外,请注意,在 VCCS 的其余子系统集成后,应更新图。

1.2.6 S4.系统参数
它是什么?
只要在模型中捕获系统结构,就可以指定系统参数。系统参数捕捉设计中系统的定量特征。它们满足非功能性系统需求(参见 S1.initial)并基于效能分析(参见 B4 和/或 W4)。
系统参数来源于其他值;例如,子系统参数。可以在模型中指定定义推导规则的数学表达式。了解如何计算系统参数值可以进行早期系统需求验证。使用建模工具的功能,可以执行模型来计算这些值并判断是否满足定量需求。
谁是负责的人?
在典型的多学科系统工程团队中,系统参数和计算它们的公式由系统分析团队在模型中捕获。
如何建模?
在建模工具中,可以将系统参数捕获为模块的值属性,它可以表示系统、子系统或组件。 用于计算该系统参数的公式可以被捕获为约束模块的约束表达式。 SysML 模块定义图的基础结构可用于捕获系统参数和约束表达式。下图显示了将系统参数捕获为 totalMass 值属性的图以及用于计算此参数的公式作为 Total Mass 约束模块的约束表达式。

为了使约束表达式能够执行计算,您必须指定在模型中何处(甚至跨方案域的多个模型)捕获的系统、子系统或组件参数应用作该约束的变量(或约束参数)表达。这可以通过使用以下以实线表示的绑定连接器在 SysML 参数图中完成。

建模工具的仿真功能允许您使用给定的输入计算系统参数。计算出系统参数后,您可以验证适当的非功能性系统需求,并判断是否满足。建模工具使您能够自动执行此验证。要为自动化需求验证做好准备,您需要将捕获系统参数的值属性与适当的系统需求相关联。您需要指定它们之间的满足关系。下图展示了totalMass 值属性与 Total Mass 非功能性需求的满足关系示例,即当totalMass 值属性的值不大于 20 kg 时满足需求。如您所见,需求文本中的自然语言表达式由Total Mass 约束模块的另一个约束表达式tm <= 20不等式改善。

如您所见,满足和改善关系都在SysML 需求图中表示,但 bdd 也可用于此目的。
下一步是什么?
l 获得系统参数后,您可以指定它们如何满足系统需求。因此,您可以转到S1.final。
Tutorial
Step 1. 为 S4 梳理模型
假设您要指定如何计算车辆气候控制系统的总质量。由于该系统参数与整个系统相关,而不是与某个子系统或组件相关联,因此应在您在step 3 of the S3 final phase tutorial中更新的系统配置模型中指定它。这个和所有随后捕获的系统参数可以存储在 4 System Parameters 包中,该包直接放在系统配置模型中的 3 VCCS Configuration 包下。

注:计算车辆气候控制系统的总质量需要知道每个子系统的总质量。这些是来自子系统的方案域模型的子系统参数。为了使用这些参数来计算 VCCS的总质量,必须在系统配置模型中使用每个子系统的方案域模型。这就是上图显示它们在系统配置模型中使用的原因。但是,您应该记住,子系统的方案域模型,除了Cooling System之一,没有详细说明。仅在捕获适当的子系统参数时才需要它们。您将在本单元教程的后续步骤之一中了解如何创建子系统参数。
为 S4 梳理模型:
1. 如果尚未打开,请打开您在step 1 of the S3 final phase tutorial中创建的 VCCS 的系统配置模型(VCCS_Solution.mdzip 文件)。
2. 右键单击3 VCCS Configuration包并选择Create Element。
3. 在搜索框中,输入 pa,即元素类型 Package 的前两个字母,然后按 Enter。
4. 键入 4 System Parameters 以指定新包的名称,然后按 Enter。
您还需要创建一个包用于在模型中存储约束模块。让它成为你在下图中看到的4 System Parameters 包下的1 Constraints包(我们假设你是自己创建的)。

Step 2. 指定系统参数以捕获总质量
如下图所示,系统需求规范(见 S1)和效能分析(见 B4)决定了捕获 VCCS 总质量的系统参数规范。

系统参数被捕获为相关模块的值属性。在这种情况下,您应该在系统配置模型中为 VCCS 模块创建一个值属性。但是,使用建模工具的继承和重新定义功能会使开始变得更容易。让我们看看它是如何工作的。
指定捕获 VCCS 总质量的系统参数:
1. 创建用于捕获系统参数的 bdd:
a. 右键单击您在step 1 of the S4 tutorial中创建的 4 System Parameters 包,然后选择 Create Diagram。
b. 在搜索框中,键入 bdd(SysML 模块定义图的首字母缩写词),然后双击 Enter。 图表已创建。
注:该图以其存储的包命名。这个名字也非常适用于该图。您只需从其名称中删除序列号。
2. 在图上显示 MoEs Holder 模块:
a. 按 Ctrl + Alt + F 打开Quick Find对话框。
b. 在对话框中:
i. 单击Any Element以仅搜索特定元素。
ii. 键入moes。
iii. 单击以清除搜索结果列表底部的Apply Filter复选框,以将外部模型的内容包含在搜索范围中(这是必要的,因为MoEs Holder模块留在问题域模型中)。
c. 当您看到在搜索结果列表中选中了MoEs Holder 模块时,按 Enter。该模块在Model Browser中被选中。
d. 将MoEs Holder模块拖到图窗口中。模块的图块显示在图上。

3. 在图上显示VCCS Configuration模块:
a. 按 Ctrl + Alt + F 打开Quick Find对话框。
b. 在对话框中:
i. 单击Any Element以仅搜索特定元素。
ii. 键入vccs。
c. 当您看到在搜索结果列表中选择了VCCS Configuration模块时,按 Enter。该模块在Model Browser中被选中。
d. 将 VCCS Configuration模块拖到图窗口中。模块的图块显示在图上。

4. 建立VCCS Configuration模块(子类型)和MoEs Holder模块(超类型)之间的泛化关系:
a. 单击图面板上的 Generalization 按钮。
b. 单击VCCS Configuration模块的图块。
c. 单击 MoEs Holder 模块的图块。MoEs Holder 模块成为VCCS Configuration模块的超类型,这意味着后者继承了前者的所有值属性。

5. 在 VCCS Configuration模块的图块上显示继承的值属性:
a. 右键单击图块并选择Symbol Properties。
b. 单击属性列表上方的下拉列表框,然后选择All。该模块图块的所有属性都显示在对话框中。
c. 在打开的对话框底部的搜索字段中,键入inh。Show Inherited属性出现在属性列表的顶部。
d. 单击以将属性值设置为 true 并关闭对话框。VCCS Configuration模块的继承值属性显示在其图块上。插入符号 (“^”) 表示它们是继承的。
6. 重新定义 VCCS Configuration模块的Total Mass MoE:
a. 右键单击该模块图块上的Total Mass值属性,然后选择 Refactor > Redefine To。
b. 直接在图块上将值属性重命名为 totalMass,然后按 Enter。让这成为方案域中命名值属性的新惯例。

您也可以重新定义Sound Level MoE,但我们不会指定如何计算它。之后,您的System Parameters图应如下图所示。

Step 3. 捕获计算总质量的公式
totalMass值属性捕获衍生系统参数。因此,您需要做的下一件事是捕获指定如何计算该值属性的数学表达式。可以将数学表达式捕获为存储在模型中的某些约束模块的约束表达式。
在这一步中,您应该定义一个约束模块并指定一个约束表达式来计算 VCCS 的总质量。 假设 VCCS 的总质量是其所有子系统的质量加上 VCCS 本身的质量的总和。约束表达式可以定义如下:
tm = cooling_tm + heating_tm + control_tm + sensors_tm + ui_tm + m
其中:
1. tm 代表 VCCS 的总质量
2. cooling_tm 代表Cooling System的总质量
3. heat_tm 代表Heating System的总质量
4. control_tm 代表Control System的总质量
5. sensor_tm 代表Sensors System的总质量
6. ui_tm 代表UI System的总质量
7. m 代表 VCCS 本身的质量
在 SysML 中,tm、cooling_tm、…、m 通常被称为约束参数,以后应该绑定到模型中指定的相应值属性。
bdd 可用于捕获约束模块。这个约束模块也不例外;因此,您可以使用在step 2 of this tutorial中创建的 bdd。然后可以将该约束模块移动到您在step 1 of this tutorial 中创建的 1 Constraints 包。
注:通常约束模块首先在模型中定义,然后才应用于模块。就 SysML 而言,约束模块在输入该模块的约束属性时应用于该模块。在模型中定义一次的单个约束模块可以应用于许多模块。因此,约束模块应存储在模型内的单独包中。
获取计算 VCCS 总质量的公式:
1.创建一个约束模块:
a. 打开System Parameters图(如果尚未打开)。
b. 单击图面板上的Constraint Block按钮,然后单击该图窗口的空白处。 创建一个未命名的约束模块。
c. 直接在该元素的图块上键入 Total Mass 以指定其名称,然后按 Enter。
2. 指定一个约束表达式来捕获上面定义的公式:
a. 单击 Total Mass 约束模块上的空约束表达式的符号。

b. 再次单击选中项。空约束表达式切换到编辑模式。

c. 键入tm=cooling_tm+heating_tm+control_tm+sensors_tm+ui_tm+m,然后按 Enter。

3. 指定约束参数:
a. 选择 Total Mass 约束模块的图块,然后单击其智能操纵器工具栏上的 Parse and Create Parameters 按钮(参见下图)。约束参数自动从约束表达式中提取并显示在图块上的参数分隔框中。

b. 一个个选择参数,直接在约束模块的图块上将其类型从默认的Real改为mass[kilograms]:
i. 双击类型以选择它,键入mass[k,然后按 Ctrl +空格键。
ii. 从下面的列表中选择mass[kilograms]类型。
注:如果列表为空,则需要加载 ISO 库。为此,单击所选参数上智能操纵器工具栏上的 ISO。
iii. 按Enter。
完成最后一个后,总质量约束模块的图块应如下图所示。

4. 将 Total Mass 约束模块拖到模型中的1 Constraints包中。约束模块被移动到该包。
Step 4. 指定子系统参数以捕获总质量
有了约束表达式,您可以轻松确定计算 VCCS 总质量所需的系统/子系统参数。该约束表达式的输入参数可以帮助您完成此任务。
您可能还记得,Total Mass 约束模块的约束表达式有六个输入参数,因此需要在模型中捕获六个系统/子系统参数作为值属性。其中五个是子系统参数,每个参数捕获一个子系统的总质量。它们应该在单独的模型中指定,每个模型都在相关子系统的方案域模型中。例如,捕获Cooling System总质量的值属性应位于您在step 1 of the SS3 tutorial中创建的Cooling System的方案域模型中定义。如下图所示,应该为 Cooling System Design 模块创建 totalMass值属性。

指定捕获Cooling System总质量的子系统参数:
1. 打开Cooling System的方案域模型,即您在step 1 of the SS3 tutorial中创建的模型。
2. 在Model Browser中,选择Cooling System Design模块:
a. 按 Ctrl + Alt + F 打开Quick Find对话框。
b. 在对话框中:
c. 当您看到在搜索结果列表中选中了Cooling System Design模块时,按 Enter。该模块在Model Browser中被选中。
3. 为 Cooling System Design 模块指定 totalMass 值属性:
a. 右键单击Cooling System Design模块并选择Create Element。
b. 在搜索框中,键入 vp,其中 v 代表值,p 代表属性,然后按 Enter。
c. 键入 totalMass:mass[k 并按 Ctrl +空格键 选择合适的值类型。
d. 从下面的列表中选择mass[kilograms]值类型,然后按 Enter。
按照上述步骤,可以适当地捕获其他子系统的总质量。
约束表达式的六个输入参数中的最后一个需要您指定另一个系统参数——VCCS 本身的质量。可以在下一步中捕获适当的值属性。
Step 5. 将约束参数绑定到系统/子系统参数
一旦有了系统/子系统参数(在模型中作为值属性捕获),就可以将它们绑定到 Total Mass 约束模块的适当约束参数。请记住,正是绑定使约束表达式能够对给定的输入执行计算。
可以使用绑定(binding)连接器建立值属性和约束参数之间的绑定。这种类型的 SysML 关系可以通过利用为 VCCS Configuration模块创建的 SysML 参数图的基础结构来创建。 但是,创建 SysML 参数图还不足以开始。只有在将总质量约束模块应用于VCCS Configuration模块之后,才能建立绑定连接器。
将 Total Mass 约束模块的约束参数绑定到相应的值属性:
1. 打开 VCCS 配置模型并确保使用的模型是最新的。
注:有关此主题的更多信息,请参阅您的建模工具的最新文档。
2. 找到 VCCS Configuration模块:
a. 按 Ctrl + Alt + F。Quick Find对话框打开。
b. 键入vccs。
c. 当您看到在搜索结果列表中选中了 VCCS Configuration模块时,按 Enter。该模块在Model Browser中被选中。
3. 为 VCCSystem Configuration模块创建一个 SysML 参数图:
a. 按 Ctrl + N。Create Diagram对话框打开。
b. 在搜索框中,键入 par(SysML 参数图的首字母缩写词),然后按 Enter。创建空白的 SysML 参数图,并打开Display Parameters/ Parts对话框。
c. 选择所有totalMass值属性并单击OK。选中的值属性显示在图窗口上,并且在打开名称编辑模式的Model Browser中选中图。

注:如您所见,值属性以点(dot)表示法显示。如果要切换到嵌套(nested)表示法,请选中所有图块,除了其中的一个totalMass值属性(顶部的第二个图块),然后右键单击它们并选择Refactor > Convert to Nested Parts。

d. 键入Total Mass of the VCCS来命名图,然后按 Enter。
4. 找到Total Mass约束模块:
a. 按 Ctrl + Alt + F。Quick Find对话框打开。
b. 键入 total。
c. 当您看到在搜索结果列表中选中了 Total Mass 约束模块时,按 Enter。在Model Browser中选中了约束模块。
5. 将Total Mass约束模块拖到Total Mass of the VCCS图上。为VCCS Configuration模块创建了一个未命名的约束属性。约束属性由 Total Mass 约束模块输入,这意味着该约束模块应用于 VCCS Configuration 模块。参数方程向导(Parametric Equation Wizard)对话框同时打开。
6. 一个个选择约束参数(在对话框的左侧)并将每个参数拖到相应的值属性(在对话框的右侧):
- heat_tm 到 Heating System Design 模块的 totalMass 值属性
- control_tm 到 Control System Design 模块的 totalMass 值属性
- ui_tm 到 UI System Design 模块的 totalMass 值属性
- tm 到 VCCS Configuration模块的 totalMass 值属性
- cooling_tm 到Cooling System Design模块的totalMass值属性
- sensor_tm 到 Sensors System Design 模块的 totalMass 值属性
注:您可能需要展开对话框右侧的结构树以查看所需的值属性。请记住,它们中的大多数属于子系统模块,而不是直接属于系统模块。
一旦绑定,约束参数将其颜色从红色变为灰色。

7. 绑定除 m 约束参数以外的所有项后(对应的值属性尚未创建!),单击 OK。对话框关闭,所有绑定都显示在图窗口中。

还有更多建立绑定连接器的方法。您可以学习其中一个将 m 约束参数绑定到一个新的值属性,该属性捕获 VCCS 本身的质量。
将 m 约束参数绑定到新的值属性:
1. 在图窗口上选择约束属性的图块,然后单击其智能操纵器工具栏上的Display All Parameters按钮。m 约束参数显示在该约束属性的图块上。
2. 选择m约束参数的图块,然后单击其智能操纵器工具栏上的Binding Connector按钮。
3. 单击图窗口上您认为不错的地方。创建一个未命名的值属性。
注:与图中显示的mass值属性一样,它由VCCS Configuration模块拥有。为确保正确,右键单击mass值属性的图块并选择Select in Containment Tree。
4. 直接在图块上,键入mass:mass[kilo 并按 Ctrl +空格键。
5. 从下面的列表中选择mass[kilograms]类型,然后按 Enter。

现在您可以运行模拟、提供输入值并查看计算结果。
注:此处不讨论仿真功能,因为它们涉及模型的使用,而不是建模。要了解有关模拟的更多信息,请参阅建模工具的最新文档。
Step 6. 为自动化需求验证做好准备
计算出系统参数后,您可以验证Total Mass系统需求并判断是否满足。建模工具使您能够自动执行此验证。要为自动化需求验证做好准备,您需要:
1. 将捕获的约束规范化为Total Mass系统需求文本中的自然语言短语。 对于 SysML,您应该使用另一个约束表达式创建另一个约束模块,这次是 tm <= 20 不等式,然后在该约束模块和 Total Mass 系统需求之间绘制一个改善关系,如下图所示。

2. 指出系统参数,其值决定是否满足系统需求。就 SysML 而言,您应该在捕获系统参数的 totalMass 值属性与 Total Mass 系统需求之间绘制满足关系。

Step 7. 增加计算的复杂性
前面的步骤描述了非常简单的计算,其中所有输入都是手动定义的。但是,在现实世界中,这种情况很少见。通常计算更复杂,一个约束表达式的输出成为另一个约束表达式的输入。
指定如何计算 VCCS 总质量的公式也可能变得更加复杂。它可以被捕获为几个约束表达式的组合。您可以为 VCCS 的每个设计子系统指定足够的约束表达式,并使它们的总质量值属性可计算,而不是手动定义。
计算 VCCS 总质量的约束模块在VCCS 配置模型中定义,而计算Cooling System总质量的约束模块应在Cooling System的方案域模型中定义。捕获Cooling System组件质量值的值属性也应在该模型中定义。按照本教程前面步骤中给出的说明,您可以使用足够的元素更新Cooling System的方案域模型。
注:系统的总质量也可以通过使用建模工具的功能来计算。MassRollUpPattern 可以应用于 VCCS Configuration模块,而不是手动定义约束和值属性。要了解有关roll-up模式的更多信息,请参阅建模工具的最新文档。
1.2.7 S1.系统需求:final
它是什么?
要拥有完整的方案域模型,您需要在捕获系统需求的元素和捕获设计中系统的解决方案架构的元素之间建立可追溯关系。由 SysML 确定,这些是满足关系,意味着后者之一满足前者之一; 例如,可以从捕获某些逻辑子系统或组件的模块到某些系统需求建立满足关系。在理想情况下,方案域模型中的一个或多个元素满足所有系统需求。
谁是负责的人?
在典型的多学科系统工程团队中,这些可追溯性关系应该由需求团队建立。
如何建模?
这两个SysML图都不适合创建大量整合关系,例如 «satisfy»。为此,矩阵或映射更合适。该建模工具提供了多种用于指定整合关系的预定义矩阵。要捕获«satisfy»关系,可以使用需求满足矩阵(Satisfy Requirement Matrix)。

下一步是什么?
l 一旦你完成了系统需求的可追溯性,你就完成了正在设计的系统的解决方案架构。 这意味着,您可以切换到实施域(Implementation domain)。
Tutorial
Step 1. 为 S1.final梳理模型
假设您要在系统需求和捕获具体系统配置的解决方案架构的元素之间建立可追溯性关系。在这种情况下,应在 1 System Requirements 包内创建需求满足矩阵Satisfy Requirement Matrix,这是VCCS配置模型中3 VCCS Configuration包的子包(VCCS_Solution.mdzip文件)。

为 S1 final 梳理模型:
1. 如果尚未打开,请打开您在step 1 of the S3 final phase tutorial中创建的 VCCS 的系统配置模型(VCCS_Solution.mdzip 文件)。
2. 右键单击3 VCCS Configuration包并选择Create Element。
3. 在搜索框中,输入 pa,即元素类型 Package 的前两个字母,然后按 Enter。
4. 键入 1 System Requirements 以指定新包的名称,然后按 Enter。
Step 2. 创建用于捕获满足关系的矩阵
在此步骤中,您应该创建一个满足需求矩阵并指定其标准。系统需求可以显示在矩阵的列中,捕获系统配置的元素可以显示在其行中。与常见的依赖矩阵相反,需求满足矩阵具有预定义的列元素类型和依赖条件,这有助于加快构建视图。
创建需求满足矩阵:
1. 在Model Browser中,右键单击 1 System Requirements 包并选择 Create Diagram。
2. 在搜索框中,键入srm,这是预定义的需求满足矩阵的首字母缩写词,然后按 Enter。
注:如果您没有看到任何结果,请单击搜索结果列表下方的Expert按钮。可用图表列表在专家模式下展开。
3. 键入System Configuration to System Requirements以指定新矩阵的名称,然后再次按 Enter。
4. 在Model Browser中,展开 2 Solution Domain 包(如果尚未展开),选择 1 System Requirements 包,并将其拖到矩阵内容上方 Criteria 区域中的 Column Scope 框中。2 Solution Domain 包的内包1 System Requirements 包,成为矩阵的范围。
5. 在Model Browser中,选择具有«moe» 元类型的任何part属性、代理端口、约束属性和值属性,然后将选中项拖到矩阵内容上方 Criteria 区域中的 Row Element Type 框。 part属性、代理端口、约束属性和值属性(具有 «moe» 元类型)成为矩阵行的类型。
注:要在结构树中选择一组不相邻的项目,请单击第一个项目,按 Ctrl,然后在按住它的同时逐个选择其他项目。这也适用于第 6 步。
6. 在Model Browser中,直接在 4 VCCS Configuration 包下,选择 3 System Structure 包,即 1 System Requirements 包的同级包和 Satisfy Requirement Matrix,然后将选中项拖到矩阵内容上面 Criteria 区域中的 Row Scope 框。3 System Structure包成为矩阵行的范围,更新矩阵的内容。目前所有单元格都是空的,除了totalMass值属性和SR-1.6 Total Mass需求相交的单元格(请记住,此关系是在step 6 of the S4 tutorial中创建的)。

下图显示了矩阵的 Criteria 区域,突出显示了step 4、5和6的相关条件。

Step 3. 捕获满足关系
现在你已经准备好建立更多满足关系了。让我们指定由 iMechanicial Power 接口模块输入的代理端口满足SR-1.7 Engine Use需求。
指定矩阵中的满足关系:
1. 双击显示由 iMechanicial Power 接口模块输入的代理端口的行和显示 SR-1.7 Engine Use 要求的列交叉处的单元格。满足关系在适当的项目之间创建并显示在单元格中。

建立所有满足关系后,您的System Configuration to System Requirements矩阵应类似于下图中的矩阵。在理想情况下,每个系统需求都必须由系统配置模型中的一个或多个元素来满足。矩阵的最终版本告诉系统工程师系统配置满足系统需求的程度。
