下载掌阅APP，畅读海量书库
立即打开
本章将概括性地介绍ISO 26262及GB/T 34590功能安全标准的内容，包含安全文化的理解、标准的发展历程、功能安全对于产品开发的意义、重要的术语及定义、标准内容框架及概览、标准分解概览等。
本章从一份问题清单开始，其中包含了标准各个部分相关的基础性问题以及实践过程中可能遇到的各种问题，旨在引导大家带着问题去阅读、思考和实践。这份清单可以说是一份进入功能安全标准的“入门考卷”。
注：除非特别说明，本书中的“标准”是指ISO 26262及对应版本的GB/T 34590。
在结合项目实践逐步展开标准内容解读之前，我想先在这里埋下一个“伏笔”，作为预先安排的一个测试。
表1-1为一份关于功能安全标准内容的初阶问题清单。由于时间和能力有限，该问题清单并不能涵盖全部标准，权当用于引发思考。随着学习的持续和深入，本清单可用于粗略检视自身学习过程中的问题，也可用于交流探讨。希望该问题清单能不断扩展，逐渐深入。
表1-1 功能安全标准初阶问题清单
（续）
（续）
各位可以结合本书和表1-1中的问题清单去学习标准，答案终将在个人学习和实践的反复磨砺中得到。
千淘万漉虽辛苦，吹尽狂沙始到金。
功能安全是一门“流程和技术相结合”的综合性通用学科，文化其实是流程的一种抽象。如果一家公司拥有先进、成熟的开发和管理流程，其安全文化自然不会差，因为流程是文化的具象化体现。简单来说，就是通过流程将文化落地。
拥有优秀的流程相当于有了好的开端，这是功能安全在项目中落地的一大保障，通过“流程为技术赋能”是功能安全真正落地的先进模式。
在讨论安全文化之前，有必要了解一下这个词的概念。由于本书是关于ISO 26262功能安全标准的内容，文中提到的“安全”特指汽车行业的功能安全。但是，安全文化中的“安全”不仅仅指功能安全，还涵盖产品开发过程中与安全相关的各个方面，我称之为“大安全”，包括功能安全、预期功能安全和信息安全。这也符合汽车发展的趋势以及对安全的需求。
1.定义
先来看看“文化”的概念。从百度百科的解释来看，“文化”一词的含义非常广泛，不同行业、不同学科都有自己的定义。其中有一种比较符合本书要表达的含义，即“文化是人类创新活动永恒拓展的载体、创新水平提升的工具、传播的手段”。
看起来该定义非常宏大，因为涉及人类创新活动。如果将活动主体缩小到公司范畴，这个定义就变得具体一些了，即“文化是公司创新活动永恒拓展的载体、创新水平提升的工具、传播的手段”。
简单讲，文化是一种载体、工具和手段。按此定义延伸到安全相关方面，安全文化则是公司安全相关活动拓展的载体、安全活动创新水平提升的工具、安全活动传播的手段，这不就是流程吗？结合个人理解和日常工作的实践经验，我对此定义深以为然。
言归正传，回到本节的主题“安全文化”。ISO 26262标准中给出了安全文化的定义，具体如下。
标准原文Safety culture includes：
a） personal dedication and integrity of the persons responsible for achieving or maintaining functional safety and of the persons performing or supporting safety activities in the organization；and
b） safety thinking throughout the organization that allows for a questioning attitude，that prevents complacency，commits to excellence ，fosters the taking of responsibility and corporate self-regulation in safety matters.
（参考ISO 26262-2:2018，Annex B）
解读 该定义强调了参与功能安全活动的组织与个人需要具备奉献、正直和诚信精神，因为这些品质会影响安全的质量。同时，该定义还强调组织要具备安全思维，围绕安全问题保持质疑，勇于承担责任和自我监督，使安全相关活动能够创新发展。这与上文提到的安全文化的内涵相符合。
2.评价标准
那么，具体如何用该定义来衡量安全文化是否足够或达标呢？
ISO 26262-2:2018附录B表B.1中的例子非常具有说明意义。我们可以从中挑选一部分来举一反三，如表1-2所示。
表1-2 安全文化评估示例
（续）
总体来说，安全文化是否满足标准要求可参考表1-3进行评估。
表1-3 安全文化评估
（续）
注：本表格仅供参考，组织可根据自身情况进行扩充。
以上准则的某些方面需要基于一些假设，例如第4条安全评估活动的公正性能否得到保障，要完美实现这一点，前提是评估人员需具备诚信和正直的品质，否则将成为安全评估中的一个“漏洞”。
根据上文的介绍，安全文化实际上是一种流程规范的抽象，嵌入公司产品开发流程的各个细节中。拥有良好的安全文化意味着功能安全落地得到了流程上的支撑和保障，使功能安全活动的开展不再面临诸多“开头难”问题，这是令人兴奋的。
Q：标准对于安全文化具体有哪些要求呢？
作为安全管理的一部分，标准要求组织建立一套功能安全开发流程，以指导并确保所有的功能安全活动都朝着实现项目功能安全目标的方向前进，具体要求如下。
标准原文The organization shall create，foster，and sustain a safety culture that supports and encourages the effective achievement of functional safety.
（参考ISO 26262-2:2018，5.4.2.1）
解读 在具体实施层面，上述标准要求的实践如下。
1）将功能安全的流程融入组织的开发流程中，基本的做法是在原本没有考虑功能安全输出物的项目计划中，同步明确各阶段与安全相关的输出物。
2）为了确保参与安全活动的人员具备功能安全相关知识，必须对他们进行有计划、有针对性和持续性的培训。这种培训旨在让团队成员充分认识到功能安全的重要性。简单来说就是，通过持续的培训，使团队成员明确功能安全的概念、必要性及实施方法，培养他们的安全开发意识。
标准原文The organization shall institute，execute and maintain organization-specific rules and processes to achieve and maintain functional safety and to comply with the requirements of the ISO 26262 series of standards.
（参考ISO 26262-2:2018，5.4.2.2）
解读 此要求需要组织输出一份公司级的关于功能安全开发的流程规范文件。该文件需清楚定义公司实施功能安全活动的流程和各环节的职责。标准定义的V模型本身就是一个通用的流程，只不过需要在此基础上进行展开并根据组织自身情况进行细化。
功能安全V模型具体可参考图1-1。
图1-1 功能安全V模型
由功能安全V模型导出的功能安全开发流程可参考图1-2。
标准原文The organization shall institute and maintain effective communication channels between functional safety，cybersecurity，and other disciplines that are related to the achievement of functional safety.
（参考ISO 26262-2:2018，5.4.2.3）
图1-2 功能安全开发流程
解读 该要求可以在上一条（参见ISO 26262-2:2018，5.4.2.2）定义组织的功能安全开发流程规范时进行同时覆盖，也就是在定义功能安全开发流程的同时，考虑其他相关标准的要求。典型的例子是ISO 21434的网络安全，即在具体实施时，可以在定义功能安全开发流程时同步考虑网络安全相关输出物。
标准原文During the execution of the safety lifecycle，the organization shall perform the required safety activities，including the creation and management of the associated documentation in accordance with ISO 26262-8:2018，Clause 10.
（参考ISO 26262-2:2018，5.4.2.4）
解读 这是一条关于文档化管理的要求，即组织在项目的整个安全生命周期内，必须按照已定义的开发流程规范，对各阶段的输出物进行有效管理。这包括输出物的编码、命名、创建、存放和权限管理等。具体如何进行文档管理，可以根据公司现有资源进行安排，如使用服务器、专门的文档管理工具或公司现有的其他系统，只要能满足上述要求即可。
标准原文The organization shall provide the resources required for the achievement of functional safety.
（参考ISO 26262-2:2018，5.4.2.5）
解读 这是基本要求，非功能安全项目也需要相关资源。这里的资源除了基本的人力、工具外，还包括流程方面的各种数据库（例如测试用例库、经验教训库等）、开发指引类文件、各类检查表等。该要求强调全方位支撑项目开发的“软性”资源，但往往这些“软性”资源是大部分组织所缺乏的。
标准原文The organization shall institute，execute and maintain a continuous improvement process，based on：
——learning from the experiences gained during the execution of the safety lifecycle of other items，including field experience；
——derived improvements for application on subsequent items.
（参考ISO 26262-2:2018，5.4.2.6）
解读 此要求可以在定义组织的功能安全开发流程规范时进行同步确定，即在该流程规范中明确组织如何进行持续改进。实际上，持续改进并非功能安全的新概念，质量管理中的PDCA循环就是一种持续改进的方法论。如图1-3所示，组织可根据PDCA循环制定持续改进策略。
图1-3 PDCA循环
这里我想分享一下功能安全开发持续改进落地的简化实用步骤，参见图1-4。
1）将项目管理中的开放问题列出清单进行管理。
2）对开口项进行闭环追踪，明确责任人、问题解决方案及解决日期。
3）将解决方案文档化形成经验教训案例，并按照文档管理要求进行案例文档的编号管理。
4）从经验教训文档中总结出相应的产品开发需求并进行编号。
5）将总结出的需求反馈到相关项目的需求规范中，并同步更新对应的需求规范。
6）通知开发团队更新相关需求，并实施对应需求的实现及验证。
图1-4 功能安全开发持续改进落地流程（简化版）
标准原文The organization shall ensure that the persons responsible for achieving or maintaining functional safety，or for performing or supporting the safety activities，are given sufficient authority to fulfil their responsibilities .
（参考ISO 26262-2:2018，5.4.2.7）
解读 此要求可以在定义组织的功能安全开发流程规范中同步明确。例如，开发流程规范应声明，产品开发过程中安全属性的优先级最高，必须确保所有安全相关问题都得到妥善解决。该要求还涉及配置的权限管理，例如，功能安全经理需具备访问标准要求的所有输出物的权限，以便进行功能安全开发和管理活动。同时，还要明确安全活动的对应责任人及其权限，并确保其权限与职责匹配。
以上就是标准关于安全文化落地的具体要求。总结而言，这些要求可以集中在一份输出物上进行呈现，即标准要求的“针对功能安全的组织特定的规则和流程”这份输出物。
该输出物也就是上文提到的组织的功能安全开发流程规范。将这份流程规范按上述要求及提示定义好，是组织安全文化落地的第一步，接下来就是执行的事。个人认为，优秀的安全文化落地的终极表现是组织从“别人要你这样做”到“我自己要这样做”的转变。
这正是“文化”一词的内涵所在，即为实现目标不断努力，持续改进和创新，最终实现组织内部理念的统一并获得外部的认可。这并非易事，需要坚持长期主义和群策群力，好事多磨。
安全文化的落地更多是对组织过程能力的考验，虽非易事，但道阻且长，行则将至。最后用中国古人的一句话来总结安全文化的落地，即“为之，则难者亦易矣；不为，则易者亦难矣”。
本节将对ISO 26262标准进行全面解析，包括ISO 26262的发展历程、重要术语和定义、汽车安全的意义、标准总体内容框架概览、标准分解概览。此外，本节还将介绍各部分内容之间的联系，以帮助读者全面了解标准的本质、用途及其内容框架。
ISO 26262是一部应用于汽车领域的标准，其应用范围为量产乘用车上的包含一个或多个电子电气系统的与安全相关的系统，但不适用于特殊用途车辆上特定的电子电气系统，例如为残疾驾驶者设计的车辆。ISO 26262发展历程参见图1-5。
图1-5 ISO 26262发展历程
许多行业都有各自的功能安全标准，这些标准最初均由IEC 61508派生而来，ISO 26262是针对汽车行业的功能安全标准，对应的国家标准为GB/T 34590。图1-6展示了IEC 61508与其他行业功能安全标准的关系。
图1-6 IEC 61508与其他行业功能安全标准的关系
在介绍标准之前，有必要了解一下ISO 26262标准的一些专业术语，这有助于更好地理解标准。ISO 26262专门用一个部分来介绍相关术语。标准中的术语是行业从业人员在搭建功能安全流程和实施功能安全开发、管理工作的过程中，与同行及公司内部使用的统一沟通语言。
以下摘取了标准中部分常用术语进行介绍，更多详情请参考标准的第1部分。
1.安全（Safety）
标准中对安全的定义是：不存在不合理的风险。
按一般的概念理解，安全就是没有风险、不受威胁、不出事故。按照这种概念，安全是不可控的，因为这是一个绝对安全的概念，而绝对安全是不存在的。
“不存在不合理的风险”这一定义将安全问题转化为风险问题，这使得安全变得可控，因为风险是可以控制的。
Q1：那么应如何控制风险？
Q2：什么是“不合理的”？或者如何界定合理性？
2.不合理风险（Unreasonable Risk）
标准中对不合理风险的定义是：根据现行的安全观念，在某种环境下被认为不可接受的风险。
Q3：那么，如何判断风险不可接受呢？为了实现风险的可接受性，功能安全开发人员需要做出哪些努力？
图1-7中标示了功能安全开发人员需要在哪些方面努力，以实现风险的可接受性。图中有两个词：“可接受的风险”和“可容忍的风险”，这两者有什么区别呢？
图1-7 风险降低示意图
解读 “不合理的风险”的定义中使用了一个状语“根据现行的安全观念”，直白点讲就是社会大众认可的道德观。从这个角度讲，风险是否可接受可以根据该地区社会大众对其接受的程度进行评价。
关于风险的接受标准，不同国家有不同的评价标准，如英国的ALARP、法国的GAMAB和德国的MEM等。这里不对这些评价标准做具体介绍，先简单举例说明什么样的风险被认为是“合理的”或“可接受的”。
比如，加油站有人边加油边点烟，这种情况你敢过去加油吗？再比如，一台装有被曝安全气囊缺陷的乘用车，以高于60km/h的速度行驶在道路上，这样的风险你能否接受？
接着上面的举例，边加油边点烟导致起火、爆炸的风险显然是非常高的，几乎所有社会大众对这样的风险都是不可接受的。那么，离加油站多远进行点烟导致的风险是可接受的呢？换句话说，风险可接受的标准又是如何界定的呢？
关于这个问题，我在这里分享了钢铁大王安德鲁·卡内基修建第一座跨越密西西比河、连接美国东西部的铁路大桥的故事作为启示。
卡内基的导师汤姆·斯科特设想建设一条跨越密西西比河的桥梁，这座桥长至少1.6km。此前，没有人建过这么长的铁路桥。根据过往建造桥梁的数据，高达1/4的桥会有倒塌的风险，但卡内基勇敢地接受了这一风险和挑战。经过7年的努力，世界上第一座宏伟的钢结构铁路大桥——圣路易斯大桥终于建成。
然而，大多数人却觉得，大桥有坍塌的风险。
当时的人们认为，大象不会踏上不结实的建筑。于是，卡内基决定让大象过桥。1874年的某个秋天，圣路易斯大桥迎来了它的第一批行人。这是一支由卡内基公司员工和好奇者组成的队伍，由一头巨象带头。巨象非常自信、从容地走上大桥，人们欢呼雀跃。他们见证了世界奇迹：这座铁路大桥能够承受巨大的压力，将美国东西部连接起来。
故事涉及铁路大桥在承受压力后坍塌风险有多大人们才能接受的问题。人们选择大象作为参照物，如果铁路大桥能承受住大象的压力，那么人走在桥上自然也不会有问题。人们能够接受他们走在这座桥上时桥发生坍塌的风险，此时的风险就可认为是合理的，也是可接受的。
3.风险（Risk）
标准中对风险的定义是：伤害发生的概率及其严重度的组合。
4.功能安全（Functional Safety）
标准中对功能安全的定义是：不存在由电子电气系统的功能异常表现引起的危害而导致的不合理风险。
5.电子电气系统（E/E System）
标准中对电子电气系统的定义是：由电子和电气要素组成的系统，包括可编程电子要素。
简单讲，构成一个系统的三要素为输入、处理和执行，如图1-8所示。
图1-8 系统三要素
6.伤害（Harm）
标准中对伤害的定义是：对人体造成的物理伤害或损伤。
由财产或环境破坏而导致的直接或间接对人体健康的损害或对人身的损伤（参考ISO/IEC Guide 51:1990）。由ISO 26262中的定义可知，安全关注的是人身安全。
7.危害（Hazard）
标准中对危害的定义是：由相关项的功能异常表现而导致的潜在伤害。
8.系统性失效（Systematic Failure）
标准中对系统性失效的定义是：与某个原因相关且以确定方式发生的失效，只有通过修改设计、生产流程、操作规程、文档等，才能排除此类失效。
9.随机硬件失效（Random Hardware Failure）
标准中对随机硬件失效的定义是：在硬件要素的生命周期中，非预期发生并服从概率分布的失效。
解读 由定义可知，系统性失效是原因确定的失效，即只要导致失效发生的条件具备，那失效就一定会发生，例如软件Bug。随机硬件失效是随机发生的，但其随机性服从一定的概率分布。
10.故障容错时间间隔（Fault Tolerant Time Interval，FTTI）
标准中对故障容错时间间隔的定义是：在安全机制未被激活的情况下，从相关项内部故障发生到可能发生危害事件的最短时间间隔。
FTTI的图形解释如图1-9所示。
图1-9 FTTI的图形解释
注：定义中明确指出，FTTI是指在没有安全机制或安全机制未起作用的情况下，从故障发生到导致危害事件的最短时间间隔。
11.汽车安全完整性等级（Automotive Safety Integrity Level，ASIL）
标准中对汽车安全完整性等级的定义是：四个等级之一，用于规定相关项或要素需要满足的ISO 26262中的要求和安全措施，以避免不合理的风险。其中，D代表最高严格等级，A代表最低严格等级。
解读 ASIL其实是一个表征需求严苛程度的指标。ASIL等级越高，在实现功能安全上需要满足的要求越严苛。
12.安全状态（Safe State）
标准中对安全状态的定义是：相关项在失效时，不存在不合理风险的运行模式。
解读 由定义可知，安全状态是一种运行模式。其实，安全状态可理解为一种从其他状态切换过来的状态，因为它是在失效发生后进入的一种运行模式。系统正常运行模式虽然也是安全的状态，但这里考虑的是发生某种失效后进入的状态，因此不把正常运行模式定义为安全状态。
13.相关项（Item）
标准中对相关项的定义是：适用于ISO 26262或GB/T 34590，实现整车功能或部分功能的系统或系统组合。
解读 简单理解，相关项即要开发的对象。
14.单点故障（Single Point Fault，SPF）
标准中对单点故障的定义是：要素中直接导致违背安全目标的硬件故障，且该要素中的故障未被任何安全机制覆盖。
解读 简单理解，单点故障即独立要素失效后能直接导致违背安全目标的故障且该失效没有相应措施来应对。例如，在整车控制器（VCU）中，加速踏板传感器故障导致踏板行程采样值错误（例如过高或过低），从而导致输出扭矩过大或过小，这将直接违背安全目标。
15.多点故障（Multiple Point Fault，MPF）
标准中对多点故障的定义是：在未被探测且未被感知到的情况下，与其他独立故障组合可能导致多点失效的故障。
注：多点故障只有在识别出（例如，通过故障树的割集分析）多点失效后才能被辨认出来。
解读 简单理解，需要两个及以上的独立故障同时发生才能导致违背安全目标的故障。例如，BMS的继电器驱动高、中、低边继电器都故障，导致高压回路断开失败，将会违背安全目标。
16.潜在故障（Latent Fault，LF）
标准中对潜在故障的定义是：在多点故障探测时间间隔内，未被安全机制探测到且未被驾驶员感知到的多点故障。
解读 由定义可知，潜在故障首先是一种多点故障，即需要两个及以上的独立故障同时发生才能导致潜在故障。这种故障既没有被安全机制探测到，也无法让驾驶员察觉。换言之，如果不采取相关措施进行检测，这种故障将伴随相关项的整个生命周期。此类故障往往是安全机制故障与基本功能本身故障相结合导致的。
图1-10展示了内存中某位发生反转（见蓝色数字）的故障。
图1-10 内存中的位反转故障
当内存发生位反转时，由于有ECC机制的存在，错误位会被直接纠正且不会有任何故障标志，因此，此位反转故障也就成了潜在故障，只能希望ECC机制不要出错。
反过来看，当ECC机制失效时，内存功能未受到影响，即ECC机制的失效是潜伏的。当内存恰巧也发生了位反转时，由于ECC机制已失效而无法应对，这势必会导致功能异常，进而违背安全目标，使其成为潜在故障。
那么，如何应对潜在故障呢？
根据定义，既然故障没有被探测到，那就必须为潜在的故障添加检测机制；既然驾驶员无法感知此故障发生，那就通过告警通知驾驶员故障的存在，以提示驾驶员及时进行相应的维修。
17.可用性（Availability）
标准中对可用性的定义是：在特定时间或给定的期间内，假设所需的外部资源是可用的，在给定条件下，产品处于执行所需功能状态的能力。
Q4：可用性和功能安全性是什么关系？两者在具体实现层面会有什么差异？
解读 从定义来看，可用性更多是实现基本功能的一种能力，而功能安全性关注的是如何在功能实现过程中控制因异常引起的风险。两者虽然属于产品的两种不同属性，但在实现层面具有一定的依存关系。例如，刹车这个功能，可用性强调踩下刹车踏板能实现预期的刹车效果，而功能安全性则考虑在刹车功能出现故障时该怎么办。比如，车辆在高速行驶时非预期地执行了刹车操作，这时其可用性并未受到破坏，但功能安全性却受到了威胁。因此，从实现层面来看，功能安全性需要对涉及安全的功能进行适当的监控和诊断，以及时应对基本功能故障问题。
可用性和功能安全性在实现上的区别可参考图1-11。
图1-11 可用性和功能安全性在实现上的区别
18.基线（Baseline）
标准中对基线的定义是：已批准的可作为变更基础的一组单一或多个工作成果、相关项或要素的版本。
解读 基线是项目管理中的一个重要概念，它指的是项目启动阶段确定的项目计划、进度、成本和范围的各里程碑下对应输出物的一组固定版本。这一组固定版本就是当前节点的一条基线，它明确了当前节点各工作成果的状态，为接下来的开发提供了明确的项目开发状态信息。
19.错误（Error）
标准中对错误的定义是：计算、观测、测量的值或条件与真实、规定、理论上正确的值或条件之间的差异。
注：错误可能因未预见的工作条件、系统、子系统或组件的内部故障引起。
20.降级（Degradation）
标准中对降级的定义是：通过设计提供失效后的安全策略。
注：降级可以包含功能缩减、性能降低，或两者均降低。例如，跛行就是一种降级后的运行模式。
21.现场数据（Field Data）
标准中对现场数据的定义是：从相关项或要素的使用中获得的数据，包括累加的运行时间、所有的故障和服务中的异常。
注：现场数据通常是客户的使用数据。
22.预期功能（Intended Functionality）
标准中对预期功能的定义是：系统或要素在不包含安全机制时的行为规范。
解读 预期功能是指使系统正常运转的基本功能，满足产品预期使用的最小功能组合需求。例如，一把既能钉钉子又能拔钉子的锤子，其功能设计应包含锤头和钳子。
23.生命周期（Lifecycle）
标准中对生命周期的定义是：从概念到报废的全部阶段。功能安全产品开发生命周期中相关的管理活动如图1-12所示。
图1-12 功能安全产品开发生命周期中相关的管理活动
标准中还有其他专业术语，这里只挑选了笔者认为使用频率较高的术语进行说明。在后文中遇到其他术语时将随文进行说明。当然，本文未进行说明的术语同样重要，从业人员需要在实践中结合标准进行理解。
1.3.2节介绍了一些标准中常见的术语及其定义，本节将从消费者和政府期望、制造商和经销商的自我要求、电子控制单元（ECU）功能的多样性、软件复杂度、产品责任、民事责任，以及标准及法规要求这几个方面来讨论为什么需要功能安全。
1.消费者和政府期望
行业高质量发展的实践表明，任何一个行业的高质量发展都必须以人为本，汽车行业也不例外。在汽车科技高速发展的同时，将保护人的生命安全作为基本底线正是一种以人为本的体现。从社会角度来看，消费者和政府对产品的安全性都有极高的期望。谁都不愿意看到事故发生在自己身上，政府也有强烈的意愿来降低这方面的社会管理成本。
例如，现在新能源汽车的安全性是社会普遍关注的问题。消费者是产品的使用者，产品的安全性直接关系到消费者的人身安全。
2.制造商和经销商的自我要求
制造商（OEM）和经销商都希望能够制造和发布满足社会大众期望的产品。OEM应尽最大努力避免由于自身产品引发事故而招致社会的谴责以及名誉受损。
丰田“刹车门”事件给丰田带来了不小的影响，持续的诉讼及大规模召回不是一般车企能够承受的。
3.ECU功能的多样性
随着汽车电子技术的高速发展，整车ECU数量不断增加，ECU的功能也日益复杂，许多ECU都包含了安全相关的功能。
图1-13展示了日益复杂的汽车电子电气架构。
整车具备的功能越来越丰富多样，势必带来整车的电子电气架构越来越复杂，功能与功能之间的交互越来越密集，这些都将导致安全相关的功能越来越多、越来越复杂。涉及安全的模块越多、功能越复杂，产品发生失效的风险就越高，这是自然规律。那么，整车复杂度增加实际会带来什么隐患呢？
图1-13 日益复杂的汽车电子电气架构
整车复杂度越来越高可能导致的结果如下。
❑车辆的可靠性和可用性显著下降。
❑因电子电气设备失效引发的车辆故障增多。
❑大量的车辆召回。
❑重大的个人伤害事件增加。
❑功能安全性降低。
4.软件复杂度
汽车电子电气架构中软件组件的占比越来越大，软件开发的复杂度也越来越高，而且这些软件组件中大部分都包含了安全相关的功能。
无人驾驶汽车是智能汽车的终极模式，是汽车技术发展的集大成者。传统汽车需要满足的要求，无人驾驶汽车自然也需要满足，而且无人驾驶汽车还需要具备传统汽车不具备的功能。在安全方面，无人驾驶汽车不仅需要考虑功能安全，还需要考虑其他安全。这些需求无疑会导致软件复杂度呈指数级增长，无人驾驶汽车系统中上亿行代码的软件复杂度使得系统的安全问题极具挑战性。
5.产品责任
德国法律《产品安全法》是一部关于产品安全的联邦法律。该法规于2011年6月1日生效，旨在确保在德国市场上销售的产品具有安全性和合规性。该法规适用于在德国市场上销售的所有产品，包括进口产品。该法规要求产品在设计、制造、销售和使用过程中，必须确保用户的人身安全和健康。此外，该法规还规定了制造商、进口商和经销商的责任和义务，以确保产品安全。
经销商和制造商在生产、销售产品过程中有责任证明自己遵循相关的标准和法规，以确保产品在制造和流通环节的安全。
6.民事责任
在故意或重大过失情况下造成的损害，责任主体应承担赔偿责任。
Q：怎样算故意或重大过失？
有明确的标准要求却不按照标准执行，无视标准的存在，明知有缺陷却不考虑解决或改善，或不进行完善的分析、审核等措施去发现潜在的问题，如果在产品开发过程中没有过程证据证明自己遵守了相关标准、法规要求并“尽心尽力”，那都可以视为故意或重大过失。
7.标准及法规要求
IEC 61508或ISO 26262等功能安全标准中有详细的功能安全要求，一些法规对产品功能安全开发有隐含要求，比如R131对于AEBS（自动紧急制动系统）的规定其实就隐含了按照功能安全标准要求开发AEBS能够很好地提供相关证据/声明，以证明该法规在安全方面规定的技术要求的符合性。
标准要求功能安全开发过程中需采用最先进的技术（State of Art），这意味着产品在开发和生产的各个环节均需采用行业认可的当前最先进技术或工艺，以确保产品的各项特性达到前沿的水平。
关于实施功能安全开发的隐含要求可归纳为图1-14所示的几类。
图1-14 功能安全开发的隐含要求
本节将简要介绍ISO 26262标准总体内容框架、标准内容中的一些基本要点，让大家在脑海中形成对该标准的整体印象。
ISO 26262标准总体内容框架如图1-15所示。
图1-15 ISO 26262标准总体内容框架
该内容框架实际上包含了产品功能安全的开发模型，而安全生命周期就蕴藏在这一开发模型中。
ISO 26262标准定义了V模型开发流程，每个阶段的活动都有明确的定义。工作成果展示了V模型各阶段活动的输出。
ISO 26262描述了具体的工作成果，例如安全计划、安全案例/档案、相关项定义、功能安全概念、技术安全概念、硬件/软件接口规范、FMEDA报告、认可措施报告等。
ISO 26262标准除了要求在开发过程中提供一些直接活动的输出物外，还要求对开发过程进行大量的验证。
ISO 26262要求应用汽车行业的一些已知技术和方法，例如审查、FMEA、FTA、硬件在环测试等。
ISO 26262不要求必须使用特定的硬件或软件架构（而IEC 61508则有此要求），但提供了一些明确的架构度量指标，例如硬件度量指标（包括SPFM、LFM、PMHF）、软件度量指标（包括测试覆盖率）。
在进行架构设计的过程中，ISO 26262标准推荐参考行业的一些优秀实践，例如E-GAS三层电子架构。在动力域相关的控制器系统中，可以大量参考E-GAS架构设计。不过，并非所有产品的架构设计都必须按E-GAS三层电子架构进行设计，还须结合相关项目的自身特性来考量。
本节将对ISO 26262标准的整体框架进行详细解析，逐一分析各部分的具体涵盖内容及输出要求。
1.3.5.1 关于标准中各种表格的标记
首先来了解标准中的一些通用知识，比如在标准中经常可以看到类似表1-4的表格。
对于表格中的数字、数字+字母、“+”等符号，标准的解释如下。
1，2，3…：强烈推荐或推荐的方法，按照ASIL等级推荐使用。强烈推荐或推荐的方法允许用未列入表中的其他方法替代，此种情况下，应提供满足相关要求的理由。
1a，2a，2b…：这些方法是可选的，应按照指定的ASIL等级进行适当的组合。
每种方法的推荐等级取决于ASIL等级，分类如下。
❑“++”表示对于指定的ASIL等级，强烈推荐采用该方法。
❑“+”表示对于指定的ASIL等级，推荐采用该方法。
❑“o”表示对于指定的ASIL等级，不推荐也不反对采用该方法。
如果有可选方法，优先选择“++”而不是“+”的方法，并说明所选方法组合符合相应要求的原因。
表1-4 标准表格中符号示例
解读 “++”标识的方法，不论是否在1a、1b、2a等可选项中，都需要根据对应的ASIL等级进行执行。
1.3.5.2 第1部分术语
本部分收录了ISO 26262标准中所有的专业术语，共185个词条。这些术语对于理解标准起到基础性作用，犹如数学里的公式和定理一样。
1.3.5.3 第2部分功能安全管理
第2部分在标准总体框架中的内容视图如图1-16所示。
图1-16 第2部分在标准总体框架中的内容视图
第2部分相关的关键输出物如图1-17所示。
图1-17 第2部分相关的关键输出物
这部分关于功能安全管理的要求主要包括以下内容。
❑独立于项目的要求，例如公司层面的管理要求；项目开发过程中的要求；生产发布后的要求。
❑针对整个生命周期及其裁剪、安全文化、能力管理、质量管理、角色、责任、安全档案、认可措施、功能安全评估的要求。
1.3.5.4 第3部分概念阶段
第3部分在标准总体框架中的内容视图如图1-18所示。
图1-18 第3部分视图
第3部分相关的关键输出物如图1-19所示。
图1-19 第3部分相关的关键输出物
1.第3部分与第8部分的关联
第3部分与第8部分的关联如图1-20所示。
图1-20 第3部分与第8部分的关联
2.概念阶段之HARA
HARA方法用于识别每个危害事件并针对其确定ASIL等级，然后将ASIL等级分配给对应的安全目标。
ASIL等级评价见表1-5。
表1-5 ASIL等级评价
（续）
Q：表中为什么没有S0、E0、C0？
1.3.5.5 第4部分产品开发：系统层面
第4部分在标准总体框架中的内容视图如图1-21所示。
图1-21 第4部分视图
第4部分相关的关键输出物如图1-22所示。
图1-22 第4部分相关的关键输出物
第4部分与第8、第9部分的关联参见图1-23。
图1-23 第4部分与第8、第9部分的关联
解读 安全要求管理、验证和安全分析贯穿整个功能安全开发生命周期。
1.3.5.6 第5部分产品开发：硬件层面
第5部分在标准总体框架中的内容视图如图1-24所示。
图1-24 第5部分视图
第5部分相关的关键输出物如图1-25所示。
图1-25 第5部分相关的关键输出物
1.硬件层面之硬件架构度量
硬件部分一个非常重要的输出物是FMEDA分析报告，用于定量评估硬件架构的失效率是否满足对应ASIL等级的度量指标要求。硬件架构度量指标包含SPFM（单点故障度量）、LFM（潜在故障度量）、PMHF（随机硬件故障度量）。
这三个指标的计算方法参见图1-26，具体详见标准的第5部分。
2.第5部分与第8、第9部分的关联
第5部分与第8、第9部分的关联参见图1-27。
1.3.5.7 第6部分产品开发：软件层面
第6部分在标准总体框架中的内容视图如图1-28所示。
标准提到需要对软件开发流程和开发环境进行描述，并输出软件开发环境文档，这项活动对于软件开发来讲是一项通用性质的基础活动，为接下来如何展开软件设计和开发活动提供指引和说明，因此该活动并未体现在图1-28中。
第6部分相关的关键输出物如图1-29所示。
图1-26 硬件架构度量计算总览
图1-27 第5部分与第8、第9部分的关联
图1-28 第6部分视图
图1-29 第6部分相关的关键输出物
第6部分与第8、第9部分的关联如图1-30所示。
图1-30 第6部分与第8、第9部分的关联
1.3.5.8 第7部分生产、运营、服务和报废
第7部分在标准总体框架中的内容视图如图1-31所示。
图1-31 第7部分视图
第7部分相关的关键输出物如图1-32所示。
图1-32 第7部分相关的关键输出物
解读 功能安全在生产和运维阶段可以通过质量管理体系（IATF 16949）来支持。安全相关的需求需额外提出并体现在生产、控制计划中，确保生产过程中的安全需求得到实现。
1.3.5.9 第8部分支持过程
第8部分在标准总体框架中的内容视图如图1-33所示。
图1-33 第8部分视图
从第8部分的框架视图可以看出，支持过程贯穿整个功能安全开发生命周期。
第8部分相关的关键输出物如图1-34所示。
图1-34 第8部分相关的关键输出物
图中提到的DIA这一输出物从形式上讲并不是ISO 26262所独有的。事实上，对于分布式开发的非功能安全项目，也可以定义一份类似的、明确双方开发责任的说明文件。具体名称可以根据各个组织的流程进行自定义。
1.3.5.10 第9部分以ASIL等级和以安全为导向的分析
第9部分在标准总体框架中的内容视图如图1-35所示。
图1-35 第9部分视图
从第9部分的内容视图可以看出，安全分析贯穿整个功能安全开发生命周期。
第9部分相关的关键输出物如图1-36所示。
图1-36 第9部分相关的关键输出物
相关失效分析在第15章有专门讲解，这里不再赘述。
1.关于ASIL等级分解要求
ASIL等级分解成功与否的标准是分解后的需求和功能是否满足相互独立性要求，而这需要通过实施DFA（相关失效分析）来证明。图1-37提供了一个简要的ASIL等级分解示例，作为ASIL等级分解原则的示意性说明。
图1-37 ASIL等级分解示例
关于ASIL等级分解的方法和原则将在第16章详细介绍。
2.要素共存的准则
分解后的要求将分配给不同的要素，这些要素能否“和谐共处”需要通过DFA来验证，如图1-38所示。
图1-38 要素共存验证
要素是否共存可通过DFA来证明，即识别出要素间的共因失效和级联失效，并分析这些失效是否有对应的控制措施，从而证明要素间的独立性。
3.安全分析
标准重点推荐了两种分析方法，分别是归纳分析和演绎分析。归纳分析的典型代表是FMEA，而演绎分析的典型代表是FTA，两种分析方法相辅相成，各有所长。两种分析方法将在后面结合实际案例进行分享。
Q：安全分析的目的是什么？由谁来执行安全分析？非功能安全开发也会用FMEA，与功能安全开发中的FMEA有什么不同？
从上述各部分与第9部分的关联关系可以看出，安全分析是一项贯穿产品整个生命周期的活动，从概念阶段到报废阶段，都可以应用相关分析技术来提供活动实施依据。安全分析与其他活动之间的关系可参考图1-39。
图1-39 安全分析与其他活动之间的关系
Q：回想一下你在项目过程中是否进行过安全分析？你的安全分析做到位了吗？你所做的安全分析是否真正落到了实处？
总结来说，ISO 26262的12个部分主要包括以下内容。
❑提供术语和定义。
❑提供汽车安全生命周期的定义及需要满足的流程。
❑支持在此安全周期内的裁剪活动。
❑为确定风险等级提供一种基于风险的汽车专用方法。
❑提供开发、验证、安全确认和认可措施以及文档化的要求。
❑提供包含所有开发过程（概念、系统、硬件、软件）的活动的要求和指引。
❑提供安全分析的方法、示例及要求。
❑提供半导体功能安全开发流程和设计要求。
关于标准第11部分半导体的功能安全开发的相关要求将在9.5节介绍芯片的功能安全架构设计时进行简要的介绍。标准第12部分是关于摩托车的功能安全相关要求，本书不展开介绍。
到这里，ISO 26262标准的概述就告一段落了。光从整个概述来看，功能安全开发涉及很多文档输出工作，但这只是“理论指导实践”的“理论”部分。标准不仅要求产品全生命周期各个过程的活动都要有明确的规范及定义，还要求根据这些规范及定义来实施对应层级的开发实现，这是“实践”。此外，我们还需要通过占据V模型“半壁江山”的验证环节对各层级的设计、开发成果进行验证和确认，每一个过程都要有对应的文档输出，通过过程把控结果，通过结果反向验证过程，如此迭代。
最终在达成功能安全目标的同时，不仅积累了组织的“技术资产”，还让组织人员养成了良好的工程习惯。这种长期获益才是实施功能安全的要义。浮在空中并非功能安全的本意，落地才是。