董高云，余文兵，周庭梁

（卡斯柯信號有限公司 平臺技術中心，上海200071）

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

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

1 嵌入式系統(tǒng)下位機架構及故障類型梳理

1.1 嵌入式系統(tǒng)下位機架構分析

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

圖1 嵌入式系統(tǒng)下位機架構

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

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

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

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

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

1.2.1 硬件

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

1.2.2 驅動&固件

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

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

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

固件代碼（如FPGA、CPLD代碼）的出錯特征與驅動類似，表現(xiàn)為與相應代碼對應的固件工作異常。出錯也具有普遍性（更換硬件后，故障仍存在），并呈現(xiàn)一定的隨機性概率（有時低概率出現(xiàn)）。

1.2.3 操作系統(tǒng)

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

操作系統(tǒng)本身的缺陷可以通過操作系統(tǒng)廠商提供的相應版本BugList 來獲得一些信息，此外，廠商的技術支持也尤為重要。其它層級的缺陷導致的操作系統(tǒng)異常更為常見，多為使用人員對操作系統(tǒng)不熟悉，或針對相應組件操作不當而導致。

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

1.2.4 應用軟件

應用軟件故障可以分為以下3種：

（1）應用軟件設計缺陷導致的程序調度錯誤，可導致程序的任務調度異常，軟件無法完成指定功能，或者導致部分任務被掛起而引起系統(tǒng)整體宕機。

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

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

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

2.1 不同類型故障的定位及分析方案

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

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

2.1.1 內核事件追蹤

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

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

圖3 SAT工作原理

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

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

圖4 SAT應用框架

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

內核事件追蹤機制針對調度錯誤的原因查找特別有幫助，對于操作系統(tǒng)本身故障的查找也有很大的參考價值，對于與任務調度和時序控制相關的驅動和硬件故障的查找也具有很好的參考價值，但是對于其他難以反饋到任務調度圖中的驅動和硬件問題，則幫助不大，需要輔以其他手段來綜合定位。

2.1.2 DUMP功能

應用軟件的程序異常可能引起程序崩潰，嵌入式操作系統(tǒng)對于這種異常有相應的記錄機制，可準確定位相應異常，并記錄在相關的存儲介質中，嵌入式操作系統(tǒng)的這種功能稱為DUMP 功能。

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

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

表1 異常信號集合

2.1.3 關鍵信息追蹤

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

（1）程序框架邏輯、程序主分支的時序點，如主周期的起始或結束點、主周期運行過程中的分段時序響應起止點、定時中斷或串口中斷的定時響應點等。

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

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

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

2.1.4 錯誤碼

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

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

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

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

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

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

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

3 結束語

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