ECU在外围传感器和执行器发生故障时，必须能够自我保护，不至于损坏ECU，因此在硬件设计中必须具有如下的保护功能： ? 电源反接保护
? 电源的浪涌，过压保护 ? ESD保护(防静电)
? 功率器件过压，过流，过温保护 ? 对地，对电源短接和开路保护及诊断 ? 地线丢失保护
7） 控制器中芯片选型原则
针对一定的用途适当的，恰当选择微处理器是设计过程中首先需要确定的。对于明确的对象，选择功能过少的微处理器，无法完成控制任务；选择功能过强的微处理器则会造成资源浪费，使性能价格比下降。为此确定了如下选型原则 a) 适用性。
所谓适用性就是能否用一个单片机完成对系统的控制，或者需要增加附加的电路才能实现控制的目的。为此，首先应该考虑是否含有所需的I/O端口的数目，这是选型过程的一个基本参考；其次是否有合适的吞吐量，即针对应用系统的需要，单片机所具备的执行控制时的处理能力，主要表现在运行速度、指令功能、指令周期的长短、中断能力和堆栈大小等指标上；第三极限参数是否满足要求，这里是指在特定的应用环境下，使用的温度范围、电压范围、最大功耗、最大电流等参数。 b) 可购买性。
为保证研究工作是否可实现的角度出发了解可购买性是十分必要的。首先要了解所选择的器件是否可直接购买到，这里包括购买的途径是否顺畅、方便，特别是销售服务是否跟得上；其次需了解是否有足够的供应量，一般而言，只要供应量充足的器件在质量方面是有保障的；第三了解是否在仍在生产或改进之中，这一点十分重要，如果已经停产则表明已无后续供货能力，如在改进中则表明可能还存在某些问题。 c) 可开发性。
这是一个十分重要的因素，所选择的单片机是否有足够的开发手段，直接影响能否顺利开发，如果没有足够的开发手段，则不宜选择有关的应用系统，同时首先应关注编译软件，要考虑编译工具的提供是否方便、运行环境、使用是否方便等；其次是调试工具，一个好的调试工具是加快开发过程的必要前提；其三是考虑技术支持能力，在遇到问题时应能得到及时的技术支持；第四是开发语言的体系与熟悉程度，这是体现可开放性的一个重要方面。 3.2.2 整车控制器的软件开发
整车控制器需要应该能适用不同的纯电动客车的要求，因此需要通用的纯电动客车整车控制器软件平台架构，共享模块的标准化。因此整车控制器应该符合汽车AUTOSAR软件结构的特殊要求。AUTOSAR（汽车开放系统架构），汽车开放系统架构联盟是由全球汽车制造商、部件供应商及其他电子、半导体和软件系统公司联合建立，各成员保持开发合作伙伴关系。自2003年起，各伙伴公司携手合作，致力于为汽车工业开发一个开放的、标准化的软件架构。AUTOSAR这个架构有利于车辆电子系统软件的交换与更新，并为高效管理愈来愈复杂的车辆电子、软件系统提供了一个基础。此外，AUTOSAR在确保产品及服务质量的同时，提高了成本效率。参考AUTOSAR对于软件的框架（如图6所示），把整车控制器的软件框架如图7所示。软件采用了分层的模块化体系结构。整个软件由一系列具有标准结构的软件功能模块构成，满足了软件的可配置的需求。
图6 Autosar软件结构框图
应用层通信管理驾驶解释车辆驱动MAP文件函数库实时任务调度系统板上设备抽象单片机驱动存储服务存储硬件抽象存储驱动通信服务通信硬件抽象通信驱动IO硬件抽象IO驱动复杂的驱动库能量管理故障诊断维护管理单片机（硬件）图7 整车控制器软件结构框图
整车控制器的软件包括：微处理器抽象层（I/O驱动、通信驱动、存储驱动和单片机驱动），ECU抽象层（I/O硬件抽象、通信硬件抽象、存储硬件抽象和ECU板上设备的驱动），服务层（实时任务调度系统、函数库、存储服务和通信服务），复杂驱动函数库和应用层组成。
微处理器抽象层是基础软件中最低的层，它包含各种驱动，是一个个软件模块，用于直接访问微控制器内的外设和外围接口。微控制器抽象层提供统一的接口，使上层软件独立于微控制器。其包括：I/O驱动、通信驱动、存储驱动和单片机驱动。
ECU抽象层连接微处理器抽象层的软件，它包含外部设备的驱动，为ECU提供外围设备的驱动程序，ECU抽象层的实现与ECU硬件相关，与微控制器无关。ECU抽象层不对硬件直接操作，都是通过微控制器抽象层的接口实现。其包括：I/O硬件抽象、通信硬件抽象、存储硬件抽象和ECU板上设备的驱动。
复杂驱动库是一整个模块，不进行层次划分。它为处理复杂传感器和执行器实现特殊的功能和定时需求。它包含处理复杂的传感器和执行器的驱动模块，实现上与微控制器、ECU和具体应用密切相关。包含如电动子节气门驱动等模块。
服务层是基础软件中最高的层，为应用和基础软件模块提供基本服务，服务层的实现部分与微控制器、ECU硬件和具体应用无关，服务层在很大程度上独立于硬件系统。其包括：实时任务调度系统、函数库、存储服务和通信服务等。
应用层是整个软件中的最高层，针对纯电动客车的专门应用程序，应用层完全独立于微处理器和ECU系统。只需要配置不同的能量管理算法就能适用不同
的车型。应用层主要包括：能量管理、维护管理、故障诊断、车辆驱动、通信管理和驾驶解释等。
MATLAB / Simulink / Stateflow仿真 控制策略 驾驶员 模型 驾驶解析 能量管理策略 车辆驱动 车辆模型 TargetLink 整车控制器 图8 能量管理算法开发流程
为了设计出可靠、高效的能量管理策略，借助于matlab的离线仿真技术，通过大量离线仿真可以在减少实车测试的情况下开发出较好的能量管理策略，同时为了避免从开发阶段到实现阶段的沟通问题，保持各阶段之间的一致性，能量管理算法开发采用TargetLink自动代码生成，如图8所示。 3.3 整车控制器的硬件在环测试
电控单元（ECU)的复杂程度快速增加，控制算法与功能不断增强，对整车而言还集成了各种总线通讯功能、在线故障诊断(OBD)等功能。传统的检测方法面对复杂的测试需求开始显得力不从心，硬件在环（HIL）测试是一套与电子控制器真实连接的测试系统，用于检测整车控制器控制功能及逻辑错误、故障等。由于总线技术的发展与成熟，现在汽车已经通过网络实现分布式控制功能。而各个ECU之间的交互作用增加，例如共享传感器、计算信息和执行器等。同时，网络支持多种总线系统(CAN、LIN、MOST、FlexRay)，并且对于整车控制器而言，其核心的控制功能又是基于CAN网络，网络中的ECU大部分由不同的厂商提供，这些都又可能成为潜在错误来源(存在产品召回的风险)，因此整车控制器的测试采用了基于dSPACE的硬件在环测试。
整车控制器预采用基于dSPACE的硬件在环测试系统，如图9所示。首先通过Matlab/Simulink建立除整车控制器外的其他纯电动客车实时仿真模型，建立
的模式可以通过RTW接口下载到dSPACE中，通过实时仿真模型dSPACE具有以下的功能：
1） 产生加速踏板、制动踏板和钥匙等控制信号； 2） 产生档位信号； 3） 实现与控制器的CAN通信
4） 设置总成部件的状态参数，改变边界条件； 5） 设置各种传感器故障；
6） 实时将车辆运行状态参数传给控制器；
通过硬件在环测试系统就可以模拟除整车控制器外的整个电动系统，能够在上车之前对整车控制器的控制功能及控制策略进行全面的测试。
User interface SimulatI/On Model RTW dSPACE CAN bus
线束
Control desk Real-Time Hardware
整车控制器
图9 基于dSPACE系统的硬件在环测试系统
整车控制器在硬件在环测试系统中需要测试的功能如表1~3所示：
表1： 整车控制器硬件功能测试