基于运行设计域（ODD）的安全论证方法

运行设计域（ODD）是自动驾驶系统（ADS）拟运行真实世界的代表性模型。对于此类人工智能（AI）赋能系统的开发流程而言，运行设计域的定义是关键环节。这是因为运行设计域是多项关键开发活动的基础，例如系统级需求定义、测试与验证，以及为基于人工智能的自动驾驶系统构建有充分依据的安全档案。由于定义不当的运行设计域会给整个开发过程带来重大安全隐患，因此在开发过程中必须完整且一致地定义运行设计域。本文提出了一种在安全关键型基于人工智能的自动驾驶系统功能开发过程中定义和维护运行设计域的方法，并提供证据证明该方法具备足够的完整性和一致性。通过铁路领域全自动系统的工业用例，验证了该方法的可行性。

高级自动驾驶系统旨在开放环境中自主运行，该系统所处环境被称为运行域（OD）（例如特定轨道、道路、工厂环境等）。为描述系统拟运行的预期运行域，需将运行设计域（ODD）指定为真实世界（即运行域）的表征模型。运行设计域的定义会产生一系列关于环境的假设，以及对基于人工智能的自动驾驶系统及其安全功能的需求，同时也涉及运行设计域边界的检测需求。这些需求必须纳入自动驾驶系统的需求规格说明中，并且是人工智能开发及安全保障流程的基础。

目前，在复杂场景下（如非受限铁路基础设施、公共道路等）确保自动驾驶系统的安全性仍是尚未解决的问题。多项研究活动（例如 safe.trAIn项目）致力于将源自功能安全的形式化需求（如铁路领域的 EN 50126 标准）与自动驾驶系统相关联，并构建合理的安全档案。为此，该项目以铁路领域认证流程的需求为基础，为无人驾驶区域列车的基于人工智能的障碍物检测功能构建安全论证。

要为基于人工智能的自动驾驶系统构建合理的安全论证，诸多论证需依赖系统的运行条件（OCs），且在开发过程中必须完整、一致地定义相应的运行设计域。运行设计域的规格说明若存在缺陷，会限制关键开发活动的开展，例如对基于人工智能的自动驾驶系统进行充分验证与测试；此外，还会使运行设计域边界的检测变得复杂 —— 而在任何自动驾驶系统的运行过程中，检测运行设计域边界都是确保基于人工智能功能安全运行的必要前提。例如，无人驾驶区域列车的障碍物检测功能依赖于基于人工智能的检测和分类任务，其运行便受此影响。

因此，本文旨在解决以下核心研究问题：

· 如何基于运行设计域的定义保障安全性？

· 如何论证运行设计域定义具备足够的完整性和一致性？

本文其余部分结构如下：第 2 章简要概述相关研究工作；第 3 章提出运行设计域定义与维护方法，以论证运行设计域的完整性和一致性；随后，通过铁路领域固定路线无人驾驶系统的工业用例，验证该方法的可行性；第 5 章探讨研究发现、局限性以及方法的有效性威胁；第 6 章总结全文并对未来研究方向进行展望。

运行设计域（ODD）概念在汽车行业中已具有重要意义，该领域常用运行设计域来规范和测试自动驾驶系统的运行。然而，仅在汽车领域，运行设计域就存在多种相似却不完全相同的定义。SAE J3016 标准将运行设计域定义为 “特定驾驶自动化系统或其功能专门设计的运行条件，包括但不限于环境、地理和时段限制，以及是否存在特定交通或道路特征的要求”。相比之下，ISO 21448《预期功能安全》（SOTIF）标准将运行设计域定义为 “特定驾驶自动化系统设计所针对的特定条件”。

