控制策略模型在整车性能及属性仿真中的作用浅谈

Part.1/ 为什么要集成控制策略模型

在日常的仿真分析中，无论是整车的控制策略模型，还是总成或子系统的控制策略如热管理、BMS、MCU等模型都越来越紧密地和物理模型的开发耦合在一起。过往的整车模型开发，控制策略的部分常被简化甚至基本忽略；但随着新能源车车型、配置及工况要求越来越复杂，仿真任务也日益增多；而且任务内容也越来越细分，比如单独研究某个总成的控制策略影响下的闭环系统输出，甚至是元部件单体在控制器调节下的闭环特性。

本文要讨论交流的内容是站在整车性能的仿真计算需求上，如果将策略部分集成到整车物理模型中，这种工作可以如何开展，以及评估及分析整车闭环后的计算结果；而不是讲解策略模型的开发和实现。

作为性能仿真或者属性分析的工程师角色，通常来说，控制策略的输入是仿真模型的边界条件：在定好模型的参数，初始条件以及工况后，执行机构的命令首先来自于试验数据，目的是为了验证物理模型的准确性。但该步骤完成后，物理模型具备一定的精度并准备用来进行性能预测的计算时，简单的边界输入比如给定某个扭矩、转速、开度等这种设置方式，就不能满足仿真需求了。

而且模型的内容需求会随着不同车型的分析需要会逐渐庞大并越发复杂，开发工作也是要求尽量frontload，这样就会要求系统仿真工程师如何有效合理地集成不同车型不同项目甚至不同部门的分析需求，将“控制 + 被控对象”的闭环系统模块化，定制化；这样才能从容应对未来可能更加迫切且更加多样化的整车集成仿真要求。

02、功能级别控制模型的开发和应用

根据以往的项目合作经验，我们可以试着将控制模型集成粗略地分成三种场景：最基本的是功能级别的控制模型；最完整或者说最贴近实车的是完全的Simulink（后简称SLK）控制模型；那么夹在中间的可以根据实际情况，比如掌握控制策略描述文档的多少，现有控制模型的完备程度等因素，可能需要定制化不同复杂程度的模型来适应闭环分析的需要。

图表 1 – 功能级别控制模型

这里提到的功能级别的控制模型，如图表 1所示，其应用目的主要是为了配合车辆基本性能比如动力性经济性的快速仿真和分析。无论是传统车的EMS/TCU，还是新能源车的VCU/FCU，都可以通过这些现成的控制元件模型和发动机/电机/电池等物理模型快速构建出整车模型，可以省去开发策略模型的环节，直接设定控制元件中的参数就可以看到对结果的影响。

但是此类模型没法修改或更新内部的逻辑，只能设定开放出来的参数，比如VCU里启停发动机的SoC限值等。而且车辆的混动架构也有各种不同的构型，此类封装好的控制元件不可能适应所有种类，需要结合信号、逻辑、数表及状态机等扩展功能来配合才能实现特定的控制功能。

03、完全SLK控制策略模型

在拥有完全SLK控制模型的情形下，可以支持的开发工作就很多了，比如直接搭建MiL环境，用接近实车的控制策略来驱动仿真模型；或者提取出只和仿真目的相关的策略模块来进行MiL集成，这样既可以让模型轻量化，还可以节约调试时间。

图表 2 – Simulink接口模型

这种模式的集成工作一般会碰到可用性的问题，需要对模型做调整或简化工作。因为，通常完整的SLK控制模型一般来自于控制开发工程师或者标定工程师，其原本的用途是为了确保控制策略的实现在逻辑上正确的，以及代码在烧写到ECU后通过调参可以达到车辆设计的预期性能。这其中除了包括应用层的完整策略外，还有通讯、诊断等其它功能模块；如果想要集成到MiL环境中，需要对模型进行适当的调整，因为有些策略是MiL环境下无法调试的，这些策略或是和硬件相关的功能，或是和物理模型没法有效关联。

比如由于车辆物理模型本身并不能包罗万象，尤其是针对车辆单一属性所构建的模型通常都是相对简化的。例如，对于动力性经济性的计算，可能工程师们只关注车辆的速度、加速度、油耗/电耗、发动机/电机/发电机的扭矩和转速，电池SoC以及所有高低压电气网络及负载的电压电流等物理量。稍微复杂一些的可能包含一些简单的热管理回路来计算温度，压力和流量的结果。但这些量即便全部反馈给完整SLK控制模型，跟实车上相比，也是远远不够的。大量的传感器信号，状态标识及CAN信号等都是控制策略在运行计算时所需的输入，如果车辆物理模型不能给出，则需要对策略部分进行简化，或者手动屏蔽一些非相关的模块，但这种工作需要对控制模型本身非常了解，不然很难做到有针对性的简化。

