利用CATIA Magic进行MBSE变体管理

1 产品线工程与MBSE

1.1 产品线工程(PLE)简介

产品线工程 （PLE） 是一种产品设计与开发方法，推出这一方法的目的是高效进行一系列同类产品的设计与开发。整个产品家族被称为产品线，而该家族中的某一型号产品则被称为产品变种(Product Variant)。

在传统的开发模式中，开发这样一个家族的通常方法是开发一个产品，然后复制和修改所有后续产品的设计文档（所谓的克隆和个性结合方法）。但这种方法充满了问题：“很难对所有产品进行全面一致性的更改。此外，可追溯性受到极大损害，很难进行影响分析。”

相比之下，PLE 方法规定用户进行包含产品整个变异频谱的常见设计。此设计称为系统的超集模型（又名 150% 型号）。然后描述可用的功能选项（通常在单独的文档/工具中，而不是系统设计文档中），并且在功能选择和设计中的特定点之间建立连接，这些点需要根据功能选择而变化（这些点称为变异点）。然后，通过做出特定的功能选择来定义家族中的特定产品。然后，通过获取家族的设计文档并根据该产品的功能选择缩小范围，可以生成特定产品（又名 100% 型号）的设计规格或文档。此工程方法通常依赖于 PLE 工具来执行。这里需要注意的是，设计文档由各种文档（资产）组成 – 需求、系统模型、代码、测试用例、手册与文档等。PLE 工具必须能够对各种资产进行操作，以生成产品的一致设计文档。这通常要求 PLE 工具与用于设计系统的工具系列中的所有工具集成。

以系统功能模型为例，产品线中存在的变异性按功能进行紧凑描述，通常组织成功能树。然后，一组功能选择一个特性配置来约定生成产品家族中特定产品的功能模型。功能模型和定义配置（Feature Model）分别保存在 PLE 工具中或直接在建模工具中建模。

1.2 MBSE简介

在设计和管理大型人造复杂系统的过程中，系统工程方法已经被采纳了半个多世纪。但是在计算机模型技术被得到普及应用以前，传统系统工程的工程实践和管理实践主要是以文档方式进行的，具体表现为：

(1) 使命分析与需求之间用文档交接、需求与架构之间用文档交接、架构与设计之间用文档交接；

(2) 在系统工程技术管理生命周期的里程碑之间对文档进行评审，从而把控系统设计与开发的质量与风险。

这种方式在系统复杂度不高的情况下是比较有效的，但是在定义、设计和管理复杂系统时，其局限性就突显出来。以自主驾驶汽车系统为例，它不仅有传统汽车的动力系统、控制系统、机械系统，还有电力系统、导航系统、路障识别系统、空调系统、娱乐系统、自动驾驶系统、网络安全保障系统等等。这样的新一代汽车系统，其零部件的数量可能会达到百万级别，其组件之间的接口数量可能会达到上万级别，其控制逻辑及软件代码量可能达到几百万行。我们需要对它的需求、功能、结构、接口、参数进行一致性定义，才能确保在生命周期阶段之间不会出现信息偏差或遗漏。

信息技术的发展，特别是计算机模型技术的出现使得对系统工程的管理能力有了大幅提升的可能，因而“基于模型的系统工程(MBSE)”技术应运而生。

关于MBSE, 权威的定义是由INCOSE给出的。在《INCOSE系统工程愿景2020》中给出了如下定义：

“MBSE是一种应用形式化建模手段，用于支持系统需求、分析、设计、验证与确认活动，这些活动从概念设计阶段开始，贯穿整个开发过程及后续的生命周期阶段。”

相对于传统基于文档的系统工程方式，MBSE的优点主要体现在如下方面：

• 实现单一数据源

传统系统工程以文档为核心。极难解决单一数据源问题。文档的每一次拷贝都意味着数据对象的复制或增加。在系统复杂度较低的时候，尚能依靠人力来维持每一份数据源的数据一致性。随着系统复杂度的增加，变更越来越频繁。维护数据源的数据一致性带来的工作量呈指数增加，渐渐变得无法承受。这也是当前每个复杂系统设计过程中经常发现的共性问题，同一数据在不同文档中难以保持一致，导致不同部门之间设计数据无法完全匹配。

MBSE将以模型为唯一数据源，原有文档、数据、接口、指标的一致性将会在模型中自然体现。

• 实现需求无二义性

