本文结合公司自主研发的项目详细分析了GDI发动机的ECU开发设计流程:Simulink模型的建立、代码生成、主控制器的开发、底层程序集成和台架测试等。台架测试表明,该项目研发控制策略、硬件设计和系统集成过程都是正确的,这个过程将为汽车行业GDI发动机ECU的开发提供有益的借鉴。
随着整车厂的竞争日趋激烈,随之而来的是核心技术的竞争,而汽车的核心技术就是发动机技术。因此,整车厂将研发重点放在发动机技术的研发上面。随着发动机技术的不断提高,人们提出了直喷式汽油发动机GDI的概念。相对于传统的发动机,它具有低油耗、低排放的优点,有利于降低车辆的运行成本和减轻环境污染。本文结合长城自主研发的项目详细分析了GDI发动机的ECU开发设计流程:Simulink模型的建立、代码生成、主控制器的开发、底层程序集成和台架测试等。
Simulink模型的建立
1. 建立模型
近年来,Simulink已经成为汽车电子控制领域动态系统建模和仿真领域中应用最为广泛的软件之一。
Simulink采用模块组合方式来建模,使用户快速、准确地创建动态系统的计算机仿真模型,特别是对复杂的不确定非线性系统,更为方便。
此项目中,控制喷油点火的模型共有7个输入量和4个输出量。输入量包括发动机转速、发动机温度、空气流量、进气压力、进气温度、踏板开度1和踏板开度2;输出量包括点火角、充磁时间、喷油脉宽和喷油起始角。图1为计算点火角和喷油角的Simulink模型,其变量对应的属性见表1。
2. 模型验证
对该模块进行测试仿真,数据采用的是长城发动机台架上标定的dat文件,首先将数据转化为Excel文本格式,然后把文本中的数据下载到Simulink的Signal Builder模块中,进行仿真验证。
采样步长为0.01s,以喷油开始角的数据作为对比,仿真结果见图2,图中的黄线为喷油开始角的理想数据,粉线为模型的仿真结果。通过对比两条曲线,可以看到理想数据和仿真结果之间的误差。
从图中明显看出:模型仿真结果和理想数据之间的误差很小,在允许的范围内,而且实际的台架测试,表明此模型生成的代码对喷油起始角进行了很好的控制。
自动代码生成
1. RTW介绍
Real–Time Workshop是由MathWorks公司提供的代码自动生成工具,它可以使Simulink模型自动生成面向不同目标的代码。
传统的产品开发流程通常包括许多小组,各小组负责不同但又相互关联的工作。他们之间缺乏有效的交流手段,通常是通过各种文档、资料和数据等进行沟通。由于不同的小组专注的问题层面不同,很难准确理解和贯彻彼此的意图,这无疑增大了产品开发的风险,延长了产品的上市时间。
在产品的开发过程中采用RTW可有效地提高产品的开发效率,进而降低成本。通过Simulink模型,RTW能自动生成面向不同目标系统的执行代码。这样,可以很快建立起系统模型,作为一个动态可执行规范,供各个小组快速地对系统进行检验,提出改进措施。自动代码生成的功能实现了从系统设计到实现的完美过渡,大大减少了软件工程师的编码工作量。
2. 喷油点火模型代码的生成
模型的仿真验证工作完成后,对模型进行设置以自动生成代码。以喷油点火模型为例,首先打开Configuration Parameters对话框对生成的代码进行配置,具体配置情况见图3。
除了对Real-Time Workshop进行配置以外,还要对Solve、Optimization和Diagnostics等进行配置。
配置完成后点击Generate code按钮或者使用键盘Ctrl+B自动生成该模型对应的C代码(见图4)。
将生成的所有的C文件和H文件都添加到底层程序所在的工程中,下载到控制器后就可以进行台架试验。
主控制器的开发
1. 硬件需求分析
项目组接到任务后,首先要做的工作就是进行硬件需求分析,撰写硬件需求说明书。硬件需求分析在整个产品开发过程中非常关键,硬件工程师应对这一项内容加以重视。
硬件需求分析主要包括硬件开发目标、基本功能、基本配置、主要性能指标、运行环境、约束条件及开发经费和进度等信息。它是硬件总体设计和制订硬件开发计划的依据,具体编写的内容有:系统工程组成及使用说明、硬件整体系统的基本功能和主要性能指标、硬件分系统的基本功能和主要性能指标及功能模块的划分等。
2. 硬件总体方案设计
硬件开发总体方案对整个系统进一步具体化。硬件开发总体设计是最重要的环节之一,总体设计不好,可能出现很严重的问题,造成的损失有许多是无法挽回的,产品的好坏特别是系统设计的合理性、科学性、可靠性、稳定性与总体设计关系密切。
硬件总体设计对各个分系统的任务以及关联关系进一步明确,它是硬件详细设计的依据。硬件总体设计应包含以下内容:系统总体结构及功能划分、系统逻辑框图、系统各功能模块的逻辑框图、电路结构图及单板组成、单板逻辑框图和电路结构图,以及可靠性、安全性、电磁兼容性讨论和硬件测试方案等。
3. 硬件详细方案设计
单板硬件详细设计,要遵守公司的硬件设计技术规范,必须对物料选用以及成本控制上加以注意。需要硬件工程师在工作中不断应用,不断充实和修正。
硬件详细设计主要有:单板逻辑框图及各功能模块详细说明,各功能模块实现方式、控制方式、接口方式、接口管脚信号详细定义、性能指标,单板原理图、PCB图、详细物料清单及单板测试、调试计划。
4. 样品制作
取回PCB板及物料之后,焊好1~2块单板,焊接过程中需要进行部分功能调试。同时需要对样品进行命名。
5. 系统联调
首先是硬件功能测试,确保每个功能都能实现,每项指标都能满足。硬件测试没问题之后,配合软件工程师对系统进行联调,撰写系统联调报告。联调是整机性能提高,稳定的重要环节,可以帮助发现各单板以及整体设计的不足,也是验证是否达到设计要求的重要方法。因此,联调是必须预先做好联调计划,并对整个联调过程进行详细记录。只有对各个环节验证到位才能保证机器走向市场后工作的可靠性和稳定性。
操作系统程序集成
1. 底层驱动提供函数及变量的分析
接到集成任务后,首先要对底层驱动所能提供的函数及变量进行分析,清楚从底层驱动获取的变量的类型、单位和数据范围等,便于在集成时对变量进行控制。此外,应掌握驱动发动机执行器的执行函数所需的参数类型,便于将上层控制策略生成的相关变量进行类型转换和赋值操作。
2. 操作系统任务的划分与调度
根据各模块时间响应性及其功能,对任务进行初步划分和调度。操作系统的调度方式分为完全抢占式调度、非抢占式调度和混合抢占式调度三种。完全抢占式调度用于保存现场的内存占用较大,理论上可以在任务的任何位置重调度, 因此任务必须同步访问共享资源,增加了系统的复杂性。非抢占调度通过调用某些服务例程实现任务切换,即用户设置重调度点。通过定义任务组使多个任务同时具有抢占或非抢占调度的特征。混合抢占调度适合抢占任务和非抢占任务共存于一个系统时使用。在这种情况下,调度策略依赖于正在运行任务的抢占特性,开发者通过配置任务优先级和抢占属性来定义任务执行顺序。
3. 系统联调及测试
系统集成工作完成后,需要进行系统联调及测试。
(1)将集成好的软件通过编译器进行编译、链接,检测是否存在语法错误及会影响系统正常运行的警告,若有,根据错误找出原因进行修改,直至编译链接完全通过为止。
(2)将编译链接后无误的程序下载到发动机ECU中,对整个系统进行分析,直至确定操作系统的调度与预期目标一致,整个系统可以正常运转为止。
(3)将发动机ECU与发动机信号模拟器通过线束对接,为ECU输入相应信号,看其能否进行正常的喷油点火。若不能,找出原因并修改,直至喷油点火信号正常运行为止。
(4)通过功能试验台为ECU输入所需的各种模拟的发动机传感器相关信号,再通过发动机信号模拟器输入传感器的信号。此刻,ECU所需信号已经全部输入完毕,ECU能正常工作,采集4个缸的喷油点火信号并与原机数据进行比较,观察其误差范围,若喷油脉宽及点火充磁时间的误差<1ms,则认为此策略可用。
(5)确保以上测试均没有任何问题后,即可进行发动机台架试验。
4. 喷油点火模型输出变量
喷油执行函数包括两个参数fuel_width_value和inj_angle,分别是喷油脉宽和喷油起始时刻,关于这两个参数在底层驱动中的定义见表2。只需要将模型中的两个变量分别对应上底层驱动函数中的两个变量即可。
同样,点火执行函数包括两个参数ign_time和ign_angle,分别是充磁时间和跳火时刻,关于这两个参数在底层驱动中的定义见表3。只需要将模型中的两个变量分别对应上底层驱动函数中的两个变量即可。
台架测试结果
从发动机台架测试试验测试结果(见表4)可以看出,喷油量、喷油起始角、充磁时间和点火角都得到了很好的控制。
结语
在汽车的发动机研发过程中,随着Simulink模型的进一步可视化、统一化及简单化,基于模型的控制策略开发已经逐步代替了传统的手工编写C代码过程,这在本文中的GDI项目中得到了很好地体现。台架测试表明,该项目研发控制策略、硬件设计和系统集成过程都是正确的,这个过程将为汽车行业GDI发动机ECU的开发提供有益的借鉴。
2024-10-29
2024-10-29
2024-11-01
2024-10-29
2024-10-29
2024-10-29
评论
加载更多