内容提要：此文为该连载系列的“下”部分，具体从自动驾驶汽车场景的HCL模型应用、示例讨论、未来工作、结论等方面内容进行论述。

概 要   

《自动驾驶功能安全和SOTIF混合分析框架》专题连载共分为“上、中、下”三个部分。此文为该连载系列的“下”部分，具体从自动驾驶汽车场景的HCL模型应用、示例讨论、未来工作、结论等方面内容进行论述。

1、用于自动驾驶汽车场景的HCL模型示例

为了说明此专题连载系列的“上、中”两部分提及的概念框架的应用，我们为自动驾驶汽车开发了一个典型的运行场景，最常见的两车事故场景之一是一辆车停在自动驾驶汽车前方的车道上。在本文中，我们为自动驾驶汽车前方的触发事件“车辆停在车道上”开发了HCL概念模型。

1.1 概念阶段

在概念层面，有一个明确定义的、自动驾驶汽车必须在触发事件“车辆停在车道上”之后完成的序列事件，从而避免事故。自动驾驶汽车必须知道它所在的车道，检测其车道上停止的车辆，决定如何响应，并安全正确地执行响应（例如，转向）。该序列在下面图1中的简单行为ESD中进行了表示。请注意，我们在图中使用术语ego来区分自动驾驶汽车，并将其与场景中的其他自动驾驶和非自动驾驶汽车参与者区分。

图 1：车辆停在车道上的行为 ESD 示例

结合一些基本的ODD信息（例如，速度限制、交通密度）时，这个简单的ESD足以识别几个HARA场景并估计暴露度、可控性和严重度。在ISO26262术语中，导致危害最终状态的每条唯一路径，都是要记录在HARA中的危险场景。从而，可以为每个危险场景确定顶层安全目标和ASIL等级（并可能在未来的场景中重复使用）。

该过程的下一步是将每条路径开发成功能ESD，如下图2所示。对于此示例，我们选择仅从上面图1中突出显示的关键事件2开始开发感知路径。行为ESD中的PE-2和功能ESD之间的连接可以被认为是一个传输门，其中PE-2的补充细节在功能ESD中进行开发。

为什么要把行为ESD和功能ESD分开呢？答案在产品开发阶段。首先构建行为ESD可以仅根据行为要求尽早执行HARA，甚至无需概念开发。功能ESD是则可以用来探索概念架构选项。

同样，我们使用功能ESD而不是FTA来提出概念架构，因为它允许使用更简单的ESD格式，从而更快地提出架构建议。

在这个例子中，我们提出了功能ESD的概念设计，感知功能分为主要（2-A）和备用（2-B）功能。这显然是一个不受行为要求驱动的设计方案，这些关键事件将在FTA层进一步拓展。

为了示例的清晰性，我们将图2中的ESD限制为仅两个关键事件，但可以根据需要通过其他事件进行扩展，以获得更细致的模型。例如，如果这是可能的系统行为，我们可以定义“部分成功”运行的关键事件。这种灵活性允许ESD对具有多种最终状态可能性的复杂场景进行建模。请注意，ESD中的关键事件之间没有独立性的假设。

图 2：仅用于感知路径的功能 ESD示例

2、系统和产品开发阶段

在之前的概念阶段中，尚不存在感知系统设计。工程师在关键事件2-A和2-B中概念性地提出了冗余感知架构。为了将这个例子延续到系统阶段，让我们假设感知系统设计者已经进一步开发了这个提议的设计，如下所述。

2.1 示例系统描述

所提出的设计，将主要(2-A)和备用(2-B)感知功能，放置在使用各种ML算法的冗余计算硬件上。其中，主系统使用激光雷达和摄像头，而备用系统使用毫米波雷达和不同的摄像头。冗余对象检测结果被发送到自动驾驶汽车系统的其余部分，从而进行进一步处理（未显示）。该设计的框图如下图3所示。

图 3：示例感知架构框图

