摘 要： 開發(fā)了一種統(tǒng)一的可靠性模型，該模型對系統(tǒng)的硬件失效、軟件失效和軟硬件交互失效都可以作出解釋。硬軟件失效可以由熟知的建模方法來解決。而提出了一套利用馬爾可夫過程來捕獲硬軟件交互失效的建模方法論，通過將其應用到真實的通信系統(tǒng)來說明該硬軟件混合的建模方法。
關鍵詞： 可靠性建模；軟件失效；硬件失效；軟硬件交互失效
針對硬件可靠性和軟件可靠性研究領域雖然有著大量的文獻，但多數(shù)都只局限于單獨的硬件或者軟件子系統(tǒng)的研究。少數(shù)研究者設法為整個系統(tǒng)建立一個混合的可靠性模型，既包括硬件也包括軟件。但他們通常認為硬件和軟件子系統(tǒng)是相互獨立的。
事實上，在許多現(xiàn)代計算機系統(tǒng)內(nèi)，硬件和軟件間的影響很大。例如，參考文獻[1]對斯坦福大學的MVS/SP操作系統(tǒng)進行的軟件錯誤分析發(fā)現(xiàn)，將近35%的軟件錯誤是和硬件有關的。在這些系統(tǒng)中，硬件和軟件子系統(tǒng)不是相互獨立的，系統(tǒng)的可靠性受軟硬件交互作用的影響。硬件和軟件系統(tǒng)之間的交互作用表現(xiàn)在兩個方面：積極的和消極的。參考文獻[1]中提到的哈勃望遠鏡機械上的問題，經(jīng)軟件變更而得到了緩和。這意味著通過軟件可以修正硬件問題，這就是軟件所起的積極作用。另一方面，預料不到的硬件失效模型致使軟件在一個非典型的操作模型下執(zhí)行，而軟件因沒有被嚴格的測試過，結果導致系統(tǒng)的性能下降。在失效狀態(tài)下，操作會更不可靠。
(5)硬件部件的失效率為λ1。
(6)局部硬件失效能以概率P1被檢測到，一旦檢測到，就可通過軟件方法以概率P2得到恢復。雖然軟件方法及相關的硬件可能找不到退化處，但是也不會有不正確的保護。
(7)一個檢測不到的硬件退化可能會導致硬軟件交互失效(失效率為λ3)，檢測到的硬件退化可導致執(zhí)行中止(失效率為λ4)。
(8)一旦局部硬件失效被檢測到，失效的硬件部件就被修正或者是替換，通過軟件恢復的概率為μ1a，沒有通過軟件恢復的概率為μ1b。
如果退化被檢測到卻沒有通過軟件的方法恢復，局部硬件失效可能進一步以概率λ2a演變?yōu)榭傮w失效；如果退化被檢測到并且通過軟件的方法恢復，則以概率λ2b演變?yōu)榭傮w失效；如果退化沒有被檢測到，則以概率為λ2c演變?yōu)榭傮w失效。
1.2 模型
基于(1)和(4)的假設，整個系統(tǒng)的可靠度為：
Rc(t)=Pr{t時刻無總體失效}×Pr{t時刻無純軟件失效}×
Pr{t時刻無硬軟件交互的失效}=RHW(t)RSW(t)RHW/SW(t)(1)
式中，RHW(t)和RSW(t)是純硬件可靠性函數(shù)，純軟件可靠性函數(shù)由假設(2)和(3)分別決定的，而軟硬件交互失效可靠性函數(shù)RHW/SW(t)來自于假設(5)~(9)。
圖1是HW/SW失效模型的狀態(tài)轉移圖。
下面通過其在通信系統(tǒng)中的應用來闡明硬軟件混合模型方法。
2 電信應用
2.1 系統(tǒng)描述
通過將模型應用到無線BSS的一個特殊部件來說明。這個特殊部件是服務器，它是BSc的一部分。服務器按N+1組配置的，組操作在負載均衡的環(huán)境下進行的。當一個服務器失效，組中剩下的服務器接管它所執(zhí)行的任務。每個服務器上運行的故障恢復軟件負責管理恢復進程。
表1列出占用時間和失效數(shù)據(jù)。表中所示的6個月中的每個月，總計硬件的占用時間的系統(tǒng)日期，不管硬件運行的是軟件R1(2列)還是R2(4列)，都已給出。第3和5列是服務器的應用編號，是通過把總的占用時間按每月的天數(shù)劃分而得到的。硬件設計也是一樣，不考慮它執(zhí)行的是哪個軟件，第6列表明了每月來自所有的服務器總的硬件失效的數(shù)目。第7列說明了服務器只運行軟件R2時的軟件失效數(shù)。
當區(qū)域中有軟件失效時，用戶會通知技術支持人員，由技術員創(chuàng)建故障列表。如果故障的性質被診斷是程序上的錯誤，通常會關閉故障列表，而當前的軟件釋放令不改變。如果故障已經(jīng)確定與軟件失效有關，則要為故障分配安全級別。區(qū)域中首次高安全性級別故障的發(fā)生與軟件更新之間的間隔通常不會超過兩周。如果域中有異常多點故障，有關這個重復事件的列表被認為是源故障列表的再現(xiàn)。在繪制表1時，只有源故障列表對高安全性級別的故障有反映。
表1沒有對硬軟件交互失效做出詳盡的說明。分析故障列表的根本原因時，沒有對其進行硬軟件交互失效的分類。多數(shù)情況下，域中發(fā)生的硬軟件交互失效都被劃分為了硬件失效，因為失效中的硬件因素在故障列表被創(chuàng)建時比軟件因素更明顯。下面，在調(diào)查硬軟件交互失效的影響時，在不確定的假設條件下分析硬件失效實際為硬軟件交互失效的概率F有多大。
2.2 配置模型
為了安裝硬軟件交互失效模型，只關注運行R2的服務器，因為硬軟件交互失效模型包含軟件失效率λ3，這個參數(shù)依賴于軟件排錯。由于這個實例中系統(tǒng)沒有內(nèi)置的檢測硬件退化的機制，在表1中，令P1=0。另外，為了滿足λ3>>λ2c，則進行進一步簡化，令λ2c=0，則由式(2)可以導出：
許多現(xiàn)有的可靠性模型都沒有考慮硬軟件子系統(tǒng)的交互失效，而只考慮了純硬件和純軟件失效。結果，大多數(shù)失效數(shù)據(jù)都是就純硬件和純軟件失效而得到的。當建立純硬件或純軟件模型時，硬軟件交互失效被忽略。這對于可靠性預測方法是非常不利的。本文方法由于考慮了硬軟件交互失效對整個系統(tǒng)的影響，這樣建立的模型比傳統(tǒng)的只分別考慮軟件和硬件所建立的模型具有更準確的可靠性預測。
參考文獻
[1] BAIN L J. Statistical analysis of reliability and life-testing models[M]. New York： Marcel Dekker， 1978.
[2] FRIEDMAN M A， TRAN P. Reliability techniques for combined hardware/software systems[C]. Proceedings of Annual Reliability and Maintainability Symposium， 1992：290-293.
[3] GOEL A L， OKUMOTO K. A Markovian model for reliability and other performance measures of software systems[C]. Proceedings of the National Computer Conference， 1979： 769-774.
[4] HECHT H， HECHT M. Software reliability in the system context[J]. IEEE Transactions on Software Engineering， January， 1986， 12(1)：51-58.
[5] IYER R K. Hardware-related software errors： measurement and analysis[J]. IEEE Transactions on Software Engineering， February， 1985，11(2)：223-230.
[6] PARZEN E. Stochastic processes[M]. San Francisco， CA： Holden-Day， 1962.
[7] PHAM H， Software reliability[M]. New York： Springer， 2000.
[8] WELKE S R， JOHNSON B W， AYLOR J H. Reliability modeling ofhardware/software systems[J]. IEEE Transactions on Reliability， September， 1995， 44(3)：413-418.