嵌入式系統(tǒng)下位機(jī)故障定位及分析方案研究

董高云，余文兵，周庭梁

（卡斯柯信號(hào)有限公司 平臺(tái)技術(shù)中心，上海200071）

在鐵路信號(hào)領(lǐng)域，大量的安全相關(guān)產(chǎn)品（如計(jì)算機(jī)聯(lián)鎖、車(chē)站列控中心、臨時(shí)限速服務(wù)器等）均采用運(yùn)行于實(shí)時(shí)嵌入式操作系統(tǒng)的嵌入式下位機(jī)來(lái)執(zhí)行核心的安全運(yùn)算和I/O控制功能，這類(lèi)產(chǎn)品對(duì)實(shí)時(shí)性有很高的要求，需要確保其安全穩(wěn)定的運(yùn)行。安全系統(tǒng)通?？梢酝ㄟ^(guò)熱備冗余設(shè)計(jì)來(lái)實(shí)現(xiàn)切換，確保單系宕機(jī)不會(huì)引起整個(gè)系統(tǒng)停機(jī)，此外，在出現(xiàn)單系宕機(jī)后，還需要在最短的時(shí)間內(nèi)迅速定位下位機(jī)故障點(diǎn)，找出故障原因和解決方案，使整體安全系統(tǒng)盡快退出降級(jí)工作模式，恢復(fù)正常工作。因此，嵌入式系統(tǒng)的下位機(jī)故障定位和分析工作至關(guān)重要。

近年來(lái)，在鐵路信號(hào)領(lǐng)域，專(zhuān)門(mén)針對(duì)嵌入式系統(tǒng)的故障分析和相關(guān)診斷設(shè)計(jì)的研究不多，且大多是針對(duì)特定的信號(hào)系統(tǒng)展開(kāi)，如軌道交通車(chē)輛故障診斷系統(tǒng)設(shè)計(jì)[1]，獨(dú)立式智能列車(chē)故障診斷系統(tǒng)[2]，基于通信的列車(chē)控制系統(tǒng)中計(jì)算機(jī)聯(lián)鎖系統(tǒng)故障因素分析[3]，鐵路信號(hào)聯(lián)鎖設(shè)備的故障分析[4]等。其它領(lǐng)域針對(duì)嵌入式系統(tǒng)故障診斷分析的研究又多集中于特定的算法和方法理論研究，如基于嵌入式的智能故障診斷的研究與設(shè)計(jì)[5]，基于BP 神經(jīng)網(wǎng)絡(luò)的集中監(jiān)測(cè)系統(tǒng)故障診斷[6]，基于大數(shù)據(jù)的控制系統(tǒng)故障診斷方法綜述[7]，嵌入式裝備故障診斷專(zhuān)家系統(tǒng)[8]。缺少專(zhuān)門(mén)針對(duì)鐵路信號(hào)領(lǐng)域的嵌入式下位機(jī)故障類(lèi)型梳理和故障定位的分析和研究成果。本文對(duì)典型嵌入式系統(tǒng)下位機(jī)的系統(tǒng)架構(gòu)進(jìn)行梳理，并提出相應(yīng)的故障定位及分析設(shè)計(jì)方案。

1 嵌入式系統(tǒng)下位機(jī)架構(gòu)及故障類(lèi)型梳理

1.1 嵌入式系統(tǒng)下位機(jī)架構(gòu)分析

圖1 為典型的嵌入式系統(tǒng)下位機(jī)架構(gòu)，由硬件、驅(qū)動(dòng)&固件（包括bootrom、BSP 包等）、嵌入式操作系統(tǒng)（OS）和應(yīng)用軟件層組成。一套2 取2架構(gòu)的SIL4 級(jí)安全系統(tǒng)下位機(jī)，通常采用2 個(gè)獨(dú)立的如圖1所示的單板板卡來(lái)實(shí)現(xiàn)組合故障安全。

圖1 嵌入式系統(tǒng)下位機(jī)架構(gòu)

