“當(dāng)我們展望未來新技術(shù)的挑戰(zhàn)時，采用統(tǒng)一的開發(fā)和應(yīng)用標(biāo)準(zhǔn)至關(guān)重要。” — 通用汽車副總裁 Ken Kelzer， 2018。

在諸多的標(biāo)準(zhǔn)與規(guī)范中，ISO 26262（汽車功能安全標(biāo)準(zhǔn)），繼承自 IEC 61508（通用電子電氣功能安全標(biāo)準(zhǔn)），定義了針對汽車工業(yè)的安全（Safety）相關(guān)組件的國際標(biāo)準(zhǔn)。簡單的說，ISO 26262通過指導(dǎo)與規(guī)范化的形式，對汽車電子產(chǎn)品，從概念階段到最后的產(chǎn)品報廢階段，提出了標(biāo)準(zhǔn)化的要求。更進(jìn)一步的是，ISO 26262細(xì)化了如何控制一個汽車電子產(chǎn)品或組件的人身傷害風(fēng)險在可接受的范圍，及文檔化整個分析、設(shè)計、開發(fā)、測試及生產(chǎn)過程。

ISO 26262的歷史可以追溯到2011年，第一版的ISO 26262標(biāo)準(zhǔn)發(fā)布。第一版標(biāo)準(zhǔn)包含10個部分:

Part 1: 詞匯（Vocabulary）
Part 2: 功能安全管理（Management of functional safety）
Part 3: 概念階段（Concept phase）
Part 4: 系統(tǒng)級的產(chǎn)品開發(fā)（Product development at system level）
Part 5: 硬件級的產(chǎn)品開發(fā)（Product development at hardware level）
Part 6: 軟件級的產(chǎn)品開發(fā)（Product development at software level）
Part 7: 生產(chǎn)，運營（Production and operation）
Part 8: 支持過程（Supporting processes）
Part 9: 面向ASIL及面向安全的分析（Automotive Safety Integrity Level (ASIL)-oriented and safety-oriented analyes）
Part 10: ISO 26262指南（Guidelines on ISO 26262）

相對于2011版的ISO 26262，發(fā)布于2018年的第二版標(biāo)準(zhǔn)修改了Part 7的名字為：

Part 7: 生產(chǎn)，運營，維護(hù)及報廢（Production, operation, service and decommissioning）

同時還增加了2個部分：

Part 11: 半導(dǎo)體廠商應(yīng)用ISO 26262的指南（Guidelines on application of ISO 26262 to semiconductors）

Part 12: 適用于摩托車的ISO 26262（Adaptation of ISO 26262 for motorcycles）

在ISO 26262的Part 3中，介紹在產(chǎn)品開發(fā)的早期階段的活動及用于保障功能安全的開發(fā)流程。這個部分包含了相關(guān)項的定義（Item Definition），危害分析與風(fēng)險評估（Hazard Analysis and Risk Assessment）的內(nèi)容。本文將從基本概念出發(fā)，介紹ISO 26262 : 2018 Part 3相關(guān)的流程，分析方法及相關(guān)技術(shù)。

1 基本概念

ISO 26262中的概念眾多（2018版185個），無法在一篇文章中一一描述，所以在本節(jié)中，只針對Part 3中涉及到的重要概念進(jìn)行解釋說明。其中可以涉及到到的其它名詞，都符上英文名詞，便于在標(biāo)準(zhǔn)中查找。

1.1 相關(guān)項定義（Item Definition）

Part 3的第一個活動是相關(guān)項定義（Item Definition）。相關(guān)項定義對于應(yīng)用ISO 26262到產(chǎn)品中非常重要，參與到產(chǎn)品開發(fā)人員和咨詢?nèi)藛T需要對產(chǎn)品有深入的了解，而相關(guān)項定義則提供了理解產(chǎn)品所必需的信息。相關(guān)項（Item）在標(biāo)準(zhǔn)的Part 1中定義如下：

應(yīng)用了ISO 26262開發(fā)標(biāo)準(zhǔn)，實現(xiàn)了整車級的某個功能或者某個功能的一部分的系統(tǒng)或者系統(tǒng)的組合（System or Combination of Systems）

而相關(guān)項定義（Item Definition）是為了描述清楚：

相關(guān)項（Item）的功能，依賴關(guān)系，與駕駛員、周圍環(huán)境以及其它整車級相關(guān)項的交互關(guān)系

提供足夠的信息用于理解相關(guān)項（Item），以便于后續(xù)過程中的活動能夠執(zhí)行

