MSBE方法 论浅尝辄止

Model Based System Engineering，基于模型的系统工程。

去触碰如此大的一个话题，还是很害怕的，但为了自己能够顺利成文，就先管理下读者和自己的预期，本文浅尝辄止。

还是惯常的成文模式，先一层层捋概念。

“一组完整的元素、子系统、或程序集来完成已定义的目标，这些元素包括产品(硬件、软件、固件)、过程、人、信息、技术、设施、服务和其他支持元素”。

这是来自于国际系统工程协会INCOSE关于“系统”的定义，一个无所不包的东西，但有边界、有目标、内部各元素之间及系统与外部环境之间有交互关系。

第二层，系统工程。

INCOSE的定义：系统工程(SE)是一种实现系统成功的跨学科的方法和手段。

狭义的角度呢，在开发早期定义并记录客户需求和所需功能，然后进行系统设计和系统验证。

但是，广义来看呢，不但考虑所有客户的技术需求，还要考虑业务需求，既看战略策略，也看计划时间，还看成本盈利。当然，在此过程还要将所有学科和专业团队整合为一个团队，形成一个从概念到生产再到运营的结构化开发过程。

可能讲得还是太空洞，聊个小故事。

大约七八年前吧，由于汽车市场下行，新项目报价成本压力比较大，当时的工程VP召集大家一起想办法缩减BOM Cost，但是聊来聊去找不到好的办法。最后呢，只能无奈地丢出一句话，你们能不能做得更好一点？这其实就是典型的传统挖掘价值的思路，在现有框架下，尽力去压出那一点点水分。后来呢，公司大刀阔斧地进行了全方位的改革，进行各种技术方案和供应链体系尝试，力求从新的模式里获取更低的成本投入和更高的商业回报，且不说效果如何，但这个方式其实可以近似理解为系统工程在解决问题和价值增值的应用。

概念和定义要保证逻辑上没有瑕疵，所以话讲得总不够实在。实在点对我们的读者群来讲，系统工程就是着力于怎么能更对、更快且更省钱地做个相对复杂的工程开发项目。

接下来就进入主题，Model-Based Systems Engineering。

国际需求工程委员会(IREB) 对模型的定义是，一个已存在的实体或将要创建的实体的抽象表示，比如公式、CAD数模、电路图、系统框图、油泥车身、3D打印等等。

MBSE呢，其实是一种实现SE的方法。

INCOSE中也有描述，MBSE是建模的形式化应用，具体会涉及到系统需求、设计、分析、验证和确认活动等。”

MBSE的主要产物是系统模型，系统模型包含了基于文档的SE中所包含的大部分信息，如Spec、接口控制文件、系统描述文档、贸易研究、分析报告、验证计划、流程和报告。

这里多讲一句，现在我们很多系统开发中是通过文档来传递和驱动的，不管是中文还是英文，文字的歧义性、低结构化、难理解性会让这个工作繁重而容易出错，而比如模型里的图形化描述就可以很好地解决文字文档的这些弊端，更容易交流理解，这就是说为什么我们能用一张图讲明白的事，不要用一张表，能用一张表，就不要用一段文字。

此外，模型也可以提供给我们不同的视角或层次，比如，语言描述的视角、功能层面的视角、具体产品的视角……再比如，整车功能架构层、E/E架构层、ECU级功能架构层、ECU级组件及软硬件接口架构层……

系统modeling的过程主要是在ASPICE V模型的左上角的需求挖掘、系统需求分析和系统架构设计（SYS.1~SYS.3），随后系统架构设计（高层级解决方案：功能描述及分配）的输出会传递到软硬件层面上。

那么，当MSBE落地时需要哪些东西：1. 方法，如OOSEM、SysMod、Arcadia…；2. 语言，如SysML、DSL …；3. 工具，如Rhapsody、Magic Draw、Capella…。

大概的样子，可以百度下SysWL的图片。。

当然，这个modelling并不只是展示在ppt看一看，它是部署在软件里的，可以将模型信息在系统开发流程里传递，自动生成代码和完成测试。

差不多了，考虑到再介入太深，一来必然会涉及到太多产品细节，不便于过多描述，二来也是开头提到的，铺得太开，很难讲明白，点到为止。

有机会的话，拿实例讲一下具体语言在具体工具上的具体产品实现。