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

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

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

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

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

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

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

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

安全機制的本質(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)是為滿足安全目標SG或功能安全需求(FSR)，由功能安全需求(FSR)在技術(shù)層面派生出的可實施的安全需求。

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

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

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

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

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

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

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

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

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

安全機制

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

安全機制應該包含：

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

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

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

Stakeholder需求

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

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

此外，針對TSR，還需要注意以下幾點:

1

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

2

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

3

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

4

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

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

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

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

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

02

安全機制的本質(zhì)

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

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

1. 安全機制屬于更深層次的TSR

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

03

怎么從FSR到TSR

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

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

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

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

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

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




審核編輯：劉清