1.2 相關(guān)項的構(gòu)成

一個相關(guān)項（Item）可以分解為1個或多個系統(tǒng)（System），并向外提供1個或多個功能（Function）。系統(tǒng)可以由多個子系統(tǒng)（Sub-system）構(gòu)成，也可以分解為多個組件（Component）。構(gòu)成一個系統(tǒng)或子系統(tǒng)的組件至少是3個：負(fù)責(zé)輸入信號的傳感器（Sensor），負(fù)責(zé)信號處理及邏輯控制的控制器（Controller）及負(fù)責(zé)輸出的驅(qū)動器（Actuator）。一個組件（Component）可以由1個或多個軟件單元（Software Unit）或1個或多個硬件（Hardware Part）構(gòu)成。下圖給出了這些概念的邏輯關(guān)系：

1.3 危害分析與風(fēng)險識別（Hazard Analysis & Risk Assessment）

危害分析與風(fēng)險識別（以下簡稱HA & RA）的主要目的在于以下2個方面：

識別危害與危害事件（Hazard and Hazardous Event），相關(guān)項的異常行為會導(dǎo)致這些危害事件

為預(yù)防與緩解識別出來的危害事件，推導(dǎo)出相應(yīng)安全目標(biāo)（Safety Goal）及其ASIL評級，來避免不合理的風(fēng)險

ISO 26262:2011中，HA & RA的輸入主要是相關(guān)項定義（Item Definition） 和 影響分析（Impact Analysis）。影響分析指出了2種可能的進(jìn)入HA & RA的初始條件：

從產(chǎn)品的Idea和期望的功能開始，把相關(guān)項視為全新開發(fā)而進(jìn)行HA & RA

由于產(chǎn)品本身的功能修改或者運行環(huán)境變化，從影響分析（Impact Analysis）開始進(jìn)行HA & RA

從2018版開始，關(guān)于影響分析的部分被劃分到Part 2 功能安全管理中，因此在2018版中，只有相關(guān)項定義作為HA & RA的輸入。

相關(guān)項定義的過程中，已經(jīng)考慮了產(chǎn)品的功能、性能及可能的失效帶來的后果（如已知的失效模式），但并沒有這些需求進(jìn)行分類。通過HA & RA識別產(chǎn)品的安全目標(biāo)，將這部分需求同產(chǎn)品自身功能區(qū)別開，納入功能安全管理的流程（如下圖所示）。因此，HA & RA對于產(chǎn)品的后續(xù)開發(fā)活動有重要的意義。

1.4 危害與危害事件（Hazard and Hazardous Event）

危害（Hazard） 是指由于產(chǎn)品功能的失效，作為潛在的原因，會導(dǎo)致發(fā)生人身傷害。但這種危害只是一種可能性，把危害和危害發(fā)生的場景（Operation Situation） 結(jié)合起來，形成危害事件（Hazardous Event），才能對其進(jìn)行分級（如，可接受或不可接受）。對危害事件的分級主要考慮以下3個方面：嚴(yán)重度（Severity），暴露度（Exposure）和可控度（Controllability）。在HA & RA過程中，分別對這3個方面進(jìn)行打分：嚴(yán)重度（0 - 3，傷害的嚴(yán)重程度逐漸增加），暴露度（0 - 4，暴露在危險環(huán)境中的程度逐漸增加），可控度（0 - 3，危害發(fā)生時的可控度逐漸降低）。這3個數(shù)值中，經(jīng)過評估任一數(shù)值取值為0，或者相加后的數(shù)值小于7，則認(rèn)為這個危害事件的風(fēng)險可接受，即相關(guān)的功能開發(fā)按照QM管理即可；但如果相加的數(shù)值大于等于7，則認(rèn)為風(fēng)險不可接受，對這個危害事件要分配 ASIL（Automotive Safety Integrity Level） 等級。ASIL分為4個等級，分別對應(yīng)相加數(shù)值的7，8，9和10。ASIL與嚴(yán)重度、暴露度和可控度的對應(yīng)關(guān)系可以參考下表：

1.5 安全目標(biāo)（Safety Goal）

對于識別出的危害事件，進(jìn)行細(xì)致的分析，并制定安全目標(biāo)（Safety Goal）。安全目標(biāo)在功能安全產(chǎn)品開發(fā)中，處于最上層的需求。安全目標(biāo)與危害事件之間，可以是1:N或N:1（N大于等于1）的關(guān)系。安全目標(biāo)可以用自然語言的形式來描述，通常是如下的模式化形式：

