根据以上的信息,大概可以做出这样的推论:
1)BMS没有采取更多的保护设计,BMS比较容易死机
1.1 如下图3所示,理论上有个备份的系统比较合适
图3 2oo2D的多个变种
1.2 节约的作法,遇到主MCU(承担主要的算法工作)无法处理,采用备份MCU监控重启或者报警也行
图4 主从MCU监控系统
2)单体的信息通过内部一路CAN传送,最远的BMU与整个BMS的距离很长,电源的供给和抗干扰的回路设计起来也是比较费劲的
3)BMU本身也只有简单的MCU+ASIC的方式,只有比较简单的测量功能,由于考虑到大巴的长度问题,如果采用单体过压或者欠压报警,用单纯的IO信号也可能存在较多问题
图5 乘用车BMU基本架构
4)CAN盒的设计,是一个比较大的问题,由于与BMS没有一个很好的通信机制,所以最好的办法是进入BMS作为一部分监控起来
对于电池管理系统的建议:
a)对于单体和模块过压这样的故障,需要在BMU端做独立的电路,加检测芯片和独立于MCU的反馈通路
b) 对于整车控制器的权限,不仅仅需要通过CAN来断开继电器,当BMS死机无法发送心跳报文的时候,整车控制器可采集直控方式切断
接下来说说直流充电的事情,整个GB/T20234.3和GB/T27930,是由BMS主控,充电机辅助的。如果充电机在后期没有BMS的信息的时候,不退出,这个系统稳定性可想而知。
在整个充电阶段,BMS实时向充电机发送电池充电需求,充电机根据电池充电需求来调整充电电压和充电电流以保证充电过程正常进行。在充电过程中,充电机和BMS相互发送各自的充电状态。
BMS根据要求向充电机发送动力蓄电池具体状态信息及电压、温度等信息
BMS充电终止条件
根据充电过程是否正常:BMS诊断充电的需求和实际的情况
电池状态是否达到BMS自身设定的充电结束条件:电池的SOC核算情况
是否收到充电机中止充电报文来判断是否结束充电:这条表征充电桩的自身状态
充电机终止条件为
停止充电指令:BMS的充电需求
充电过程是否正常:充电机诊断充电情况
是否达到人为设定的充电参数值:充电机本身的保护
是否收到BMS中止充电报文来判断是否结束充电:BMS的充电需求
图6 GB/T 27930 充电流程
对比Combo或者Chademo系统(编者:指欧盟和日本采用的充电标准)的充电过程,在充电过程中的失效,BMS整体失效一般不会发生,而且本身采取了PWM+PLC通信两种不同形式交互整个充电过程。前者用幅度表征充电过程,PLC通信交互控制信息。我个人对于修订后的GB27930一系列在系统安全上的缺陷,觉得后续真的要在互通性、误报错和安全几项内容进行系统折中才行。短期内来看,一下子给乘用车私人客户的纯电动汽车来用,问题更多一些。
图7 充电失效保护概念
相关文章
[错误报告][推荐][收藏] [打印] [关闭] [返回顶部]