3.3 自动驾驶的安全结构（第三章 自动驾驶汽车的安全保障）

3.3 自动驾驶的安全结构（Safety Frameworks for Self Driving）

学习内容：

    **1. 通用的安全架构**
    	事故树（故障树）：Fault Trees Analysis （FTA）
    	故障模式和影响风险：Failure Modes and Effects Analyses （FMEA）
    	危险及可操作性分析：Hazard and Operability Analysis (HAZOP)
    **2. 汽车安全结构**
    	功能安全
    	预期的功能安全

1. 故障树分析

故障树作为一种初步分析框架，并具有良好的扩展性能力以涵盖关键细节；这种结构采用自顶向下的方法进行设计与分析，在这一过程中逐步优化并确定所有潜在风险及其影响路径。

故障树的顶部节点是根事件或顶部事件。

故障树中的中间节点是逻辑门，它们定义根事件的可能原因。

逐步分解直至能够精确定义此类事件的概率等级。通过运用布尔逻辑法则结合概率理论来实施故障树分析，并评估根本原因事件的整体发生概率及其最主要的触发因素。

让我们考虑一个简单的例子，并以车祸作为根事件。

汽车事故可能由软硬件及其他风险类别构成，并包含我们在视频中详细阐述的其他潜在风险。同样地，其原因通常源于制造缺陷或是材料质量问题。同样地，在遭受黑客入侵的情况下……软件错误也可能是感知代码出现故障或是网络安全漏洞所导致。由此我们能够深入探索软件子系统及其内部的具体运算过程，在递归过程中逐步增加层级深度以完成相应的运算任务

最终目标是实现某个特定的故障率指标。
我们可以通过设定来分配每个单位时间或每个单位里程发生的概率值。
当前阶段已经抵达了故障树分析中的叶子节点阶段。
接下来采用逻辑门结构模型可以进行后续的概率计算。
通过明确计算方法可以得出总体系统的故障率分布情况，在已知各叶子节点故障概率的前提下进行分析。
这些用于向上推算概率的操作遵循集合论中关于事件发生概率的基本法则。

例如，在独立事件的情况下，“OR运算的结果等于子节点概率之和或乘积”。这体现了故障树的基本概念——当考虑叶节点的概率时，“故障树被称为概率故障树”。这种基于自顶向下的安全分析方法广泛应用于核能行业、航空航天领域以及自动驾驶技术中。其主要挑战在于构建一个全面且精确的故障树模型，并准确识别影响系统安全的关键事件（即叶节点事件）的概率值。

2. 故障模式和影响分析

FMEA，它代表失效模式和影响分析。

故障树是从系统故障开始向其所有潜在原因展开分析的过程；反过来是自上而下的方法；它通过分析各种原因来识别可能导致的不同后果。通常，在评估安全关键系统的风险时，通常会同时应用FTA和FMEA的方法来提高安全性评估的有效性。

故障机制是指整体系统中某一关键单元造成系统失效的方式。

效果分析是指分析所有这些模式失败可能造成的影响。

通常情况下而言，在进行效果分析时, 研究者们旨在识别导致系统出现最严重故障的模式, 并通过优化设计流程来提高系统的冗余度和可靠性水平。

FMEA的核心概念在于通过优先级对故障模式进行分类以提高系统的可靠性。因此我们通常会询问以下相关问题：

    影响有多严重？
    故障发生的频率有多高？
    检测这些故障有多容易？

随后我们采用优先级值来评估所有故障的风险等级并被要求处理风险等级最高的故障

步骤如下：
我们的目标是构建一个包含所有可能的危险情况的表 ，

最初，我们与领域内的专业人士就某个问题展开讨论，并在表格中明确具体的细节要求。

然后，我们对系统的目的提出质疑，并列出故障的失败可能性。

然后我们对每一种失败的可能性进行了鉴定，并分别给予每个后果一个等级评分（1至10分），其中最高分为最严重的状况。针对每一个结果, 我们识别可能导致结果的根本原因, 并分别按1至10的评分区间评估其发生频率。

