基于模型设计的电动车整车控制器开发研究

田韶鹏，阙同亮

（武汉理工大学 现代汽车零部件技术湖北省重点实验室 汽车零部件技术湖北省协同创新中心，武汉 430070）

随着电动汽车的快速发展，企业对电子控制系统的性能与开发效率提出了越来越高的要求，传统手写代码的开发方式周期长、调试难度大，逐渐不适用于现代电控系统的开发。而随着Matlab/Simulink的广泛应用，基于模型的设计流程越来越多地应用在电控系统开发过程中[1-2]。利用Matlab/Simulink工具搭建控制模型，在设计初期就可以直观地反映设计需求，进行系统设计，并通过不断仿真对设计进行验证。在实现阶段可利用模型直接生成代码，完成软硬件的集成，可以大大提高开发效率[3]。同时生成的代码还具有规范、安全、高效的特点。

本文根据目标电动车需求设计整车控制器的控制策略，利用Matlab/Simulink建立控制模型，生成应用层代码，并将代码与底层驱动集成后下载到目标硬件平台进行硬件实测，验证代码的有效性。

1 整车控制策略开发

1.1 整车研究对象和需求分析

本文以某小型纯电动物流车作为研究平台，开发其适用的整车控制器，其整车控制结构如图1所示。

图1 整车控制结构Fig.1 Structure diagram of the target vehicle

整车控制器需要接收来自加速踏板、制动踏板、变速器、点火开关等的信号，通过CAN总线传输的电机控制器、电池的CAN报文，根据相应的控制方法输出对电机、电池、高压配电柜的控制信号。具体功能有：①整车控制器需要采集驾驶员的操作动作，并通过对其他控制器的控制实施驾驶员的操作意图，实现车辆的正常行驶并具有限速功能；②整车控制器能够对整车能量进行管理，调度电池能量输出，以增大电动车的行驶里程；③整车控制器还需要具有故障诊断和管理功能，能够根据故障严重程度进行合理的故障处理，如提示驾驶员或跛行模式，保障行车安全；④研究对象电动车使用五档变速器，但不具有档位位置传感器和车速传感器，因此整车控制器还需要根据变速器两端转速的比值进行判断档位位置，并利用计算得到的档位进行车速计算。在倒档时整车控制器还需要控制相关设备发出提示。

控制器的处理芯片来自飞思卡尔公司的MC9S12XEP100单片机，底层软件已经完成开发，具有可靠的实时运行环境，利用底层环境预留的接口函数，即可获得信号输入和输出控制信号。因此在开发阶段开发人员专注于控制策略的开发即可。

1.2 整车控制策略开发

本项目从纯电动汽车的运行工况角度出发，设计整车控制策略，将电动车控制策略分为起步模式、正常行驶模式、制动能量回收模式和跛行模式。

起步模式指电动车启动开关打开并挂在前进档，但加速踏板开度为0的状态。起步模式的主要功能是防止电动车在上坡起步时溜车。根据电机控制器输出的电机转向和转速，整车控制器可判断车辆是否处于上坡起步状态，如检查到处于上坡起步状态，将控制电机输出一克服坡度的正转矩，到达不溜车的目的。

电动车处于正常行驶模式时，需要根据电机转速、加速踏板开度，并结合加速踏板解析策略，计算加速转矩。对于加速踏板的解析策略，如图2所示通常分为3种[4-7]。曲线A偏重动力性，曲线C偏重经济性，曲线B作为折中方案，处理关系简单，易于实现，考虑车辆的主要用途和成本，选曲线B作为加速踏板基础解析策略。

图2 加速踏板的解析策略Fig.2 Analysis strategy of acceleration pedal

由于研究对象电动车以气压制动系统为主进行制动，只有制动踏板开关传感器，且机械制动无法调整。因此采用轻度制动能量回馈策略，设置一恒定的较小的电制动力，并以某一斜率递增到此恒定值。电机高转速时受到最大功率限制，低转速时回馈效率低，所以能量回馈只在两区间内进行。另外SOC较高时，为防止过度充电，也不进行能量回馈。

当电动车需要进行能量管理或故障管理时，即进入跛行模式。当电池SOC或电压低于某一值时，整车控制器将限制电机的输出转矩，以达到增大电动车行驶里程的目的。本项目中使用阶梯式的转矩限制策略，随着SOC的逐渐降低，对转矩的限制逐渐增大。

