什么是功能安全？一文帶你認(rèn)識(shí)功能安全

引言

一篇文章帶你認(rèn)識(shí)功能安全

隨著各行各業(yè)在產(chǎn)品開發(fā)設(shè)計(jì)和測試過程中都采用了一套標(biāo)準(zhǔn)化的實(shí)踐，安全實(shí)踐也變得越來越規(guī)范。汽車行業(yè)也不例外，功能安全標(biāo)準(zhǔn) ISO-26262 滿足了針對安全關(guān)鍵零部件的汽車專用國際標(biāo)準(zhǔn)的需求。ISO-26262是電氣和電子（E/E）系統(tǒng)的通用功能安全標(biāo)準(zhǔn)。本文將結(jié)合ISO-26262，從什么是功能安全、什么是功能安全工程師以及功能安全工程師主要做什么，三個(gè)方面展開對功能安全的介紹。

01

什么是功能安全

1

背景簡介

由于汽車的復(fù)雜性，整個(gè)行業(yè)正在致力于提供符合安全要求的零部件系統(tǒng)。比如，線控油門系統(tǒng)，當(dāng)駕駛員踩下油門踏板，踏板上的傳感器向控制器發(fā)送信號(hào)時(shí)，控制器會(huì)綜合分析如發(fā)動(dòng)機(jī)轉(zhuǎn)速、車輛速度、踏板位置等信號(hào)，然后將控制指令發(fā)送給油門本體。測試和驗(yàn)證線控油門系統(tǒng)等是汽車行業(yè)面臨的一個(gè)挑戰(zhàn)。ISO 26262的目標(biāo)就是為所有汽車E/E系統(tǒng)提供一個(gè)統(tǒng)一的安全標(biāo)準(zhǔn)。

脫胎于IEC-61508的功能安全I(xiàn)SO-26262的國際標(biāo)準(zhǔn)草案于2009年6月發(fā)布。從草案發(fā)布開始，ISO-26262已經(jīng)在汽車行業(yè)獲得了廣泛的關(guān)注。工程師將ISO-26262視為最先進(jìn)的技術(shù)狀態(tài)（state-of-the-art）。該技術(shù)的技術(shù)狀態(tài)在特定時(shí)間是開發(fā)設(shè)備或流程的最高水準(zhǔn)。汽車制造商一般要對因產(chǎn)品故障而造成的損害負(fù)責(zé)。ISO-26262在汽車行業(yè)是一個(gè)通用標(biāo)準(zhǔn)，它提供了一種衡量系統(tǒng)安全性的方法。

圖1: 安全相關(guān)系統(tǒng)

ISO-26262使用V-Model來管理功能安全，并在系統(tǒng)、軟件和硬件級(jí)別上規(guī)范產(chǎn)品的開發(fā)。ISO-26262標(biāo)準(zhǔn)提供了整個(gè)產(chǎn)品開發(fā)過程中的法規(guī)和建議——從概念階段到產(chǎn)品報(bào)廢階段。它詳細(xì)說明了如何為系統(tǒng)和組件分配一個(gè)可接受的風(fēng)險(xiǎn)級(jí)別，并對整個(gè)測試過程進(jìn)行記錄。一般來說，ISO 26262：

提供了汽車整個(gè)安全生命周期 （管理，開發(fā)，生產(chǎn)，運(yùn)營，服務(wù)，退役），并支持在這些生命周期階段中定制必要的活動(dòng)；

提供了一種基于汽車特定風(fēng)險(xiǎn)的方法來確定風(fēng)險(xiǎn)類別（ASIL）;

使用ASIL來指定項(xiàng)目的必要安全要求，以實(shí)現(xiàn)可接受的殘余風(fēng)險(xiǎn)；

提供了驗(yàn)證和確認(rèn)措施的要求，以確保達(dá)到足夠和可接受的安全水平；

2

評估風(fēng)險(xiǎn)——危害分析和風(fēng)險(xiǎn)評估（HARA）

