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

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

根據ISO 26262，功能安全系統階段開發內容可以分為兩大部分:

技術安全需求及方案開發及驗證

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

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

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

什么是技術安全需求TSR

安全機制的本質

怎么從FSR到TSR

什么是技術安全方案TSC

系統安全架構設計

安全分析

技術安全需求分配至系統架構

鑒于內容較多，今天我們先聊前三部分內容。

01

什么是TSR

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

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

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

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

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

由FSR技術化的安全需求

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

所謂FSR技術化的安全需求就是，基于系統架構中組件分配得到的FSR，根據該組件內部以及對外的依賴關系和限制條件，將FSR定義的邏輯功能需求進行技術性轉化和體現。

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

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

安全機制

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

安全機制應該包含：

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

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

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

Stakeholder需求

Stakerholder需求主要包括車輛使用，法律法規，生產和服務方面相關的安全需求。一般都是以具體技術細節直接進行呈現，所以會直接并入TSR之中。

例如，車輛發生碰撞后，相關項應該采取的哪些應對措施，可能是轉矩輸出非使能，高壓系統斷電等。

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

1

技術安全要求和非安全要求不能互相矛盾。

2

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

3

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

4

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

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

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

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

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

02

安全機制的本質

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

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

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

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

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

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

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

2. 安全機制是實現相應ASIL等級的關鍵之一

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

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

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

3. 安全機制多和系統安全架構設計相關，一定程度上決定了系統安全架構

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

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

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

在實際系統開發過程中，為實現相應的ASIL等級，控制系統一般進行分層設計，功能安全擁有獨立的軟件層和硬件層，開發過程相對獨立，甚至獨立的開發團隊。

為實現后續安全監控，需要將安全相關的應用層功能在監控層進行多樣化設計復現，所以這部分TSR和我們正常的系統應用層功能開發需求有點類似，但不是完全復制，而是多樣化，差異化的設計實現，所以這些信息或者需求會和應用層功能實現存在一定關聯。

右邊是安全機制，是更深層次技術安全需求，這些都是保證系統功能安全的關鍵技術手段。

03

怎么從FSR到TSR

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

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

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

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

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

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




審核編輯：劉清