《電子技術(shù)應(yīng)用》
您所在的位置:首頁 > 嵌入式技術(shù) > 設(shè)計(jì)應(yīng)用 > 硬軟件交互的可靠性建模及其應(yīng)用
硬軟件交互的可靠性建模及其應(yīng)用
來源:微型機(jī)與應(yīng)用2011年第5期
胡慧芳,沈元隆
(南京郵電大學(xué) 電子科學(xué)與工程學(xué)院,江蘇 南京 210003)
摘要: 開發(fā)了一種統(tǒng)一的可靠性模型,該模型對(duì)系統(tǒng)的硬件失效、軟件失效和軟硬件交互失效都可以作出解釋。硬軟件失效可以由熟知的建模方法來解決。而提出了一套利用馬爾可夫過程來捕獲硬軟件交互失效的建模方法論,通過將其應(yīng)用到真實(shí)的通信系統(tǒng)來說明該硬軟件混合的建模方法。
Abstract:
Key words :

摘  要: 開發(fā)了一種統(tǒng)一的可靠性模型,該模型對(duì)系統(tǒng)的硬件失效、軟件失效軟硬件交互失效都可以作出解釋。硬軟件失效可以由熟知的建模方法來解決。而提出了一套利用馬爾可夫過程來捕獲硬軟件交互失效的建模方法論,通過將其應(yīng)用到真實(shí)的通信系統(tǒng)來說明該硬軟件混合的建模方法。
關(guān)鍵詞: 可靠性建模;軟件失效;硬件失效;軟硬件交互失效

 針對(duì)硬件可靠性和軟件可靠性研究領(lǐng)域雖然有著大量的文獻(xiàn),但多數(shù)都只局限于單獨(dú)的硬件或者軟件子系統(tǒng)的研究。少數(shù)研究者設(shè)法為整個(gè)系統(tǒng)建立一個(gè)混合的可靠性模型,既包括硬件也包括軟件。但他們通常認(rèn)為硬件和軟件子系統(tǒng)是相互獨(dú)立的。
事實(shí)上,在許多現(xiàn)代計(jì)算機(jī)系統(tǒng)內(nèi),硬件和軟件間的影響很大。例如,參考文獻(xiàn)[1]對(duì)斯坦福大學(xué)的MVS/SP操作系統(tǒng)進(jìn)行的軟件錯(cuò)誤分析發(fā)現(xiàn),將近35%的軟件錯(cuò)誤是和硬件有關(guān)的。在這些系統(tǒng)中,硬件和軟件子系統(tǒng)不是相互獨(dú)立的,系統(tǒng)的可靠性受軟硬件交互作用的影響。硬件和軟件系統(tǒng)之間的交互作用表現(xiàn)在兩個(gè)方面:積極的和消極的。參考文獻(xiàn)[1]中提到的哈勃望遠(yuǎn)鏡機(jī)械上的問題,經(jīng)軟件變更而得到了緩和。這意味著通過軟件可以修正硬件問題,這就是軟件所起的積極作用。另一方面,預(yù)料不到的硬件失效模型致使軟件在一個(gè)非典型的操作模型下執(zhí)行,而軟件因沒有被嚴(yán)格的測(cè)試過,結(jié)果導(dǎo)致系統(tǒng)的性能下降。在失效狀態(tài)下,操作會(huì)更不可靠。

 (5)硬件部件的失效率為λ1。
 (6)局部硬件失效能以概率P1被檢測(cè)到,一旦檢測(cè)到,就可通過軟件方法以概率P2得到恢復(fù)。雖然軟件方法及相關(guān)的硬件可能找不到退化處,但是也不會(huì)有不正確的保護(hù)。
 (7)一個(gè)檢測(cè)不到的硬件退化可能會(huì)導(dǎo)致硬軟件交互失效(失效率為λ3),檢測(cè)到的硬件退化可導(dǎo)致執(zhí)行中止(失效率為λ4)。
 (8)一旦局部硬件失效被檢測(cè)到,失效的硬件部件就被修正或者是替換,通過軟件恢復(fù)的概率為μ1a,沒有通過軟件恢復(fù)的概率為μ1b。
 如果退化被檢測(cè)到卻沒有通過軟件的方法恢復(fù),局部硬件失效可能進(jìn)一步以概率λ2a演變?yōu)榭傮w失效;如果退化被檢測(cè)到并且通過軟件的方法恢復(fù),則以概率λ2b演變?yōu)榭傮w失效;如果退化沒有被檢測(cè)到,則以概率為λ2c演變?yōu)榭傮w失效。
