内容提要：此文为该连载系列的“中”部分，具体对自动驾驶汽车HCL模型和开发方法进行解析，含括ESD分析的概念阶段、具有FTA/BN分析的系统和产品阶段等方面的内容。

概述

《自动驾驶功能安全和SOTIF混合分析框架》专题连载共分为“上、中、下”三个部分。此文为该连载系列的“中”部分，具体对自动驾驶汽车HCL模型和开发方法进行解析，含括ESD分析的概念阶段、具有FTA/BN分析的系统和产品阶段等方面的内容。

可在本专栏中查阅“自动驾驶功能安全和SOTIF混合分析框架（上）：现有体系的局限和解决方案”。

1、自动驾驶HCL模型和方法的开发

通过此专题连载系列的“上”部分，我们已经确定了HCL框架的要求和潜在优势，那么在本文中，我们将注意力转向开发方法。本文的目的是在概念层面上描述完整的自动驾驶汽车HCL框架开发方法。我们将明确方法中的各个步骤，并对每个步骤进行描述。

为了进一步展示标准兼容性，该方法中的步骤以ISO26262生命周期为基础，使用传统的V型开发模型。

V型开发模型的初始阶段是(i)概念阶段、(ii)系统级开发以及(iii)产品开发（包括硬件和软件）阶段。我们的重点将放在前三个阶段，以建立概念性HCL框架。

我们无需了解ISO26262各个阶段的详细信息即可理解该方法。其他系统开发模型，例如敏捷、螺旋和DevOps，通常不包含在当前的自动驾驶汽车安全标准中，并且超出了本文的范围。然而，随着这些模型的安全实践变得更好，HCL框架的集成可能是未来研究的一个领域。

2、ESD分析的概念阶段

下面的图1显示了在ISO26262概念阶段背景下HCL方法的初始步骤，其中白色圆框显示HCL步骤，而灰色框显示与传统ISO26262交付成果的关系。该过程使用熟悉的ISO26262输入：描述功能行为、约束和项目边界的相关项定义和描述、运行和环境条件的运行设计域(ODD)定义。显然，HCL流程满足ISO26262中的HARA和FSC开发步骤，同时还产生兼容的HARA与FSC输出。接下来，我们将依次单独讨论这些步骤，以展示HCL对自动驾驶的应用和必要的调整。

图1：HCL 模型方法论第1部分：ISO26262概念阶段

2 .1 场景发掘

开发一套完整的驾驶场景在很大程度上是一个归纳过程，很难证明其完整性。为了帮助实现完整性，场景启发可以从多种来源中获取，包括但不限于：

•NHTSA碰撞前场景

•监管要求的测试用例

•公司开发的测试和仿真场景（和结果）

•自动驾驶汽车驾驶日志和脱离报告

•ODD的专家分析

•场景和行驶分类文献

•自动驾驶汽车事故报告

•结构化的头脑风暴

可见，简单地采用HCL方法并不能自动解决场景完整性问题，但该方法有望实现(i)减少场景变量，(ii)事故序列的可视化表示(iii)重用ESD中的行为和功能，以及(iv)迭代开发。

然而，改变事件（例如，天气、速度、照明）的概率，但不改变序列结构的参数，要放在BN的条件概率层，而不是ESD层。很明显，这种方法将所需场景排列的总数减少了几个数量级。

同时，ESD格式提供了事故序列的清晰、完整的可视化表示，非专业人员也可以轻松理解甚至构建。ESD中的关键事件可以代表任何类型的不确定事件，包括系统故障、系统决策、场景参与者的存在或场景参与者的行动。与传统的ISO26262 HARA不同，ESD还可以在一张图中直观地表达多种可能的事故序列和最终状态。

ESD形式主义提供了超越传统事件树分析(ETA)的额外功能，让人们相信它能够充分模拟自动驾驶汽车可能遇到的各种场景。简单的ESD可能表面上类似于传统的事件树，但ESD形式扩展了ETA的几个关键特性，包括：