无二义性是指每个需求只有唯一的含义。然而由于自然语言的特殊性，对于同样一段描述，不同的人员可能会有不同的理解。特别是当需求从总体传递到系统，系统传递到分系统，分系统传递到单机的时候，由于工程师之间的背景有着极大的差异，关注系统的侧面也各不相同，所以这种对同一条需求的差别理解现象更加容易发生。

采用MBSE研制方式后，需求将在模型中被条目化管理，需求的分析、分解、实现、验证都被跟踪，对于任何一条需求都可以在系统工程环节的任何一个节点追溯到其源头。

• 疏通上下游之间信息沟通与反馈

当前复杂系统研制过程主要是以任务书或规格说明书为载体的自顶向下信息传递。然而在系统研制过程中经常会在下层设计部门产生派生需求，这些在设计过程中产生的派生需求应该且必须反馈回上层设计部门，经由上层设计部门评估派生需求对整个系统的设计/可靠性方面带来的影响。当前很多复杂系统研制过程并没有一个高效的反馈机制，设计的反馈通常只在设计师之间口口相传。反馈效率取决与不同部门之间设计师的个人关系及熟悉程度。急需建立一个数字化的，行之有效反馈机制与通道。

随着市场竞争不断加剧，企业的产品/型号研制任务繁重，研制进度要求越来越紧。工作安排上会实行多型号并行开发，其技术状态管理的难度也随之增加，普遍存在诸如设计文件多基线多状态、产品技术状态变化涉及面广等特点,使得通用产品在不同型号各个研制阶段应用时的状态追溯日益复杂和困难。在实际工作中受设计文档难以验证和评审的影响，存在技术或管理上的协调不充分、甚至矛盾的现象。采用MBSE方式之后，信息/数据的传递方式将转换为以模型为核心的传递方式，原有的困局将被大大改善。

• 系统指标在方案设计初期得到分解/确认

系统设计中的一个重要且难点问题是对系统功能指标和非功能指标的分配与确认。非功能指标通常包含：性能指标、可靠性指标、安全性指标、维修性指标和成本指标等。非功能指标分配是将系统非功能的定量要求分配到规定的产品层次上，通过分配使整体和部分的非功能定量要求协调一致。这是一个由整体到局部，由上到下的分解过程。系统指标的分配是一个多学科，多指标协同/权衡的过程。

目前很多复杂系统研制时，对功能性指标的分解采用自然语言+Word的方式进行，描述不准确，并且难以验证。同时对于非功能需求/指标目前只能依靠设计师的个人经验进行分解并且在方案设计初期极难确认。目前很多产品需要等到性能样机出来以后，才能初步开展非功能指标的确认和验证工作。然而在此阶段才发现指标分配得不合理从而导致的系统更改将会对整个系统研制的进度/成本带来极大的影响。

MBSE帮助我们在V模型的左侧建立一套能够对功能、非功能等系统指标进行早期分解、分析、验证及确认的方法，以减少后期系统设计的更改。

• 系统架构与设计知识得以固化

许多企业拥有多年型号系统研制经验，以图样、专利、标准、设计报告、论文等载体形式积累了大量型号研制、系统工程管理的成果和经验，但知识存在分散化、无法有效整合共享、大量经验类知识存在于人员头脑之中等问题。

MBSE将帮助建立起一套产品/系统知识管理系统，系统知识将以涉众需求为源头，展开到系统定义、子系统划分、功能定义、接口定义、指标分析、系统/组件验证与确认等各个方面。

从应用领域来看，MBSE在汽车、航空、航天、船舶、核电及高科技等行业有着充分的应用场景，其应用前景不可小觑。

2 汽车变体管理场景

产品家族概念的产生发展与产品平台化模块化竞争策略的发展过程息息相关。人们观察到，通过产品家族策略来赢得市场竞争优势的产品类别有很多，比如手机、家用电器、汽车、民用飞机、网络电商等，其中汽车和手机由于具有用户市场庞大、基本共性功能相似以及用户偏好易识别归类等共同特点，导致他们都倾向于实行产品家族策略。

从平台化角度来看，成本是决定产品竞争优势的重要因素之一，对于市场竞争日趋激烈的汽车产业来说，极度追求规模效应的目的也在于此。为了充分发挥大规模制造带来的成本节约优势，平台化模式在汽车行业率先得到了应用，而产品的平台化制造则以产品的平台化设计开发为基础。为此，企业深度理解并有效实施产品平台化开发战略将直接决定后续成本控制的可能空间，并带来其它方面的诸多益处，具有重要的意义。

