9.2.使用案例

9.2.1.概述

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

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

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

圖21-假設與SEooC開發之間的關系

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

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

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

9.2.2.開發一個作為SEooC的系統

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

為了本示例的目的，系統包括在某些車輛條件下激活功能和允許在適當的駕駛員請求下解除功能的功能。流程如圖22所示。

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

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

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

圖22-SEooC系統開發

步驟1a-定義SEooC的范圍

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

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

?該系統是為總質量不超過1800公斤的車輛而設計的。

?該系統是為前輪驅動的車輛設計的。

?該系統設計最大道路坡度為32%而設計的。

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

?功能要求：

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

l當駕駛員請求時，系統會解除功能。

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

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

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

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

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

關于SEooC使用環境的假設示例可以是：

?外部源可以提供具有所需 ASIL 等級的信息，使系統能夠檢測適當的車輛狀況(ASILx)。

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

步驟2-SEooC的開發

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

步驟3-工作成果

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

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

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

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

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

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

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

9.2.3.開發一個作為獨立于環境的安全要素的硬件組件

9.2.3.1概述

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

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

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

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

圖23-SEooC硬件組件開發

9.2.3.2步驟1-系統層面的假設

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

系統層面屬性和要求按照ISO26262-2：2018的6.4.5.7。

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

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

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

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

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

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

c.為了實現安全狀態，當斷言復位時，MCU將所有I/O輸出驅動到低狀態。

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

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

在這一步建立了ASIL能力。

9.2.3.4步驟1b-系統層面的設計的假設

一些系統層面設計假設的示例，對SEooC的外部：

A.該系統將在單片機電源上實現安全機制，以檢測過電壓和欠電壓故障模式。

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

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

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

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

9.2.3.5步驟2-硬件開發的執行

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

9.2.3.6步驟3-工作成果

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

9.2.3.7步驟4-將SEooC集成到系統中

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

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

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

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

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

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

9.2.4.開發一個作為獨立于環境安全要素的軟件組件示例

9.2.4.1概述

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

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

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

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

圖24-SEooC軟件組件開發

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

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

?軟件組件集成到給定的軟件分層架構中。

?由軟件組件引起的任何潛在干涉是在其環境中監測和處理的。

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

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

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

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

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

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

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

9.2.4.4步驟2-軟件組件的開發

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

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

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

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

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

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

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

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

責任編輯：xj

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

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