當(dāng)我們對新開發(fā)的車型有了清晰的定義后，也就打響了汽車功能安全的第一槍。我們需要用HARA來識(shí)別和評估潛在的危險(xiǎn)。一般來講， OEM的功能安全工程師會(huì)對車輛級(jí)的功能進(jìn)行HARA分析，以識(shí)別潛在的危險(xiǎn)場景，并確定每個(gè)潛在危險(xiǎn)所需的風(fēng)險(xiǎn)降低水平。HARA考慮了在特定駕駛場景中暴露于潛在危險(xiǎn)情況的頻率和持續(xù)時(shí)間（Exposure），糾正故障行為以減輕潛在危險(xiǎn)所需的控制量（Controllability），以及在故障行為發(fā)生時(shí)潛在后果的嚴(yán)重程度（Severity）。

HARA是在車輛層面的特性上進(jìn)行的，而不是在零部件或者要素層面。對于每一個(gè)潛在的危險(xiǎn)，都考慮了一些潛在的駕駛方案。比如：在前向碰撞緩解系統(tǒng)中，將根據(jù)不同的駕駛場景，如操作速度和駕駛條件，評估非預(yù)期制動(dòng)的潛在危險(xiǎn)。

3

分配安全等級(jí)——功能安全完整性等級(jí)（ASIL）

在HARA過程中，OEM為每個(gè)已識(shí)別的潛在風(fēng)險(xiǎn)分配了一個(gè)ASIL （AutomotiveSafety Integrity Level）等級(jí)。ASIL在開發(fā)過程中就已經(jīng)確定了。根據(jù)可能存在的風(fēng)險(xiǎn)。

圖2：功能安全等級(jí)評定

比如：如果某輛車的邁速表出了故障，從車子啟動(dòng)開始就不顯示任何信息，場景可以歸類為QM，因?yàn)樗緳C(jī)可以很容易地感知故障，并且選擇不開車或者非常謹(jǐn)慎的駕駛。換言之，場景的可控性非常高，而嚴(yán)重程度則很低。相比之下，如果車輛無法進(jìn)行控制，駕駛員在高速行駛時(shí)剎車失靈的情況可以歸類于ASIL-D，因?yàn)檫@時(shí)導(dǎo)致人嚴(yán)重受傷的概率很高。

為了適當(dāng)?shù)亟鉀Q這些情況，ISO 26262使用ASIL評級(jí)來確定供應(yīng)商必須采取的開發(fā)步驟的嚴(yán)格性，并定義了安全目標(biāo)（safetygoal）的要求：

1. FIT率（FailureIn Time）: FIT率是車輛在給定時(shí)間段內(nèi)可接受的故障率。車輛必須滿足ASIL評級(jí)所規(guī)定的FIT率，但OEM也可以靈活地為系統(tǒng)內(nèi)的基礎(chǔ)組件選擇FIT率。

2. 安全概念（Safety Concept）：安全概念決定如何檢測顧故障及如何控制故障，具有更高ASIL評級(jí)的系統(tǒng)需要更嚴(yán)格的故障檢測和響應(yīng)能力。

3. 安全要求（SafetyRequirements）：安全要求規(guī)定了對任何給定故障的適當(dāng)響應(yīng)。比如，傳感器檢測到與內(nèi)部安全相關(guān)的問題，如內(nèi)存損壞，故障響應(yīng)系統(tǒng)可能會(huì)在規(guī)定的時(shí)間內(nèi)終止通過控制器的通信，以便向其他系統(tǒng)指示其故障狀態(tài)。這是安全要求所描述的典型的安全機(jī)制——但故障響應(yīng)系統(tǒng)并不總是恰當(dāng)合適的。如：對于智駕功能，車輛可能采用故障操作系統(tǒng)，這要求冗余系統(tǒng)接管必要的時(shí)間，以使車輛處于最小的風(fēng)險(xiǎn)狀態(tài)（比如，安全停車在路邊）。對于系統(tǒng)故障，遵循嚴(yán)格的開發(fā)過程有助于增加該功能將以一種安全的方式運(yùn)行的信心。

4

持續(xù)的測試和集成

汽車功能安全在整個(gè)開發(fā)過程中都采用了V模型。V模型要求，對于開發(fā)的每一步驟，在測試中都必須對應(yīng)有一個(gè)相應(yīng)的步驟。供應(yīng)商定期評估其開發(fā)過程，以確保硬件和軟件開發(fā)都遵循了所需要的步驟。

