張蕾 唐甜 徐杰

摘 要：軟件健康管理概念最早源于NASA“Integrated Vehicle Health Management Technical Plan”報告，旨在實現(xiàn)自動檢測、診斷、預計和減緩有軟件異常引起的不良事件。本文首先闡述了飛機健康管理的定義和特點，其次基于失效模式，對開發(fā)過程中出現(xiàn)的故障進行整理和分類，其次結(jié)合FMEA的思想，對故障的風險順序數(shù)進行計算，最后列出高風險故障，制定緩解措施，為國內(nèi)軟件領(lǐng)域開展健康管理提供借鑒。

關(guān)鍵詞：軟件健康管理；風險順序數(shù)；FMEA分析

2008年10月7日，澳航空中客機A330-303攀升至37000英尺高空中，3分鐘之內(nèi)發(fā)生兩次急速向下“俯沖”，其中110名乘客和四分之三機組成員受傷。調(diào)查結(jié)果指出，本次事故是由于飛機上的一個組件——飛行數(shù)據(jù)/惰性參考單元（ADIRU），在事故前突然失效，并向其他系統(tǒng)發(fā)送錯誤數(shù)據(jù)，根據(jù)這些錯誤參數(shù)，對客機實行俯沖指示，導致本次事故發(fā)生[ 1 ]。此事件說明，對于這種高安全性、高可靠性要求的嵌入式系統(tǒng)，需要有一種有效的方式，來阻止這種軟件運行時錯誤，并在系統(tǒng)發(fā)生錯誤時，能夠自動從故障中恢復，避免導致災難性后果。

在軟件開發(fā)過程中，有確認和驗證（V&V）環(huán)節(jié)，這個環(huán)節(jié)的主要任務就是要確保在軟件被使用之前，發(fā)現(xiàn)軟件實現(xiàn)中與需求不一致的內(nèi)容，以及隱含的軟件錯誤和缺陷。然而經(jīng)驗顯示，這種發(fā)現(xiàn)錯誤的黃金標準，在實際使用中并不能達到期望的目標。甚至軟件本身的問題已經(jīng)很少，但和一些硬件（比如傳感器、作動器）聯(lián)系在一起使用，當意外的操作條件產(chǎn)生或環(huán)境的改變，也會導致有些軟件錯誤或缺陷的發(fā)生，因此軟件健康管理顯得至關(guān)重要。

1 軟件健康管理的概念

軟件健康管理（SWHM）被可理解為一種技術(shù)，應用健康管理的原則和技術(shù)到軟件系統(tǒng)中，它是健康管理（PHM）的一個新分支，是用來檢測、診斷、預測和減輕由于軟件故障引起的不良事件[ 2 ]。出現(xiàn)這些故障的原因很多，包括：編碼錯誤、非預期故障、有硬件引起的故障或與外部環(huán)境的交互問題?？偠灾?，軟件健康管理就是當軟件故障發(fā)生在意想不到的條件下發(fā)生時，維護系統(tǒng)的功能和性能的一種方法。

通過對軟件健康管理概念的理解可以看出，軟件健康管理具有以下幾個特點：

1）軟件健康管理是健康管理技術(shù)在軟件領(lǐng)域中的拓展，是健康管理的一個新分支；

2）強調(diào)自主性，自動檢測、診斷和處理；

3）軟件健康管理關(guān)注的對象是由異常情況引起的不良事件，而非故障，該不良情況有可能是軟件內(nèi)部引起的，也可能由外部環(huán)境引起；

4）軟件健康管理的目的是通過對不良事件危險性的評估，采取相應的減緩措施阻止該不良事件演變成故障，對系統(tǒng)的正常運行造成影響；

5）健康管理過程與硬件健康過程相似但不完全相同，與硬件最大的不同在于對未來狀態(tài)的預測，對于引起不良事件的軟件構(gòu)件/模塊并不能對自己進行狀態(tài)預測，只能預測該構(gòu)件/模塊的不良事件在軟件內(nèi)部傳播時對與之相關(guān)構(gòu)件/模塊的影響。

軟件故障隨著時間增長不會發(fā)展，也不會自己消除，會存在于整個軟件的生命周期中，需求錯誤、設(shè)計缺陷和編碼錯誤等都是例子。如果軟件故障再測試中不能被發(fā)現(xiàn)和移除，將一直以休眠形式，存在于軟件系統(tǒng)中，在操作過程或條件達到時被觸發(fā)。

