基于模型的自动驾驶行为安全概念方法

A.通过架构观点分离关注点

ISO 26262安全相关活动的一个关键步骤是定义功能和技术安全概念。这些现有的工件为我们在本文中提出的概念化提供了基线。功能安全概念和技术安全概念都是从不同角度与系统架构设计相关的安全措施规范：前缀功能和技术可以映射到技术中立（功能）和技术特定（技术）安全措施。

观点是系统工程中的概念，旨在构建参与定义系统架构的利益相关者的关注点。定义不同的观点实现了一种分而治之的策略，该策略允许将系统描述集中在上述利益相关者关注的问题上（例如，表达系统的功能（与功能相关的问题）与如何实现这一点（与技术相关的问题））。

Nolte和Nolte and Maurer关注的是关于自动驾驶汽车设计的更抽象的解决方案中性问题，强调了操作观点的重要性。根据INCOSE10德国分会的系统架构框架（SAF），这种观点“满足了概念阶段的信息需求”。为了将这一观点应用于自动驾驶，针对技术中立（和功能相关）的问题，系统架构框架里是这么解释的：功能域视角解决的是系统需求定义过程中的信息需求问题。举个例子，它会把运行域（也就是预期的落地方案）里的实际使用场景，转化成系统功能层面的概念，以此定义系统需要具备的行为逻辑。

在自动驾驶汽车的设计工作中，运行视角描述的是：在对应运行条件下，自动驾驶汽车作为整个社会技术体系的一部分，会表现出怎样的行为。也正因为如此，ISO 21448里提到的车辆层级分析，完全可以归到运行视角的范畴里。而功能视角，讲的是自动驾驶汽车内部的系统功能，比如行业常用的感知-规划-执行这套模式里的各个功能模块。本文后续做的概念梳理，其中一个结论就是：站在运行视角讨论时，我们称其为“自动驾驶汽车”；站在功能视角讨论时，我们就用“自动驾驶系统”来指代。

B.架构视角与ISO 26262现有安全概念的对应关系

结合架构视角的相关概念，再加上我们对ISO 21448的分析，我们得出结论：要想把标准要求系统地落地，用来规范安全行为，最好能有一个专门的安全概念，针对运行域里的目标行为明确对应的安全措施。接下来我们就分析一下，现有安全标准里已有的术语体系，能不能支撑这件事。

先从ISO 26262里的基础定义说起，功能安全概念的定义是：功能安全需求的规范，以及配套的相关信息、这些需求在架构各组成元素中的分配方式，还有实现安全目标所需的各类交互关系。从这个定义就能看出来，功能安全概念的规范范围，并不局限在单个（子）系统当中。

例如，Bergenhem等人讨论了通过严格应用ISO 26262指南来解决SOTIF相关问题的可能性，从整体项目定义和细化开始。

因此，功能安全概念能够涵盖ISO 26262和ISO 21448范围内的安全措施。

Stolte等人表明，这种与SOTIF相关的要求可以包含在功能安全概念中。由于在实践中，功能安全概念通常局限于（子）系统视角，这种扩展可能会给行业带来实际挑战。

ISO 26262要求对项目进行定义。项目可以在从车辆级到小型子系统的不同组成级别上定义。如果将小型子系统定义为项目——如传统上实施的——则抽象级别存在潜在差距：鉴于应在车辆级识别危害，在较低级别定义的项目将安全需求的范围限制在特定系统功能（及其技术实施）。

将车辆在其背景下（即系统的社会技术系统）定义为一个项目的替代方案导致了与本文中提出的概念类似的概念化。

将功能安全需求分配给要素（也就是系统、组件、零件或单元）更容易解释为面向系统的功能视角，而不是面向上下文的操作视角。由于ISO 26262中采用了功能视角，通常会为项目外部但仍是车辆一部分的其他（子）系统指定外部措施。因此，只有当车辆被定义为项目时，车辆级安全措施，例如目标行为的精细规范，才会被视为该过程的一部分。虽然ISO 26262没有禁止将车辆级项目的表述和上下文元素解释为其他交互系统，但SOTIF的创建已经建立了自己的概念来定义车辆级分析的需求。

功能安全需求被定义为“独立于实施的安全行为规范或独立于实施安全措施，包括其安全相关属性”。虽然该定义没有明确，但功能安全需求是否规定了特定系统的安全措施。本说明强调了功能安全需求的潜在重点，即在ISO 26262的背景下实现功能的系统，而不是操作角度。因此，根据其定义，不需要在车辆层面定义功能安全需求。

因此，ISO 26262中规定的功能安全概念可以包括解决指定目标行为不足的安全需求。然而，从操作角度对专用安全需求的规范可以从运行角度和功能角度之间的关注点分离中受益。

C.ISO 21448中目标行为安全措施的概念化

为了详细说明功能和操作层面的需求分离可能是什么样子，我们继续分析ISO 21448术语。按照ISO 21448的定义，“功能修改”指的是“对功能规范做出的更改”。但这份标准本身并没有给“功能规范”下明确的定义。结合整份标准的表述逻辑来看，车辆既定的目标行为显然是功能规范的组成部分。所以我们认为，功能修改的覆盖范畴里，也包含针对自动驾驶汽车目标行为制定的安全措施。这类功能修改需要明确规范下来，用来缓解甚至消除那些已经识别出的、会带来不可接受风险的危险行为。

但问题是，ISO 21448同样没有给“危害行为”这个术语下明确定义。再加上标准里没有对“行为”做体系化的概念梳理，到底该怎么界定和描述危害行为，就变得很模糊。标准里有时候直接提“危害行为”，有时候又表述为“车辆层面的危害行为”，反而让概念的边界更不清晰了。为了让表述有统一的参照，Graubohm等人给出了明确的定义：车辆的某一特定动作会引发至少一种危险，且这种动作能在一段时间内，以运动或动态行为的形式从外部被观测到。本文后续提到的危害行为，都沿用这个定义，也就是仅站在车辆层面来描述。

除了“功能修改”之外，ISO 21448里还用到了“SOTIF措施”这个说法，但同样没有给出明确定义。在标准第8章“应对SOTIF相关风险的功能修改”中，也没有把SOTIF措施和功能修改这两个概念做明确区分。标准里列举了不少常见的SOTIF措施，比如系统修改、功能限制、权限移交，还有应对合理可预见误用场景的相关措施。但SOTIF措施和行为规范修改之间到底是什么对应关系，标准里并没有讲清楚。

D.相关安全标准中的安全措施

