現(xiàn)在很多汽車和零部件企業(yè)在控制器開發(fā)過程中都要求采用ISO 26262的功能安全標(biāo)準(zhǔn)。由于功能安全標(biāo)準(zhǔn)制定了汽車整個生命周期中與安全相關(guān)的所有活動，內(nèi)容繁雜、細(xì)化規(guī)則多、專業(yè)術(shù)語多，很容易讓人陷入某個細(xì)節(jié)而無法理解整體目標(biāo)。

今天我們針對重點內(nèi)容做個簡化的介紹，便于快速理解！

1.功能安全的概念

汽車功能安全的定義是“不存在由電子電氣系統(tǒng)的功能異常表現(xiàn)引起的危害而導(dǎo)致不合理的風(fēng)險”，就是說汽車上各種E/E模塊在功能失效時不能給人員帶來傷害。

簡單的說，功能安全就是“功能”失效時要保證人的“安全”！

2.功能安全的目的

功能安全的目的是為了降低來自系統(tǒng)性失效和隨機硬件失效的風(fēng)險。

簡單地說，功能安全的目的就是降低風(fēng)險，避免傷人！

3.功能安全的內(nèi)容

功能安全的內(nèi)容不僅僅是產(chǎn)品功能本身，還包括需求、研發(fā)、驗證、生產(chǎn)、運行、維保等產(chǎn)品生命周期內(nèi)的所有活動及管理過程，功能安全需要第三方認(rèn)證時也是分為體系和產(chǎn)品兩種認(rèn)證。

4．功能安全的分級

功能安全根據(jù)嚴(yán)重度S、暴露概率E和可控性C三個因素分為A、B、C、D四個等級。

ASIL A-D為安全等級，QM質(zhì)量管控為非安全等級

其中的嚴(yán)重度S分為4級，從無傷害到致命傷害；暴露頻率分5級，從不可能到高概率；可控制性C分4級，從可控到難以控制或不可控。

S、E、C分級說明

ASIL四個等級中A最低，D最高，等級越高，意味著該產(chǎn)品失效后可能引起的安全風(fēng)險越大，這時產(chǎn)品的研發(fā)嚴(yán)格程度越高、研發(fā)成本越多、研發(fā)驗證周期也越長。

這里要注意的是ASIL的分級要從三個因素綜合考慮，單一因素等級很高，不一定是屬于安全等級。比如有些風(fēng)險嚴(yán)重度很高，但頻率很低，就不一定是安全等級，可能屬于質(zhì)量管控QM。

5.產(chǎn)品相關(guān)的功能安全

功能安全標(biāo)準(zhǔn)提供了產(chǎn)品整個生命周期的方法論，涉及內(nèi)容廣泛，但是工程師們最關(guān)注的還是產(chǎn)品設(shè)計開發(fā)相關(guān)的標(biāo)準(zhǔn)。

功能安全中的產(chǎn)品適合應(yīng)用于車輛中的電子、電氣、軟件組件安全相關(guān)的產(chǎn)品，可以是整個系統(tǒng)，也可以是硬件模塊、嵌入式軟件、半導(dǎo)體IC等產(chǎn)品，比如某款MCU芯片通過功能安全ASIL-B產(chǎn)品認(rèn)證。

產(chǎn)品相關(guān)的部分主要包括概念階段、產(chǎn)品開發(fā)中的系統(tǒng)層面、硬件層面和軟件層面。

產(chǎn)品設(shè)計開發(fā)相關(guān)部分

5.1概念階段

概念階段要做的工作是相關(guān)項定義、危害分析和風(fēng)險評估、功能安全概念。

相關(guān)項的定義就是確定功能安全的研究對象，包括產(chǎn)品功能、接口、環(huán)境條件和法規(guī)要求等，這一步實際上就是要先把產(chǎn)品的主要功能梳理清楚。

危害分析和風(fēng)險評估HARA是基于相關(guān)項展開，進行功能失效分析和整車危害分析，對危害事件根據(jù)S、E、C三個維度進行ASIL等級評定，這一步的主要目的是確定安全目標(biāo)。

危害分析和風(fēng)險評估HARA

安全目標(biāo)中應(yīng)包括FTTI ，即“故障容忍時間間隔(Fault Tolerant TimeInterval)”，這是保障生命安全的重要性能指標(biāo)。

功能安全概念就是要根據(jù)安全目標(biāo)和初始的系統(tǒng)架構(gòu)，確定功能安全概念層面的安全需求FSR。

5.2產(chǎn)品開發(fā)

產(chǎn)品開發(fā)涉及到了ECU的具體設(shè)計部分，包括系統(tǒng)層面、硬件層面和軟件層面。這三個層面的開發(fā)流程是個V模型，先進行系統(tǒng)分析設(shè)計、然后是硬件、軟件設(shè)計及其測試，最后是系統(tǒng)測試和確認(rèn)。

