我們在概念開發(fā)階段，通過組件層別的安全分析(FTA, FMEA)對功能安全開發(fā)最初的安全需求，即安全目標(biāo)(SG)，進(jìn)行細(xì)化，得到了組件級別的功能安全需求(FSR)和方案(FSC)。

但FSR本質(zhì)上還是屬于功能層面的邏輯安全需求，屬于"需要做什么"的層次，無法具體實(shí)施，所以需要將FSR進(jìn)一步細(xì)化為技術(shù)層面的安全需求(TSR)，即"怎么做"，為后續(xù)的軟件和硬件的安全開發(fā)奠定技術(shù)需求基礎(chǔ)。

根據(jù)ISO 26262，功能安全系統(tǒng)階段開發(fā)內(nèi)容可以分為兩大部分:

技術(shù)安全需求及方案開發(fā)及驗(yàn)證

系統(tǒng)集成測試及安全確認(rèn)(Validation)

它們在開發(fā)過程中并不連續(xù)，分別隸屬于系統(tǒng)開發(fā)V模型的左邊和右邊，中間穿插了硬件和軟件開發(fā)。系統(tǒng)階段技術(shù)安全需求(TSR)和方案(TSC)開發(fā)和概念階段功能安全需求(FSR)和方案(FSC)一脈相承，和概念開發(fā)開發(fā)緊密銜接。只有硬件和軟件開發(fā)完成，才能進(jìn)行系統(tǒng)層面集成測試和需求確認(rèn)。

系統(tǒng)集成這部分我們留在軟件和硬件開發(fā)之后再聊。針對第一個大的部分，即技術(shù)安全需求(TSR)和方案(TSC)，我們主要聊以下內(nèi)容:

什么是技術(shù)安全需求TSR

安全機(jī)制的本質(zhì)

怎么從FSR到TSR

什么是技術(shù)安全方案TSC

系統(tǒng)安全架構(gòu)設(shè)計

安全分析

技術(shù)安全需求分配至系統(tǒng)架構(gòu)

鑒于內(nèi)容較多，今天我們先聊前三部分內(nèi)容。

01

什么是TSR

總體而言，技術(shù)安全需求(TSR:Technical Safety Requirement)是為滿足安全目標(biāo)SG或功能安全需求(FSR)，由功能安全需求(FSR)在技術(shù)層面派生出的可實(shí)施的安全需求。

那到底什么是由FSR派生出的技術(shù)安全需求呢？

根據(jù)ISO 26262的定義，技術(shù)安全要求(TSR)應(yīng)該明確功能安全需求在各自層級的技術(shù)實(shí)現(xiàn); 考慮相關(guān)項(xiàng)定義和系統(tǒng)架構(gòu)設(shè)計，解決潛在故障的檢測、故障避免、安全完整性(即滿足ASIL等級)以及產(chǎn)品生產(chǎn)和服務(wù)方面的必要安全問題。

什么意思呢？直接上個我自己總結(jié)的公式:

技術(shù)安全需求(TSR) = 由FSR技術(shù)化的安全需求+ 安全機(jī)制 + Stakeholder需求

由FSR技術(shù)化的安全需求

將FSR進(jìn)一步技術(shù)化，得到可以實(shí)施的技術(shù)安全需求，是TSR的重要來源，但它只是TSR其中一個組成部分。

所謂FSR技術(shù)化的安全需求就是，基于系統(tǒng)架構(gòu)中組件分配得到的FSR，根據(jù)該組件內(nèi)部以及對外的依賴關(guān)系和限制條件，將FSR定義的邏輯功能需求進(jìn)行技術(shù)性轉(zhuǎn)化和體現(xiàn)。

這部分技術(shù)需求屬于相對基礎(chǔ)的TSR，不涉及深層次的探測，顯示，控制或減輕系統(tǒng)出現(xiàn)故障的安全措施，所以并不能保證系統(tǒng)功能安全。它的主要的目的是為后續(xù)相關(guān)安全機(jī)制的開發(fā)或者需求的提出奠定技術(shù)基礎(chǔ)。

例如，由FSR技術(shù)化的安全需求包括，定義邏輯功能需求中所涉及的軟件組件，硬件組件(傳感器，控制單元，執(zhí)行單元)，組件接口技術(shù)信息(如信號名稱，來源等)，傳輸方式(CAN總線等)，計算周期，軟件組件不同平臺復(fù)用配置需要的標(biāo)定數(shù)據(jù)，硬件組件指標(biāo)要求等。

安全機(jī)制

安全機(jī)制(Safety Mechanism)目的在于探測，顯示和控制故障，屬于功能安全事后補(bǔ)救措施，是TSR非常重要的組成部分，是實(shí)現(xiàn)功能安全，防止安全目標(biāo)SG或者功能安全需求FSR違反的重要技術(shù)實(shí)現(xiàn)手段之一。

安全機(jī)制應(yīng)該包含：