避免（Avoid to），如，避免近光燈非預(yù)期的熄滅

阻止（Prevent to），如，阻止安全相關(guān)提示信息在2秒內(nèi)關(guān)閉

應(yīng)該（Should），如，收到胎壓不足的警告信號后，胎壓不足警告燈應(yīng)該亮起

每個安全目標(biāo)都有對應(yīng)的ASIL評級，安全目標(biāo)的ASIL等級取決于與之相關(guān)聯(lián)的風(fēng)險事件的最高ASIL等級?？梢詾槊總€安全目標(biāo)分配故障響應(yīng)時間間隔（Fault Tolerance Time Interval），用以規(guī)定檢測違反安全目標(biāo)的故障和安全機(jī)制響應(yīng)時間的最大間隔。安全目標(biāo)可以用如下的表格的形式表示：

1.6 功能安全需求（Functional Safety Requirement）

功能安全需求（Functional Safety Requirement，F(xiàn)SR）派生自安全目標(biāo)，一個安全目標(biāo)至少派生一條功能安全需求。派生出的功能安全需求有無歧義，可理解，無矛盾，可實現(xiàn)及可測試等要求。派生的過程中，功能安全需求獨立于系統(tǒng)的技術(shù)架構(gòu)，還要給功能安全需求分配唯一的ID，當(dāng)前狀態(tài)及對應(yīng)ASIL等級屬性。下面是一個表格形式的功能安全需求的例子：

1.7 功能安全概念（Functional Safety Concept）

功能安全概念（Functional Safety Concept）是Part 3的最后一個活動。雖然在產(chǎn)品開發(fā)尚未進(jìn)入系統(tǒng)設(shè)計階段（Part 4），但此時需要假設(shè)一個系統(tǒng)架構(gòu)（System Architectural Design），因為功能安全概念需要在整車的架構(gòu)上實現(xiàn)。功能安全概念階段需要描述必要的功能安全需求，并分配這些安全需求到系統(tǒng)的功能要素（Element）上。在ISO 26262中，功能安全概念階段要求達(dá)成以下目標(biāo)：

指定與相關(guān)項安全目標(biāo)相符功能行為（Functional Behavior）或者降級的功能行為（Degraded Functional Behavior）。系統(tǒng)功能的降級是指如果由于故障不能正確的運行，需要系統(tǒng)工作在一個功能或性能受限的狀態(tài)。一般系統(tǒng)降級要設(shè)計降級的策略，如近光燈系統(tǒng)，降級策略要求至少有一個燈可以工作。

根據(jù)安全目標(biāo)，指定針對合適的手段及時檢測和控制相關(guān)的故障的限制條件

在相關(guān)項的層面上，設(shè)計策略或者措施用來達(dá)成要求的容錯能力，或者基于相關(guān)項本身、駕駛員或者外部措施以減輕相關(guān)故障造成的影響

分配功能安全需求到系統(tǒng)架構(gòu)或者外部措施上

驗證功能安全概念并指定功能安全確認(rèn)標(biāo)準(zhǔn)，這里的驗證是指對設(shè)計過程的驗證（Verification），主要是檢查設(shè)計過程的正確性。

2 功能安全概念階段相關(guān)技術(shù)

為保障功能安全概念階段的活動能夠正確實施，對應(yīng)每個活動都有一系列的實施方法。本節(jié)對涉及到的一些重要技術(shù)手段進(jìn)行介紹。

2.1 識別相關(guān)項（Identify Item）

為了識別出相關(guān)項（Item)及針對相關(guān)項（Item）任何的功能開發(fā)之前，無論這些涉及到的功能，是否是功能安全相關(guān)的，都需要一個合適的出發(fā)點。在這里，系統(tǒng)工程（System Engineering）的方法論可以給出一個很有價值的方案。系統(tǒng)工程方法論中，為描述系統(tǒng)對外提供的服務(wù)，有一個針對系統(tǒng)上下文（System Context）建模的過程。通過模型化的系統(tǒng)上下文，可以表達(dá)出一個系統(tǒng)針對周圍環(huán)境直接的影響，還可以得到系統(tǒng)的輸入與輸出信息流（包括數(shù)據(jù)流與控制流）。在這個階段，在外部與系統(tǒng)交互的是系統(tǒng)參與者（System Actor）。

