| 编辑推荐: |
本文主要通过几个方面：OEM的设计工作类型、采用MBSE的好处、MBSE的典型使用--软件定义汽车来介绍了MBSE对汽车EEA研发的作用。
本文来自于汽车电子电气架构创新发展论坛，由火龙果软件Linda译、推荐。 |
|
1. 前言
传统的EEA中最核心的系统设计基本都是以文字描述为基础的，辅助以各种图表。现在的大多数国产车都是这么造出来的。看起来好像也没毛病，毕竟我们的几十个自主品牌靠这种方式造了几十年的车，广大的人民群众也渐渐接受了国产车，国产车的份额也能占到国内份额的30%左右，好像按照这种方式也能够继续生存下去。
可是我们中国人民是有理想的，我们一直在想着弯道超车或者换道超车。既然想超车就要换个好的动力系统或者靠超强的能力。
我们先说说超强的能力怎么获得，说句心里话，这个真的很难，我们的优势在于成本控制，IT技术应用比较成熟，敢于创新，还有我们的员工很敬业，这是我们能够在过去的几十年里能够取得那么大的进步的基础。
可是，随着合资厂的本土化程度越来越高，我们的成本优势在迅速的失去——因为合资厂的销量的优势，所以可以取得同样的质量下更低的价格。我们的员工也因为追求稳定的生活和较好的福利待遇而在为老外打工。IT的应用技术虽然我们有一定的优势，可是这个对终端用户的吸引有限，老百姓买车还是追求基本的性能和质量。
既然这样，我们想要超车或者不被别人拉下，就只能靠动力系统——开发模式和工具的提升了。关于开发模式，我以前有一篇文章《谈谈正向开发》，应该已经说得比较多了，这里就不再重复了。只是再次容我声嘶力竭的喊一句：不搞正向开发，要么彻底出局，要么就一直维持那可怜的销量吧——因为脱离了正向开发的支撑，仅仅靠系统集成是没办法玩大的。
2. 开发工具的重要性
搞正向开发，没有工具是玩不转的。为啥呢？因为正向开发意味着要对大量的设计掌握到非常详细的程度，大家可以想象一下，汽车上的零部件总成至少就要有几千个，带软件的ECU至少也有几十个，这几十个ECU的软件总行数至少几千万至几亿行了。
当前的车辆软件代码量是智能手机的10倍，一辆具备自动驾驶能力的车辆甚至会是1000倍，各类ECU之间的通信交互太过复杂
如果想搞正向开发，就意味着对这几十个ECU的大部分逻辑关系要掌握。车上的软件相关的功能至少也要有几百个，如果把几百个功能分配到几十个控制器中，并且让这些控制器能够完美的协调工作，渴望靠几个天才的脑袋来进行设计一定是不靠谱的。最可靠的方式就是需要工具来把这些复杂的关系和需求管理起来。
3. OEM的设计工作类型
汽车厂中的大多数的设计工作可以分为两个大类：
一个是物理实体的零部件设计：这个部分大家早都已经引入了诸如CATIA、UG之类的数字设计工具，进行设计和相应的仿真，统称为CAD和CAE。已经被广泛使用。相信现在已经没有人使用手工画图来设计零部件了。
另外一个是逻辑相关的设计，也就是软件相关的。这个部分是目前汽车行业创新竞争的主体。但是对于这种看不见却异常重要的东西——逻辑——这种只能存在于人的大脑中的非实体存在的东西，在很长一段时间中，很多OEM中还是采用文字为主的描述和表达方式，与供应商之间的数据交换和交流也是以文档形式为主，Word，Excel是最重要的工具，用来管理逻辑相关的需求和设计。
这是一个很奇怪的现象，在那些看似传统的领域中，车身上的各种零部件的布置和性能基本都已经可以通过数字模型进行前期的设计和部分的性能的仿真，从而能够在进入开模前就发现各种问题，减少后期模具和实物验证的成本。
而在我们重点努力的领域中，Office这种极其原始的开发管理方式却还是大行其道。幸亏零部件行业竞争比较激烈，虽然很多OEM跟供应商的交流基本靠口头解释为主，但还是会有很多经验丰富的供应商来陪着OEM们来玩猜猜猜的游戏——如果供应商猜错了，供应商大多数是要自己吃进损失的……这真是一个极其让人惊讶的游戏。
4. 什么是MBSE？
基于模型的系统工程（MBSE）是相对于传统基于文档的系统设计而言，传统设计方式中，系统方案设计阶段多数通过撰写方案设计文档来对系统进行定义，如下图： 
MBSE（基于模型的系统工程）=用数字化建模代替写文档进行系统方案设计，把设计文档描述系统结构、功能、性能、规格需求的名词、动词、参数全部转化为数字化模型表达。其本质就是为了让OEM的设计能够数字化，以标准格式进行存储和交换。 
5. 采用MBSE有什么好处？
1. 架构和系统设计工具的引入，使得逻辑系统的设计也可以数字化了，数字化的最大好处就是可以标准化，减少了文字描述带来的歧义，这一点对于中国的OEM来说尤其的重要，这是由于中文是不太适合进行严谨的技术类描述的，常用的中文文字就那么多，加之中文没有严格的语法，势必造成很多的歧义。
2. 由于AUTOSAR的应用，符合AUTOSAR标准的SWC和相应的ARXML格式的描述文件成为了一个标准的数据交换格式（虽然也没有完全标准化），没有前期的数字化设计，是没法直接生成SWC的。OEM不能提供SWC给供应商，就没有办法提供准确的设计，也就只能把全部功能设计逻辑都以文字形式提供出去，必然会有各种各样的问题产生。
3. 实现数字连续性 data continuity，借助数字连续性，企业能够将产品整体质量提升到新的水平。数字连续性意味着与某个产品或设计工作的相关的所有人都在任何时候都能用一致版本的数据与模型。公司内的所有部门和外部单位，如供应商和（未来的）买家，也可以随时在需要的时候了解这些相同的可靠信息。
这样能改善协作，提升效率并限制出错率。产品生命周期的信息在每个部门将实时地保持一致。该平台应是数据驱动（data-driven），而非文件驱动（file-driven）。
4. 实现数字孪生 digital twins。这个在以前的一篇关于MBSE的文章中已经描述过了，大家有兴趣可以翻出来看看。简单的说，就是通过在实际产品中的数据采集来反过来优化原始的设计。
5. 快速的迭代更新。工具的使用是可以提升效率的，这一点毋庸置疑，否则那些软件就不会卖出天价了。有了模型，可以有针对性的快速更改和验证，这样整个设计的迭代更新就可以大幅度提升了。
6. 使需求追溯和功能实现成熟度的管理成为可能。有了工具，就可以把各种需求、功能、和零部件软件之间轻松的映射起来，从而可以实现精细化管理，追踪每个需求的实现情况。更可以改变传统的以ECU为核心的管理模式，让管理人员的精力转到核心的功能实现上，至少可以在某个ECU的开发出现问题时，通过工具中的统计来迅速的判断出哪些需求没有被完全实现，而不是把所有相关的开发人员和供应商叫到一起来讨论后才能确定影响范围。这是一种管理质量和效率的双重提升。
7. 方便知识的共享和普及。不可否认的是，优秀的工程师永远都是宝贵的财富。但是现在很多传统的组织中，知识（Knowhow）集中在少数的人手中，虽然有各种各样浩如烟海的文档和规范的存在，可是由于数量众多和更新不及时，很多设计的原始目的已经很难被追溯了，新进的人很难去了解系统的全貌。而通过大家在统一的工具中的协作，知识的共享和传承可以被最大化的实现。
8. 工作效率的大幅度提升，现在的很多的工具都提供文档的自动生成功能。在设定好文档模板和导出的条件之后，上千页的文档就可以轻松导出，既可以保证质量，又大幅度降低了工程师的工作量。如果没有工具，这些工作都是要手工完成的。另外，模型化的表达方式可以大幅度提升理解的效率。一张优秀的图表胜过千言万语。加之我们大多数的理工科的人在文字表达上不够强，所以标准化的图形是最优的选择。
9. 提升设计质量，模型化数字化之后就可以自校验，进行仿真，及早发现问题。这个活动可以称之为MIL（Model
In Loop）。加上前面所说的标准化、快速迭代等特点，同样时间出来的产品，质量绝对是不一样的。
6. MBSE的典型使用--软件定义汽车
SDV的一个目标是车上承载的服务可以快速部署，而且可以按需要部署，并能够经常更新。如果没有数字化的设计基础，仅仅靠文字来在OEM内部的各种部门中交流，并传递给软件供应商，迅速的更新是不可能的。虽然有了OTA技术，但是如果没有可以隔三差五就可供更新的功能，而是按照原来的半年以上一个版本的模式，用户是没有办法满意的。
特斯拉为啥呢那么频繁的更新软件？一个重要的原因就是他们的设计团队中很多人都是来自软件行业，对所谓的数字化设计早都已经驾轻就熟了，再加之他们自己强大的软件开发能力，基本上是只有想不到，没有做不到了。
7. 总结
总之，我们国内的OEM在数字化这条路上还是要敢于大手笔投入。俗话说，舍不得孩子套不着狼，连一点工具的钱都不舍得投入的话，怎么与那些洋枪洋炮PK呢？况且，这点投入对于OEM来说根本不是问题，随便一个车型改款的投入都绰绰有余了。
真正的挑战在于思维模式、习惯和现有的人员能力，让工具真正的发挥作用是要改变现有的各种工作流程，并且让现有的大部分人员转变工作方式的。这个才是最难的。
| 
