道路车辆功能安全- - ISO26262 标准
ISO26262- -1 1 适用范围和主要内容
ISO26262 是 IEC61508 对 E/E 系统在道路车辆方面的功能安全要求的具体应用。它适用于所有提供安全相关功能的电力、电子和软件元素等组成的安全相关系统在整个生命周期内的所有活动。
安全在将来的汽车研发中是关键要素之一，新的功能不仅用于辅助驾驶，也应用于车辆的动态控制和涉及到安全工程领域的主动安全系统。将来，这些功能的研发和集成必将加强安全系统研发过程的需求，同时，也为满足所有预期的安全目的提供证据。
随着系统复杂性的提高，软件和机电设备的应用，来自系统失效和随机硬件失效的风险也日益增加，ISO26262，包括其导则，都为避免这些风险提供了可行性的要求和流程。
系统安全可以从大量的安全措施中获得，包括各种技术的应用（如：机械，液压，气动，电力，电子，可编程电子元件）。尽管 ISO26262 是相关与 E/E 系统的，但它仍然提供了基于其他相关技术的安全相关系统的框架。
ISO26262：
-提供了汽车生命周期（管理，研发，生产，运行，服务，拆解）和生命周期中必要的改装活动。
-提供了决定风险等级的具体风险评估方法（汽车安全综合等级，ASILs） -使用 ASILs方法来确定获得可接受的残余风险的必要安全要求。 -提供了确保获得足够的和可接受的安全等级的有效性和确定性措施。
功能安全受研发过程（包括具体要求，设计，执行，整合，验证，有效性和配置），生产过程和服务流程以及管理流程的影响。
安全事件总是和通常的功能和质量相关的研发活动及产品伴随在一起。ISO26262 强调了研发活动和产品的安全相关方面。
ISO 26262 主要用于安装在最大毛重不超过 3.5 吨的乘用车上的一个或多个 E/E 系统的安全相关系统。ISO26262 唯一不适用于为残疾人设计的特殊目的车辆的 E/E 系统。系统研发早于 ISO26262 出版日期的，也不在标准的要求之内。ISO26262 表述了由 E/E 安全相关系统，包括这些系统的互相影响，故障导致的可能的危险行为，不包括电击，火灾，热，辐射，有毒物质，可燃物质，反应物质，腐蚀性物质，能量释放及类似的危险，除非这些危险是由于 E/E 安全相关系统故障导致的。
ISO26262 对 E/E 系统的标称性能没有要求，对这些系统的功能性性能标准也没有什么要求（例如：主被动安全系统，刹车系统，ACC 等）
ISO26262-2 功能安全管理
ISO26262 是 IEC61508 对 E/E 系统在道路车辆方面的功能安全要求的具体应用。它适用于所有提供安全相关功能的电力、电子和软件元素等组成的安全相关系统在整个生命周期内的所有活动。
那么，为什么遵照 ISO26262 就能设计出符合功能安全要求的产品呢？ISO26262 是通过什么方式来保证产品能够符合功能安全的要求的呢？下面我们就来具体看看 ISO26262 在产品研发上的具体思路。ISO26262 系列标准分为 10 本，从 ISO26262-1 到 ISO26262-10，分别从功能安全管理，概念，系统级研发，软硬件的研发，生产和操作等方面对产品的整个生命周期进行了规范和要求。从而使得产品在各个生命周期都比较完善的考虑了其安全功能。
一个好的产品，要靠一整套好的管理体系来实现，并可靠的生产出来。ISO26262 给出了一套这样的管理方法、流程、技术手段和验证方法，称之为安全管理生命周期，框架如下:
图 1 项目安全生命周期
那么各部分又有什么具体含义和措施呢？下面就来分别说明：
1、 项目定义：
项目定义，是对所研发项目的一个描述，是安全生命周期的初始化任务，其包括了项目的功能，接口，环境条件，法规要求，危险等内容，也包括项目的其他相关功能，系统和组件决定的接口和边界条件等。
2、 安全生命周期的初始化
基于项目定义，安全生命周期要对项目进行区分，确定是新产品研发，还是既有产品更改。如果是既有产品更改，影响分析的结果可以用来进行安全生命周期的拼接。
3、 危险分析和风险评估
安全生命周期初始化之后，就要按照 ISO26262-3 的第七条款来进行危险分析和风险评估，危险分析和风险评估的流程要考虑暴露的可能性，可控性和严重性，以便确定项目的 ASIL 等级。接下来就是为每一个风险设立安全目标，并确定合适的 ASIL 等级。
4、 功能安全概念
基于安全目标，功能安全概念就要考虑具体的基本架构。功能安全概念就是对定位到每个项目元素中的功能安全要求的具体化和细化。超出边界条件的系统和其他技术可以作为功能安全概念的一部分来考虑。对其他技术的应用和外部措施的要求不在 ISO26262 考虑的范围之内。
5、 系统级产品研发
有了具体的功能安全概念之后，接下来就是按照 ISO26262-4 的系统级研发了。系统级研发的过程基于技术安全要求规范的 V 模型。左边的分支都是系统设计和测试，右边的分支是集成，验证，确认和功能安全评估。
6、 硬件级产品研发
基于系统的设计规范，硬件级的产品研发要遵循 ISO26262-5 的要求。硬件研发流程应符合 V 模型概念左侧分支的硬件设计和硬件要求。硬件的集成和验证在右侧分支。
7、 软件级产品研发
基于系统的设计规范，软件级的产品研发应遵循 ISO26262-6 的要求。软件研发
流程应符合 V 模型概念中左侧分支的软件需求规范和软件设计架构设计的要求。
软件安全需求中的软件集成和验证在右侧分支中。
8、 生产计划和操作计划
其包括：生产和操作计划，相关的需求规范，系统级产品研发的开始等。
ISO26262-7 的第 5 条款和第 6 条款给出了生产和操作的具体要求。
9、 产品发布
产品发布是产品研发的最后一个子阶段，该项目也将完成，具体要求在ISO26262-4 的第 11 条款中。
10、 产品的操作、服务和拆解
产品的操作、服务和拆解应符合 ISO26262-7 的第 5 条款和第 6 条款中，对产品的生产、操作、服务和拆解的相关要求。
11、 可控性
在危险分析和风险评估中，要考虑司机和处于危险中的其他人可以采取措施来控制危险情况的能力。如何提供对可控性的有效性证明不在 ISO26262 的范围之内。
12、 外部措施
参考项目以外的，在项目定义中被描述的措施（参加 ISO26262-3 的第 5 条款），以便减小项目的危险结果。外部危险降低措施不但可以包括附加的车载设备，如：动态稳定控制器防爆轮胎等，也可以包括非车载装置，如：护栏，隧道消防系统等。这些外部措施在进行危险分析和风险评估的时候应该被考虑到，但如何为这些外部措施的有效性提供证明不在 ISO26262 的范围之内，除非是 E/E设备。但要注意的是，没有明确安全例证的外部措施是不完整的。
13、 其他技术
其他技术是指那些不在 ISO26262 范围之内的，不同于 E/E 技术的设备。如：机械和液压技术。这些都要在功能安全概念的规范中加以考虑或者在制定安全要求时加以考虑。
通过以上这些具体的生命周期的各个阶段和标准中对每个阶段所必须考虑的措施、方法和具体技术的要求，将各个阶段的要求和如何满足要求的措施都进行逐一落实，这样才能设计出、制造出满足功能安全要求的安全产品。
5.4.2 安全文化
7 组织应建立，执行和维持一个持续改进的过程，基于在：
1）从其他项目的安全生命周期执行过程中学习的经验的，包括 现场经验；
2）在以后的项目中的改进应用
ISO26262-3 概念阶段
我们来具体看一下在概念阶段，ISO26262-3 对于项目定义、安全生命周期初始化和危险分析和风险评估的定义和要求。
5 、 项目定义
首先是项目定义阶段。项目定义，也就是对要进行研发的产品进行一个定义，进行一个描述。主要有两个目的：一个是定义和描述项目；一个是对项目有一个足够的理解，以便能够很好的完成安全生命周期中定义的每一个活动。基于以上目的，要对项目进行明确、准确、正确的定义，就需要获得一些基本信息，ISO26262 中给出了一些建议如下：
1、项目信息：
a） 项目的目的和功能
b） 项目的非功能性要求，如操作要求、环境限制等
c） 法规要求（特别是法律和法规），已知的国家和国际标准等
d） 类似功能、系统或元素达到的行为
e） 对项目预期行为的构想
f） 已知的失效模式和风险在内的项目缺陷造成的潜在影响
2、项目的边界条件以及相关项目之间的接口条件：
a） 项目的所有元素
b） 项目对其他项目或项目环境元素的相关影响
c） 其他项目，元素和环境对本项目的要求
d） 在系统或者包含的元素中，对功能的定位和分配
e） 影响项目功能时，项目的运行情况
有了以上这些基本的信息，就可以对要进行的项目给出一个比较明确和具体的项目定义，明确项目的要求，从而使得对项目有一个足够的理解，能够指导后续工作，来很好的完成安全生命周期中定义的每一个活动。
6 6 、 项目的安全生命周期
那么，有了项目定义之后，就要确定项目的安全生命周期，对项目的安全生命周期进行初始化，也就是开始对项目的安全生命周期进行细化。而要进行细化，就要区分是项目是新产品研发还是既有产品的改造。如果是全新的设备研发，则相关工作就得从安全生命周期的开始做起，项目定义之后就是项目危险分析和风险评估。
如果是既有产品的改造，那么从项目定义开始的这些流程都可以使用一些既有的文件对整个过程进行定制。现有产品升级改造，就要注意以下一些问题：
1．要做一个产品和使用环境的分析，以制定出预期更改，并评估这些更改产生的影响。
a) 对项目的更改包括设计更改和执行更改。设计更改应该是由需求规范、功 能和性能的增加或者成本的优化所致，执行更改不能影响项目的规格和性能，但可以影响执行特征。执行更改可以由软故障更改，使用新的研发成果或生产工具所致。
b) 如果配置数据和校准数据的更改会影响到产品的行为，则更改须考虑这些 数据。
c) 对产品环境的更改应该是由产品要使用的新的目标环境或由于其他相关产 品或元素升级而引发。
2．要表述清楚产品使用的前后条件的差别，包括：
a) 操作条件和操作模式
b) 环境接口
c) 安装特征，如：在车辆内部的位置，车辆的配置和变化等
d) 环境条件的范围，如：温度，海拔，湿度，震动，EMC 和汽油标号等。
3．要明确给出产品变更的描述以及影响的范围。如果不能明确产品的变更和对环境数据影响的改变，则相关影响的分析数据都要进行记录。
4．影响到的服役产品，需要进行升级的，要进行逐一列出。
5．定制的相关安全活动应符合各个应用生命周期阶段的要求，包括：
a) 定制应基于影响分析的结果。
b) 定制的结果应包括在符合 ISO26262-2 的安全计划中。
c) 影响到的产品须返工，包括确认计划和验证计划。
确定了以上这些基本信息之后，对所要进行的产品研发或者设备更改工作就有了一个清晰明确的定义，对产品的预期使用功能、环境，以及与相关设备的接口也有了一个明确的定义，接下来就可以进行危险分析和风险评估了。
7 7 、 项目的危险分析和风险评估
在概念阶段，ISO26262-3 给出了对危险分析和风险评估的要求。危险分析和风险评估的目的和之前的 ISO13849,IEC62061 等的标准一样，都是为了将设备存在的危险识别出来，并根据危险的程度按照一定的原则对其进行分类，从而针对不同的风险设定具体的安全目标，并最终减小或消除风险，避免未知风险的发生。
也正是因为这样，危险分析、风险评估和 ASIL 等级的确定只是和避免风险有关的安全目标相关。通过对危险情况的系统评估，考虑引发危险的影响因素——伤害的严重性，暴露于危险中的可能性和危险的可控性，来确定安全目标和 ASIL 等级。而这三个指标都是针对产品的功能行为的，所以做危险分析和风险评估时，并不一定先要知道设计细节。
无内部安全机制的项目应在危险分析和风险评估过程中进行评估，拟实施或在以前的项目中已经实施的安全机制不在危险分析和风险评估考虑。在一个项目中，提供充分独立的外部评估措施是非常有效的。例如，如果有足够独立的证据证明，电子稳定控制系统可以通过增加控制来减少在底盘系统的故障影响。此举的目的是证明要实施或已经实施的项目的安全机制成立为功能安全概念的一部分危险分析和风险评估的第一步是情形分析和危险识别，即通过相关的情况分析将产品存在的风险识别出来。这就要考虑可能引发危险的操作环境和操作模式，并且要考虑在正确使用时和可预见的误使用时的情况。基于这样的考虑，我们应该通过大量的技术来系统分析，
注意以下一些方面：
1. 准备一个用来进行评估的操作情况清单
2. 系统的确定清单上的危险。主要可以通过诸如：头脑风暴，检查列表，历史记录，FMEA，产品矩阵，以及相关的领域研究等技术手段进行。
3. 风险应该用在车辆上可以被观察到的条件或影响来进行定义或描述
4. 在相关操作条件和操作模式下危险事件的影响应该被明确说明。如：车辆电源系统故障可能导致丧失引擎动力，丧失转向的电动助力以及前大灯照明。
5. 如果在风险识别中识别出的风险超出了 ISO26262 的要求范围，则需给出合适的相应措施。当然，超出 ISO26262 的风险可以不必分类分级。完成风险的识别之后，就要对这些风险进行适当的分级，以便设定相应的安全目标，并按照不同的风险等级来采取合理的措施加以避免。
风险的分类主要是通过 3 个指标来考量，即：危险发生时导致的伤害的严重性、在操作条件下暴露于危险当中的可能性（危险所在工况的发生概率）、危险的可控性。
首先，来看伤害的严重性。这里的伤害是指危险事件发生时，对所有被卷入事件中的人的伤害，包括车上的司机和乘客，骑自行车的人，行人，其他车辆上的人员。伤害的严重性可以分为 4 个等级，即：S0，S1，S2，S3（对于伤害严重性的详细描述可以参考 ISO26262-3中附录 B 的内容，这里只做分级说明）。如下表：
其次，来看在操作条件下暴露于危险中的可能性。可能性被分为 5 个等级，即：E0，E1，E2，E3，E4，具体分级见下表。
至于暴露值是选 E1 还是选 E2，主要看车辆在目标市场正常、合理的使用情况。这里要注意的是，评估暴露于危险中的可能性并不考虑在车上安装了多少个要评估的产品，且假设了所有的车上都安装了这个产品。对于那种认为不是每辆车都安装的产品，其相应的暴露在危险中的可能性会减小的说法也是错误的。
这里，E0 只用于在风险分析中一些建议性的情况，通常如果一个危险，人员暴露其中的可能性是 E0 级，则无需考虑 ASIL 等级。
再次，来看可控性。即危险事件能被司机或者其他交通参与人员进行控制并减小或者避免伤害的可能性。在 ISO26262 中，可控性被分为 4 个等级，即：C0，C1，C2，C3。但要注意，使用这个分级的条件是司机处于正常状态，即：不疲劳，有驾照，按照交通规则行驶，
当然，其中要考虑可预见的误操作和误使用。四个级别为：
其中，C0 通常用于不影响车辆安全操作的情况。如果一个危险的可控性被评为 C0，则对其没有 ASIL 要求。
由此，根据以上的三个参数，即可确定风险分析中每个风险相应的 ASIL 等级（汽车安全完整性等级），具体确定方法如下表：
ASIL 等级分为 A、B、C、D 四个等级，ASIL A 是最低的安全等级，ASIL D 是最高的安全等级。除了这四个等级 QM 表示与安全无关。
在风险分析过程中，要确保对每个危险事件，根据 S、E、C 和具体的操作条件和模式确定的 ASIL 等级不低于其安全目标的要求。同时，相似的安全目标也可以合并为一个安全目标，但要达到的 ASIL 等级应该是合并项目中最高的。如果安全目标可以被分解到具体的状态中，那么每个安全目标也要转换成达到安全目标的具体安全状态下的具体要求。
安全目标及其属性（ASIL）应按照 ISO26262-8:2011，第 6 条款规定。
要注意的是，危险分析、风险评估和安全目标都要进行审核，以保证对条件和危险分析完整，符合项目定义，并与相关的危险分析和风险评估一致。
由此，完成概念阶段的危险分析和风险评估，形成减少和防止危险发生的安全目标，并通过验证审核。
8、功能安全概念
做完危险分析和风险评估之后，在概念阶段，ISO26262-3 还给出了功能安全概念这个阶段。其主要目的是通过前面的危险分析和风险评估之后得出的安全目标来确定具体的功能安全要求，并将它们分配到初步的设计架构，或者外部减少危险的措施当中去，以确保满足相关的功能安全要求。
为了符合功能安全目标，功能安全概念给出了一些基本的安全机制和安全措施，以便于功能安全要求被很好的分配到系统架构的元素中去。这些主要的机制和措施如下：
-故障检测和失效缓解措施
- 安全状态转换
- 故障容错机制。即：故障不会直接导致违背安全目标，或者保持系统出于安全状态
（降 级或者没有降级）
- 故障检测和为了将暴露时间减小到可接受的程度的司机警示装置
- 逻辑仲裁：不同功能触发的多任务请求应该通过逻辑仲裁来选择最合适的控制
基于以上这些机制和措施，再根据之前的项目定义、危险分析和风险评估、安全目标的设定，以及考虑来自外部的一些预想架构、功能、操作模式及系统状态等，就可以开始考虑将功能安全要求进行适当的分配，指定 ASIL 等级，并将其合理的分配到子系统当中了。安全目标和功能安全要求的层次结构如下表所示：
安全目标和功能安全要求的层次结构
图 安全要求结构
在功能安全概念中，ISO26262 从功能安全要求的来源和功能安全的分配两个方面给出了一些建议和要求，具体如下：
1. 功能安全要求的来源：
a) 功能安全要求应该从安全目标和安全状态来获得，并考虑预想架构、功能概念、
操作模式和系统状态等。
b) 要为每个安全目标设定至少一个功能安全要求。
c) 每个功能安全要求都要考虑以下内容：
i.操作模式
ii. 故障容错时间间隔
iii. 安全状态，过渡到安全状态是否符合设备要求
iv. 急停操作间隔
v. 功能冗余
这项活动可以通过安全分析（如 FMEA，FTA，HAZOP），以制定一套完整有效的功能性安全要求的支持。
d) 警示和降级
e) 如果安全状态不能通过立即关闭来达到，则需指定一个紧急操作。
i. 这些动作应该在功能安全概念中详细描述
ii. 驾驶员或者陷入危险中的人可以使用的手段或者控制要在功能安全概念中详细 描述
2. 功能安全要求的分配：
a)研发安全架构概念
b)功能安全要求分配
i. 功能安全要求的分配应该基于项目预想架构的元素进行。
ii. 分配过程中，ASIL 和功能安全要求考虑的内容信息都要继续传承。
iii. 如果多个功能安全要求被分配到同一个架构元素，则这个架构元素应以这些功 能安全要求的最高 ASIL 等级进行研发。
iv. 如果项目由超过一个的系统组成，则对于每个独立系统和他们的接口的功能安 全要求都要从考虑预想系统架构的功能安全要求中获得，而这些功能安全要求也都要被分配到系统中去。
v. 如果 ASIL 等级需要被拆解，则要符合 ISO26262-9 第五条款的要求。
vi. 如果安全要求被分配到其他技术的元素中，则无需考虑 ASIL 等级。
c)如果功能安全概念依赖于其他技术的元素，则应考虑以下环节：
i. 靠其他技术执行的功能安全要求应该从其相应的元素中获得并分配到元素中去。
ii. 明确与其他技术的接口的相关功能安全要求。
iii. 有其他技术执行的功能安全要求要确保有具体的措施。
d)依赖于外部风险降低措施的功能安全概念应满足如下要求：
i. 应用于外面风险降低措施的功能安全要求应该从相应的外部风险降低措施中获得并分配到其中去。
ii. 明确与外部风险降低措施的接口的功能安全要求
iii. 如果外部风险降低措施由 E/E 系统构成，则功能安全要求可以用 ISO26262来进 行评估。
iv. 必须确保由外部风险降低措施执行的功能安全要求的正确执行。
e)功能安全概念应该按照 ISO26262-8 第九条款的要求来验证与安全目标的一致性和符合性。
f) 项目安全确认的原则应该详细的写在功能安全概念中。
g)功能安全要求的审核应该阐明功能安全要求符合安全目标。
由此，按照流程完成以上的这些分析和审核之后，即完成了功能安全概念的阶段，最终会形成功能安全概念的结果，和通过审核的功能安全要求。
附录 A 概念阶段概述
附录 B 危险分析和风险评估
给出了危险分析和风险评估的一般解释对于这种分析方法，风险（R）可在危险事件被描述为一个函数（F），与危险事件的发生频率（f），即通过的人的及时反应避免特定的伤害或损害能力，损害或损伤的可控性（C），以及潜在的严重程度（S）有关。
R = F(f,C,S)
发生的频率 f 有以下几个因素确定，一个需要考虑的因素是危险事件的频繁度和在危险事件涉及的人数。在 ISO26262 中，这个的度量是简化成暴露于危险中的可能性（E）。另一个因素是，有可能导致危险事件（故障率，λ）的产品故障率，故障率的特点是硬件随机故障和系统性故障：
f = E.λ
危险分析和风险评估用来设置功能安全要求，这样项目风险是可以避免的。ASILs 等级导出的危害分析和风险评估确定出项目的功能安全要求最小集 合。
