LIN控制器休眠唤醒类型方式及测试案例

这次我们的介绍主题是LIN休眠唤醒，一起看看标准和差异性，开发和测试的关系，实际的案例分享也来了。

01、LIN控制器休眠唤醒类型介绍

虽然新架构的发展促进着通信技术的升级换代，但作为车载通信技术的常青树之一的LIN通信，由于其自身的特点，将会继续发光发热。其中LIN的休眠唤醒作为整车休眠唤醒的重要组成部分，需引起开发和测试工程师足够的重视。本文将介绍此方面的内容，LIN总线是主从结构，下面将从LIN主/从节点分别展开。

主节点休眠唤醒

主节点的唤醒条件在LIN协议2.1规范中定义的是被唤醒信号唤醒，但是实际应用OEM多是依据自己的需求进行开发的。

常见的几种唤醒方式如下：

1．硬线唤醒（硬线唤醒源实质就是定义唤醒线的电平变化，如传统车的KL15上电）

2．网络唤醒（网络唤醒即是网络管理报文唤醒，此处网络管理报文指的是LIN的上层网络总线（CAN/FlexRay），LIN本身不存在网络管理报文，上层网络唤醒伴随LIN网络唤醒）

3．特定信号唤醒（例：车辆使用模式信号为特定值时LIN网络才能唤醒）

规范描述在主节点不发送帧头时，从节点应发送唤醒信号来唤醒主节点。这种唤醒必须满足两个条件：

1．从节点必须支持发送唤醒信号

2．主节点能够被唤醒信号唤醒

但是实际测试中发现，从节点一般不支持发送唤醒信号唤醒（实车测试遇到过网络唤醒休眠异常情况，排查发现为从节点阳光雨量控制器不断发送唤醒信号导致的，即取消了该控制器能发送唤醒信号的功能）。

随着局部网络唤醒的应用，主节点唤醒方式大多为网络唤醒，LIN网络做成与上层网络同睡同醒的机制。 主节点休眠的最终表现形式都是发送睡眠指令，当然休眠与唤醒本就是强关联，且主节点的唤醒休眠条件多是依据OEM自身需求而定，我们就不进行展开了。

从节点休眠唤醒

从节点的唤醒条件同样为接收到唤醒信号，LIN协议2.1规范中描述从节点唤醒条件可能为接收到主节点发送同步间隔场，这是LIN通信机制的缘故，从节点进行通信必须接收到主节点发送的帧头才能发送从节点响应部分，而帧头可以充当唤醒信号，从节点在接收到唤醒信号完成初始化后即可正常通信。

规范描述从节点的两种休眠条件如下：

1．接收到睡眠指令

2．总线空闲4-10S

正是由于从节点需求的通用性，我们才能总结出各零部件供应商的实现差异点，沉淀测试经验来优化我们的测试。其中从节点最典型的测试就是休眠唤醒遍历测试，下文将对此进行详细展开。

02、休眠唤醒测试案例分享

案例1：连续仿真发送从节点响应的某帧帧头时，样件会不断重复休眠唤醒的过程。

造成该现象的根本原因是该零部件供应商除了上述两种休眠条件外还增加了另外一个休眠条件：检测主节点丢失（即接收到主节点的发送报文）；我们测试休眠唤醒为了避免其它帧头对测试造成影响，所以选择该从节点响应的某一帧进行休眠唤醒测试，这就造成了主节点丢失的条件，从节点会进入休眠；休眠之后又会被周期仿真的帧头唤醒，所以就出现重复休眠唤醒的现象。

检测到主节点丢失休眠条件在各节点工作正常是不会产生任何影响，但可以在LIN总线短地的条件下使样件进入休眠，防止由于LIN线短地造成样件无法休眠导致整车馈电，此是在满足标准基础上的设计优化。当然，具体的问题要依据具体设计而定，有可能总线空闲的判断逻辑覆盖了低电平时情况，未检测到电平变化就识别为总线空闲，这样就无需增加休眠条件了。

案例2：样件在接收到睡眠指令后偶发性不能进入休眠。

测试用例我们一般遍历测试接收到睡眠指令后等待300-1100ms样件是否都能正常进入休眠；

造成该问题的根本原因是样件在接收到睡眠指令后有一个预休眠处理，时间为500ms（功能设计于数据保存），在预休眠期间样件不会识别任何帧头；所以只要是遍历等待时间小于500ms，依据自动脚本等待时间代码的时间叠加，就造成样件偶发不能进入休眠的现象。

由于特殊样件有特定的需求，这种情况我们就会优化我们的测试方法。同时在此基础上可以延伸出等待总线空闲临界点的休眠唤醒测试的新场景。

总而言之，测试设计以具体需求设计为基础，用以高效发现问题，以及评估设计合理性，这是一个消化吸收、总结沉淀、扩展延伸的过程，需要对设计需求有深入的理解，需要关注和了解具体的实现方法，需要在测试过程中实践和分析。

03、小结

通过上述的介绍，相信大家对LIN唤醒休眠有了一定的了解。由于LIN主节点多是OEM根据自己的需求进行开发，就没有对主节点的唤醒休眠测试进行展开；如果大家想了解常见的唤醒方式（同睡同醒），可参照AUTOSAR网络管理部分的分享内容。

审核编辑：郭婷