4.3 自动驾驶的安全结构（第四章 车辆的动态建模）

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

学习内容：

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

1. 故障树分析

该方法可作为初步分析框架，并支持逐步扩展至包含所有必要细节。这种自顶向下的方法用于系统性地识别可能发生的事故及其主要原因，在此过程中我们不仅关注可能发生的事故（需避免的情况），还明确事故发生的各种途径以及更低层次子系统的潜在问题。在故障树中，
根节点代表系统发生事故的基本事件，
而中间节点则表示逻辑门，
用于定义根事件发生的潜在原因。
分解过程会持续到能够精确量化这些原因的程度。
通过应用布尔代数规则来整合概率信息，
我们可以评估根本原因事件总的发生概率，
并识别出最可能导致其发生的根本原因。

让我们从一个简化的案例入手，并将车祸设为故障树的根源事件。汽车事故的原因可能被分解为软件故障或硬件故障以及其他危险因素中的危险类。硬件故障通常源于制造缺陷或材料缺陷。同样地，在遭受黑客入侵的情况下，软件错误也可能因感知代码故障或网络安全漏洞导致。我们将在每个连续的分支中深入分析相关的子系统及其具体计算，在这里开始，在每个连续的分支中深入分析相关的子系统及其具体计算，在这里开始，在每个连续的分支中深入分析相关的子系统及其具体计算，在这里开始，在每个连续的分支中深入分析相关的子系统及其具体计算

例如，在独立事件中，OR与AND几率将是子节点几率的加法或乘法。这体现了故障树的基本概念：当考虑叶节点的概率时，默认情况下会构建一个概率故障模型。这种自上而下的安全分析方法不仅在核工业及航空航天领域得到了广泛应用，在自动驾驶系统中也同样适用。然而这一过程也面临着诸多挑战：构建一个全面且精确的故障树模型，并正确识别影响系统的关键风险点并非易事。

2. 故障模式和影响分析

FMEA，它代表失效模式和影响分析。故障树是从系统故障向下延伸到所有可能的原因，而FMEA是一个自下而上的过程，它查看各个原因，并确定可能发生的所有可能的影响。通常，FTA’s和FMEA’s一起被用来评估安全关键系统。
故障模式是指整个系统中某个特定组件可能导致系统失败的模式或方式。
效果分析是指分析所有这些模式失败可能造成的影响。通常，效果分析试图识别那些导致最严重故障的模式，从而改进设计，为系统增加更多的冗余或更高的可靠性。

FMEA背后的核心理念在于通过系统化的方法对潜在风险进行分类与管理。我们的目标是根据故障的重要程度对其进行分类评估，在分析时会考虑以下问题：影响有多大？故障发生的概率如何？检测这些故障是否困难程度如何？通过赋予每个故障一个优先级别值来进行量化分析，并随后集中解决那些具有最高优先级的故障。

步骤如下：
我们的目标是创建一个涵盖所有潜在危险情况的数据表格。
随后与领域专家进行交流，并在表格中明确所需的具体细节。
接着，我们质疑了系统的功能目的，并罗列了可能导致系统故障的所有潜在问题。
针对每一种可能出现的问题
我们会评估其可能导致的影响，并根据其严重程度给予评分（评分范围从1到10分）。
针对每一个结果
我们会找出导致这些结果的根本原因
并进一步分析这些根本原因中的关键因素
并根据其出现频率，在另一个评分维度上给予打分。

然后，在识别所有可能的故障模式时，请注意这些故障模式能够直接由操作员察觉并进行处理。在这些模式导致影响之前，请确保我们能够及时评估其发生概率，并从1-10分区间量化其可探测性（1表示能被探测到的概率非常高），其中1代表肯定能探测到而10则表示完全无法探测到）。最后计算风险优先级数（RPN：risk priority number），即严重程度、发生的可能性以及可探测性的乘积值。该数值越大，则该问题的风险等级越高

最后，在优化我们的系统实现的过程中成功解决了出现频率最高的各类故障模式的基础上

让我们继续采用一种较为简单的评估机制，并通过一个具体的示例来更清晰地阐述这一过程。考虑一个特定的情况：当车辆行驶在覆盖有碎石的道路测试区域时所遇到的技术故障会导致控制器失灵。这种故障可能导致的身体接触风险是最为严重的后果之一；此外还可能引发驾驶员不适或者失控的可能性但这些结果的影响程度均低于前者。这类事件在城市建筑密集区中并不罕见只要涉及特定类型的建筑物就可能出现此类情况因此我们有必要对此进行持续关注假设我们能够计算出事件4的发生频率类似地我们还可以为其他潜在的问题分配当前分数值为此我们可以设定各个因素的重要性等级并据此进行风险评估如果目前尚未发现相关缺陷那么我们的自动驾驶系统在这方面的感知能力就处于较低水平这使得其在整个风险矩阵中的排名靠后事故发生的优先级由各因素的重要性等级相乘得出具体数值在此案例中该优先级值等于10（可探测性）乘以4（发生频率）再乘以10（严重程度）最终得到的结果是400这个数值同样可以用来与其他潜在问题的风险级别进行比较例如另一个可能引发事故的因素是信号接收端出现故障其优先级值达到100另一个问题是GPS定位信号丢失导致导航功能失效其优先级则高达300还有一个问题是车辆运动预测系统出现偏差导致路径规划失误其优先级值为150基于这些信息我们需要采取相应的措施来解决这些问题按照从高到低的顺序依次关注碎石路面行驶带来的技术挑战GPS定位信号丢失所导致的功能中断以及信号接收端可能出现的问题这就是FMEA分析的基本框架

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

