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

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

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

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

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

02

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

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

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

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

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

03

完全SLK控制策略模型

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

图表 2 – Simulink接口模型

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

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

04

多级复杂程度的控制模型

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

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

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

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

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

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

图表 4 – 控制模型 (AMESim)

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

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

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

图表 6 – 车辆物理模型

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

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

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

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

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

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

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

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

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