-
安全需求規(guī)范
- 安全需求的標記法
對應(yīng)于2.2章節(jié)中的安全需求特性，通過如下組合來定義安全需求：
- 自然語言（適應(yīng)于較高層面的安全需求，如功能和技術(shù)安全需求）；
- 表1中所列舉方法（適應(yīng)于較低層面的安全需求，如軟件和硬件安全需求）；
表1 定義安全需求
| 方法 |
ASIL |
||||
| A |
B |
C |
D |
||
| 1a |
用于需求定義的非正式標記法 |
++ |
++ |
+ |
+ |
| 1b |
用于需求定義的半正式標記法 |
+ |
+ |
++ |
++ |
| 1c |
用于需求定義的正式標記法 |
+ |
+ |
+ |
+ |
- 注1：安全要求定義方法的恰當選擇考慮：針對特定問題待定義的安全要求，方法是否足夠準確以具備相關(guān)規(guī)定的安全要求的特性；方法的復(fù)雜性；定義或管理安全要求的人員的背景知識。示例包括使用狀態(tài)圖或關(guān)系圖來定義軟件或硬件的復(fù)雜行為，包括許多狀態(tài)或/和復(fù)雜轉(zhuǎn)換。
- 注2：對于高等級的安全需求（安全目標、功能技術(shù)安全需求和技術(shù)安全需求）自然語言和其他類型非正式語言較為適合，有些要求可能用半形式記法更好處理。
- 注3：半形式記法使用數(shù)學或圖形要素【如方程、圖形、圖表、流程圖、時序圖和許多其他形式的表示(例如 UML?和 SysML?)】補充的自然語言來表達需求。示例包括基于模型的技術(shù)，以及在自然語言中為要求描述語句應(yīng)用模板和受控詞匯表。
- 注4：對于低等級的安全需求，如詳細的軟件及硬件的行為、能力等，可明確定義，以半形式符號描述更加清晰；但不應(yīng)該要求所有需求進行半形式化描述；
- 安全需求的特性和特點
- 安全需求應(yīng)能被明確識別出。
- 注：安全需求應(yīng)被列在單獨的文檔中，如果安全需求與其他需求在同一個文檔中，安全需求應(yīng)被明確標識出；
- 安全需求應(yīng)繼承原安全需求的ASIL等級，安全目標已被分解的除外；
- 注：安全目標是頂層的安全需求，對于ASIL等級的繼承始于安全目標水平；
- 安全需求應(yīng)被分配給實現(xiàn)這些要求的相關(guān)項或元素；
- 安全需求需具備如下特性：
- 明確的，無歧義的；
- 可理解；
- 不可分割，即不可再被細化為一個以上的需求；
- 注：在此特性與其他重要的安全要求特性相反時，不可分割性的重要性可被降低；
- 內(nèi)部一致：即每個單獨的安全需求不包含自相矛盾的內(nèi)容（不同于外部一致性，外部一致性指多個安全需求不含有相互抵觸的內(nèi)容）；
- 可實現(xiàn)的；
- 注：如果某個要求在相關(guān)項的開發(fā)限制（資源、當前技術(shù)水平等）內(nèi)可被實現(xiàn)，則其是可行的。
- 注：一項要求在技術(shù)上可以實現(xiàn)，它不需要重大的技術(shù)進步，并且在可接受范圍內(nèi)符合相關(guān)項限制（如成本、進度、技術(shù)、法律、法規(guī)等）；
- 可驗證的；
- 注：如果在定義要求的層面上有方法檢查這些要求是否得到了滿足，則要求是可驗證的。
- 注：收集到有關(guān)相關(guān)項的證據(jù)表明相應(yīng)的要求已得到滿足。如果要求是可測量的，可驗證性會更強。
- 必要的；
- 注：某項需求定義了一項重要的能力、特性、約束或質(zhì)量要素，如果該需求被移除或刪除，會導(dǎo)致產(chǎn)品的其他能力或流程無法滿足要求；
- 注：需求當前適用，沒有被廢棄；需求應(yīng)明確標識截止日期或使用時間；
- 實施自由的
- 注：僅描述需求應(yīng)陳述要求是什么，而不是如何滿足要求；不要對架構(gòu)的設(shè)計做太多不必要的限制；
- 完整的；
- 注：對需求的表述要清晰，不進行進一步擴充。
- 合規(guī)的：
- 注：符合政府法規(guī)、汽車行業(yè)和產(chǎn)品標準、規(guī)范及接口要求。
- 安全需求屬性
安全需求應(yīng)具有如下屬性，
- XXX安全需求在安全生命周期內(nèi)，具有唯一識別并保持不變。
- ASIL等級；
- 安全需求的狀態(tài)
示例：安全需求的狀態(tài)可以是Draft（未通過評審和批準）及Released（通過評審和批準的）；
- 其他類型的
安全目標：安全狀態(tài)、FTTI等??
功能安全需求可能有：運行模式，故障容錯時間區(qū)間（間隔）或故障容錯時間，安全狀態(tài)，緊急操作時間區(qū)間，功能冗余幾種屬性。
對技術(shù)安全需求、軟件安全需求、硬件安全需求的要求參見公司功能安全流程的相關(guān)文件（在下面表格中，ID，ASIL等級，Status使用了加粗字體代表必選，其他的屬性用正常字體代表可選屬性的舉例）
-
-
- 安全目標
-
表2 安全目標屬性描述
| 屬性 |
屬性描述 |
| ID |
|
| ASIL等級 |
|
| Status |
|
| 安全狀態(tài) |
|
| FTTI |
-
-
- 功能安全需求
-
表3 功能安全需求屬性描述
| 屬性 |
屬性描述 |
| ID |
|
| ASIL等級 |
|
| Status |
|
| 運行模式 |
|
| 故障容錯時間 |
|
| 安全狀態(tài) |
|
| 緊急操作時間區(qū)間 |
|
| 功能冗余 |
|
| 緊急操作 |
|
| 報警、降級 |
-
-
- 技術(shù)安全需求
-
表4 技術(shù)安全需求屬性描述
| 屬性 |
屬性描述 |
| ID |
|
| ASIL等級 |
|
| Status |
|
| 外部接口 |
|
| 限制條件 |
|
| 系統(tǒng)配置要求 |
-
-
- 軟件安全需求
-
表5 軟件安全需求屬性描述
| 屬性 |
屬性描述 |
| ID |
|
| ASIL等級 |
|
| Status |
|
| 維持安全狀態(tài) |
|
| 硬件故障監(jiān)控處理 |
|
| 軟件故障監(jiān)控處理 |
|
| 是否車載測試 |
|
| 生產(chǎn)維護過程中是否可修改 |
|
| 與性能或時間敏感 |
-
-
- 硬件安全需求
-
表6 硬件安全需求屬性描述
| 屬性 |
屬性描述 |
| ID |
|
| ASIL等級 |
|
| Status |
|
| 控制要素內(nèi)部失效 |
|
| 對外部失效容錯 |
|
| 符合其他要素的安全需求 |
|
| 故障探測 |
|
| 未定義安全機制的硬件 |
-
安全需求管理
- 安全需求的管理方式
- 通過《System Safety Requirements Traceability Matrix 》表格對安全需求進行管理
每一層子需求都需要滿足上一層的母需求，使用《System Safety Requirements Traceability Matrix 》表格的Source Traceability部分標注追溯關(guān)系。參閱表格的相關(guān)標注。
- 安全需求的管理需要滿足：
- 分層結(jié)構(gòu)
注：如圖1所示，分層結(jié)構(gòu)是指安全需求分布在幾個連續(xù)層面上的。這些層面與產(chǎn)品開發(fā)階段一致。
- 合理的架構(gòu)
注：與架構(gòu)相對應(yīng)，安全需求在每個層面都應(yīng)進行合理地分組；
- 完整性
注：一個層面的安全需求完整地落實了前一層面的全部安全需求。
- 外部一致性
注：不同于內(nèi)部一致性（每個單獨的安全需求不包含自相矛盾的內(nèi)容），外部一致性表示多個安全需求不互相抵觸。
- 分層結(jié)構(gòu)中任意一層的信息不重復(fù)
注：信息不重復(fù)表示安全需求的內(nèi)容不重復(fù)出現(xiàn)在分層結(jié)構(gòu)同一層面的其它安全需求中；
- 可維護性
注：可維護性表示需求集可被修改或擴展，例如引入需求的新版本或增加/去掉需求集內(nèi)的需求。
注：當安全需求符合 ?2.2安全需求的特性和特點 與 3.1安全需求的管理方式 時，安全需求的可維護性更好。
??????????????????????????? ??????? ?????? 圖1 安全要求的結(jié)構(gòu)
- 安全需求應(yīng)置于配置管理之下
?????? 當較低層面的安全需求與較高層面的安全需求相符合時，配置管理可定義一個基線作為安全生命周期后續(xù)階段的基礎(chǔ)。
-
- 安全需求的追溯性要求
使用《System Safety Requirements Traceability Matrix 》表格的Source Traceability部分標注追溯關(guān)系。參閱表格的相關(guān)標注。
安全需求應(yīng)當是可追溯的，
- 安全需求源自于更高層級的安全需求；
- 安全需求導(dǎo)出到更低層級，或?qū)С鲋猎O(shè)計中來實現(xiàn)。
- 按照《驗證過程管理規(guī)定》中有關(guān)“驗證規(guī)范”的章節(jié)中，驗證規(guī)范所描述的測試案例，均可以追溯每個安全需求是被充分驗證的。
注1:可使用各種追溯記錄類型，如需求管理系統(tǒng)、電子材料等；
注2：可追溯性另外還支持了：
- 實現(xiàn)安全需求、實現(xiàn)、驗證之間的一致性；
- 對特定安全需求進行更改時的影響分析；
- 認可措施（如功能安全評估，以評估功能安全實現(xiàn)與否）的執(zhí)行。
- 安全需求的追溯內(nèi)容
安全需求的追溯應(yīng)包括：
- 安全目標與功能安全需求之間的雙向追溯性
- 安全目標與安全確認測試用例之間的雙向追溯性
- 功能安全需求與技術(shù)安全需求之間的雙向追溯性
- 功能安全需求與整車集成測試用例之間雙向追溯性
- 技術(shù)安全需求與硬件安全需求
- 技術(shù)安全需求與軟件安全需求
- 硬件安全需求與硬件設(shè)計
- 硬件安全需求與硬件集成測試用例
- 軟件安全需求與軟件架構(gòu)設(shè)計
- 軟件安全需求與嵌入式軟件測試用例
- 軟件架構(gòu)設(shè)計與軟件詳細設(shè)計
- 軟件架構(gòu)設(shè)計與軟件集成測試用例
- 軟件詳細設(shè)計與軟件單元測試用例
- 驗證方法
應(yīng)將表2中所列舉的驗證方法，用于驗證安全需求是否符合本章節(jié)的要求，及是否符合得出安全需求的公司功能安全流程體系相關(guān)部分中關(guān)于驗證安全需求的特定要求。
表7 驗證安全要求的方法
| 方法 |
ASIL |
||||
| A |
B |
C |
D |
||
| 1a |
通過走查驗證 |
++ |
+ |
o |
o |
| 1b |
通過檢查驗證 |
+ |
++ |
++ |
++ |
| 1c |
半形式驗證 |
+ |
+ |
++ |
++ |
| 1d |
形式驗證 |
o |
+ |
+ |
+ |
| *可執(zhí)行模型可以支持方法1c | |||||
-
安全需求的分解
- 安全需求分解的條件
- 對功能安全需求進行ASIL分解需具備功能安全需求和功能安全概念；
- 對技術(shù)安全需求進行ASIL分解需具備技術(shù)安全需求和技術(shù)安全概念；
- 對軟件安全需求進行ASIL分解需具備軟件安全需求和軟件安全架構(gòu)；
- 對硬件安全需求進行ASIL分解需具備硬件安全需求和硬件安全架構(gòu)；
- 分解后的安全需求必須互相冗余，且由相互獨立的元素執(zhí)行。
- 安全需求分解的標識
分解后的安全需求的ASIL等級表示方法為 ASIL X (Y)，其中X為分解后的ASIL等級，Y為安全目標的ASIL等級。
示例：如果一個ASIL D的需求分解成一個ASIL C的需求和一個ASIL A的需求，則應(yīng)標注成“ASIL C(D)”和“ASIL A(D)”. 如果ASIL C(D)的需求進一步分解成一個ASIL B 的需求和一個ASIL A的需求，則應(yīng)使用安全目標的ASIL等級將其標注為”ASILB(D)”和“ASILA(D)”。
-
- 安全需求分解的模式
按照如下模式進行安全需求的分解，或可使用得出更高ASIL等級的方案。
- 按照圖2所示對ASIL D的安全需求進行分解：
圖2：ASIL D分解方案
- 一個ASIL C(D) 的需求和一個ASIL A(D)的需求；或
- 一個ASIL B(D) 的需求和一個ASIL B(D)的需求；或
- 一個ASIL D(D)的要求和一個QM(D)的要求。
當分解為兩個ASIL B(D)的安全需求時，額外的要求如下：
- 參照表1中ASIL C的要求來定義分解后的安全需求。
- 如果用相同的軟件工具開發(fā)分解后的元素，那么這些軟件工具應(yīng)考慮為開發(fā)ASIL D相關(guān)項或元素的軟件工具，并符合《TK_P_SUP_06 工具評估流程》中軟件工具使用的置信度。
- 按照圖3所示對ASIL C的安全需求進行分解：
圖3：ASIL C分解方案
- 一個ASIL B(C) 的需求和一個ASIL A(C)的需求；或
- 一個ASIL C(C) 的需求和一個QM(C)的需求。
- 按照圖4所示對ASIL B的安全需求進行分解：
圖4：ASIL B分解方案
- 一個ASIL A(B) 的需求和一個ASIL A(B)的需求；或
- 一個ASIL B(B) 的需求和一個QM(B)的需求。
- 一個ASIL A 的需求不應(yīng)進一步分解，除非需要分解成一個ASIL A(A) 的需求和一個QM(A) 的需求，如圖5所示：
圖5：ASIL A分解方案
- 如果對初始安全需求的ASIL 分解是將分解后的需求分配給預(yù)期功能及相關(guān)安全機制，則相關(guān)安全機制宜被賦予分解后的最高ASIL等級。另一方面安全需求應(yīng)被分配給預(yù)期功能，并按照相應(yīng)分解后的ASIL等級執(zhí)行。
- 安全需求分解的相關(guān)要求
- ASIL分解可以多次應(yīng)用；
- 初始安全需求應(yīng)分解為獨立安全要素執(zhí)行的冗余安全需求；
- 進行ASIL等級分解時，應(yīng)分別考慮每一個初始的安全要求。應(yīng)針對每一個初始安全需求單獨進行ASIL分解；
- 初始安全要求應(yīng)分解為冗余安全要求，并由充分獨立要素實現(xiàn)。如果相關(guān)失效分析沒有找到導(dǎo)致違反初始安全要求的合理原因，或者根據(jù)初始安全要求的ASIL等級，所識別的相關(guān)失效的每個原因都被充分的安全措施控制，則這些要素具有充分的獨立性；
注1：一條被分解的要求可能是幾個初始安全要求分解的結(jié)果。
注2：使用同構(gòu)冗余來實現(xiàn)分解的要求（例如，通過復(fù)制的設(shè)備或復(fù)制的軟件）并不能解決硬件和軟件系統(tǒng)性失效。 除非相關(guān)失效的分析（參見第7章）提供了充分的獨立性證據(jù)或存在潛在共因可進入安全狀態(tài)的證據(jù)，否則不允許ASIL等級的降低。因此，在沒有針對特定系統(tǒng)應(yīng)用背景的相關(guān)失效分析的支持下，單靠同構(gòu)冗余通常不足以降低ASIL等級。
注3：ASIL等級分解通常不適用于在多通道架構(gòu)設(shè)計中確保通道選擇或通道切換的要素。 應(yīng)用ASIL分解時，需提供分解后安全需求冗余且執(zhí)行元素相互獨立的證據(jù)。
- 硬件架構(gòu)指標(SPFM, LFM)和隨機硬件失效導(dǎo)致違背安全目標的指標(PMHF)需參照安全目標的ASIL等級來要求。即便進行了ASIL分解，這些硬件相關(guān)的指標也維持不變
- 每個分解后的安全需求應(yīng)符合初始安全需求
注4：此要求通過定義提供了冗余。
注5：如果將分解后的安全要求分配給安全機制，則應(yīng)在評估分解后的要求是否符合初始安全要求時，考慮該安全機制的有效性。
示例：分配給指定ECU的ASIL D要求，可能被輕易的分解為分配給ECU中簡單看門狗的ASIL D要求和該ECU微處理器的QM安全要求。然而，這個簡單的看門狗不足以覆蓋ASIL D要求的微處理器的失效模式。在這種情況下，該看門狗不能有效地滿足初始的安全要求。
- 如果在軟件層面應(yīng)用ASIL 分解，應(yīng)在系統(tǒng)層面檢查執(zhí)行分解后的元素間的充分獨立性，如果有必要，應(yīng)在軟件層面、硬件層面或系統(tǒng)層面采取適當?shù)拇胧﹣慝@得充分的獨立性；
- 如果不能通過關(guān)閉元素來阻止對初始安全需求的違背，則應(yīng)展示執(zhí)行分解后安全需求的充分獨立的元素具備足夠的可用性；
- 應(yīng)至少按照分解后的ASIL等級要求，在系統(tǒng)層面和軟件層面開發(fā)分解后的要素；
- 應(yīng)至少按照分解后的ASIL等級要求，在硬件層面開發(fā)分解后的要素，但硬件架構(gòu)指標(SPFM, LFM)和隨機硬件失效導(dǎo)致違背安全目標的指標(PMHF)除外；
- 按照分解前的ASIL等級要求開展對分解后的元素的相關(guān)集成活動及后續(xù)活動；
- 同質(zhì)冗余（復(fù)制設(shè)備或復(fù)制軟件）因缺少要素間的獨立性，通常不足以降低ASIL等級；
- ASIL分解完成后需更新相應(yīng)安全需求的ASIL等級和相應(yīng)的架構(gòu)設(shè)計；
- ASIL分解不適用于在多通道架構(gòu)設(shè)計中用來確保通道選擇或開關(guān)的要素；
- 如果架構(gòu)要素不是充分獨立的，則冗余需求和架構(gòu)要素繼承初始的ASIL等級；
- 如果對初始安全要求的ASIL等級分解導(dǎo)致將分解后的要求分配給預(yù)期功能及相關(guān)安全機制，則： a) 相關(guān)安全機制宜被分配分解后的較高ASIL等級；及
注1：通常，與預(yù)期功能相比，安全機制具備較低的復(fù)雜度和更小的規(guī)模。安全要求應(yīng)被分配給預(yù)期功能，并按照相應(yīng)分解后的ASIL等級實現(xiàn)。
注2：如果選擇了分解方案 ASILx(x) +QM(x)，則 QM(x)意味著質(zhì)量管理體系足以實現(xiàn)預(yù)期功能要素安全要求的開發(fā)。
-
子元素的ASIL等級確定準則
- 初始ASIL等級為QM的子元素的ASIL等級的確定
如果未分配ASIL等級的子元素和安全相關(guān)子元素共同存在于同一元素中，如果能證明未分配ASIL等級的子元素不能直接或間接地違背分配給該元素的任何安全需求，即：未分配ASIL等級的子元素不能干擾元素中安全相關(guān)的任何子元素，則應(yīng)僅視其為QM的子元素。
注1：該子元素到安全相關(guān)元素的級聯(lián)失效是不存在的。
注2：可通過設(shè)計措施獲得，諸如考慮軟件的數(shù)據(jù)流和控制流，或硬件的輸入/輸出信號及控制線。
否則，應(yīng)將不具備免于干擾證據(jù)的共存安全相關(guān)子元素的最高ASIL等級分配給該子元素。
-
- 具備不同的初始ASIL等級的子元素的ASIL等級的確定
如果同一元素中存在不同ASIL等級（包括QM(x)）的安全相關(guān)子元素，若能證明對分配給元素的每個安全需求，某個子元素不會干擾任何分配了較高ASIL等級的其它子元素，則應(yīng)僅視該子元素為較低ASIL等級的子元素。否則，由于不具備免于干擾的證據(jù)，應(yīng)將共存安全相關(guān)子元素的最高ASIL等級分配給該子元素。文章來源：http://www.zghlxwxcb.cn/news/detail-450322.html
注： 對免于干擾的評估應(yīng)與分配給共存的子要素的最高ASIL等級要求相匹配文章來源地址http://www.zghlxwxcb.cn/news/detail-450322.html
到了這里，關(guān)于安全需求規(guī)范和管理指南的文章就介紹完了。如果您還想了解更多內(nèi)容，請在右上角搜索TOY模板網(wǎng)以前的文章或繼續(xù)瀏覽下面的相關(guān)文章，希望大家以后多多支持TOY模板網(wǎng)！