04、多级复杂程度的控制模型

上面两节提到的控制模型要么是比较简单的功能级控制模型，只能完成非常有限的工况计算和分析；要么是完整庞大的SLK模型，可能需要大量的调整和更新才能匹配车辆物理模型进行仿真。对于系统仿真工作来说，由于分析任务的属性、目标、工况及精确度等因素的要求，不可能非此即彼地去使用上面两种模型，那么自然会衍生出对于不同复杂程度控制模型的需求。

早些年还有一个客观制约是通常作为车辆属性或性能的仿真分析工程师，其建模分析的软件工具和控制开发/标定工程师的工具是不一样的，而且做物理建模的仿真工程师不具备策略模型开发的能力和专业背景。但现在随着建模仿真软件工具或平台的功能越来越多样化，不同软件间的接口也更加成熟稳定，已经可以很快速高效地对控制模型和被控对象模型进行集成。而且现在的仿真平台功能多样化，在同一个平台上同时开发策略模型和车辆模型也可以完成许多闭环系统建模仿真及分析的任务。

这里先分享一些想法和过往项目的心得，有感兴趣的读者可以找机会一起讨论。

在开发模型过程中，有关于控制策略的输入除了以模型的形式呈现外，还可以有流程图或特性表格（也是标定项）来表示策略的执行过程。如下面图表 3所示，在某款混动车型的整车控制器VCU的逻辑实现中，可以依照此控制描述文档中的流程图、特性表以及相关的逻辑。这里并不是要构建非常复杂的车辆模型，或者对多个属性进行同时评估或优化，而是只以整车经济性（热机）的分析目的进行建模。

图表 3 - 控制策略/逻辑描述

利用信号、逻辑运算、算术运算再配合上状态流图，通常就可以实现常规的、常用的控制模块，如图表 4所示，这里在AMESim平台上实现了一些基本的VCU控制模块，包括车辆模式切换，扭矩分配以及再生制动等。

图表 4 – 控制模型 (AMESim)

并且针对实现的逻辑功能，需要有数据对其进行逻辑验证及功能验证。这里因为有实车的试验数据可做为验证的依据，所以可以将试验数据作为策略模型的边界条件，检验实现的逻辑计算是否能和试验结果匹配。如图表 5中所示，将车辆模式和扭矩分配的计算结果与试验数据进行了对比。当然，仿真验证要尽量多地覆盖典型的车辆工况及使用场景，这样才能有利于提升模型的精度；只有确保策略模型和实车数据的误差在允许的范围内，才可以考虑下一步的集成工作。

图表 5 – 策略模型输出和试验数据对比

车辆物理模型的开发是可以和策略模型并行的：由于此款车型的建模只以热机的经济性为分析目的，因此模型的构建也是相对比较简单的。根据架构和设计参数以及总成的特性数据，搭建出如图表 6所示的模型。

图表 6 – 车辆物理模型

同样地，需要对开环车辆物理模型进行验证，确保模型精度及求解的稳定性，如图表7所示。在和经济性属性相关的所有重要变量，都要进行比对。这里需要额外提一句，像这种比较简单的模型，状态变量很少，通常求解都会很快而且即便做大量的变参数仿真，也基本不会遇到模型求解卡住的问题。但是如果研究的车辆属性或性能包含比较复杂的系统，而且系统之间还有耦合：像热管理系统的仿真，除了每个回路自身的循环，还会有回路间的耦合计算（换热器，散热器，chiller等）；而且像冷媒回路涉及到相变，求解会相对更复杂更耗时。

相对简单的应对办法就是在开环物理模型上多做一些仿真工况的测试，设计并设定好边界条件，通过batch或者脚本的方式，来检验模型求解的稳定性以及求解时间是否过长；同时也可以评估不同工况下的结果是否合理，符合预期。这是在集成控制模型前需要提前做好的准备工作。

图表 7 – 车辆物理模型仿真结果和试验数据对比

当两部分模型分别完成各自的开发和验证工作后，下一步就是集成。如图表 8的示意图所示，如果前面两步走的工作打下比较好的集成基础，无论是控制器模型还是车辆物理模型的精度和适应性都达到了集成要求，那么在这一步搭建闭环模型时就可以减少潜在的风险。

图表 8 – “车辆 + 控制”的闭环模型示意图

除了需要替换原本两个模型的接口信号外，还要注意一些容易出错的地方：比如踏板的信号是0~1，还是0~100；发动机/电动机/发电机的扭矩正负方向；在跑一些新工况的时候是否有一些不合理的特性数表外插导致结果异常等问题。而且调试的过程也要遵循由简入繁的原则，比如从纯电模式开始，先确认动力系统在控制器结算的输出下是否和整车负载匹配，车速是否能跟上，驾驶员模型的输出是否能和试验数据匹配上等。再下一步可以调试发动机启停，离合器作动，制动能量回收等闭环系统的表现。

