Aistė Aleksandravičienė

Aurelijus Morkevičius博士
著

MagicGrid®知识体系
使用MagicGrid进行基于模型的系统工程实用指南
达索系统

第二版
目录
目录

前言 OLIVIER SAPPIN

前言 AURELIJUS MORKEVIČIUS

本书的贡献者

本书的评审者

前言

第 章 问题域
黑盒视角
涉众要求
系统上下文
用例
有效性度量
白盒视角
功能分析
1.2.2 概念子系统
1.2.3 子系统有效性度量
1.2.4 追溯到涉众要求

第2章 解决方案域
2.1构建目标系统的逻辑架构
2.1.1 系统需求
2.1.2 系统结构
2.1.3 系统行为
2.1.4 系统参数
2.1.5 追溯到系统需求
2.2 构建子系统的逻辑架构
2.2.1 子系统需求
2.2.2 子系统结构
2.2.3 子系统的行为
2.2.4 子系统参数
2.2.5 追溯到子系统需求
2.3 构建系统配置模型
2.3.1 系统配置结构
2.3.2 系统配置行为
2.3.3 系统配置参数
2.3.4 从系统配置到系统需求的可追溯性

第3章 实现域
3.1 实现域分析
3.1.1 实现需求

附录A: 安全性&可靠性分析
A.1 涉众需要: 安全性和可靠性需求
A.2 黑盒视图中的概念FMEA
A.3 黑盒视图中的功能FMEA
A.4 功能FMEA覆盖分析
A.5 在问题域处理安全性和可靠性需求
A.5.1 白盒视图下的FMEA
A.5.2 解决LSA中的安全性和可靠性问题
A.6 子系统层解决安全性和可靠性问题
A.6.1制冷子系统层
A.6.2 过滤子系统层
A.7 子系统级的逻辑子系统FMEA
A.8 在配置层处理安全性和可靠性问题

附录B: 从体系架构到系统架构
B.1 体系工程
B.2 从体系到系统架构转换
B.2.1 MagicGrid : 系统环境上下文
B.2.2 MagicGrid : 涉众方要求

后记

术语表

参考书目

关于作者
ISBN 978-609-454-554-2
©2018-2021,No Magic, Inc。保留所有权利。
虽然No Magic公司采取了预防措施,以确保准确性和完整性,但该书中内容信息仅供参考,No Magic公司不对其准确性或完
整性做保证或对未来的功能或产品的可用性做任何承诺。No Magic公司对不承担因使用本书中包含的任何信息或建议而
直接或间接产生的任何责任、损失或风险。未经No Magic公司事先书面许可，不得以任何形式或方式转载本出版物的任
何部分。所有其他商标均为其所有者的财产。
前言: OLIVIER SAPPIN
基于模型的系统工程(Model Based System Engineering,MBSE)是开发复杂系统的一种相对年轻的实践。
MBSE的承诺能够在任何时候根据使用的需要和场景，逐步建模和仿真系统行为。这个承诺是关于避免特定学科
的隧道效应，并提供项目涉众连续监控系统开发演变的能力。MBSE的关键成功因素之一便是能应用基于健全的
系统工程方法论得出的最佳实践。

MagicGrid知识体系之书(BoK)侧重于指导实践者如何部署MBSE。MagicGrid提供一个框架，随着您的建模
和系统工程实践深入，该框架可以很容易地被采用、部署和剪裁。这本书教你如何使用CATIA®Magic软件设计
和优化当前和未来的系统和产品。这是多年研究的成果，我很自豪地用达索系统(Dassault Systèmes )名义来
支持这项努力。

感谢所有让这一切成为现实的魔法师(Magicians)，特别是我们的行业流程顾问团队，他们与客户进行了
长时间的学习、消化、开发和培训这个框架。我还要感谢我们的合作伙伴和客户，他们在发布之前对这项工作
进行了同行评审。

——Olivier Sappin, CATIA首席执行官

达索系统公司
前言: AURELIJUS MORKEVIČIUS
MagicGrid BoK是一种独特的、基于模型的系统工程体验。这本书描述了从A到Z开发系统模型成千上万种
可能的直接方法中的一种。它回答你可能提出的所有问题，从“为什么”开始，以“如何”结束，但当今可用
的信息源很少能回答的这些问题。

当我10年前开始做MBSE培训和咨询时，我首先想到的是，业界缺乏使用SysML语言开发系统模型的明确方
法。每个客户开发的模型都不同。此外，每个顾问都使用不同的方法来培训客户。SysML曾经(现在仍是)因为客
户在使用中不得其法而受到诟病，这不足为奇。除了在团队中发起内部讨论，并开始以框架的形式收集和总结
我们的经验，以使用某种“教程式的”SysML来架构系统，没有其他方法。首先着眼于框架，然后适配到语
言。我确信这是唯一百分百符合SysML的方法。我们有可能需要扩展和定制；然而，它们并不是必需的。

在收集知识的同时，我与当地一所大学进行了一些科学研究，以证明我的想法是正确的。与我的团队和同
事一起，我写了几篇论文，并在世界各地的各种活动上发表了多次演讲和教程，例如INCOSE国际研讨会，
INCOSE当地分会活动，MBSE网络体验研讨会等等。许多积极的反馈给了我继续致力于《MagicGrid》的信任和
自信。

在与来自不同行业的多个客户合作后，我确信没有一个唯一统一的方法来解决这个问题，也不可能有。每
个行业，每个客户都有自己的特点，我们也考虑到了这一点。MagicGrid已经演化成为最佳实践的基础和集
合，可以对其进行裁剪或扩展以支持每个特定的客户需求。MagicGrid方法论深受INCOSE手册、ISO/IEC/IEEE
15288、统一架构框架(Unified Architecture Framework UAF,以前称为UPDM)和开发工作的影响。激励我们努
力的公司包括庞巴迪运输公司、康斯伯格国防和航空公司、福特汽车公司、约翰迪尔公司、BAE系统公司，以
及近年来和我共事的团队成员同事们一直合作的许多其他公司。

我很自豪的是，除了MagicGrid框架之外，我们还设法将一个详细的循序渐进的教程与之融合在一起，并
以书籍和电子书的形式出版。请注意，这本书只有在你的帮助下才能变得更好。请不吝赐教，联系我们并提供
您的反馈，以使这本书的第二版更好。

我希望这本书能成为所有MBSE实践者在黑暗中航行的灯塔；阳光中航行的微风。

——Aurelijus Morkevičius博士
达索系统公司
本书的贡献者
Armonas, PhD, andrius.armonas@3ds.com

Barry Papke, barry.papke@3ds.com

Daniel Brookshier, daniel.brookshier@3ds.com

Edita Milevičienė, edita.mileviciene@3ds.com

Elona Paulikaitytė, elona.paulikaityte@3ds.com

Gintarė Kriščiūnienė, gintare.krisciuniene@3ds.com

Osvaldas Jankauskas, osvaldas.jankauskas@3ds.com

Rokas Bartkevičius, rokas.bartkevicius@3ds.com

Ronald Kratzke, ronald.kratzke@3ds.com

Saulius Pavalkis, PhD, saulius.pavalkis@3ds.com

Solange Muhayimana, solange.muhayimana@3ds.com

Thomas Marchand, thomas.marchand@3ds.com

Tomas Juknevičius, tomas.juknevicius@3ds.com

Žilvinas Strolia, zilvinas.strolia@3ds.com

本书的评审者
Andrew Terbrock
Antonio Tulelli
Arnaud Durantin
Atif Mahboob
Bernhard Meyer
Bryan K. Pflug
Carmelo Tommasi
Kris Gough
Christian Guist
Christian Konrad
Damian Delic
Darius Šilingas
David D. Walden
David Hughes
Jeff Tipps
Jon Symons
Gauthier Fanmuy
Himanshu Upadhyay
Holger Gamradt
James Towers
Jonathan Jansen
Macaulay Osaisai
Michael Schneider
Michael Elliot
Oliver Nagel
Olivier Casse
Paolo Neri
Pierfelice Ciancia
Piotr Malecki
Prem Sharma
Raymond Kempkens
Robert Marino
Sagar Nirgudkar
Shelley Higgins
Sven Degenkolbe
Thomas Eickhoff
Timo Wekerle
Toshihiro Obata
Ulf Koenemann
Zackary Bogner
前言
为什么写这本书呢?

任何理论都需要付诸实践。当一种方法与如何在实践中使用它的完整指南一起提供时，它就变得有用了。
CATIA®No Magic推出的基于模型的系统工程 (MBSE)的MagicGrid框架也不例外。这就是我们决定写这本书的主
要原因。

所以，如果你是MBSE的新手，或者想要从头到尾学习MagicGrid框架，这本书就是为你准备的。如果你想
学习如何使用MagicGrid并结合CATIA Magic软件与OMG®系统建模语言(SysML)™来实践MBSE，这本书也是为你准
备的。如果你想通过对一个简单熟悉的真实系统建模的示例来获得全面的指导，这本书同样适合你。

如果你熟悉UML/SysML和CATIA Magic系统工程建模软件的基本概念，这本书对你来说就很容易理解。

本书适用于CATIA Magic如下产品线暨对应角色进行建模实践：

 Magic Cyber-Systems Engineer / Cameo Systems Modeler和Cameo DataHub插件

 Magic Systems of Systems Architect / Cameo Enterprise Architecture和Cameo DataHub 插件

 Magic Software Architect / MagicDraw、SysML插件和Cameo DataHub插件)

为什么是MagicGrid?

MagicGrid是理论和实践之间的桥梁，将MBSE的三个主要组件—方法、语言和建模工具—结合在一起。

在与来自不同行业部门(如国防、汽车、航空航天和医疗保健等)的公司合作时，产生了为MBSE开发新框架
的想法。他们需要一种明确的方法来使用SysML语言开发系统模型，这是由国际系统工程理事会(INCOSE)定义
MBSE的关键使能器。然而，当时市场上有很多MBSE的方法，但现有的方法过于抽象，无法解决现实问题。实践表
明，每个行业和每个客户都有自己的特点，不能在没有进行任何裁剪或扩展的情况下使用一种标准方法。

MagicGrid框架是通过总结大量实施MBSE项目的经验而演化出来的，可以裁剪或扩展以支持特定客户需
求，被看成是最佳实践的基础和集合。

该框架在实践中是完全适用的，原因如下：

 它完全与标准SysML兼容，这意味着不需要对标准SysML进行扩展。
 它清楚地定义了基于系统工程过程的最佳实践的建模过程。
 它是独立于工具的，只要工具支持SysML，就可以适配这个实践。
MagicGrid 101

正如标题所揭示的，MagicGrid框架可以表示为Zachman风格的矩阵(见下图1)，旨在建模过程中指导工程
师并回答他们的问题，如“如何组织模型?”，“什么是建模工作流?”，“在工作流的每个步骤中应该产生什
么模型工件?”，“这些工件是如何连接在一起的?”等等。

图1

如您所见，该框架为开发目标系统(System Of Interest, SOI)定义了问题域、解决方案域和实现域。每

个域都表示为MagicGrid框架下的单独行。代表问题域的行被分成了两部分，以表示问题域应该通过从黑盒和
白盒两个角度来观察目标系统。代表解决方案域的行被分成许多内部行，表示可以在多个颗粒度层指定系统的
解决方案结构。代表实现域的行没有被分割，也没有像上面的行那样完全高亮显示，以表示除了实现需求规格
之外的所有内容都不是MBSE的一部分，因此出现在矩阵范围之外。

每个域的定义都了包含目标系统的不同方面。这些方面与SysML的四个支柱相匹配，即需求、结构、行为
和参数(也称为参数化)；另外，在本版本中增加了安全和可靠性角度。它们被表示为矩阵的列。

某行和列相交的单元格表示系统模型的视角，该视角可以包含一个或多个表示工件。表示工件可以是一个
视图，包括可以用于建模的元素、矩阵、映射或表。

尽管没有在框架中明确表示，但可以为单个问题提供多个解决方案架构。在这种情况下，将执行权衡分
析，以选择目标系统实现的最优解决方案。
符合ISO/IEC/IEEE 15288

在详细探讨MagicGrid之前，重要的是要揭示它是如何满足ISO/IEC/IEEE 15288定义的整个系统工程生命
周期的。

MagicGrid实际上只覆盖ISO/IEC/IEEE 15288中技术相关的流程。

任务或任务分析过程被认为是MagicGrid的问题域的输入，通常情况下会通过其他技术进行描述，如
OMG®Unified Architecture Framework (UAF)®，我们可以使用相同的CATIA Magic工具以及之前提到的MagicGrid
框架开发系统。

MagicGrid框架的问题域涵盖了整个涉众要求和需求定义过程。其中对应的子流程如下：

 涉众要求定义子流程映射到MagicGrid的涉众要求Stakeholder Needs单元。
 运行概念和其他生命周期概念开发子流程映射到系统上下文、用例和有效性度量（System Context,
Use Case Measures of Effectiveness (MoEs)）单元。
 涉众要求到涉众需求转换子流程映射到概念子系统、功能分析和子系统有效性度量（Conceptual
Subsystems, Functional Analysis, MoEs for Subsystems）单元。
系统需求定义过程在系统需求单元中执行，可以在子系统需求和组件需求单元中进行扩展。

在系统需求完成之后，架构定义过程就开始了。在MagicGrid中，除了系统需求和子系统需求单元外，它
涵盖了解决方案域的所有系统级和子系统级单元。架构定义过程还包括组件级单元，但只是部分被覆盖。组件
级单元还覆盖了设计定义流程。这是架构与设计相交的地方，或者换句话说，MBSE满足基于模型的设计
(MBD)，并且执行评估架构候选子流程的活动。架构权衡后，设计定义过程就开始了。

最后，根据所选择的实现技术实践，使用对应的技术专长或学科，实现过程将需求、架构和设计转换为创
建系统元素动作。这部分内容映射在MagicGrid的实现域中，如图2 所示。

图2
案例研究

在本书中，建模框架应用于车辆空气调节单元(Vehicle Climate Control System,VCCS)的系统规格和架

构设计中。技术准确性和实际解决方案的可行性不是优先考虑的问题。

如何阅读这本书

重要的是要理解，这本书不会取代建模工具自带相关文档。它的目的是给予补充和加强。

该书的目录结构与MagicGrid框架布局相对应。分为三个主要章节，每个章节描述一个领域内的建模工作
流。这三个域是问题域(包括黑盒视角和白盒视角子章节)、解决方案域(包括对应于创建解决方案域模型的不
同阶段的子章节)和实现域。

每个章节包含子章节，而子章节由多个节段组成，每个节段都以MagicGrid框架的相关单元(cell)命名。
这些单元格的顺序定义了建模工作流。每个节段都包括对单元的简要概述，以解释在该单元中建模的目的、谁
负责以及如何建模。它还为建模人员提供了基本操作步骤列表。每个步骤都在相关的子节中进行了描述，小节
提供了问题的答案，如“要做什么?”、“为什么要这样做?”，以及“怎么做?”。基于这些操作指南，读者可
以据此自己创建VCCS的示例模型。如果您的建模工具是CATIA Magic系列，且版本是2021x或更高，则欢迎您通
过工具自带的名为“VCCS (MG BoK v2 Sample).mdzip”示例模型进行学习。

在本书正文中凡是标有 符号的文本框都是用来为向您提供额外的信息，这些信息用于更高效的建模的
提示和技巧，或是对更详细的信息源的引用。

此外，这本书的第二版包括：

 附录A，提供了关于如何使用安全和可靠性信息丰富系统模型的完整说明。
 附件B，它提供了在基于模型的环境中从体系到单个系统架构进行转换的详细描述。
所有的关键词和首字母缩略词都在术语表中加以定义。

如何提供反馈

我们欢迎读者对这本书或未来版本提供任何反馈。请发送电子邮件至NoMagic.MagicGrid@3ds.com。
 第1章 问题域
问题域主要是对涉众要求（Stakeholder Needs）进行分析，并通过使用SysML模型元素进行细化提炼，以

此在定义环境下的目标系统(System Of Interest, SOI)中获得对功能（Function）清晰一致的描述。

如下图所示，问题域分析分为两个阶段进行。在第一阶段，目标系统被认为是一个黑盒子。主要关注的是
它如何在不了解其内部结构和行为的情况下与已定义的环境相关方进行交互（例如：进行目标系统的运行分
析)。在第二阶段，打开黑盒，从白盒的角度分析目标系统，这有助于理解目标系统的预期行为和概念结构（例
如进行进行目标系统的功能分析)。还需要注意的是，问题域定义不关注目标系统的逻辑或物理架构的定义。

正如您在下面的图1-1中所看到的，问题域定义的两个阶段都从目标系统的需求、结构、行为和参数进行分
析。唯一的区别是分析问题时角度的不同；

图1-1

1.1 黑盒视角
问题域分析首先从黑盒的视角来分析目标系统应该做什么来满足涉众要求的期望；这一阶段的目标是理解
目标系统如何与其环境交互以解决面临的挑战。由于目标系统被认为是一个黑盒，所以分析并不关注其内部结
构和行为。执行分析是为了在各种系统上下文环境中，定义目标系统的主要键入和输出、黑盒功能以及可量化
的特征对象。
 下页描述了在黑盒视角，如何使用SysML模型进行问题域的定义，如图1-2。

图1-2

1.1.1 涉众要求

1.1.1.1 它是什么?

单元格（Stakeholder Needs）表示从目标系统的各涉众方收集的信息。这些信息包括主要用户需求、系
统相关的政府法规、行业标准、政策、程序和内部指南等。

涉众要求可以通过采访涉众方，问卷调查，小组讨论，或者研究不同格式编写的文档来捕获需求。虽然这
些信息是原始的，但不需要特别重写。然而，它需要在问题域模型的其他单元中进行分析和细化提炼。完成分
析和提炼之后，通过创建可追溯矩阵建立起问题域提炼模型同涉众要求之间的追溯关系（详情参见1.2.4追溯到
涉众要求章节），并且这些提炼的模型将作为指定系统需求的基础（参见2.1.1系统需求章节）。

1.1.1.2 谁负责？

涉众要求的获取和分析可以由需求工程师或业务/任务分析师来完成。
1.1.1.3 如何建模 ?

涉众要求可以在建模工具中直接捕获，或者从其他工具或格式文档导入，包括:

 需求管理工具（例如：Requirement Engineer (TRM)(从19.0 SP4版本起)， IBM®Rational®DOORS®)

 电子表格(即 Microsoft Excel文件)
 ReqIF文件(包含从其他工具导出的数据，如IBM®Rational®DOORS®，PTC Integrity Modeler,
Polarion®REQUIREMENTS™，或 Siemens Teamcenter)
在建模工具中，单个涉众要求可以被捕获为SysML需求，并且具有惟一的标识号、名称和文本规范。涉众要
求整个列表可以显示在SysML需求表 (见图1-3) 或视图中。涉众要求可以按层次相互关联 (例如，按来源分

组) 。它可以分为两类：功能性和非功能性。这有助于进一步分析涉众要求。

图1-3

1.1.1.4 教程

步骤1:涉众要求模型组织
一个组织良好的模型更容易阅读、理解和维护；因此，建议将创建的模型组织到包中。SysML模型中的
Package包与文件系统中的文件夹非常相似；通常文件夹用于组织文件 (包括其他文件夹) ，而包用于组织图和
元素 (包括其他包) 。

根据MagicGrid框架的设计，捕获的涉众要求模型元素应该存储在包结构下，如下图1-4所示。顶层包表示
域，中层包表示视角，底层包表示单元。

如果您使用MagicGrid v2 QuickStart或MagicGrid v2 Blank，可以跳过这一步（以及建立模型结构的其他

步骤）。 版本建模工具下自带这两个模板结构，并包括一个基于MagicGrid框架的预定义结构。
 图1-4

在包命名中使用数字可以使您保持包在模型树中的顺序。

根据涉众要求组织模型，如下。

1) 右键单击Model包（这是根包的默认名称)，并选择Create Element。
2) 在搜索框中，键入元素类型Package的前两个字母pa，然后按回车键。
3) 键入1 Problem Domain作为新包的名称并按回车键。
4) 右键单击1 Problem Domain包并选择Create Element。
5) 重复步骤2和步骤3，创建名为1 Black Box的包。
6) 右键单击1 Black Box包并选择Create Element。
7) 重复步骤2和步骤3，创建名为1Stakeholder Needs 的包。
步骤2:涉众要求表格创建
在SysML模型中，有许多方法可以捕获涉众要求。你可以直接在模型浏览器中或者在表达视图中（例如，
一个需求图或表格)，或者另一个可以显示需求的视图（例如，块定义图 (block definition diagram，bdd))。在本
教程中，我们使用需求表，因为它是将涉众要求从外部源（如Microsoft Excel 电子表格或
IBM®Rational®DOORS®）导入模型的最佳方法。

值得注意的是，MagicGrid BoK是描述完成任务的一种可能的方法（例如，由于上面解释的原因，我们选择
创建需求表来捕获和显示涉众要求），但这并不意味着您不能用另一种方法来做这件事。对于所有替代方案的
完整描述，请参考建模工具的最新文档。

创建SysML需求表来捕获涉众要求，如下。

1) 右键单击1 Stakeholder Needs 包并选择 Create Diagram。

2) 在搜索框中键入rt，其中r代表需求（requirement），t代表表格（table），然后双击回车，需求表就创建
了。
注意，表是以它所在的包命名的。这个名字也很适合需求表。您只需要从其名称中删除序列
号。

3) 选择1 Stakeholder Needs包并将其拖到表格Criteria区域的Scope框中。从现在开始，每次追加相关包的内容

时，该表都会更新，如图1-5。
 图1-5

步骤3:涉众要求捕获
假设您需要将下列涉众要求捕获到您的模型中,见表1-1

表1-1

＃ 名字 文本
1 Ambient Temperature I want to see the ambient temperature on the screen

2 Comfortable Temperature I'd like to feel comfortable temperature while being in the cabin

3. Desired Temperature It should be a possibility to easily specify the desired temperature

4 Heating & Cooling The unit must be able to heat and cool
5 Energy Consumption I'd like the unit to consume as little energy as possible

6 Manual Control I should be able to start and stop climate control by myself

7 Sound Level Climate control unit in max mode shall not be louder than engine

8 Total Mass Mass of the unit shall not exceed 2 percent of the total car mass

单个涉众要求可以存储为SysML需求，该需求具有惟一的标识、名称和文本规范。

您可以通过以下方法之一将涉众要求导入到您的模型中：

 从模型中直接捕获信息
 从Microsoft Excel电子表格中复制信息
 从Microsoft Excel电子表格中同步信息
 从ReqIF文件导入信息
 从IBM Rational DOORS中同步信息
(1) 从模型中直接捕获信息

模型中直接捕获涉众的需求，如下。

1) 打开步骤2中创建的表（如果尚未打开)。
 2) 在表格的工具栏上，单击Add New，选择Requirement，如图1-6。

图1-6

3) 在新创建的行中，键入表1-1中显示的第一个涉众要求的名称和文本。
4) 重复步骤2和步骤3，直到表中包含所有项，如图1-7所示。

图1-7

可以看到，在SysML需求表中创建的项也会出现在模型浏览器中。

(2) 从Microsoft Excel电子表格中复制信息

如果在Microsoft (MS) Excel电子表格中为您提供了涉众要求列表，您可以通过利用建模工具提供的复制-粘

贴功能，轻松地将此信息转移到SysML模型。

从MS Excel电子表格中复制涉众的需求

1) 打开电子表格并选择要复制到模型中的内容，如图1-8。
 图1-8
2) 复制内容：
 Windows或Linux操作系统下按Ctrl+C键。
 在macOS上按Command+C。
3) 切换到建模工具并打开在本单元教程的第2步中创建的SysML需求表（如果还没有打开的话）。
4) 将内容粘贴到表格中：
 在Windows或Linux操作系统下按Ctrl+V。
 在MacOS上按Command+V。
5) 选择Requirement作为粘贴数据的类型，如图1-9。

图1-9

6) 稍等直到涉众要求被粘贴到表中，见图1-10。
 图1-10

(1) 从Microsoft Excel电子表格中同步信息

将涉众要求从MS Excel电子表格转移到SysML模型中的另一个选择是使模型与电子表格内容同步。

从MS Excel电子表格同步涉众要求

1) 打开步骤2中创建的需求表（如果尚未打开）。

可以看到，复制到SysML需求表的项也会出现在模型浏览器中。

2) 在表格工具栏中，单击 然后选择Excel/CSV File > Select File。

3) 在Excel/CSV Sync Options同步选项对话框中，从文件系统中选择MS Excel文件，如图1-11。

图1-11

4) 单击Details展开对话框，如图1-12。
5) 将SysML需求表的列映射到MS Excel电子表格的列。为此，请执行以下操作：
a. 选择左侧的一列，并将其拖动到右侧的相关列。
b. 释放鼠标。
 图1-12

建模工具可能要求您在设置映射之前刷新对话框。因此，如果您在对话框底部看到此通知，请单击
Refresh，如图 。

6) 单击OK。
7) 当系统提示出现在建模工具窗口的右下角时（如下图1-14），单击Read from file。

图1-14
8) 当涉众要求与需求表同步数据时请耐心等待，同步完成后，相应的提示将显示在右下角。
 与 需求表同步的项目也会出现在模型浏览器中，如图

图1-15
如您所见，表中的所有项目都用绿色高亮显示。上面的图例（Legend）显示，所有新项目都像这样高
亮显示。您可以更改图例的颜色或从表中隐藏图例。这一点，以及更多关于使用图例（Legend）的信息，可以
在建模工具的文档中找到。

(2) 从ReqIF文件导入信息
有时候，涉众要求是通过使用以下工具来收集的：

 IBM®Rational®DOORS®
 PTC integrity modeler
 Polarion®REQUIREMENTS™
 Siemens Teamcenter
 DS ENOVIA Requirement Engineer(TRM)
在这种情况下，需求管理工具和建模工具之间的信息可以通过需求交换格式（ReqIF）文件进行传输。因
此，将涉众要求捕获到模型的过程如下：

1) 从需求管理工具导出需求为ReqIF文件。
2) 在建模工具中将ReqIF文件导入为SysML模型，如图1-16。

图1-16

我们跳过第一步，假设已经有ReqIF文件。

从ReqIF文件导入涉众要求,如下。

1) 从主菜单中选择File>import from > Requirements Interchange Format (ReqIF) File。

2) 选择文件系统中的ReqIF文件并单击Open。
3) 在Select Package for New Data对话框中，选择您想要存储导入Stakeholder Needs的包中（即：包1
 Stakeholder Needs），如图1-17。

图1-17

4) 单击OK。
5) 当涉众要求被导入到1Stakeholder Needs的包后，等待一会。由于该包是SysML需求表的范围（请参阅步骤
2），所有导入的项也会出现在表中，如图1-18。

图1-18

(3) 从IBM Rational DOORS中同步信息

如果从IBM®Rational®DOORS®项目中收集涉众要求（见下图1-19），可以通过同步DOORS和建模工具之
间的数据，将它们导入SysML模型。

建模工具只有在安装了Cameo DataHub插件后才能与DOORS同步。
 图1-19

在本教程中，我们假设DOORS仅用于捕获涉众要求，并在SysML模型中执行进一步的分析。出于这个原
因，我们需要在DOORS和建模工具之间建立单向同步。在单向同步中，条目信息从DOORS复制到建模工具，但
没有条目信息从建模工具复制回DOORS。

尽管下面定义了与IBM® Rational® DOORS® Next Generation 6.x同步的步骤。也可以同步IBM®

Rational® DOORS® 8.0-8.3和9.0-9.6以及IBM® Rational® DOORS® NG4.x/5.x的需求。

从DOORS NG 6.x同步涉众要求到建模工具，如下。

1) 确保您在建模工具上安装了Cameo DataHub Plugin 19.0或更高版本。

2) 连接到DOORS NG 6.x库：
在建模工具的主菜单中，选择 Tool> DataHub > DataHub Explorer。Cameo DataHub Explorer面板在建
模工具窗口的右侧打开。

在打开面板的工具栏上，单击Add Data Source按钮，见图1-20。

图1-20
 键入所需信息后，单击Create，如下图1-21所示。

图1-21

等待建模工具连接到DOORS NG 6.xd的库。操作完成后，会在Cameo DataHub Explorer面板树显示

DOORS存储库中的项目 （像包一样）。其中一个项目是VCCU Project (Requirement) ，见图1-22。
图1-22

3) 同步数据：
在Cameo DataHub Explorer面板树中，选择1 Stakeholder Needs包，并将其拖到建模工具窗口左侧的模型
 浏览器中的1 Black Box 包中。

在这种情况下，您应该忽略在本单元步骤 中创建的内部包1 Stakeholder Needs。如果您决定

忽略此建议，并将涉众要求项一个一个地拖到包1Stakeholder Needs中（不管CCU Stakeholder

Needs 包），请记住，您有可能会丢失随后将在DOORS项目中创建的项。在这种情况下，只
有个别项目是同步的，而不是整个项目。

在开放对话框中，执行以下操作，见图1-23:
a) 单击One-way Synch to Cameo Systems Modeler以选择同步方向。
b) 指定映射关系：
 Folder 到 Package
 Requirement 到 Requirement
c) 单击OK按钮。

图1-23

等待同步完成的消息。两个树中的同步项都被标记为S（见下图1-24）。
4) 展开1 Black Box包的内容，并查看Stakeholder Needs包及所有导入模型的数据。

“S”表示已同步数据，“ ”表示同步源。当您选择了One-Way Synch to Cameo Systems Modeler

时，DOORS NG 6.x成为同步的单一源。
 图1-24

如果涉众要求是从外部需求管理软件（例如，IBM®Rational®DOORS®）同步而来的，这并不适用，
因为在SysML模型中所做的所有更改将在常规同步之后被覆盖。在这种情况下，涉众要求的分组、编
号和分类应该在需求管理工具中完成。

步骤4: 涉众要求分组
在您的模型中导入涉众要求之后，可以根据它们的特征将它们分组。这些组可以是与系统相关的政府法
规、用户需求、行业标准或业务需求等等。

为了对涉众要求进行分组，您需要创建额外SysML需求元素，每个元素代表一组涉众要求，通常称为分组需
求。分组需求本身可能没有任何文本，只有唯一的标识号和名称。

现在让我们分析模型中的车辆空气调节单元的涉众要求。实际上，它们中的大多数是用户要求，因此可以
分组到User Needs需求之下。被捕获为Total Mass的涉众需求听起来像一个设计约束。出于这个原因，它应该出
现在Design Constraint 需求分组下。还可以创建名为Stakeholder Needs的顶层分组需求，以体现需求层次结构。

对涉众要求进行分组,如下。

1) 创建User Needs需求:
在模型浏览器中，右键单击1 Stakeholder Needs包并选择Create Element。
在搜索框中，键入re -需求类型的第一个字母，并按回车键。一个新的需求类型元素被创建。
键入User Needs作为新建需求的名称，并按回车键。
2) 在模型浏览器中，选择除Total Mass需求（列表中的第一个项）和User Needs需求（列表中的最后一个
项）之外的所有条目，见图1-25。
 如果要选择树中相邻的一组需求项，单击第一个需求项，同时按Shift，选择最后一个需求
项。

图1-25
3) 将所选需求拖到User Needs需求内（如下图1-26左），它变成了一个分组需求（如下图1-26右）。

图1-26
4) 重复步骤1以创建Design Constraints需求。
5) 选择Total Mass 需求并将其拖到Design Constraint需求上。后者成为一个分组需求。
6) 重复步骤1以创建Stakeholder Needs需求。
7) 选择分组需求：User Needs和Design Constraint。
8) 将选择的需求拖到Stakeholder Needs需求上，见图1-27。它成为顶层分组需求。同时可以查阅SysML需求
表中对应的更改。

确保该表以紧凑树模式（Comact tree mode）显示。为此，单击表格工具栏上的选项按钮

，然后选择Display Mode > Compact Tree。
 图1-27

步骤5：涉众要求编号

如果涉众要求是从外部软件同步而来的，并用于需求管理（例如，IBM®Rational®DOORS®），这并不
适用在建模工具下做需求编号，因为在SysML模型中所做的所有更改将在常规同步之后被覆盖。因
此，涉众要求的分组、编号和分类应该在需求管理工具中执行。

我们用来捕获和存储涉众要求的SysML需求模型可能有层级编号。另外层级编号不应该与唯一标识符混
合，因为唯一标识符是不会被更改的。

涉众要求默认使用从1到无穷大的自然数进行编号。为了将涉众要求与系统或实现需求区分开来，我们建议
用特殊的前缀对它们进行编号(例如： SN-，其中S代表涉众方，N代表需求)。

在将涉众要求组织成组之后，他们的编号就变得不准确了，就像需求表中的需求编号从11开始，接下来我
们需要修复这个问题。

用前缀SN-对涉众的需求进行编号，如下。

1) 在模型浏览器中，右键单击Stakeholder Needs（顶层分组需求)，并选择Element Numbering。然后Element

Numbering对话框被打开。
2) 在对话框中，单击Prefix列的空值单元格开始编辑，键入SN-（见下图1-28），然后按回车键。Stakeholder
Needs的层次编号更新为SN-11。
 图1-28

3) 如果还没有看到更多选项，请单击Details查看更多选项。
4) 单击勾选Renumber From Initial Value复选框。
5) 单击Renumber Recursively按钮，涉众要求的每一项都用前缀SN-编号从1开始。

如果您想要确保所有项目都重新编号，请展开对话框左侧的模型树，以查看VCCU涉众要求
的整个层次结构,见图1-29。

6) 单击OK，关闭对话框。

图1-29
步骤6：涉众要求分类

如果涉众要求是从外部软件同步而来的，并用于需求管理（例如，IBM®Rational®DOORS®），这并不
适用在建模工具下做需求编号，因为在SysML模型中所做的所有更改将在常规同步之后被覆盖。因
此，涉众要求的分组、编号和分类应该在需求管理工具中执行。

涉众要求可以是功能性的，也可以是非功能性的。功能涉众要求指定目标系统期望做什么。它们被用例和
用例场景进一步细化（参见1.1.3用例章节）。识别目标系统SoI可量化特征的非功能性涉众要求通过有效性度
量得到了细化提炼（参见1.1.4有效性度量章节）。

分类有助于进一步分析涉众要求，特别是在处理大量的信息时。如果情况不适用，可以跳过此步骤。

虽然非功能性涉众要求可以捕获为SysML需求，但功能性涉众要求应该转换为SysML功能性需求。用技术术
语来说，功能需求（包括接口、性能、设计和其他更具体的需求，这些需求到目前为止还不需要）是需求的一
个子类，并继承了需求的所有特性。

在给定的示例中，大多数涉众要求（除了Sound Level, Energy Consumption, 和 Total Mass）是功能性的。

因此，应该将它们重构为SysML功能需求。

将SysML需求转换为功能需求

1) 在模型浏览器或需求表中，选择除sound level、energy consumption和Total Weight以外的所有需求。

如果要选择树中一组不相邻的条目，请按住Ctrl键逐个鼠标左键单击。

2) 右键单击选择，然后选择Refactor > Convert To > More Specific > Functional Requirement，见图1-30 。

图1-30

然后，所有的需求都被转换成功能需求，并且每个元素图标上显示的是F而不是R，见图1-31。
 图1-31

1.1.1.5 完成涉众要求，下一步做什么?

 对涉众要求进行分析，以确定系统上下文环境（参见1.1.2系统上下文章节）。
 功能涉众要求通过用例和用例场景进一步分析和细化提炼（参见1.1.3用例章节）。
 非功能性可量化的涉众要求可以通过有效性度量来细化（参见1.1.4有效性度量章节）。

1.1.2 系统上下文

1.1.2.1 它是什么?

系统上下文（或运行环境）确定系统的外部视图。系统上下文引入了所有不属于系统但与系统交互的外部
实体。可以为单个目标系统SoI定义多个系统上下文。除了系统本身（目前被认为是一个黑盒），特定系统上下
文中的元素集合还可以包括外部系统（自然的或人工的）和用户（人、组织），它们与目标系统SoI交互以交换
数据、物质、能量，甚至人力资源。

总的来说，该单元包含以下步骤：

 系统上下文的定义

 每个系统上下文的参与者：目标系统、系统的假定用户、其他系统等等。

 每个系统上下文的参与者之间的交互

 在这些交互中交换的项

1.1.2.2 谁负责？

系统上下文可以由系统分析师或系统工程师识别和定义。

如何建模?

系统上下文图主要描绘了位于中心的目标系统SoI，没有内部结构的细节，被它所有相交互实体所包围，例
如假定的用户和外部系统等等。在SysML模型中，可以将系统上下文捕获为SysML块类型的元素。所有实体也可
以被捕获为SysML块。正如SysML所定义的，系统上下文中使用实体块定义之后，后将创建一个由之前系统上下
文块为类型的部件属性。
 我们建议使用块而不是参与者（stick man人符号）来捕获甚至是人 自然实体（例如，SoI的用户 ，
因为参与者actor不能是SysML模型中的系统上下文环境的一部分见图

SysML内部块图（ibd）可以用来表示特定系统上下文的实体，以及它们之间的交互。每个实体都表示
为相关系统上下文块的一部件属性。

系统上下文中的交互可以被捕获为连接器，这些部件属性之间存在一个或多个项流。数据、物质或能量都
是可以作为流动的项。它们可以作为信号、块或值类型存储在模型中，这取决于它们的性质，并且通常被引用
为交换项。

正如您在下面的图1-33中所看到的，系统上下文图可以用各种图片作为补充，以可视化结果可以呈现
给涉众，包括那些对模型知之不多的人。

图1-33

1.1.2.4 教程

步骤 组织系统上下文的模型
 按照MagicGrid框架的结构，系统上下文和它们所拥有的SysML内部块图，以及它们所代表的元素，都应该存
储在1 Black Box包中的一个单独包中。我们建议以Magicgrid单元格命名包，即2 System Context，如下图1-34.

图1-34

组织系统上下文的模型,如下。

1) 右键单击1 Black Box包并选择Create Element。

2) 在搜索框中，键入pa（元素类型Package的前两个字母）并按回车键。
3) 键入2 System Context作为新包的名称，按回车键。
步骤2:捕获系统上下文
系统上下文可以通过分析涉众要求来确定（参见1.1.1涉众要求章节）。车辆空气调节单元Vehicle Climate
Control nit的涉众要求使您能够识别单个上下文:Vehicle In Use。它可以作为SysML块类型的元素在模型中捕获。
创建一个Block（块）模型元素来捕获Vehicle In Use系统上下文，如下。

1) 右键单击2 System Context包并选择Create Element。

2) 在搜索框中，键入bl（所需元素类型的第一个字母）并按回车键。
3) 键入Vehicle In Use以指定新块的名称并按回车键。然后块被创建并在模型浏览器中显示。

图1-35

一个重要的事情是目标系统SoI可能在多个系统上下文中运行。为了说明这一点，我们需要捕获另外一个系
统上下文。在本例中，我们将使用Maintenance in Vehicle（见下图1-36）。您可以按照上面的过程自行创建相
应的块。
 图1-36

最新捕获的系统上下文没有包含进一步分析。它没有在涉众要求中被提及，在这里只是为了演示目的而创
建的。

步骤3:创建ibd图描述系统上下文

要指定Vehicle In Use系统上下文的参与者，首先需要为该系统上下文块创建一个SysML内部块图。

要为Vehicle In Use块创建IBD，如下。

1) 右键单击Vehicle In Use块并选择Create Diagram。

2) 在搜索框中，键入ibd （SysML内部块图的首字母缩写），然后双击回车键。视图被创建并出现在Vehicle
in Use块下的模型浏览器中。

视图名字默认和所在block同名。以Vehicle in Use 命名ibd图非常适合此场景，所以不需要重

命名它，如下图 。

图1-37

步骤4:捕获系统上下文的参与者

参与系统上下文环境的实体可以作为该系统上下文的部件属性在模型中被捕获，其中每个部件属性类别都
是捕获的对应实体的块，（例如目标系统SoI，它的上下文参与者是用户或某些外部系统）。
 这里，您应该记住SysML规范，它告诉您应该使用块来定义概念，使用部件来指定这些概念的用法。
一旦在模型中定义了任何概念，就可以在许多系统环境中使用。例如，Vehicle Climate Control Unit
SoI被定义为一个块，可以使用其为Vehicle in Use系统上下文中部件属性的类别，也可以使用其为
Vehicle in Maintenance系统上下文中部件属性的类别，这意味着它同时参与了这两种使用场景。

涉众要求表明，Vehicle In Use包括以下参与者：

 Vehicle Climate Control Unit 即目标系统

 Vehicle Occupant (司机或乘客)， 目标系统的使用者
 Vehicle Cabin，封闭的环境，必须提供舒适的空气温度
 Temperature Sensor,为目标系统提供环境温度的外部系统

捕获Vehicle in Use系统上下文的参与者，如下。

1) 如果尚未打开，请打开本单元教程步骤3中创建的ibd。
2) 确保在视图中开启类型选择模式Type Selection Mode 如图1-38，否则，在此图中创建的部件将不会对应块
类型。

在此模式下，当您创建部件属性时，工具会提供一个块列表，您可以从中选择部件属性类型。如
果所需的块还不存在，您可以直接在部件属性上输入它的名称来创建它

图1-38

3) 单击视图面板上的Part Property按钮，然后单击视图编辑区上的空白位置。创建一个未命名的部件属性，并
提供该属性可选类型的现有块的列表。
 图1-39

当启用类型选择模式时，部件属性上输入的始终是定义的新块名。该新块是部件属性的类
型，而不是部件属性的名称。如果您还想指定名称，请在形状上的冒号 之前输入它。但是，

名称不是必须的，因为在此图中创建的部件属性可以很容易地通过它们的类型识别。当您希望指
定同一块的多个用法时（例如，车辆的左前轮、右前轮、左后轮和右后轮），名称是很有用的，
见图 。

图1-40

4) 直接在部件属性上输入冒号（“ ：”）右边键入VCCU，然后按回车键。刚刚创建的部件属性的类型
VCCU块出现在模型浏览器中,如图1-39。
5) 重复步骤3和步骤4创建其余的部件属性：一个键入类型为 Vehicle Occupant块，一个键入类型为Cabin块，
另一个键入类型为Temperature Sensor块。

由于您需要连续创建多个部件属性，请使用Sticky按钮的功能（见下图 ），因此每次您想

创建一个新的部件属性时，都不需要单击面板上的part property按钮。当启用Sticky模式时，您可
以根据需要创建所选类型的任意多个元素。完成后按Esc。

当您完成时，您将拥有四个部件属性和相同数量的块，这些块是您在模型中键入名字而创建的，见图1-
42。
 图1-42
为了保持模型的良好组织架构，我们建议将捕获用户和其他系统的块存储在2 System Context 包下的一个
单独的包中。为此，您需要创建一个内部包，然后按住Shift键选择多个块，并将块拖动到模型浏览器中的新位
置，见图1-43。

图1-43

步骤5:指定系统上下文参与者之间的交互

涉众要求表明，在Vehicle in Use 的系统上下文中，车辆空气调节单元会与所有参与者进行交互。因此，我

们需要在模型中捕获这些信息。

请记住，可以将交互指定为对应部件属性间带一个或多个项流的连接器。我们将从绘制连接器开始。
 在VCCU 和Vehicle Occupant部件属性之间绘制一个连接器，如下。

1) 选择 :VCCU部件属性，在它的智能操作工具栏上单击Connector按钮 。
2) 选择 :Vehicle Occupant部件属性，连接器被创建，如图1-44。

图1-44
您可以使用相同的方法创建其他连接器。完成之后，您的ibd图看起来应该与图1-45非常相似。

图1-45

步骤6. 添加系统上下文项流

首先，我们需要能够通过连接器从一个部件属性流向另一个部件属性的项。我们建议将捕获这些项的元素
存储在一个单独的包中（参见下图1-46）。这个包的内容也将在白盒分析模型中使用。因此，不要直接在2
System Context包（它是黑盒分析模型的一部分）下创建新包，而是在1 Problem Domain包下创建它。

图1-46

如果我们假设您已经自己创建了3 Exchange Items包（包号是3，因为2号将用于White Box包），那么我们可

以直接创建项流，并将其分配给连接器。可以在单个连接器上分配一个或多个项流。

涉众要求指明：

 Vehicle Occupant shall be able to turn the VCCU on and off, and specify the desired temperature （参见 SN-
1.1.2, SN-1.1.6）

 VCCU shall provide a comfortable air temperature for the Vehicle Occupant sitting in the Cabin (参见SN-
1.1.7)

 VCCU shall obtain the ambient temperature from the Temperature Sensor of the vehicle (参见 SN-1.1.5)

 VCCU shall display status and temperature information (参见 SN-1.1.5)

这些语句使您能够识别下列交互项：

 User Command

 Desired Temperature

 Air

 Comfortable Air

 Ambient Temperature

 Information

空气Air和舒适的空气Comfortable Air是物质；因此，它们可以在模型中被捕获为块。其余的项可以捕获
为信号，因为它们表示数据。

捕获模型中的用户命令User Command、所需温度Desired Temperature和信息Information，并将它们指定

为:VCCU和:Vehicle Occupant部件属性之间的传递的项流，如下。

1) 右键单击3 Exchange Items包并选择Create Element。

2) 在搜索框中，键入si （元素类型Signal的前两个字母）并按回车键。
3) 键入User Command指定新信号的名称并按回车键。
4) 将信号拖动到:VCCU和: Vehicle Occupant部件属性之间的连接器。
5) 在打开的对话框中，选择From Vehicle Occupant to VCCU作为流的方向，然后单击Finish。一个传送User
Command信号的项流被创建并显示在连接器上。
6) 重复步骤1到3创建Desired Temperature信号。
7) 将信号拖动到同一个连接器。
8) 在打开的对话框中，选择From Vehicle Occupant toVCCU作为流的方向，然后单击Finish。一个传递
Desired Temperature信号的项流被创建并显示在连接器上。
9) 重复步骤1到3创建Information信号。
10) 将信号拖动到同一个连接器。
11) 在打开的对话框中，单击Finish。将创建一个传递Information信号的新项流并显示在连接器上，如图1-
46。
 图1-47

以同样的方式，您可以捕获其余的交互项，然后在Vehicle In Use ibd图中的其他连接器上指定项流。一旦

完成，你的ibd图看起来应该和下面的非常相似，如图1-48。

图1-48

正如您在下图1-49中所看到的，系统上下文图可以用各种图像加以补充，以便结果可以更好地呈现给涉
众，甚至包括那些不能阅读模型的人。有关更多信息，请参阅建模工具的最新文档。
 图1-49

1.1.2.5 完成系统上下文，下一步做什么?

 系统上下文用于分析目标系统SoI的预期行为（参见1.1.3用例章节）。行为分析从识别目标系统的用
例开始，每个用例都属于该目标系统的一个或多个系统上下文。
 作为系统上下文的部件属性捕获的每个系统上下文的参与者也在用例单元中使用。并且它们可以在描
述用例场景的SysML活动图中表示为泳道。
 在系统上下文单元中标识的交互项在用例场景中用作对象流和引脚pin类型。
 在捕获目标系统的块创建之后，可以捕获描述非功能性涉众要求的系统的定量特征。因此，接下来可
以进行有效性度量值的分析定义。

1.1.3 用例

1.1.3.1 它是什么?

在这个单元中，用例和用例场景来细化功能性涉众要求。与涉众要求相比，用例更精确地告诉人们期望从
系统得到什么，以及他们想通过使用系统得到什么。每个用例必须属于在系统上下文单元中定义的一个或多个
系统上下文（参见1.1.2系统上下文章节）。

总的来说，该单元产生：

 为用户提供有意义价值的功能用例。
 关于系统如何与用户和/或其他系统交互的用例场景。

1.1.3.2 谁负责？

用例及其场景可以由系统分析人员或系统工程师来定义。

1.1.3.3 如何建模?

在建模工具中，可以通过利用SysML用例图的基础结构来捕获系统的用例。每个用例图都应该考虑在系统上
下文单元中定义的一个系统上下文中进行创建（参见1.1.2系统上下文章节）。用例可以被捕获为用例类型的元
素。

一个用例可以在不同的上下文中执行。执行系统上下文的一个或多个用例的实体应该在用例图1-50中表示
为块。在这里，您应该记住，这些块类型是系统上下文的部件属性。正如下图所示，即使是人，比如vehicle
occupant，也可以表示为块 （可以添加图片）。
 图1-50

我们建议使用块而不是Actor(人形符号)来捕获甚至是人-自然实体(例如，SoI的用户)，因为Actor不
能是SysML模型中的系统上下文的一部分，如图1-51。

图1-51

每个用例必须有一个名称和主要场景，备选场景是可选的。用例场景可以以SysML活动或时序图的形式捕
获。在活动图中，目标系统、系统的假定用户和/或其他系统可以表示为泳道（活动分区），如图1-52。在时序
图中，它们被表示为生命线。与此同时，目标系统被认为是一个黑盒。
 图1-52

1.1.3.4 教程

步骤1: 组织用例模型

遵循MagicGrid框架的结构，在SysML活动或时序图中出现的用例及其场景，以及它们所表示的元素，应该
存储在1 Black Box包中的一个单独的包中。我们建议以单元格命名包，也就是3 Use Case，如图1-53。
 图1-53

组织用例的模型，如下。

1) 右键单击1 Black Box包并选择Create Element。

2) 在搜索框中，键入pa（元素类型Package的前两个字母）并按回车键。
3) 键入3 Use Cases以指定新包的名称并按回车键。
步骤2:创建用例图

您必须创建一个SysML用例图开始捕获Vehicle In Use系统上下文的用例（参见1.1.2系统上下文章节)。还需
要在视图编辑框中显示捕获系统上下文的块。Vehicle Occupant块（代表目标系统用户）也应该显示在视图编辑
框中。

创建一个视图来捕获在Vehicle In Use中执行的用例，如下。

1) 右键单击3 Use Cases包并选择Create Diagram。

2) 在搜索框中键入uc，其中u代表use， c代表case，然后按回车键键，用例图就被创建了。

如果您有多个系统上下文，我们建议将每个系统上下文的用例存储在一个单独的包中。在当前这
种情况下，不需要。

3) 键入“Vehicle In Use SC”以指定新视图的名称，并再次按回车键，如图1-54。

图1-54
4) 在模型浏览器中，选择Vehicle In Use块。可使用Quick Find功能：
 按Ctrl + Alt + f，Quick Find对话框打开。
键入Vehicle In U。
搜索结果列表中选择Vehicle In Use块，按回车键，如下图1-55所示，在模型浏览器中的Vehicle In Use
块被选中了。

图1-55

5) 将Vehicle In Use块拖动到新创建的用例图编辑区，Vehicle In Use 块出现在视图中，如图1-56。

图1-56
6) 重复步骤4的子步骤，找到Vehicle Occupant块，并将其拖动到该视图编辑区。Vehicle Occupant块也出现
在视图上。
7) 如果关系也显示在视图上，选择它并按Delete键从视图中删除它的符号。当对话框询问您是否想要从模型
中删除关系时，单击No。
8) 选择Vehicle In Use块并拖动符号的右下角以放大它，以便在其中嵌套用例，如图1-57。
 图1-57

正如你在下图1-58中所看到的，Vehicle Occupant块可以显示为你在Vehicle In Use系统上下文的ibd中应用到

该模块上的图片(见1.1.2章节)。为此，选择该块并单击视图工具栏上的Show As Image按钮 。

图1-58

步骤3：捕获用例

通过分析涉众要求，我们可以看到VCCU的主要目标是为车内所有乘员提供舒适的温度。这个目标可以在
模型中捕获为Vehicle In Use系统上下文的Provide Comfortable Temperature用例。让我们在Use Cases of Vehicle In
Use SC 用例图中来捕获它。

捕获Provide Comfortable Temperature用例，如下。

1) 打开在本单元教程步骤2中创建的用例图（如果尚未打开的话）。
2) 单击视图面板上的Use Case按钮，并将鼠标移动到Vehicle In Use块上。
3) 当你看到Vehicle In Use块周围的蓝色边框时，点击。在块下创建了一个未命名的用例。
4) 键入Provide Comfortable Temperature指定此用例名并按回车键。
 5) 双击用例以打开它的Specification，并确保Vehicle In use块被设置为它的subject，如图1-59。

图1-59

6) 选择代表VCCU用户的Vehicle Occupant块，单击关联按钮 ，然后选择Provide Comfortable

Temperature，将这两个元素关联起来，如图1-60。

图1-60

步骤4: 创建用于指定用例场景的视图

用例场景可以在SysML活动或时序图中捕获。SysML活动更适合指定抽象的行为定义，当您需要区分同步
和异步交互时，应该使用时序图。

在本例中，我们选择使用SysML活动图。

为Provide Comfortable Temperature用例场景创建SysML活动图，如下。

1) 在Use Cases of Vehicle In Use SC 用例图中，右键单击Provide ComfortableTemperature用例，并选择Create

Diagram。
 2) 在搜索框中，键入act （SysML活动图的首字母缩写），并按回车键。创建并打开了新的活动图。它和所
在SysML活动同名。

如果您参考显示用例Provide Comfortable Temperature的用例图，您可以看到用例右下角有个叉子( )

图标装饰。这个修饰表示用例包含一个内部视图，即Provide Comfortable Temperature活动图。双击用
例将会打开该内部视图，如图 。

步骤5: 创建泳道和设置分配模式

活动图中的泳道用于表示相关系统上下文的参与者（参见1.1.2系统上下文章节）。它们允许您在模型的结
构部分和行为部分之间建立分配关系。在黑盒分析模型中使用这些关系来指定系统上下文的哪个参与者负责执
行相关用例场景的哪个步骤。

请记住，系统上下文中的参与者被捕获为其部件属性。当您在用例嵌套的活动图中创建泳道时，建模工具
会自动识别并建议您选择嵌套系统上下文下的部件属性。此外，您需要在活动图中启用allocate to usage
mode模式。此模式允许您传递分配关系是考虑到系统上下文而建立的。否则，分配是通用的，与任何系统上下
文无关。

现在，让我们在Provide Comfortable Temperature用例场景中表示Vehicle In Use系统上下文的参与者。

在Provide Comfortable Temperature活动图中创建泳道，如下。

1) 打开在本单元格教程的第4步中创建的活动图（如果尚未打开）。
2) 单击活动图面板上的Vertical Swimlanes按钮，然后单击该视图编辑区的空白区域。
3) 在打开的对话框中，选择Usage (Action allocated to Part) 以启用allocation to usage模式，然后单击OK，如
图1-62。
 图1-62
4) 在Represent Properties对话框中，单击OK 以显示相关的系统上下文参与者，如图1-63。

图1-63

默认情况下，MagicGrid模板中都启用了此模式。

在本例中，对话框总是显示属于相关系统上下文的部件属性列表。从技术上讲，相关的系统上下
文是用例的主题subject，它包含了活动图（参见本单元教程的步骤 ）。

5) 单击对话框上的OK按钮，泳道将出现在视图中。

泳道总是按照从 到 的字母顺序排列，但是按钮 和 （在选择泳道头部时出现）使您能够根

据偏好选择在活动图中重新排列，如图 。

图1-64

当完成该步后，已经准备好可以定义Provide Comfortable Temperature用例场景。

步骤6: 指定用例场景的步骤

在活动图中，用例场景步骤可以捕获为调用行为动作call behavior action。正如SysML所定义的，调用行为

动作call behavior action可能有一个被分配的行为，该行为可以是模型中定义的活动、状态机或交互。如果在模
型中启用了行为创建模式Behavior Creation Mode，则可以创建调用行为动作同时创建行为活动。我们推荐采用
这种模式建模，原因如下：
  指定循环步骤比较容易。因为在模型中创建的任何步骤，作为分配给某个调用行为动作的活动，都可
以被一个或多个活动图中的其他调用行为动作引用。
 当需要分解步骤时，不需要创建引用的活动。它已经被创建并作为行为分配给调用行为动作。
 Activity Decomposition Map不包括调用行为动作。为了确保您拥有用例步骤的整个分解，您需要将它们
捕获为活动。

获取Provide Comfortable Temperature用例场景的步骤，如下。

1) 确保在关系图中启用了Behavior Creation Mode (参见下图1-65)。否则，活动将不会作为行为被创建并分配

给调用行为动作。

图1-65

2) 单击视图面板上的Initial Node按钮，然后在视图面板上的:Vehicle Occupant泳道内空白位置单击。初始节

点Initial Node被创建并显示在活动图上。
3) 在初始节点的智能操作工具栏上，单击控制流Control Flow按钮 ，然后在相同泳道的视图面板上空白
位置单击。创建了一个未命名的操作，同时也创建了一个新的活动，并将这个新活动分配给未命名操
作。
4) 键入Turn on Climate Control以命名活动并按回车键。

请确保在冒号(":")后面输入名称如图1-66。否则，该名称将被赋予动作，而不是被引用的活
动，如图1-67。

图1-66
 图1-67
5) 在新创建动作的智能操作器工具栏上单击控制流Control Flow按钮 ，然后在视图面板上的:VCCU泳道内
的空白位置单击。创建了一个未命名的操作，同时也创建了一个新的活动，并将这个新活动分配给未命
名操作。
6) 记得在冒号后面键入Check System以命名活动 。完成后按回车键。
7) 重复步骤5和步骤6，直到创建下图中所示的动作。
8) 选择Stop Climate Control动作，然后在它的智能操作工具栏上，单击控制流按钮 。
9) 右键单击视图面板上的空白位置并选择Activity Final。final node被创建并显示在图上，如图1-68。

图1-68
现在，让我们把这个流分成两个部分:当系统在检查后可以启动时，是主流程；当系统不能启动时，是可选
流程。为此，我们需要在Check System和Start Climate Control动作之间插入一个决策点decision node，并在活动
最终节点之前插入一个merge node合并节点。

使用可选流程更新用例场景，如下。

1) 单击视图面板上的Decision按钮，然后单击Check System和Start Climate control动作之间的控制流，然后插

入决策点decision node。

在插入新节点之前，可以在视图面板上的现有模型元素之间留出更多空间。要做到这一点，请
单击在视图面板上的pusher 按钮。

2) 选择decision node和Start Climate control活动之间的控制流，键入[OK，并按回车键（自动添加右中括

号）。因此，为该控制流定义了OK（Guard看门狗），并在图中的方括号中显示。
 如果您打开控制流的规格Specification，您可以看到中括号之间的文本被设置为Guard属性值，如
图1-69。

3) 单击视图面板上的Merge按钮，然后单击活动最终节点之前的控制流。
4) 选择decision node, 在其智能操作工具栏上单击Control Flow按钮 ，然后单击merge node，控制流被创
建。
5) 选择该控制流，键入[Not OK，并按回车键。为该控制流定义了Not OK（Guard看门狗），并显示在视图
内的方括号内。
在您完成之后，Provide Comfortable Temperature活动图应该看起来与下图非常相似，如图1-70。

图1-70

在该场景中还必须指定备选流，即乘客可以设定所需的温度，也可以在评估车内舒适度后享受环境温度。
为此，您需要在图中插入另一对决策和合并节点。

用另一个可选流程更新用例场景，如下。

单击视图面板上的Decision按钮，然后单击Evaluate Comfort和Set Temperature动作之间的控制流。插入

了决策点。
选择决策点decision nodes和Set Temperature动作之间的控制流，键入[Not Comfortable，并按回车键。为
该控制流定义了Not Comfortable (Guard)，并显示在图中的方括号中。
单击新创建的决策点的智能操作工具栏上的Control Flow按钮，然后选择Enjoy Temperature动作。一个
新的控制流被创建。
立即给新建的控制流键入[Comfortable ，该guard显示在图中的方括号中。
单击图面板上的Merge按钮，然后单击Start Climate control和Measure Temperature动作之间的控制流。
选择Get Comfortable Air和Enjoy Temperature动作之间的控制流，单击其箭头末端，然后将其拖动到新
创建的合并节点。控制流的目标节点就会被更改。
在您完成之后，您的Provide Comfortable Temperature活动图应该看起来与下图1-71非常相似。

图1-71

建模工具的仿真引擎，基于OMG®Executable UML (fUML)™标准，使您能够验证指定的行为，并查看您的

模型是否正确。要启动仿真会话，请单击在Provide Comfortable Temperature活动图工具栏上的Run按钮 。然

后在Simulation仿真面板中，单击Start按钮 启动模型执行。

到目前为止，我们已经使用控制流连接动作action。在下一步中，我们将指定哪些数据、物质或能量在动
作之间流动。

步骤7: 向用例场景添加项流

现在，我们将用项流更新Provide Comfortable Temperature用例场景，方法是将它们从系统上下文分析期间

创建的Vehicle In use ibd中同步出来（参见1.1.2系统上下文章节）。这有助于识别和消除问题域模型中结构和
行为部分的逻辑不一致，例如存在一个没有出现在任何用例场景中的有问题的项流，或者识别出需要新项流。

在将项流添加到捕获Provide Comfortable Temperature用例场景的活动图之前，我们需要首先查看Vehicle In

use的 ibd图。接下来让我们从:Vehicle Occupant和:VCCU这两个部件属性之间的相互作用开始。我们可以看到，
Vehicle Occupant为VCCU提供控制命令，并设置所需的温度（见下图1-72用橘色高亮圈出来的部分）。

图1-72

在用例场景中，这些信号的项流必须在这些部件属性之间实现传递。请记住，在Vehicle In Use的
ibd图中指定的部件属性在Provide Comfortable Temperature活动图中表示为泳道。并且项流应该由对象流传
递，而不是控制流。因此，我们需要将相关控制流转换为对象流。

创建分配给: Occupant和: VCCU部件属性的动作之间传递的项流—User Command信号，如下。

1) 选择“Turn On Climate Control”和“Check System”之间的控制流。

2) 右键单击选择并选择Refactor > Convert To > Object Flow。然后控制流将转换为对象流，并为这两个操作
创建引脚pin。
3) 在模型浏览器中，在3 Exchange Items 包下，选择User Command 信号。
4) 将信号拖动到“Turn On Climate Control”动作的输出引脚上。User Command类型被设置为输出引脚的类
型。
5) 将信号拖动到Check System动作的键入引脚。User Command类型被设置为键入引脚的类型。

6) 选择对象流，并从它的智能操作工具栏上，单击项流管理器Item Flow Manager按钮 。

7) 在打开的对话框中，选择传递User Command信号的项流(参见下图1-73)。在相关操作之间建立项流。
 图1-73

8) 单击Close关闭对话框。
9) Turn Off Climate Control 和 Stop Climate Control操作间控制流也需要改成对象流，创建pin，设置pin类型
并显示流项，重复步骤1到8。
当您完成时，视图看起来应该与下图1-74相同。

图1-74
 您可能会注意到，引脚pin上只显示它们的类型。为此，请执行以下操作：

按下Alt键并选择任何输入引脚。图中选择了所有输入引脚。
右键单击所选内容，单击Show Name以清除所选内容，然后单击选择
“Show Type”复选框，如图 。

图
重复以上步骤来隐藏输出引脚类型。

创建分配给: Occupant和: VCCU部件属性的动作之间传递的项流-Desired Temperature信号，如下。

1) 选择“Set Temperature”动作，并在它的智能操作工具栏上单击“对象流”按钮 。
2) 点击“Reach Desired Temperature”动作。并为这两个动作创建带有引脚的对象流。
3) 在模型浏览器的3 Exchange Items包下，选择Desired Temperature信号。
4) 拖动信号到 Set Temperature动作的输出引脚。Desired Temperature类型被设置为输出引脚的类型。
5) 将信号拖动到达到Desired Temperature动作的输入引脚上。Desired Temperature类型被设置为输入引脚的
类型。

6) 选择对象流并在它的智能操作工具栏上单击项流管理器按钮 。
7) 在打开的对话框中，选择传递Desired Temperature信号的项流。并将该信号就转换成为对象流中传递的
项。
8) 单击Close关闭对话框。
当您完成时，视图看起来应该与下图1-76相同。

图1-76
 您可能会注意到，引脚不显示其类型，图上只显示项流。这使得视图不那么拥挤，也更容易阅读。
如果你想隐藏引脚的类型，做以下事情

按下Alt键并选择任何输入引脚。图中选择了所有输入引脚。
右键单击所选内容，然后单击Show Type以清除所选项。
重复以上步骤来隐藏输出引脚类型。

使用相同的方法来定义以下内容:
 Ambient Temperature信号在Measure Temperature 和 Display Tempera动作之间流动。并且它是在Vehicle
In Use系统上下文下的:Temperature Sensor和: VCCU部件属性之间传递。
 Air从Provide Air动作传送到Reach Desired Temperature动作。并在Vehicle In Use系统上下文下的:Cabin
和: VCCU部件属性之间传递。
 Comfortable Air块从Reach Desired Temperature动作到Get Comfortable Air动作之间流动。并且它是在
Vehicle In Use系统上下文下的Cabin和:VCCU部件属性之间传递。
 Display Temperature和Evaluate Comfort动作之间流动Information信号。并且它是在Vehicle In Use系统上
下文下的:Vehicle Occupant和: VCCU部件属性之间传递。
完成之后，您的视图应该类似于下图1-77。您可能会注意到这里的所有项流都与在Vehicle In Use 的ibd图
中相同。始终记住，一个精确和完整的模型需要在系统结构和行为之间进行项流同步。由于这个原因，结构模
型中确定的所有交换项都必须考虑到，并包含在行为模型中。

图1-77

现在您可以启动并运行仿真来执行模型并验证指定的行为。

步骤8: 使用并行流补充用例场景

Provide Comfortable Temperature场景仍然需要一些更新才能完全完成。我们还需要指定Reach Desired

Temperature动作的输入信号之一是Ambient Temperature信号。因此，我们必须将Measure Temperature动作产
生的信号流分成两部分。为此，可以利用分支节点。
 将从Measure Temperature动作中流出的对象流分成两部分，如下。

1) 单击视图面板上“Fork Horizontal”按钮旁边的黑色小三角形，然后选择“Fork Vertical”。

2) 单击“Measure Temperature”和“Display Temperature actions”两动作之间的对象流。“Fork Vertical”
就插入到视图中了。
3) 单击“Fork Vertical”，然后在它的智能操作工具栏上单击对象流按钮 。选择Reach Desired
Temperature 动作。创建该动作的对象流和输入引脚。输入引脚类型自动设置为Ambient Temperature环境
温度信号，你不需要做任何修改。

4) 选择对象流并从它的智能操作工具栏单击项流管理器按钮 。
5) 在打开的对话框中，单击以选择传递Ambient Temperature信号的项流。该信号成为对象流的传输项。
6) 单击Close关闭对话框，如图1-78。

图1-78

现在可以认为用例场景已经做完了。您可以再次启动并运行仿真，以执行模型并验证指定的行为。

1.1.3.5 完成用例，下一步做什么?

创建了一个或多个用例场景后，您就可以进行功能分析了。分配给目标系统的功能(在SysML术语中，它们
出现在代表目标系统的泳道中)可以被分解，以指定目标系统预期的内部行为（参见1.2.1功能分析章节）。

1.1.4 有效性度量

1.1.4.1 MOE是什么?

在该单元中，非功能性涉众要求通过有效性度量(MOE)得到了细化，MOE以数字格式捕获了目标系统的可
量化特征。MoE是系统工程中广泛使用的一个传统术语，描述系统在特定环境下执行任务的良好程度。
在问题域模型中，它们作为高级关键性能指标，将在解决方案域模型中自动检查：通过MOE，您可以定义用于
验证系统设计的设计约束。

同一套MOE可以用于不同的模型，用来定义其他目标系统的数值特性。

1.1.4.2 谁负责？

MOE可以由系统分析人员或系统工程师来定义。

1.1.4.3 如何建模?

要在建模工具中捕获MOE，可以使用SysML块定义图(bdd)。要定义可重用的MOE集合，应该创建一个单
独的块，并将其设置为代表目标系统块的超类型。在真实项目中，具有可重用MOE集的块可以存储在外部模型
中，也称为库。MOE被捕获为应用«MOE»构造型的值属性。目标系统块从超类型块继承它们。建模工具中的重
定义机制允许您定义不同的默认值，并从每个MoE细化提炼出不同的需求，如图1-79。

图1-79

1.1.4.4 教程

步骤1: 组织MOE模型

按照MagicGrid框架结构，捕获有效性度量的模型元素应该存储在1 Black Box包中的一个单独包中。我们建

议将包命名为4 Measures of Effectiveness，如图1-80。
 图1-80

组织MOE模型，如下。

1) 右键单击1 Black Box包并选择Create Element。

2) 在搜索框中，键入pa（元素类型Package的前两个字母）并按回车键。
3) 键入4 Measures of Effectiveness作为新包的名称并按回车键。
步骤2: 创建块捕获MOE

要捕获车辆空气调节单元的MOE，首先需要创建一个bdd图和一个块，将块设置为VCCU块的超类。另
外，如果是一个真实项目，MoE库可以在外部模型（也称为库）中创建。

创建视图和块捕获MOE，如下

1) 右键单击4 Measures of Effectiveness包并选择Create Diagram。

注意，视图是以它所存储位置下的包命名的。即视图名也默认为所在包名。您只需要从其名称中
删除序列号即可。

2) 在搜索框中，键入bdd （SysML块定义图的首字母缩写），然后双击回车键来创建块定义图。
3) 单击视图面板上的Block按钮，然后单击该视图编辑窗口中的空白区域，将创建一个未命名的块。
4) 键入MoEs Holder指定此块的名称并按回车键。
5) 在模型浏览器中，选择VCCU块，使用Quick Find功能:
按Ctrl + Alt + f，Quick Find对话框打开。
键入VC。
当您在搜索结果列表中看到选中的VCCU块时(如下图所示)，按“回车键”。然后在模型浏览器中选
中了VCCU块，如图1-81。

图1-81

6) 将VCCU块拖到视图编辑窗中。VCCU块将出现在视图中，如图1-82。
7) 在MoEs Holder块的智能操作工具栏上，单击Generalization按钮 ，点击VCCU块。MoEs Holder块就成
为VCCU块的超类。
 图1-82
步骤3: 捕获目标系统MoE

现在我们将分析非功能性涉众要求SN-1.1.1、SN-1.1.4和SN-1.2.1。它们会提示你为level, total mass和 total

energy consumption创建MOE。接下来，让我们在模型中捕获这些MOE。

获取Vehicle Climate Control Unit的MoE，如下

1) 选择MoEs Holder块，然后单击Create Element按钮 > Value Property。

2) 键入soundLevel以作为新值属性的名称并按回车键。
3) 右键单击value属性并选择Stereotype。

可以在属性名前面输入“ ”，例如/soundLevel，表示它是可派生的。或者，将Is Derived属性值

设置为true，右键单击该属性，然后选择Is Derived复选框。
4) 在搜索框中，键入MOE并按Ctrl +空格键选择«moe»。
5) 按回车键，然后构造型«moe»将应用于soundLevel 值属性。
6) 重复以上步骤来捕获Total mass和Total energy consumption MoE，如图1-83。

图1-83

MOE可能有单位，这些单位可以作为值类型在模型中捕获。大多数常用的值类型存储在ISO 80000单位库
中，这是由建模工具提供的。

将标准单位（来自库）设置为MoE类型，如下

1) 选择任何值属性并单击智能操作工具栏上的ISO，等待单元库加载完成。
2) 选择totalMass值属性并在智能操作工具栏上单击指定类型按钮 。
3) 键入kilg找到Mass[kilogram]值类型，类型就指定了。
 可以缩短值类型列表。只需要单击选择Apply Filter复选框，然后确保选中“Filter By Package
Imports”复选框（在“筛选器”下选项按钮 ），如图 。

图
默认情况下，值类型只显示基本单元。然而，该列表可能不包括所需的值类型，您可能需要扩
展它。为此，应该更新Basic Units矩阵。更多信息，请参考建模工具最新文档。

4) 重复步骤2和步骤3找到work[megajoules]，并将其设置为totalEnergyConsumption值属性的类型。
您也可以手动创建自定义单位。

将自定义单位设置为MoE类型，如下

1) 选择soundLevel值属性并在智能操作工具栏上单击定义类型按钮 。
2) 键入dBA，按回车键。自定义值类型直接创建在包4 Measures of Effectiveness下，并指定为soundLevel值属
性的值类型，如图1-85。

图1-85

如果您想在VCCU块上显示MOE（见下图1-86），则需要更新该块的符号属性。右键单击VCCU块，选择
Symbol Properties，然后在打开的对话框中，找到Show Inherited属性（确保对话框中打开了All模式，否则找不
到它），将属性值设置为true。
 图1-86

以MoEs Holder块捕获的MoE集合以后可以在不同的模型中重用，将相同的量化特征分配给其他目标
系统。

如果您想修改目标系统SoI中继承的MOE，则需要重定义它们。假设你想修改MOE名字，使他们更具体。

重定义继承的值属性，如下

1) 双击VCCU块以打开其规格Specification。
2) 在对话框的左侧，单击Properties。
3) 在右侧内容框内，选择totalEnergyConsumption值属性并单击下面的重定义按钮，如图1-87。

图1-87
4) 在Name单元格中，键入属性的新名称（例如，totalEnergyConsVCCU）。
5) 按回车键确认更改。
6) 重复步骤3 ~ 5，重定义其他MOE，如下图1-88所示。
 图1-88

1.1.4.5 完成有效性度量 (MoE) ，下一步做什么?

现在您已经有了有效性的度量，您可以定义设计约束，这些约束可以用来验证系统设计是否正确(参见
2.1.4系统参数章节)。

1.2 白盒视角
一旦您从黑盒角度完成了问题域定义（即完成了目标系统的运行分析），您可以切换到白盒角度来分析目
标系统。这有助于在生成其逻辑解决方案架构之前理解目标系统的预期行为。

在问题域定义的第二阶段，您应该更深入分析系统功能，以确定目标系统下的概念子系统（在某些方法论
中称为功能块）。概念子系统是目标系统逻辑解决方案架构设计的第一步。

对系统功能的深入分析称为功能分析。如下图所示，在Use Case单元（第2层）中识别出来的目标系统具有
每个功能，在功能分析单元（第3层）中进行分解。然后，分解的功能被分配给概念子系统（又名功能块），
表示每个概念子系统执行一个或多个功能。
 功能分解过程可以根据需要尽可能多的迭代，以实现问题域定义要求的颗粒度。下图1-89显示了每层功能
可以分解为更详细的行为。概念子系统相应地被分解成更具体的结构。需要注意的是，系统行为和结构的颗粒
度在每层都必须保持一致。

图1-89

在确定了功能子系统之后，就可以指定它们之间的交互。每个子系统都有自己的量化特征（即有效性度量
MOE）。目标系统功能、功能子系统和MOE共同建立了指定系统需求的基础（参见2.1.4系统参数章节），如图

1-90。

图1-90

请阅读后续段落，了解如何从白盒角度分析问题域。

1.2.1 功能分析
1.2.1.1 它是什么?

在该单元中，您应该分解黑盒分析过程中识别出来的目标系统的每个功能（参见1.1.3用例章节），更深
入地分析预期的系统行为。

将每个功能分解为更详细的系统行为，有助于识别执行这些功能的概念子系统（即功能块）。概念子系统
将在白盒分析的下一个单元中被捕获（参见1.2.2概念子系统章节）。

需要注意的是，通过更深入的分析，已分解功能的子功能还可以再分解。根据需要解决的问题的颗粒度要
求，可以执行多次分解。每一个被分解的子功能从子功能的角度来看都是一个功能。

功能分析单元的结果是预期系统行为模型。可以从该模型中提取一个活动分解图activity decomposition
map，从目标系统的高层目标开始，到目标系统的预期功能结束。

1.2.1.2 谁负责？

作为用例分析的延续，功能分析可以由系统分析人员或系统工程师来定义。

1.2.1.3 如何建模?

功能分析是使用 SysML 活动图进行用例场景连续细化。应该为分配给目标系统的每个功能创建一

个新的 SysML 活动图（参见 1.1.3 概念子系统章节）。尽管有两个甚至更多的泳道分区，您应该只选择嵌
套在表示目标系统这个部件属性泳道分区下的功能。下图为 VCCU 目标系统执行“Reach Desired

Temperature”功能（Provide Comfortable Temperature 用例场景的一部分）的白盒场景，如图 1-91。

 图1-91

1.2.1.4 教程

步骤1: 组织功能分析模型
 根据MagicGrid框架设计，捕获分解的系统功能的模型工件应该存储在包结构下，如下图1-92所示。如您所
见，顶层包表示域，中层包表示视角，底层包表示单元。

图1-92

组织功能分析模型，如下

1) 右键单击1 Problem Domain包并选择Create Element。

2) 在搜索框中，键入元素类型Package的前两个字母pa，然后按回车键。
3) 键入2 White Box作为新包的名称并按回车键。
4) 右键单击2 White Box包并选择Create Element。
5) 重复步骤2和步骤3，创建名为3 Functional Analysis包。
步骤2: 创建活动图分解功能

假设您想将模型中捕获的功能Reach Desired Temperature进行分解。需要在该活动下创建一个SysML活动

图。

更改模型中Reach Desired Temperature活动的位置，将该活动移动到3 Functional Analysis包下，即2 White

Box包的子包（在本单元教程的上一步中创建）。

在Reach Desired Temperature活动中创建SysML活动图，如下

1) 打开Provide Comfortable Temperature活动图：

按Ctrl + Alt + F打开Quick Find对话框。
单击Diagram只搜索视图并键入Prov。
 当您看到在搜索结果列表中选中的Provide Comfortable Temperature活动图时（见下图1-93），按回车
键。然后活动图将被打开。

图1-93

2) 选择 Reach Desired Temperature动作，然后在其智能操作工具栏上单击SysML活动图按钮 （见下图1-

94）。将打开一个新创建的活动图。

图1-94

如果您返回到Provide Comfortable Temperature活动图（只需在打开的图表工具栏上点击图标 ），

您可以看到Provide Comfortable Temperature上有 ( )图标，表明其包含一个内部视图，可通过双击打开该
内部视图，如图1-95。

图1-95

3) 在模型浏览器中，选择Reach Desired Temperature达到预期温度活动：

在视图窗口上右键Reach Desired Temperature动作。
选择Go To > Behavior Reach Desired Temperature，然后在模型浏览器中该动作被选中。
4) 将Reach Desired Temperature活动拖拽到3Functional Analysis包下 （在2 White Box包内）。相关的活动图
将被一起移动到包下，如图1-96。

图1-96

当您在实际项目中完成白盒分析，捕获目标系统功能的所有活动（它们出现在Provide Comfortable

Temperature活动图的:VCCU泳道中）必须存储在包3 Functional Analysis中，如图1-97。

图 1-97

步骤3: 定义白盒场景

现在，我们将指定功能白盒场景，该功能由Reach Desired Temperature活动捕获。

 活动图有几个输入和一个输出。在 SysML 中，这些是活动参数节点，它们与 Provide Comfortable
Temperature 活动图中 Reach Desired Temperature 动作的输入和输出引脚相对应。输入和输出是一个很好的起
点，应该在指定场景时加以考虑。此外，您可以删除不必要的信息，比如参数名字，那么在视图窗口中就会
拥有更多空间。

删除活动参数节点的名称，如下

1) 单击该节点，当它被选中时，单击其名称，名称就被选中了。
2) 按下键盘上的Delete键，如图1-98。

图1-98
这一次，在开始定义场景之前，您不需要在视图中创建任何泳道。等你在模型中捕获了概念子系统（也就
是功能块）之后，再创建泳道。

定义Reach Desired Temperature活动的白盒场景，如下

1) 确保在视图中开启行为创建模式Behavior Creation Mode。如果没有开启，将不会创建活动并将其作为行

为分配给调用行为动作。单击行为创建模式按钮 即可开启行为创建模式。

2) 单击视图面板上的Initial Node按钮，然后单击视图编辑区上的空白位置。完成初始节点的创建。

3) 选择初始节点，并在其智能操作面板上单击 “控制流”按钮 ，然后单击视图编辑窗口上的空白位

置。一个未命名的行为动作以及一个新活动被创建，并且新活动被分配为该行为动作。

4) 键入Read Desired Temperature并按回车键。

注意一定要在冒号 “ ” 后面输入名称，否则名称将被赋予活动，而不是参考的活动。

5) 选中 :Desired Temperature节点，并在它的智能操作工具栏上单击 。
6) 单击Read Desired Temperature动作，对象流和操作的输入引脚就被创建。该引脚的类型自动设置为输入参
数节点的类型，如图1-99。

图1-99

记住，如果要隐藏输入pin脚名但显示其类型，您需要右键单击该pin，删掉勾选的show name复选
框以清除选择，然后勾选show type复选框。

7) 使用以下指导原则捕获其他项以构建完整的场景，该场景显示在下图1-100中：

 要捕获新动作action，请在智能操作工具栏上选择Control Flow 或Object Flow 。当您创建对象

流时，不要忘记右键单击视图编辑窗口中的空位置，然后选择Call Behavior Action（否则中央缓冲
节点可能会出现在视图中）。
 要连接两个动作action，先选择源动作并在其智能操作工具栏上单击Control Flow 或Object Flow
，然后点击目标动作。
 若要设置Pin引脚的类型（除非它不是自动设置的），请从模型浏览器中拖动对应的元素（块或信
号）到引脚位置。
 要创建decision节点或者merge节点，右键单击视图编辑窗口中的空白位置，然后选择decision或
merge。
 要指定Guard，请选择相关的控制流，输入方括号，然后指定条件，如[Desired Temperature < Ambient
Temperature。请记住，您不需要手动输入关闭括号。一旦按下回车键键，这些都将自动完成。
 要创建输出引脚和到输出参数节点的对象流，请在该动作的智能操作工具栏上选择Object Flow
，然后单击要关联的输出参数节点。输出引脚和对象流都被创建创建的，其类型自动设置为关
联输出参数节点的类型。
 更改新控制流箭头末端新建元素的类型（例如，从动作到决策点或从决策点到合并点），右键单击
视图编辑窗口中的空白位置并选择该类型。
 图1-100

注意，有几个引脚类型是CU Command元素，其中CU代表计算单元Computing Unit，这实际上是一个信

号。它可以与捕获为交换项的其他信号和块一起存储在3 Exchange Items包中。

您可以运行仿真以验证指定的行为，并查看您的模型是否正确。要启动仿真会话，请在Reach Desired

Temperature活动图工具栏上点击运行按钮run 。在仿真面板中，点击Start按钮 启动运行模型。

在这种情况下，我们可以假设车辆空气调节单元可能包括四个子系统：一个用于接收来自系统外部的数
据，一个用于冷却空气，一个用于加热空气，一个用于控制其他系统。MagicGrid框架的下一个单元格会描述如
何捕获它们。

步骤4: 创建活动分解映射图

现在，我们将为Provide Comfortable Temperature活动创建一个活动分解映射图，并查看它被分解的黑盒功

能和白盒功能。活动分解映射图是建模工具中的预定义关系图之一。

为Provide Comfortable Temperature活动创建活动分解映射图，如下

1) 在模型浏览器中选择活动：

按Ctrl + Alt + F。
 在Quick Find对话框中：
a) 确保点选Type选项。
b) 键入Provide C。
当您在搜索结果列表中看到Provide Comfortable Temperature活动时，选择它并按回车键。在模型浏览
器中该活动被高亮选中。
2) 右键单击该活动并选择Create Diagram。

如果在视图类型列表中没有搜到结果，单击下面的Expert按钮。可用视图列表将在Expert模
式下展开。

3) 在搜索框中，键入adm（预定义活动分解图的首字母缩写），然后按回车键，视图被创建。
4) 再按回车键，如图1-101。

注意，视图是以封闭的活动命名的。这个名称也适合该视图，因此不需要改名。

图1-101

如果只显示了部分长元素名，您可以更改映射图设置以显示完整的元素名。单击视图工具栏上
的Options按钮 ，并取消勾选Cut Element Names。

1.2.1.5 完成功能分析，下一步做什么?

白盒场景仿真增强了对目标系统的概念子系统识别；因此，下一个单元格介绍概念子系统。

1.2.2 概念子系统
1.2.2.1 它是什么?

虽然功能分析（参见1.2.1功能分析章节）有助于识别概念子系统（又称功能块），但在该单元格会将它们捕
获到模型中。概念子系统应被视为一组相互关联相互作用的部件，它们会执行目标系统一个或多个预期功能。

值得注意的是，每个概念子系统都可以分解为更具体的结构。这种分解的迭代次数取决于您想要获得的概念
架构的颗粒度层级。从其内部部件的角度来看，每个子系统都被视为一个系统。

一旦在模型中捕获了概念子系统，就该指定它们执行哪些系统功能。需要将功能分配给概念子系统。记住，
预期的系统行为和结构的颗粒度必须在每层都保持一致；因此，不能将子系统层的功能分配给它的组件，也不
能将该组件的功能分配给子系统。只有在您完成当前层颗粒度分析之后，才能允许进行更深入的分析。行为分
解和结构分解颗粒度匹配关系建议在白盒视图章节中介绍。

该单元格还考虑目标系统的输入和输出。它们是通过分析系统上下文和用例场景确定的，而其他的是通过考
虑功能分析的结果确定的。

总的来说，该单元将产生：

 目标系统的输入和输出

 目标系统概念子系统的定义

 交互：

 概念子系统和目标系统外部之间
 在概念子系统之间
 分配预期的系统功能给目标系统的概念结构

请记住，并非总是需要指定目标系统的概念架构。例如，当使用MagicGrid方法论建模已存在的系统
时，可以跳过概念子系统单元，直接定义目标系统的逻辑架构。

1.2.2.2 谁负责？

系统的结构分解及其内部通信可以由系统分析人员或系统工程师来定义。
1.2.2.3 如何建模?

要捕获目标系统或其任何概念子系统的输入和输出，您可以使用bdd。将这些输入和输出指定为SysML流
属性。正如SysML所定义的，可以通过存储在模型中某个地方或甚至某些外部库中的接口块将输入输出分组。
代理端口用于将接口块与捕获目标系统结构的块关联起来。下图1-102显示了车辆空气调节单元及其一个概念子
系统（Processing subsystem）的输入输出端口。

图1-102

要定义目标系统的概念子系统以及它们之间的交互，您可以创建ibd图捕获模型中的目标系统块。在执行功能
分析时识别出来的概念性子系统（参见1.2.1功能分析章节），可以指定为代表目标系统的块的部件属性。在这
些部件属性之间带一个或多个项流的连接器表示概念子系统之间的交互。部件属性和内部块图外框之间带项流
的连接器表示概念子系统与目标系统外部之间的交互。应该通过代理端口创建连接器。下图1-103展示了车辆空
气调节单元概念子系统以及它们内部间通讯和与外部的通信。
 图1-103

捕获了所有概念子系统模型之后，您都可以回到白盒场景，分配目标系统白盒功能给概念子系统，表示每
个概念子系统（即功能块）执行一个或多个白盒功能。在活动图中泳道代表概念子系统。下图1-104显示了
Reach Desired Temperature功能的子功能，分配给目标系统的概念子系统。

图1-104
1.2.2.4 教程

步骤1: 组织概念子系统通信模型

按照MagicGrid框架结构，捕获概念子系统通信的模型工件应该存储在2White Box 包中的一个单独的包中。

我们建议将包命名为2 Conceptual Subsystems Communication，如图1-105。

图1-105

组织概念子系统的通信模型，如下

1) 右键单击2 White Box包并选择Create Element。

2) 在搜索框中，键入pa（元素类型Package的前两个字母）并按回车键。
3) 键入2 Conceptual Subsystems Communication来指定新包的名称并按回车键。
步骤2: 创建块定义图指定概念接口

接下来定义概念接口（捕获目标系统的输入和输出），首先需要创建块定义图BDD并在视图编辑窗口中显
示表示目标系统的块。之前，您应该将该块拖动到包2Conceptual Subsystems Communication下更改该块在模型
中的位置。

创建并准备用于定义目标系统接口的bdd图

1) 创建bdd：
右键单击2 Conceptual Subsystems Communication包并选择Create Diagram。
在搜索框中，键入SysML块定义图的首字母缩写bdd，然后按回车键，创建视图。
键入VCCU Interfaces指定内部块图的名称，并再次按回车键。
2) 在模型浏览器中，使用快速查找功能选择VCCU块：
按Ctrl + Alt + f，Quick Find对话框打开。
输入VC。
 当您在搜索结果列表中看到选中的VCCU块时（如下图所示），按回车键。在模型浏览器中VCCU块
被选中，如图1-106。

图1-106
3) 拖动VCCU块到新创建的包2 Conceptual Subsystems Communication 下（参见本单元教程的步骤1）。如果
出现一条消息，询问是否要将块的关系一起移动，请单击Yes。
4) 将VCCU块拖到新创建的视图编辑窗口中，然后块就会在图1-107中。
图1-107

步骤3: 捕获概念接口

通过对系统上下文环境的分析（参见1.1.2系统上下文章节），们可以得出以下结论：

 车辆空气调节单元由车辆乘员（司机或乘客）控制，他可以打开和关闭系统，设定所需的温度。
 车辆空气调节单元从客舱获取空气，并提供舒适的空气。
 车辆温度传感器提供了车辆空气调节单元的环境温度。
 车辆空气调节单元显示信息（例如，状态信息，车内温度）。
这些信息作为指定目标系统的概念接口的输入，定义与外部的通信：Vehicle In Use系统上下文的假设用户
和其他实体。定义完目标系统的概念子系统（也称为功能块）之后，需要考虑和捕获用于内部通信的概念接
口。

记住，输入和输出都可以捕获为流属性。带in方向的流属性表示输入，带out方向的流属性表示输出。流属
性名不像它们的类型那样重要。捕获为Vehicle In Use系统上下文中交换项的块和信号成为流属性类型。

接口块具有流属性。代理端口是该接口块在目标系统块上的应用。如果多个代理端口的类型为同一个接口
块，那么代理端口名是需要的；否则，他们的名字并不重要。
创建manual control接口块，并将其与VCCU块关联，如下

1) 打开VCCU interface块定义图（如果尚未打开）。
2) 点击视图面板上的Interface Block按钮，然后单击视图编辑区的空白位置。在模型中创建了一个未命名的
接口块，直接将其放置于2 Conceptual Subsystems Communication包之下，并显示在视图中。
3) 键入Manual Control来命名接口块并按回车键。
4) 单击Create Property 按钮，并选择Flow Property，如图1-108。

图1-108
5) 直接在接口块的形状上做以下操作：
删除流属性方向out部分，定义流属性方向为in。
键入uc以指定流属性名称。
键入:Use使用并按Ctrl +空格键打开流属性类型列表。在列表中选择User Command信号。该信号就被设
置为其类型，如图1-109。

图1-109

6) 重复步骤4和步骤5，创建另一个流属性，如下图1-110所示。

图1-110

7) 选择图上的Manual Control接口块，并将其拖到VCCU块上。VCCU块上会创建一个新的代理端口，该端口
类型为Manual Control接口块。可以看到，代理端口内显示箭头，表示这个端口是目标系统输入，如图1-
111。
 图1-111

如果您将鼠标悬停在代理端口上，工具提示框显示通过该代理端口提供给系统的输入，如图
。

如图

参照上述过程，创建带流属性的接口块（如下图1-113所示），然后创建代理端口将它们与VCCU块关联起
来。

图1-113

完成后，VCCU Interfaces块定义图即可标记为完成。完整的视图排除了在模型迭代过程中可能发生
的不必要的布局更改。与完整视图相关的模型更新（例如，调整块新属性的形状大小造成与其他属性
重叠）将冻结，直到您允许它们显示更新。
若要将VCCU Interfaces视图标记为已完成，右键单击视图编辑窗口上的任意位置，然后选择complete。
视图顶部会出现一个通知框，表示视图冻结。更多有关此特性的信息，请参阅建模工具的最新文档。

下图1-114显示了Blackbox ICD 表，这是车辆空气调节单元接口视图的另一种替代视图。本教程没有介绍如

何构建ICD表，但是您可以在建模工具的最新文档中找到相关信息。

图1-114
 为了保持模型的可读性，我们建议将所有接口块存储在一个单独的包中。为此，你需要直接在2
Conceptual Subsystems Communication包下创建1 Conceptual Interfaces包，然后将所有的接口块拖到里面，如图1-
115。

图1-115

步骤4: 创建内部块图捕获概念子系统

车辆空气调节单元概念子系统可以在一个ibd图中指定，该ibd属于VCCU块。根据SysML，内部块图的框架
表示目标系统的边界，因此允许您通过该框架上显示的代理端口指定目标系统内部组成和系统外部之间的交互
（参见本单元教程的步骤3）。

创建用于捕获目标系统概念子系统的ibd图，如下

1) 在VCCU Interfaces块定义图中，选择VCCU块，然后在它的智能操作工具栏上单击SysML internal Block

Diagram按钮 。然后创建一个以该块命名的新的ibd图，并打开Display Parts/Ports对话框。
2) 确保VCCU块的所有代理端口都被选中，单击“确定”，代理端口显示在新创建的图表框架中。
3) 键入VCCU Conceptual Subsystems Communication作为新视图的名称，并再次按回车键。
最后内部块图应该类似于下图1-116所示。
 图1-116

当VCCU Interfaces块定义图（参见本单元教程的步骤 ）将SoI表示为黑盒，创建的idb表示为相同的

系统的白盒：打开VCCU块来查看其内部结构。这就是为什么bdd中VCCU块的边界上显示的代理端
口会显示在 视图框架上，如图

步骤5: 捕获概念子系统

根据功能分析（见功能分析章节），Vehicle Climate Control Unit由以下概念子系统组成：

 Cooling
 Heating
 Processing
 Human-Machine Interacting
它们可以被定义为VCCU块的部件属性。部件属性不需要名称，但是它们的类型应该是通过捕获上面列出
的概念子系统的块。
接下来指定概念子系统，如下

1) 打开VCCU Conceptual Subsystems Communication ibd图，该ibd在本单元教程的步骤4中创建。

 2) 确保在视图中开启Type Selection Mode。否则，在此视图中创建的部件将不会有类别块，如图1-118。

图1-118
3) 单击视图面板上的Part Property按钮，然后单击视图编辑窗口上的空白位置。一个未命名的部件属性将会
被创建，并提供可选择的该属性类别的现有块列表。
4) 直接在部件属性上的冒号(“:”)旁边输入Cooling并按回车键。然后在模型浏览器中就创建了刚刚创建的部
件属性类别的Cooling块。
5) 重复步骤3和步骤4，从上面的列表中创建另一个概念子系统。
当您完成时，您的VCCU Conceptual Subsystems Communication ibd图看起来应该非常类似于下图1-119中
。

图1-119
为了保持模型的良好结构，我们建议将捕获为概念子系统的所有块存储在一个单独的包中。为此，您需要
直接在2 Conceptual Subsystems Communication包下创建2Conceptual Subsystems包，然后将所有概念子系统块拖
到里面，如图1-120。
 图1-120

如果功能分析需要分解SoI的一个或多个子系统，我们强烈建议对每个子系统使用与SoI相同的模型结
构pattern模式。为每一个较低层重复在此颗粒度上创建结构，有助于建立良好且易于阅读的模型递归
结构。

步骤6: 指定概念子系统与目标系统外部之间的交互

在这一步中，我们重点定义车辆空气调节单元的概念子系统（即功能块）与外部之间的交互作用。子系统
和目标系统外部之间的交互可以指定为具有一个或多个项流的连接器，连接适当的部件属性和视图框架（记
住，ibd中的视图框架表示目标系统的边界）。在该单元中，不像系统上下文单元（参见1.1.2系统上下文章
节），连接器是在兼容的代理端口上建立的。通过这些连接器交换的信息、物质或能量可以定义为通过项流传
递的项。
 让我们从目标系统外获取空气并提供舒适空气开始定义制冷子系统。

指定制冷子系统和目标系统外部之间的交互，如下

1) 选择类型为Cabin Air Inlet接口块的代理端口，然后在它的智能操作工具栏上单击Connector按钮 ，如图

1-121。

图1-121
2) 单击: Cooling 部件属性，选择New Proxy Port (如下图所示)。新的兼容代理端口被创建，它的类型是同一个
接口块Cabin Air Inlet，如图1-122。

图1-122

3) 在模型浏览器中，选择Air块。为此，请使用Quick Find 快速查找功能:

按Ctrl + Alt + f，Quick Find对话框打开。
键入Air。
当您在搜索结果列表中看到Air块被选定（见下图1-123），按回车键。然后在模型浏览器中选择Air
块。
4) 将Air块拖动到打开的视图编辑窗口上新创建的连接器上。

图1-123
 SysML所定义的是你想要指定的在连接器上流动的项，必须是流属性的类型（或子类型），决定
了部件属性在连接器一端的输入，在连接器另一端的输出，反之亦然。在本例中，Air块是流属性类
型，可以设置为流过连接器的项。

5) 不要在打开的对话框中做任何更改，直接单击Finish。然后将Air块被指定为新创建的连接器的项流，如图
1-124。

图1-124
6) 重复步骤1和步骤2，在Cabin Air Outlet接口块和:Cooling 部件属性之间创建连接器和代理端口
7) 重复步骤3在模型浏览器中选择Comfortable Air块。
8) 将该块拖到新创建的连接器上。
9) 在打开的对话框中，将流方向改为From Cooling System To VCCU，然后单击Finish。将Comfortable Air块被
指定为流经新创建的连接器的项流，如图1-125。

图1-125

制热子系统和外部之间的交互也相似。可以相同的方式指定。一旦完成，视图应该如图1-126。
 图1-126

如您所见，代理端口名称在视图中被隐藏。这大大增加了视图的可读性。要隐藏代理端口的名称，
请执行以下操作：
选中任意代理端口时，同时按住 键，该视图中的所有代理端口被选中。
右键，然后单击以清除“Show Name”复选框。

现在指定Processing subsystem从外部获取环境温度；人机交互子系统从外部接受用户命令和期望温度，同时
也向外部提供各种信息。

按照上述建完模后，您的VCCU Conceptual Subsystems Communication内部块图应该与下图1-127非常相似

。

图1-127
步骤7: 指定概念子系统之间的交互

在这一步中，我们将指定目标系统概念子系统之间的交互。与前面的步骤一样，可以将这些交互指定为通
过兼容的代理端口在对应部件属性之间建立的连接器。通过这些连接器交换的信息、物质或能量可以定义为传
递的项流。

功能分析使我们能够识别以下交互信息：

 Processing subsystem处理子系统从人机交互子系统获取所需的温度。
 如果Processing subsystem处理子系统识别到设定温度Desired Temperature低于环境温度Ambient
Temperature，则会启动制冷子系统。
 如果Processing subsystem处理子系统识别出设定温度Desired Temperature高于环境温度Ambient
Temperature，它将启动制热子系统。
 人机交互子系统将处理子系统产生的各种信息提供给外部。
基于上述描述，在Processing Subsystem Interfaces图中需要定义更多的接口块，下图1-128将这些接口块高亮
显示了。

图1-128
 我们假设您已经创建了该视图，并按照下图1-129所示重新组织排序模型。

图1-129

如你所见，CU Command信号有两个子类型Cool信号和Heat信号。通过这种信号层次结构，您可以在指定
用例下确切地指出哪个信号流过同一个概念接口，即:Processing和:Colling部件之间的Cool信号，以及:
Processing和:Heating部件之间的Heat信号。

Information 信号也有子类型。这些信号包括 Ambient Temperature, Desired Temperature 和 Status 信号。如

果我们想更具体地指定哪种信息可以通过类型为 Output information 或 Internal Data Transfer 接口块的代理端
口传递，这些信号是有用的。

子类型可以在单独的名为Exchange Items的bdd中进行定义。您已经知道如何创建一个新的bdd，如何在那里
显示已有的和创建新的模型元素，以及如何在它们之间建立泛化关系。要在Processing Subsystem Interfaces视图
中嵌套显示Exchange Items视图的内容，只需要将Exchange Items视图从模型浏览器拖拽到Processing Subsystem
Interfaces 视图编辑窗口上。然后，在Exchange Items视图智能操作工具栏上，单击Show Diagram Overview
Content按钮 ．

现在让我们继续定义 Vehicle Climate Control Unit 概念子系统之间的相互作用。

定义人机交互子系统和处理子系统之间的交互，如下

1) 打开VCCU Conceptual Subsystems Communication 块定义图。

2) 选择:Processing部件属性，并在它的智能操作工具栏上单击Display All Ports按钮 ，如图1-130。

图1-130

系统将显示出另外两个代理端口，如图1-131。

图1-131

3) 选择类型为Internal Data Transfer接口块的代理端口，然后在其智能操作工具栏上单击Connector按钮 。

4) 单击: Human-Machine Interacting 部件属性并选择New Proxy Port，新的兼容的代理端口就被创建了。如您
所见，它类型是同一个接口块。
5) 在模型浏览器中的3 Exchange Items包下，选择Desired Temperature信号并将其拖拽到新创建的连接器上。
6) 在打开的对话框中，将流的方向改为From Human-Machine Interacting to Processing，然后单击Finish。将
Desired Temperature信号指定为流过新创建的连接器的项流。
7) 在模型浏览器中的3 Exchange Items包下，选择Ambient Temperature信号并将其拖拽到新创建的连接器
上。
8) 不要在打开的对话框中更改任何内容，单击Finish。然后将Ambient Temperature指定为流过新创建的连接
器的项流。
9) 重复步骤7和步骤8，将Status信号指定为流经新创建的连接器的项流，如图1-132。
 图1-132

以同样的方式，指定处理子系统和制热系统以及处理子系统和制冷子系统之间的交互。完成后，你的视图
看起来应该和下面1-133的很相似。

图1-133

更准确地说，还可以指定从制冷子系统流出的Comfortable Air为Cooling Air，从制热子系统流出的Comfortable

Air为 Heating Air。需要在Exchange Items图中创建Comfortable Air的子类型Cooled Air块和Heated Air块，如图1-
134。

图1-134

由于Comfortable Air块有两个子类，您可以在: Cooling部件属性和视图框之间，以及在:Heating部件属性和

视图框之间的连接器上更新项流。如果不再需要连接器上的类型为Comfortable Air块的项流，您可以直接删除
它。

删除项流，如下。

1) 选择相关连接器并在它的智能操作工具栏上单击项流管理器按钮Item Flow Manager 。

2) 在打开的对话框中，单击以清除对所传递的是Comfortable Air块的行的选项，如图1-135。
图1-135

3) 关闭对话框。
 完成后，你的ibd图应该如下图1-136所示。

图1-136

下表是VCCU Conceptual Subsystems Communication内部块图的另一种替代视图。本教程没有介绍如何

构建白盒ICD表，但您可以在建模工具的最新文档中，找到相关信息，如图 。

步骤8: 分配功能给概念子系统并同步项流

现在是时候用泳道更新Reach Desired Temperature图（参见1.2.1功能分析章节）了，泳道代表了车辆空气

调节单元概念子系统。后续，应该将动作分配给这些泳道，以便指定负责执行每个功能的概念子系统。

这些分配使您能够通过从相关的ibd图中同步项流来更新Reach Desired Temperature视图。这一次，我们将

从VCCU Conceptual Subsystems Communication图来同步。
将功能分配给概念子系统，如下。

1) 打开Reach Desired Temperature视图：

按Ctrl + Alt + F，打开Quick Find对话框。
选择Diagram，只搜索视图并输入Rea。
当您在搜索结果列表中看到选中的Reach Desired Temperature视图时（如下图1-138所示），按回车
键，视图将被打开。

图1-138

2) 单击活动图视图快捷面板上的Vertical Swimlanes按钮，然后单击该视图编辑窗上的空白区域。视图中就创
建了带有空白标题的泳道。
3) 右键单击任一泳道，选择Insert Swimlane > Vertical to the Left。就创建了一个新的带有空白标题的泳道。
4) 重复步骤3创建另一条泳道。
5) 在模型浏览器中，选择VCCU块。请使用Quick Find功能:
按Ctrl + Alt + f，打开Quick Find对话框。
选择Type，只搜索类型，输入VCCU。
当您在搜索结果列表中看到选定的VCCU块时，按回车键。在模型浏览器中就选中了VCCU块。
6) 展开VCCU块以查看其属性。
7) 选择: Human-Machine Interacting并将其拖到第一条泳道的头部。泳道代表该部件属性。
8) 依次重复步骤7，将: Cooling, :Processing, :Heating这三个部件属性都拖拽到泳道中。完成后，如下图1-139
所示。

图1-139
9) 将初始节点、Read Desired Temperature动作和 Send Data to Computing Unit动作拖拽到:Human-Machine
interaction泳道。
10) 将Get Desired Temperature, Get Ambient Temperature, Process Data, Initiate Cooling, and Initiate Heating动作
拖拽到:Processing泳道中。
11) 拖拽 Air Out from Cabin actions ，Cool Down Temperature to Desired，Blow Cooled Air Back to Cabin动作以
 及活动最终节点到 :Cooling泳道中。
12) 拖拽Draw Air Out from Cabin action ，Heat Up Temperature to Desired以及 Blow Heated Air Back toCabin动
作到:Heating分区。

当你完成时，Reach Deired Temperature视图应该看起来如下图1-140。

图1-140

一旦分配完所有动作，就该定义它们之间的项流了。跨泳道边界的项流可以很容易地从对应的ibd图中（在
本例中是VCCU Conceptual Subsystems Communication视图）同步。让我们从Send Data to Computing Unit 和Get
Desired Temperature活动之间的项流开始。前者分配给 :Human-Machine Interacting部件属性，后者分配给:
Processing部件属性。如果你查看VCCU Conceptual Subsystems Communication视图，你会看到Desired
Temperature信号在这两部件属性之间流动。因此，您可以得出结论，相同的信号在它们分配的活动之间流动。
建模工具帮助您指定项流，而不需要在视图间切换，如下所述。

同步Send Data to Computing Unit和Get Desired Temperature动作之间的项流，如下。

1) 选择这些动作之间的对象流。

2) 在它的智能操作工具栏上单击项流管理器按钮 。
3) 在打开的对话框中，选择列表中的唯一项流。它表示传递了 Desired Temperature信号，如图1-141。
 项流管理器列表中总是包含两个活动之间可能的流的项。这些项流来自相关的ibd图。

图1-141

4) 关闭对话框。然后传递Desired Temperature信号的项流显示在视图中。
以同样的方式，指定：

• Cool信号从Initialize Cooling动作流向Draw Air Out from Cabin动作。

• Heat信号从Initialize Heating动作流向Draw Air Out from Cabin动作。
完成之后，您的活动图看起来如下图1-142。
 图1-142

接下来，您可以在同一泳道中指定Read Desired Temperature 和Send Data to Computing Unit动作之间的项流

。

定义Read Desired Temperature 和 Send Data to Computing Unit动作之间传送Desired Temperature信号的项流，如

下。

1) 选择这些动作之间的对象流。

2) 在它的智能操作工具栏上，单击New Item Flow按钮

3) 在打开的对话框中，确保将Desired Temperature信号选择为被传递的项流，然后单击Finish（见下图1-
143）。因此，Desired Temperature信号成为相关活动之间传递的项流。
 图1-143

按照前面的步骤，指定下面视图中看到的其他项流。请记住，你可以更具体地指定Cool Down Temperature

to Desired 和 Blow Cooled Air Back to Cabin 活动之间项流。在Create / Edit Item Flow对话框中选择Cooled Air块
而不是Comfortable Air块。另外，你也可以更具体地指定Heat Down Temperature to Desired 和 Blow Cooled Air
Back to Cabin活动之间的项流，如图1-144。

图1-144
 Pin引脚不显示其类型；视图中只显示了项流。这使得视图不那么拥挤，也更容易阅读。如果你想隐藏
引脚类型：
按下Alt键并选择任意输入引脚。视图中所有输入引脚都会被选中。
右键，然后单击Show Type以清除所选内容。
重复以上步骤来隐藏输出引脚类型。

尽管比用例场景更详细（参见1.1.3用例章节），但这仍然是一个高层场景，可能也需要分解。由功能分解
引发的进一步结构分解是并行执行的。对于功能和结构分解可能和问题域理解一样，有许多轮迭代。

1.2.2.5 完成概念子系统，下一步做什么?

 无论目标系统是否具有可量化特征，系统功能及其概念子系统都会细化提炼涉众需求。因此，一旦完成
了这一步，您就可以建立与涉众要求追溯关系（参见1.2.4追溯到涉众要求章节）。

 您可能还需要为一个或多个概念子系统指定可量化的特征，这将比定义的整个目标系统的可量化特征更
具体（参见1.1.4有效性度量章节）。下一步，考虑子系统有效性度量。

1.2.3 子系统有效性度量

1.2.3.1 它是什么?

在该单元格中，您应该为目标系统的一个或多个概念子系统（即功能块）指定MoE，以进一步细化提炼非功
能性涉众要求。该单元格是可选的，因为除了为整个目标系统定义的MoE之外（参见1.1.4有效性度量章节），
您可能不需要定义子系统MoE。

1.2.3.2 谁负责？

概念子系统的MoE可以由系统分析人员或系统工程师来定义。

1.2.3.3 如何建模?

为了在建模工具中捕获概念子系统的MoE，您可以使用SysML块定义图—与您使用bdd在有效性度量单元中捕获
目标系统MoE的方法相同。就像在那个单元中一样，概念子系统的有效性度量可以作为子系统的值属性在模型
中被捕获，并应用«moe»构造类型，如图1-145。

图1-145

1.2.3.4 教程
步骤1： 组织子系统MoE模型

按照MagicGrid框架结构，子系统MoE模型元素应该存储在2 White Box包中的一个单独的包中。我们建议以

该单元名命名包，即命名4 MoEs for Subsystems，如图1-146。

图1-146

为子系统组织MoE模型，如下。

1) 右键单击2 White Box包并选择Create Element。

2) 在搜索框中，键入pa(元素类型Package的前两个字母)并按回车键。
3) 键入4 MoEs for Subsystems指定为新包的名称并按回车键。
步骤2： 捕获子系统MoE

让我们指定VCCU概念子系统的MoE，它在模型中定义为Cooling块。就像整个目标系统的MoE一样，这个概
念性子系统的MoE细化了相同的非功能性涉众要求:SN-1.1.1、SN-1.1.4和SN-1.2.1。因此，Cooling块可以从有
效性度量单元中介绍的同一个MoE Holder下继承所有MoE。之后，如果需要更改继承的值属性（例如名称或类
型），可以重定义继承的值属性。在本例中，我们将只更改名称。

定义制冷子系统MoE，如下。

1) 创建一个bdd图：
选中4 MoEs for Subsystems包，右键选择Create Diagram。
在搜索框中，输入bdd （SysML块定义图的首字母缩写），然后双击回车键，视图被创建。

注意，默认视图名和所在存储包同名的。这个名称也非常适合该视图，所以您只需要从其名
称中删除序列号即可。

2) 在新创建的视图上显示MoEs Holder块：
按Ctrl + Alt + f，打开Quick Find对话框。
输入有效性度量 MoEs。
当您看到在搜索结果列表中被选中的MoEs Holder块时（见下图1-147），按回车键。MoEs Holder块
在模型浏览器中就被选中。
 图1-147
将该块拖拽到视图编辑窗口中。
3) 以同样的方式，在图表上也显示Cooling块。
4) 选择Cooling块并在它的智能操作工具栏上单击泛化按钮 。
5) 选择MoEs Holder块。因此，Cooling块继承MoEs Holder块的所有属性，如图1-148。

图1-148
6) 在Cooling块上显示继承的属性：
选中Cooling块并右键，选择Symbol Properties。
在打开对话框的右上角，从下拉列表中选择All，将对话框切换到All Properties模式。
在属性列表下面的搜索框中，输入inh。
当您看到Show Inherited符号属性显示在列表的顶部时，选中该选项将其设置为true，如图1-149。
 图1-149

关闭对话框。
7) 重定义totalEnergyConsumption值属性。:
双击Cooling块，打开其规格。
在对话框的左侧，单击Properties。
在右侧，选择totalEnergyConsumption值属性并点击下面的Redefine按钮。
在Name单元格中，输入属性的新名称，例如energyConsCool。
按回车键确认更改，如图1-150。

图1-150

8) 用同样的方法重定义其他属性。
9) 关闭对话框。
 当完成时，视图应该如下图1-151所示。

图1-151

在您捕获了车辆空气调节单元的所有概念子系统的MoE之后，您的视图应该类似于下图1-152。

正如您所见，值隔间被剪切以显示值属性行的完整长度。
为此，请执行以下操作：
选择定义为车辆空气调节单元概念子系统的所有块。按Shift键支持多选。
右键并选择符号属性Symbol Properties。
在打开的对话框中，找到Shrinkable Attributes and Operations Compartment属性，并将其值设置
为true。

图1-152

1.2.3.5 完成子系统MoE捕获，下一步做什么?

当您定义了子系统MoE后，你可以指定涉众要求细化提炼到什么（参见1.2.4追溯到涉众要求章节）。
1.2.4 追溯到涉众要求

1.2.4.1 它是什么?

为了拥有一个完整的问题域模型，您需要在捕获涉众要求的元素和捕获白盒功能、概念子系统、概念接口和
目标系统的非功能性特征的元素之间建立可跟踪性关系。由于后者比涉众要求更具体，我们建议建立提炼refine
关系。这些关系应该从最低层具化元素指向较高层元素，例如捕获功能分解模型为子功能的动作。当您完成了
这里的可跟踪关系时，涉众的每一项需求都必须由其他SysML类型的一个或多个元素来细化提炼。反之，在问
题域模型中并没有考虑到所有涉众的需求，这可能会形成不正确的系统需求规范（参见2.1.1系统需求章节），
从而导致开发出错误的系统。

1.2.4.2 谁负责？

可追溯性关系可以由系统分析人员或系统工程师来定义。

1.2.4.3 如何建模?

这两种SysML图都不适合创建大量的交叉关系，比如细化提炼。对于这一点，矩阵或映射图更合适。建模工
具提供了大量的预定义矩阵来定义交叉关系。为了捕获细化关系，可以使用细化需求矩阵Refine Requirement
Matrix，如图1-153。
图1-153
1.2.4.4 教程

步骤1： 组织可追溯性关系模型

可追溯性关系和显示关系的视图view可以存储在一个单独的包中，它直接创建在1 Problem Domain包下，

作为其最后一个内部包表示建模工作流，如图1-154。

图1-154

组织模型以实现可追溯性，如下。

1) 右键单击1 Problem Domain包并选择Create Element。

2) 在搜索框中，输入元素类型Package的前两个字母pa，然后按回车键。
3) 输入4 Traceability来定义新包的名称并按回车键。
步骤2： 创建矩阵用以捕获提炼关系

要捕获提炼关系，您应该首先创建一个提炼需求矩阵。该矩阵是预定义矩阵，列表示需求，单元格中表示
提炼关系。你只需要指定矩阵的行：

 调用行为动作，用它捕获目标系统的功能
 部件属性，用它捕获目标系统的概念子系统
 代理端口，用它捕获目标系统的接口
 应用«moe»构造型的值属性，用它捕获目标系统或其子系统的MoE
涉众要求必须被问题域元素提炼细化。因此，列元素必须从包含白盒分析结果的包中被获取。

创建一个提炼需求矩阵Refine Requirement Matrix

1) 右键单击4 Traceability包并选择Create Diagram。

2) 在打开的对话框中，单击Expert模式。
3) 在搜索框中，键入rrm，提炼需求矩阵的首字母缩写，然后按回车键。矩阵被创建。
4) 输入Refine Stakeholder Needs作为新矩阵的名称并再次按回车键。
5) 指定列元素范围：
在模型浏览器中，选择需求SN-1 Stakeholder Needs。
将其拖到矩阵上方的Criteria区域的Column Scope框中。选定的包成为矩阵列的范围。
6) 指定行元素类型：
 在模型浏览器中，选择任意调用行为动作，例如Initialize Cooling 动作（出现在Reach Desired
Temperature动作下），如图1-155。

图1-155
将选择的动作拖拽到矩阵上方的Criteria区域的Row Element Type框上。矩阵的行被设置为显示类型为
调用行为动作的模型元素。
在模型浏览器中，选择任意部件属性；例如，类型为Cooling块的部件属性，如图1-156。

图1-156

同时按住Ctrl键并将部件属性拖拽到矩阵上方的Criteria区域的Row Element Type框中。矩阵的行也被

设置为显示类型为部件属性的元素。
重复步骤c和d，使矩阵行能够显示代理端口和应用了«moe»构造型的值属性。
7) 指定行元素范围：
在模型浏览器中，选择2 White Box。
将选择的内容拖到矩阵内容上方的Criteria区域的Row Scope框上。选定的包成为矩阵行的范围。
下图1-157显示了矩阵的Criteria区域，标出步骤5、6和7步骤相关域。

图1-157

如果矩阵显示接口块，您可以通过修改显示设置轻松地删除它们。单击Row Element Type框边上的…

按钮，并在打开的对话框中清除Include Subtypes复选框。另外不要忘记刷新矩阵。

步骤3： 捕获提炼关系

现在，可以准备捕捉提炼关系了。让我们创建从Cool Down Temperature动作到SN-1.1.6 Desired

Temperature涉众要求(捕获为需求)的提炼关系，以传达该活动细化提炼了涉众需求。

在矩阵中指定提炼关系，如下。

 双击 Cool Down Temperature动作所在行和SN-1.1.6Desired Temperature 需求所在列的交叉单元格。这两

项之间提炼关系被创建，并将显示在单元格中。

为了节省空间，下图1-158中隐藏了2 Conceptula Subsystems Communication 包中的内容。

 图1-158

在捕获所有的细化提炼关系之后，您的Refine Stakeholder Needs矩阵应该如下图所示。记住，当您完成

时，涉众要求的每一项都必须由问题域分析模型中的一个或多个元素来细化，如图1-159。
图1-159
 您可能已经注意到，矩阵还显示了隐含的细化提炼关系（虚线箭头）。一旦叶需求被细化提炼出来，同一
分支的所有上层需求也认为被细化提炼；这就是建立隐含的提炼关系的逻辑。有关如何创建和使用隐含关系的
信息，请参考建模工具的最新文档。

1.2.4.5 完成问题域设计，下一步做什么?

当至少90%的涉众要求（此阈值在不同的组织中可能有所不同）被问题域模型中的一个或多个元素所细化
提炼后，问题域分析就完成了。可以使用建模工具支持的度量功能来监视问题域分析项目的状态。下图1-160中
的度量表计算了与需求提炼相关的度量值，由预定义Requirement Refinement度量套件计算得出。更多关于如何
使用度量的信息，请参阅建模工具的最新文档。

完整的问题域分析模型，包括目标系统的涉众需求、目标系统的预期功能和概念结构，MoE（可以没
有），被视为基于模型形式的初始系统需求规范。如果需要文本形式的系统需求规范(这种情况并不罕见)，可
以将问题域分析模型转换(手动或自动地利用转换算法)为SysML需求模型，并提供给系统架构师，作为在解决
方案域中开发目标系统逻辑架构的输入。这部分内容将在解决方案域章节中介绍。

图1-160

第2章 解决方案域
一旦问题域分析完成，目标系统的涉众要求被转换为SysML模型，就该开始考虑目标系统的解决方案域模
型了。解决方案域模型精确定义了目标系统的跨学科领域逻辑架构，以解决问题域分析模型中定义的问题。解
决方案域模型不应该与详细的设计模型混在一起，详细设计模型是在目标系统开发的后期阶段创建的，不是
MagicGrid框架下的组成部分。

由于相同的问题定义可能有多个解决方案，因此我们可以通过权衡分析，以选择实现系统的最佳解决方案
(见下图2-1)。

应该注意的是，问题域可以由一个组织来定义，解决方案域可以由另一个组织来定义。此外，不同的组织
也可以提供不同的解决方案。
 图2-1

从下图2-2中可以看到，创建解决方案域模型包括了定义目标系统的需求、结构、行为和参数。此外，构建
逻辑架构的任务通常包括不止一次的迭代，从系统级到子系统级，从子系统级到组件级架构，如有必要，甚至
可以迭代到更深的颗粒度。所以说系统架构模型的精度取决于迭代的次数。

图2-2
1.部署解决方案域

目标系统的逻辑架构可以在单个模型中定义，甚至可以在问题域定义的同一模型中定义。然而，在大多数
情况下，解决方案域模型的范围和复杂性超过了问题域定义的范围和复杂性，特别是当它包含多个解决方案
时。在两个或多个单独的模型中定义解决方案域有助于管理信息复杂性。此外，这种模型划分方法支持在更细
粒度的级别上管理模型的所有权、进行变更分析和监控、访问控制、并发修改和模型重用。

下面的材料介绍了跨多个模型部署解决方案域的方法。

如前所述，可以为同一个问题提供多个解决方案。为了阐述我们的方法，我们介绍三个解决方案域模型：
Solution Domain 1, Solution Domain 2 和Solution Domain 3。虽然Solution Domain 1和Solution Domain 2的内容没
有展开，但是您应该将它们想象成与Solution Domain 3的内容相似。逻辑系统架构(Logical System Architecture,
LSA)模型是每个解决方案域的核心。基于问题域分析的结果，它用分层级结构定义了目标系统的逻辑子系统。
从下图中可以看到，在这种情况下有三个逻辑子系统：Subsystem 1, Subsystem 2 和Subsystem 3。值得注意的
是，每个子系统都被认为是LSA模型中的一个黑盒，该模型还为每个子系统定义了逻辑接口，以确定它们如何
相互操作并根据系统需求集成到整个系统中。为了避免混乱，在下面的图中没有包含接口。LSA模型的所有者
是系统架构师，他拥有目标系统的“大局观”。换句话说，系统架构师就像一个管弦乐队的指挥：他/她确保每个
人在同一时间演奏相同的旋律。

在LSA模型中定义逻辑子系统有助于识别工作包，并将它们定义到独立的工程团队中。每个团队为定义的
子系统开发一个或多个逻辑架构。这个工作可能是并发进行的。如下图所示，这三个子系统都有几个解决方
案。Logical Subsystem X Architecture 1 中X代表1、2或3，在最上层是可见的，而其他的隐藏在下面。Subsystem
1和Subsystem 1 Architecture之间的是泛化关系（带空心三角形箭头的实线），表示负责Logical Subsystem 1
Architecture 1模型的工程团队知道（或者用SysML语言继承了）LSA模型中定义的逻辑子系统的设计约束（例
如逻辑接口），并且必须遵循这些约束。

以上阐述概括成通俗易懂的信息就是不同逻辑子系统的架构，甚至相同逻辑子系统的不同架构可能包含不
同数量的组件。逻辑子系统的解决方案域模型定义了该逻辑子系统的需求、结构、行为和参数。

在工程团队完成了LSA逻辑子系统架构模型中定义的所有子系统的逻辑架构之后，系统架构师可以将它们
集成为一个模型。他/她从每个逻辑子系统中选择一个首选的子系统，并构建整个系统的综合逻辑架构。注意，
可以提出多个解决方案。如图所示，我们称这些解决方案为System Configuration 1, System Configuration 2 等
等。就像每个子系统的逻辑架构一样，整个目标系统的集成逻辑架构定义了结构、行为和参数，并且必须满足
系统需求规格说明。

有了目标系统的完整模型，系统架构师就可以进行权衡分析并选择最优的系统配置；有了几个解决方案域
的最优系统配置，系统架构师可以首先选择一个最优的解决方案。下图2-2中的权衡分析Trade Off说明了这一
点。
 而且，不仅可以在多个解决方案域之间进行权衡，而且可以在一个解决方案域内目标系统逻辑架构的每个
层级（系统-分系统等）进行权衡分析。

图2-3

2.在解决方案域中应用MagicGrid方法论

通常情况下，子系统需求不足以构建子系统的逻辑架构，特别是当它由下游供应商（承包商）开发，因为
原始设备制造商（OEM，承包商）通常不愿意共享问题域模型。因此，供应商可能需要先进行逻辑子系统的问
题域分析。下图2-4展示了在逻辑子系统级应用MagicGrid框架，这里逻辑子系统是该场景下的目标系统。

图2-4
2.1构建目标系统的逻辑架构
在解决方案域的这一阶段，您可以想象自己是系统架构师，并致力于交付目标系统的逻辑架构(例如建立逻
辑系统架构(logical system architecture, LSA)模型。构建这个模型的基本目标是定义目标系统的逻辑子系统，这
将引出对工作包的标识。

如前所述，目标系统的逻辑架构可以存储在一个独立的模型中，独立于问题域定义。下图2-5中橘色高亮圈
出的区域则是我们正在讨论的解决方案域。

图2-5

根据MagicGrid框架内容 (参见下图2-6中高亮显示的区域)，系统级解决方案域模型定义了系统需求、结
构、行为和参数。此外，在LSA逻辑系统架构模型中创建的每个SysML元素必须满足至少一个系统需求。否
则，就缺乏在LSA模型中存在的必要。因此，系统级解决方案域建模起始都是关于系统需求：首先定义系统需
求，当您完成整个LSA模型建模时，建立系统需求和逻辑系统架构元素之间的追溯关系。
 图2-6

2.1.1 系统需求

2.1.1.1 它是什么?

要定义逻辑系统架构，首先需要有系统需求规格以便遵循它。您可能还记得，从黑盒和白盒的角度进行的问
题域分析的结果可以被视为以基于模型的形式呈现的初始的系统需求规格。该单元的主要任务是手动将问题域
分析模型转换为基于SysML需求模型，该模型使您能够以结构化形式呈现系统需求规格。

在转换之后，为了跨越解决方案和问题域模型之间的边界，必须建立以下追溯关系：

 从系统需求到涉众要求——显示哪个系统需求来自哪个涉众要求
 从系统需求到问题域模型元素——显示哪些模型元素是由哪个系统需求细化提炼出来的
在处理目标系统的逻辑架构时，可以不断更新系统需求规格。而且，子系统、组件的逻辑架构需求，甚至
更底层精确的需求都是从系统需求中派生出来的。这在子系统需求一章中进行了描述。

与涉众要求不同，系统需求是可验证的：在您完成LSA逻辑架构模型之后，建立逻辑系统架构元素到系统
需求间的满足关系，以便确认前者满足后者。这在追溯到系统需求章节中进行了描述。
2.1.1.2 谁负责?

系统需求规格必须由执行了问题域分析的系统分析人员或系统工程师生成。

2.1.1.3 如何建模?

在建模工具中，系统需求规格中每一项都可以存储为SysML需求，它具有惟一的标识、名称和文本规格。
与涉众要求的文本规格相反，系统需求必须是正式的，并按照特定的指南写下来。例如，只写简短清晰的句
子，避免条件关键字(例如如果、除外、以及，if, except, as well)，可以使用关键字应当shall，并包括表格。有
关如何编写好的文本要求的更多信息，请参阅INCOSE Systems Engineering Handbook。

通过使用需求之间的包含关系可以将系统需求分层。其中表示系统需求规格的SysML需求必须位于最顶
层，它可能没有需求正文。

SysML需求表或需求图可以帮助可视化系统需求的层次结构(参见下图2-7)。需求表或需求图也可以包含在
需求报告中。

图2-7

每个系统需求必须由某个特定涉众要求派生出来，并且/或者细化提炼了问题域中一个或多个模型元素。要
描述一个派生关系，你应该建立从系统需求指向涉众要求的«deriveReqt»关系 (下图2-8显示了在矩阵中显示的这
些关系)。要确定一个细化关系，则应该建立从系统需求指向问题域模型中定义的某个部件属性、调用行为动作
或MoE的«refine»关系。
 图2-8

2.1.1.4 教程

步骤1. 创建和组织系统需求模型

为了定义系统需求，首先需要建立适当的模型结构。按照MagicGrid框架的设计，捕获系统需求的模型工件
应该存储在包的结构下，如下图2-9所示，上层包代表域，下层包代表单元。

图2-9

然而，在实际的项目中，将解决方案域模型与问题域模型分离是很常见的。根据这个实践，我们建议在另
一个模型中定义车辆空气调节单元(VCCS)的系统需求和逻辑架构。问题领域模型的内容应该在该模型中可用，
因为问题领域分析的结果被认为是一个初始的系统需求规格，应该从基于模型的形式转换为文本形式。就建模
工具而言，问题领域模型应该在解决方案领域模型中使用。为此，我们借助使用建模工具的相关功能。

创建和组织系统需求规格的模型，如下。

1) 开始共享问题域模型。

有关此主题以及步骤 和步骤 中提到的相关主题的更多信息，请参阅建模工具的最新文档。

2) 创建一个新模型，并命名为VehicleCCS Solution.mdzip。
3) 在解决方案域模型中设置问题域模型作为read-only，问题域模型就会以只读形式导入到解决域模型，可以
使用但不能编辑，如图2-10。

图2-10

灰色字体表示不能修改。这是因为问题域模型在解决方案域模型中是作为只读的原因。

4) 右键单击Model包(这是根包的默认名称)并选择Create Element。
5) 在搜索框中，键入pa(元素类型Package的前两个字母)并按回车键。
6) 键入2 Solution Domain来定义新包的名称，并按回车键。
7) 右键单击2 Solution Domain包并选择Create Element。
8) 重复步骤5。
9) 键入1 System Requirements来定义新包的名称，并按回车键，如图2-11。

图2-11
步骤2： 创建系统需求视图

为了捕获和显示系统需求，建议使用SysML需求图或需求表。如何使用需求表已在章节涉众要求中介绍，
下面描述了如何使用视图。

创建SysML需求图以定义系统需求，如下。

1) 右键单击1 System Requirements包并选择Create Diagram。

2) 在搜索框中键入rd，其中r代表需求，d代表视图，然后双击回车以创建需求视图，如图2-12。

注意，视图是以存储它的包命名的。您只需要从其名称中删除序列号。

图2-12

步骤3： 定义系统需求

通过车辆空气调节单元的白盒分析，我们识别出了以下系统需求：

表2-1
捕获模型中的系统需求，如下。

1) 打开System Requirements图，如果还没有打开的话。
2) 单击视图面板上的Requirement按钮，然后单击视图编辑区的空白空间,一条新需求将被创建。
3) 在需求框中直接键入上面表格中第一个需求的名称并按回车键。
4) 单击需求上的Text属性值一次，然后再单击一次。然后属性将切换到编辑模式。
5) 键入第一条需求的文本。
6) 当你完成时，点击需求框以外的空白处。
7) 重复步骤2到步骤6以捕获其余的需求。
完成之后，您的System Requirements需求图的内容看起来如下图2-13。

图2-13

此外，您需要一个分组需求来表示整个需求规格。创建分组需求的最简单方法在涉众要求章节的第4步教程
中进行了描述。按照步骤创建名为SRS for VCCS的分组需求。

在System Requirements需求图中显示需求层次结构，如下。

1) 将分组需求SRS For VCCS拖动到该需求图编辑区中。

2) 右键单击需求的框并选择Display > Display Paths，然后需求之间的包含关系显示在需求图编辑区中。

3) 在需求图工具栏(位于需求图编辑区的顶部)上，单击Quick diagram Layout按钮 ．

为了将系统需求与涉众要求、子系统和组件需求以及系统实现的详细需求区分开来，我们建议在它们的编
号上添加前缀。按照涉众要求章节的第5步教程中描述的步骤将前缀SR-添加到您的系统需求中。随后，可以将
这些系统需求重构为更具体的需求。例如，Setting Desired Temperature可以重构为接口需求，Max Energy
Consumption可以重构为物理需求。为此，遵循涉众要求章节的第6步教程中描述的步骤对需求进行重构。在您完
成编号和分类之后，系统需求图的内容看起来如下图2-14。
 图2-14

步骤4： 建立涉众要求的可追溯性

从系统需求到涉众要求的追溯关系可以在SysML需求图或矩阵中建立。我们建议在大范围内使用矩阵，因
为它提供了比视图更为紧凑的模型视角。

在本书例子里，您需要说明哪些系统需求(更具体)由哪些涉众要求(抽象)派生而来，也就是说，在它们之
间建立派生关系。因此，我们建议使用派生需求矩阵，这是建模工具中预定义的矩阵之一。不同于普通矩阵，
它预定义了一些准则来方便我们快速创建追溯关系。

就像在问题域模型中一样，可跟踪性视图和关系可以存储在一个单独的包中。因为您已经知道如何创建
包，所以我们假设您是自己创建包的。为了根据MagicGrid框架保持模型的良好组织，该包应该始终是2 Solution
Domain包的最后一个子包。因此，它的名称必须以数字5开始，例如，5 Traceability。

创建派生需求矩阵，如下。

1) 在模型浏览器中，右键单击5 Traceability包并选择Create Diagram。

2) 在搜索框中，键入drm(预定义派生需求矩阵的首字母缩写)，然后按回车键。

如果你没有看到任何结果，点击搜索结果列表下面的Expert按钮。可供选用图表的列表将在
模式中展开。

3) 键入System Requirements to Stakeholder Needs作为新矩阵的名称，并再次按回车键。

4) 在模型浏览器中，选择需求SR-1 SRS for VCCS，并将其拖到矩阵上方的Criteria(条件)区域的Row Scope框
中。然后SR-1 SRS for VCCS需求成为矩阵行的范围。
 5) 在模型浏览器中，选择SN-1 Stakeholder Needs requirement (您可能需要先依次展开1 Problem Domain, 1
Black Box, 和1 Stakeholder Needs packages)，并将其拖到矩阵上方的条件区域的Column Scope（列范围）
框中。然后SN-1 Stakeholder Needs需求成为矩阵列的范围。

6) 单击Direction（方向）框并选择Row to Column（行到列），然后将建立从系统需求 (行元素) 到涉众要求

(列元素) 的派生关系，如图2-15。
7) 单击Criteria区域下方提示框中的Refresh超链接。更新了矩阵的内容。目前所有的单元格都是空的。

图2-15
下图显示了矩阵的Criteria区域，在步骤4、5和6中突出显示了相关的准则。

现在已经准备好建立派生关系了。我们将在SR-1.1 Setting Desired Temperature和SN-1.6 Desired Temperature

之间创建一个派生关系，以表示SR-1.1 Setting Desired Temperature是从SN-1.6 Desired Temperature派生出来的，
或者，换句话说，这个系统需求是由于涉众要求而创建的。

定义矩阵中的派生关系，如下。

 双击 SR-1.1Setting Desired Temperature和SN-1.1.6 Desired Temperature在行列交叉处的单元格。派生关

系被创建并显示在单元格中，如图2-16。
图2-16
 如果您想在设置关系之前阅读需求文本内容，只需将鼠标移到需求名称上停留几秒钟，然后文本将出
现，如图 所示。

定义完所有的派生关系之后，您的系统需求到涉众要求派生矩阵如下图2-18所示。您可能还记得，每个系
统需求都必须来自一个或多个涉众要求。否则，必须修改和更新系统需求规格。如果决定不在系统需求规格中
处理一些涉众要求，那么这些涉众要求可能不会被覆盖。

图2-18

然后，可以创建需求派生图，用蓝色箭头表示来自不同领域的需求之间的派生关系，如图2-19。

图2-19
 步骤5: 建立到问题域模型元素的追溯关系

从系统需求到问题域模型的其余部分的可跟踪关系可以在SysML需求图或矩阵中建立。我们建议大范围使
用矩阵，因为它提供了比图表更紧凑的模型视图。

在这种情况下，您需要确定哪些问题域元素是由哪些系统需求细化的；也就是说，在它们之间将建立细化
(Refine)关系。因此，我们建议利用细化需求矩阵(Refine Requirement Matrix)的基础结构，这是建模工具中预定
义的矩阵之一。与普通矩阵不同，它有一些预定义的准则来加速视图的构建。

该矩阵和所建立的关系可以存储在您在前面步骤中创建的5 Traceability包中。

创建一个细化需求矩阵(Refine Requirement Matrix) ，如下。

1) 在模型浏览器中，右键单击5 Traceability包并选择Create Diagram。

2) 在搜索框中，键入rrm(预定义的细化需求矩阵的首字母缩写)，然后按回车键。

如果在视图类型列表中看不到任何结果，请单击下面的Expert按钮。可用视图的列表将在
模式中展开。

3) 键入System Requirements to Problem Domain作为新矩阵的名称，并再次按回车键。

4) 在矩阵工具栏上，单击Change Axes(更改坐标轴)按钮以交换矩阵的行和列。需求变成矩阵行的类型。
5) 在模型浏览器中，选择需求SR-1 SRS for VCCS (您可能需要先展开 1 System Requirements包)，并将其拖
到矩阵内容上方的Criteria区域的Row Scope框中。然后需求SR-1 SRS for VCCS成为矩阵行的范围。
6) 选择列元素类型：
在模型浏览器中，选择任一调用行为动作；例如，类型为Initialize Cooling活动的调用行为动作 (它出
现在问题域分析模型的3 Functional Analysis包里的Reach Desired Temperature活动下) 。
将选中的调用行为动作拖到矩阵内容上方的Criteria区域的Column Element Type框上，矩阵的列被设
置为显示调用行为动作的元素。
在模型浏览器中，选择任一部件属性，例如类型为Cooling block部件属性。它出现在问题域分析模型
中的2 Logical Architecture包中VCCU块下。
按住Ctrl键并将选中的部件属性拖到矩阵内容上方的Criteria区域中的Column Element Type框中，矩阵
的列被设置为显示类型为部件属性的元素。
重复步骤c和d，使矩阵的列能够显示代理端口和应用了«MoE»构造型的值属性。
7) 定义列元素范围：
在模型浏览器中，选择问题域分析模型中的2 White Box包。
将选中的包拖到矩阵上方的Criteria区域的Column Scope框上，然后选定的包成为矩阵列的范围。
 8) 单击Direction框并选择Row to Column，然后您将建立从系统需求(显示为行元素)到捕获问题域概念(显示
为列元素)的工件的细化关系，如图2-20。
9) 单击Criteria区域下方提示框中的Refresh超链接，更新了矩阵的内容。当前所有单元格都是空的。

图2-20

下图显示了矩阵的Criteria区域，其中高亮显示了步骤5、6、7和8的相关准则。

现在您已经准备好建立细化关系了。让我们在SR-1.1 Setting Desired Temperature需求和Human-Machine

interaction块的p1代理端口之间创建一个，以确定前者来细化后者，或者，换句话说，创建这个系统需求是为了
细化该代理端口。

在矩阵中定义细化关系，如下。

 双击显示SR-1.1 Setting Desired Temperature的行和显示p1代理端口的列的交叉处的单元格。在适当的项

之间创建细化关系并显示在单元格中，如图2-21。

图2-21

在所有细化关系被定义之后，您的System Requirements to Problem Domain矩阵应该类似于下图2-22。请记

住，每个系统需求都必须细化问题域分析模型中捕获的一个或多个元素。否则，必须修改和更新系统需求规
格。如果决定不在系统需求规格中处理某些元素(例如声级和总重量的MoE)，则可以忽略它们。

图2-22
2.1.1.5 系统需求已完成，下一步做什么?

 当您在SysML需求模型中捕获了系统需求规格后，您就可以开始构建目标系统的逻辑架构了。这意味
着您可以移动到System Structure单元格。

 在构建目标系统的逻辑架构时，可以随时更新系统需求规格。只有在切换到子系统级解决方案域模型
后，更新才应该停止。
2.1.2 系统结构

2.1.2.1 它是什么?

在完成系统需求规格之后，您可以开始构建目标系统的逻辑架构。通常从捕获目标系统的逻辑子系统开
始。逻辑系统架构（LSA）还定义了接口，以确定这些子系统是如何相互操作并集成为一个整体。解决方案域
的子系统可能与问题域中识别出的子系统不同。这种情况经常发生，因为问题域定义不像解决方案架构定义那
样精确。为了实现从解决方案架构的子系统追踪到问题域模型中概念架构的子系统，我们可以建立交叉关系。

定义逻辑子系统的目的是为了在系统工程项目中建立工作分解结构(WBS)。每个逻辑子系统标识为一个单
独的工作包，并立即被指派给一些工程团队。该团队为定义的子系统开发一个或多个逻辑架构。这些独立的团
队之间通常是并行工作来开发不同子系统的逻辑架构。单个子系统的逻辑架构建模在构建子系统逻辑架构一章
中进行了描述。

2.1.2.2 谁负责?

系统架构师或系统工程师可以捕获LSA模型中的系统结构。他/她必须是整个系统工程项目的负责人，他拥
有目标系统的“大局观”，并负责将子系统及其组件平滑地集成到整个系统中。

2.1.2.3 如何建模?

如您所记得的那样，LSA捕获目标系统、其向下一级的逻辑子系统以及用于确定这些子系统如何相互操作
的接口，即它们交换哪些数据、物质或能量。可以在SysML bdd(块定义图)中创建并显示LSA模型。可以将子系
统捕获为块，将接口捕获为由对应的接口块类型化的代理端口。

在下图2-23中，您可以看到一个车辆空气调节单元(VCCS)的LSA模型样本。它显示了捕获VCCS逻辑子系
统的块，拥有流属性的接口块，捕获外部和内部通信的输入和输出，以及相关流属性类型的各种交换项目。
 图2-23

«abstraction» 关系可以用来声明LSA中的逻辑子系统是从问题域分析模型中的概念子系统(功能块)中派生出来
的，如图2-24。

图2-24

2.1.2.4 教程

步骤1: 组织LSA的模型

可以从系统需求章节中创建的解决方案域模型里捕获逻辑系统架构LSA。首先您需要预先建立一个模型结
构。按照MagicGrid框架的设计，相关的模型工件应该存储在包的结构下，如下图2-25所示。

图2-25

组织LSA模型，如下。

1) 打开您在系统需求章节中创建的解决方案域模型(VehicleCCS Solution.mdzip)文件),如果尚未打开话。
2) 右键单击2 Solution Domain包，并选择Create Element。
3) 在搜索框中，键入pa(元素类型Package的前两个字母)，然后按回车键。
4) 键入2 System Structure定义新包的名称，按回车键。
为了使2 System structure包的内部结构组织清晰，您需要创建更多的包。包括：

 1 Logical Interfaces
  2 Exchange Items

 3 Logical Subsystems

在创建完后 (按照前面的步骤自行创建)，解决方案域模型的模型组织结构应该与下图2-26相同。

图2-26
步骤2: 创建捕获LSA的bdd

为了准备捕获VCCS的逻辑架构，您需要首先创建bdd图。

创建用于捕获VCCS逻辑架构的bdd图，如下。

1) 右键单击2 System Structure包并选择Create Diagram。

2) 在搜索框中，键入bdd (SysML块定义图的缩写)，然后按回车键，创建图表。
3) 键入Logical Architecture of VCCS定义新关系图的名称，并再次按回车键。
步骤3: 捕获逻辑子系统

正如系统需求规格所示，VCCS包括：

 HMISystem，其中HMI代表人机接口（Human-Machine Interface）
 CP System，其中CP代表中央处理（Central Processing）
 Cooling System，制冷系统
 Heating System，制热系统
逻辑子系统可以被捕获为上一步中创建的bdd中的块。如前所述，逻辑系统架构LSA模型总是在下一层定义
逻辑子系统，并且每个子系统的逻辑架构应该随后由独立的工程团队在独立的模型中搭建(参见2.2.2子系统结构
章节)。

请注意，逻辑子系统的名称对应于问题域模型中概念子系统的名称，例如Cooling System to Cooling，或者

Heating System to Heating。然而，这些概念并不相同；因此，在定义VCCS的逻辑子系统时，请确保没有从问题
域模型中选择块，而是要在解决方案域模型中创建一个新的块。为了防止出错，您可以预先缩小名称自动补全和
类型选择范围。下图2-27显示了之前(左边)和之后(右边)的自动完成，将范围缩小到解决方案域模型。

图2-27

将自动完成和类型选择范围缩小到解决方案域模型，如下。

1) 创建一个包图：
右键单击2 System Structure包并选择Create Diagram。
在搜索框中键入pd，其中p代表package, d代表diagram，然后按回车键。包图被创建。
键入“ Scope for Auto-completion and Type Selection”命名新包图，并再次按回车键。
2) 在模型浏览器中，选择2 Solution Domain和2 System Structure包(后者是前者的子包)，并将它们拖动到新创
建的包图的编辑域中。

3) 选择2 System Structure 包，在它旁边的智能操作工具栏上单击包的import按钮 。

4) 选择2 Solution Domain包，在包之间创建包的W导入关系，如图2-28。

图2-28

从现在开始，当您在2 System Structure包中建模时，建议作为名称和类型的元素将只从2 Solution Domain包

中提取，而存储在1 Problem Domain包(来自问题域模型)中的元素将被放在一边。这意味着不建议您从问题域模
型中捕获的概念性子系统和接口以及交换项中进行选择。
 如果您仍然看到这些元素，请单击过滤选项按钮 ，在其列表下方单击并勾选Filter By Package Imports复
选框(见下图2-29)。有关包导入特性的更多信息，请参阅建模工具的最新文档。

图2-29

获取目标系统的逻辑子系统，如下。

1) 打开Logical Architecture of VCCS块定义图(如果尚未打开)。

2) 在解决方案域模型中捕获目标系统：
单击视图面板上的Block按钮，然后单击视图编辑区。
键入VCCS以命名块并按回车键。
3) 捕获逻辑子系统：
在VCCS块旁边的智能操作工具栏上点击组合按钮 ，然后单击视图编辑区上的空白处。
键入HMI System以命名块并按回车键。
重复步骤3.a 和3.b，从上面的列表中获取其他子系统。

4) 在图工具栏上，单击快速布局按钮 ，如图2-30．

图2-30
 注意，部件属性名称 显示在关系的箭头末端 与默认值不同。它们可以手动更改。为此，您需要
在视图上选择想要重命名的部件属性，然后再次单击它以进入名称编辑模式 参见下图 。您可
以立即修改它。

5) 在模型浏览器中，选择子系统的所有块，并将它们拖到您在本单元教程的第1步中创建的3 Logical
Subsystems包中。如下图2-32显示，这些块已经被移动到3 Logical Subsystems包中。

图2-32

步骤4: 建立对问题域模型的可跟踪性

可追溯关系使您能够指定问题域模型中识别出来的哪个概念子系统(又名功能块)，决定了逻辑系统架构
LSA模型中哪个逻辑子系统的创建。针对本例，我们使用抽象关系建立从解决方案域到问题域的追溯关系。

您已经知道，建立可跟踪关系的最有效方式是矩阵。接下来让我们创建一个追溯矩阵。

创建问题域模型的可跟踪关系矩阵，如下。

1) 在模型浏览器中，右键单击5 Traceability包，它是2 Solution Domain的子包，并选择Create Diagram。

2) 在搜索框中，键入dm(依赖矩阵的首字母缩写)，然后按回车键。

如果你没有看到任何结果，点击搜索结果列表下面的Expert 专家模式 按钮。可用的视图列表将

在 模式中展开。

3) 键入LSA to Problem Domain以命名新的矩阵的名称，再按回车键。

4) 定义行和列元素类型：
在模型浏览器中，选择任意块，例如VCCS块。
将其拖到矩阵内容上方的Criteria 区域的Row Element Type 框中。矩阵的行和列都被设置为显示块类
型的元素(见下图)。
单击Column Element Type框旁边的按钮。
 在打开的对话框中，单击以清除包含子类型复选框。否则，列会显示一些这里不需要显示的接口
块。
单击OK关闭对话框。
5) 定义行元素范围：
在模型浏览器中，选择VCCS块。
将选中的块拖到矩阵内容上方的Criteria 区域的Row Scope框上。选定的块成为矩阵行的范围。
在模型浏览器中，选择3 Logical Subsystems 包，它与VCCS块在同一个包中。
按住Ctrl键并将选中的包也拖到Row Scope框上。3 Logical Subsystems 包和VCCS块一起成为矩阵行的
范围(见下图)。
6) 定义列元素范围：
在模型浏览器中，选择VCCU块(为此，您可能需要点开以下只读包的内容： 1 Problem Domain > 2
White Box > 2 Conceptual Subsystems Communication )。
将选中的块拖到矩阵内容上方的Criteria区域的Column Scope 框上。选定的块成为矩阵列的范围。
在模型浏览器中，选择2 Conceptual Subsystems 包，它与VCCU块在同一个包下。
按住Ctrl键并将所选中的包也拖到Column Scope框上。然后2 Conceptual Subsystems 包连同VCCU块成
为矩阵列的范围， (见下图2-34)。
7) 定义依赖准则：
单击Dependency Criteria 框旁边的按钮。
在打开的对话框中，找到抽象关系。：
a) 在条件列表下面的搜索框中键入abs。
b) 单击以选择抽象关系旁边的复选框。
c) 单击OK。抽象关系成为矩阵的依赖准则(见下图2-34)。
8) 单击Direction框并选择Row to Column，然后您将建立从逻辑子系统(行元素)到概念子系统(列元素)的抽象
关系。
9) 单击Criteria 区域下方提示框中的Refresh超链接。更新矩阵的内容。然后可以看到此刻所有的单元格都是
空的，还没有关系被建立。
下图2-34显示了矩阵的Criteria 区域，其中高亮显示了步骤4、5、6、7和8的相关准则。

图2-34
 现在您已经准备好定义抽象关系了。双击相关行和列相交处的单元格(例如，在表示Cooling System块的
行和表示Cooling块的列之间) ，如图2-35。

图2-35
在所有抽象关系被建立之后，你的模型中的LSA to Problem Domain依赖矩阵应该类似于下图2-36。

图2-36

步骤5: 捕捉逻辑接口

如系统需求规格所示，VCCS应该能够从外部接收到以下内容：

 用户设定的温度
 温度传感器测量到的环境温度
 对驾驶室空气的制冷或制热
这些需求语句显示出系统相互间需要逻辑接口，正如下图2-37所示。这些接口比问题域分析模型中确定的
概念接口更精确：DesiredTmpSet 和 AmbientTmpRead 具有值属性，可保存特定Integer类型。这些属性也可以设
置默认值，例如DesiredTmp=22。
 图2-37

如果您已经学习了概念子系统章节中的教程，您应该已经知道如何创建带有流属性的接口块，以及如何将
这些接口块和系统架构块绑定。如果之前章节漏过这些，这是另一个学习接口知识的机会。

捕获接口块以提供所需的温度，并将其与VCCS块关联，如下。

1) 打开Logical Architecture of VCCS 块定义图(如果尚未打开)。

2) 单击视图面板上的Interface Block按钮，然后单击视图编辑区上的空白位置。在2 System Structure下会直接
创建了一个未命名的接口块，并显示在视图上。
3) 键入UserDataInput以命名接口块并按回车键。
4) 单击Create Property按钮 ，并选择Flow Property，如图2-38。

图2-38
5) 对接口块直接操作如下所示：
移除流属性方向指示器的out部分，设定流属性的方向为in。
键入dts以指定流属性名称。此时不要按回车!
键入: DesiredTmpSet并按回车键。在模型中直接在UserDataInput接口块下创建DesiredTmpSet信号，
并随即将其设置为唯一的流属性类型。
6) 组织模型：
确保在视图上选择了UserDataInput接口块并按Alt+B。元素在模型浏览器中被选中。
点击UserDataInput接口块边上的 号展开其他内容。
选择DesiredTmpSet信号并将其拖动到3 Exchange Items包中。
再次选择UserDataInput接口块，并将其拖到2 System Structure 包的子包1 Logical Interfaces 包中。
7) 选择视图中的UserDataInput接口块，并将其拖到VCCS块上。从而为VCCS块创建一个新的代理端口，该
端口类型为UserDataInput接口块。注意，该代理端口上有一个箭头，表示该端口是目标系统的键入，如图
2-39。

图2-39
8) 创建用于显示交换项的视图：
在模型浏览器中，右键单击3 Exchange Items包并选择Create Diagram。
在搜索框中，键入bdd (SysML块定义图的首字母缩写)，然后按回车键。然后块定义图被创建。
从默认视图名称中删除序号，再次按回车键。
9) 为DesiredTmpSet信号创建一个属性：
在模型浏览器中，选择该信号并将其拖动到Exchange Items视图编辑区中。
在信号符号上单击Create Property按钮
键入DesiredTmp来命名新属性。
键入Int 并按下Ctrl +空格键打开可能的类型列表。在搜索结果列表中看到Integer值类型(粉色的那个)
后，选择它。
 输入=22，按回车键。为信号创建默认值为22的Integer类型的属性，如图2-40。

图2-40

按照上面的步骤，再捕获另外两个接口块(包含所有相关信息)，并将它们绑定到VCCS块上。完成之后，模
型中的Logical Architecture of VCCS 块定义图应该与本教程步骤的第一张图相似。

系统需求规格还表明，VCCS应能够向外界提供以下内容：

 供给驾驶室适温的冷空气或热空气
 将VCCS状态信息反馈给驾驶员或用户
这些语句表明VCCS需要更多的接口。你可以在下图2-41中看到它们。我们假设您自己来更新模型。

图2-41

现在该开始考虑VCCS的逻辑子系统的逻辑接口了。就像目标系统本身一样，每个逻辑子系统可
以有许多逻辑接口。其中一些是从目标系统继承来的用于对外通讯。有些用于与VCCS的其他子系统
进行内部通信。这些是在LSA逻辑系统架构中从头开始定义的。

让我们从为外部通信定义的逻辑接口开始。如前所述，您不需要创建新的接口块：只需将选中的接口块拖
到捕获了相关逻辑子系统的块上(与您对VCCS块所做的相同)。例如，可以将InsideAirInlet接口块拖到Cooling
System块上。这就为Cooling System块创建一个InsideAirInlet接口块类型的代理端口，如图2-42。

图2-42

在定义了用于外部通信的所有接口之后，您的模型中的Logical Architecture of VCCS 块定义图如下图2-43。

现在让我们考虑用于逻辑子系统之间内部通信的逻辑接口。
 图2-43

很明显，CP System应该能够向其他子系统发送命令。这些命令可能包括启动、停止、待机、制冷、加热
等。稍后可以在对子系统的逻辑架构建模时识别它们。同时需要创建一个新的接口块和一些信号(下图2-44中被
高亮显示)。另外，必须添加新的派生出来的子系统需求，这些建模工作让我们留在其他单元中完成。

图2-44
 注意，新创建的接口块的cmd流属性方向是out。这是因为它是从CP系统的角度定义的，CP系统应该能够向
VCCS的其他子系统发送命令。

下一步是定义CP System块能够将命令信号或命令信号的任何子类型信号发送出去，并且Cooling System、

Heating System和HMI System块能够接收它们。所以应该为捕获逻辑子系统的每个块创建代理端口，然后将
Cooling System、Heating System和HMI System块的代理端口共轭。这些接口块的代理端口名字前会出现波浪号
(~)，表示这些代理端口的流属性方向与定义相反, 即Cooling System、Heating System和HMI System能够接受
Command信号或任何其子类型信号。

创建共轭代理端口，如下。

 右键单击该代理端口，然后选择Is Conjugated，如图2-45。

图2-45

这里需要注意的是，尽管这种指定兼容代理端口的方式更简单，但并不推荐。在实际项目中，定义
几个兼容的接口块，比定义了一个接口块，然后使其中一个代理端口共轭则更常见。
还有两个接口，InternalResponse和InternalDataTransferer，可以指定它们用于内部通信。见下图2-46。我们
假设您在模型中已经定义并高亮显示这些SysML元素。
 图2-46

2.1.2.5 完成系统结构，下一步做什么?

 有了逻辑子系统并知道它们将如何通信，您就可以开始处理它们的逻辑架构模型。因此，您可以转到构
建子系统的逻辑架构章节。

 不过您仍留有两个单元格用来创建逻辑系统架构模型。因此，您应该继续进入系统行为和系统参数单元格
构建模型。
2.1.3 系统行为

2.1.3.1 它是什么?

逻辑系统架构LSA不仅是关于系统结构的；系统架构师也可以在LSA模型中捕获整个目标系统的行为。然
而，这并不是一种常见的做法。由于目标系统的精确逻辑架构尚未定义，因此系统行为模型显得过于抽象，不
能充分地说明系统行为。此外，它可能与所选系统配置的集成模型中的系统行为发生冲突(参见2.3构建系统配
置模型章节)。这就是为什么在实际项目中构建目标系统的逻辑系统架构时经常跳过这个单元格原因。

与LSA模型不同，所选系统配置的系统行为在集成模型中是至关重要的。由于集成模型包含了目标系统的
所有逻辑子系统的架构，因此可以用来分析整个系统的集成行为，并执行系统需求验证。

2.1.3.2 谁负责?

系统架构师或系统工程师可以捕获LSA模型中的系统行为。他/她必须是整个系统工程项目的负责人，他拥
有目标系统的“大局观”，并负责将子系统及其组件平滑地集成到整个系统中。

2.1.3.3 如何建模?

可以通过SysML状态机图、活动图或时序图的组合来捕获LSA模型中的系统行为。SysML状态机允许捕获
目标系统的状态以及它们之间的转换，以响应随时间发生的事件。活动或时序图应该用于定义这些状态或转换
效果的entry, do, 和exit行为。

虽然下图2-47只捕获了制冷系统(子系统之一)的行为，但整个LSA模型中目标系统的行为与此非常类似。

图2-47
 为了避免与所选系统配置的集成模型中的系统行为发生冲突，必须将 模型中已定义的系统行为
从 块中的分类器行为(Classifier Behavior)里取消。为此，请执行以下操作，如图

右键单击VCCS块并选择Specification。
在打开的对话框中，从Properties下拉列表中选择Expert模式以扩展属性列表。
单击Classifier Behavior(译注：类目行为)属性值的单元格，并从下拉列表中选择
<UNSPECIFIED>。

2.1.3.4 教程

按照通常的做法，我们在LSA模型中先跳过这个单元，然后在系统配置模型中再返回来完成(参见2.3.2系统
配置行为章节)。

2.1.3.5 下一步做什么?

下一个要访问的单元格是系统参数。
2.1.4 系统参数

2.1.4.1 它是什么?

一旦在模型中捕获了系统结构，您就可以进入这个单元格，即使是抽象的逻辑系统架构模型。

系统参数捕获目标系统的量化特征，您可以度量这些特征。它们用于计算问题域分析期间确定的那些
MoEs(见有效性度量章节)。在解决方案领域模型中捕获的MoE满足非功能性定量系统需求。

从系统参数推导MoE的数学表达式也在这个单元格中被定义。了解如何计算MoE，有助于尽早对系统需
求进行验证。使用建模工具的功能，可以通过执行模型来计算这些值，并显示被量化的需求是否得到满足。

这里需要注意的是，并非解决方案域中的所有MoE都来自于问题域模型中的MoE。其中有一些只有在构
建目标系统的逻辑架构时才能被识别。

2.1.4.2 谁负责?

LSA模型中的系统参数可以由系统架构师或系统工程师捕获。他/她必须是整个系统工程项目的负责人，
他拥有目标系统的“大局观”，并负责将子系统及其组件平滑地集成到整个系统中。

2.1.4.3 如何建模?

正如您应该已经知道的，有效性度量可以捕获自模型中应用了«MoE»构造型的值属性。这些值属性必须
属于块，它代表目标系统。您还必须知道，有效性度量可以从可重用的MoE集合(称为MoE持有人)中继承，而
不是从头定义它们。

计算MoE的公式可以捕获自某个约束块的约束表达式。SysML块定义图的基础结构可用于捕获MoE、约束
表达式，甚至所需的系统参数。下图2-49块定义图捕获了totalEnergyConsVCCS有效性度量，以及作为Total
Energy Consumption约束块中的约束表达式来计算MoE的公式。

图2-49

为了使约束表达式能够执行计算，您必须指定哪些系统参数应该作为该约束的变量。就像MoE一样，系
统参数可以在模型中捕获，作为捕获目标系统或它的任何子系统的块的值属性，只是没有应用任何构造型。
SysML参数图可以将系统参数、MoE与约束变量绑定起来，系统参数作为输入，MoE作为输出。为此应该使用
绑定连接器(用实线表示，如下图2-50所示)。
 图2-50

建模工具的仿真功能允许您使用给定的输入来计算MoE。通过计算MoE，您可以验证对应的非功能性系
统需求，并显示它是否得到满足。建模工具使您能够自动执行此验证。为了为自动化需求验证做好准备，您
需要在捕获了MoE的值属性到对应的系统需求之间创建一个满足关系。下图2-51显示了totalEnergyConsVCCS
值属性与Max Energy Consumption这条非功能性需求之间的满足关系的示例，这意味着当totalEnergyConsVCCS
值属性的值不大于3.518 kWh时，需求就满足了。如您所见，需求文本中的自然语言表达式由Max Energy
Consumption约束块的另一个约束表达式(不等式x <= 3.518)来细化。

图2-51

除了在SysML需求图中可以表示满足和细化关系，块定义图bdd也可以。

2.1.4.4 教程

步骤1： 组织系统参数模型
 正如系统需求规格所定义的，我们需要定义计算车辆空气调节单元总能耗的数学表达式。捕获到的约束
块可以存储在2 Solution Domain包中的单独包中，如图2-52。

图2-52

组织用于存储约束块的模型，如下。

1) 打开您在系统需求章节中创建的解决方案域模型(VehicleCCS Solution.mdzip 文件)，如果已打开则跳转到

下一步。
2) 右键单击2 Solution Domain包并选择Create Element。
3) 在搜索框中，键入pa(元素类型Package的前两个字母)，然后按回车键。
4) 键入4 System Parameters以命名新包，按回车键。

在模型中我们还没有涉及3 System Behavior包 在 模型中对系统行为建模不是必要的 ，所以

我们在包编号中先跳过“ ”。

步骤2： 定义用于捕获总能耗的MoE

从下图2-53中可以看到,系统需求规格(见系统需求章节)和在问题域模型中对应的MoE(见有效性度量章节)
确定了解决方案域模型中VCCS下总能量消耗MoE。

图2-53
 前面已经提到过，MoE可以从零开始定义，也可以从MoE Holder即MoE库中继承。下面的过程描述了如
何从MoE库中继承。重定义继承的MoE更改其名称和类型。重定义对于自动化需求验证是必要的，参考如下
步骤。

捕获并定义VCCS总功耗的MoE，如下。

1) 创建一个块定义图bdd用于捕获系统参数：
右键单击在本单元教程的第1步中创建的4 System Parameters包，并选择Create Diagram。
在搜索框中，键入bdd (SysML块定义图的首字母缩写)，然后双击回车键，块定义图被创建了。
键入“System Parameters for Total Energy Consumption”以指定新建块定义图的名称，并再次按回车
键。
2) 在视图中显示MoE Holder块：
按Ctrl + Alt + F打开Quick Find对话框。
在对话框中，键入moes。
当您看到在搜索结果列表中选中的MoE Holder块时，按回车键。在模型浏览器中选中了该块。
将MoE Holder块拖动到视图编辑区中，如图2-54。

图2-54
3) 在图中显示VCCS块：
按Ctrl + Alt + F打开Quick Find对话框。
在对话框中，键入vccs。
当您在搜索结果列表中看到选中的VCCS块时，按回车键。然后在模型浏览器中选择该块。
将VCCS块拖到视图编辑区中，VCCS块将显示在视图中，如图2-55。

图2-55
4) 建立VCCS块与MoE Holder块之间的泛化关系：
选择VCCS块的形状，然后单击在它的智能操作工具栏上泛化按钮 。
选择MoE Holder块的形状。然后MoE Holder块成为VCCS块的超类型，即VCCS块继承MoE Holder块
中的所有MoE，如图2-56。

图2-56

5) 重定义VCCS块的totalEnergyConsumption值属性：
双击VCCS块以打开其规格。
在打开的对话框的左侧，单击Properties。
6) 选择totalEnergyConsumption值属性并单击下面的Redefine按钮，如图2-57。

图2-57

在Type单元格中，键入kWh并按回车键。kWh值类型在模型中创建，并设置为重定义的值属性的类
型。
 在Name单元格所在列中，键入totalEnergyConsVCCS以重命名重定义的值属性，并按回车键，如图
2-58。

图2-58

单击Close，关闭窗口。
当您完成以上步骤后，您的模型中System Parameters for Total Energy Consumption 块定义图如下图2-59
所示。

图2-59
步骤 ： 定义计算总能耗的方法

你需要做的下一件事是捕获数学表达式，它定义了如何计算以上定义的MoE。它可以被捕获为存储在模
型中的某个约束块的约束表达式。

假设VCCS的总能耗等于它所有子系统的能耗之和。约束表达式定义如下：

totalEnergyCons = energycon1 + energycon2 + energycon3 + energycon4

其中：

1. totalEnergyCons表示VCCS消耗的总能量
2. energycon1表示制冷系统消耗的能量
3. energycon2表示CP系统所消耗的能量
4. energycon3表示供暖系统所消耗的能量
 5. energycon4表示HMI系统消耗的能量
在SysML里 totalEnergyCons, energycon1，…和energycon4通常被称为约束参数，随后会绑定到值属性。

您可以使用本单元格教程的步骤2中创建的bdd块定义图来捕获约束块。

获取计算VCCS总能耗的方法，如下。

1) 创建一个约束块：
打开System Parameters for Total Energy Consumption参数图。
单击视图面板上的Constraint Block按钮，然后单击该视图编辑区中的空白区域。一个未命名的约束
块就被创建了。
直接在该约束块中键入Total Energy Consumption块名称并按回车键。
2) 指定一个约束表达式来捕获上面定义的公式：
在Total Energy Consumption约束块上单击空约束表达式的符号{}，如图2-60。

图2-60

再次单击所选内容，空约束表达式切换到编辑模式，如图2-61。

图2-61

键入totalEnergyCons= energyCon1 + energyCon2 + energyCon3 + energyCon4，然后按回车键，如图2-

62。

图2-62

3) 定义约束参数：
选择Total Energy Consumption约束块，在其智能操作工具栏上(见下图2-63)，单击Parse and Create
Parameters按钮 ，从约束表达式中自动提取约束参数并显示在参数间隔栏中。
 图2-63

逐个选择参数，并在约束块上直接将它们的类型从默认的Real更改为kWh：
a) 双击类型选择，键入kWh，按Ctrl +空格键。
b) 从下面的列表中选择kWh类型。
c) 按回车。

做完后，Total Energy Consumption约束块应如下图2-64所示。

图2-64

步骤 ： 定义系统参数，用于计算总能耗

使用约束表达式，您可以很容易地确定要计算VCCS总能耗所需的系统或子系统(在本例中)参数。输入
Total Energy Consumption 约束块的参数可以帮助您完成此任务。

请记住，它有四个输入参数，每个参数代表VCCS的单个子系统的能量消耗，并且在您的模型中需要四个
子系统参数。我们要为捕获VCCS子系统的每个块指定对应的值属性。

为捕获VCCS的每个子系统所消耗的能量定义子系统参数，如下。

1) 打开系统总能耗参数图System Parameters for Total Energy Consumption。

2) 显示捕获VCCS块的逻辑子系统的块：
右键单击VCCS块，选择Display > Display Related Elements。
 在打开的对话框中，单击Outgoing，然后选中Association复选框，如图2-65。

图2-65
单击OK关闭对话框。可以看到表示VCCS子系统的所有块都显示在视图编辑区中，如图2-66。

图2-66

3) 为制冷系统Cooling System块创建energyCons值属性：
选中制冷系统块，单击创建元素按钮 ， 然后选择Value Property
键入energyCons:kW，按Ctrl +空格键选择合适的值类型。
在下拉列表中选择kWh值类型，然后回车。
再按回车键。
4) 重复以上步骤3，为CP System, Heating System, 和 HMI System块创建值属性，如图2-67。
 图2-67

步骤5： 绑定约束参数到相应的值属性

一旦模型中有了所有必要的值属性，就该将它们绑定到对应的约束参数了。请记住，正是绑定赋予了约
束表达式对给定输入执行计算的能力。

可以使用绑定连接器建立值属性和约束参数之间的绑定。可以使用为VCCS块创建的SysML参数图的基础
结构来创建这种类型的SysML关系。然而，创建SysML参数图还不足以开始工作。只有在为VCCS块创建了由
Total Energy Consumption约束块类型的约束属性之后，才能建立绑定连接器。请注意，同一个约束块可以在多
个上下文中使用，而绑定连接器是上下文中特定的关系。

将约束参数绑定到相应的值属性，如下。

1) 在模型浏览器中选择VCCS块：
按Ctrl + Alt + F，Quick Find对话框打开。
键入vccs。
当您在搜索结果列表中看到VCCS块被选中时，按回车键。
2) 为VCCS块创建一个SysML参数图：
按Ctrl + N，打开Create Diagram对话框。
在搜索框中，键入par (SysML参数图的首字母缩写)，并按回车键。创建空白的SysML参数图，并打
开Display Parameters/Properties对话框。
除了totalEnergyConsVCCS值属性(默认选择)之外，还可以选择显示另外四个值属性，每个都名为
energyCons，并由捕获VCCS的每个子系统的块拥有。

如果您无法看到它们，则可能需要展开相关的部件属性，如图 。

图
 单击OK。选中的值属性显示在视图编辑区中，并且此时在Model Browser中显示该视图已处于编辑
模式，如图2-69。

图2-69

如上图所示，深度嵌套的 值属性以点符号显示。 如果你想切换到嵌套符号， 选择除

totalEnergyConsVCCS值属性外的其余所有的元素符号，然后右键单击它们并选择Refactor >
Convert to Nested Parts，如图 。

键入Total Energy Consumption of VCCS以命名视图，并按回车键。

3) 找到Total Energy Consumption of VCCS约束块：
按Ctrl + Alt + F，Quick Find对话框打开。
键入total en。
当您看到在搜索结果列表中Total Energy Consumption约束块被选中时，按回车键。约束块在模型浏
览器中被选中。
4) 将约束块拖动到Total Energy Consumption of VCCS参数图中。VCCS块下一个类型为Total Energy
Consumption约束块的未命名约束属性被创建。同时，打开Parametric Equation Wizard对话框，如图2-
71。
5) 依次选择约束参数(在对话框的左侧)，并将每个参数拖动到对应的值属性(在对话框的右侧)：
 energycon1拖拽对应Cooling System块的energyCons值属性
 energycon2拖拽对应CP System块的energyCons值属性
  energycon3拖拽对应Heating System块的energyCons值属性
 energycon4拖拽对应HMI System块的energyCons值属性

你可能需要展开对话框右侧的结构来查看你需要的值属性。记住，它们属于子系统块，
而不是系统块。
一旦绑定，约束参数颜色将从红色变为灰色。

图2-71

6) 绑定所有项目后，单击OK。对话框关闭，所有绑定都显示在关系图上，如图2-72。

图2-72
 绑定连接器也可以从值属性或约束参数的智能操作工具栏中创建，如图2-73。

图2-73

现在您可以执行模型，提供输入值，并查看计算结果。要开始执行，请单击在Total Energy Consumption of

VCCS图上方的工具栏中的Run按钮 。在Simulation面板的Variables选项卡中(默认情况下，它在Simulation面
板的右侧)，可以定义输入值并查看输出值(计算的结果) ，如图2-74。

图2-74

步骤6： 执行早期的系统需求验证

有了捕获MoE的值属性的具体值，您就可以验证相关的系统需求并显示它是否得到满足。建模工具使您能
够自动执行此验证。您需要做以下工作为自动化需求验证做好准备：

1) 将捕获的约束形式化为特定系统需求文本中的自然语言短语。
2) 指出值属性，决定其值是否满足系统需求。
在本文案例中，您应该形式化Max Energy Consumption系统要求，即“The system shall consume maximum
3.518 kWh”。这需要使用约束表达式创建另一个约束块(不等式x <= 3.518)来确保细化相关的系统需求。
将Max Energy Consumption系统需求形式化，如下。

1) 为系统需求的形式化创建一个单独的视图：
右键单击1 System Requirements包并选择Create Diagram。
在搜索框中，键入rd (SysML需求图的首字母缩写)，然后按回车键，新需求视图被创建了。
键入System Requirements Formalized作为新建视图的名称，并再次按回车键。
2) 在视图编辑区显示Max Energy Consumption需求：
按Ctrl + Alt + F，Quick Find对话框打开。
键入max en。
当您看到搜索结果列表中Max Energy Consumption需求被选中时，按回车键。在模型浏览器中会发现
该需求被选中。
将需求拖到新创建的视图编辑区中。
3) 在视图编辑区中显示需求SRS For VCCS：
右键单击Max Energy Consumption需求，并选择Display > Display Related Elements。
在打开的对话框中，点选Outgoing，只选中Containment复选框，如图2-75。

图2-75
单击OK。
4) 创建Max Energy Consumption约束块：
在视图面板中，单击Constraint Block按钮。
单击视图编辑区上的空白位置。
键入Max Energy Consumption以命名新创建的元素，然后按回车键。
指定x <= 3.518不等式作为约束表达式：
a) 在约束块上单击空约束表达式的符号。
b) 再次单击所选内容，将空约束表达式切换到编辑模式。
c) 键入x <= 3.518，然后按回车键。
选中Max Energy Consumption约束块，在弹出的智能操作工具栏上单击解析和创建参数按钮 。然
后工具会从约束表达式中自动提取约束参数x并显示在参数栏中。
选择参数并在约束块的形状上直接将参数类型从默认的Real更改为kWh：
a) 双击类型选择，键入kWh，按Ctrl +空格键。
b) 从下拉列表中选择kWh类型。
c) 按下回车。
5) 指定Max Energy Consumption约束块与相关系统需求的细化关系：

选中约束块并在它的智能操作工具栏上单击Refine按钮 。
点击Max Energy Consumption系统需求的形状。表达了文本系统需求被Max Energy Consumption约束
块形式化的提炼关系被创建，如图2-76。

图2-76
 建模工具使您能够通过解析需求的文本自动创建约束块。在此之前，您必须更新项目选项。

更新项目选项，如图2-77，如下。

1) 从主菜单中，选择Options > Project。

2) 在Project Options对话框的搜索框中，键入glossary。

3) 单击将Use Requirement Terms Glossary选项设置为true。

4) 单击OK关闭对话框。

图
然后你会发现在Max Energy Consumption系统需求文本中，maximum一词被划了下划线。如果将鼠标悬停在该
文本上，就会看到不等式运算符，该运算符根据单词maximum自动解析，如图2-78。

图
x <= 3.518不等式存储在模型中，作为虚拟约束块的约束表达式，可以按需提取，因为这不是需求自动验证所必
需的，所以虚约束表达式就足够了。

从Max Energy Consumption系统需求中提取约束块，如下。

1) 右键单击需求并选择Tools > Extract Constraint Block From requirement。在模型中创建新
的约束块，并自动关联到Max Energy Consumption系统需求。
2) 将最大能耗约束块拖到需求图编辑区上。图中显示了约束块的形状以及从该约束块指向最大能耗
系统需求的细化关系。

接下来，定义totalEnergyConsVCCS值属性的值可用于确定是否满足Max Energy Consumption系统需求。为

此，您需要将Max Energy Consumption约束块的参数x绑定到totalEnergyConsVCCS 的值属性上。这过程可以在
Total Energy Consumption of VCCS参数图中完成。
将Max Energy Consumption约束块的参数x绑定到totalEnergyConsVCCS的值属性上，如下。

1) 打开Total Energy Consumption of VCCS参数图。

2) 将Max Energy Consumption约束块拖动到视图编辑区。
3) 在打开的对话框中，选择左边的约束参数x，并将其拖动到右边的值属性totalEnergyConsVCCS，如图2-
79。

图2-79

4) 单击OK。Total Energy Consumption of VCCS参数图被更新，添加了Max Energy Consumption约束属性，以

验证系统的Max Energy Consumption需求，如图2-80。

图2-80
 如果项目中的Use Requirement Terms Glossary选项被设置为true，则不需要更新Total Energy Consumption of
VCCS参数图。只要建立一个从totalEnergyConsVCCS值属性指向Max Energy Consumption系统需求的满足关系
就足够了，如图2-81。

创建一个从totalEnergyConsVCCS值属性到Max Energy Consumption系统需求的满足关系，如下。

1) 在System Requirements Formalized需求图上显示VCCS块:

按Ctrl + Alt + F， Quick Find对话框打开。

输入vccs。

当您在搜索结果列表中看到选中的VCCS块时，按回车键。在模型浏览器中该块被选中。

将该块拖动到视图编辑区中。

2) 选择totalEnergyConsVCCS值属性(不是整个块!)

3) 在值属性的智能操作工具栏上，点击满足按钮 。

4) 点击Max Energy Consumption系统需求。

图
现在，如果您将鼠标悬停在Max Energy Consumption系统需求上的带下划线的单词maximum上，您将看到满足
该系统需求的完整条件，如图2-82。

图
 如果您返回到Total Energy Consumption of VCCS视图并再次执行该模型，您应该注意到
totalEnergyConsVCCS值属性现在以绿色高亮显示，表明满足了Max Energy Consumption系统需求。尝试更改输
入值并观察当无法满足需求时，颜色会如何改变。这就是您执行自动化需求验证的方式。此外，通过这种方
式，您可以执行手动或自动(需要定义算法)参数优化，以找到最优的系统配置，如图2-83。

图2-83

步骤7： 在模型中存储值

您在Simulation面板的Variables选项卡中定义的系统或子系统参数值，以及您计算出的MoE值，都可以存储
在您的模型中。SysML实例规格及其槽(slot)值可以用于此目的。一旦您有了想要保留的输入和输出的组合值，
就可以将它们保存为相关系统架构块(此处是指VCCS及其子系统的块)实例的槽值。请记住，每次保存这些块的
实例规格时，都是在运行时捕获系统的快照。您可以在不同的时间点拍摄任意多的快照。

为了保持模型的良好组织，建议将实例规格及其插槽存储在单独的包中。它们可以在一种特殊类型的表中
显示，即实例表。它为检查槽值和重新计算它们提供了一个方便的版面布局。此外，可以在这里创建具有相应
槽的新实例。
创建VCCS块的实例，如下。

1) 在Simulation面板的Variables选项卡中，选择根元素，即VCCS块，如图2-84。

图2-84

2) 在顶部的工具栏中单击Export to New Instance按钮 。

3) 在Select Owner对话框中，选择4 System Parameters包(可能需要先展开2 Solution Domain包)。
4) 单击对话框底部的Create Owner按钮，然后选择Package。

如果您没有看到Create Owner按钮，请切换到Creation Mode按钮。就可以在对话框中看到Create

Owner按钮。
5) 在新包的规格Specification中，键入1 Parameter Values作为它的名称。
6) 单击该包的属性窗口的Close按钮以关闭窗口。
7) 在Select Owner对话框中单击OK。VCCS块的实例被创建，该实例的槽属性包含相关值属性的具体值，如
图2-85。

图2-85
 正如您在上图2-85中所看到的，模型浏览器并不是检查实例的最佳位置，特别是当您有多个实例时。在这
种情况下，应该使用实例表。

在实例表中显示VCCS块的实例，如下。

1) 创建实例表：
在模型浏览器中，右键单击1 Parameter Values包并选择Create Diagram。
在搜索框中，键入ins。当您看到在搜索结果中选择的实例表时，请按回车键，实例表被创建。
键入Total Energy Consumption Values指定新建实例表的名称，按回车键。

2) 在模型浏览器中，在同一个包下，选择根实例，也就是VCCS块的实例vccs，如图2-86。

图2-86

3) 将选中的实例拖到右侧的实例表中。

表中显示了VCCS块的实例。
VCCS块作为所选实例类型，自动设置为实例表的类目（classifier）。然后，您可以在实例表上方的
Criteria区域中看到它。

4) 隐藏除Name以外的所有列：

右键单击任何列。
选择hide。
重复步骤a和b以隐藏其他不需要的列。
5) 显示相关槽位值的列：
在实例表上方的工具栏上，单击Columns按钮并选择select Columns。
在打开的对话框中，点击选择：
a) 所有energyCons值属性(您可能需要事先展开对应的部件属性)，这些是输入值的槽。
b) totalEnergyConsVCCS值属性，这是输出值的槽，如图2-87。

图2-87

单击OK关闭对话框。
完成之后，模型中的实例表应该与下图2-88中相同。

图2-88

现在，您可以创建新的行来显示不同输入和输出值的其他实例。

在实例表中创建VCCS块的新实例规格，如下。

1) 在实例表上方的工具栏上，单击Create (Insert)按钮 然后选择Create with Parts(参见下图2-89)。该步是

因为您还需要创建属于VCCS块的部件而不是直接属于该块的值属性槽。一行所有槽值为0的新实例创建
完成。

图2-89
 2) 在新创建的行中，指定输入值。
3) 完成之后，在实例表上方的工具栏上，单击Run按钮 并选择Evaluate Selected Rows。然后结果被计算
出来，如图2-90。

注意，违反Max Energy Consumption系统需求的输出值被高亮显示。如果您没有在模型中看到

高亮显示，请确保在您的模型中使用了SimulationProfile.mdzip。有关如何在项目中使用另一个项
目或概要文件的更多信息，请参阅建模工具的文档。

图2-90

实例表的内容可以导出到MS Excel电子表格，以便用于内部或外部共享。

2.1.4.5 完成系统参数，下一步做什么?

本单元构建目标系统的LSA逻辑系统架构模型的任务就基本完成了。剩下要做的就是建立从LSA模型到系
统需求规格的可跟踪关系(参见2.1.5追溯到系统需求章节)。
2.1.5 追溯到系统需求

2.1.5.1 它是什么?

为了拥有一个完整的LSA逻辑系统架构模型，您需要建立从捕获目标系统中LSA的元素到捕获系统需求的元
素之间的跟踪关系。正如SysML所定义那样，这属于是满足关系，这意味着来自LSA模型的元素满足一个或多
个系统需求。例如，可以从捕获某个逻辑子系统的块所类型化的部件属性到某个系统需求建立一个满足关系。
在完整的LSA模型中，所有的系统需求都被逻辑系统架构的一个或多个元素所满足。

2.1.5.2 谁负责?

LSA逻辑系统架构模型中的可追溯关系可以由系统架构师或系统工程师建立。他/她必须是整个系统工程项
目的负责人，对目标系统有一个“完整视图”，并负责将子系统及其组件平滑地集成到整个系统中。

2.1.5.3 如何建模?

这SysML视图都不适合创建大量的交叉关系，比如满足关系。这时矩阵描述交叉关系显得更合适。建模工
具为指定交叉关系提供了很多预定义矩阵。为了获取满足关系，可以使用Satisfy Requirement Matrix，如图2-91。

图2-91

2.1.5.4 教程

步骤1： 创建一个矩阵来捕获满足关系

在本步骤中，我们会创建一个Satisfy Requirement Matrix并定义其准则。系统需求可以在矩阵的行中显示，

捕获到的目标系统的 逻辑系统架构元素可以在列中显示。

创建一个Satisfy Requirement Matrix，如下。

1) 在模型浏览器中，右键单击5 Traceability包(您在系统需求章节中创建的)并选择Create Diagram。

2) 在搜索框中键入srm(预定义的满足需求矩阵的首字母缩写)，然后按回车键。

如果你没有看到任何搜索结果，点击搜索结果列表下面的Expert按钮。可用视图的列表将在
模式中展开。
3) 键入LSA to System Requirements以指定为新矩阵的名称，按回车键。

4) 在矩阵工具栏上，单击Change Axes按钮以交换矩阵的行和列。此时需求变成矩阵行类型。

5) 选择需求SR-1 SRS for VCCS (您可能需要首先展开1 System Requirements包)，并将其拖到矩阵内容上方的

Criteria区域的Row Scope框中。将需求SR-1 SRS for VCCS用于矩阵行的范围。

6) 选择列元素类型：

在模型浏览器中，选择任意部件属性、代理端口和值属性。

若要选择模型树中非相邻项的集合，请单击第一个项，按 ，同时依次选择其他项。

将所选内容拖到矩阵内容上方的Criteria区域的Column Type框上。将矩阵的列设置为在所选范围（见
下一步）内显示所有部件属性、代理端口和值属性。

7) 选择列元素范围：

在模型浏览器中，选择VCCS块(您可能需要事先展开1 System Structure包)。

将所选块拖到矩阵内容上方的Criteria区域的Column Scope框上。选定的块成为矩阵列的范围(见下图
2-92)。

图2-92
 一旦您完成了这些条件的设置，矩阵的内容就会被更新。如果你已经在系统参数单元格教程的步骤6中创建
了满足关系，那么除了totalEnergyConsVCCS值属性和SR-1.9Max Energy Consumption相交的那个单元格之外，
其他所有单元格暂时都是空的，如图2-93。

图2-93

步骤2： 捕获满足的关系

现在您已经准备好定义其他满足的关系了。在矩阵中，这很容易做到。

指定一个从p1： UserDataInput代理端口到SR-1.1Setting Desired Temperature需求的满足关系，如下。

 双击代理端口的列和需求的行交汇处的单元格。对应项之间满足关系被创建如下图2-94所示。

图2-94
 假设我们正在矩阵内填元素间关系。如果需要提示哪些元素可以关联，请参考下图2-95。

图2-95

2.1.5.5 逻辑架构已完成，下一步做什么?

一旦你完成了LSA逻辑系统架构，你会得到以下内容：

 逻辑子系统
 逻辑接口
 交换信息
有了这些信息，就可以定义每个逻辑子系统的解决方案架构了。
2.2 构建子系统的逻辑架构
一旦系统架构师确定了目标系统的逻辑子系统，他/她就可以将它们分发给独立的工程团队，开始进行逻辑
子系统架构(LSSA)设计。因此，创建解决方案域模型的这一阶段致力于构建目标系统的所有逻辑子系统的架
构。在这个阶段，您应该想象自己是在VCCS的单个逻辑子系统的LSSA上工作的工程团队的一员。

如前所述，每个逻辑子系统的LSSA应该存储在单独的模型中，与问题域定义和逻辑系统架构模型分离开。
下图2-96中红色虚线框高亮显示区显示了我们即将讨论的解决方案域的子系统部分。如您所见，这些模型可以
并行开发。

图2-96

一个完整的LSSA逻辑子系统架构模型模型由子系统需求、结构、行为和参数的规格组成。此外，您在这个
模型中创建的每个SysML元素必须满足至少一个子系统需求；否则，就没有在LSSA模型中创建它的依据。因
此，逻辑子系统架构模型起点和结束点都是子系统需求：首先指定子系统需求，当您的模型完成侯，建立子系
统需求和SysML元素之间建立可追溯关系，如图2-97。

图2-97

在构建解决方案域模型的这个阶段中的逻辑子系统可以被称为目标子系统。同时，从指定设计子系统的各
个工程团队的视角来看，它又被称为目标系统。

请注意，以下材料主要关注于构建单个目标子系统的逻辑架构。以下是VCCS的制冷系统设计过程。另外
您应该记住，当您为制冷系统构建逻辑架构时，其他工程师/工程团队将并行地构建CP系统、制热系统和HMI系
统的逻辑架构。

2.2.1 子系统需求

2.2.1.1 它是什么?

为了提供逻辑子系统的解决方案架构，负责的工程团队需要分析相关子系统需求规格，该规格是在创建完
整的逻辑系统架构模型时产生的。来自规格中每个子系统需求，应该指向特定的系统需求或来自逻辑系统架构
模型的元素(例如，值属性或代表相关逻辑子系统的块的代理端口)。这证明了子系统需求的必要性(就像系统需
求指向涉众要求或问题域模型元素那样)。

完成LSSA之后，应该建立从LSSA元素到子系统需求的满足关系，以确定哪些LSSA元素满足哪些子系统需
求。这在追溯到子系统需求一章中进行了描述。

2.2.1.2 谁负责?

子系统需求规格可以由构建了LSA逻辑系统架构模型的系统架构师或系统工程师生成。
2.2.1.3 如何建模?

在建模工具中，可以将单个子系统需求捕获为SysML需求。就像系统需求一样，子系统的需求必须有唯一
的标识、名称和文本规格，这些规格必须是正式的，并通过遵循特定的指导方针来编写(这些指导方针的示例在
系统需求章节中提供)。

与系统需求一样，子系统需求可以被分类并组织为多层需求结构。可以使用SysML需求图或表格来捕获和
显示它们2-98。

图2-98

矩阵和关系图可以用来建立和审查子系统需求和系统需求或LSA模型元素之间的交叉关系，如图2-99。
 图2-99

图2-100

2.2.1.4 教程

步骤1： 创建和组织子系统需求模型

要开始定义子系统需求，您需要建立对应的模型结构。按照MagicGrid框架的布局，捕获子系统需求的模型构
件应该存储在包的结构下，如下图所示。上层的包代表域，下层的包代表单元，如图2-101。

图2-101

然而，这并不是我们要创建的内容。在真实的项目中，2.1 Cooling System Solution Domain包及其子包(以

及所有随后添加的包)将出现在与LSA模型分离的另一个模型中。这是必要的，因为指定建立LSSA模型的工程
组只能读取逻辑系统架构模型，而不能对LSA模型做任何修改。
 因此，在组织用于构建制冷系统的逻辑子系统架构的包之前，您需要创建一个新的模型使用逻辑系统架构
模型，建模工具提供重用功能。需要注意的是，对于逻辑系统架构LSA中标识的每个逻辑子系统，都要建立一
个逻辑子系统架构LSSA模型。

为制冷系统的LSSA创建一个新模型，并组织它来捕获子系统需求规格，如下。

1) 开始共享LSA模型。一旦您共享了它，在LSA模型中使用的问题域分析模型也将被共享。

有关此主题以及步骤 和步骤 中提到的主题相关的更多信息，请参阅建模工具的最新文档。

2) 创建一个新模型。这是制冷系统的解决方案架构模型，因此它可以命名为Cooling System Solution.mdzip。

3) 在制冷系统的LSSA模型中，将LSA模型设置为只读,问题域分析模型也被自动使用，如图2-102。

图2-102

灰色的名称表示不能修改的元素，因为问题域模型在解决域模型中是只读的。

4) 右键单击Model包(这是根包的默认名称)并选择Create Element。
5) 在搜索框中，键入元素类型Package的前两个字母pa，然后按回车键。
6) 键入2.1 Cooling System Solution Domain，作为新建包的名称，按回车键。

用于存储其他逻辑子系统 例如CP System和Heating System等 的解决方案架构会包含在 ，

包中。

7) 右键单击2.1 Cooling System Solution Domain，选择Create Element。

8) 在搜索框中，键入元素类型Package的前两个字母pa，然后按回车键。
9) 键入1 Subsystem Requirements命名新建包的名称，按回车键，如图2-103。
 图2-103

步骤2： 创建子系统需求图

为了捕获和显示子系统需求，我们建议使用SysML需求图或需求表。这次创建一个需求图。

创建SysML需求图以定义子系统需求，如下。

1) 右键单击1 subsystem Requirements包并选择Create Diagram。

2) 在搜索框中键入rd，其中r代表需求，d代表视图，然后双击回车，需求图被创建，如图2-104。

注意，图表是以存储它的包命名的。这个名称也适用该需求图，您只需从其名称中删除序列
号。

图2-104

步骤 ： 定义子系统的需求

假设负责Cooling System(制冷系统)解决方案架构的工程团队从系统架构师那里收到了以下子系统需求，如
表2-2：

表2-2

＃ Name Text
The Cooling System shall be able to draw the air out of the cabin and blow back the
1 Air for Cooling
cooled air.
 The Cooling System shall be able to compress, condense, and evaporate the
2 Cooling Approach
refrigerant.
Cooling System The main working states of the Cooling System shall be Off and On. Being in the On
3.
Working States state, the Cooling System shall visit the Initializing, Idling, and Operating sub-states.
Max Energy
4 Consumption for The Cooling System shall consume maximum 1.2 kWh.

Cooling
5 Internal Communication
6 Initialization
7 Idling
The Cooling System shall get control signals from the Central Processing (CP) System
send back the response.
The Cooling System shall be initialized by the CP System. If the initialization
succeeds, the Cooling System shall transit to the Idling state and wait there for the
signal to start cooling.
The Cooling System shall go to the Idling state either after the successful
initialization or when the CP System requires it to stop cooling.

While working the Cooling System shall cool down the cabin air until the CP System
8 Operating
requires to stop.

由于您已经知道如何在需求图中捕获需求，我们假设您可以自己完成这项工作。或请参阅系统需求教程中
的步骤3来回顾。当您完成时，您的模型中的Subsystem Requirements需求图，参考图2-105.

图2-105

您还需要对子系统需求进行分组、编号和分类。这些主题在1.1.1教程的步骤4、步骤5和步骤6中进行了描
述，所以我们假设您已经掌握。如下图所示，子系统需求应该是：

 对分组需求SRS for Cooling System下的需求进行分组(如果您需要回顾如何在需求图上显示关系，请参

阅2.1.1系统需求教程步骤3 )

 使用SSR-前缀进行编号
 需求分类为接口、功能、非功能和物理需求，如图2-106
 图2-106

子系统需求可以组织为多层需求结构，如下图2-107所示。

图2-107
步骤4： 定义跟踪关系

如前所述，必须证明任意子系统需求的必要性。也就是说，可以创建子系统需求来派生系统需求或细化
LSA模型元素。在SysML模型中，deriveReqt关系用于描述派生关系，refine关系用于描述细化提炼关系。这两
种类型的关系都可以在SysML需求图或矩阵中定义。我们建议在更大的范围内使用矩阵，因为它提供了比视图
更紧凑的模型视角。

在这种情况下，我们建议借助使用建模工具中预定义矩阵：派生需求矩阵或提炼需求矩阵。不管您选择什么矩
阵，与其他情况不同的是，您都需要更新依赖项准则来设置矩阵准则。因此，如果它是Derive Requirement
Matrix，您需要将提炼关系refine设置为除了deriveReqt关系之外的依赖准则，如果它是refine Requirement Matrix
，您需要将deriveReqt关系设置为除了提炼关系refine之外的依赖准则。矩阵中的依赖项准则见下图2-108所示。

图2-108

下面步骤展示了如何创建派生需求矩阵，但是您可以自己创建提炼需求矩阵，看看哪个更适合您。

与其他模型一样，可跟踪性视图和关系应该存储在一个单独的包中。因为您已经知道如何创建包，所以我
们假设您可以自己完成这项工作。为了根据MagicGrid框架保持模型的良好组织，该包应该始终是2.1 Cooling
System Solution Domain包的最后一个子包。因此，它的名称必须以数字5开始(例如，5 Traceability)。

创建派生需求矩阵，如下。

1) 在模型浏览器中，右键单击5 Traceability包并选择Create Diagram。

2) 在搜索框中，键入drm，这是预定义派生需求矩阵的首字母缩写，然后按回车键。

如果你没有看到任何结果，点击搜索结果列表下面的Expert按钮。可用视图列表将在 模
式中展开。
3) 键入Subsystem Requirements to System Requirements and LSA以命名新的矩阵，按回车键。
4) 在模型浏览器中，选择SSR-1 SRS for Cooling System需求，并将其拖到矩阵内容上方的Criteria区域的Row
Scope框中。SSR-1 SRS for Cooling System需求将成为矩阵行的范围。
5) 选择列元素类型：
在模型浏览器中，按住Ctrl键，选择任意部件属性、代理端口和值属性。
将选中项拖到矩阵内容上方的Criteria区域的Column Type框上。矩阵的列被设置为显示所选范围内
（见下一步操作）除了默认需求外的所有部件属性、代理端口和值属性。
6) 选择列元素范围：
在模型浏览器中，选择需求SSR-1 SRS for VCCS (为此，您可能需要事先展开以下包： 2 Solution
Domain 和 1 System Requirements)。
 按下Ctrl键，同时选择Cooling System块(为此您可能需要首先展开1 System Structure包)。
将选择拖到矩阵内容上方的Criteria区域的Column Scope框上。SR-1 SRS for VCCS和Cooling System块
成为矩阵中列的范围。
7) 将细化关系设置为依赖关系：
单击Dependency Criteria框旁边的按钮。
在打开的对话框的左侧，选择Simple Navigation。
在对话框底部的搜索框中，键入refine。
选择Refine [Abstraction] (SysML)并单击将Is Applied复选框的值设置为true，如图2-109。

图2-109

也可以改变细化关系的表现格式，使其不同于矩阵中的 关系 见下图 。
有关更多信息，请参考建模工具的文档，如图 。

图
单击OK关闭对话框。与deriveReqt关系一起，细化关系被设置为矩阵的依赖标准。
8) 单击Direction框并选择Row to Column，可以创建从子系统需求(即行元素)指向逻辑系统架构元素和系统
需求(即列元素)的关系。
9) 单击Criteria 区域下方提示框中的Refresh超链接。更新了矩阵的内容。目前所有的单元格都是空的。
下图2-111显示了矩阵的Criterial区域，在步骤4、5、6、7和8上突出显示。

图2-111

现在您已经准备好建立派生和细化关系了。让我们创建SSR-1.1.1 Air for Cooling和 SR-1.4 Cabin Air之间的

派生关系。表明SSR-1.1.1 Air for Cooling子系统需求是因为SR-1.4 Cabin Air系统需求而被创建的。
定义矩阵中的派生关系，如下。

1) 双击 SSR-1.1.1 Air for Cooling行和 SR-1.4 Cabin Air列之间交叉处的单元格，如图2-113。

如果您想在设置关系之前阅读需求文本，只需将鼠标悬停在需求名称上。文本将出现在工具提
示中，如 图。

图2-113
2) 选择DeriveReqt以创建派生关系。系统自动在两项之间创建派生关系并显示在单元格中。

在建立了所有的派生关系之后，你的模型中的Subsystem Requirements to System Requirements and LSA矩阵

参考下图2-114所示。

图2-114

如您所见，SSR-1.2.1Internal Communication子系统需求没有派生到任何系统需求。这是因为SSR-
1.2.1Internal Communication子系统需求是创建用来细化Cooling System模块的p3和p4代理端口。让我们在矩阵中
指定适当的关系。

在矩阵中指定细化关系，如下。

 双击显示p3或p4代理端口的列和显示SSR-1.2.1Internal Communication子系统需求的行相交的单元格。在两
项之间创建细化关系并显示在单元格中，如图2-115。

图2-115

尽管派生自系统需求，SSR-1.1.1 Air for Cooling子系统需求也细化了LSA逻辑系统架构模型中Cooling

System块的p1和p2代理端口。我们假设，你自己建立了对应追溯关系，如图2-116。

图2-116
然后，可以创建需求派生图，其中蓝色箭头表示来自不同领域的需求之间的派生关系，绿色箭头表示包含
关系，如图2-117。
 图2-117

2.2.1.5 完成子系统的需求，下一步做什么?

当您有了目标系统的特定逻辑子系统需求时，您可以构建该子系统的逻辑解决方案架构。首先定义子系统
结构，这意味着您可以接下来将进入到子系统结构单元。

2.2.2 子系统结构

2.2.2.1 它是什么?

您可以通过定义子系统的内部结构并定义其组件如何一起操作，以及它们如何与相同目标系统的其他子系
统交互来开始构建子系统的解决方案架构。

您可能还记得，与其他子系统交互的接口是由系统架构师在LSA逻辑系统架构模型中定义的。这些是被指
派来构建单个子系统的解决方案架构的工程团队必须遵循的约束。这确保了整个目标系统的模型完整性。

如果需要更改(例如，需要一个额外的接口，或者已经存在的接口被认为不需要)，工程团队需要向系统架
构师申请。如果该请求被接受，则必须将变更通知其他工程团队，以确保系统级的完整性。

2.2.2.2 谁负责?

逻辑子系统的结构定义可以由系统架构师或系统工程师捕获，他们属于负责构建该逻辑子系统的解决方案
架构的工程团队。

2.2.2.3 如何建模?

在建模工具中，子系统的组件可以使用SysML块定义图(bdd)来定义。组件本身可以被捕获为块，接口可以
被捕获为由对应的接口块类型化的代理端口，如图2-118。
 图2-118

为了定义子系统的各个部分如何在子系统内部一起运行，和外部如何交互，以及它们交换了什么材料，可
以使用SysML内部块图。下图2-119以SysML内部块图的形式展示了制冷系统的内部结构和各部件之间的相互作
用。

图2-119

2.2.2.4 教程

步骤1： 组织子系统结构模型

VCCS制冷系统的LSSA可以在子系统需求章节中创建的模型中捕获。要开始对子系统结构建模，您需要预先
建立对应的模型结构。按照MagicGrid框架的设计，相关的模型工件应该存储在包的结构下，如下图2-120所示。
 图2-120

组织子系统结构模型，如下。

1) 打开您在子系统需求章节教程的第1步中创建的制冷系统(Cooling System Solution.mdzip)的解决方案域模

型。
2) 右键单击2.1Cooling System Solution Domain包，选择Create Element。
3) 在搜索框中，键入元素类型Package的前两个字母pa，然后按回车键。
4) 键入2 Subsystem Structure命名新新包的名称并按回车键。
要保持3 System structure包的内部结构良好组织，您需要创建更多的包。分别是：

 1 Logical Interfaces

 2 Exchange Items

 3 Logical Components

当您按照前面的步骤创建以上包元素后，制冷系统的解决方案域模型下的模型浏览器如下图2-121。

图2-121

步骤2： 准备捕获子系统结构

请记住，在定义逻辑子系统的过程中工程团队必须考虑该子系统的所有接口，这是由LSA逻辑系统架构模
型中的系统架构师决定的。因此，这些接口必须存在于逻辑子系统的解决方案域模型中。

虽然子系统的工程团队可以读取逻辑系统架构模型，但是他们不能做任何更改。对子系统结构建模前，他
们应该做的第一件事是创建一个捕获目标系统的特定子系统的块 (在这里是制冷系统块)，并使它能够从逻辑系
统架构模型继承所有相关接口。
 继承可以通过在表示制冷系统的两个块之间建立泛化关系来实现：一个在LSA模型中(超类型)，另一个在
制冷系统的LSSA模型中(子类型)。因此，子类型块从超类型块继承所有规格(包括由类型为对应接口的代理端
口)。这里需要注意的是，继承的代理端口应该重定义；否则，无法完成LSSA的某些建模工作；例如，从代理
端口到相关子系统需求的满足关系。

泛化关系可以在块定义图bdd里创建，创建在制冷系统的解决方案域模型(在本单元教程的第1步中创建)中
的2 Subsystem Structure包下。

捕获制冷系统的结构，如下。

1) 创建块定义图bdd：
右键单击2 Subsystem Structure包并选择Create Diagram。
在搜索框中，键入bdd (SysML块定义图的首字母缩写)，然后按回车键，块定义图被创建。
键入Cooling System Structure以命名新视图的名称，并再次按回车键。

2) 创建目标子系统的块：

单击视图面板上的Block按钮，然后单击视图编辑区。
键入Cooling System Architecture以命名为新建块的名称并按回车键。

3) 在图中显示LSA模型中的Cooling System块：

在模型浏览器中选择Cooling System块(您可能需要随后还需要展开2 Solution Domain, 2 System

Structure 和 3 Logical Subsystems包)。
 将中的块拖动到视图编辑区。Cooling System块的符号显示在块定义图上，如图2-122。

图2-122

4) 在Cooling System块(超类型)和Cooling System Architecture块(子类型)之间画一个泛化关系：

选择Cooling System Architecture块的符号。
在所选块的智能操作工具栏上单击泛化按钮 。
选择Cooling System块的符号，如图2-123。

图2-123

5) 重定义已继承的代理端口：
双击图上Cooling System Architecture块。
在打开的对话框的左侧，单击Ports/Interfaces。
 在第一行中选择代理端口并单击下面的Redefine按钮，如图2-124。

图2-124

所选的代理端口被重定义，并且从那时起不再使用指示继承的插入符号(" ^ ")来标识，如图2-125。

图2-125
逐行重定义其余部分(项顺序可能与下面的图中看到的不同) ，如图2-126。

图2-126
单击Close。

6) 在Cooling System Architecture块的符号上显示代理端口和接口：

在视图编辑区中选择Cooling System Architecture块。

 在块的智能操作工具栏上单击“显示所有端口”按钮 ，如图2-127。

图2-127

如下图2-128显示代理端口和接口。

图2-128

步骤3： 捕获制冷系统的部件

根据子系统需求定义，制冷系统应包括：

 Compressor
 Condenser
 Evaporator
根据经验，工程团队识别出更多的组件：

 Receiver Dryer
 Metering Device
尽管我们使用Cooling System Structure块定义图(在本单元教程的第2步中创建的)，但所有这些元素都可以使
用bdd或ibd来捕获。稍后，当您需要指定组件之间的交互关系时，ibd就非常有用。
捕获制冷系统的组件，如下。

1) 打开Cooling System Structure块定义图，如果还没有创建，请按照本单元教程的步骤2加以创建。

2) 选择Cooling System Architecture块，在其智能操作工具栏上(见下图)单击组合按钮 ，然后单击视图编辑
区上的空白处，如图2-129。

图2-129

在模型浏览器中另一个块被创建，并其符号在视图编辑区被选中。
3) 直接在选中的块上输入Compressor类型，指定其为相应的制冷系统组件，并按回车键，如图2-130。

图2-130
4) 重复步骤2和步骤3，依次创建Condenser, Evaporator, Receiver Dryer和 Metering Device 块，如图2-131。

图2-131

5) 在模型浏览器中，选择所有组件块并将它们拖动到在本单元格教程的第1步中创建的包3 Logical
Components中，如图2-132。
 图2-132

步骤4： 创建用于定义内部交互的内部块图

请记住，块定义图最适合捕获组件，而内部块图在您需要定义这些组件之间的交互时很有帮助。这就是为
什么我们需要为Cooling System Architecture块创建一个内部块图。要开始定义交互，您需要在该视图中指定制
冷系统的所有代理端口和组件。它们都是在Cooling System Structure块定义图中被捕获的。

创建一个内部快图来定义制冷系统的内部交互，如下。

1) 在Cooling System Structure 块定义图中，选择Cooling System Architecture块，然后在其智能操作工具栏上

(见下图2-133)单击SysML内部框图按钮 。于是ibd被创建，并打开了Display Parts/Ports对话框。
 图2-133
2) 在打开的对话框中，选择所有部件属性和前两个代理端口(见下图2-134)，然后单击OK按钮。

没有必要在同一个视图中捕获所有通信。所以我们将隐藏几个代理端口，因为它们与我们将要
在新创建的图中建模的内容无关。

图2-134

3) 在模型浏览器中，新创建的视图在编辑模式中被自动选中，键入Cooling System Logical Components作为

它的名称并再次按回车键，如图2-135。
 图2-135

4) 简化部件属性的名称，使其形状更紧凑(不要删除名称；你以后可能会用到它们)。
5) 重新排列视图上的形状，如下图2-136所示。

图2-136

步骤5： 定义与外部的交互

在这个步骤中，我们专注于定义制冷系统和外部组件之间的交互作用；也就是VCCS的其他子系统甚至是
整个车辆的其他系统。正如您已经知道的，交互可以定义为通过兼容的代理端口建立的连接器。在这些相互作
用中交换的信息、物质或能量可以定义为流过相关连接器的项。

我们可以从指定继承到的接口(已在LSA中识别出来)交互开始。在该视图中有两个：一个是让空气流入制
冷系统，另一个是送出冷气。我们定义了压缩机消耗来自舱内的空气，而蒸发器(它的风扇)将冷空气送回驾驶
舱内。

定义压缩机在驾驶室内消耗空气，如下。

1) 在视图框选择p1代理端口(类型为insideAirInlet接口块)，然后在它的智能操作工具栏上单击Connector按钮
。
2) 点击cmp部件属性 (类型为Compressor块)。
3) 选择New Proxy Port。为Compressor块创建一个代理端口，并在视图框和所选部件属性之间创建连接器，
如图2-137。
 图2-137

4) 在模型浏览器中，展开只读包2 Solution Domain > 2System Structure > 2 Exchange Items包。

重要的是，与外部通信的交换项只能从 逻辑系统架构模型中获取。否则，会破坏不同逻辑
子系统模型的一致性和完整性。

5) 选择Cabin Air块并将其拖动到已经打开了的视图边框内新创建的连接器上。

根据 ，想要指定为流经连接器的项的元素必须是连接代理端口类型的接口块所拥有的其
中一个流属性。

6) 不要在打开的对话框中做任何更改，单击OK。然后Cabin Air块被定义为流过新创建的连接器的项，如图
2-138。

图2-138
 同样，定义蒸发器将冷空气送回驾驶室(只需在最后一步中改变流方向)。完成后的内部块图参考下图2-
139。

图2-139

然而，我们还没有最后完成。让我们假设工程团队已经确定了另外两个接口，它们既没有在系统需求中提
到，也没有在子系统需求规格中提到：一个用于将热空气排出车辆，另一个用于将从制冷剂中分离出来的水分
从VCCS中移除。要在模型中捕获此信息，您需要创建两个新的接口块，并将它们作为代理端口分配给VCCS块。
因为它是系统级信息，所以只能在LSA模型中完成。因此，制冷系统的工程团队必须针对两个新的接口通知系
统架构师，并请求对逻辑系统架构模型进行相关更改。当接口变更完后，制冷系统的工程团队可以更新他们的
模型，让Cooling System Architecture块从逻辑系统架构模型中继承新添加的两个新的代理端口。这些变化也可
能影响其他工程团队的工作；在这种情况下，系统架构师必须承担通知他们的责任。

我们假设您暂时返回到逻辑系统架构模型LSA并自己捕获提到的接口(这个过程在系统结构章节中有介
绍)。完成之后，模型中的Logical Architecture of VCCS块定义图如下图2-140所示(更新部分已高亮显示)。需要
特别注意的是，子系统甚至系统需求必须被评审并进行相应的更新。我们将在追溯到子系统需求一章中再介
绍。
 图2-140

现在是更新制冷系统解决方案域模型中的Cooling System Logical Components 内部块图的时候了。首先，你

需要在视图中显示新创建的代理端口；其次，您需要定义之前提到的制冷系统组件和外部组件之间的交互。

在Cooling System Logical Components 内部快图框中显示新创建的代理端口，如下。

1) 确保在制冷系统的解决方案域模型中更新解决方案域模型(文件)。

有关此主题的更多信息，请参阅建模工具的最新文档。
2) 打开Cooling System Logical Components图。

3) 选择视图框并在其智能操作工具栏上单击Display All Ports按钮 (见下图)。Cooling System模块的所有代

理端口被显示在视图边框上，如图2-141。
 图2-141
4) 此时您暂时还不需要类型是InternalControl和InternalResponse接口块的任何元素。然后逐个选择它们，按
Delete键将它们从视图中删除(别担心；它们仍然在模型中)。

正如前面提到的，没有必要在同一个视图中捕获所有交互。因此，我们将忽略显示几个代理
端口，因为它们与我们将要在新创建的图中建模的内容无关，如图 。

图2-142

当完成捕捉冷凝器将多余的热空气从制冷系统中排放出来以及车辆干燥器将水分回收这两项工作后，内部
块图如下图2-143所示。

图2-143

现在，如果您打开在本单元教程的第3步中创建的Cooling System Structure 块定义图，就可以更新它，以便

在制冷系统及其对应组件的块上显示新的代理端口，如图2-144。
 图2-144

步骤6： 定义制冷系统内的交互作用

在这一步中，我们将继续定义制冷系统不同组件之间的交互作用。与前面的步骤一样，可以将交互定义为
通过兼容的代理端口建立的连接器。在这些相互作用中交换的信息、物质或能量可以定义为流过相关连接器的
项。

假设工程团队确定了以下交互作用：

1) 压缩机以低压、低温气体的形式消耗制冷剂，并将制冷剂转化为高压、高温气体。
2) 在冷凝器内部，制冷剂变成液体。
3) 接收器干燥机从制冷剂分离水分，但不改变其物理特性。
4) 计量装置使制冷剂变成低压、低温液体。
5) 蒸发器将制冷剂转化为气体提供给压缩机回路。
上面的步骤产生了制冷系统的另一个接口。即用于交换制冷剂的接口，它可作为新的接口块在模型中加以
捕获。工程团队不需要将新识别出来的接口告知其他人；它仅用于内部通信，可以在制冷系统的解决方案域模
型中捕获。

捕获交换制冷剂的接口块，如下。

1) 打开Cooling System Structure视图。

2) 单击视图面板上的Interface Block按钮，然后单击视图编辑区上的空白位置。然后在模型浏览器中 2
Subsystem Structure包下一个未命名的接口块被创建，并显示在视图上。
3) 键入RefrigerantExchange以命名接口块并按回车键。
4) 点击接口块右上角的Create Elem ent按钮 ，然后选择Flow Property，如图2-145。

图2-145

5) 直接在接口块的符号上做以下操作：
保留inout，即流属性的默认方向。
输入r以定义流属性名称，此时不要按回车键!
输入: Refrigerant，按回车键。Refrigerant信号将在制冷剂交换接口模块下直接被创建，并随即被设置
为唯一流属性类型，如图2-146。

图2-146
6) 在模型浏览器中选择RefrigerantExchange接口块：
在视图上选中此接口块
按Alt + B。
7) 将选中的接口快拖动到最近的1 Logical Interfaces包，将RefrigerantExchange接口存储到这个包中。
8) 展开接口块内容，选择Refrigerant信号。
9) 将信号拖动到最近的2 Exchange Items包，然后Refrigerant信号将储放到这个包中，如图2-147。
 图2-147

如您所见，制冷剂在模型中被自动捕获为信号，这是不正确的，因为制冷剂应该被定义为一个块。通过将
制冷剂信号重构为一个块，可以很容易地解决这个问题。接下来需要定义制冷剂在不同物理条件下的相互作
用。每种工况都可以捕获为制冷剂块的子类型。以在块定义图中创建子类。

捕获制冷剂的各种物理条件，如下。

1) 创建一个bdd：
右键单击2 Exchange Items包并选择Create Diagram。
在搜索框中，键入bdd (SysML块定义图的缩写)，然后按回车键，块定义图被创建。
键入Refrigerant Conditions 以命名视图的名称，再次按回车键。
2) 将Refrigerant信号拖动到视图编辑区，制冷剂信号符号出现在视图中。
3) 将Refrigerant Conditions重构为块：
右键单击并选择Refactor > Convert To > Block.。
单击OK以删除这两种类型之间不兼容的所有属性。
4) 选中Refrigerant块，在它的智能操作工具栏上单击泛化按钮 。
5) 单击视图编辑区上的空白位置。
6) 直接在新形状上键入LPLTG来命名块并按回车键，如图2-148。

LP为低压，LT为低温，G为气体。

图2-148

7) 按照步骤4到步骤6逐个创建HPHTG、HPHTL和LPLTL块，如图2-149。
 HP代表高压，HT代表高温，L代表液体。

图2-149

当您完成时，您可以定义制冷系统组件之间的交互(在此步骤的开始部分列出)。

定义压缩机以高压、高温气体的形式向冷凝器提供制冷剂，如下。

1) 请确保在Cooling System Logical Components视图中启用了类型选择模式。否则，代理端口的创建不会触

发接口块的选择来指定该代理端口类型。
2) 选择类型为Compressor块的部件属性的符号，然后在它的智能操作工具栏上单击代理端口按钮 。然后
一个新的代理端口出现在部件属性边框上。
3) 输入ref后在选择类型列表中找到 RefrigerantExchange接口块，按向下箭头键选择它，然后按回车键。

4) 在新创建的代理端口的智能操作工具栏上单击Connector按钮 。
5) 单击类型为Condenser块的部件属性。
6) 选择New Proxy Port。为该部件属性创建了一个兼容的代理端口，并建立这对部件属性之间的连接器，如
图2-150。

图2-150
7) 在模型浏览器中，展开2 Exchange Items包的内容(如果它还没有展开的话)，选择HPHTG块，并将它拖到
新创建的连接器。

根据 语言，想要定义为流经连接器的项的元素必须是连接代理端口的类型接口块所拥有的至
少其中一个流属性类型。这也适用于子类型。这就是为什么Refrigerant块以及它的任何类型 在本例中
指 块 ，可以分配给连接器的原因。

8) 不要在打开的对话框中做任何更改，直接单击OK。HPHTG块将被定义为在新创建的连接器上流动的项，
如图2-151。

图2-151

以同样的方式，定义前面描述的交互的其余部分。完成后的内部块图参考下图2-152。

连接器的颜色可以通过修改其符号属性来更改。为此，右键单击连接器并选择Symbol Properties。
在打开的对话框中，选择画笔颜色属性的值单元格，然后单击…按钮以打开Color对话框。选择蓝色
或其他任何你想要的颜色，然后关闭两个对话框。
 图2-152

现在，如果您回到本单元教程步骤3中创建的Cooling System Structure 块定义图，您可以使用新创建的代理

端口更新它，如图2-153。

图2-153

2.3.7.5 完成子系统结构，下一步做什么?

 有了逻辑组件并知道它们如何通信，您就可以继续结构建模并进入每个逻辑组件。
 但是，子系统的解决方案架构中仍然有两个未访问的单元。需要继续进入子系统行为和子系统参数章节。
2.2.3 子系统的行为

2.2.3.1 它是什么?

一旦完成了子系统的结构，工程团队就可以切换到该子系统的行为建模。行为模型可以是相对抽象的，并
且必须满足子系统的功能需求(参见2.2.1子系统需求章节)。建模工具提供功能，基于测试用例运行行为模型，
检查并显示这些功能需求是否得到满足。

当完成时，子系统行为应该与其他子系统行为集成到一个代表整个目标系统的综合行为的单一模型中。这
只有在集成的模型兼容的情况下才能实现；也就是说，是否它们可以通过接口和交换项进行通信。记住，在
LSA逻辑系统架构模型中，接口和交换项是由系统架构师决定的。

如果工程团队决定对逻辑子系统的结构模型中捕获的每个逻辑组件的行为进行建模，则可以跳过这个单元
(参见2.2.2子系统结构章节)。

请注意，以下材料主要侧重于建立VCCS制冷系统的行为模型。在本单元教程的最后几个步骤中，范围扩
展到包括CP系统的行为模型。这对于学习两个子系统之间的通信如何建模是必要的。但不包括制热系统、人机
接口系统等其他子系统的行为模型；然而，您应该想象定义的工程师/工程团队正在同时处理它们。

2.2.3.2 谁负责?

定义的逻辑子系统的行为可以由系统架构师或属于负责构建该逻辑子系统的解决方案架构的工程团队的系
统工程师捕获。

2.2.3.3 如何建模?

子系统的行为模型可以通过组合使用SysML状态机、活动或时序图来捕获。状态机允许捕获子系统的状态
以及它们之间的转换，以响应随时间发生的事件。活动或时序图应该用于定义这些状态或转换效果的进入、执
行和退出行为。

下图2-154显示了SysML状态机图，识别出制冷系统的主要状态。状态之间的转换可以由各种类型的事件触
发(例如：一个信号事件，在Off和On状态之间的Start)。这些信号取自逻辑系统架构模型。这确保了不同逻辑子
系统的行为模型的完整性。
 图2-154

状态可以有一个或多个内部行为，这些行为以模型中某处创建的SysML活动图的形式定义。如您所见，运
行状态将Cool Down Cabin Air活动定义为Entry行为。冷却客舱空气活动图如下图2-155所示。

图2-155

2.2.3.4 教程

步骤1： 组织子系统行为模型

制冷系统的状态可以在该子系统的解决方案域模型中捕获(您在子系统需求章节中创建的模型)。根据
SysML，状态只能存储在包含执行这些行为的块之下。在这种情况下，它是属于制冷系统架构块；因此，您不
需要创建任何额外的包来存储模型中的状态。它们应该直接出现在制冷系统架构块下，该块存储在2 System
Structure包中。

但是，如果需要定义Cooling System在处于一种或另一种状态或从一种状态转换到另一种状态时执行的某些
行为，则应该在单独的包中定义该行为。按照MagicGrid框架的设计，这个包应该存储在下图2-156所示的包结
构下。

图2-156

组织子系统行为的模型，如下。

1) 打开制冷系统(Cooling System Solution.mdzip)的解决方案域模型，该模型在子系统需求教程的第1步中创

建。
2) 右键单击2.1 Cooling System Solution Domain包，选择Create Diagram。
3) 在搜索框中，键入元素类型Package的前两个字母pa，然后按回车键。
4) 键入3 Subsystem Behavior以定义新包的名称并按回车键。

步骤2： 创建用于捕获制冷系统状态的视图

描述制冷系统状态的SysML状态机图应该直接在代表子系统的块下创建。

创建用于捕获制冷系统状态的SysML状态机图，如下。

1) 打开您在子系统需求教程的第1步中创建的制冷系统的解决方案域模型(如果还没有打开的话)。
2) 在模型浏览器中，选择制冷系统架构块。为此，请使用Quick Find功能：
a. 按Ctrl + Alt + F，Quick Find对话框打开。
b. 键入csd, c代表制冷，s代表系统，a代表架构。
c. 当您在下面的搜索结果列表中看到Cooling System Architecture块被选中时，按回车键。然后在模型
浏览器中Cooling System Architecture块被选中了。

3) 为Cooling System Architecture块创建SysML状态机：

右键单击“Cooling System Architecture”块，选择Create Diagram。
 在搜索框中，键入smd (SysML状态机图的首字母缩写)，然后按回车键。被创建的状态机图已带有初
始状态和未命名状态，可开始状态定义，如图2-157。

图2-157

键入Cooling System States以定义新视图的名称，并再次按回车键。

步骤3： 捕获制冷系统的状态

假设致力于制冷系统解决方案架构的工程团队已经确定了以下一组状态，在VCCS运行期间制冷系统可以
存在以下状态：

停机状态(Off)
工作状态(On)：
初始化状态(Initializing)
待机状态(Idling)
运行状态(Operating)

以下规则描述了这些状态之间的转换：

 子系统的第一个状态是Off。
 子系统可以从Off状态移动到On状态，然后再切换回来。
 当处于On状态时，子系统首先进入初始化Initializing状态。
 从初始化状态，子系统可以移动到idle状态或Off状态。
 从idle状态，子系统可以移动到Operating状态。
 子系统可以从操作状态移回操作状态或待机状态。
触发状态之间转换的事件发生将在本教程的后面讨论。当前步骤主要关注于创建状态和它们之间的转换。

定义制冷系统的状态，如下。

1) 打开制冷系统状态机图(如果尚未打开)。图中已经包含了初始状态和未命名状态。
2) 选中未命名状态，然后单击，切换到名称编辑模式。
3) 键入Off以定义名称并按回车键。
4) 选中Off并在它的智能操作工具栏上单击转换按钮 。
5) 单击视图编辑区上的空白位置，另一个状态被创建。
6) 直接在该状态上键入On并按回车键。
7) 拖动新创建状态一角放大它，这对于创建内部状态是必要的，如图2-158。

图2-158
8) 单击视图面板上的Initial按钮，并将鼠标移动到状态on上。
9) 当您看到On状态周围的蓝色边框时，请单击。在On状态中创建了一个初始状态，On状态自动变成复合状
态。
10) 选中初始状态并在它的智能操作工具栏上单击转换按钮 。
11) 右键单击复合状态中任意空白位置并选择State。创建该组合状态的另一个内部状态。
12) 在未命名的新建内部状态上直接键入Initializing并按回车键，如图2-159。

图2-159
13) 按照之前步骤，从上面的列表中创建其余的状态。完成之后，您的状态机图如图2-160所示。

图2-160

步骤4： 定义在转换时发生的事件
 正如SysML所定义的，状态之间的转换可以由各种类型的事件触发，如时间、更改、信号事件等。制冷系
统状态之间的转换仅由信号事件触发。例如，制冷系统在接收到Start信号后，从Off状态移动到On状态；当停
止信号Stop到达时，它移回Off状态。

需要注意的是，这些信号来自制冷系统之外。更准确地说，它们实际上来自CP系统。因此，工程团队不需
要在制冷系统的LSSA逻辑子系统架构模型中捕获它们。这些信号已经在LSA逻辑系统架构模型中捕获，因此必
须从那里去获取。在CP系统的LSSA上工作的工程团队也在他们的模型中使用了这些信号。唯一的区别是CP系
统将它们发送到外部。

让我们从在Off和on状态转换时定义触发器开始。

使Start信号成为制冷系统开关状态转换的触发器，如下。

1) 打开Cooling System States状态机图(如果尚未打开)。

2) 在模型浏览器中，展开以下只读包的内容：2 Solution Domain > 2System Structure > 2 Exchange Items，
如图2-161。

图2-161
3) 选择Start信号并将其拖动到Off和On状态之间的转换上，如图2-162。

图2-162

4) 当您松开鼠标时，Start信号将成为触发制冷系统 Off和On状态转换的信号事件，如图2-163。
 图2-163

查看下图2-164，定义Stop、Cool和Idle触发器。

图2-164

当您完成时，您可以运行仿真以验证定义的行为，并查看您的模型是否正确。要启动仿真会话，请单击

Cooling System States状态机图工具栏上Run按钮 。在仿真面板中，单击Start按钮 启动状态机执行。请注

意，状态机进入Off状态，并在那里等待Start信号触发它。

你可以从两个地方激活转换：

 在视图上，如图2-165。

图2-165
  在仿真面板上，如图2-166。
图2-166

尝试触发所有的转换，看看是否可以访问所有的状态。正如您可能看到的，一些转换仍然没有触发器。这
些将在以后定义，遵循子系统通信的特定逻辑。

现在是时候想象自己是负责CP系统的LSSA的工程团队，创建捕获逻辑子系统行为的状态机。这是建模两
个子系统之间的通信所必须的。就像制冷系统的LSSA一样，CP系统的LSSA也应该存储在一个单独的模型中。
我们假设您创建了模型，在其中使用了LSA模型，并自己建立了必要的包结构(请参阅子系统需求教程的第1
步，以刷新您的记忆)。然后，为逻辑子系统架构创建一个bdd块定义图，并创建一个块来捕获CP系统。然后使
它成为在LSA模型中代表CP系统的块的子类型(参见2.2.2子系统结构教程的步骤2)，最后重定义它所继承来的代
理端口。

图2-167

当您有下图2-167中所示的模型时，您可以指定CP系统的行为。注意点火开关信号Ignition On和 Ignition Off

是在CP系统的LSSA模型中捕获的，而DesiredTmpSet和Idle信号是取自LSA模型，如图2-168。
 图2-168

使点火开关信号成为CP系统开关状态转换的触发器，如下。

1) 选中从Off状态到On状态的转换。
2) 直接输入Ignition On并按回车键。在模型浏览器中Ignition On信号被创建，并将其作为信号事件自动分配
到从Off状态到No状态的转换。
3) 右键单击转换并选择Go To > Signal Ignition On (见下图2-169) 。然后在模型浏览器中该信号被选中。

图2-169
 4) 将信号拖动到最近的2 Exchange Items包中，如图2-170。

图2-170

按照上面的步骤创建Ignition Off信号。

正如您所看到的，operation状态到本身自转换是由另一种类型的事件触发的：相对时间事件。它允许建模
者定义CP系统每隔3秒返回操作状态。将有一个分配给该状态的内部行为，在每次进入操作状态时被执行。

使时间事件成为从Operating状态到本身自转换的触发器，如下。

1) 选中转换transition。
2) 直接输入after (3s)，按回车键，相对时间事件在自转换上被创建。
3) 确保自转换仍然被选中并按回车键。详情请参阅转换规格中的触发器信息，如图2-171。

图2-171

在处理完CP系统的状态之后，运行仿真，看看行为模型是否正确。

现在，您已经创建了两个状态机：一个用于制冷系统，另一个用于CP系统。此外，您已经定义了制冷系统
正在等待CP系统的信号。现在是时候捕捉CP系统何时以及如何发送这些信号了。

步骤5： 定义状态的内部行为

目标系统的每个逻辑子系统都可以执行与它的一个或多个状态相关的一个或多个行为。这些行为通常被称
为状态的内部行为。内部行为可以以SysML活动图的形式来捕获，并存储在相关的LSSA模型中，位于
3Subsystem Behavior包之下(参见本教程步骤1)。
 假设负责的工程团队必须定义当CP系统进入初始化状态时，它调用了VCCS的其他逻辑子系统。因此，它
应该向所有这些子系统发送Start信号。由于信号应该被发送到CP系统之外，因此定义通过p2代理端口传递该信
号非常重要，如下图2-172所示。

图2-172

定义CP系统在进入初始化状态时发出Start信号，如下。

1) 打开CP系统的LSSA模型(在上一步中创建的模型)。（如果还没有打开的话）
2) 创建一个新的SysML活动图：
在模型浏览器中，选择3 Subsystem Behavior包。
右键单击包并选择Create Diagram。
在搜索框中，键入ad (SysML活动图的首字母缩写)，然后按回车键，创建一个SysML活动图。并且它
包含在SysML 活动下。
输入Initializing Other Subsystems以定义新建活动图的名称，并再次按回车键。拥有该活动图的SysML
活动默认和视图同名，如图2-173。
图2-173
3) 单击视图面板上的Initial Node按钮，然后单击视图编辑区上的空白位置。初始节点被创建并显示在视图
中。
4) 在模型浏览器中，选择Start信号：
按ctrl + Alt + F。
键入Start。
当您在下面的搜索结果中看到Start信号时，请按回车键。
5) 将选中的信号拖到新创建的视图编辑区中。Start发送信号动作被创建并显示在视图编辑区中。
6) 在两个节点之间建立控制流：
选择初始节点并在它的智能操作工具栏上单击控制流按钮 。
单击Start发送信号动作，然后控制流被创建了，如图2-174。

图2-174

7) 选中Start发送信号动作并按回车键。
8) 在发送信号动作的规格中，找到On Port属性并选择它的值单元格。
9) 单击该单元格中带有三个圆点的按钮。
10) 在“Select Port”对话框中，选择LSSA模型中属于CP System Architecture块的p2代理端口，然后关闭对话
框，如图2-175。

图2-175
 然后，所选代理端口名显示在Start发送信号动作上，如图2-176。

图2-176

11) 打开CP System States状态机图。

12) 在模型浏览器中选择Initialize Other Subsystems活动，并将其拖到初始化状态中。

确保您选择的是 活动，而不是图表，如图 。

13) 选择Entry，如图2-178。

图2-178

然后，Initialize Other Subsystems活动被设置为Initialize状态的Entry行为，如图2-179。

 图2-179

负责制冷系统逻辑子系统架构的工程团队必须定义制冷子系统对Start信号的响应。假设Cooling System如果
已经准备好启动，其发送coolOK信号属性值为true，否则发送coolStatus信号属性值为false。如图2-180所示，响
应信号是通过p4代理端口发送的。其他VCCS车辆空气调节单元的逻辑子系统需要同样定义响应，但这里我们
不去建模他们的行为。通过两个子系统模型就足以了解如何建模子系统间通信。

图2-180
要定义制冷系统在初始化状态时执行自检并发出具有对应属性值的冷却状态信号，如下。

1) 如果还没有打开，请打开制冷系统的逻辑子系统架构模型(在子系统需求教程的第1步中创建的模型)。
2) 创建一个新的SysML活动图：
在模型浏览器中，选择3 Subsystem Behavior包。
右键单击包并选择Create Diagram。
在搜索框中，键入ad (SysML活动图的首字母缩写)，然后按回车键。一个SysML活动图就被创建了，
它包含在SysML活动下。
键入Perform System Check以定义新活动图的名称，并再次按回车键。拥有该活动图的SysML活动默认
和视图同名。
3) 单击视图面板上的Initial Node按钮，然后单击视图编辑区上的空白位置。初始节点被创建并显示在视图
内。
4) 创建决策节点：
在新创建的初始节点的智能操作工具栏上，单击控制流按钮 。
右键单击下方的空白处并选择Decision。
5) 创建一个opaque action，将coolOK属性值设置为true：
单击视图面板上Action按钮旁边的黑色小三角形，然后选择Opaque Action。
单击视图编辑区上的空白位置。一个新的opaque action被创建并显示在视图上。
直接输入coolOK = true；。
完成后单击视图编辑区上的任意处。
6) 在决策节点和新创建的opaque action之间创建一个控制流，并设置概率为80%：
在它的智能操作工具栏上，选择决策节点并单击控制流按钮 。
单击opaque action。创建动作之间的控制流。
确保控制流仍然被选中并按回车键。
在控制流规格中，找到Probability属性并在其值单元格中输入0.8，如图2-181。

图2-181
关闭对话框，概率值将显示在视图上，如图2-182。
 图2-182

7) 按照步骤5创建另一个opaque action。这次设置coolOK属性值为false(见下图2-183)。
8) 按照步骤6建立另一个控制流，设置概率为20% (参见下图2-182)。
9) 创建一个发送信号动作，发送coolStatus信号：
在模型浏览器中，选择coolStatus信号：
a) 按ctrl + Alt + F。
b) 输入cools。当您在下面的搜索结果中看到coolStatus信号时，选中并按回车键。
将选定的信号拖到打开的视图编辑区中。具有相同名称的发送信号动作将被创建并显示在视图编辑
区中。

图2-183
保持选中并按回车键。
在Specification窗口中，找到On Port属性并选择其值单元格。
单击该单元格中带有三个圆点的按钮。
在Select Port对话框中，选择属于Cooling System Architecture块的p4代理端口块，然后关闭对话框，
如图2-184。
 图2-184
然后，所选代理端口名称将显示在coolStatus发送信号动作上，如图2-185。

图2-185
10) 建立从每个opaque action到发送信号动作的对象流：
在视图编辑区中选择一个opaque action，然后在它的智能操作工具栏上，单击对象流按钮 。
点击发送信号动作的输入引脚。对象流被创建，一个新的输出引脚被附加到opaque action。
单击视图编辑区上的输出引脚名。然后再次单击它以进入名称编辑模式。
 键入coolOK以更改pin名称，如图2-186。

注意，在下图中，引脚Pin不显示它们的类型，只显示它们的名称。操作如下：
同时按下Shift键并选中两个引脚。
右键选中内容并单击以选择Show Name复选框。
不要勾选Show Type复选框。

图2-186

单击视图面板上的Merge按钮，然后单击新创建的对象流。合并节点被创建。
选择视图编辑区上的另一个opaque action，并在它的智能操作工具栏上，单击对象流按钮 。
单击合并节点。到合并节点的另一个对象流被创建，并将一个新的输出引脚附加到opaque action上。
单击视图编辑区上的输出引脚名。然后再次单击它以进入名称编辑模式。

图2-187
键入coolOK以更改引脚名称，如图2-187。
11) 打开Cooling System States状态机图。
 12) 在模型浏览器中选择Perform System Check活动(确保您选择的是SysML活动，而不是视图)并将其拖到
initialize状态，如图2-188。

图2-188
13) 选择Entry，然后，执行系统检查活动被设置为Initializing状态的entry行为。
当您处理完这个状态机图后，尝试再次运行仿真。在开始模型执行之前，确保启用了Auto Open Diagrams
模式(参见下图2-189)。在此模式下，工具将自动打开当前正在执行的视图。因此，当模型执行从Cooling System
States状态图切换到Perform System Check活动图(定义为初始化状态的entry行为)，Perform System Check活动图
将自动打开。

图2-189

负责的工程团队还必须定义CP系统在收到其他子系统的响应后的行为。它应该根据该信息评估所有子系统
的状态，并向它们发送信号，触发它们转移到待机或关闭状态。如图2-190所示，对应的信号通过p2代理端口发
出。
 图2-190

请注意，SysOK和SysNotOK信号没有定义在任何模型中，尽管系统架构师应该在LSA模型中对它们进行了
定义(请参阅系统结构教程的第5步)。这意味着系统架构师必须被告知这两个新识别出来的信号。一旦他/她更新
了LSA模型，这些信号就可以在所有逻辑子系统的LSSA模型中使用。在这里，我们希望您能更新LSA模型。

定义CP系统评估所有子系统的状态，并向它们发送信号，如下。

1) 打开CP系统的LSSA模型(在上一步中创建的模型)，如果还没有打开的话。
2) 创建一个新的SysML活动图：
在模型浏览器中，选择3 Subsystem Behavior包。
右键单击包并选择Create Diagram。
在搜索框中，键入ad (SysML活动图的缩写)，然后按回车键。一个SysML活动图就被创建了。它包含
在SysML活动下。
输入Evaluate Status以定义新视图的名称，并再次按回车键。拥有该活动图的SysML活动默认和视图同
名。
3) 单击视图面板上的Initial Node按钮，然后单击视图编辑区上的空白位置。初始节点被创建并显示在视图
中。
4) 创建一个等待coolStatus信号的接受事件动作：
单击视图面板上的Accept Event Action按钮，然后单击视图面板上的空白位置。接受事件动作被创建
并显示在视图上。
在模型浏览器中，选择coolStatus信号：
a) 按ctrl + Alt + F。
b) 键入cools。
c) 当您在下面的搜索结果中看到coolStatus信号时，选中并按回车键。
将选定的信号拖到接受事件动作上，它变成了coolStatus接受事件动作。
双击接受事件动作。
在其规格中，找到Is Unmarshall属性并将其值设置为true。
关闭对话框。
当coolStatus接受事件动作被黄色边框包围时，选中该动作并点击带有黄色三角形的按钮(见下图2-
191)。
 选择Synchronize Accept Event Action Output Pins by Signal Properties。

图2-191

以coolStatus信号的属性名和类型的输出引脚被附加到接受事件动作上，如图2-192。

图2-192

5) 创建一个空的opaque action：
单击视图面板上Action按钮旁边的黑色小三角形，然后选择Opaque Action。
单击视图编辑区上的空白位置。一个新的opaque action被创建并显示在视图中。
完成后单击视图编辑区上的任意地方。
6) 在初始节点和opaque action之间创建一个控制流：
选中初始节点，并在初始节点的智能操作工具栏上单击控制流按钮 。
单击opaque action。控制流被创建。
7) 在coolStatus接受事件动作和opaque action之间建立一个对象流：
选择coolStatus接受事件动作的输出引脚，并在它的智能操作工具栏上，单击对象流按钮 。
单击opaque action。对象流与opaque action的输入引脚一起被创建。
在视图面板上单击输入引脚名。然后再次单击它以进入名称编辑模式。
输入coolOK以重命名引脚并按回车键，如图2-193。

图2-193
8) 定义opaque action表达式：
选中opaque action。
直接输入coolingReady = coolOK；
 完成后，单击视图编辑区上的任意地方，如图2-194。

图2-194
9) 为CP System Architecture块创建coolingReady值属性：

在模型浏览器中，右键单击CP System Architecture块，然后选择Create Element。

在搜索框中键入“value”属性的首字母缩写“vp”，按回车键。新的value属性将被创建，并处于名称编
辑模式。
输入coolingReady：Bool并按Ctrl +空格键。
当您在下面的列表中看到布尔类型时，选中并按回车键。
10) 创建决策节点：
在opaque action智能操作工具栏上单击控制流按钮 。
右键单击下方的空白处并选择Decision。
11) 创建两个SysOK发送信号动作：
在模型浏览器中，选择SysOK信号：
a) 按ctrl + Alt + F。
b) 键入syso。
c) 当您在下面的搜索结果中看到SysOK信号时，选中并按回车键。
将选定的信号拖拽到视图编辑区两次，两个SysOK发送信号动作被创建，并显示在视图编辑区中。
12) 重复前面的步骤，再创建两个SysNotOK发送信号动作。
13) 自行创建下图中看到的控制流。
14) 定义所有子系统转换到idle状态的条件：
选择右边的控制流。
输入[coolingReady==true并按回车键，Guard被定义了。

注意，右括号是自动添加的。你不需要自己输入。

15) 定义所有子系统转换到Off状态的条件，如图2-195：
选择左边的控制流。
键入[else并按回车键。
 图2-195
16) 定义SysOK发送信号动作是通过CP System Architecture块的p2代理端口发送的。
17) 定义SysNotOK发送信号动作是通过CP System Architecture块的p2代理端口发送的，如图2-196。
 图2-196

如果指定 系统需要考虑所有逻辑子系统的状态，参考评估状态活动图，如图 所示。

图
18) 打开CP System States状态机图。
19) 在模型浏览器中选择Evaluate Status活动，并将其拖到Initializing状态。
20) 选择为Do Activity，如图2-198。

图2-198
然后，Evaluate Status活动被设置为initialize状态的do行为，如图2-199。
 图2-199

必须通过定义触发到idle和Off状态转换的信号来更新这两个逻辑子系统的状态机图。您可以自己完成这些
操作(可参阅本单元教程的步骤4)。

以下是CP System States图的最终视图，如图2-200。

图2-200

以下这是制冷系统状态图的最终视图，如图2-201。

图2-201

步骤6： 同步来自结构模型的项流
 正如问题域模型一样，您在逻辑子系统架构的结构模型中识别的项流也可以在其行为模型中显示。下图显
示了Cool Down Cabin Air活动图中的项流(泳道间HPHTG和HPHTL信号)是从您在子系统结构教程的步骤4中创
建的Cooling System Logical Components内部块图同步的。记住，在你将动作分配到对应的泳道后，这是很容易
做到的，如图2-202。

图2-202

Cool Down Cabin Air活动图定义了制冷系统在运行状态下的行为(见下图2-203)。由于您已经知道如何创建

SysML活动视图，并将所选的SysML活动设置为状态的entry, do, 或者exit行为，因此这里不解释如何进行此操
作。然而，所描述的视图在Cooling System Solution模型中可用，可以在<modeling tool安装文件
夹>\samples\MagicGrid (即：C：\Program Files\Cameo Systems Modeler 2021x\samples\MagicGrid)。

图2-203

从对应的内部块图同步项流，如下。
 1) 选择“Compress Refrigerant”和“Turn Gas Into Liquid”动作之间的对象流。

2) 在对象流的智能操作工具栏上，单击实现所有项流按钮 ，如图2-204。

图2-204

项流从Cooling System Logical Components内部块图中同步，并显示在对象流上，如图2-205。

图2-205

2.2.3.5 完成子系统的行为，下一步做什么?

 一旦您定义了所有逻辑子系统的预期行为，您就可以开始将它们的LSSA模型集成到整个系统中，并创建
目标系统模型的不同配置(参见2.3构建系统配置模型章节)。
 您还可以转到子系统参数单元并确定计算一个或多个子系统参数的方法。
2.2.4 子系统参数

2.2.4.1 它是什么?

一旦在模型中捕获了子系统结构，您就可以转到这个单元。

子系统参数捕获可以度量的相关逻辑子系统的定量特征。它们用于计算在问题域分析期间确定的逻辑子系
统的MoE (参见1.2.3子系统的有效性度量章节)。在解决方案域模型中捕获的子系统的MoE满足非功能性定量子
系统需求。

从子系统参数推导MoE的数学表达式也应该在这个单元中定义。了解如何计算MoE可以实现早期的子系统
需求验证。利用建模工具的功能，可以执行模型来计算这些值，并判断是否得到满足定量需求。

这里需要注意的是，并非解决方案域中的所有MoE都必须基于问题域模型中的MoE。只有在构建逻辑子系
统的逻辑架构时，才能识别定义出某些MoE。

2.2.4.2 谁负责?

被指定的逻辑子系统的参数可以由系统架构师或系统工程师捕获，他们属于负责构建该逻辑子系统的LSSA
的工程团队。

2.2.4.3 如何建模?

就像整个目标系统的MoE一样，逻辑子系统的MoE可以作为应用«MoE»构造型的值属性在模型中捕获。这
些值属性必须属于块，这些块表示对应的逻辑子系统。您还必须知道，有效性度量可以从可重用的MoE集合(称
为MoE持有人)继承，而不需要从头定义它们。

计算MoE的公式可以捕获为某个约束块的约束表达式。SysML块定义图可用于捕获MoE、约束表达式，甚
至所需的子系统参数。下图2-206显示了捕获totalEnergyConsCool有效性度量的块定义图bdd，以及计算MoE的
公式，作为Total Energy Consumption for Cooling约束块的约束表达式。

图2-206
 为了使约束表达式能够执行计算，您必须定义应该将哪些子系统参数作为该约束表达式的变量(或者，按照
SysML，称为约束参数)使用。就像MoE一样，子系统参数可以在模型中捕获，作为捕获逻辑子系统或其任何组
件的块的值属性，只是没有任何构造型。SysML参数图可用于将子系统参数以及MoE与约束参数联系起来：前
者作为输入，后者作为输出。如下图2-207所示，实线表示绑定连接器。

图2-207

建模工具的仿真功能允许您通过给定的输入计算MoE。计算MoE之后，您就可以验证对应的非功能性子系
统需求，并显示它是否得到满足。建模工具使您能够自动执行此验证。为了能自动化验证需求，您需要创建一个
从捕获为MoE的值属性到相应子系统需求的满足关系。下图2-208显示了totalEnergyConsCool值属性与Max Energy
Consumption for Cooling非功能性需求间的满足关系的示例，这意味着当totalEnergyConsCool值属性的值不大于
1.2 kWh时，需求就被满足了。正如您所看到的，需求文本中的自然语言表达式由Max Energy Consumption for
Cooling约束块的约束表达式(x <= 1.2不等式)细化而成。

图2-208

SysML需求图中表示了满足和细化关系，但是块定义图bdd也可以表示这两种关系。
2.2.4.4 教程

步骤1： 组织子系统参数模型

捕获用于计算子系统参数的表达式的约束块可以存储在2.1 Cooling System Solution Domain包下的一个单独

的包中。按照MagicGrid框架的布局，它的名称必须以数字4开头，如图2-209。

图2-209

为子系统参数组织模型，如下。

1) 打开您在子系统需求教程的步骤1中创建的制冷系统的解决方案域模型(Cooling System Solution.mdzip)，

2) 右键单击2.1Cooling System Solution Domain包，选择Create Element。
3) 在搜索框中，键入pa(元素类型Package的前两个字母)并按回车键。
4) 键入4 Subsystem Parameters作为新包的名称并按回车键。

步骤2： 定义用于捕获制冷系统总能耗的MoE

根据子系统需求规格(参见2.2.1子系统需求章节)和在问题域模型中为冷却块确定的MoE(参见1.2.3子系统有
效性度量)，负责的工程团队必须定义用于捕获制冷系统消耗的总能量的MoE。

前面已经提到过，MoE可以从零开始定义，也可以从MoE持有者那里继承。下面的过程描述了后一种情
况。重定义继承的MoE以更改其名称和类型。重定义对于自动化需求验证是必要的，这将在以下步骤中描述。

定义用于捕获制冷系统消耗的总能量的MoE，如下。

1) 创建一个块定义图bdd用于捕获系统参数：
右键单击在上一步中创建的4 System Parameters，并选择Create Diagram。
在搜索框中，键入bdd (SysML块定义图的首字母缩写)，然后双击回车键。创建了图表。
键入Subsystem Parameters for Total Energy Consumption for Cooling定义新视图名称，并再次按回车
键。

2) 在视图上显示MoE Holder块：
按Ctrl + Alt + F打开Quick Find对话框。
在对话框中，键入MoE。
当您看到在搜索结果列表中选中的MoE Holder块时，选中并按回车键。然后在模型浏览器中可以看
 到该块被选中。
将MoE Holder块拖动到视图编辑区。视图中显示了块，如图2-210所示。

图2-210
3) 在视图上显示Cooling System Architecture块：
按Ctrl + Alt + F打开Quick Find对话框。
在对话框中：
a) 单击Any Element只搜索特定的元素。
b) 键入cooling system a。
当您在搜索结果列表中看到Cooling System Architecture块被选中时，按回车键。然后在模型浏览器中
会看到将该块被选中。
将Cooling System Architecture块拖到视图编辑区中。视图中显示了该块，如图2-211所示。

图2-211
4) 建立Cooling System Architecture块和MoE Holder块之间的泛化关系：
在块定义图中选中Cooling System Architecture块，然后在它的智能操作工具栏上单击泛化按钮 。
选择MoE Holder块。MoE Holder块成为Cooling System Architecture的超类型，这意味着后者继承了前
者的所有MoE，如图2-212。
 图2-212
5) 为Cooling System Architecture块重定义totalEnergyConsumption值属性：
右键单击Cooling System Architecture块，选择规格Specification.。
在打开的对话框的左侧，单击Properties。
在右侧的Value Properties类别下，选择totalEnergyConsumption值属性。
单击Redefine按钮。
在Type单元格中，立即输入kWh并按回车键。kWh值类型将在模型中被创建，并设置为重定义的值
属性的类型。
在Name单元格中，输入totalEnergyConsCool覆盖之前属性名并按回车键。这个新名称下继承的值属
性现在属于Cooling System Architecture块，如图2-213。
图2-213

单击Close。

如您所见，它重定义的继承的值属性显示在花括号中。

步骤3： 定义计算制冷总能耗的方法

您需要做的下一件事是捕获几分钟前为制冷系统所定义的如何计算MoE的数学表达式。它可以被捕获为存
储在模型中的某个约束块的约束表达式。

假设制冷系统的总能量消耗等于它的所有组件所消耗的能量之和。约束表达式定义如下：

totalEnergyCons = energycon1 + energycon2 + energycon3 + energycon4 + energycon5

其中：

1) totalEnergyCons表示制冷系统消耗的总能量
2) energycon1表示压缩机Compressor所消耗的能量
3) energycon2表示冷凝器Condenser所消耗的能量
4) energycon3可以代表Receiver Dryer所消耗的能量
5) energycon4可以表示计量装置Metering Device所消耗的能量
6) energycon5表示蒸发器Evaporator所消耗的能量

根据SysML，totalEnergyCons, energycon1，…，和energycon5通常被称为约束参数，以后应该和模型中定义
的对应值属性绑定。
 块定义图可用于捕获约束块。因此，您可以使用本单元教程步骤2中创建的bdd。获取计算制冷系统总能耗
的方法与在2.1.4 系统参数教程的步骤3中描述的方法相同。根据该方法，Subsystem Parameters for Total Energy
Consumption for Cooling块定义图应该如下图2-214所示。

图2-214

步骤4： 定义子系统参数，用于计算制冷总能耗

有了约束表达式，您就可以很容易地确定计算制冷系统消耗的总能量所需的子系统或组件参数。本例中指
定Total Energy Consumption for Cooling约束块的输入参数。

Total Energy Consumption for Cooling约束块有5个输入参数，每个参数代表制冷系统单个组件的能耗，因此

模型中需要5个组件参数。应该为捕获制冷系统的每个组件的块指定值属性。

捕获上述组件参数的过程符合2.1.4章节系统参数教程第4步中描述的过程。一旦你完成了参数定义，
ubsystem Parameters for Total Energy Consumption for Cooling块定义图如下图2-215所示。

图2-215

步骤5：绑定约束参数和对应的值属性

一旦模型中定义了所有必要的值属性，就该将它们和对应的约束参数绑定。请记住，正是绑定赋予了约束
表达式基于给定输入执行计算的能力。

可以使用绑定连接器建立值属性和约束参数之间的绑定。这类SysML关系可以在Cooling System
Architecture块下创建的SysML参数图下创建。然而，创建SysML参数图还不够。只有为Cooling System
Architecture块创建了类型为Cooling System Architecture约束块的约束属性后，才有可能建立绑定连接器。请注
意，同一个约束块可以在多个上下文中使用，而绑定连接器是用于特定上下文的。

如果将SysML参数图命名为Total Energy Consumption for Cooling冷却系统总能耗，则建立绑定关系的步骤

与2.1.4章节系统参数教程的第5步中描述的类似。完成后，您的模型中的冷却总能耗 Total Energy Consumption

for Cooling参数图应该如下图2-216所示。

图2-216

现在您可以执行模型，提供输入值，并查看计算结果。运行模型请在Total Energy Consumption for Cooling

参数图上方的工具栏中单击Run按钮 。在仿真面板的Variables选项卡中(默认情况下，它在仿真面板的右
侧)，可以指定输入值并查看输出值(计算的结果) ，如图2-217。
 图2-217

步骤6： 执行早期的子系统需求验证

有了捕获MoE的值属性的具体值，您就可以验证相关的子系统需求并显示它是否得到满足。在本例中，你
可以对制冷子系统的最大能耗需求Max Energy Consumption for Cooling进行验证，该需求描述The Cooling
System shall consume maximum 1.2 kWh。该验证过程的步骤可参考2.1.4章节系统参数教程第6步中所描述的。如
果您将需求图命名为Subsystem Requirements Formalized,，那么最后该需求图与如图2-218类似。

图2-218

现在，如果您返回到Total Energy Consumption for Cooling参数图并再次执行该模型，您应该看到

totalEnergyConsCool值属性绿色高亮显示，这意味着满足了最大能耗这个系统需求。尝试更改输入值，并查看
在需求未满足时高亮显示的颜色如何变化。这就是您执行自动化需求验证的方式。此外，通过这种方式，您可
以进行手动或自动(需要定义一些算法)参数优化，以找到最优的系统配置，如图2-219。

图2-219

这些值可以作为SysML实例规格及其slot值并存储在模型中。如果您不记得如何操作，请参阅2.1.4章节系统
参数教程的第7步。
步骤7： 重新计算不同状态下的子系统参数

有时，用于计算子系统参数的值可能是动态的，并且可能在子系统的不同状态下发生变化。因此，系统参
数值也可能不同。

为了说明这一点，让我们假设制冷系统的组件，在初始化状态和运行状态耗能较多，空闲状态耗能较少。

可以使用建模工具支持的Action Language Helper (ALH)表达式来指定能耗值：

 opaque behavior行为的主体Body设置为对应状态的entry或do行为，如图2-220。

图2-220
 而如图2-221所示，opaque action的主体。它属于对应状态的entry 或 do。

图2-221
 如你所见，这个ALH.setValue 表达式有一组变量，需要：

1) 部件属性的名称(在下图2-222中高亮显示)，由要更新其值属性的块类型化。该部件属性必须属于包含状
态机图的块；在本例中，包含状态机的块是Cooling System Architecture块。

图2-222

2) 要更新的值属性的名称(在下图2-223中高亮显示)。值属性必须属于先前定义为部件属性类型的块。

图2-223

3) 您希望为前面定义的值属性设置的具体值(例如，0.5)。

在不透明行为（opaque behavior）集的主体中定义值作为制冷系统待机状态的入口行为，如下。

1) 打开制冷系统状态机图：
按ctrl + Alt + F。
选择Diagram，并输入cooling sytem s
当您在下面的搜索结果中看到Cooling System States视图时，选中并按回车键。
2) 在视图编辑区双击idling待机状态。
3) 在打开对话框的右侧，在Entry类别下，选择Behavior Type属性。
 4) 单击此属性的值单元格，并从下拉列表中选择Opaque Behavior，如图2-224。

图2-224
5) 选择下面的Body and Language属性。
6) 单击此属性的值单元格并在那里输入：
ALH.setValue (cmp,“energyCons”,0.1);

ALH.setValue (cnd,“energyCons”,0.1);

ALH.setValue(evp,“energyCons”,0.1);

ALH.setValue (rd,“energyCons”,0.02);

ALH.setValue(md,“energyCons”,0.02);

7) 单击Close, idling状态中显示了ALH的表达式，如图2-225。

图2-225

定义opaque action本身的初始化状态的Entry 行为，如下。

1) 打开Perform System Check图：

按ctrl + Alt + F。
 选择Diagram并键入perform。
当您在下面的搜索结果中看到Perform System Check图时，请按回车键。
2) 单击图表面板上Action按钮旁边的黑色小三角形，然后选择Opaque Action。
3) 单击初始节点和决策节点之间的控制流。一个新的opaque action被创建并显示在视图上。
4) 立即键入以下内容到新创建的Opaque Action的形状：
ALH.setValue (cmp,“energyCons”,0.2);

ALH.setValue (cnd,“energyCons”,0.2);

ALH.setValue(evp,“energyCons”,0.08);

ALH.setValue (rd,“energyCons”,0.08);

ALH.setValue(md,“energyCons”,0.05);

5) 按下回车键，如图2-226。

图2-226

按照上述步骤，您可以更新Cool Down Cabin Air活动图。完成后，可以运行仿真，查看

totalEnergyConsCool值属性如何在制冷系统的各种状态下更改值。确保您在上下文环境(Cooling System Design

块)下运行仿真，它包含状态机图；否则，不计算子系统参数值。通过单击Run按钮旁边的黑色小三角形 并
选择Run with Context启动仿真。

2.2.4.5 子系统参数已完成，下一步做什么?

完成子系统参数单元意味着完成了整个模型，该模型描述了逻辑子系统的解决方案架构。在您可以将它集
成到整个目标系统的模型之前，唯一的任务是建立逻辑子系统架构元素到子系统需求间的追溯关系。
2.2.5 追溯到子系统需求

2.2.5.1 它是什么?

要拥有特定逻辑子系统的完整LSSA模型，您需要建立逻辑子系统架构元素到子系统需求间的追溯关系。正
如SysML定义的，这些是满足关系，意味着后者中的需求满足前者中的模型元素；例如，可以建立从类型为代
表某个逻辑组件的块的部件属性到某个子系统需求满足关系。在完整的LSSA模型中，所有的子系统需求都由一
个或多个架构元素来满足，即使这些元素还没有被实现。

2.2.5.2 谁负责?

指定逻辑子系统的LSSA模型中的追溯关系可以由系统架构师或系统工程师捕获，他们属于负责构建该逻辑
子系统的LSSA的工程团队。

2.2.5.3 如何建模?

SysML提供的9大视图都不适合创建大量的交叉关系，比如满足关系。建议使用依赖矩阵。建模工具为定义
交叉关系提供了广泛的预定义矩阵。比如可以使用满足需求矩阵来捕获满足关系，如图2-227。

图2-227

2.2.5.4 教程

步骤1:创建一个依赖矩阵来捕获满足关系
 在该步骤中，我们创建一个满足需求矩阵并定义它的准则。子系统需求可以显示在矩阵的行中，捕获的
LSSA的元素可以显示在列中。

创建一个满足需求矩阵，如下。

1) 在模型浏览器中，右键单击5 Traceability包(您在2.2.1章节子系统需求教程的第4步中创建)并选择Create
Diagram。
2) 在搜索框中，键入srm(预定义的满足需求矩阵的首字母缩写)，并按回车键。

如果你没有看到任何结果，点击搜索结果列表下面的 按钮。可用视图列表将在 模
式中展开。

3) 输入LSSA to Subsystem Requirements指定新矩阵的名称，并再次按回车键。

4) 在矩阵工具栏上，单击Change Axes按钮交换矩阵的行和列。矩阵行的类型变为需求。
5) 在模型浏览器中，选择SSR-1 SRS for Cooling System 需求(您可能需要首先展开1 Subsystem Requirements
包)，并将其拖到矩阵内容上方的Criteria区域的Row Scope框中。SSR-1 SRS for Cooling System需求成为矩
阵行(见下图)的范围。
6) 选择列元素类型：
在模型浏览器中，选择任意部件属性、代理端口、值属性、状态和调用行为动作。

若要选择树中几个非相邻项元素，请单击第一个元素，再按 ，同时依次选择其他元素。

将选中项拖到矩阵内容上方的Criteria区域的Column Type框上。矩阵的列被设置为显示您在下一个步
骤中选择的范围内的所有部件属性、代理端口、值属性、状态和调用行为操作(见下图)。

7) 选择列元素范围：
在模型浏览器中，选择Cooling System Architecture块(您可能需要事先展开1 Subsystem Structure包)。
将选中块拖到矩阵内容上方的Criteria区域的Column Type框上。选定的块成为矩阵列的范围(见下图2-
228)。

图2-228
 一旦完成，矩阵的内容就会被更新。目前所有的单元格都是空的，除了totalEnergyConsCool值属性和需求
SR-1.3 Max Energy Consumption for Cooling的交集(你可能还记得，这个关系是在2.2.4子系统参数教程的步骤中
创建的) ，如图2-229。

图2-229

步骤2： 捕获子系统需求的满足关系

现在你可以继续建立其他满足关系。因为你已经知道怎么做了，我们假设你可以自己完成矩阵。完成的矩
阵请参见下图2-230。

图2-230
 如果功能需求被标记为无效，则无需担心 您可以简单地忽略该警告，如图

如您所见，有一些代理端口不能追溯到任何子系统需求(如您所记得的，它们在2.2.2子系统结构章节中被识
别)。这需要对子系统需求规格进行修订和更新，反之亦然。这一次，只需要更新子系统需求规格。您可以在下
图2-232中看到高亮显示的新需求。
 图2-232

然后，可以完成该满足需求矩阵。正如在下面的图2-233中可以看到的，不再有悬空的元素了。

图2-233

步骤3： 追溯到系统需求并修订

如果您查看Subsystem Requirements to System Requirements and LSA矩阵，您可以看到有一些新的子系统需

求没有建立追溯关系。SSR-1.1.2热空气清除和SSR-1.1.3废物清除是您在上一步中创建的子系统需求，如图2-
234。

图2-234

在这个矩阵中建立了更多细化的关系之后，它应该如下图2-235所示。
 图2-235

现在是时候建立从这些子系统需求到系统需求的派生关系了。这要求您首先捕获新的系统需求。SSR-1.1.2
Hot Air Removal或SSR-1.1.3 Waste Removal需求的产生，是由于在制冷系统逻辑子系统架构LSSA模型上工作的
工程团队识别出了接口。而且，这些接口首先属于目标系统。因此，我们可以说，目前至少缺少两个系统需
求。

以下是应对这种情况的行动项：

1) 作为系统架构师，在LSA模型中添加系统需求规格，并添加两个新的接口需求，如图2-236。

图2-236
2) 在LSA to System Requirements需求满足矩阵中，建立对应代理端口(在2.2.2子系统结构教程的步骤5中创
建)到这些需求的满足关系，如图2-237。

图2-237
3) 在System Requirements to Stakeholder Needs派生需求矩阵中，创建从新的系统需求到涉众要求间缺失的派
生关系，如图2-238。

图2-238
 4) 作为负责的工程团队，在制冷逻辑子系统架构模型中建立子系统和新系统需求之间缺失的派生关系，如
图2-239。

图2-239

当您完成时，查看From Stakeholder Needs to Subsystem Requirements需求图。它也应该被更新，如图2-240。

图2-240

2.2.5.5 完成子系统逻辑架构，下一步做什么?

MagicGrid BoK并没有详细说明如何对每个组件建模(例如，如压缩机、冷凝器和蒸发器等)或如MagicGrid
框架定义的建立更具体颗粒度更细的模型。只需注意，这些颗粒度级的建模工作流足够支持子系统层建模了。
也就是说，您从该详细级别的需求派生开始，然后对结构、行为和参数展开建模，以满足需求；然后，您就可
以建立跟踪关系，以批准建议的逻辑架构。

正如序言中所提到的，解决方案域的组件级模型可以是MBSE和MBD范畴，因为这是逻辑架构与目标系统
的逻辑(高级)设计相关的地方， 接下来就开始MBD。因此，除了SysML之外，还可以在组件级应用其他标准。
这些包括用于设计软件组件的OMG®统一建模语言(UML)®，用于设计机械、电气和电子组件的Modelica®语言
等。请注意，对于UML，您不需要切换软件，因为建模工具同时支持UML和SysML。

当您拥有所有逻辑子系统的LSSA模型，包括它们的组件和更精确的单元模型时，您可以将它们集成，并在
单个模型中拥有目标系统的整个逻辑架构(参见2.3构建系统配置模型章节)。

2.3 构建系统配置模型
构建系统配置模型是指定解决方案域的最后阶段。在工程团队完成目标系统SoI所有逻辑子系统的解决方案
架构之后开始构建系统配置模型。此阶段的目标是构建整个目标系统SoI的集成模型，并通过验证模型的完整性
来检查其逻辑子系统是否能够成功地相互交互。这是系统架构师或系统集成商的任务。注意，可以提出多个解
决方案；然后系统架构师/集成商基于多方案进行权衡分析，从每个逻辑子系统中选择一个首选的子系统。

下图2-241中红色曲线包围的区域即当前讨论的解决方案域的一部分。

图2-241
 通过查看MagicGrid框架的设计布局（参见下图2-242中突出显示的区域），你可能会推断出，系统配置模
型捕获了目标系统SoI的总体结构、行为和参数。

图2-242

2.3.1 系统配置结构

2.3.1.1 它是什么?

一旦所有工程团队交付了SoI每个逻辑子系统的LSSA模型（在逻辑系统架构LSA模型中定义），系统架构
师/集成商就能够完成他/她们的工作。也就是说，他/她们可以将所有的模型集成为一个整体，并构建系统配置
模型。

建立系统配置模型的主要目的是验证目标系统的逻辑子系统是否能够成功通信。系统架构师/集成商必须检
查各个逻辑子系统间的接口是否兼容。如果检测到一个或多个不兼容的接口，系统架构师/集成商要求对应负责
的工程团队正确地审查和变更其模型。工程团队完成该任务后，系统架构师/集成商可以再次尝试集成模型。

虽然VCCS总体上有四个逻辑子系统，但本文档只关注集成其中两个制冷系统和CP系统（: the Cooling

System和the CP System）。集成了所有逻辑子系统的模型可以在建模工具安装文件夹>\samples\MagicGrid中找
到；例如，C:\Program Files\Cameo Systems Modeler 2021x\samples\MagicGrid。

2.3.1.2 谁负责?

系统配置结构可以被系统架构师或系统工程师捕获，他是整个系统工程项目的负责人，负责顺利集成子系
统及其组件为一个整体系统，也是拥有目标系统SoI逻辑系统架构（LSA）模型的人。这个任务也可以由系统架
构师下的系统集成商执行。
2.3.1.3 如何建模?

可以使用SysML bdd图（块定义图）来捕获系统配置的集成结构模型，如图2-243。

图2-243

用户使用结构分解图（The Structure decomposition map）能够以紧凑的形式检查和更新集成的结构模型，

如图2-244。

图2-244

可以通过在SysML ibd图中指定逻辑子系统通信来验证接口的兼容性，如图2-245。
 图2-245

2.3.1.4 教程

步骤1： 创建和组织系统配置结构模型

因为已经有了Cooling System和CP System的LSSA模型，您（作为系统架构师/集成商）可以将它们集成到

一个代表整个VCCS系统的单一模型中。

为此，您必须创建另一个模型。通常，这个模型可以称为系统配置模型。请注意，在单个解决方案域中可
以有多个系统配置模型；不过，这里我们只关注其中一个。

创建VCCS的系统配置模型，如下。

1) 开始共享制冷系统和CP系统的LSSA模型。

• VCCS所有子系统的LSSA模型应在此步骤中共享。
• 有关此主题以及步骤 和步骤 主题相关的更多信息，请参阅建模工具的最新文档。

2) 创建一个新模型。可以命名为 VehicleCCS Configuration.mdzip。这是车辆空气调节单元（Vehicle Climate

Control System）的配置模型。
3) 在VCCS的配置模型中，将制冷系统Cooling System的LSSA模型权限设置为只读read-only。因为它已经被
用于制冷系统的LSSA模型，VCCS（LSA模型）的问题域模型和解决域模型相当于也自动被共享使用
了，如图2-246。
 图2-246

4) 重复步骤3，使用CP System的解决方案域，如图2-247。

图2-247
5) 右键单击Model包 (这是根包的默认名)，并选择创建元素Create Element。
6) 在搜索框中，键入 pa（元素类型 Package 的前两个字母），然后按回车。
7) 输入 3 Configuration Domain 指定新包名，并按回车键（参见步骤9中的图）。
8) 右键单击 3 Configuration Domain 包，选择Create Element。
9) 重复步骤6。
10) 输入 2 System Structure 指定新包的名称，按回车，如图2-248。

图2-248
步骤2： 准备捕获系统配置的结构

要准备捕获目标系统或其中一个配置的集成结构，首先需要创建一个表示系统配置的块。新建的VCCS配
置块必须继承LSA模型中捕获的VCCS块的所有结构和行为特征（参见2.1.2系统结构教程的步骤3）。因此，
VCCS配置块必须是捕获的LSA模型下VCCS块的子类。

在 2 System Structure 包下创建的bdd图可以用来捕获这个块，也可用来执行本单元教程的后续步骤。

准备捕获VCCS配置块结构，如下。

1) 创建一个bdd图：
在模型浏览器（Model Browser）中，右键单击您在本单元教程的第1步中创建的 2 System Structure
包，并选择创建视图Create Diagram。
在搜索框中，键入bdd (SysML块定义图的首字母缩写)，然后按回车。创建了bdd图。
输入VCCS Configuration Structure 指定新视图的名称，再次按回车键。

2) 在视图中显示LSA模型中的VCCS块：
在模型浏览器中，选择VCCS块（您可能需要首先展开 2 Solution Domain和 2 System Structure包），
如图2-249。

图2-249

将选中的VCCS块拖动到新创建的视图框内，VCCS块就出现在视图中了。

3) 创建一个块来捕获VCCS配置:
请选择VCCS块，如果尚未选中，在智能操作工具栏上单击泛化按钮 ，如图2-250。
 图2-250
在视图下空白处单击，将创建一个新的未命名块，显示在视图编辑框中。
输入 VCCS Configuration 指定新块的名称，按回车键，如图2-251。

图2-251

4) 重定义继承的代理端口：

双击视图中 VCCS Configuraiton 块。

在打开的对话框的左侧，单击Ports/Interfaces。
在第一行中选择代理端口并单击下面的重定义Redefine按钮，如图2-252。
 图2-252
然后，选择的代理端口被重定义了。不会显示表示继承关系的的插入符号（" ^ "）。不要改任何东西，
如图2-253。

图2-253

逐行重定义其余部分（项的顺序可能与下面的图中看到的不同），如图2-254。

图2-254

单击 Close。
 5) 在 VCCS Configuration 块的智能操作工具栏上单击显示所有端口 Display All Ports 按钮 。VCCS
Configuration 块的代理端口就会显示出来，如图2-255。

图2-255

步骤3： 捕获系统配置的集成结构

您可以利用上一步中创建的bdd来构建集成的结构模型。在此步骤中，您需要做的就是定义包含在指定系
统配置中的逻辑子系统。如果（在本例中）每个逻辑子系统只有一种方案架构，那么系统配置也是单一的。

在指定系统配置结构时，表示逻辑子系统的块必须取自LSSA模型；即来自制冷系统的LSSA模型（Cooling
System Solution.mdzip文件）的制冷系统架构块（Cooling System Architecture block），来自CP系统的LSSA
（CP System Solution.mdzip文件）的CP系统架构块（CP System Architecture block）。确保您不是从LSA模型中
获取表示逻辑子系统的块，这些块既没有内部结构，也没有行为；记住，创建它们是为了识别工作包。

建模工具实际上使您能够防止选择不适当的块。为此，您需要将类型选择的范围缩小到一个或多个包。在
本例中，使用的是共享模型（used model）中的 2.1 Cooling System Solution Domain和 2.2 CP System Solution
Domain包，如下图2-256所示。如果您需要回顾如果缩小范围，请参阅2.3.2教程的第3步。
 图2-256
现在，您已经准备好捕获VCCS配置的集成结构。只是不要太快地为VCCS Configuration块创建新的部件属
性（part property）。作为VCCS块的子类，它已经从超类继承了它们。因此，您所需要做的就是重定义VCCS
Configuration块继承的部件属性，并为它们选择新的类型。

获取VCCS配置的集成结构，如下。

1) 如果没有打开，请打开VCCS配置结构的bdd图（VCCS Configuration Structure bdd）。

2) 将制热系统的LSSA集成到VCCS配置中：
双击 VCCS Configuration 块。
在VCCS Configuration 块的规范“specification”中，单击左侧的属性Property。
选择右边的 Cooling 部件属性，然后单击下面的重定义Reifine按钮。
在类型Type列中，选择Cooling System Architecture块，如图2-257。

图2-257

3) 按照步骤2.c和2.d，将CP System的LSSA集成到VCCS configuration中。

关闭对话框后，VCCS Configuration Structure视图看起来应该与下图2-258类似。
 图2-258

如果您将组成部分一个一个地从封闭的VCCS Configuration块中拖出，视图就成为如下图2-259样子。

图2-259

如果您决定显示更深层的结构（右键单击制冷系统设计Cooling System Design块，并选择Display >Display

Related Elements），视图应该如下图2-260所示。
 图2-260

SoI配置的集成结构也可以显示在结构分解图Structure decomposition map中，这是建模工具的预定义视图之

一。它可以以紧凑的形式显示任何结构，特别适合于评审。

在结构分解图Structure decomposition map中显示VCCS配置的集成结构

1) 在打开的视图中，选择VCCS Configuration块。
2) 右键单击选择的VCCS Configuration块，然后选择创建视图Create Diagram。
3) 在搜索框中，键入sdm (结构分解图的首字母缩写)，然后按回车键。就创建了结构分解图。

如果你没有看到任何结果，点击搜索结果列表下面的Expert按钮。可用视图列表将在Expert模式
中展开。

4) 输入VCCS Configuration Structure指定新map图的名称，再次按回车键，如图2-261。

图2-261
 如果你的建模工具版本低于2021x，你应该看到cooling和cp的部件属性两次(见下图2-262)。
这是因为这些版本中的结构分解图显示继承的部件属性，即使它们是重定义的，。

图
要从图中删除继承的部件属性，请选择它们并按删除键。

步骤4： 验证接口兼容性

现在是时候指定逻辑子系统如何在VCCS配置中通信了。

记住，只有当这些逻辑子系统具有兼容的接口时，通信才可能实现。出于这个原因，我们可以说系统架构
师通过在SoI的特定配置中指定交互来执行接口兼容性验证。

您已经知道，可以在SysML ibd中指定系统内部组成之间的交互。因此，让我们创建一个并检查VCCS的两
个逻辑子系统Cooling System和CP System是否能够成功通信。

指定制冷系统和CP系统之间的相互交互

1) 创建一个ibd图，用于指定逻辑子系统之间的交互：
在本单元教程第2步创建的VCCS Configuration Structure视图中，选择VCCS Configuration块。

在智能操作工具栏上单击SysML内部框图按钮 。
创建了一个新的空白ibd视图。
在Display Parts/Ports对话框中，执行以下操作:
a) 单击右侧的Clear All，取消选择所有项。
b) 单击选中cooling: cooling System Architecture和cp: cp System Architecture部件属性（如下图2-263
所示）附近的复选框，单击OK。
 图2-263
选中的部件属性（part property）显示在视图框中，如图2-264。

图2-264

在模型浏览Model Browser中，选择新创建的视图并按F2进入名称编辑模式。
输入subsystem Communication in VCCS修改名称，然后按回车键。
2) 显示制冷系统和CP系统之间交互的代理端口:
右键单击cooling属性，并选择Display>Display/Ports。
在Display Parts/Ports对话框中，执行以下操作:
a) 单击右侧的Clear All，取消选择所有项。
b) 单击选中p3: ~InternalControl和p4: InternalResponse代理端口附近的复选框（见下图2-
265），然后单击OK。
 图2-265

所选代理端口显示在冷却部件属性(part property)上，如图2-266。

图2-266

按照步骤a和b在cp部件属性上显示相关的代理端口，如图2-267。

图2-267
 可以 看到 ，有 两对 兼容的 代理端 口 ： 一对 类型 是InternalControl 接口 块， 另一 对 类型 是
InternalResponse接口块（interface block）。每一对都有一个用于数据输入的代理端口和一个
用于数据输出的代理端口。

3) 在兼容的代理端口间创建部件属性（part property）之间的连接器：

在cp部件属性上选择p2代理端口，然后在它的智能操作工具栏上单击Connector按钮 。
点击cooling部件属性上的p3代理端口。
按照步骤a和b在另一对兼容的代理端口之间创建连接器connector，如图2-268。

图2-268
4) 将Start信号指定为cp和Cooling部件属性之间流过连接器connector的项流（item flow）:
在模型浏览器中，选择开始Start信号:
a) 按Ctrl + Alt + F，快速查找Quick Find对话框打开。
b) 键入start，当您在下面的搜索结果列表中看到选定的start信号时，按回车键。在模型浏览器中就会
选中在以下包结构 :2 Solution Domain> 2 System Structure> 2 Exchange Items下的start信号。
将选中的start信号拖动到类别为InternalControl接口块的两个代理端口之间的连接器上。
在打开的对话框中，不要更改任何内容，然后单击Finish，如图2-269。

图2-269
5) 按照步骤4将SysOK和SysNotOK信号指定为流经同一连接器的项流（item flow），并将coolStatus信号指
定为流经cooling和cp部件属性之间连接器的项流，如图2-270。
 图2-270

如您所见，没识别出不兼容的接口，我们可以声明制冷系统和CP系统可以在VCCS中成功通信。

在指定逻辑子系统与外部的交互之后， Subysystems Communication in VCCS 视图应该如下图2-271所示。

图2-271

2.3.1.5 完成系统配置结构，下一步要做什么?

 集成的系统配置模型可以比LSA模型计算出更精确的系统参数值。系统配置参数章节描述如何做到这
一点。
 此外，逻辑子系统通信的规范使它们的行为模型能够交换信号（到目前为止，只能在单个逻辑子系统的
范围内发送和接收信号）。因此，您可以切换到分析整个目标系统SoI的集成行为，这会在系统配置行
为这章中描述。
2.3.2 系统配置行为

2.3.2.1 它是什么?

目标系统的行为集成了其逻辑子系统的行为，在LSA模型中被识别（参见2.1.2系统结构章节）。

一旦您构建了整个SoI的集成结构模型（参见前一章），您就拥有了它的集成行为模型。在这个单元中不需
要建模工作。其主要目的是对集成的系统行为模型进行分析和验证。

2.3.2.2 谁负责?

系统架构师或系统工程师，是整个系统工程项目的负责人，可以分析和验证系统配置的综合行为，负责顺
利集成子系统及其组件为一整体，也是拥有SoI LSA模型的人。这个任务也可以由系统架构师的下属系统集成商
执行。

2.3.2.3 如何建模?

记住，这个单元格主要工作不是建模，是集成模型并分析。为此，可以使用建模工具的仿真能力，通过可执
行模型，来仿真整个目标系统SoI的行为，并验证它是否符合预期。

仿真模拟使您能够监视执行进度。标记出当前、最后访问的和所有其他访问过的元素。下图2-272描述了模
型执行的仿真时刻，当CP System Architecture块通过p2代理端口发出Start信号，然后Cooling System Architecture
块将接收到该信号。注意，Subsystems Communication in VCCS视图是有帮助的；它指定Start信号发送的位置。

图2-272
2.3.2.4 教程

步骤1: 启动系统配置块的仿真

作为系统架构师，分析执行集成系统行为，以验证SR-1.2.1 Internal communication内部通讯、SSR-1.2.2

Initializing初始化和SSR-1.2.3 Idling空闲需求。你需要证明指定的系统行为符合以下逻辑：

1) 一旦点火启动，CP系统初始化VCCS的所有其他子系统（这里，仅制冷系统）。
2) 作为响应，制冷系统执行自检并通知CP系统是否可以启动。
3) CP系统从制冷系统接收到反馈状态后，决定它们是否都能启动。
为了仿真SoI的整个配置的行为，必须指定一个相关块作为仿真环境。此处指定为VCCS Configuration块，
如下图2-273所示。

图2-273

如果系统行为在LSA模型中已经定义，但仍被指定为VCCS块（VCCS Configuration块的超类）的分类
器行为（classifier behavior），则在仿真过程中会与VCCS Configuration块的集成行为发生冲突。
为 了 避 免 这 种 冲 突 ， 请 返 回 LSA 模 型 ， 并 设 置 VCCS 块 的 Classifier Behavior 属 性 值 为
<UNASSIGNED>（参见2.3.3系统配置参数章节）。如果您不能更改LSA模型（例如，您没有相关
的权限），您可以为VCCS Configuration块定义一个伪系统行为（例如具有单个缺省状态的状态
机）。从而使伪系统行为成为类器行为，在仿真过程中不与集成系统行为发生冲突。
启动VCCS Configuration块的仿真，如下。

1) 在模型浏览器中选择VCCS Configuration块。
2) 右键单击选择，然后选择Simulation > Run。仿真面板Simulation在建模工具窗口的底部打开。

3) 单击Auto Open Diagrams按钮 激活该模式，在该模式中，当前执行的视图将自动打开。

4) 在Simulation面板的工具栏上，单击开始按钮 。仿真Session会为VCCS Configuration块中的每个组成部

分（part）创建状态机仿真。在本例中，这些是Cooling System Architecture和CP System Architecture块的
状态机，如图2-274。
图2-274

步骤2: 分析系统配置的集成行为

当模型开始执行时，监视仿真进程，直到两个状态机都处于Off状态。下图显示了当您触发CP System States

状态机图中的Off和On状态之间的转换时的情况，如图2-275。

图2-275

作为手动触发转换的结果，CP System Architecture块进入初始化Initializing状态。在进入该状态时，它通过

p2代理端口发送Start信号（见下图2-276）。

图2-276

正如IBD Subsystems Communication in VCCS视图中定义的，Start信号由制冷系统架构Cooling System

Architecture块接收，如图2-277。
 图2-277

收到Start信号自动触发在Cooling System States状态机图中显示的Off和On状态之间的转换。因此，Cooling

System Architecture块进入initialize初始化状态。在进入initialize初始化状态时，它执行系统检查Perform System
Check活动并通过p4代理端口发送coolStatus信号。记住，coolStatus信号具有coolOK属性值，为true或false，如
图2-278。

图2-278
 正如ibd Subsystem Communication in VCCS视图中定义的，CP System Architecture块接收到coolStatus信号，
如图2-279。

图2-279

CP System Architecture块收到coolOK信号，读取它的属性值，并决定两个子系统是否可以切换到idle状态。
为此，它先执行Evaluate Status活动，如图2-280。

图2-280

CP System Architecture块通过p2代理端口发送SysOK或SysNotOK信号（见下图2-281）。如图所示，同样的
信号也会在内部发送，这里是为了触发CP System Architecture块内的一个转换：或者是切换到idle状态，或者是
切换到Off状态。
 图2-281

因此，捕获逻辑子系统的两个块都切换到它们各自状态机的idle状态（参见下图2-282）。等待
DesiredTmpSet信号。

图2-282
 如果您想在单个视图框内显示两个或更多视图，创建一个内容视图Content diagram，从模型浏览器中将

您想要查看的所有视图拖动到内容视图编辑框中，并将每个视图形状转换为视图概览状态（参见下图
）。有关更多信息，请参阅建模工具的最新文档，

分析表明，该集成系统行为模型满足相关系统和子系统的需求。

2.3.2.5 完成系统配置行为。下一步做什么?

完成集成系统行为模型的分析后，就可以切换到最后一个任务构建系统配置模型，计算出比LSA模型更精
确的系统参数值。2.3.3章节描述如何做到这一点。
2.3.3 系统配置参数

2.3.3.1 它是什么?

系统配置模型使您能够将不同颗粒度的计算方法联系起来，例如一个来自系统级别的计算方法和一些来自
子系统级别的计算方法。与LSA模型相比，可以定义更具体的输入值，得到更精确的计算结果。例如，在LSA
模型中，您必须指定制冷系统的能耗，而在系统配置模型中，可以通过对其逻辑组件的能耗进行汇总来导出系统
能耗。

2.3.3.2 谁负责?

系统架构师或系统工程师是整个系统工程项目的负责人，可以分析和验证系统配置参数，并负责将子系统
及其组件顺利集成到整个系统中；也是拥有目标系统SoI的LSA模型的人。这个任务也可以由系统架构师的下属
系统集成商执行。

2.3.3.3 如何建模?

通常您不需要在系统配置模型中捕获任何计算方法。在LSA模型和LSSA模型中都做过。您还定义了系统、
子系统和组件参数。您也不需要在系统配置模型中重新捕获它们。

但是，您可能需要更新绑定。例如，您可能需要将LSA模型中指定的约束参数和LSSA模型中创建的值属性
绑定。在这种情况下，SysML参数图的基础架构就会很有帮助，如图2-283。

图2-283
2.3.3.4 教程

步骤1: 重定义MoE

假设您想要检查制冷系统的逻辑组件的能耗如何影响整个VCCS的总能耗。为此，您需要做如下事情。

首先，重定义从VCCS块继承的totalEnergyConsumptionVCCS值属性。重定义对于计算来说不是必需的，因
为您可以使用继承的值属性执行它们。但是，您需要重定义值属性，以便能够创建从值属性到相关系统需求的
满足关系。

重定义totalEnergyConsumptionVCCS值属性，如下。

1) 打开在本单元教程的第2步中创建的VCCS Configuration Structure视图。

2) 右键单击VCCS Configuration块，选择Specification。
3) 在打开的对话框的左侧，单击Properties属性。
4) 在Value Properties类下，选择值属性totalEnergyConsumptionVCCS，单击下面的Redefine按钮。
5) 所选的值属性被重定义，现在不再出现指示继承关系的插入符号(" ^ ")。不要改变任何东西。
6) 单击Close按钮，如图2-284。

图2-284

现在可以做步骤2。

步骤2: 创建参数图

接下来要做的是将捕获制冷系统总能耗的值属性与约束属性的输入参数关联起来，约束属性定义了计算整
个VCCS总能耗的方法。

创建SysML参数图是建立这种关系的好实践。请记住，这种类型的视图只能在块下创建。这里，参数图创
建在VCCS Configuration块下。
为VCCS Configuration块创建SysML参数图，如下。

1) 在模型浏览器中，右键单击该块并选择Create Diagram创建视图命令。
2) 在下面的创建视图对话框中选择SysML Parametric Diagram。一个新参数图被创建，显示参数/属性对
Display Parameters/Properties话框被打开。
3) 在对话框中：
选中约束属性:Total Energy Consumption 边上的复选框。

这个约束属性定义了计算VCCS总能耗的方法。在LS 模型中为VCCS块指定了这个约束属
性。它也属于VCCS Configuration块，因为它是VCCS块的子类，并从VCCS块继承了它的所
有特性，包括约束属性。

单击cooling:Cooling System Architecture部件属性边上的按钮 ，展开其包含的内容。

单击选中/ totalenergyconschool: kWh值属性边上的复选框。

该分系统参数是通过对压缩机、冷凝器、蒸发器等部件的能耗进行综合得出的，从组件参数
派生而来。在计算VCCS的总能耗时，需要将LSA模型中指定的energyCons: kWh值属性替换
为该值属性。

单击cp: cp System Architecture部件属性边上的按钮 ，展开其包含的内容。

单击选择energyCons: kWh值属性边上的复选框。

由于您还没有定义CP系统能耗计算的方法，您可以使用LSA模型中定义的值属性。同样的逻
辑也适用于其他逻辑子系统。

按照d和e步骤选择heating: Heating System加热系统和hmi: HIMI System部件属性下的energyCons: kWh

值属性。
确保选中了/totalEnergyConsVCCS: kWh值属性边上的复选框。
确保其他所有内容都未选。
单击OK关闭对话框。
4) 在模型浏览器中，将新建的参数图命名为VCCS Configuration Energy Consumption 。
完成之后，VCCS Configuration Energy Consumption视图应该如下图2-285所示。

图2-285
 如果愿意，可以将显示值属性的点标记改为嵌套表示。选择除totalEnergyConsVCCS值属性之外的所
有组成，然后右键并选择Refactor>Convert to Nested Part转换为嵌套表达，如图 。

步骤3: 更新绑定关系

现在可以更新绑定关系并重新进行计算。

更新参数图中的绑定关系，如下。

1) 选择约束属性并它的智能操作工具栏上单击Display All Parameters 显示所有参数按钮 。参数和到相应

值属性的绑定连接器就会显示在视图上,如图2-287。

图2-287
 2) 在cooling:Cooling System Architecture 部件属性中选择/ totalenergyconschool: kWh值属性。
3) 在它的智能操作工具栏上单击绑定连接器Binding Connector按钮 。
4) 单击energycon1参数框。创建了新的绑定连接器，参数图已经准备好计算VCCS遇到制冷系统组件消耗能
量时的总能量消耗,如图2-288。

图2-
288

5) 重复2到4，在CP System Architecture块的energyCons值属性和energycon2参数之间建立另一个绑定器连

接。
6) 重复2到4建立VCCS Configuration块的/totalEnergyConsVCCS值属性和totalEnergyCons参数绑定连接。
现在，如果您在这个视图上运行仿真，可以输入子系统和组件的不同的能量消耗值，并查看结果。结果值可
以存储在模型中（参见2.1.4系统参数章节中的第7步），如图2-289。
 图2-289

当您将所有逻辑子系统的解决方案架构集成到系统配置模型中时，您可以更新此视图中的其他绑定关系。

2.3.3.5 完成系统配置参数, 下一步做什么?

完成了系统配置参数意味着你已经完成了绝大部分系统配置模型工作。还需要做的是完成系统配置到系统
需求的追溯。
2.3.4 从系统配置到系统需求的可追溯性

2.3.4.1 它是什么?

为了确保系统配置模型的完整性，并且考虑和实现了所有的系统需求，您需要分析并指定系统配置模型到
系统需求规格的追溯关系 – 满足关系。

2.3.4.2 负责的是谁?

追溯关系可以由系统架构师或系统工程师指定，他们是整个系统工程项目的负责人，并负责将子系统及其
组件顺利集成到整体中。

2.3.4.3 如何建模?

正如您已经知道的，满足需求矩阵为指定满足关系提供了最好的框架。这个矩阵与在LSA模型中创建的矩
阵基本相同。只有列域不同：这里应该选择VCCS Configuration块而不是VCCS块。

下图2-290的矩阵显示了一些还没满足的系统需求。为此，您需要构建Heating和HMI Systems的LSSA，然
后将它们集成到系统配置模型中。

图2-290
2.3.4.4 教程

指定可追溯性关系的步骤相当于“追溯到系统需求”教程中的步骤：

 步骤1. 创建表示满足关系的矩阵
 步骤2. 捕获满足关系

2.3.4.5 完成解决方案域设计，下一步做什么?

拥有完整的系统配置模型意味着您已经完成了整个解决域的工作，这表明您已经准备好转到实现域，并准
备开始考虑您的真实系统。
 第3章 实现域

3.1 实现域分析
在确定了整个系统的逻辑架构和设计，并选择了最佳的系统配置（通过权衡分析）后，就可以实施系统
了。此时，您应该将系统视为真实的，而不是抽象的系统，就像您对待问题和解决域那样。

下表中可以看到，MagicGrid框架只覆盖了部分实现域。该框架仅定义如何为SoI指定实现需求。然而，SoI
的详细物理设计并不是MagicGrid框架的一部分。目标系统SoI开发的下一步可以通过使用诸如电气和机械CAD
工具或自动代码生成工具等来完成，如图3-1。

图3-1

3.1.1 实现需求

3.1.1.1 它是什么?

为了实现目标系统，在产生系统的详细物理设计时，首先需要遵循详细的需求。这些需求基于目标系统的
逻辑架构，包括其所有子系统的逻辑架构，甚至更精确的单元。

实施需求规格书提供给负责设计正在实施系统的各个学科工程师。

3.1.1.2 谁负责?

系统设计师负责生成实现需求规范。
3.1.1.3 如何建模?

在建模工具中，实现需求规范的项可以存储为SysML需求，该需求具有惟一的标识符、名称和文本规范。
实现需求必须是形式化的，并按照一定的参考指南写的。这可能包括只写简短清晰的句子；避免条件关键字，
例如如果if、除非except、也as well，使用应当Shall等关键字。欲了解更多关于如何编写好的文本需求的信息，
请参阅INCOSE系统工程手册。

管理实现需求类似于管理系统、子系统和组件需求。与那些需求一样，实现需求可以被分类和组织为组、
子组等等。SysML支持各种各样的需求类别，如物理需求、功能需求和性能需求等。对于组需求，请使用包含
containment关系。捕获组项的SysML需求可能不包含任何文本。如下图所示，它显示了制冷系统的实现需求示
例，有四组需求：电子与电气、机械、流体和通用特性，如图3-2。

图3-2

如下图所示，每个实现需求应该从系统配置模型中提炼细化一个或多个模型元素，或者至少从解决域的一
个需求中派生出来。为此，可以创建一个指定这两种关系类型的矩阵（类似于2.2.1章节的步骤4）。

图3-3
 通过分析以上矩阵，您可以得出结论，实现需求规范还没有完成。当系统配置模型中的每个元素被一个或
多个实现需求提炼（refine），并且每个解决方案域需求被至少一个实现需求覆盖时，才被认为是完成了。

在不同域的需求之间建立派生关系，您可以很容易地从非常详细的需求追溯到非常抽象的需求，并查看哪
些项决定了其他项的创建。为了执行这个影响分析（不管是下游还是上游），我们建议使用需求派生图
Requirement Derivation Map框架，这是建模工具中预定义视图之一，如图3-4。

图3-4

3.1.1.4 教程

本单元教程的步骤和子系统需求教程的步骤相似：

 步骤1. 创建和组织子系统需求模型
 步骤2. 创建子系统需求视图
 步骤3. 指定子系统的需求
 步骤4. 指定追溯关系
不同之处在于，在步骤4中，您建立了对制冷系统的子系统需求和系统配置模型的相关元素的可追溯关系。

3.1.1.5 下一步做什么?

您已经准备好开发系统的详细物理设计了。但哪些活动不属于MagicGrid方法的范围。
附录A: 安全性&可靠性分析

作者： Andrius Armonas, PhD, Elona Paulikaitytė, Osvaldas Jankauskas, Tomas Juknevičius

可靠性是功能单元在给定条件下、给定时间间隔内执行所需功能的能力（ISO/IEC 2382:2015 Information

Technology）。安全性是没有不可接受的风险（IEC 61508:2010 EEPE安全相关系统）。

SysML作为MBSE的关键组成之一，具有捕获需求、架构、约束、视图和视角的良好基础。但是，SysML
没有提供必要的构造来捕获系统模型中的安全性和可靠性信息。Cameo Safety and Reliability Analyzer插件填补
并支持了这些缺失的部分。支持以下安全可靠性标准：

 根据IEC 60812:2006标准进行失效模式和影响分析(FMEA)
 根据以下医疗标准进行危害分析：
 IEC 62304

 ISO 14971:2007， 2007-10-01修正版（医疗设备 - 风险管理在医疗设备上的应用）

ISO 26262功能安全插件，与Cameo安全性可靠性分析插件一起使用，支持ISO 26262（道路车辆-功能安
全）标准。

本附录描述了如何使用支持FMEA分析的Cameo安全性和可靠性分析插件来丰富使用MagicGrid方法创建的
具有安全性和可靠性信息的系统模型。

下图A-1描述了通用的安全性和可靠性分析流程。可靠性和安全性分析是基于系统模型（涉众要求、系统
行为和结构部件）进行的，并被识别为单独项，当使用FMEA方法时，这些项被称为FMEA项。然后对这些项
进行排列，并通过引入新的安全性和可靠性需求来解决最关键的问题。随后，通过引入新的行为和改变系统结
构来支持已识别的安全性和可靠性需求，可以对系统的架构和设计进行更改。对系统模型修改需要进行相同的
安全性和可靠性评估。

安全性和可靠性分析可以由安全工程师或系统工程师负责执行。

图A-1
A.1 涉众需要: 安全性和可靠性需求
由涉众方识别出来的安全性和可靠性需求可以捕获为SysML需求。关于如何在需求表中捕获涉众要求的更
多信息，请参阅1.1.1章节。使用SysML需求捕获安全性和可靠性需求不需要SysML语言的任何扩展；一个具有
相应名称的分组需求就足够了。如下图A-2所示，SN-1.3 Safety & Reliability 作为来自涉众方的安全性与可靠性
要求的容器。

图A-2

A.2 黑盒视图中的概念FMEA
黑盒视角应包含基于FMEA方法的定性概念组件和功能失效模式分析。概念FMEA的目的是采取措施消除
或减少源自黑盒视角的失效。失效的减少是通过引入新的安全和可靠性需求来实现的，这是概念FMEA分析的
结果，然后通过下游的变化来提炼和满足这些需求。

传统的FMEA是在基于类似电子表格的环境中完成的，现在使用安全和可靠性分析插件支持作为管理
FMEA的主要方式。表中的每一行都称为FMEA项，它引用（或语义分组）经典FMEA元素，如失效原因、失效
模式、局部和最终影响以及缓解。

黑盒概念FMEA表包含以下列,如表A-1：

表A-1

列名 目的
Id 分配给每个FMEA项的唯一ID。
名字 Name 对用户友好的FMEA项名称。
项 Item 被分析的部分与特定的FMEA项相关。

失效原因 表示导致失效模式的架构缺陷的元素。一个FMEA项，例如，FMEA表的单行，可以
Cause of Failure 有多个失效原因。
失效模式 Failure Mode 描述系统可能无法满足设计意图的特定模式的元素。
 局部失效影响 描述失效模式对所考虑的系统元素影响的元素。一个FMEA项目，例如, FMEA表的单
Local Effect of Failure 行，可能有多个局部失效影响。
失效的最终影响 描述失效模式对最终用户或环境影响的元素。您可以为单个FMEA项指定多个失效的
Final Effect of Failure 最终影响值。

提炼 FMEA项提炼的涉众方需求的引用。
Refine
缓解 Mitigation 对缓解失效的需求的引用。

下图A-3显示了安全性和可靠性分析插件支持的FMEA表，它代表了概念FMEA。Item项是:VCCU单元，这
是正在建模的系统。每一个FMEA项都从涉众方需求中提炼出安全性和可靠性要求。例如，F-2 FMEA项提炼了
SN-1.3.2.2 Biofouling 生物污染涉众方需求。提炼的FMEA项确定了:VCCU单元如何无法满足汽车乘客不暴露于气
候控制单元中积累的任何有毒物质的需求：

 首先，确定失效的潜在原因；在该例中，失效原因是乘客直接接触到积聚在气候控制装置中的有
毒物质。
 然后，识别出失效模式；在该例中，失效模式是乘客无法操作:VCCU单元（因为该单元产生有毒
物质）。
 失效的局部和最终影响要么直接输入，要么从库中重用，因为它们往往会在产品线或不同产品之
间重复出现。
 最后，分析出新的安全或可靠性需求；在该例中是要求安装空气过滤器，以防止有毒物质在气候
控制装置单元中积聚。

图A-3

如前所述，FMEA项可以有一个名字。名字是一个概括句，传达了在具体的FMEA项上分析的本质。FMEA
项名的目的是优化模型中FMEA项的搜索，促进FMEA项的重用，方便FMEA项的管理。

如果在创建的系统中任何原因都会引起失效模式，并且引入缓解安全或可靠性需求是重要的，则可以根本
不指定原因（见F-1 FMEA项）。然后，需要将新引入的安全性和可靠性需求和黑盒、白盒、LSA、子系统或组
件视图中新创建或更新的行为或结构模型关联。

安全性和可靠性分析工作流是重复的，因此源自黑盒视角的失效可以在整个SoI中产生共鸣，从问题域到实
现域。为了捕获失效场景，使用关系图Relation Map diagram描述FMEA因果链。例如，Biofouling生物污垢关系
图 （见下图A-4）描述了从SN-1.3.2.2 Biofouling生物污垢涉众需求开始到FMEA分析过程中产生的模型元素和
FMEA项的关系。
 图A-4

在FMEA分析过程中，每当识别出导致意外场景的失效影响（系统架构中新引入的变更），这个关系图就
会逐渐扩展。

A.3 黑盒视图中的功能FMEA
功能FMEA着重于系统的行为，而不是提炼涉众方的需求。与概念FMEA表相比，黑盒功能FMEA表包含以
下额外的列,如表A-2：

表A-2

列名 目的
子系统 连接分配给项列中定义的部件的活动的流入和/或流出流。
源（派生） 流的源动作 Source action of flow。
目标（派生） 流的目标动作 target action of flow。

黑盒功能FMEA如下图所示。可以看到，项列仍然引用 :VCCU，就像在概念FMEA中一样。但是，子系统
列表示分析潜在失效的对象流。此分析源是为用例指定的活动图（参见1.1.3用例章节）。下面的功能FMEA表
中显示了用例部分中的提供舒适温度Provide Comfortable Temperature活动。当执行一个功能FMEA，所有传入
和传出代表:VCCU泳道的流，以及VCCU所执行的行动被用于潜在的失效的分析（例如，如果其中一个流入给
定活动的输入流并没有产生预期的输出，系统如何执行？）。

在这个特定的示例中，我们只关注与Check System和Reach Desired Temperature 动作（action）相关的对象

流，但同样也可以对控制流和动作进行处理。在FMEA表下展示的活动图中，被分析的流用蓝色的颜色编码。
在功能性FMEA表中Source和Target列表示这些流连接（flow connect）的动作。Refines列表示被分析的用例。缓
解“Migration”列与概念FMEA表中描述的目的一样,如图A-5。

图A-5

F-7 FMEA项通过评估当执行系统试图达到所需温度功能时未能接收到空气的可能影响，分析从提供空气
Provide Air动作到达到所需温度Reach Desired Temperature动作的对象流。在FMEA表中，VCCU不能从客舱吸空
气VCCU cannot suck air from cabin作为原因填在失效原因cause of Failure列中。因此，出现功能丧失Loss of
function的失效模式，导致局部影响是VCCU not operational，最终影响乘客过热或过冷。为了减轻这种风险，产
生了在故障安全模式下自动关闭系统的新的安全需求（见需求6）。在概念FMEA中，新引入的需求要么在问题
域层解决，要么在下游解决。其他功能FMEA项也以类似的方式进行了分析，参考F-7 FMEA项。
 为了演示安全性和可靠性要求是如何在该层或下游处理的，让我们看一下新引入的安全需求 - 提供跛行模
式Provide Limp Mode。原始MagicGrid下名为提供舒适温度Provide Comfortable Temperature的活动图如图A-6所
示。

图A-6

为了处理提供跛行模式Provide Limp Mode的这个安全需求，会产生新的:VCCU功能，称为启动气候控制在

后馈模式@72F（Start Climate Control Fallback mode @72F）。只要:VCCU还没有接受启动命令或接收到所需的
温度，这种模式下将提供所需的默认72°F温度,如图A-7。
 图A-7

在功能FMEA表中被分析的流，用蓝色 表示，对应功能FMEA表下的subsystem

根据功能FMEA分析新增的元素，用粉色高亮显示。

A.4 功能FMEA覆盖分析
重要的是用功能FMEA覆盖所有传入和传出到:VCCU单元的流；因此，应该建立一个追溯矩阵（见下图A-
8）。在这个矩阵中，可以创建subystem relation关系，也可以清楚地看到FMEA项还需要覆盖多少流。

创建SYSML dependency Matrix，显示被FMEA项覆盖的数据流，选择关系是Subsystem Relation。

 图A-8

A.5 在问题域处理安全性和可靠性需求
所有新引入的安全性和可靠性需求都包含在一个包中（见下图A-9）。

图A-9
 下图A-10列出了安全性和可靠性需求。需求8和需求9是在白盒层FMEA分析的结果（参见下面的章节）。

图A-10

从问题声明到组件设计，安全性和可靠性需求可以在所有层级进行处理。例如，安全需求1 Use Flame -

Resistant Materials （使用阻燃材料）不能在问题层解决，因为该层级不包含实际的系统设计。这个需求可以在逻
辑子系统层解决，因为系统设计中使用的特定材料在这一层是已知的。另一个例子是需求2 Air Filters 空气过滤
器，它可以在白盒层和下游处理,如图A-11。
 图A-11

下面描述了 （在白盒视角中）MagicGrid开始 Reach Desired Temperature活动下的活动图。空气直接流向从

舱内抽气的动作。

为满足2 Air Filters 过滤网的安全需求，新增的:Filtering过滤网逻辑子系统需增加过滤网功能，对应Fliter Air

过滤网气流进入: Cooling制冷子系统和: Heating制热子系统（如下图A-12所示）。

图A-12

创建从Filter Air action过滤空气动作和:Filtering过滤子系统到2 Air Filters空气过滤器安全需求的满足关系。

在对模型进行上述修改后，生物污垢Biofouling关系图将被更新，新引入满足2 Air Filters空气过滤

器安全需求的模型元素,如图A-13。

图A-13
 让我们看看另一个例子，其中安全需求 5 Shut Down the System in Fail-Safe Manner when Unable to Read or
Accept Ambient Temperature 在无法读取或接受环境温度时，以故障安全方式关闭系统被处理。名为故障安全Fail Safe的
新功能被分配给:Processing子系统，并且故障安全Fail Safe功能将Fail Safe信号发送到SoI的外部。Fail Safe信号是CU
Command信号的一个子类，可以通过现有的接口传递，如下图A-15所示

图A-14

图A-15
A.5.1 白盒视图下的FMEA

在白盒层执行功能和概念FMEA就像在黑盒层做的一样，需要检查所有功能、他们的传入和传出流和概念
子系统，定义新概念子系统和功能满足安全性和可靠性的需求。例如:过滤子系统必须经过概念子系统FMEA分
析(见下图A-16)。作为这个分析的结果，需要增加新的安全特性来解决:过滤概念子系统的安全性(因为它可能导
致安全问题)。为此，创建了两个新的安全需求8和9。

图A-16

例如，F-9 FMEA项分析:Filtering过滤子系统怎样引起失效不能保护乘客免受接触可能积聚在:VCCU的有毒
物质，由于外部因素，如灰尘、树叶、垃圾堵塞过滤器从而可能导致死于火或烟雾中毒。结果，产生了失效模
式Reduction of function，这意味着:Filtering过滤子系统过滤空气的能力降低，导致局部影响:VCCU（过载或着
火），最后造成对乘客的影响，如被烧伤，被毒烟熏，或开车时发生事故。为了降低这些风险，引入一个新的安
全需求来检测:Filtering 过滤子系统中的任何阻塞情况。

新引入的安全需求需要通过修改系统模型来满足。下图A-17描述了Test Air Flow测试气流功能，通过测试

传入气流来响应这两个需求。该活动图还包含了在黑盒层引入的其他安全需求，这些需求由对应的功能来处理
和满足。
 图1-17

在检查了:Filtering 过滤子系统并更新模型之后发现了其它失效。这些可能的失效会影响缓解风险了的较低
层系统元素和模型元素。下图展示了:Filtering过滤子系统经过概念子系统FMEA分析后的因果链,如图A-18：

图A-18

A.5.2 解决LSA中的安全性和可靠性问题

在解决方案层，安全性和可靠性需求派生自问题域。下图A-19/20显示了一个新的安全性和可靠性分组需
求，内含有安全性和可靠性需求。
 图A-19

图A-20

这些安全性和可靠性需求起源于问题域，如下图A-21System Requirements to Stakeholder needs系统需求

到涉众方需要的派生需求矩阵。
 图A-21

这些需求，就像问题领域中的安全性和可靠性需求一样，需要通过更新模型来满足。以SR-1.12.7 Air
Filters 过滤网需求为例，需要在LSA层上创建一个Filtering System块，包含相应的端口和部件（见下图A-
22）。

使用«abstraction»关系来声明LSA中的Filtering System过滤系统派生自问题域分析模型中称为Filtering的概
念子系统。下图A-21LAS到问题域矩阵LSA to Problem Domain Matrix中展现了这种关系。

图A-21
 图A-22

VCCS的总能耗等于其所有子系统的能耗之和，这意味着总能耗的表达式还需要加上过滤系统的能耗（参见
2.1.4 系统参数章节）。约束表达式定义如下：

totalEnergyCons = energycon1 + energycon2 + energycon3 + energycon4 + energycon5

其中energycon5 约束参数表示过滤系统所消耗的能量。需要为过滤系统创建energyCons值属性，并为Total
Energy Consumption约束块指定一个额外的energycon5约束参数。定义之后，需要绑定之前值属性和约束参数，
以使约束表达式能够在更新后的模型上执行计算,如图A-23。

图A-23
完成这些修改之后，就该指定过滤系统的解决方案架构，并重新查看其他VCCS子系统，以确保系统级的
完整性。

A.6 子系统层解决安全性和可靠性问题

A.6.1制冷子系统层

正如黑盒视角部分的功能FMEA中所提到的，新引入的需求可以在问题域层或下游处理。SR-1.12.1 Use
Flame-Resistant Materials 使用阻燃材料安全需求是早期在问题域层提出的需求之一，但由于SoI设计中缺乏特定
材料信息而无法解决。然而，Cooling子系统架构层对材料信息描述非常详细，能够满足并响应这一需求。

Cooling子系统已经指定了制冷剂refrigerant的交互关系。制冷剂的物理条件已经被捕获（见下图A-24）。
然而，SR-1.12.1 Use Flame-Resistant Materials 使用火焰-耐腐蚀材料安全需求介绍了危险材料识别系（HMIS）
的易燃性等级，所使用的材料（在这种情况下为制冷剂）应符合该等级。
 图A-24

为了满足SR-1.12.1 1 Use Flame-Resistant Materials使用阻燃材料的安全需求，定义了额外的Cooling子系

统物理要求，称为SSR-1.1.4 Use Flame-Resistant Refrigerant 使用阻燃制冷剂,如图A-25。

图A-25

为了满足这个安全需求，需要对制冷剂类型等级进行修改。因此，具体R-134a 制冷剂类型可以定义为
Refrigerant制冷剂的每个物理条件子类的一个块。下图A-26包含了执行的更改，并说明了如何处理SSR-1.1.4
Use Flame-Resistant Materials使用阻燃材料的需求。
 图A-26

A.6.2 过滤子系统层

在分析了FMEA并且识别出新的:Filtering过滤子系统之后，工程团队必须开始在逻辑子系统架构（LSSA）
上工作（参见2.2构建子系统的逻辑结构章节）。正如在构建子系统的逻辑架构一节中所指出的，每个逻辑子系
统的LSSA应该存储在一个单独的模型中。过滤系统也可以有自己的FMEA分析。

A.6.2.1 子系统的需求

让我们假设负责过滤系统解决方案架构的工程团队从系统架构师那里收到了以下子系统需求,如图A-27:

图A-27

矩阵和图可以用来建立和评审: Filtering过滤子系统需求和系统需求间的交叉（cross-cutting）关系。下面的
矩阵捕获了更具体信息: Filtering过滤子系统需求派生自哪些系统需求,如图A-28。
 图A-28

可以创建一个关系图 Relation map，其中蓝色箭头表示来自不同域需求之间的关系，红色箭头表示失效和

缓解失效的需求之间的关系，青色箭头表示为提炼来自不同域的需求而创建的失效之间的提炼关系。所有这些
关系说明了FMEA因果链，从最初的涉众方需求一直到根据FMEA分析做出的满足安全和可靠性决策而产生的
过滤系统需求。下图显示了从SN-1.3.2.2 Biofouling 生物污染利益相关者需求到过滤系统的关系图的一部分,如图
A-29。

图A-29

A.6.2.2 子系统结构

可以确定过滤系统的内部结构，然后指定其组件之间的操作，以及过滤系统的逻辑组件如何与SoI的其他子
系统交互。详细步骤请参考子系统结构章节。

捕获过滤系统的内部组件

根据子系统需求中的定义，并根据工程团队经验，过滤系统应由以下几个部分组成：

 风扇
 膜式颗粒过滤器
 压力传感器
 带阈值的电压比较器
 这些可以指定为过滤系统块的部件属性。使用SysML块定义图（bdd），如下图A-30所示。

图A-30

应该注意的是，根据LSA SSR 3.2.1Filter Status过滤器状态组需求，系统需要不断地获取过滤器状态。为了

能够安全地运行，过滤系统应监测过滤器是否撕裂、堵塞，以及堵塞的严重程度。因此，需要在空气通过过滤
器之前和之后安装压力传感器。然后通过三个专门的电压比较器对比压力信息以确定过滤器的状态。

指定过滤系统内部交互

在该步骤中，我们着重于指定过滤系统组件与子系统外部之间的交互。为了指定子系统组件之间的交互，使
用SysML内部块图（ibd），如下图A-31所示。为过滤系统架构块Filtering System Architeture block创建了一个ibd。
正如子系统结构教程第5步所建议的那样，首先，我们开始通过这些继承的端口指定过滤系统和外部交互：

一个是让舱内空气及其压力流进过滤系统，并被 : Membrane Type Particle Fileter膜式颗粒过滤器及before :

P Pressure Sensor压力传感器组件使用/消费。
第二个是让过滤后的机舱空气从过滤系统的风扇:Fan流出。
第三个是专门控制风扇的，传递Fan1, Fan2, Fan3, Fan4和Stop信号到: Fan风扇。
最后一个用于从该子系统的电压比较器中发出信号来指示滤波系统的状态。

图A-31
在通过继承端口捕获过滤系统盒外部交互之后，下一步是继续过滤系统内部逻辑组件之间的交互。要了解
更多细节，请参阅2.2.2教程的步骤6。
 在兼容端口之间创建连接器以传递以下交互,如图A-32：

Before : Pressure Sensor前压力传感器将空气压力转换成与空气压力成比例的电信号（电压）。

: Membrane Type Particle Fileter滤膜式颗粒过滤器提供过滤空气到风机: Fan，过滤空气压力到after :
Pressure Sensor 后压力传感器。
After : Pressure Sensor后压力传感器消耗过滤的空气压力，产生与过滤后的空气压力成比例的电压信号。
过滤后的空气进入风机: Fan，以便循环出系统。
压力传感器产生的电压信号到clogModerate: VoltageComparatorWithThreshold, clogHigh:
VoltageComparatorWithThreshold及rip: VoltageComparatorWithThreshold组件，其中空气的电压信号与当前
的电压参考进行比较，称为过滤前后的阈值threshold。

图A-32

在确定组件和SoI外部之间的交互之后，下一步是更新 Filtering System Structure bdd图，显示捕获

的过滤系统架构及其组件上新的代理端口（见下图A-33）。
 图A-33

A.6.2.3子系统的行为

识别和捕获了过滤系统架构之后，下一步是继续进行行为架构建模。可用SysML状态机图、活动图或时序
图捕获过滤系统的行为。

捕获过滤系统的状态

使用了SysML状态机图捕获过滤系统的主要状态，如下图冷却子系统状态机图。状态之间的转换是由信号事
件触发的，例如在Off和On状态之间的Start信号，或在initialize, Off和Operating状态之间的SysNotOK和SysOK信
号。

假设负责过滤系统解决方案架构的工程团队确定了以下状态集，在VCCS运行期间过滤系统可以存在：

1. 关机状态（Off）

2. 开机状态（On）

a. 初始化（Initializing）

b. 运行（Operating）
 以下规则描述了这些状态之间的转换,如图A-34：

 子系统的初始状态是Off。
 子系统可以从Off状态切换到On状态，然后再回来。
 当处于On状态时，子系统首先进入Initializing子状态。
 从初始化Initializing状态，子系统可以切换到Operation操作状态或Off关机状态。

图A-34

与制冷系统的情况一样，这些信号也来自滤波系统外部。CP系统发送这些信号来调用系统。因此，必须指
定该子系统对Start信号的反应。作为响应，过滤系统发送带Status属性的filterStatus过滤状态信号，如果已经准
备好启动，则Status属性值设置为filterOK，如果还没有准备好，则发送filterStatusCloggedM、
filterStatusCloggedS或filterRipped中的一个值。下图描述了通过p1代理端口发送响应信号,如图A-35。

filterStatusCloggedM代表过滤器状态为中度阻塞，filterStatusCloggedS代表过滤器状态为严重阻塞。
 图A-35

膜粒子过滤器是一种物理上可能损坏并导致过滤系统无法启动的部件。因此，膜粒子过滤器可以有自己的
状态机来表示其可能的状态，例如：
1) 正常过滤
2) 部分堵塞
3) 严重的堵塞
4) 破裂
这些可能由环境条件触发，如在多灰尘环境下延长作业时间ProlongedOperationInDustyEnvironments，大进
气量LargeDebreeInAirIntake或过度振动ExcessVibration，在Membrane Type Particle Filter States状态图下它们被
描述为signal event转换信号事件。膜粒问题消除后，即可恢复正常工作。为此，将创建Servcing信号表示部件已

修复,如图A-35。
 图A-36

为了满足SSR-3.2.2 Fan States风扇状态分组需求，为过滤系统的风扇组件创建了另一个状态机（见下图A-

37）。风扇状态图描述了风扇在系统运行过程中可能存在的供电状态，如：

1) Off
2) Blowing1
3) Blowing2
4) Blowing3
5) Blowing4
这些状态由信号事件Fan1、Fan2、Fan3和Fan4触发，改变风扇的功率。风扇也可以在任何时候关机，不管
是否在吹风状态。停止信号Stop用于切换到该状态。CP系统控制风机；因此，所有的触发信号都是从CP系统发
出的。

吹风状态名上的数字表示风机的功率，数值越大表示风机的功率越强。以类似的方式为每个触发这些
状态的信号命名。
 图A-37

指定状态内部行为

正如子系统行为教程的第5步所提到的，SoI的每个逻辑子系统都可以执行与一个或多个状态相关的一个或
多个行为。过滤系统的内部行为使用SysML活动图描述。为了表示过滤系统执行自检并发送带有属性值的
filterStatus信号，将创建一个活动图，该活动图被指定为Initializing初始化状态的do行为。

为了表明CP系统评估所有子系统的状态并发送SysOk和SysNotOK信号，应该更新CP System Status 状态机

图。下图A-38是Filtering System States状态机图。

图A-38

变更时必须与其他工程团队协商沟通，以确保系统级的完整性。

A.6.2.4子系统参数

子系统参数用于捕获可度量的过滤逻辑子系统的定量特征。用于计算逻辑子系统的MoE，以满足非功能性
定量子系统的需求。利用建模工具提供的功能，执行模型并使用数学表达式计算MoE，以确定定量需求是否得
到满足。（详情请参阅子系统参数章节）
 指定子系统参数计算过滤系统总能耗

根据子系统需求规格和在问题域和下游捕获识别出来的过滤系统MoE，需要建模计算过滤系统消耗的总能
量的公式。创建名为System Parameters for Total Energy Consumption for Filtering的SysML块定义图（bdd），用
于定义totalenergyconfilter值属性所需的约束表达式和参数。

下图A-39所示的Total Energy Consumption for Filtering滤波总能耗约束块有7个输入参数，每个输入参数代

表滤波系统单个组件的能耗，因此需要在模型中定义7个组件参数。并为代表过滤系统组件的每个块指定值属
性。

图A-39
假设过滤系统的总能量消耗等于其所有组件的能量消耗之和。约束表达式定义如下:

totalEnergyCons = energycon1 + energycon2 + energycon3 + energycon4 + energycon5 + energycon6 + energycon7

式中约束参数如下：

1) totalEnergyCons表示过滤系统消耗的总能量
2) energycon1表示风扇所消耗的能量
3) energycon2表示膜式颗粒过滤器Membrane Type Particle Filter所消耗的能量
4) energycon3表示before : Pressure Sensor前压力传感器所消耗的能量
5) energycon4表示after: Pressure Sensor 后压力传感器所消耗的能量
6) energycon5表示 rip:VoltageComparatorWithThreshold所消耗的能量
7) energycon6表示clogHigh: VoltageComparatorWithThreshold所消耗的能量
8) energycon7表示clogModerate: VoltageComparatorWithThreshold所消耗的能量
 需要与模型中指定的相应值属性绑定。为此，创建名为Total Energy Consumption for Filtering的SysML参
数图，如下图A-40所示。因为过滤子系统的最大能耗需求为The Filtering System shall consume maximum 1.2
kWh。为了满足这个需求，创建约束块Max Energy Consumption for Filtering 并将其与totalenergyconfilter值绑定。

图A-40
这是一个简单的传感器模型，将0-2大气压（0-200000 Pa）范围的输入压力转换为1-10V范围的电压输出信
号，如下参数图A-41所示。

图A-41
下图A-42展示了与 :Fan风机状态和输入压力相关的风机能耗简化模型，而输入压力又取决于膜过滤器渗透
性中的压降。能耗是37瓦特乘以:Fan风扇吹力强度（Blowing1-Blowing4）乘以输入压降相关的线性校正因子。

图A-42
 这是一个简单的根据过滤器的状态（堵塞/撕裂/正常），通过过滤膜压降搭建过滤器模型。压降会影响下
游系统，如风机的能耗,如图A-43。

图A-43
这是一个带有阈值的电压比较器模型。当input1的电压大于input2 + threshold时，触发一个输出信号signal,
如图A-44。

图A-44

下一步是建立从过滤系统LSSA模型元素到子系统需求之间的追溯关系。
A.6.2.5 追溯到子系统需求

根据追溯到子系统需求章节，为了实现子系统需求，需要定义交叉关系（例如满足satesfy关系）。正如您
在下图A-45中看到的，名为LSSA to Subsystem Requirements 满足需求矩阵（Satisfy requirement matrix）已经完
成，这意味着所有子系统需求都由一个或多个架构元素覆盖并满足。

图A-45

A.7 子系统级的逻辑子系统FMEA
正如黑盒视角部分的概念FMEA中所提到的，安全性和可靠性分析工作流是重复的，因此也可以对VCCS的
逻辑组件进行安全性和可靠性分析。下图A-46展示了对过滤系统进行的逻辑子系统FMEA和安全性和可靠性分
析，重点放在before : Pressure Sensor前压力传感器和after : Pressure Sensor后压力传感器组件。压力传感器必须
进行安全性和可靠性分析，因为过滤系统在失效时可能无法检测到故障，从而将无法防止系统出现安全问题。

图A-46

例如，因为F-11 FMEA项分析before : Pressure Sensor前压力传感器如何无法保护乘客免受事故，比如火灾

烧伤或由于VCCU环境下造成中毒，再比如堵塞过滤器或VCCU着火，这些情况被称为局部失效影响。这些情
况可能是由before : Pressure Sensor前压力传感器的断线引起的，这将导致无法提供有关空气压力的数据给其他
子系统部件。从而出现失效模式 –Loss of Function，这意味着失去了确定pf: Membrane Particle Filter膜粒子过滤
器状态的能力。为了降低风险，定义了一个新的安全需求来处理未知的过滤器状态（参见上面表中 SSR-4 Handle
Unknown Filter State处理未知过滤器状态需求）。其他逻辑子系统FMEA项以与F-11 FMEA项相同的方式进行分
析。

与问题域的概念FMEA表相比，过滤系统逻辑子系统FMEA表包含以下额外的列,如表A-3：

表A-3

列名 目的
分类 按照系统的某些方面对失效进行分类（FMEA项）。

新识别的安全需求 SSR-4 Handle Unknown Filter State处理未知过滤器状态（如下图A-47所示）可以在过

滤系统中处理。

图A-47

A.8 在配置层处理安全性和可靠性问题
让我们跳到最后一个阶段：根据安全可靠性分析引起的变更调整配置模型。过滤子系统架构已经设计完
成，因此应该与其他子系统集成，并确保成功交互。所以，需要指定SoI的特定配置中的交互来验证接口的兼容
性,如图A-48。

图A-48

如您所见，没有识别出不兼容的接口，我们可以说过滤系统可以在VCCS中成功通信。
附录B: 从体系架构到系统架构

作者Aistė Aleksandravičienė, Gintarė Kriščiūnienė, Aurelijus Morkevičius, PhD

基于模型的工程实践最近已经演化超越了单个系统工程实践。在这个创新的时代，系统思维可以应用于系
统之系统（SoS）环境中，以应对新的挑战，如自动交通控制、工业4.0、物联网等。

SoS是SoI，其组成元素是系统本身；多个组织参与了SoS体系的设计、维护和运行。

因此，在设计SoS时，为多个组织建立一个数字环境进行交互是很重要的，特别是在从SoS过渡到系统架构
（SA)）时（见下图B-1）。在大多数情况下，这是合同甲方和承包商或原始设备制造商（OEM）和供应商之间
的协同。本附录提供了一个详细的方法，确保在基于模型的环境中保持从SoS到SA的数字连续性。

图B-1

B.1 体系工程
可以使用统一架构框架®(UAF®)v1.1捕获SoS的知识，其布局（也称为UAF网格）由行和列组成，其中行
表示域，列表示模型类型。行和列的交集称为视图规范或仅仅是一个视点。

在本附录中，我们只关注UAF资源域，它捕获逻辑SoS结构，以及它们如何服务以实现体系能力。但是，
UAF没有指定为单个系统定义架构的方法。所以，我们使用基于SysML语言的MagicGrid方法论,如图B-2。
 图B-2

B.2 从体系到系统架构转换
UAF资源域捕获不同资源，包括人力资源和系统是如何交互以满足运行需求并实现SoS能力。资源存放于
称为能力配置的逻辑容器中。每个能力配置都可以追溯到其在特定时间内要实现的能力。在不同的时间段可能
有多个功能配置实现相同的能力。同时，可能有几个可选的能力配置。确定使用哪个版本的能力配置作为分析
SoI系统上下文的输入是很重要的。

B.2.1 MagicGrid : 系统环境上下文

系统上下文或运行环境决定SoI的外部视角。因此，特定系统环境中的元素集包括SoI本身和外部系统（自
然的或人工的），以及与SoI交互交换数据、物质、能量或人力资源的用户（人、组织）。

正如MagicGrid所定义的，系统上下文在模型中被定义为SysML块。SoI、外部系统和假定的用户也被定义
为SysML块。组合关联composite association关系使建模人员能够将它们与特定的系统上下文关联起来，而
SysML内部块图提供了显示系统上下文的参与者及其交互的机制。
 让我们看看如何从SoS模型中获取单个SoI的系统上下文。这里，资源结构Resources Structure和资源关联
Resources Connectivity视角充当了主要信息来源（见下图B-3）。

图B-3

SoI的系统上下文最初在SoS (UAF)模型中定义为Resources Structure资源结构视角，它捕获SoI以及相同体系

SoS下的其他系统。SysML模型中的系统上下文视图可以被认为是资源结构视角的一个子集（参见下图B-4）。

图B-4

因此，在系统架构SA (SysML) 模型中捕获特定SoI的系统上下文的块将成为体系SoS (UAF)模型中的能力配

置的子类。因此，该块继承了相关能力配置的所有组成。SoI的系统上下文的组成部分用SysML块重定义
（redefine），SysML块捕获了SysML模型中的SoI、参与者或外部系统 （参见下图B-5）。组成的重定义对于进
一步建模是必要的：这使建模人员能够在不修改体系SoS (UAF)模型的情况下更新系统上下文信息。例如，您可
能需要添加新的端口或比在体系SoS (UAF)模型中定义的端口更具体的端口。
 图B-5

如果在体系SoS（UAF）模型的资源关联视角中定义了端口/接口和交互，那么它们也会显示在系统架构SA
(SysML)模型中。如下图所示，该任务包括：(1)创建相关的SysML接口块；(2)创建SysML接口块到UAF资源接
口间的抽象关系；(3)使用SysML代理端口重定义UAF资源端口；(4)使用SysML连接器重定义UAF资源连接器。
捕获流经资源连接器的项的UAF元素（例如数据元素）可以在SysML模型中重用，除非它需要更具体的信息。
这里，将创建一个新的SysML元素(5)，并指定从它指向UAF模型中相关元素的抽象关系(6) ,如图B-6。

图B-6

B.2.2 MagicGrid : 涉众方要求

涉众方要求可能包括主要用户要求、与系统相关的政府法规、行业标准、政策、流程、内部指南等。可以
将它们捕获为SysML需求，这使建模人员能够将文本信息存储在SysML模型中。涉众方要求可以根据其来源进
行分组，并将其分为功能性需求和非功能性需求。可以使用SysML需求图或需求表来显示它们的层级结构。

涉众方要求可以通过采访利益相关者，给他们问卷，在小组中讨论需求，或者研究以不同格式编写的文档
来获取。除了这些信息源，体系SoS的UAF模型也可以作为涉众方要求的输入。更准确地说，资源流程
Resource Processes、资源状态Resource States和资源交互场景视角Resource Interaction Scenarios Viewpoints可用于
识别功能性涉众方要求，而资源度量视角可用于识别非功能性需求（参见下图B-7）。
 图B-7

在资源流程视角中定义的功能子集被分配（使用Is Capable To Perform关系，如下图所示）到SysML模型中

的SoI系统，形成SoI系统一个或多个功能性涉众要求。这也适用于分配给UAF模型中相关系统的状态和交互的
情况。

当功能性涉众要求被捕获时，SysML可以创建从描述涉众方要求的SysML需求到UAF模型中相关功能、状
态或交互的提炼关系 （见下图）。

体系UAF模型中系统所拥有的度量转化为SYSML模型中SoI系统的一个或多个非功能性定量涉众要求。当
捕获到这些数据时，SysML可以创建这些非功能性定量需求到UAF模型中的相关度量间的细化（refine）关系
（见下图B-8）。

当在SysML模型中捕获SoI的用例和MoE时，SysML提炼关系可以帮助传达哪些涉众方需要这些用例和MoE
来提炼。

图B-8

后记
感谢抽时间阅读MagicGrid Bok第二版，我们欢迎您对该书提供反馈和意见。在发表第三版之前您的建议和反馈
都会被考虑。此外，您可以注册为MagicGrid BoK的下一个版本的审稿人，如果感兴趣请发邮件至
NoMagic.MagicGrid@3ds.com
术语表
动作 Action

可以捕获活动中系统功能的基本单元的SysML元素。它表示在系统运行期间活动执行时将发生的某种形式的处
理或转换。动作表示为圆角矩形，动作名称以字符串的形式显示在矩形内。

活动 Activity

一种行为SysML元素类型，它可以包含一组模型元素，比如操作和流，以及呈现这些元素的活动图。

活动图 Activity diagram

一类SysML行为图，可用于描述控制流或操作之间的输入和输出流。活动图可以用于规格化预期系统功能的黑
盒和白盒场景，并与状态机图组合使用来设计系统行为。

参与者 Actor

一个SysML元素，当它与特定上下文中目标系统交互时，它可以捕获由一个人、一个组织或另一个系统所扮演
的角色。然而，MagicGrid方法建议使用块而不是参与者来描述这些概念，在用例章节中描述了原因。

关联 Association

一种SysML关系类型，它使您能够指定哪些参与者与特定系统上下文中目标系统交互，以调用或参与用例。这
种关联的符号是实线表示。

绑定连接器 Binding Connector

一种特殊类型的SysML连接器，代表参数图中的约束参数和值属性之间的相等关系，为了表示约束参数从该值
属性接收值。绑定连接器的符号是实线。

黑盒/白盒 Black box/white box

黑盒表示系统的外部视图。在黑盒视角的系统分析中，根据系统的输入和输出来观察它，而不需要了解它的内
部结构和行为。

白盒表示系统的内部视图。从白盒的角度进行系统分析时，对系统进行功能分解，以确定系统的功能块，也称
为系统的逻辑子系统或组件。

块 Block

定义的SysML元素，它可以捕获系统结构的基本单元。一个块用一个矩形表示，在名称区域上显示名为«block»
的stereotype块。
块定义图 (bdd)

一种结构化SysML图，可用于定义块的特性和块之间的关系，如关联、泛化和依赖关系。它根据属性和操作以
及系统层次结构或系统分类树等关系来捕获块的定义。块定义图可用于规格化系统或子系统的结构，并定义该
系统或子系统的接口和约束。

调用行为动作 Call Behavior action

一种特殊类型的SysML操作，它可以调用另一种行为：活动、状态机或交互。调用行为操作使您能够将较高级
别的行为分解为一组较低级别的行为。

组合关联/定向组合 Composite association /Directed Composition

一种特殊类型的SysML关联关系，它允许您指定一个块是另一个块的组成部分。组合关联的示为两个块之间用
实线连接，在实线复合端为一个黑色的菱形，在实线部分端为一个开放的箭头。绘制块之间的组合关联将为出
现在关系的黑色菱形端上的块创建一个部件属性；部件属性可以有一个名称，并由出现在组合关联的箭头端上
的块定义其类型。

组件 Component

系统结构的基本对象。组件通常被分组成系统的子系统；通过分解这些子系统来识别组件。组件可以被捕获为
模型中的一个块。

连接器 Connector

一种SysML关系，用于表示ibd中两个部件属性之间的通信。可以通过各种端口（只要这些端口是兼容的）在部
件属性之间建立连接；例如，通过代理端口连接的两个部件属性传递通过兼容的代理端口在连接上交换物质、
能量或数据。绑定连接器的符号使用实线表示。

约束块 Constraint block

定义的SysML元素，它可以捕获约束表达式（方程或不等式）。约束表达式使您能够约束块的值属性。约束表
达式的变量称为约束参数。这些约束参数接收被约束的值属性值。约束块的表示法与块的表示法相同，但是在
元素的名称之前有«constraint»构造类型。

约束参数 Constraint parameter

出现在约束块的约束表达式中的变量。它被捕获为模型中的约束块的一个属性，并在该约束块的参数隔间
（compartment）中用一个字符串表示。
约束属性 Constraint property

约束块在某个块环境中的用法，或者换句话说，由模型中某处定义的类别为约束块的块的属性。它可以表示为
bdd中该块的约束隔间中的字符串，或者表示为参数图中的圆角矩形。在这两种情况下，约束属性的名称都显
示为字符串，其后跟冒号和该属性类别的约束块的名称；例如，质量：总质量。

控制流 Control flow

一对动作action之间的一种SysML关系。控制流使您能够表示在关联活动中动作执行的顺序。控制流表示为带有
开放箭头的虚线。

决策/合并 Decision/Merge

决策节点标志着活动中可选流的开始。它被表示为一个空心菱形，并且必须有一个输入流和两个或多个输出
流。

合并节点标志着活动中可选流的结束。它被表示为一个空心菱形，并且必须有两个或多个流入流和一个流出
流。

交换项 Exchange item

定义一种可以在系统内两个结构对象之间流动的物质、能量或数据类型的概念；例如，在ibd中捕获系统子系统
的两个部件属性之间。可以将交换项捕获为块或信号，然后将其作为项流分配给连接器。在这种情况下，连接
器用填充的三角形表示。

失效模式与影响分析 (FMEA)

检查尽可能多的组件、组装和子系统，以识别系统中潜在失效模式及其原因和影响的过程。

流属性 Flow Property

接口块的一个属性。它可以有方向和类型。flow属性的方向指明了该属性是表示模型中结构对象的输入还是输
出。

分支 / 集合 Fork/join

分支节点标志着活动中并发流的开始。它被表示为一个线段（水平或垂直），并且必须有一个输入流和两个或
多个输出流。

集合节点标志着活动中并发流的结束。它被表示为一个线段（水平或垂直），并且必须有两个或多个流入流和
一个流出流。

功能 Function

一种由系统或系统的某一部分执行的将输入转换为输出的任务。可以将单个功能捕获为模型中的活动。

功能块 Function block

用于定义负责执行系统一个或多个功能的结构对象的概念。通过对系统的功能分解来识别功能块。功能块作为
输入，定义目标系统结构。它们也可以被称为功能分解的不同层次中的逻辑子系统或逻辑组件。
功能拆解/功能分解 Functional decomposition / Functional breakdown

一组步骤，将系统的整体功能分解成更小的部分，以识别功能块。

图形用户界面 (GUI)

一种用户界面类型，允许使用图标或其他形象的指示符与电子设备进行交互，而不仅仅是通过命令行使用文
本。

逻辑系统架构 (LSA) 模型

解决方案域模型的核心。基于问题域分析的结果，它定义了目标系统的逻辑子系统(作为单层层结构)。LSA模
型的目的是识别工作包，每个子系统一个工作包，并将它们分配给独立的工程团队。

逻辑子系统架构 (LSSA)模型

一个解决方案域模型，它包含单个逻辑子系统的逻辑架构及其组件的高层设计，以及更精确的单元。

接口 Interface

一种硬件或软件组件，将系统中的两个或多个结构对象或系统与环境中的对象连接起来，以便将物质、能量或
数据从一个对象传递到另一个对象。

接口块 Interface block

一个SysML定义元素，可以包含一组流属性，这些属性将模型中捕获的某些结构对象的输入和输出定义为一个
块；例如，一个系统、一个子系统或一个组件。接口块的表示法与块的表示法相同，但是在元素名之前有
«interfaceBlock»构造类型。

内部框图 (ibd)

一种结构化SysML视图，可用于根据属性和这些属性之间的连接器来捕获块的内部结构。块定义图可用于指定
系统上下文环境和系统内的交互。

有效性测量(MoE)

MoE是目标系统的一个数值形式特征，是系统工程中广泛使用的一个传统术语，描述了系统在特定环境下执行
任务的情况。

模型浏览器 Model Browser

建模工具GUI的一个元素，表示模型存储库的内容。默认情况下，它位于建模工具主窗口的左侧。

基于模型的设计(MBD)

一种处理与设计复杂控制、信号处理和通信系统相关问题的数学和可视化方法。
基于模型的系统工程 （MBSE）

为支持系统需求、设计、分析、验证和确认活动而建模的形式化应用，从概念设计阶段开始，一直持续到整个
开发和后期的生命周期阶段。MBSE侧重于创建和利用模型作为工程师之间信息交换的主要手段，而不是基于
文档的信息交换。

建模工具 Modeling tool

CATIA Magic软件专门用于MBSE：

Magic Cyber Systems Engineer / Cameo Systems Modeler以及Cameo DataHub插件

Magic System of Systems Architect / Cameo Enterprise Architecture，以及Cameo DataHub插件
Magic Software Architect / MagicDraw带有SysML和Cameo DataHub插件
对象流 Object flow

一对动作之间的一种SysML关系。对象流使您能够表示当活动执行时，从一个动作到另一个动作传递的物质、
能量或数据流。对象流表示为带有开放箭头的实线。

包 Package

一种可以包含其他元素的SysML元素。包可以用来将元素组织成逻辑组。

参数图 Parametric diagram

一种特殊的ibd类型，它显示一个块的内部结构，侧重于该块的值属性和应用的约束块的约束参数之间的绑定。
参数图可以用来计算系统参数值（借助建模工具的仿真能力）。

部件属性 Part property

在另一个块的上下文中使用一个块；换句话说，一个由模型中某处定义的另一个块类型化的块的属性。在bdd
中，它可以表示为该块的部件单元格中的字符串，或者在ibd中表示为矩形。使用部件属性使您能够指定模型中
捕获的作为的块表示的系统的内部结构。一个简化的ibd（没有代理端口）可以用来指定系统上下文中的交互；
在这种情况下，系统上下文被捕获为一个块，其中的部件属性的类型是描述目标系统的块。

表达工件 Presentation artifact

系统模型的某些部分或方面的可视化表示。它可以是一个视图、矩阵、Map图或表格。表示构件作为模型或数
据编辑器的数据输入。

代理端口 Proxy port

块的属性类型，由模型中某处定义的接口块类型化。它表示由该块所代表的结构对象边界上的点，通过它外部
实体可以与该结构对象交互。换句话说，它是接口块在另一个块上下文中的使用。代理端口总是表示为块或部
件属性的外形上的一个小矩形，通常用箭头来代理端口是用于接收系统、子系统或组件的输入，还是用于提供
输出。
需求 Requirement

一个SysML元素，它可以捕获翻译或表达需求的基于文本的语句。它可以用来捕获涉众要求，或者在模型中规
格化系统需求和详细的物理需求。

可靠性 Reliability

功能单元在给定条件和给定时间间隔内执行所需功能的能力（ISO/IEC 2382：2015 Information Technology）。

安全性 Safety

无不可接受的风险（IEC 61508：2010 EEPE安全相关系统）。

时序图 Sequence diagram

一种行为SysML图，可用于描述块的各个部分如何通过操作调用和异步信号交互。

信号 Signal

可以用来捕获交换项的SysML元素。

智能操作工具栏 Smart manipulator toolbar

建模工具GUI的一部分。当在视图框中选择元素的符号时，它就会出现。

利益相关者 Stakeholder

对一个系统或系统所拥有的满足其需求和期望的特征有权利、分享、声明或兴趣的个人或组织。

涉众要求 Stakeholder needs

从目标系统利益相关者处收集的信息。这些信息包括主要用户需求、与系统相关的政府法规、政策、流程和内
部指导方针等。单个涉众要求可以被捕获为模型中的需求。

状态 State

捕获系统状态的元素，存在于运行期间。状态表示为圆角矩形，名称显示为矩形内的字符串。
状态机图 State machine diagram

一种行为SysML图类型，可用于规格化系统中的结构如何随时间改变状态以响应事件的发生。它可以用来指定
系统或其部分的行为。

子系统 Subsystem

在一个更大的系统中，次要的或从属的系统。子系统可以被捕获为模型中的一个块。

系统上下文 System context

确定系统外部视角的概念。它必须引入不属于系统的元素，但确实与系统相互作用。除了系统本身（被认为是
一个黑盒）之外，特定系统上下文中的元素集合还可以包括与该上下文中目标系统交互的外部系统和用户
（人、组织）。单个系统上下文可以被捕获为模型中的一个块。

系统 System

为一个或多个共同目的而组织成一个复杂整体的相互作用的元素的组合。

系统架构 (SA)

与系统设计相比，这是一个更加抽象、面向概念化、全局的架构，侧重于实现目标系统的任务和运行概念。侧
重于系统和系统元素中的高层结构。

目标系统 (SoI)

考虑系统整个生命周期。为了生成系统需求规格，首先从黑盒的角度分析系统，然后从白盒的角度分析系统。

体系 (SoS)

一个系统元素是系统本身的目标系统。通常情况下，体系涉及多个异构的分布式系统的大规模跨学科问题。

系统工程 (SE)

将涉众要求、需求和约束转化为系统解决方案所需的整个系统生命周期的跨学科任务。

系统需求 System requirements

系统、子系统或部件的设计要满足的需求。系统需求来源于涉众要求，涉众要求是更加抽象的需求。

系统参数 System parameter

系统、子系统或部件的数值特征。它可以指定为捕获该系统、子系统或组件的块的值属性。系统参数由MoE派
生出，可以根据系统需求进行验证。

系统建模语言 （SysML）

应用于系统工程的通用建模语言。它支持广域的系统和体系的规格、分析、设计、验证和验证。
权衡 Trade-off

一种情境决策，涉及减少或失去质量、数量或一组属性或设计，以换取其他方面的收益。简而言
之，权衡就是交换和妥协，一件事增加而另一件事必须减少。

转换 Transition

一种SysML关系，表示从一种状态到另一种状态的变化。它可以由事件并发触发。

统一架构框架 (UAF)

定义表示企业架构的方法，使涉众能够关注企业中感兴趣的特定领域，同时还着眼大局。UAF满
足商业和工业企业以及美国国防部(DoD)、英国国防部(MOD)、北大西洋公约组织(NATO)和其他
国防组织的特定业务、运行和体系集成需求。

用例 Use Case

一种SysML元素类型，可以用来捕获人们期望从系统中获得什么功能，以及他们希望通过在特定
的系统上下文中使用它来实现什么。用例的表示法是一个带名字（通常是动词短语）的椭圆，椭
圆中包含名称。

用例图 Use case

一种可用于定义在特定系统上下文中执行的一组用例的行为SysML图类型；它表示目标系统的黑
盒视角。它还显示并可用于创建用例和系统上下文的参与者之间关联，以指定谁/什么负责调用或
参与什么用例。

值属性 Value property

块的一种属性，它可以表示一个数量、一个布尔值或一个字符串。它以字符串的形式显示在块的
值隔间中，并且可以用来捕获目标系统有效性的度量（还必须应用«MoE»构造型）。
SOI：目标系统
Item flow：项流
system integrator：系统集成商
VCCS （Vehicle Climate Control System： 车辆空气调节单元
Cooling system：制冷系统
Heating system:：制热系统
The Structure decomposition map：结构分解图
System configuration structure：系统配置结构
Generalization：泛化
Redefine ：重定义
Poxy Port ：代理端口
used model ：共享模型
stereotype ：构造类型
operation ：操作
signal reception ：接收
binding connector ：绑定连接器
Call behavior Action ：调用行为动作
parameters compartment ：参数隔间
open arrowhead ：开放箭头
conjugate port ：共轭端口
measures of effectiveness ：有效性测量
fork node ：分支节点
join node ：连接节点
item flow ：项流
Flow property ：流属性
FMEA ：故障模式与影响分析
The Structure decomposition map ：使用结构分解图
Classifier behavior ：类行为
Cross-cutting ：交叉关系
Legend： 图列
Activity final node ：活动最终节点
Flow final node：流终点
opaque behavior：不透明行为
classifier behavior：分类器行为
refine：细化
System Context：系统语境
flow specification：流规范
trigger：触发器
guard： 看门狗
effect：影响
completion events：完整事件
simulation session：仿真会话
specification：规格
参考书目
Chami M., Oggier, P., Naas, O., Heinz, M. “Real World Application of MBSE at Bombardier Transportation”,
SWISSED, Zurich, 2015. Available at https：//goo.gl/zf5uvp.
Dandashi, F., Hause, M. C., "UAF for system of systems modeling", 10th System of Systems Engineering
Conference (SoSE), pp. 199-204, San Antonio, TX, 2015.
Delp, C., Lam, D., Fosse, E., Cin-Young Lee, “Model based document and report generation for systems
engineering”, Aerospace Conference, IEEE, 2013. Available at http：//www.omgsysml.org/View_Paper-
IEEE_2013.pdf.
Estefan, J. INCOSE Survey of MBSE Methodologies, INCOSE TD 2007-003-02, Seattle, WA, USA, 2008.
Friedenthal, S., et al. A Practical Guide to the SysML, 4th Edition: The Systems Modeling Language. Boston：
MK/OMG Press, 2011.
Friedland, B., Herrold, J., Ferguson, G., Malone, R. “Conducting a Model Based Systems Engineering Tool Trade
Study Using a Systems Engineering Approach”, 27th Annual INCOSE International Symposium, pp. 1087-1099,
Adelaide, 2017.
Hallqvist, J., Larsson, J. “Introducing MBSE by using Systems Engineering Principles”, 26th Annual INCOSE
International Symposium, pp. 512-525, Edinburgh, 2016.
Hause, M.C., Thom, F., "Bridging the Chasm – Tracing from Architectural Frameworks to SysML", 17th Annual
INCOSE International Symposium, pp. 1317-1332, 2007.
Hause, M. C., Thom, F., "MoDAF and SysML – A Winning Combination", INCOSE UK Chapter – Spring
Symposium 2005, 2005.
Hoffmann, H.-P. “Systems Engineering Best Practices with the Rational Solution for Systems and Software
Engineering”, Release 3.2.1, February 2011. Available at https：//www.slideshare.net/ billduncan/ibm-rational-
harmony-deskbook-rel-312.
ISO/IEC/IEEE 15288:2015 “Systems and Software Engineering–System Life Cycle Processes”, Geneva, 2015.
Mazeika, D., Morkevicius, A., Aleksandraviciene, A. “MBSE driven approach for defining problem domain”, 11th
Conference of System of Systems Engineering (SoSE), pp.1-6, Kongsberg, 2016.
Morkevicius, A., Aleksandraviciene, A., Armonas, A., Fanmuy, G. “Towards a Common Systems Engineering
Methodology to Cover a Complete System Development Process”, 30th Annual INCOSE International
Symposium, Cape Town, South Africa, July 2020.
Morkevicius, A., Aleksandraviciene, A., Mazeika, D., Bisikirskiene, L., Strolia, Z. “MBSE Grid： A Simplified
SysML‐Based Approach for Modeling Complex Systems”, 27th Annual INCOSE International Symposium, pp.
136-150, Adelaide, 2017.
Morkevicius, A., Bisikirskiene, L., Jankevicius, N. “We Choose MBSE： What’s Next?”, Proceedings of the
Sixth International Conference on Complex Systems Design & Management, CSD&M, pp. 313, Paris, 2015.
Morkevicius, A., Jankevicius., N. “An approach： SysML-based automated requirements verification”, IEEE
International Symposium on Systems Engineering (ISSE), pp. 92-97, Rome, 2015.
Object Management Group OMG Systems Modeling Language (OMG SysML), v1.5, May 2017. Available at
https：//www.omg.org/spec/SysML/1.5/.
Object Management Group OMG Unified Modeling Language (OMG UML), v2.5.1, December 2017. Available at
https：//www.omg.org/spec/UML/2.5.1/.
Soegaard, S. E. “Adopting MBSE using SysML in System Development–Joint Strike Missile (JSM)”, No Magic
World Symposium, May 2016. Available at https：//vimeopro.com/user28256466/no-magic- world-symposium-
2016-presentations/page/3.
Spangelo, S. C. et al. “Applying model based systems engineering (MBSE) to a standard CubeSat”, Aerospace
Conference IEEE, 2012.
Walden, David, ed. INCOSE Systems Engineering Handbook: A Guide for System Life Cycle Processes and
Activities, v.4. International Council on System Engineering (INCOSE), August 2015.
Weilkiens, T. Systems Engineering with SysML/UML: Modeling, Analysis, Design. MK/OMG Press, 2008.
Zachman, J. A. “A framework for information systems architecture”, IBM Syst. J., vol. 26, no. 3, pp. 276-292,
1987.
关于作者
Aistė Aleksandravičienė(艾斯达·亚历山德拉维切恩)

Aistė是OMG®认证系统建模专家(OCSMP)。目前，她担任Dassault Systèmes, CATIA品牌的系统工程行业业

务顾问。

Aistė负责培训达索客户关于MBSE的三大支柱：语言(SysML)、方法(MagicGrid)和工具(CATIA Magic软件和
集成)。在与雷诺-日产、徕卡地质系统、庞巴迪运输和康斯伯格国防与航空航天等客户合作期间，她提供
培训，提供工具演示，并参与提供定制解决方案。Aistė还致力于培训材料和撰写论文(单独或与同事合
作)，以在系统工程社区中传播MBSE文化。她是多个MBSE会议和其他公共活动的发言人。

Aistė拥有立陶宛考纳斯科技大学信息系统工程硕士学位。

Aurelijus Morkevičius(奥勒利尤斯·莫尔克维丘斯)
Aurelijus是OMG®认证的UML、系统建模和BPM专家。目前，他是Dassault Systèmes, CATIA品牌的系统工程
行业业务顾问高级经理。

他精通企业、任务、基于模型的系统和软件工程(主要基于UAF、SysML和UML)以及国防防御架构(DoDAF、
MODAF、NAF)。Aurelijus是目前OMG UAF(以前称为UPDM)标准开发小组的联席主席和主架构师。他代表
CATIA品牌参与INCOSE和NATO组织活动。

Aurelijus于2013年获得考纳斯大学Kaunas University and Technology信息工程博士学位。他目前在同一

所大学教授企业架构课程。Aurelijus也是多篇论文的作者，并在多个会议上作为演讲嘉宾发言。
ISBN 978-609-454-554-2