近年来，众多研究致力于明确运行设计域的内容。Czarnecki提出了一种汽车领域开放世界模型，该模型描述了道路环境要素，可用于规范自动驾驶系统的运行设计域。文献的作者强调，对于汽车系统而言，相关要素列表可能永远无法完备，并提出了定义运行设计域时应考虑的关键因素。文献研究了运行条件变化、运行设计域模糊边界以及运行设计域过渡对自动驾驶系统的影响。特别是在汽车领域，近年来一直致力于推动运行设计域的统一定义和应用。除上述定义外，ISO 21448 标准还要求运行设计域的边界和覆盖范围需足够充分，且必须能检测到系统超出运行设计域的情况。美国联邦政府交通部下属机构 —— 国家公路交通安全管理局（NHTSA）发布了自动驾驶系统可测试案例与场景框架，其中包含运行设计域分类法。另一项关于汽车领域运行设计域的标准化工作形成了英国标准 BSI PAS1883，该标准针对自动驾驶车辆控制系统的开发与评估制定了规范。这些核心概念也体现在最新的 ISO 34503 标准中，该标准为测试场景下道路车辆的运行设计域制定了规范。由于该标准是获得广泛认可的重要国际标准，因此也被用作本文所提方法的基础（参见第 3 章）。目前正在推进的 OpenODD 项目旨在为运行设计域描述的定义和应用制定技术标准，且计划与 ISO 34503 标准保持兼容。

其他领域的研究也对运行设计域概念进行了探索。在航空领域，欧洲航空安全局（EASA）发布了机器学习应用概念文件第二版，其中提出了人工智能 / 机器学习组件运行设计域和运行域的定义。这些概念在航空领域已有既定含义，如今也应用于基于人工智能的系统。在铁路领域，研究人员也在探索将运行设计域应用于自主列车和远程控制。文献提出的运行设计域包含四个所谓的子域以及子域间的过渡，分别对应从手动控制到自主正常运行的不同自动化运行级别。文献的作者提出了一种用于远程驾驶的运行设计域迭代定义流程。在制造领域，有学者提出了一种用于构建环境表征的本体，尽管作者未明确将其称为运行设计域，但其概念与其他领域的运行设计域具有相似性。

上述所有方法均对运行设计域的定义进行了阐述，但均未解决如何论证运行设计域定义具备足够完整性和一致性的问题，而这正是本文的研究重点。

定义运行设计域的常见目的之一是从中推导测试案例。文献提出了一种从自动驾驶领域深度神经网络（DNN）感知功能输入域分析结果中推导本体的方法，该研究设计了推导 “KI-A” 本体的流程，该本体可用作运行设计域的定义。文献提出了一种基于用例的自动驾驶运行条件收集方法，其中包含一个对用例运行条件进行分类的框架。该研究的重点并非确保运行设计域定义的完整性，而是防止系统超出运行设计域，并为此提出了四种可实现该目标的通用策略。文献探讨了自动驾驶汽车运行设计域的完整性问题，但未论证如何实现目标运行设计域定义的完整性。文献 的研究重点是运行设计域定义的可能度量指标，这些指标也可用于比较不同的运行设计域。文献提出了一种类似方法，将运行设计域定义为用于测试自动列车运行目标检测系统的本体。

据我们所知，目前已有多种定义和应用运行设计域的方法，但鉴于运行设计域在自主系统（ASs）安全论证中的重要性，尚无研究聚焦于如何确保运行设计域的完整性和一致性，这正是本文要填补的研究空白。

通过设定预先定义的限制条件，使自主系统在能力有限的情况下仍能安全可靠地运行，是一种常用方法（例如适用于自动驾驶系统）。我们提出一种与领域无关的运行设计域定义：“特定自动化系统或其功能专门设计的运行条件，包括但不限于环境、地理和时段限制，以及是否存在特定基础设施特征的要求”。

目前，运行设计域的应用重点主要集中在：例如，通过定义运行设计域限制自主系统的运行区域、对已定义的运行设计域进行测试，以及实现测试覆盖等方面。然而，如何定义一个足够完整且能用于安全性论证的运行设计域，仍是一项亟待解决的挑战。相比之下，自主系统安全性的诸多论证通常基于从运行设计域中推导的假设（例如，参见 Aurora 自动驾驶安全档案框架或文献）。因此，只有当运行设计域定义不当所带来的风险处于可接受的较低水平时，这些论证才成立。这也是运行设计域的规范制定需要像其他与安全相关的开发任务一样，得到特别关注和指导的原因。