除此之外，我们也参考了IEC 61508和ISO指南51这两份文件，它们都提供了风险管理方面的通用指引。根据这些安全标准，风险管理需要在操作层面和功能层面进行明确的风险表示。ISO 21448没有为SOTIF活动指定此类显式表示。特别是，ISO 21448没有规定如何将剩余风险评估追溯到实施的功能修改所预期的风险降低。相比之下，IEC 61508明确引入了必要的风险降低和安全完整性的概念。必要的风险降低通知规定了“通过E/E/PE安全相关系统和/或其他风险降低措施实现的风险降低，以确保不超过可容忍的风险”。安全完整性规定了“E/E/PE安全相关系统在规定时间内在所有规定条件下圆满执行规定安全功能的可能性”。结合起来，这种概念化能够在整个产品生命周期中明确表示和管理风险。ISO 26262规定了汽车安全完整性等级（ASIL），该等级将IEC 61508的指南应用于汽车领域。与ISO 26262相比，ISO 21448没有定义与汽车安全完整性水平相当的标准，也没有提供明确表示必要的风险降低和安全完整性的指导方针。对于规范和设计，ISO 21448甚至明确规定，第6条和第7条中与风险评估相关的技术假设不一定与第8条中的SOTIF措施相关，但仍然可以追溯到规范和设计。Van Eikema Hommes认为，根据IEC 61508将风险降低和安全完整性归因于安全功能的要求不适合创新系统，因为关于失效率的知识通常尚未建立。但ISO 21448明确要求，风险可接受标准必须做清晰的评估，这就没法直接沿用ASIL认证里那套偏定性的安全措施逻辑，只有随机硬件失效率的限制是例外。也正因为如此，针对自动驾驶汽车目标行为的安全要求，得同时有定量和定性两套风险降低的思路才行。

总的来说，我们梳理了现有汽车安全标准在术语定义和实操指引上的不足——这些标准本来就是用来明确管控自动驾驶特定目标行为风险的。可恰恰是规范本身的缺失，反而成了自动驾驶汽车的一大风险来源。

结合安全工程相关标准的行业背景，我们先梳理了当前已有的安全概念体系。本节会以安全标准里的通用既定术语为基础，正式介绍行为安全需求和行为安全概念这两个核心定义。上一节我们已经分析过，ISO 26262里现有的安全概念和相关要求，是能够覆盖ISO 21448的对应要求的。同时，我们强调了专门考虑运营观点和在行为规范中明确表示风险降低的潜在好处。因此，本节介绍了为指定目标行为指定安全概念的术语和定义。

A.将行为安全需求整合到ISO 26262的要求和设计流程中

图2概述了本文对ISO 26262和ISO 21448现有概念的扩展。我们在本节中详细阐述了ISO 26262中所述的要求和设计流程的整合。

图2：安全需求和设计流程，包括ISO 26262概述的扩展，蓝色

1）目标行为与行为能力

在第一节中，我们给出了一个简化的例子，说明如何针对规范不足和各自的风险指定和评估目标行为。在之前的出版物中，我们将目标行为定义为参与者在特定场景背景下应表现出的（内部和外部）行为的“规范”[…]。“为了将这些概念作为更成熟的需求规范的一部分，我们还参考了行为需求（简称行为相关的利益相关者需求）。

对于自动驾驶汽车行为的安全评估，行为能力是Nowakowski等人提出的一个术语，近年来得到了更广泛的采用。自动驾驶汽车安全联盟将行为能力定义为“ADS功能在其ODD内操作车辆的预期和可测量能力”。反过来，系统能力是系统工程中的一个既定概念，通常被定义为系统在给定性能下实现结果的潜力。

2）行为安全需求

为了提供基于ISO 26262中现有功能安全需求概念的术语，同时明确承认从操作角度来看专用规范的潜在好处，我们引入了行为安全需求的概念。

与SOTIF在车辆层面的功能安全需求对称的行为安全需求的定义是：独立于解决方案的安全措施规范，包括其安全相关属性

3）功能安全需求与行为安全需求的关系

在第2节中，我们指出，从操作和功能的角度明确区分功能安全需求是不必要的，并强调了这种分离的潜在好处。如果将操作和功能观点分开考虑，则可以应用以下概念：在ISO 26262中，实施独立性将功能安全需求与技术安全需求分开，而两者都需要定义一个项目（即车辆中的系统）。与从功能安全需求到技术安全需求的推导类似，行为安全需求可以推导到作为自动驾驶汽车（一部分）的感兴趣系统的功能安全需求（如图2所示）。行为安全需求的解决方案独立性很重要，因为目标行为是从操作角度指定的。因此，在不假定初步系统架构的情况下，自动驾驶汽车被视为交通环境中的代理。对于从功能角度来看的功能安全需求，对称属性是实现独立性。Nolte描述了从操作角度的需求到功能角度的需求，以及代理和资源的概念。

行为（安全）要求规范考虑了代理自我载体及其在系统边界内的运行条件。在特定场景中，运行条件可以是实体（及其行为）以及环境条件。自我车辆由自动驾驶系统等资源实现，该系统具有某些功能，从而满足功能（安全）要求。功能（安全）要求具体化了行为（安全）需求，因为它们规定了感兴趣的系统如何在车辆层面促进目标行为。Stolte等人给出了一个行为安全需求的例子。“车辆必须能够沿着一定宽度的驾驶走廊行驶。他们将这一特殊要求定义为“一般要求”，作为功能安全概念的一部分。这也突显了行为安全和功能安全概念之间分离的可能性。因此，感知系统特有的功能安全需求是：“[感知]系统应检测车辆环境中的相关物体。”

B.对ISO 21448术语的扩展

根据我们的定义，行为安全需求指定了面向上下文的安全措施，可以通过系统的功能修改来满足这些措施。因此，行为安全需求可以作为提高目标行为和功能修改之间可追溯性的一种手段。目标行为范围内的一种可能的安全措施是任何类型的修改规范。这种修改可以包括进一步的运行条件、机动选项的限制、性能标准的调整和行为能力的规范。

1）行为安全概念

根据行为安全需求的定义和功能安全概念的定义，与SOTIF的功能安全概念对称的行为安全概念定义是：行为安全需求规范、相关信息、行为能力分配以及实现安全目标所需的相互作用。相关信息包括必要的风险降低和安全需求所需的安全完整性。相比之下，功能安全概念中的相关信息包括ASIL。

2）行为安全概念与系统架构的整合

