导读
上一篇提到了BMS对动力电池的故障检测方法、故障评估及处理策略，本篇主要讨论故障的诊断机制。
在汽车级应用的场景下ECU（ElectronicControlUnit）应具备完整且准确的诊断功能，从而对被控对象以及ECU本身进行有效故障记录、分析、以及管理。同时通过对ECU的诊断功能的应用能有效防止核心部件损坏、提前预防安全性故障的发生，使得系统以一种可预见的、安全稳定的状态保持运行。而诊断机制的使命就在于建立一套通用性强的体系标准实现对ECU故障的识别、记忆、配置，并使ECU能与生产制造设备、售后维修设备、甚至是用户的工具进行必要的信息交互。
从实现诊断方式的不同来对ECU分类可以将其大致归为两类。第一类ECU自行完成故障的识别、记忆、配置、交互。第二类ECU仅进行故障识别，并将故障状态发送至第一类ECU，由第一类ECU完成对其的故障记忆、配置和交互。在分布式架构的BMS中主控单元BMU属于第一类ECU，从控单元LECU可以归为第二类ECU。但作者在之前的文章中也提到未来的趋势是LECU将成为Module中的核心部件，而不再只是电池管理系统中的一个子部件，因此LECU能够独立实现诊断功能非常有必要的。
BMS诊断功能主要包括两部分，分别为故障确认机制和服务处理机制。
故障确认机制
故障确认是指BMS在进行初始化、运行管理、充电管理、以及关机过程中出现的异常进行识别和确认的机制。主要包括：诊断故障代码定义、故障检测机制、警示机制、故障恢复机制、故障修复策略、故障发生时电控单元的运行方式等。
故障检测内容往往是根据预先危险性分析（PHA）、失效模式分析（FMEA）、以及法律法规要求来确定的，故障代码（DTC）需要与BMS检测的故障一一对应。故障的检测机制通过故障检测计数器、故障待定计数器、老化计数器等参数将故障分为未确认故障、已确认故障、以及复位已老化的故障。
通过上表所示的诊断服务指令即可实现读取故障代码，临时控制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
课程上线
感兴趣的快来学习吧！
《CATIA基础命令-面（Plane）的11种创建方法》
