本文要點
在上文EPB功能安全筆記(5)：EPB系統軟體接口定義中基于EPB系統初步的系統架構，在架構中定義的各個子產品的功能基礎上，細化了各個子產品間的信号接口，得到一個更加具體的EPB系統架構。
定義接口後的EPB系統架構
另一方面，開發的本質實際上是實作需求。對于EPB系統功能安全開發而言，如何将Safety Goal轉化成EPB系統架構中要素的的安全要求，是EPB系統功能安全開發的核心之一。對應到ISO 26262中，這一工作包括了功能安全概念開發（Functional Safety Concept Development）和技術安全概念開發（Technical Safety Concept Development）。
在實際的功能安全開發過程中，功能安全概念和技術安全概念有着很強的因果關系，聯系非常緊密，甚至有些公司習慣性地将其合稱為“Safety Concept Development”。不過，對于剛接觸功能安全的朋友來說， ISO 26262将對功能安全概念和技術安全概念的說明分别放在了part3和part4中，容易導緻讀者先入為主地對兩者進行了概念上的分割；于此同時，ISO 26262對這兩部分的說明中密集地充斥着貫穿ISO 26262始終的關鍵概念，造成了一定程度上的了解障礙。
鑒于此，筆者在對EPB系統的安全概念開發進行舉例說明前，插入這篇側重于理論說明的總結，旨在強調功能安全概念和技術安全概念的要點，希望能給讀者提供一些參考。
1.概念辨析
在ISO 26262的part3和part4中，反複提到了以下幾個關鍵的專有名詞：
- 安全目标（Safety Goal）
- 功能安全概念（Functional Safety Concept）
- 功能安全要求（Functional Safety Requirement）
- 技術安全概念（Technical Safety Concept）
- 技術安全要求（Technical Safety Requirement）
當獨立地看各個概念的定義時，了解起來沒有什麼難度；但是當這些概念同時出現時，卻有些分不清彼此。接下來對這些概念進行對比和辨析。
1.1.安全目标與功能安全要求
安全目标是怎麼得到的呢？前文提到，通過對整車進行危害分析和風險評估，識别出需要防止、減輕或控制的危害和危害事件，為每個危害事件制定安全目标，并将汽車安全完整性等級(ASIL)與每個安全目标關聯。比如：
整車應避免非預期減速， ASIL C
而當所研究的對象（即相關項）有造成某條安全目标所對應的危害事件的可能時，相關項就需要考慮這一條安全目标。如EPB系統有導緻整車非預期減速的接口時，EPB就繼承了這一條安全目标：
EPB應避免非預期減速， ASIL C
這樣一來，安全目标變成了EPB系統最高層級的功能安全要求。
反過來，ISO 26262, part3, 8.4中對功能安全要求的定義又指出：
如果适用,應考慮以下幾點來定義每項功能安全要求:
a)運作模式;
b)故障容錯時間間隔;
c)安全狀态;
d)緊急運作時間間隔;及
e)功能備援(例如故障容錯)。
也就是說，功能安全要求除了ASIL等級以外，還包含部分或者全部a) - e)的屬性。既然安全目标是最高層級的功能安全要求，那麼安全目标必然也還包含部分或者全部a) - e)的屬性。
總結：
- 安全目标是相關項最高層級的功能安全需求。
- 安全目标和功能安全需求一樣，包含ASIL等級、FTTI、safe state等屬性。
1.2.功能安全要求與技術安全要求
通過上一節的說明讀者可以發現，安全目标和功能安全要求的口吻像是甲方，“我需要功能實作XX”，從這個角度，技術安全要求就是那個要滿足甲方需求的乙方，需要回答“功能應該怎麼做實作XX”。
ISO 26262, part3中說明功能安全要求的導出時提到：
功能安全要求應由安全目标和安全狀态導出，并考慮初步架構設想。
功能安全要求應配置設定給初步架構設想中的要素。
而在ISO 26262, part4中提到：
技術安全要求應根據功能安全概念、相關項的初步架構設想和如下系統特性來定義:
a) 外部接口，如通訊和使用者接口，如果适用；
b) 限制條件，例如環境條件或者功能限制；
c) 系統配置要求。
想必這已經很好了解，身為“甲方”的功能安全要求隻需要根據大緻的架構便可确定“我需要功能實作XX”；而身為“乙方”的技術安全要求則必須知道明确的細化的系統架構，才能夠回答“功能應該怎麼做實作XX”。
另一方面，技術安全要求如何實作功能安全要求呢？關鍵是定義必要的安全機制（safety mechanism）。
安全機制是ISO 26262中另一個非常重要的概念，其定義為：
為了達到或保持某種安全狀态，由電子電氣系統的功能或要素或其他技術來實施的技術解決方案，以探測故障、控制失效。
簡而言之，安全機制即為實作安全所定義的措施。這些措施包括但不限于：
a)與系統自身故障相關的探測、訓示和控制措施；
注1: 包括系統或者要素的自身監控，用于探測随機硬體故障，以及，如果适用，探測系統性失效。
注2：包括對通訊通道(例如:資料接口、通訊總線、無線射頻連結)失效模式的探測和控制的措施。
b)涉及探測、訓示和控制與本系統有互相影響的外部裝置中所發生故障的措施；
示例: 外部裝置包括其他的電控單元、電源或者通訊裝置。
c)使系統實作或者維持在安全狀态下的措施；
注3：包括在安全機制沖突時的優先和仲裁邏輯。
d)細化和執行報警和降級概念的措施；
e)防止故障潛伏的措施。
關于如何定義安全機制，2018版的ISO 26262對此進行了更新，個人認為更加準确和更加便于了解了。是以在這裡附上2018版的英文說明。
For each safety mechanism that enables an item to achieve or maintain a safe state, the following shall be specified:
a) the transition between states;
NOTE 1 This includes the requirements to control the actuators.
b) the fault handling time interval with respect to the timing requirements apportioned from the appropriate architectural level; and
NOTE 2 This sub-requirement aims to achieve a consistent timing within the boundary of the fault handling time interval) FTTI which is specified for each Safety Goal.
c) the emergency operation tolerance time interval, see ISO 26262-1:2018, 3.45, if the safe state of the item cannot be reached within the FTTI.
NOTE 3 In-vehicle testing and experimentation can be used to determine the emergency operation tolerance time interval.
EXAMPLE 1 Duration of the degraded operation prior to the safe state.
EXAMPLE 2 A safety mechanism for a brake-by-wire application, which depends on the power supply, can include the specification of a secondary power supply or storage device (capacity, time to activate and operate, etc.).
總結：
- 安全目标和功能安全要求均不表述為技術解決方案，而表述為功能目的。
而技術安全要求側重于解釋“如何做”。
- 技術安全要求通過定義具體的安全機制來實作“如何做”。
1.3.功能安全概念與技術安全概念
個人認為實際上功能安全概念和技術安全概念都可以用一句話概括：
- 功能安全概念：為了實作功能安全目标，把功能安全要求配置設定給相關項中的初步架構要素或外部措施的一切活動的總和。
- 技術安全概念：為滿足功能安全要求而設計系統架構和技術安全要求的一切活動的總和。
基于此，我們可以說，定義功能（技術）安全要求的過程就是在進行功能（技術）安全概念開發的過程，一些公司習慣性地合稱為“安全概念開發，Safety Concept Development”。
按照這個解釋，Safety Concept Development看起來是在定義可落地的系統方案和要求，與術語中給人空中樓閣之感的“Concept”一詞有點違和。但是，如果鳥瞰整個功能安全開發，Safety Concept Development是屬于系統層的開發，輸出為對系統最底層的要素——軟體和硬體的要求，而在完成了Safety Concept Development之後，隻有當最底層的要素滿足了功能安全要求時，才可以說産品滿足了功能安全。從這個角度看，這裡的“Concept”一詞還是挺準确的。
功能安全開發鳥瞰
2.從安全概念開發看主機廠和供應商的合作
主機廠和供應商的合作關系即為甲方和乙方的關系。主機廠的主要職責之一是定義整車系統E/E架構，并基于E/E架構對各個ECU的供應商提出要求，包括功能安全要求。而各個ECU對主機廠來說是黑盒，原則上主機廠隻需要關心ECU的輸出，而不需要去了解ECU的具體的系統架構；供應商也不會對主機廠開放。
某主機廠某款車型的整車E/E架構圖，1為ESP
從這個角度講，主機廠是在整車層做功能安全概念開發（Functional Safety Concept Development），遞交給供應商的要求為功能安全要求（Functional Safety Requirement）。供應商拿到功能安全要求後，會基于ECU具體的系統架構對系統中的軟體和硬體配置設定技術安全要求（Technical Safety Requirement），完成技術安全概念開發（Technical Safety Concept Development）。
這種在安全概念開發上的合作模式是目前國内主機廠和供應商間的主流合作模式，尤其是與保密性高的國外供應商間的合作模式。但是現在也可以看到的是，随着國内一些研發實力較強的主機廠對供應商的産品了解程度越來越高，要求也越來越細，而且有能力去推動供應商調整系統架構設計。在這種情況下，主機廠給供應商遞交的可以是技術安全要求而不是功能安全要求。這種合作模式實際上在國外的主機廠和供應商之間已經很成熟，同時也從側面說明了國内主機廠研發實力正在逐年提高。
下篇預告
下一期将基于EPB系統架構以及接口定義，以前文分析确定的Safety Goal為目标，舉例闡述如何進行安全概念開發，得出技術安全要求。