汽車功能安全標准于2011年作爲ISO標准正式頒布，此後，汽車業界開始采納應用該標准。

虽然标准的采纳是自愿的，但在这样的背景和趋势之下，无论是汽车厂商还是零部件供应商，为了满足ISO 26262的要求，要尽快调整体制，完善规章制度，构筑基于规格的生产流程，并由负责ISO 26262认证的第三方机构进行认证。

一、功能安全

什么是功能安全？所谓的“功能安全”，就是通过安全功能和安全措施来避免不可容许的功能风险的技术总称。功能安全（Function Safety）的“功能”指的是监控受控对象和控制器的安全装置起的作用。通常我们将计算机作为安全装置，如果控制器发生故障，则该计算机将会关闭受控对象，并向用户发出危险警告。安全装置所实现的这种安全性作用，被称为“功能安全”。功能安全可以说是通过使用计算机等的安全装置所设计出的安全措施。

但是，在這裏不得不提醒大家，安全本身並不是通過增加某種電子安全設備來保證的，而是通過“去除”導致危險發生的設計或機械故障的安全機制來保證。這種安全機制被稱爲“本質安全”。

舉個栗子，這是一個非常經典的例子：

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

歐美已經頒布了成套的功能安全相關産品指令和設計標准，並深入到各個領域，在核電行業、石油、化工、電廠等過程工業，工業機器、電梯扶梯、智能電網、家電軟件評估、汽車行業、醫療軟件評估領域廣泛應用。

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

二、功能安全制定的曆程

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

上世紀70年代開始，隨著各種現代化及其的使用，以及工業生産過程的自動化程度越來越高，以電氣、電子、可編程電子産品的大量應用爲標志的現代化控制系統越來越多的滲透到各個領域，參與著各種控制過程。

但是，工業文明在給人類帶來利益的同時，也帶來了災難。由于系統設計不合理、設備元器件故障或失效、軟件系統的故障導致的事故、人身傷害、環境汙染，越來越頻繁的危及著我們的生命安全和賴以生存的環境。

人們開始認識到，必須采取措施，用標准和法規來規範領域內安全相關系統的使用，使技術在安全的框架內發展，使人類既能盡可能享受新技術帶來的安全和舒適，同時又能掌控危險。功能安全標准研究從此展開。

然而，安全控制系統或設備執行安全功能時的可靠性問題，限制了用戶使用新技術的積極性。由于沒有公認的評價體系，制造商很難說服用戶使用新技術，尤其在關系人身財産安全的重要領域使用新技術。另外，不同行業對安全要求的不同，也限制了安全設備的産業化生産規模。制造商迫切需要一個公認的標准來建立一個與用戶對接的公共平台。

于是，2000年5月，國際電工委員會正式發布了IEC61508標准，名爲《電氣/電子/可編程電子安全相關系統的功能安全》。

IEC61508中，系统中的安全设备（减少风险的手段）由中继控制器或PLC（Programmable logic控制器）等设备构成，我们把安全设备将实现其安全功能的可靠性的概率称为安全完整性水平，即SIL（Safety Integrity Level）。换句话说，基于这个等级标准，即，如果与构成安全系统的部件的故障率低，则由此构成的整个安全系统的故障率也是低的。

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

针对这个问题，对IEC 61508重新修订制定了ISO 26262标准。2011年11月，ISO 26262正式颁布。

ISO 26262 不同于 IEC 61508，它“不是一个可靠性标准”，它并没有为可接受失效概率设定准确的数字。ISO 26262基于概率论的定量危害分析仅限适用于硬件，其次，基于目标产品的使用条件和使用方法，针对整个系统进行危害分析和风险评估，识别出系统危害并对危害的风险等级——ASIL等级（Automotive Safety Integration Level，汽车安全完整性等级）进行评估。IEC 61508定义了安全完整性等级 (SIL)，而 ISO 26262 则定义了汽车安全完整性等级 (ASIL)。

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

三、ISO 26262是什么

ISO 26262是针对汽车电子的功能安全标准。

车载电子系统，即车辆所搭载的电子设备和计算机(包括软件)，是ISO 26262的直接认证目标对象。在今年颁布的第二版ISO 26262中，车辆对象范围还扩大到了到巴士、卡车、两轮车辆。

ISO 26262的目的是确保“安全”，为了实现这个目的，不仅要考虑ISO26262直接针对的电子系统，还要考虑构成电子系统的其他元件是否安全。此外，还必须明确ISO 26262的应用场景，从整体上确保车载电子系统的安全性。

图1为ISO 26262的体系结构

ISO 26262的内容包括：

Part 1：定义术语

Part 2：功能安全管理

Part 3：概念阶段

Part 4：产品开发：系统层面