在产品生命周期中整合行为安全需求需要分配给系统架构。在ISO 26262中，功能安全需求被分配给项目系统架构内的元素。相比之下，行为安全需求被分配给车辆层面的行为能力（见图2中的“映射”）。这使得在特定的操作环境中能够进行基于性能的评估，例如自动驾驶汽车安全联盟所述。ISO/TS 5083引入了“安全能力”一词，用于类似目的。除了评估感兴趣系统内的功能接口外，这种评估还评估了自动驾驶汽车在指定运行条件下的行为性能。如今，这种评估通常是作为系统验证的一部分进行的，在系统验证中，系统性能是根据安全目标进行评估的。从概念上讲，安全目标仍然是车辆层面的最高安全需求。也就是说，它们的作用不受行为安全概念的影响（见图2中安全目标和功能安全需求之间的持久关系）。然而，验证过程可以补充行为安全概念，以提供针对特定场景的行为能力评估。虽然在安全目标层面的验证仍然是必要的，但行为安全概念支持在具有特定情境性能标准的定义场景中进行结构化评估，而不是在任何场景下都必须满足的最坏情况假设。

3）行为安全概念与车辆级SOTIF策略的关系

最后，需要讨论行为安全概念与车辆级SOTIF策略（VLSS）的关系。ISO 21448将VLSS定义为一组车辆级要求，用于支持设计、验证和确认活动，以实现SOTIF。“基于这一定义，行为安全概念和VLSS都是一组车辆级要求。与VLSS相比，行为安全概念的范围仅限于目标行为的安全需求。因此，行为安全概念专门从操作角度指定安全措施。相比之下，VLSS还可以包括指定自动驾驶系统功能的要求，这些要求可以分配给功能视点。例如，ISO 21448的附件D.1规定了模式转换期间驾驶员信息的要求。行为安全概念中包含的（行为安全）要求的一个重要方面是必要的风险降低和安全完整性的属性。VLSS不需要此类标准，因此也不作为ISO 21448中规定的评估剩余风险的SOTIF活动的一部分。因此，行为安全概念对安全措施的规范引入了重大约束，因此可以成为VLSS的一部分，但并不等同。

总之，引入的术语和定义及其与系统和安全工程既定实践的整合有助于将车辆级规范和系统级规范之间的关注点分开。基于这一概念基础，我们在下一节中引出了行为安全概念的要求。

本文的核心目的是补充配套概念，让SOTIF相关工作更好落地，因此整套概念框架的核心参考依据就是ISO 21448。这一节我们就拆解标准中关于目标行为规范的目标与要求，受本文研究范围限制，我们只从标准第5至第10条中提取对应需求。

针对规范与设计环节，ISO 21448给出了不少指引和建议，但除了两个相对抽象的目标之外，并没有提出太多硬性的强制要求。标准里写明：“本条款的核心目标有两点：a）规范与设计所包含的信息，需足以支撑所有SOTIF相关工作开展； b）每完成一轮SOTIF相关活动的迭代，规范与设计都要按需同步更新”。这两项要求都没有明确规范和设计里必须包含哪些具体内容，只举了一些可能相关的示例，比如自动驾驶车辆与行人、骑行者、其他道路使用者的交互逻辑，对应的环境条件、道路基础设施等，都可以纳入规范与设计的范畴。对应到行为安全概念上，就要求它必须覆盖这类信息，能够为规范与设计的合规文档提供支撑。

标准第6条“危害识别与评估”要求，必须系统地识别车辆层面预期功能带来的危害；同时要系统梳理危害行为可能造成伤害的场景，评估对应风险，且评估工作必须对照既定的可接受标准开展。下一节我们会具体说明，行为安全概念如何承载满足这些要求所需的全部工作产出，比如危害项、风险估算值、可接受风险阈值、运行条件、验收标准等。为了让SOTIF工作的结构更清晰，我们还在第6.C小节专门设计了对应风险分析、风险评估、风险处置三个环节的专属模型视图。

第7条“识别潜在功能不足与潜在触发条件”设定了两个目标：a）必须识别出规范层面的潜在不足、性能层面的潜在不足，以及各类潜在触发条件，包括合理可预见的直接误用，梳理清楚所有会导致危害行为的因素；b）必须评估系统的响应是否满足SOTIF的可接受要求。 基于这些硬性要求，行为安全概念需要具备完整记录已识别功能不足与触发条件的能力。我们此前的研究已经验证，基于行为的分析方法能够帮助系统地识别这些内容，但行为安全概念本身并不承担识别功能不足与触发条件的作用，这点后面会具体展开。

针对“应对SOTIF相关风险的功能修改”，ISO 21448第8条也设定了两个目标： a）应对SOTIF相关风险的措施必须明确规定并落地执行；b）规范与设计的输入信息必须同步更新。要把这些要求落实到目标行为的规范中，我们建议从不同的架构视角区分安全措施，这和ISO 26262采用的思路是一致的。更具体来说，我们提出了“行为安全需求” 这个概念（第3节有明确定义），专门用来界定车辆层级的安全措施。因此行为安全概念并不覆盖元件层级的SOTIF相关风险，那些为了解决元件层级不足、但需要在车辆层级明确的安全措施，要纳入迭代式的SOTIF生命周期中统筹整合。基于这套概念框架和ISO 21448第8条的要求，行为安全概念需要通过行为安全需求来定义安全措施，把识别出的不足、触发条件和功能修改串联起来。下一节我们会说明，通过明确规定所需的风险降低程度和安全完整性，能够更便捷地评估既定安全措施是否达标。

第9条“验证与确认策略的定义”的两个目标是：a）必须制定SOTIF的验证与确认策略，明确验证目标，同时需覆盖以下考量：对潜在危害场景的必要评估、对相关场景空间的充分覆盖、所需的各类证据（比如分析结果、测试报告、专项调研），以及生成证据的具体流程；b）必须说明所选验证确认方法与验证目标的合理性。本文重点讨论的是行为安全概念在规范与设计环节的价值，因此没有深入拆解它对验证确认工作的支撑作用。不过结合标准第9条的要求，我们也初步分析了它的潜在价值：行为安全概念属于设计类的工作产出，本身不提供自动驾驶车辆的测试结果，所以在界定场景覆盖范围这块作用有限；但它内部基于交通规则分析制定的严谨行为规范，能给整个场景空间搭建起清晰的框架。制定验证确认策略本身就需要对运行环境、车辆目标行为做出结构化定义，除此之外，概念里明确记录的各场景风险水平，也能为验证目标的制定提供部分理论支撑——毕竟验证目标本身就是根据所需的风险降低程度和安全完整性要求来定的。

在ISO 21448所有的强制性章节中，唯一明确提及具体行为相关内容的，是第10条“已知场景的评估”。该条款设定了五个目标：a）必须评估已识别的潜在危害场景是否会构成实际危害；b）系统及其元件的功能，必须能适配已知危害场景和合理可预见的误用场景；c）必须评估车辆层面规定行为中，潜在的危害行为是否在可接受范围内；d）需按照验证与确认策略，充分覆盖所有已知场景；e）验证结果必须能够证明已达成验证目标。要开展已知场景评估，前提就是必须明确定义车辆层级的预期行为。