產(chǎn)品開發(fā)V模型

5.2.1系統(tǒng)層面

系統(tǒng)層面

系統(tǒng)層面中的技術(shù)安全實際上就是針對概念階段中提出的功能安全的拆解，它是根據(jù)系統(tǒng)的設(shè)計方案來分析。

比如一個ECU可以分為很多個模塊，電源、通信、AD采樣、IO輸出等，可以分別分析每個模塊可能的失效模式，分析其對功能安全要求的影響程度。

如果某個模塊的失效違背了功能安全要求，那么就要對這個模塊分配相應(yīng)的設(shè)計要求，這個設(shè)計要求就是技術(shù)安全要求。

集成和測試是常規(guī)開發(fā)流程，安全確認(rèn)是為了確認(rèn)安全需求是否正確，按照預(yù)期的實現(xiàn)后，能否能達到安全目標(biāo)。

這里要說明的是，系統(tǒng)的技術(shù)安全概念完成后并不能直接進入系統(tǒng)集成和測試，而是要先進入硬件層面和軟件層面。

5.2.2 硬件層面

硬件層面就要對系統(tǒng)層面提出的模塊進行硬件的拆解分析，確定硬件安全要求，硬件層面的內(nèi)部開發(fā)過程也是個V模型。

硬件層面

硬件安全的拆解要進一步細(xì)化，比如電源模塊失效時的欠壓或者過壓值是多少？當(dāng)欠壓或過壓時，要執(zhí)行的安全機制是什么？重啟還是強制斷電還是發(fā)出報警信息？MCU是否需要兩路完全獨立的電源供電等等。

硬件架構(gòu)設(shè)計也要遵循一定的功能安全原則：

硬件架構(gòu)設(shè)計原則

對于硬件架構(gòu)設(shè)計原則表格里的技術(shù)或方法，一個+號表示建議實施，兩個+號表示強烈建議實施。

硬件層面中還有個概念叫硬件隨機失效，我們在做功能安全時，主要關(guān)注兩種失效，系統(tǒng)性失效和隨機硬件失效。

隨機硬件失效是指在硬件要素的生命周期中，非預(yù)期發(fā)生并服從概率分布的失效。因此只有硬件會發(fā)生隨機失效，軟件不會。

隨機失效與硬件的設(shè)計無關(guān)，即使硬件的設(shè)計是正確的，元器件也符合質(zhì)量標(biāo)準(zhǔn)，但隨機失效仍然會發(fā)生，而且無法預(yù)知。

隨機失效雖然無法預(yù)知，但是失效率可以在合理的精度范圍內(nèi)進行預(yù)測，也就是可以進行定量評估的。

另外一個系統(tǒng)性失效是指以確定的方式與某個原因相關(guān)的失效，只有對設(shè)計或生產(chǎn)流程、操作規(guī)程、文檔或其他相關(guān)因素進行變更后才可能排除這種失效。

不同于隨機硬件失效的不可預(yù)知性，系統(tǒng)性失效的形式是確定的，只要滿足相應(yīng)條件就一定會發(fā)生。從另一個角度來說，系統(tǒng)性失效是可以復(fù)現(xiàn)的。硬件和軟件都會產(chǎn)生系統(tǒng)性失效。

當(dāng)找到造成失效的確定方式后，可以采取對應(yīng)的措施，如修復(fù)軟件bug、更改電路設(shè)計等就可以有效避免系統(tǒng)性失效。

6 軟件開發(fā)層面

軟件自身的開發(fā)也是一個V模型，從產(chǎn)品開發(fā)概述、安全定義到最后的軟件測試。

軟件層面

軟件層面也是從系統(tǒng)層面提出的模塊分解為軟件安全要求，軟件安全分析可以采用歸納的方法，也可以采用演繹的方法。

歸納就是自下而上分析，先分析底層單元有什么失效模式，再找出其對頂層安全要求的影響。比如底層采樣值的計算錯誤會導(dǎo)致頂層的ECU無法輸出正確的控制信號。

演繹就是自上而下，比如ECU的安全目標(biāo)是能夠輸出正確的控制信號。

這時就需要根據(jù)軟件架構(gòu)從一層層排查，最后排查出哪些底層原因會導(dǎo)致輸出錯誤的控制信號。比如邏輯運算錯誤、數(shù)據(jù)存儲失效會影響頂層的安全目標(biāo)，那么這兩部分就要被分配相應(yīng)的安全要求。

與硬件不同，軟件只有系統(tǒng)性失效，而沒有隨機硬件失效，其中比較重要的是軟件架構(gòu)設(shè)計，軟件架構(gòu)也要遵循一定的原則。

軟件架構(gòu)原則