Part 5：产品开发：硬件层面

Part 6：产品开发：软件层面

Part 7：生产、运行、服务和报废

Part 8：支持过程

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

Part 10：ISO 26262导则

Part 11：半导体应用指南

Part 1是定义标准中使用的术语的词汇表。

Part 2中的功能安全管理定义了涉及安全相关系统開發的組織和人員應滿足的要求。

在Part 3概念阶段，ISO 26262给出去了灾害分析和風險評估的要求。主要做三件事：項目定義、安全生命周期初始化、災害分析和風險評估。

在Part 3中获得的安全需求，将在技术安全中详细说明，并分解在Part 4系统层面的安全设计中。然后，根据硬件和软件层面的开发安全要求（Part 5和6）进行系统集成，最后对系统级功能安全进行测试验证。

在开发阶段，完成系统级产品设计后，将技术安全需求规范分解到相应的软硬件技术安全需求规范里，进而开展软硬件级产品设计，而在硬件层面（Part 5），必要的活动和产品开发过程包括技术安全概念的硬件实现、潜在的硬件故障及影响分析、与软件开发的协调。

在Part6的軟件層面開發中，通過V字模型流程，遵循技術安全概念，實施軟件安全要求的導出、軟件架構設計、軟件單體設計和細化。並在此基礎上實施編碼，完成編碼後，進行軟件單元測試，軟件集成（模塊組合）和集成測試，以及軟件安全要求的驗證。

Part 7规定了直到废弃前的批量生产、服务、市場监管的安全要求。

Part 8规定了对供应商的开发委托要求，所要支持的系统过程（安全要求的管理、配置管理、变更管理、验证、书面化），以及软件工具认证、軟件組件认证、硬件组件规定与认证有关的要求，对多个过程进行横向参与。

Part 9提供了关于ASIL认定和技术分析方法的指导，并且与第8部分一样，涉及多个流程。

Part 10是作为Part1～9的补充，对特定项目的解说及事例的指南。

尽管对于 Part 5对于硬件层面已经有相关说明，但是关于半导体层面的要求还是有限的。

四、ASIL

在ISO 26262中，ASIL是危害的风险等级的指标。

依据ISO 26262标准进行功能安全设计时，首先对系统的功能进行逐个分析，识别系统所有的危害，然后依据三个因子（S\E\C）来评估危害的风险级别。

嚴重度（Severity）

嚴重度是指一旦風險成爲現實，對駕駛員、乘員、或者行人等涉險人員的傷害程度。比如電子鎖故障就比刹車故障的嚴重程度低。

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

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

暴露率（Exposure）

暴露率，描述風險出現時，人員暴露在系統的失效能夠造成危害的場景中的概率。基于目標危險事件的情景，根據道路環境、天氣、車輛周六的情況、失去等等來判斷該指標。比如底盤出現異響比乘員座椅故障暴露率低。

暴露率，用EX表示， X取值从0至4，共5个等级。E0是几乎不肯能暴露于危险中，E4是可能性极高。

風險E0E1E2E3E4內容沒有可能可能性非常低可能性低有一半的可能可能性高

可控性（Controllability）

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

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

風險C0C1C2C3內容可控簡單可控、一般可控、幾乎不可控

ASIL等级的確定基于S、E、C这三个影响因子，下表中给出了ASIL的確定方法，其中D代表最高等级，A代表最低等级，QM表示质量管理（Quality Management），表示按照质量管理体系开发系统或功能就足够了，不用考虑任何安全相关的设计。確定了危害的ASIL等级后，为每个危害確定至少一个安全目标，作为功能和技术安全需求的基础。

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

從安全目標可以推導出開發階段的安全需求，安全需求繼承安全目標的ASIL等級。那麽，要如何繼承項目的安全需求呢？

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

五、産品開發階段中功能安全需求的繼承

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

1.安全目標設定

如何提出系統安全需求是系統安全設計的第一步，系統安全需求的指導方針在現代安全法規中通常被表述爲“安全目標設定”，它描述了所需實現的系統安全目標，並根據系統安全目標選擇相應的實現方法和途徑。

对所实施ISO 26262的项目，应用危险分析和风险评定以及评估ASIL等级，来避免不可接受的风险，并確定项目的安全目标。所谓的安全目标，就是为了防止在特定驾驶状态下发生危险事件而采取的功能需求。通过危害分析和风险评估，为每一个风险確定一个ASIL等级，而安全目标就是为了每一个风险而设定的。

2.功能安全需求的設定（功能安全概念）

爲了符合功能安全目標，在功能安全概念中規定了項目的功能安全需求。

所謂的功能安全概念，是指得出實現安全目標所需的功能安全要求，並將他們分配到初步的設計架構，或者外部減少危險的措施當中去，以確保滿足相關的功能安全。

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

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

