前言

汽车行业里有很多两轮车可以借鉴和学习的知识和经验方法。虽然有些需要做适度的调整，但汽车行业的积累确实非常的好。ISO 26262就是一个例子，当汽车的电子功能器件增多时，这个标准提供了在功能安全上很有力的支持，比如ASIL等级，以至于摩托车也得以沿袭（MSIL）。最近看了以下关于ISO 26262的标准，以及对应的书籍。记录以下笔记。

ISO26262是一个国际标准。它不做组织流程和方法的要求，它所要求的是能够实现功能安全的一个战略性的要求，包括组织内部评估产品的功能安全是否能够实现，以及评估结果的沟通方法指引。除了面向实际产品外，此标准还要求要对产品开发的过程进行评估，采用标准化流程以及标准的衔接方式以确保可靠性的目标。

与ISO26262相关联的标准，比如汽车行业的TS16949，SPICE构架或CMMI流程。它们与26262不同，它们为实现质量和质量改进提供了一个好的基础和流程框架，通过它们可以支持和改进相关项目所需的安全性，但具体应该做到怎样的安全性程度，并没有在这些标准中有具体的规定。

ISO26262中的一些基本的要求：

根据ISO26262 B.1表格制定安全文化问卷，包含安全文化指标。组织结构层面，要求必须积极推动安全文化的培训。必须通过适当的规则和流程来支持实施这些要求。组织结构必须积极创建所描述的业务流程，从而使发现的安全异常与安全管理人员以及所有相关角色之间的开诚布公的交流成为可能。

在安全生命周期的活动期间，所需的记录内容（ISO26262第8部分文件）必须由相应胜任的工作人员准备，并作为正式的工作产出。持续流程改进必须植根于组织机构的指导方针。如果是学习型的组织，可以由员工的自身形象体现。相应的工具也可以支持设计以开放性为特征的安全文化，比如World Café研讨会方法。但无论如何，最终都要赋予对安全工作熟知的员工以基于角色分工的责任和必要的权限。

理解管理活动的两大分类

高级别管理活动和与项目相关的管理活动是存在区别的。前者指的是整个周期内与具体项目没有关联的，包括安全分类，安全文化，培训与资质的建设；后者指的是研发的过程管理，在项目中指定相应负责人，做出安全方案计划，验证和确认计划，进行评估。以及开始生产后的管理活动，包括为达到每个生产单位的功能安全制定生产流程，并且在开始生产后实施功能安全管理。

功能安全经理的角色

职责：在从方案到生产的产品开发过程中负责定义系统的功能安全性。他是涉及技术或组织要求的所有有关安全相关标准、指南和具体规定的核心联系人。他是内部和外部的功能安全的接口，特别是对客户和供应商。作为一名员工，他完全独立于项目，而不是开发团队的成员。

要求：他需要具备过程管理和质量管理的经验。必须有ISO26262知识以及其他与产品相关的安全标准/指南的理论和实践证明。具备危害分析能力，如FMEA和FTA方法。他要被证明有可靠性工程领域的知识。需要管理经验和团队领导经验。具备与客户和供应商的高沟通能力和专业形象。具备升级报告并且能够处理和解决冲突的能力。

对于这一角色的优劣评估的重要部分是，能否在项目的早期阶段识别并避免项目中的所有风险和含糊之处。

技术安全管理部分

持续验证和确认（V+V）（错误预防和组织措施）是必须在经济投入和时间投入上都要进行的基本活动。

ISO26262标准不做组织流程和方法的要求，可通过ISO9000或TS16949做组织程序。只有具备改变的意愿，并且必须能够得到最高管理层在所有事务上的积极支持才能成功实施和建立安全管理。

确保功能安全的措施包括：

1、实施实现功能安全的战略、活动和步骤；

2、根据ISO26262的第8部分第5段制定开发接口协议DIA；

3、根据ISO26262的第8部分制定相应支持流程；

