Safety for Automated Driving-01

本文主要关注自动驾驶安全第一白皮书 / Safety First for Automated Driving 中第2章 Safety by Design的内容。

先总结我需要的部分 : )

以及具体探讨 iso26262功能安全 和 iso21448预期功能安全 以及这里不太关注iso21434网络安全 的部分之后再做详细整理。这里只粗略整理一下白皮书中涉及的部分。

Basic

SAE 等级

Structure Overview

1 Twelve Principles

安全运行：自动驾驶汽车必须能够应对其任何关键部件的受损。

安全层：自动驾驶汽车必须了解自己的限制，并了解何时可以安全地将控制权转交给驾驶员。

设计运行区域（Operational Design Domain，ODD）：自动驾驶系统可以安全运行的条件，包括地理位置、道路类型、速度范围、天气、时间、国家和地方性交通法律法规。

交通中的行为：汽车的行为需要其他道路上的驾驶员可以预测，并且必须根据交通规则采取行动。

用户责任：车辆需要能够识别驾驶员的精神状态，并向他们传达他们需要负责的任何任务。

由车辆发起的操控权交接：无人驾驶车辆必须能够让驾驶员知道何时需要移交，并使其易于操作。如果忽略了接管请求，则车辆还需要有一种在最小化风险的同时应对这种情况的方法。

由车辆操作人员发起的操控权交接：驾驶员需要有一种方法明确要求接管自动驾驶汽车的操作。

自动化的影响：甚至在自动驾驶结束后，自动驾驶汽车也必须考虑自动化对驾驶员的影响。

安全评估：需要一种一致的方式来验证和确认自动驾驶汽车满足安全目标的能力。

数据记录：如果自动驾驶汽车识别出事件或事件，它必须能够以不违反相关数据隐私法律的方式进行记录。

网络安全性：安全的自动驾驶汽车将需要针对安全威胁采取一些保护措施。

被动安全性：自动驾驶汽车需要针对可能是车辆自动化特有的任何碰撞情况做好准备。

2 Safety by Design

系统地开发可靠性以支持通过设计实现安全

流程：

简单地说

1 以12原则${}^{\, [1]}$(+法律框架)为要求找到需要的系统能力(能力的目的)，以及能力与12原则的关系(2.1.6)，

2 能力的实现需要哪些要素${}^{\, [3]}$(2.2.2)，每项能力对应需要哪些要素(2.2.1)，以及 具体示例 (App. A)

3 将要素连接成通用体系结构(2.3)

4 可靠性${}^{\, [2]}$将作为这些整个设计过程的安全保障(2.1.3 - 5)；

• $[1]$ 12原则 功能性+安全性
• $[2]$ 可靠性/Zuverlässigkeit/dependability 是安全性要求，指在这些方面需要做到可靠(安全安保无故障)。
• $[3]$ 要素/Element 在这边就是指哪些组件/设备/数据来实现这些能力，比如能力 FS_1 车辆位置的确定 需要通过环境感知传感器，先验感知传感器以及自车运动来判断。

2.1.a 可靠性领域

the dependability domains

主要阐述了三个可靠性领域：预期功能安全、功能安全和信息安全。

即自动驾驶汽车从组件到整车要确保的安全性。包括

• 元件/设备是否正常工作的功能安全，
• 元件/设备虽然没坏但是还是没有达到预期功能的预期功能安全，
• 以及自动化智能化而需求的联网和通信功能带来的信息安全安保。

2.1.4 功能安全

即 ISO 26262，功能安全旨在避免电子电气系统故障导致功能异常而引起的不合理的危害。

2.1.3 预期功能安全（SOTIF）

即 ISO 21448。蕴含了从 L2 拓展到L3/L4的安全需求变化，单纯的保障电子电气功能安全，已经无法继续降低自动驾驶的安全风险。

SOTIF需要考虑的汽车的安全风险来自预期功能不足或人员误操作。这些不属于ISO26262的范畴。

