車輛CAN網絡休眠異常監控方法研究

張新宇 李朋飛 周紅英 段金亮

摘 要：針對汽車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].