此外，我们假设已经对架构中每个组件的失效概率（在危险故障模式下）进行了估计，如下表1所示。请注意，这些概率值仅用于说明。

表1：假定的组件失效概率

出于本示例的目的，我们将重点关注传感器之间的共因因素。为了简化，我们忽略了计算和 ML软件组件之间的常见共因关系，因为它们是示例的辅助。

2.2 FTA和BN层的开发

我们为关键事件2-A和2-B开发了一个简单的系统级FTA，如下图4所示。对于这个简单的示例，我们跳过了定性FTA步骤，直接进入定量FTA。如上所述，该FTA忽略了诸如其他失效模式、任务时间和常见原因（除了下面提到的）等因素。

如图4所示，FTA形式不足以对高保真度的自动驾驶汽车进行建模。图4中的注释突出显示了FTA未能充分模拟系统的地方。特别是对于传感器，单个传感器的故障不会直接导致感知失败，因此它不是一个正确的或门。然而，一个传感器的故障会显著增加感知失败的可能性，因此它也不是一个正确的与门。BN层中的“noisy”门可以更准确地处理这种类型的复杂交互。

此外，“失败”或“未失败”的FTA状态可能无法充分描述单个传感器的行为。虽然这些状态可能足以满足ISO26262的范围，但它们并未涵盖广泛的SOTIF因素。例如，单个传感器的性能也可能受到驾驶条件的非确定性影响，从而导致中间状态的不确定范围，例如“轻度退化”或“严重退化”。另外，SOTIF域中的软因果因素超出了传感器性能，可能包括天气、照明、驾驶员行为、速度等。

对ML算法的软因果影响，也最好通过BN层中的条件概率来处理。没有简单的FTA共因模型（例如，Beta模型）能够充分模拟传感器和环境条件之间的复杂相互作用。ML算法多种多样，但它们可能间接受到共同传感器环境因果因素的影响。对于这个简单的例子，我们专注于传感器的因果因素，但另一个因素，是否“成功”检测所需的距离（或碰撞时间），会因为最小制动距离而变化，这又可能会受到ODD条件的影响，比如下雨。

图 4：感知事件的系统级故障树示例

本示例的最后一步是详细的FTA和BN层的开发，以解决上面提出的问题。在此步骤中，修改了图4中存在缺陷的FTA，并添加了BN层以解决图4中发现的局限。

组合的FTA和BN层如下图5所示。所有BN节点的条件概率表(CPT)如图6所示。

图5说明了BN如何实现功能安全和SOTIF问题的无缝集成。在BN层中，传感器“故障”的概念已经扩展为更一般的传感器“性能”概念。换句话说，传感器的电子故障和失效（即功能安全）只是传感器性能不佳的潜在原因之一。其他原因还包括SOTIF触发因素，例如下雨或光线不足。在此示例中，我们没有包含传感器性能下降的状态，但可以轻松添加它们。

与FTA一样，请注意此示例中的所有定量值仅用于说明目的。需要说明的是，本示例中未开发用于对自动驾驶汽车系统的FTA和BN层进行严格量化的方法。而CPT中的示例概率旨在说明模型的格式和灵活性。条件概率在逻辑上是一致的（例如，大雨比小雨更糟），但它们不是从真实世界的数据中得出的。

图 5：FTA 和 BN 层之间的集成示例

图 6：BN 层的条件概率表

3、讨论

一旦模型结构的所有三层都已开发，并且节点已被量化，则可以使用文中已经描述的算法对整个HCL模型进行量化。由于系统安全目标是基于ESD层定义的，模型的量化还可以提供与ISO26262、ISO21448一致的ASIL硬件指标以及SOTIF性能指标的量化。

3.1 示例结果的讨论

