EPB功能安全筆記(20) 尾聲：ISO26262的總結和展望

駕駛哥

2021年4月23日 09:36

瀏覽：3003 評論：1 收藏：2

知圈 | 進“汽車智能交互社群”請加微信13636581676，備注交互

抱著“為ISO 26262及功能安全的初學者提供有價值參考”的初衷，《EPB系統功能安全筆記》系列文章來到了尾聲。

受限于筆者的個人水平，初衷達到幾何尚未可知，但是可以肯定兩點：一是在更新這個系列文章的過程中，筆者在系統梳理對功能安全理解的同時也獲得了不少新的認知；二是雖然在更新過程中盡可能嚴謹，但文章中不可避免地有值得討論甚至是錯誤之處，還請有經驗的讀者諒解并甄別。

作為《EPB系統功能安全筆記》的收官，本文的目標是站在ISO 26262的全局視角對功能安全開發過程中的關鍵點做出串聯和總結；與此同時，在智能駕駛迅猛發展、E/E系統架構快速迭代的今天，本文站在安全的角度指出ISO 26262在這一潮流中的局限并做出展望。

需要提前指出，功能安全開發活動是貫穿整個產品安全生命周期的（管理、開發、生產、運行、服務、報廢），重點包括開發過程(包括需求規范、設計、實現、集成、驗證、確認和配置)、生產過程、服務過程和管理過程的，而 系列文章只聚焦于開發過程 ，因為本文的梳理也僅圍繞開發過程展開。

Part 1: ISO 26262總結

1.1.功能安全的目標

ISO 26262中對“Functional Safety, 功能安全”的定義如下。

absence of unreasonable risk due to hazards caused by malfunctioning behavior of E/E systems.（不存在由電子電氣系統的功能異常表現引起的危害而導致不合理的風險）

針對這一定義需要進行一些補充方能獲得更清晰的認識。

首先，對于定義中提到的“危害（hazard）”和“風險（risk）”，可以讓人聯想到很多理解，比如車禍造成人員受傷、造成維修財產損失、車主隱私泄露等等。功能安全里中將這兩個詞和“傷害（harm）”想關聯，并給出了解釋：

Harm: Physical injury or damage to the health of persons. （傷害：對人身健康的物理損害或破壞）

可見功能安全所期望避免的危害是指對駕駛員或者路人或周邊車輛內人員（注意：不僅僅是駕駛員）造成的健康傷害。

其次，汽車是集成了機械、液壓、化學、E/E等眾多系統于一身的復雜產品，每個系統的故障都會威脅到駕駛員或周邊車輛內人員的人身安全。比如化學電池自燃、制動管路泄露導致制動力丟失、碰撞時A柱剛性強度不達標、轉向控制系統失效導致方向盤鎖死等等。但這些并不全在功能安全的考慮范圍內。功能安全的研究對象只有“E/E system（電子電器系統）”。從這個角度，產品或者車輛滿足了功能安全的要求，僅代表車輛實現了E/E系統的安全，還需要其他系統滿足相應的安全設計才能全方位地提高汽車的安全。

換個角度看，車輛實現了E/E系統的功能安全，是不是可以說E/E系統100%沒有安全風險了呢？定義中“unreasonable，不合理的”一詞給出了對這個問題的否定的回答。

就像世界上沒有永動機一樣，世界上也沒有100%安全的系統，功能安全追求的是將風險控制在合理的范圍內，或者說可被接受的范圍內。如下圖所示。

功能安全開發的目標（截圖來自TUV培訓資料）

1.2.量化功能安全的目標

既然功能安全追求的是將風險控制在合理的范圍內，那么必須首先對界定“合理性”給出量化的指標才能指導功能安全開發。量化功能安全的目標本質上分為兩步：

確定不合理的風險
定義將不合理的風險降低為合理風險的標準

1.2.1.確定不合理的風險

對于如何確定不合理的風險，在EPB功能安全筆記(1)：危害分析與風險評估(理論篇)中給出了詳細的說明。簡單來說分為兩步：

step1: 確定相關項所有功能異常所有行為可能導致的整車危害

在這一過程中需要注意：應以能在整車層面觀察到的條件或行為來定義危害。那么既然是以整車層面觀察到的行為來定義危害，首先需要了解車輛所有可能的運動行為。從整車動力學的角度，汽車所有的運動行為可以通過下圖中的運動坐標系來準確描述。

車輛運動坐標系

而在每一個坐標系上，因為控制不當而可能產生的所有的整車表現也能被界定。思路如下圖所示。

step2: 結合危害和場危害發生時刻車輛運行的場景來分析風險。

這一步驟對應“危害事件分類（Classification of hazardous events）”