4、根据ISO26262第3部分第7段进行危险分析和风险评估；

5、根据ISO26262第3部分第8段，第4部分第6段，第5部分和第6部分制定和实施安全要求；

6、根据ISO26262第9部分第7和第8段分析相关误差和进行安全性分析；

7、根据ISO26262第8部分第9段和第4部分第9段进行验证和确认活动；

8、根据ISO26262第2部分制定功能安全一致性措施；

9、在项目特定的安全管理中包含所有安全活动（ISO26262第2部分第5段）；

10、如有必要，根据ISO26262第8部分论证运营可靠性；

11、如有必要，根据ISO26262第2部分第6.4.5段细分安全生命周期；

根据ISO 26262第2部分对安全计划中描述的每项活动根据以下几点进行扩展：

1、设定目标。

2、活动的其他依赖性和信息。

3、开展活动的必要资源。

4、开始时间和持续时间。

5、确定相应的工作结果。

关于更改管理

ISO26262第8部分第8.4.2.1段和第8.4.2.2段包含更改请求的最低要求：

明确的更改标识例如一个数字序列，日期；

更改的详细描述；

请求更改的原因；

与申请更改相关的产品版本。

ISO26262第9部分第8.4.3.1段规定在实施更改前分析更改请求的影响。

关于开发接口协议DIA

开发接口协议定义了客户与供应商在功能安全领域的责任和沟通。跨公司合作对产品责任产生影响，需要在功能安全管理领域给予特别关注。ISO26262第8部分要求委托方（客户）和供应商必须创建DIA。必须在DIA中包括以下内容：

1、制定制造商和分包商的安全经理。

2、安全生命周期和阶段的分配以及活动，应根据标准要求分配给最终客户、客户和供应商。

3、要确定每个缔约方必须开展哪些活动和进程。例如定义由谁执行哪些验证和确认措施。必须指定每个活动的负责人角色。

4、必须描述交付范围。确定哪些工作产品和文档由供应商必须提供。特别是必须列出需要交换的所有信息和工作成果。是检查是否符合安全目标必须的。

5、列出负责这些活动的人员。此外要给出方法，以确保这些人有足够的能力执行他们所负责的任务。

6、将从系统级制定目标派生的目标值传递给每个受影响的部分，以满足“单一错误度量”和“潜在错误度量”的目标值，并用以评估是否满足安全性目标（由于随机错误造成）

7、确保制造商和分包商之间兼容性的支持流程和工具。必须定义客户和供应商之间的接口，以便信息交换顺利运行，例如文档格式的定义。

关于汽车安全完整性等级的概念ASIL

ASIL不是风险的等级或者安全性的等级，二是需要降低风险的等级，对ASIL的分级是为了定义将每个安全功能风险最小化。

ASIL A=所需风险降低的最低水平 每小时出现危险故障的可能性10的-5次方

ASIL B=每小时出现危险故障的可能性10的-6次方

ASIL C=每小时出现危险故障的可能性10的-7次方

ASIL D=所需风险降低的最高水平每小时出现危险故障的可能性10的-8次方

减少ASIL高等级部件最常用的策略：冗余

根据经验，冗余度越高，那么每个组件所需要的ASIL要求就会越低。当一个功能被多次在不同组件里运行时，那么一个冗余组件的失效会被剩余的组件所弥补。在实践中，ASIL的分解经常用于降低ASIL的要求，尤其可以避免或者减少产生最高成本和花费的ASIL D级别。

一个具有ASIL D的系统组件可以通过以下分解实现：

1、一个ASIL A组件，另一个ASIL C组件。

2、两个ASIL B的冗余组件。

3、一个ASIL D组件，另一个依据QM开发的或已经在车辆中实现的组件。

功能安全的可用性可以区分为“失效安全”和“容错”。

失效安全：指的是具有错误检测和识别的能力，并且在必要时实现进入安全的状态。

容错：指的是即使发生故障，也可以维持完整的与安全有关的功能继续运行。

