【功能安全】【ISO26262】指南
本标准概述了ISO 26262的核心内容：通过功能安全要求确保汽车系统的安全性，并区分其与其他国际标准如IEC 61508的主要区别。该标准详细介绍了功能安全的关键概念（如故障、错误和失灵），并对其进行了分类：单点故障（Single Point Fault）、残余故障（Residual Fault）、已检测双点故障（Detected Dual Point Fault）、已感知双点故障（Perceived Dual Point Fault）及潜在双点故障（Latent Dual Point Fault）。此外，还定义了系统的可控性层级（C0至C3），并阐述了其在汽车系统中的应用流程：从危害分析和风险评估开始，在功能设计阶段确定需求，在技术设计阶段制定方案，并最终通过产品生产确认检测以实现合格认证与授权。最后强调了通过具体的安全案例进行论证和支持证明的重要性以确保系统的可接受安全性。
目录
一、前言
二、ISO 26262 的关键概念
三、 故障(fault),错误(error)和失灵(failure)的解释
四、可控性观念(Notions of controllability)
五、安全过程需求结构(Safety process requirement structure) - 安全相关的流程和顺序(Flow and sequence of the safety requirements)
六、产品生产,确认检测,合格与授权
七、对于安全案例的理解
一、前言
该段落呈现了ISO 26262标准的概览性综述，并作为补充资料目的加以提供以强化对 ISO 26262 标准的理解。它阐述了 ISO 26262 标准的基本概念以便于更好地掌握相关知识.内容从基本概念扩展至专业领域.对于 ISO 26262 标准中与其它部分存在差异的部分建议参考 SO 通过引用 SO 进行推荐和信息分享.
二、ISO 26262 的关键概念
1、用于汽车系统的功能安全
1.1、区别一
IEC 61508标准在设备运行于控制模式时得以实施,例如一个工厂厂房内部配置了一套Control\ System以管理其相关设施
ISO 26262 使用安全目标概念和安全概念如下:
⎯ 危害分析和风险评估用于识别危害，用于达到风险减少.
⎯ 安全目标明确表达每一个有危害的事件.
⎯ 汽车安全完整性等级(ASIL)关联到每一个安全目标.
⎯ 功能安全概念是对功能如何达到安全目标的一种描述. 在功能安全需求中陈述.
⎯ 技术安全概念是对功能在硬件和软件中如何实施的一种陈述.在技术安全需求中陈述.
⎯ 软件安全需求和硬件安全需求描述了部分在软件和硬件设计阶段将会实施的特定的安
全需求.
例如:
⎯ 安全气囊系统: 其中一种危害是无目的性的展开
⎯ 相关的安全目标是确保安全气囊不展开,除非是一个撞击需要展开.
⎯ 功能安全概念指定一个冗余功能检测车辆是否处于撞击状态.
⎯ 技术安全概念指定两个独立的带有不同轴向的加速度传感器和两个独立的点火电路用于
实施.只有电路都闭合时才能爆炸弹出气囊.
1.2、区别二
IEC 61508主要针对一次性或小型设备系统的安全性与可靠性评估。随后，在工厂环境中建立并测试这些系统后，通常会进行安全有效性的验证。对于大量生产的产品如汽车等设备，则会在量产前完成安全有效性的验证。因此，在ISO 26262标准中对产品生命周期内的各项活动顺序进行了详细规划。特别是ISO 26262-7版本特别明确了针对生产需求的具体要求。需要注意的是，这些内容并未包含在IEC 61508标准内。
1.3、区别三
IEC 61508 基于一个隐含假设，在该标准中系统将被规划和执行. 汽车系统的主要生产者通常是单一供应商或者多家联合供应商（如汽车制造商）. ISO 26262 涵盖关键要求（specific requirements），其作用在于协调多方面组织之间的合作开发工作（包括制定和发展互操作性接口协议DIA），这些内容均可见于ISO 26262-8 中的第5部分描述.
1.4、区别四
IEC 61508不提供用于危害分级的规范性需求(normative requirements)，而ISO 26262则包含一个基于汽车方案（automotive scheme）的结构来执行危害分级（hazard classification）。该方案将识别存在于汽车系统中但可能未导致事故的所有潜在风险。结果取决于当潜在风险出现时驾驶员是否处于驾驶状态以及是否存在能有效规避该风险的可能性；同时还需要考虑驾驶员是否有能力影响事件的结果。这一概念如图二所示。
1.5、区别五
需求会在硬件和软件开发阶段被采用（ISO 26262-5 和 ISO 26262-7）。为了适应现代要求（state-of-the-art），该需求会被调整以采用最新的技术。特别地，在软件开发阶段（ISO 79.4.3.3），涉及基于模型开发的要求（model-based development）。这一点并未被IEC 79.4.3.4所涵盖。
1.6、区别六
风险缓解需求(Risk mitigation requirements)在ISO 26262标准中被明确定义为A类完整性等级(ASIL)，而非传统的安全完整性等级(SIL).这种分类方法的原因在于SIL在IEC 61508标准中采用了概括性描述（见IEC 61508-1第3表），这种表述方式更适合提供总体概念.尽管如此，在实践中这类关键图表（headline figures）通常会被选用作为具体的风险缓解需求说明.值得注意的是ASIL体系并未涵盖那些具有概率性质的安全要求和目标(probabilistic requirement/target)，因为其核心关注点在于确保系统在极端情况下的确定性保障.
2, 项(Items), 系统体系(systems), 基本单元(element), 组件组(components), 硬件构成(hardware parts) 和 软件模块(software modules)
项目要素定义：其相关定义可在ISO 26262-1标准中找到。
项目要素：项目要素（items）在其所处的整体范围内被评估（assessed within the entire scope），其中项目要素可能是单一系统（a system）、一组系统（an array of systems）、单一功能或多个功能（functions）。对于单一或多个功能的情况而言，则是由相应的系统或一组系统的功能来实施的（see Figures 3 and 4）。
系统架构：由一系列组件构成（assemblies），其中包括至少一个传感器（sensor）、一个控制器（controller）以及一个执行器（actuator），如图4所示。
组件划分：每个组件都是项目要素中的任何子单元；它可以独立存在也可以进行分解。
不可分割的元素：不可分割的元素要么是一个硬件部分（hardware part），要么是一个软件单元（software unit）。而可分割的元素则需满足以下条件：它必须能够作为一个独立系统或者子系统来分解。
子系统应用：通常用于突出显示该元素作为更大系统的一部分。
组件特性：作为非系统的层级结构中的基本构建块，在特定领域内具备逻辑性和技术上的可分离性。
三、 故障(fault),错误(error)和失灵(failure)的解释
1、故障(fault),错误(error)和失灵(failure)的关系
按照ISO 26262-1标准, 故障、错误与失灵被分别定义为系统的三种基本状态. 图5展示了三种不同情况的连续性: 系统性软件问题(systematic software issues)、随机发生的硬件问题(random hardware issues)以及系统性硬件问题(systematic hardware issues). 系统性软件问题是由于设计缺陷或规范不足所导致;而所有软件相关的故障以及部分硬件相关问题都属于系统性的范畴. 随机发生的硬件问题往往由物理过程引发,如元件损坏等. 在组件层面,每一种类型的故障可能导引出不同的后果:例如在车辆层面,同一份故障可能由不同的原因引起而导致相同的结果. 其中一部分潜在的问题可能会带来危险后果,尤其是当其他因素促进其演变为事故时.例如，在一个交叉路口发生顶撞行为可能导致交通事故的发生.
2、 故障类别（仅用于随机硬件缺陷）
通常情况下，在随机硬件缺陷中，缺陷组合被视为仅限于两个缺陷组合的情况，并非总是如此——当涉及的安全功能或技术的安全概念数量超过两个时例外。
从而多数情况下一缺陷可归类于以下几种：
- 单点缺陷（Single Point Fault），
- 残余缺陷（Residual Fault），
- 已检测到的双点缺陷（Detected dual point defect），
- 已感知到的双点缺陷（Perceived dual point defect），
-潜在存在的双点缺陷（Latent dual point defect）， - 安全缺陷（Safe defect）。
单点故障(Single Point Fault):
这个故障直接导致违背安全目标.
没有安全机制被实施用于控制任何的硬件元件的故障(该故障已经潜在的违反了安全目标).
例如一个未被监控的电阻导致了一个故障模式，违法安全目标.
残余故障(Residual Fault):
这个故障直接导致违背安全目标.
至少一种安全机制被实施用于控制一些硬件元件的故障,故障已经潜在的违反了安全目标.
例如如果一个随机存储器模块仅有一个RAM 检测板检测, 某种桥接故障(bridging faults)将
是不可控的.这些故障就是残余故障.
已检测到的双点故障(Detected dual point fault):
这个故障有可能导致违反安全目标，但只有和其他独立的故障结合才会导致违反安全目标.
这个故障被安全机制检测到，安全机制在一定时间内阻止故障从潜在状态变成故障状态.
例1 flash 由奇偶校验(parity)保护: 单点故障被检测到并且被控制.
例2 flash 由错误修正和检测逻辑(EDC)保护: 在EDC 逻辑中故障通过检测被发现.
已感知的双点故障(Perceived dual point fault):
这个故障有助于违反安全目标但只有在与另一个独立的故障结合才会导致违反安全目标.
这个故障由于驾驶员腿短，没有在规定的时间内通过安全机制进行检测.
例如一个双点故障被驾驶员察觉,如果功能极大地收到了故障的后果的影响.
潜在双点故障(Latent dual point fault):
这个故障有可能违反安全目标，但只有和另一个故障结合才会违反安全目标.
这个故障既不是有一个安全机制检测到也不是通过驾驶员感知.换句话说,这个特别的故障
是可以容忍的,因此系统仍然可以运行,驾驶员将不会被告知该故障.
例1 flash 由错误检测和修正逻辑保护:一个单点故障由EDC 修正但是没有被告知. 在这种
情况下故障是可控的(因此故障点被修正) ,但是它既不是被检测也不是被感知到.如果另一
个故障发生在EDC 逻辑中,它将会导致失去对该单点故障的控制,导致对安全目标的潜在威
胁.
例2 flash 由EDC 保护: 在EDC 中的故障将导致EDC 无法使用,并且无法被测试发现.
安全故障(Safe fault):
n 点故障并且n > 2, 一个故障可以被认为是安全故障除非在安全概念中展示了相关.
一个安全故障也是一个不会违反安全目标的故障.
一个安全故障不会导致违反安全目标的概率明显增加.
例1 在短暂故障情况下, 安全机制将会存储事项到一个fault free 状态,这样的一个故障被
认为是一个安全故障，甚至从不会告知驾驶员它的存在.
例2 flash 由EDC 和CRC 保护: 单点故障被EDC 修正但不会被显示:
故障被控制但是没有被EDC 显示.
如果EDC 逻辑失灵，故障被CRC 检测到,导致关闭系统.
仅有一个单点故障在flash 中出现, EDC 逻辑失败并且CRC 校验监管失败, 将发生违反安全
目标(n=3).
硬件元件的故障模式可以被分级展示在图6 中,并且用流程图显示在图7 中.
四、可控性观念(Notions of controllability)
该标准第1部分将可控制性定义为：通过相关人员迅速响应可防止伤害（harm）或损害（damage）。该标准第3部分第7章进一步阐述了可控性是对驾驶员及其他有生命危险者可能采取行动以减少危害事件的一种估计。如 ISO ₂₆₂₆₂-3 第7章所述，在此分类中有四个层次
五、安全过程需求结构(Safety process requirement structure) - 安全需求的流程和序列(Flow and sequence of the safety requirements)
在ISO 26262 标准中对安全需求开发的流程(flow )和序列(sequence)进行了详细阐述并进行了说明,具体内容如图8所示.危害分析与风险评估过程被实施,用于识别风险并为这些风险制定相应的安全目标(见ISO 26262-3 第7段).功能安全概念由此衍生,用于满足特定需求下的安全目标.这些需求则定义了相关的安全机制(the safety mechanisms)以及其他的保障措施(the other safety measures),以确保系统的安全性.系统架构的另一个组成部分则需要被评估是否支持这些需求.这一评估过程可参考ISO 26262-3 第8段的相关规定.在确定具体实施的安全需求时,一个技术层面的安全概念将会被提出,这将明确硬件与软件之间的功能划分(见ISO 26262-4 第6章).系统设计完成后,需与上述技术安全要求保持一致.其具体实施细节将在系统设计规范中得到明确的规定(见ISO 26262-4 第7章).最后,硬件与软件的安全需求将会被制定出来,以满足上述技术要求以及系统的整体设计规范(见ISO 26262-5 第6章).
六、产品生产,确认检测,合格与授权
在ISO 26262标准中, 产品生产被定义为信息或数据,构成一个或多个系统安全过程活动的结果( A work product is information or data which constitutes the result of one or more system safety process activities ). 产品生产的适当格式化将确保其与生产内容相匹配(Work products will be in a format appropriate to the work product’s content).例如, 在实际应用中可以通过仿真工具对多个电子文件进行读取和解析, 并将其整合为相应的执行模块. 这种信息存储方式与ISO 26262标准一致, 不需要额外生成独立的产品生产文档. 相关信息可以直接提取自现有文档或者整合到单个文档中以减少存储负担.
2、合格(qualification)与授权(authority)
七、对于安全案例的理解
安全案例的解析
多种方式可用于对安全案例进行阐述.其中一种方法可在当前章节内提供.
定义安全目标的目的,可采用以下术语:
安全案例需传达一个清晰、全面且合理的论断（基于证据支持），使系统能在可接受的安全环境下正常运行.
在上述定义中应考虑的关键因素包括：首先,安全案例的作用在于传递论证,其目的在于证明基于现有证据体系是否能实现合理结论.由于安全案例是一个策略性的工具,通常用于第三方,因此其表达需具有说服力和清晰度.绝对安全并非可达目标,而通过安全案例则可证明系统已达到足够的安全性（规避不合理风险）.为了确保理解效果,建议对相关内容进行清晰定义.此外,该方法还可适用于整车或其子系统.
构建安全案例的核心要素包含三个关键要素：需求、论证和证明.这三个要素之间的关系已在图11中进行了详细说明.