檢測系統(tǒng)性及隨機(jī)硬件故障的措施。例如，針對系統(tǒng)I/O，總線信號范圍檢查，冗余校驗(yàn)，有效性檢測，邏輯計算單元數(shù)據(jù)流及程序流監(jiān)控，控制器硬件底層軟件監(jiān)控等。

顯示故障。例如，對駕駛員進(jìn)行聲音，不同類型及顏色的指示燈，提示文字等預(yù)警，增加駕駛員對車輛的可控性。

控制故障的措施。例如，F(xiàn)ail to safe:將系統(tǒng)在指定的故障容錯時間間隔(FTTI)導(dǎo)入安全狀態(tài)，包括降級，故障仲裁，故障記錄等。如果不能，還需要定義緊急運(yùn)行時間間隔及運(yùn)行狀態(tài)。或者Fail to operational，通過并行冗余系統(tǒng)，當(dāng)一個系統(tǒng)失效后，進(jìn)入另外一個并行系統(tǒng)繼續(xù)提供全部或部分功能。少。

Stakeholder需求

Stakerholder需求主要包括車輛使用，法律法規(guī)，生產(chǎn)和服務(wù)方面相關(guān)的安全需求。一般都是以具體技術(shù)細(xì)節(jié)直接進(jìn)行呈現(xiàn)，所以會直接并入TSR之中。

例如，車輛發(fā)生碰撞后，相關(guān)項(xiàng)應(yīng)該采取的哪些應(yīng)對措施，可能是轉(zhuǎn)矩輸出非使能，高壓系統(tǒng)斷電等。

此外，針對TSR，還需要注意以下幾點(diǎn):

1

技術(shù)安全要求和非安全要求不能互相矛盾。

2

對于使相關(guān)項(xiàng)達(dá)到或保持安全狀態(tài)的每個安全機(jī)制，應(yīng)指定以下內(nèi)容:切換到安全狀態(tài)的條件，時間間隔(FTTI)，必要的話，緊急運(yùn)行狀態(tài)及時間間隔。

3

對于ASIL(A)、(B)、C 和 D 等級的技術(shù)安全需求，應(yīng)該制定防止故障潛伏安全機(jī)制。

4

對于 ASIL(A)、(B)、C和 D 等級的TSR: 用于防止雙點(diǎn)故障變成潛伏故障的安全機(jī)制的開發(fā)應(yīng)符合以下ASIL安全等級要求:

a) ASILB(對于分配為ASILD的技術(shù)安全要求);

b) ASILA(對于分配為ASILB和ASILC的技術(shù)安全要求);

c) QM(對于分配 ASILA的技術(shù)安全要求)。

這個就是安全機(jī)制的安全機(jī)制ASIL等級的約束，該約束的本質(zhì)是對TSR對應(yīng)ASIL等級的分解，主要是為防止由安全機(jī)制失效導(dǎo)致的雙點(diǎn)故障潛伏。(我后面在安全機(jī)制的本質(zhì)會細(xì)聊)

02

安全機(jī)制的本質(zhì)

接下我們聊聊困惑很多朋友的一個問題:安全機(jī)制到底是什么，它和TSR到底有什么區(qū)別?

在ISO 26262-4:2018中，TSR和安全機(jī)制這兩部分內(nèi)容獨(dú)立成章節(jié)，并沒有合在一起進(jìn)行闡述，這給很多朋友造成一種誤解，認(rèn)為安全機(jī)制和TSR好像是不一樣的存在，它們之類的區(qū)別也不夠清楚。下面我從三個方面來闡述一下安全機(jī)制的本質(zhì):

1. 安全機(jī)制屬于更深層次的TSR

安全機(jī)制是為防止SG或FSR的違反，基于由FSR技術(shù)化的安全需求，提出的更深層次的事后補(bǔ)救技術(shù)安全措施，它包括:

由FSR技術(shù)化得到的TSR的安全機(jī)制，主要是防止系統(tǒng)性故障，或硬件單點(diǎn)故障潛伏提出的技術(shù)安全需求。

以及安全機(jī)制的安全機(jī)制。例如針某TSR提出了已經(jīng)有了安全機(jī)制A，但由于該TSR的ASIL等級較高(C或D)，安全機(jī)制A本身也可能失效，此時如果原有功能正常，系統(tǒng)不會違反安全目標(biāo)SG，但安全機(jī)制A的失效就會潛伏，變成雙點(diǎn)故障，所以需要對安全機(jī)制A的功能安全進(jìn)行監(jiān)控，提出針對安全機(jī)制A的相應(yīng)的技術(shù)安全需求，防止安全機(jī)制A的故障潛伏。

一般來講，考慮到系統(tǒng)實(shí)現(xiàn)的成本和復(fù)雜度，安全機(jī)制不超過兩層。根據(jù)ISO 26262，三點(diǎn)及以上故障就可以認(rèn)為安全故障，否則就會出現(xiàn)無窮的安全機(jī)制嵌套。