圖3：V字開發(fā)模型

OEM，供應(yīng)商或者獨(dú)立的第三方公司對所有相關(guān)的工作產(chǎn)出物進(jìn)行功能安全審核和評估，以確保功能安全的實(shí)現(xiàn)。功能安全需求一個(gè)全面的管理過程，以確保適當(dāng)?shù)谋O(jiān)督和完整的系統(tǒng)集成。

02

什么是功能安全工程師，

功能安全工程師做什么？

關(guān)于什么是功能安全工程師？這個(gè)問題乍一看很好回答，但如果仔細(xì)思考下就會(huì)發(fā)現(xiàn)，想找到真實(shí)統(tǒng)一的答案卻并不容易。比如擁有完善開發(fā)體系流程的大公司和初創(chuàng)的小公司，他們對功能安全工程師的定義大概率是不同的。思來想去，還是決定以一個(gè)新項(xiàng)目為例，來說明下什么是功能安全工程師以及在產(chǎn)品開發(fā)過程中功能安全工程師做什么。

1

報(bào)價(jià)階段

1.安全要求的分析與澄清：

功能安全工程師要對客戶的安全輸入進(jìn)行分析，以確認(rèn)公司內(nèi)部產(chǎn)品的安全要求是否與客戶匹配。通常會(huì)以會(huì)議的形式跟客戶討論和澄清相關(guān)安全要求。

2. 執(zhí)行影響分析：

分析完客戶的安全要求之后，一般功能安全工程師還會(huì)做影響分析，以確定公司內(nèi)部的平臺(tái)項(xiàng)目或者已經(jīng)量產(chǎn)的其他客戶項(xiàng)目是否有可以直接復(fù)用的功能，或者修改之后可以復(fù)用的功能。如果是全新的產(chǎn)品開發(fā)，則客戶忽略影響分析。

3.開發(fā)接口協(xié)議（DIA）責(zé)任劃分：

弄清楚產(chǎn)品的開發(fā)邊界之后，功能安全工程師要跟客戶去確定每一方的開發(fā)責(zé)任范圍，并明確開發(fā)過程中的產(chǎn)出物的責(zé)任方以及雙方如何進(jìn)行產(chǎn)出物的交互，雙方對以上內(nèi)容都打成一致后，DIA也就完成了。最后別忘了雙方都需要在DIA上簽字。

4.準(zhǔn)備項(xiàng)目功能安全計(jì)劃和安全檔案：

在報(bào)價(jià)階段，功能安全工程師要根據(jù)項(xiàng)目的時(shí)間計(jì)劃以及客戶的安全輸入來準(zhǔn)備初版的項(xiàng)目功能安全計(jì)劃（主要內(nèi)容是計(jì)劃管理和指導(dǎo)整個(gè)項(xiàng)目開發(fā)過程中的安全活動(dòng)的執(zhí)行，包含日期、關(guān)鍵節(jié)點(diǎn)、任務(wù)、可交付的成果、職責(zé)和資源等）以及安全檔案（主要內(nèi)容是與客戶闡明所開發(fā)的產(chǎn)品已經(jīng)按照ISO 26262的要求進(jìn)行開發(fā)并實(shí)現(xiàn)了功能安全所準(zhǔn)備的證據(jù)，包含產(chǎn)品開發(fā)各個(gè)階段的關(guān)鍵產(chǎn)出物的記錄，產(chǎn)出物的評審記錄等）。

5.準(zhǔn)備評審會(huì)議：

以上內(nèi)容都完成之后，功能安全工程師就可以跟審核員（Assessor）約評審會(huì)議了。在會(huì)上，審核員會(huì)根據(jù)功能安全工程師準(zhǔn)備的證據(jù)對該項(xiàng)目的產(chǎn)品開發(fā)成熟度進(jìn)行評估以確認(rèn)是否滿足當(dāng)前的開發(fā)需要，以及是否有安全相關(guān)的風(fēng)險(xiǎn)，并輸出當(dāng)前階段的評估報(bào)告。

【注】：由于每家公司的開發(fā)流程不同，所以對功能安全評估次數(shù)要求也不同，但基本都會(huì)在項(xiàng)目的關(guān)鍵節(jié)點(diǎn)進(jìn)行功能安全評估。

