基于OSEK 標準的汽車網絡管理設計和驗證淺析

陳姿霖， 王遠波， 陳 佩

（陜西重型汽車有限公司汽車工程研究院， 陜西 西安 710200）

近年來汽車向舒適化、 智能化方向迅猛發展， 汽車電子控制系統的數量大幅增多， 部分ECU需要長時間工作，提高了網絡復雜度與電源分配的難度以及車輛對網絡的依賴性， 為了解決ECU數量增多帶來蓄電池饋電、 長期靜置后無法啟動等問題， 需要對車輛ECU進行休眠喚醒的管理，使車輛在長期靜置后能夠再次啟動。

使用網絡管理機制， 能使網絡上的控制器穩定、 有序運行， 提高網絡資源的利用率， 實時監控網絡上控制器的運行情況、 降低鑰匙拔出后車輛的電能消耗， 使車輛一直具有足夠的能量再次啟動。 本文在OSEK國際通用網絡管理規范的基礎上， 從設計方案和測試兩方面著手， 定義一種適合重型汽車使用的網絡管理和測試方法， 解決車輛電源分配和饋電問題。

1 OSEK網絡管理概述

OSEK是一種直接網絡管理方法， 通過專用的報文來報告網絡當前的狀態、 與網絡內的其它控制器 （簡稱ECU）進行網絡狀態、 休眠請求、 休眠命令的傳遞， 互相協商以達到共同休眠的目標。 網絡上每個有網絡管理功能的ECU都有專用的網絡管理報文 （簡稱NM報文）， 網絡上的所有ECU沒有主從之分， 任何ECU都可以喚醒網絡、 申請休眠、發送休眠指令。

2 OSEK網絡管理設計

網絡管理設計包含ECU類型、 NM報文定義、 時間參數要求、 網絡狀態、 休眠和喚醒等方面。

2.1 ECU類型

根據車輛所有ECU的功能情況可將控制器分為兩大類。①Ⅰ類： 只在點火鑰匙打開 （簡稱IGN ON） 時工作； ②Ⅱ類： 在IGN ON時全程工作、 在點火鑰匙關閉 （簡稱IGN OFF） 下按需工作。 網絡管理的各項設計要求主要用于管理Ⅱ類ECU的休眠和喚醒行為。

2.2 NM報文定義與格式

2.2.1 NM報文定義

NM報文的ID格式使用標準幀或擴展幀都可以， 根據車型平臺進行統一規劃。

NM報文共有3類： 聲明報文 （簡稱Alive報文）、 邏輯環報文 （簡稱Ring報文）、 跛行回家報文 （簡稱LimpHome報文）。 通過NM控制域的標志位來進行區分， ECU使用NM報文向網絡內其它ECU聲明自身的當前狀態。

2.2.2 NM報文格式

1） 目標地址

目標地址位于報文數據場中的第1個字節， 根據實際網絡情況而定， 如果網絡中只有一個Ⅱ類節點， 那么目標地址一直為發送節點的地址； 如果網絡中存在大于一個Ⅱ類節點， 除了第1幀的alive聲明報文的目標地址為發送節點的地址， 剩余發送的NM報文中的目標地址為邏輯后繼節點的地址。

2） NM控制域

控制域位于報文數據場中的第2個字節， 其各個位的含義， 見圖1。

圖1 NM報文的控制域

3） NM數據域

數據場的第3字節到第7字節， 使用者可根據車型平臺功能定義進行自定義應用。

對于未定義的預留位全部用 “0/1” 進行填充。

4） NM報文類型和休眠標記

根據NM 報文中控制域的定義， 本章節介紹Alive 報文、 Ring報文、 LimpHome報文、 Sleep.Ind和Sleep.Ack標志的含義和用途。 ①Alive報文： 網絡中每個ECU 初始化完成后或者在令牌環傳遞的過程中發現自身被跳過時， 都會發送Alive報文， 用于聲明自己地址或聲明自己被跳過，向其它ECU聲明需要加入到網絡管理的邏輯環中。 Alive報文的目標地址等于發送Alive報文節點自身的地址。 在該階段， 網絡上的II類ECU需要根據其它ECU發送的Alive報文不斷的動態調整配置表， 進而確定自身的前繼節點和后繼節點。 ②Ring報文： ECU在確定了自身的前繼節點和后繼節點后， 需要與網絡內的其它ECU 建立令牌環，ECU在接收到其前繼節點的Ring報文后， 向其后繼者發送自己的Ring 報文， 這個傳遞的順序和機制稱為令牌環。Ring報文的目標地址為其后繼節點地址。 ③LimpHome 報文： 處 于 故 障 狀 態 （NMRxcount、 NMTxcount 數 值 超 過 閾值） 的ECU以TError周期發送LimpHome報文。 與Alive報文相同， LimpHome報文目標地址為發送LimpHome報文節點自身的地址。 當網絡內只有一個II類ECU 時， ECU 發送4組Alive報 文、 Ring報 文， 再 發 送 一 幀Alive 報 文 后， 發 送LimpHome報文。 ④Sleep.Ind標志： Sleep.Ind為休眠請求標志位， 當ECU檢測到自身的休眠條件不滿足時， 發出的NM報文中該位為0， 聲明自身不滿足休眠條件； 當ECU檢測到自身的休眠條件滿足時， 發出的NM報文中該位為1，聲 明 自 身 滿 足 休 眠 條 件。 ⑤Sleep.Ack 標 志： Sleep.Ack 為休眠應答標志位， 令牌環中第1個檢測到所有ECU的休眠請求標志位為1的ECU發出的NM報文中該位為1。 發出NM報文中該位為1的ECU和接受到該指令的ECU需立即停發所有報文。