2. 安全機(jī)制是實(shí)現(xiàn)相應(yīng)ASIL等級的關(guān)鍵之一

除ISO 26262對不同開發(fā)過程的約束(包括方法，驗(yàn)證等)外，在系統(tǒng)，軟件和硬件開發(fā)階段，不同ASIL等級直接決定了應(yīng)該采取哪些安全措施，以及安全措施的類型(或高級層度)。

越高的ASIL等級對應(yīng)的安全措施，在數(shù)量和質(zhì)量的要求越高。例如，對于ASILB的系統(tǒng)，可能具有單獨(dú)時間Base的Watchdog可能就夠了，但是對ASILD系統(tǒng)而言，可能需要上程序流邏輯監(jiān)控才能滿足。

當(dāng)然不同的安全機(jī)制在實(shí)施難度和成本上都有所不同，這部分內(nèi)容我會在后續(xù)的專題里一步步講解。

3. 安全機(jī)制多和系統(tǒng)安全架構(gòu)設(shè)計相關(guān)，一定程度上決定了系統(tǒng)安全架構(gòu)

安全機(jī)制是保證系統(tǒng)功能安全的非常重要的技術(shù)手段，而這些技術(shù)手段，例如，硬件冗余，輸入輸出有效性檢驗(yàn)，安全狀態(tài)導(dǎo)入，或我們常見的控制器3層安全監(jiān)控架構(gòu)等等，這些都直接決定了我們系統(tǒng)的安全架構(gòu)，會在架構(gòu)設(shè)計中進(jìn)行考慮，直接融入架構(gòu)設(shè)計之中。這個也是為什么在功能安全在系統(tǒng)階段開發(fā)過程中，花很大的篇幅來講安全機(jī)制和架構(gòu)設(shè)計的重要原因之一。

為了方便理解安全機(jī)制，我們一起來看個關(guān)于加速踏板開度采集的例子:

其中，左邊屬于由FSR技術(shù)化的安全需求，主要是明確加速踏板技術(shù)信息，包括采用什么樣傳感器，輸出信號有哪些，類型，采樣周期等。

在實(shí)際系統(tǒng)開發(fā)過程中，為實(shí)現(xiàn)相應(yīng)的ASIL等級，控制系統(tǒng)一般進(jìn)行分層設(shè)計，功能安全擁有獨(dú)立的軟件層和硬件層，開發(fā)過程相對獨(dú)立，甚至獨(dú)立的開發(fā)團(tuán)隊(duì)。

為實(shí)現(xiàn)后續(xù)安全監(jiān)控，需要將安全相關(guān)的應(yīng)用層功能在監(jiān)控層進(jìn)行多樣化設(shè)計復(fù)現(xiàn)，所以這部分TSR和我們正常的系統(tǒng)應(yīng)用層功能開發(fā)需求有點(diǎn)類似，但不是完全復(fù)制，而是多樣化，差異化的設(shè)計實(shí)現(xiàn)，所以這些信息或者需求會和應(yīng)用層功能實(shí)現(xiàn)存在一定關(guān)聯(lián)。

右邊是安全機(jī)制，是更深層次技術(shù)安全需求，這些都是保證系統(tǒng)功能安全的關(guān)鍵技術(shù)手段。

03

怎么從FSR到TSR

上面我們聊到TSR的具體組成部分，包括由FSR技術(shù)化的TSR，安全機(jī)制和Stakeholder需求。

前兩部分TSR的導(dǎo)出，和概念階段聊到的SG到FSR類似，都是通過安全分析(即FTA，F(xiàn)MEA分析方法)完成。

以FTA分析為例，主要是將違反的FSR作為頂層分析事件，進(jìn)行原因分析，安全分析的具體細(xì)節(jié)我在這里就不重復(fù)了，不熟悉的朋友移步功能安全專題03篇內(nèi)容。

實(shí)際操作過程中，對于比較簡單的FSR，即涉及的組件功能的比較簡單，完全可以依據(jù)經(jīng)驗(yàn)直接導(dǎo)出，對于相對比較復(fù)雜的FSR則需要進(jìn)行完整的安全分析。

對于Stakeholder需求，一般需要根據(jù)Item Definition中定義的法律法規(guī)及之前項(xiàng)目經(jīng)驗(yàn)進(jìn)一步細(xì)化，一般情況下，該部分需求可以在不同項(xiàng)目中可以復(fù)用。

寫在最后: TSR和安全機(jī)制我們就聊完了，網(wǎng)絡(luò)上很多關(guān)于它們的介紹都太表面，照抄標(biāo)準(zhǔn)，希望這篇能夠給朋友們理解TSR和安全機(jī)制帶來幫助，下期我們繼續(xù)看功能安全系統(tǒng)階段開發(fā)其他內(nèi)容。




審核編輯：劉清