Autoware.universe 高效学习第三章 -- 智驾技术务虚会其二之智驾安全性讨论

1 前言和资料

接上一篇文章 智驾技术务虚会之智驾技术栈讨论 ，我们继续智驾技术务虚会，本文重点讨论智驾软件的安全性问题。按理说 “安全生产大于天”，智驾代替人开车，直接关乎车上乘客和其他道路参与者的安全，安全性更应该是 “大于天” 的事情。但在工程领域，不存在 100% 的安全，绝对的安全，意味着无上限的成本，而智驾技术本身追求的是普惠性，追求低成本的惠及大多数人。本文尝试讨论汽车行业是如何在工程上实现安全性要求的。
本文参考资料如下：
（1）autoware architecture
（2）Development of Safety Critical Software in Operational Domain
（3）ISO 26262 2018 Part1 ~ 12
（4）百度–自动驾驶安全第一白皮书
（5） 莱茵认证101
（6）V-Model
（7）V-model_(software_development)
本系列博客汇总：Autoware.universe 高效学习系列。

2 正文

2.1 自动驾驶车辆是混合关键系统（Mixed criticality systems）

（1）行驶任务在不同层次的响应耗时要求：
第一，战略层面（旅行的最高层任务），如导航路线规划，10+秒。
第二，战术层面（在车流中操纵车辆），如跟车，并线，对物体的响应，1~10秒。
第三，操作层面（对车进行横向和纵向控制），0.01~0.1秒。
第四，主动安全（对迫在眉睫的威胁做出反应），如紧急制动，紧急避让，0.1~15秒。
（2）正是由于车辆有不同层次的响应要求，而且响应不及时，导致的后果也不同（通常响应耗时越短，后果约严重），因此我们可以按后果的严重性，评估汽车不同系统的关键性：

安全关键（Safety-critical）：这是最高最重要的关键性级别。安全关键系统失败，可能会对人类造成伤害甚至死亡，比如车辆转向系统，刹车系统。
任务关键（Mission-critical）：任务关键系统具有较高的优先级。系统失败会导致任务无法实现，但不会伤害任何人，例如导航系统。
低关键（Low-critical）：最低等级的关键性。低关键性系统失败，即不影响正常行驶，也不危险，只会影响用户体验，比如车载收音机。
混合关键系统（Mixed criticality systems）：自动驾驶车辆是典型的混合关键系统，即在一个平台上，运行两个或多个不同级别（即安全关键、任务关键和低关键）的系统。

（3）自动驾驶车辆的智驾子系统是最高等级的安全关键（Safety-critical）系统，如果智驾系统失败，可能会对乘客和行人造成伤亡，特斯拉，蔚来，华为都有过严重的智驾交通事故。

2.2 智能网联汽车安全三剑客

（1）智能网联安全三剑客即功能安全，预期功能安全，信息安全，相关定义以及对于的标准如下：

功能安全（Functional Safety）：解决安全相关系统中电气和/或电子设备故障可能造成的危险（Addresses possible hazards caused by malfunction behavior of electrical and/or electronic in safety-related systems）。功能安全是在汽车电子电气技术基础上发展而来的一项安全技术，对应的标准为 ISO 26262，前身是电子、电气及可编程器件功能安全基本标准IEC 61508。
预期功能安全（Safety of The Intended Functionality，SOTIF）：指的是规避由于功能不足、或可合理预见的人员误用所导致的人身危害。预期功能安全技术属于智能网联汽车技术的一部分，对应的标准为 SOTIF ISO 21448。
信息安全（Cyber Security）：指规避重要信息泄露、被篡改、盗窃或遗失。信息安全同样属于智能网联汽车技术的一部分，对应的标准为 ISO/SAE 21434 和 SAE J3061。

