基于汽車電子實(shí)時(shí)系統(tǒng)的健康監(jiān)控模塊實(shí)現(xiàn)

李自清

摘 要：隨著汽車整車安全性、經(jīng)濟(jì)性等方面的發(fā)展，本文結(jié)合汽車電子軟件平臺(tái)化的需求，建立了車控實(shí)時(shí)系統(tǒng)健康管理方法理論架構(gòu)和流程體系，實(shí)現(xiàn)了面向汽車電子實(shí)時(shí)系統(tǒng)的健康監(jiān)控管理模塊。本文中的健康監(jiān)控模塊通過AUTOSAR/OSEK系統(tǒng)服務(wù)API獲取車控實(shí)時(shí)系統(tǒng)運(yùn)行時(shí)任務(wù)、資源、事件、中斷等軟件狀態(tài)信息，通過環(huán)境和應(yīng)用系統(tǒng)狀態(tài)檢測器讀取運(yùn)行環(huán)境信息和車控應(yīng)用對象的狀態(tài)信息，利用相應(yīng)的hook函數(shù)實(shí)現(xiàn)信息的監(jiān)測、收集和發(fā)送。

關(guān)鍵詞：計(jì)算機(jī)軟件；汽車電子；實(shí)時(shí)系統(tǒng)；健康管理；軟件監(jiān)控

中圖分類號(hào)：TP311.15 文獻(xiàn)標(biāo)識(shí)碼：A

1 引言（Introduction）