6.相關(guān)項(xiàng)定義以及危害分析：

如果站在主機(jī)廠角度，功能安全工程師要完成所開發(fā)產(chǎn)品的相關(guān)頂定義（主要內(nèi)容是在整車層面對相關(guān)項(xiàng)進(jìn)行定義和描述，包括功能，及其與駕駛員、環(huán)境和其他相關(guān)項(xiàng)之間的依賴性和相互之間的影響），并對其進(jìn)行危害分析和風(fēng)險(xiǎn)評估（主要是識(shí)別并分類由相關(guān)項(xiàng)中的功能異常表現(xiàn)引起的危害事件，以及定制防止危害事件發(fā)聲或者減輕危害程度的安全目標(biāo)及其安全等級(jí)，來避免不合理的風(fēng)險(xiǎn)），以便得出產(chǎn)品的頂層功能安全目標(biāo)，以及功能安全概念，并打包發(fā)給供應(yīng)商。

2

概念設(shè)計(jì)階段

功能安全概念/要求開發(fā)：功能安全工程師要完成功能安全概念/要求（FSC/FSRs）的開發(fā)。功能安全概念的主要目的如下：

1)要根據(jù)功能安全目標(biāo)定義產(chǎn)品的功能性或者降級(jí)的功能性行為；

2)要根據(jù)功能安全目標(biāo)定義關(guān)于合理地、及時(shí)地檢測和控制相關(guān)故障的約束條件；

3)要定義產(chǎn)品層面的策略或者是措施，以通過產(chǎn)品本身、司機(jī)或者外部的措施來實(shí)現(xiàn)故障容錯(cuò)或者減小對相關(guān)故障的影響；

4)把功能安全要求分配給系統(tǒng)架構(gòu)設(shè)計(jì)；

5)確認(rèn)功能安全概念并且定義號(hào)安全確認(rèn)的準(zhǔn)則；

圖4：功能安全目標(biāo)和安全要求層級(jí)

3

開發(fā)設(shè)計(jì)階段

系統(tǒng)開發(fā)設(shè)計(jì)

1. 技術(shù)安全概念/要求開發(fā)：

功能安全工程師要完成（或者協(xié)助系統(tǒng)需求工程師完成）TSC/TSRs的開發(fā)。技術(shù)安全概念的主要目的如下：

a. 制定系統(tǒng)要素和接口關(guān)于功能、相關(guān)性、約束和屬性方面實(shí)施中所需的技術(shù)安全要求；

b. 制定系統(tǒng)要素和接口實(shí)施安全機(jī)制的技術(shù)安全要求；

c. 制定在生產(chǎn)、運(yùn)行、服務(wù)和報(bào)廢中系統(tǒng)及其要素功能安全的相關(guān)要求；

d. 驗(yàn)證技術(shù)安全要求在系統(tǒng)層級(jí)是否符合功能安全要求并與功能安全要求一致；

e. 制定滿足安全要求且不與非安全相關(guān)要求沖突的系統(tǒng)架構(gòu)設(shè)計(jì)和技術(shù)安全概念；

f. 分析系統(tǒng)架構(gòu)設(shè)計(jì)，防止故障并為生產(chǎn)和服務(wù)得出必要的安全相關(guān)特殊特性；

g. 按照各自的ASIL等級(jí)，驗(yàn)證系統(tǒng)架構(gòu)設(shè)計(jì)和技術(shù)安全概念是否適用于滿足安全要求；

圖5：系統(tǒng)層面的產(chǎn)品開發(fā)

2. 安全機(jī)制的裁剪：

一般在產(chǎn)品設(shè)計(jì)初期，開發(fā)人員已經(jīng)完成了關(guān)鍵芯片（比如：Micro-controller, SBC, ASIC, Driver ICs, Intelligence Sensor等）的選型。功能安全工程師在此階段還要主導(dǎo)完成對芯片手冊安全機(jī)制的裁剪活動(dòng)，哪些是產(chǎn)品所必須用到的，哪些是可以裁剪的，并給出充分的理由。

3. 系統(tǒng)安全架構(gòu)開發(fā)：

