提高嵌入式軟件質(zhì)量

　　航空領(lǐng)域的軟件應(yīng)用

　　高集成系統(tǒng)中的嵌入式軟件日益復(fù)雜。在軍事領(lǐng)域中，用于F-22猛禽戰(zhàn)斗機(jī)的航空電子軟件由170萬行代碼組成，用于F-35聯(lián)合攻擊戰(zhàn)斗機(jī)的航空電子軟件預(yù)計(jì)有570萬行代碼。對(duì)于商務(wù)班機(jī)，波音787飛機(jī)飛行控制系統(tǒng)將有大約650萬行代碼。軟件內(nèi)容不斷膨脹，飛機(jī)復(fù)雜性不斷增加，使發(fā)生故障的風(fēng)險(xiǎn)也不斷加劇，從而使獲得高度可信性軟件的過程復(fù)雜無比。

　　軟件故障風(fēng)險(xiǎn)

　　研究以往發(fā)生的嵌入式設(shè)備故障對(duì)于理解代碼相關(guān)的問題大有裨益。例如，一次性使用火箭在測(cè)試飛行期間發(fā)生的故障歸根于代碼缺陷。在這種特殊情況下，發(fā)射器在發(fā)射后不到一分鐘的時(shí)間內(nèi)自毀，原因在于：攻角超過規(guī)定的安全限度，導(dǎo)致發(fā)射器遭遇高氣動(dòng)載荷。

　　事后調(diào)查揭露了故障的根本原因：溢出導(dǎo)致嵌入式軟件發(fā)生運(yùn)行錯(cuò)誤。在將一個(gè)64位浮點(diǎn)數(shù)轉(zhuǎn)換為16位有符號(hào)整數(shù)時(shí)，一對(duì)決定火箭姿態(tài)和位置的冗余慣性參考系統(tǒng)中產(chǎn)生溢出，從而將火箭噴管移到了極端位置。冗余系統(tǒng)的存在不起作用，因?yàn)閭溆孟到y(tǒng)也發(fā)生了同樣的問題。

　　如上所述的運(yùn)行時(shí)錯(cuò)誤代表一類特定的軟件錯(cuò)誤，稱作潛伏性故障。這類故障位于代碼中，但是除非在特殊條件下運(yùn)行特定測(cè)試，否則在系統(tǒng)測(cè)試期間無法檢測(cè)到這些故障。因此，這些代碼表面上能正常運(yùn)行，但實(shí)際上會(huì)導(dǎo)致意外的系統(tǒng)故障。以下為若干運(yùn)行時(shí)錯(cuò)誤示例：數(shù)據(jù)未初始化；數(shù)組訪問越界；空指針解引用；溢出和下溢；計(jì)算錯(cuò)誤；同時(shí)訪問共享數(shù)據(jù)；非法類型轉(zhuǎn)換。

　　高集成軟件驗(yàn)證

　　按照傳統(tǒng)方法，源代碼級(jí)軟件驗(yàn)證涉及代碼檢查、靜態(tài)分析和動(dòng)態(tài)測(cè)試。每種方法都有缺點(diǎn)。

　　代碼檢查僅依賴于檢察人員的專業(yè)技術(shù)，若有大量代碼需要檢查，則會(huì)是一項(xiàng)繁瑣的工作。傳統(tǒng)的靜態(tài)分析技術(shù)主要依靠模式匹配方法檢測(cè)不安全的代碼模式，但無法證明不存在運(yùn)行時(shí)錯(cuò)誤。隨著嵌入式軟件日益復(fù)雜，對(duì)所有操作條件進(jìn)行動(dòng)態(tài)測(cè)試已經(jīng)不太可能，這進(jìn)一步證明了Edsger Dijkstra的觀點(diǎn)：測(cè)試只能發(fā)現(xiàn)錯(cuò)誤，但不能證明錯(cuò)誤不存在。