汽車電子技術(shù)已成為當(dāng)今汽車工業(yè)創(chuàng)新的主要手段。從信息處理的角度講，未來汽車將是一個(gè)具有交通功能的移動(dòng)信息終端。汽車的絕大多數(shù)功能將通過支持這個(gè)信息終端的汽車電子技術(shù)實(shí)現(xiàn)，軟件在汽車價(jià)值中的比重越來越大。過去的汽車電子軟件子系統(tǒng)相對獨(dú)立，產(chǎn)生的故障也易于在小范圍內(nèi)隔離和處理。而隨著新一代汽車電子的發(fā)展，更大規(guī)模的互聯(lián)、更復(fù)雜的軟件功能為汽車故障處理帶來了巨大的挑戰(zhàn)。軟件健康管理（Software Health Management，SHM）從硬件的PHM發(fā)展而來[1]。軟件健康管SHM是一個(gè)基于實(shí)時(shí)在線監(jiān)測的反饋循環(huán)過程。常用的軟件故障恢復(fù)策略可分為冗余策略、恢復(fù)點(diǎn)策略、構(gòu)件修復(fù)策略、系統(tǒng)重構(gòu)策略[2]。文獻(xiàn)[3]闡述了一個(gè)面向安全關(guān)鍵系統(tǒng)軟件和傳感器集成健康管理系統(tǒng)，其收集硬件傳感器、軟件傳感器、操作系統(tǒng)等多種來源的信息，使用貝葉斯網(wǎng)絡(luò)進(jìn)行融合分析；文獻(xiàn)[4]認(rèn)為安全系統(tǒng)的故障從產(chǎn)生階段、系統(tǒng)邊界現(xiàn)象原因、尺度、日標(biāo)、意圖、能力和持續(xù)八個(gè)方面分為16個(gè)基礎(chǔ)分類：開發(fā)故障、操作故障、內(nèi)部故障、外部故障、自然故障、人為故障、硬件故障、軟件故障、惡意故障、非惡意故障、故意故障、非故意故障、意外故障、不適當(dāng)故障、持久故障、瞬時(shí)故障。文獻(xiàn)[5]采用狀態(tài)監(jiān)測器和環(huán)境監(jiān)測器，分別對軟件的內(nèi)部狀態(tài)信息和外部環(huán)境信息進(jìn)行監(jiān)測；本文中以面向汽車電子的實(shí)時(shí)操作系統(tǒng)內(nèi)核為基礎(chǔ)，對健康管理系統(tǒng)主要分為控制流、數(shù)據(jù)流、實(shí)時(shí)性這三個(gè)方面觸，因?yàn)槿魏我环矫娴倪`背都會(huì)造成系統(tǒng)的故障，因此目前主要從這三個(gè)方面并結(jié)合全局錯(cuò)誤處理機(jī)制進(jìn)行健康監(jiān)控管理的設(shè)計(jì)和實(shí)現(xiàn)。首先，本文對健康監(jiān)控管理系統(tǒng)進(jìn)行總體設(shè)計(jì)和描述；其次，本文對控制流、數(shù)據(jù)流、實(shí)時(shí)性和全局錯(cuò)誤處理機(jī)制的詳細(xì)設(shè)計(jì)和實(shí)現(xiàn)進(jìn)行闡述；最后，對本文中所提到的健康管理系統(tǒng)進(jìn)行總結(jié)。

2 健康管理系統(tǒng)總體架構(gòu)（General framework of

health management system）

健康管理是一個(gè)系統(tǒng)性的過程，是提高實(shí)時(shí)系統(tǒng)可靠性和安全性的重要保障，它通過在故障診斷基礎(chǔ)上結(jié)合更多的信息進(jìn)行故障預(yù)測、預(yù)防和恢復(fù)，提高系統(tǒng)可靠性并降低運(yùn)行維護(hù)成本[6]。在汽車電子軟件領(lǐng)域已經(jīng)得到廣泛關(guān)注和應(yīng)用的AUTOSAR標(biāo)準(zhǔn)[7]需求規(guī)范文檔4.0版本中已明確指出了健康管理的重要性，本文擬結(jié)合汽車電子軟件標(biāo)準(zhǔn)體系A(chǔ)UTOSAR/OSEK[8]等規(guī)范，研究面向汽車電子的實(shí)時(shí)系統(tǒng)健康管理；文獻(xiàn)[9]的健康監(jiān)控通過對三個(gè)健康監(jiān)控表的管理來實(shí)現(xiàn)：系統(tǒng)健康監(jiān)控表，模塊健康監(jiān)控表和分區(qū)健康監(jiān)控表。

本文針對汽車電子系統(tǒng)的領(lǐng)域需求，參照AUTOSAR/OSEK規(guī)范，提出了一種面向汽車電子實(shí)時(shí)操作系統(tǒng)的健康監(jiān)控管理方法[10]。其架構(gòu)的健康管理系統(tǒng)的總體設(shè)計(jì)思路如圖1所示。

該健康管理系統(tǒng)基于汽車電子領(lǐng)域主流處理器平臺(tái)，面向汽車電子的實(shí)時(shí)操作系統(tǒng)內(nèi)核進(jìn)行擴(kuò)展，主要包括健康監(jiān)控、故障處理、自主容錯(cuò)等部分。本文重點(diǎn)對健康監(jiān)控模塊進(jìn)行了設(shè)計(jì)實(shí)現(xiàn)，通過對實(shí)時(shí)系統(tǒng)的數(shù)據(jù)流、控制流、實(shí)時(shí)性的監(jiān)控，并結(jié)合全局錯(cuò)誤處理機(jī)制實(shí)現(xiàn)有效管理，實(shí)時(shí)監(jiān)管汽車電子軟件系統(tǒng)的健康狀態(tài)，降低系統(tǒng)運(yùn)行的錯(cuò)誤風(fēng)險(xiǎn)。

3 健康監(jiān)控管理設(shè)計(jì)思路（Design of health

monitoring management）

面向汽車電子的實(shí)時(shí)操作系統(tǒng)的健康管理模塊主要從控制流、數(shù)據(jù)流、實(shí)時(shí)性，以及全局錯(cuò)誤處理模塊進(jìn)行闡述，健康管理模塊的功能邏輯設(shè)計(jì)如圖2所示。

3.1 數(shù)據(jù)流監(jiān)控

對于一個(gè)函數(shù)來說，傳入?yún)?shù)的正確與否直接影響著該函數(shù)的執(zhí)行結(jié)果，因此在函數(shù)執(zhí)行前對傳入?yún)?shù)的檢測是必不可少的。由于每個(gè)函數(shù)需要檢測的內(nèi)容不同，同時(shí)每個(gè)函數(shù)的參數(shù)各異，本文通過分析，確定將函數(shù)檢測部分放在函數(shù)執(zhí)行代碼之前，由用戶來進(jìn)行檢測。通過提供一種全局的錯(cuò)誤處理機(jī)制，用戶檢測到錯(cuò)誤后，向ErrorManager報(bào)告錯(cuò)誤類型，由ErrorManager進(jìn)行統(tǒng)一處理。

函數(shù)參數(shù)的檢測目前沒有和函數(shù)的執(zhí)行分離開來，主要是考慮到參數(shù)的作用域問題。除了參數(shù)檢測之外，通過提供對全局關(guān)鍵數(shù)據(jù)的實(shí)時(shí)檢測，提供統(tǒng)一的函數(shù)入口，具體檢測代碼由用戶來實(shí)現(xiàn)。這個(gè)功能的好處就是用戶可以在任何時(shí)間任何地方檢測全局關(guān)鍵數(shù)據(jù)，不需要記住相關(guān)函數(shù)，只需要向全局關(guān)鍵數(shù)據(jù)檢測函數(shù)中傳入變量即可。

在全局錯(cuò)誤處理機(jī)制和全局關(guān)鍵數(shù)據(jù)的檢測外，同時(shí)提供關(guān)鍵數(shù)據(jù)的存取服務(wù)。可以實(shí)現(xiàn)在程序運(yùn)行的過程中動(dòng)態(tài)的保存某一個(gè)變量的值，隨時(shí)訪問保存的數(shù)據(jù)。保存時(shí)用戶需要按照固定的結(jié)構(gòu)體進(jìn)行封轉(zhuǎn)（包括：函數(shù)名、變量名、變量類型、變量值），讀取時(shí)只需提供變量名和函數(shù)名（之所以要求同時(shí)提供變量名和函數(shù)名是為了防止變量名的重復(fù)）。數(shù)據(jù)流監(jiān)控相關(guān)API描述如表1所示。

3.2 控制流監(jiān)控

從實(shí)時(shí)操作系統(tǒng)運(yùn)行的角度來觀察，任何任務(wù)的實(shí)質(zhì)就是若干函數(shù)的順序執(zhí)行。保證函數(shù)按順序執(zhí)行是完成任務(wù)的首要工作，因此控制流健康監(jiān)控的主要作用就是防止不合理任務(wù)調(diào)度，保證任務(wù)按序執(zhí)行。

本文將任務(wù)（包括多干函數(shù)）中函數(shù)的執(zhí)行看作是一個(gè)控制流，在運(yùn)行之前將每一個(gè)任務(wù)中的函數(shù)注冊到一個(gè)控制流（ControlFlow）中，該功能也可以通過配置工具來實(shí)現(xiàn)（因?yàn)槿蝿?wù)中函數(shù)的執(zhí)行順序是事前確定的）。在一個(gè)函數(shù)執(zhí)行之前，調(diào)用Hook函數(shù)檢測該函數(shù)的前驅(qū)是否已執(zhí)行，若已執(zhí)行就執(zhí)行該函數(shù)，否則報(bào)錯(cuò)；執(zhí)行完該函數(shù)之后調(diào)用Hook函數(shù)將其標(biāo)記為已執(zhí)行。控制流監(jiān)控相關(guān)API描述如表2所示。

3.3 實(shí)時(shí)性監(jiān)控

從實(shí)時(shí)操作系統(tǒng)的高安全性角度考慮，僅僅執(zhí)行順序正確以及得到正確的運(yùn)算結(jié)果還不夠，仍需保證每一個(gè)任務(wù)必須在規(guī)定的時(shí)間內(nèi)（deadline之前）得到執(zhí)行完畢，這樣才能保證整個(gè)系統(tǒng)的安全性。對于實(shí)時(shí)性的監(jiān)控，可利用該實(shí)時(shí)操作系統(tǒng)實(shí)現(xiàn)的時(shí)間保護(hù)機(jī)制完成。

在操作系統(tǒng)配置工具中，針對每一個(gè)Task對應(yīng)生成一個(gè)Alarm，alarm名稱跟任務(wù)名一一對應(yīng)。同時(shí)配置好Alarm的回調(diào)函數(shù)（callback），該回調(diào)函數(shù)的參數(shù)中設(shè)置了TaskID，以及對應(yīng)的錯(cuò)誤等級(jí)，發(fā)生錯(cuò)誤時(shí)由回調(diào)函數(shù)將發(fā)生錯(cuò)誤的TaskID，以及錯(cuò)誤等級(jí)報(bào)告給錯(cuò)誤管理器

3.4 全局錯(cuò)誤管理機(jī)制

前面分別對控制流監(jiān)控、數(shù)據(jù)流監(jiān)控和實(shí)時(shí)性監(jiān)控三方面做了闡述，本小節(jié)將具體闡述全局錯(cuò)誤管理機(jī)制。錯(cuò)誤類型分為系統(tǒng)級(jí)錯(cuò)誤和用戶級(jí)（控制流、數(shù)據(jù)流、實(shí)時(shí)性）錯(cuò)誤，錯(cuò)誤碼為四位十進(jìn)制正整數(shù)組成：第一位是錯(cuò)誤類型，后面三位為具體的錯(cuò)誤代碼。比如1002代表第一類錯(cuò)誤2號(hào)錯(cuò)誤。目前規(guī)定1代表系統(tǒng)級(jí)錯(cuò)誤、2代表控制流錯(cuò)誤、3代表數(shù)據(jù)流錯(cuò)誤、4代表實(shí)時(shí)性錯(cuò)誤。在啟動(dòng)健康監(jiān)控之前，需要定義好各種錯(cuò)誤的解決方案，當(dāng)在系統(tǒng)運(yùn)行過程中錯(cuò)誤管理中心接收到錯(cuò)誤報(bào)告時(shí)，根據(jù)相應(yīng)的錯(cuò)誤類型調(diào)用不同的解決方案。

全局錯(cuò)誤管理的好處在于將以前分散的錯(cuò)誤處理集中起來，提高錯(cuò)誤處理的效率，同時(shí)便于管理。全局錯(cuò)誤管理機(jī)制的示例API如表4所示。例如當(dāng)需要更新某種錯(cuò)誤類型的解決方案時(shí)，只需要更新全局錯(cuò)誤管理中對應(yīng)錯(cuò)誤的解決方案。

and management function）

健康監(jiān)控管理模塊的功能實(shí)現(xiàn)依據(jù)上述的健康監(jiān)控管理模塊的設(shè)計(jì)思路。在實(shí)現(xiàn)中采用了C語言實(shí)現(xiàn)，在本文利用偽代碼描述了數(shù)據(jù)流監(jiān)控、控制流監(jiān)控、實(shí)時(shí)性監(jiān)控、全局錯(cuò)誤管理機(jī)制的實(shí)現(xiàn)框架。

4.1 數(shù)據(jù)流監(jiān)控

以全局關(guān)鍵數(shù)據(jù)為例，在數(shù)據(jù)流監(jiān)控實(shí)現(xiàn)中，為需要監(jiān)控的全局變量進(jìn)性統(tǒng)一編號(hào)。本文中的全局關(guān)鍵數(shù)據(jù)編號(hào)是在操作系統(tǒng)配置時(shí)，將需要檢測的全局變量全部定義成宏。在需125要檢測指定的全局關(guān)鍵數(shù)據(jù)時(shí)，需要將關(guān)鍵數(shù)據(jù)的ID作為參數(shù)傳入函數(shù)CheckGlobalVar，該函數(shù)根據(jù)不同的ID對關(guān)鍵數(shù)據(jù)監(jiān)測或調(diào)用回調(diào)函數(shù)進(jìn)行檢測和檢測結(jié)果反饋。CheckGlobalVar函數(shù)的實(shí)現(xiàn)如下所示：

4.2 控制流監(jiān)控

控制流的監(jiān)控主要監(jiān)控函數(shù)的執(zhí)行順序，為此需要為每一個(gè)函數(shù)執(zhí)行節(jié)點(diǎn)分配如表5所示結(jié)構(gòu)，記錄整個(gè)函數(shù)的執(zhí)行序列。在執(zhí)當(dāng)前結(jié)點(diǎn)時(shí)，首先檢測整個(gè)執(zhí)行流中該函數(shù)的前驅(qū)節(jié)點(diǎn)（第一個(gè)函數(shù)節(jié)點(diǎn)除外）是否已經(jīng)成功執(zhí)行，若成功執(zhí)行繼續(xù)執(zhí)行后續(xù)節(jié)點(diǎn)，否則向系統(tǒng)發(fā)出執(zhí)行流紊亂警告，整個(gè)執(zhí)行流成功運(yùn)行完成后，需要對執(zhí)行流中的函數(shù)節(jié)點(diǎn)進(jìn)行釋放和復(fù)位。

4.3 實(shí)時(shí)性監(jiān)控

實(shí)時(shí)性監(jiān)控主要針對任務(wù)或者函數(shù)的執(zhí)行時(shí)間的監(jiān)控，該功能的實(shí)現(xiàn)需要借助實(shí)時(shí)系統(tǒng)的Alarm機(jī)制，因?qū)崟r(shí)系統(tǒng)的Alarm機(jī)制是建立在硬件定時(shí)器之上，保證了硬實(shí)時(shí)的要求。為了監(jiān)督任務(wù)或函數(shù)的執(zhí)行時(shí)間，需在任務(wù)或函數(shù)的執(zhí)行開始和結(jié)束位置分別調(diào)用相應(yīng)的Hook函數(shù)，如下所示，最終通過計(jì)算前后時(shí)間的差值，檢測任務(wù)或函數(shù)的執(zhí)行是否在指定時(shí)間范圍內(nèi)正常結(jié)束。

4.4 全局錯(cuò)誤管理機(jī)制

全局錯(cuò)誤管理機(jī)制將將數(shù)據(jù)流錯(cuò)誤、控制流錯(cuò)誤、超時(shí)錯(cuò)誤、系統(tǒng)錯(cuò)誤進(jìn)行分類，針對不同的錯(cuò)誤類型和錯(cuò)誤代碼采用不同的錯(cuò)誤處理策略，能夠盡早發(fā)現(xiàn)、并提交錯(cuò)誤報(bào)告給實(shí)時(shí)系統(tǒng)，降低后續(xù)因臟數(shù)據(jù)、執(zhí)行流紊亂等錯(cuò)誤帶來系統(tǒng)運(yùn)行風(fēng)險(xiǎn)的進(jìn)一步放大。以下以偽代碼方式描述了全局錯(cuò)誤管理機(jī)制的策略選擇過程。針對具體的錯(cuò)誤的應(yīng)對策略可以根據(jù)需求進(jìn)行完善。

本文提出了一種面向汽車電子實(shí)時(shí)系統(tǒng)健康管理理論架構(gòu)和流程體系，闡述了基于數(shù)據(jù)流、控制流、實(shí)時(shí)性和全局錯(cuò)誤處理的健康監(jiān)控管理模塊功能方案，實(shí)現(xiàn)了對汽車電子實(shí)控系統(tǒng)的健康監(jiān)管，在一定程度上降低了實(shí)時(shí)系統(tǒng)的錯(cuò)誤運(yùn)行風(fēng)險(xiǎn)。后續(xù)的健康管理相關(guān)算法和應(yīng)用研究，如基于人工智能的故障預(yù)測推理、基于服務(wù)的汽車CPS應(yīng)用等，都可以在此基礎(chǔ)上進(jìn)行有效的開展。

參考文獻(xiàn)（References）

[1] FaezeEshragh，Mehdi Kargahi.Analytical architecture-based performability evaluation of real-time software systems[J].Journal of Systems and Software，2013，86（1）：233-246.

[2] 李寧波，等.嵌入式RTOS健康監(jiān)控技術(shù)研究[J].計(jì)算機(jī)工程，2009，35（3）：260-262.

[3] 陳光，等.服務(wù)軟件系統(tǒng)的健康管理綜述[J].計(jì)算機(jī)科學(xué)與探索，2013，7（7）：577-591.

[4] J Schumann，OJ Mengshoel，T Mbaya.Integrated Software and Sensor Health Management for Small Spacecraft[C].Fourth IEEE International Conference on Space Mission Challenges for Information Technology（SMC-IT 2011），2011：77-84.

[5] A Avizienis，et al.Basic Concepts and Taxonomy of Dependable and Secure Computing[J].IEEE Transactions on Dependable and Secure Computing，2004，1（1）：23.

[6] Kai Wang，et al.A Prognostics and Health Management Based Method for Refurbishment Decision Making for Electromechanical Systems[J].IFAC-Papers OnLine，2015，48（3）：454-459.

[7] J Park，G Yoo，E Lee.A Reconfiguration Framework for Self-Healing Software[C].International Conference on Convergence and Hybrid Information Technology，2008：83-91.

[8] AUTOSAR.AutomotiveopenSystemARchitecture[DB/OL].http：//www.autosar.org，2014.

[9] OSEK/VDX.OSEK/VDX Operating System Specification

Version 2.2.2[S].http：//www.osek-vdx.org，2014.

[10] Michael Short，Michael J.Pont.Assessment of high- integrity embedded automotive control systems using hardware in the loop simulation[J].Journal of Systems and Software，2008，81（7）：1163-1183.