1) 晴朗 - 不存在云层完全或部分遮蔽太阳的可能性；
2) 多云 - 阳光有一定可能性在云层间直射到配备自动驾驶系统（ADS）的车辆；
3) 阴天 - 天空无间隙。利益相关者可根据八分量法（oktas）将云量分为以下等级：i) 晴朗：碧空无云：0 - 1个八分量；
ii) 多云：少云：1 - 2个八分量；
iii) 多云：散云：3 - 4个八分量；
iv) 多云：碎云：5 - 7个八分量；
v) 阴天：8个八分量。
云量即天空被云覆盖的程度，它会影响一天中任何时段的光照情况。利益相关者可以对晴空、阴天等采用不同的分级方式。虽然白天/夜晚的时间以勒克斯为单位的照度来表示，但云量（或云层覆盖）用八分量法表示。需要强调的是，云量在白天或夜晚都可能存在，因此与一天中的时间无关。当配备ADS的车辆从有云层覆盖的区域行驶到无云层覆盖的区域（即多云条件），太阳间歇性出现时，云量可能会因相机过曝而影响能见度或传感器感知。
d) 太阳位置：太阳在地平线以上的高度（以度数范围表示）。
其他天气属性，如温度、湿度、气压、地表温度、冰雹、冻雨或太阳耀斑等，也可作为运行设计域（ODD）定义的一部分加以考虑。
10.5 网联性
网联性指车辆从外部系统接收数据和/或向外部系统传输数据的能力，以便确定自身位置或与其他车辆及更广泛的基础设施进行通信。某些自动驾驶系统（ADS）的实现可能会利用车外传感器的网联性，将某些运行设计域（ODD）属性的值传输给ADS。例如，一些ADS为了安全执行其动态驾驶任务（DDT），可能依赖于调度员通过车对基础设施（V2I）通信发送的位置信号或控制指令。或者，在某些ADS配置中，ADS可能依赖于通过V2I通信传输给它的车外天气数据传感信息。对于此类系统的安全运行，数据质量和延迟至关重要。
如果自动驾驶系统安全执行动态驾驶任务需要网联性，那么网联性属性应被划分为通信属性和定位属性。
连通性至少应被划分为以下属性，也可以有其他附加属性：a) 通信：通信属性应分类如下：
1) 类型：（例如车队管理、交通管理、车联网（V2X））；
2) 技术：（例如蜂窝网络（如2G、2.5G、3G、4G、5G）、卫星通信、无线局域网（WLAN）、专用短程通信（DSRC）、智能交通系统（ITS - G5）、侧行链路PC5等）；
3) 下行链路：吞吐量、延迟；
4) 上行链路：吞吐量、延迟；车联网（V2X）包括车与车通信（V2V）、车与基础设施通信（V2I）、车与人通信（V2P）、车与网络通信（V2N）。
b) 定位：定位属性应分类如下：
1) 基于卫星的全球定位：
i) 伽利略卫星导航系统（Galileo）；
ii) 全球导航卫星系统（GLONASS）；
iii) 全球定位系统（GPS）；
iv) 实时动态定位（RTK）；
v) 北斗卫星导航系统；
2) 区域定位：
i) 印度区域导航卫星系统（NavIC）；
ii) 准天顶卫星系统（QZSS）；
iii) 印度区域导航卫星系统（IRNSS）；
c) RTK校正：
1) 国家特定；
2) 站点特定；
3) 全球特定（诺瓦泰卫星）。
信号强度和干扰可作为通信和定位各属性的子属性。干扰因素可能包括环境中存在的电磁（EM）信号（例如路边发射器）。利益相关者可在其ODD规范中指定信号强度和干扰范围。
11 动态元素
动态元素应进一步被划分为以下属性：
a) 交通参与者；b) 本车。
11.1 交通参与者交通参与者应分为以下属性：
a) 参与者类型；
b) 特殊车辆的存在情况：
特殊车辆至少应分为以下类别或包含其他属性：
1) 救护车；
2) 警车；
3) 作业车辆；
4) 交通管理车辆；
5) 消防车。
参与者类型可能包括：
1) 机动车；
2) 非机动车；
3) 弱势道路使用者（行人、两轮车、自行车、电动滑板车）；
4) 动物；
5) 骑马者。
此外，每个交通参与者可分为静止状态（车辆则为停放状态）和移动状态。
每个交通参与者可使用以下三个属性中的两个进行分类：
i) 参与者密度；
ii) 交通流量；
iii) 流速。
选择三个属性中的两个可使规范制定者定义出独特的规格。参与者密度以单位距离内的参与者数量来表示。流量是指在特定时间段内通过参考点的参与者数量（例如15分钟的流量）。流速是指参与者通过给定点的速率，通常以每小时的参与者数量来表示。流量可用于推算交通流。利益相关者应根据其信息来源指定测量所用的单位距离或单位时间。
此外，每个交通参与者还可能具有（相对于本车的）位置属性，例如前车的存在情况。
11.2 本车本车的最高允许速度应被定义为运行设计域（ODD）的一个属性。这是由于设计或性能限制所致。此外，本车可能还具备预定义路线以及车辆重量的属性。
12 运行设计域定义格式
12.1 总则
对于特定的硬件和软件配置，运行设计域定义（ODD）在车辆的整个使用寿命期间都应有效。运行设计域可能会随着车辆软件的更新而改变。运行设计域的定义是车辆安全概念的一部分。为了使利益相关者能够共享、比较以及重复使用运行设计域定义，不仅使用一套标准的运行设计域属性很关键，采用标准格式也同样重要，特别是对于非技术类受众而言。
依据 ISO 34502 标准，运行设计域定义在基于模拟的测试中起着关键作用。然而，本文着重关注供监管机构、系统工程师、地方当局等利益相关者使用的功能层面的运行设计域定义。在模拟执行层面用于基于模拟的测试或对运行设计域进行其他基于计算机分析的运行设计域定义格式，将在 ASAM OpenODD 中予以规定。使用本文档所规定的分类法和格式的运行设计域定义示例在附录 B 中有所展示。
12.2 定义格式类型
由于定义运行设计域需要大量的属性，运行设计域定义可能会变得很繁琐。为了使运行设计域定义简洁明了，应采用宽松型、限制型或默认型格式。利益相关者可为其定义选择任何一种格式。不过，他们应当说明针对该属性所使用的是哪种格式。
采用 “宽松型” 模式的运行设计域定义只需列出不在运行设计域定义范围内的属性。其余未指明的属性应被视为属于运行设计域定义的一部分。采用 “限制型” 模式的运行设计域定义意味着只有在运行设计域范围内的属性才会列在运行设计域定义之中。其余未指明的属性（未列出的）应被视为在运行设计域定义范围之外。
采用 “默认型” 模式的运行设计域定义意味着列在运行设计域定义中的感兴趣的属性被视为在运行设计域范围内，并且会在自动驾驶系统（ADS）运行期间受到监测。其余未指明的属性（未列出的）应被视为不会影响自动驾驶系统性能，可能不会受到监测。不过，在 “默认型” 模式下未指明的属性也被视为在运行设计域范围内。
注：在限制模式和许可模式下，从每一个分类属性都能推导出特定的参考行为。而在默认模式下，只能从运行设计域（ODD）定义中明确说明的属性推导出特定行为。
对于任何运行设计域（ODD）定义，利益相关者都应定义格式的默认状态：宽松型还是限制型。在运行设计域定义的某些部分使用宽松型定义，而在其他部分使用限制型定义（为便于阅读）可能是合理的。在这种情况下，应在运行设计域定义的相关部分明确提及定义类型。
12.3 可读性运行设计域定义是安全保障流程中的首要步骤之一。因此，运行设计域定义需要在自动驾驶系统（ADS）开发者、监管机构以及测试工程师等众多利益相关者之间进行共享并达成一致，同时还需要供人员用于规范制定、沟通交流、分析以及调试等目的。这就要求运行设计域规范对于技术用户和非技术用户而言都要易于理解。运行设计域定义应能让技术用户和非技术用户都理解。
12.4 包含、排除及条件性
对于在第 8 - 11 条中定义的每一个运行设计域属性，该属性可能被包含在运行设计域定义之中，也可能被排除在其外，或者其包含 / 排除具有条件性。
例如，一个自动驾驶系统运行的速度被定义为处于 0 到 80 公里 / 小时之间。然而，在浓雾情况下，该自动驾驶系统被限定在 0 到 40 公里 / 小时的速度范围内运行。
在自动驾驶系统的设计中，期望自动驾驶系统在恶劣的运行设计域条件（例如暴雨或浓雾）下具备降低或降级的能力以维持系统的安全运行是合理的。在这类情形下，运行设计域定义格式应允许设计人员指定条件语句或简化的运行设计域。降低或降级的能力定义应通过对运行设计域定义设置限制条件来实现。因此，如表 1 所规定的三个关键词应被用作限定词，用于明确属性的包含、排除及条件性质。每个带有限定词的运行设计域陈述都应针对一个父类（或更高级别的运行设计域属性），并将其子属性分类到这三个类别中。在涵盖所有父类后，便可生成完整的运行设计域描述。
表 1：用于包含、排除及条件性的限定词
根据利益相关者选定的ODD定义的许可性和限制性，可使用 “包含（Include）” 或 “排除（Exclude）” 关键字作为限定词来细化ODD。
例如，“可行驶区域类型” 包含 “高速公路”“放射状道路”“集散道路”“次要道路”“匝道”“停车场” 和 “共享空间” 等属性。为了针对可行驶区域类型撰写一个声明，表明只有高速公路适用，可表述为：“包含的” 道路类型为 “高速公路”。或者，也可以表述为 “排除的” 道路类型为放射状道路、集散道路、次要道路等。这两种方法都是有效的，但第一种方法效率更高，可读性也更好。
12.5 可扩展性及表述运行设计域（ODD）属性间的关系
运行设计域属性受已定义的类别层级或分类法（第 8 - 11 条）的约束，这使得属性之间的关系能够得以呈现。运行设计域属性之间的关系可能以领域本体描述为基础。虽然利益相关者可以扩展属性（及其子属性）以定义他们所需的运行条件，但在运行设计域定义中对属性的包含或排除应当与现有属性集以及属性之间的关系保持一致。利益相关者可以添加额外的属性层级作为上述列表中属性的父属性，以便对属性进行分组。
12.6 客观边界运行设计域的定义应当确保其边界能得到客观明确。这要通过确定每个运行设计域属性取值的边界来实现。
12.7 陈述构成
对于每个运行设计域属性陈述，应当定义以下组成部分（表 2）：
・限定词（包含、排除、条件性）
・属性
・属性值表 2：运行设计域定义陈述的示例构成
来源：智驾社
