基于Simcenter Analyst的整车快速仿真平台

随着西门子工业软件的Simcenter（这里主要是指Amesim，Analyst，Architect和Studio等，本文不涉及3D，CFD或Test的内容）平台被越来越多的汽车OEM客户应用到日常的车型开发工作中，近些年一些更深层次的需求也从OEM客户的研发工作中提炼出来。

作为使用Simcenter最为频繁的部门，诸如整车集成部门，动力总成部门，热管理部门，以及空调部门，这些部门的日常仿真及分析结果经常需要和不同的专业组以及负责车型项目的同事讨论交流，内容涉及油耗电耗、低温性能、多属性平衡等关注点。

但每个团队的人力物力资源有限，面对众多在研车型的前期仿真分析，如果还是依靠传统的开发方式：比如从零开始收集车型信息，根据动力架构构建模型，设定参数和工况，运行仿真后给出初步结果；这种方式对于有同时多个车型或架构的仿真任务的部门来说，已经不能满足需求了。

因此，这里提出基于Analyst的整车仿真平台，将模型开发人员和模型使用人员的角色剥离开，通过对不同OEM客户的实际分析需求（比如动力性，经济型，热管理，低温续航，低频NVH等）定制化开发的快速建模及仿真平台，可以让系统仿真的CAE工程师专注在模型开发领域，而大量的部门外部需求，比如来自其它专业组的同事或者车型项目的同事，可以通过此定制化的平台快速建模、分析并得出初步结论。以此可以快速响应不同的仿真需求

方案的出发点

无论是国内还是国外，拥有大型研发团队的OEM或Tier-1供应商，在数字模型开发的过程中，都会面临如下几个方面的挑战（见图表 1），比如：

图表 1 – 目前系统仿真模型开发和使用所面临的一些实际挑战

→ 模型的参数是否是最新的，和当前样车一致，哪些模型的结果是经过试验验证过的？

→ 不同专业组关注不同的车辆性能及属性，一个或几个模型满足不了所有兄弟部门的需求

→ 企业内部不同工具或开发平台的模型共用性问题

→ 对于需求最迫切的模型使用者来说，比如项目工程师，迫于模型开发的较高门槛或车型项目时间节点要求，而无法快速获得想要的分析结果

。。。

通过对上述问题或者说需求的归纳和分析，可以看出主要矛盾点就是集中在模型的开发需要专业人员或工具，模型数量版本及涉及的参数及试验数据大量庞杂，而且只会越来越多。不同部门的工具和模型不同，之间交流存在障碍需要打通。

简单来说就是下方图表 2中所展示的：我们希望仿真模型可以通过某种降低门槛的方式更广泛地用在研发的每个部门及每个环节，这样做可以让模型开发人员专注在车辆模型或子系统的细节；而有仿真需求的项目工程师可以不必花时间学习模型开发的专业技能而是直接使用模型，进行配置和选择后，快速获取结果。

图表 2 – 系统仿真工作流程化后的收益

同时，通过标准化的开发流程，可以让模型复用在任何新车型或新构型中；即便是不同平台的模型（比如Simulink的控制模型），也可以通过提前定义好接口模块而实现闭环模型的开发和验证。

除此之外，平台化的车辆模型开发可以更好地管理所有车型的：不同阶段即不同版本的模型，对应的参数设定，运行的工况，和其它模型共仿真的结果以及对应的整车或台架试验数据等等。

为实现上述目标并解决实际客户问题，利用Simcenter Analyst以及Amesim等工具作为开发平台，由SISW的工程服务团队进行定制化开发，即可完全响应OEM客户在日常仿真建模及模型管理方面的各种需求。

方案的实施

如果从整体的开发工作角度来看，如图表 3所示，在从零开始的设计工作中，先是要确定车辆的架构。无论是对于已有的架构优化，还是全新设计开发的新型架构，都可以通过Studio和Architect来实现。

图表 3 – 系统仿真解决方案

接下来通过专业领域的建模分析工具来完成元部件/子系统/整车的模型开发工作，比如Amesim，Flomaster或SLK等。

最后就是模型的使用阶段，这一阶段也就是我们需要基于Analyst做定制化开发，根据客户需求来完成平台的搭建。

谈到具体的开发工作，至少涉及到图表 4所示的诸多方面，比如某种子系统或元部件的模型参数如何检索及发布；不同车型或架构下提供具体几种参数组合的选择，可以仿真计算哪些车辆属性；每个属性涉及到哪些国标工况和企业内部工况…

