特约专栏 | 一个软件BUG可能要召回百万辆车?ISO 26262功能安全到底解决了什么问题

这里有三个关键词，要想做好功能安全，那就一定要理解好这三个关键词。

第一是电气/电子系统故障，它包括硬件故障，比如MCU损坏，MOS短路了，也包括软件故障，比如程序错误，数据异常，算法错误，所以如果是机械故障，比如悬挂断裂、轮胎爆胎了，或者高压绝缘没做好导致人被电击了，这些都是不考虑在内的。

第二是不合理风险，什么叫不合理？例如发动机控制ECU如果某个温度传感器坏了。这个时候系统限制发动机功率，那车辆还能行驶，这就是合理风险。但是如果刹车控制ECU失效导致车辆无法制动，那这就是不可接受风险。

第三是故障导致，功能安全关注的是失效链：故障->系统行为->整车风险。

所以ISO 26262核心不是设计一个不会坏的零件，而是设计一个即使发生故障，也能控制风险的系统。

2.2 ISO 26262 的安全目标如何理解？

功能安全设计第一步是啥？是识别危险，如何识别危险？通过HARA分析来识别危险，比如自动驾驶转向系统中方向盘控制错误可能后果是车辆偏离车道。

而所谓的安全目标就是指在车辆层面上，通过危害分析与风险评估所确定的顶层安全要求，一个安全目标可以与多个危害相关联，同时多个安全目标也可以与单个危害相关联。所以安全目标是整车层面上分析得到的，而不是通过某个ECU内部分析得到的。根据三个因素（严重度+暴露度+可控度）来评判风险等级，最终形成ASIL等级，包括QM，ASILA，ASILB，ASILC，ASIL D，ASILD代表最高安全等级。例如自动驾驶转向控制，通常需要ASIL D。

2.3 ISO 26262 整体架构是怎么样的？

ISO 26262是一套完整开发流程。整体可以分为：

Part 1：术语和管理，定义了标准中使用的所有核心术语、词汇和缩写，为整个标准提供统一的语言基础。

Part 2：功能安全管理，规定了组织层面和项目层面的功能安全管理要求，包括安全文化的建立、人员资质、职责分配以及安全计划的制定。

Part 3：概念阶段，说明如何开展车辆层面的项目定义、危害分析与风险评估HARA，并由此确定安全目标以及功能安全概念。

Part 4：系统级开发，涵盖系统级技术安全要求的制定、系统架构设计、硬件与软件的接口定义、系统集成以及系统级验证测试。

Part 5：硬件开发，针对硬件开发流程，包括硬件安全要求分配、硬件架构设计、定量和定性硬件安全指标评估（如单点故障指标、潜伏故障指标）、硬件集成与验证。

Part 6：软件开发，针对软件开发流程，涵盖软件安全要求的分配、软件架构设计、单元设计与实现、软件集成以及软件验证和测试。

Part 7：生产，运行，维护，报废，规定了产品在制造、售后、日常维护、维修以及最终报废全过程中，如何保持功能安全。

Part 8：支持流程，包含了配置管理，变更管理，文档管理等。

Part 9：以汽车安全完整性等级为导向和以安全为导向的分析，阐述了ASIL等级的分解原则、相依失效分析，以及多元素共存的分析方法。

Part 10：指南，为非规范性的参考指南，提供了对ISO26262各个部分的解释、示例和补充说明，帮助工程师理解和落地标准。

Part 11：半导体应用指南，专门针对半导体元器件，如芯片、IP核等的开发、生产与运作提供了详细指导和用例说明。

四、功能安全到底在解决什么问题

黄永超 | 作者

冯亚军 | 审核

免责声明：如涉及侵权请及时与我们联系反馈，我们会在第一时间做更正声明或做删除处理。文章版权及解释权归原作者及发布单位所有，如需转载或引用本文的任何内容，请注明出处。