1. 项目概述:为什么硬件保护与诊断是BMS的“生命线”
在电动汽车和储能系统的电池管理系统(BMS)开发中,我们工程师最怕听到的两个字就是“失效”。电芯的过压、欠压、过温、欠温,任何一个保护环节的漏报或误报,轻则导致系统停机、用户体验受损,重则可能引发热失控,造成不可挽回的安全事故。因此,一套独立于软件、在硬件层面直接响应的保护电路,以及能够验证这套电路自身是否“健康”的诊断机制,就成了BMS设计中不容妥协的底线。这不仅仅是功能实现,更是满足ASIL-D等高功能安全等级要求的基石。
德州仪器(TI)的BQ796xx系列电池监控芯片,正是这一设计哲学的集大成者。它不仅仅提供了高精度的电压、温度采集,更内置了一套堪称“武装到牙齿”的硬件保护与诊断子系统。很多初次接触该系列芯片的工程师,可能会把注意力集中在ADC精度、通信拓扑上,而忽略了数据手册中关于“Protector”和“Diagnostic”的章节。殊不知,这些才是确保芯片在车辆全生命周期内可靠工作的核心。本文将深入BQ796xx的硬件保护与诊断世界,抛开枯燥的寄存器列表,从工程实践的角度,拆解其OVUV(过压/欠压)、OTUT(过温/欠温)保护器的自检逻辑,以及通过双ADC比对实现的多种诊断手段。我会结合自己踩过的坑和调试经验,告诉你这些功能如何配置、如何解读结果,以及在实际项目中如何将它们融入系统级的健康管理策略。
2. 硬件保护器:不只是比较器,更是可自检的“安全卫士”
BQ796xx的硬件保护器并非简单的模拟比较器。它是一个集成了配置锁存、周期性自检和故障报告的数字-模拟混合系统。理解其架构,是正确使用的前提。
2.1 OVUV与OTUT保护器的工作原理与配置锁存
OVUV保护器监控所有电芯电压通道(VC),而OTUT保护器监控所有GPIO配置为温度采集的通道。其核心是一个高速、高精度的窗口比较器。当你通过寄存器设置好OV、UV、OT、UT的阈值后,并不是比较器实时读取这些寄存器值。芯片内部有一个关键动作:配置锁存(Latch)。
当你使能保护器(例如设置OVUV_GO=1)时,芯片会将相关的阈值寄存器、模式寄存器、有效通道数(NUM_CELL)等配置信息,一次性锁存到专用的硬件保护器模块中。此后,保护器将完全基于这些被“冻结”的硬件配置独立运行,与软件寄存器的后续更改脱钩。这样做的核心目的是防止软件跑飞或通信干扰意外修改保护阈值,确保保护逻辑的确定性。只有重新使能保护器,新的配置才会被再次锁存。
实操心得:这是一个极易忽略的细节。调试时,你修改了
OV_THRESH寄存器,但发现保护点没变?先检查是否重新发送了OVUV_GO=1命令来触发重新锁存。同样,在系统初始化流程中,必须在配置完所有保护参数后,最后一步才发送GO命令。
2.2 保护器的核心诊断:奇偶校验、DAC验证与BIST
既然保护器依赖锁存的配置,那么如何确保这些被锁存的配置在长达数万小时的工作中不发生比特翻转或硬件退化呢?BQ796xx提供了三层递进的诊断机制。
2.2.1 奇偶校验:配置的“守门员”
这是最基础也是持续进行的诊断。芯片会在后台周期性地检查锁存在硬件保护器中的配置数据奇偶性。如果检测到奇偶错误,说明锁存的配置可能已损坏。
- 检查内容:
- OV/UV阈值、OT/UT阈值。
- OVUV/OTUT工作模式(如轮询模式、单通道模式)。
- 有效电芯数量(
NUM_CELL)及GPIO配置。
- 故障标志:
- OVUV奇偶错误:
FAULT_PROT1[VPARITY_FAIL]置1。 - OTUT奇偶错误:
FAULT_PROT1[TPARITY_FAIL]置1。
- OVUV奇偶错误:
- 工程意义:奇偶校验错误属于系统性、持续性的故障,一旦发生,通常意味着硬件存在潜在问题。在功能安全分析中,这类故障需要被归类为潜在故障,并触发系统降级或进入安全状态。在实际代码中,需要定期(如每100ms)轮询这两个标志位。
2.2.2 DAC验证:阈值是否“言行一致”?
奇偶校验通过了,只能说明“数据没变坏”,但无法证明“数据是对的”,更无法证明“比较器能正确响应这个数据”。DAC验证就是为了解决第一个问题:锁存的阈值,其对应的模拟电压值是否正确?
芯片内部有一个精密的数模转换器(DAC),用于生成OV/UV/OT/UT的比较基准电压。诊断时,这个DAC的输出可以被切换到辅助ADC(AUX ADC)的输入,由主机MCU读取测量值。
- 操作流程:
- 锁定通道:通过
OVUV_CTRL[OVUV_LOCK3:0]或OTUT_CTRL[OTUT_LOCK2:0]将保护器锁定到某一个特定通道(例如电芯1或GPIO1)。 - 切换模式:将保护器模式设置为单通道运行模式并重启(
OVUV_GO=1)。 - 读取测量:主机从AUX ADC的特定寄存器中读取DAC电压值。
- 计算验证:将读取的ADC码值反向计算为电压,与理论值(
0.8 * 设定的阈值电压)进行比较。通常允许一个很小的误差范围(例如±5mV)。
- 锁定通道:通过
- 关键限制:
- 进行DAC验证时,被锁定的通道绝对不能处于真实的故障状态(例如电芯电压确实超过了OV阈值)。否则,DAC的输出会被钳位或影响,导致测量值不准。诊断前务必确认系统状态。
- 测量到的DAC电压是设定值的0.8倍,这是芯片内部设计的固定比例,在计算比较时务必注意。
踩坑记录:曾经在电池包静置时进行DAC验证一切正常,但在带载测试时验证失败。后来发现,大电流导致电芯端电压瞬间波动,触发了临时的OV条件,影响了DAC验证。解决方案是在诊断流程开始前,增加一个“电压/温度稳定区间检查”,确保被诊断通道远离触发阈值至少100mV。
2.2.3 内置自检:全路径的“消防演习”
这是最彻底、最强大的诊断——内置自检(BIST)。它不再是静态检查,而是动态地模拟故障,检验从传感器输入到故障标志输出(包括NFAULT引脚)的整条信号链是否完好。可以把它想象成一次不通知的“消防演习”。
OVUV Protector BIST 流程详解:
- BIST启动:设置
OVUV_MODE[1:0]=0b10(BIST模式),然后发送OVUV_GO=1。 - 比较器阈值测试:
- BIST引擎会在内部生成两个测试电压:一个略高于锁存的OV阈值,一个略低于锁存的UV阈值。
- 它检查OV比较器是否对“高于阈值”的电压正确触发(输出高),以及UV比较器是否对“低于阈值”的电压正确触发。
- 故障标志:
FAULT_PROT2[OVCOMP_FAIL]或[UVCOMP_FAIL]。
- UV故障路径测试:
- 对每一个激活的电芯通道,BIST会内部断开该通道到OVUV多路复用器(MUX)的输入,模拟一个“开路”条件,这必然会导致该通道被检测为欠压(UV)。
- 然后,BIST引擎检查对应的
FAULT_UV寄存器位是否被正确置1,以及NFAULT引脚(如果使能)是否被正确拉低(有效)。 - 测试完一个通道后,BIST会复位该故障位,解除NFAULT,再测试下一个通道。
- 故障标志:
FAULT_PROT2[VPATH_FAIL]。
- OV故障路径测试:
- BIST引擎直接向
FAULT_OV寄存器的每一位依次写入1,检查该位是否能被置位,并同时检查NFAULT引脚是否响应。 - 故障标志:同样标记为
FAULT_PROT2[VPATH_FAIL]。
- BIST引擎直接向
- BIST完成:测试结束后,OVUV比较器会被关闭。主机需要重新发送命令(
OVUV_MODE[1:0]=0b01, OVUV_GO=1)来启动正常的轮询保护模式。
OTUT Protector BIST流程类似,只是对象换成了GPIO温度通道,通过内部上拉GPIO口来模拟UT(欠温)条件进行测试。
BIST实操的黄金法则:
- 环境净化:启动BIST前,必须用
MASK寄存器屏蔽所有与OVUV/OTUT无关的故障。确保所有电芯电压远离OV/UV阈值至少100mV,所有GPIO温度远离OT/UT阈值。任何预先存在的真实故障都会导致BIST中止(BIST_ABORT位置1)。 - 观察NFAULT:如果使能了NFAULT引脚,在BIST运行期间你会观察到该引脚高速闪烁(Toggling)。这是验证故障输出物理链路完好的最直观方法。
- 故障定位技巧:如果BIST失败且
[VPATH_FAIL]或[TPATH_FAIL]被置位,但不知道具体是哪个通道出了问题,可以启用“无复位”选项(DIAG_PROT_CTRL[PROT_BIST_NO_RST]=1)重新运行BIST。在此模式下,BIST不会在测试每个通道后复位故障寄存器。运行后,查看FAULT_OV/FAULT_UV/FAULT_OT/FAULT_UT寄存器,仍然保持置1的位,对应的就是故障通道。
表:硬件保护器诊断功能对比与使用场景
| 诊断功能 | 检测目标 | 执行方式 | 关键寄存器/标志位 | 典型执行周期 | 工程意义 |
|---|---|---|---|---|---|
| 奇偶校验 | 锁存配置数据的完整性 | 后台自动、周期性 | FAULT_PROT1[V/TPARITY_FAIL] | 持续进行 | 防御存储单元软错误,满足安全标准对内存完整性的要求。 |
| DAC验证 | 锁存阈值对应的模拟电压准确性 | 主机MCU主动触发 | AUX ADC测量值 | 上电初始化、定期维护(如每24小时) | 确保保护阈值的模拟基准无偏差,校准系统。 |
| BIST | 整个保护路径(比较器、逻辑、输出)的功能性 | 主机MCU主动触发 | FAULT_PROT2[OV/UV/OT/UTCOMP_FAIL],[V/TPATH_FAIL],[BIST_ABORT] | 上电自检、关键操作前(如充电开始) | 最全面的功能验证,证明保护电路“随时能工作”,是安全案例的核心证据。 |
3. 基于ADC比较的诊断:用冗余测量验证系统可信度
除了保护器自身的BIST,BQ796xx还提供了一套基于主辅ADC(Main/AUX ADC)比较的诊断方法。其核心思想是冗余测量:用两套独立的测量路径对同一个物理量进行测量,通过比较结果的一致性来判断任一路径是否失效。这是诊断模拟前端(AFE)功能完整性的关键。
3.1 电芯电压测量一致性检查
这是最常用的诊断。主ADC和辅ADC拥有相同的前端滤波器(抗混叠滤波等)。通过将同一个VC通道同时切换到两个ADC进行测量,并比较结果。
- 配置要点:
- 锁定通道:通过
ADC_CTRL2[AUX_CELL_SEL4:0]锁定要诊断的单个或多个辅ADC测量通道。 - 双ADC运行:确保主ADC和辅ADC都已使能并处于连续转换模式。
- 设置阈值:通过
DIAG_COMP_CTRL1[VCCB_THR4:0]设置可接受的差值阈值。这个值需要根据你的系统噪声水平和精度要求来设定,通常为几个mV到十几mV。 - 启动比较:设置
DIAG_COMP_CTRL3[COMP_ADC_SEL2:0]=0b001(电芯电压检查) 并发送[COMP_ADC_GO]=1。
- 锁定通道:通过
- 结果获取:比较完成后,
ADC_STAT2[DRDY_VCCB]=1。主机读取FAULT_COMP_VCCB1/2寄存器,每一位对应一个电芯通道。如果某位为0,表示该通道主辅ADC差值在阈值内;为1则表示超出阈值,可能存在故障。 - 诊断值读取:如果配置为单通道锁定模式,用于比较的辅ADC测量值会存放在
DIAG_AUX_HI/LO寄存器中,主ADC值在DIAG_MAIN_HI/LO中。这对于调试和精度分析极有帮助。 - 避坑指南:
- 对齐问题:默认情况下,辅ADC的CELL1时隙与主ADC的CELL1时隙对齐。对于高串数电芯,这会导致主辅ADC对高层通道的采样时间差较大,可能因电芯电压瞬变而引入比较误差。可以通过
ADC_CONF1[AUX_CELL_ALIGN]设置为与主ADC Cell8时隙对齐,来减少高层通道的采样延迟差。 - 滤波与稳定:
ADC_CONF1[AUX_SETTLE1:0]设置辅ADC的建立时间,需要在诊断速度和噪声滤波之间权衡。对于高噪声环境,需要更长的建立时间。 - 无效条件:文档中明确列出了会导致比较中止的条件,如选择了无效的通道、与平衡检测(BBVC)冲突、ADC未使能等。触发中止时,
FAULT_COMP_MISC[COMP_ADC_ABORT]会置位。务必在代码中检查此位,否则可能误判为所有通道诊断通过。
- 对齐问题:默认情况下,辅ADC的CELL1时隙与主ADC的CELL1时隙对齐。对于高串数电芯,这会导致主辅ADC对高层通道的采样时间差较大,可能因电芯电压瞬变而引入比较误差。可以通过
3.2 温度测量与平衡FET诊断
温度测量检查的原理与电压检查完全一致,只是对象换成了GPIO通道。通过ADC_CTRL3[AUX_GPIO_SEL3:0]选择GPIO通道,设置DIAG_COMP_CTRL2[GPIO_THR2:0]阈值,然后启动比较(COMP_ADC_SEL2:0]=0b101)。结果在FAULT_COMP_GPIO寄存器中。
平衡FET诊断则是一种巧妙的功能性测试。其原理是:打开某个电芯的平衡FET(CBn),此时该FET导通,其导通压降非常小。通过主ADC测量电芯电压(VCn - VCn-1),同时通过辅ADC测量CB引脚间的电压(CBn - CBn-1)。在FET正常导通的情况下,CB间的电压应远小于电芯电压的一半。
- 操作流程:
- 暂停所有正在进行的电芯平衡。
- 通过
DIAG_CBFET_CTRL1/2寄存器选择要测试的FET(注意规则:最多同时打开8个,且不能有超过2个连续)。 - 锁定对应的辅ADC通道 (
AUX_CELL_SEL)。 - 发送
DIAG_COMP_CTRL3[CBFET_CTRL_GO]=1来打开选中的诊断FET。 - 等待足够的dV/dt时间让电压稳定。
- 启动ADC比较 (
COMP_ADC_SEL2:0]=0b100)。 - 芯片内部执行判断:
AUXCELL测量值 < 0.5 * VCELL测量值。 - 读取
FAULT_COMP_CBFET1/2寄存器获取结果。 - 关闭诊断FET(清除
DIAG_CBFET寄存器并再次发送CBFET_CTRL_GO=1),或退出平衡暂停状态。
- 核心价值:这个诊断不仅能发现FET完全开路(烧毁)的硬故障,还能间接检测到FET导通电阻异常增大(老化)的潜在故障,因为这会使得CB间电压升高,可能超过阈值。
3.3 开线检测:预防“失联”的致命故障
VC(电压采集)或CB(平衡)引脚与电池模组之间的连接线如果开路,BMS将无法感知该电芯的真实状态,这是极其危险的。BQ796xx的开线检测通过在引脚上注入/拉出一个小电流,观察电压变化来实现。
- 物理原理:
- 对于VC1~VC16和CB1~CB16引脚,芯片内部连接一个**电流沉(Current Sink)**到地。
- 对于VC0和CB0引脚,内部连接一个**电流源(Current Source)**到AVDD。
- 当使能开线检测电流时,如果外部连线完好,电池模组的内阻和外部滤波电容会维持引脚电压基本不变。
- 如果外部连线开路,引脚悬空。对于VC1~VC16/CB1~CB16,电流沉会缓慢拉低外部电容上的电压;对于VC0/CB0,电流源会缓慢拉高电压。这个电压变化会被ADC捕捉到。
- 诊断流程:
- 配置开线检测阈值
DIAG_COMP_CTRL2[OW_THR3:0]。 - 使能电流沉/源:
DIAG_COMP_CTRL3[OW_SNK1:0]。 - 关键等待:等待足够的时间(dV/dt时间),让开路点上的电压变化达到可检测的程度。这个时间由外部差分电容(Cvc,通常22nF或10nF)和注入电流(典型值几个µA)决定,通常需要几十到几百毫秒。等待时间不足是开线检测失败的最常见原因。
- 启动ADC比较:对于VC开线,
COMP_ADC_SEL2:0]=0b010;对于CB开线,=0b011。 - 芯片比较所有激活通道的电压(主ADC测VC,辅ADC测CB)是否低于(对于电流沉)或高于(对于电流源)设定的阈值。
- 读取
FAULT_COMP_VCOW1/2或FAULT_COMP_CBOW1/2寄存器。 - 务必关闭电流沉/源。
- 配置开线检测阈值
- 设计考量:开线检测的可靠性高度依赖外部RC滤波网络的设计。RC时间常数太大,会延长检测所需的等待时间;太小,则可能无法有效滤除噪声,导致误触发。需要在系统响应时间和噪声免疫力之间取得平衡。
4. 数字后处理与持续后台诊断
除了上述需要主机触发的诊断,BQ796xx还有一些在后台默默运行的持续诊断。
后置ADC数字低通滤波器诊断:主ADC测量值在送入VCELL寄存器前,会经过一个数字低通滤波器(LPF)以平滑噪声。芯片内部为每个通道的LPF都复制了一个“诊断用LPF”。在后台,真实的ADC数据会同时送入主LPF和诊断LPF,并持续比较两者的输出。一旦发现不一致,FAULT_COMP_MISC[LPF_FAIL]就会被置位。这个诊断是全自动、持续进行的,只要主ADC在运行。
更巧妙的是,芯片还提供了诊断LPF自身的自检功能。通过设置DIAG_COMP_CTRL4[LPF_FAULT_INJ]=1并重启主ADC,芯片会向诊断LPF注入一个错误,强制触发一次LPF_FAIL。如果这个标志位能被正确置位,说明故障检测逻辑本身是工作的。测试完成后,将该位清零即可。这是一个典型的“故障注入”测试,用于验证诊断电路的有效性,是满足ISO 26262等标准中“诊断覆盖率”要求的重要手段。
5. 系统集成与诊断策略实践
了解了这些诊断功能后,如何将它们有机地整合到BMS软件中,形成一套完整的健康监控策略?
1. 分层诊断策略:
- 上电自检:系统上电后,在进入正常监控模式前,应依次执行:保护器DAC验证 -> 保护器BIST -> ADC比较检查(电压、温度)。这是最全面的检查,确保硬件从“沉睡”中醒来后一切正常。
- 周期性诊断:在系统运行时,以较低频率(如每小时一次)执行ADC一致性检查、开线检测。以更高频率(如每10秒)轮询奇偶校验、LPF诊断等后台标志位。
- 事件触发诊断:在关键操作前后执行,例如充电开始前,执行一次保护器BIST和平衡FET诊断;车辆高压上电前,执行一次开线检测。
2. 故障响应与处理:
- 分级响应:不是所有诊断失败都要立刻关断系统。例如,单个通道的ADC一致性轻微超差,可以记录并标记该通道数据“降级”,同时提高该通道的诊断频率。如果保护器BIST失败或奇偶校验错误,则必须立即进入安全状态(断开接触器)。
- 信息记录:所有诊断结果和故障标志,都应连同时间戳、系统状态(电压、温度、电流)一起存入非易失性存储器。这对于售后分析和功能安全审计至关重要。
3. 资源与时间权衡:
- 诊断耗时:BIST和开线检测耗时较长(可能几十毫秒),在此期间保护功能可能被暂停或处于特殊模式。需要评估这段时间内的风险,必要时在诊断期间启用软件备份监控。
- 计算开销:频繁读取和比较ADC诊断值会增加MCU负担。可以考虑在FPGA或专用安全芯片中实现部分比较逻辑,或使用BQ796xx提供的直接故障寄存器来减轻MCU负载。
最后一点个人体会:BQ796xx的硬件诊断功能非常强大,但“拥有功能”和“正确使用功能”是两回事。在项目初期就应将诊断流程的设计纳入整体架构,编写详尽的诊断需求规范,并在HIL(硬件在环)测试中充分验证各种故障注入场景下的诊断响应。这些工作看似繁琐,但它们是构建一个真正可靠、符合功能安全要求的BMS的必经之路。当你看到这些诊断机制在测试中成功捕捉到人为注入的故障时,你对系统安全的信心会大大增强。