在我剛剛接觸功能安全這個領域的時候經(jīng)?；煜δ馨踩?(FSR) 和技術(shù)安全要求 (TSR)。這兩種要求應提供何種程度的細節(jié)，以及兩者之間的界限究竟在哪里，這些都不清楚。因此我將在這篇文章中討論這個問題。

1.需求層次

功能安全要求 (FSR) 源自項目定義、HARA 和安全目標，并可追溯至安全目標。每個安全目標應至少有一個與之關(guān)聯(lián)的 FSR。

技術(shù)安全要求 (TSR) 主要源自 FSR。每個 FSR 應至少有一個與之關(guān)聯(lián)的 TSR。

下圖提供了從 ISO26262 第 3 部分 - 項目定義到第 5 部分硬件安全要求 (HSR) 和第 6 部分軟件安全要求的要求/活動流程的層次視圖。

2.FSR和TSR之間的區(qū)別

該表給出了 FSR 和 TSR 之間的高級差異。

3.邊界FSR與TSR

讓我們以巡航控制功能為例，以更好地理解 FSR 和 TSR 之間的界限。在下圖中，巡航控制功能表示為一個項目，并具有多個相互交互的模塊，例如巡航控制模塊、用戶交互、制動模塊和發(fā)動機模塊。項目定義討論了車輛級別功能的行為期望。當我們定義 FSR 時，必須將整個項目定義的范圍視為邊界。這在圖中以綠色虛線突出顯示。每個 FSR 都應在車輛級別指定要求，并應分配給實現(xiàn)它的模塊。

TSR 指定系統(tǒng)級的要求。因此，TSR 的邊界位于模塊或系統(tǒng)級。這在圖中以橙色虛線突出顯示。

4.獨立于實施與關(guān)聯(lián)于實施

指定功能行為而不涉及“如何”實現(xiàn)功能的需求是與實現(xiàn)無關(guān)的需求。指定“如何”實現(xiàn)功能的需求是與實現(xiàn)相關(guān)的需求。

讓我們回到我們的巡航控制示例，更好地理解這方面的需求。

5.FSR功能

這些是安全實現(xiàn)安全目標所需的預期功能要求。

6.FSR故障監(jiān)控與緩解

應使用以下 FSR 格式來定義故障監(jiān)控要求。

FSR 1：“ECU 應能夠在 YYYY 時間范圍內(nèi)檢測到 XXXX 故障”

FSR 2：“確認故障后，ECU 應在 ZZZZ 時間范圍內(nèi)轉(zhuǎn)換到安全狀態(tài)（項目級安全狀態(tài)）” 

這里的“XXXX”表示影響車輛級功能的任何故障（例如數(shù)據(jù)或通信故障）。YYYY 是故障檢測時間，ZZZZ 是故障反應時間。YYYY + ZZZZ 應小于 FTTI（容錯時間間隔）。

FSR 必須指定通用要求以避免或檢測和緩解故障，而不是直接指定解決方案。例如，

如果檢測到故障，巡航控制模塊應向用戶發(fā)出指示

巡航控制應采取措施在 YYYY 時間范圍內(nèi)檢測內(nèi)部故障（而不是提供電源監(jiān)控、外部看門狗等解決方案）

7.TSR功能

我們將“巡航控制模塊在檢測到故障時應向用戶指示”作為 FSR，并為其推導出 TSR 框架。

TSR 要求應指定準確的 CAN 接口細節(jié)

TSR 要求應指定啟用/禁用該功能的確切標準

TSR 要求應指定監(jiān)控數(shù)據(jù)的正確性和活躍性

TSR 要求應指定系統(tǒng)級操作模式（例如，操作模式應基于點火狀態(tài)）

TSR 要求應指定硬件相關(guān)輸入的去抖動時間

8.TSR故障監(jiān)控

TSR 應指定系統(tǒng)級可用的故障監(jiān)控方面的解決方案。例如，

巡航控制應實施安全機制，以檢測保存巡航控制數(shù)據(jù)的 RAM 中的故障

巡航控制應實施安全機制來檢測巡航控制算法的時序和執(zhí)行故障

例如，如果內(nèi)存保護單元被視為系統(tǒng)級概念的一部分，則 TSR 應指定相同的內(nèi)容。否則，TSR 應允許自由決定軟件設計級別的解決方案。

9.總結(jié)

通過本文的討論和實例分析，我們詳細闡明了功能安全要求（FSR）和技術(shù)安全要求（TSR）之間的區(qū)別及其各自的細節(jié)要求。理解FSR和TSR的邊界和差異對于安全工程師在實施和設計安全系統(tǒng)時至關(guān)重要。FSR側(cè)重于項目定義和車輛級功能的要求，而TSR則聚焦于系統(tǒng)級的實現(xiàn)細節(jié)。希望通過本文的講解，能夠幫助安全工程師更清晰地把握FSR和TSR的定義和應用，從而在實際工作中更加高效準確地制定和實施安全策略。