2022汽车半导体生态峰会演讲实录|达索系统魏周君: MBES建模的角度赋能汽车软件开发-每日速看

以“智链未来 本立而道生”为主题的“2022张江汽车半导体生态峰会暨全球汽车电子博览会”由《中国汽车报》社主办，张江高科、爱集微、浦东新区投资促进二中心承办，11月7日-8日在上海张江科学会堂隆重举行。

(资料图片仅供参考)

本届峰会邀请了以半导体为核心的全球智能网联汽车生态链企业高管、知名分析师与投资机构、中外行业大咖参加，瞄准新智能汽车与能源汽车技术前沿，就科创+产业+金融进行深度交流，为汽车半导体产业发展贡献智慧和力量。同时，通过趋势分享、前沿技术碰撞、投资逻辑解读以及全球汽车电子博览会，共同探讨全球巨变下的汽车半导体产业链发展，为业界充分展示汽车电子最新发展成果与趋势，打造国际化一流汽车半导体领域展示平台。

其中，在11月7日举办的“软件定义汽车专场”，达索析统（上海）信息技术有限公司达索系统工程高级顾问魏周君做了题为《MBES建模的角度赋能汽车软件开发》的精彩演讲，以下内容为现场演讲实录：

魏周君：大家下午好，很开心有这个机会和大家一起来做一个交流。前面也说到了，在SDV里面，我们有大的方向，我们目标客户群体，Feature的变化，有场景的变化，座舱的变化，感知的认识，还有操作系统里面越来越复杂的操作系统的开发。在这个过程里面，方方面面都需要我们有理念的转化。

达索析统（上海）信息技术有限公司 达索系统工程高级顾问 魏周君

今天我只讲开发的方法，理念，以及我们可能用到的工具的一些变化，我不讲具体的技术。

这边我有三个议题，一是基于模型的系统工程MBSE，最近的一些发展的趋势。

第二个方面，讲一下我们在软件定义汽车里面MBSE的一些方法、途径。

最后说一下达索在MBSE，在SDV上的价值。

首先，我们看一下MBSE在汽车方面一些应用，现在越来越频繁的讲用户体验，那么车要怎么开发，以前我们可能有一个Benchmark对标，再修改它。现在用什么方法来进一步的挖掘客户的一些新体验或者说车要有什么样的新特征？软硬件怎么更好的设计满足我们未来所谓的开放性，可迭代性等等。另外，法律法规越来越多和成本直接挂钩。

在发展过程中，我们看到国外的厂家越来越多的注重所谓的MBSE，也就是系统架构建模在里面的应用，像雷诺，大众，包括日系一些，还有Tier 1中的一些企业，用系统工程的方法把新的工程开发的理念引入进来。

在国内也有一些的研究机构在提，如何用新的开发理念解决相应的开发问题。

现在越来越多的研究机构，或者是国内外的一些企业都在关注这个方向。

针对SDV我们怎么用MBSE中的一些方法。这个我想和大家做一个交流，可能每个人有自己不同的一些认识。

首先我们看一下这样一个运行的环境，我们未来的车，可能不止是一个物理的运输工具了，更多的作为一个载体，也不再只是第三空间还是什么。交通出行系统现阶段可能比天上飞的系统的复杂度要差一些。我们这个系统里面，可能要遇到一些软件，不止有车载，还有我们的云端，可能还有每一个用户相关的终端设备及软件设备，这些软件是我们要关注的点。

我们看一下这个过程里面，相应的软件开发过程里面的复杂度越来越高。这个模型的左边，是我们怎么定义相应的场景，这个就要影射更多的Feature出来，而这个Feature就是传统意义上的一些Feature。也有面向我们更多的智驾出行，或者是相应的一些更广泛应用的一些场景。

接下来的话，我们可以看到我们在系统性的设计这一块，其实是相当欠缺的。很多我们做的事情，可能也需要有相应的功能以后，才能一步一步的再往下做。

另外在这个过程里面，我们需要去进行我们相应的26262，要做设计的追溯，再到最后的代码，到测试，这个追溯链有没有被提出来。

我们在设计的过程里面，软件的设计，生命周期怎么管理，以及软件和硬件的设计过程，如何进行相应协同，是我们要关注的一些问题点。

谈到所谓的系统工程，我们要提一下MBSE，所谓系统工程提的是什么内容？系统工程就是跨专业协同的设计理念，我们强调不同的专业在我们设计周期里面要高效的协同起来。另外一个方面，我们要在这个过程里面，把我们系统的需求和相应的功能在早期就可以充分的考虑进来，或者是充分的分析清楚，正向的研发我们整个的设计和集成验证的过程。