为此，我们研究了一种自主系统运行设计域的定义方法，该方法基于此类系统（如替代汽车或列车驾驶员的自动驾驶系统）开发的当前最佳实践。首先，我们构建了一个安全论证，以确保运行设计域描述的充分性（参见图 1），该论证源自与安全专家和领域专家共同分析的特定应用场景。通常而言，定义运行设计域可视为自主系统领域分析阶段的一部分。与传统系统相比，在领域分析阶段，必须更详细、更明确地分析环境特性对自主系统安全功能的影响（例如不同天气状况的影响）。因此，在开发过程中，领域分析阶段和运行设计域规范制定都必须经过多次完善，这意味着自主系统的领域分析阶段需要迭代进行。我们强调运行设计域定义应具备机器可解释性（例如采用领域特定语言），以便在整个开发过程中实现自动处理和追踪。

图1、ODD定义的安全档案结构

我们确定了由运行设计域规范不当引发的两个主要安全问题：定义的完整性不足和一致性缺失。若运行设计域定义未考虑任何与安全相关的要素，则该定义不完整。某一要素若对系统安全功能存在影响，则被视为与安全相关。若运行设计域要素及其关系的规范未反映现实世界中与安全相关的特性（例如运行设计域要素属性的参数范围过窄），则该定义存在一致性问题。

为清晰起见，我们将上述问题形式化表述如下：通过函数Φ: OD → ODD，将真实世界运行域（OD）的要素映射到运行设计域（ODD）定义的要素中。运行设计域工程流程的结果是对该函数的限定，即

该限定函数仅对运行设计域定义中已考虑的运行域要素（即OD有效。此外，我们将SE∈OD定义为运行域中所有与安全相关的要素。那么，若满足以下条件，则运行设计域定义不完整：

进一步地，我们将p(x)定义为运行域或运行设计域中要素x的与安全相关的属性和关系。若运行设计域中存在某一要素，其与安全相关的属性和关系集与真实世界运行域中对应要素的属性和关系集不相等，则运行设计域定义存在一致性问题，即：

上述两种问题可能同时出现的典型情况是：自主系统在运行设计域定义中未考虑的运行条件下运行，即运行域不在运行设计域范围内 —— 这种情况也被称为 “超出运行设计域”（ODD exit）。

因此，本文提出的方法旨在为以下两个主张提供证据支持：运行设计域定义具备足够的完整性（G1.1）和足够的一致性（G1.2）。所有证据均支持这两个主张，下文将对其进行详细阐述：

E1 运行设计域管理流程

在自主系统的全生命周期内，需建立一套专门用于定义和更新运行设计域的流程，并将其融入系统开发和运行生命周期，以确保系统地考虑与运行设计域相关的各个方面。例如，自主系统运行设计域的明确迭代定义应作为领域分析的有机组成部分，确保在开发早期就专门考虑环境条件对系统安全性的影响。此类流程还应包括需求与运行设计域要素的追踪管理，此外，还需明确如何管理运行设计域定义的必要更新（例如基于新发现或自主系统部署的变更）。该流程有助于确保运行设计域定义包含所有相关要素，并能准确反映现实世界的属性。

E2 领域标准的应用

与整个系统开发过程类似，通用标准和领域标准有助于保障安全性。在运行设计域定义方面，可利用现有的标准、指南和类似文档，捕捉并考虑所有相关的环境条件。例如，特定领域的标准通常已包含对运行条件的考量，如 ISO 16750 标准规定了汽车电气和电子设备的环境条件，文献为轨道车辆的温度、高度、冲击和振动等方面提供了指导。通过这种方式，可将该领域先前工作中已识别的与运行设计域相关的要素及其所考虑的参数，与当前运行设计域定义进行交叉验证。

E3 运行设计域相关现有数据

