每日快播：达索系统基于系统工程的AUTOSAR设计端到端解决方案

"达索系统的AUTOSAR Builder(简称AB)工具聚焦于RTE层以上的开发过程，对于RTE层以下的部分，达索系统希望和合作伙伴或其他友商进行联合开发与设计，共同为客户提供更有创造力的数字化环境。”

【资料图】

达索系统MBSE高级业务经理魏周君介绍，AUTOSAR Builder是达索系统旗下一款基于Eclipse的开放、可扩展工具套件，用于设计和开发符合AUTOSAR CP&AP标准的系统和软件，该工具基于Artop 平台实现，可以同其他符合 AUTOSAR标准的工具无缝集成。

魏周君 | 达索系统，MBSE高级业务经理

以下是演讲内容整理：

达索系统在AUTOSAR开发方面的工具

首先简单介绍下达索系统。作为领先的数字化解决方案供应商，40年来达索系统一直致力于汽车行业创新工具的研发支持。大家耳熟能详的一些工具都属于达索系统或达索系统合作伙伴。在AUTOSAR组织成立伊始，达索系统就是其中一员，我们一直作为领导者之一参与相应的AUTOSAR相关活动，包括标准制定、工具开发方面的支撑，达索系统陪伴着AUTOSAR一起成长。

关于AUTOSAR的概念——无论如何CP和AP都会分为相应的层次，最底层和SOC或传统的控制器相关；中间有底软或中间件；再上层有RTE层的定义；顶层有应用层的定义。

图源：达索系统

达索系统的工具聚焦在RTE层以上的开发过程，而RTE层以下会和合作伙伴或其他友商工具联合开发。下图是经典CP开发的过程，蓝框里所示步骤六以上都由达索系统的工具完成，包括RTE的开发，其优势更强调系统层面的开发，帮助大家搭出更完整的系统架构，再到单个ECU完成抽取，再交给后面其他的工具。

图源：达索系统

下图是典型的两种场景，其他友商工具可以交付给达索系统AB典型的数据类型或者平台的数据，AB基于所有文件所包含的信息，可以进行后续的设计工作，包括数据类型上进行更新设计，一层一层的完成后，再把相应的网络信息或其他和硬件相关的信息读取进来，再完成相应从软件到硬件的结合，之后进行相应的ECU抽取，从整个系统框架里抽取单个的ECU，再交给后面的工具完成BSW层的设计。

图源：达索系统

另一种模式是在相应的BSW底软工具里进行服务开发，有了相应服务开发后可以把其类型的定义交付给AB，这样AB就可以在早期设计中把服务添加进来，这些服务可以帮助我们早期定义服务接口和诊断等更详细的设计，可以沿用或直接复用在地软软设计工具里已经定义好的内容。后续的工作基本上一致。过程中肯定会牵扯到不断的迭代，后端的工具又把相应的BSW设计进行了修改，对前端的PORT进行重新定义，从而进一步的迭代。整个过程中，AB都支持元素级别的版本对比，通过这样的机制，再加上数据库保证在底软层和SWC层开发过程中，两边数据信息版本保持一致，从而保证开发的正确性。

MBSE和AUTOSAR结合，达索系统的解决方案

众所周知，软件设计本身处于系统开发，在此之上有系统的开发，还有其他项目管理、变更管理等等。对于整个软件开发而言，面临的问题是多方面的。

一是软件设计过程本身开发和治理问题；二是系统层面和软件层面协同开发的问题，包括设计、仿真以及快速迭代的能力；三是整个系统设计和软件设计如何在同一个平台里实现，从而加速整个开发过程和提高研发质量的问题。

首先看一下软件本身开发过程问题，这涉及了开发过程端到端的追溯能力。一般来说，开发的需求、任务、变更或问题都存储在不同的工具里，每个阶段，不同的工具，会产生不同的设计交付物，比如代码、模型和输出的文档，如果要实现好的软件设计过程治理，就需要在开发的过程中把每个阶段的追溯链进行完整的把控。