第三，我们要考虑我们整个生命周期里面的方方面面，从它的最开始的设计，到最后的运输、交付、维护、报废的整个过程，我们要考虑整个的运行场景，从广度和深度的不同角度来分析它和定义它。

这三个方面，落实到我们技术或者是我们的工程技术上，就是技术的协同，全局的管控，还有一个是精细的设计，所有的过程里面的问题要尽早的归零和测试。

第三个方面，我们要看见我们开发的技术上的一些局部的，同时要看见我们应用和场景上的整体。从这三个角度，这个就是系统工程，希望在我们的工程设计里面，能够给大家一些另外的一个维度去思考。

我们展开来看一下这三个方面如何去落实。首先我们看一下所谓的既见局部又见整体。

现在的出行是多个系统交互的一个过程，所以我们要有相应的一些分析方法和工具帮助我们对多系统交互还有服务的层面进行相应的分析，接下来我们要定义到整车相应的结构和控制系统是什么样。

接下来我们有整车的MDU和电子电气的进一步设计。

再往下，延伸到我们的专业设计层面。这个过程里面，我们需要在不同的层级里面双向可追溯，同时可以提供我们实时、透明的管理能力。另外一个方面，我们需要有自己的系统行为仿真，基于数字技术的系统行为的仿真，在早期帮助我们发现解决相应的一些在后期才会花大量的成本做的事情。

在这个过程里面提一个核心的问题，我们在这个过程里面把我们不同的利益相关者关心的问题都收集进来，用同一个模型，去做我们的核心节点，不管是从多种生产线还是多种产品线，以及特征相关的，需求相关的角度还是和我们的安全性，以及验证相关的。还有传统逻辑功能相关的，这些利益相关者，都整合进来，如何整合进来？这样整合进来的优势就是我们协作和沟通的效率大大提高。

我们现在在开发的过程里面，不停的再做这些事情，但效率似乎不高。

这个里面还有一个关键的点，那就是我们引入了所谓的基于模型的方法。基于模型和基于文档的本质区别，就是我们把文档里面零碎的信息收集到了一个完整的模型里面，这个模型会相关描述我们的需求，描述系统的构成，接口，接口之间传输的物质、能量、信息，以及每一个模块具有的相应的行为，所有的这些信息都会在一个叫做系统建模语言的模型里面把它描述出来。用这个模型的语言，我们就可以方便的让不同的专业能够在早期进行相应的沟通，而且因为我们用的同一个模型，这个模型本身就有一致性、统一性，不是像文档那样你翻页寻找。而在维护文档的过程当中，从一个表格移到另外一个表格是非常痛苦的过程。我们要用我们的文档，或者是用我们模型，把我们原来这些文档的信息承载下来，加速我们的迭代，这是我们做所有工作的基础。

这个里面我们需要建哪些模型？首先我们会建什么？这个里面有一个定义，就是基于模型的系统工程，在整个的设计过程里面需求、架构用模型来表现，同时用模型来驱动我们的分析和设计验证的过程。

这个里面，我们做什么事情？我们对需求进行建模，这些需求变成我们的规格化，形式化，统一的管理在统一的数据库里面。我们建立系统的模型，描述了我们系统的构成有哪些，接口有哪些，接口间的关系有哪些，以及应该具有的行为有哪些。因为我们用的是一个统一的架构模型，所以这个可以很方便的从架构模型里面提取相应信息展示给不同的业务部门的人，比如说你是关心安全性相关，你可能就可以用这个模型去生成相应的表格，帮助你做早期的分析。

在这个架构模型基础上，我们可以添加一些相应的约束，一维的多物理场的关系，让这个模型早期进行仿真。有了这个以后，我们可以对关键的参数，像续航历程，扭矩，ADAS的一些碰撞的时间，可以进行早期的虚拟化仿真。这个基础上，我们优化性能。

有了这个模型，接下来就可以让它细化，进一步的在其他的专业上面做一些设计，变成我们自己详细的规则。

这个模型，或者是系统工程，并不是专门做某一件事情，而是起到粘合剂的作用，把所有的相关的工程结合到一起，发挥1+1大于2的效果，这个是我们需要建立的一些模型，我们有需求、架构、分析、协同相关的模型等等。

我们看有什么样的应用？首先就是这个架构模型里面，你可以看到我们的架构模型，描述的就是我们的系统以及系统的上下文和系统的相应元素。它描述的角度是我们不同的利益相关者关心的一些问题，通过不同的架构视角表现出来，同时架构里面又包含了相应的对这个架构需要满足的一些约束，和最后设计过程里面设计的决策，都会描述在里面。

