隨著自動駕駛技術的發展，在保證高安全性的同時，也需要滿足高可用性的需求，這對功能安全設計提出了更高的要求。預期功能安全和信息安全作為“安全” 的重要部分，提升了車輛的整體安全性。如何將預期功能安全、信息安全、功能安全三者融合，并在芯片層級助力其實現，也是未來需要思考和解決的問題。

1.    汽車電子功能安全標準簡介

隨著汽車中電子器件占比的不斷提升，由于電子器件失效而造成危害的概率也在不斷上升。通過遵循一定的設計開發流程，同時在原有功能設計中加入保證安全性的額外功能，已成為業內普遍采用的方式，從而有效降低風險發生的概率，保證人員安全。以上方法的目的是保證“預期功能”的安全性，將風險降低到可接受的范圍內，也即本文中討論的“功能安全”的概念。

功能安全要求由來已久，在汽車電子行業開始重視功能安全設計的同時，它在工業控制、航空航天以及鐵路軌道交通等領域也在普遍被采用。下圖總結了不同行業中功能安全相關標準的基本信息和要求。

圖1 不同行業中功能安全相關標準的基本信息

汽車電子行業中普遍使用的功能安全標準ISO 26262是基于工業行業功能安全標準IEC 61508演化而來，其更加適用于汽車行業實際情況。ISO 26262標準目前主要包含兩個版本：ISO 26262:2011版和ISO 26262:2018版，其中ISO 26262:2018版是在ISO 26262:2011版基礎上修訂的版本，較2011版在原有基礎上增加了半導體功能安全章節和摩托車功能安全相關章節，同時修訂了2011版中部分內容，使得標準內容更加明晰。此外，我國也發布了道路車輛功能安全國家標準GB/T 34590，第一版國標于2017年發布，第二版功能安全國標目前正在審批中，預計近期即可正式發布。

無論是功能安全國際標準還是國家標準，其均為非強制標準。但是隨著功能安全概念和要求的不斷普及和深入，從行業范疇看其已經成為一定意義上的“強制”標準和準入門檻了。

2.    汽車電子功能安全開發要求

根據ISO 262626:2018的要求，汽車電子功能安全開發需要遵循以下V模型進行開發和驗證。在V模型的左側側重于設計開發要求，而V模型的右側側重于驗證與確認。ISO 26262:2018標準概覽如下圖所示。

圖2 ISO 26262:2018標準概覽

依照ISO 262626:2018的要求，汽車電子功能安全主要針對系統性失效和隨機硬件失效進行避免或控制。對于系統性失效，通常通過遵循一定的開發流程來避免，典型的示例如軟件開發過程中遵循A-SPICE或者CMMI流程進行開發。對于隨機硬件失效，則是依靠設計安全架構來對其進行探測和控制的，典型示例如通過冗余設計保證高安全性。

圖3 失效的分類和避免/控制方法

按照功能安全標準中的要求，對于系統性失效，通常沒有定量的指標去衡量；而對于隨機硬件失效，則需要按照以下表格同時滿足三個指標的要求。

表1 硬件隨機失效度量指標要求

對于功能安全設計的正確性和完整性，需要進行驗證和確認，二者的目的和執行層級通常會有所不同。

驗證（verification）的目的是確定檢查對象是否滿足其特定要求，典型的驗證活動可以分為以下幾類：

-     驗證評審，走查，檢查；

-     驗證測試；

-     仿真模擬；

-     原型樣機；及

-     分析（安全分析、控制流分析、數據流分析等）。

確認（validation）的目的是基于檢查和測試，確保安全目標是充分的，并已達到且具有足夠的完整性等級。

需要注意的是，與傳統質量體系不同的是，功能安全本身更強調技術層面的要求。雖然為了控制系統性失效，功能安全整體要求中規定了對于流程體系的要求，并且其中很多規定是與ISO 9000以及IATF 16949質量體系中的要求基本一致，但功能安全更加突出了對于隨機硬件失效的探測和處理要求，這就需要從技術和設計層面加以重點考慮，這也是功能安全與質量體系之間較為突出的區別。

總體來看，如果想要達成功能安全的要求，不僅需要搭建和落地相應流程體系，還需要從技術層面上（包括硬件方面和軟件方面）進行功能安全設計，最終滿足定性和定量兩個角度的要求。

3.    汽車電子功能安全開發概覽

汽車電子功能安全開發的最終目的是保證由于E/E系統失效造成整車級別危害的概率降低到可接受的范圍內，因此無論是在整車級別設計功能安全，還是在控制器ECU層級以及在芯片層級設計功能安全，其均是為了達成前述目標。

從整車、控制器至芯片層級的需求和技術開發路徑抽象概括如下圖所示。

圖4 概念安全需求和技術開發路徑抽象圖示