有了系統(tǒng)需求，系統(tǒng)架構(gòu)，功能安全要求和技術(shù)安全要求后，功能安全工程師就可以開始設(shè)計(jì)（或者協(xié)助系統(tǒng)架構(gòu)工程師設(shè)計(jì)）系統(tǒng)安全架構(gòu)了。設(shè)計(jì)系統(tǒng)安全架構(gòu)要注意以下幾點(diǎn)：

a. 確保系統(tǒng)安全架構(gòu)和前面階段的系統(tǒng)架構(gòu)設(shè)計(jì)的一致性；

b. 系統(tǒng)安全架構(gòu)要能實(shí)現(xiàn)技術(shù)安全要求；（相應(yīng)的安全要求和安全機(jī)制最好能體現(xiàn)在系統(tǒng)安全架構(gòu)中）

c. 設(shè)計(jì)的系統(tǒng)安全架構(gòu)能否被充分驗(yàn)證，預(yù)期的軟硬件設(shè)計(jì)是否能滿足此系統(tǒng)安全架構(gòu)，是否方便于系統(tǒng)集成時(shí)測試的執(zhí)行；

d. 設(shè)計(jì)時(shí)要充分考慮安全相關(guān)的內(nèi)部和外部接口；

e. 如果此階段需要進(jìn)行ASIL等級(jí)的降級(jí)分解，要按照ASIL的要求進(jìn)行分解；

4. 啟動(dòng)系統(tǒng)層面的安全分析：

有了完整的安全要求和系統(tǒng)安全架構(gòu)之后，功能安全工程師就可以啟動(dòng)系統(tǒng)層面的安全分析（FMEA分析，F(xiàn)TA分析，DFA分析）了。執(zhí)行安全分析的主要目的在于：提供證據(jù)證明系統(tǒng)設(shè)計(jì)實(shí)現(xiàn)了相應(yīng)ASIL等級(jí)的功能安全要求、識(shí)別失效原因和故障影響、識(shí)別或者確認(rèn)安全相關(guān)系統(tǒng)組件和接口。

a. FMEA分析：FMEA是一種定性的、歸納式的單點(diǎn)故障分析方法，主要是在早期檢測和消除產(chǎn)品設(shè)計(jì)和制造過程中的薄弱點(diǎn)。

b. FTA分析：FTA是一種演繹式故障分析，它使用布爾邏輯來分析系統(tǒng)不期望的狀態(tài)，以結(jié)合一系列較低級(jí)的事件。FTA的目標(biāo)是分析在系統(tǒng)中發(fā)生的實(shí)際故障的路徑，以定位系統(tǒng)故障的原因。

c. DFA分析：DFA的主要目的是通過分析潛在原因或者誘發(fā)因素，來確認(rèn)設(shè)計(jì)中已經(jīng)充分實(shí)現(xiàn)了要求的獨(dú)立性（Independence獨(dú)立性是指在兩個(gè)或者多個(gè)元素之間沒有級(jí)聯(lián)故障和共因故障，從而可能導(dǎo)致違背安全目標(biāo)），或相互之間免于干擾（FFI免于干擾是指在兩個(gè)或者多個(gè)元素之間沒有可能導(dǎo)致違反安全要求的級(jí)聯(lián)故障）。如果有必要的話，也可以制定相應(yīng)安全措施，來減輕可能的相關(guān)失效。

圖６：不同類型的相關(guān)性失效之間的關(guān)系

硬件開發(fā)設(shè)計(jì)

1. 硬件安全要求開發(fā)：

有了系統(tǒng)層面的安全要求、安全架構(gòu)和安全分析的輸入后，功能安全工程師就可以開始開發(fā)（或者協(xié)助硬件工程師開發(fā)）硬件安全要求了。硬件安全要求主要從分配給硬件的技術(shù)安全要求和系統(tǒng)架構(gòu)設(shè)計(jì)中導(dǎo)出。

圖７：硬件層面的產(chǎn)品開發(fā)

2. 硬件安全架構(gòu)設(shè)計(jì)：

