23
4 月
MBSE概述
- By IanGoo
最近我去了一趟位于成都的Siemens创新中心，了解了一下他们的拳头PLM产品Teamcenter，顺便了解了一下Teamcenter背后的MBSE的概念，觉得非常有趣，于是又查阅了一些资料，觉得这是一种非常有意思的思想，故作此记录以为备忘。
“SE”是什么
首先需要介绍的是MBSE中后面两个字母：SE。
MBSE的全称是“Model-Based System Engineering”，基于模型的系统工程。很容易理解，“SE”指的就是系统工程。那什么是系统工程？
1940年代，美国贝尔实验室在开发大规模电话交换机的时候，发现将一个个零件组合成组件，将组件组成一个庞大的电话电报系统之后，整个系统的复杂度呈现出指数型爆炸的趋势，远远高于组件复杂度的总和。在这样的背景下，贝尔实验室开始将“系统”本身作为研究对象，研究系统本身的需求工程、可靠性工程、物流、人力与团队、团队协调、测试评估、可维修性等等各方面的特征，并逐步形成了一套方法论体系，这套体系就是系统工程。
二战之后，最复杂的系统出现在航空航天领域，一架喷气式战斗机的机械系统零部件数量高达百万，还要加上电气、液压、软件，航空器的高可靠性还要求很多系统都要设计四重冗余，因此，系统工程在诞生之后不久就在航空、航天、军工领域大放异彩。1955年，一位功成名就的科学家、喷气推进实验室创始人历经千辛万苦回到了中国，将系统工程的理念带入中国，系统工程很快在中国的军工领域得到应用。北京航空航天大学就有一个学院，黑话叫“14系”，正式名称“可靠性与系统工程学院”，专门培养系统工程人才。
1990年，INCOSE（International Concil on System Engineering，国际系统工程协会）成立，这标志着系统工程学科拥有了标准化的国际学术组织。
系统工程的重要性不言而喻。如果不重视系统工程的能力建设，就有可能“好食材做猪食”，而系统工程如果很强，一样可以用不那么高精尖的组件拼出总体性能极为强悍的最终产品来。毕竟用户使用的是最终的整个系统，而非系统当中的某个零件。
看到现在，似乎还是没法下口。系统工程究竟有哪些具体的工作内容呢？
1969年，Arthur David Hall提出了一种三维结构模式，被称为硬系统方法论（Hard System Methodology，HSM）。
有硬系统方法论那就应该有软系统方法论咯？还真有，是英国管理与系统科学家Peter Checkland在HSM的基础上拓展出来的，发布于1981年。不过软系统方法论一般是运用于包含大量的人因要素的系统当中，如社会科学、政治决策等领域，汽车研发这种非常客观化的系统工程当然是属于HSM的应用范畴。
HSM有三个维度，分别是时间维度、逻辑维度和知识维度。
- 逻辑维度
逻辑维度是思考问题的方法论体系。同样分成七个步骤。- 问题定义
很多系统设计上的问题并不明确。因为一个大型系统会牵涉到自然、经济、社会、政策等很多方面。如果在问题定义上出现了偏差，问题就会很严重，会造成项目整个偏离既定路线，造成极大的浪费。
问题定义出现偏差的前提下开始推进项目，用游戏玩家的说法就是“科技树点歪了”。 - 价值设计
在明确了问题后，价值系统设计的重点是对问题可能的解决方案以什么样的评估体系进行评估。这一阶段的主要内容有：第一，如何量化评价指标；第二，评价指标中的主观与客观项目如何分离；第三，如何从多个子系统的综合中作出综合性的评价；第四，如何从这些评价体系中提炼出组织的价值观。 - 系统整合
将组件整合成一个系统的过程。 - 系统分析
系统分析主要有三个方面：- 变量选择：哪些变量可以描述这个系统？
- 建模和仿真：对于工程系统，CAD和CAE系统可以完成这项任务。而涉及到更高层次的抽象系统，可能就需要动用GPSS等分析工具。
- 可靠性工程：对于一个大的系统来说，可靠性不单纯是组件可靠性的综合。可靠的组件一样可能组成拉胯的系统，而不可靠的组件一样可以组成高可靠性的系统。
- 系统优化
在约束条件规定的可行域内从多种方案或者替代方案中得出最优解或者满意解。目前应用最广的仍然是传统的线性规划。 - 决策
- 实施
- 问题定义
- 时间维度
时间维度是伴随着产品从规划到退市的整个生命周期，这就是所谓的“产品生命周期”，针对产品生命周期的全流程管理系统就是所谓的“产品生命周期管理系统”（PLM系统）。而Siemens Teamcenter正是目前市场上占有率最高的PLM系统（虽然性能上不是最出色的）。HSM将产品的生命周期分成了7个阶段：系统规划、系统设计、系统开发、工艺设计、产品上市、销售与售后、退市。其中前四个阶段就是系统的开发阶段，而后三个则是上市销售后的阶段。 - 知识维度
知识维度是为了管理对应的系统所需要的专业知识。除了工程本身所在的专业领域的相关知识（如设计汽车需要机械、电气、软件等专业知识），还可能需要管理学、社会科学、法律等更高层次的专业知识。
这仅仅是一个比较“祖师爷”的方法论，系统工程的世界里还有其他模型，有些模型将通用技术、专用工程（如电磁兼容、可靠性、人机工程）等也纳入系统工程的范畴，而且各个行业、各个国家/地区也都衍生出了自己的系统工程方法论，这是一个极为庞大的学术领域。
仅仅一个Siemens Teamcenter系统当然很难涵盖系统工程方法论的所有方面，Teamcenter专注于时间维度，时间维度是产品的生命周期，Teamcenter就是PLM系统的代表性产品。如果将PLM的焦点进一步汇聚到正向研发，那就是四个大的步骤：需求分析、系统设计、专业设计、工艺设计。这四个大步骤走完后，还需要反过来走一遍做验证，这就构成了很多PLM软件做宣传时喜欢用的那个“V”型研发体系的基础：
在这样的正向研发体系当中，专业设计、工艺设计、组件集成、组件测试是涉及到具体的产品的，传统的流程是在样机上展开的，现在有了CAD和CAE，可以做计算机辅助设计和虚拟仿真，而需求分析、方案设计、产品测试和需求确认，也就是V型上端的四步，产物则是一堆堆的文档。
Emm……用文档造车，这玩意儿我熟……
从文档到模型
如前所述，面向正向研发的系统工程主要的产物有两大块：原型和文档。对于汽车设计来说，原型的数字化速度肉眼可见，各类CAD、CAE、动力学分析工具满天飞，造型的Alias、结构的Catia、动力学仿真的Simulink等等，任君选择。可是，顶层设计呢？上头要求一根传动轴的扭矩容量是多少，直径和长度是多少、刚度要求是多少，这些，都还是写在文档里的。
无可否认，随着互联网的普及，访问文档没那么费事了，传统的Microsoft Office文档已经逐渐退出了开发文档的舞台，取而代之的是Confluence、语雀、石墨这样的共享型、知识库型的文档，而且不一定要用电脑，一台手机甚至一块智能手表就能访问。但是，它们的本质上依然是文档。
这种利用文档对系统开发的需求和设计进行定义的系统工程方式被称为“DBSE”，Document-Based System Engineering，基于文档的系统工程，或者“TSE”，Traditional System Engineering，传统系统工程。
DBSE的问题在于，它的“数字化”是不完整的，只有V型下方的数据实现了数字化，但是对这些模型的操作和校核依然得以赖人工，因为只有人类能够阅读并理解V型上部形成的文档。
所以，完整的数字化应当能够将文档也给干掉。而其中的关键，在于将需求文档和方案设计文档改写为某种计算机能够理解的范式。这种范式就是“模型”。建立这样的模型的过程就是“建模”。基于模型的系统工程——Model-Based System Engineering，就是所谓的MBSE。
MBSE的要点在于“建模”，而建模的范式则由“建模语言”界定。目前系统工程行业的标准是SysML建模语言。
SysML是由UML2.0发展而来的一种建模语言，由INCOSE和OMG联合推出。INCOSE上文已经介绍了，OMG又是什么？仿佛是某种基督教语境下的感叹词？
并不是，OMG=Object Management Group。这里的“Object”是软件工程当中的一个概念，即“对象”。
在世界上出现编程这个概念的时候，程序设计的方法都是面向过程的。乃至“程序”这个词本身就是按照一定的顺序执行特定操作的意思。但是，随着软件规模的增大，面向过程的程序设计带来了一系列的问题，整个软件要增加或者修改某个功能，将会造成巨量的代码修改量。在这样的背景下，面向对象的程序设计就诞生了。
举一个很简单的例子：五子棋游戏。面向流程的设计方法大致是这样：
可以看到，整个程序的设计思路是将“下五子棋”这个过程一步步切割为函数，然后通过环环相扣的函数来实现整个程序的运作。但是这样的设计会存在一个问题。比如，我想要给这个程序增加一个悔棋的功能，那工作量等同于重写。
而面向对象的程序设计则不然，它将五子棋的整个系统切割为若干个对象：
- 玩家，即黑白双方，他们的行为是一致的。
- 图形系统，负责画面的绘制。
- 规则系统，负责规则、输赢判断。
整个程序设计变成了这样的结构：
增删功能，只需要对Rules模块做出修改就可以，这就使得程序的可维护性变得更强，整体的架构也更加灵活。时至今日，面向对象的程序设计已经成了行业最常用的思路。
1989年，IBM、苹果、Sun Microsystems等企业联合成立了OMG，用于将面向对象的程序设计标准化。OMG在日后开发了一系列用于描述面向对象设计的标准工具，其中就有UML（Unified Modeling Language，通用建模语言），上面的两张描述五子棋游戏的图就是用UML绘制的。
UML的特点，就是用标准化的范式来描述面向对象程序设计当中的几乎一切，每个对象是如何定义的、它们之间如何进行交互、传递什么样的信息，都可以用标准的UML来进行描述。如上面面向对象的五子棋游戏，图像化的描述背后是一串代码：
abstract Player {
{field}黑/白方
{method}接受输入
{method}输出落子位置
}
class Graphic {
{method}接受落子位置
{method}绘制画面
}
class Rules {
{method}判定输赢
}
Player - Graphic
Player -- Rules标准化的代码让计算机系统来阅读当然不成问题。而且由于代码可以和图像严格地一一对应，因此也可以通过图像来自动生成代码，这一点非常方便。
UML强大的描述能力正契合了INCOSE的需求，INCOSE和OMG联手，在UML2.0规范的基础上开发了一套面向工业系统的建模语言——SysML（System Modeling Language，系统建模语言）。SysML和UML有很多的相似之处，但是又有些许的不同。
SysML可以描述9大类系统要素：
这基本上涵盖了一个工业系统的全部内容。
将系统工程中的文档全部模型化后，系统的自动化程度将得到质的飞跃。举一个很简单的例子：NVH当中的车内噪音测试。
在需求分析阶段，工程师拿到销售或者PM给出的建议，将其用SysML写成需求模型，需求模型界定了各种工况环境下的噪音要求，在一步步完成设计和样车试制后需要进行测试，测试工程师只需要将噪音传感器的数据按照既定格式导入，开发系统将自动对比传感器获取的数据与需求模型，实现全自动化的需求确认工作。这就比拿到数据后，测试工程师在Excel表里人工核对数据是否满足需求要高效得多。
需求文档和方案设计文档的模型化，实际上是打通了文档与设计对象之间的隔阂，让计算机能够协助工程师工作，这也是MBSE相当重要的设计思路。一个完全体的MBSE是这样的：
MBSE与造型设计
很不幸，MBSE与造型设计很难共存。
造型设计的根本目标是人的审美，这是一种高度主观的专业设计门类。因此，在大的MBSE系统设计当中，只是将造型作为专业设计当中的一个切片来进行处理，预留好造型与总体系统的数据接口就算善莫大焉了，想要给造型设计的需求来“建模”，这就有些强人所难了。
我们描述某种造型设计风格的时候，最常见的就是各种形容词，如动感、强壮、厚重、轻盈等等，这些“形容词”在建模语言中是不允许存在的。建模语言为了保证模型描述的精确性和客观性，需要定义好约束条件和量化条件，造型设计的描述在这样的要求面前，属于圆榫方卯，很难兼容。
所以，造型设计在很长一段时间内将维持人工理解、人工设计、人工评审，原因很简单——造型设计的客户是人。
当然，就Teamcenter本身而言，可能有一些模块是可以让造型使用的，比如Polarion，这就是一个类似Jira的敏捷开发平台，造型设计团队或许有可能使用Polarion来进行一些项目管理。不过，对于造型来说，或许选择Shotgun或者Deon会更好一些。再比如Materials模块，用于库房管理还是不错的，或许可以用于材质库的管理。