3.技術安全需求的設定（技術安全概念）

爲了在項目中實現功能安全需求，必須根據技術安全概念，將項目級別的功能安全需求細化爲系統級別所需要的技術安全需求。

所謂的技術安全需求，是爲了實現功能安全需求，系統應具備的技術性安全措施。

所謂的技術安全概念，是說明如何實現技術安全需求規範。

在整個開發生命周期，技術安全需求是要落實功能安全概念的技術需求，其用意是從細節的單級功能安全需求到系統級安全技術需求。

4.系統設計

在系統設計階段，系統及子系統需要按上面所定義的貫徹技術安全要求，設計出符合系統規範的開發方法。這裏，不僅考慮安全需求，還考慮非安全需求(ASIL等級表中被判定爲“QM”的要求)。爲了實現技術安全要求，必須考慮到系統設計的可驗證性，實現功能安全的技術能力以及系統集成期間的測試可行性。

將實施所需規範中的技術安全要求集合，即爲系統規範樣式。

系统规范应直接或通过进一步细化到硬件，软件或两者兼有。此外，设计硬件 - 软件接口（HSI），规定硬件和软件的交互，并应与技术安全的概念一致。

另外，系統規範必須驗證對技術安全概念的符合性和完整性。

5.硬件安全需求和功能安全的硬件開發

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

ISO 26262所要求的硬件设计的要点，一是定量地实施对硬件架構指標的评估，二是由于偶发硬件故障而导致的随机失效率的评估。

硬件架構指標，是用于評估硬件架構對硬件的偶然故障的影響（魯棒性）的指標，且爲定量數值，由標准定義的公式來確定。

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

6.軟件安全需求的規範

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

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

軟件安全要求規範還必須驗證與技術安全概念、系統規範、硬/軟件接口規範的兼容性和一貫性。

六、功能安全的軟件級開發

符合功能安全的軟件開發有什麽不一樣的嗎？

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

ISO 26262要求将各危险风险降低设定为安全目标，并且在整个开发过程中，保证测试结果都可以通过其验证测试、实施、规范和要求来追溯。这就是功能安全的可追溯性。可追溯性可通过给需求添加ID号码来识别。

在軟件開發中，ID號碼用于關聯軟件安全需求標准的軟件安全需求（相當于軟件功能設計）、軟件架構設計標准的軟件組件以及軟件單元設計標准的函數（如下图）。 这使得安全需求的关系明确，并且通过验证和试验，可以有效地发现对于上级要求来说的下级要求存在的遗漏，以及对函數不良影响的条件的影响等。

關于需求的可追溯性管理，可使用軟件開發中的需求管理工具來實現。

2.設計方法

在ISO 26262中，软件想要达到系统所分配的更高安全目标的ASIL D等级，就需要更加严谨的软件架构。

在软件架构设计中，如果想要达到符合ASIL D等级，就必须满足軟件組件的分层化、軟件組件大小的限制、适当的调度、軟件組件的内聚、耦合限制和中断限制。

在各種軟件設計的方法中，結構化設計方法已经不是什么新鲜的方法了。但在ISO 26262中，显然，该方法是处理应对ASIL相应等级的必须手段。

在软件架构级别的错误检测阶段中，对于ASIL D的要求，必须进行输入输出数据的范围检查、数据有效性检查、外部监控、控制流监视和软件冗余设计。

在软件架构级别的错误处理阶段中，对于ASIL D的要求，必须具有发生错误时的缩退功能以及并行的冗余。

在单体软件设计阶段中，对于ASIL D的要求，相关函數只能有1个出入口，限制动态安全对象（例如堆栈区域），执行变量初始化，禁止相同变量名称，限制使用全局变量，限制指针使用，禁止隐式类型转换，禁止隐藏数据流/控制流，禁止无条件跳转，禁止递归调，ISO 26262没有深入涉及建模设计。关于汽车建模设计（基于模型的开发），MATLAB / Simlink被认为是典型方法，尽管如此，执行建模设计并不一定有助于导入功能安全。

不基于模型设计的软件开发代码质量，与基于模型设计的软件开发代码质量是相同的。在建模设计中提高模型的质量，也有助于由此产生的产品（项目）的安全性。关于设计模型时的指南，ISO 26262结合编码指南定义了设计指南的要求。

3.驗證

所謂“驗證”，就是確認已“正確”完成産品開發。

在ISO26262中，關于軟件架構設計、軟件單體設計和實現(編碼)，規定需要完成與ASIL等級相對應的驗證。

对于软件架构设计验证，如果是ASIL A级别，只要排查就足够了。但如果是达到符合ASIL D级别，则必须进行检查，动态（可执行模型）仿真，原型设计，控制流/数据流分析。