舉例來說，EPB系統（電子駐車系統，Electric Parking Brake）和制動相關，存在一個危害：卡鉗錯誤拉起導致車輛產生非預期的制動。如果這個危害發生在高速公路上時，很可能造成人員傷亡；但是如果危害僅僅發生在車速低于10kph的停車場，則不會有造成人員傷亡的風險。

從這個角度，功能安全需要結合危害和危害發生時刻車輛運行的場景來綜合分析危害所導致的風險是否在可接受的范圍內。車輛的運行場景，可以理解為是下圖各個因素的排列組合。簡單來說，運行場景 = 道路場景 + 駕駛場景，比如“高速公路+直行加速”或者“高速公路+直線制動”等。

車輛運行場景

當列出了相關項的所有場景與危害的組合后，接下來就是對其進行分類和篩選，確定哪些風險是可接受的，哪些是不可接受的。ISO 26262從三個維度來進行分類和篩選：

1.S（severity 嚴重度）： 危害發生對駕駛員或乘客或路人或周邊車輛中人員會造成的傷害等級。

2.E（Exposure 曝光度）： 運行場景在日常駕駛過程中發生的概率。

3.C（controllability 可控度）： 駕駛員或其他涉險人員控制危害以避免傷害的概率。

通過這三個維度的綜合評分確定汽車安全完整性等級（ ASIL, automotive safety integrity level），如下圖所示。ASIL D代表最高嚴格等級，ASIL A 代表最低嚴格等級。QM（quality management）則意味著只要按照企業流程開發就可以滿足ISO 26262要求，無其他特殊要求。

1.2.2.定義將不合理的風險降低為合理風險的標準

ISO 26262要求，應為具有ASIL等級的每個危害事件確定一個安全目標。

比如對于以下危害事件：

整車危害	場景	可能發生的風險
車輛非預期減速	兩輛車運行在同一車道且速度相近	前車非預期減速，后車制動不及，追尾
S值	E值	C值	ASIL等級
碰撞速度超過40kph時，駕駛員有危及生命的危害 S3	場景發生概率與兩車車距有關，能造成碰撞危害的場景暴露度中等 E3	駕駛員不可控 C3	C

我們可以定義一條安全目標：

EPB應避免錯誤建壓而造成過高的減速度 → ASIL C

但是除了ASIL等級以外，安全目標還有其他屬性，包括FTTI、safe state等。在EPB功能安全筆記(3)：如何定義一條完整的Safety Goal？中以案例的形式對如何確定安全目標的屬性給出了具體的說明，確定這些屬性的過程就是確定安全標準safety criteria的過程，而這個安全標準即為界定“合理性”的量化指標。

1.3.將安全目標轉化成軟硬件開發需求

安全目標作為最高層級（整車層）的功能安全需求，它實際上是概念層的產物，因為安全目標是在不需要知道相關項系統架構的情況下被完整定義出來的，而最終安全目標的實現是需要依賴于系統架構以及架構中的要素（如軟件、硬件）的。換句話說，要想實現安全目標，就必須結合系統架構將安全目標細化為更具體的功能安全需求并分配給系統架構中的要素（軟件和硬件等），這一活動對應功能安全概念開發（Functional Safety Concept Development）和技術安全概念開發（Technical Safety Concept Development），最終得到軟/硬件功能安全需求。

在《EPB功能安全筆記(7)——EPB safety concept分析示例》中對這一過程進行了詳細的示例說明。

功能安全開發鳥瞰

另外，在對系統中的要素分配功能安全需求的過程中，經常會遇到以下類似的情況：

對某個要素的功能安全需求的ASIL等級為ASIL D或者ASIL C，而實際只能達到ASIL A或者ASIL B

ISO 26262開了個“后門”來合理地避免這類偏差影響功能安全開發，這個“后門”就是ASIL分解。ASIL分解是降低對功能安全需求的ASIL等級的裁剪方法，這一方法的核心點是通過將一條功能安全需求分解成兩條相互獨立的需求并分配到兩個及兩個以上相互獨立的元素（如軟件模塊、硬件模塊、輸入信號等）上。正是由于這些參與分解的獨立的元素之間構成了互為冗余關系，從整個系統的角度看，只有當這些元素同時發生失效時才會違背安全目標，這樣一來對每個參與分解的相關元素的功能安全要求可以降低。

在《EPB功能安全筆記(16)——ASIL分解及其關鍵點》中對分解的要點進行了說明。

當軟、硬件功能安全需求確認后，接下來就遵循“V模型”進行需求開發和驗證，ISO 26262對軟、硬件開發的功能安全要求體現在了“V模型”的各個環節，總的來說ASIL等級越高，各個環節的功能安全要求越高。

功能安全開發與“V模型”

1.4.安全分析

