2023年3月14日-16日，2023第四届软件定义汽车论坛暨AUTOSAR中国日盛大召开，达索系统亮相本次论坛。
达索系统大中华区战略客户制造业务高级总监包大石接受了盖世汽车访问。在采访中，包大石表示，“科技是第一生产力，达索系统作为一家科技公司，推出的3DEXPERIENCE平台为企业和人们提供协作式虚拟环境，通过一体化协同平台打通不同专业之间的工具链，助力汽车行业从软件设计到开发流程各个业务模块的可持续创新。”
包大石 | 达索系统大中华区战略客户制造业务高级总监
达索系统大中华区MBSE高级业务经理魏周君在会上进行了《达索系统基于系统工程的AUTOSAR设计端到端解决方案》的主题演讲，分享了达索系统卓越的解决方案和独特的技术主张。
达索系统基于系统工程的
AUTOSAR设计端到端解决方案
"达索系统的AUTOSAR Builder®️（简称AB）工具聚焦于RTE层以上的开发过程，对于RTE层以下的部分，达索系统希望和合作伙伴或其他友商进行联合开发与设计，共同为客户提供更有创造力的数字化环境。”
魏周君介绍，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上，把硬件、软件和其他的交付件整个的管理起来。
“我们的中间层提供从需求到每个元素，包括软件、硬件完整周期的追溯链。同时可以管理测试过程，包括更上层的变更管理、问题管理以及项目管理。我们会整合起来提供给大家一站式的平台。”
达索系统的未来展望
