张新宇 李朋飞 周红英 段金亮

摘 要：针对汽车CAN网络中电控系统休眠异常问题，给出网络休眠异常原因和相应分类;在OSEK网络管理协议基础上，分析该OSEK直接网络管理下汽车ECU节点协同休眠逻辑，设计扩展OESK-NM报文和休眠监测诊断策略，建立了整车CAN网络休眠异常在线监控方法。该方法易于软件模块化实现，可为网络休眠异常的诊断提供数据支持，有效提高CAN网络故障排查的便利性。

关键词：CAN网络;网络管理;休眠;诊断

中图分类号：U462.1  文献标识码：A  文章编号：1671-7988（2020）17-87-03

Research on Monitoring Method for The Abnormal Sleeping of CAN Network

Zhang Xinyu， Li Pengfei， Zhou Hongying， Duan Jinliang

（Anhui JiangHuai Automobile Co.， LTD.， Technical Center， Anhui Hefei 230601）

Abstract： For the abnormal sleeping of the electronic control units （ECUs） in the vehicular CAN network， the reasons and classification of abnormal network sleeping are presented. Based on OSEK NM （Network Management）， the cooperative sleeping mechanism of ECUs under OSEK direct NM is analyzed， the extended OESK-NM message and diagnosis strategy are proposed and the online monitoring strategy of abnormal sleeping for vehicular CAN network is established. The method can be implemented more easily by the software modularization. It can provide data support for the diagnosis of network abnormal sleeping， and effectively improve the convenience of CAN network fault detection.

Keywords： CAN network; Network management（NM）; Sleep; Diagnostic

CLC NO.： U462.1  Document Code： A  Article ID： 1671-7988（2020）17-87-03

引言

随着汽车智能化的发展，电子控制器之间通过总线技术互通互联，传递控制信息。各控制器通常通过网络管理技术来协调控制器之间工作步调一致，但是，实际应用过程中，由于软件漏洞或硬件失效等异常因素造成的控制器无法正常休眠的事件也时常发生。特别是随着智能网联汽车的兴起，在车辆静置的情况下仍然会有总线通信的需求，休眠唤醒的频次增多，造成异常事件出现的几率增加。

车辆休眠异常带来的是车辆的静态能耗成倍的增加， 进而严重的会导致汽车蓄电池电量耗尽，无法起动车辆等故障。这给客户对车辆的使用带来极大的不便，另外、在售后维修方面也缺乏有效的技术手段去定位这类故障产生的准确原因，大大增加了维修技师排查车辆问题的难度。

本文将重点研究如何利用车辆网络状态管理，提出一种监控控制器休眠及网络异常事件的方法，最终异常状态将会被记录内部存储空间，在维修时，可以通过读取被记录的故障信息，快速锁定出现异常的控制器或网络异常事件的原因，并用来制定维修方案。

1 车辆休眠异常事件分析

1.1 车辆基本通讯网络概述

汽车上控制器从工作条件上可以划分为两种。一种是常电（KL30）工作的控制器，另一种是点火电（KL15）工作的控制器。在典型的汽车网络架构上，常电工作的控制器在一路CAN总线上，点火电工作的控制器在另一路CAN总线上。由于车辆休眠异常均发生在常电工作的控制器，所以本文只研究常电工作的控制器。

常电工作的控制器一般都需要参与网络管理，网络管理的主要作用有：

1.1.1 网络通信的管理

网络管理控制ECU初始化，网络模式和休眠唤醒的开始/结束时间。

1.1.2 处理通信故障

例如：Busoff故障发生时网络管理知道如何处理。

1.1.3 网络其他节点监测

可以对参与网络管理的其余节点状态进行监测。

1.2 网络休眠异常类型划分

网络休眠异常按照故障表现的不同可以划分为：

（1）网络无法休眠;

（2）休眠后异常唤醒。

对于单个控制器来说，无法休眠原因又可以劃分为主动异常和被动异常。

主动异常是指该控制器由于软件漏洞或硬件失效，导致唤醒源一直存在，以致控制器无法进入休眠状态。

被动异常是当前控制器已经满足休眠条件，但由于接收到其他控制器有使用网络的需求，而无法进入休眠状态。

2 OESK网络管理及异常监测

2.1 网络休眠逻辑

參与OESK网络管理的ECU的休眠唤醒策略遵循从初始化、建立令牌环、休眠指示、总线休眠四种状态。在初始化阶段，ECU初始化网络控制参数，并基于OSEK协议发送Alive报文，之后基于OESK协议与同网段其他ECU建立令牌环。在ECU判断出本地满足休眠条件后，会发送休眠指示，直到所有令牌环内的ECU均发送休眠指示后，第一个发送休眠指示的ECU发出包含休眠确认的消息，之后等待一段时间后关闭总线控制器，整个网络进入休眠状态。

