久久精品国产精品亚洲人人_欧美日韩另类女同_成人亚洲欧美丝袜在线观看_午夜黄色视频毛片_国产福利精品自拍视频_欧美三级电影在线观看_国产精品第15页_亚洲国产精品丝袜在线观着_激情五月婷婷五月丁香五月_久久奇米99视频777

汽車功能安全標準于2011年作為ISO標準正式頒布，此后，汽車業(yè)界開始采納應(yīng)用該標準。

雖然標準的采納是自愿的，但在這樣的背景和趨勢之下，無論是汽車廠商還是零部件供應(yīng)商，為了滿足ISO 26262的要求，要盡快調(diào)整體制，完善規(guī)章制度，構(gòu)筑基于規(guī)格的生產(chǎn)流程，并由負責(zé)ISO 26262認證的第三方機構(gòu)進行認證。

一、功能安全

什么是功能安全？所謂的“功能安全”，就是通過安全功能和安全措施來避免不可容許的功能風(fēng)險的技術(shù)總稱。功能安全（Function Safety）的“功能”指的是監(jiān)控受控對象和控制器的安全裝置起的作用。通常我們將計算機作為安全裝置，如果控制器發(fā)生故障，則該計算機將會關(guān)閉受控對象，并向用戶發(fā)出危險警告。安全裝置所實現(xiàn)的這種安全性作用，被稱為“功能安全”。功能安全可以說是通過使用計算機等的安全裝置所設(shè)計出的安全措施。

但是，在這里不得不提醒大家，安全本身并不是通過增加某種電子安全設(shè)備來保證的，而是通過“去除”導(dǎo)致危險發(fā)生的設(shè)計或機械故障的安全機制來保證。這種安全機制被稱為“本質(zhì)安全”。

舉個栗子，這是一個非常經(jīng)典的例子：

比如在鐵路道口，我們常常有這樣的危險顧慮，就是有人或者車輛進入到了鐵道入口，和火車相撞，導(dǎo)致死亡。“本質(zhì)安全”就是從根本上避免危險的措施，把危險源直接“除掉”，方法是可以把這個鐵道道口改為立交橋。但是在某些情況或某些制約下，不能把鐵道道口“除掉”，自然就會想到附加一個安全設(shè)施，這就是功能安全。因為某些制約，不得不設(shè)置鐵路道口，但大家還要想避免這樣的交通事故，那怎么辦呢？這是功能安全。

歐美已經(jīng)頒布了成套的功能安全相關(guān)產(chǎn)品指令和設(shè)計標準，并深入到各個領(lǐng)域，在核電行業(yè)、石油、化工、電廠等過程工業(yè)，工業(yè)機器、電梯扶梯、智能電網(wǎng)、家電軟件評估、汽車行業(yè)、醫(yī)療軟件評估領(lǐng)域廣泛應(yīng)用。

這里，我們只談汽車功能安全。

二、功能安全制定的歷程

功能安全標準化的運動起源于20世紀90年代。

上世紀70年代開始，隨著各種現(xiàn)代化及其的使用，以及工業(yè)生產(chǎn)過程的自動化程度越來越高，以電氣、電子、可編程電子產(chǎn)品的大量應(yīng)用為標志的現(xiàn)代化控制系統(tǒng)越來越多的滲透到各個領(lǐng)域，參與著各種控制過程。

但是，工業(yè)文明在給人類帶來利益的同時，也帶來了災(zāi)難。由于系統(tǒng)設(shè)計不合理、設(shè)備元器件故障或失效、軟件系統(tǒng)的故障導(dǎo)致的事故、人身傷害、環(huán)境污染，越來越頻繁的危及著我們的生命安全和賴以生存的環(huán)境。

人們開始認識到，必須采取措施，用標準和法規(guī)來規(guī)范領(lǐng)域內(nèi)安全相關(guān)系統(tǒng)的使用，使技術(shù)在安全的框架內(nèi)發(fā)展，使人類既能盡可能享受新技術(shù)帶來的安全和舒適，同時又能掌控危險。功能安全標準研究從此展開。

