SASETECH，是国内首个由汽车安全专家发起组建的技术社区，致力于为汽车安全的从业者提供交流、学习、合作的中立性平台。
本文概述
笔者从事功能安全工作三年有余，站在一个工程师的职业生涯的角度，目前还处于探索的初期。无论是研究什么领域，初期都有个明显的特点：技术积累速度快，同时发现之前认知错误或偏差的情况也频繁。比如单就“如何理解和对待功能安全？”这一简单的问题，对它的回答在这三年的项目实践过程中也迭代了好几版答案。
“如何理解和对待功能安全”？从事功能安全开发的工程师不仅会时常自我发问，也经常收到来自从事其他方向的工程师的“拷问”。本文意在整理笔者当前对这个问题的答案。需要强调的是，受限于个人经验能力，这个答案不会完美，它依旧在不断迭代；但是笔者认为它至少具备一定的成熟度，可以给刚入门或者即将入门做功能安全的工程师一些参考。
另外，笔者计划借助SESETECH的平台，维护一个定位为“功能安全开发入门”的系列文章，旨在围绕着ISO 26262的标准框架，结合实例对功能安全开发的方法论的实践运用展开说明，希望能为功能安全初学者提供一个可以参考的视角，同时也希望在分享的过程中能让读者深刻体会功能安全开发的关键不是流程，而是技术。欢迎感兴趣的读者订阅专栏，同时欢迎所有指正文章问题或者进行技术讨论的声音，相互交流，共同进步。
目录
01 功能安全的范围
02 功能安全的方法论
03 功能安全与产品安全的区别
1 功能安全的范围
实际上“功能安全”是一个在ISO 26262发布之前就存在的概念。随着计算机、集成电路等技术的发展已经渗透到所有工业领域，对电子/电气的安全和可靠性要求也越来越高。国际电工委员会在2000年5月正式发布的电气和电子部件行业相关标准IEC 61508《电气/电子/可编程电子安全系统的功能安全》对工业领域（自动化、轨道交通、机器人等等）的电气/电子/可编程电子部件构成的系统的整体安全生命周期建立了一个基础的评价方法。
但是宽泛的适用范围以及标准制订时并没有引入汽车行业，使得IEC 61508直接实施在汽车领域存在很多局限，导致国内外主流OEM虽然在汽车功能安全开发实践中有过探索和实践，但难成行业体系。
另一方面，随着计算机和集成电路技术的发展，层出不穷的汽车被动安全和主动安全系统在拯救了无数生命的同时，也存在着功能异常表现而造成危及生命的伤害的潜在风险（如安全气囊非预期起爆）。于此同时，在汽车智能化的浪潮下，汽车上的电气和电子系统（E/E system）也越来越复杂。汽车行业亟需一个通用的适用于汽车E/E系统的安全性的评价体系和安全开发的指导体系。
在这样的背景下，ISO 26262基于IEC 61508的理论框架衍生开来，并于2011年正式发布第一版，旨在对汽车安全生命周期(管理、开发、生产、运行、服务、报废)的各个阶段提供功能安全方法指导。自此，基于ISO 26262的系统指导，汽车功能安全开始真正地陆续融入国内外各大主流OEM的开发体系中。
ISO 26262与IEC 61580
我国也在不断推进功能安全在汽车行业的落地，国家标准化管理委员会基于ISO 26262的框架体系于2017年发布《GB/T 34590道路车辆 功能安全》，该标准的发布对推动功能安全在中国汽车行业的落地有着积极作用。
ISO 26262对几个关键词的定义进一步明确了明确了汽车功能安全的范围。
Absence of unreasonable risk due to hazards caused by malfunctioning behavior of E/E systems. (不存在由电子/电气系统的功能异常表现引起的危害而导致不合理的风险。)
1. “E/E system”， 电子/电气系统
功能安全要讨论的对象是E/E系统，更明确地说是组成E/E系统的软件和硬件。因此，机械/液压/化学等安全设计都不在ISO 26262的研究范围。
2. “hazard”，危害
危害的类型有很多种，比如健康伤害、财产损失等等。功能安全讨论的危害仅仅指因为E/E系统的故障行为而引起的对人的健康伤害。同时需要强调一点，功能安全指的对人的伤害不仅仅是驾驶员，同时包括路人或周边车辆内人员。
3. “unreasonable risk” ，不合理的风险
世界上没有100%安全的产品，功能异常不可能100%避免。功能安全的目标是将E/E系统出现功能异常的可能性控制在合理的（或者说可接受的）范围内，以此将功能异常可能造成的风险控制在可接受的范围内。
2 功能安全的方法论
上节提到，功能安全的目标是将E/E系统出现功能异常而导致的风险控制在合理的范围内。实现这一目标可以分为两步：
· 识别不合理的风险
· 降低不合理的风险
2.1 识别不合理的风险
识别不合理的风险的功能安全开发活动称为“危害分析与风险评估”。危害分析与风险评估可以继续细分为两步：
step1:
识别相关项所有功能异常所有行为可能导致的整车危害
step2:
结合危害和危害发生时刻车辆运行的场景来分析风险。
不是所有的整车危害都会造成人身伤害。举例来说，和制动控制相关的ESC系统（电子稳定性系统，Electric Stability Controller）存在一个危害：ESC错误建立轮缸压力导致车辆产生非预期的制动。如果这个危害发生在高速公路上，很可能造成人员死亡；但是如果危害仅仅发生在车速低于10kph的停车场，则大大降低了人员死亡的风险。
因此，评估风险是否可被接受，需要结合危害和危害发生时刻车辆运行的场景来综合分析。当完整地罗列出所有场景与危害的组合后，接下来对其进行分类和筛选以确定哪些风险是可接受的，哪些是不可接受的。ISO 26262从三个维度来进行分类和筛选：
· S（severity 严重度）：危害发生对驾驶员或乘客或路人或周边车辆中人员会造成的伤害等级。
· E（Exposure 曝光度）：运行场景在日常驾驶过程中发生的概率。
·C（controllability 可控度）：驾驶员或其他涉险人员控制危害以避免伤害的概率。
通过这三个维度的综合评分确定汽车安全完整性等级（ ASIL, automotive safety integrity level），如下图所示。ASIL D代表最高严格等级，ASIL A 代表最低严格等级。QM（quality management）则意味着只要按照企业流程开发就可以满足ISO 26262要求，无其他特殊要求。
ASIL等级, 截图来自ISO 26262
ISO 26262,part3指出：“应为具有ASIL等级的每个危害事件确定一个安全目标,该ASIL等级从危害分析中得出。如果所确定的安全目标是类似的,可将其合并为一个安全目标”。ASIL等级是安全目标的基本属性，ASIL等级越高，意味着危害事件造成的不合理的风险越大，因此功能安全开发要求也会越高。
2.2 降低不合理的风险
当识别出不合理的风险后，接下来就需要对能引起不合理的风险的功能进行功能安全开发，尽可能避免功能异常发生的概率或功能异常所能造成的风险的严重程度。
要想有效避免功能异常，首先需要知道功能异常是如何发生的。从下图可以看出，E/E系统种要素（软件或硬件）的三类故障最终可能引起系统的失效从而引起功能异常而导致风险：
· 系统性软件故障
· 系统性硬件故障
· 随机硬件故障
故障导致失效的示例，截图来自GB/T 34590, 第10部分
前两类故障统称为系统性故障，由它们导致的失效则称为“系统性失效”；后者则导致“随机硬件失效”。两类失效的特点和区别为：
· 系统性失效（systematic failure）：以确定的方式与某个原因相关的失效，只有对设计或生产流程、操作规程、文档或其他相关因素进行变更后才可能排除这种失效。
· 随机硬件失效(random hardware failure)：在硬件要素的生命周期中，非预期发生并服从概率分布的失效。
由此我们可以说，功能安全开发将功能异常控制在可接受的范围内，本质上就是将系统性失效和随机硬件失效控制在可接受的范围内。
如果结合“V模型”开发来看，控制系统性失效的措施可以概况为两点：
· 在“V模型”左边设计阶段考虑尽可能周到
· 在“V模型”右边验证阶段验证尽可能完善
进一步地，保证“左边设计阶段考虑尽可能周到”，既体现在对开发者的要求上，也体现在对审核过程的要求上。以软件举例，"V模型"中的各个阶段及要点示意如下。
软件开发过程“V模型”, 截图来自GB/T 34590
而对随机硬件失效的控制，ISO 26262从以下两个维度提出了要求：
· 硬件架构度量的评估(Evaluation of the hardware architectural metrics)
· 随机硬件失效导致违背安全目标的评估(Evaluation of safety goal violations due to random hardware failures)
硬件架构度量用来评估相关项的架构应对随机硬件失效时的有效性。硬件架构的度量旨在实现以下目标：
· 显示用于防止硬件架构中单点或残余故障风险的安全机制的覆盖率是否足够(单点故障度量)；
· 显示用于防止硬件架构中潜伏故障风险的安全机制的覆盖率是否足够(潜伏故障度量)
对随机硬件失效导致违背安全目标的评估是用来确定违背安全目标的残余风险已经足够低。ISO 26262对这一评估推荐了两个方法：
· 第一个方法包括使用概率的度量,即“随机硬件失效概率度量”( Probabilistic Metric for random Hardware Failures，PMHF)，通过使用例如定量故障树分析(FTA)及将此计算结果与目标值相比较的方法，评估是否违背所考虑的安全目标。
· 第二个方法包括独立的评估每个残余和单点故障，及每个双点失效是否导致违背所考虑的安全目标。
值得一提的是，实际开发中所有的公司几乎都使用PMHF。
3 功能安全与产品安全的区别
很多功能安全工程师在日常生活中可能会面临一个相同的困扰：项目开发中和安全挂钩的任何问题，不管三七二十一都会拉功能安全工程师进入讨论组，并期待功能安全工程师做出决定。
面对这个普遍的“误解”，功能安全工程师需要首先在项目团队中强调：功能安全≠产品安全，不要“放大”了功能安全的作用。
一个完整的汽车产品的组成部分除了软件和硬件外，还包括机械或液压等其他部件，也就是说，对于一个安全相关的产品而言，除了E/E故障可能引起产品失效进而造成安全风险外，机械故障、液压故障等都可能造成安全风险。因此，产品安全(Product Safety)是一个包含汽车功能安全(Functional Safety)的更大安全主题，对于一款安全相关的产品的开发，实现功能安全并不意味着实现了产品安全。从这个角度看，决定一款安全相关的产品最终能否释放到市场上，产品经理扮演着比功能安全经理更重要的角色，产品经理需要综合各个组成部件的安全设计和风险评估结果来做出决定。
功能安全与产品安全的关系
功能安全与产品安全的区别在 “functional safety related availability”这一话题中会得到深刻的体现。这一话题常见于对自动驾驶冗余系统的安全设计中，比如确定当冗余系统的主路（primary）出现故障后，辅路（backup）在紧急运行(Emergency Operation)过程中的表现。2018版ISO 26262的第10部分新增了这一话题的讨论，并基于案例给出了指导。笔者认为，从方法论的角度，ISO 26262的指导十分有借鉴意义，但是从实践的角度，由于案例分析中只考虑了功能安全，得出的结论将会受到挑战。
比如，在确定冗余系统的辅路在紧急运行时的最大允许运行时间Teotti(Emergency Operation Tolerance Time Interval)时，ISO 26262的案例分析中使用了PMHF作为紧急运行过程中可接受的出错概率，但是由于没有第三套备份，意味着辅路系统在紧急运行时出现任何导致功能失效的故障都将造成风险，包括E/E故障、机械故障或者液压故障等。因此，以仅关注E/E故障的PMHF为目标导出的Teotti存在不完整性。
作者： 小青的风筝
文章来源：sasetech
推荐阅读
更多物联网安全，PSA等技术干货请关注平台安全架构(PSA)专栏。欢迎添加极术小姐姐微信（id:aijishu20)加入PSA技术交流群，请备注研究方向。
