canoe capl写的uds基础代码脚本测试用例 1、10服务和22服务测试用例，拿去参考...

canoe capl写的uds基础代码脚本测试用例 1、10服务和22服务测试用例，拿去参考，自己搭的发送和接收函数，拿去做做基本的uds测试没问题。 2、节点dtc丢失与恢复测试，19服务读取dtc，验证dtc存在。

最近在折腾UDS诊断测试脚本，顺手整理了点基础测试用例。拿canoe的CAPL撸代码其实挺有意思的，虽然一开始被字节序折腾得够呛。分享两个常用服务的测试套路，直接上硬货。

canoe capl写的uds基础代码脚本测试用例 1、10服务和22服务测试用例，拿去参考，自己搭的发送和接收函数，拿去做做基本的uds测试没问题。 2、节点dtc丢失与恢复测试，19服务读取dtc，验证dtc存在。

先说10服务和22服务这对黄金搭档。会话控制配数据读取，简直就是诊断界的泡面搭档。我习惯把收发函数单独封装，比如这样：

// 发送请求报文 void SendRequest(byte serviceId, byte subFunc, byte dataIdentifer[]) { byte msg[8]; msg[0] = 0x03; // 假设是单帧 msg[1] = serviceId; msg[2] = subFunc; if(serviceId == 0x22) { msg[3] = dataIdentifer[0]; msg[4] = dataIdentifer[1]; } // 发送到总线... } // 接收响应处理 on message 0x732 // 假设响应ID { if(this.byte(0) == 0x03) { // 正响应 if(this.byte(1) == 0x50) { // 10服务响应 write("会话模式切换成功"); } else if(this.byte(1) == 0x62) { // 22响应 parseData(this.byte(3), this.byte(4)); // 解析数据 } } else { // 负响应 handleNRC(this.byte(2)); // 处理错误码 } }

测试10服务的时候重点玩转子服务参数。比如先切默认会话再切编程模式：

testCase("10服务_默认会话") { SendRequest(0x10, 0x01, null); // 等响应 if(getRespCode() != 0x50) { testFail("没切到默认会话"); } } testCase("10服务_编程会话") { SendRequest(0x10, 0x02, null); // 这里可能需要安全访问 if(getRespCode() == 0x7F) { retryWithSecurity(); } }

22服务测试要特别注意数据对齐。比如读取车速0xF40A：

testCase("22服务_读取车速") { byte did[2] = {0xF4, 0x0A}; SendRequest(0x22, 0x00, did); // 假设车速是uint16类型 word speed = (respData[0] << 8) | respData[1]; if(speed > 300) { testWarning("车速数据异常"); } }

再说说DTC测试这个磨人的小妖精。19服务最骚的操作是带状态掩码查询。比如突然拔掉某个节点电源模拟DTC丢失：

// 正常状态读取DTC testCase("19服务_DTC存在") { SendRequest(0x19, 0x0A, null); // 读取所有DTC if(findDTC(0xP1234) == 0) { testFail("该有的DTC没找到"); } } // 断电后检测 testCase("节点DTC丢失") { powerOff(Node_ECU1); delay(1000); SendRequest(0x19, 0x0A, null); if(findDTC(0xP1234) == 1) { testFail("断电后DTC还在？"); } } // 恢复供电后检测 testCase("DTC恢复测试") { powerOn(Node_ECU1); doCyclicDTCUpdate(); // 模拟运行几个循环 SendRequest(0x19, 0x0A, null); if(findDTC(0xP1234) == 0) { testFail("DTC没自动恢复"); } }

这里有个坑要注意：19服务响应的DTC列表是打包成三字节一组，得用位运算拆解：

int findDTC(long searchDTC) { for(int i=0; i<respDataLen; i+=3) { long dtc = (respData[i] << 16) | (respData[i+1] << 8) | respData[i+2]; if((dtc & 0x00FFFF) == searchDTC) { return 1; } } return 0; }

实际测试中发现有些ECU喜欢在DTC状态字节里玩花样，比如0x08表示待处理故障。这时候得把状态掩码玩明白：

byte statusMask = 0x08; // 只关注待处理故障 SendRequest(0x19, 0x0A, &statusMask);

这些测试脚本虽然基础，但足够应付80%的日常验证。特别是新搭环境的时候，拿这几个用例当探针，能快速摸清ECU的响应套路。下次再聊聊用0x2E服务写数据时遇到的玄学问题，那才叫刺激...