通常系統(tǒng)工程中對系統(tǒng)建模采用SysML/UML，但系統(tǒng)上下文并沒有作為獨立概念在SysML/UML中存在，因此需要引入一種能夠形象表達(dá)系統(tǒng)上下文的方法：SYSMOD。通過SYSMOD，我們就可以在SysML/UML中，以如下的方式定義一個車燈管理系統(tǒng)（Headlight Management System）的上下文：

2.2 明確相關(guān)項的邊界

一個車載系統(tǒng)或相關(guān)項，必然要和周邊系統(tǒng)或駕駛員產(chǎn)生交互，它的邊界就是一個非常重要的信息：哪些組件屬于系統(tǒng)元素，哪些位于系統(tǒng)之外？這些信息要在相關(guān)項定義這個過程中識別出來（至少是一部分，因為有時項目初期產(chǎn)品的需求并不十分明確）。明確相關(guān)項邊界的第一個任務(wù)是要明確系統(tǒng)交互的參與者（System Actor）。系統(tǒng)參與者在概念階段應(yīng)該是清晰的，否則就會陷入一個怪圈：如果系統(tǒng)的開發(fā)者對于系統(tǒng)的使用者無法識別清楚，那么該如何正確的建立系統(tǒng)的概念和理解呢？下面有幾個方法可以快速的幫助識別系統(tǒng)的參與者：

系統(tǒng)的參與者應(yīng)該主要來自于需求分析

系統(tǒng)的參與者應(yīng)該是使用系統(tǒng)提供的服務(wù)或接口，與系統(tǒng)有直接交互的人員

與正在開發(fā)的系統(tǒng)有交互的其它系統(tǒng)也應(yīng)該被列為系統(tǒng)的參與者，并且進(jìn)行分類，如，傳感器，驅(qū)動器，外部系統(tǒng)，或者由于系統(tǒng)的運行，會受到影響的外部環(huán)境（光線、溫度等），這些可以幫助我們更好的理解當(dāng)前開發(fā)的系統(tǒng)，更容易的描述其提供的服務(wù)

識別出系統(tǒng)的參與者之后，第二個任務(wù)要識別出參與者與系統(tǒng)之間的信息流。通過SysML/UML，我們可以建立系統(tǒng)參與者和相關(guān)項之間的連接（如使用Connector將2者相連），這表示系統(tǒng)的參與者提供信息流給系統(tǒng)，或者接收從系統(tǒng)提供來的信息流（如從傳感器來的車速信號，或者輸出到屏幕的視頻信號）。同系統(tǒng)的參與者一樣，我們需要在系統(tǒng)開發(fā)的早期識別出這些信息流，并用建模的形式把它們識別出來（可以使用SysML中的Information Item來表示，參考系統(tǒng)上下文圖中的黑色三角）。以下幾個方法可以用來識別系統(tǒng)中的信息流：

哪些信息是系統(tǒng)參與者發(fā)送給相關(guān)項的，如系統(tǒng)上下文中的車輛信號、開關(guān)信號

這些信息是否與我們正在實現(xiàn)的系統(tǒng)密切相關(guān)

相關(guān)項如何集成到整車環(huán)境中，如與供電模塊的連接

相關(guān)項發(fā)送哪些信息到系統(tǒng)的參與者

定義完系統(tǒng)的參與者與相應(yīng)的信息流后，最后一個任務(wù)則是它們?nèi)绾瓮嚓P(guān)項交互（包括輸入及輸出），即識別出系統(tǒng)的交互點（Interaction Point，系統(tǒng)上下文圖中的帶箭頭的小正方形）。當(dāng)我們使用Connector建立系統(tǒng)參與者與相關(guān)項之間的連接時，Connector與相關(guān)項的交點可以認(rèn)為就是交互點。但這種識別方法不夠精確，需要使用以下方法進(jìn)行提煉：

相關(guān)項使用哪些途徑與外界交換信息

已識別出的交互點是概念上的還是物理上的

是否有哪些交互的路徑可以合并的

需要注意的是，在功能安全概念階段，系統(tǒng)的交互點（Interaction Point）和系統(tǒng)接口（Interface）是不同的：系統(tǒng)交互點在這個階段仍然是個抽象的概念，只用于識別相關(guān)項與外部環(huán)境之間存在交互；而接口則包含在交互點內(nèi)，描述相關(guān)項對外要求或提供的服務(wù)，以及信息流的具體內(nèi)容。接口的建模在系統(tǒng)設(shè)計過程中實施，如ASPICE流程中的SYS.2。

2.3 需求定義技術(shù)（Techniques for Specifying Requirements）