硬件安全架構(gòu)設(shè)計(jì)主要是硬件架構(gòu)師來負(fù)責(zé)，功能安全工程師協(xié)助支持，并支持做硬件架構(gòu)的評審。硬件安全架構(gòu)應(yīng)盡量滿足模塊化、適當(dāng)?shù)牧６人?、簡單性等特征。在硬件架?gòu)設(shè)計(jì)過程中，也可以參考ISO 26262第５部分中硬件架構(gòu)的設(shè)計(jì)方法（Table1）。

圖８－硬件架構(gòu)設(shè)計(jì)原則

3. 軟硬件接口列表（HSI）：

在硬件設(shè)計(jì)階段，功能安全工程師還要協(xié)助硬件工程師完成軟硬件接口列表的設(shè)計(jì)。在定義軟硬件接口時(shí)，要考慮好以下的要素：

a. 存儲(chǔ)器（RAM,ROM等）；

b. 總線接口（CAN, LIN等）；

c. 轉(zhuǎn)換器（A/D，D/A，ＰＷＭ）；

d. Ｉ/O口；

e. 看門狗（內(nèi)狗，外狗）；

f. 多路轉(zhuǎn)換器；

【注】：每家公司對HSI的責(zé)任劃分也是不同的，有的可能要求系統(tǒng)工程師或者軟件工程師主導(dǎo)HSI的定義。

圖９：軟硬件接口概覽

4. 硬件安全分析：

功能安全工程師要協(xié)助硬件工程師進(jìn)行硬件層面的安全分析，包括FMEA和FMEDA分析。

a. FMEA分析：硬件FMEA分析直接在系統(tǒng)FMEA分析的基礎(chǔ)上繼續(xù)對硬件組件進(jìn)行分析就可以了。

b. FMEDA分析：FMEDA的計(jì)算，需要的輸入比較多（如：安全目標(biāo)，硬件失效率目標(biāo)值，安全要求，安全架構(gòu)，BOM表，Mission Profile，安全機(jī)制列表，SN29500的基礎(chǔ)失效率等），有了這些輸入就可以開始FMEDA的計(jì)算了，以檢查所設(shè)計(jì)的硬件產(chǎn)品的三個(gè)指標(biāo)值（SPFM，LFM，PMHF）是否滿足相應(yīng)ASIL等級(jí)的要求。

圖10：硬件失效率度量指標(biāo)值

軟件開發(fā)設(shè)計(jì)

1. 軟件安全要求開發(fā)：

與硬件開發(fā)類似，有了技術(shù)安全要求、系統(tǒng)需求和系統(tǒng)架構(gòu)、硬件設(shè)計(jì)規(guī)范、軟硬件接口列表和軟件開發(fā)環(huán)境的輸入后，功能安全工程師就可以協(xié)助軟件需求工程師來開發(fā)軟件安全要求了。軟件安全要求一般來源于分配給軟件的技術(shù)安全要求或者軟件功能和特性的要求（如：能夠安全執(zhí)行相關(guān)功能，能夠使系統(tǒng)達(dá)到或者維持安全狀態(tài)的相關(guān)功能等）。

圖11：軟件層面的產(chǎn)品開發(fā)

2. 軟件安全架構(gòu)：

軟件安全架構(gòu)設(shè)計(jì)主要是軟件架構(gòu)師來負(fù)責(zé)，功能安全工程師協(xié)助支持，并支持做軟件架構(gòu)的評審活動(dòng)。軟件架構(gòu)的設(shè)計(jì)要盡量滿足一致性、簡單性、可驗(yàn)證性、模塊化、可維護(hù)性等特征。在軟件架構(gòu)設(shè)計(jì)中也可以參考ISO 26262第６部分中軟件架構(gòu)設(shè)計(jì)的方法（Table2, Table3 和Table４）。

圖12：軟件架構(gòu)設(shè)計(jì)原則

3. 軟件單元設(shè)計(jì)和實(shí)現(xiàn)：

軟件單元設(shè)計(jì)與實(shí)現(xiàn)主要由軟件開發(fā)人員負(fù)責(zé)，功能安全工程師能提供的支持相對有限。與軟件架構(gòu)設(shè)計(jì)類似，軟件單元設(shè)計(jì)也應(yīng)盡量滿足一致性、可維護(hù)性、可驗(yàn)證性等特性。在軟件單元設(shè)計(jì)和實(shí)現(xiàn)的活動(dòng)中，也可以參考ISO 26262第６部分中軟件單元設(shè)計(jì)的方法（Table5, Table6）。

