本文将介绍ISO-26262标准所规范的系统功能安全发展概念，并以一个微控制器分析案例来展示ISO-26262在实际设计上的应用。

前言

下列为ISO-26262安全流程之各章节名称：

Part 1 :名词解释(Vocabulary)

Part 2 : 功能安全管理(Management of functional safety) 

Part 3 : 概念阶段(Concept phase) 

Part 4 : 产品开发：系统层级(Product development: system level) 

Part 5 : 产品开发：硬体次系统层级(Product development: hardware level) 

Part 6 : 产品开发：软体次系统层级(Product development: software level) 

Part 7 : 生产与操作使用(Production and operation) 

Part 8 : 支援流程(Supporting processes) 

Part 9 : ASIL 等级界定与安全达成度分析(ASIL-oriented and safety-oriented analyses) 

Part 10 : ISO-26262指南(Guideline)

而在这些章节中，又以三大阶段为主要重点，如图2所示：

3.生产、运作阶段：以Part 7、Part 8为主，在于规范产品生产、操作规划、生产前确认相关功能安全需求皆被设计与实行、关于组装与制造之需求发展与执行与产品销售后续服务的SOP(Start Of Production)流程。

ISO-26262安全性验证方法

为了实现具有高可靠度/安全性的车用电子系统，势必要在系统的设计中加入安全机制(Safety Mechanism)来避免系统失效时造成危害。然而加入什么样的安全机制，如何才能让安全机制发挥最大的效用，不能仅凭研发工程师的主观认定，必须透过一套有系统的分析方法来制定安全机制的设计方针。故安全性分析(Safety Analysis)也是ISO 26262规范中非常重要的一项要求，而当微控制器芯片的ASIL要求在等级B以上时，也必须透过安全性分析来验证是否能够达成预期的ASIL要求。

上图4为常见的车用电子产品的V-model开发流程，由图4可知安全分析主要从芯片研发初期时就必须进行，才能为安全机制的设计提供最好的依据。在ISO 26262规范中建议的安全分析方法主要有FMEA(Failure Mode and EffectAnalysis)、FTA(Fault Tree Analysis)以及FMEDA(Failure Mode Effect and Diagnostic Analysis)三种。三种分析方法都有其不同的目的，FMEA主要是用于列出MCU内元件有哪些可能的失效模式，以及这些失效模组对MCU的影响；FTA则是列出导致MCU失效的原因主要是由于哪个/些元件出错所导致；而FMEDA主要是用来分析不同的安全机制对于各种不同的元件失效模式的有效性。针对MCU硬件设计的开发商来说，FMEDA尤其重要，因为在ISO 26262规范中，FMEDA是用来评判MCU硬体能否达到ASIL要求的主要依据之一。第4章将会有MCU FMEDA的实例展示。

1. ISO 26262软件安全性验证方法

ISO-26262标准对软件的设计与测试验证于Part6单元有详细描述。因为汽车领域有其特殊之发展需求，如控制系统的Model based design 与规格验证等。汽车电子发展流程常用V-Model流程来叙述，如图5所示。从系统的需求透过模型建立分析来产生系统设计规格并透过工具如CarSim或dSPACE来验证确认设计规格是否满足需求。进而再配置安全功能到硬件或软件的设计上。

软件的验证从Model Based Software 验证到原始程式码的静态分析(Static Analysis) 以及动态分析(Dynamic Analysis)来验证软件设计的安全性。静态分析常用MISRA C or C++来检查是否违背安全设计法则，常见的动态分析包括 白箱测试(white box testing)以及Back-to-Back 测试，如图6所示。

软件的测试矩阵(metrics)标准要求须符合单元测试覆盖(Coverage) 如语句(Statement)、分支(Branch)、MC/DC(Modified Condition/Decision Coverage以及整合测试(Integration Test)，如功能涵盖率( Function Coverage)、呼叫功能涵盖率(Call Coverage)，如图7所示。

例如，安全架构师可以估计将纠错代码（ECC）添加到内存中所产生的影响，审查诊断覆盖率的总体改进，并确定所推荐的一组安全机制是否能满足安全目标。

汽车微控制器实例展示

图8是一款汽车微控制器架构图，其主要应用为电动车马达的控制，故此微控制器须能符合高安全性的要求。在此我们将此微控制器的安全性要求设为ASIL D。而根据表1可知其各项相关参数的量化标准。

表1中SPFM是Single Point Fault Metrics的缩写，代表的是对于单点错误的容错能力。而LFM则是Latent-multiple-point Fault Metrics 的缩写，代表的则是对于多点错误的容错能力。最后PMHF则是Probabilistic Metrics for Hardware Failure的缩写，即所谓的硬件失效率，单位为FIT（Failure In Time）。下表2是图8汽车微控制器在未加入安全机制前的硬件失效率。

由表2可知，其硬件失效率高达725，与ASIL-D的要求还有很大的差距。分析此差距是加入安全机制时非常必要的事前工作，可以让设计者在决定采用何种安全机制时能够有所依据，尽量避免不适当设计的产生。为了达成ASIL-D的要求，势必要加入安全机制（Safety Mechanism）来提升微控制器的安全性，而ISO 26262对于ASIL-D的硬件设计有非常高的要求（如表1），任何克服故障的方法都必须有赖于故障的侦测与诊断机制。一般来说，诊断机制的故障诊断率越高，也代表微控制器的安全性越高。

因此高安全性反映在硬件设计上即代表安全机制需要非常高的故障诊断覆盖率（Diagnostic Coverage，DC）。DC值在ISO 26262中可分为high（99%）、medium（90%）、与low（60%）三种等级，表3列出ISO 26262 part 5 所提供的微控制器安全机制参考设计，这些安全机制都具有99%的DC值，欲达成ASIL-D的要求，建议加入这些具有高故障诊断率的安全机制到微控制器设计中。

下图9是参考上表3之后，将图8微控制器进一步改良之后的架构图。比较图8与图9可以发现，加入安全机制后整体架构图的改变。为了验证加入的安全机制，可以使微控制器的整体故障率达到ASIL-D的要求，在此我们采用了FMEDA方法来分析，下表4 是针对此架构所进行的FMEDA的部分结果展示。如需要芯片安全设计技术培训或FMEDA相关工程服务，请致电牛喀网客服：189-1745-1722。

根据FMEDA的分析结果，改良后的微控制器的硬件失效率可降至9.45FITs，已符合ASIL D的< 10 FITs的要求。由上述实例展示可知，为了要达成高安全性微控制器的设计，在架构设计时就必须将安全性的议题纳入考虑。这无疑会使原有的设计周期所需花费的时间变长，也会增加额外的人力与软硬件投入。然而因为汽车微控制器芯片与人身生命安全有重大关联，这些投资是不可避免的。若将来中国的IC设计产业想扩大汽车电子产品的市场，势必要将以往只考虑成本与出货时间的观念加以调整。

结论

在本文中，针对汽车电子产业目前主要依循的功能安全规范ISO 26262，提供了整体概念与其核心精神的介绍。另外针对ISO 26262中较为特别的SEooC设计概念也有所涉及。针对软件安全性设计的部分，则是介绍了其测试项目以及与V模型开发流程之间的整合关系。最后则是利用所开发的一款微控制器作为展示案例，说明ISO 26262安全标准的实际应用。