同样地，需要对开环车辆物理模型进行验证，确保模型精度及求解的稳定性，如图表7所示。在和经济性属性相关的所有重要变量，都要进行比对。这里需要额外提一句，像这种比较简单的模型，状态变量很少，通常求解都会很快即便做大量的变参数仿真，也基本不会遇到模型求解卡住的问题。如果研究的车辆属性或性能包含比较复杂的系统，系统之间还有耦合：像热管理系统的仿真，除了每个回路自身的循环，还会有回路间的耦合计算（换热器，散热器，chiller等）；像冷媒回路涉及到相变，求解会相对更复杂更耗时。
相对简单的应对办法就是在开环物理模型上多做一些仿真工况的测试，设计并设定好边界条件，通过batch或者脚本的方式，来检验模型求解的稳定性以及求解时间是否过长；也可以评估不同工况下的结果是否合理，符合预期。这是在集成控制模型前需要提前做好的准备工作。
图表7 – 车辆物理模型仿真结果和试验数据对比
当两部分模型分别完成各自的开发和验证工作后，下一步就是集成。如图表 8的示意图所示，如果前面两步走的工作打下比较好的集成基础，无论是控制器模型还是车辆物理模型的精度和适应性都达到了集成要求，那么在这一步搭建闭环模型时就可以减少潜在的风险。
图表8 – “车辆 + 控制”的闭环模型示意图
除了需要替换原本两个模型的接口信号外，还要注意一些容易出错的地方：比如踏板的信号是0~1，还是0~100；发动机/电动机/发电机的扭矩正负方向；在跑一些新工况的时候是否有一些不合理的特性数表外插导致结果异常等问题。调试的过程也要遵循由简入繁的原则，比如从纯电模式开始，先确认动力系统在控制器结算的输出下是否和整车负载匹配，车速是否能跟上，驾驶员模型的输出是否能和试验数据匹配上等。再下一步可以调试发动机启停，离合器作动，制动能量回收等闭环系统的表现。
图表9 –闭环模型和试验数据对比
Zui终可以通过闭环调试过程，得到类似如图表 9中所示的仿真结果（车辆模式和离合器状态的数值定义与实车不同）。当然，这里只展示了一个工况的验证结果，如果在前期开发和试验规划过程中，尽量多覆盖一些循环工况或企业特定工况，这样作为模型验证的依据可以提升闭环模型的精度及求解稳定性。
就是利用闭环模型可以做参数敏感性分析，比如像车重，阻力，pedal map，初始SoC，SOC启发动机上下限，模式切换延迟时间等无论是设计参数还是控制参数，都可以快速地通过批处理或脚本来实现批量分析，甚至可以作为标定的参考依据或探索方向。
05
拓展到多属性平衡分析
和提升模型开发效率及应用范围
前述文字可以算是概括性地介绍了对于控制模型和车辆模型集成为闭环系统时一些经验性的步骤和心得。毕竟只有一个属性或单一性能的分析是无法适应OEM未来甚至现在的需求。如果要进行拓展，通常是将整车热管理系统及相关性能和动力部分以及控制策略整合成一个“多属性”的整车模型，这样就可以通过虚拟模型的结果，来评估和分析这种相互矛盾的属性。
图表10 – 动力+热管理+VCU功能控制模型
如图表 10中展示，这里将某款混动车型的动力系统，和主要的热管理循环回路系统模型（发动机冷却、电池直冷、电机电控冷却，空调冷媒及乘员舱），再加上整车VCU的一些基本控制集成为一个VEM（整车能量管理）的模型。熟悉Amesim的人看到这个截图应该就能八九不离十的猜到这个模型的状态变量数目……嗯，200+
这个模型还没有加热管理的控制策略，可以想象如果我们再引入新的控制策略，那么模型的调试时间，单一工况的求解时间都可能会增加不少。并且，这里只是一款车型的一个模型；如果管理几款不同车型，且控制策略及标定也不一样，每个不同部门或工程师关心的指标也不一样，如果希望通过仿真来给出方向，甚至指导设计，即便是在已有完整的模型上进行更改和升级，这个工作量也是相当巨大的。随着项目和数据的累计，车型对应的模型版本也会越来越多，只靠文件夹和文件名以及开发工程师的个人经验来管理和维护，是无法确保开发工作的稳定性、正确性以及高效性的。
当OEM的整车部门在数字化的研发中逐步积累了众多车型的数字化模型，那么面对的情况很有可能就是如图表 11所展示的。
图表11 – 整车数字孪生模型的复杂度
OEM未来甚至现在遇到的挑战一定会比这个图上更加复杂，系统间的强耦合关系（比如能耗和热管理）也需要更加深入和全面的探索分析。相信对于上图中每一个子系统或者每个单一属性，都有非常在行的领域专家可以解决实际工程问题；或者每个CAE工程师对于单独一个子系统或单一性能也有能力构建准确的模型甚至具备一定预测性。但如何把这些专长和过往项目经验有机整合，通过类似模块化的实施方式来各取所长，Zui后再集成出专门针对模型使用者需求的特定模型，这个是目前Zui需要实现的。
如图表 12中所展示的，基于Analyst和相关的专业平台工具是面对上述挑战的一个zuijia选择，并且已经在国外的一些OEM客户中得到了很好的应用。即可以从零开始规划初期阶段需要哪些Zui基本的架构、模型元件、工况、设计参数组等基本因素，先将平台搭建好，并且在日常的仿真分析的反馈中来决定下一步的拓展方向；也可以把现有的车型模型及数据库的积累信息做相应的评估和分类，将其移植到Analyst为基础的定制化平台上。这样除了可以系统地将不同架构、属性及复杂程度的模型分门别类的管理好，还可以将设计人员、开发工程师和模型使用者的角色区别开，确保开发工程师可以专注于模型内容的丰富和升级工作，而使用者不必研究细节就可以快速选定其所需的车型架构、总成的组合、工况和参数设定等开放的变量，并迅速获得仿真分析结果。
相信随着国内OEM客户的需求不断更新和提升，这种定制化的平台可以更加发挥出整车部门的开发能力，提升开发效率，管理、维护和支持多个车型的平台项目，实现从“数字双生”到“数字孪生”的迈进。