如圖1所示，最下層為硬件層；bootrom 和BSP包確保硬件上電之后能正常地進(jìn)入初始工作狀態(tài)，加載各個(gè)硬件端口、運(yùn)行操作系統(tǒng)鏡像等。各種端口設(shè)備（如USB口、網(wǎng)口、串口等）的驅(qū)動(dòng)保證這些端口設(shè)備能夠在不同的嵌入式操作系統(tǒng)環(huán)境下正常工作；

可編程固件指的是CPLD、FPGA等固件的可編程邏輯代碼，可實(shí)現(xiàn)特定的功能（如計(jì)數(shù)器、安全時(shí)鐘）并被驅(qū)動(dòng)操控；

嵌入式OS負(fù)責(zé)嵌入式下位機(jī)系統(tǒng)的軟硬件資源分配、任務(wù)調(diào)度、控制、協(xié)調(diào)并發(fā)活動(dòng)。常用的嵌入式OS包括vxWorks、QNX，μCOS、嵌入式Linux 等；

最上層是應(yīng)用軟件，包含平臺(tái)軟件和上層應(yīng)用軟件，從故障定位的角度一般不予以區(qū)分。

1.2 嵌入式系統(tǒng)下位機(jī)故障類(lèi)型梳理

1.2.1 硬件

硬件故障指硬件板卡整體或部分元器件（包括集成元器件模塊）的瞬時(shí)或永久故障。絕大部分情況下嵌入式系統(tǒng)硬件故障均以個(gè)案形式出現(xiàn)。此外，嵌入式操作系統(tǒng)和驅(qū)動(dòng)程序可能會(huì)對(duì)一些底層的硬件故障給出特定的故障報(bào)警碼并顯示在硬件報(bào)警設(shè)備（如故障指示燈）上面，或者返回給上層的軟件調(diào)用接口，也可以用點(diǎn)燈或閃燈的方式對(duì)故障進(jìn)行指示。相關(guān)設(shè)計(jì)在相應(yīng)的操作手冊(cè)中能查到，可以考慮通過(guò)合理的報(bào)警設(shè)計(jì)對(duì)相應(yīng)的報(bào)警接口進(jìn)行調(diào)用。

1.2.2 驅(qū)動(dòng)&固件

驅(qū)動(dòng)故障指驅(qū)動(dòng)代碼存在缺陷，或驅(qū)動(dòng)代碼與硬件不匹配導(dǎo)致驅(qū)動(dòng)相關(guān)的硬件設(shè)備工作不正常。驅(qū)動(dòng)故障和硬件故障最大的區(qū)別是：驅(qū)動(dòng)故障具有普遍性，相同的驅(qū)動(dòng)代碼在同一種板卡上表現(xiàn)一致，更換同種硬件板卡后故障仍然存在。一些通信外設(shè)相關(guān)驅(qū)動(dòng)故障（如串口驅(qū)動(dòng)、網(wǎng)絡(luò)驅(qū)動(dòng)），其發(fā)生有一定概率和隨機(jī)性，給復(fù)現(xiàn)、排查和分析帶來(lái)困難。

另外，存在一定概率的具有普遍性的硬件設(shè)計(jì)缺陷，導(dǎo)致硬件工作不正常，即使更換板卡，問(wèn)題仍會(huì)存在，容易與驅(qū)動(dòng)故障的現(xiàn)象混淆。但這類(lèi)硬件設(shè)計(jì)缺陷，也會(huì)從驅(qū)動(dòng)層面體現(xiàn)出來(lái)，可以在驅(qū)動(dòng)層面通過(guò)加補(bǔ)丁的方式解決。

