LIN网络管理：休眠&唤醒测对了吗

---

LIN的休眠唤醒在ISO 17987协议中介绍的非常清楚，实际的协议一致性测试中如何正确测试及评估测试结果是本文的重点。

一、协议概述

LIN网络管理主要指休眠和唤醒。

休眠

1、主机节点发送休眠命令进行休眠；
2、或者总线静默4s~10s（没有显/隐性位之间的转换）节点自动进入休眠状态。

唤醒

LIN网段上的主/从机节点都可以向总线上发送唤醒信号，唤醒信号持续 250μs～5ms的显性电平（5个bit位）。其余节点(除发送唤醒信号以外的节点)以大于 150μs 为阈值判定唤醒信号。

这里有几个细节点：
1、唤醒信号持续 250μs～5ms，按照位时间51us计算，至少是需要5个显性bit位。
2、主机节点的同步间隔段也可以充当唤醒信号（理由：同步间隔段时至少由13个显性位组成，按照位时间51us计算，此时的显性电平持续时间为51*13=663us，满足唤醒信号要求。)
3、如上图，协议规定唤醒信号最多可以发送 3 次，3 次之后，必须等待至少 1.5s 之后才可以再次发送唤醒信号。

二、休眠测试（节点级）

1.测试场景

利用诊断帧中的主机请求帧0x3C作休眠命令，要求Byte0=0x00，其余Byte=0xFF。节点能够正常休眠。

当发送的0x3C报文数据场内容有误时，如下图Byte1=0x1时，节点不休眠。

2.问题描述

在发送错误的3C休眠报文时，结果出现Trace窗口报文停发，电源电流变为0，理所应当的会判断为节点休眠。与上述测试场景预期结果不符（不休眠），认为节点有故障。实际真的如此吗？

3.结果分析

Trace窗口上报文停发并不一定是响应3C休眠命令导致的。发送3C休眠报文，LDF调度表跳转到LIN诊断调度表中，Trace上报文立即停发只是因为没有切换回Normal调度表。因此，对于节点休眠的判断应该回归到电流上。

• 正确的3C报文发送后节点立即休眠，电流在ms级别内变为0。
  从波形图可以看到节点休眠的时间差为4.574ms。
  
• 错误的3C报文发送后节点没有休眠，4s后电流变为0。
  从波形图可以看出，错误的3C报文发出后，因调度表在诊断调度表中没有切换回Normal调度表，导致报文停发，但是LIN线电流没有降为0。报文停发后，没有显/隐性位之间的转换，4s后因总线空闲导致休眠。时间差为4.009s印证此结论。
  
  注：若没有示波器条件，可进行程控电源电流监测，立即变0还是4秒变0。

而总线静默4~10s后进入休眠模式的Trace效果如下图。

综上，发送错误的3C休眠报文，被测LIN节点是没有休眠满足预期的。表现上看着像是休眠了，是因为总线静默4s~10s休眠，而不是发送休眠命令导致的休眠。

三、唤醒测试（节点级）

唤醒测试在CANoe中主要用到linWakeup函数进行自动化实现。下面通过代码来了解一下具体实现。

测试前提：
1、测试中，首先要能保证唤醒脉冲正常发出。可以在LIN线上接入示波器，观测唤醒脉冲是否正常发出。
2、要确保被测节点处于休眠状态。当LIN硬件未处于睡眠模式时，调用linWakeup将无效。可以通过linBusIsAwake()来查询LIN总线的唤醒状态。

//通过on key事件在手动验证的时候触发
on key 'a'
{
	linWakeup(150, 3, 300);
    /*参数介绍：结合第一部分概述介绍的唤醒波形图很容易理解
    150：连续两个信号之前的延迟，单位：ms
    3：发送唤醒信号的次数
    300：唤醒信号显性电平的持续时间
    */
}