这项评估主要分两个核心维度：一是系统验证层面，判断系统性能能不能达到既定的目标行为要求；二是需求验证层面，对照规范本身的不足，评估目标行为本身设得合不合理。行为安全概念对这两个维度都有支撑作用：评估系统性能时，有完整记录的目标行为风险可接受标准作为参照；做需求验证时，有明确记录的运行条件、机动选项假设（也就是设计假设）作为依据。

总的来说，从上面的需求推导能看出来，我们提出的行为安全概念是一项很实用的工作产出，能够在整个SOTIF生命周期里支撑多项SOTIF目标落地。把车辆层级的要求清晰规范出来，能给ISO 21448里已有的工作产出补充更明确的结构。不过因为本文的研究范围只限定在SOTIF生命周期的规范与设计环节，所以后面的应用示例不会涉及它对后续SOTIF目标的支撑作用，相关的重要局限性我们会在第7.B小节详细说明。

这一节我们从三个维度讲解行为安全概念的生成逻辑。每个小节都会具体说明，如何生成一套能够承载前述各类工作产出（比如功能不足、行为安全需求）的行为安全概念。生成行为安全概念的核心步骤，隶属于我们此前提出的风险管理方法体系。虽然这些步骤可以直接嵌入SOTIF安全生命周期中，但我们这套模式更聚焦于行为维度。相比之下，ISO 21448本身并没有明确区分车辆层级与元件层级的工作。

A.将方法整合到显性风险管理体系中

我们此前的研究提出过一套显性风险管理方法，并且已经将其应用到了行为规范的制定工作中。对行为规范落地显性风险管理之后，就能梳理出对应的行为安全概念。由于本文重点讲解行为安全概念的生成逻辑，因此我们在图3中汇总了它包含的所有产出物，并且按照风险管理的基础步骤（风险分析、风险评估、风险处置）做了颜色区分，这些步骤都是制定行为规范安全需求的必要环节。整体而言，这套方法将安全措施分为两类，分别对应不可接受风险的两种成因：一种是目标行为本身就具备危害性（根源是规范本身存在不足），另一种是实际运行行为与目标行为出现了危险偏差（比如由性能不足导致）。

图3：行为安全概念包含的产出物概览 灰色产出物是生成安全概念的前置必备内容；青绿色产出物在风险分析阶段生成；紫色产出物在风险处置阶段生成

1）危害目标行为的风险分析

作为先决条件，行为安全概念需要对目标行为和行为能力进行初步规范。例如，这样的初始规范基于交通规则，但应包括其他利益相关者的需求（即规范行为）。此外，可以对所需系统在其操作环境中的危害有初步了解。初始目标行为根据场景中考虑的运行条件指定了机动选项。在将明确的安全措施指定为行为安全概念的一部分之前，需要对危害事件、危害行为及其潜在原因（即功能不足、触发条件和启动条件）进行分析。在风险分析过程中，需要识别因合规执行规范而导致的危害行为。这种危害行为是由目标行为中的规范不足造成的。

造成这种不足的原因可能是，例如，缺少运行条件或对如何在这些条件下行事的错误结论。

ISO 21448为此类分析提供了多种示例方法。例如，STPA可以作为一种结构化方法来识别自动驾驶系统的触发条件、功能不足和危害行为。Zhu等人提供了一种识别此类运行条件的适应性方法。他们通过使用HAZOP关键字来识别危害行为。同样，有多种定量风险评估方法可以支持行为安全概念的产生。

最后，风险分析应导致对已识别危害行为造成的风险的估计。由于行为安全需求规定的安全完整性取决于没有安全措施的危害行为的初始风险，因此需要明确估计初始风险。

2）危害目标行为的风险评估

之前的分析为决定指定目标行为的风险是否可接受，或者是否需要将明确的安全措施作为行为安全概念的一部分提供了基础。如果估计的风险高于可接受的风险，则需要指定必要的风险降低措施。相应的安全完整性取决于为没有安全措施的自动驾驶汽车的目标行为确定的初始风险。正如风险接受标准一样，风险评估可以是定性和定量的。如果确定风险不可接受，则需要指定安全目标。在之前的工作中，我们表明，基于作为行为安全概念一部分的更详细的上下文描述，安全目标可以变得更加详细。虽然这将开放环境的一些复杂性转移到了指定的安全目标上，但更细致、更具体的安全目标规范可以带来更有针对性的风险管理。

3）危害目标行为的风险处理

基于指定的安全目标，行为规范的安全措施需要被确定为行为安全概念中的核心工件（见图3）。根据初始目标行为，应明确行为规范中已经包含的安全措施，或者需要指定新的安全措施以实现必要的风险降低。例如，这些措施可以是在某些运行条件下调整或排除机动选项。这些安全措施由行为安全需求规定。除了功能修改的概念外，行为安全需求还需要分配风险降低和安全完整性，以满足安全目标。为了在系统架构和行为安全概念之间建立可追溯性，行为安全需求被分配给行为能力。在不同的环境中，可能需要一种行为能力来满足多种行为（安全）要求。例如，在多种情况下都需要确定安全跟车距离的能力。因此，行为能力支持开发人员管理复杂性，因为能力在多个场景中持续存在。相比之下，行为安全需求与风险降低和安全完整性有关，具体取决于环境。

图4：量化风险的汇总和分解，以捕捉估计和可接受的风险，以及必要的风险降低，作为Hofmeister和Kinalzyk的扩展。概率被建模作为说明。危害的严重程度在危险事件描述中进行了编码

从设计的角度来看，特定于上下文的能力可以支持功能架构和系统级需求的规范。从验证和确认的角度来看，对能力的抽象支持了对现有系统功能是否充分实现能力的评估。

4）危害偏离目标行为的风险分析、评估和处理

第5-A1至5-A3节侧重于规范不足造成的危害行为的风险管理。也就是说，指定的目标行为本身会导致危害事件。在本节中，我们将详细介绍针对目标行为危害偏差的风险管理（即风险分析、风险评估和风险处理）。我们假设在此步骤之前已经彻底处理了危害目标行为。

与危害目标行为的风险分析类似，危害事件也需要识别与目标行为的偏差。有演绎和归纳两种方法来识别由偏离指定目标引起的危害事件行为。这种偏差的原因可能是性能不足（例如传感器范围有限）、元件级别的规格不足（例如致动器在低环境温度和低电压值的组合下运行不足）。与第5-A1小节和第5-A2小节类似，根据风险接受标准估计和评估危害行为造成的风险。如果确定风险不可接受，则规定安全目标和行为安全需求。这可能包括系统元件需要满足的更高的性能要求。或者，可以调整目标行为，例如，如果必须通过提高系统性能来实现的风险降低是不可行的（例如，增加必要的传感器范围而不是降低行驶速度）。在完成风险处理步骤后，再次评估剩余风险。行为安全概念中记录了已识别的危害行为、功能不足、触发条件以及指定的安全措施。