除了通常意義上的驅(qū)動(dòng)之外，如bootloader和BSP 包等啟動(dòng)階段加載項(xiàng)也統(tǒng)一歸類(lèi)為驅(qū)動(dòng)。bootrom 和BSP 包在廠家出廠之前一般會(huì)做通用功能的常規(guī)測(cè)試，出錯(cuò)之后會(huì)直接導(dǎo)致板卡無(wú)法啟動(dòng)且有明顯故障指示，因此這兩類(lèi)底層驅(qū)動(dòng)通常出錯(cuò)的可能性較小，問(wèn)題定位也相對(duì)簡(jiǎn)單。另外，bootrom 啟動(dòng)過(guò)程中的部分錯(cuò)誤也可能沒(méi)有任何指示燈的提示，僅表現(xiàn)為板卡啟動(dòng)失敗。尤其是安全產(chǎn)品的自研板卡的，板卡指示燈的設(shè)計(jì)也沒(méi)有統(tǒng)一的規(guī)定，工程師依賴(lài)經(jīng)驗(yàn)的成分更多。

固件代碼（如FPGA、CPLD代碼）的出錯(cuò)特征與驅(qū)動(dòng)類(lèi)似，表現(xiàn)為與相應(yīng)代碼對(duì)應(yīng)的固件工作異常。出錯(cuò)也具有普遍性（更換硬件后，故障仍存在），并呈現(xiàn)一定的隨機(jī)性概率（有時(shí)低概率出現(xiàn)）。

1.2.3 操作系統(tǒng)

操作系統(tǒng)的故障包括2類(lèi)：（1）操作系統(tǒng)本身存在缺陷，使得其在特定的場(chǎng)景，或使用其某個(gè)缺陷模塊時(shí)出現(xiàn)錯(cuò)誤；（2）由于對(duì)操作系統(tǒng)相關(guān)函數(shù)和配置的錯(cuò)誤使用，或其它層級(jí)的缺陷導(dǎo)致操作系統(tǒng)異常，有時(shí)表現(xiàn)為操作系統(tǒng)的崩潰。

操作系統(tǒng)本身的缺陷可以通過(guò)操作系統(tǒng)廠商提供的相應(yīng)版本BugList 來(lái)獲得一些信息，此外，廠商的技術(shù)支持也尤為重要。其它層級(jí)的缺陷導(dǎo)致的操作系統(tǒng)異常更為常見(jiàn)，多為使用人員對(duì)操作系統(tǒng)不熟悉，或針對(duì)相應(yīng)組件操作不當(dāng)而導(dǎo)致。

操作系統(tǒng)故障時(shí)，可以通過(guò)操作系統(tǒng)運(yùn)行時(shí)自帶的一些集成編譯工具（如vxWorks的Tornado、Workbench、QNX 的Momentics工具包等），查看相應(yīng)的運(yùn)行參數(shù)，獲悉一些關(guān)鍵運(yùn)行信息，也可以通過(guò)操作系統(tǒng)自帶的一些運(yùn)行監(jiān)控組件來(lái)跟蹤程序異常。

1.2.4 應(yīng)用軟件

應(yīng)用軟件故障可以分為以下3種：

（1）應(yīng)用軟件設(shè)計(jì)缺陷導(dǎo)致的程序調(diào)度錯(cuò)誤，可導(dǎo)致程序的任務(wù)調(diào)度異常，軟件無(wú)法完成指定功能，或者導(dǎo)致部分任務(wù)被掛起而引起系統(tǒng)整體宕機(jī)。

（2）在內(nèi)存分配、指針跳轉(zhuǎn)或其它編程語(yǔ)言的用法上出現(xiàn)錯(cuò)誤，導(dǎo)致程序異常，引起程序崩潰。包括未遵守安全編碼規(guī)范，未加防護(hù)或防護(hù)不當(dāng)。可通過(guò)操作系統(tǒng)提供的工具記錄一系列內(nèi)存越界等故障發(fā)生的執(zhí)行點(diǎn)等信息，以適當(dāng)方式導(dǎo)出和查看。

（3）邏輯錯(cuò)誤造成的邏輯設(shè)計(jì)和實(shí)現(xiàn)上的缺陷，可能造成非預(yù)期的執(zhí)行結(jié)果，但一般情況下，下位機(jī)程序運(yùn)行沒(méi)有明顯異常，需要結(jié)合測(cè)試流程方能發(fā)現(xiàn)這類(lèi)錯(cuò)誤。

2 嵌入式系統(tǒng)下位機(jī)故障定位及分析方案

