|
上一篇《电池管理系统故障检测、处理、及诊断机制（一）》提到了BMS对动力电池的故障检测方法、故障评估及处理策略，本篇主要讨论故障的诊断机制。
在汽车级应用的场景下ECU（Electronic Control Unit）应具备完整且准确的诊断功能，从而对被控对象以及ECU本身进行有效故障记录、分析、以及管理。同时通过对ECU的诊断功能的应用能有效防止核心部件损坏、提前预防安全性故障的发生，使得系统以一种可预见的、安全稳定的状态保持运行。而诊断机制的使命就在于建立一套通用性强的体系标准实现对ECU故障的识别、记忆、配置，并使ECU能与生产制造设备、售后维修设备、甚至是用户的工具进行必要的信息交互。
从实现诊断方式的不同来对ECU分类可以将其大致归为两类。第一类ECU自行完成故障的识别、记忆、配置、交互。第二类ECU仅进行故障识别，并将故障状态发送至第一类ECU，由第一类ECU完成对其的故障记忆、配置和交互。在分布式架构的BMS中主控单元BMU属于第一类ECU，从控单元LECU可以归为第二类ECU。但作者在之前的文章中也提到未来的趋势是LECU将成为Module中的核心部件，而不再只是电池管理系统中的一个子部件，因此LECU能够独立实现诊断功能非常有必要的。
BMS诊断功能主要包括两部分，分别为故障确认机制和服务处理机制。
故障确认是指BMS在进行初始化、运行管理、充电管理、以及关机过程中出现的异常进行识别和确认的机制。主要包括：诊断故障代码定义、故障检测机制、警示机制、故障恢复机制、故障修复策略、故障发生时电控单元的运行方式等。 故障检测内容往往是根据预先危险性分析（PHA）、失效模式分析（FMEA）、以及法律法规要求来确定的，故障代码（DTC）需要与BMS检测的故障一一对应。故障的检测机制通过故障检测计数器、故障待定计数器、老化计数器等参数将故障分为未确认故障、已确认故障、以及复位已老化的故障。
一旦故障确认不仅需要保持故障代码DTC，并且需要同时存储一组快照Snapshot信息，以对故障的检测和修复起到辅助作用。Snapshot的内容一般分为全局快照(Global snapshot)和局部快照(Local snapshot)两部分。全局快照一般包括：KL.15的状态、供电电压值、累计里程值等整车信息。局部快照主要是电池管理中的关键参数：SOC、最高最低电压、最高最低温度、电流、HVIL状态、碰撞开关状态等。当故障存储空间不足时，需要通过故障代码溢出管理机制进行故障的删除和更新。因此需要对不同故障分配不同的优先级，尽量使更为严重的故障保存下来。
服务处理则包括对诊断故障代码DTC（Diagnostic Trouble Code）的交互控制、Routine Control、Bootloader等。
通过上表所示的诊断服务指令即可实现读取故障代码，临时控制BMS吸合特定的接触器或是执行某一项程序，以及实现Bootloader功能。
步骤A 进入编程模式（Programming模式）：在此之前ECU一直运行在应用程序下，此处ECU收到进入编程模式请求，应该执行硬件初始化后进入Bootloader的编程模式。 步骤B 安全算法验证流程：用来验证刷新工具的合法性。算法一般是ECU与上位机之间约定好的，通过一组SEED-KEY比较结果是否一致，结果一致则为合法的刷新工具，允许执行刷新工作，否则拒绝进行刷新。 步骤C 写入指纹信息FingerPrint 在下载变更之前写入指纹信息，作为对此次下载的记录。 步骤D 至步骤H 将flash的擦除和重编程程序载入。 步骤E、H和步骤J 校验下载是否正确。 步骤I 应用程序或标定数据的下载过程。 步骤K 验证程序的独立性及可兼容性。 即验证所下载的应用程序或标定数据是否与其他部分兼容，其后可能执行复位等，从而运行新的下载程序。 步骤L 写入配置数据，比如车辆识别码。刷新完成后，电控单元复位并进入应用程序正常运行，还应该再进行一些处理，包括清除DTC，写入车辆信息和ECU配置信息。
参考文献： [1] ISO14229-1: 2006 Road Vehicle - Diagnostic Systems Diagnostic Services Specification [2] ISO15765-2: 2004 Road Vehicle - Diagnostic on CAN Part 2: Networking Layer Services [3] ISO15765-3: 2004 Road Vehicle - Diagnostic on CAN Part 3: Application Layer Services 新课程 点击标题查看
|
|
|
