一、概述
随着科技日益进步，汽车电子系统日益增加，车上越来越多的电控单元与我们的安全息息相关。我们将与我们安全相关的电控系统称为安全相关系统，安全相关系统的功能失效等可能导致的安全问题，即为功能安全所关注的范畴。例如由于电控系统的功能失效导致的车辆的意外加速，意外减速等等。而车辆由于机械故障，燃油泄漏等等导致的安全问题不属于功能安全范畴。
随着安全问题的日益突出，传统的开发方式已经不能够满足保证电控单元的安全的需求，因而在汽车电控单元开发工作中引入功能安全的概念，通过功能安全标准，全面完整的保证电控单元开发应用过程中的安全问题。
2000年5月，由国际电工委员会正式发布iec61508 电气/电子/可编程电子安全系统的功能安全。2011年国际标准化组织颁布汽车相关的功能安全标准iso26262。iso26262主要定位于汽车领域的电子电器部件，旨在提高汽车电子、电气产品功能安全。iso26262为汽车安全提供了一个生命周期理念，从管理、到开发、生产、经营、服务、直至报废，并在这些生命周期阶段中提供必要的技术和管理支持。
我国正在iso26262的基础上制定对应的国家标准，目前国内的技术水平普遍低于iso标准，因此在与国际接轨过程中，提升自己的能力，符合功能安全保准的要求首当其冲，然而，建立功能安全的体系需要从组织结构做起，全面系统的形成符合功能安全需求的管理、研发、生产体系，对于国内的企业而言，从无到有建立这样的体系面临的挑战是可想而知的，而恒润作为国标委的核心成员，全程参与功能安全国家标准的制定过程，公司内部有专门的部门负责功能安全的咨询，实施工作，能够协助企业顺利完整的实现功能安全体系的建立。
对于一个安全相关系统的开发，功能安全的内容贯穿整个产品的生命周期，从开始的项目定义到最终的产品报废，整个过程如图所示，整个的功能安全流程主要分为：管理、概念、系统、软件开发、硬件开发、生产与应用维护等几个方面，通过此几个方面的联合管理，保证产品的功能安全问题。在此文中我们简单介绍硬件开发相关的功能安全内容。
二、硬件阶段的功能安全开发过程
硬件的功能安全开发是在概念和系统阶段之后进行的，在概念和系统阶段我们应当已经得到了项目的具体定义、并对项目的应用场景进行分析，以得到产品的功能安全等级（asil等级），同时在系统阶段我们要得到完整的系统设计，以及针对我们的产品和对应的功能安全等级所提出的功能安全需求（保证哪些功能安全）和技术安全需求（如何保证功能安全）。
在这之后到了硬件的功能安全开发阶段，首要做的事情是通过技术安全需求具体导出硬件安全需求（即：在硬件方面我们要如何去保证功能安全），当我们导出硬件安全需求之后，我们就可以依照系统设计和硬件安全需求去进行硬件开发。在硬件设计阶段，除了硬件设计工作之外，我们同样要进行安全分析和设计验证工作，以保证硬件设计满足安全需求。
在功能安全的范畴内，硬件的开发阶段，有两个过程是区分与传统的开发流程的，即硬件架构的指标分析和硬件的随机失效率分析，通过此两个过程获得的三个量化硬件指标去衡量硬件设计时候符合功能安全的要求。
对于硬件功能安全开发主要分为六个阶段：如下图所示
在硬件功能安全开发阶段之前，需要经过系统阶段，建立全面的功能安全计划，以及对应的技术安全需求（参照汽车功能安全开发的系统阶段）
阶段一【5.5】：硬件层面上的产品研发启动
启动硬件开发阶段，制定硬件开发阶段的各种安全活动和安全计划。
阶段二【5.6】：硬件安全需求规范
在此阶段我们需要依据技术安全需求制定出一致完整的能够用于指导开发的需求规范，技术安全需求由功能安全的系统阶段提出。
阶段三【5.7】：硬件设计
根据系统规范和硬件安全需求进行设计，
硬件设计包含硬件架构设计和硬件详细设计两个部分，对于硬件架构设计要表示出所有硬件组件及彼此间的关联、保证硬件安全需求和实现之间的可追溯性、同时考虑复用和非功能因素。对于硬件详细设计即为原理图级别，同时要考虑硬件零部件在应用环境和操作规范下的使用以及硬件的鲁棒性。在硬件设计阶段同时要进行安全分析并验证硬件设计。
阶段四【5.8】：分析硬件架构指标
在此阶段我们要分析硬件架构的指标：单点故障指标、潜在故障指标
阶段五【5.9】：分析随机失效率指标
阶段六【5.10】：硬件集成和测试
三、硬件设计的评价指标
在整个的硬件功能安全开发方面，我们需要通过硬件的评价指标来衡量硬件的设计是否符合对应等级的功能安全标准：
在介绍硬件指标之前要引入几种不同的故障形式：
单点故障：某个器件单独发生会导致功能失效的故障，即为单点故障（单点故障没有安全机制去保证其出错后的安全性）
残余故障：当为了保证某个单点故障发生之后的安全性而引入安全机制之后，某些不能被安全机制覆盖的故障形式即为残余故障（当残余故障发生时，安全机制是无效的）
潜在故障（潜伏故障）：被安全机制覆盖的单点故障和安全机制共同构成多点故障，若这些多点故障没有更多的安全机制覆盖时，即为潜在故障（当安全机制出现故障时，潜在故障发生即会导致出现安全问题）
功能安全引入硬件架构等指标能够客观的评估不同架构之间的区别，并能够依照质保评估最终设计、评价asil等级通过的标准等
硬件架构指标：
单点故障指标目标值
|
|
asil b
|
asil c
|
asil d
|
|
单点故障指标
|
>=90%
|
>=97%
|
>=99%
|
潜在故障目标值
|
|
asil b
|
asil c
|
asil d
|
|
潜在故障指标
|
>=60%
|
>=80%
|
>=90%
|
随机失效率指标：
对于随机失效率指标可采用两种不同的方法来评价，两种方法均为评估由于单点失效、潜在失效或者可能的多点失效导致的违背安全目标的残余风险。
方法一：随机硬件失效的概率统计（pmhf），例如定量故障树分析（fta）
方法二：独立评价每一个会违背安全目标的单点故障和潜在故障，例如割集分析
对于pmhf方法，不同的asil等级推荐的目标值
|
|
asil b
|
asil c
|
asil d
|
|
随机失效率指标
|
<10-7h-1
|
<10-7h-1
|
<10-8h-1
|
对于方法2：不同的故障类型具有不同的衡量指标：
单点故障的失效率等级目标值
|
|
asil b
|
asil c
|
asil d
|
|
单点故障的失效率等级目标值
|
失效率等级1/2
|
失效率等级1/失效率等级2+专门措施
|
失效率等级1+专门措施
|
残余故障的评价指标
|
asil 等级
|
残余故障对应的诊断覆盖度
|
|
>=99.9%
|
>=99%
|
>=90%
|
<90%
|
|
asil d
|
失效率等级4
|
失效率等级3
|
失效率等级2
|
失效率等级1+专门措施
|
|
asil c
|
失效率等级5
|
失效率等级4
|
失效率等级3
|
失效率等级2+专门措施
|
|
asil b
|
失效率等级5
|
失效率等级4
|
失效率等级3
|
失效率等级2
|
潜在故障的评价指标
|
asil 等级
|
潜在故障对应的诊断覆盖度
|
|
>=99%
|
>=90%
|
<90%
|
|
asil d
|
失效率等级4
|
失效率等级3
|
失效率等级2
|
|
asil c
|
失效率等级5
|
失效率等级4
|
失效率等级3
|
四、总结
通过以上的介绍，可以看出功能安全的硬件开发与传统的硬件开发从核心过程上是基本保持一致的，但是从技术指标上是有很大区别的，同时，在计算硬件的评价指标方面有涉及到一系列的方法，如何能完备的完成硬件的功能安全开发就成为完备的功能安全体系的一个必要条件。
.jpg)
.jpg)