概念階段的功能安全需求（Functional Safety Requirement）是后續(xù)功能安全開發(fā)活動的基礎(chǔ)。產(chǎn)品開發(fā)的成功或失敗依賴于功能安全需求的質(zhì)量，大量的事故可以追溯到有缺陷的需求，如不完整的表述，錯誤的實現(xiàn)以及對不清晰的需求的錯誤理解。ISO 26262中需求可以分為4個等級（但不限于4個，可以根據(jù)需要再細(xì)分）：功能安全目標(biāo)，功能安全需求，技術(shù)安全需求及硬件/軟件安全需求。好的需求對于產(chǎn)品質(zhì)量、成本/時間、功能安全的實現(xiàn)及測試都有重要的意義，因此本節(jié)對需求的定義技術(shù)做一些基本的描述。

需求定義通常由需求工程師進(jìn)行。大多數(shù)成功的項目至少有2名資深的需求工程師，他們協(xié)同工作并相互檢查對方的成果。需求開發(fā)過程中，最好也有其他的助理工程師加入，因為從組織的角度，需求開發(fā)過程中的知識積累需要傳遞給下游的工程活動，并且組織也需要培養(yǎng)更多的需求專家。需求開發(fā)要求的工程師技能要求一般包括以下幾點：

需求開發(fā)的經(jīng)驗。沒有什么比經(jīng)驗更重要，經(jīng)過多個項目的磨練后，有經(jīng)驗的工程師可以判斷出哪些該做，哪些不該做。即使沒有成功項目的經(jīng)驗，那么那些從失敗的錯誤中獲取的經(jīng)驗也十分重要。

合作。需求工程師幾乎和項目中的所有人員打交道，特別是在敏捷（Agile）開發(fā)團(tuán)隊中，還要和客戶進(jìn)行面對面的溝通。

傾聽和觀察的技巧。需求工程師應(yīng)該擅長從系統(tǒng)工程師或客戶處發(fā)現(xiàn)細(xì)微的線索，用于挖掘缺失的需求。

寫作溝通能力。需求工程師的主要角色是將需求文檔化，那就要求需求工程師能夠清晰有組織的把需求表達(dá)出來，即使是一些復(fù)雜問題和想法。常用的手段包括圖表化、數(shù)據(jù)流圖、控制流圖、用例圖或狀態(tài)圖等。
領(lǐng)域知識。對于正在開發(fā)的產(chǎn)品，需求工程師要具備相應(yīng)的領(lǐng)域知識，如導(dǎo)航工程師就不是十分適合開發(fā)剎車或者燃油系統(tǒng)的需求。

需求的表達(dá)方式除了采用MS Office系列（Word，Excel），還可以使用支持SysML的工具進(jìn)行描述，除了具備直觀的好處之外，還可以和后續(xù)的工程活動方便的追溯（見下節(jié)）。SysML中增加了需求圖（Requirement Diagram）用于描述系統(tǒng)需求，如下圖所示：

在工具中，每一個需求塊（Block）會分配一個全局唯一的GUID，可以用于標(biāo)識這個需求。但GUID通常與需求定義時分配的ID不一致且難于理解，因此針對需求塊，SysML還提供了需求ID字段，用于與外部工具建立需求對應(yīng)關(guān)系。另外，為方便在各個需求管理工具之間交換數(shù)據(jù)，通常會采用CSV格式的表格，通過導(dǎo)入/導(dǎo)出的形式進(jìn)行數(shù)據(jù)傳遞。

2.4 追溯性相關(guān)技術(shù)（Techniques for Traceability）

作為消除系統(tǒng)性故障（Systematic Fault）的重要手段，可追溯性在功能安全相關(guān)設(shè)計的驗證過程中是重點檢查的內(nèi)容?？勺匪菪栽谙到y(tǒng)開發(fā)的不同階段表現(xiàn)不同，如用例和需求之間，可以表現(xiàn)為實現(xiàn)關(guān)系（Realization）；用例和用例之間，可以表現(xiàn)為包含、擴(kuò)展（Include, Extend）等關(guān)系?？勺匪菪缘谋憩F(xiàn)形式可以有多種：

基于ID的可追溯性

基于SysML/UML關(guān)系圖的追溯

以及基于關(guān)系矩陣的追溯

下圖是一個使用SysML/UML關(guān)系圖建立追溯性的例子，在圖中通過手工連接的方式把用例和需求連接起來，優(yōu)點是圖形比較直觀：

