引言

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

　　隨著各行各業(yè)在產(chǎn)品開發(fā)設(shè)計和測試過程中都采用了一套標(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,，從什么是功能安全,、什么是功能安全工程師以及功能安全工程師主要做什么,，三個方面展開對功能安全的介紹。

　　01

　　什么是功能安全

　　1

　　背景簡介

　　由于汽車的復(fù)雜性,，整個行業(yè)正在致力于提供符合安全要求的零部件系統(tǒng),。比如，線控油門系統(tǒng),，當(dāng)駕駛員踩下油門踏板,，踏板上的傳感器向控制器發(fā)送信號時，控制器會綜合分析如發(fā)動機(jī)轉(zhuǎn)速,、車輛速度,、踏板位置等信號，然后將控制指令發(fā)送給油門本體,。測試和驗(yàn)證線控油門系統(tǒng)等是汽車行業(yè)面臨的一個挑戰(zhàn),。ISO 26262的目標(biāo)就是為所有汽車E/E系統(tǒng)提供一個統(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)在特定時間是開發(fā)設(shè)備或流程的最高水準(zhǔn),。汽車制造商一般要對因產(chǎn)品故障而造成的損害負(fù)責(zé),。ISO-26262在汽車行業(yè)是一個通用標(biāo)準(zhǔn)，它提供了一種衡量系統(tǒng)安全性的方法,。

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

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

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

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

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

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

　　2

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

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

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

　　3

　　分配安全等級——功能安全完整性等級（ASIL）

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

　　圖2：功能安全等級評定

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

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

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

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

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

　　4

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

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

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

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

　　02

　　什么是功能安全工程師,，

　　功能安全工程師做什么？

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

　　1

　　報價階段

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

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

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

　　分析完客戶的安全要求之后,，一般功能安全工程師還會做影響分析,，以確定公司內(nè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ù)項(xiàng)目的時間計劃以及客戶的安全輸入來準(zhǔn)備初版的項(xiàng)目功能安全計劃（主要內(nèi)容是計劃管理和指導(dǎo)整個項(xiàng)目開發(fā)過程中的安全活動的執(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ā)各個階段的關(guān)鍵產(chǎn)出物的記錄,，產(chǎn)出物的評審記錄等）,。

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

　　以上內(nèi)容都完成之后，功能安全工程師就可以跟審核員（Assessor）約評審會議了,。在會上，審核員會根據(jù)功能安全工程師準(zhǔn)備的證據(jù)對該項(xiàng)目的產(chǎn)品開發(fā)成熟度進(jìn)行評估以確認(rèn)是否滿足當(dāng)前的開發(fā)需要,，以及是否有安全相關(guān)的風(fēng)險,，并輸出當(dāng)前階段的評估報告?！咀ⅰ浚河捎诿考夜镜拈_發(fā)流程不同,，所以對功能安全評估次數(shù)要求也不同，但基本都會在項(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)險評估（主要是識別并分類由相關(guān)項(xiàng)中的功能異常表現(xiàn)引起的危害事件,，以及定制防止危害事件發(fā)聲或者減輕危害程度的安全目標(biāo)及其安全等級,，來避免不合理的風(fēng)險），以便得出產(chǎn)品的頂層功能安全目標(biāo),，以及功能安全概念,，并打包發(fā)給供應(yīng)商。

　　2

　　概念設(shè)計階段

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

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

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

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

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

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

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

　　3

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

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

　　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ù)和報廢中系統(tǒng)及其要素功能安全的相關(guān)要求,；

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

　　a. 存儲器（RAM,ROM等）；

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

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

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

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

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

　　與硬件開發(fā)類似，有了技術(shù)安全要求,、系統(tǒng)需求和系統(tǒng)架構(gòu),、硬件設(shè)計規(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è)計主要是軟件架構(gòu)師來負(fù)責(zé),，功能安全工程師協(xié)助支持，并支持做軟件架構(gòu)的評審活動,。軟件架構(gòu)的設(shè)計要盡量滿足一致性,、簡單性、可驗(yàn)證性,、模塊化,、可維護(hù)性等特征。在軟件架構(gòu)設(shè)計中也可以參考ISO 26262第６部分中軟件架構(gòu)設(shè)計的方法（Table2, Table3 和Table４）,。

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

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

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

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

　　4. 軟件安全分析：

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

　　4

　　測試驗(yàn)證階段

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

　　在各個階段的測試開始之前，功能安全工程師要主導(dǎo)ISO 26262方法的裁剪活動,。功能安全工程師要跟系統(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è)計要求

　　c） DV測試：DV是設(shè)計驗(yàn)證,，驗(yàn)證產(chǎn)品設(shè)計是否滿足要求,，其中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è)計與硬件需求是一致的。

　　軟件測試驗(yàn)證

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

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

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

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

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

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

更多信息可以來這里獲取==>>電子技術(shù)應(yīng)用-AET<<