当整车控制器接收到电机控制器、电池管理系统或高压配电柜出现故障时，整车控制器将根据故障等级进行故障处理。本项目中将故障分为3级，一级故障属于严重故障，故障处理方式为强制停车；二级故障将限制电机输出，使电动车进入跛行模式，并提醒驾驶员靠边停车检查或前往维修点检测；三级故障为轻微故障，将使用仪表提示驾驶员出现故障，不影响电机输出。

2 控制模型的搭建与自动代码生成

2.1 模型的搭建

控制策略的实现是由自动代码生成完成，模型的搭建需要考虑生成代码功能的清晰划分。所以根据功能的相关程度进行模块化建模，将控制模型分为高压上电模块、驱动力计算模块、制动能量回馈模块、档位计算模块、能量管理模块和故障管理模块。同时将模型的输入输出端和控制模型分离，以使上层应用软件与底层驱动集成方便，行车模式的建模使用Stateflow创建有限状态机模型，根据功能模块的计算结果和输入信号进行模式转换。

完成建模后还需要对模型进行功能检查。使用Simulink自带的Design Verifier可检查模型的设计错误，包括是否存在死循环、数据溢出等。在运行Design Verifier后，可得到相关报告，内容包括检查的目标、使用的分析方法、每个信号的取值范围等。

图3 车辆状态机模型的Design Verifier报告Fig.3 Design Verifier report of vehicle state machine

检查设计错误后，还可以利用Design Verifier自动生成测试用例。根据需要选择测试的内容，主要包括了决策覆盖、条件覆盖、MC/DC覆盖、Lookup table覆盖等。

以车辆状态机模型为例，在覆盖度上选择前三项覆盖内容，生成测试用例，并进行仿真，仿真后可得到覆盖度报告。覆盖度报告可以看出Design Verifier将每种条件组合，生成测试用例，检查每个带有判断条件的模块能否实现。100%覆盖度表明测试用例覆盖了判断条件的每个分支，说明状态机模型不存在死循环或无法达到的状态。

图4 测试用例的部分覆盖度报告Fig.4 Part of coverage report of the test model

2.2 自动代码生成技术

要进行自动代码生成，在Simulink模型中至少有3部分需要配置：解算器（sovler）；系统目标文件（system target file）；目标硬件设置（hardware implementation）。

由于模型只生成应用层代码，手动集成应用层与底层软件，目标硬件设置为通用即可，芯片类型根据使用芯片的规格，选择16位嵌入式处理器。

对于解算器，其类型需设置为固定步长。由于模型是用于生产嵌入式代码，并下载到单片机中运行，而单片机总是以时钟源提供的稳定频率运行，无法进行变步长运算，所以两采样点间的时间间隔要设为固定。步长的大小取决于对计算精度和速度的平衡，步长越小，精度越高，而计算的速度越慢。在目标硬件为通用的情况下，对代码生成没有影响，本文设置为0.01 s。

其次将系统目标文件选择为Embedded Coder的ert.tlc。Embedded Coder是可生成用于嵌入式单片机的实时C代码的编码器。TLC文件的作用是将模型编译出的RTW文件转换为支持某平台或硬件的代码。

完成以上设置后，点击Build Model即可生成代码。但是此时生成代码的可读性和执行效率都较差，不具备于底层驱动集成的条件。所以必须优化代码生成过程，以生成质量更高的代码。

2.3 生成代码的优化

生成代码优化通常可分为两方面，一是优化模型中模块的参数和信号线的数据类型和存储类型。二是优化子系统的代码生成，使生成的代码存放在指定文件的指定函数中。

默认情况下信号线以double型变量定义，并且参数和信号线都以结构体形式生成代码，这会使得参数和信号线在调用时都产生冗长的代码，降低可读性，并加重RAM的储存和单片机的计算负担。

模块参数优化方式是将参数设置为以内联（Inline）形式生成代码，这样在参数调用时会以常数形式展开到代码中，并将常数储存在单片机的ROM中，大大增强代码可读性，并减少了RAM占用。对于信号线的优化，首先在Matlab中创建数据对象，同时为模型中的信号线赋上相同名称，并设置信号线与同名数据对象绑定，即可在Base Workspace中对信号线统一进行设置。根据不同的计算要求，修改变量的数据类型，将默认的double型按需改为不同长度的整型或定点型。信号线的存储类型为ExportedGlobal，这样信号线变量以全局变量的形式定义，接近传统编程习惯。信号线定义优化前后对比如图5所示。

图5 信号线的定义优化前后对比Fig.5 Signal definition comparison between before and after optimization