B.明确的风险表示

虽然上一节侧重于行为安全概念生成的定性方面，但本节阐述了行为安全概念中风险的定量概念化。这方面的主要目标是为每项行为安全需求制定明确的必要风险降低规范。为了明确此类行为安全措施，还需要对所考虑的情景进行定量风险分析和评估。

Hofmeister和Kinalzyk阐述了明确表示所考虑场景的原因。作者建议将全球验收标准分解为基于危害的验收标准，然后根据所考虑场景中的危害行为对这些验收标准进行实例化。除了全球验收标准外，这种针对特定环境的验收标准还可以评估没有一组特定的个体受到自动驾驶汽车的过度威胁。Hofmeister和Kinalzyk认为，不考虑这一方面的评估方案将违反德国伦理委员会的建议。

为了对风险接受标准进行分解，行为安全概念明确地捕捉了关于所考虑的运行条件的假设。图4说明了我们如何扩展Hofmeister和Kinalzyk的工作，明确规定了必要的风险降低（Rred，nec（x））。在危害分析和风险评估中，在多种情况下识别危害事件，估计其风险（Rest（x）），并根据规定的可接受风险水平进行评估（Racc（x））。

在之前的工作中，我们阐述了在指定可接受的风险和风险接受标准的过程中面临的挑战。ISO 21448要求选择能够有效代表相关利益相关者接受风险的风险接受标准，并应通过公开讨论来告知。此外，基于风险接受标准推导可接受的目标风险涉及风险评估期间的多种假设。行为安全概念可以支持这些过程，因为它对运行条件以及明确规定的行为安全措施及其假设的风险降低做出了假设。根据对估计和可接受风险的评估，可以确定特定危害事件的必要风险降低。

在以下方程式中，我们使用标量表达式进行简化。这也会影响所选的风险度量。有多种替代（关键性）指标以及风险指标的不同表示。这些指标中的每一个都有不同的假设。行为安全概念不假定某种风险度量或替代度量。相关风险指标的定义取决于正在进行的研究，也与安全案例设计领域当前的安全绩效指标工作有关。

将风险简化为奇异标量值意味着以下方程描述了多种风险表示（例如估计和接受的风险）的定量关系。这些方程式不足以进行实际的风险管理。每个方程式都说明了需要定义为行为安全概念一部分的约束和假设。

方程式1定义了必要的风险降低是由估计风险和可接受风险之间的差值决定的。如果估计的风险低于可接受的风险，则不需要指定进一步的风险降低。参数x是可变的，因为我们将详细说明风险可以在多个抽象级别上描述，并涉及不同的工件。

包括IEC 61508和Fowler的考虑因素，我们进一步区分了标称风险降低（Rred，nom（x））和安全完整性风险（Rsi（x）。由于安全完整性可以描述为圆满执行必要风险降低的概率，因此需要通过指定的安全措施实现的标称风险降低需要高于必要的风险降低。因此，必要的风险降低被定义为标称风险降低与安全完整性之间的差值的绝对值（在方程式2中）。

Hofmeister和Kinalzyk提出了一个总体风险水平（即估计风险和可接受风险）。Favarò等人以及Koopman和Widen也指出了总体水平和事件水平风险评估的必要性。我们扩展了Hofmeister和Kinalzyk的工作，明确表示了总体水平和事件水平必要的风险降低。在事件层面，危害事件被归因于必要的风险降低（我们将其定义为Rred，nec（HZEj，i）），并被纳入由所考虑的危害事件实例化的常见危害规范（我们定义为HZj）。危害事件的定性组成为共同危害，由方程式3定量计算

它要求具有相同共同危害的所有危害事件的必要风险降低需要高于或等于该危害的总必要风险降低（方程式3）。由于该需求仅涵盖已知的危害事件，因此需要额外的安全裕度S来考虑未知危害事件的风险。然而，S的校准不在本文的范围内，因为我们关注的是可以根据已知危害事件估计的风险，以便在行为安全概念中指定专门的安全措施。

根据ISO 26262，每个危害事件都需要至少一个安全目标（我们定义为SGj，m）来解决。在实践中，安全目标是在如此高的层次上指定的（即它们是顶级安全需求），以至于安全目标与危害之间的关系比安全目标与危害事件之间的关系更强。定量地，我们定义了为安全目标指定的必要风险降低必须高于或等于危害的必要风险减少的要求（方程式4）。

行为安全概念记录了所考虑的危害事件、其各自的（总体水平）危害以及指定的安全目标。由于车辆层面的安全措施规范需要对自动驾驶车辆的运行环境做出多种假设，因此为其应解决的危害事件规定了行为安全需求。行为安全需求（Rred，nec（BSRm，n））的风险降低需要满足其相应安全目标的指定风险降低。

因此，在风险分析和评估期间对运营环境的假设与风险处理的运营环境假设之间建立了可追溯性。也就是说，行为安全概念记录了两种假设。在风险分析过程中，记录了为识别和评估危害事件而假设的运行条件。在风险处理过程中，记录了根据行为安全需求实现风险降低的运行条件。这些假设需要在部署之前进行验证，但也需要在整个产品生命周期中进行监控。

风险的定量汇总和分解为风险评估提供了理论基础的一个方面。从定性上讲，行为安全需求也规定了必要的风险扣除。通过语义规范行为分析等方法，开发人员还能够整合利益相关者在身体健康之外的需求，这些需求通常难以量化，但在风险评估中可能需要考虑。

C.集成到基于模型的系统工程方法中

在汽车领域，基于模型的系统工程（MBSE）尚未完全采用。例如，基于模型的设计在ISO 21448中只提到一次，在ISO 26262中有详细说明。相比之下，MBSE是航空和航空航天等学科开发安全关键系统的既定手段。例如，其他领域利用MBSE，因为使用更传统的基于文档的方法在整个开发过程中处理技术系统的复杂性以及所需的严谨性变得低效和无效。虽然行为安全概念并不关注组成自动驾驶系统的技术系统的复杂性，但它针对的是包括自动驾驶汽车及其环境在内的社会技术系统。由于这一操作层面的复杂性是确保自动驾驶安全的主要挑战之一，我们采用基于模型的方法来展示行为安全概念的规范。在本节中，我们提出了一个基于模型的框架来表示行为安全概念的内容，该框架基于Nolte的架构框架和相应的SysML配置文件。该框架建立在RAAML元模型的基础上，并将其范围从ISO 26262专有概念扩展到ISO 21448的范围。其他可用作基线但也需要根据ISO 21448范围进行定制的架构框架是统一架构框架和系统架构框架。

