概述

傳感器的功能安全要求往往非常通用，包括輸入信號的故障模式，因此難以實施和測試。也許作者關(guān)注的是系統(tǒng)的預(yù)期功能，但預(yù)期功能不在安全要求的范圍內(nèi)。安全要求表達了作者對故障模式的期望。本文以雷達傳感器的對象列表為例，說明了明確這一點的重要性。

背景

雷達、激光雷達和攝像頭等傳感器被廣泛用于實現(xiàn)現(xiàn)代車輛中的ADAS功能。由于傳感器可能會發(fā)生故障并提供錯誤的對象數(shù)據(jù)，因此必須指定功能安全要求（FSR）以應(yīng)對潛在的安全目標違規(guī)。如果分配給系統(tǒng)元素的FSR在錯誤的級別（例如車輛功能級別）上指定，則從這些要求中得出的技術(shù)安全要求（TSR）將顯示較差的質(zhì)量。不能低估對功能安全性的影響。本文給出了一個示例，并解釋了如何提高FSR和TSR質(zhì)量的實用解決方案。

ADAS常見的功能安全要求

在ADAS傳感器規(guī)范中，常見的功能安全要求是針對誤報和漏報：

傳感器不得報告虛假對象

傳感器應(yīng)報告所有相關(guān)對象

這些要求看似合理，但更詳細的分析表明，這兩項要求并不適用于傳感器系統(tǒng)。實際上，這些要求是車輛功能被錯誤地歸咎于傳感器的幾種故障模式中的兩種。

對象列表故障模式分析

如果在傳感器外部實施數(shù)據(jù)融合，傳感器通常會報告對象列表。每個對象都由幾個屬性（例如物理屬性）描述。在尋找功能或信號的故障模式時，了解感興趣的信號及其子信號的組成非常重要。對象列表可以根據(jù)其目的顯示幾種故障，而每個對象可以根據(jù)其屬性顯示其他故障。以下分析并不完整，目的是展示一些潛在的陷阱。

對象列表的目的是報告相關(guān)對象（這里不再進一步分析“相關(guān)性”，但必須在項目中定義驗證標準）。因此，可以從列表中添加和刪除對象?？赡艹霈F(xiàn)的問題包括：

一個對象應(yīng)該被添加到列表中，但沒有被添加（假陰性）

一個對象不應(yīng)添加到列表中，但被添加了（誤報）

一個對象應(yīng)從列表中刪除，但沒有被刪除（誤報）

一個對象不應(yīng)從列表中刪除，但被刪除了（假陰性）

一個對象應(yīng)添加到列表中，但添加得太早或太晚（灰色正值）

一個對象應(yīng)從列表中刪除，但刪除得太早或太晚（灰色負值）

這是與對象列表相關(guān)的六種故障模式，盡管并非所有這些故障模式都必然與安全相關(guān)（這取決于車輛功能和車輛架構(gòu)）。功能所有者（通常是OEM）需要通過歸納分析方法分析這些故障模式的影響。

詳細列表中的前四種故障模式涵蓋了上述兩種故障模式，因此不禁要問，這份簡單的列表是否錯誤。答案是肯定的。這兩種故障模式指的是車輛功能（例如，對物體進行緊急制動），而六種故障模式指的是傳感器實現(xiàn)的功能（提供對象列表）。在車輛層面，尚無法知道傳感器是否會發(fā)送對象列表。在車輛層面，很明顯，車輛應(yīng)對與預(yù)期功能相關(guān)的對象做出反應(yīng)，而不應(yīng)對其他對象做出反應(yīng)。然而，簡單地將這些要求分配給傳感器并不能確保足夠安全的實現(xiàn)，這一點從更完整的六項要求列表中可以看出。

對象屬性故障模式分析

下一個問題是：距離或相對速度等對象屬性怎么辦？如何考慮這些屬性的故障模式？此示例表明，在識別故障模式之前正確定義信號類型非常重要。傳感器提供對象列表，列表的故障模式如上所示。列表的每個元素（報告的對象）都有幾個屬性，報告的數(shù)據(jù)也可能以不同的方式失效。例如，如果使用動態(tài)范圍的很大一部分通過12位信號描述偏航率等物理屬性，則以下模擬信號故障模型適用：

值停滯

超出上限（超出范圍）

低于下限（超出范圍）

正偏移（偏差）

負偏移（偏差）

積極跳躍

負跳躍

正向漂移

負漂移

振蕩