軟件開發(fā)完成后，再重新回到系統(tǒng)層面，進入系統(tǒng)及相關(guān)項集成和測試、安全確認(rèn)，完成一個大的V模型流程。

產(chǎn)品開發(fā)V模型

7.功能安全示例

下面我們以BCM的燈光控制為例，做一個簡單的流程說明，便于大家更直觀的理解。

產(chǎn)品設(shè)計開發(fā)相關(guān)流程

7.1概念階段

相關(guān)項定義：BCM的主要功能是燈光控制、門鎖控制、車窗控制、雨刮控制、發(fā)動機防盜、胎壓監(jiān)測等。其中燈光控制中的剎車燈如果失效，會導(dǎo)致后方車輛看不到前車剎車提醒，有一定風(fēng)險，屬于相關(guān)項。

危害分析和風(fēng)險評估：行車過程中，如果剎車燈不能點亮則無法及時提醒后方車輛剎車或減速，有被追尾的風(fēng)險。

根據(jù)三個維度初步判斷安全等級為ASIL B級，安全目標(biāo)為剎車燈應(yīng)按預(yù)期點亮。

7.2產(chǎn)品開發(fā)-系統(tǒng)層面

BCM的燈光控制中的剎車燈相關(guān)的系統(tǒng)架構(gòu)如下圖所示：

剎車燈系統(tǒng)架構(gòu)圖

相關(guān)軟硬件的接口描述如下：

1.MCU通過硬線信號和CAN收發(fā)器接收剎車相關(guān)信息；

2.MCU根據(jù)相關(guān)輸入信息控制剎車燈點亮邏輯；

3.MCU控制高邊芯片驅(qū)動剎車燈輸出；

4.MCU和HSD通過SBC提供電源。

根據(jù)系統(tǒng)架構(gòu)，初步安全分析可知，要滿足安全目標(biāo)，剎車燈功能需滿足如下幾點：

1.安全的信息接收；

2.安全的處理邏輯；

3.安全的驅(qū)動輸出；

4.安全的電源供電。

7.3產(chǎn)品開發(fā)-硬件層面

硬件層面需先定義硬件安全需求 HSR，細(xì)化軟硬件接口（HSI）規(guī)范；再做硬件安全分析 FMEA/FTA/DFA、計算硬件架構(gòu)度量指標(biāo) SPFM、LFM并評估由于隨機硬件失效導(dǎo)致的安全目標(biāo)違背的概率 PMHF；最后是硬件集成和測試，驗證 HSR。

具體設(shè)計內(nèi)容可以從電路設(shè)計異構(gòu)、自檢、驅(qū)動芯片診斷、獨立供電、看門狗等方面考慮。

7.4產(chǎn)品開發(fā)-軟件層面

軟件層面也需要先定義軟件安全需求 SSR；再設(shè)計軟件架構(gòu) AD，并進行軟件層面的安全分析FMEA 和相關(guān)失效分析DFA；完成軟件單元設(shè)計UD 和實現(xiàn)，然后進行軟件單元測試驗證，最后是嵌入式軟件測試，驗證 SSR。

具體設(shè)計內(nèi)容可從軟件功能單元解耦、錯誤探測和錯誤處理的安全機制，如軟件自檢、CAN通信超時處理、驅(qū)動診斷邏輯和診斷故障處理機制方面考慮。

此外，在實際應(yīng)用中，某些安全目標(biāo)如果難以直接達到，還可以進行ASIL分解。ASIL分解是可以將一條功能安全需求分解成兩條相互獨立的需求并分配到兩個及兩個以上相互獨立的元素（如軟件模塊、硬件模塊、輸入信號等）上。

這樣一個ASIL D可以分解為一個ASIL C和一個ASIL A或分解為兩個ASIL B。對每個元素來說降低了對功能安全需求的ASIL等級。

8 小結(jié)

功能安全是覆蓋產(chǎn)品整個生命周期的方法論，最終目的是保證產(chǎn)品不因E/E系統(tǒng)的故障而產(chǎn)生對人的不合理危害。

產(chǎn)品開發(fā)相關(guān)的內(nèi)容主要是概念階段、系統(tǒng)階段和軟硬件開發(fā)階段。

功能安全失效主要分兩種，軟硬件的系統(tǒng)性失效和硬件的隨機失效。系統(tǒng)性失效是可復(fù)現(xiàn)的，可以通過設(shè)計方法、流程控制改善。硬件隨機失效是電子器件本身的特性，不可復(fù)現(xiàn)，也無法通過設(shè)計或流程控制等改善。

功能安全的過程，就是自上而下，從系統(tǒng)到軟硬件逐層分析、拆解，細(xì)化安全需求，制定應(yīng)對策略，通過精確的設(shè)計，盡可能減少故障發(fā)生時對人員的傷害！