ECU休眠判断逻辑如下图1所示：

2.2 网络休眠异常监测方法

依照上文对网络休眠故障的划分，网络休眠故障一种是不能够休眠，一种是休眠后异常唤醒。

对于网络不能够休眠的情况，从ECU的休眠逻辑判断可以知道，在参与网络管理的所有ECU中存在一个或者多个ECU不能满足本地休眠条件。

对于网络休眠后异常唤醒，从ECU的休眠逻辑分析有两种情况，一是发生在休眠确认之后和网络休眠期间，另一种是发生在整体网络休眠之后。无论是哪种情况，网络管理状态都是回到初始化。异常唤醒的唤醒源存在本地唤醒源和网络唤醒源两种，无论哪一种非预期的唤醒都是系统对网络通信需求的错误判断。

在OESK-NM报文的协议数据单元（PDU）中，除了协议规定的源节点地址（SA）和目的节点地址（DA），控制域（CF）之外，剩下的数据区域为可选的数据区域。在OESK NM-PDU的基础上扩展，将可选的数据区域中定义两个字节的唤醒源标识符，如下图2所示，定义Byte6-Byte7为唤醒源标识符。

该唤醒源标识的定义如下表1-2：

其中，Byte6的低4位Bit0-3为保留空间。

其中，Byte6的Bit4定义为Busoff恢复的唤醒源。

其中，Byte6的Bit5定义为网络唤醒源，在CAN总线上即为来自于CAN收发器的唤醒源。

Byte6的Bit6-7以及Byte7中的Bit0-7共计10Bit，每一位分别定义一个或一类唤醒源，由各个ECU根据自身控制器的本地唤醒源来定义具体含义。

在网络管理状态更新的同时更新唤醒源的状态，如果唤醒源有效，该位置1，唤醒源无效，该位置0;在该ECU发送网络管理报文时，将唤醒源标识信息同步到网络管理报文中。

对于网络休眠异常时，可以采用在令牌环内的ECU互相监控的方法来监测网络休眠异常原因。实施的逻辑策略为，当某个ECU满足本地休眠条件满足进入休眠等待NM_ SleepInd = 1时，启动休眠监测诊断。如下图所示：

休眠监测诊断策略如下：

（1）ECU监测目的节点的网络状态，当目的节点网络状态为Active状态（NM_SleepInd = 0），暂存记录目的节点的节点地址和唤醒源标识;当目的节点网络状态为NM_ SleepInd时，删除上述记录。

（2）ECU设定一个休眠超时计时器TBusSleep Timeout，计时器的时间参数可以根据不同车辆实际情况，或者不同的使用条件下设定不同的时间参数。当ECU满足TBusSleep Timeout之后，如果目的节点网络状态为Active状态，则将目的节点地址及唤醒源标识转换为故障码存储到内部存储单元。该故障码的格式定义为：

网络休眠监控流程如图4：

2.3 异常休眠数据读取

一旦总线上发生了网络不休眠或被异常唤醒过的现象，那么总线上这些网络管理的节点就可以一对一的记录异常休眠数据的故障码。可以使用总线设备直接观测休眠异常的节点和存在的唤醒源，也可以和其他类型的故障码一样，可以通过诊断设备发送读取指令来读取故障码，从而很容易来锁定网络休眠异常的原因。

3 结论

本文通过整车网络应用中出现的网络休眠异常的情况进行了分析研究，并在OSEK 网络管理协议的基础上，利用了OESK网络管理的令牌环特性和协议数据单元可扩展的特性，拓展了一种用于监控网络休眠异常的策略。ECU不需要关心网络上其他ECU分别是什么，只需要通过OSEK的网络管理监控令牌环上目的节点的状态即可，因此更容易模块化软件，用在不用的车型和网段上。 在售后维修服务方面为网络休眠异常的监测和定位带来数据支持，提高了故障排查的便利性。

参考文献

[1] OSEK/VDX Committee.Communication specification version3.0.3 [EB/OL]， [2006-05].

[2] OSEK/VDX Committee/Network management specification.version 2.5.3[EB/OL]， [2006-05].

[3] OSEK/VDX Committee.OSEK implementation language specifieali -on，version 2.5[EB/OL]，[2006-05].

[4] ISO.Road vehicles：Communication between vehicle and external experiments for emission-related diagnostic，ISO 15031[EB/OL]， [2005-06].

[5] ISO.Road vehicles：Open interface for embedded automotive applica -tions，ISO 17356[EB/OL]， [2005-01].