2.1 不同類(lèi)型故障的定位及分析方案

根據(jù)故障分類(lèi)梳理結(jié)果，本文對(duì)不同種類(lèi)故障，有針對(duì)性地給出相應(yīng)的故障定位及分析方案，如圖2所示。

圖2 嵌入式系統(tǒng)下位機(jī)故障定位及分析方案匯總

2.1.1 內(nèi)核事件追蹤

當(dāng)硬件、驅(qū)動(dòng)、操作系統(tǒng)等底層故障發(fā)生時(shí)，會(huì)引起整個(gè)軟件的運(yùn)行異?；虿僮飨到y(tǒng)的崩潰，在無(wú)法通過(guò)I/O設(shè)備導(dǎo)出相關(guān)故障時(shí)，需要采用其它方式記錄崩潰之前的系統(tǒng)運(yùn)行狀態(tài)，以用于故障分析。常用的COTS型嵌入式操作系統(tǒng)（如vxWorks、QNX 等）均提供了一些內(nèi)核事件追蹤分析工具包，記錄系統(tǒng)運(yùn)行過(guò)程中發(fā)生的內(nèi)核事件，基于該嵌入式系統(tǒng)的工具包，輔以一定的隊(duì)列控制、內(nèi)存及U盤(pán)讀寫(xiě)策略，形成內(nèi)核事件追蹤方案。

以QNX 操作系統(tǒng)為例，QNX 提供一種系統(tǒng)追蹤分析工具包[9]（SAT，System AnalysisToolkit）。SAT工作在操作系統(tǒng)的內(nèi)核級(jí)，能夠在不修改應(yīng)用程序的情況下有效監(jiān)控并記錄系統(tǒng)運(yùn)行過(guò)程中發(fā)生的內(nèi)核事件（包括系統(tǒng)調(diào)用、進(jìn)程間通信、中斷等）。SAT 工作原理如圖3所示[10]，由調(diào)試級(jí)內(nèi)核、Kernel緩沖區(qū)、數(shù)據(jù)捕捉程序及數(shù)據(jù)解釋程序組成。調(diào)試級(jí)內(nèi)核負(fù)責(zé)采取內(nèi)核事件，放入Kernel緩沖區(qū)（Kernel 緩沖區(qū)是一個(gè)循環(huán)列表，可以循環(huán)記錄事件）。數(shù)據(jù)捕捉程序從Kernel緩沖區(qū)獲取事件數(shù)據(jù)并保存為指定名字的.kev 文件，數(shù)據(jù)解釋程序解析.kev文件。為了使內(nèi)核支持SAT，需要將調(diào)試級(jí)內(nèi)核和tracelogger 程序編譯到內(nèi)核鏡像中。

圖3 SAT工作原理

實(shí)時(shí)嵌入式應(yīng)用程序一直持續(xù)運(yùn)行，且其故障點(diǎn)具有不確定性，持續(xù)記錄內(nèi)核事件可能會(huì)導(dǎo)致宕機(jī)時(shí)文件無(wú)法導(dǎo)出或不易導(dǎo)出，如果頻繁寫(xiě)到外部存儲(chǔ)ROM中，會(huì)使文件過(guò)大，且容易損壞外部ROM，而寫(xiě)外存效率低也容易影響應(yīng)用程序的運(yùn)行?；谝陨蠁?wèn)題的考慮，內(nèi)外存需配合使用，內(nèi)存實(shí)時(shí)記錄保證宕機(jī)時(shí)有記錄，避免時(shí)間點(diǎn)不確定性問(wèn)題；外存只在宕機(jī)時(shí)將內(nèi)存數(shù)據(jù)寫(xiě)入，方便文件導(dǎo)出。