BN模型可以更准确地描述感知所涉及的多种类型传感器之间的关系，这些依赖关系在BN模型的结构和条件概率表(CPT)中都得到了体现。对于传感器模型，与门已从FTA中删除，并替换为BN事件传感器性能。通过此更改，我们扩展了FTA的严格与门逻辑，从而在BN中包含额外的不确定性和灵活性。在更新的模型中，如果两个传感器都发生故障，则传感器组肯定有故障。但是，如果只有一个传感器发生故障，我们仍然允许通过共因出现可能的故障。在两个传感器都没有故障的情况下，我们允许一些“泄漏”来解释未知数。此表说明了BN Noisy门提供的灵活性。传感器性能的CPT如上图6(a)所示。

此外，证明了软因果因素的结合，它们各自对激光雷达和相机性能的概率影响，已在BN中进行了量化。请注意，Rain节点具有三种可能的状态，说明了BN对非二元变量的能力。相机性能受雨水和光照的影响，因此它具有最复杂的CPT，如图6(b)所示。CPT涵盖了雨水和照明的所有组合的条件概率，在一张紧凑的表格中包含了六种不同的场景变体。

BN层的另一个不直观的好处是BN固有的能力，可以将观察到的证据（或假设的证据）应用于每个BN节点，并更新整个网络的条件概率。例如，我们可能会问这样一个问题：“如果我们在夜间小雨中行驶，而雷达传感器已经出现故障，感知失败的概率是多少？”该问题的相关概率总结如下表2所示。

表2：在BN中应用证据的示例

BN中概率更新的传递也是双向的，这种能力源于贝叶斯定理的使用：

贝叶斯定理允许网络根据A|B的条件概率计算B|A的条件概率，反之亦然。这意味着分析师可以进行从A到B的向前推理（因果推理），也可以从B到A向后推理（证据推理）。

因此，除了如上所示使用因果推理更新顶层系统概率外，BN还可以用于具有证据推理的预测模式。在这种模式下，证据被放置在更高级别的节点上，并且条件概率会自动传播到更低级别的节点。通过这种方式，BN可用于识别观察到的高级别故障的最可能的诱发因素。这些方法也可以组合使用（因果推理），从而在复杂系统中同时存在观察到的原因和观察到的影响的情况下进行推理。

下面图7说明了在BN层中使用双向（即因果关系）推理。在此示例中，我们已经获得了Sensor2集发生故障的证据，因此在Sensor Performance2节点上将故障状态的概率设置为100%。该证据会自动传播到整个BN，如虚线箭头所示。最初，信息向后传播（即证据推理），但一旦到达Rain和Lighting节点，它就开始向前传播（即因果推理）。或许与直觉相反，对传感器2故障的观察，实际上增加了传感器1发生故障的可能性，因为它们把雨水和照明作为共因因素。

图 7：BN 层中的因果推理

3.2 示例中基本要求的讨论

上述示例简单说明了将建议的HCL框架应用于自动驾驶汽车感知部分的单个场景，该示例展示了专题连载“上”部分的“新框架的基本要求表”中所确定的许多基本原则。而且，HCL方法具备满足基本要求的潜力，已在专题连载“上”部分“自动驾驶功能安全和SOTIF混合分析框架（上）：现有体系的局限和解决方案”中进行了详细说明。

在这里，我们将总结在示例中具体说明的要求。

集成与综合能力

该案例研究提供了一个简单的示例，说明如何将功能安全和SOTIF问题集成到一个单一的综合概率模型中。基于场景的模型足够灵活和全面，可以考虑自动驾驶汽车安全分析中的各种复杂性和“软”因素，这些因素通常会从ISO26262分析中排除。

可见，HCL框架代表了一种潜在的方法，用于定量分析ISO21448涵盖的功能依赖关系和触发事件。该标准仍在发展中，尚未提出具体的方法。尽管我们的示例仅限于通用感知系统，但未来我们可以设想该框架用于表征与标准一致的特定功能和行为（例如，在夜间检测被遮挡的行人）。

可维护和高保真能力

