1、運用arm處理器系列軟件工具可加速遵循安全至上的規范越來越多程序設計人員在設計平安相關應用程序時采納處理器，范圍遍及醫療、運送、航空與工業領域。因此，透過這些處理器所執行的軟件也受到更為嚴格的檢查，由于任何一個小錯誤都有可能導致嚴峻后果。為了避開導致這樣的后果，包括iec 61508，還有最近才通過的汽車業iso 26262等平安標準應運而生，以確保開發人員與客戶在軟件方面能符合業界最先進的最佳實務準則。即便如此，要打算標準當中有哪些元素適用，哪些不適用，接下來還要確保整體設計符合標準，囫圇過程十分耗時以致于令人卻步。因為消費類器件的設計周期極短且逐漸與汽車平安系統整合，開發人員也因此瀕臨更大

2、的時光壓力，必需在日益緊迫的設計周期期限前完成設計改動。所幸針對軟件開發工具與相關作業，軟件系列工具廠商具備普通軟件開發人員所沒有的信息與學問，因此在市場中具有獨特定位，能為全部平安相關軟件開發人員提供支持。對編譯器來說更是如此，由于編譯器能挺直影響系統平安性，而且其有可能產生的注入錯誤，后續功能設計測試卻無法檢測。因此，系列軟件工具組很適合那些用法基于arm核心處理器的開發人員，能使開發人員確保系統符合規矩規范，并同時對付日益增強的產品上市時光的壓力。arm 處理器逐漸拓展應用陪同移動的風潮，加上持續擴展的生態系統提供支持，基于arm核心處理器的應用已從智能手機與等器件，拓展到基礎架構設備及

3、數據服務器?，F在，設計人員也逐漸開頭將它們導入平安相關的應用。這類應用涵蓋了工業（馬達控制、工廠、遠距監控）；汽車（底盤控制、車身與平安、儀表板、智能、引擎控制、防抱死剎車）；醫療（注入泵、起搏器、病患監控）；鐵路（信號與通訊控制）；核能（控制面板、馬達控制、系統監控）與航空電子等領域。圖 1 ： arm處理器橫跨消費類與數據服務器應用領域，打入、工業電子等各種產業，然而在這些領域當中，iec 61508、iso 26262等標準所規范的功能性平安需求，為微控制器軟件開發社群帶來了新的壓力。整體而言，系統對智能功能的需求增強，帶動了arm處理器為市場所廣泛采納，但這也要求業者必需具備整合能力與

4、彈性以降低成本，提供更多功能，并隨時更新系統。與此同時，許多采納硬編碼規律來提供各種功能的設計，現在都逐漸整合到由軟件所控制的32位微控制器，從而又產生出新的問題。設計重心逐漸移轉至微控制器與程序編碼功能，也同時將平安問題推向軟件領域，讓平安應用程序符合iec 61508標準的責任，也因此落在軟件開發人員的肩上。這套標準原本規范的是電氣與或電子系統的功能平安性，現在則同時涵蓋平安系統的電子組件。圖 2 ： iec 61508及相關產業專用標準，能幫助平安相關的電氣、電子與可編程系統符合最新要求。功能性平安能讓平安相關系統針對輸入做出正確響應，進而避開不須要的挺直或間接風險以及損傷。因為iec

5、61508標準用語含糊，因此衍生出各種產業專用的標準，例如專供鐵路運送用法的en50126/8/9、醫療器件專用的iec 60601、核能專用的iec 60880，還有陸上交通工具專用的iso 26262。 iso 26262適用于3,500公斤以下量產客用車的平安相關系統，但不包括殘障專用等特別用途車輛。普通汽車里的微控制器往往多達150個，而隨著消費者導向的導航系統被整合到駕駛輔助、運動檢測系統、推動、車載動態控制與主動被動平安系統時，汽車逐漸成為運算裝置涉足平安系統的一個討論案例。平安系統開發人員所瀕臨的壓力與日俱增，汽車也成為典型案例。相較于過去動輒長達3到10年的產品生命周期，現在還