因此，這為此類對象屬性提供了另外10種故障模式。其他故障模型通常適用于狀態(tài)數(shù)較少的信號或通信總線。

安全目標違規(guī)分析

對于對象列表和對象屬性的每種故障模式，必須通過歸納分析方法分析其對安全目標違規(guī)的影響，這是功能或系統(tǒng)所有者（通常是OEM）的責任。然后可以得出所有安全相關(guān)故障模式的安全要求。

通用要求的問題

最后但并非最不重要的一點是，通用要求的另一個問題是它們可能涵蓋損壞的輸入信號對輸出信號質(zhì)量的影響。在系統(tǒng)無法檢測和/或控制此類故障的情況下，無法完全實現(xiàn)“傳感器不得發(fā)送損壞的對象數(shù)據(jù)”之類的要求，因為潛在的根本原因是輸入信號本身。讓我們更詳細地看一下。

傳感器接收系統(tǒng)外部產(chǎn)生的信號。例如，雷達傳感器檢測來自物體的回聲。傳感器提供的對象列表可能會失效（見上文）。列表可能會失效，列表中的每個對象也可能會失效。這種失效的根本原因是什么？根據(jù) (1)，系統(tǒng)元素的每個輸出信號失效都可能源于系統(tǒng)本身或損壞的輸入信號。因此，每當傳感器提供損壞的對象列表時，根本原因可能是系統(tǒng)本身，也可能是系統(tǒng)檢測到的損壞信號。因此，將以下要求分配給傳感器根本沒有意義：

傳感器不得報告虛假對象。

在這種情況下，底層車輛功能要求在系統(tǒng)層面上尚未得到正確細化。相反，對傳感器的可行要求可能是：

傳感器應(yīng)檢測任何可能導(dǎo)致對象列表安全相關(guān)損壞的內(nèi)部系統(tǒng)故障。

（注意：當然也必須定義“任何故障”和“安全相關(guān)”。）以這種方式制定的要求明確排除了輸入信號側(cè)的任何故障。對于雷達傳感器，回波質(zhì)量可能會受到影響，即偏離在未受干擾環(huán)境中產(chǎn)生的預(yù)期回波。實際上，物體屬性（傳感器測量的屬性除外）和環(huán)境都會影響信號，從而導(dǎo)致傳感器的輸出信號損壞。在分析故障模式和規(guī)范安全要求時，必須考慮完整的內(nèi)部和外部（從傳感器的角度來看）信號路徑：

傳感器發(fā)射雷達脈沖

雷達脈沖從天線發(fā)射到物體

雷達脈沖在物體上反射

回聲從物體傳輸?shù)教炀€

傳感器接收回聲

第一步和最后一步可能會因傳感器故障而失敗。第二步和第四步可能會因環(huán)境條件而失敗。第三步可能會因物體屬性對信號質(zhì)量的影響而失敗。因此，五個步驟中至少有三個步驟可能會對雷達傳感器提供的對象數(shù)據(jù)產(chǎn)生影響，因此根本原因在傳感器之外。因此，不能將“傳感器不得報告虛假對象”之類的安全要求分配給傳感器。

功能安全要求的細化

功能安全要求通常源自功能的故障模式。因此，上述通用安全要求（“傳感器應(yīng)檢測任何內(nèi)部系統(tǒng)故障……”）需要針對所有這些故障模式進行細化。

對象列表示例：

傳感器應(yīng)檢測任何可能將不存在的對象添加到對象列表中（誤報）的系統(tǒng)內(nèi)部故障。

對象數(shù)據(jù)示例：

傳感器應(yīng)檢測出任何可能導(dǎo)致相對速度人為增加5%以上的系統(tǒng)內(nèi)部故障。

可以為對象列表和對象數(shù)據(jù)的所有其他故障模式指定類似的要求。

總結(jié)

為了規(guī)范系統(tǒng)的安全要求，功能故障的根本原因需要是系統(tǒng)故障和輸入信號故障。分配給系統(tǒng)的安全要求應(yīng)明確規(guī)定導(dǎo)致正在調(diào)查的輸出信號故障（=功能故障）的系統(tǒng)內(nèi)部故障。特別是，系統(tǒng)的安全要求不應(yīng)過于籠統(tǒng)，以至于它們還涵蓋環(huán)境對系統(tǒng)輸入信號的影響。此類要求不能由系統(tǒng)實現(xiàn)。整體功能安全概念必須涵蓋環(huán)境（一般而言：系統(tǒng)外部）對系統(tǒng)輸入信號的影響。