9.2.使用案例

9.2.1.概述

開發(fā)SEooC涉及對產(chǎn)品開發(fā)中相應階段的前提條件作出假設，例如。對于軟件組件，它是軟件架構(gòu)設計的一部分，相應的階段是【配置管理】（ISO26262-8：2018的第7條）。沒有必要對所有前提條件作出假設，例如安全計劃。

圖21顯示了假設與SEooC開發(fā)之間的關系。開發(fā)一個SEooC可以從一定層次的需求和設計開始。每個單獨的要求或設計前提是預先確定的狀態(tài)“假定”。

在SEooC開發(fā)過程中，將驗證SEooC的需求的正確實現(xiàn)(來自對SEooC以外的設計的假設、高層需求和假設)。

圖21-假設與SEooC開發(fā)之間的關系

然后在相關項開發(fā)過程中確定這些需求和假設的驗證。

同樣，驗證活動表明，在任何級別上，開發(fā)的SEooC都與使用它的使用環(huán)境中的要求一致。例如，當使用獨立于使用環(huán)境開發(fā)的軟件組件時，對軟件規(guī)范的驗證可以證明軟件架構(gòu)設計規(guī)范中的要求得到滿足。當SEooC的開發(fā)完成，相關項開發(fā)達到對安全元件的要求的階段時，可以生成此驗證報告。

下面給出了SEooC的一些典型示例，即系統(tǒng)、硬件組件和軟件組件。

9.2.2.開發(fā)一個作為SEooC的系統(tǒng)

本節(jié)旨在說明如何將SEooC概念的裁剪應用于一個新的E/E系統(tǒng)，該系統(tǒng)可以由不同的車輛制造商集成。

為了本示例的目的，系統(tǒng)包括在某些車輛條件下激活功能和允許在適當?shù)鸟{駛員請求下解除功能的功能。流程如圖22所示。

注1：根據(jù)SEooC的確切性質(zhì)，可能需要對需求進行一些額外的裁剪。

注2：根據(jù)SEooC的確切性質(zhì)，ISO26262-3和ISO26262-4的一些要求不能適用，因此只作了零元器件考慮。

注3：雖然ISO26262系列標準的所有條款都沒有顯示，但這并不意味著它們不適用。

圖22-SEooC系統(tǒng)開發(fā)

步驟1a-定義SEooC的范圍

基于假設，SEooC的開發(fā)者定義了SEooC的目的、功能和外部接口。

關于SEooC范圍的這些假設的舉例可以是：

?該系統(tǒng)是為總質(zhì)量不超過1800公斤的車輛而設計的。

?該系統(tǒng)是為前輪驅(qū)動的車輛設計的。

?該系統(tǒng)設計最大道路坡度為32%而設計的。

?系統(tǒng)具有與其他外部系統(tǒng)的接口，以獲得所需的車輛信息。

?功能要求：

l當駕駛員在特定車輛條件下提出要求時，系統(tǒng)啟動該功能；

l當駕駛員請求時，系統(tǒng)會解除功能。

步驟1b-關于SEooC的安全需求的假設

開發(fā)SEooC對相關項定義、相關項的安全目標和與SEooC功能相關的相應功能安全需求作出假設，以確定SEooC的技術安全需求。

分配給SEooC的功能安全需求假設的示例可以是：

?系統(tǒng)在高車速不會時激活該功能(ASILx)。

?當沒有檢測到駕駛員請求時，系統(tǒng)不會解除該功能(ASILy)。為了實現(xiàn)假定的安全目標，定義了關于使用環(huán)境的具體假設。

關于SEooC使用環(huán)境的假設示例可以是：

?外部源可以提供具有所需 ASIL 等級的信息，使系統(tǒng)能夠檢測適當?shù)能囕v狀況(ASILx)。