• 预期功能不足：可分为3个模块的功能不足（误触发/漏触发）。比如传感器和相应算法在大雾天气下不能正确识别其他车辆。
  • 自动驾驶功能的基础模块 / 机器人学与控制学中 sense - plan - act 这三步都有可能产生预期功能安全不足。
• 合理预见的人员误操作：比如交互界面设计有缺陷导致误启动/解除自动驾驶功能。

SOTIF场景识别与目标：
◆ 1 安全已知区域 ◆ 2 危险已知区域 ◆ 3 危险未知区域 ◆ 4 安全未知区域

措施&迭代式改善流程：

• 区域1的措施

  • 明确定义要开发的功能，以：

    • 通过分析识别潜在的风险

    • 发现不足时完善定义

      将使用与ISO 26262 类似（但不相同）的风险分析方法来分析功能和技术规范。如果检测到不足，则将对功能或系统进行改进。

• 区域2的措施

  • 验证功能，包括其系统组件，以：
    • 对功能（包括其驾驶情景）仿真
    • 测试系统组件以及整个系统
    • 确认在出现不足的情况下，可以对功能或系统进行的改进
    • 确定剩余风险可接受性的依据

• 区域3的措施

  • 确认功能系统：
    • 减小区域 3 至可接受水平，如通过耐久性试验、驾驶测试、仿真等

简单地说，

对于区域2 通过分析识别出场景-针对场景开发出策略-对场景做仿真测试-根据结果做优化设计。V模型。

对于区域3 通过实车运行，仿真测试积累数据，将危险未知转换为危险已知，减小区域3。

2.1.5 汽车信息安全

即 ISO 21434

Safety 与 Security

Safety侧重于系统的正常运行，Security性则侧重于系统抵抗某种形式的故意恶意行为的能力。安全性主要担心被动攻击、自然随机性和人为造成的事故及碰撞所引起的风险；而安保性则担心以有意识的创造性、确定性和恶意行为形式的主动攻击所带来的风险。

当从L2 扩展到L3 或L4 车辆时，信息安全面临的挑战是自动驾驶功能严重依赖于外部数据，例如传感器信息、地图、定位信息等。

措施：

1. 安全开发生命周期

   我感觉安全开发生命周期SDL不单单属于2.1.5汽车的信息安全，而应该是这个3个domain从定义到开发到维护，都应该考虑的流程。而且这个概念主要来自于ISO26262也就是功能安全。

   

   SDL 通常都会将实践广泛分为三类，即预备、开发和维护：即 概念阶段，产品开发阶段 和 生产运行阶段。

   • 预备包括培训以确保开发组织内具备基准知识，以及制定政策、程序和指南，以确保其余过程具备必要的基础。
   • 开发包括软件工程中熟悉的常规做法，例如安保性要求定义、威胁建模，静态和动态分析、模糊测试、代码审查和渗透测试等。
   • 最后，维护包括事件响应、更新签核程序和其他确保产品在发布后继续运行的实践。

2. 深度防御安全架构

   深度防御从低级别组件开始并且贯穿到单个设备、设备组（可形成一个独立系统，例如感知）、 车辆本身和支持车辆所需的基础设施。自动驾驶嵌入式系统采用传统信息安全三要素（CIA）：保密性、 完整性（包括真实性）、可用性。

   • 组件级别：
     • 例如微控制器、ECU、摄像头传感器
     • 一些基本元素可用于安全地实现机密性、完整性和真实性
     • 要求：
       • 确保微控制器实现或集成硬件安全模块或类似的专用硬件，在其上可以构建更高级功能所使用的加密功能
       • 建立组件防篡改、可配置性（例如，删除或禁用不需要的功能）和可更新性的功能
   • 设备级别：
     • 例如激光雷达、雷达、摄像机单元等
     • 组件建立的安保性也被充分利用
     • 要求：
       • 建立固件和软件的完整性和真实性（安全启动）, 加密和验证消息，验证被授权升级设备的实体，以及验证升级本身
       • 减轻针对设备的DoS 攻击的功能，以及如何防止来自设备的意外信息泄露
   • 系统级别：
     • 要求：
       • 系统内各个设备之间整体通信的安全、向其他设备证明每一设备的安全状态、抵御共享通信信道情况下的拒绝服务攻击
       • 安全冗余机制：
         • 利用传感器融合和交叉引用（多种模态中感知内容）迫使攻击者需要在多个不同设备之间进行协调攻击，才能欺骗整个系统
         • 多个独立安全系统
   • 整车级别：
     • 要求：
       • 人员对车辆的访问是受限的，并且基于功能进行隔离。

   

