纯电动汽车整车电气设计及整车CAN通讯课件.ppt
纯电动汽车整车电气设计及整车CAN通讯,1,纯电动汽车整车电气设计及整车CAN,2010-5-9,纯电动汽车整车电气设计及整车CAN通讯,2,发展概况,在全球提倡环境保护和石油能源紧缩的情况下，传统汽车已经不能适应人们的节能减排需求，新型汽车纷纷兴起。 纯电动车EV是未来汽车发展的目标，但受限于电池技术，安全性和性能得不到保障，成本高昂。 在这种情况下，混合动力微车HEV作为过渡模式具有很高的市场契合度，成本较低，受电池技术限制较小，性能与安全性都有很高的保障性，预计在未来十年内会占据适当的市场份额，加上国内新能源汽车市场处于萌芽状态，在此时介入是一个不错的选择，混合动力微车配备小排量发动机与小功率电动机，相关电力设备较为复杂，因此整车的电器保护与电气系统的设计是必不可少的。,纯电动汽车整车电气设计及整车CAN通讯,3,整车系统结构示意图,发动机,纯电动汽车整车电气设计及整车CAN通讯,4,电气系统整体配置框图,纯电动汽车整车电气设计及整车CAN通讯,5,整车以车辆管理单元（VMU）作为主控制单元，以电机驱动控制单元（PMU）、电池管理系统（BMU）、CVT和发动机ECU及相关控制电器作为从控制单元，以发动机、电动机和蓄电池组作为控制对象。 车辆管理单元是整车控制的核心，以整车的性能最优为目标，控制车辆的运行状态、能源分配，协调和发挥各部分的优势。其功能如下： （1）汽车驱动控制功能根据驾驶员的要求以及相应的车辆运行状态、工况，计算驱动转矩，控制电机驱动控制系统和发动机控制系统满足工况要求。 （2）制动能量回馈控制根据制动踏板的开度、车辆行驶状态、电池管理系统的信息，确定制动模式和制动力矩。 （3）整车能量管理控制能量消耗，对蓄电池、辅助动力源和车载其他动力系统统一管理，提高整车能量利用率，增加续驶里程。,纯电动汽车整车电气设计及整车CAN通讯,6,（4）故障诊断及保障提供安全和诊断服务，充电和驱动时的安全保障，故障的诊断监控车辆温度、冷却系统、车辆的运行状态监视主要设备的过电流、过电压、欠电压、过热，必要时切断主断路器。 （5）车辆状态监视通过通讯网络采集车辆状态信息，通过人机界面显示给司机。 （6）通讯管理整车通讯的主节点，接收来自电机驱动控制单元、发动机控制单元、电池管理系统、人机界面的所有信息，发送电机设定转速、设定力矩、正反转信息，各个部件的启动停止命令，车辆的工作模式和整车的运行状况等。,纯电动汽车整车电气设计及整车CAN通讯,7,整车通信网络,对于混合动力汽车，很多部分都由独立的电子控制器进行控制。为了将整个电动汽车内各系统进行统一管理，实现数据共享和相互之间协同工作，我们采用CAN总线进行数据传递。 CAN网络是现场总线技术的一种，它是一种架构开放、广播式的新一代网络通信协议，称为控制器局域网现场总线。CAN网络原本是德国BOSCH公司为欧洲汽车市场所开发的。CAN推出之初是用于汽车内部测量和执行部件之间的数据通信。在现代轿车的设计中，CAN总线被广泛的采用，奔驰、宝马、大众等汽车都采用了CAN总线进行控制器的联网。,纯电动汽车整车电气设计及整车CAN通讯,8,CAN总线的特点如下： （1）数据传输距离远，传输速率高 根据物理层实现的不同最远传输距离可达10km，最高传输速率可达1Mbit/s。 （2）多主、广播式通信 CAN通信网络没有网络地址之分，各个主设备的通信采用广播式通信。网络中各个节点都可以发送和接收报文，节点根据报文的标识符决定接收或屏蔽该报文。原理上网络可连接节点数量不限，但局限于物理层实现。 （3）CSMA/CD+AMP总线访问仲裁机制 CAN总线采用CSMA/CD+AMP总线访问仲裁机制。各个节点实时对总线信号进行监测，当总线出现空闲时，节点才允许发送数据。而当总线上同时有超过两个节点同时传送报文时，则采用“无损逐位仲裁”的方法来仲裁总线控制,纯电动汽车整车电气设计及整车CAN通讯,9,权，优先级高的报文拥有最高优先权，没有来得及发送的报文则等待并重新发送。报文的优先级由报文的标识符决定。这样拥有较高优先级的报文会赢得仲裁并能够保证在一定时间内发送成功，从而保证了通讯的实时性。 （4）高安全性，可靠的错误检测和处理机制 CAN总线通信网络节点发送的报文遭到破坏后，可自动重发。节点在错误严重的情况下具有自动切断的功能。 整车控制系统主要由6个部分7个节点构成，6个部分是：车辆管理单元、电池管理系统、电机驱动控制单元、CVT与发动机控制单元、人机界面和状态传感器。7个节点是：车辆管理单元、电池管理系统、电机驱动控制单元、CVT与发动机控制单元、加速踏板、制动踏板和人机界面。其中车辆控制单元是主节点，其他节点为从节点。,纯电动汽车整车电气设计及整车CAN通讯,10,人机界面,整车控制系统网络拓扑图如下所示：,CVT与发动机ECU,车辆管理单元,电机驱动控制单元,电池管理系统,CAN总线,纯电动汽车整车电气设计及整车CAN通讯,11,HEVCAN总线节点分析表：,纯电动汽车整车电气设计及整车CAN通讯,12,CAN通信原理,现场总线是一种开放式实时系统，它只具有简化的网络结构，而与 OSI 不完全保持一致。按照 OSI 基准模型，CAN 结构划分为两层：数据链路层和物理层。 物理层应给出系统的电气规约：总线负载、传送速率（波特率）、物理信号定义、总线故障检测方法、电缆选择、系统的机械和电气接口等。 数据链路层需给出报文结构（帧格式）的定义，在遵循 CAN2.0A/B 的基础上，仲裁场必须遵循 SAE J1939 标准，对于标定监测系统其数据场还必须遵循 CCP 协议。 CAN 系统中，数据在节点间发送和接收以四种不同类型的帧形式出现和控制，其中：数据帧将数据由发送器传至接收器；远程帧由节点发送，以请求发送具有相同标识符的数据帧；出错帧可由任何节点发送，以检测总线错误，而超载帧用于提供先前和后续数据帧或远程帧之间的附加延时。此外，数据帧和远程帧以帧间空间同先前帧隔开。,纯电动汽车整车电气设计及整车CAN通讯,13,因出错帧和超载帧由硬件（集成芯片）自动发送，设计员直接面临的是数据帧和远程帧，而汽车控制通信网络中远程帧的使用甚少，因此我们只要研究与设计数据帧结构。 数据帧由 7 个不同的位场组成：即帧起始、仲裁场、控制场、数据场、CRC 场、应答场、帧结束。数据场长度可为 0。CAN 协议具有标准信息帧和扩展信息帧两种格式，区别在于标准帧采用 11 位标识符（ID）,而扩展帧采用 29 位标识符。标准格式和扩展格式数据帧如图所示。 各个位场定义如下： （1） SOF（帧起始）：标志总线空闲状态，并使所有站点同步； （2）仲裁场：标准格式帧的 RTR 位为远程请求位，可用于要求数据。扩展格式帧的 SRR位为替代远程请求位，IDE 为扩展标识位；,纯电动汽车整车电气设计及整车CAN通讯,14,（3) 控制场：共 6 位，DLC 告知随后的数据域的长度。 （4）数据场：共 064 位，即 8 个字节，包含将要传输的数据。 （5）校验场：共 16 位，包含一个检测字，用于自动检测传输错误。 （6）应答场：共 2 位，当其它节点接收正确时，给出信号。 （7）EOF（帧结束）：共 7 位，标志通信结束。,纯电动汽车整车电气设计及整车CAN通讯,15,CAN的分层结构：,纯电动汽车整车电气设计及整车CAN通讯,16,标准格式和扩展格式数据帧：,纯电动汽车整车电气设计及整车CAN通讯,17,CAN报文格式：,纯电动汽车整车电气设计及整车CAN通讯,18,优先级(P) : 3位，它共分为8级(即0到7)，其中0最高，7最低。一般面向控制的信息优先级为3，面向数据的信息优先级为6。在系统中，要求响应速度越快的控制子系统其控制信息优先级越高。 保留位(R) :1位，此位清零，留待SAE将来使用。 数据页(DP) : 1位，分为0页和1页。DP用来做数据页的选择，目前参数群编号PGN(包括保留位、数据页、PDU格式和特定PDU四个部分)大部分定义在0页，1页供将来扩展使用。 源地址(SA): 8位，网络中一个特定的源地址仅匹配一个装置以确保CAN标识符的唯一性。 数据域:CAN数据帧只有8个字节的数据域，因此如果所要发送的数据超过8字节，就应该分成几个数据帧来分批发送。数据域的第一个字节从1开始作为报文的序号，后7个字节用来存放数据，所以PDU1格式和PDU2格式一共最多可以发送255 X 7 =1785个字节的数据，报文被接收以后按序号重新组合成原来的数据。当传递速率大于10次/S时，则不允许多帧发送。,纯电动汽车整车电气设计及整车CAN通讯,19,SAE J1939中，信息优先级顺序：,纯电动汽车整车电气设计及整车CAN通讯,20,CN2004B DATA定义格式与ID定义,纯电动汽车整车电气设计及整车CAN通讯,21,ID解析：,纯电动汽车整车电气设计及整车CAN通讯,22,总结与展望,近期做了很多关于整车电气系统设计的工作，但还有很多不足： （1）整车电气设计的合理性，与各位同事所作部分的兼容性； （2）CAN总线通信刚刚上手，节点分配与协议部分都比较生涩； （3）仅对整车电气系统有个整体的了解，具体到各子系统所需的电压、电流、功率范围、工作状态、信息交换的概念还比较模糊； 接下来一段时间的工作重心要放在整车通信部分的理论研究，深入了解CAN总线通信协议与节点分配规则，整车通信是协调各子系统工作状态的重要基础，需要有扎实的理论知识做铺垫。 远期的工作要注重建立全面的总线检测系统，系统内部和外部的各种电气干扰、系统本身的结构设计、元器件的选择以及系统安装，外部的环境条件等，都会导致通信系统误差加大、传输失常等情况的发生，要解决这些必须从软件和硬件上着手，增强抗干扰功能，建立完善的错误报告和故障处理机制。,