然而，安全控制系統(tǒng)或設(shè)備執(zhí)行安全功能時的可靠性問題，限制了用戶使用新技術(shù)的積極性。由于沒有公認的評價體系，制造商很難說服用戶使用新技術(shù)，尤其在關(guān)系人身財產(chǎn)安全的重要領(lǐng)域使用新技術(shù)。另外，不同行業(yè)對安全要求的不同，也限制了安全設(shè)備的產(chǎn)業(yè)化生產(chǎn)規(guī)模。制造商迫切需要一個公認的標準來建立一個與用戶對接的公共平臺。

于是，2000年5月，國際電工委員會正式發(fā)布了IEC61508標準，名為《電氣/電子/可編程電子安全相關(guān)系統(tǒng)的功能安全》。

IEC61508中，系統(tǒng)中的安全設(shè)備（減少風(fēng)險的手段）由中繼控制器或PLC（Programmable logic控制器）等設(shè)備構(gòu)成，我們把安全設(shè)備將實現(xiàn)其安全功能的可靠性的概率稱為安全完整性水平，即SIL（Safety Integrity Level）。換句話說，基于這個等級標準，即，如果與構(gòu)成安全系統(tǒng)的部件的故障率低，則由此構(gòu)成的整個安全系統(tǒng)的故障率也是低的。

但是，有一種觀點認為，在SIL定義中加入概率因素并不合適的。為什么不合適呢？那是因為功能安全標準不僅涉及了硬件部分，還涉及了軟件部分。僅論硬件故障發(fā)生的概率，除了初始故障和損耗故障以外，偶發(fā)故障基本是隨機發(fā)生的，如果把設(shè)計錯誤分開，那么加入概率因素是非常合適的。與此相對的軟件故障可不是隨機的了，所以軟件故障(bug)是很難去計算其發(fā)生的概率的。例如，如果軟件的設(shè)計中混入了bug，只要其發(fā)生路徑和條件具備，那么故障的發(fā)生概率就是百分百！

針對這個問題，對IEC 61508重新修訂制定了ISO 26262標準。2011年11月，ISO 26262正式頒布。

ISO 26262 不同于 IEC 61508，它“不是一個可靠性標準”，它并沒有為可接受失效概率設(shè)定準確的數(shù)字。ISO 26262基于概率論的定量危害分析僅限適用于硬件，其次，基于目標產(chǎn)品的使用條件和使用方法，針對整個系統(tǒng)進行危害分析和風(fēng)險評估，識別出系統(tǒng)危害并對危害的風(fēng)險等級——ASIL等級（Automotive Safety Integration Level，汽車安全完整性等級）進行評估。IEC 61508定義了安全完整性等級 (SIL)，而 ISO 26262 則定義了汽車安全完整性等級 (ASIL)。

ASIL有四個等級，分別為A，B，C，D，其中A是最低的等級，D是最高的等級。然后，針對每種危害確定至少一個安全目標，安全目標是系統(tǒng)的最高級別的安全需求，由安全目標導(dǎo)出系統(tǒng)級別的安全需求，再將安全需求分配到硬件和軟件。ASIL等級決定了對系統(tǒng)安全性的要求，ASIL等級越高，對系統(tǒng)的安全性要求越高，為實現(xiàn)安全付出的代價越高，意味著硬件的診斷覆蓋率越高，開發(fā)流程越嚴格，相應(yīng)的開發(fā)成本增加、開發(fā)周期延長，技術(shù)要求嚴格。

三、ISO 26262是什么

ISO 26262是針對汽車電子的功能安全標準。

車載電子系統(tǒng)，即車輛所搭載的電子設(shè)備和計算機(包括軟件)，是ISO 26262的直接認證目標對象。在今年頒布的第二版ISO 26262中，車輛對象范圍還擴大到了到巴士、卡車、兩輪車輛。

ISO 26262的目的是確?！鞍踩保瑸榱藢崿F(xiàn)這個目的，不僅要考慮ISO26262直接針對的電子系統(tǒng)，還要考慮構(gòu)成電子系統(tǒng)的其他元件是否安全。此外，還必須明確ISO 26262的應(yīng)用場景，從整體上確保車載電子系統(tǒng)的安全性。

