車輛CAN網(wǎng)絡(luò)休眠異常監(jiān)控方法研究

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

摘 要：針對汽車CAN網(wǎng)絡(luò)中電控系統(tǒng)休眠異常問題，給出網(wǎng)絡(luò)休眠異常原因和相應(yīng)分類;在OSEK網(wǎng)絡(luò)管理協(xié)議基礎(chǔ)上，分析該OSEK直接網(wǎng)絡(luò)管理下汽車ECU節(jié)點(diǎn)協(xié)同休眠邏輯，設(shè)計(jì)擴(kuò)展OESK-NM報(bào)文和休眠監(jiān)測診斷策略，建立了整車CAN網(wǎng)絡(luò)休眠異常在線監(jiān)控方法。該方法易于軟件模塊化實(shí)現(xiàn)，可為網(wǎng)絡(luò)休眠異常的診斷提供數(shù)據(jù)支持，有效提高CAN網(wǎng)絡(luò)故障排查的便利性。

關(guān)鍵詞：CAN網(wǎng)絡(luò);網(wǎng)絡(luò)管理;休眠;診斷

中圖分類號：U462.1? 文獻(xiàn)標(biāo)識碼：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

引言

隨著汽車智能化的發(fā)展，電子控制器之間通過總線技術(shù)互通互聯(lián)，傳遞控制信息。各控制器通常通過網(wǎng)絡(luò)管理技術(shù)來協(xié)調(diào)控制器之間工作步調(diào)一致，但是，實(shí)際應(yīng)用過程中，由于軟件漏洞或硬件失效等異常因素造成的控制器無法正常休眠的事件也時(shí)常發(fā)生。特別是隨著智能網(wǎng)聯(lián)汽車的興起，在車輛靜置的情況下仍然會有總線通信的需求，休眠喚醒的頻次增多，造成異常事件出現(xiàn)的幾率增加。

車輛休眠異常帶來的是車輛的靜態(tài)能耗成倍的增加， 進(jìn)而嚴(yán)重的會導(dǎo)致汽車蓄電池電量耗盡，無法起動車輛等故障。這給客戶對車輛的使用帶來極大的不便，另外、在售后維修方面也缺乏有效的技術(shù)手段去定位這類故障產(chǎn)生的準(zhǔn)確原因，大大增加了維修技師排查車輛問題的難度。

本文將重點(diǎn)研究如何利用車輛網(wǎng)絡(luò)狀態(tài)管理，提出一種監(jiān)控控制器休眠及網(wǎng)絡(luò)異常事件的方法，最終異常狀態(tài)將會被記錄內(nèi)部存儲空間，在維修時(shí)，可以通過讀取被記錄的故障信息，快速鎖定出現(xiàn)異常的控制器或網(wǎng)絡(luò)異常事件的原因，并用來制定維修方案。

1 車輛休眠異常事件分析

1.1 車輛基本通訊網(wǎng)絡(luò)概述

汽車上控制器從工作條件上可以劃分為兩種。一種是常電（KL30）工作的控制器，另一種是點(diǎn)火電（KL15）工作的控制器。在典型的汽車網(wǎng)絡(luò)架構(gòu)上，常電工作的控制器在一路CAN總線上，點(diǎn)火電工作的控制器在另一路CAN總線上。由于車輛休眠異常均發(fā)生在常電工作的控制器，所以本文只研究常電工作的控制器。

常電工作的控制器一般都需要參與網(wǎng)絡(luò)管理，網(wǎng)絡(luò)管理的主要作用有：

1.1.1 網(wǎng)絡(luò)通信的管理

網(wǎng)絡(luò)管理控制ECU初始化，網(wǎng)絡(luò)模式和休眠喚醒的開始/結(jié)束時(shí)間。

1.1.2 處理通信故障

例如：Busoff故障發(fā)生時(shí)網(wǎng)絡(luò)管理知道如何處理。

1.1.3 網(wǎng)絡(luò)其他節(jié)點(diǎn)監(jiān)測

可以對參與網(wǎng)絡(luò)管理的其余節(jié)點(diǎn)狀態(tài)進(jìn)行監(jiān)測。