SysML概要文件中架构框架的这种具体实现不是本文的贡献。相反，我们关注的是描述SysML配置文件语义的概念模型。因此，所提出的行为安全概念并不局限于SysML作为特定的建模语言。特别是最近发布的SysML v2，例如，可以在未来的工作中研究其潜在的好处。同样，我们不依赖于我们用来实现所提出的（元）模型的工具集的特定属性。

在前面的章节（第5-A小节和第5-B小节）中，我们表明行为安全概念的一个核心方面是风险的明确表示。虽然对于功能安全，ISO 26262中已将既定的安全措施定义为确定的ASIL的一部分，但ISO 21448没有为自动驾驶汽车的目标行为规定安全措施，包括预期的风险降低。因此，行为安全概念的规范和评估取决于在危害分析和风险评估以及风险处理过程中对假设的明确表示。因此，我们以ISO 31000的方式介绍基本元模型：风险分析、风险评估和风险处理。同时，我们提供了元模型和我们在上一节（第5-A小节）中介绍的风险管理活动之间的映射。

1）风险分析

在风险分析中，主要目标是识别潜在危害及其来源。因此，图5中的元模型将术语风险作为车辆层面的潜在危害。为了确定和量化自动驾驶的风险，业界和学术界通常会采用基于场景的方法。因此，需要表示危害场景，包括相应的危害事件。虽然ISO 21448中没有定义“危害行为”一词，但它对SOTIF的因果链至关重要。根据我们在第二节中的文献综述和第2节中讨论的背景术语，我们将危害行为概念化为在某种情况下可能造成伤害的车辆运行。

图5：与行为安全概念生成相关的风险分析术语的概念模型

由于行为安全概念的范围仅限于ISO 21448，我们关注的是作为危害行为原因的功能不足，不包括系统故障的安全措施。组合起来导致危害事件的运行条件要么是触发条件，如果它们由于功能不足而导致危害行为，要么是启动条件，如果它导致（危害）车辆操纵导致危害事件。启动条件是我们引入的一个术语，用于使SOTIF危害事件模型中的危害和危害事件之间的因果关系更加明确。

ISO 21448将“包含危害可能导致危害的条件的场景”称为危害和危害事件之间的过渡条件。然而，触发条件也是这种情况的一部分，在危害事件模型中是明确分开的。为了解决这种歧义，我们将危害表现为危害事件所需的运行条件称为启动条件。最后，系统上下文为其他不一定与安全相关的系统工程任务提供了接口概念。

2）风险评估

风险评估通过比较估计风险和可接受风险来补充风险分析，从而确定安全措施所需的风险降低。与风险分析一样，风险评估涉及多个假设，需要明确记录这些假设，以在自动驾驶汽车的整个生命周期内建立可追溯性。

首先，明确的风险评估通常包括在风险分析过程中识别和分析的危害事件（见图6）。因此，风险接受标准适用于这些已知事件，可以分别对接受的风险进行建模。这并不意味着忽视了未知事件的风险评估，但这超出了任何安全概念的范围（至少根据ISO 26262的定义）。通常，未知事件的风险作为安全案例的一部分进行定性评估，其中论证了组织在开发过程中为什么尽职尽责。根据所代表的估计和可接受的风险，可以指定必要的风险降低，并将其与安全目标相关联。与功能安全概念类似，安全目标是行为安全概念中的顶级安全需求。

图6：与行为安全概念生成相关的风险评估术语的概念模型

3）风险处理

基于安全目标，在风险处理过程中规定了行为安全需求（见图7）。这些安全需求是车辆层面的安全相关行为要求，规定了系统环境中特定危害事件的行为能力和运行。

图7：行为安全概念中风险处理术语的概念模型

图8：示例SysML需求图，其中为自动驾驶卡车在高速公路上行驶的场景分配了行为安全需求与行为能力

为了更清楚地说明这套方法和元模型怎么落地生成行为安全概念，这一节我们搭了一个示例模型。我们以第3.1-B小节的场景为参考，完整走了一遍示例安全分析和基于模型的风险处置流程，最终输出了这个样例化的行为安全概念。

这里要特别说明：这一节的内容只是演示用法，告诉大家怎么用我们提出的方法和元模型给行为安全概念建模，也就是展示这套方法的实际操作流程。里面的各项要求、量化的风险数值，都不能直接拿来当有效的通用参考。要做真正靠谱的风险分析和评估，结合真实数据修正风险估算，必须基于经过充分测试、已经实际部署的系统才行。

A.场景描述

我们选的具体场景是这样的：一辆自动驾驶卡车（自车）在限速60km/h的高速公路上行驶，正逐步靠近前方的拖车。前方拖车因为堵车之类的原因开始减速，自车也同步调整目标车速，跟上前车节奏。 就在这个过程中，有一辆乘用车从自车旁边超过，然后快速并入自车所在的车道——比如它马上要走出口匝道，需要提前并线。并入之后，这辆乘用车也开始减速，把车速调整到和前方拖车一致。 这个场景对应的模型视图，在附件的图9里。

图9：所考虑用例的示例模型

B.行为规范

对应的行为要求很明确：自车必须及时感知到乘用车启动了变道动作，并且做出比原先预判更快的减速操作。 行为规范对应的模型视图，见图10。

图10：SysML序列图中行为规范的示例模型

C.风险分析

• 典型的危害是两辆道路车辆之间可能发生追尾碰撞。

• 在考虑的危害情况下，自我车辆表现出危害行为，因为它没有充分减速以防止与乘用车碰撞。

• 这种危害行为是自我车辆与进入自我车道的乘用车碰撞的危害事件的一个条件。

• 例如，这种危害行为可能是由于功能不足以及时预测乘用车变道的启动造成的。

• 在这种情况下，识别出的功能不足的触发条件可能是乘用车在执行变道之前的行为。

• 除了危害行为外，危害事件是由启动条件引起的。启动条件是乘用车在制动时进入自行车道的变道操作。虽然启动条件和触发条件看起来很相似，但两者之间存在重要差异。触发条件描述了乘用车的行为，该行为未被自我车辆识别为已启动的变道（即它触发了功能不足）。相比之下，启动条件侧重于乘用车侵入自行车道及其纵向减速，从而实际发生伤害。

• 对于严重程度在MAIS 5至6之间的相关乘客受伤，初步估计的身体伤害风险为8.4·10⁻⁷h⁻¹。在本文中，我们将风险表示为每工作小时发生一定严重伤害事故的平均概率。这符合ISO 26262中的暴露分类指标和IEC 61508中的PFH（每小时危险失效的平均频率）。每公里概率等替代表示是可能的，并且受到不同假设的约束。为了在自动高速公路场景中比较手动驾驶车辆和自动驾驶车辆，我们假设使用时间相似。因此，每运行小时的单位概率支持在类似情况下对两种运输方式进行比较。其他风险评估将需要不同的指标进行比较，并需要不同的假设。虽然事故严重程度的估计是基于Alassar，但为了说明这个例子，假设了可能性。

