本文要點
在上文【EPB功能安全筆記（1）(2)）】中，對EPB系統地進行了危害分析與風險評估。ISO 26262要求，應為具有ASIL等級的每個危害事件确定一個安全目标。比如對于以下危害事件：
| 整車危害 | 場景 | 可能發生的風險 | |
| 車輛非預期減速 | 兩輛車運作在同一車道且速度相近 | 前車非預期減速，後車制動不及，追尾 | |
| S值 | E值 | C值 | ASIL等級 |
| 碰撞速度超過40kph時，駕駛員有危及生命的危害 S3 | 場景發生機率與兩車車距有關，能造成碰撞危害的場景暴露度中等 E3 | 駕駛員不可控 C3 | C |
我們可以定義一條Safety Goal：
EPB應避免錯誤建壓而造成過高的減速度 → ASIL C
但是，面對着上面這一條需求，開發人員很難不一頭霧水。因為我們可以問出一系列問題：
1.減速度大于多少算是“過高”？
2.減速度過高一定會導緻危害嗎？
3.減速度過高導緻的危害都是ASIL C嗎？
實際上，除了ASIL等級以外，Safety Goal還有其他屬性，本文将對Safety Goal的其他屬性進行介紹，以期讀者在閱讀完本文後可以回答上述問題。
ISO 26262對功能安全需求的定義
ISO 26262-2018第三部分7.4.2.4中總結了功能安全需求的屬性。
Each functional safety requirement shall be specified by considering the following, as applicable。
a) operating modes;
b) fault tolerant time interval;
c) safe states;
d) emergency operation time interval; and
e) functional redundancies (e.g. fault tolerance).
這裡需要特别注意比較容易忽略的詞：“as applicable（如果适用）”。這表明，并不是每條功能安全需求都需要同時包含a)~e)。但是即便如此，a)~c)是三個基礎的屬性，每個Safety Goal都應該定義這三個屬性。
對于d)和e)，由于涉及到的use case比較複雜，計劃在系列文章的後半段再展開說明，本文暫不做涉及。
1.1.operating modes (運作模式)
conditions of functional state that arise from the use and application of an item or element.（相關項或要素的可感覺的功能狀态。）
EXAMPLE: System off; system active; system passive; degraded operation; emergency operation; safe state.
這個屬性比較好了解，就是功能安全需求所對應的系統運作模式。
1.2.fault tolerant time interval, FTTI (故障容錯時間間隔)
minimum time-span from the occurrence of a fault in an item to a possible occurrence of a hazardous event, if the safety mechanisms are not activated. (在沒有安全機制的情況下從相關項出現故障到危害事件發生的最小事件間隔)
fault tolerant time interval, FTTI
FTTI可以說是功能安全最重要的概念之一。本文以2018版ISO 26262的定義為基準。
為什麼要強調這一點呢？前面的文章提到：“在危害分析和風險評估過程中，應對不含内部安全機制的相關項進行評估，即在危害分析和風險評估過程中不應考慮将要實施或已經在前代相關項中實施的安全機制”；而Safety Goal是基于危害分析和風險評估得到的，換句話說，确定Safety Goal的過程中也不考慮任何安全機制。從這一點上看，2018版的這一處更新是在強調：如果把Safety Goal看作是整車層的功能安全需求，那麼FTTI也應該在整車層定義。這一更新也是對2011版ISO 26262的FTTI概念定義不清的糾正。做過功能安全開發的朋友可能深有體會，2011版ISO 26262對FTTI的概念定義在整車層、系統層、軟硬體層是混用的。
1.3.safe state(安全狀态)
operating mode, in case of a failure, of an item without an unreasonable level of
risk. (沒有不合理風險的相關項的運作模式)
EXAMPLE: Switched-off mode
safe state
讨論safe state的前提是考慮了執行安全措施（safety mechanism）。因為當相關項的故障發生後，隻有正确且及時地執行了安全措施，危害才有可能避免。
那麼如何定義safe state呢？我們也許可以從一個問題上入手：産品是用不是用在自動駕駛車輛中？
對于自動駕駛，當系統在出現故障之後，需要系統來自己操作避免事故（自動駕駛等級越高，駕駛員可以越晚介入接管甚至是完全不用接管），出了事故是廠家的責任而不是駕駛員的責任。
在這種情況下，整車層的safe state的定義方向為：及時切換到備援系統。
對于非自動駕駛系統，可以把所有的E/E系統看作是幫助駕駛員更好駕駛的輔助産品。那麼既然是輔助産品，當系統出現故障以後，隻要系統及時退出工作，并正确向駕駛員報告了故障，那麼接下來是駕駛員的責任，無論事故是否能夠被避免。
在這種情況下，整車層的safe state的定義方向為：系統退出并報警提醒駕駛員。
如何确定Safety Goal的其他屬性？
通過上節我們可以看到，operation mode和safe state相對比較好确定，是以補充完整Safety Goal的關鍵在于确定FTTI。
實際功能安全開發過程中是如何定義FTTI的呢？概括來說，就是設計相應的測試用例，通過故障注入的方式進行實車測試或者模型仿真。
整車測試的優勢在于真實性，但是成本高昂，且容易受到不必要因素的幹擾，尤其是對于多車參與的場景；仿真在成本上優勢明顯，且對場景的複現性強，更有利于排除不必要因素的幹擾。是以，除了對整車動力學模型精準度要求極高的場景（比如車輛失穩）外，一般都采用仿真的方式。
為盡可能保證仿真結果的可信度，一般選取偏保守的參數，使得仿真得出的結果相比實車更嚴苛。但同時也可能在一些安全目标上增加了功能安全開發的難度。
接下來就以下面這條Safety Goal為例，說明如何通過仿真确定FTTI。Safety Goal背後的場景為：
EPB應避免錯誤建壓而造成過高的減速度 → ASIL C
同一車道内前車突然非預期減速
針對這一場景搭建的整車模型至少需要包含如下關鍵參數：
| 參數 | 設定值 | 備注 |
| 兩車初始距離 | 和兩車初速度有關，取 S = v * 1s | |
| 兩車初始速度 | 10~180m/s, 取樣間隔為10 | |
| 後車駕駛員反應時間 | 1.2s | 前車發生故障到後者駕駛員踩制動的時間 |
| 前車從駕駛員踩制動到車輛産生制動力的滞後時間 | 0.2s | 制動系統特性 |
| 後車從駕駛員踩制動到車輛産生制動力的滞後時間 | 0.2s | 制動系統特性 |
| 前車減速度 | -1 ~ ~10m/ss，取樣間隔為1 | |
| 後車減速度 | -5 ~ ~10 m/ss，取樣間隔為1 | |
| 前車故障持續時間 | 0~3s. 取樣間隔為0.2 |
根據仿真結果，我們可以得到不同減速度和不同初始速度下兩車是否會發生碰撞，以及發生碰撞時刻兩車的相對速度。
不同的碰撞速度将影響S值評分，如下圖所示：
場景：同一車道内前車非預期減速
對于E值，可以根據兩車初速度對場景做進一步的細分，如下表所示。
| 初始速度 | E值 |
| V0≤120kph | E4 |
| 120≤V0≤160kph | E3 |
| 160≤ V0≤200kph | E2 |
| V0≥200kph | E1 |
對于C值，如果兩車在碰撞發生前持續的時間比較長，則後車駕駛員有較高的可能性在這段時間内通過轉向避免和前車相撞。是以C值也可以适當調整：
| 從故障發生到發生碰撞的持續時間 | C值 |
| >6s | C2 |
| ≤6s | C3 |
綜合上述的S/E/C評分标準和仿真得到的碰撞速度的結果，我們可以大緻得到這樣一個表格。這個表格定量地給出了評價Safety Goal是否被違背的标準，是以也被稱為safety margin (或safety criteria) 。
仿真得到的safety margin
注意：這裡的參數和結果舉例僅為了解釋說明，具體值和真實的開發存在差距。
前面提到，FTTI在沒有安全機制的情況下從相關項出現故障到危害事件發生的最小事件間隔。根據仿真結果，我們可以看到，不同的ASIL等級對應不同的FTTI。比如造成ASIL C的hazard，FTTI最短為1.4s；而造成ASIL A的hazard，FTTI最短為0.6s。
與此同時，不同的ASIL等級也對應着不同的減速度範圍。比如減速度小于-7m/ss才可能造成ASIL C的hazard；而當減速度小于-3m/ss時就有可能造成ASIL A的hazard。
由此，對于開頭提出的三個問題也有了答案。
總結
Safety Goal作為最高層級的功能安全需求，除了ASIL等級以外，還有其他的屬性。隻有當其他屬性也被清晰地定義後，這條Safety Goal才是完整的，接下來才能以Safety Goal為目标和指導進行功能安全開發。
基于上面的分析，我們可以将本文開始提到的Safety Goal補充完整。
Safety Goal：EPB應避免錯誤建壓而造成過高的減速度
ASIL: C
FTTI：see safety margin
safe state: EPB shut down and warn driver
safety margin:
| ASIL Rating | deceleration | FTTI |
| A | < -3m/ss | 600ms |
| B | < -5m/ss | 1000ms |
| C | < -7m/ss | 1400ms |
這裡有一點需要補充，按照上面這條Safety Goal的描述，相當是按照不同的ASIL等級及對應的FTTI細分出了三條Safety Goal，這對後續的功能設計來說未免有點複雜。比如為了實作Safety Goal，我們會設計相應的安全機制（safety mechanism），那麼理論上這裡需要定義三個安全機制。但是實際上這三個安全機制的作用是重疊的，本質上都是對減速度進行限制。簡單的做法就是按照最高要求設計一個安全機制，同時覆寫三條細分的Safety Goal的需求。這樣一來，對ASIL等級和FTTI都選取最嚴格的值，得到一條簡化後的Safety Goal。
Safety Goal：EPB應避免錯誤建壓而造成過高的減速度
ASIL: C
FTTI：600ms
safe state: EPB shut down and warn driver
safety margin: deceleration < -3m/ss
這樣定義的Safety Goal簡化了功能安全設計，但是顯然是增加了開發難度的。是以如果後續的開發能夠滿足這樣嚴苛的Safety Goal那就充分利用了簡化的優勢；如果無法滿足，可以按照原始的safety margin降低難度再進行開發。
下篇預告
在此之前，我們需要熟悉EPB系統。下篇文章将結合VDA305對EPB系統架構展開說明。