1.2 網(wǎng)絡(luò)休眠異常類型劃分

網(wǎng)絡(luò)休眠異常按照故障表現(xiàn)的不同可以劃分為：

（1）網(wǎng)絡(luò)無法休眠;

（2）休眠后異常喚醒。

對于單個(gè)控制器來說，無法休眠原因又可以劃分為主動異常和被動異常。

主動異常是指該控制器由于軟件漏洞或硬件失效，導(dǎo)致喚醒源一直存在，以致控制器無法進(jìn)入休眠狀態(tài)。

被動異常是當(dāng)前控制器已經(jīng)滿足休眠條件，但由于接收到其他控制器有使用網(wǎng)絡(luò)的需求，而無法進(jìn)入休眠狀態(tài)。

2 OESK網(wǎng)絡(luò)管理及異常監(jiān)測

2.1 網(wǎng)絡(luò)休眠邏輯

參與OESK網(wǎng)絡(luò)管理的ECU的休眠喚醒策略遵循從初始化、建立令牌環(huán)、休眠指示、總線休眠四種狀態(tài)。在初始化階段，ECU初始化網(wǎng)絡(luò)控制參數(shù)，并基于OSEK協(xié)議發(fā)送Alive報(bào)文，之后基于OESK協(xié)議與同網(wǎng)段其他ECU建立令牌環(huán)。在ECU判斷出本地滿足休眠條件后，會發(fā)送休眠指示，直到所有令牌環(huán)內(nèi)的ECU均發(fā)送休眠指示后，第一個(gè)發(fā)送休眠指示的ECU發(fā)出包含休眠確認(rèn)的消息，之后等待一段時(shí)間后關(guān)閉總線控制器，整個(gè)網(wǎng)絡(luò)進(jìn)入休眠狀態(tài)。

ECU休眠判斷邏輯如下圖1所示：

2.2 網(wǎng)絡(luò)休眠異常監(jiān)測方法

依照上文對網(wǎng)絡(luò)休眠故障的劃分，網(wǎng)絡(luò)休眠故障一種是不能夠休眠，一種是休眠后異常喚醒。

對于網(wǎng)絡(luò)不能夠休眠的情況，從ECU的休眠邏輯判斷可以知道，在參與網(wǎng)絡(luò)管理的所有ECU中存在一個(gè)或者多個(gè)ECU不能滿足本地休眠條件。

對于網(wǎng)絡(luò)休眠后異常喚醒，從ECU的休眠邏輯分析有兩種情況，一是發(fā)生在休眠確認(rèn)之后和網(wǎng)絡(luò)休眠期間，另一種是發(fā)生在整體網(wǎng)絡(luò)休眠之后。無論是哪種情況，網(wǎng)絡(luò)管理狀態(tài)都是回到初始化。異常喚醒的喚醒源存在本地喚醒源和網(wǎng)絡(luò)喚醒源兩種，無論哪一種非預(yù)期的喚醒都是系統(tǒng)對網(wǎng)絡(luò)通信需求的錯(cuò)誤判斷。

在OESK-NM報(bào)文的協(xié)議數(shù)據(jù)單元（PDU）中，除了協(xié)議規(guī)定的源節(jié)點(diǎn)地址（SA）和目的節(jié)點(diǎn)地址（DA），控制域（CF）之外，剩下的數(shù)據(jù)區(qū)域?yàn)榭蛇x的數(shù)據(jù)區(qū)域。在OESK NM-PDU的基礎(chǔ)上擴(kuò)展，將可選的數(shù)據(jù)區(qū)域中定義兩個(gè)字節(jié)的喚醒源標(biāo)識符，如下圖2所示，定義Byte6-Byte7為喚醒源標(biāo)識符。

該喚醒源標(biāo)識的定義如下表1-2：

其中，Byte6的低4位Bit0-3為保留空間。

其中，Byte6的Bit4定義為Busoff恢復(fù)的喚醒源。

其中，Byte6的Bit5定義為網(wǎng)絡(luò)喚醒源，在CAN總線上即為來自于CAN收發(fā)器的喚醒源。

Byte6的Bit6-7以及Byte7中的Bit0-7共計(jì)10Bit，每一位分別定義一個(gè)或一類喚醒源，由各個(gè)ECU根據(jù)自身控制器的本地喚醒源來定義具體含義。