前面提到，ISO 26262的目標是將E/E系統的功能異常表現引起的危害而導致不合理的風險降低到合理的范圍之內，而E/E系統是由最基本的要素即軟件和硬件組成的，E/E系統的功能異常必然是由軟件和硬件的異常引起的。

另一方面，當E/E系統的功能安全的目標轉換成軟件和硬件的安全需求后，將系統的不合理的風險降低到合理的范圍內，就意味著需要將軟件和硬件的異常（失效）控制在合理的范圍內才算滿足了相應的安全需求。

系統與組成元素

軟件和硬件的所有失效可以歸為兩類：

隨機硬件失效(random hardware failure)：在硬件要素的生命周期中，非預期發生并服從概率分布的失效。

系統性失效（systematicfailure）：以確定的方式與某個原因相關的失效，只有對設計或生產流程、操作規程、文檔或其他相關因素進行變更后才可能排除這種失效。（如軟件bug，硬件開發手冊）

根據上面對兩類失效的定義，可以得出軟件和硬件相對應的失效特點下：

軟件：只有系統性失效
硬件：既存在系統性失效，又存在隨機硬件失效

軟/硬件功能安全需求中的ASIL等級的的不同本質上是對要素避免系統性失效和隨機硬件失效的要求的嚴苛程度不同。而協助和證明軟硬件避免失效的能力達到了安全需求需要借助安全分析。

簡單來說，安全分析的目的就是借助分析方法去實現以下三點目標從而證明產品符合ISO 26262的要求：

失效被完整地識別
系統性失效被有效地規避
隨機失效被控制在了可接受的范圍內

ISO 26262推薦的分析系統性失效的方法為FMEA (Failure Mode and Effects Analysis)，在《EPB功能安全筆記(8)——FMEA方法論介紹》和《EPB功能安全筆記(9)——FMEA方法論的拓展——FMEA-MSR》中對FMEA進行了全方位的說明。

而ISO 26262對隨機硬件失效分析推薦的方法為FTA (Fault Analysis Tree) 。對于電子元器件的失效率而言，業界有統一的設計規范和衡量指標，所以在對電子電器產品而言，FTA的優勢明顯，不僅可以進行定性分析，還能進行定量分析。這也是ISO 26262推薦FTA的重要原因。由于隨機硬件失效的相關內容不易理解，因此系列中用了5篇文章對這一部分進行說明，詳細內容請參考 EPB功能安全筆記(10) —— EPB功能安全筆記(15)。

1.5.功能安全驗證和確認

根據“V模型”開發流程，軟/硬件需求實現以后，需要進行驗證，這一過程被稱為功能安全驗證（safety verification）和功能安全確認（safety validation）。

verification和validation的釋義十分接近，功能安全國標GB/ T 34590中將這兩個詞分別翻譯成“驗證”和“確認”，實際上單看這兩個詞還是會讓讀者產生含義重合的印象。

維基百科上對這兩個詞的解釋非常到位：

Verification：Have we made what we were trying to make? （預期的事情有沒有實現？）
Validation: Are we trying to make the right thing? （做的事情是否正確？）

沿著這個思路理解功能按照開發中的概念，可以得到如下解釋：

Safety verification：驗證功能安全需求有沒有被實現？
Safety validation: 確認功能安全需求提的對不對？即功能安全需求實現了是否確實能保證安全？

根據這樣的解釋可以發現功能安全驗證（safety verification）和功能安全確認（safety validation）屬于兩個維度。

關于系統/硬件/軟件三個層級的功能安全需求如何進行安全驗證（safety verification）分別記錄在標準中的第4/5/6部分。而安全確認的目的概括為：

提供符合安全目標的證據及功能安全概念適合相關項的功能安全的證據。
提供安全目標在整車層面上是正確的、完整的并得到完全實現的證據。

由此可以看出安全確認中的“確認”在于確認安全目標及安全目標對應的安全標準(safety criteria)是否被滿足。

在《EPB功能安全筆記(18)——功能安全驗證和確認》中對功能安全驗證和確認的關鍵點進行了詳細說明。

1.6.功能安全評估

當一切功能安全開發活動完成后，在正式量產之前，需要對開發產物進行審核，審核通過后方能釋放產品。“ISO 26262，part2，功能安全管理”中詳細介紹了功能安全的審核流程和要求，對應的術語為“認可措施，Confirmation measures”。

安全管理流程圖，截圖來自ISO 26262-2018, part2

Confirmation measures的主要目的是對功能安全開發過程及產物進行評估，以確認是否滿足ISO 26262的要求。而這一評估需要從三個維度來展開，如下圖所示。

這三個維度的對象及目的如下：