图5中集成的FTA和BN层，说明了BN如何扩展FTA以描述自动驾驶汽车应用程序典型的复杂相互依赖性和不确定性。无需关于独立性的不切实际的假设，BN层允许对相关失效进行复杂的表示。如表2所示，该模型可以回答复杂的问题，例如“在雨中夜间雷达出现故障的情况下，系统故障的概率是多少？”允许在风险知情的情况下做出决策。

新技术适应能力

HCL模型的主要优势之一是能够明确承认和表征新技术性能的不确定性。该示例使用HCL模型来描述在不确定的运行环境中，具有复杂感知传感器和机器学习算法的系统。在充分了解性能的情况下，可以明确定义CPT。而且，在工程师不太自信的情况下，BN的“Noisy”门允许将不完善的知识纳入分析。随着新技术得到更好的理解，贝叶斯更新过程为更新HCL模型中的知识更新，提供了一条自然的途径。

基于场景的分析能力

图1和图2中的ESD展示了如何明确定义运行场景序列，以及如何对开发过程分阶段以满足开发流程的需要。实际上，行为ESD甚至可以在定义产品架构之前就开发出来。

例如，在此专题连载的“中”部分“自动驾驶功能安全和SOTIF混合分析框架（中）：HCL开发阶段和方法 ”中所表述的，ESD层提供了更复杂的场景进行概率建模的能力。我们的示例是一个简化的场景，尽管它确实代表了主要的汽车致命事故场景之一。针对复杂自动驾驶汽车场景的进一步开发留给未来工作。

尽管我们认为不太可能，但某些自动驾驶汽车场景可能非常复杂，以至于使用ESD和FTA形式准确表示它们是不可行的，即使使用额外的BN层也是如此。在这些罕见的情况下，HCL框架可以作为这些场景完全基于BN建模的“垫脚石”。而纯BN模型以增加复杂性为代价提供最大的灵活性和保真度。请注意，场景的纯BN模型，仍可能是整个HCL模型的一部分。

基于风险、定量和纳入不确定性

本专题连载旨在在概念层面开发和证明自动驾驶汽车的HCL方法，因此框架定义和示例都没有开发出严格的模型量化方法。然而，量化和不确定性的结合是完整方法的重要方面，因此我们在下面回应一些潜在的问题。

关于量化的可行性：这种常见的反对意见往往来自那些不熟悉贝叶斯概率的人。简而言之，任何定性判断都有与之相关的隐含的定量测量，可以通过多种技术严格得出定量测量及其不确定性。贝叶斯方法将使我们能够严格结合硬证据、软证据和专家意见，根据需要产生定量值和不确定性。

关于量化的重要性：除了具有量化值这个内在工程有用性之外，它还以贝叶斯更新的形式提供了另一个重要的好处。随着从现场不断接收到新数据，具有先前的定量值允许将新证据严格纳入更新的模型中，而此更新过程允许模型在开发过程中不断更新，并在系统的整个生命周期内进行维护。

可论证模型

可论证模型的一个关键方面是可理解的模型。图5很好地说明了HCL模型的可解释性，其中互连的FTA和BN图直观地传达了系统中的相关因果因素。这两层都明确地与图1和图2中ESD中描述的运行场景中的事件相关联。模型的图形结构有助于让非专业人士清楚地了解模型中包含的所有因素。

模型数据的合理性超出了本概念文件的范围。然而，使用说明性数据，我们展示了如何通过合并更灵活的BN层来纠正图4 FTA中存在缺陷和不完整的逻辑。BN中的“noisy”门和软因果因素在CPT中被完全量化，以便为设计决策和/或风险接受决策提供更准确的概率。最终，我们认为，完全量化CPT的要求本质上推动了基础数据的选择和证明的严格性。

可维护模型

由于我们没有在示例中展示量化技术，因此我们没有在示例中明确展示模型的可维护性方面。但是，我们可以定性地观察到，我们在示例中的简单BN层，将来可以根据ODD扩展或现场经验轻松扩展。例如，现有模型可以添加额外的因果因素（例如，雪或雾），或者可以添加全新的因果网络（例如，组织因素）。网络中分配的概率也可以使用众所周知的贝叶斯更新方法基于运行数据进行更新。