然后，在识别所有的故障模式时需要注意的一点是这些故障模式必须能够被操作员直接察觉并采取相应的维护与排查措施。为了确保这些异常情况能够及时得到处理我们会在每个周期内测定该模式的可探测性并将结果以1至10分的形式给出其中1分表示该问题必定会被发现而10分则意味着该问题几乎无法被察觉。

在确定风险优先级数（RPN）的过程中，在最后阶段我们需要确定一个关键指标。这个指标是将三个因素相乘得到的结果：严重程度、发生概率以及被发现的可能性。

最后，在优化我们的运行机制时，我们集中解决了造成最多问题的故障模式。此外，在实施FMEA方法时也可以根据故障树分析中实际发生的故障概率来实施，并依据在固定运行周期内可能出现的关键事件概率来设定可接受的风险阈值。这种方法不会影响数字的价值及其在整个分析过程中的重要性。

我们可以继续采用简便的方法，并借助一个具体的例子来阐述FMEA的过程

针对某一特定故障, 即因道路施工而导致测试区域出现的一层覆盖着碎石的道路, 这一情况将导致控制系统出现不稳定状态。最坏的情况可能导致严重的身体伤害, 且会引发严重的后果。然而, 这一情况也可能造成驾驶员不适, 或者接近失控的状态（较为轻微的情况）。这种情况在城市中较为常见, 尤其是在有这类建筑的地方频繁发生, 所以这一情况是有可能发生的。假设我们可以计算出4的发生次数

同样地, 我们可以对其他效果给予当前分数. 假设该问题尚未被检测到, 因为道路表面纹理未在监控期间进行, 我们的自动驾驶系统. 所以, 在诸多因素中排第十. 事故的风险优先级是10乘以4乘以10, 即400

同样的情况下, 我们也可能面临其他类型的失效模式. 具有100级优先级的信号感知问题, 或者是与GPS相关的同步问题, 也可能是具有150级优先级的车辆运动预测问题. 因此我们必须着手解决这些失效实施的问题, 通过重点关注砂砾行驶的情况, 而不是依赖GPS失效或运动预测失效.

最后涉及信号感知这一环节。这通常代表FMEA的基本架构。该方法源自军事与航空航天产业的发展，并已在汽车制造领域得到应用推广。它提供了一种系统性地量化与管理风险的有效方法。

危险和可操作性研究: HAZOP（Hazard and Operability Analysis）

与FMEA相比 HAZOP 更像是一种定性分析工具 在FMEA中 我们倾向于通过定量方法来评估潜在风险 因此 HAZOP 的核心目标是通过群体讨论有效地识别可能存在的危险因素 对于复杂的工艺流程 HAZOP 可以帮助我们对风险进行初步评估 无需为每个风险事件的具体发生概率 严重程度以及检测手段预先设定具体数值 这种做法在实际操作中往往难以实现 HAZOP 方法通常在系统设计的初期阶段用于辅助概念设计阶段 在HAZOP 中 我们会引入一系列引导性词汇 如"不" "多" "少" "早" "晚" 以引导团队围绕每个系统需求展开头脑风暴 每个词汇对应着一种特定的风险模式 如果这些模式未被提及 可能会导致潜在问题未被识别 因此 HAZOP 实际上是一种简化的动态性 FMEA 头脑风暴执行方法

让我们聚焦于一种更具体的安全类型，并深入探讨用于开发自动汽车及其低级自主特性的现有安全架构。这些架构通常被用于评估自动汽车硬件和软件系统的故障行为。特别地，在ISO 26262中描述的功能安全方法以及扩展至ISOPAR 21448.1中定义的预期功能安全方法方面，请您了解这两个过程的具体细节？如果想了解更多细节，请参考提供的补充材料链接。

功能性安全（functionality Safety），简称FUSA，在汽车领域具体表现为车辆在运行过程中因硬件或软件问题导致的功能异常状态或设计预想之外的行为表现，并且不会带来不合理风险。