圖1為ISO 26262的體系結(jié)構(gòu)

ISO 26262的內(nèi)容包括：

Part 1：定義術(shù)語

Part 2：功能安全管理

Part 3：概念階段

Part 4：產(chǎn)品開發(fā)：系統(tǒng)層面

Part 5：產(chǎn)品開發(fā)：硬件層面

Part 6：產(chǎn)品開發(fā)：軟件層面

Part 7：生產(chǎn)、運行、服務(wù)和報廢

Part 8：支持過程

Part 9：基于ASIL和安全的分析

Part 10：ISO 26262導(dǎo)則

Part 11：半導(dǎo)體應(yīng)用指南

Part 1是定義標準中使用的術(shù)語的詞匯表。

Part 2中的功能安全管理定義了涉及安全相關(guān)系統(tǒng)開發(fā)的組織和人員應(yīng)滿足的要求。

在Part 3概念階段，ISO 26262給出去了災(zāi)害分析和風(fēng)險評估的要求。主要做三件事：項目定義、安全生命周期初始化、災(zāi)害分析和風(fēng)險評估。

在Part 3中獲得的安全需求，將在技術(shù)安全中詳細說明，并分解在Part 4系統(tǒng)層面的安全設(shè)計中。然后，根據(jù)硬件和軟件層面的開發(fā)安全要求（Part 5和6）進行系統(tǒng)集成，最后對系統(tǒng)級功能安全進行測試驗證。

在開發(fā)階段，完成系統(tǒng)級產(chǎn)品設(shè)計后，將技術(shù)安全需求規(guī)范分解到相應(yīng)的軟硬件技術(shù)安全需求規(guī)范里，進而開展軟硬件級產(chǎn)品設(shè)計，而在硬件層面（Part 5），必要的活動和產(chǎn)品開發(fā)過程包括技術(shù)安全概念的硬件實現(xiàn)、潛在的硬件故障及影響分析、與軟件開發(fā)的協(xié)調(diào)。

在Part6的軟件層面開發(fā)中，通過V字模型流程，遵循技術(shù)安全概念，實施軟件安全要求的導(dǎo)出、軟件架構(gòu)設(shè)計、軟件單體設(shè)計和細化。并在此基礎(chǔ)上實施編碼，完成編碼后，進行軟件單元測試，軟件集成（模塊組合）和集成測試，以及軟件安全要求的驗證。

Part 7規(guī)定了直到廢棄前的批量生產(chǎn)、服務(wù)、市場監(jiān)管的安全要求。

Part 8規(guī)定了對供應(yīng)商的開發(fā)委托要求，所要支持的系統(tǒng)過程（安全要求的管理、配置管理、變更管理、驗證、書面化），以及軟件工具認證、軟件組件認證、硬件組件規(guī)定與認證有關(guān)的要求，對多個過程進行橫向參與。

Part 9提供了關(guān)于ASIL認定和技術(shù)分析方法的指導(dǎo)，并且與第8部分一樣，涉及多個流程。

Part 10是作為Part1～9的補充，對特定項目的解說及事例的指南。

盡管對于 Part 5對于硬件層面已經(jīng)有相關(guān)說明，但是關(guān)于半導(dǎo)體層面的要求還是有限的。

四、ASIL

在ISO 26262中，ASIL是危害的風(fēng)險等級的指標。

依據(jù)ISO 26262標準進行功能安全設(shè)計時，首先對系統(tǒng)的功能進行逐個分析，識別系統(tǒng)所有的危害，然后依據(jù)三個因子（S\E\C）來評估危害的風(fēng)險級別。

嚴重度（Severity）

嚴重度是指一旦風(fēng)險成為現(xiàn)實，對駕駛員、乘員、或者行人等涉險人員的傷害程度。比如電子鎖故障就比剎車故障的嚴重程度低。