?外部源可以提供關于駕駛員請求的信息,且該信息達到所需的 ASIL等級(ASILy。

步驟2-SEooC的開發(fā)

當技術安全需求已從該相關項的假定功能安全需求中導出時，SEooC是按照ISO26262系列標準的要求開發(fā)的。

步驟3-工作成果

在SEooC開發(fā)結(jié)束時，提供了表明所導出的技術安全需求得到滿足的工作成果。然后將工作成果中的所有必要信息提供給相關項集成商，包括SEooC的安全需求和在使用環(huán)境中所做的假設。

步驟4-將SEooC集成到相關項中

在相關項開發(fā)過程中，規(guī)定了安全目標和功能安全需求。該相關項的功能安全需求與SEooC假定的功能安全需求相匹配，以確定其有效性。

在SEooC假設不匹配的情況下，從影響分析開始，進行變更管理活動，如【變更管理】（ISO26262-8：2018的第8條）所述。潛在成果包括：

?在實現(xiàn)安全目標方面，這種差異可以被認為是可以接受的，并且不采取任何行動。

?這種差異可以被認為影響安全目標的實現(xiàn)，對于相關項定義或功能安全概念來說，可能需要進行變更。

?這種差異可以被認為影響安全目標，需要對SEooC組件進行變更（可能包括組件的變更）。

9.2.3.開發(fā)一個作為獨立于環(huán)境的安全要素的硬件組件

9.2.3.1概述

本節(jié)使用微控制器(MCU)作為示例硬件組件SEooC。流程如圖23所示。

注1：根據(jù)SEooC的確切性質(zhì)，例如，需要對需求進行一些額外的裁剪。為了適應由于隨機硬件故障而違反安全目標的概率的目標值。

注2：根據(jù)SEooC的確切性質(zhì)，ISO26262-5的一些要求不適用，因此只作了零元器件考慮。

注3：雖然ISO26262系列標準的所有條款都沒有顯示，但這并不意味著它們不適用。

圖23-SEooC硬件組件開發(fā)

9.2.3.2步驟1-系統(tǒng)層面的假設

單片機的開發(fā)（見圖23）作為SEooC開始（步驟1），并假設

系統(tǒng)層面屬性和要求按照ISO26262-2：2018的6.4.5.7。

根據(jù)對一些參考應用的分析，該階段可以分為兩個子步驟(1a和1b)。這些要求是關于硬件產(chǎn)品開發(fā)的前提條件(ISO26262-5：2018的表A。1)；示例如下。

9.2.3.3步驟1a-關于技術安全需求的假設

下面是一些為MCU創(chuàng)建的假定技術安全需求的示例。

關于技術安全需求的假設(步驟1a)：

a.CPU指令存儲器的故障通過至少具有目標值（例如）的硬件中的安全機制來減輕。分配給硬件元器件層面的單點故障度量(也可以用所需的DC表示)。

b.單片機對違反安全目標的總概率的貢獻不超過相關ASIL指示概率的10%。

c.為了實現(xiàn)安全狀態(tài)，當斷言復位時，MCU將所有I/O輸出驅(qū)動到低狀態(tài)。

d.與處理功能相關的任何安全機制都在不到10毫秒內(nèi)完成（系統(tǒng)架構(gòu)中適當級別上的故障處理時間間隔的指定零元器件）。

e.存在一個內(nèi)存保護單元，以提供用不同的ASIL分離軟件任務的可能性。

在這一步建立了ASIL能力。

9.2.3.4步驟1b-系統(tǒng)層面的設計的假設

一些系統(tǒng)層面設計假設的示例，對SEooC的外部：

A.該系統(tǒng)將在單片機電源上實現(xiàn)安全機制，以檢測過電壓和欠電壓故障模式。

B.該系統(tǒng)將在單片機外部實現(xiàn)一個窗口看門狗安全機制，以檢測單片機的時鐘或程序序列故障。

C.針對單片機EDC安全機制中的潛在故障，將進行軟件測試。

D.在關鍵時刻執(zhí)行基于SW的測試，以驗證CPU程序序列的邏輯監(jiān)控中沒有潛在故障。

E.在與安全有關的操作中，不使用單片機的調(diào)試接口。因此，調(diào)試邏輯中的任何故障都將被視為安全故障。

9.2.3.5步驟2-硬件開發(fā)的執(zhí)行

在這些決定的基礎上(假定的技術安全需求和與SEooC以外的設計相關的假設)，以ISO26262-5描述的SEooC被開發(fā)（步驟2），并準備每個適用的工作成果。例如，由于隨機硬件故障而違反安全目標的評估(見ISO26262-5：2018的9.5.1中描述的工作成果)是考慮到SEooC假設的，包括假定的技術安全需求中發(fā)現(xiàn)的FIT率的任何預算。在SEooC假設的基礎上，參照ISO26262-9對單片機內(nèi)部相關故障進行了安全分析和分析。

9.2.3.6步驟3-工作成果

在MCU產(chǎn)品開發(fā)結(jié)束（步驟3），將工作成果中的必要信息提供給系統(tǒng)集成商。這包括以下文件：假設要求、與SEooC以外的設計有關的假設以及ISO26262系列標準的適用工作成果(例如，關于由于隨機硬件故障而違反安全目標的概率的報告)。

9.2.3.7步驟4-將SEooC集成到系統(tǒng)中

當在相關項硬件產(chǎn)品開發(fā)階段考慮作為SEooC開發(fā)的MCU時，所有SEooC假設的有效性，包括SEooC假設的技術安全需求和與SEooC外部設計相關的假設（步驟4）?？赡艿氖?，SEooC假設和系統(tǒng)需求之間會發(fā)生不匹配。例如，相關項開發(fā)者可以決定不實現(xiàn)假定的外部組件。因此，由于SEooC開發(fā)者所做的隨機硬件故障而導致的安全目標違規(guī)的評估可能不再與該相關項一致。

在SEooC假設不匹配的情況下，從影響分析開始的變更管理活動按照【變更管理】（ISO26262-8：2018的第8條）進行。潛在成果包括：

?在實現(xiàn)安全目標方面，這種差異可以被認為是可以接受的，不采取任何行動。

?這種差異可以被認為影響了安全目標的實現(xiàn)，對功能安全概念或技術安全需求都可能需要改變。

?差異可視為影響安全目標的實現(xiàn)，并需要對SEooC組件進行變更（可能包括組件的變更）。

?差異可以被視為影響安全目標的實現(xiàn)，因此安全度量被重新計算，但重新計算的度量表明設計滿足系統(tǒng)目標，因此不需要變更。

9.2.4.開發(fā)一個作為獨立于環(huán)境安全要素的軟件組件示例

9.2.4.1概述

這個條款說明了將SEooC概念應用于新的中/低級別軟件組件的不同步驟。流程如圖24所示。

注1：根據(jù)SEooC的確切性質(zhì)，可能需要對需求進行一些額外的裁剪。

注2：根據(jù)SEooC的確切性質(zhì)，ISO26262-6的一些要求不適用，因此只作了零元器件考慮。

注3：雖然ISO26262系列標準的所有條款都沒有顯示，但這并不意味著它們不適用。

圖24-SEooC軟件組件開發(fā)

9.2.4.2步驟1a-關于軟件組件作為SEooC的范圍的假設

該步驟旨在說明有關軟件組件的目的、其邊界、目標環(huán)境、功能和特性的相關假設。這些假設的示例包括：

?軟件組件集成到給定的軟件分層架構(gòu)中。

?由軟件組件引起的任何潛在干涉是在其環(huán)境中監(jiān)測和處理的。

?軟件組件提供假定的軟件功能需求中指定的功能：功能性軟件要示清單。

9.2.4.3步驟1b-關于軟件組件安全需求的假設

步驟1b意在對可能影響軟件組件的更高級別安全需求作出假設，以得出其軟件安全需求。例如，如果假設由軟件組件計算的給定數(shù)據(jù)集具有高完整性(ASILx)，則分配給SEooC的軟件安全需求可以是：

?軟件組件檢測輸入數(shù)據(jù)上可能違反安全目標的任何損壞(ASILx)；

?軟件組件根據(jù)假定的技術安全需求(ASILx)發(fā)出要通知的錯誤條件的信號；

?對檢測到的任何錯誤條件(ASILx)返回一個默認值，并具有故障狀態(tài)(ASILx)；及

?軟件組件返回以下用CRC和狀態(tài)(ASILx)編碼的結(jié)果。

9.2.4.4步驟2-軟件組件的開發(fā)

一旦明確說明了對軟件組件的必要假設，SEooC是根據(jù)ISO26262-6的要求開發(fā)的，對應于其ASIL能力(本例中為ASILx)。所有適用的工作成果都可在不同的環(huán)境中進一步集成，包括與驗證假定的軟件安全需求有關的工作成果。

9.2.4.5步驟3-在新的特定使用環(huán)境中集成軟件組件

在軟件組件與新的特定使用環(huán)境中的其他軟件組件集成之前，將檢查在此SEooC上所做的所有假設的有效性。這包括假定的軟件安全需求及其ASIL能力，以及對軟件組件的目的、邊界、目標環(huán)境、功能和屬性所作的所有假設（見9.2.4.2和9.2.4.3）。

如果有關軟件組件的某些假設不符合這一新使用環(huán)境，則根據(jù)【變更管理】（ISO26262-8：2018的第8條）啟動影響分析。影響分析的潛在結(jié)果包括：

?在實現(xiàn)軟件架構(gòu)設計層面適用的安全需求方面，這些差異是可以接受的，沒有采取進一步行動。

?這些差異影響了軟件架構(gòu)設計水平上適用的安全需求的實現(xiàn)，根據(jù)【變更管理】（ISO26262-8：2018的第8條），這些要求可能需要進行變更。

?這些差異影響了軟件架構(gòu)設計級別適用的安全需求的實現(xiàn)，并根據(jù)【變更管理】（ISO26262-8：2018的第8條）要求對SEooC組件（可能包括組件的變更）進行變更。

注：如果軟件組件在特定軟件架構(gòu)設計中的集成導致具有不同ASIL的軟件安全相關要素共存，則符合【要素共存標準】（ISO26262-9：2018第6條）所述要素共存的標準，或者將具有較低ASIL的要素升級到較高的ASIL。

責任編輯：xj

原文標題：SEooC使用案例ISO26262:2018-10-9.2

文章出處：【微信公眾號：汽車電子硬件設計】歡迎添加關注！文章轉(zhuǎn)載請注明出處。