2.1.b 能力/功能

2.1.6 能力要求

能力分为失效安全能力(FS)和失效降级能力(FD)。

• 失效安全能力提供并实现客户价值。失效安全能力可以中断，因为它们的不可用性和安全之间的相关性足够低或者被失效降级能力覆盖。

  指一个设备，即使有特定失效下，也不会造成对人员或其他设备的伤害

• 即使在发生故障的情况下，失效降级能力也应在一定的性能水平下执行，以便在特定的时间段内提供一个安全的系统，直到进入一个达到允许系统退出的最低风险状况（MRC）。

所以 能力FS是实现安全的系统运行的必要不充分条件，安全(标称)状态必须所有FS都能正常运行，否则进入降级运行状态(一个合适的MRC)，最终进入最终MRC(自动驾驶系统完全退出后的状态)。能力FD要保障失效时可以通过降级达到暂时安全状态的能力。

简单地说 检测到FS功能不行了，那就要开始降级到退出了，这时需要FD功能作为一步一步的降级判断。

2.1.7 MRC 和 MRM

最低风险状况MRC和最低风险策略MRM，有可容忍的风险级别。MRM 是一种到达MRC（被称为安 全状态）的紧急操作。

在这里 MRC不仅仅是一个静止状态(停车)，也可以是降级后运行中的车辆/驾驶员接管后的车辆。而最终MRC指自动驾驶系统完全退出后的状态，例如静止或被驾驶员接管。

应使用列出的MRM 在整个系统中反映潜在的故障模式。应采用一些分析方法，其中还可能包括失效分析技术，如FMEA 或DFMEA 等。可以利用额外的分析方法对系统的预期用途和误用进行分析。上述分析技术输出的结果定义了每个组件的安全状态，以及这些状态如何激活系统中的MRC 和MRM。

2.2 要素

2.3 通用逻辑架构

本章没有系统设计的具体实现。

2.1.6.1 节介绍了通用的感知- 规划- 执行设计范例，并通过功能安全和预期功能安全进行扩展，从而推导出自动驾驶系统的能力要求。

2.2.2 节介绍了用于实现自动驾驶能力的逻辑组成部分（要素）。通过整合第2.2节能力的信号链可以导出一套通用架构。由此产生的逻辑体系结构完整说明了不同要素之间的连接和信号流。

除了2.2 节描述的要素之外，为了代表目前技术水平，还应满足一组附加要求。每个要素都应具有失效安全和/ 或失效静默模式（取决于具体系统设计的各方面）。在任何情况下，都应观察单个要素或要素组合的当前性能和失效并报告给系统监视器。冗余要素应该避免从属失效，因此它们应该按设计分开。

最后一步是将能力分配到要素上。所有能力、所有要素都被分配给至少一个能力，并且所有要素都相互连接。

3 V&V

引用

[1] 自动驾驶安全第一白皮书 / Safety First for Automated Driving

[2] ISO ({2011}). Road vehicles – Functional safety [Norm]. ({ISO 26262}) ISO, Geneva, Switzerland

• Previous
  计算机体系结构-02
• Next
  Safety for Automated Driving-02