張蕾 唐甜 徐杰

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

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

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

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

1 軟件健康管理的概念

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

通過對(duì)軟件健康管理概念的理解可以看出，軟件健康管理具有以下幾個(gè)特點(diǎn)：

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

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

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

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

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

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

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

因此要進(jìn)行軟件健康管理，需要有兩個(gè)步驟：

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

用戶執(zhí)行錯(cuò)誤，定義了用戶在操作時(shí)，導(dǎo)致的錯(cuò)誤。

3 基于FMEA的故障分析

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

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

3.1 風(fēng)險(xiǎn)順序數(shù)計(jì)算

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

3.2 RPN計(jì)算

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

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

4 總結(jié)與展望

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

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

參考文獻(xiàn)：

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

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

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