达索系统提供的解决方案，是把很多异构工具间的关联关系有效的整合到一起，把数据库里的需求以及原有设计文档里的需求和电子电气架构、设计模型、软件的代码等等形成完整的追溯链，可以从需求到代码以及中间的分析交付物形成追溯，同样可以从代码追溯到最原始的需求。

第二方面进行系统架构的设计。如下图所示，软件的设计在右下角，上端有软件架构的设计，下面有AUTOSAR的设计。再往上层有整个系统以及整车、车所在环境的定义，我们把它理解为智能出行或智能出行的场景定义成L0层，整车本身可以是L1层，车的部件或大的子系统定义成L2层，最后一些部件的实现是L3层。达索系统的解决方案会提供完整的建模和分析，同时提供方法论的支持，让大家更有条理的完成该过程。

图源：达索系统

L0层是针对智驾场景的仿真，我们可以用UAF体系级的设计框架帮助大家分析企业的策略是什么，来定义需要怎样的出行服务，以及该出行服务提供给客户怎样的价值网络。

接下来，定义具体的车辆本身，可以进行更详细的分析。此处略过这层，直接到车辆的子系统分析，如果以ADAS系统为例进行分析，我们会对ADAS系统本身的需求进行分析，定义ADAS系统运行的过程和哪些系统进行交互，以及在交互过程中的功能链。每个功能链又需要哪些相应的硬件去承载，我们会进行功能链以及硬件构成接口的分析。再往下到了解决方案域，会定义ADAS系统可能有哪些软件的控制逻辑，这些控制逻辑可以进行早期的分析和仿真，基于状态机分析多个ECU的行为交互，因为，ECU的行为间会有相应的触发，当ECU的数量到一定程度或者整个SOC、超算的HPC的算量大到一定程度时，就会有多个程序的状态机进行交互的复杂场景，需要进行早期的分析验证。

L3层会进一步的把ADAS系统再打开，关注于SWC或软件开发的过程。此时，需要定义软件的功能场景，接下来更详细的定义软件的需求，它的接口以及哪些软件用AUTOSAR去实现；哪些软件用其他中间件实现，以及中间件和应用层的接口等等。定义的每个元素都是有语意的实体，元素定义完后可以进行大团队元素级版本的比较和协作，进行完整的追溯。同时可以把设计的过程和安全性以及软件信息相关的设计规范结合到一起。

最后通过建立的模型生成AUTOSAR的文件；或者把状态机生成C代码，状态机生成的代码就可以直接作为算法进行后续的编译和运行，这就是我们在硬件和软件拉通方面的解决方案。

最后，我们知道软件最终是要交付的，要提供到产品上。达索系统的解决方案可以和Git或其他的软件管理仓储进行结合，可以直接把软件作为交付工件PART提供到整车的BOM上，把硬件、软件和其他的交付件整个的管理起来。我们的中间层提供从需求到每个元素，包括软件、硬件完整周期的追溯链；同时可以管理测试过程，再上面有变更的管理、问题的管理以及项目的管理。我们会整合起来提供给大家一站式的平台。

图源：达索系统

达索系统的未来展望

简而言之，我们想提供给我们的用户的是从体系层面到系统层面，再到子部件、软件以及软件到开发一系列的数据连续性；同时提供全周期的追溯，基线的管理以及工程管理过程的结合，提供工程研发与工程管理过程相结合的完整解决方案。

达索系统的工具链集合除了今天提到的AUTOSAR工具，也会和其他的友商、合作伙伴互通有无，与其他的友商形成更好的解决方案，共同为我们的客户提供更有创造力的数字化环境。

（以上内容来自达索系统MBSE高级业务经理魏周君于2023年3月14日-16日在2023第四届软件定义汽车论坛暨AUTOSAR中国日发表的《达索系统基于系统工程的AUTOSAR设计端到端解决方案》主题演讲。）