摘 要： 開發(fā)了一種統(tǒng)一的可靠性模型，該模型對系統(tǒng)的硬件失效、軟件失效和軟硬件交互失效都可以作出解釋。硬軟件失效可以由熟知的建模方法來解決。而提出了一套利用馬爾可夫過程來捕獲硬軟件交互失效的建模方法論，通過將其應(yīng)用到真實的通信系統(tǒng)來說明該硬軟件混合的建模方法。
關(guān)鍵詞： 可靠性建模；軟件失效；硬件失效；軟硬件交互失效
針對硬件可靠性和軟件可靠性研究領(lǐng)域雖然有著大量的文獻(xiàn)，但多數(shù)都只局限于單獨的硬件或者軟件子系統(tǒng)的研究。少數(shù)研究者設(shè)法為整個系統(tǒng)建立一個混合的可靠性模型，既包括硬件也包括軟件。但他們通常認(rèn)為硬件和軟件子系統(tǒng)是相互獨立的。
事實上，在許多現(xiàn)代計算機(jī)系統(tǒng)內(nèi)，硬件和軟件間的影響很大。例如，參考文獻(xiàn)[1]對斯坦福大學(xué)的MVS/SP操作系統(tǒng)進(jìn)行的軟件錯誤分析發(fā)現(xiàn)，將近35%的軟件錯誤是和硬件有關(guān)的。在這些系統(tǒng)中，硬件和軟件子系統(tǒng)不是相互獨立的，系統(tǒng)的可靠性受軟硬件交互作用的影響。硬件和軟件系統(tǒng)之間的交互作用表現(xiàn)在兩個方面：積極的和消極的。參考文獻(xiàn)[1]中提到的哈勃望遠(yuǎn)鏡機(jī)械上的問題，經(jīng)軟件變更而得到了緩和。這意味著通過軟件可以修正硬件問題，這就是軟件所起的積極作用。另一方面，預(yù)料不到的硬件失效模型致使軟件在一個非典型的操作模型下執(zhí)行，而軟件因沒有被嚴(yán)格的測試過，結(jié)果導(dǎo)致系統(tǒng)的性能下降。在失效狀態(tài)下，操作會更不可靠。
(5)硬件部件的失效率為λ1。
(6)局部硬件失效能以概率P1被檢測到，一旦檢測到，就可通過軟件方法以概率P2得到恢復(fù)。雖然軟件方法及相關(guān)的硬件可能找不到退化處，但是也不會有不正確的保護(hù)。
(7)一個檢測不到的硬件退化可能會導(dǎo)致硬軟件交互失效(失效率為λ3)，檢測到的硬件退化可導(dǎo)致執(zhí)行中止(失效率為λ4)。
(8)一旦局部硬件失效被檢測到，失效的硬件部件就被修正或者是替換，通過軟件恢復(fù)的概率為μ1a，沒有通過軟件恢復(fù)的概率為μ1b。
如果退化被檢測到卻沒有通過軟件的方法恢復(fù)，局部硬件失效可能進(jìn)一步以概率λ2a演變?yōu)榭傮w失效；如果退化被檢測到并且通過軟件的方法恢復(fù)，則以概率λ2b演變?yōu)榭傮w失效；如果退化沒有被檢測到，則以概率為λ2c演變?yōu)榭傮w失效。
1.2 模型
基于(1)和(4)的假設(shè)，整個系統(tǒng)的可靠度為：
Rc(t)=Pr{t時刻無總體失效}×Pr{t時刻無純軟件失效}×
Pr{t時刻無硬軟件交互的失效}=RHW(t)RSW(t)RHW/SW(t)(1)
式中，RHW(t)和RSW(t)是純硬件可靠性函數(shù)，純軟件可靠性函數(shù)由假設(shè)(2)和(3)分別決定的，而軟硬件交互失效可靠性函數(shù)RHW/SW(t)來自于假設(shè)(5)~(9)。
圖1是HW/SW失效模型的狀態(tài)轉(zhuǎn)移圖。
下面通過其在通信系統(tǒng)中的應(yīng)用來闡明硬軟件混合模型方法。
2 電信應(yīng)用
2.1 系統(tǒng)描述
通過將模型應(yīng)用到無線BSS的一個特殊部件來說明。這個特殊部件是服務(wù)器，它是BSc的一部分。服務(wù)器按N+1組配置的，組操作在負(fù)載均衡的環(huán)境下進(jìn)行的。當(dāng)一個服務(wù)器失效，組中剩下的服務(wù)器接管它所執(zhí)行的任務(wù)。每個服務(wù)器上運行的故障恢復(fù)軟件負(fù)責(zé)管理恢復(fù)進(jìn)程。
表1列出占用時間和失效數(shù)據(jù)。表中所示的6個月中的每個月，總計硬件的占用時間的系統(tǒng)日期，不管硬件運行的是軟件R1(2列)還是R2(4列)，都已給出。第3和5列是服務(wù)器的應(yīng)用編號，是通過把總的占用時間按每月的天數(shù)劃分而得到的。硬件設(shè)計也是一樣，不考慮它執(zhí)行的是哪個軟件，第6列表明了每月來自所有的服務(wù)器總的硬件失效的數(shù)目。第7列說明了服務(wù)器只運行軟件R2時的軟件失效數(shù)。
當(dāng)區(qū)域中有軟件失效時，用戶會通知技術(shù)支持人員，由技術(shù)員創(chuàng)建故障列表。如果故障的性質(zhì)被診斷是程序上的錯誤，通常會關(guān)閉故障列表，而當(dāng)前的軟件釋放令不改變。如果故障已經(jīng)確定與軟件失效有關(guān)，則要為故障分配安全級別。區(qū)域中首次高安全性級別故障的發(fā)生與軟件更新之間的間隔通常不會超過兩周。如果域中有異常多點故障，有關(guān)這個重復(fù)事件的列表被認(rèn)為是源故障列表的再現(xiàn)。在繪制表1時，只有源故障列表對高安全性級別的故障有反映。
表1沒有對硬軟件交互失效做出詳盡的說明。分析故障列表的根本原因時，沒有對其進(jìn)行硬軟件交互失效的分類。多數(shù)情況下，域中發(fā)生的硬軟件交互失效都被劃分為了硬件失效，因為失效中的硬件因素在故障列表被創(chuàng)建時比軟件因素更明顯。下面，在調(diào)查硬軟件交互失效的影響時，在不確定的假設(shè)條件下分析硬件失效實際為硬軟件交互失效的概率F有多大。
2.2 配置模型
為了安裝硬軟件交互失效模型，只關(guān)注運行R2的服務(wù)器，因為硬軟件交互失效模型包含軟件失效率λ3，這個參數(shù)依賴于軟件排錯。由于這個實例中系統(tǒng)沒有內(nèi)置的檢測硬件退化的機(jī)制，在表1中，令P1=0。另外，為了滿足λ3>>λ2c，則進(jìn)行進(jìn)一步簡化，令λ2c=0，則由式(2)可以導(dǎo)出：
許多現(xiàn)有的可靠性模型都沒有考慮硬軟件子系統(tǒng)的交互失效，而只考慮了純硬件和純軟件失效。結(jié)果，大多數(shù)失效數(shù)據(jù)都是就純硬件和純軟件失效而得到的。當(dāng)建立純硬件或純軟件模型時，硬軟件交互失效被忽略。這對于可靠性預(yù)測方法是非常不利的。本文方法由于考慮了硬軟件交互失效對整個系統(tǒng)的影響，這樣建立的模型比傳統(tǒng)的只分別考慮軟件和硬件所建立的模型具有更準(zhǔn)確的可靠性預(yù)測。
參考文獻(xiàn)
[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.