对于子系统，优化前其代码直接展开在代码生成框架的model_step函数中不利于功能的划分和函数调用。因此在创建子系统时，将其设置为原子系统，并按需将子系统的函数打包方式设置为不可重用和可重用函数，这样在代码生成时，会为每个子系统生成函数，在与底层软件集合时，方便调用和重用。

2.4 代码验证与软件在环测试

为了保证生成的C代码与模型功能的一致性，验证C代码，查找可能存在的缺陷，在代码与底层集合前还需要进行软件在环（SiL）或硬件在环测试（HiL）。本项目由于缺乏HiL相关设备，故使用SiL方法测试代码。

进行SiL仿真前，要先根据使用的16位MCU设置仿真环境，以模拟实际运行环境。使用Model reference模块，调用经过调试的驱动力计算模型，调用后可设置为以正常方式仿真，或将模型编译成C代码再进行仿真。利用Design Verifier生成的测试用例作为输入，将Simulink模型运行结果与代码运行结果比较，并计算两者间的误差。

SiL仿真结果如图6所示。第一幅图为加速踏板的模拟量输入，实际电压值为范围为0～5 V，对应单片机的模拟量输入为0～4095。为了避免踏板位置传感器的误差，以0.7 V和3.8 V作为踏板输入的起始点。在此范围外的输入会以0%或100%踏板位置计算；第二幅图为Simulink模型计算的驱动力，从图中可看出其变化趋势与输入相同，并在踏板输入超过限值时以最大转矩110 N·m和0 N·m输出；第三幅为模型与代码计算的误差；第四幅图为模型编译成C代码后的计算结果。从最后2幅图可看出C代码计算结果变化趋势与模型设计的基本相同，计算误差在0～1.6 N·m范围内，满足使用要求。证明该模块生成的C代码可用。

图6 驱动力模块SiL结果Fig.6 Result of SiL test of driving force model

3 软件集成与处理器在环测试

3.1 应用层与底层驱动的集成

完成优化并验证代码后，可进行与底层驱动的集成工作。生成代码会产生如图7所示文件。

其中ert_main.c为Embedded Coder根据模型生成的简单逻辑主函数文件，集成时不需要使用。rtwtypes.h主要存放数据类型别名和复杂数据类型的定义，由于底层驱动已经定义好数据类型，同时建模时使用的数据类型依照驱动的定义，此文件也无需使用。其他文件加入到CodeWarrior集成开发环境中，在底层驱动中调用变量和函数，即可完成与驱动的集合。

3.2 硬件实测

整车控制器本身支持CCP协议的通讯方式，可以通过支持CCP的标定监控软件在电脑上读取程序在整车控制器的运行情况，监控和标定整车控制器内部变量。本项目中，为了验证生成代码在硬件上运行的有效性，利用信号发生器和CAN通讯卡产生加速踏板，制动踏板信号，电机状态报文等，模拟车辆运行的不同状态。标定监控软件如图8所示。

图7 生成文件Fig.7 Files genarated by embedded coder

图8 硬件结果Fig.8 Result of hardware test

从测试结果可看出，整车控制器的运行可以达到预期效果，能够实时地对输入信号做出反应，根据输入信号切换车辆的运行状态，并能够正确计算出车辆状态、车速、档位等关键信息。证明了自动生成的代码能够满足设计要求，运行稳定可靠。

4 结语

本文采用代码自动生成方式设计并实现了整车控制器的应用层程序，充分利用Simulink工具，验证模型并优化代码生成过程，减少代码尺寸，提高了代码可读性和运行效率，最后利用硬件实测验证了代码的有效性。代码自动生成方式开发整车控制器，不仅能在功能设计阶段就将需求和模型整合，还能减少手写编程和代码调试的时间，大大提高了开发效率，加快项目进展。

[1]周兵，万吉奎，刘志远，等.动机控制器虚拟测试系统的开发与验证[J].现代制造工程，2015（8）：126-131.

[2]许保同.基于Simulink的纯电动汽车VCU控制策略设计方法[J].汽车工程师，2016（5）：19-21.

[3]孙忠潇.Simulink仿真及代码生成技术入门到精通[M].北京：北京航天航空大学出版社，2015.

[4]朱晓琪.纯电动汽车整车控制器开发[D].吉林：吉林大学，2015.

[5]刘永山.纯电动汽车整车控制器开发及控制策略研究[D].武汉：武汉理工大学，2014.

[6]吴敏.电动汽车整车控制器基础软件开发及控制策略研究[D].吉林：吉林大学，2014.

[7]徐凯.纯电动汽车整车控制系统研究和设计[D].太原：太原理工大学，2016.