现有数据可为运行设计域定义具备足够完整性和一致性提供额外证据。例如，统计数据可揭示运行设计域特定方面的信息，如天气条件、预期的其他智能体 / 系统（如自动驾驶场景中的其他车辆）、人员等。为此，既可以使用通用统计数据，也可以使用特定地理区域或路线的专用数据（若系统被限定在特定区域或路线运行）。例如，全球、国家或地区层面的道路交通事故数据；又如，可利用现有的地图和基础设施数据（如自动驾驶系统的高清地图、自主移动机器人（AMRs）的仓库布局信息）。这些数据集合包含了与运行设计域相关的要素及其关系信息，可为安全论证提供进一步支持。

E4 跨领域认可度

据我们所知，运行设计域定义在自主系统中的应用最初源于自动驾驶领域。此后，人们投入大量精力研究和规范开放道路驾驶场景下的运行设计域。近年来，航空、铁路 等其他领域也开始致力于开发和应用运行设计域定义。其中部分领域的定义涉及共同概念和应用场景（如人员 / 行人），因此，运行设计域分类法的总体结构以及带有属性的要素可保持一定相似性。无论如何，将当前运行设计域定义与其他领域的定义进行对比（例如找出定义和概念的异同点），都能提供额外的证据支持。例如，在公共空间中对人员 / 行人的考量，在汽车和市郊列车场景中具有相似性。汽车领域已针对这一问题开展了大量研究，将汽车领域的既有知识应用于列车场景，可进一步增强人们对相关概念（如人员检测）已被充分捕捉的信心。

E5 专家判断

与需求验证类似（安全标准强烈建议对已定义的安全需求进行逐步审查和检查，例如 ISO 26262-8:2018 标准），运行设计域定义的完整性和一致性也可通过专家审查来验证。因此，开发自主系统的机构必须建立严格的审查流程，该流程需纳入 “四眼原则” 等最佳实践，并对审查过程和参与审查的专家进行记录。参与审查的专家必须在自主系统运行的领域以及系统本身（包括其能力和局限性）两方面具备足够的专业知识。此外，运行设计域必须纳入所有与安全相关的开发工件的配置和变更管理流程中。每次修改后，都必须重复执行审查流程。因此，通过专家审查可验证运行设计域的完整性和一致性。

E6 组件弱点分析结果

运行设计域的定义必须考虑所有对系统安全性有影响的相关环境要素和条件。除了纳入通用领域知识外，系统及其感知能力的局限性和特性，也为确定需要考虑哪些方面以及详细程度提供了额外依据。例如，若人员的姿态对机器学习（ML）算法检测人员至关重要，则人员的这一特征必须在运行设计域中明确规范。因此，对系统关键组件的深入分析会发现需要额外考虑的问题。例如，对传感器的敏感性分析可能会揭示其在特定天气条件（如温度、降水）下的局限性。通过对传感器组件进行FMEA或HAZOP等安全分析方法，可识别此类弱点并发现不足。此外，将系统能力与人类操作员的能力进行对比，也能发现系统在运行设计域中需要额外考虑的相关方面。

E7 测试场景

传统上，基于需求的测试一直是开发安全关键型系统的基础。然而，对于自动驾驶系统，ISO 21448《预期功能安全》（SOTIF）标准将基于场景的测试视为验证和确认自动驾驶系统的最先进技术。当前研究的一个重点是，根据特定指标生成能充分覆盖运行设计域的自动驾驶车辆代表性测试场景。这一研究方向再次凸显了制定足够准确的运行设计域规范的重要性，同时也有助于避免运行设计域定义出现遗漏或细节不足的问题。例如，参考运行设计域相关要素的标准测试场景，可对运行设计域定义进行交叉验证；同样，探索和识别边缘案例或功能缺陷也可为运行设计域定义的可信度提供证据支持。此外，生成代表性测试场景还有助于确定运行设计域的哪些部分对安全功能有实际影响，并发现运行设计域要素之间的相互依赖关系（例如，白天是否更容易识别动物？）。

E8 现场数据

