下载文档原格式
ISO26262功能安全原理与实践1
首先是定义安全要求。
安全目标要求在意外情况下确保驾驶员、乘客和其他道路使用者的安全。
这些安全要求基于安全性能指标，比如最大不可接受失效率和最小故障间隔时间。
其次是确定安全措施。
安全措施是保证系统满足安全要求的措施，包括硬件和软件的措施。
硬件措施包括冗余设计、故障检测、安全监控等方法。
软件措施包括代码检测、故障处理、功能隔离等方法。
安全措施应根据功能安全的分级进行选择，高风险等级的系统需要更严格的措施。
然后是进行安全分析。
安全分析是在整个开发过程中进行的，旨在识别系统可能的安全风险。
安全分析可以采用多种方法，如系统安全性分析（SSA）和模式故障和影响分析（FMEA）。
通过安全分析可以确定相关的安全等级和安全目标。
iso26262功能安全评价方法【原创实用版2篇】目录（篇1）1.Iso26262 功能安全评价方法的背景和意义2.Iso26262 功能安全评价方法的具体内容3.Iso26262 功能安全评价方法的实施步骤4.Iso26262 功能安全评价方法的优势和应用5.Iso26262 功能安全评价方法的未来发展正文（篇1）一、Iso26262 功能安全评价方法的背景和意义Iso26262 功能安全评价方法是一种针对汽车电子系统功能安全的国际标准，它的出现是为了确保汽车电子系统在失效情况下能够按照预期方式进行故障处理，从而避免对人员和环境造成伤害。
随着汽车电子化程度的不断提高，功能安全日益受到重视，Iso26262 功能安全评价方法应运而生，成为了保证汽车安全的重要手段。
二、Iso26262 功能安全评价方法的具体内容Iso26262 功能安全评价方法主要包括以下几个方面：1.安全目标的定义：根据汽车电子系统的功能和失效模式，明确安全目标，确保系统在失效情况下能够按照预期方式进行故障处理。
2.危害分析：通过对汽车电子系统可能的失效模式进行分析，评估可能带来的风险和危害程度。
3.功能安全等级：根据危害分析结果，为汽车电子系统中的各个功能分配相应的安全等级。
4.安全要求和措施：针对不同安全等级的功能，制定相应的安全要求和措施，确保系统在失效情况下能够满足安全目标。
5.验证和评估：对汽车电子系统进行实际验证和评估，检查系统在失效情况下是否能够按照预期方式进行故障处理。
三、Iso26262 功能安全评价方法的实施步骤1.建立项目团队：由汽车制造商、零部件供应商、技术服务公司等相关方共同组成项目团队，明确各方职责和任务。
2.收集和分析相关信息：收集汽车电子系统的设计、制造、使用等方面的信息，进行系统分析和失效模式分析。
3.制定安全目标和功能安全等级：根据分析结果，制定安全目标和功能安全等级。
4.制定和实施安全要求和措施：针对不同安全等级的功能，制定相应的安全要求和措施，并确保在系统设计和制造过程中得到有效实施。
Q11. 功能安全这个概念的形成与发展？对中国汽车行业和企业而言，重要性何在？功能安全概念的形成起源于上个世纪。
19世纪70年代到80年代，在世界范围内，尤其是石油化工领域中一些大型项目的生产过程中，多次发生爆炸事故或者严重的污染物泄漏事情。
当时业内专家通过系列而系统的分析手段，明确了事故发生的主要原因是因为相关安全控制系统安全功能失效导致的，而造成这些失效的直接原因中，由于电子、电气、可编程逻辑控制器产品自身安全功能不完善导致系统失效的比重是非常大的。
为了提高电子、电气、可编程逻辑控制器产品的安全性能，从1989年开始，世界范围内的业内专家，对产品安全性设计技术非常重视，并且计划将电子、电气及可编程电子安全控制系统相关的技术发展为一套成熟的安全设计技术标准。
1993年，在包含TÜV SÜD技术专家的专家技术团队的不断努力下，诞生了DIN V VDE 0801标准。
之后随着更多业内专家的参与和积极努力，国际电工委员会终于在1998年的时候，正式颁布了IEC61508(功能安全基础标准)标准的第一版，并在2010年正式颁布了该标准的第二版。
到目前为止，除功能安全的基础标准IEC61508之外，其他相关领域的功能安全系列标准也已经颁布并得到大量的应用。
如专门针对过程控制行业的IEC61511标准，专门针对工厂自动化领域的IEC62061和ISO13849-1标准，专门针对铁路信号控制领域的EN5012X系列标准，专门针对核电领域的IEC61513标准…当然，这其中也包含针对道路车辆功能安全领域的专用标准ISO26262。
ISO26262是从电子、电气及可编程器件功能安全基本标准IEC61508派生出来的，ISO26262标准主要定位在汽车行业中特定的电气器件、电子设备、可编程电子器件等专门用于汽车控制领域的1部件和系统，它旨在提高汽车电子、电气产品功能安全性能。
另外此前路人皆知的“踏板门”、“刹车门”等事件，其实和功能安全都有很大的关联度。
做功能安全需要对ISO26262理解到什么程度？干这一行前景怎么样？写在最前面：作为一名功能安全工程师，刚从事这份工作时浏览这个问题还带着很多入门前的疑惑，如今再次浏览时，自认为可以根据自己的工作经验输出一些浅见了。
借着回答这个问题也希望能抛砖引玉，和各位前辈们做进一步探讨。
根据我的经验，探索某一事物的过程也是否定自己认知的过程，所以只能说现在的回答代表自己当前的理解，后续如果有新理解会更新这个答案本文试图回答以下问题：· 什么是功能安全？· 功能安全在企业怎么落地？· 功能安全工程师的工作内容· 入门时如何对待ISO 26262文档？· 功能安全工程师的前景文末有与作者沟通的渠道，欢迎和作者交流讨论。
01.什么是功能安全（Functional Safety）？在这里先引用ISO 26262和GB/T 34590中的定义，从定义展开强调几个关键词。
ISO 26262：absence of unreasonable risk due to hazards caused by malfunctioningbehavior of E/E systems.GB/T 34590：不存在由电子电气系统的功能异常表现引起的危害而导致不合理的风险。
1. “E/E system”，电子电器架构功能安全要讨论的对象是E/E架构设计，因此机械/液压/化学等设计都不在ISO 26262的研究范围。
2. “hazard”，危害危害有很多类型，如人身伤害或者财产损失等等。
功能安全里的危害仅仅指对驾驶员或者路人或周边车辆内人员（注意：不仅仅是驾驶员）造成的健康伤害。
换句话说，功能安全开发目的是避免伤人，而不是避免你的损伤你的豪车，也不是避免你的豪车被偷。
3. “unreasonable”，不合理的即“不可被接受的”。
就像世界上没有永动机一样,世界上也没有100%安全的系统,因此功能安全追求的是将危害控制在可被接受的范围。
功能安全FunctionalSafetyISO26262-1ISO 26262-1 词汇表ISO26262是基于IEC61508标准演化⽽来的⼀项标准，旨在满⾜道路车辆电⼦电⽓系统领域的特定需求。
这种改编适⽤于由电⼦电⽓元件和软件组件组成的安全系统的整个⽣命周期内的所有活动。
安全是未来汽车发展的关键问题之⼀。
⼀些新的功能，在驾驶员辅助、动⼒、车内动态控制和主动&被动安全系统等⽅⾯⽇益牵涉到越来越多的系统安全⼯程。
这些功能的开发和集成会增加对安全系统开发流程、并证明所有合理的系统安全⽬标都得到满⾜的证据的需求程度。
随着技术复杂度、软件内容和机电⼀体化程度的不断提⾼，系统失效和随机硬件失效的风险也越来越⼤。
ISO 26262会提供适当的要求和流程来避免这些风险。
系统安全是通过⼀系列安全措施来实现的，通过应⽤各种技术（例如机械、液压、⽓动、电⽓、电⼦、可编程电⼦），并在开发过程的各个层⾯上应⽤。
尽管ISO26262涉及到电⼦电⽓系统的功能安全，但是它也会提供其他系统常⽤安全技术的框架。
ISO26262可以：a)提供车辆安全⽣命周期的⽀持（管理、开发、⽣产、操作、服务、报废）；b)提供车辆专⽤的风险评估⽅法（ASIL，Automotive Safety Integrity Levels，汽车安全完整性等级）；c)使⽤ASIL评级提出可实施的功能安全需求，来避免不合理的剩余风险；d)向供应商提供功能安全需求。
功能安全受到开发流程（需求规范、设计、实现、集成、验证、确认和配置）、⽣产和服务流程、管理流程的影响。
安全问题与以功能为导向、以质量为导向的开发活动和⼯作产品交织在⼀起。
ISO 26262阐述了开发活动和⼯作产品等安全相关的内容。
1 名称解释：⽂档、标准或者经验。
1.3architecture：架构；代表相关项/功能/系统/元件的构造块及构造块的边界和接⼝，且相关的功能已经分配给了硬件/软件元件。
ISO26262中的安全分析：FMEA、FMEDA与FTAISO 26262中对“Functional Safety, 功能安全”的定义如下：Absence of unreasonable risk due to hazards caused by malfunctioning behavior of E/E systems.（不存在由电子电气系统的功能异常表现引起的危害而导致不合理的风险）而从本质上来讲，电子电器系统的功能异常表现由两类失效引起：•随机硬件失效(random hardware failure)：在硬件要素的生命周期中，非预期发生并服从概率分布的失效。
•系统性失效（systematic failure）：以确定的方式与某个原因相关的失效，只有对设计或生产流程、操作规程、文档或其他相关因素进行变更后才可能排除这种失效。
从这个角度，可以认为功能安全的目标就是将电子电器系统的随机硬件失效和系统性失效控制在合理的（或者说可接受的）范围内。
适当且充分的安全分析可以帮助功能安全开发更好地实现这一目标。
安全分析方法包含两类：•归纳分析（Inductive analysis）•演绎分析（Deductive analysis）ISO 26262标准中对这两类分析方法分别推荐了FMEA (Failure Mode and Effects Analysis)和FTA (Fault Tree Analysis)。
另一方面，ISO 26262中对功能安全开发的要求既有定性分析的要求，也有定量分析的要求。
当试图将这些要求与分析方法对应时存在着一些误解，认为FMEA只能用于定性分析，而FTA则只用于定量分析，其实不然。
作为两种被很多行业广泛使用的分析方法，FMEA和FTA均既能用于定量分析也能用于定性分析，只是不同行业会基于不同的目标加以筛选使用。
而实际上在功能安全开发过程中，FMEA和FTA的定量分析和定性分析均所有体现且发挥着不同的作用。
ISO26262电控开发流程概述摘要：功能安全（Functional Safety）的要求是无论零部件或者安全相关控制系统发生的失效是硬件随机失效还是系统失效，都需要使受控设备可靠地进入和维持安全状态，避免对人员或者环境产生危害；本文从电控开发流程角度触发，介绍功能安全流程的建立、要求及方法，并结合标准要求，给出完整的电控开发流程体系。
关键词：功能安全；电控单元；ASIL等级引言在过去近40年中，功能安全的理念和技术不断发展，已经在全球范围深入各个行业和领域，成为社会、行业、企业控制各种灾难性事故的有效措施。
ISO26262是欧洲多个知名主机厂及供应商共同讨论制定的，于2005年启动，2011年底发布，2018年发布第二版，加入商用车。
新版ISO26262标准为实现汽车电子系统全生命周期内的功能安全起到了至关重要的指导作用，但对新版标准的详细解读以及如何将其应用到实际的产品中，目前可供参考的应用案例还很少。
因此，以ISO26262新版标准作为指南，进行电控系统的产品开发，对于正确解读和应用ISO 26262 标准具有重大参考意义。
1 标准介绍2018版的ISO 26262 标准主要包括 12 个部分，其体系结构图如图 1所示[1、2]。
图1 ISO26262标准体系结构ISO26262标准的第一部分介绍相关术语；第二部分功能安全管理，定义了涉及安全相关系统开发的组织和人员应满足的要求，定义功能安全管理指南及安全计划，建立公司安全文化；第三部分概念阶段，主要是对危害分析和风险评估的描述，导出功能安全目标，确定功能安全相关概念，导出客户需求；第四部分为系统层面的产品开发，完成系统设计及安全分析，并按要求进行系统相关测试，导出系统需求，FMEA及FTA概念；第五部分为硬件层面的产品开发，确定基于ASIL等级的硬件安全指标，包含SPFM，LFM，PMHF指标，完成硬件安全分析及设计；第六部分为软件层面的产品开发，包含软件开发指南、软件需求、软件实现、软件验证计划、软件验证报告；第七部分为生产、运行、服务和报废过程中功能安全相关的要求和建议；第八部分为是对支持过程的归纳；第九部分为基于汽车安全完整性等级（ASIL）和安全的分析，明确ASIL等级的分配原则；第十部分为对整个ISO26262标准的应用导则。
ISO 26262-1 词汇表ISO26262是基于IEC61508标准演化而来的一项标准，旨在满足道路车辆电子电气系统领域的特定需求。
这种改编适用于由电子电气元件和软件组件组成的安全系统的整个生命周期内的所有活动。
安全是未来汽车发展的关键问题之一。
一些新的功能，在驾驶员辅助、动力、车内动态控制和主动&被动安全系统等方面日益牵涉到越来越多的系统安全工程。
这些功能的开发和集成会增加对安全系统开发流程、并证明所有合理的系统安全目标都得到满足的证据的需求程度。
随着技术复杂度、软件内容和机电一体化程度的不断提高，系统失效和随机硬件失效的风险也越来越大。
ISO 26262会提供适当的要求和流程来避免这些风险。
系统安全是通过一系列安全措施来实现的，通过应用各种技术（例如机械、液压、气动、电气、电子、可编程电子），并在开发过程的各个层面上应用。
尽管ISO26262涉及到电子电气系统的功能安全，但是它也会提供其他系统常用安全技术的框架。
ISO26262可以：a)提供车辆安全生命周期的支持（管理、开发、生产、操作、服务、报废）；b)提供车辆专用的风险评估方法（ASIL，Automotive Safety Integrity Levels，汽车安全完整性等级）；c)使用ASIL评级提出可实施的功能安全需求，来避免不合理的剩余风险；d)向供应商提供功能安全需求。
功能安全受到开发流程（需求规范、设计、实现、集成、验证、确认和配置）、生产和服务流程、管理流程的影响。
安全问题与以功能为导向、以质量为导向的开发活动和工作产品交织在一起。
ISO 26262阐述了开发活动和工作产品等安全相关的内容。
1 名称解释：1.1allocation：分配；将需求分配给架构级元件。
1.2anomaly：异常；指偏离期望的一些条件，这些条件包括需求、说明书、设计文档、用户文档、标准或者经验。
1.3architecture：架构；代表相关项/功能/系统/元件的构造块及构造块的边界和接口，且相关的功能已经分配给了硬件/软件元件。
1.4assessment：评估；是指对相关项/元件特征的考察。
1.5audit：审计；是实施过程的考察。
1.6ASIL：车辆安全完整性等级，Automotive Safety Integrity Level；是指ABCD四个等级中的一个等级，规定了相关项或元件的ISO26262需求和安全测量措施，来避免不合理剩余风险；其中，D代表最严格等级，A代表最不严格等级。
1.7ASIL decomposition：ASIL分解；指将安全需求冗余地分摊给那些足够独立的元件，目的是降低这些独立元件的冗余安全需求的ASIL等级。
1.8availability：有效性；假设所需的外部资源可用的条件下，在特定条件、特定时间或时期内，产品处于正在执行所需功能的状态的能力。
1.9baseline：基线；是指正处于配置管理中的某个或多个工作产品/相关项/元件的一个版本，并作为变更管理流程的一个基础用于进一步开发。
1.10branch coverage：分支覆盖；指控制流分支中，已被执行的百分比。
注1：100%的分支覆盖率意味着100%的软件已执行语句覆盖率（statement coverage）。
注2：if语句总有两个分支：条件true和条件false，因此这里的所谓“分支”并不是指if … else中的else这个语句。
1.11calibration data：标定数据；指软件开发过程中，在软件build之后需要匹配的数据或参数。
例：参数（parameter，例如低怠速值、发动机特性图）；车辆特定参数（vehicle specific parameters，一般是一种自适应值，通过自动标定算法实现，例如节气门限位器）；变体编码（variant coding，例如国家/地区代码、左舵/右舵）。
1.12candidate：候选项；指项目或元件的定义和使用条件与已发布的某个项目或元件一样或高度相似。
注：此定义适用于在经使用验证的背景中候选项的使用情况。
1.13cascading failure：级联失效；元件/相关项的失效导致其他元件或相同相关项的其他元件失效。
注：级联失效是一种非共因失效的相关失效。
1.14common cause failure：共因失效CCF；指某个单独特定的事件或根本原因导致的相关项的两个或多个元件失效。
注：CCF是一种非级联失效的相关失效。
1.15component：组件/零部件；指非系统级的元件，这些元件一般是因为在逻辑和技术可以从系统中分割出来，并由多个硬件或多个软件单元组成。
注：一个组件是一个系统的一部分。
1.16configuration data：配置数据；在软件build期间，分配并控制软件build过程的数据。
例：预处理器指令；软件build脚本（例如XML配置文件等构建脚本）。
注1：配置数据不能包括可执行代码或可判断代码；注2：配置数据控制软件的build（构建）。
只有配置数据选择的代码或数据能包括到可执行代码中。
1.17confirmation measure：确认措施；指对功能安全相关的确认审查（confirmation review）、审计（audit）、评估（assessment）。
1.18confirmation review：确认评审；确认工作产品符合ISO26262的要求，且参与的评审员具备所要求的独立性。
注1：ISO26262-2中会给出完整的评审清单；注2：审查的目的是为了保证评审项对于ISO26262的合规性。
1.19controllability：可控性；指通过相关人员的及时反应，来避免特定伤害/损害的能力；该能力可能需要外部措施的支持。
注1：所谓的相关人员，包括驾驶员、乘客或靠近车辆的外部人员；注2：危害分析和风险评估（HARA）中的参数C，代表了可控性的潜力。
1.20dedicated measure：专用措施；指确保违反安全目标的估计概率在声称的失效率范围内的措施。
例：设计功能点，如硬件的过度设计（额定电功率或额定热应力）和物理分离（例如印刷电路板上触点的间距）；对来料进行特殊抽样试验，降低因违反安全目标的失效模式的发生风险；老化测试；专用控制计划。
1.21degradation：退化；指失效发生后的安全设计策略。
注：退化可以是功能性的减少、性能的较少或功能性和性能的双重减少。
1.22dependent failures：相关失效；是指有一种失效，其同时或连续发生失效的概率不能表示为各自无条件概率的简单乘积。
注1：当A和B两个失效同时发生的概率P AB≠P A×P B时，A和B两个失效算做相关失效。
其中P AB指A和B两个失效同时发生的概率；P A指A发生失效的概率；P B指B发生失效的概率。
注2：相关失效包括共因失效和级联失效。
1.23detected fault：检出故障；在规定时间内，由防止潜伏故障发生的安全机制检测到的故障，叫做检出故障。
例：检出故障可由功能安全概念中定义的专用安全机制来检测。
这种安全机制包括：检测出错误后，通过仪表板上的报警装置通知驾驶员。
1.24development interface agreement：开发接口协议；表示客户和供应商之间的协议，规定了各方交换活动、证据或工作产品的责任。
1.25diagnostic coverage：诊断覆盖率；指安全机制所检测或控制的硬件元器件失效的比例。
注1：诊断覆盖率可以根据残余故障或硬件元器件中可能出现的潜在多点故障来评估；注2：定义见ISO26262-5给出的方程表示；注3：可考虑在架构的不同层级实现安全机制。
1.26diagnostic test interval：诊断测试间隔；安全机制执行在线诊断测试的时间间隔。
1.27distributed development：分布式开发；在客户和供应商之间为整个相关项或元件或子系统划分开发责任，来进行相关项或元件的开发工作。
注：客户和供应商是合作方的角色。
1.28diversity：多样性；指以独立性为目标，满足相同需求的不同解决方案。
例：多样的程序设计；多样化的硬件。
注：多样性并不能保证独立性，但可以解决某些类型的共因失效。
1.29dual-point failure：双点失效；两个独立故障共同导致违反安全目标的故障的发生。
注1：双点故障是二阶多点故障；注2：ISO26262中所述的双点失效包括一个影响安全相关元件的故障，一个影响相应的安全机制以达到或保持安全状态的故障。
注3：对于直接违反安全目标的双点失效，需要两个独立故障的存在，例如，因残余故障与安全故障的组合而违反安全目标的故障就不属于双点故障，因为残余故障不算第二个独立故障，无论该故障是否导致了违反安全目标的情况发生。
1.30dual-point fault：双点故障；两个独立的单个故障共同导致的故障，叫做双点故障。
注1：只有识别出双点失效后，才能识别出双点故障，例如故障树中的割集分析；注2：见多点故障。
1.31electrical and/or electronic system，电子电气系统，E/E system；即由电子和/或电气元件组成的系统，包括可编程电子元件。
例：电源；传感器或其他输入设备；通信路径；执行器或其他输出设备。
1.32element：元件；系统或系统的一些组成部件，包括组件、硬件、软件、硬件部件和软件单元。
1.33embedded software：嵌入式软件；在处理元件中执行的完全集成的软件。
注：处理元件一般是一个MCU、FPGA或ASIC，但也可能是一个更复杂的零部件或子系统。
（PS：比如SOC片上系统？）1.34emergency operation：应急操作；就是降级的功能，从故障发生时的状态开始，转变到预警和降级概念的安全状态。
1.35emergency operation interval：应急操作间隔；指需要应急操作来支持预警和降级概念的时间跨度。
注：应急操作是预警和降级概念的一部分。
1.36error：错误；计算、观察或测量的值或条件，与真实、规定或理论上正确的值或条件之间的差异。
注1：错误的发生，可能是由于不可预见的操作条件，或由于系统、子系统或零部件的1.44fault reaction time：故障响应时间；从检测出故障到安全状态的时间跨度。
1.45fault tolerant time interval：容错时间间隔；发生危害事件之前，系统可能存在一个或多个故障的时间跨度。
1.46field data：现场数据；指从相关项或元件使用过程中获得的数据，包括累计运行时间、所有的失效记录以及运行中的运行情况记录。