圖13：軟件單元設(shè)計(jì)和實(shí)現(xiàn)的設(shè)計(jì)原則

4. 軟件安全分析：

功能安全工程師要協(xié)助軟件工程師完成軟件的安全分析。與硬件相比，軟件安全分析沒有特定的方法，有的公司要求做軟件FMEA分析；而有的公司覺得用FMEA的思路來做軟件安全分析也并不是特別合適，這時(shí)候通常采用一種軟件關(guān)鍵路徑分析的方法來對軟件進(jìn)行安全分析（需要軟件的動(dòng)態(tài)架構(gòu)和靜態(tài)架構(gòu)來支持分析）。

4

測試驗(yàn)證階段

對于各個(gè)階段的測試話題，由于很少有公司要求功能安全工程師去執(zhí)行測試活動(dòng)，這里只簡單聊一聊各個(gè)階段的測試以及功能安全工程師在測試驗(yàn)證階段要做些什么。

在各個(gè)階段的測試開始之前，功能安全工程師要主導(dǎo)ISO 26262方法的裁剪活動(dòng)。功能安全工程師要跟系統(tǒng)、軟硬件和相關(guān)測試工程師一起，完成對ISO 26262方法的裁剪，被裁剪掉的方法要給出充分合理的理由。（“＋＋“代表高度推薦該方法，一般不能裁剪掉；“＋”代表推薦該方法，如果有合理的理由可以進(jìn)行裁剪；“ｏ”代表不推薦該方法）

系統(tǒng)測試驗(yàn)證

系統(tǒng)階段的測試一般包含以下幾種：

a)系統(tǒng)功能測試：驗(yàn)證系統(tǒng)功能是否滿足系統(tǒng)要求

b)系統(tǒng)集成測試：驗(yàn)證組件之間的接口是否滿足設(shè)計(jì)要求

c) DV測試：DV是設(shè)計(jì)驗(yàn)證，驗(yàn)證產(chǎn)品設(shè)計(jì)是否滿足要求，其中DV測試又包含環(huán)境耐久測試、電磁兼容測試、電氣特性測試

d) PV測試：PV是產(chǎn)品驗(yàn)證，主要驗(yàn)證產(chǎn)線上生產(chǎn)出來的產(chǎn)品是否符合要求。一般PV之后的產(chǎn)品，就具備了批量生產(chǎn)的資格了。

硬件測試驗(yàn)證

硬件階段的測試一般比較關(guān)注硬件功能測試，也就是基于相關(guān)硬件需求的測試，以確認(rèn)硬件電路設(shè)計(jì)與硬件需求是一致的。

軟件測試驗(yàn)證

硬件階段的測試一般包含以下幾種：

a) 軟件功能測試：驗(yàn)證軟件實(shí)現(xiàn)是否與軟件需求一致。

b) 軟件單元測試：驗(yàn)證單元設(shè)計(jì)是否與單元設(shè)計(jì)需求規(guī)范一致。

c) 軟件集成測試：驗(yàn)證集成的軟件是否滿足軟件需求，以及軟件組件之間的接口是否一致。

上述系統(tǒng)、硬件和軟件層面的測試驗(yàn)證分別由系統(tǒng)、硬件和軟件測試工程師來負(fù)責(zé)。功能安全工程師主要關(guān)注相關(guān)的測試結(jié)果是否都通過，測試覆蓋度是否滿足100％。如果有測試失敗項(xiàng)，該測試會(huì)不會(huì)對產(chǎn)品的功能安全有影響。如果有失效項(xiàng)，復(fù)測結(jié)果如何。

【注】：通常故障注入測試會(huì)涵蓋在功能測試?yán)铮赃@里沒有單獨(dú)把故障注入測試拎出來。對于有些產(chǎn)品，如果用到的ASIC有安全手冊，也需要對裁剪后的安全機(jī)制進(jìn)行故障注入測試，以確保實(shí)現(xiàn)的安全機(jī)制滿足要求。

審核編輯：劉清