嚴重性用SX表示，X取值可以是0/1/2/3，級別從低到高，級別越高，傷害越嚴重。S0無傷害；S1輕微或有限傷害；S2嚴重或危及生命的傷害（可生還）；S3危及生命的傷害（有死亡可能）或致命傷害；

風(fēng)險S0S1S2S3內(nèi)容沒有傷害輕度或中度傷害重度或危及生命（還有生存的可能性）威脅生命安全（幾乎沒有生還的可能）

暴露率（Exposure）

暴露率，描述風(fēng)險出現(xiàn)時，人員暴露在系統(tǒng)的失效能夠造成危害的場景中的概率?；谀繕宋ｋU事件的情景，根據(jù)道路環(huán)境、天氣、車輛周六的情況、失去等等來判斷該指標。比如底盤出現(xiàn)異響比乘員座椅故障暴露率低。

暴露率，用EX表示， X取值從0至4，共5個等級。E0是幾乎不肯能暴露于危險中，E4是可能性極高。

風(fēng)險E0E1E2E3E4內(nèi)容沒有可能可能性非常低可能性低有一半的可能可能性高

可控性（Controllability）

可控性，描述風(fēng)險出現(xiàn)時，駕駛員或其他涉險人員能夠避免事故或傷害的可能性。比如，輪胎緩慢漏氣比剎車失靈可控性高。

可控性，用CX表示，最低C0可控，最高C3幾乎不可控，共4個級別。

風(fēng)險C0C1C2C3內(nèi)容可控簡單可控、一般可控、幾乎不可控

ASIL等級的確定基于S、E、C這三個影響因子，下表中給出了ASIL的確定方法，其中D代表最高等級，A代表最低等級，QM表示質(zhì)量管理（Quality Management），表示按照質(zhì)量管理體系開發(fā)系統(tǒng)或功能就足夠了，不用考慮任何安全相關(guān)的設(shè)計。確定了危害的ASIL等級后，為每個危害確定至少一個安全目標，作為功能和技術(shù)安全需求的基礎(chǔ)。

通過危害分析和風(fēng)險評估，我們得出系統(tǒng)或功能的安全目標和相應(yīng)的ASIL等級。當ASIL等級確定之后，就需要對每個評定的風(fēng)險確定安全目標，安全目標是最高級別的安全需求。安全目標確定之后，就需要在系統(tǒng)設(shè)計、硬件、軟件等方面進行設(shè)計、實施和驗證。

從安全目標可以推導(dǎo)出開發(fā)階段的安全需求，安全需求繼承安全目標的ASIL等級。那么，要如何繼承項目的安全需求呢？

接下來我們將先為大家說明如何繼承安全需求。

五、產(chǎn)品開發(fā)階段中功能安全需求的繼承

下圖為功能安全需求繼承的流程圖：

1.安全目標設(shè)定

如何提出系統(tǒng)安全需求是系統(tǒng)安全設(shè)計的第一步，系統(tǒng)安全需求的指導(dǎo)方針在現(xiàn)代安全法規(guī)中通常被表述為“安全目標設(shè)定”，它描述了所需實現(xiàn)的系統(tǒng)安全目標，并根據(jù)系統(tǒng)安全目標選擇相應(yīng)的實現(xiàn)方法和途徑。

對所實施ISO 26262的項目，應(yīng)用危險分析和風(fēng)險評定以及評估ASIL等級，來避免不可接受的風(fēng)險，并確定項目的安全目標。所謂的安全目標，就是為了防止在特定駕駛狀態(tài)下發(fā)生危險事件而采取的功能需求。通過危害分析和風(fēng)險評估，為每一個風(fēng)險確定一個ASIL等級，而安全目標就是為了每一個風(fēng)險而設(shè)定的。

2.功能安全需求的設(shè)定（功能安全概念）

為了符合功能安全目標，在功能安全概念中規(guī)定了項目的功能安全需求。

所謂的功能安全概念，是指得出實現(xiàn)安全目標所需的功能安全要求，并將他們分配到初步的設(shè)計架構(gòu)，或者外部減少危險的措施當中去，以確保滿足相關(guān)的功能安全。