軟件中的故障，在與有問題的硬件交互操作時發(fā)生。硬件系統(tǒng)（包括他們的傳感器）可能會出現(xiàn)與其期望的行為不同，因此會導致軟件故障。這個不同的行為可能有很多原因：比如開發(fā)過程中的意外事件、硬件故障導致的結(jié)果（傳感器電纜壞掉）、失效的傳感器或逐漸退化的硬件系統(tǒng)（信號噪聲超過指定的級別）。物理系統(tǒng)會因為各種原因產(chǎn)生異常，在這種物理環(huán)境下，軟件能正常運行極其困難。

因此要進行軟件健康管理，需要有兩個步驟：

1）首先要根據(jù)歷史的關(guān)鍵軟件，在開發(fā)過程中可能發(fā)生的故障進行整理并分類；

2）利用故障模式和影響分析（FMEA）的方法對這些故障進行分析，指定緩解計劃。

2 基于失效模式的故障分類

通過對歷史的關(guān)鍵軟件進行整理，將故障分為16類，包括算法錯誤、總線接口錯誤、配置管理錯誤、編譯錯誤、數(shù)據(jù)定義錯誤、數(shù)據(jù)處理錯誤、文檔錯誤、硬件錯誤、輸入/輸出系統(tǒng)錯誤、實現(xiàn)錯誤、交叉?zhèn)鬏斿e誤、性能錯誤、自測試錯誤、系統(tǒng)集成錯誤、工具錯誤、用戶執(zhí)行錯誤。

算法錯誤，定義了軟件設(shè)計中的基本錯誤，其中包括錯誤的混合邏輯、錯誤的數(shù)據(jù)發(fā)送/更新算法、死代碼、錯誤的分支邏輯、錯誤的算法邏輯、錯誤的工程單元、錯誤的方程或計算、錯誤的故障檢測算法、錯誤的故障隔離算法、錯誤的故障管理邏輯、錯誤的報告邏輯、計算時使用的錯誤的信號、初始化邏輯錯誤、初始化值錯誤、反轉(zhuǎn)邏輯錯誤、缺少初始化功能、缺少計算過程中限制值、缺少原型模型、不正確或不合適的計算或條件范圍、操作符錯誤、錯誤的復位邏輯、錯誤的復位時間、設(shè)置值或變量錯誤、語法錯誤、測試模型錯誤、錯誤的臨界值、錯誤的延遲、筆誤、缺失或不正確或不合適的有效性檢查。

總線接口錯誤，定義了數(shù)據(jù)資源和總線傳輸錯誤，其中包括錯誤的位位置、總線初始化錯誤、發(fā)送的數(shù)據(jù)錯誤及總線接口信號缺失。

配置管理錯誤，定義配置管理過程中存在的錯誤，其中包括未被發(fā)布的正確的軟件版本、執(zhí)行延遲、不正確的軟件版本、需求未及時更新以及軟件版本與需求不匹配。

編譯錯誤，定義軟件生成過程中，由工具軟件創(chuàng)建的一類錯誤，包括不正確的匯編代碼生成。

數(shù)據(jù)定義錯誤，定義了內(nèi)存中的錯誤數(shù)據(jù)結(jié)構(gòu)描述，其中包括錯誤的數(shù)據(jù)結(jié)構(gòu)、錯誤的數(shù)據(jù)類型、錯誤的枚舉類型、錯誤的查找表、錯誤的偏移量、錯誤的位大小。

數(shù)據(jù)處理錯誤，定義了包含非法的、未定義的或錯誤的數(shù)據(jù)元素或變量的使用，其中包括強制類型轉(zhuǎn)換錯誤、斷點錯誤、低位高位反序、表或數(shù)組的索引錯誤、錯誤的數(shù)據(jù)處理邏輯、使用錯誤的內(nèi)存地址、錯誤的比例因子、錯誤的轉(zhuǎn)換邏輯、錯誤的變量或變量類型。

文檔錯誤，定義文檔中出現(xiàn)的錯誤，比如設(shè)計文檔、流程圖、狀態(tài)圖、結(jié)構(gòu)圖等，能導致后續(xù)的軟件開發(fā)出現(xiàn)異常。

硬件錯誤，定義在軟件直接或間接影響的物理系統(tǒng)的不足或缺陷。

