概览

• 汽车行业国际标准
• ISO26262国际标准草案DIS: 06.2009发布
• 提供了一个通用标准, 用于衡量系统在使用时的安全性; 提供了通用词汇表, 指代系统特定部分
• 采用分步系统, 管理功能安全, 并在系统, 硬件及软件层面规范产品开发

ISO26262关键组成

• 定义汽车安全生命周期(管理,开发,生产,运行,服务,报废), 支持在各生命周期阶段自定义必要的活动
• 提供基于风险的具体方法, 判定汽车的风险等级(ASIL汽车安全完整性等级)
• 使用ASIL指定项目的必要安全要求, 使残余风险在可接受范围内
• 提供验证要求和确认方法, 确保实现有效且可接受的安全水平

汽车安全生命周期

汽车安全生命周期

• 描述整个生产生命周期, 包括对安全管理员的需求, 安全计划的制定及确认方法的定义(安全检查,审计,评估)

1. 概念阶段
   1. 项目定义: 描述项目及环境及其他项目之间相关性和相互作用, 确保安全生命周期中定义的每项活动都得到准确实施
   2. 安全生命周期启动: 基于项目定义, 区分全新开发项目/改款项目来启动对应安全生命周期. 改款项目:识别变更部分进行影响分析后, 调整部分安全生命周期活动
   3. 风险分析&风险评估: 概念阶段核心, 识别会引起项目故障的危害并对其分类, 制定预防和减少这些危害相关的安全目标, 避免不合理风险
   4. 功能安全概念: 从安全目标引出功能安全要求, 分配给该项目初始结构元件/外部措施, 为符合安全目标, 功能安全概念包括安全措施, 包括应用于项目结构原件并在功能安全要求中详细列出的安全机制
2. 产品开发阶段
   1. 概念阶段得到安全需求, 在技术安全中详细说明, 分解在系统层面的安全设计中; 完成系统及产品设计后, 技术安全需求规范分解到相应的软硬件技术安全需求规范内, 开展软硬件级产品设计
   2. 硬件层面: 必要活动和产品开发过程包括技术安全概念硬件实现, 潜在硬件故障, 影响分析, 与软件开发协调
   3. 软件层面: V模型流程, 遵循技术安全概念, 实施软件安全要求导出, 软件架构设计, 软件单体设计和细化. 在此基础上实施编码, 进行软件单元测试, 软件集成和集成测试, 软件安全要求的验证
3. 生产&经营
   1. 生产: 由负责生产过程的相关制造商/个人/机构(车辆制造商,供应商等)实现功能安全; 在生产计划和控制中涵盖安全相关的特殊特性, 规定了确保在生产过程中实现功能安全的要求
   2. 经营,服务,报废: 制定了开发维修说明和用户信息要求, 包括用户手册与计划, 维修工作的执行和监控, 考虑了项目的安全相关的特殊特性

汽车安全完整性等级ASIL

ASIL

• ISO26262标准的重要组成部分, 在开发过程的开始阶段确定, 分析系统的预期功能, 指出可能危害, 不关注系统使用的技术
• ASIL由不同安全要求分ABCD四级别, D级有最安全的关键流程, 测试规范最严格
• 由组件ASIL级别分别规定最低测试要求
• 比如，​以​雨刷​系统​为​例。​安全​分析​将​确定​丧失​雨刷​功能​会对​驾驶​员​的​视线​造成​何​种​影响。​ASIL​给​出​指导，​选择​适当的​方法​来​使​产品​达到​一定​程度​的​完整性，​旨​在​补充​现有​的​安全​做法。​目前，​汽车​制造​采用​高​安全​标准，​而​ISO26262​旨​在​规范​行业​内的​特定​做法。

硬件组件认证

• 两个主要目的
  1. 明确部件对整体系统适应性
  2. 评估故障模式
• 基础硬件组件可通过标准认证进行评估, 更复杂的不见通过ASIL分解及测试进行评估
• 硬件认证在系列环境和操作条件下进行测试, 使用多种定量方法分析测试结果, 写入认证报告, 随附测试程序, 假设, 输入标准