与FMEA相比, HAZOP更倾向于定性分析,而FMEA则侧重于定量风险评估。H-zAPO的核心目标是通过群体讨论有效地识别潜在危险,尤其适用于复杂流程的风险管理。与FMEA不同, HAZOPO无需为风险的发生可能性、严重程度及检测手段设定具体数值,因为这种精确赋值往往难以实现。H-zAPO常在设计初期阶段应用于概念设计阶段。其新增的核心要素包括一系列引导语句（如"不"、“多”、“少”、“早”、“晚"）,这些指导语旨在帮助识别可能导致系统失效的各种模式,从而避免遗漏潜在问题。因此,H-zAPOPO本质上是一种简化版的动态FMEA头脑风暴方法

现在让我们聚焦于一种更为具体的网络安全类别，并探讨用于汽车及低级自主系统的现有安全架构。这些架构一般用于评估自动车辆硬件和软件系统的故障情况。特别地，请我们讨论ISO 26262所描述的功能安全方法及其扩展版本，在ISOPAR 21448.1中也被定义为预期功能安全标准。我们无法深入阐述这两个概念，但对于进一步了解，请参阅提供的补充资料链接。

功能性安全(functional safety)是汽车系统中因硬件或软件缺陷导致的异常操作定义为功能性安全问题，并且设计缺陷不会引发不合理后果。该术语缩写为FUSA。

ISO 262标准规范了机动车内电气与电子系统功能安全的技术术语与操作活动。此规范仅限于解决可能影响自动驾驶汽车安全的硬件及软件潜在缺陷。该标准指出了四个汽车安全完整性等级或ASIL等级。其中ASIL D等级最为严格而A级最为基础。每个ASIL等级均与其相应的技术开发要求相匹配，在认证过程中必须满足这些要求。

该程序遵循V型流程进行功能安全管理。始于最左侧上方的功能需求分析阶段，在此过程中识别潜在风险与威胁，并一直到功能模块的具体实现过程。随后转向右侧分支，在此过程中确认设计目标已达成；(如软件单元测试)作为基础验证手段，在此之后通过仿真、测试轨道、操作和道路测试等方法开展子系统及整体系统的验证工作；当最左侧上方的需求达到顶点时（即当左边的V下降至最低点），则意味着高级需求已转化为基础实现步骤；而当转向右侧分支并到达顶端时，则需确保所有基础功能模块均已完成；将这些模块整合起来即可完成整个系统的安全性要求；最终阶段是对整个系统的安全评估进行全面总结，并评估剩余的安全风险水平...判断我们的系统是否达到了可接受的安全水平。

从功能安全阶段V的起点开始, 我们采用HARA方法或危害识别与风险评估（HRA）。在进行HARA评估时, 我们识别潜在危险事件并将其分类; 同时设定避免不合理风险的具体要求。这一流程推动所有相关系统的开发与测试工作。为此目的, 首先确定可能影响汽车安全的硬件、软件故障及非预期功能。这正是我们在功能安全框架中采用FMEA方法或HAZOP技术的原因; 其结果是为我们的系统识别出一系列特定的危害。接着, 在绘制ODD图时必须考虑这些关键场景; 为此我们需要建立一个详细的场景列表.

接下来，在完成全面的风险评估后

在制定系统需求时，请特别关注最坏-case scenarios，并确保所设计的硬件和软件系统能够充分满足这些极端条件的需求。此外，请深入探讨目标功能安全标准（SOTIF）的安全性。根据ISOS 21448标准文档正式定义，在SOTIF中特别关注与系统性能限制及可预测误用相关的故障原因。需要注意的是，在此标准范围内无法涵盖的技术限制（如传感器性能限制及噪声）或算法限制（如目标检测错误及执行器技术限制）所导致的功能不足或性能受限问题。对于上述硬件及软件故障问题，则由ISO 26262的功能安全标准予以规范管理

SOTIF旨在解决因用户预见到的操作失误所带来的潜在安全隐患。该方案不仅针对用户的常见困惑状态进行了优化设计，并且能够有效应对超出正常操作能力范围（超载操作）以及过于自信可能导致的安全漏洞（过度自信）。当前的标准划分为0级、1级和2级自动化目标。然而，在实际应用中发现该方案不仅适用于三级及以下自治级别，在实施过程中可能还需额外考虑相关因素以确保系统的稳定性和可靠性。在设计过程中采用了类似于V型开发模式的方法论框架，并在此基础上进行了相应的优化与扩展以适应功能安全需求