平台化的核心在于实现不同产品间零部件的通用。早在20世纪80年代，一些跨国汽车企业就提出了汽车产品平台的理念，强调在同一平台内应用一些固定的零部件组合，同平台的不同车型之间具有相似的结构与配置，从而为产品的设计开发与生产制造带来了很大的便利。与传统开发模式相比，平台化模式具有节约开发成本、分摊制造和采购成本、产品衍生能力强、新品开发时间短、质量更易保障等优势。同时，通过实施平台化开发战略，企业可以将资源集中于汽车平台的设计开发，即以高水准的平台确保后续衍生车型产品的高水准落地。

下面以某车厂汽车产品策略为例，了解一下产品变体管理的场景。

某车厂按市场要求计划同时发展多款车型以满足不同消费群体：首先从发动机来看，需要分别支持汽油、柴油、电动等多种发动机；从车门数量来看，某些车型需要四门，而另一些车型只需要两门；从外饰来看，车门颜色需要考虑支持多种不同色系，而且外型需要考虑支持多种变体，比如轿车、房车和敞篷汽车等。

以上是多个车型变化点的描述，对之进行抽象化概念表达，可以描述成变体的特征模型（Feature Model），如下所示：

在众多变体车型中，我们摘取两款车型：运动版与家庭版，得到他们的特征描述如下 ：

3 针对MBSE模型的变体管理

在汽车领域，通过MBSE进行车辆的系统架构定义形成了描述架构的系统模型，这样构建了系统设计、开发、生产制造和运营维护的基础模型。然而在平台化的产品家族策略背景下，同样面临着“设计开发管理”上的两个基本问题：

“很难对所有产品进行全面一致性的更改。此外，可追溯性受到极大损害，很难进行影响分析。”

因此人们需要利用PLE思想来管理MBSE系统架构模型。也就是说需要识别产品家族的特征模型，在单个型号产品设计基础上定义150%产品架构模型，从架构模型中识别并描述变化点，并且能够利用配置信息从150%超类模型中自动生成产品型号的100%变体模型。

本文采用达索公司的CATIA Magic工具来构建系统架构MBSE模型，利用工具中支持PLE的插件MBPLE来进行面向架构的变体管理。

3.1 定义特征模型（Feature Model）

在CATIA Magic中，特征模型是一个简单的 UML 类模型。特征模型的根节点是应用了 «RootFeatureGroup» Stereotype的类。前面章节中汽车的特征模型在CATIA Magic的MBPLE模型中表现形式如下：

这里，产品特征(Feature)可以直接放置到根功能组（类）或子组中。根特征组应用 «RootFeatureGroup» Stereotype；子组被建模为 特征组（类），应用«FeatureGroup» Stereotype，然后使用组成关系连接到根特征组中。

注：在“汽车变体管理场景”章节中一共定义了八个特征点，而在本示例特征模型中定义了几十个特征点，但上述八个特征点是被包含在内的。

特征点通常被分为三类：布尔型、枚举型和数字型。

• 布尔型

示例中，内部分类中的Navigation, HeatedSeats都是布尔型，它们只有"是/否"两个选项，由于特征模型用 UML 表示，这里采用 Boolean指定他们的类型。

• 枚举型

具有多种替代选择的每个特征都建模为 UML 属性，并指定枚举类为类型。

包含多个替代选项的特征，具有指定的枚举类型，它的枚举选项定义如下：

定义为特征的所有UML属性都应用了«Feature» Stereotype。

• 数字型

对于以变化数值为选项的特征点，在定义UML属性时，指定Integer为其类型。比如特征模型中的numDoors属性。

3.2 定义特征配置（Configuration）

什么是配置呢？配置是项目中已创建的特征模型（类）的实例模型。

在CATIA Magic中使用实例表来创建特征配置，创建配置的步骤如下：

1. 创建实例表。
2. 将根特征组设置为其Classifier。
3. 为实例表的表格填充相应的属性值。

实例表的每一行就是一个单独的特征配置（变体）。

在这个示例中的特征配置代表了四个变体，分别是：

• ConfigurationWithWrongDoorsCount
• FancyCarConfig
• MainStreamCarConfigWithABS
• MainStreamCarConfigWOABS