软件组件认证

• 认证软件组件
  1. 确定功能要求
  2. 资源使用
  3. 预测在故障和重载情况下的软件行为
• 需要在正常操作条件下进行测试, 在系统中插入故障, 判定如何应对非正常输入
• 设计解读那分析并处理软件错误, 如运行时和数据错误

在实践中证明

硬件​及​软件​组​件​可​通过“在​实践​中​证明”的​论据，​证明​其​符合​ISO26262​要求。​若​组​件​已​在​其他​实际​应用​中​无​故障​运行，​则​可​适用​该​条款。​ISO26262​也​适用​于​在​实践​中​得到​证明​的​早期​系统。​很多​情况​下，​若​某种​系统​已经​在​几百​万​辆​汽车​上​得到​验证，​则​没有​必要​重新​检验​其​是否​符合​标准。​例如，​目前​制造​的​汽车​中，​很多​系统​是​按照​ISO26262​发布​前​的​高​级别​安全​标准​制造​的。​在​实际​应用​过程​中，​这些​安全​关键​组​件​运行​良好、​可靠。在​早期​汽车​中​就​已​使用​且​一直​未​变的​可靠​系统​仍​可​获得​ISO26262​认证。​类似​实际​应用​和​得到​广泛​部署​的​早期​实际​应用​中的​认证​组​件​结合，​极大​地​降低​了​总体​系统​复杂​度。

测试工具认证

工具置信度

• TCL和ASIL决定了软件工具要求的认证水平
• TCL评估因素
  1. 软件工具出故障的可能性, 错误输出对安全相关项目或开发中的元件会造成何种危害
  2. 输出中预防或检测该错误的可能性
• TCL1,TCL2,TCL3,TCL4(最高置信度)

工具认证过程

• 提供
  1. 软件工具认证计划(STQP):
     1. 计划软件工具的认证和能证明该工具符合所需置信度的用例
     2. 包括: 软件工具独特的标识和版本号, 用例, 环境, 描述, 用户手册, 预先确定的ASIL
  2. 软件工具文档: 功能描述,安装过程描述,用户手册,运行环境,异常状态下的预期行为
  3. 软件工具分类分析(STCA):确定工具置信度
     1. 工具影响(TI): TI1-TI2
        1. TI1:确定发生故障的软件工具绝不会违反安全要求时选TI1
        2. TI2:其他所有情况选TI2
     2. 工具错误检测(TD): TD1-TD3
        1. TD1:对工具检测错误的能力有高度置信
        2. TD2:中等置信度,不能检测所有可能违规行为,需要额外测试
        3. TD3:低置信度,只能随即检测出错误
  4. 软件工具认证报告: 包括结论及完成认证且满足要求的证据, 任何验证期间产生的故障/错误输出在此分析记录

实践中提升置信

从​实践​中​提升​置信​是​工具​认证​的​一个​重要​方面。​若能​证明​某​工具​已经​符合​认证​要求，​就​无​需​进一步​的​认证。​这​将​大幅​降低​开发​过程​中的​花费​及​时间​成本。​然而，​在​用于​项目​开发​前，​每​个​安全​相关​项目​或​元件​都​必须​证明​已​达到​认证​要求。​为​证明​这​一点，​该​工具​必须​证明：

• 曾经​为了​相同​的​目的，​在​类似​的​用例​中​使用​过
• 该​工具​的​规范​没有​改变
• 未​在​曾经​开发​的​安全​相关​项目​中​违反​安全​要求。

例如，​假设​工具​A​用于​验证​汽车​X​的​ECU（引擎​控制​单元）。​若​测试​工具​A​未​违反​任何​安全​要求​且​没有​改变，​那么​它​就​可​用于​验证​汽车​Y​的​ECU，​只要​汽车​Y​的​ECU​用途​与​汽车​X​的​ECU​使用​方法​类似​即可。

ref

• 什么​是​ISO 26262​功能​安全​标准？
• iso26262中文版本文档.pdf
• 自动驾驶 - 功能安全（ISO26262）概述【附PDF原版资料下载】