基于以上應(yīng)用場(chǎng)景所設(shè)計(jì)的一種SAT的應(yīng)用框架如圖4 所示。其中，調(diào)試內(nèi)核進(jìn)程實(shí)時(shí)捕捉系統(tǒng)發(fā)生的事件并記錄到內(nèi)核緩沖區(qū)隊(duì)列中；Tracelogger是QNX 提供的一個(gè)在后臺(tái)運(yùn)行的組件程序，其被觸發(fā)后，可將調(diào)試內(nèi)核捕捉到的事件（kernelbuffer）刷到指定文件；trace是自定義的追蹤進(jìn)程，它通過(guò)PULSE 監(jiān)控用戶(hù)關(guān)鍵進(jìn)程的運(yùn)行狀況（見(jiàn)圖4中的①），當(dāng)用戶(hù)關(guān)鍵進(jìn)程掛掉或邏輯上出現(xiàn)宕機(jī)時(shí)，trace在規(guī)定時(shí)間內(nèi)沒(méi)收到該進(jìn)程發(fā)送過(guò)來(lái)的PULSE，其會(huì)向調(diào)試內(nèi)核進(jìn)程發(fā)送STOP 命令（見(jiàn)圖4中的②），調(diào)試內(nèi)核收到該命令后會(huì)立即通過(guò)SIGINT 觸發(fā)Tracelogger 進(jìn)程（圖4中的③）開(kāi)始進(jìn)行事件抓取和存儲(chǔ)操作，主動(dòng)去將當(dāng)前內(nèi)核緩沖區(qū)隊(duì)列中的所有數(shù)據(jù)刷到ROM中，存儲(chǔ)為trace.kev文件。

圖4 SAT應(yīng)用框架

在程序或操作系統(tǒng)崩潰后，Tracelogger 能夠?qū)⑾到y(tǒng)崩潰之前一段時(shí)間（可自行設(shè)定）記錄到的文件存到相關(guān)的ROM 存儲(chǔ)設(shè)備中，之后可以將ROM中存儲(chǔ)的.kev 文件導(dǎo)出，利用QNX 的IDE 進(jìn)行查看。QNX的IDE 能夠以圖形化的方式清晰地展示不同任務(wù)對(duì)CPU的占用情況，以及程序在執(zhí)行過(guò)程中發(fā)生的所有內(nèi)核事件，再結(jié)合人工分析可確認(rèn)內(nèi)核事件的異常，從而推斷底層故障的原因。

內(nèi)核事件追蹤機(jī)制針對(duì)調(diào)度錯(cuò)誤的原因查找特別有幫助，對(duì)于操作系統(tǒng)本身故障的查找也有很大的參考價(jià)值，對(duì)于與任務(wù)調(diào)度和時(shí)序控制相關(guān)的驅(qū)動(dòng)和硬件故障的查找也具有很好的參考價(jià)值，但是對(duì)于其他難以反饋到任務(wù)調(diào)度圖中的驅(qū)動(dòng)和硬件問(wèn)題，則幫助不大，需要輔以其他手段來(lái)綜合定位。

2.1.2 DUMP功能

應(yīng)用軟件的程序異?？赡芤鸪绦虮罎?，嵌入式操作系統(tǒng)對(duì)于這種異常有相應(yīng)的記錄機(jī)制，可準(zhǔn)確定位相應(yīng)異常，并記錄在相關(guān)的存儲(chǔ)介質(zhì)中，嵌入式操作系統(tǒng)的這種功能稱(chēng)為DUMP 功能。

本文以QNX 操作系統(tǒng)的coredump為例進(jìn)行說(shuō)明。UNIX 系統(tǒng)將“主內(nèi)存”稱(chēng)為核心（core），核心映像（coreimage）包括CPU 現(xiàn)場(chǎng)、任務(wù)?？臻g等。當(dāng)進(jìn)程發(fā)生錯(cuò)誤或收到異常信號(hào)（signal）而終止執(zhí)行時(shí)，系統(tǒng)會(huì)將coreimage寫(xiě)入一個(gè).core文件，以作為調(diào)試時(shí)恢復(fù)進(jìn)程現(xiàn)場(chǎng)，即所謂的核心轉(zhuǎn)儲(chǔ)（core dump）。QNX 繼承了coredump的概念，在QNX下可以通過(guò)dumper 程序來(lái)使用coredump功能，dumper 程序必須編譯到內(nèi)核中。