对于软件单一设计和实现（编码）验证，如果是ASIL A级别，只要排查就足够了。但如果是达到符合ASIL D级别，就必须进行检查，半正式验证（使用基于模型的仿真验证等），控制流/数据流分析，静态代码分析。

4.確認

所謂“確認”，就是通過提供客觀證據對特定的預期用途或應用要求已得到滿足的認定。通過試驗來確認是否産生了滿足要求的成果物。

对于ASIL D等级要求，无论是软件单元测试还是软件集成测试，都必须进行基于需求的测试、接口测试、故障注入测试、资源测试和背靠背测试。

在测试用例的导出方法中，需求分析，等价类的创建和分析以及边界值分析是对于符合ASIL D等级的基本要求。

对于软件单元测试的覆盖率，ASIL A可以执行100％的C0覆盖（指令覆盖率），而ASIL D则要求100%实施C1覆盖(分支网罗率)及MC/DC(Modified Condition/Decision Coverrage) 。

对于软件集成测试，ASIL D要求100%实施功能覆盖和调用覆盖。

5.軟件工具的認證

为了软件开发而使用导入的各种软件工具（以下简称为工具），ISO 26262为它们设定了可靠性评估指标，只有被认定为符合指标的工具才能够用于开发。

所以，首先第一步，我们需要看看工具是否符合ISO 26262的认证标准。

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

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

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

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

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

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

1a 信赖度通过使用而增强

只有提供了標准規定的工具實際應用的有關證據，才能基于使用曆史，提升工具的信賴度。

1b 评估工具开发过程

該工具開發的開發過程是否開發流程，開發標准。

1c 软件工具确认确认

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

1d 按照安全标准进行开发

工具开发是否符合ISO26262，IEC61508和RTCA DO-178（航空系统和设备的安全标准）等标准。

事实上，只要执行了附加认证，就可以使用TCL2或TCL3中评估的软件工具。ISO 26262也列出了关于TCL2和TCL3级工具可接受的认证方法。

ISO 26262-8:2011表4列出了对TCL3级工具可接受的认证方法，表5列出了对TCL2级工具可接受的认证方法。（如图）

根據工具中開發的項目或ASIL類別的不同，優先選擇應用不同的認證方法。下圖爲合並的表格，其中突出顯示了優選方法並且進行了說明。

++表示該方法被強烈建議用于所對應的ASIL

+表示該方法被建議用于所對應的ASIL

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

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

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

实际上，从供应商处购买工具时，用户很难执行认证。因此，引入符合ISO 26262的第三方认证工具是非常符合现实需求的。

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

在特定軟件組件发生故障时，为了防止对另一軟件組件造成不良影响，ISO 26262一个名为“软件隔离”的结构技术。当多个不同ASIL等级的軟件組件在同一个MPU上共存时，该技术非常适用。

举个例子：在没有分区的情况下，假设有ASIL A，ASIL B和ASIL C三个不同等级的软件，使用一个MPU和一个资源（共享内存）进行操作，则三个软件必须符合最高的ASIL等级要求（即ASIL C），导致必须承担高于必要的开发成本。同时，低等级的任务修改高等级的数据，会造成高等级使用了不可信的数据，影响安全功能。

如果有分区，即使三个不同ASIL等级的软件在一个MPU上，也可以将最佳的ASIL等级应用于各个軟件組件，可以避免浪费的开发成本。

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

7.流程改進

在嵌入式软件领域，要求不断改进过程标准，如CMMI和Automotive SPICE。

ISO 26262也需要流程改进，但基本上是对现有流程改进的延伸。建议至少通过CMMI Level 2和Automotive SPICE Level 3认证。

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

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

第三方组织可以是公司内的独立部门，例如质量保证部门，或是外部第三方认证机构。为应对功能安全认证的市場需求，有许多供应商和工具供应商要求知名第三方认证机构进行审核。

七、結論

2011年11月15日，ISO 26262 标准正式颁布。2018年，ISO 26262正式上路。

在这一领域，欧洲、日本应用ISO 26262要早于国内，美国则推出SAE J2980标准。技术咨询公司在和国内OEM合作时会要求引入功能安全。国际汽车厂商（宝马、通用、福特等）、汽车零部件供应商（博世、德尔福等）早已采用该标准开发安全相关的电子电器产品，应用在汽车的开发。

ISO 26262涉及汽车电子电气系统的整个安全生命周期及其管理过程，满足该标准对汽车企业及供应商来说必将是巨大的挑战。为满足ISO 26262，必须在公司安全文化、工作流程制定、产品设计与开发等方面进行持续的改进。

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

▲文章来源于：知乎   牛喀学城

返回