运行设计域可从有人驾驶系统运行过程中收集的数据中推导得出，例如通过在不同道路或特定铁路轨道上进行测试行驶来收集数据。在此过程中，必须收集并标记摄像头图像等数据，以便识别场景和目标（如天气状况、树木、交通标志、动物、其他车辆等），并将其存入数据库。这需要采用标准化的标记方案和可通过现场收集的新数据不断扩充的数据库。该数据库以及对收集数据中特定目标出现频率的统计，可实现以下两个目标：a）推导和完善运行设计域的相关属性；b）将现有运行设计域与运行过程中收集的数据进行对比。这有助于确保并提升运行设计域定义的完整性（例如通过识别缺失要素）和一致性（例如通过发现参数范围不匹配问题）。

E9 运行域监控

为确保运行设计域的完整性，在系统原型和成品系统的运行过程中，都需对运行域进行主动监控。这可通过利用现有传感器（如摄像头、温度传感器）的感知能力以及云或基础设施提供的额外信息来实现。监控和分析运行域所需的具体频率可能因领域而异，同时，该频率也可作为衡量运行设计域对实际运行条件捕捉程度的指标。根据运行过程中收集的信息，需人工审查数据以识别新的目标、属性等。若发现尚未纳入运行设计域的新方面，则必须按照运行设计域管理流程（参见证据 E1）对运行设计域进行更新。因此，通过这种方式可检查已定义的运行设计域是否与实际运行域相符，并有效提升运行设计域的完整性。

上述证据应能证明运行设计域定义具备足够的正确性，从而为自主系统的开发奠定坚实基础。该方法摒弃了仅基于经验和零散考量来定义运行设计域的方式，而是为运行设计域的定义提供了结构化框架，基于该框架可对自主系统的安全性进行论证。下一章将展示该方法如何应用于自主系统的开发过程。

为评估本文提出的用于降低运行设计域定义不当所带来风险的方法，我们采用了铁路领域固定路线无人驾驶列车的工业用例。下文将阐述如何应用该方法，为第 3 章提出的安全档案生成适用于该用例的证据。

4.1 汉堡自动列车运行系统

在本次评估中，我们以德国汉堡某条示范路线上的无人驾驶区域列车自动运行系统（ATO）为研究对象，该系统的自动化等级为 GoA 4 级。该区域的部分传感器数据可公开获取。本评估旨在展示如何为安全档案（参见图1）生成证据，为此，我们应用所提方法并描述为支持运行设计域定义主张所需开展的潜在工作。

为应用该方法，我们选取了区域列车在韦德尔（Wedel）站至奥尔斯多夫（Ohlsdorf）站之间的运行路线（参见图 2），下文将其简称为 “HH_S1 路线”。该路线部分数据可公开获取，且足以满足本研究的需求 —— 本研究重点在于展示如何为运行设计域构建论证并生成证据，而非提供全部证据。我们进一步假设该路线将用于自动列车运行系统，并需为此制定相应的运行设计域。

图2、所选示例路线HH_S1的地图摘录（绿线）

可基于汽车领域现有研究成果（即 ISO 34503:2023-08 标准）中的分类法基础，为 HH_S1 示范路线定义运行设计域。因此，我们将运行设计域大致划分为 “环境条件”“场景要素” 和 “动态要素” 三个顶层要素（参见图 3）。通过这种方式，可借鉴既有知识，并根据分类法较低层级的领域特定方面进行调整。图 3 展示了本研究所需的该路线运行设计域定义的部分要素及其子要素。

图3、所选路线HH_S1的ODD定义摘录

4.2 证据生成

针对上述用例中的自动化系统开发，下文将阐述为遵循本文方法制定足够正确的运行设计域所需开展的活动和生成的证据。此外，通过 safe.trAIn 项目中针对无人驾驶区域列车的具体解决方案示例，展示该方法在实际用例中的应用，从而评估其适用性。

E1 运行设计域管理流程