一個(gè)進(jìn)程通常有2種終止的方式：（1）正常的邏輯上的退出；（2）運(yùn)行異常導(dǎo)致的Crash 退出。core dump正是針對(duì)后一種情況，dumper 程序在后臺(tái)運(yùn)行，并為所有進(jìn)程提供一個(gè)算后轉(zhuǎn)儲(chǔ)服務(wù)。當(dāng)程序異常終止時(shí)，程序當(dāng)前狀態(tài)的轉(zhuǎn)儲(chǔ)被寫(xiě)入磁盤(pán)。轉(zhuǎn)儲(chǔ)文件名稱(chēng)與使用.core擴(kuò)展名的程序名相同。表1為QNX_IDE 列出的signal 異常信號(hào)[11]，用戶(hù)可以參照這個(gè)集合，使用signal 函數(shù)來(lái)綁定自定義的異常處理邏輯。一旦發(fā)生表1中的各類(lèi)異常，可以直接被DUMP 精準(zhǔn)記錄。在程序運(yùn)行時(shí)可以將出錯(cuò)信息記錄在ROM存儲(chǔ)裝置（Flash、U盤(pán)等）中，離線查看。

表1 異常信號(hào)集合

2.1.3 關(guān)鍵信息追蹤

為了更有效地追蹤上層應(yīng)用軟件執(zhí)行情況，通常會(huì)在應(yīng)用軟件的各個(gè)關(guān)鍵位置增加一系列的關(guān)鍵信息追蹤。關(guān)鍵信息添加的位置需要根據(jù)不同應(yīng)用的情況來(lái)確認(rèn)，但總體來(lái)看，可以大致上分為以下3類(lèi)：

（1）程序框架邏輯、程序主分支的時(shí)序點(diǎn)，如主周期的起始或結(jié)束點(diǎn)、主周期運(yùn)行過(guò)程中的分段時(shí)序響應(yīng)起止點(diǎn)、定時(shí)中斷或串口中斷的定時(shí)響應(yīng)點(diǎn)等。

（2）邏輯比較復(fù)雜，經(jīng)分析認(rèn)為容易出問(wèn)題的點(diǎn)，如一些復(fù)雜算法的中間結(jié)果、2乘2取2系統(tǒng)的主備狀態(tài)更新點(diǎn)、溫度電壓的超限判斷點(diǎn)、串口數(shù)據(jù)接收點(diǎn)等。

（3）針對(duì)特定問(wèn)題的信息追蹤點(diǎn)，如不同安全產(chǎn)品的嵌入式系統(tǒng)下位機(jī)在現(xiàn)場(chǎng)應(yīng)用時(shí)所碰到特定的穩(wěn)定性問(wèn)題，經(jīng)分析需要追蹤消息在某串口接收處理路徑上的流轉(zhuǎn)過(guò)程，就需要在這個(gè)路徑上的所有消息傳遞點(diǎn)上增加相應(yīng)的信息追蹤。

關(guān)鍵信息的原始記錄通常寫(xiě)入全局變量?jī)?nèi)存區(qū)，并且可以周期性地通過(guò)網(wǎng)絡(luò)或串口發(fā)送給上位機(jī)系統(tǒng)維護(hù)臺(tái)，或者在宕機(jī)時(shí)寫(xiě)入ROM（Flash 等）進(jìn)行永久記錄，以方便離線查看。對(duì)于正常運(yùn)行時(shí)的關(guān)鍵信息應(yīng)通過(guò)網(wǎng)絡(luò)發(fā)送給上位機(jī)的相關(guān)診斷維護(hù)設(shè)備進(jìn)行記錄。正常運(yùn)行過(guò)程中不宜寫(xiě)入ROM存儲(chǔ)裝置，以免因頻繁寫(xiě)操作損壞ROM；異常宕機(jī)時(shí)的信息記錄可考慮寫(xiě)ROM操作，以便在網(wǎng)絡(luò)和串口異常導(dǎo)致關(guān)鍵信息無(wú)法發(fā)送至系統(tǒng)維護(hù)臺(tái)時(shí)，可通過(guò)寫(xiě)ROM的方式進(jìn)行本地記錄。