6、得協作消費類裝置（12到18個月）的設計周期。汽車里的150個微控制器都仰賴軟件程序運轉，有時甚至像編譯器這樣的基本組件也會造成系統故障，只因注入了不簡單發覺的錯誤，并在功能測試階段有可能無法檢測。這會對系統持續造成風險，但只要符合iec 61508標準，再加上iso 26262，就能將風險降至可以容忍的程度。舉例來說，iec 61508最佳實務準則建議一開頭就要用法可以信賴的工具。普通普遍認為編譯器是t3分類的離線支持工具，表示編譯器會挺直或間接影響平安系統的可執行代碼，因此挑選編譯器“是有其正值性的”。iec 61508-3 section 7.4.4.3我們可以藉由通過驗證且正在用法的實

7、證，來呈現工具的成熟度與穩定性，再加上來自業界專家的第三方評估以及廠商擔保，藉此證實挑選的正值性。最佳實務準則還能加以延長，用來驗證輸出以及語言子集的用法，像是misra c/c+。測試目標所用法的軟件自然重要，但要如何得知已經測試了每種可能發生的情況？究竟沒有執行的程序代碼就無法測試。這時就要利用代碼籠罩率分析，來辨識尚未執行的程序代碼，進而確保囫圇應用程序均已測試完畢。分析代碼籠罩率可利用源代碼插裝或跟蹤數據，由于串流跟蹤的影響程度最小。至于語言子集，在許多案例當中，高階程序設計語言的定義不完整或含糊不清，造成不同編譯器的行為也有所不同。“嚴格模式”，還有misra c/c+之類的語言子集

8、，就是為了消退這些模棱兩可的情況所設計，同時還能：確保用法的語言與標準語言全都；替未定義的行為設定規章；移除免工具用法選項；強制統一編碼式樣（例如：/*.*/ versus /）；充實可讀性；并縮小整體所需測試范圍。iso 26262比iec 61508更進一步，提供的架構更考究詳情，在這樣的架構下可考慮采納以其它技術為基礎所開發的平安系統。涵蓋范圍從產品周期管理到供貨商關系，但對于軟件開發人員來說，它提供了一種專為汽車設計、以風險為基礎的辦法來評判完整性，而這套辦法就稱為汽車平安完整性等級（automotive safety integrity levels; asils）。用法asils明

9、確定義iso 26262的適用要求，以避開不合理的剩余風險，同時提供驗證需求與確認措施，以確保達到足夠且可接受的平安程度。建議：遵守默認標準好消息是，在iso 26262公布后才開頭的設計，并不一定要遵循其設計指南，才干成就“最先進”的設計準則并取得法律庇護。不過聰慧的業者會強制遵循其廣泛的標準，由于傳統上說這的確是一種好的做法也能確保全都性，同時還能降低成本，由于目前不包括在標準里的要求，很可能明天就會被列入，所以最好從一開頭就加以制度化。但要同時符合iec 61508與iso 26262，每個步驟都必需預備解釋文件，從離線工具用法的合理性，向來到工具行為、手冊、危急分析、編譯器缺失報告、歷

10、史版本、測試報告，還有實際及預期結果的差異報告，都只是其中少數幾個項目。這樣的解釋文件需要投入極大心力，花費時光且成本昂貴，這時軟件系列工具供貨商就能派上用場。他們是工具的專家。舉例來說，他們熟知編譯器如何運作、如何利用平安應用程序，也了解如何利用它來取得既定輸出并利于平安相關開發。arm compiler系列軟件工具就是一個很好的用法案例，它最近取得了德國平安技術檢驗機構tüv süd的認證。取得該認證后客戶便能將arm compiler建立工具應用在平安相關開發，最高可達平安完整性等級第三級(sil3, iec 61508)以及汽車sild(asild, iso 26262)，而無須舉行其他合格驗證。還有arm compiler 規范套件可擴充tüv süd驗證功能，其中包括平安手冊、缺失報告、測試報告與開發程序報告做為支持數據。圖 3 ： 對于生產汽車應用程