具体来看，我们看到这个里面是我们一个相应的建模方法论，这个由我们的相应模型产生。根据这个模型的方法论，一步一步的产生模型。之后会得到相应的需求模型，描述需求，以及需求之间的一些约束。

接下来，我们描述系统的相应组成，以及接口。进一步把我们的组成和约束变成甬道图，承载我们的功能，以及他们之间的交互。

下面我们进一步的描述是我们每一个板块里面具有的行为，以及状态的切换等等这些信息。所有这些信息，是在同一模型里面，只不过用视图的方法把这些东西展示出来，这些都是车载的空调系统不同的表现而已，最后这些信息可以用文档生成的形式打印出报告。

下面我们可能会设计某一个详细的模型，需要多个模块用不同的协议来传递，我们的模型同样也是可以描述协议这个层面。刚刚说到两个模块之间，有各种形式。我们用模型的方式，把我们的协议描述出来，比如DDS里面用哪些定义者，哪些发布者，相应的数据类型等等。这些描述出来的协议，我可以进一步的把它导入到后面的RTI的框架里面生成代码，我们的设计，可能是一个ADAS系统，我们最开始是设计相应的一些用例，有一些功能我们用DDS的方法实现出来。我们建这些模型，最后可以导出到软件的框架，生成相应的代码。

我们刚刚说到我们进行协议层面的一些实现，另外一个方面就是可以在早期用模型的方法来优化整个算法。这个例子里面，也是用建模的方法论，实现一个道路保持最早期的状态期（音）。用这个状态期（音），我们驱动虚拟的车辆在早期进行道路保持算法的验证。

这个车辆有完整的动力模型，感知的模型，这个模型里面把算法添加进去就可以进行早期验证。

这个是我们运行的一个架构控制的状态机（音），是我们的整个测试的虚拟平台，它可能会在整个的算法过程里面进行道路保持和跟车。

这个是我们在早期对道路保持算法的状态机（音）的定义。这个是虚拟的驾驶的场景，有车道线检测，以及对车道居中的算法，要跟车，跟随前车的速度。我们会把方向盘打一下，它会根据算法达到我们要达到的目的。我们可以用工具实现动力学、感知的模型。算法的模型可以在这添加进去，这个状态机（音）可以导入到C苗L你可四（英音），里面可以进一步的系，生成代码，进行后续的开发。我们早期可以帮助你实现这个能力。

从这一步生成代码，大家觉得没有什么意义，你要想一下，我们这个状态机模型，在早期的时候和其他的算法模型，或者是其他的中控的一些模型，很多的状态机要联合仿真的时候，它的意义就产生了。因为多个算法交互到一起，它们之间的行为的表现会不会是你预期这个样子？如果用想象的方式，可能是不容易验证的。

接下来，我们在这里也有相应的东西。同样是虚拟的道路、传感器，在这个过程里面我们用一些感知的方式，把信息传输到算法模型里面，刚刚的状态机的模型存在Similar Linux，我们在里面进行一些开发，把这个里面的模型和虚拟的空间里面的这一辆车结合起来，然后进一步的验证更复杂场景里面一些表现。

在这个过程里面，可以给座舱加上一些捕获眼动，头动的能力，可以更方便的显示，比如说有一个操作台，我们加上VR的眼镜，可以在这个里面显示或者是模拟有人，无人操作的情况下我们这个ADAS的系统和驾驶人员的整个体验情况。

这边有一个视频，我不具体的放了。这个描述的就是虚拟的场景如何与Similar Linux进行联合仿真的能力。

接下来我们看一下，我们刚刚说的建立模型，一层一层的建立，让这些模型牵引我们的工作的意义是什么。我们在统一的一个数据源下面，把我们所说RFLP，需求、逻辑、功能的模型串联到一起，支撑着这个过程里面所有的业务操作。包括相应的需求的开发，或者是整车的架构设计，电子电气的架构设计，软件架构的设计，让我们用一套模型牵引整个设计。同时借用已有的一些工程管理，方便我们在这个过程当中的管理。

最后一个方面，说到我们所谓的多个专业的协同。这里提到一个关键的问题，不管是26262还是什么，提到端到端的追溯。我们想做到的追溯就是从我们前端，可能用多种工具已有的需求，到我们过程当中涉及到的需求、功能，逻辑组成的实现，包括物理的实现。以及我们最后的相应代码、模型如何在这个过程里面有效的整合到一起。我们也有一个视频。

这一块我们有一个端到端的追溯，可以从不同层级的需求，追溯到我们的Similar Linux模型，追溯到我们的电子电气的架构，追溯到我们的每一个代码，以及相应的测试，整个追溯链可以完整的拉通出来。