必须为自动列车运行系统的全生命周期建立并执行运行设计域管理流程。为此，我们建议将该流程明确融入通用的 DevOps 工作流（参见机器学习运维流程（MLOps Flow））。图 4 以 safe.trAIn 项目的示例展示了在不同阶段应考虑的运行设计域相关方面，该示例采用类似 V 模型的方法，包括在系统开发中定义运行设计域、将其用于安全概念及机器学习训练与测试，以及将其纳入验证与确认（V&V）活动（包括运行时监控）。这可作为运行设计域管理融入开发流程的具体示例。在此，我们采用的确保可追踪性的方法之一是将需求与相应的运行设计域要素相关联。下文以源自德国行车服务条例的需求 R1 为例进行说明。

示例 1：关联 HH_S1 路线运行设计域要素的需求 R1 自动列车运行系统必须监测轨道 [场景要素。可行驶区域。轨道]、信号 [场景要素。可行驶区域。信号]、道岔过渡段 [场景要素。道岔。过渡段] 和接触网 [场景要素。基础结构。接触网]。

图4、安全MLOps过程中ODD方面的概述

E2 领域标准的应用

在为该用例定义和完善运行设计域时，可参考现有的铁路标准和指南。例如，轨道车辆相关的 EN 50155 标准、行车服务条例或驾驶员手册等指令；此外，还可参考欧盟关于铁路系统互操作性的指令和互操作性技术规范（TSI）等铁路应用相关的欧洲指令；其他信息来源还包括该领域已认可的其他概念，如铁路领域的概念数据模型（CDM）。

E3 运行设计域相关现有数据

为使运行设计域基于真实世界数据，可利用各类可用数据。例如，可通过铁路地图信息⁴检查该路线所有相关的已索引基础设施要素是否已充分纳入运行设计域定义；环境条件相关数据的示例包括该路线所在区域（即汉堡市）的历史天气数据，通过这些数据可推导并验证关于天气条件和能见度的假设（如温度极值、降水量、降雪、雾天等）。在本示例中，根据汉堡市的可用天气数据⁵，我们得出温度极值为 - 29.1°C / 40.1°C。因此，运行设计域的参数设定为覆盖该区域所有记录温度，即 - 35°C 至 45°C（参见图 3）。其他潜在数据来源包括类似轨道和运行条件的记录数据，通过对这些数据的分析和审查，可深入了解运行设计域的特定特征（如需考虑的铁路信号是否相同）。

E4 跨领域认可度

对于本用例，可借鉴其他领域的知识。在第 4.1 节所述的运行设计域定义中，我们采用了 ISO 34503 标准的结构框架，该框架借鉴了汽车领域已充分研究的运行设计域要素和子结构。在运行设计域中考虑轨道上或轨道附近人员时，也可将汽车领域关于行人尺寸的知识迁移应用。例如，以所谓的 “兹维基盒”（Zwicky boxes）形式捕捉的行人相关尺寸特征。

E5 专家判断

在运行设计域开发过程中，需实施严格的专家审查流程，包括在与安全相关方面发生开发变更后进行重复审查。作为最佳实践示例，在 safe.trAIn 项目中，我们邀请了机器学习专家、评估人员、系统架构师、工程师和安全专家等多方利益相关者，对运行设计域定义提供初步反馈。将运行设计域作为核心开发工件，有助于所有相关利益相关者进一步参与其中。遵循 “四眼原则” 的运行设计域定义明确审查以及专家组审查，可进一步强化专家判断的论证效力。

E6 组件弱点分析结果

根据自动列车运行系统特定的系统架构，可开展不同类型的弱点分析。例如，基于所使用的传感器，可确定其对环境条件的敏感性。由于本用例未披露具体的系统架构，我们参考文献，以表1 的形式列举了当前常见自主系统感知能力的已知弱点作为示例。此外，还需对各个感知能力进行安全分析。例如，在基于机器学习的人员检测中，对区分特征的分析可能会发现运行设计域规范中需进一步明确区分的问题。

表 1、源自文献的自动驾驶系统传感器优缺点

E7 测试场景