ISO 262规范了机动车内电气与电子系统中功能安全的关键术语与操作活动。由此可知，在自动驾驶汽车的安全性方面存在潜在风险的情况下，则只能采取硬件或软件解决方案。本标准制定了四个汽车安全完整性等级体系：其中ASIL D级别最为严格，在此等级下实施的安全设计要求最为苛刻；而A级则代表着最低的安全等级，在这种情况下实施的安全设计要求相对较为宽松。每个等级均与其对应的开发要求紧密相关，在认证过程中必须满足这些要求

功能安全程序遵循v形流程。

始于左侧上方的需求概述，在右侧架构中展开对潜在危害及风险的全面评估与应对策略制定。随后推进功能模块的具体实施步骤，在右侧技术架构下完成各子系统的开发与整合调试工作。由基础性验证（例如软件单元测试）作为起点，在仿真实验室中建立完善的功能运行环境，并通过仿真平台、测试轨道模拟以及操作场景等多维度验证手段来完成子系统及整机系统的综合检验工作。当左侧技术路径中的V值降至零时，在右侧架构中高级需求将逐步转化为基础性实施方案；而当达到右侧顶端节点时，则需整合所有底层功能模块并对其运行效能进行全面评估以确保系统达到安全稳定运行标准。

在完成功能安全V的评估后进行总结，并对剩余风险进行分析以确认系统的安全水平是否符合预期要求。在HARA过程中，我们不仅识别危险事件并对其进行优先级分类，还明确制定了避免不合理风险的具体要求。这些步骤推动了超出当前范围的所有系统开发和测试工作。

为了实现这一目标，我们首先确定了可能影响汽车安全的软件问题与硬件问题以及其他非预期功能。这些分析过程正是在功能安全框架中采用FMEA或HAZOP方法时所涉及的内容，并从而导致我们系统面临一组特定的危害。

然后，在系统绘制我们的Odd图时必须执行的一系列场景中建立一个场景列表。随后，在危险事件和情况之间建立联系后需描述预期损失并确定风险参数随后需计算每种情况与危险组合下的潜在风险数值。在完成风险评估后需选择面临最高风险的情景每个可能发生的故障可能导致最坏情况的发生

最后，在考虑所有可能的极端情况时（或称作最坏情况），我们制定了我们的安全标准（或称作安全需求）。HARA流程旨在确定系统的功能边界（或称作设计目标），以便全面识别所有可能出现的极端情况（或称作潜在风险）。通过验证测试确保在极端情况下系统的响应机制不会导致不可接受的风险（或称作失败处理）。这体现了功能性安全的核心思想。

您应当优先关注那些可能发生的极端需求，并确保硬件和软件配置能满足基本要求。

对此，我们可以对其安全特性进行深入分析，并明确指出其在该文档中的具体规范。SOTIF体系主要考察与系统性能瓶颈及可预判性误操作相关的潜在故障源点。鉴于技术层面的制约（例如传感器性能界限及噪声影响），以及算法层面的缺陷（包括目标识别失误与执行机构的技术瓶颈），这些因素可能导致系统性能受限以及功能无法完全实现。

硬件与软件故障由ISO 26262的功能安全标准进行处理，并超出SOTIF的能力范围。SOTIF通过解决由于用户预期误操作引起的不安全性来扩展其能力。例如，在操作困惑、过载操作以及过度自信的情况下，则会超出其适用性范围。当前SOTIF的标准将目标设定为自动化级别，并涵盖第0至第2级功能安全等级。然而，在第三至第五级功能安全等级的应用中，则需要采用额外措施加以支持。

作为功能安全流程的一个延伸项目,SOTIF特别针对当前自动驾驶技术中的关键问题进行优化,并采用了类似于V型架构的方法论框架,但在此基础上增加了新的功能模块.为了系统性地识别潜在风险,HARA模型被用来帮助发现由于性能限制或操作不当所导致的安全隐患,随后按照设计、测试和验证等阶段依次展开,确保所有安全要求均获得满足.