如今，汽車行業變革迅猛，汽車的設計、使用和銷售模式都在快速演變。駕駛員安全技術、交通擁堵、環境問題及汽車作為代步工具的基本前提都影響著新一代汽車的研發。為解決這些難題，很多汽車廠商都試圖強化計算能力以優化車輛控制。

　　歐盟新車安全評鑒協會（EuroNCAP）頒布的新標準規定，車道變換支持等安全輔助功能是獲得五星安全評級的必要條件。車載處理器的數量在所有細分市場都穩步上升，目前平均為40-50個，而一些高端車型則已經搭載近120個處理器。

　　據Semicast Research預測，到2022年，僅發動機引擎罩下的電子控制單元（ECU）組件就將達到近860億美元的市場規模，相較2015年的530億年復合增長率達到7%。半導體廠商將有機會在汽車電子領域挖掘一大桶金。

　　高科技芯片可以改善動力系統排放、增強安全性能、并利用蜂窩網絡實現車輛間及道路基礎設施之間的互聯。但是，隨著系統的復雜化，保證駕駛員安全就變得更為關鍵，必須打造更加自動化，系統化，且能患于未然的解決方案——即我們通常所稱的“功能安全”。

　　什么是功能安全

　　簡而言之，功能安全的最終目的是確保產品安全運行，即便出現問題也可以繼續保駕護航?；谶@一理念，ARM將保證安全視為頭等大事，而非單純依照市場導向隨波逐流，不斷加強研發，推出更多功能安全相關產品。

　　各行各業都會制定標準，指導未來發展并限定最低準入門檻。在汽車電子行業，這一標準就是ISO 26262，它將功能安全定義為：“避免因電氣／電子系統故障而導致的不合理風險”。

　　不同領域的標準并不完全一致，例如針對電氣和電子系統的IEC 61508以及飛行器電子硬件的DO-254都有各自的定義方式。更需值得注意的是，它們都擁有專用術語，并提供了包括目標參數在內的工程研發指導。因此，開始產品研發前確定目標市場并制定合適的流程至關重要，因為中途修改研發流程必然會導致效率低下。圖1展示了硅片IP的不同應用標準。實際操作中，如果需要滿足多套標準，則可以求同存異，先列出專屬需求，再執行質量管理等通用準則；最一開始就要做到安全第一。

　　圖1：硅片IP的功能安全標準

　　實際操作中，功能安全系統必須由獨立評估員認證，符合所有安全標準。實現功能安全需要具備預測能力的故障模式，實時判斷系統狀態是功能完整、部分功能損壞、還是系統必須關閉進行重啟或重置。

　　并不是所有故障都會立刻引發嚴重事故。比如，汽車動力轉向系統故障可能會導致突發性的錯誤轉向，但是由于電氣和機械設計天然的時間延遲，故障并不會馬上產生后果，這一延遲通常是幾毫秒以上，ISO 26262將之定義為容錯時間間隔，間隔長短取決于潛在的事故類型和系統設計。所以，不難理解，對系統安全要求越高，產生不安全事件的故障就越應該避免。

　　理想情況下，功能安全不會影響系統性能；但現實生活中，現行的許多安全措施都會嚴重影響系統性能、功率和面積（PPA）。如何在保證功能安全的前提下減輕對系統性能的不利影響以及設計制造成本的上升，是設計師們面臨的一大難題。

　　為什么需要功能安全

　　芯片IP的功能安全曾是非常小眾的領域，只有少數汽車、工業、航空航天和其他類似市場的芯片與系統開發商感興趣。然而，隨著過去幾年各類汽車應用的興起，情況已經發生巨大變化。除了汽車外，還有很多其他行業也能從電子器件的增加受益，當然保障功能安全是大前提。醫療電子和航空就是兩個典型例子。

　　自動駕駛過去幾年吸引了不少人的眼球，但一直是霧里看花；如今，隨著高級駕駛輔助系統（ADAS）及富媒體車載信息娛樂系統（IVI）的普及，盡管高度自動化駕駛的時代依然遙遠，但自動駕駛汽車的前景已變得愈發清晰，尺寸形狀各異的無人機和日益普及的物聯網也是亟需功能安全的領域，ARM 的技術將成為一大助力。

　　ARM功能安全技術

　　與其他技術市場一樣，新興的功能安全應用也需要半導體的驅動，這并不是紙上談兵，日新月異的產品創新已經引起了ARM合作伙伴的濃厚興趣。多數功能安全嵌入式系統都需要具備安全防護及實時處理兩大核心要素，ARM Cortex-R系列處理器為此需求量身定制，為嵌入式系統提供高性能運算解決方案，確保產品的高可靠性、高可用性、容錯、以及強大實時自主判斷能力。這些特性為實現ADAS和IVI系統的高安全完整性打下基礎，不僅可以執行關鍵行為處理，應對安全相關的中斷事件，與其他系統通訊，還可以對集成度較低的復雜功能進行監管。

