提高嵌入式軟件質量

　　航空領域的軟件應用

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

　　軟件故障風險

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

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

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

　　高集成軟件驗證

　　按照傳統方法，源代碼級軟件驗證涉及代碼檢查、靜態分析和動態測試。每種方法都有缺點。

　　代碼檢查僅依賴于檢察人員的專業技術，若有大量代碼需要檢查，則會是一項繁瑣的工作。傳統的靜態分析技術主要依靠模式匹配方法檢測不安全的代碼模式，但無法證明不存在運行時錯誤。隨著嵌入式軟件日益復雜，對所有操作條件進行動態測試已經不太可能，這進一步證明了Edsger Dijkstra的觀點：測試只能發現錯誤，但不能證明錯誤不存在。

　　一種新的驗證方法稱為抽象解釋，它以靜態分析為基礎，使用形式化數學證明，可發現某些運行時錯誤或證明它們不存在。抽象解釋可直接應用于源代碼，而無需執行代碼。

　　抽象解釋和基于證明的驗證方法作為一種基于證明的驗證方法，通過在以下問題中將三個大整數相乘可對抽象解釋進行說明：–4586×34985×2389=？

　　雖然手動計算此問題的答案很費時，但是我們可以應用乘法法則確定答案的符號為負。確定此計算的符號就是抽象解釋的一種應用。這種技巧使我們不需要對整數執行完成的乘法計算就能夠準確地知道最終結果的一些屬性，例如符號。利用乘法法則，我們還知道此計算的結果符號不可能為正。采用類似方式可將抽象解釋應用到軟件符號學中，以證明軟件的某些屬性。不執行程序本身，

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

　　使用抽象解釋驗證軟件

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

圖1 Polyspace顏色編碼

表1：顏色編碼

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

　　結論

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