图表 9 – 闭环模型和试验数据对比

最终可以通过闭环调试过程，得到类似如图表 9中所示的仿真结果（车辆模式和离合器状态的数值定义与实车不同）。当然，这里只展示了一个工况的验证结果，如果在前期开发和试验规划过程中，尽量多覆盖一些循环工况或企业特定工况，这样作为模型验证的依据可以进一步提升闭环模型的精度及求解稳定性。

接下来就是利用闭环模型可以做参数敏感性分析，比如像车重，阻力，pedal map，初始SoC，SOC启发动机上下限，模式切换延迟时间等无论是设计参数还是控制参数，都可以快速地通过批处理或脚本来实现批量分析，甚至可以作为标定的参考依据或探索方向。

05、拓展到多属性平衡分析

和提升模型开发效率及应用范围

前述文字可以算是概括性地介绍了对于控制模型和车辆模型集成为闭环系统时一些经验性的步骤和心得。但是毕竟只有一个属性或单一性能的分析是无法适应OEM未来甚至现在的需求。所以如果要进行拓展，通常是将整车热管理系统及相关性能和动力部分以及控制策略整合成一个“多属性”的整车模型，这样就可以通过虚拟模型的结果，来评估和分析这种相互矛盾的属性。

图表 10 – 动力+热管理+VCU功能控制模型

如图表 10中展示，这里将某款混动车型的动力系统，和主要的热管理循环回路系统模型（发动机冷却、电池直冷、电机电控冷却，空调冷媒及乘员舱），再加上整车VCU的一些基本控制集成为一个VEM（整车能量管理）的模型。熟悉Amesim的人看到这个截图应该就能八九不离十的猜到这个模型的状态变量数目……嗯，200+

而且这个模型还没有加热管理的控制策略，可以想象如果我们再引入新的控制策略，那么模型的调试时间，单一工况的求解时间都可能会增加不少。并且，这里只是一款车型的一个模型；如果同时管理几款不同车型，且控制策略及标定也不一样，每个不同部门或工程师关心的指标也不一样，如果希望通过仿真来给出方向，甚至指导设计，即便是在已有完整的模型上进行更改和升级，这个工作量也是相当巨大的。而且随着项目和数据的累计，车型对应的模型版本也会越来越多，只靠文件夹和文件名以及开发工程师的个人经验来管理和维护，是无法确保开发工作的稳定性、正确性以及高效性的。

因此，当OEM的整车部门在数字化的研发中逐步积累了众多车型的数字化模型，那么面对的情况很有可能就是如图表 11所展示的。

图表 11 – 整车数字孪生模型的复杂度

而且OEM未来甚至现在遇到的挑战一定会比这个图上更加复杂，系统间的强耦合关系（比如能耗和热管理）也需要更加深入和全面的探索分析。相信对于上图中每一个子系统或者每个单一属性，都有非常在行的领域专家可以解决实际工程问题；或者每个CAE工程师对于单独一个子系统或单一性能也有能力构建准确的模型甚至具备一定预测性。但如何把这些专长和过往项目经验有机整合，通过类似模块化的实施方式来各取所长，最后再集成出专门针对模型使用者需求的特定模型，这个是目前最需要实现的。

如图表 12中所展示的，基于Analyst和相关的专业平台工具是面对上述挑战的一个最佳选择，并且已经在国外的一些OEM客户中得到了很好的应用。即可以从零开始规划初期阶段需要哪些最基本的架构、模型元件、工况、设计参数组等基本因素，先将平台搭建好，并且在日常的仿真分析的反馈中来决定下一步的拓展方向；也可以把现有的车型模型及数据库的积累信息做相应的评估和分类，将其移植到Analyst为基础的定制化平台上。这样除了可以系统地将不同架构、属性及复杂程度的模型分门别类的管理好，而且还可以将设计人员、开发工程师和模型使用者的角色区别开，确保开发工程师可以专注于模型内容的丰富和升级工作，而使用者不必研究细节就可以快速选定其所需的车型架构、总成的组合、工况和参数设定等开放的变量，并迅速获得仿真分析结果。

而且相信随着国内OEM客户的需求不断更新和提升，这种定制化的平台可以更加发挥出整车部门的开发能力，提升开发效率，同时管理、维护和支持多个车型的平台项目，实现从“数字双生”到“数字孪生”的迈进。

图表 12 – 基于Analyst及相关平台实现最佳开发流程