2.1.4 錯(cuò)誤碼

錯(cuò)誤碼方式通過(guò)在整個(gè)程序中設(shè)計(jì)一種規(guī)范格式的錯(cuò)誤碼來(lái)實(shí)現(xiàn)一種通用函數(shù)錯(cuò)誤返回邏輯。故障分析人員可以對(duì)照錯(cuò)誤碼的定義，對(duì)記錄的錯(cuò)誤碼進(jìn)行解析，從而準(zhǔn)確地判斷故障類(lèi)型。在設(shè)計(jì)錯(cuò)誤碼時(shí)要做到錯(cuò)誤分支的全覆蓋，涵蓋整個(gè)應(yīng)用程序的所有函數(shù)和文件，也包括硬件設(shè)備的錯(cuò)誤碼。錯(cuò)誤碼的設(shè)計(jì)方式可參考以下某安全產(chǎn)品嵌入式下位機(jī)的錯(cuò)誤碼相關(guān)定義（C語(yǔ)言）：

由以上的代碼可知，錯(cuò)誤碼的格式可采用4byte 32bit 長(zhǎng)整形來(lái)表示，其中，高16bit 代表錯(cuò)誤模塊索引號(hào)（如代碼中的MODULE_CXXM3模塊為0x1002），低16bit 代表某錯(cuò)誤模塊的具體錯(cuò)誤索引號(hào)。上述代碼宏CXXM3_ERROR_4對(duì)應(yīng)的錯(cuò)誤碼0x10020004即可代表一種特定的錯(cuò)誤類(lèi)型，可將其用于該種類(lèi)型錯(cuò)誤的返回值。此外，還可考慮采用分層和分類(lèi)定位，在故障碼的數(shù)據(jù)結(jié)構(gòu)中包含代碼行號(hào)和文件號(hào)等信息。

2.2 綜合故障定位及分析方案

本文提出一種故障定位及分析的綜合方案，如圖5所示。該方案在程序中設(shè)計(jì)全覆蓋的錯(cuò)誤碼和關(guān)鍵信息追蹤，在出現(xiàn)故障后，將其記錄在用戶(hù)緩沖區(qū)中，并根據(jù)故障類(lèi)別，考慮將關(guān)鍵故障寫(xiě)到ROM中，同時(shí)通過(guò)網(wǎng)絡(luò)向系統(tǒng)維護(hù)臺(tái)發(fā)送關(guān)鍵追蹤信息和故障時(shí)的關(guān)鍵故障狀態(tài)記錄。

圖5 一種故障定位及分析的綜合方案

