在ISO 26262功能安全標準體系解讀（上）中，我們?yōu)榇蠹医榻B了：什么是功能安全？功能安全的制定經(jīng)歷了什么樣的歷程？什么是ISO 26262?如何評估ASIL？
通過危害分析和風險評估，我們得出系統(tǒng)或功能的安全目標和相應的ASIL等級。當ASIL等級確定之后，就需要對每個評定的風險確定安全目標，安全目標是最高級別的安全需求。安全目標確定之后，就需要在系統(tǒng)設計、硬件、軟件等方面進行設計、實施和驗證。
從安全目標可以推導出開發(fā)階段的安全需求，安全需求繼承安全目標的ASIL等級。那么，要如何繼承項目的安全需求呢？
接下來我們將先為大家說明如何繼承安全需求。
產(chǎn)品開發(fā)階段中功能安全需求的繼承
下圖為功能安全需求繼承的流程圖：
1.安全目標設定
如何提出系統(tǒng)安全需求是系統(tǒng)安全設計的第一步，系統(tǒng)安全需求的指導方針在現(xiàn)代安全法規(guī)中通常被表述為“安全目標設定”，它描述了所需實現(xiàn)的系統(tǒng)安全目標，并根據(jù)系統(tǒng)安全目標選擇相應的實現(xiàn)方法和途徑。
對所實施ISO 26262的項目，應用危險分析和風險評定以及評估ASIL等級，來避免不可接受的風險，并確定項目的安全目標。所謂的安全目標，就是為了防止在特定駕駛狀態(tài)下發(fā)生危險事件而采取的功能需求。通過危害分析和風險評估，為每一個風險確定一個ASIL等級，而安全目標就是為了每一個風險而設定的。
2.功能安全需求的設定（功能安全概念）
為了符合功能安全目標，在功能安全概念中規(guī)定了項目的功能安全需求。
所謂的功能安全概念，是指得出實現(xiàn)安全目標所需的功能安全要求，并將他們分配到初步的設計架構，或者外部減少危險的措施當中去，以確保滿足相關的功能安全。
所謂的功能安全需求，是一種安全措施（減少有害影響的活動或解決方案），且該安全措施不依賴于以安全目標為基礎的項目安全行為規(guī)范和實施。
安全目標和功能安全需求之間的關系是分層的，如下圖所示。
3.技術安全需求的設定（技術安全概念）
為了在項目中實現(xiàn)功能安全需求，必須根據(jù)技術安全概念，將項目級別的功能安全需求細化為系統(tǒng)級別所需要的技術安全需求。
所謂的技術安全需求，是為了實現(xiàn)功能安全需求，系統(tǒng)應具備的技術性安全措施。
所謂的技術安全概念，是說明如何實現(xiàn)技術安全需求規(guī)范。
在整個開發(fā)生命周期，技術安全需求是要落實功能安全概念的技術需求，其用意是從細節(jié)的單級功能安全需求到系統(tǒng)級安全技術需求。
4.系統(tǒng)設計
在系統(tǒng)設計階段，系統(tǒng)及子系統(tǒng)需要按上面所定義的貫徹技術安全要求，設計出符合系統(tǒng)規(guī)范的開發(fā)方法。這里，不僅考慮安全需求，還考慮非安全需求(ASIL等級表中被判定為“QM”的要求)。為了實現(xiàn)技術安全要求，必須考慮到系統(tǒng)設計的可驗證性，實現(xiàn)功能安全的技術能力以及系統(tǒng)集成期間的測試可行性。
將實施所需規(guī)范中的技術安全要求集合，即為系統(tǒng)規(guī)范樣式。
系統(tǒng)規(guī)范應直接或通過進一步細化到硬件，軟件或兩者兼有。此外，設計硬件 - 軟件接口（HSI），規(guī)定硬件和軟件的交互，并應與技術安全的概念一致。
另外，系統(tǒng)規(guī)范必須驗證對技術安全概念的符合性和完整性。
在7月29日的系統(tǒng)功能安全開發(fā)實踐技術培訓中，來自國際Tier 1的實踐專家，會介紹如何完成系統(tǒng)與軟硬件的接口的設計和規(guī)范，還將結合實例深入講解如何進行安全管理，安全分析，確定安全目標，F(xiàn)MEA，F(xiàn)TA的分析方法應用，以及FTTI，技術安全需求及接口等，歡迎近期需要導入安全標準的企業(yè)前來參加。
5.硬件安全需求和功能安全的硬件開發(fā)
根據(jù)分配給硬件的技術安全要求，可以獲得硬件安全需求。硬件安全需求主要用于保證控制器內(nèi)部硬件故障的安全機制的安全要求。
ISO 26262所要求的硬件設計的要點，一是定量地實施對硬件架構指標的評估，二是由于偶發(fā)硬件故障而導致的隨機失效率的評估。
硬件架構指標，是用于評估硬件架構對硬件的偶然故障的影響（魯棒性）的指標，且為定量數(shù)值，由標準定義的公式來確定。
隨即失效率，是基于概率論，用來評價安全機制在安全性的邏輯支持之下的有效性。
6.軟件安全需求的規(guī)范
軟件安全要求以因故障引起技術安全要求偏離的功能為對象，并將其細化定義至可實施/驗證軟件的等級。
在軟件安全要求的設計方面，需要考慮指定的系統(tǒng)和硬件配置，硬件/軟件接口，硬件安全要求，時間限制，與項目外部視圖的接口，受軟件影響的車輛，系統(tǒng)以及硬件涉及的各個動作模式。
軟件安全要求規(guī)范還必須驗證與技術安全概念、系統(tǒng)規(guī)范、硬/軟件接口規(guī)范的兼容性和一貫性。
功能安全的軟件級開發(fā)
符合功能安全的軟件開發(fā)有什么不一樣的嗎？
1.軟件安全要求的可追溯性
ISO 26262要求將各危險風險降低設定為安全目標，并且在整個開發(fā)過程中，保證測試結果都可以通過其驗證測試、實施、規(guī)范和要求來追溯。這就是功能安全的可追溯性。可追溯性可通過給需求添加ID號碼來識別。
在軟件開發(fā)中，ID號碼用于關聯(lián)軟件安全需求標準的軟件安全需求（相當于軟件功能設計）、軟件架構設計標準的軟件組件以及軟件單元設計標準的函數(shù)（如下圖）。 這使得安全需求的關系明確，并且通過驗證和試驗，可以有效地發(fā)現(xiàn)對于上級要求來說的下級要求存在的遺漏，以及對函數(shù)不良影響的條件的影響等。
關于需求的可追溯性管理，可使用軟件開發(fā)中的需求管理工具來實現(xiàn)。
2.設計方法
在ISO 26262中，軟件想要達到系統(tǒng)所分配的更高安全目標的ASIL D等級，就需要更加嚴謹?shù)能浖軜嫛?/div>
在軟件架構設計中，如果想要達到符合ASIL D等級，就必須滿足軟件組件的分層化、軟件組件大小的限制、適當?shù)恼{(diào)度、軟件組件的內(nèi)聚、耦合限制和中斷限制。
在各種軟件設計的方法中，結構化設計方法已經(jīng)不是什么新鮮的方法了。但在ISO 26262中，顯然，該方法是處理應對ASIL相應等級的必須手段。
在軟件架構級別的錯誤檢測階段中，對于ASIL D的要求，必須進行輸入輸出數(shù)據(jù)的范圍檢查、數(shù)據(jù)有效性檢查、外部監(jiān)控、控制流監(jiān)視和軟件冗余設計。
在軟件架構級別的錯誤處理階段中，對于ASIL D的要求，必須具有發(fā)生錯誤時的縮退功能以及并行的冗余。
在單體軟件設計階段中，對于ASIL D的要求，相關函數(shù)只能有1個出入口，限制動態(tài)安全對象（例如堆棧區(qū)域），執(zhí)行變量初始化，禁止相同變量名稱，限制使用全局變量，限制指針使用，禁止隱式類型轉(zhuǎn)換，禁止隱藏數(shù)據(jù)流/控制流，禁止無條件跳轉(zhuǎn)，禁止遞歸調(diào)
ISO 26262沒有深入涉及建模設計。關于汽車建模設計（基于模型的開發(fā)），MATLAB / Simlink被認為是典型方法，盡管如此，執(zhí)行建模設計并不一定有助于導入功能安全。
不基于模型設計的軟件開發(fā)代碼質(zhì)量，與基于模型設計的軟件開發(fā)代碼質(zhì)量是相同的。在建模設計中提高模型的質(zhì)量，也有助于由此產(chǎn)生的產(chǎn)品（項目）的安全性。關于設計模型時的指南，ISO 26262結合編碼指南定義了設計指南的要求。
針對特殊的應用場合，軟件安全設計還涉及信息安全，以及面向自動駕駛的預期功能安全等相關考量，具體的實施上需要制定合適的安全機制，安全架構（比如E-GAS安全架構），并進行滿足安全標準的測試，軟件部分與ASPICE有諸多重疊支出，將二者融合起來執(zhí)行，能夠更加全面的改進軟件安全和質(zhì)量。
3.驗證
所謂“驗證”，就是確認已“正確”完成產(chǎn)品開發(fā)。
在ISO26262中，關于軟件架構設計、軟件單體設計和實現(xiàn)(編碼)，規(guī)定需要完成與ASIL等級相對應的驗證。
對于軟件架構設計驗證，如果是ASIL A級別，只要排查就足夠了。但如果是達到符合ASIL D級別，則必須進行檢查，動態(tài)（可執(zhí)行模型）仿真，原型設計，控制流/數(shù)據(jù)流分析。
對于軟件單一設計和實現(xiàn)（編碼）驗證，如果是ASIL A級別，只要排查就足夠了。但如果是達到符合ASIL D級別，就必須進行檢查，半正式驗證（使用基于模型的仿真驗證等），控制流/數(shù)據(jù)流分析，靜態(tài)代碼分析。
4.確認
所謂“確認”，就是通過提供客觀證據(jù)對特定的預期用途或應用要求已得到滿足的認定。通過試驗來確認是否產(chǎn)生了滿足要求的成果物。
對于ASIL D等級要求，無論是軟件單元測試還是軟件集成測試，都必須進行基于需求的測試、接口測試、故障注入測試、資源測試和背靠背測試。
在測試用例的導出方法中，需求分析，等價類的創(chuàng)建和分析以及邊界值分析是對于符合ASIL D等級的基本要求。
對于軟件單元測試的覆蓋率，ASIL A可以執(zhí)行100％的C0覆蓋（指令覆蓋率），而ASIL D則要求100%實施C1覆蓋(分支網(wǎng)羅率)及MC/DC(Modified Condition/Decision Coverrage) 。
對于軟件集成測試，ASIL D要求100%實施功能覆蓋和調(diào)用覆蓋。
5.軟件工具的認證
為了軟件開發(fā)而使用導入的各種軟件工具（以下簡稱為工具），ISO 26262為它們設定了可靠性評估指標，只有被認定為符合指標的工具才能夠用于開發(fā)。
所以，首先第一步，我們需要看看工具是否符合ISO 26262的認證標準。
為此，我們需要驗證軟件工具對于安全功能的影響（TI），也要同時考評軟件工具，針對自身可能出現(xiàn)的內(nèi)部錯誤的診斷能力（TD），并最終生成該軟件工具的置信等級（TCL）。
TI是對軟件工具是否對正在開發(fā)的設計產(chǎn)生直接的安全相關影響的評估。TI分為兩個級別，TI1和TI2。TI1意味著對設計沒有直接影響，而TI2則表示對設計有直接影響。當軟件工具故障對項目或者組件完全沒有影響時，可選擇TI1。其他情況則選擇TI2。
TD指對工具由于誤操作而引起錯誤輸出防護手段，以及工具發(fā)生錯誤時候檢測能力的信賴性，,用TD1，TD2，TD3三個等級來評價。當對于誤動作以及對應的誤輸出的防護和檢測手段信賴性要求比較高時候，選擇TD1；信賴度要求處于中等程度的時候選擇TD2，其他情況選擇TD3。
例如，假設某工具用于檢測設計模型的錯誤。該工具對模型執(zhí)行靜態(tài)分析。當靜態(tài)分析良好時，該工具不能檢測模型中的所有可能違規(guī)行為。還有一點值得注意的是，這并不一定意味著該模型是錯誤的，而僅僅表明需要額外的測試。該例是一種中等程度的置信水平，即TD2。
根據(jù)TI和TD，我們可以通過以下矩形表格來確定TCL
判定為TCL1的工具無需認證即可使用，而判定為TCL2和TCL3的工具則需要附加鑒定方法，以下為適用的四種認證方法：
1a 信賴度通過使用而增強
只有提供了標準規(guī)定的工具實際應用的有關證據(jù)，才能基于使用歷史，提升工具的信賴度。
1b 評估工具開發(fā)過程
該工具開發(fā)的開發(fā)過程是否開發(fā)流程，開發(fā)標準。
1c 軟件工具確認確認
確認滿足標準所判定的指標的方法。
1d 按照安全標準進行開發(fā)
工具開發(fā)是否符合ISO26262，IEC61508和RTCA DO-178（航空系統(tǒng)和設備的安全標準）等標準。
事實上，只要執(zhí)行了附加認證，就可以使用TCL2或TCL3中評估的軟件工具。ISO 26262也列出了關于TCL2和TCL3級工具可接受的認證方法。
ISO 26262-8:2011表4列出了對TCL3級工具可接受的認證方法，表5列出了對TCL2級工具可接受的認證方法。（如圖）
根據(jù)工具中開發(fā)的項目或ASIL類別的不同，優(yōu)先選擇應用不同的認證方法。下圖為合并的表格，其中突出顯示了優(yōu)選方法并且進行了說明。
++表示該方法被強烈建議用于所對應的ASIL
+表示該方法被建議用于所對應的ASIL
注：*沒有如何安全標準完全適用于軟件工具的開發(fā)。但可以選擇安全標準的相關子集要求。
在TCL2的情況下，ASIL A/B/C需要附加驗證方法1a和1b，ASIL D需要附加驗證方法1c和1d。
在TCL3的情況下，ASIL A/B 需要附加驗證方法1a和1b，ASIL C/D需要附加驗證方法1c和1d。
實際上，從供應商處購買工具時，用戶很難執(zhí)行認證。因此，引入符合ISO 26262的第三方認證工具是非常符合現(xiàn)實需求的。
6.通過保護功能防止故障的傳播
在特定軟件組件發(fā)生故障時，為了防止對另一軟件組件造成不良影響，ISO 26262一個名為“軟件隔離”的結構技術。當多個不同ASIL等級的軟件組件在同一個MPU上共存時，該技術非常適用。
舉個例子：在沒有分區(qū)的情況下，假設有ASIL A，ASIL B和ASIL C三個不同等級的軟件，使用一個MPU和一個資源（共享內(nèi)存）進行操作，則三個軟件必須符合最高的ASIL等級要求（即ASIL C），導致必須承擔高于必要的開發(fā)成本。同時，低等級的任務修改高等級的數(shù)據(jù)，會造成高等級使用了不可信的數(shù)據(jù)，影響安全功能。
如果有分區(qū)，即使三個不同ASIL等級的軟件在一個MPU上，也可以將最佳的ASIL等級應用于各個軟件組件，可以避免浪費的開發(fā)成本。
軟件分區(qū)技術有很多，將軟件分區(qū)應用于汽車MPU時，從成本方面考慮，一般認為，利用MPU的存儲器保護單元的OS方法是最有希望的。
7.流程改進
在嵌入式軟件領域，要求不斷改進過程標準，如CMMI和Automotive SPICE。
ISO 26262也需要流程改進，但基本上是對現(xiàn)有流程改進的延伸。建議至少通過CMMI Level 2和Automotive SPICE Level 3認證。
在ISO26262中，Part2功能安全的管理規(guī)定了確認審查（從技術的觀點驗證成果）和功能安全審核（從過程的角度確認功能安全活動的實施狀態(tài)）。通過結合三點功能安全評估的驗證策略（S/E/C）實現(xiàn)獨立評估ASIL等級，該評估項目可評估功能安全的合規(guī)性。
ASIL的獨立性被定義為4個級別，最輕的級別是“認證方案應由不同的人實施”，最重的級別是“來自不同部門或組織的人員實施認證”（即并且必須由第三方實施）。根據(jù)認證的內(nèi)容，較高的ASIL級別需要更高的獨立性。
第三方組織可以是公司內(nèi)的獨立部門，例如質(zhì)量保證部門，或是外部第三方認證機構。為應對功能安全認證的市場需求，有許多供應商和工具供應商要求知名第三方認證機構進行審核，
結論
2011年11月15日，ISO 26262 標準正式頒布。2018年，ISO 26262正式上路。
在這一領域，歐洲、日本應用ISO 26262要早于國內(nèi)，美國則推出SAE J2980標準。技術咨詢公司在和國內(nèi)OEM合作時會要求引入功能安全。國際汽車廠商（寶馬、通用、福特等）、汽車零部件供應商（博世、德爾福等）早已采用該標準開發(fā)安全相關的電子電器產(chǎn)品，應用在汽車的開發(fā)。
ISO 26262涉及汽車電子電氣系統(tǒng)的整個安全生命周期及其管理過程，滿足該標準對汽車企業(yè)及供應商來說必將是巨大的挑戰(zhàn)。為滿足ISO 26262，必須在公司安全文化、工作流程制定、產(chǎn)品設計與開發(fā)等方面進行持續(xù)的改進。
ISO26262標準暫時沒有出現(xiàn)官方層面的強制執(zhí)行要求，但該標準的執(zhí)行，將減少因為電子器件失效造成的交通事故和降低潛在召回風險，所以目前國際大型車企非常重視ISO26262標準的應用和推廣。
遺憾的是，目前國內(nèi)汽車電子領域的專用功能安全標準尚屬空白，雖然部分意識比較超前的民族品牌企業(yè)也關注ISO26262標準的制定和發(fā)展，然而，有些企業(yè)在接觸功能安全之后，遇到重重困難后選擇了放棄。
功能安全工程師的人才缺口也不斷擴大，相應的薪資水平也在隨之增長，一名資深的功能安全專家，年薪可達百萬。
中企檢測認證網(wǎng)提供iso體系認證機構查詢，檢驗檢測、認證認可、資質(zhì)資格、計量校準、知識產(chǎn)權貫標一站式行業(yè)企業(yè)服務平臺。中企檢測認證網(wǎng)為檢測行業(yè)相關檢驗、檢測、認證、計量、校準機構，儀器設備、耗材、配件、試劑、標準品供應商，法規(guī)咨詢、標準服務、實驗室軟件提供商提供包括品牌宣傳、產(chǎn)品展示、技術交流、新品推薦等全方位推廣服務。這個問題就給大家解答到這里了，如還需要了解更多專業(yè)性問題可以撥打中企檢測認證網(wǎng)在線客服13550333441。為您提供全面檢測、認證、商標、專利、知識產(chǎn)權、版權法律法規(guī)知識資訊，包括商標注冊、食品檢測、第三方檢測機構、網(wǎng)絡信息技術檢測、環(huán)境檢測、管理體系認證、服務體系認證、產(chǎn)品認證、版權登記、專利申請、知識產(chǎn)權、檢測法、認證標準等信息，中企檢測認證網(wǎng)為檢測認證商標專利從業(yè)者提供多種檢測、認證、知識產(chǎn)權、版權、商標、專利的轉(zhuǎn)讓代理查詢法律法規(guī)，咨詢輔導等知識。
本文內(nèi)容整合網(wǎng)站：百度百科、搜狗百科、360百科、知乎、市場監(jiān)督總局 、國家認證認可監(jiān)督管理委員會、質(zhì)量認證中心
免責聲明：本文部分內(nèi)容根據(jù)網(wǎng)絡信息整理，文章版權歸原作者所有。向原作者致敬！發(fā)布旨在積善利他，如涉及作品內(nèi)容、版權和其它問題，請跟我們聯(lián)系刪除并致歉！
打賞
更多>同類ISO26262認證知識
0 條相關評論
