【導讀】采用ARM處理器是越來越多的程序設計人員設計時需要的！范圍也遍及醫療、運輸、航空電子與工業領域。這也使得處理器所執行的軟件也受到更為嚴格的檢查，為什么呢？因為小錯誤就可能造就很嚴重的后果！那么該怎么好好的利用呢？
越來越多程序設計人員在設計安全相關應用程序時采用ARM處理器，范圍遍及醫療、運輸、航空電子與工業領域。因此，透過這些處理器所執行的軟件也受到更為嚴格的檢查，因為任何一個小錯誤都有可能導致嚴重后果。
為了避免導致這樣的后果，包括IEC 61508，還有最近才通過的汽車業ISO 26262等安全標準應運而生，以確保開發人員與客戶在軟件方面能符合業界最先進的最佳實務準則。
即便如此，要決定標準當中有哪些元素適用，哪些不適用，接下來還要確保整體設計符合標準，整個過程非常耗時以致于令人卻步。由于消費類器件的設計周期極短且逐漸與汽車安全系統整合，開發人員也因此面臨更大的時間壓力，必須在日益緊迫的設計周期期限前完成設計改動。
所幸針對軟件開發工具與相關作業，軟件系列工具廠商具備一般軟件開發人員所沒有的信息與知識，因此在市場中具有獨特定位，能為所有安全相關軟件開發人員提供支持。
對編譯器來說更是如此，因為編譯器能直接影響系統安全性，而且其有可能產生的注入錯誤，后續功能設計測試卻無法檢測。因此，系列軟件工具組很適合那些使用基于ARM核心處理器的開發人員，能使開發人員確保系統符合法規規范，并同時應付日益增加的產品上市時間的壓力。
ARM 處理器逐漸拓展應用
伴隨移動的風潮，加上持續擴展的生態系統提供支持，基于ARM核心處理器的應用已從智能手機與嵌入式等器件，拓展到基礎架構設備及數據服務器。現在，設計人員也逐漸開始將它們導入安全相關的應用。
這類應用涵蓋了工業（馬達控制、工廠自動化、遠距監控）；汽車（底盤控制、車身與安全、儀表板、智能傳感器、引擎控制、防抱死剎車）；醫療（注入泵、起搏器、病患監控）；鐵路（信號與通訊控制）；核能（控制面板、馬達控制、系統監控）與航空電子等領域。
圖 1 ： ARM處理器橫跨消費類與數據服務器應用領域，打入汽車電子、工業電子等各種產業，然而在這些領域當中，IEC 61508、ISO 26262等標準所規范的功能性安全需求，為微控制器軟件開發社群帶來了新的壓力。
整體而言，系統對智能功能的需求增加，帶動了ARM處理器為市場所廣泛采用，但這也要求業者必須具備整合能力與彈性以降低成本，提供更多功能，并隨時更新系統。與此同時，許多采用硬編碼邏輯來提供各種功能的設計，現在都逐漸整合到由軟件所控制的32位微控制器，從而又產生出新的問題。
設計重心逐漸移轉至微控制器與程序編碼功能，也同時將安全問題推向軟件領域，讓安全應用程序符合IEC 61508標準的責任，也因此落在軟件開發人員的肩上。這套標準原本規范的是電氣與／或電子系統的功能安全性，現在則同時涵蓋安全系統的電子組件。
圖 2 ： IEC 61508及相關產業專用標準，能協助安全相關的電氣、電子與可編程系統符合最新要求。
功能性安全能讓安全相關系統針對輸入做出正確響應，進而避免不必要的直接或間接風險以及損傷。
由于IEC 61508標準用語模糊，因此衍生出各種產業專用的標準，例如專供鐵路運輸使用的EN50126/8/9、醫療器件專用的IEC 60601、核能專用的IEC 60880，還有陸上交通工具專用的ISO 26262。 ISO 26262適用于3,500公斤以下量產客用車的安全相關系統，但不包括殘障專用等特殊用途車輛。
一般汽車里的微控制器往往多達150個，而隨著消費者導向的導航系統被整合到駕駛輔助、運動檢測系統、推進、車載動態控制與主動／被動安全系統時，汽車逐漸成為運算裝置涉足安全系統的一個研究案例。
[page]
安全系統開發人員所面臨的壓力與日俱增，汽車也成為典型案例。相較于過去動輒長達3到10年的產品生命周期，現在還得配合消費類裝置（12到18個月）的設計周期。
汽車里的150個微控制器都仰賴軟件程序運轉，有時甚至像編譯器這樣的基本組件也會造成系統故障，只因注入了不容易發現的錯誤，并在功能測試階段有可能無法檢測。
這會對系統持續造成風險，但只要符合IEC 61508標準，再加上ISO 26262，就能將風險降至可以容忍的程度。舉例來說，IEC 61508最佳實務準則建議一開始就要使用可以信賴的工具。
一般普遍認為編譯器是T3分類的離線支持工具，表示編譯器會直接或間接影響安全系統的可執行代碼，因此選擇編譯器“是有其正當性的”。[IEC 61508-3 Section 7.4.4.3]
我們可以藉由通過驗證且正在使用的實證，來展現工具的成熟度與穩定性，再加上來自業界專家的第三方評估以及廠商擔保，藉此證明選擇的正當性。
最佳實務準則還能加以延伸，用來驗證輸出以及語言子集的使用，像是MISRA C/C++。測試目標所使用的軟件自然重要，但要如何得知已經測試了每種可能發生的狀況？畢竟沒有執行的程序代碼就無法測試。這時就要利用代碼覆蓋率分析，來辨識尚未執行的程序代碼，進而確保整個應用程序均已測試完畢。分析代碼覆蓋率可利用源代碼插裝或跟蹤數據，因為串流跟蹤的影響程度最小。
至于語言子集，在許多案例當中，高階程序設計語言的定義不完整或模糊不清，造成不同編譯器的行為也有所不同。
“嚴格模式”，還有MISRA C/C++之類的語言子集，就是為了消除這些模棱兩可的狀況所設計，同時還能：確保使用的語言與標準語言一致；替未定義的行為設定規則；移除免工具使用選項；強制統一編碼式樣（例如：/*...*/ versus //）；改善可讀性；并縮小整體所需測試范圍。
ISO 26262比IEC 61508更進一步，提供的架構更講究細節，在這樣的架構下可考慮采用以其它技術為基礎所開發的安全系統。涵蓋范圍從產品周期管理到供貨商關系，但對于軟件開發人員來說，它提供了一種專為汽車設計、以風險為基礎的方法來評判完整性，而這套方法就稱為汽車安全完整性等級（Automotive Safety Integrity Levels; ASILs）。
使用ASILs明確定義ISO 26262的適用要求，以避免不合理的剩余風險，同時提供驗證需求與確認措施，以確保達到足夠且可接受的安全程度。
建議：遵守默認標準
好消息是，在ISO 26262公布后才開始的設計，并不一定要遵循其設計指南，才能成就“最先進”的設計準則并取得法律保護。不過聰明的業者會強制遵循其廣泛的標準，因為傳統上說這確實是一種好的做法也能確保一致性，同時還能降低成本，因為目前不包括在標準里的要求，很可能明天就會被列入，所以最好從一開始就加以制度化。
但要同時符合IEC 61508與ISO 26262，每個步驟都必須準備說明文件，從離線工具使用的合理性，一直到工具行為、手冊、危險分析、編譯器缺失報告、歷史版本、測試報告，還有實際及預期結果的差異報告，都只是其中少數幾個項目。
這樣的說明文件需要投入極大心力，花費時間且成本昂貴，這時軟件系列工具供貨商就能派上用場。他們是工具的專家。舉例來說，他們熟知編譯器如何運作、如何利用安全應用程序，也了解如何利用它來取得既定輸出并利于安全相關開發。
ARM Compiler系列軟件工具就是一個很好的使用案例，它最近取得了德國安全技術檢驗機構TüV SüD的認證。取得該認證后客戶便能將ARM Compiler建立工具應用在安全相關開發，最高可達安全完整性等級第三級(SIL3, IEC 61508)以及汽車SILD(ASILD, ISO 26262)，而無須進行其他合格驗證。還有ARM Compiler 規范套件可擴充TüV SüD驗證功能，其中包括安全手冊、缺失報告、測試報告與開發程序報告做為支持數據。
圖 3 ： 對于生產汽車應用程序可編程系統的業者來說，要符合IEC 61508與ISO 26262軟件功能安全要求，就必須提供大量說明文件與報告。
這樣的第三方認證與支持廠商保證，能即時節省人員工時、投入心力與相關成本，同時還能讓產品或設計更快上市，甚至可以保證應用程序設計還會繼續被市場所采用，因為在快速設計周期的時代，時間就是一切。