基于场景的测试是自动列车运行系统等高度自动化系统验证与确认（V&V）流程的组成部分，包括制定充足的测试集（如基于运行设计域的组合测试）和测试边缘案例。对边缘案例的研究有助于确定运行设计域中需考虑的所有相关要素及其参数。在本用例中，这包括考虑使用轮椅的行动障碍人士（即 HH_S1 路线运行设计域中的动态要素。交通智能体。轮椅，参见图 3）在轨道附近活动的场景。为实现与运行设计域的可追踪性，从而支持基于覆盖范围的验证与确认论证，我们在测试场景描述中关联了运行设计域要素。下文以采用 Gherkin 语法⁶编写的测试场景 TS1 示例，展示了如何在场景描述中引用 HH_S1 路线运行设计域的相关要素。通过这种方式，例如可对 HH_S1 路线运行设计域中铁路信号表征的充分完整性和一致性进行交叉验证。

示例 2：关联 HH_S1 路线运行设计域的测试场景 TS1 假设自动列车运行系统正在轨道 [场景要素。可行驶区域。轨道] 上行驶； 当视线范围内出现信号 [场景要素。可行驶区域。信号] 时； 则需正确识别信号 [场景要素。可行驶区域。信号] 的潜在异常情况及其状态。

E8 现场数据

在自动列车运行系统的原型测试阶段和运行过程中，需收集运行域相关信息，并分析其与运行设计域定义的一致性。在本案例中，我们可审查 OSDAR23 数据集（作为该路线现场数据的示例），并交叉验证所有数据集中的标记要素是否已充分纳入 HH_S1 路线运行设计域定义（参见表 2）。数据集中所有标记要素均在相应的运行设计域定义中进行了规范（需注意，人群等目标组在运行设计域模型中通过多重性 “[0..*]” 表示）。例如，数据中标记为 “轨道” 的要素，在运行设计域分类法中归类于 “场景要素” 的子要素 “可行驶区域” 下的 “轨道”（参见图 3）。

表2、OSDAR23 数据集中标记要素与 HH_S1 路线运行设计域所考虑要素的对比

E9 运行域监控

在自动列车运行系统架构中集成了用于检测当前运行域的额外监控模块。该模块基于高完整性输入数据，追踪运行条件的存在情况并记录违规情况。通过对这些信息的进一步分析，可增强对运行设计域定义正确性的信心。系统架构中的分布外（out-of-distribution）检测器可检测未知输入（也称为不确定性），当要素或概念与机器学习组件的训练数据不匹配时，该检测器会触发警报。根据运行设计域管理流程（参见证据 E1），对运行域与运行设计域的偏差以及可能需要的更新进行处理。

我们以特定路线上的自动列车运行系统为例，评估了所提方法在实际高度自动化系统中的应用情况。通过该评估，展示了可通过哪些方式生成何种证据，以支持运行设计域定义具备足够完整性和一致性的安全目标。

通过本文提出的方法，我们对第 1 章提出的研究问题进行了如下解答：

如何基于运行设计域的定义保障安全性？

运行设计域是自动驾驶系统需求规格说明、验证与确认（V&V）以及安全保障的基础。因此，运行设计域的规范制定需要特别关注和指导。本文提出了一种用于运行设计域定义和维护的迭代方法（参见第 4.1 节），旨在避免运行设计域定义出现完整性不足和一致性缺失的问题。该方法基于安全关键型系统开发的当前最佳实践，并以运行设计域描述充分性的安全论证为驱动（参见图 1）。

如何论证运行设计域定义具备足够的完整性？

图 1 所示的目标结构符号（GSN）片段总结了支持运行设计域完整性和一致性论证的证据。然而，所提供的证据是否足以支撑安全论证，需结合具体案例进行判断。因此，必须建立额外流程以确保所收集证据的可信度，此外，通过独立审查目标结构符号片段形式的论证，也可提供帮助。