在CATIA Magic中，最快捷地创建特征配置的方式是使用自动创建向导：

从快捷方式菜单中，选择工具>创建实例。

按照自动即时向导的步骤操作完成实例创建。

3.3 使用变异点定义系统模型

在这里，具有变异点的系统模型是什么呢？系统模型（也称为 150% 模型）是代表具有可变元素对象的系统的模型。同时，在150%系统模型基础上，我们利用变异点来标记系统模型中可能在不同型号中出现变化的模型元素。

任何SysML模型中的模型元素都可以作为潜在的变异点，但是实践中常用的被定义为变异点的模型元素包括：Class, Block, Relation, Property, Operation, Activity, Action, Requirement等等。

与前面对特征点的分类方式一致，变异点也分为三类：

• 存在型变异点

此类变异点对应于布尔型特征点。如果模型元素（需求、块、属性、操作等）在系统的某些变体中不存在，则用存在变异点标记它。它是最常用的变异点。

用“存在”变异点标记元素的方式如下：

右键单击元素，然后从快捷方式菜单中选择变体建模>添加变异点>存在。

此操作将系统模型元素标记为具有变异点。更改点图标显示在上面。

当上述“天窗”组件被定义为一个“存在”变异点时，要求在变异点配置中将这个block与特征模型中的特征点关联起来。此处，特征模型中的特征点是布尔型的“SunRoof”，

系统模型元素SunRoof与特征模型元素SunRoof之间通过如下的关联定义建立关联：

• 枚举型变异点

模型中的发动机”Engine”是一个枚举型变异点。它被指定为ElementProperty变异点，通过如下定义进行枚举值的映射：

• 数值型变异点

“车门数量”属性就是一个数值型变异点，它在不同变体车型中表现为不同数量；与此类似，车辆最大重量也是数值型变异点。默认情况下，最大重量为1000KG；当车辆为Estate型时，最大重量为1350KG；而当车辆为Cabriolet型时，最大重量为1500KG。这个属性被指定为变异点，通过类似的JavaScript脚本进行解析，获取变异值：

3.4 应用特征配置

当我们针对150%系统架构模型定义好了变异点后，我们将需要应用“特征配置”来识别出150%模型的特定子集，即面向某一具体配置的100%模型。

“指定配置”是利用”Variant”工具菜单来执行的：

在前面对特征配置定义的前提下，这里有四种变体配置供选择。选择一种配置后，可变元素（具有变异点的元素）将在图表上以红色/绿色/黄色着色，具体取决于元素是否存在（绿色）、不存在（红色）或在所选配置中更改（黄色）。

以配置”MainStreamCarConfigWoABS”为例，生成的100%模型如下：

3.5 生成100%变体模型

最后一步就是针对150%系统模型，应用完特征配置之后，将它转换并导出成100%系统模型。这一步操作是通过Model Transformations功能来完成的。

打开模型转换向导：

选择Model Transformations:

这一操作，根据规定的变化点，将模型（修改/删除的元素）更改为系统的特定变体。实现变种后，您可以对普通系统模型（100%模型）进行任何处理：分析、模拟、报告、发布等。

在转换后的100%模型中，几个变异点的选择解释如下：

1. 由于特征配置的SunRoof是N, 转换后该Class被删除；
2. 由于特征配置中车门数量为4，因此转换后Door的多重性被设为4；
3. 根据配置脚本，在该特征配置选择中，maxMass被设置为1350；
4. 根据特征的枚举定义，在该特征配置中，Engine被选择为TurboDiesel，因此Engine的Part指向TurboDiesel, 而不是原来的Engine。

4 总结

正如戴姆勒公司在其MBSE转型的文章中提到了，“新一代汽车，特别是智能化汽车，其复杂度相比传统汽车有着指数级增长。传统的系统工程手段已经达到了其管理能力的权限，无法应付高复杂度汽车的管理要求，因此基于模型的系统工程方式必然是未来应对汽车行业复杂度的关键手段。”MBSE已经在汽车及航空航天等复杂系统领域得到成功应用，未来也必然成为复杂系统行业技术管理及流程管理的主要支撑手段。

结合PLE，MBSE又能处理多变体型号设计开发过程中共性与差异性的设计要求，提升设计研发效率，帮助企业借助于平台化模型化的产品策略提升市场竞争力。