文章目录

前言一、概述1.主节点2.从节点

二、从节点诊断测试1.CANoe ISC方式2.CAPL自动化脚本方式

三、主节点诊断测试1.帧超时时间（高低压）&节点丢失2.应答错误故障码

总结

前言

<code>本文暂不谈及3类从节点诊断等LIN诊断协议的具体深入内容，主要了解一下LIN的主从节点诊断如何在CANoe进行测试，以及涉及数据链路层的LIN相关诊断测试实战如何进行CAPL自动化用例编写。

一、概述

1.主节点

主节点通常是高性能ECU，主节点可以用CAN线进行诊断测试。通过节点的CAN diag_req\diag_resp报文进行DTC信息读取。

2.从节点

从节点通常是不参与复杂数据通信的执行器ECU，通常从节点能够传输简单的诊断信息，比如错误信息标志位。LIN从节点诊断使用诊断帧来传输诊断或配置信息，包含8个字节数据。标识符：

a.主机请求帧（主节点发送帧头+主节点发送应答） 0x3C

b.从机应答帧（主节点发送帧头+从节点发送应答） 0x3D

二、从节点诊断测试

1.CANoe ISC方式

需要开启主模式，通过Frames定义3C、3D周期报文，间隔100-150ms。具体报文设置如下图，缺点是每测一个DUT都要新建一次ISC诊断报文。

因此，该方法适用于节点级手动测试或者回归测试复现相关问题。

2.CAPL自动化脚本方式

LIN网络上新增node，加入CAPL脚本，如下。脚本中发送3C后给一个100ms定时器，时间太短不行（从节点没初始化完成）。

<code>/*@!Encoding:936*/

/*-------------CAPL脚本实现LIN诊断3C、3D报文发送---------------------*/

includes

{

}

variables

{

linFrame *msg;

linFrame *msg1;

msTimer header_msg_send;

}

on timer header_msg_send

{

output(msg1);

}

void LIN_Diag_Simulation()

{

msg.id = 0x3C;

msg.msgChannel = 20;

msg.dlc=8;

msg.rtr = 1;

msg.byte(0) = 0x03;

msg.byte(1) = 0x02;

msg.byte(2) = 0x10;

msg.byte(3) = 0x01;

msg.byte(4) = 0x00;

msg.byte(5) = 0x00;

msg.byte(6) = 0x00;

msg.byte(7) = 0x00;

output(msg);

write("TEST SUCCESS");

msg1.id = 0x3D;

msg1.msgChannel = 20;

msg1.dlc=8;

msg1.rtr = 1;

settimer(header_msg_send,100);

}

on key 'a'

{

LIN_Diag_Simulation();

write("go to");

}

注意：如下图，脚本方式发送诊断命令，从节点不能失效处理，否则没有3D应答帧。原因：从节点失效，LDF文件中定义的3D报文失效，LIN通讯始终是遵循LDF文件调度。（踩坑：不能认为有从节点样件就失效掉该节点）。

三、主节点诊断测试

主节点的诊断测试数据链路层主要涉及到帧超时时间（高低压）、节点丢失、应答错误故障码等用例，下面将具体节点级测试中脚本优化和需要注意的地方进行说明。

1.帧超时时间（高低压）&节点丢失

脚本核心在于处理仿真从节点的丢失与正常发送。实现方式：在vTESTStudio中使用系统变量，关联至Simulation Setup从节点Node中的CAPL脚本（如下）进行节点的激活与失效，仿真实现节点丢失。

<code>/*--------触发节点丢失及恢复 add qhz 2022.10.15------------------------*/

on sysvar sysvar::LIN_Simulation::linActivate

{

if (@sysvar::LIN_Simulation::linActivate==1)

{

linactivateResps("node name1"); //恢复指定节点

linactivateResps("node name2");

write("仿真节点发送报文,%d",linactivateResps("node name2"); //打印结果

}

else

{

linDeactivateResps("node name1"); //丢失指定节点

linDeactivateResps("node name2");

write("停止节点发送报文,%d",linDeactivateResps("node name2"); //打印结果

}

}

Trace现象：从节点报文先正常发出，linDeactivateResps方法生效后出现错误帧。

2.应答错误故障码

处理从节点报文应答错误脚本。实现方式：在vTESTStudio中使用系统变量，关联至从节点node中的CAPL脚本（如下）进行仿真实现节点的应答错误响应控制。推荐使用下面的优化方式2代码。

<code>/*原脚本

存在问题：在VTEST中调用linSetRespError不生效，不确定哪个从节点生效？

可以使用SetBusContext(GetBusNameContext("网段name"))函数进行环境通道配置

*/

int count = 1;

for(j=0;j<count;j++) // 1次response_error为1，之后为0

{

linSetRespError(1); // 设置\重置调用从节点的响应错误标志 0:reset 1:set

testWaitForTimeout(200);

}

linSetRespError(0);

/*优化方式1

实现：使用系统变量进行CAPL脚本关联，CAPL脚本加在从节点node中进行调用

缺点：每测一个network都需要加一次CAPL脚本，麻烦

*/

//case脚本通过关联的系统变量去执行Node中的脚本

for(j=0;j<count;j++) // 1次response_error为1，之后为0

{

@sysvar::LIN_Simulation::linSetResp = 1;

testStep("","记录设置响应错误标志时刻，便于trace定位");

testWaitForTimeout(200);

@sysvar::LIN_Simulation::linSetResp = 0;

}

@sysvar::LIN_Simulation::linSetResp = 0;

//Node中的脚本如下：

on sysvar sysvar::LIN_Simulation::linSetResp

{

if (@sysvar::LIN_Simulation::linSetResp==1)

{

linSetRespError(1);

}

else

{

linSetRespError(0);

}

}

/*优化方式2

实现：使用setSignal函数直接改变应答错误信号值，把应答信号name存在配置文件中

*/

for(j=0;j<count;j++) // 1次response_error为1，之后为0

{

setSignal(SignalName,1);

testStep("","记录设置响应错误标志时刻，便于trace定位");

testWaitForTimeout(200);

}

setSignal(RepSignalName,0);

Trace现象：从节点应答报文正常发出后，linSetRespError(1)生效会使得报文中的ErrResp信号置为1，如下图。

使用CAPL自动化脚本执行过程中，在调用linGotoSleep等CAPL自带函数的时候，可能会存在函数不生效的情况。例如：添加LDF文件后，脚本调用linwakeup()方法trace窗口没有唤醒报文发出。这是需要检查ISC配置，第二个图标不能勾选。

图标2的含义是：激活或停用CAPL命令过滤，用于控制分配网络的LIN主控功能。如果点击激活，则会忽略linGotoSleep等CAPL函数。

总结

LIN协议相对于CAN协议而言内容较为简单，但实际协议一致性测试过程中，仍然也有很多地方需要去考虑。特别是本文介绍的从节点诊断如何进行测试、主节点的诊断自动化脚本如何合理化、状态管理如何测试以及之前文章提到的休眠唤醒测试细节点等等，都值得设计、推敲来满足测试要求。