嵌入式下位機(jī)軟件在運(yùn)行時(shí)啟動(dòng)內(nèi)核事件追蹤機(jī)制，開(kāi)一個(gè)自定義追蹤進(jìn)程trace，當(dāng)用戶(hù)程序進(jìn)程掛掉或邏輯上的宕機(jī)導(dǎo)致trace在規(guī)定時(shí)間內(nèi)沒(méi)收到該進(jìn)程發(fā)送過(guò)來(lái)的PULSE（圖5中的①），trace會(huì)向調(diào)試內(nèi)核發(fā)送STOP 命令（圖5中的②），調(diào)試內(nèi)核收到該命令后會(huì)立即通過(guò)SIGINT 觸發(fā)tracelogger 進(jìn)程（圖5中的③）開(kāi)始進(jìn)行事件抓取和存儲(chǔ)操作，主動(dòng)去將當(dāng)前內(nèi)核緩沖區(qū)隊(duì)列中的所有數(shù)據(jù)刷到ROM 中，存儲(chǔ)為trace.kev文件。此外，在程序正常運(yùn)行過(guò)程中，針對(duì)程序運(yùn)行過(guò)程中的關(guān)鍵信息也需要每個(gè)周期實(shí)時(shí)記錄和追蹤相應(yīng)狀態(tài)，并通過(guò)網(wǎng)絡(luò)發(fā)送給系統(tǒng)維護(hù)臺(tái)（圖5中的④），以便在程序發(fā)生異常時(shí)，可通過(guò)所記錄的最后一個(gè)主周期各個(gè)關(guān)鍵信息的狀態(tài)來(lái)推測(cè)和還原異常故障發(fā)生時(shí)的系統(tǒng)調(diào)度情況。另外，故障發(fā)生時(shí)的故障報(bào)警信息也要通過(guò)網(wǎng)絡(luò)向系統(tǒng)維護(hù)臺(tái)發(fā)送。在下位機(jī)故障報(bào)警設(shè)計(jì)時(shí)，還需要盡可能地把出錯(cuò)數(shù)據(jù)包的相關(guān)信息（如出錯(cuò)包號(hào)、錯(cuò)誤包的包頭信息等）上報(bào)給上位機(jī)診斷維護(hù)程序（圖5中的④）。在較為嚴(yán)重的故障和宕機(jī)發(fā)生時(shí)，若網(wǎng)絡(luò)通信發(fā)生了異常，可以將一些關(guān)鍵的故障報(bào)警信息，以及應(yīng)用程序異常所引起的操作系統(tǒng)觸發(fā)CoreDump異常記錄（通過(guò)在運(yùn)行時(shí)加載DUMP 功能而獲取）等，以文件的方式寫(xiě)入ROM 中（圖5中的⑤）。對(duì)于ROM的寫(xiě)操作僅限于在系統(tǒng)出現(xiàn)故障時(shí)進(jìn)行，而在正常運(yùn)行時(shí)的關(guān)鍵狀態(tài)追蹤，則只向網(wǎng)絡(luò)發(fā)送，不寫(xiě)入ROM。

目前，這種綜合方案已成功應(yīng)用于iBase22-TSP型軌旁安全計(jì)算機(jī)平臺(tái)中?；谠撔蛙壟园踩脚_(tái)可以實(shí)現(xiàn)地鐵CBTC系統(tǒng)的ZC/LC應(yīng)用和城際鐵路CCS通信控制器應(yīng)用。采用了本綜合方案后，基于該型平臺(tái)的嵌入式系統(tǒng)下位機(jī)的故障診斷維護(hù)功能得到豐富和加強(qiáng)，縮短了故障定位時(shí)間，增強(qiáng)了系統(tǒng)的可維護(hù)性，有助于系統(tǒng)穩(wěn)定性的改善和提高。

3 結(jié)束語(yǔ)

本文梳理了鐵路信號(hào)產(chǎn)品嵌入式系統(tǒng)下位機(jī)的故障類(lèi)型，針對(duì)每一種故障類(lèi)型，詳細(xì)探討了相應(yīng)的故障定位及分析方法，最后提出一種嵌入式系統(tǒng)下位機(jī)故障定位及分析的綜合方案，并將該綜合方案成功應(yīng)用于iBase22-TSP 型軌旁安全計(jì)算機(jī)平臺(tái)中，使得該型平臺(tái)嵌入式系統(tǒng)下位機(jī)的故障定位和診斷維護(hù)功能得到加強(qiáng)。雖然本文以鐵路信號(hào)產(chǎn)品的嵌入式系統(tǒng)下位機(jī)作為研究對(duì)象，但所提出的方案本身具有通用性，也適用于其它工業(yè)控制自動(dòng)化領(lǐng)域的嵌入式系統(tǒng)下位機(jī)故障定位及分析相關(guān)設(shè)計(jì)。然而，受研究對(duì)象的既有軟硬件架構(gòu)所限，本文中提到的故障類(lèi)別和相應(yīng)的分析方法還不夠全面，要做到對(duì)嵌入式系統(tǒng)下位機(jī)故障的精確定位，還需要輔以更多的技術(shù)手段，不斷豐富和補(bǔ)充。此外，故障定位及分析方法屬于產(chǎn)品可維護(hù)性設(shè)計(jì)的一部分，如果要更進(jìn)一步地加強(qiáng)故障定位及分析功能，還需要從產(chǎn)品可維護(hù)性的其它方面來(lái)采取措施。