1.2 模型
 基于(1)和(4)的假設(shè),整個(gè)系統(tǒng)的可靠度為:
 Rc(t)=Pr{t時(shí)刻無總體失效}×Pr{t時(shí)刻無純軟件失效}×
  Pr{t時(shí)刻無硬軟件交互的失效}=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的一個(gè)特殊部件來說明。這個(gè)特殊部件是服務(wù)器,它是BSc的一部分。服務(wù)器按N+1組配置的,組操作在負(fù)載均衡的環(huán)境下進(jìn)行的。當(dāng)一個(gè)服務(wù)器失效,組中剩下的服務(wù)器接管它所執(zhí)行的任務(wù)。每個(gè)服務(wù)器上運(yùn)行的故障恢復(fù)軟件負(fù)責(zé)管理恢復(fù)進(jìn)程。
 表1列出占用時(shí)間和失效數(shù)據(jù)。表中所示的6個(gè)月中的每個(gè)月,總計(jì)硬件的占用時(shí)間的系統(tǒng)日期,不管硬件運(yùn)行的是軟件R1(2列)還是R2(4列),都已給出。第3和5列是服務(wù)器的應(yīng)用編號(hào),是通過把總的占用時(shí)間按每月的天數(shù)劃分而得到的。硬件設(shè)計(jì)也是一樣,不考慮它執(zhí)行的是哪個(gè)軟件,第6列表明了每月來自所有的服務(wù)器總的硬件失效的數(shù)目。第7列說明了服務(wù)器只運(yùn)行軟件R2時(shí)的軟件失效數(shù)。

 當(dāng)區(qū)域中有軟件失效時(shí),用戶會(huì)通知技術(shù)支持人員,由技術(shù)員創(chuàng)建故障列表。如果故障的性質(zhì)被診斷是程序上的錯(cuò)誤,通常會(huì)關(guān)閉故障列表,而當(dāng)前的軟件釋放令不改變。如果故障已經(jīng)確定與軟件失效有關(guān),則要為故障分配安全級(jí)別。區(qū)域中首次高安全性級(jí)別故障的發(fā)生與軟件更新之間的間隔通常不會(huì)超過兩周。如果域中有異常多點(diǎn)故障,有關(guān)這個(gè)重復(fù)事件的列表被認(rèn)為是源故障列表的再現(xiàn)。在繪制表1時(shí),只有源故障列表對(duì)高安全性級(jí)別的故障有反映。
 表1沒有對(duì)硬軟件交互失效做出詳盡的說明。分析故障列表的根本原因時(shí),沒有對(duì)其進(jìn)行硬軟件交互失效的分類。多數(shù)情況下,域中發(fā)生的硬軟件交互失效都被劃分為了硬件失效,因?yàn)槭е械挠布蛩卦诠收狭斜肀粍?chuàng)建時(shí)比軟件因素更明顯。下面,在調(diào)查硬軟件交互失效的影響時(shí),在不確定的假設(shè)條件下分析硬件失效實(shí)際為硬軟件交互失效的概率F有多大。
2.2 配置模型
 為了安裝硬軟件交互失效模型,只關(guān)注運(yùn)行R2的服務(wù)器,因?yàn)橛曹浖换ナP桶浖?lambda;3,這個(gè)參數(shù)依賴于軟件排錯(cuò)。由于這個(gè)實(shí)例中系統(tǒng)沒有內(nèi)置的檢測(cè)硬件退化的機(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)建立純硬件或純軟件模型時(shí),硬軟件交互失效被忽略。這對(duì)于可靠性預(yù)測(cè)方法是非常不利的。本文方法由于考慮了硬軟件交互失效對(duì)整個(gè)系統(tǒng)的影響,這樣建立的模型比傳統(tǒng)的只分別考慮軟件和硬件所建立的模型具有更準(zhǔn)確的可靠性預(yù)測(cè)。
參考文獻(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.

此內(nèi)容為AET網(wǎng)站原創(chuàng),未經(jīng)授權(quán)禁止轉(zhuǎn)載。