我们提供一个环境，支持这种完整的车载软件的全生命周期的覆盖，这里就和我们的SPACE有一个影射。我们在这个环境里面有支持软件相关的工程，有我们规定的一些系统架构的问题。还有系统层级关心的流程，还有软件面的一些流程，都会在这个环境里面来支持。

我们在这个里面把我们所有的软件的交付物和我们硬件的交付物，结构件的交付物整合在一起，实现我们面向采购，供应的一些完整的管理。

我们通过其他一些手段，实现我们相当于OTA的同步，你可以通过OTA的服务器往后端传输。

我们把前端的SPACE要求的系统层面，软件层面的设计，我们整车的管理和OTA进行结合。

这个过程里面，帮助我们进行一个全生命周期的持续集成管理。

同时你可以看到，两个环境里面，他们负责的范围不一样，我们整车的集成环境里面，负责整车的相应架构、问题，还有一些电子电气的架构的一些设计问题。另外一个方面，我们软件相关的快速迭代环境，我们可能关注软件相应开发的管理流程，以及相应的变更、CRCD过程，和我们开发人员必须去操作的一些开发工具他们之间的关联关系。

同时在这个过程里面，我们也是有比较完整的管理链，我们实现了所谓的LM IN PRM（音）的过程，这个过程可以实现软件的开发，快速的迭代，我们可以把我们软件开发的交付物和整车开发的交付物结合起来，不会出现以前软件和整车产生比较大的割裂情况。

因为在未来的情况下，可能软件要和我们的硬件，和我们的结构结合。不管是座舱，还是智驾，整个架构的一些选用也有一个快速迭代的过程，我们要用一种更好的方法把整个的糅合到一起。

最后看一下我们达索对软件定义汽车在MBSE上面的策略和价值。核心的点就是这个样子，我们用一个达索3DE（音）的平台，贯穿架构建模的过程。同时让我们在这个过程里面定义的这些模型，不管是需求，功能，逻辑相关，还是和交付物相关，都可以有联系性。和我们外部的一些业界标准、工具有一个开放性的接口，这个是我们达索对如何在软件定义汽车上面用MBSE的一些核心的理念。

落实下来，主要就是分三个方面，我们定义为一个多尺度的架构建模，这个从我们的整个场景的定义，再到特征的定义，再到功能，用例，到最后的实现，我们通过不同尺度的架构建模的工具和方法，帮助我们实现。

另外一个方面，我们所说的这种多专业的协同设计，用模型牵引不同的专业，实现他们的追溯性，协同的关系。

还有就是提供更多的虚拟仿真的方法，让我们在微模型末端要做的事情，尽早在早期得到权衡验证。

这个里面概括就是我们的架构建模，有我们需求和系统的建构，多专业的协同里面有不同的视角模型，以及我们从架构模型到不同专业模型当中的一个下发或者是联动，还有一个方面是提供我们一些分析的模型，帮助我们进行指标的分析和性能的评估。

像这个图里面，这个是我们的传统的V Model，我们以前很多的东西都在后面做，前面的迭代利用的是大量瀑布式的基于文档的方式，我们基于模型的方式给我们的好处就是，在前期能够在每一个阶段用我们的模型，加速我们的分析。另外一个方面就是把我们以前在V Model后面做的事情提早到V Model的早期进行，再进行早期的权衡验证。

这个是我们达索的MBSE应用到SDV一些价值，简单的来说就是首先我们构筑的是一个正向开发的能力，我们会描述我们各个阶段需要不同的模型。下面我们构筑面向于智能网联汽车的一个架构设计的能力，在这个里面，可能有我们不同的、基于特征的产品线的分析。还有我们相应的不同层级的软件开发的过程，以及我们软件的一些早期的定义和仿真的能力。

最后，也是比较重要的一点，还是想通过另外一种不同的设计方式实现。因为这个基于模型的设计有一些特有的价值，也就是说我们能够用模型把我们以前用文档写出来的模式记载下来，加速迭代。

另一方面，我们以后的这种产品可能都是一些高度智能化的产品，它本身需要我们用一些不同的方式来表现，我们现在做的很多的东西，可能是人写的文档，可能是一个表格，没有意义。我们用模型承载下来以后，每一个表格的信息有语法语义，背景关系，这样有利于我们以后面向更复杂的系统，或者是复杂度超过我们以前机电系统若干倍的开发过程里面，更好体现我们工程师的创造能力。这个是我今天要分享的，谢谢大家。

（注：以上速记内容未经本人确认）