无论如何，本文提出的方法仍存在一些有效性威胁。例如，使用证据 E4（跨领域认可度）时，可能存在忽视领域特定方面的风险（如从非汽车领域视角看铁路基础设施中的信号和交叉路口）；证据 E6（组件弱点分析结果）存在的问题是，目前尚无针对基于人工智能组件的弱点分析最佳实践；此外，由于运行设计域通常并非组件分析的重点，弱点分析中可能无法充分体现对运行设计域完整性或一致性至关重要的方面。而且，在许多情况下，很难确定运行设计域应细化到何种程度 —— 即使通过故障模式与影响分析（FMEA）等传统弱点分析方法获得结果，专家也难以识别运行设计域中高敏感性的方面（即细化运行设计域可显著提升安全性和可用性等质量与性能的方面）。在试图利用证据 E7（测试场景）避免运行设计域定义出现遗漏或细节不足时，若缺乏可用于指导测试场景生成的已验证覆盖度指标，也会成为问题。此外，在引用证据 E8（现场数据）时，通常需要对这类数据进行收集、筛选和标注，目前这一过程仅能部分自动化，仍需人工操作，而人工操作易出错，可能导致忽视相关目标或方面；而且在实际应用中，收集现场数据时还需解决数据隐私以及大规模存储数据的可行性等问题。证据 E9（运行域监控）通过运行过程中收集的数据，检查已定义的运行设计域是否与实际运行域相符，并识别潜在差距。然而，迄今为止，我们仍缺乏可大规模实际应用的成熟的 “超出运行设计域” 检测技术；此外，在开发过程中，必须仔细权衡分析运行数据以识别运行域中新属性的频率与自动驾驶系统性能之间的关系，使其符合特定用例的需求。

尽管如此，这进一步凸显了需要通过多种不同类型的证据来证明已定义运行设计域的完整性和一致性。这一要求不仅需在自主式人工智能系统的开发流程中落实，还需体现在此类系统未来的安全标准中。总体而言，本文提出的方法展示了可通过提供哪些类型的证据来增强对运行设计域定义的信任，从而为依赖运行设计域定义正确性的基于人工智能系统的通用安全论证提供支持（例如自主移动机器人、自动驾驶汽车或无人驾驶列车等自动驾驶系统）。

需要说明的是，本研究未对不同措施的有效性进行评估，而这一评估目前正在 safe.trAIn 项目中开展，该项目以无人驾驶区域列车的障碍物检测系统为用例。在评估过程中，我们计划针对 safe.trAIn 项目用例，按照本文提出的方法生成各类证据，并研究这些证据在实际流程中的适用性。同时，还将对基于场景的测试、现场数据收集以及 “超出运行设计域” 检测等不同方法进行评估，以积累关于这些方法有效性的知识，并识别各类方法的局限性。safe.trAIn 项目探索了一种所谓的机器学习运维（MLOps）方法（参见图 4），该方法可在流水线中自动生成用于论证运行设计域完整性和一致性的各类证据。在项目后续阶段，我们计划邀请独立安全评估人员，对为 safe.trAIn 项目用例生成的用于论证运行设计域完整性和一致性的各类证据进行评估。此次评估还旨在深入了解如何权衡本文方法中的各类证据，以及如何处理部分证据无法生成以支持安全论证的情况。理论上，该方法也适用于汽车等其他领域，但目前尚未对此进行研究验证。

为描述自动驾驶系统（ADS）拟运行的预期运行域（OD），需在开发过程中对运行设计域（ODD）进行规范（参见 ISO 21448 标准）。这一真实世界的表征模型是基于人工智能的自动驾驶系统系统级需求定义、验证与确认（V&V）活动以及安全保障的基础。本文提出了一种在安全关键型基于人工智能的自动驾驶系统功能开发过程中定义和维护运行设计域的方法，并提供了一系列不同类型的证据，以在安全档案中论证运行设计域具备足够的完整性和一致性。此外，通过铁路领域全自动系统的工业用例，验证了该方法的可行性。

在未来研究中，我们计划对不同措施的有效性进行评估。本文讨论中指出的该方法存在的部分局限性，需要进一步研究解决，并在未来基于人工智能系统的标准化活动中加以关注。此外，该方法在其他领域的适用性也将是未来的研究方向之一。