几乎所有的ECU，都要做CAN方面的测试，BCM、EMS、VCU、BSG、BMS、TCU、EPS、ADAS等，只要带CAN端口，都需要做这样的测试，几乎所有OEM都要求供应商CAN测试。
诊断通信定义
对于绝大多数车企而言，诊断通讯的定义沿用的是UDS框架，只是所定义内容各自略有不同。
读故障请求示意图
假如诊断通信所用的ID分别为0x703（CANoe→被测ECU）和0x723，那么：
CANoe读取被测ECU的故障值的方式为：发数据 “03 22 DE 62”，然后被测ECU返回ID 0x723，数据区首先包含返回的估值字节数，然后按照类似dbc的Multiplexer的定义方式，用滚动ID的方式，返回各个ECU的故障值
CANoe读清除被测ECU的故障值的方式为：发数据 “04 14 ”，然后被测ECU返回ID 0x723，数据区包含清除结果，或成功清除，或者需要等待，正在清除中。
清除故障命令，所返回的结果，要么成功，要么等待中，但是读取故障，返回的值比较复杂，需按照类似dbc的Multiplexer的定义方式，将结果拼接成一个长数据，再根据故障位置的定义，从对应的位置去索引故障状态结果的值。
一般而言，由于整车功能规划和通信协议矩阵的变化，对于被测ECU，所接收的ID是不固定的，不同项目、不同车型平台之间很容易出现变动。但是所接收的ID来自于哪些ECU，是比较固定的，再加上ID的数量要远多于ECU的数量，所以，被测ECU返回的“拼接数组”，在全行业看，是以发送方控制器为基本单元进行索引的，而不是以发送方发送的ID。换句话说，被测ECU所接收的其中2个ID，如果来自同一个控制器，则它们两个分别掉线之后从被测ECU返回的诊断故障数据，是完全一样的。
CAN故障诊断测试包含哪些项？
假如被测ECU接收了15个ID，每个ID都有自己的周期，那么，如果某一个ID掉线了（包括长期掉线和短暂掉线），ECU应该怎么处理？报什么故障值？如果是短暂掉线，报文又恢复了，又该报什么故障值？
整车一般有一个总控模块，当它发的某个信号为1的时候，其他模块才能激活故障记录功能，如果发0，其他模块禁止记录故障，这个总控模块一般为BCM或者网关。那么，就需要检查一下，它发0的时候，其它是不是真的没有记录，它发1的时候，是不是真的记录了，有没有做到“令行禁止”？
当CAN总线被CANstress持续干扰（比如RTR位被干扰），被测ECU busoff了，之后再取消干扰，被测ECU有没有自动bus off recovery，且正常工作？再检测到故障时（比如某个ID掉线了），有没有正常记录掉线故障值？能不能正常返回故障？
当所接收的报文的DLC和定义的不一样时，被测ECU应对其抛弃，认为没有接收到正确报文，按照掉线处理。读取故障时，应能返回正确的故障。它实际上有没有做到这样？
当被测ECU持续接收不到ACK时，应当报发送错误，但不应当有错误帧，也不应当bus off，而是该怎么工作还怎么工作。它实际上有没有实现这个要求？
测试方案设计
PC：需要安装LabVIEW和CANoe，且CANoe需要能正常调用框图中所有Vector体系内的硬件。即CANoe的CAPL语言要能正常调用这些硬件。
VN1640：在本系统的功能为记录总线数据。
CAN卡：用于和被测ECU之间收发报文，是上图测试方案的核心部件。因为牵涉到多周期报文的发送，在CAPL中实现非常繁琐，而且需要按照Multiplexer的定义方式拼接信息数组，所以需要该CAN卡能够较好地支持底层调用。
可编程电源：用于给被测ECU供电，如果公司内部有Vector系列的可编程电源，可通过CAPL调用，那可以直接应用。如没有，可以采购更便宜的可编程电源，通过LabVIEW调用亦可。
CANstress：给被测ECU制造总线干扰，属于关键设备，建议采用Vector的。
案例说明
假设要测试VCU控制器，VCU控制器共接收25个ID（见图1），测试让ID逐个掉线，然后读取被测对象返回的故障值，再使掉线的ID恢复，然后再清除故障，掉线时长分别为：T1，T2，T3，T4，相应返回故障值的期望也会有区别，然后把所有ID轮一遍。
- LabView调用电源，重启被测对象
- 按照定义好的ID，周期，DLC，向被测ECU发送报文
- 执行for循环，对所有ID执行四次掉线，时长分别为：T1，T2，T3，T4，并分别读取故障、核对故障、清除故障
LabView和CANoe之间，可以通过软件之间的调用关系来挖出，这些参数载CAPL中以变量形式存在，可以充分挖掘CAPL高级功能。可以把CAPL做出标准化功能模块，用LabView灵活调用即可。
图1
标签：掉线,被测,车载,故障诊断,故障,ECU,测试,ID From： https://www.cnblogs.com/laoluoits/p/16944035.html