上網時間 : 2006年06月01日
原本期望Therac255放射治療儀可以透過放射線殺死腫瘤來挽救生命，但其結果卻大為相反。這個裝置因為軟體缺失導致超過劑量的輻射而害死了三位病人，並對部份病人造成傷害；這個操控疏失的軟體是由一位程式設計師所撰寫，該程式碼從來沒有作過應有的檢查和測試。
Therac255只是在嵌入式系統研討會(ESC)中演講者們所引用的許多例子之一，這使人理解到一點：人的生命就和數百萬美元的投資一樣，通常取決於軟體工程，但是太多的計劃卻因為缺少良好的程式規劃和管理支援，最後宣告失敗。
而且，問題可能因程式設計師處理多核心裝置所帶來的其它挑戰而變得更糟。確實如此，一項由《EE Times》和《Embedded Systems Design》針對數千位嵌入式工程師所作的年度調查發現，隨著測試與除錯所花費的時間比專案開發中的任一個步驟還要多，這使更好的軟體除錯工具成為關注重點。
“這是目前僅存的一種明知產品有缺陷仍得以合法出貨的產業，但你認為那還能持續多久？”同時兼具顧問與作者身份的Jack Ganssle問道。Jack Ganssle在該會議上發表從嵌入式軟體造成的災難中所學習到的一課。
“我們並不恐懼軟體，但是我們必須抱著戒慎恐懼的心情，因為即使是在1億分之一的錯誤也能致人於死。”Ganssle說，他已開發過1百多個嵌入式方案，包括白宮的安全系統。
“隨著嵌入式系統越來越複雜，軟體也成為越來越重要的一環。目前，我們的DSP支出約有50%都在軟體上，”美商亞德諾(ADI)公司DSP部門總經理Gerald McGuire表示。該公司共有200多位軟體工程師。
儘管軟體重要性益增，但可靠性卻未隨之增加。依據一份報告顯示，由於超出預算、延遲、缺乏關鍵特色或其他各種因素，使得80%的軟體計劃失敗。另一項報告則顯示，超過百萬條程式碼的大型軟體系統錯誤多達20,000個，一年之後其中的1,800個錯誤仍未解決。“我們無法擺脫錯誤，”義大利易立信實驗室的資深嵌入式軟體設計專家Lorenzo Fasanelli說。但是工程師們還是能大聲舉出錯誤，從中學習並重寫程式以先行找出錯誤使之減到最少，他補充道。“不研究失敗，我們就無法提升技術發展水準，”系統架構師Kim Fowler說。他並在ESC會議上曾發表稱之為“不可思議的失敗”(Fantastic Failures )的演講。
戰爭故事
有許多可以從失敗中學習的例子。Ganssle引用另外一個於2001年5月在巴拿馬一系列測試中導致28個人死亡的放射線系統，美國食品藥物管制局後來便下令關閉製造該系統的公司。在美國軍用Chinook直升機墜毀之後，僅針對17%程式碼所作的軟體測試中就發現了500個錯誤，其中包括50個致命性的錯誤。
“為什麼只有在人死了以後才來檢查軟體？”Ganssle問道，他並指出關於直昇機墜毀的法庭案例仍在上訴中。
有些起搏器刺激心跳速率可以達每分鐘190次跳動，使得一些公司將軟體升級於傳送這種使用電容耦合的植入式裝置。不幸地是，其他使用起搏器的病人們在通過金屬檢測器時，卻不慎導致其裝置的程式被重新改寫。2003年，一個日本婦女的心臟起搏器便被家中的電鍋意外改寫程式。
軟體失靈也使電動門窗凍結在鎖定狀態下，一位泰國政治家被迫關在他那輛BMW 745i車內，最後不得不請來員警來打破車窗。福特也回收它的2000 Explorers部份車種，原因是車燈和雨刷在部份情況下無法運作。此外，2004 Poniac Grand Prix也因一個閏年的錯誤而面臨軟體回收之命運。其它還包括工程訓練不佳，例如，缺乏充份的測試、不當的錯誤操作，以及程式語言本身的不足。管理問題則包括在壓縮時間表中要求了更多的特性，預算緊縮也該承擔部份責任。
“我們必須預先測試每件事情，然後將測試整合到設計過程內。接著我們必須相信我們作測試時所取得資料，”Ganssle表示。
當工程師因為測試失敗而改變時，他們經常忽略到必須回到該測試的起點，以確保所做的改變不會引發一些新的錯誤，Dave Stewart表示；他是嵌入式研究解決方案 (Embedded Research Solutions)公司的CTO，在一場ESC會議中就即時軟體設計所面臨的首要問題提出看法。
工程師必須在其程式中建立處理錯誤的模式，而且這些模式必須以系統的另一個狀態共存，並且將錯誤視為許多可能的輸入之一來處理，Stewart補充道。
易立信的Fasanelli就如何在嵌入式軟體中發現、提出報告和使錯誤降到最低提出詳細的描述。程式設計師必須視其為一個標準措施，以對所有的輸入和一個系統的所有狀態進行分類，並且記錄任何不合法的輸入或者邊緣狀態，不管它們是否影響了程式的執行能力。
另外，程式應該例行地追蹤和彙報他們自己的性能，待機時間和記憶體整合情況。 建立這樣的除錯特性可能影響到系統的成本，但是那可以透過減少維修成本來抵消的，Fasanelli說。
圖4: 許多的錯誤都會使軟體方案遭致失敗。
“例外的處理特別難以測試，主要是因為難以產生例外，而這也是程式碼中最難以測試的部分，”Ganssle表示。
控制粗糙的C語言
諷刺地是，今天大多數流行的程式語言，C和C++最易於產生錯誤。那時因為C編譯器有許多的必須編譯和連接的程式碼都可能產生嚴重執行錯誤，特別是在轉用另一款新處理器時；但是這些C編譯器卻未提供任何診斷錯誤的工具。
“在C語言中有許多程式設計師無法完全了解小東西，”Dan Saks說，而他在ESC會議中發表演說時，便隨手找到了近40個，“由這個教訓中便是了解到我們所能設想到的，以及無法想像到的是什麼。”
例如，C語言不會以位元組來定義位元的數量，然而標頭檔則可詢問處理器，而且假如CPU不支援一般的8位元位元組時，也可以調整程式。同樣地，減法指示器的一般應用可能導致一個未定義型字元的產生，Saks & Associates顧問公司總裁Saks說。
“C語言的使用實際上是犯法的，”Ganssle說。“實際上，C語言將編譯一個電話號碼簿，我猜我們用C語言是因為我們認為除錯非常有趣。”
針對每1,000行的程式碼，C語言在最壞的情況下可產生500個錯誤，平均167個錯誤或12.5個自動產生的程式碼，Ganssle 說。相較於最壞的情況下有50個錯誤，採用Ada語言的平均是25個錯誤和4.8個自動產生的程式碼錯誤，他說。起源於歐洲的Spark語言甚至更好，每 1,000行程式碼中平均只產生4個錯誤，他宣稱。
依據‘2006年嵌入式市場調查’結果顯示，如今已開發完成的計劃中有二分之一是使用C語言。該調查並顯示C++程式語言的接受度正在增加中。
《Embedded Systems Design》總編輯Jim Turley在發表‘嵌入式市場調查’結果時指出，至少二分之一的受訪者表示C語言是其主要採用的程式語言。然而，從2005年的調查來看，支持C語言的人數下降了3%。相形之下，C++語言的支持人數在今年增加28%，受訪者並預測明年C++的採用率還會增加4%。
該調查顯示只有很少的工程師使用Java。Matlab、LabView和UML也常被使用在嵌入式方案中，儘管Java因為應用於許多系統的GUI介面部份而獲得更多的關注。
“幾乎每一種語言都不及C++，”Turley說，他指出許多設計團隊都曾評估Java，但是發現它缺乏效能和開發工具。
關於工具的選擇，53%的嵌入式工程師認為除錯的品質是他們在選擇開發工具時最重要的標準。只有大約13%的人認為，開放原始碼的內容是一個重要的選擇標準。
然而，當提到作業系統時，開放原始碼的作業系統，例如Linux正在贏得了重大的支持。至少20%的受訪者表示他們使用開放原始碼的作業系統，許多設計團隊則依賴Linux 的商業化版本。
Turley說，對於作業系統回應的一項解讀是，Linux正在快速獲得支持，因為“開放原始碼這個術語在五年前並不代表任何意義。”然而，與2005年的調查相較，從其他的調查問題卻顯示出越來越少的受訪者會考慮採用Linux，這也讓Turley總結道：“Linux的魅力已漸冷卻了。”
管理也必須依軟體的情況擔負部份的責任。“我們經常處於限制過多的情況之下，我們有太多的特性必須在很短的時間內完成，”Fowler在他‘不可思議的失敗’演講中說。“問題是，增添特性需要很多的回歸測試。重要的是詢問這個特性是否能保留到下一次的升級中，否則你便是讓你自己走向失敗。”
“作為工程師的我們需要透過過去相關的失敗案例，或者是具有長期性的表單、緊縮的預算和進度表，提出具有說服力的方法來警告管理階層，”他補充道。
工程師過度勞累是幾次太空災難發生的一項因素，他們在發射前數個月內每週工作時數長達60到80個小時，Ganssle說。
預算不足是另一個失敗的因素，土木工程的災難最為明顯。一個著名的例子發生於1940年，官員們發現了以先前一半的預算即可建造出一座 Tacoma Narrows橋的方法，但因此法建造的這座橋在啟用不過四個月的時間後，即在數次疾風過後而全面坍塌了。同樣地，位於拉斯維加斯的MGM大酒店，因未使用灑水裝置雖節省了20萬美元，但是卻在一場損失慘重的火災後支出逾2億美元的法庭訴訟費用與重建成本，Ganssle說。
就軟體方案範圍而言，“花費2千美元購置開發工具，卻可能在程式開發上節省10萬美元的開銷，”嵌入式研究解決方案公司的Stewart說。
致力於多核心
在ESC展會中的活動顯示，嵌入式軟體工具廠商要處理因多核心和多執行緒架構引起的問題越來越多。例如，Mentor Graphic公司和Green Hills軟體公司都說，他們對MIPS32 34K多執行緒處理器核心系列將提供更多的支援。Green Hills今年稍早曾宣佈支援TI的DaVinci平台，推出了支援MIPS32 34K的多項開發工具。Green Hills也強調該公司對單核心MIPS32 24KE系列的支援。
QNX軟體系統公司近日宣佈支援DaVinci平台，該平台乃是結合ARM和 DSP核心以支援數位視音視訊應用。為了協助性能最大化，QNX將支援基於TI DSP/BIOS連接技術核心之間的介面層。這使它有可能卸載對DSP的媒體處理，並釋出ARM核心作為其他方面的應用。
QNX行銷部門副總裁Dave Curley說，該公司去年秋天發佈了一個多核心的初始方案。採用該公司的Neutrino即時作業系統(RTOS)和Momentics IDE工具，這個初始方案支援不對稱多處理、對稱多處理的和限制多處理(BMP)。Curley說，後者的能力是唯一的，它可讓程式設計者為特定處理器分配執行緒。
“多核心的其中一個挑戰是要了解如何在多執行緒的處理器環境中運作，”Curley說。“有了BMP，你不用再重寫，即能把原有的程式碼和一個處理器聯結起來。”
QNX's多核心加速程式可提供針對QNX Neutrino多核心技術開發工具套件和英特爾Pentium多核心處理器的極限版本。
虛擬平台的供應商Virtutech公司也宣稱擁有Freescale半導體公司MPC8641D雙核心處理器的第一個模擬模型。Wind River正將這個模擬模型用於它的工程部門，以開發它自有產品的多核心版本。
“對於軟體開發者而言，多核心是一項全面性的革命，”Virtutech公司行銷部門副總裁Paul McLellan說，“你關斷一個核心的多次岔斷，但是另一個核心便會持續接著運作。”他解釋說，與實際的硬體不同處是，處理器還要花費一段時間才能關閉，而該Virtutech的Simics環境讓使用者可以停止整個系統。
ARM則指出其新推出的RealView 3.0開發工具套件增加了一個具有‘多核心DSP意識’的除錯引擎。ARM開發系統部門總經理Bryn Perry宣稱，ARM擁有支援DSP除錯的潛力。 Perry還說，ARM正在和DSP處理器供應商共同合作，但是仍沒有宣佈支援哪一款特定的數位訊號處理器。
迄今為止，RealView能連接ARM和DSP除錯器，並且使它們同步進行。但是一些客戶們只想在簡單的瀏覽整個系統的除錯，因此，ARM必須與DSP供應商結盟，Perry解釋道。
技術上來看，MIPS32 34K系列並不是一個多核心解決方案，但是它卻被宣傳為一款能提供多核心利益的多任務架構。Mentor Graphics日前宣佈，它的Nucleus RTOS和基於Eclipse的Edge工具套件目前也支援該系列產品。在34K裝置中，Nucleus Plus RTOS在兩個虛擬處理元件(VPE)中都可執行；第一個VPE上的Nucleus Plus對第二個進行初始化，並控制所有的週邊資源。
作者: 麥利