（2）Safety 和 Security：这是汽车安全中经常提到的两个概念，很相关，也很相似，较为通俗的理解是：Safety 指防范车自身的问题，即各种失效，由 ISO 26262 设定最高标准。Security 指车能防攻击或者防误用能力，类似“安保”，预期功能安全和信息安全属于这个范畴。
（3）安全三剑客中，体系最完整，最成熟的是功能安全；而信息安全通常会嵌入到功能安全的范畴中，统一管理；至于预期功能安全，尚属于定性分析的层次，整体还处在发展过程中。更多的讨论，推荐阅读 百度–自动驾驶安全第一白皮书。

2.3 功能安全

2.3.1 ISO 26262

（1）ISO 26262 版本历史：截至 2024 年，共有两个版本：
一是 ISO 26262:2011，分为十个部分，涵盖了管理功能安全、概念阶段、系统级、硬件级、软件级的要求，以及支持过程等方面。
二是 ISO 26262:2018，分为十二个部分，改进内容：将适用范围从仅限乘用车扩展到包括摩托车、卡车、巴士等其他道路车辆；引入了适应新技术和概念的条款，例如自动驾驶和先进驾驶辅助系统(ADAS)；增加了对电动车和混合动力车的考虑。
（2）ISO 26262:2018 的十二个部分（下载链接：ISO 26262 2018 Part1 ~ 12 ）：

Part 1: Vocabulary，术语和定义，此部分给出了整个标准使用的术语、定义和缩写词，确保所有后续部分中的术语都有统一的理解和应用。
Part 2: Management of functional safety，管理功能安全，这一部分提供了如何在整个汽车开发生命周期中规划、实施、监控和改进功能安全管理体系的指南。
Part 3: Concept phase，概念阶段，这里描述了项目早期的活动，包括风险评估（如危害分析和风险评估）以及确定安全目标和安全需求等。
Part 4: Product development at the system level，产品开发：系统级，详细说明了开发安全相关的电气和/或电子系统时需要遵循的流程，包括系统设计、分析、验证和确认活动。
Part 5: Product development at the hardware level，产品开发：硬件级，专注于硬件组件的安全生命周期，其中包含硬件的设计、实现和评估过程。
Part 6: Product development at the software level，产品开发：软件级，说明了软件开发过程中的安全方面，包括软件架构、设计、实现、验证、测试和确认。
Part 7: Production, operation, service and decommissioning，生产和运营，讨论了制造、操作、服务和最终报废阶段中功能安全的考量，确保在整个产品生命周期内维持必要的安全水平。
Part 8: Supporting processes，支持过程，这一部分涉及到评估、验证、配置管理等多种支持过程，这些是完成主要安全生命周期活动所必需的。
Part 9: Automotive safety integrity level(ASIL)-oriented and safety-oriented analyses，ASIL相关的安全分析，详细介绍了定性和定量的安全分析方法，如故障树分析（FTA）、失效模式与影响分析（FMEA），以及如何将其用于确定汽车安全完整性级别（ASIL）。
Part 10: Guidelines on ISO 26262，指南，包含对整个ISO 26262标准的额外解读和例子，以帮助理解和实施这些标准。
Part 11: Guidelines on application of ISO 26262 to semiconductors，ISO 26262应用到半导体上的指南，这一部分专门针对半导体产品的制造商和供应商，为他们在应用ISO 26262标准时提供具体的指导。
Part 12: Adaptation of ISO 26262 for motorcycles，应用 ISO 26262 到摩托车，此部分是对ISO 26262标准的适配，专为摩托车及其子系统和组件的特殊性质而设。

（3）学习思路：
第一步：熟悉整体框架和关键概念
阅读第1部分（Vocabulary）：首先了解标准中所使用的关键术语和定义。
审视第2部分（Management of functional safety）：这将帮助您理解如何管理功能安全，并为进一步的学习打下良好的管理基础。
浏览第10部分（Guideline on ISO 26262）：此部分提供对标准的额外解释和示例，有助于您更好地理解后续各部分的内容。
第二步：根据职责与兴趣深入特定部分
系统工程师：可能需要重点理解第3部分（Concept phase）和第4部分（Product development at the system level）。
硬件工程师：应该深入第5部分（Product development at the hardware level）。
软件工程师：需要详细学习第6部分（Product development at the software level）。
质量与安全经理：应当掌握第2部分（Management of functional safety）和第9部分（ASIL-oriented and safety analyses）。

