ECU应用层软件模型之模型生成代码小结10

文摘   2024-12-16 07:09   上海  

ECU 应用层软件模型系列文章不断更新中,从零开始教你做应用层开发:


经过以上9篇文章来构建起ECU应用层软件模型生成代码的基本认识,核心是:
  • 如何进行代码生成配置

  • 如何进行数据字典配置

重点是结合了ECU应用层软件的特点,包括代码生成配置的应用层软件调用,硬件相关配置,也包括数据字典内容涉及的定点化和自定义存储类,这些关键内容都开了个头,但是还有很多细节需要细究。不过后续将以Simulink建模为主,代码生成和数据字典为辅。

1 ECU应用层软件模型的目标代码是怎样的

对于ECU应用软件模型,个人觉得首先最关键的点是你期待你的模型要生成怎样的代码,已经写过的文章就是围绕这个点,展开了一些工作,比如数据字典的定义与应用。

然后经过代码生成配置,最终生成的代码是否如你所期待的。
如果不符合你的预期,那么除了上述工作是否存在优化,还有一个点在于模型本身,比如模型搭建出来之后,各模块本身的属性配置是否合理,比如数据类型如何配置不合理,就有可能导致精度丢失。
再比如模型中的变量与常量是否正确且合理地Link到了数据字典中的变量与常量。
总之,对结果有清晰的认识,即对模型要生成怎样的代码有清晰的认识,才能更高效地去进行Simulink建模及其相关配置等工作。
2 ECU应用层软件模型有哪些内容
不管是哪一个控制器的应用层软件,本质上就是三个词:输入,控制和输出。

1) 输入:传感器信号,CAN报文接收信号和其他

ECU应用层软件模型首先需要对输入信号进行处理,比如:

  • 对于传感器信号,涉及到滤波和转换等,比如常见的AD信号需要将AD值转换成实际的物理量。


  • 对于CAN报文接收信号,如果是信号未被解析,则需要按照DBC将原始值转换为物理值;如果是信号已解析,通常也需要验证CAN信号的有效性。

  • 另外也涉及到故障诊断和存储相关信号的输入,比如通常需要接收来自底层软件诊断服务相关信号进行故障诊断,也需要在ECU上电时刻读取内存中的一些信号。

2)控制:取决于控制对象

控制主要取决于控制对象,比如动力总成系统有电机,电池,充电机和加热器等,底盘总成系统有制动,转向和悬架等,智能座舱系统有门窗,各种灯和座椅灯等等。根据不同的控制对象,相应的控制策略或算法有针对性,以电机控制的应用层软件为例,包括:

  • 电流控制策略,即根据目标扭矩需求,通过查表或算法计算出最优的电流相位(id和iq),以实现高效和精确的电流控制。

  • IGBT控制算法,即基于计算出的id和iq,控制IGBT开关,生成所需的电压波形,从而控制电机的电磁场,进而调节电机的转速和扭矩。

  • 故障诊断与保护,即建立故障诊断策略,定义不同等级的故障响应,比如温度过高、通讯延迟等,实施相应的保护措施,如限制扭矩、停止输出或紧急下电。

  • 其他功能,比如标定与自适应,根据电机特性Map,动态调整控制参数,以适应温度变化、老化效应等。

source: 新课首发 | 新能源汽车驱动电机控制软件开发

3)输出:执行器控制指令,CAN报文发送信号和其他

关于CAN报文发送信号和其他不再多说,与这方面相应的输入信号差不多。重点在于执行器控制指令。不管是哪类控制器,最终都需要执行器来执行,比如电磁阀或电机,这些执行器有各自的特性,因此通常需要在执行器层面考虑其特性而转换最终的输出,这种输出通常也要转换成底层软件匹配的物理量形式。

4)接口:应用层软件与底层软件的关系

ECU应用层软件要按预期的运行,必须依托ECU底层软件,可以这么说底层软件通过一系列精心设计的模块和接口,为应用层软件的控制任务提供必要的支撑和执行环境。
如果以AUTOSAR接口来说,通常涉及到两种接口SR(Sendeer和Receiver)和CS(Client和Server),在此基础上,通过RTE构建起ECU应用层软件和底层软件的桥梁。

其中,底层软件通过底层软件通过微控制器抽象层(Microcontroller Abstraction Layer, MCAL)处理CAN控制器的配置,确保应用层可以简单地发送和接收报文。底层软件包含各种设备驱动程序,如ADC、PWM、SPI、CAN等,这些驱动程序使得应用层能够轻松访问和控制传感器、执行器等硬件设备,比如底层软件的ADC驱动会处理与硬件的交互,将模拟信号转换为数字信号供应用层使用。底层软件提供诊断、内存管理、操作系统服务等,这些服务层功能为应用层软件的稳定运行提供保障,比如通过诊断服务,应用层可以请求底层软件执行故障检测,确保系统健康运行。
3 小结
话不多说,从下篇文章起就开始专注于Simulink建模部分,看如何去构建应用层软件模型来实现相应的控制功能。不过在此有兴趣可以思考几个问题:
1)ECU应用层软件模型开发通常不是一个人能做的,而是一个团队。那么一个人与一个团队去做开发,需要考虑哪些差别点?一个人可能怎么做?一个团队又应该怎么做?
2)ECU应用层软件模型开发通常都需要基于V流程开发,即包括需求分析,架构设计,详细设计,单元测试,软件集成和软件测试,那么如果以详细设计为切入点,其他环节别遗忘了,其他环节应该要怎么体现或实施?
3)ECU应用层软件模型开发是一个软件开发项目,既然是项目就涉及到ECU研发的各个环节,那么如何管理一个ECU应用层软件开发项目,包括开发活动组织,软件问题解决和软件交付问题等等。

source: Multiple Virtual ECU Car Control System Verification Solution

总之,在深入某个细节之时,仍需要抬头了解自己所处的位置,了解你自己为什么而做,欢迎持续关注,下篇文章再叙~




创作不易,欢迎点赞再看收藏关注



汽车研发交流群,有兴趣的朋友请添加群主:prOmiseyes,备注:公司+职务入群。仅限汽车从业人员。

谦益行
分享汽车研发日常,助力你我共同成长。
 最新文章