追溯圖的形式能夠同時表達(dá)的追溯范圍有限，如果需求和用例較多，追溯圖由于圖中的元素太多，就不容易使用（如，查找是否有需求的遺漏），在這種情況下使用追溯矩陣（Traceability Matrix）就更合適。追溯矩陣可以在工程的全路徑的任意2個連續(xù)的環(huán)節(jié)（如，需求和用例）中間建立直觀的關(guān)系矩陣。如下圖所示，圖的橫縱坐標(biāo)分別表示需求與用例，箭頭則表示實現(xiàn)（Realization）的方向，高亮的行表示需求有遺漏的情況：

建立了雙向追溯之后，需求或者設(shè)計發(fā)生了變更，就可以通過追溯判定變更的影響范圍。支持baseline的SysML/UML工具，還可以基于baseline進(jìn)行差分?；赽aseline可以很容易的識別出需求和設(shè)計中發(fā)生了變更的部分，從發(fā)生了變更的部分出發(fā)，可以追溯到對應(yīng)的上下游工程中，需要變更的內(nèi)容，以確保一致性。

2.5 危害識別與分析技術(shù)（Techniques for Hazard Identification and Analysis）

常用的危害分析技術(shù)有20多種，幾乎覆蓋了包括了：概念，概要設(shè)計，詳細(xì)設(shè)計，測試及運行在內(nèi)的產(chǎn)品開發(fā)的各個階段。從方法論上來說，危害分析技術(shù)可以分為2大類：內(nèi)推法（Inductive）和外推法（Deductive）：

內(nèi)推法從系統(tǒng)中某個組件的故障出發(fā)，自下而上的推導(dǎo)，在整車的級別上產(chǎn)生的影響是否違反功能安全目標(biāo)

外推法從違反功能安全目標(biāo)的失效開始，自上而下的推導(dǎo)可能產(chǎn)生這個影響的組件故障

在功能安全概念階段，危害分析的主要目的是保障完整及正確的派生功能安全需求。在ISO 26262:2018, Part 3中提到了3種危害分析方法：FMEA (Failure Mode and Effects Analysis)，HAZOP (Hazard and Operability Analysis) 和FTA (Fault Tree Analysis)。這三種分析方法的分類見下圖：

以下介紹一下FMEA的基本分析技巧。FMEA用于分析系統(tǒng)中的關(guān)鍵組件的失效是否會影響功能安全目標(biāo)，影響功能安全目標(biāo)的失效是否設(shè)計了安全機(jī)制，相應(yīng)的安全機(jī)制可以作為功能安全需求而記載到對應(yīng)的文檔中。FMEA的主要成果物為FMEA Worksheet，下圖是來自于Ford的FMEA Handbook，圖中給出了FMEA的主要的分析過程：

FMEA的輸入有多種，其中比較重要的是功能塊圖（Functional Block Diagram）和參數(shù)圖（Parameter Diagram）。功能塊圖簡化了系統(tǒng)設(shè)計和支持的服務(wù)，在功能安全概念階段可以幫助快速建立對產(chǎn)品的理解。功能塊圖展示了子系統(tǒng)之間的關(guān)系和接口，同時也指示了系統(tǒng)所必須提供的功能。下圖給出了系統(tǒng)的功能塊圖的例子：

對于功能塊圖中的任一功能，對其進(jìn)行危害分析時，需要明確該功能的輸入信號，運行環(huán)境，配置信息及期望的和錯誤的輸出。把這些信息整合，可以如下圖所示的參數(shù)圖（Parameter Diagram）：

通過對這些參數(shù)的分析，可以得出導(dǎo)致某個功能出現(xiàn)故障的基本原因。在后續(xù)的分析過程中，針對故障原因，設(shè)計合理的檢測和消除機(jī)制，可以有效的提升系統(tǒng)的安全性。

3 總結(jié)

本文從ISO 26262:2018，Part 3中的基本概念出發(fā)，介紹了該部分涉及到重要概念及開發(fā)過程中需要用到的基本技術(shù)。在ISO 26262流程中，概念階段（包括功能安全概念和技術(shù)安全概念）是最重要的階段，這個階段出現(xiàn)的任何紕漏，都會影響后續(xù)的功能安全開發(fā)活動。由于ISO 26262采用的是V模型，概念階段變更引起的工作量會十分巨大。本文希望通過一些重要概念的解釋和實用技術(shù)的說明，理清功能安全概念的過程，幫助功能安全開發(fā)人員，實現(xiàn)正確的功能安全概念。