•随机和确定性时间延迟

•时间条件和竞争事件

•物理变量条件

•并发独立序列

•序列同步

•收敛序列和循环过程

有一些例子说明了ESD对航空航天、化学品和无人海洋领域中复杂的动态序列建模的能力。我们相信这些证据，有力证明了ESD形式足以模拟任何自动驾驶汽车场景，但需要更深入的工作，来充分开发自动驾驶汽车的ESD方法。

另外，ESD的简洁、明确的格式还可以识别场景和子场景之间的“等价类”，从而减少模型中的重复。例如，无法检测到自动驾驶汽车前方的车辆，对车辆是停止、减速还是缓慢行驶几乎没有影响。序列的结构基本相同，可以在多个场景中重复使用。

需要注意的是，ESD中采用的细节级别的灵活性，允许使用具有更少、不太详细序列的高级模型获得有价值的结果，然后再用更详细的序列改进ESD。我们通过将ESD开发分为行为ESD（针对HARA）和功能ESD（针对FSC），展示出方法的这种灵活性，也可以修改提议的方法以满足开发过程的需要。

2.2 行为ESD开发

行为ESD是一种高级ESD，它描述了自动驾驶汽车成功驾驭一个场景所必须表现出的顶级行为（或车辆级功能）。此ESD的主要目的是执行基于场景的HARA，以识别安全目标和相关的ASIL目标。

使用关键事件，行为ESD还描述了自动驾驶汽车在场景中可能表现出的高级不当行为。这种分析可以通过行为指南关键词表来辅助。

需要注意的是，这一级别的分析是独立实现的，并且不同于传统的功能分析，例如功能危害分析(FHA)。ESD允许明确映射功能之间的条件关系，从而避免逐个功能分析的限制。例如，一个功能的不当行为可能会创建一个新的子序列，从而触发对其他功能不同的行为需要。

2.3 ESD危害分析

此步骤可能与典型的ISO26262 HARA流程非常相似。ESD中从起始事件（即场景）到危险最终状态的每条“路径”都是HARA中要考虑的一个项目。根据起始事件、关键事件和最终状态的属性，可以估计每条路径的暴露度、可控度和严重度参数。

然后，可以将安全目标与每个项目（即路径）适当地关联起来。与传统的HARA类似，如果安全目标是相同的，则它们可以在场景之间共享。

2.4 功能性ESD开发

在此步骤中，通过将行为分解为功能和子功能，对行为ESD进行了修订和扩展。每个具有安全目标的路径都经过单独分析，以识别潜在的安全障碍和其他关键事件。

虽然，最初的ESD分析纯粹针对行为，但功能ESD旨在获取较低级别的功能行为和不当行为。行为ESD可以同样描述人类或机器的行为（例如，检测行人），但功能性ESD开始设定特定的机器功能（例如，主要感知和备用感知）。而ESD结构则可以通过早期的系统架构来建立。

功能性ESD还可能包括其他场景因素，不仅仅是硬件和软件故障，例如时间延迟、竞争事件和其他可能影响场景结构的随机事件。另外，关键事件可以获取任何结果不确定的事件。具体来说，ESD关键事件还可以获取SOTIF触发事件和缺陷，从而实现功能安全和SOTIF的集成。

2.5 ESD架构分析

在前面的危险分析步骤中，分析了每个ESD中通往危险最终状态的每条路径，从而得出安全目标和ASIL等级。然后，在功能性ESD开发步骤中，对每条路径进行单独分析，从而识别潜在的安全障碍和其他关键事件。

在概念阶段的最后一步，通过评估详细路径，从而确定哪些关键事件将被记入以降低风险，哪些功能将被指定为安全关键。同时，安全关键功能将被分配与顶级安全目标一致的ASIL目标，并将导出功能安全要求。其中，每个功能安全要求对应于功能ESD中的一个关键事件。而在ISO26262术语中，此步骤对应于功能安全概念和ASIL分解。

