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

　操作應用于安全苛刻的航空和軍事領(lǐng)域的嵌入式軟件時(shí)必須高度關(guān)注安全問(wèn)題。為達到可靠性目標，軟件開(kāi)發(fā)團隊精益求精，力爭使這些軟件應用符合嚴格的驗證流程并實(shí)現零缺陷目標。Edsger Dijkstra有句名言：測試只能發(fā)現錯誤，但不能證明錯誤不存在。如果測試無(wú)法證明不存在嚴重的運行錯誤，那么嵌入式軟件開(kāi)發(fā)團隊如何才能確定其軟件沒(méi)有這些錯誤呢?基于數學(xué)證明的代碼驗證是值得一試的解決方案。在軟件驗證方面，可擴展的高性能數學(xué)技術(shù)在實(shí)際應用方面的最新發(fā)展十分有用，可實(shí)現對軟件中不存在運行時(shí)錯誤進(jìn)行證明。

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

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

　　軟件故障風(fēng)險

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

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

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

　　高集成軟件驗證

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

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

　　一種新的驗證方法稱(chēng)為抽象解釋?zhuān)造o態(tài)分析為基礎，使用形式化數學(xué)證明，可發(fā)現某些運行時(shí)錯誤或證明它們不存在。抽象解釋可直接應用于源代碼，而無(wú)需執行代碼。

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

　　雖然手動(dòng)計算此問(wèn)題的答案很費時(shí)，但是我們可以應用乘法法則確定答案的符號為負。確定此計算的符號就是抽象解釋的一種應用。這種技巧使我們不需要對整數執行完成的乘法計算就能夠準確地知道最終結果的一些屬性，例如符號。利用乘法法則，我們還知道此計算的結果符號不可能為正。采用類(lèi)似方式可將抽象解釋?xiě)玫杰浖枌W(xué)中，以證明軟件的某些屬性。不執行程序本身，

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

　　使用抽象解釋驗證軟件

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

　　圖1 Polyspace顏色編碼

　　表1：顏色編碼

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

　　結論

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