图表 4 – 平台部署中需要考虑的输入

而且，所有车企的研发部门都是具备多种工具链来支持日常开发工作，需要有效协调利用非西门子工具开发出的模型来支持平台的建模仿真分析工作；另外对于企业内部已有的一些前后处理脚本，比如Matlab的或者Python的也需要继承，不要重复开发浪费资源。

最终呈现出的基于Analyst开发的平台架构如图表 5所示，其中底层为模型开发工作中前两个阶段完成的输出物，即架构和子模型（也包括已有的脚本）。这些工作物是系统架构工程师和模型开发工程师所负责的。而上层就是基于Analyst搭建的使用平台。

图表 5 – 车辆模型开发平台的架构示意图

在上层平台中，可以根据不同车型项目或者架构类型组合出所需要的虚拟车辆模型，并且可以从属性/工况库中设定需要计算的指标，以及对应的车辆即子系统的参数配置。

从这个示意图中，可以很明显地看出模型的开发及架构是作为底层的基础工作，上层的模型使用者是无需了解或接触底层的内容。对于使用者开放出来的工况选择，车型项目，车辆模型以及参数配置这些是可以满足其不同仿真分析需求。

Analyst具体呈现出的界面根据客户定制要求的不同而不同，这里就不具体展示了。

方案的收益

如果按照前面介绍的内容完成了平台的定制化开发，那么模型的使用者可以仅仅通过简单的几个步骤，比如模型选取，参数组选择，工况和属性选择就能快速出结果进行分析。

如果是同样类型或构型的车型，只不过有了新的单品数据或者设计数据抑或是新一版的控制策略或标定参数，那么也可以快速地通过模板模型内容的要求填入到系统中，来比较两版不同参数设定下，模型的结果有何差异。

从图表 6中我们可以看出通过预先定义好的工况以及车辆模型配置的选择，生成大量的组合仿真结果，用来评估不同车辆属性KPI的优劣。当然，能够实现此目的的前提是架构工程师提前规划好不同的构型，以及需要分析的属性都包含哪些，并且不同的子系统及元部件需要详细到什么程度，如果分级等；同时还需要有模型开发工程师根据架构的要求，把每个单独元件需要表征的物理现象按不同详细程度的需求进行合理实现，定义好接口，确保模型使用者可以按需实现不同组合；尤其是像有些车辆相关的属性或指标是有互相矛盾的，那么如何能够较准确地用虚拟模型预估或预测，就要看模型开发工程师的功力了。

图表 6 – 模型使用者可以快速获取分析结果 – KPI

在图表 7中展示的更具体的一种使用场景：比如对于某种混动构型，在工况方面需要考虑最基本的车辆动力性和经济性的要求选择了五种不同的工况；另外，对于整车静载荷以及电池容量分别又有几种不同组合。这类仿真分析可以很容易地通过平台已经做好的模型库以及参数及工况设定功能来实现批处理，并且最终的指标结果可以通过直观的雷达图来呈现。

图表 7 – 模型使用者可以快速获取分析结果 – spider chart

如果只是这种单一的需求，对于模型开发人员来说很容易实现；但当整个部门或整个研发技术中心都需要快速仿真评估不同车型构型的属性计算结果，可以想象这就不是一两个人可以随时响应的，而且也不是所有属性的分析模型开发人员都有相应的专业背景。

总结

行业越来越内卷的大潮下，速度依然是王道。既然不是所有的人都能用模型，会用模型，或者想用模型；那就开发出便捷易用的整车模型仿真分析平台，不用深入到细节，而是相关的人员可以直接拿来用就能达到目的即可。但毕竟是定制化开发的平台，需要工程服务的有经验的工程师和客户事先多轮沟通，收集好需要考虑的车型架构，车辆属性，元部件特性，接口信息，试验数据等，才能系统地准确地搭建好这个平台，同时还应该考虑未来的基本可扩展性：比如模型或数据的保密等级以及分享时的安全性，后处理方式的可拓展性，自动生成报告模板的可编辑性等。

总之，随着主机厂的研发工作逐渐地数字化虚拟化，基于模型的开发方式已经几乎被所有行业内客户所认可，那么如何高效便捷地最大化利用起这些模型也许就是每个OEM客户的整车性能或系统仿真专业组下一步需要考虑的重点。