2.3.2 莱茵认证

（1）功能安全的标准 ISO 26262 是开放的，汽车行业内任何组织都可以下载下来，用来指导自身产品的功能安全建设。但如果零部件公司想进入整车厂采购目录（智驾也算零部件），通常情况下，整车厂（尤其是欧洲车企）会要求零部件供应商进行专业的 ISO 26262 认证并通过，然后才会进行采购，这时就需要专业的第三方认证机构，最有名的就是 莱茵认证，参考 莱茵认证101。

（2）如果个人想在功能安全领域深入下去，甚至成为功能安全专家，而不只是简单的自学一下，莱茵认证也提供相关的培训和资格认证。感兴趣的读者可以报名莱茵的功能安全培训，并参加考试，如果通过，会得到莱茵颁发的资格证书。不过这个考试不是针对所有人的，通常需要具有一定的从业经验，参考 tuv fs-engineer。

2.3.3 V-model 开发模型

（1）三种常用的软件开发模式：
瀑布式（Waterfall）：从项目开始，每个要求都是已知的。开发顺序是连续的。不允许迭代。适用于在开发阶段之间进行更改成本非常高或不可能的项目。最早的开发模型。
V 模型（V-Model）：可以视为瀑布模型的扩展，它专注于每个阶段之间的可追溯性、验证和验证。它按时间顺序分为多个开发阶段，中间没有迭代。安全关键系统的开发模型，ISO 26262 采用这种开发模型。
敏捷开发（Agile）：敏捷方法是以人为本的开发模型。设计、测试和需求可以通过迭代随时间演变。这适合于知识密集型的开发，在这种开发中，无法在项目开始时就与客户明确定义需求。互联网用这个。

（2）V-model 的两个阶段和两种验证（Verification 和 Validation）：
项目定义阶段：包括 Requirements analysis 需求分析，System design 系统设计，Architecture design 架构设计，Module design 模块设计。
项目验证阶段：包括 Unit testing 单元测试，Integration testing 集成测试，System testing 系统测试，User acceptance testing 用户验收测试。
Verification：验证。评估产品、服务或系统是否符合法规、要求、规范或强加条件。这通常是一个内部过程。用来回答：Have you built it in the right way?
Validation：验证。保证产品、服务或系统满足客户和其他已确定的利益相关者的需求。它通常涉及外部客户的接受度和适用性。用来回答：Are you building the right thing?

（3）ISO 26262 与 V-model：ISO 26262系列标准基于V型模型，作为产品开发不同阶段的参考过程模型。ISO 26262 的十二个部分与 V-model 的对应关系如图：

2.3.4 智驾开发中的 V-modle 变种

（1）智驾系统属于安全关键系统，也需要遵循 ISO 26262，因此也要按照 V-model 来开发。但是智驾技术仍处在快速变化中，需求并不确定， V-model 灵活性不佳。针对这个问题，业内出现了将 V-model 与敏捷开发结合在一起的新开发模式，称为敏捷系统工程。整个开发过程中，V-model 将重复进行，直到所有的 verification 和 validation 都能以可追溯的形式成功完成。

（2）采用敏捷系统工程，智驾软件的开发思路是把智驾按照场景（行车，泊车）分别进行开发，即 ODD：Operational Design Domain，运营设计域，指的是给定的驾驶自动化系统或其功能专门设计为运行的操作条件，包括但不限于环境、地理和时间限制，和/或某些交通或道路特征的必要存在与否。每个 ODD 就是一个 V-model，通过不断的添加 ODD ，实现新功能并控制复杂度。

3 总结

本文尝试对智驾安全进行了讨论，阐述了汽车或者说智驾行业是如何在工程上落地安全要求的，并简单阐述了 ISO 26262 的自学路径。其实不光汽车行业需要功能安全，未来低空经济，人形机器人也同样需要功能安全，这个方向也很吃经验，值得长期投入。