3、系统和产品阶段

ESD分析完成了生命周期的概念阶段后，在系统级和产品开发阶段，FTA和BN是主要工具。

下面的图2继续显示HCL方法的步骤，这次是在ISO26262系统和产品开发阶段的背景下，格式类似于图1。

我们将依次讨论HCL的每个步骤，从而开发FTA和BN层在自动驾驶汽车环境中的概念应用。

图2：HCL模型方法论第2部分：系统和产品阶段

3.1 系统级FTA开发

系统级FTA开发的过程，与传统ISO26262流程中的情况类似。

前面步骤中的安全目标(SG)和功能安全概念(FSC)，为提出技术安全概念(TSC)提供输入，从而实现更高级别的要求。

可见，SG、FSC和TSC一起形成了一个层次化的需求树，构成了初始系统级FTA的结构基础。这种将需求映射到FTA的过程，启动了完善TSC和FTA的迭代过程，而FTA结果向设计团队提供了有关可能需要修订TSC的单点故障、常见原因和潜在故障等问题的反馈。初始系统级FTA具有典型的定性特征，侧重于对系统结构进行建模，并确保一套完整、一致且可行的技术安全要求来实现安全目标。

在HCL环境中开发FTA，其中有一些附加功能，下面将简要概述。首先，每个FTA顶级事件都源自特定运行场景中的特定ESD关键事件。因此，可以在了解确切的运行环境的情况下构建FTA，从而进行更详细和准确的分析。例如，与分析“无法感知车辆”不同，ESD更丰富的上下文，可能会给我们“无法感知在闭塞交叉口从左侧接近的车辆”。显然，更具体的ESD上下文，不仅简化了FTA分析，而且通过仅包括相关变量（如车辆左侧的传感器），便使分析更加准确。

随着FTA的构建，我们还可以寻找事件之间比FTA的AND/OR逻辑更复杂的逻辑关系。

同样，我们可以开始确定通常会被排除在FTA之外的“软”因果因素，例如，接近车辆的速度会同时影响碰撞的严重度和概率。而这些关系和因素，为下一步的BN层提供输入。

集成ESD和FTA层的一个副作用是HCL模型通常包含相对大量的故障树，但每个故障树都较小（仅与故障树的方法相比）。此功能有助于模块化，但可能会导致模型中的一些冗余。在评估大量场景时，ESD关键事件和FTA事件之间存在重复或者差异很小的可能性。幸运的是，可用的HCL软件能够通过传输门和其他功能来处理这种复杂性。

3.2 概念BN开发

此步骤采用上一步中确定的软关系和因果因素，并开始开发定性BN的结构。

根据系统特性和建模需求，这些因果因素可能包括：

•组织因素（安全文化、能力、时间压力等）

•复杂系统行为（ML/AI、卡尔曼滤波器、复杂软件等）

•人为行为（错误、反应等）

•ODD条件（天气、速度、照明、功能等）

在此步骤中，FTA中的基本事件与BN中的影响因素相关联。在某些情况下，如果BN提供了更准确的表示，则可以替换FTA的整个子树。

请注意，由于可用参数数量较多，BN层始终能够生成比FTA更准确的模型，但代价是增加了复杂性。这取决于建模者的判断来确定在哪里进行权衡。

3.3 FTA细化与BN细化

所提出方法的最后一步是开发详细的FTA和BN层。本专题连载首先提出了概念框架的开发，因此这些步骤的细节留给未来工作。有兴趣的朋友，可以添加牛小喀微信：NewCarRen，加入专家社群参与讨论。

更多内容，请关注：“自动驾驶功能安全和SOTIF混合分析框架（下）：HCL模型示例及讨论”，关注牛喀网，学习更多汽车科技。

作者：SCCM特邀专家
牛喀网文章，未经授权不得转载！