　　什么是故障？

　　故障可能是系統性的（如規范制定和設計過程中的人為因素），也有可能與使用的工具有關。減少故障的一種方法是執行嚴苛的質量管控流程，必須包括詳細的規劃、審查和量化評估。合理的規劃使用工具認證非常重要，管理與追蹤需求變更的能力也同樣關鍵。ARM的Compiler 5編譯器已經通過南德集團（TüV SüD）認證，助力安全研發，客戶無需對編譯器進行額外認證。

　　還有一種故障類型被稱為隨機硬件故障。它們可能是圖2顯示的永久性故障，比如短路；也有可能是由于天然輻射而造成的軟性故障。這類故障可以利用集成在軟硬件的方案進行處理，因此系統級的技術也同樣重要。舉例來說，邏輯內建自測試（BIST）可以應用于系統啟動和關閉，區分軟性和永久性故障。

　　圖2：故障類型

　　應對措施

　　故障檢測和控制措施的選擇和設計是流程設計師最喜歡的環節，因為他們可以同時用系統級和微架構級的技術大展手腳。建立故障模式概念和效果分析（FMEA）是個不錯的開始，列舉出所有可能出現的故障模式及其后果的嚴重程度。有了這些信息，加上設計師對復雜系統的深入理解，即可鑒別出最嚴重的故障模式，并設計出應對措施。

　　應對潛在故障的方法較多，下面列出了一些最常用的技術：

　　1、多樣化檢查器：使用另一條電路檢查主電路是否發生故障。舉個例子，檢查器可以為中斷控制器計數，持續記錄人為及系統引起的中斷總數。

　　2、完整鎖步復制：該技術主要用于Cortex-R5處理器，對一個IP元件（如一個處理器）進行多次實例化，利用循環產生操作延遲，生成時間和空間冗余。大容量存儲通常由多個實例共享，以降低所需面積。盡管這一技術非?？煽?，但也極為昂貴。

　　3、選擇性硬件冗余：這個方案里，只有硬件的關鍵部分可以復制，如仲裁器。

　　4、軟件冗余：硬件冗余通常非常復雜，而且會產生間接成本，是對資源的不合理使用。硬件運算的替代方法就是，在多個處理器內核上運行同一次計算，檢查結果是否匹配。

　　5、錯誤檢測和校正碼是另一種為人熟知的技術，通常被用于保護存儲器和總線。代碼類型多種多樣，但目標只有一個，既通過少量附加位獲得更高冗余，無需復制所有底層數據。汽車系統中，這一尖端技術可以利用足夠多的冗余檢測出一個存儲字的2位錯誤；并支持錯誤修正。

　　故障日志

　　檢測出故障后就必須進行記錄，以幫助監管軟件判斷系統的健康和安全狀況。安全故障（如存儲器修正）和危險故障（如不能挽回的硬件故障）必須分別記錄。

　　故障記錄通常從故障計數開始，可以由系統級架構記錄有信號事件（類似于中斷）的數量；或者由IP計數器記錄。為了解這些事件發生的原因，最好還能將過去的事件作為參考，判斷當前時間的發生原因。為支持這一需求并進行調試糾錯，可以允許一些IP捕捉額外信息，如被偵查的存儲地址。因為該地址通常會由軟復位保存，所以可以在系統啟動和系統自檢過程中被讀取。

　　有一點需要牢記，故障也可能發生在安全架構本身。與硬件故障不同的地方是，后者通常可以在使用過程中被很快發現，但安全檢查器中的故障可能是潛伏的，它已經無法偵測危險故障，但故障卻已經悄悄地蔓延開了。這樣的故障被稱為潛伏故障，定期測試檢查器是個不錯的方法。

　　安全完整性等級

　　不同的標準體系反應安全等級的方法也各不相同，但其主要目的是直觀的反映功能的關鍵性。比如說，控制擋風玻璃雨刮、安全氣囊或制動器的ECU，完整性必須高于控制車速表或泊車傳感器的ECU，因為前方視野至關重要，突然剎車或氣囊充氣可能造成致命后果，駕駛員也會兇多吉少；而車速表或泊車傳感器對安全停車的重要性就低得多了。

　　換句話說，安全完整性等級是與人避免危險情況的必要性和能力相關的；而各項標準的作用就是指導人們如何定義安全完整性等級，并提供相關參數，幫助其對系統完整性進行量化。

　　IEC 61508將安全完整性等級（SIL）分成4級，第4級為最高完整性。與之相似，ISO 26262提出了汽車安全完整性等級（ASIL），最低為ASIL A，最高為ASIL D。此外，就表二所示，針對ASIL B到ASIL D，ISO 26262分別就單點故障、潛伏故障和硬件故障概率指標（PMHF，業內也稱及時故障）提出了建議參數?？蓹z測故障的比例被稱為診斷覆蓋率。