• 风险分析的模型视图见附件图11。

图11：SysML块定义图中的风险分析示例模型

D.风险评估

• 鉴于已识别的危害和危害事件，可以指定一个安全目标，以防止自我车辆与前方执行车道变换进入自我车道的乘用车发生碰撞。

• 作为一个（总体水平）风险接受标准，我们采用正风险平衡。根据所选目标运行域的事故统计数据，可接受的（总体水平）风险可定义为发生类似严重程度事故的概率。在这个例子中，我们假设相关乘客受伤的可接受风险为1.4·10⁻⁷h⁻¹，严重程度在MAIS 5至6之间。在实际的开发项目中，可以使用更具体的事故数据或人类驾驶员模型来推导出事件级别的可接受风险。

• 根据估计的初始风险和假设的可接受风险，我们定义了7·10⁻⁷h⁻¹的必要风险降低。这种风险降低与既定的安全目标有关。

• 风险评估的模型视图见附件图12。

图12：SysML块定义图中的风险评估示例模型

E.风险处理

• 为了满足安全目标，定义了行为安全需求，规定了车辆层面的安全措施。

• 行为安全需求是针对特定的运行条件（系统环境）定义的，并分配给行为能力。

• 在这个例子中，满足行为安全需求的相关行为能力是检测乘用车的关键横向偏移，以及调整在领头车辆后面驶入自我车道的车辆的预测制动距离的能力。

• 由于行为安全需求（图8中的BSR-3和BSR-4）之间没有足够的独立性（由于感知和对环境的反应之间的依赖性），所有行为安全需求都需要同样满足降低风险的要求（即7·10⁻⁷h⁻¹）。

• 风险处理的模型视图见图8。

通过这个例子，我们展示了如何使用基于模型的方法来实现行为安全概念。该模型表明，SOTIF工件（如触发条件、功能不足和危害行为）的连贯文档支持整个SOTIF活动的可追溯性。特别是行为安全需求对行为能力和所考虑的背景的可追溯性在多个模型视图中显示出来。

我们开展这项研究的核心目的，是用提出的行为安全概念及配套方法，补充完善ISO 21448中的现有指引。首先需要明确的是，ISO 21448已经为安全行为规范搭建了基础框架，也定义了车辆级SOTIF策略这一核心概念。结合第2节对标准术语的分析我们认为，这套标准的内容仍有进一步厘清的空间，尤其是站在运行视角，可以把风险的表述逻辑梳理得更清晰。为了验证我们这套概念的实际价值，我们将第6节示例的分析结果，与ISO 21448的对应指引做了对标对比，具体内容见7.A小节。此外，本文的研究局限性，会在7.B小节展开说明。

A.与ISO 21448中的示例对标

ISO 21448附件D.1给出了驾驶政策规范的相关指引，标准中将驾驶政策定义为“车辆级SOTIF策略在决策层面的落地实现”，同时引用了Nistér、Shalev-Shwartz等人的研究作为驾驶政策的参考案例。本次对比评估，我们就以附件D.1中的车辆级SOTIF策略示例为参照。不过这些示例要么并非针对特定场景设计，要么与我们示例中的运行条件不匹配，因此我们仅提取了核心结论来做对标分析。

标准建议，驾驶政策的设计需重点关注五个方向：运行设计域（ODD）分析、对其他道路使用者行为的假设、道路基础设施、自动驾驶车辆自身不足的预判与防控、运行模式之间的切换管理。 接下来我们重点讨论第二、第三、第四个方向。ODD分析虽然通常对自动驾驶车辆的目标行为影响显著，但从标准给出的目标和示例来看，该方向的核心是避免车辆超出ODD运行，它对规范与设计的影响，更多体现在功能层面，通过具体技术方案落地。同理，运行模式切换虽然从运行角度会间接影响自动驾驶车辆的行为，但本次评估暂不展开讨论。

先说对其他道路使用者行为的假设这部分。标准中特别指出，不能默认其他道路使用者（自动驾驶车辆除外）都会遵守交通信号灯规则，任何形式的碰撞都属于危害事件。还有一条建议要求：驾驶政策要基于对其他道路使用者行为的假设，监测对方是否具备停车能力。这条要求虽然从宏观层面说明了该方向的应对思路，但落到具体的运行条件中，到底该如何评估是否达标，其实并没有明确的标准。

其他几个关注方向也存在同样的问题，都能从更具体的运行条件设定中获益。标准表D.3罗列了道路基础设施带来的各类问题，由于该方向本身的定位，相关运行条件已经围绕危害事件设定，但对应的驾驶政策要求依然十分笼统，比如仅提到 “驾驶政策要能识别道路基础设施情况，监控自动驾驶车辆的行为”。 要在整个运行设计域内验证这条要求，会面临一个很现实的问题：记录运行环境相关假设的工作量，会大量从规范设计阶段后移到验证确认阶段。这样一来，很多需要补充的安全措施，可能要到开发后期的测试环节，甚至车辆部署之后才会被发现。

最后是表D.4的内容，即对自动驾驶车辆自身不足的预判、预防与缓解。标准中举了一个危害事件的例子：自动驾驶车辆接近视线遮挡区域时，无法及时感知其他交通参与者。这是行业公认的核心难点，Graubohm等人的研究也详细分析过，接近遮挡区域时，明确的假设设定会产生显著影响。但标准给出的要求依然偏抽象：“驾驶政策要监控车辆状态，在遇到基础设施或道路设计造成的视线遮挡时，主动减速、保持谨慎”，最终还是需要开发方自行明确车速选择的相关假设。

而我们提出的行为安全概念，恰恰要求在这些关注方向上，结合对应运行条件制定明确的行为规范。比如在我们的示例中，我们先从功能场景规范入手，这个阶段的运行条件先用非参数化的方式描述即可——比如设定前方卡车在自车车道内减速，乘用车从相邻车道超车。在这套明确的运行条件下，我们就能定位到具体的危害事件。 对应到安全措施上，我们可以明确提出行为安全需求：系统要持续跟踪乘用车的横向偏移量；自车的减速距离计算，必须同时兼顾前方卡车的减速情况，以及乘用车并入自车道后的减速情况。

另一方面，ISO 21448附录D.1中提供的示例突出了行为安全概念规范中的一个重要权衡。抽象的关注点、危害事件和要求大大降低了驱动策略设计的复杂性。这与安全力场和责任敏感安全（RSS）提出的广义安全包络相一致。这些方法没有对不同场景下的运行条件做出明确的假设。