　　一種新的驗(yàn)證方法稱為抽象解釋，它以靜態(tài)分析為基礎(chǔ)，使用形式化數(shù)學(xué)證明，可發(fā)現(xiàn)某些運(yùn)行時(shí)錯(cuò)誤或證明它們不存在。抽象解釋可直接應(yīng)用于源代碼，而無需執(zhí)行代碼。

　　抽象解釋和基于證明的驗(yàn)證方法作為一種基于證明的驗(yàn)證方法，通過在以下問題中將三個(gè)大整數(shù)相乘可對(duì)抽象解釋進(jìn)行說明：–4586×34985×2389=？

　　雖然手動(dòng)計(jì)算此問題的答案很費(fèi)時(shí)，但是我們可以應(yīng)用乘法法則確定答案的符號(hào)為負(fù)。確定此計(jì)算的符號(hào)就是抽象解釋的一種應(yīng)用。這種技巧使我們不需要對(duì)整數(shù)執(zhí)行完成的乘法計(jì)算就能夠準(zhǔn)確地知道最終結(jié)果的一些屬性，例如符號(hào)。利用乘法法則，我們還知道此計(jì)算的結(jié)果符號(hào)不可能為正。采用類似方式可將抽象解釋應(yīng)用到軟件符號(hào)學(xué)中，以證明軟件的某些屬性。不執(zhí)行程序本身，

　　通過驗(yàn)證源代碼的某些動(dòng)態(tài)屬性，抽象解釋在傳統(tǒng)靜態(tài)分析技術(shù)和動(dòng)態(tài)測(cè)試之間架起橋梁。抽象解釋在單個(gè)階段中調(diào)查程序的所有可能行為，即所有可能值的組合，以確定如何以及在何種條件下程序會(huì)產(chǎn)生某些類別的運(yùn)行時(shí)故障。由于抽象解釋與考慮中的操作相關(guān)，我們可以用數(shù)學(xué)方法證明該技術(shù)能預(yù)測(cè)正確的結(jié)果，因此它得出的結(jié)果被認(rèn)為是可靠的。

　　使用抽象解釋驗(yàn)證軟件

　　抽象檢查可用作靜態(tài)分析工具，檢測(cè)并用數(shù)學(xué)方法證明源代碼中不存在某些運(yùn)行時(shí)錯(cuò)誤，如溢出、除以零以及數(shù)組訪問超出邊界等。執(zhí)行此驗(yàn)證無需執(zhí)行程序、代碼插裝或測(cè)試用例。MathWorks Polyspace代碼驗(yàn)證產(chǎn)品使用的便是此類靜態(tài)分析。向Polyspace產(chǎn)品輸入C、C++或Ada源代碼。Polyspace產(chǎn)品首先檢查源代碼，以確定可能出現(xiàn)潛在運(yùn)行時(shí)錯(cuò)誤的位置。然后它會(huì)生成一份報(bào)告，該報(bào)告使用顏色編碼表示代碼中各元素的狀態(tài)，如圖1和表1所示。

圖1 Polyspace顏色編碼

表1：顏色編碼

　　標(biāo)為綠色的Polyspace結(jié)果表示代碼中不存在某些運(yùn)行時(shí)錯(cuò)誤。在檢測(cè)到運(yùn)行時(shí)錯(cuò)誤且代碼顯示為紅色、灰色或橙色的情況下，軟件開發(fā)人員和測(cè)試人員可使用驗(yàn)證流程中生成的信息修復(fù)發(fā)現(xiàn)的運(yùn)行時(shí)錯(cuò)誤。

　　結(jié)論

　　靜態(tài)分析融合抽象解釋后，可提高高集成系統(tǒng)中嵌入式軟件的質(zhì)量和可靠性。此方法能幫助工程師實(shí)現(xiàn)證明軟件中不存在某些運(yùn)行時(shí)錯(cuò)誤的目標(biāo)。具有抽象解釋的代碼驗(yàn)證解決方案有助于實(shí)現(xiàn)良好的質(zhì)量流程。這是強(qiáng)有力的驗(yàn)證流程，可幫助實(shí)現(xiàn)嵌入式設(shè)備的高集成性。