所謂的功能安全需求，是一種安全措施（減少有害影響的活動或解決方案），且該安全措施不依賴于以安全目標為基礎(chǔ)的項目安全行為規(guī)范和實施。

安全目標和功能安全需求之間的關(guān)系是分層的，如下圖所示。

3.技術(shù)安全需求的設(shè)定（技術(shù)安全概念）

為了在項目中實現(xiàn)功能安全需求，必須根據(jù)技術(shù)安全概念，將項目級別的功能安全需求細化為系統(tǒng)級別所需要的技術(shù)安全需求。

所謂的技術(shù)安全需求，是為了實現(xiàn)功能安全需求，系統(tǒng)應(yīng)具備的技術(shù)性安全措施。

所謂的技術(shù)安全概念，是說明如何實現(xiàn)技術(shù)安全需求規(guī)范。

在整個開發(fā)生命周期，技術(shù)安全需求是要落實功能安全概念的技術(shù)需求，其用意是從細節(jié)的單級功能安全需求到系統(tǒng)級安全技術(shù)需求。

4.系統(tǒng)設(shè)計

在系統(tǒng)設(shè)計階段，系統(tǒng)及子系統(tǒng)需要按上面所定義的貫徹技術(shù)安全要求，設(shè)計出符合系統(tǒng)規(guī)范的開發(fā)方法。這里，不僅考慮安全需求，還考慮非安全需求(ASIL等級表中被判定為“QM”的要求)。為了實現(xiàn)技術(shù)安全要求，必須考慮到系統(tǒng)設(shè)計的可驗證性，實現(xiàn)功能安全的技術(shù)能力以及系統(tǒng)集成期間的測試可行性。

將實施所需規(guī)范中的技術(shù)安全要求集合，即為系統(tǒng)規(guī)范樣式。

系統(tǒng)規(guī)范應(yīng)直接或通過進一步細化到硬件，軟件或兩者兼有。此外，設(shè)計硬件 - 軟件接口（HSI），規(guī)定硬件和軟件的交互，并應(yīng)與技術(shù)安全的概念一致。

另外，系統(tǒng)規(guī)范必須驗證對技術(shù)安全概念的符合性和完整性。

5.硬件安全需求和功能安全的硬件開發(fā)

根據(jù)分配給硬件的技術(shù)安全要求，可以獲得硬件安全需求。硬件安全需求主要用于保證控制器內(nèi)部硬件故障的安全機制的安全要求。

ISO 26262所要求的硬件設(shè)計的要點，一是定量地實施對硬件架構(gòu)指標的評估，二是由于偶發(fā)硬件故障而導(dǎo)致的隨機失效率的評估。

硬件架構(gòu)指標，是用于評估硬件架構(gòu)對硬件的偶然故障的影響（魯棒性）的指標，且為定量數(shù)值，由標準定義的公式來確定。

隨即失效率，是基于概率論，用來評價安全機制在安全性的邏輯支持之下的有效性。

6.軟件安全需求的規(guī)范

軟件安全要求以因故障引起技術(shù)安全要求偏離的功能為對象，并將其細化定義至可實施/驗證軟件的等級。

在軟件安全要求的設(shè)計方面，需要考慮指定的系統(tǒng)和硬件配置，硬件/軟件接口，硬件安全要求，時間限制，與項目外部視圖的接口，受軟件影響的車輛，系統(tǒng)以及硬件涉及的各個動作模式。

軟件安全要求規(guī)范還必須驗證與技術(shù)安全概念、系統(tǒng)規(guī)范、硬/軟件接口規(guī)范的兼容性和一貫性。

六、功能安全的軟件級開發(fā)

符合功能安全的軟件開發(fā)有什么不一樣的嗎？

1.軟件安全要求的可追溯性

ISO 26262要求將各危險風(fēng)險降低設(shè)定為安全目標，并且在整個開發(fā)過程中，保證測試結(jié)果都可以通過其驗證測試、實施、規(guī)范和要求來追溯。這就是功能安全的可追溯性?？勺匪菪钥赏ㄟ^給需求添加ID號碼來識別。