因此，在一般假设下给出的保证存在不确定性。行为安全概念要求对所考虑的情景做出明确的假设，以便进行风险评估。因此，行为安全概念可以支持在开发过程中对选定场景中的RSS参数进行合理性检查。

B.限制

在本文中，我们提到了所提出的行为安全概念的多种局限性，以及作为我们工作的一部分进行的分析。

首先，一个关键的挑战是验证指定的行为安全需求。行为安全需求和安全目标之间的可追溯性是支持其验证的重要抽象机制。然而，行为安全需求是在指定的运行条件下明确评估的。因此，行为安全概念不能为未知场景的充分覆盖提供证据。24 ISO 21448第11条（“未知场景的评估”）、第12条（“SOTIF实现的评估””）和第13条（“运营阶段活动”）中的指南表明，在行业中也没有提供此类证据的常见做法。对于“已知场景的评估”，第10条提供了可用于验证行为安全概念的指导。本文重点介绍规范和设计活动。我们明确不为ISO 21448中的验证和确认方面提供方法论指导，因为它不在本文的范围内。

其次，行为安全需求规定了自动驾驶汽车在场景中应表现出的行为能力。在第5-A小节中，我们说明了如何在事件层面和总体层面上管理必要的风险降低。然而，为了对风险进行有效的（去）组合，有必要确保所考虑的危害事件准确地代表了总体水平的危害。作为我们工作的一部分，我们没有为这种（取消）组成提出确保代表性所必需的具体标准。此类标准的定义需要在交通中运行的自动驾驶车辆的大量数据。

第三，本文重点介绍了ISO 21448目标的合规性。然而，我们没有展示如何确保ISO 21448工件和ISO 26262工件（如功能和技术安全概念）之间的一致性。一般来说，ISO 21448概述了ISO 21448和ISO 26262之间的相互作用。作为ISO 26262第三版工作的一部分，目前正在研究如何同时实现符合ISO 26262和ISO 21448的开发的进一步指导方针。在我们看来，IEC 61508确立了重要的工作，特别是在一致的风险管理方面。然而，由于IEC 61508最初通过ISO 26262针对汽车领域进行了定制，随后通过ISO 21448进行了扩展，因此对自动驾驶来说，必要的风险降低的一致规范变得具有挑战性。Fowler对运输部门进行了类似的观察。

关于ISO 21448的合规性，我们的工作有两个重要的局限性。首先，我们没有展示如何将最小风险操作作为行为安全概念的一部分。该限制继承自ISO 21448，因为驾驶政策仅限于确保在不需要过渡到最低风险条件的条件下的安全行为。尽管如此，作为确保预期功能安全的一部分，明确整合旨在通过牺牲行程终止来建立最小风险条件的演习是一项必要的任务。

最后，虽然我们在行为安全需求的规范中看到了解释无法防止或检测和减轻合理可预见的误用的潜力，但我们并不声称完全涵盖ISO 21448的这一方面。相反，本文介绍的行为安全需求通常考虑操作环境的触发条件，无论其分类为合理可预见误用。

在这篇文章中，我们提出了行为安全概念，作为一种连贯的工作产品，有助于在车辆层面为目标行为制定安全措施。

拟议的行为安全概念包括触发条件、功能不足、危害行为和相应的安全需求等工件。我们的建议基于对ISO 21448、ISO 26262和IEC 61508的分析。分析发现了差距，为ISO 21448要求在多个方面的应用提供了额外的指导：首先，ISO 21448需要明确表示风险，以表明符合风险接受标准。

同时，标准没有推荐具体的方法来应用这一要求。为了在车辆层面明确安全措施，以解释基于自动驾驶汽车背景的必要风险降低差异，我们引入了行为安全需求这一术语。

其次，ISO 21448没有明确区分车辆级（即从运行角度）的功能修改和系统级修改（例如从功能角度）。为了从操作角度指定解决自动驾驶汽车目标行为的安全措施，我们引入了行为安全概念。行为安全概念是行为安全需求和行为能力的规范。行为安全概念中的运行观点可以促进目标运行领域的审批过程（如德国法规所要求的）。

此外，这一级别的安全措施专用规范也作为一种技术无关的安全概念，以支持跨公司的沟通。在这方面，我们讨论了与车辆级SOTIF策略的异同。

通过这篇文章，我们打算为指定目标行为的安全措施的明确规范做出贡献。因此，我们为ISO 21448提供了概念扩展，并提供了一种方法和元模型来指定行为安全概念。这两个贡献都以高速公路上的自动卡车为例进行了说明。我们使用现有的自动驾驶SysML配置文件在SysML中对示例场景和行为安全概念进行建模。该示例展示了基于模型的方法如何支持运行条件、功能不足和行为安全需求之间的可追溯性。为了将本文的方法论贡献应用于其他运行领域和自动驾驶系统，涉及多个建模决策。

例如，有许多研究出版物和标准用于构建作战领域和驾驶机动。本文在使用这些分类法中的一种来处理行为安全概念时没有做出特别的假设。

对于未来的工作，我们认为伦理讨论的上下文相关要求规范具有很高的潜力。为了在这种情况下利用行为安全需求，有必要在风险管理过程中明确整合道德评估。

这一结论来自现有的研究，该研究表明，将人类价值观之间的权衡转化为工程需求对所考虑的背景高度敏感。

我们在德国自动驾驶圆桌会议上参与了相关活动，讨论了利益相关者参与的潜在方法，以确定自动驾驶的接受标准，而不仅仅是净风险。

利益相关者的参与可能是整合接受标准的一种手段，这些标准将目前的身体伤害范围扩展到其他类型的伤害。

未来工作的另一个领域是基于行为的视角，特别是行为安全概念，可以做出贡献的是端到端的自动驾驶系统。Barbier主张将行为能力作为此类黑匣子系统验证和确认策略的一部分。在这种情况下，不需要分配给特定系统功能的技术无关的安全需求规范似乎是有益的。

最后，有必要进一步调查，以得出行为安全概念如何有助于公共风险管理的结论。在德国，现行法规要求自动驾驶汽车的管理者定义目标运营域。然而，例如，如果有一个负责管理公共道路的机构，如德国高速公路的高速公路有限公司，那么定义一次目标运营域并让部署到该目标运营域的每个公司都为该域的合规行为辩护似乎是合理的。在这种情况下，可以研究行为安全概念，以支持运营领域当局和部署公司之间跨学科的安全需求沟通。

免责声明：文中观点仅供分享交流，文章版权及解释权归原作者及发布单位所有，如涉及版权等问题，请您联系alpha.yuan@houwa-tech.com告知，我们会在第一时间做出处理。