在網(wǎng)絡(luò)管理狀態(tài)更新的同時(shí)更新喚醒源的狀態(tài)，如果喚醒源有效，該位置1，喚醒源無效，該位置0;在該ECU發(fā)送網(wǎng)絡(luò)管理報(bào)文時(shí)，將喚醒源標(biāo)識信息同步到網(wǎng)絡(luò)管理報(bào)文中。

對于網(wǎng)絡(luò)休眠異常時(shí)，可以采用在令牌環(huán)內(nèi)的ECU互相監(jiān)控的方法來監(jiān)測網(wǎng)絡(luò)休眠異常原因。實(shí)施的邏輯策略為，當(dāng)某個(gè)ECU滿足本地休眠條件滿足進(jìn)入休眠等待NM_ SleepInd = 1時(shí)，啟動休眠監(jiān)測診斷。如下圖所示：

休眠監(jiān)測診斷策略如下：

（1）ECU監(jiān)測目的節(jié)點(diǎn)的網(wǎng)絡(luò)狀態(tài)，當(dāng)目的節(jié)點(diǎn)網(wǎng)絡(luò)狀態(tài)為Active狀態(tài)（NM_SleepInd = 0），暫存記錄目的節(jié)點(diǎn)的節(jié)點(diǎn)地址和喚醒源標(biāo)識;當(dāng)目的節(jié)點(diǎn)網(wǎng)絡(luò)狀態(tài)為NM_ SleepInd時(shí)，刪除上述記錄。

（2）ECU設(shè)定一個(gè)休眠超時(shí)計(jì)時(shí)器TBusSleep Timeout，計(jì)時(shí)器的時(shí)間參數(shù)可以根據(jù)不同車輛實(shí)際情況，或者不同的使用條件下設(shè)定不同的時(shí)間參數(shù)。當(dāng)ECU滿足TBusSleep Timeout之后，如果目的節(jié)點(diǎn)網(wǎng)絡(luò)狀態(tài)為Active狀態(tài)，則將目的節(jié)點(diǎn)地址及喚醒源標(biāo)識轉(zhuǎn)換為故障碼存儲到內(nèi)部存儲單元。該故障碼的格式定義為：

網(wǎng)絡(luò)休眠監(jiān)控流程如圖4：

2.3 異常休眠數(shù)據(jù)讀取

一旦總線上發(fā)生了網(wǎng)絡(luò)不休眠或被異常喚醒過的現(xiàn)象，那么總線上這些網(wǎng)絡(luò)管理的節(jié)點(diǎn)就可以一對一的記錄異常休眠數(shù)據(jù)的故障碼?？梢允褂每偩€設(shè)備直接觀測休眠異常的節(jié)點(diǎn)和存在的喚醒源，也可以和其他類型的故障碼一樣，可以通過診斷設(shè)備發(fā)送讀取指令來讀取故障碼，從而很容易來鎖定網(wǎng)絡(luò)休眠異常的原因。

3 結(jié)論

本文通過整車網(wǎng)絡(luò)應(yīng)用中出現(xiàn)的網(wǎng)絡(luò)休眠異常的情況進(jìn)行了分析研究，并在OSEK 網(wǎng)絡(luò)管理協(xié)議的基礎(chǔ)上，利用了OESK網(wǎng)絡(luò)管理的令牌環(huán)特性和協(xié)議數(shù)據(jù)單元可擴(kuò)展的特性，拓展了一種用于監(jiān)控網(wǎng)絡(luò)休眠異常的策略。ECU不需要關(guān)心網(wǎng)絡(luò)上其他ECU分別是什么，只需要通過OSEK的網(wǎng)絡(luò)管理監(jiān)控令牌環(huán)上目的節(jié)點(diǎn)的狀態(tài)即可，因此更容易模塊化軟件，用在不用的車型和網(wǎng)段上。 在售后維修服務(wù)方面為網(wǎng)絡(luò)休眠異常的監(jiān)測和定位帶來數(shù)據(jù)支持，提高了故障排查的便利性。

參考文獻(xiàn)

[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].