2.3 網絡管理狀態

網絡管理的狀態總共有3種狀態： 未激活、 啟動、 激活。 NM狀態如圖2所示。

圖2 NM狀態

2.3.1 網絡未激活

在該狀態下， ECU不會收發任何報文， 當檢測到電源使能信號有效、 本地喚醒事件有效、 遠程事件 （接收到任意總線報文）， 應請求啟動網絡， 從未激活向啟動狀態遷移， 該遷移過程需要在一定的時間內完成。

2.3.2 網絡啟動狀態

該狀態包含3個子狀態： 網絡初始化、 網絡激活、 網絡休眠。

1） 網絡初始化狀態： ECU進入網絡啟動狀態后先進行通信程序、 寄存器等網絡初始化行為， 初始化應在一定的時間內完成， 初始化完成后ECU會發出NM報文和應用報文， 先發NM報文后發應用報文。

2） 網絡激活狀態包含網絡重置、 網絡正常運行、 網絡跛行3種子狀態。 ECU進入網絡激活狀態后首先進入的是網絡重置狀態， 發送Alive報文聲明自身的存在， 然后立刻進入網絡正常運行狀態； 在網絡正常運行狀態下監控其它處于激活的節點， 記錄所有ECU的源地址， 動態適配自身的前繼節點和后繼節點， 并以一定的周期向自身后繼節點發送Ring報文， 建立邏輯環； 當錯誤計數器到達閥值后ECU會進入跛行狀態， 并以一定的周期發送狀態為跛行的NM報文， 當ECU從Busoff狀態下恢復后發出的第1幀NM報文應該為跛行報文。

3） 網絡休眠狀態包含休眠等待和徹底休眠兩種狀態。ECU進入休眠狀態首先進入的是休眠等待狀態， 該狀態需要定義合理的時間用于ECU休眠之前的信息存儲， 在該狀態下ECU不能發送任意報文， 但是可以被喚醒源喚醒， 時間到后應該遷移到徹底休眠狀態； 徹底休眠狀態為ECU的低功耗狀態。

2.4 休眠和喚醒

當車輛靜止， 鑰匙從on擋切換到off擋時， Ⅰ類ECU就停止工作； 當車輛靜止拔出鑰匙， 為了保證蓄電池的使用時長和防止潰電， 網絡上的Ⅱ類ECU在該情況下檢查自身運行的功能對網絡的需求， 如果需要使用網絡， 發送的NM報文中不帶休眠請求信息； 如果不需要使用網絡， 發送的NM報文中帶休眠請求信息； 在環運行的過程中， 每個控制器都監控其他節點發送的休眠請求信息， 第1個檢測到所有ECU都發送了休眠請求的ECU發送休眠命令報文， 所有ECU停發報文， 進入低功耗模式。 這樣在網絡上通過請求休眠和休眠命令這樣的信息使整個網絡的所有ECU達到同步休眠。

Ⅱ類ECU休眠條件由其功能的使用情況而決定。

鑰匙處于off擋時， 如果外部有功能需求會將整車喚醒；喚醒一般針對的是Ⅱ類ECU， 整車的喚醒條件或ECU的喚醒條件主要由車輛的實際應用而定。

3 測試

根據OSEK網絡管理設計規范中定義的初始化時間、 報文周期、 網絡狀態的切換入手， 從正向、 逆向、 邊界、 冗余等方面制定全方面的測試用例。

3.1 測試用例設計

因為在正常-休眠-喚醒狀態的切換過程中， 需要在特定的時間發送特殊報文， 在測試過程中需按照測試用例開發測試腳本來完成測試。

以整車網絡從鑰匙off擋—on擋—off擋—休眠這個過程為例， 設計的測試用例需要覆蓋單節點和多節點的初始化時間、 報文類型、 狀態遷移、 喚醒休眠順序等方面進行正向、 逆向、 臨界、 冗余測試， 以保證測試覆蓋率， 盡可能地發現問題， 進行完善。

3.2 測試數據解析

測試數據解析分為喚醒數據和休眠數據兩類， 如圖3、圖4所示。

圖3 喚醒數據

圖4 休眠數據

4 結束語

本文從設計和測試兩方面來介紹OSEK網絡管理的設計和驗證方法。 全面的設計內容需要大量實車應用測試， 總結所遇到的問題， 對規范進行補充， 以達到穩定、 節能的目的。