整車層級功能安全開發活動對應于ISO 262626:2018標準Part 3概念階段內容，整車廠通過HARA分析等一系列手段確定相關項（Item）的安全目標（Safety Goal），并進一步分解為功能安全需求（Functional Safety Requirement）下發給零部件供應商。

零部件供應商在獲取的安全目標和/或功能安全需求的基礎上將開展系統開發以及硬件/軟件開發，對應于ISO 262626:2018標準Part 4系統階段、Part 5硬件階段和Part 6軟件階段開發活動。這個階段是零部件供應商能力和經驗的體現，也是設計的核心。雖然獲取的上層功能安全需求一致，但是受限于能力區別，不同的零部件供應商的實現方案通常會有不小的差別，這也造成了產品成本和技術指標的不同。隨著控制器復雜度的不斷提升，其對芯片的依賴程度也在逐步增加，想要設計一個符合特定功能安全等級要求的系統，所使用的核心芯片（如微控制器芯片）就需要首先符合分配的安全等級，否則對控制器的開發會帶來巨大的額外工作量。在這種情況下，零部件供應商在選擇系統中使用的核心復雜芯片時，為了節省自身工作量，通常第一選擇是符合安全等級要求的芯片（ISO-Compliant），這樣也造成了芯片供應商對自身芯片產品功能安全要求的不斷提升。

對于芯片供應商而言，除了要設計滿足高性能且可靠的芯片外，還需要使其滿足功能安全的要求。雖然這部分不是法規的要求，但是目前來看已經成為部分類型車規芯片“上車”的一個門檻了。作為車規芯片功能安全開發的起始，安全需求的定義至關重要。芯片供應商為了使其研發的芯片在更廣闊的市場和應用中被采用，芯片產品通?；赟EooC（Safety Element out of Context）的方式進行開發，芯片頂層安全需要來自不同目標應用對于芯片安全需求的集合與抽象總結。雖然可能無法完美匹配某一應用的要求，但是其更好的適配了多種應用的多數通用需求，具備了更好的應用前景和潛在用量。

在假設了芯片頂層安全需求后，需要將需求進一步細化和分解，并伴隨芯片開發不同階段進行需求實現和驗證。下圖是芯片開發過程中采用的一種需求分解細化推導示例（不同類型芯片以及不同設計者會有不同方法，也存在不同的需求命名方法，此處僅作為參考示例）。

圖5 芯片層級功能安全需求逐級推導示例

從上圖可以看出，與控制器ECU相比，芯片本身其實一個更加復雜，集成度更高的系統，因此上圖所示分析方法其實是將功能安全標準的不同階段與芯片開發階段進行了對應與融合。作為組成芯片系統的關鍵單元，IP的功能安全設計尤為重要，是芯片功能安全設計中需要重點攻關的工作內容。

在芯片層級功能安全開發中，除了硬件部分以外，底層軟件功能安全開發也是必須要考慮的活動。以微控制器芯片為例，涉及到的底層軟件包含（但不限于）固件程序，MCAL以及安全庫（如有），這些軟件組件的安全等級通常與芯片假設的安全等級對應。由于這些軟件組件與芯片設計緊密相關，所以通常是由芯片供應商來提供給用戶，進而降低用戶使用芯片的工作量，提升芯片易用性。

4.    高性能微控制器芯片（MCU）實例

基于汽車電子不同應用的需求，紫光芯能推出了滿足ASIL D等級要求的THA6系列高性能微控制器芯片。

在功能安全開發過程中，芯片基于SEooC方式進行開發，從安全需求定義、安全架構和安全機制設計、定性/定量安全分析、功能安全驗證/確認等不同階段和角度保證了功能安全得到有效實施。在安全機制設計過程中，設計人員充分考慮了安全性和用戶易用性的要求，并且盡可能的提升芯片的可用性，使其更符合汽車電子的獨特要求。

目前此系列芯片已經通過了第三方認證機構功能安全流程體系認證和功能安全產品認證。

5.    結論與展望

隨著汽車電子系統功能安全要求的不斷提升，在滿足可靠性的同時，對安全性的需求也在不斷加強，其中符合功能安全要求已經成為了很多車規產品“必需”的屬性，尤其對于車規芯片產品。汽車電子復雜度的提升也帶來了對于芯片的更高要求，如何設計生產出高安全性車規芯片是亟需解決的問題，這就需要對技術難關進行攻克，并不斷總結和積累經驗。

此外，隨著自動駕駛技術的發展，在保證高安全性的同時，也需要滿足高可用性的需求，這對功能安全設計提出了更高的要求。預期功能安全和信息安全作為“安全” 的重要部分，提升了車輛的整體安全性。如何將預期功能安全、信息安全、功能安全三者融合，并在芯片層級助力其實現，也是未來需要思考和解決的問題。