Key points	Confirmation review	Functional safety audit	Functional safety assessment
待確認的對象	功能安全開發過程中的關鍵輸出物(如H&R,safety plan, safety concept, safety case等)	功能安全所需流程的實施情況	相關項（即進行功能安全開發的產品）
確認的目的	審查是否已經充分且可信地實現了按照輸出物在ISO 26262中對應章節的目的和要求	審查實施功能安全開發的過程是否滿足流程要求（如safety plan是否創建并跟上項目節點）	審查相關項定義的安全措施是否完整地被實現了；審查安全措施是否合理且有效

在《《EPB功能安全筆記(19)——功能安全的認可措施（Confirmation Measures）理解與辨析》中對以上三個維度的措施進行辨析和說明。

Part2: ISO 26262展望

站在2021年看智能駕駛，無疑是一片琳瑯滿目的壯觀景象：層出不窮的黑科技：超大的顯示屏娛樂功能強大，智能座艙高度數字化， OTA遠程升級幾乎是新車型標配，ADAS輔助駕駛功能也越來越豐富和實用。至于智能駕駛的終極目標——自動駕駛，在市場的狂熱逐漸退燒后，各大廠家重新制定了自動駕駛計劃。智能汽車正在朝著便利和解放駕駛員的方向上狂奔。

但是，除了給駕駛員帶來便利以外，智能汽車更核心的愿景是減少交通事故，為人類創造更美好的生活。如果解放了駕駛員的同時卻不能保證駕駛員的安全，個人認為智能汽車上的黑科技更多的是錦上添花，而沒有大規模推廣的意義。

而支撐這些智能駕駛技術的是全新的E/E系統及組成E/E系統的軟件和硬件。從這個角度，致力于避免E/E系統失效而造成不可接受的風險的功能安全就顯得更加重要。

但是，實現了功能安全的E/E系統就足夠安全嗎？

我們不妨先來看兩個召回的案例。

1.7.案例1

2020年3月19日，由于自動緊急制動系統（Autonomous Emergency Braking, AEB）存在故障，沃爾沃汽車宣布在全球范圍內召回汽車近74萬輛，共涉及9款在售車型。此次召回的原因，是因為一些場景下無法有效識別物體，導致AEB在該工作的時候不工作。一般AEB探測物體依賴傳感器毫米波雷達和攝像頭兩個關鍵傳感器的信息融合。因為多普勒效應，毫米波雷達不擅長識別靜態物體；而攝像頭在霧天或者光線不足等情況下探測度都會降低，這些因素都會導致在一些場景下無法正確識別物體從而激活AEB。

因此，這次召回不是因為系統故障導致的，而是傳感器本身的功能局限導致的，不屬于ISO 26262的范疇。為彌補功能安全的局限，預期功能安全SOTIF (Safety of the Intended Functionality)以及標準ISO 21448便誕生了。

簡單來說，SOTIF強調的是避免因為預期的功能表現局限而導致不合理的風險。

因為SOTIF誕生的背景是智能駕駛的發展，所以如果按照智能駕駛的功能鏈：感知——決策——執行來歸類，“功能表現局限”體現在3個方面：

1.傳感器感知局限導致場景識別錯誤

2.深度學習不夠導致決策算法判斷場景錯誤

3.執行器功能局限導致與理想目標偏差

目前SOTIF的標準ISO 21448已經發布了draft版本，按照計劃在2022年3月正式發布。

1.8.案例2

2015年7月，兩名美國白帽黑客成功侵入一輛正在行駛的JEEP自由光SUV的CAN總線網絡系統，向發動機、變速箱、制動、轉向等系統發送錯誤指令，最終使這輛車開翻到馬路邊的斜坡下。這起案件導致吉普大規模召回。

吉普車遭到黑客攻擊，圖片來自網絡

功能安全和SOTIF研究的對象是智能駕駛系統自身可能產生的失效，還有另一。

黑客攻擊也是也是未來智能駕駛不可忽略的一類失效。為了應對這一種情況，已經在互聯網領域發展很成熟的信息安全正在被運用到汽車開發中。智能駕駛的智能化程度越高，可能被黑客攻擊的點就越多，對信息安全的需求量更大。

這里需要強調一點，功能安全和SOTIF以人身安全為核心，但是不是所有的信息安全問題都會導致人身安全。換句話說，信息安全除了要考慮人身安全以外，還需要考慮黑客攻擊帶來的其他風險，比如車輛被偷導致的財產損失以及隱私泄露風險。

信息安全的研究范圍

2020年車輛信息安全標準ISO 21434，Road Vehicle - Cybersecurity Engineering標準正式發布，該標準是基于SAE J3061制定的、針對車輛整個生命周期的標準。主要涵蓋安全管理、基于項目的網絡安全管理、持續的網絡安全活動、相關風險評估方法、以及道路車輛概念驗證階段，產品開發階段和開發完成后階段的網絡安全。對于該標準如何落地，業界尚在摸索中。