标准兼容

该示例通过此专题连载的“中”部分“自动驾驶功能安全和SOTIF混合分析框架（中）：HCL开发阶段和方法 ”的示例图里显示了与ISO26262兼容的步骤，也说明了该方法的实际应用。HCL方法中对功能安全和SOTIF的处理方式提供了ISO26262和ISO21448之间的统一方法。显然，我们的示例中没有明确涵盖ISO26262一致性的许多细节（例如，ASIL目标、安全要求等），但这些部分与文中涵盖的安全分析过程切合。

3.3 未来工作

我们初步探索了在概念层面上开发自动驾驶汽车安全的整体框架。因此，要开发完整的详细框架，还有几个领域的工作要做。

其一，框架的概念阶段需要进一步发展，从开发一套全面的基于情景的ESD的方法开始。其二，需要对构建ESD的过程进行额外定义，包括处理因开发大量场景而不可避免地重复的方法。其三，对于FTA和BN层，我们需要建立一个流程来识别FTA模型的不足之处，以及BN层对自动驾驶汽车最有价值的地方。其四、需要一种严格的方法来量化具有不确定性的BN层。

其五，需要开发更详细的实际示例来演示和验证HCL方法。在ESD层，可以演示更复杂、更详细的场景；在较低层，本专题连载中的简单感知示例可以用具体的细节进行扩展；自动驾驶汽车的其他功能，包括定位、预测和运动规划，也是HCL建模的绝佳实践；ODD因果因素的综合模型及其与自动驾驶汽车全栈的交互将是最终目标。

4、结论

我们制定了新的自动驾驶汽车风险评估和安全分析框架的基本要求，并提出了一个基于已建立的混合因果逻辑(HCL)方法的新框架。新框架允许集成功能安全和SOTIF分析，包括ODD条件和组织因素等软因果因素。这项工作是第一个提出将HCL方法应用于自动驾驶汽车领域的工作。

为确保提议的框架满足自动驾驶汽车领域的需求，我们为任何新的自动驾驶汽车安全框架制定了一套基本要求。为了制定和证明这些要求，我们确定当前自动驾驶汽车安全面临的挑战，以及当前方法的缺陷或局限性。当前的方法和新的方法根据这些要求进行了评估。这些要求也可用于评估任何建议的自动驾驶汽车安全方法。

提议的HCL方法根据已确定的基本要求进行了系统审查，表明HCL满足所有基本要求。为符合ISO26262产品开发生命周期的自动驾驶汽车应用开发了分步HCL方法。然后将该方法应用于简单的自动驾驶汽车运行场景以展示其实用性。进而，根据基本要求对本示例的结果进行评估，并显示其满足一般HCL需求分析所预测的这些要求。

本连载系列文中的HCL方法经过改编并以新颖的方式应用于自动驾驶汽车领域。我们开发了一种运行场景驱动的方法，而不是ESD层的故障驱动方法，以使对各种自动驾驶汽车场景的分析变得可行。将BN层用于表征自动驾驶汽车在不同ODD条件下的SOTIF性能，是自动驾驶汽车领域的一种新方法。出于实际目的，它清楚地展示了HCL框架如何无缝扩展现有的ISO26262方法，以提供一个统一的框架来解决自动驾驶汽车的功能安全和SOTIF问题。

显然，需要一种综合方法来解决自动驾驶汽车系统安全的基本需求。基于对这种方法的基本要求的分析，混合因果逻辑方法似乎是一个很好的候选者，应该进一步开发以应用于自动驾驶汽车。

关注牛喀网，学习更多汽车科技。有兴趣的朋友，可以添加牛小喀微信：NewCarRen，加入专家社群参与讨论。

作者：牛喀网专栏作者
牛喀网文章，未经授权不得转载！