輸入/輸出系統(tǒng)錯誤，定義了和輸入輸出相關(guān)的錯誤，其中包括錯誤的數(shù)據(jù)列表、I/O同步錯誤、數(shù)據(jù)結(jié)構(gòu)順序錯誤、缺少或錯誤的信號輸入。

實現(xiàn)錯誤，定義了軟件需求被錯誤的實現(xiàn)的錯誤，包括軟件需求或軟件變更需求，在代碼中被錯誤的實現(xiàn)。

交叉?zhèn)鬏斿e誤，定義了處理器或并聯(lián)模塊之間，不能正確握手的錯誤，其中包括錯誤的定義邏輯、工程單元不匹配、故障管理、輸入輸出不同步、錯誤的初始化邏輯、錯誤的交叉?zhèn)鬏斶壿?、錯誤的復位時間、錯誤的采集時間、錯誤的延遲。

性能錯誤，定義了違反實時需求或處理器極限閾值的錯誤，包括超出處理器極限閾值；

自測試錯誤，飛行前的充分的測試，用來驗證系統(tǒng)的狀態(tài)是否正常。其中包括不合適的測試條件、錯誤的測試設(shè)計、不恰當?shù)男枨蟆㈠e誤的測試時間、時間管理、測試用例中輸入錯誤的值、丟失復位功能。

系統(tǒng)集成錯誤，定義了當主要系統(tǒng)組件聚集在一起作用時產(chǎn)生的錯誤。其中包括通道未同步、需求沖突、錯誤變更需求、錯誤的數(shù)據(jù)資源、發(fā)動機單元不匹配、ICD或軟件不匹配、不一致的接口順序、錯誤的需求、錯誤的接口、錯誤的手冊、內(nèi)存使用錯誤、缺失數(shù)據(jù)、缺失訪問驅(qū)動、缺失頭文件、ICD文件中缺失信號、缺失軟件更新、缺失測試點、無需求、錯誤的參數(shù)、參數(shù)順序錯誤、同步率下降、需求不清楚、不必要的需求。

工具錯誤，其中包括運算法則錯誤（工具產(chǎn)生錯誤的信號和值）、輸入數(shù)據(jù)錯誤。

用戶執(zhí)行錯誤，定義了用戶在操作時，導致的錯誤。

3 基于FMEA的故障分析

和其他風險管理方法類似，我們重點考慮發(fā)生的頻率、嚴重程度及檢測的可能性，檢測的可能性是用來測量故障發(fā)生的階段和根據(jù)原因分析確定的故障注入階段之間誤差。

這種方法和風險管理的區(qū)別在于，這種方法是基于數(shù)據(jù)和已經(jīng)存在的或已經(jīng)發(fā)生的事件，而不是根據(jù)概率和驗證程度估計的事件。

3.1 風險順序數(shù)計算

風險順序數(shù)是一類故障類型相關(guān)的基本風險估計。這個參數(shù)的范圍從0到1000，可清楚的表明分類中的故障相對的風險優(yōu)先級。計算公式為：

3.2 RPN計算

當估計出的PRN值超過120，則可認為為高風險故障。對于高風險的故障，可采用風險避免、風險轉(zhuǎn)移、接受風險或風險減緩的措施來緩解。

如表2所示故障的RPN均超過120，在開發(fā)過程中，制定緩解措施，控制風險的發(fā)生。

4 總結(jié)與展望

本文根據(jù)失效模式，對歷史關(guān)鍵軟件，在開發(fā)過程中可能發(fā)生的故障進行整理并分類，利用FMEA的方法，對所有可能發(fā)生的故障的RPN進行計算，對于RPN超過120的故障，即是高風險故障，需要高度關(guān)注，并制定緩解措施，希望國內(nèi)軟件領(lǐng)域開展健康管理提供借鑒。

本文僅通過分析，列出高風險故障，在后續(xù)的研究中，需重點關(guān)注，可采用何種方式，在開發(fā)過程中減少此類故障發(fā)生。

參考文獻：

[1] Ashok N Srivasiava，Robert W Mah，Claudia Meyer，Integrated Vehicle Healeh Management Technical Plan[R].Version 2.03.NASA，2009：44.

[2] 宮華偉，李保中，溫永強.軟件健康管理在ADIRU中的應用及驗證.電光與控制第22卷第7期，2015年7月.

[3] 解維奇，蔡遠文，邢曉辰，辛朝軍.軟件健康管理系統(tǒng)故障診斷推理機算法，測控技術(shù)2014年第33卷第5期.