在軟件開發(fā)中，ID號碼用于關(guān)聯(lián)軟件安全需求標準的軟件安全需求（相當于軟件功能設(shè)計）、軟件架構(gòu)設(shè)計標準的軟件組件以及軟件單元設(shè)計標準的函數(shù)（如下圖）。 這使得安全需求的關(guān)系明確，并且通過驗證和試驗，可以有效地發(fā)現(xiàn)對于上級要求來說的下級要求存在的遺漏，以及對函數(shù)不良影響的條件的影響等。

關(guān)于需求的可追溯性管理，可使用軟件開發(fā)中的需求管理工具來實現(xiàn)。

2.設(shè)計方法

在ISO 26262中，軟件想要達到系統(tǒng)所分配的更高安全目標的ASIL D等級，就需要更加嚴謹?shù)能浖軜?gòu)。

在軟件架構(gòu)設(shè)計中，如果想要達到符合ASIL D等級，就必須滿足軟件組件的分層化、軟件組件大小的限制、適當?shù)恼{(diào)度、軟件組件的內(nèi)聚、耦合限制和中斷限制。

在各種軟件設(shè)計的方法中，結(jié)構(gòu)化設(shè)計方法已經(jīng)不是什么新鮮的方法了。但在ISO 26262中，顯然，該方法是處理應(yīng)對ASIL相應(yīng)等級的必須手段。

在軟件架構(gòu)級別的錯誤檢測階段中，對于ASIL D的要求，必須進行輸入輸出數(shù)據(jù)的范圍檢查、數(shù)據(jù)有效性檢查、外部監(jiān)控、控制流監(jiān)視和軟件冗余設(shè)計。

在軟件架構(gòu)級別的錯誤處理階段中，對于ASIL D的要求，必須具有發(fā)生錯誤時的縮退功能以及并行的冗余。

在單體軟件設(shè)計階段中，對于ASIL D的要求，相關(guān)函數(shù)只能有1個出入口，限制動態(tài)安全對象（例如堆棧區(qū)域），執(zhí)行變量初始化，禁止相同變量名稱，限制使用全局變量，限制指針使用，禁止隱式類型轉(zhuǎn)換，禁止隱藏數(shù)據(jù)流/控制流，禁止無條件跳轉(zhuǎn)，禁止遞歸調(diào)，ISO 26262沒有深入涉及建模設(shè)計。關(guān)于汽車建模設(shè)計（基于模型的開發(fā)），MATLAB / Simlink被認為是典型方法，盡管如此，執(zhí)行建模設(shè)計并不一定有助于導(dǎo)入功能安全。

不基于模型設(shè)計的軟件開發(fā)代碼質(zhì)量，與基于模型設(shè)計的軟件開發(fā)代碼質(zhì)量是相同的。在建模設(shè)計中提高模型的質(zhì)量，也有助于由此產(chǎn)生的產(chǎn)品（項目）的安全性。關(guān)于設(shè)計模型時的指南，ISO 26262結(jié)合編碼指南定義了設(shè)計指南的要求。

3.驗證

所謂“驗證”，就是確認已“正確”完成產(chǎn)品開發(fā)。

在ISO26262中，關(guān)于軟件架構(gòu)設(shè)計、軟件單體設(shè)計和實現(xiàn)(編碼)，規(guī)定需要完成與ASIL等級相對應(yīng)的驗證。

對于軟件架構(gòu)設(shè)計驗證，如果是ASIL A級別，只要排查就足夠了。但如果是達到符合ASIL D級別，則必須進行檢查，動態(tài)（可執(zhí)行模型）仿真，原型設(shè)計，控制流/數(shù)據(jù)流分析。

對于軟件單一設(shè)計和實現(xiàn)（編碼）驗證，如果是ASIL A級別，只要排查就足夠了。但如果是達到符合ASIL D級別，就必須進行檢查，半正式驗證（使用基于模型的仿真驗證等），控制流/數(shù)據(jù)流分析，靜態(tài)代碼分析。

4.確認

所謂“確認”，就是通過提供客觀證據(jù)對特定的預(yù)期用途或應(yīng)用要求已得到滿足的認定。通過試驗來確認是否產(chǎn)生了滿足要求的成果物。

對于ASIL D等級要求，無論是軟件單元測試還是軟件集成測試，都必須進行基于需求的測試、接口測試、故障注入測試、資源測試和背靠背測試。

在測試用例的導(dǎo)出方法中，需求分析，等價類的創(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ā)而使用導(dǎo)入的各種軟件工具（以下簡稱為工具），ISO 26262為它們設(shè)定了可靠性評估指標，只有被認定為符合指標的工具才能夠用于開發(fā)。

所以，首先第一步，我們需要看看工具是否符合ISO 26262的認證標準。

為此，我們需要驗證軟件工具對于安全功能的影響（TI），也要同時考評軟件工具，針對自身可能出現(xiàn)的內(nèi)部錯誤的診斷能力（TD），并最終生成該軟件工具的置信等級（TCL）。

TI是對軟件工具是否對正在開發(fā)的設(shè)計產(chǎn)生直接的安全相關(guān)影響的評估。TI分為兩個級別，TI1和TI2。TI1意味著對設(shè)計沒有直接影響，而TI2則表示對設(shè)計有直接影響。當軟件工具故障對項目或者組件完全沒有影響時，可選擇TI1。其他情況則選擇TI2。

TD指對工具由于誤操作而引起錯誤輸出防護手段，以及工具發(fā)生錯誤時候檢測能力的信賴性，,用TD1，TD2，TD3三個等級來評價。當對于誤動作以及對應(yīng)的誤輸出的防護和檢測手段信賴性要求比較高時候，選擇TD1；信賴度要求處于中等程度的時候選擇TD2，其他情況選擇TD3。

例如，假設(shè)某工具用于檢測設(shè)計模型的錯誤。該工具對模型執(zhí)行靜態(tài)分析。當靜態(tài)分析良好時，該工具不能檢測模型中的所有可能違規(guī)行為。還有一點值得注意的是，這并不一定意味著該模型是錯誤的，而僅僅表明需要額外的測試。該例是一種中等程度的置信水平，即TD2。

根據(jù)TI和TD，我們可以通過以下矩形表格來確定TCL

判定為TCL1的工具無需認證即可使用，而判定為TCL2和TCL3的工具則需要附加鑒定方法，以下為適用的四種認證方法：

1a 信賴度通過使用而增強

只有提供了標準規(guī)定的工具實際應(yīng)用的有關(guān)證據(jù)，才能基于使用歷史，提升工具的信賴度。

1b 評估工具開發(fā)過程

該工具開發(fā)的開發(fā)過程是否開發(fā)流程，開發(fā)標準。

1c 軟件工具確認確認

確認滿足標準所判定的指標的方法。

1d 按照安全標準進行開發(fā)

工具開發(fā)是否符合ISO26262，IEC61508和RTCA DO-178（航空系統(tǒng)和設(shè)備的安全標準）等標準。

事實上，只要執(zhí)行了附加認證，就可以使用TCL2或TCL3中評估的軟件工具。ISO 26262也列出了關(guān)于TCL2和TCL3級工具可接受的認證方法。

ISO 26262-8:2011表4列出了對TCL3級工具可接受的認證方法，表5列出了對TCL2級工具可接受的認證方法。（如圖）

根據(jù)工具中開發(fā)的項目或ASIL類別的不同，優(yōu)先選擇應(yīng)用不同的認證方法。下圖為合并的表格，其中突出顯示了優(yōu)選方法并且進行了說明。

++表示該方法被強烈建議用于所對應(yīng)的ASIL

+表示該方法被建議用于所對應(yīng)的ASIL

注：*沒有如何安全標準完全適用于軟件工具的開發(fā)。但可以選擇安全標準的相關(guān)子集要求。

在TCL2的情況下，ASIL A/B/C需要附加驗證方法1a和1b，ASIL D需要附加驗證方法1c和1d。

在TCL3的情況下，ASIL A/B 需要附加驗證方法1a和1b，ASIL C/D需要附加驗證方法1c和1d。

實際上，從供應(yīng)商處購買工具時，用戶很難執(zhí)行認證。因此，引入符合ISO 26262的第三方認證工具是非常符合現(xiàn)實需求的。

6.通過保護功能防止故障的傳播

在特定軟件組件發(fā)生故障時，為了防止對另一軟件組件造成不良影響，ISO 26262一個名為“軟件隔離”的結(jié)構(gòu)技術(shù)。當多個不同ASIL等級的軟件組件在同一個MPU上共存時，該技術(shù)非常適用。

舉個例子：在沒有分區(qū)的情況下，假設(shè)有ASIL A，ASIL B和ASIL C三個不同等級的軟件，使用一個MPU和一個資源（共享內(nèi)存）進行操作，則三個軟件必須符合最高的ASIL等級要求（即ASIL C），導(dǎo)致必須承擔高于必要的開發(fā)成本。同時，低等級的任務(wù)修改高等級的數(shù)據(jù)，會造成高等級使用了不可信的數(shù)據(jù)，影響安全功能。

如果有分區(qū)，即使三個不同ASIL等級的軟件在一個MPU上，也可以將最佳的ASIL等級應(yīng)用于各個軟件組件，可以避免浪費的開發(fā)成本。

軟件分區(qū)技術(shù)有很多，將軟件分區(qū)應(yīng)用于汽車MPU時，從成本方面考慮，一般認為，利用MPU的存儲器保護單元的OS方法是最有希望的。

7.流程改進

在嵌入式軟件領(lǐng)域，要求不斷改進過程標準，如CMMI和Automotive SPICE。

ISO 26262也需要流程改進，但基本上是對現(xiàn)有流程改進的延伸。建議至少通過CMMI Level 2和Automotive SPICE Level 3認證。

在ISO26262中，Part2功能安全的管理規(guī)定了確認審查（從技術(shù)的觀點驗證成果）和功能安全審核（從過程的角度確認功能安全活動的實施狀態(tài)）。通過結(jié)合三點功能安全評估的驗證策略（S/E/C）實現(xiàn)獨立評估ASIL等級，該評估項目可評估功能安全的合規(guī)性。

ASIL的獨立性被定義為4個級別，最輕的級別是“認證方案應(yīng)由不同的人實施”，最重的級別是“來自不同部門或組織的人員實施認證”（即并且必須由第三方實施）。根據(jù)認證的內(nèi)容，較高的ASIL級別需要更高的獨立性。

第三方組織可以是公司內(nèi)的獨立部門，例如質(zhì)量保證部門，或是外部第三方認證機構(gòu)。為應(yīng)對功能安全認證的市場需求，有許多供應(yīng)商和工具供應(yīng)商要求知名第三方認證機構(gòu)進行審核。

七、結(jié)論

2011年11月15日，ISO 26262 標準正式頒布。2018年，ISO 26262正式上路。

在這一領(lǐng)域，歐洲、日本應(yīng)用ISO 26262要早于國內(nèi)，美國則推出SAE J2980標準。技術(shù)咨詢公司在和國內(nèi)OEM合作時會要求引入功能安全。國際汽車廠商（寶馬、通用、福特等）、汽車零部件供應(yīng)商（博世、德爾福等）早已采用該標準開發(fā)安全相關(guān)的電子電器產(chǎn)品，應(yīng)用在汽車的開發(fā)。

ISO 26262涉及汽車電子電氣系統(tǒng)的整個安全生命周期及其管理過程，滿足該標準對汽車企業(yè)及供應(yīng)商來說必將是巨大的挑戰(zhàn)。為滿足ISO 26262，必須在公司安全文化、工作流程制定、產(chǎn)品設(shè)計與開發(fā)等方面進行持續(xù)的改進。

ISO26262標準暫時沒有出現(xiàn)官方層面的強制執(zhí)行要求，但該標準的執(zhí)行，將減少因為電子器件失效造成的交通事故和降低潛在召回風(fēng)險，所以目前國際大型車企非常重視ISO26262標準的應(yīng)用和推廣。

▲文章來源于：知乎   ?？W(xué)城

返回