容错等级描述

FTS1 系统安全并且正确的进行反应

FTS2 系统进入容错，但未有功能限制

FTS3 系统运行是安全的，但是功能受限制

FTS4 系统进行安全的反应（失效安全）

FTS5 系统运行变得无法预见

关于安全性分析和方法

安全性分析包括以下任务：

1、确认安全目标和安全概念。

2、验证安全目标和安全要求。

3、确定导致安全目标或安全要求失效的故障原因和发生的条件。

4、确定进行错误检测或错误行为检测的额外要求。

5、确定必要的错误检测措施。

6、确定有关安全目标和安全要求验证的进一步要求，例如车辆测试。

7、确定单点故障量度和潜在故障量度（ISO26262第5部分C2和C3）

安全性分析的方法

定性方法：

定性FMEA和故障树分析FTA

危害和可操作性研究HAZOP

定性的扩展的基于时间的自动机ETA

定量的安全性分析方法：

定量FMEA

定量FTA

定量ETA

马尔可夫模型

可靠性框图

关于危害分析和风险评估

危险分类和识别

评估后果的严重程度S：严重程度，评估发生危险情况的相对频率E：发生率，评估损害在人为干预或其他措施后依旧无法避免或减轻的可能性C：可控性

S0 无伤害

S1 轻微或有限的伤害

S2 严重或危及生命的伤害（可能幸存）

S3 危及生命的伤害（不太可能幸存），致命伤害

E0 几乎不可能0.0001

E1 可能性非常低0.001（大多数驾驶员一年少于一次）

E2 可能性低0.01（一年很少几次）

E3 中等可能性0.1（每个月都有或者更频繁）

E4 可能性高1（每次开车都会出现的情况）

C0 通常可控 0.001（小于0.1%的普通驾驶者或道路人员不能规避危害）

C1 简单可控0.01（小于1%的普通驾驶者或道路人员不能规避伤害）

C2 正常可控0.1（小于10%的普通驾驶者或道路人员不能规避伤害）

C3 很难控制或不可控1（不能规避危害）

基于风险图：基于危险分析的S、E、C得出所要求的ASIL级别

简单判定ASIL等级方法：基于S+E+C的总和进行判断（如S1 E3 C2）

总和小于等于6：QM

总和为7：ASILA

总和为8：ASILB

总和为9：ASILC

总和为10：ASIL D

如判定为ASIL A\B\C\D，则要采取特殊的措施。如果判定为QM（质量管理），那适用的标准就足够，没有必要进一步采取特殊的安全措施。注意：每一个相关项，每一个元件都要确认ASIL级别。

硬件故障的分类和指标

单点故障SPF:系统内只有一个系统元素发生故障，出现单点故障是指无安全机制保护，并立即导致破坏安全目标；

多点故障MPF：几个独立故障的组合体，一起组成了多点故障，最后导致了功能失效。

被检测到多点故障MPF D：这类多点故障时指检测到的/诊断出的系统错误。

可感知的多点故障MPF P：这类多点故障是一个可被察觉的错误，即驾驶员感知到错误干预（例如功能受到限制）

潜在多点故障MPF L：指无法识别到的系统中存在的错误，且与其他故障相结合可导致系统进入危险状态。这类故障如果可能出现的话，必须采取额外措施，防止系统中有遗留的错误，或借助其他检测措施减少潜在故障。

残留故障BF：此处故障指第一个带有危险影响的错误，这些都无法通过诊断被识别出来，这些残留的错误，即有偏差的那一部分，是通过安全机制不被发觉的并导致破坏安全目标。

安全的故障SF：在这类故障下，人们理解的是没有危险的错误。

不同ASIL 等级 对于各类故障的度量边界值要求不同。最优情况下，度量值应等于1。

所考虑的元素故障率越小，度量值就越是接近于理想最佳状态。

如果未达到目标值，则需要改进了安全机制的诊断覆盖率，并由此规范额外的硬件和软件安全要求。