情景为基于情景的评估所使用的测试提供了基础和理由[4],[6], [12]-[15]；
它有助于达成对场景的明确描述，这对于提供标准化、可重复和可再现的测试至关重要[12]；
场景的标准化描述可以更容易地进行自动比较和分类[16]；
l适当指定的情景是衡量评估范围的基础[6]；
适当指定的场景使我们能够将测试的结果转化为对特定操作设计领域（ODD）的AV性能的评估[17], [18]。
虽然场景的概念在自动驾驶的背景下经常被使用[5]-[7], [15], [19]-[23], 但真正给出明确定义的情况却很少。此外，即使是这些定义也不明确，因为有歧义和使用其他未定义的术语。从实施的角度来看，鉴于最近推出的许多模拟器[24]-[28]，准确地描述场景变得更加重要。
为此，有几种文件格式和方法用于定义评估反车辆的场景，如OpenSCENARIO[29]和CommonRoad[30]。因为这些实施方案的重点是可以模拟的情景，这些实施方案是在定量的水平上描述情景，因此，它们没有为情景的定性描述提供概念。
此外，这些实施方案和其他用于评估AV领域的面向对象的方法[31]-[34]大多缺乏对每个术语的定义和论证。
在这项工作中，作为开发一个完整的场景本体的起点，我们提出了一个新颖的面向对象的框架（OOF），以解决上述的缺陷。为了避免定义的模糊性，我们为对应于情景的概念及其所有的基本构件（如活动、参与者和事件）对应的概念的延伸性定义。
这些定义通过规定什么时候应该使用这些概念的必要充分条件来赋予这些概念的意义。我们在AVs[13]、[14]、[29]、[35]-[37]安全评估领域常用的定义基础上对每个组件进行定义。在与现有的定义[13]、[14]、[38]大体一致的同时，这个框架旨在足够明确，以实现情景描述的形式化。
更具体地说，因为我们给出了与情景相对应的概念的特征，并说明这些概念是如何相互关联的，所以我们可以把情景组件定义为具有属性、方法和与作为其他类对象的关系的类对象。
除了情景的定义，我们还引入了情景类别的概念，用于定性地描述情景，即情景的抽象。场景类别支持根据典型组件的类别对场景进行分类。提出的OOF为构建能够有效评估AV性能的场景描述提供了明确的指导方针。
拟议的方法带来了几个好处：
首先，我们为情景的定性描述提供了概念，这很有用，因为它能够对情景进行分类并对情景进行解释。
其次，OOF允许重复使用和维护（场景的构件），以及对（场景的构件）进行操作并与之互动。
第三，我们的框架得到了每个概念的定义和理由的支持。
第四，该框架能够将这些概念及其关系翻译成面向对象的代码。这反过来又被用来用一种编码语言来描述场景，这种语言可以被各种软件代理理解，如仿真工具，并且可以被移植到已有的格式，如OpenSCENARIO[29]。
为了说明如何使用所提出的OOF，我们用一种编码语言实现了该框架，该语言可在https://github.com/ErwindeGelder/ ScenarioDomainModel.上公开获取。
这个链接包含了所提出的OOF的实际应用，例如描述从数据中提取的场景[39]。该框架还被用作数据库系统的模式，用于存储情景和情景类别。这样的数据库可用于对AVs[40]执行基于场景的评估。
为了进一步说明OOF的使用，本文提供了一个实际案例示例，其中车辆接近人行横道。拟议的OOF为评估AVs的场景提供了本体论[41]的第一步。在随后的研究中，本文提出的形式化概念将被用来设计一个具有逻辑约束的本体，使计算机能够对情景进行推理。
这篇文章的大纲如下。在第二节中，我们解释了为什么OOF是有用的，以及背景是什么。我们在第三节中定义了情景、事件、活动和情景类别的概念。将这些定义正式化的OOF将在第四节中介绍。在第五节中，提供了一个应用实例，以说明该框架在现实世界中的使用情况。文章在第六节中结束。
在第II-A节中，我们解释了为什么我们要提出一个用于描述情景和情景类别的OOF。第II-B节提供了关于我们想要定义情景的背景信息。
A.为什么要采用面向对象的框架？
根据Johnson和Foote[42]，OOF是一个 "体现了对一系列相关问题的解决方案的抽象设计的类集"。面向对象被用于“一种表示、建模和抽象的形式主义”[43]，这就是为什么它被认为“不仅有用，而且是基本的”[43]。此外，Patridge[44]指出，面向对象的建模可以提供从传统的基于实体关系的数据建模到完全基于形式化本体的数据建模的桥梁。
OOF提供了以下好处：
明确性：它提供了 "一个共同的词汇，供设计者交流、记录和探索设计方案"[45]。
模块化：通过将一个场景分解为多个组件，场景本身的复杂性就会降低。因此，"模块化使人们更容易理解变化的影响" [42]。
可重用性：个OOF促进了可重用性[42], [46], [47]。例如，如果两个类共享某些程序和/或属性，这些程序和/或属性可以由一个所谓的超类提供，这两个类从超类中继承这些程序和属性，这样，这些程序和属性只需要被定义一次。
封闭性：封闭保证了 "可以安全地进行兼容修改，这有利于程序的进化和维护"[46]。
有可能翻译成面向对象的编程语言：由于该框架由一组类组成，它可以直接用于面向对象的编码语言。然后，该框架规定了不同类之间的关系，并提供了关于一个类的属性和可能值的信息。
B.场景的背景
由于场景的概念在道路交通领域之外的许多不同背景下使用，这个概念的定义存在广泛的多样性（概述见[48]，[49]）。因此，有理由认为，"没有[通用]'正确'的场景定义"[48]。因此，要定义场景的概念，重要的是要考虑它将被使用的背景。
在这篇文章中，场景的背景是对AVs的评估，其中AVs指的是配备了驾驶自动化系统的车辆。假设评估方法使用基于场景的测试案例。最终的目标是建立一个数据库，其中包含AV在现实世界中行驶时必须应对的所有相关场景[6]。因此，一个场景应该是对AV的潜在使用情况的描述。
III.定义
引入OOF的主要原因之一是支持在研究人员、开发人员和用户之间共享知识。因此，重要的是，我们使用的术语要有明确的定义。在第四节中介绍我们的OOF时，我们将把术语正规化，以便它们可以被软件代理使用。
在本节中，我们定义术语场景、事件、活动和场景类别，从而深入了解下一节中使用的术语。我们的目标是提供符合这些术语在文献中的普遍使用的延伸性的定义，并明确该术语使用时的充分必要条件。
我们首先在III-A节中定义了场景的概念。接下来，我们分别在第三部分B和第三部分C中定义了场景的两个重要组成部分：事件和活动。最后，我们在III-D中提出了场景类别的定义。
III-A至III-D的每一节都以背景信息开始。接下来，我们得出结论，得出我们所建议的相应术语的定义。在提出定义后，每一节都以提议定义的评论和含义来结束。在第III-A至III-D节提供的定义中，使用了表I中所列的术语。表一中的定义大多基于文献，更多细节见附录A。
A.场景
Go和Carroll[51]描述了系统设计领域内的一个情景。他们将情景定义为：“包含以下内容的描述：(1)参与者，(2)关于参与者的背景信息和关于其环境的假设，(3)参与者的目标或目的，以及(4)行动和事件的顺序。
一些应用程序可能会省略其中的一个要素，或者它们可能简单地、隐含地表达出来。虽然在一般情况下，任何领域的情景要素都是相同的，但情景的使用却有很大不同。”
Geyer等人[14]描述了自动驾驶背景下的一个场景。他们用电影或故事书的比喻来描述一个场景，并指出 "一个场景至少包括情节中的一个情况，包括布景和动态元素。进一步，一个场景包括一个或两个演员的持续活动"。
Geyer等人[14]对场景的定义是 "由场景、动态元素和可选的驾驶指令"。在Geyer等人[14]中，活动的含义并不详细。
Ulbrich等人[13]将场景定义为“一连串场景中几个场景之间的时间发展。每个场景都从一个初始场景开始。行动和事件以及目标和价值可以被指定，以描述情景中的时间发展特征。除了一个场景外，一个场景的时间跨度是一定的。”[13]的作者指出，行动和事件将不同的场景联系在一起。[13]中没有对行动和事件做进一步的描述。
Elrofai等人[38]给出了自动驾驶背景下场景的另一个定义。他们将场景定义为 "主机车辆在被动[即静态]环境中的行动和演习，以及紧邻的主动[即动态]环境在一定时间内的持续活动和演习的组合"。
Saigol等人[36]将场景定义为 "对AV与其他道路使用者和/或道路基础设施之间短暂互动的描述"。
在一份关于OpenSCENARIO 2.0的概念文件中[52]，场景被定义为 "由道路使用者（行为者实体）的行动定义的'时间发展描述'，其中时间激活（定义何时）'由'条件'触发器'调节。一个场景包括布景和动态元素"。
作为构建情景概念的综合定义的基础，我们将上述定义中包含的主要特征列举如下：
1.一个场景对应一个时间区间。
上述定义[13]、[14]、[38]、[51]指出，一个场景对应于一个时间区间。
Van Notten等人[48]将这样的场景称为链式场景（"像电影一样"），而不是快照场景，即描述某一特定时间瞬间的状态的场景（"像照片一样"）。
2.一个场景由两个或多个事件组成[13]、[14]、[48]、[51]、[53]。
使用事件来开发场景可能会有帮助[49]。因此，一个场景可以被定义为一个特定的事件序列，或者像Kahn [53，第143页]写的那样，"一个场景的结果是试图或多或少地描述一些假想的事件序列"。
此外，Geyer等人[14]和Ulbrich等人[13]使用事件的概念来描述一个场景，尽管他们没有提供事件一词的定义。因为一个场景至少包含一个开始事件和一个结束事件，事件的最小数量是两个。在第III-B节，我们将详细阐述事件的概念。
3.现实世界的交通情景是定量的情景。
关于数据的性质，一个场景可以是定性的，也可以是定量的[48]。为了使真实世界的交通情景适合于模拟目的，必须对其进行定量描述。然而，也可以对场景进行定性描述，以便人类专家能够阅读和理解。
为定量情景提供定性描述，被称为故事和模拟方法[54]。请注意，对一个情景的定性描述并不能唯一地定义一个定量的情景。定性描述可被视为定量场景的抽象，也见第三节D。
4.一个场景的时间区间包含所有相关事件。
根据[14]，"一个场景的结束是由与该场景有关的第一个不相关的情况来定义的"。以类似的方式，我们要求一个场景的时间区间应该包含所有相关的事件。请注意，"相关 "是主观的，因此，一个事件被认为是与一个或多个参与行动者的观点有关，通常被称为 "自主车辆"。
5.一个场景包括对环境的描述。
一个场景应该包括对静态和动态环境的描述。尽管对静态环境的描述不是情景的一般前提，但在谈到交通情景时，经常包括这一点[13]、[14]、[19]、[30]、[38]。静态环境由所有相关的物理元素组成，这些元素在场景开始和结束的时间区间内不会对自主车辆发生相关的变化。
动态环境由所有相关的参与者组成，这些参与者发生的变化与自主车辆有关。例如，道路可能是静态环境的一部分，但如果路面温度的变化与自主车辆有关，道路就是动态环境的一部分。
6.一个场景包括至少一个自主车辆[14], [38]。
由于前面提到的两个特点，要求一个场景至少要包括一辆自主车辆。 请注意，自主车辆通常被视为被测设备。然而，在本文中，这是没有必要的，因为自主车辆只是一个载体，其视角被用来定义场景中的相关内容。
7.情景描述了行为人的目标或活动。
无论是活动、目标，还是活动和目标的组合，都需要确定情景中的每个行为者如何对具体事件做出反应。请注意，这对自主车辆也是成立的，因为自主车辆是一个行为者。在使用真实世界的数据描述一个场景时，不需要给出目标；例如，Elrofai等人[38]提到了行动者的活动而不是目标。
然而，当描述一个AV必须应对的场景时，可以指定自主车辆的目标（即其驾驶任务[14]）而不是其活动[13]。请注意，如果描述的是行为者的活动而不是其目标，观察者可能无法确定行为者是否成功地对情景做出了反应。
因此，我们将一个场景定义如下：
定义1（情景）：情景是对自主车辆、静态环境、动态环境的相关特征和活动和/或目标的定量描述，以及在第一个和最后一个相关事件之间的时间区间内与自主车辆相关的所有事件。
当在OOF中应用定义1时，只需提供对该组件的引用，就可以给出该场景的组件的“描述”。一个引用可以是，例如，一个文件的全名，一个指向计算机内存特定部分的指示器，或者一个针对数据库中特定条目的标识符。
引用的好处是，场景的这些部分可以在不同的场景中进行交换，因为这些场景可以使用相同的引用。例如，OpenSCENARIO文件允许提供对OpenDRIVE文件的引用，该文件描述了一个道路网络[55]。正如我们将在第四节看到的，在我们提出的框架中，一个场景可能包含对物理元素、活动、行为者和事件的引用。
B.事件
正如定义1中提到的，一个场景由事件组成。事件一词被用于许多不同的领域，例如：
在计算[56]时，事件是软件识别的动作或事件。事件的一个常见来源是软件用户的输入。一个事件可能触发一个状态转换。
在概率论中，一个事件是一个实验的结果或一组结果[57]。例如，抛出的硬币背面着地就是一个事件。
在混合系统理论领域，"当连续状态[矢量]达到连续状态空间的某些规定集时，连续和离散动态在'事件'或'触发'时间相互作用" [58]。此外，"一个混合系统可以处于几种模式之一，[......]，由于事件的发生，系统从一种模式切换到另一种模式"[59]。
在ISO 15926-2标准中，规定了一个用于长期数据整合、访问和交换的本体，其中事件被定义为 "一个在时间上范围为零的可能个体，这意味着它发生在时间的某一瞬间"[60] 。
在基于事件的控制中，控制动作是在事件触发时计算的，这与更传统的控制动作是定期计算的方法不同[61]。在基于事件的控制中，事件是在系统（即将）达到某个阈值的时刻触发的。
在提供事件的定义之前，根据前述文献，对事件的结论如下：
1.一个事件对应一个瞬间。
对于事件的定义，我们考虑采用混合系统的线性时间模型[62]。因此，事件发生在某个时间瞬间。
2.一个事件标志着一个模式的转换或一个系统达到阈值的时刻。
诱发模式转换的原因可能是输入信号的突然变化、参数的变化、模型的变化或外部原因。也有可能事件标志着一个系统达到一个阈值的时刻。
因此，我们对事件的定义如下：
定义2（事件）：一个事件对应于发生模式转换或系统达到特定阈值的时刻，其中前者可以由内部和外部原因引起。
定义2表明，一个事件的时刻可以用两种不同的方式来定义：(1）通过模式转换或（2）通过系统达到一个阈值。第一种类型可能是由一个突然的驱动器输入引起的模式转换。一个事件也可能是由外部原因引起的，如环境变化。第二类事件，即与系统达到阈值有关，在描述测试场景时特别有用。
例如，考虑自主车辆接近一个即将过马路的行人[63]。这里，事件标志着车辆和行人之间的距离小于dv,p米的时刻。在这个事件发生的时刻，行人开始穿过马路，如果车辆不改变其速度或方向，就会与行人发生碰撞[63]。通过使用一个可变的阈值dv,p，该值是灵活的，可以通过不同的设置来定义多种情况。
对于事件的实际执行，可以规定一组条件。在这种情况下，事件发生在条件满足的时刻。在[29]中，给出了一个广泛的可用于定义事件的条件清单。例如，一个条件可以是车辆和行人之间的距离低于某个阈值。
备注1：Ulbrich等人[13]和Geyer等人[14]使用术语场景来定义一个场景。
与事件一样，我们认为场景对应于整个场景的临时快照。场景可以通过取整个场景的时间横截面来获得，如定义1所述。
C.活动
为了描述一个场景的动态环境，使用了活动。一个场景也可以描述自主车辆的活动。活动[11]、[14]、[35]、[37]、[64]和行动[13]、[14]、[65]这两个术语都是在自动驾驶的背景下使用。虽然严格来说，行动和活动这两个词的含义略有不同，但它们经常被用于同一目的：
根据[13]，行动可以被指定用于描述场景中的时间发展特征。
Elrofai等人[11]认为活动是场景动态部分的一个构件："活动是状态变量的时间演变，如速度和方向，以描述例如变道，或刹车至静止"。
在情景目录开发的词汇表[35]中，活动被定义为 "一个对象在一个时间区间内的状态[矢量]。一个活动以一个事件开始，以另一个事件结束"。
在ISO 15926-2标准中，活动被定义为 "一个可能的个体，通过引起标志着一个可能的个体的开始或结束的事件而带来变化"[60]。
在提供活动的定义之前，根据上述文献，对活动的结论如下：
1.一个活动对应于一个事件间的时间区间。
相对于事件而言，活动跨越了一定的时间间隔。此外，一个活动的开始和结束都由一个事件来标志。
2.一项活动定量地描述了一个或多个状态变量的时间演变。
因为活动是情景的组成部分，而情景对应的是量化的描述，所以活动本身也需要量化。因此，一项活动描述了一个或多个状态变量的时间演变，即一个或多个状态变量在与该活动相对应的事件间时间区间内的轨迹，其中状态变量一词的定义见表I。
3.一个活动是由一个行为者执行的。
一个活动描述了一个或多个状态变量的时间演变，而一个状态变量对应于一个行为者，例如，车辆的加速度。
因此，我们对活动的定义如下：
定义3（活动）：活动是对一个行为者的一个或多个状态变量在两个事件之间的时间演变的定量描述。
例如，一项活动可以描述在加速或减速期间的纵向加速度（或，例如，速度）。描述车辆相对于相应车道中心的横向位置的活动，被标记为 "直线行驶 "或 "改变车道"。
D.场景类别
根据定义1，在AV的性能评估方面，一个场景需要是定量的。然而，在文献中，场景一词也被用来指代场景的集合，其中这个场景的集合被定性描述。例如，在[66]中，提出了一个预碰撞情景的类型学。
在这里，每一个碰撞前的情景都是许多定量情景的抽象。类似的研究已经进行，以描述导致高速公路事故[67]、汽车-自行车事故[68]和汽车-行人事故[69]的情景。在[70]中，提出了一个场景分类法，以定性地描述自动驾驶的挑战性场景。在[23]中，对所谓的功能场景、抽象场景、逻辑场景和具体场景进行了区分。
这四种类型的情景描述代表了不同的抽象水平，功能情景指的是非正式的人类可读情景，抽象情景指的是正式的声明性描述，逻辑情景指的是具有参数范围和分布的参数化情景，而具体情景指的是具有固定参数值的参数化情景。
前面提到的参考文献[23], [66]-[70]显示，术语情景也被用来处理定性描述。由于我们将情景定义为定性描述，我们需要引入一个不同的术语来处理定性描述。
我们建议使用情景类别这一术语来指代情景的定量描述。定性描述可以被看作是定量场景的抽象，而定量描述可以被看作是定性描述的具体化。
因此，我们对情景类别的定义如下：
定义4（情景类别）：情景类别是对自主车辆、静态环境和动态环境的相关特征和活动和/或目标的定性描述。
引入情景类别的概念会带来以下好处：
对人来说，解释定性描述往往比定量描述更容易。
有共同点的情景可以归为一组，这就可以对情景的类型进行定性，便于对情景进行讨论。
一组情景的完整性可以通过考虑情景类别的完整性（见[71]）和每个类别中情景的完整性（见[72]）来评估。
用动词 "组成 "来描述一个场景和一个场景类别之间的形式关系，用∈来表示。如果特定场景类别C是特定场景S的抽象，那么我们说C包含S，或者简单地说C∈S。一个给定的情景类别可以包括多个情景，多个情景类别可以包括一个特定的情景。因此，与[66]、[68]、[69]、[73]中提议的情景分类不同，情景分类不需要相互排斥。
动词 "包括 "用于描述两个情景类别之间的关系。如果一个情景类别C2包括C1中包含的所有情景，那么就说它包括一个情景类别C1。在这种情况下，我们可以写成C2⊇C1。因此，我们得出：
我们建议为场景和场景类别提供标签形式的额外信息。标签是一个关键字或一个关键词，它提供了关于一段数据的额外信息[74]。例如，数据库中的项目可以包含一些标签，使用户能够快速检索出几个具有标签所描述的某一特征的项目[75]。这些标签的使用带来了几个好处：
情景的标签可以帮助确定哪些情景类别构成和不构成情景。
通过使用标签或标签的组合，很容易从场景数据库或场景库中选择场景。
在拥有通用的情景类别- 和情景类别所包含的情景广泛的多样性-以及具有特定的情景类别包含的情景中没有太多的多样性之间存在着平衡。
对于某些系统，人们可能对一组特定的情景感兴趣，而对于另一个系统，人们可能对一组具有高度多样性的情景感兴趣。为了适应这一点，标签可以用层次树结构[76]。树的不同层可以看作是不同的抽象层次[77]。
图1显示了取自[16]的两个标签树的例子。这些标签描述了车辆的可能活动，即横向运动控制（通过转向）和纵向运动控制（通过加速和减速）。在没有定义活动的情况下，标签可以指行为者的目标。
例如，在一个测试案例中，自主车辆的目标是左转，那么标签 "转弯 "和 "左转 "是适用的。请注意，标签不仅可以用来对车辆行为进行分类，还可以用来对交通和环境情况进行分类，例如，"加塞 "或 "大雨"。
IV.面向对象的场景框架
我们已经在II-A中解释了OOF的使用。在本节中，我们将介绍OOF用于评估AV的场景。框架的概述通过类图正式表示出来，这些类图在 IV-A中简要介绍。接下来，第IV-B节解释了在我们的框架中如何正式表示一个情景类别。
同样，在第IV-C中，我们描述了一个场景是如何被正式表示的。OOF可以在面向对象的语言中直接实现，比如C++和Python，因为这些语言支持类的定义，从这些类中实例化对象，以及诸如继承和聚合等概念。
OOF在编码语言中的实际实现可以在https://github.com/ ErwindeGelder/ScenarioDomainModel上公开获得。这个链接也包含了OOF的技术应用教程。
图1. 车辆的横向和纵向活动的标签[16]。横向活动是相对于相应车辆所处的车道而言的。
图2. 我们的面向对象框架（OOF）的大多数类的类级关系。
在图2和图3中，蓝色实心块代表根据定义4用于描述情景类别的类，红色实心块代表根据定义1用于描述情景的类。绿色的虚线块代表所谓的抽象类。抽象类不能被实例化。每个类都作为创建对象的模板，而某个特定类的对象则被称为该特定类的实例。
图2显示了类级关系，而图3显示了实例级关系。在图2中，从例如Scenario到Time interval的箭头表示Scenario是Time interval的一个子类。因此，时间区间的所有属性都被Scenario继承了。图3中带有菱形的箭头表示一个聚合。
这意味着，例如，一个行为者，作为一个实例，有一个行为者类别属性。在这里，从Actor类别到Actor的箭头起点处的 "1 "表示一个行为者正好有一个行为者类别。同样，从事件到时间区间的聚合箭头处的 "2 "表示一个时间间隔包含两个事件，即定义时间间隔的开始和结束的事件。
图3. 我们的面向对象框架（OOF）的大多数类的实例级关系。
聚合箭头开始处的 "0，1，... "表示一个对象有零个、一个或多个相应类别的对象。带有文字“comprise”和“includes”的箭头表示在第III-D节中解释的方法。
这里，“comprise”可以用s表示，“includes”可以用⊇表示，见(1)。
因为图2中的所有其他类都是Scenario元素的子类，这些类继承了Scenario元素的属性和程序。在我们的框架中，一个场景元素有一个可由人类解释的名字，一个唯一的ID，以及可能的预定义标签，这些标签也可以由软件代理解释。所以，图2中的所有其他类也有这些属性。除了这些属性外，定性元素类还有一个可供人类解释的描述。
静态环境是由一个或多个物理元素类别来定性描述的。因为物理元素类别定性地描述了静态环境，它们包含了对它们所描述的物理事物的人类可理解的描述。
自主车辆和动态环境由活动类别和行为者类别来定性描述。根据定义3，活动类别包括状态变量。指定用于描述状态变量的时间演变的模型。注意Model是一个抽象类，用作不同模型的模板，例如图2中所示的三个例子:正弦、线性和常数。设z(t)表示t时刻的状态变量，则正弦模型定义如下:
其中振幅(A)、持续时间(T)、初始时间(t0)和初始状态(z0)为参数。线性模型和常数模型分别用以下方程描述:
线性模型包含三个参数，即斜率(s)、初始时间(t)和初始状态(z)。常数模型只有参数z0。
由于活动类别是一种定性描述，其模型的参数值并不是活动类别的一部分。请注意，本文只考虑了正弦波、线性和常数模型，但要描述复杂的行为，可能需要更复杂的模型。更复杂的模型不在本文的讨论范围内，但用这样的模型来扩展OOF是很简单的。
行为者类别是物理元素类别的一个子类，所以行为者类别继承了物理元素类别的属性。此外，行为者类别有一个属性，指定对象的类型。为了表明一个行为者是一个自主车辆，标签 "自主车辆 "被添加到行为者类别的标签列表中。
情景类别有物理元素类别、活动类别和行为者类别作为属性。情景类别的另一个属性是行为列表。这些行为描述了哪些行为者执行哪些活动。注意，有可能一个行为者执行多项活动，也有可能一项活动由多个行为者执行。
读者可能会问，为什么我们要引入描述一个情景类别的不同类别，即蓝色块，而不是只用一个类别来模拟一个情景类别。不同类的主要优点是类的实例的可重用性，因为这些实例可以在不同的情景类别中交换。
例如，如果两个场景类别有相同的行为者类别，我们只需要定义一次行为者类别，而如果行为者类别不是一个类的实例，而只是场景类别的属性，我们将需要定义两次行为者类别。
为了区分直接用于组成场景的对象，这些对象是由数量元素类的子类实例化而来的。
场景类是时间区间的一个子类，因此，它有定义场景开始和结束的事件。场景还将物理元素、活动、行为者和事件作为属性。
物理元素、活动和行为者是物理元素类别、活动类别和行为者类别的定量对应物，正如情景是情景类别的定量对应物一样。与情景类别一样，情景包含一个行为列表，描述哪些行为者进行哪些活动。
一个物理元素有一个物理元素类别，它可能有多个定量定义物体的属性，如其大小、重量、颜色、雷达截面等。物理元素可以用来定义，例如，道路布局、静态天气和照明条件以及基础设施元素。
根据定义3，一个活动定量地描述了一个或多个状态变量在一个时间区间内的演变。状态变量是由活动所具有的属性的活动类别来定义的。与活动类别所包含的模型一起，状态变量的时间演变被一组参数所描述。这些参数的值是活动的一部分。
按照定义2，一个事件包含描述事件发生时的阈值或模式转换的条件。
与物理元素和活动类似，行为者也有其定性的对应物--行为者类别--作为属性。此外，该行为者还包含一个初始状态向量和一个期望状态向量，可以用来指定意图，作为属性。描述意图对定义测试场景特别有用，因为它是以自主车辆的目标而不是以其活动来定义的。
拥有物理元素、活动和行为者的定性对应物的一个好处是，定性描述可以被重复使用和交换。例如，可以有许多不同的制动活动，但只需要有一个活动类别来定性地定义制动活动。
这里假定所有的制动活动都是用相同的模型建模的，并且适用类似的标记。如果不是这样，就需要定义多个活动类别，但活动类别的数量仍将大大低于活动的数量。
V.例子：人行横道
为了说明OOF的使用，我们描述了一个使用第四节中介绍的类的对象的场景。该场景如图4所示。自主车辆在一条双车道道路的右侧车道上行驶，一名行人在与自主车辆行驶的道路相交的人行道上行走。
自主车辆和行人最初都在接近人行横道。自主车辆刹车，在人行横道前完全停住。当自主车辆静止时，行人使用人行横道穿过道路。当行人通过自主车辆时，自主车辆加速。这个例子的代码是公开的。
图4. 一个场景的示意图，在这个场景中，自主车辆和行人都在接近一个没有信号灯的人行横道。行人有优先权。
这个特殊的场景可以用来制定一个评估AV的测试场景。例如，在评估一个行人自动紧急制动系统时[63]，我们对该系统在司机或自主车辆的自动化系统不制动的情况下的行为感兴趣。
我们首先使用我们提出的框架定性地描述了这一情景。接下来，第V-B节对该场景进行了定量描述。在第V-C节中，我们展示了如果我们考虑一个有过路行人的实际测试场景，哪些对象被重复使用，哪些对象是不同的。
A.人行横道的定性描述
为了根据所提出的领域模型描述场景，从图2和图3中的类中实例化了一些对象。图5显示了用于定性描述场景的对象。有两个行为者类别：一个是自主车辆，一个是行人。
四个不同的活动类别被定义为：刹车、静止、加速和直走。刹车、静止和加速活动类别包含状态变量vego，即自我车辆的速度，并分别使用（2）和（3）的正弦模型、（5）的常数模型和（4）的线性模型。
两个行为者类别，四个活动类别，以及代表人行横道的物理元素类别，都被情景类别使用。情景类别有四个行为。前三个行为将前三个活动类别分配给自主车辆。最后一个行为将活动类别中的直行分配给行人。
B.人行横道的定量描述
用于定量描述情景的对象如图 6 所示。两个行动者指的是图5中行动者类别的定量对应物。
使用图4所示的坐标框架为每个行为者列出初始状态向量。由于我们描述的是一个真实世界的场景，所以没有必要为行为者定义目标或意图。
共定义了四个事件。这些事件标志着定义活动开始和结束的时间点。为简单起见，假设情景的开始时间为0秒。
图5所示。用于定性描述图4图解所示场景的对象。每个块的第一行显示了名称(在双冒号之前)和实例化对象的类。下面几行显示对象的属性，属性的名称和值分别在冒号之前和之后。为了简洁起见，省略了每个对象的惟一ID。
图6所示。用于定量描述如图4所示情景的对象。为了简洁起见，我们省略了每个对象的标记和惟一ID。
有四种活动被定义，每一种活动都是指其质量上的对应关系。这些活动包含参数值以及标志活动开始和结束的事件。
正如第一项活动（自主车辆刹车）所描述的那样，自主车辆以8米/秒的速度启动，在4秒内刹车，完全停住。通过对（2）的正弦函数进行两次积分，可以看出，自主车辆在离行人过街中心4米处停下。
如第二项活动（自我静止）所述，在等待3秒后，自主车辆以1.5米/秒的速度加速到 7.5米/秒，如第三个活动（自主车辆加速）所描述的。第四个活动描述了行人的位置和速度。
人行横道描述了整个静态环境，包括自主车辆行驶的主路和人行道。
图6中的例子显示了道路布局的一些属性，以说明如何描述静态环境。请注意，在实践中，静态环境的定量描述可能包含比图6中提到的更多的方面。如第III-A节所述，可以参考另一个包含静态环境（部分）描述的来源，见[55]。
情景有先前定义的物理元素、行动者和活动作为属性。这些行为被用来将前三个活动分配给自主车辆，最后一个活动分配给行人。场景也有标志着场景开始和结束的事件。
不同的场景可以通过，例如，改变参数值来定义。这说明，图5中的情景类别包括多种情景，包括仅因参数值不同而与图6中的情景不同的情景。
图7. 这些对象与图5中的自主定性、行人定性、直线行走和行人过马路定性以及图6中的开始场景、行人和行人过马路等对象一起，描述了一个测试场景，该场景示意图如图4。为了简洁起见，每个对象的标签和唯一的ID被省略了。
C.人行横道的测试场景
在这个例子中，我们考虑一个基于先前说明的真实世界场景的测试场景，见图4。为了描述这个测试场景，我们重新使用了图5中的两个角色类别（自我定性和行人定性）和图6中描述行人的角色（行人过街）。图7显示了用于描述这个测试场景的其他对象。
该情景类别与图5所示的情景类别的唯一不同之处在于，它不包含描述自主车辆的活动类别。
对自主车辆的定量描述有两个属性是不同的。首先，初始状态向量还包括场景开始时的速度，用vego表示，而且初始位置离行人过街处更远，这样自主车辆的驾驶员或自动化系统就有更多的时间来感知行人了。
第二，因为没有为自我车辆定义活动，所以定义了期望状态向量。目标是在以vego=8 m s-1的速度行驶时到达自我车辆前方80米处。
假设自主车辆的速度不变，当自主车辆距离人行道中心2.5秒时，标志着行人行走活动开始的事件被触发。在自主车辆以vego =8 m s-1的速度行驶的情况下，这是在20米的距离下，类似于图6中描述的情况。
与情景类别一样，该情景不包含自主车辆的活动。此外，情景的结束事件也有不同的定义：现在，如果自主车辆到达目的地（xego≥20米），与行人相撞，偏离路径太多（yego≤-2米或yego≥1米），或到达目的地的时间太长（t>100秒），则情景结束。
请注意，这个例子考虑的是一个以固定速度（1米/秒）过马路的行人，而不考虑自主车辆的靠近。为了模拟，例如，行人注意到自主车辆并在即将发生碰撞时加速的情况，可以添加一个描述行人速度增加（例如，2米/秒）的活动。
这个活动的开始是在一个预定义的事件上，例如，条件是xego/vego1s和yped < 0 m。
D.实例说明
这个例子说明了定义场景时面向对象方法的好处，这些好处是:
清楚地说明情景的内容，
模块化，这使得我们很容易理解从图6的真实世界场景到图7的测试场景的变化，以及
可重用性，正如被多次使用的对象所说明的那样。
此外，图5至图7中列出的每个对象都可以直接转换为面向对象编程语言中的一个对象。为了进一步说明所提出的OOF在现实生活中的实用性，该框架被TNO的StreetWise程序用来在数据库中存储现实世界的场景[11]。
在这个例子中，我们考虑了两个不同的行为者：自主和行人。这些都是交通参与者的例子，但行为者不一定是交通参与者。
例如，在基础设施到车辆的通信环境中传输信息的路边单位也可以是行为者。在这种情况下，信息的传输可以被认为是一种活动。行为者的另一个例子是路面，如果对场景来说，模拟表面温度的变化是很重要的。
VI.总结
自动驾驶汽车（AVs）的性能评估对于自动驾驶汽车的法律和公众接受以及自动驾驶汽车的技术发展至关重要。由于情景对评估至关重要，因此需要对情景进行明确的定义。
在这项工作中，我们在性能评估AV的背景下提出了一个新的概念场景的定义。
虽然我们的定义与文献中的其他定义一致，但它更具体，以至于可以直接用代码实现。我们进一步定义了事件、活动和场景类别的概念。为了正式确定场景、事件、活动和场景类别的概念，我们提出了一个面向对象的框架（OOF）。
使用所提出的框架，有可能以定性和定量的方式描述一个场景。该框架用类图表示，可以直接转化为面向对象的软件实现的类结构。这使我们能够将场景翻译成代码，这样领域专家和软件程序，如仿真工具，都能够理解场景的内容。为了证明这一点，我们已经公开了我们在编码语言Python中的实现。
OOF已经通过一个带有人行横道的城市场景示例进行了说明。我们还演示了如何使用这个特定的场景来使用提议的框架定义一个测试场景。在所提出的OOF的公开编码实现中，我们已经展示了如何从实际应用的角度使用所提出的OOF。
所提出的框架适用于场景挖掘[39]，[78]和基于场景的评估[6]，[11]，因此，该框架为实现基于场景的AVs性能评估提供了一个步骤。下一步是定义与特定部署区域的AV相关的场景和场景类别。
未来的工作还包括创建一个用于评估AVs的场景本体。提出的OOF可以作为[41]的一个很好的起点。本体允许向关系添加属性，从而实现自动推理。通过这种方式，本体实现了场景的自动分类，从而帮助克服数据模糊的问题[52]。
附录A
名词术语
对于场景的定义，我们从文献中采用了几个概念。在这一节中，详细介绍了文献中采用的自主车辆、物理元素、行为者、静态环境、动态环境、行为、状态变量、状态矢量、模型和模式等概念。
A.自主车辆
自主车辆是一个场景的主体。特别是，自主车辆是指通过其传感器感知世界的车辆（见，例如，[77]）。 在进行测试时，自主车辆也指必须执行特定任务的车辆（见，例如，[30]，[35]）。在这种情况下，自主车辆通常被称为被测系统[4]、被测车辆[5]或主机车辆[5]。
B.物理元素
物理元素是指存在于三维空间的物体。
C.行为者
根据[35]，"行动者是一个场景中的所有动态部分，不包括自主车辆本身"。请注意，与[35]相比，在本文中，自主车辆的司机，和/或自动化系统被认为是行动者，与[14]类似，因为它们具有与另一个司机或自动化系统相同的属性。
虽然前面提到的[35]的定义很好地说明了行为者可能是什么，但为了避免循环定义，我们使用了另一个定义:行为者是一个动态的物理元素，即经历变化的物理元素。
备注2：行为者也是一个物理元素，而物理元素不一定是行为者。例如，一个静态的路标被认为是一个物理元素，但因为它在一个场景的过程中没有变化，所以它不是一个行为者。
D.静态环境
静态环境指的是环境中在一个场景中不发生变化的部分。这包括地理空间上的固定元素[13]，如道路网络。
E.动态环境
相对于静态环境，动态环境指的是环境中在一个场景的时间范围内发生变化的部分。 在实践中，动态环境主要包括与自主车辆有关的移动行为者（除自主车辆外）。
例如，OpenSCENARIO[29]是一种用于描述驾驶模拟动态内容的文件格式，其主要用例是描述 "涉及车辆、行人和其他交通参与者等多个实体的复杂、同步的动作" [29]；所以对于OpenSCENARIO来说，这些动作代表了动态环境。与通信范围内的车辆进行通信的路边设备[79]也是动态环境的一部分。
此外，不断变化的（天气）条件也是动态环境的一部分。
备注3：请注意，环境中的某个元素是属于静态环境还是动态环境，可能并不总是那么明显。然而，最重要的是，所有与AV评估相关的环境部分都在静态或动态环境中描述。
F.行动
我们将行为定义为行为人和行为人所执行的活动的组合，或行为人和他们所参与的活动的组合。这与[29]中对行为一词的使用是一致的。
G.状态变量
Dorf和Bishop [80, p. 163]写道:“在给定激活输入和描述动力学的方程的情况下，状态变量描述了系统的当前配置，可以用来确定未来的响应。”在我们的案例中，"系统 "可以指一个行为者、一个组件或一个模拟。例如，一个状态变量可以是一个行为者的加速度。
H.状态矢量
状态矢量是指 "包含所有n个状态变量的向量"[80, p.233]
I.模型
一个动态系统通常使用形式为z˙(t)= fθ(z(t), u(t), t)的微分方程来建模[81]，其中z(t)代表时间t的状态向量，u(t)代表外部输入向量，函数fθ(. )的参数化为θ。注意，严格来说，z(. )、u( . )、t和θ是函数f的输入，但θ被认为在某个时间区间是不变的。例如，以下一阶模型的参数为θ=（a，b）：
J.模式
在一些系统中，系统的行为可能突然发生突变，例如，由于输入、模型参数或模型的突然变化。这样的转变被称为模式转换。在每个模式中，系统的行为由一个具有固定函数fθ和平滑输入u(. )的模型描述[59]。
参考文献：
[1]K. Bengler, K. Dietmayer, B. Färber, M. Maurer, C. Stiller, and
H. Winner,“Three decades of driver assistance systems: Review and futureperspectives,” IEEE Intell.Transp. Syst. Mag., vol. 6, no. 4, pp. 6–22, Oct. 2014.
[2] W. Wachenfeld and H. Winner,“The release of autonomous vehicles,” in
Autonomous Driving, Berlin, Germany: Springer, 2016, pp. 425–449.
[3] T. Helmer, K. Kompaß, L. Wang, T. Kühbeck, and R. Kates, Safety Performance Assessment of Assisted and Automated Driving in Traffic: Simulation as Knowledge Synthesis. Berlin, Germany: Springer, 2017, pp. 473–494.
[4] J. E. Stellet, M. R. Zofka, J. Schumacher, T. Schamm, F. Niewels, and J. M. Zöllner, “Testing of advanced driver assistance towards au- tomated driving: A survey and taxonomy on existing approaches and open questions,” in Proc. IEEE 18th Int. Conf. Intell. Transp.Syst., 2015, pp.1455–1462.
[5] O. Gietelink, J. Ploeg, B. De Schutter, and M. Verhaegen, “Development of advanced driver assistance systems with vehicle hardware-in-the-loop simulations,” Veh. Syst. Dyn., vol. 44, no. 7, pp. 569–590, 2006.
[6] A. Pütz, A. Zlocki, J. Bock, and L. Eckstein, “System validation of highly automated vehicles with a database of relevant traffic sce- narios,” in Proc. 12th ITSEur. Congress, 2017, pp. 1–8. [Online]. Available: https://www.pegasusprojekt.de/files/tmpl/pdf/12th%20ITS% 20European%20Congress_Folien.pdf
[7] C. Roesener et al., “A comprehensive evaluation approach for highly automated driving,” in Proc. 25th Int. Tech. Conf. Enhanced Safety Veh., 2017, pp. 1–13. [Online].Available: https://www-esv.nhtsa.dot.gov/ Proceedings/25/25ESV-000259.pdf
[8] S. Riedmaier, T. Ponn, D. Ludwig, B. Schick, and F. Diermeyer, “Survey on scenario-based safety assessment of automated vehicles,” IEEE Access, vol. 8, pp. 87 456–87 477, 2020.
[9] A. Knapp, M. Neumann, M. Brockmann, R. Walz, and T. Winkle, “Code of practice for the design and evaluation of ADAS,” Eur. Automobile Manufacturers’ Assoc. (ACEA), RESPONSE III: a PReVENT Project, Tech. Rep Response3_CoP_e_v5.0.doc, 2009.[Online]. Available: https:
//www.acea.auto/files/20090831_Code_of_Practice_ADAS.pdf
[10] Road Vehicles - Functional Safety, Standard ISO 26262, International Organization for Standardization, 2018.[Online]. Available: https://www. iso.org/standard/68383.html
[11] H. Elrofai, J.-P. Paardekooper, E. de Gelder, S. Kalisvaart, and O. Op den Camp, “Scenario-based safety validation of connected and automated driving,” Netherlands Org. Appl. Sci. Res., TNO, Tech. Rep., 2018. [Online]. Available: http://publications.tno.nl/publication/ 34626550/AyT8Zc/TNO-2018-streetwise.pdf
[12] A. Aparicio et al., “Pre-crash performance of collision mitigation and avoidance systems: Results from the ASSESS project,” in Proc. World Automot. Congr., 2013, pp. 489–505.
[13] S. Ulbrich, T. Menzel, A. Reschka, F. Schuldt, and M. Maurer, “Defin- ing and substantiating the terms scene, situation, and scenario for auto- mated driving,” in Proc. IEEE 18th Int. Conf. Intell. Transp. Syst., 2015, pp. 982–988.
[14] S. Geyer et al., “Concept and development of a unified ontology for generating test and use-casecatalogues for assistedand automated vehicle guidance,” IET Intell. Transp. Syst., vol. 8, no. 3, pp. 183–189, 2014.
[15] M. R. Zofka, F. Kuhnt, R. Kohlhaas, C. Rist, T. Schamm, and J. M. Zöllner, “Data-driven simulation and parametrization of traffic scenarios for the development of advanced driver assistance systems,” in Proc. 18th Int. Conf. Inf. Fusion, 2015, pp. 1422–1428. [Online]. Available: https://ieeexplore.ieee.org/abstract/document/7266724
[16] E. de Gelder, O. Op den Camp, and N. de Boer, “Scenario categories for the assessment of automated vehicles,”CETRAN, Tech. Rep., 2020, ver- sion 1.7. [Online]. Available: http://cetran.sg/wp-content/uploads/2020/01/REP200121_Scenario_Categories_v1.7.pdf
[17] H. Weber et al., “A framework for definition of logical scenarios for safety assurance of automated driving,” Traffic Inj. Prevention, vol. 20, no. sup1, pp. S65–S70, 2019.
[18] M. Gyllenhammar et al.,“Towards an operational design domain that supports the safety argumentation of an automated driving system,” in Proc. 10th Eur. Congr. Embedded Real Time Syst., 2020, pp. 1–10. [On- line]. Available: https://www.diva-portal.org/smash/get/diva2:1390550/ FULLTEXT01.pdf
[19] A. Ebner, T. Helmer, R. R. Samaha, and P. Scullion, “Identifying and analyzing reference scenariosfor the development and evaluation of active safety: Application to preventive pedestrian safety,” Int. J. Intell. Transp. Syst. Res., vol. 9, no. 3, pp. 128–138, 2011.
[20] W. Hulshof, I. Knight, A. Edwards, M. Avery, and C. Grover, “Autonomous emergency braking test results,” in Proc. 23rd Int. Tech. Conf. Enhanced Saf. Vehicles, 2013, pp. 1–13. [Online]. Available: https://cdn.euroncap.com/media/1384/aeb-test-results-esv-2013-0-a837f165-3a9c-4a94-aefb-1171fbf21213.pdf
[21] Z. Xiong and J. Olstam, “Orchestration of driving simulator scenarios based on dynamic actor preparation and automated action planning,” Transp. Res. C, Emerg. Technol., vol. 56, pp. 120–131, 2015.
[22] Y. Shao, M. A. Mohd Zulkefli, Z. Sun, and P. Huang, “Evaluating con- nected and autonomous vehicles using a hardware-in-the-loop testbedand a living lab,” Transp. Res. C, Emerg. Technol., vol. 102, pp. 121–135, 2019.
[23] C. Neurohr, L. Westhofen, M. Butz, M. Bollmann, U. Eberle, and R. Gal- bas, “Criticality analysis for the verification and validation of automated vehicles,”IEEE Access, vol. 9, pp. 18016–18041, 2021.
[24] F. Rosique,P. J. Navarro, C. Fernández, and A. Padilla, “A systematic review of perception system and simulators for autonomous vehicles research,” Sensors, vol. 19, no. 3, 2019, Art. no. 648.
[25] P. Wimmer et al.,“Toward harmonizing prospective effectiveness assess- ment for road safety: Comparing tools in standard test case simulations,” Traffic Inj. Prevention, vol. 20, no. sup1, pp. S139–S145, 2019.
[26] Q. Chao et al.,“A survey on visual trafficsimulation: Models, evaluations, and applications in autonomous driving,” Comput. Graph. Forum, vol. 39, pp. 287–308, 2020.
[27] P. Kaur, S. Taghavi, Z. Tian, and W. Shi, “A survey on simulators for testing self-driving cars,” 2021, arXiv:2101.05337. [Online]. Available: https://arxiv.org/abs/2101.05337
[28] A. Nehemiah, P. Fryscak, and M. Sasena, “Building an Autonomous Vehicle (AV) simulation toolchain with Simulink, RoadRunner and NVIDIA DRIVE Sim,” Blog Post, 2021. [Online]. Available: https://blogs.mathworks.com/student-lounge/2021/04/26/building-an-autonomous-vehicle-av-simulation-toolchain-with-simulink- roadrunner-and-nvidia-drive-sim/
[29] OpenSCENARIO, 2021, Accessed: Dec. 2021. [Online]. Available: https:
//www.asam.net/standards/detail/openscenario/
[30]M. Althoff, M. Koschi, and S. Manzinger, “CommonRoad: Composable benchmarks for motion planning on roads,” in Proc. IEEE Intell. Veh. Symp., 2017, pp. 719–726.
[31] W.-T. Tsai, A. Saimi, L. Yu, and R. Paul,“Scenario-based object-oriented testing framework,” in Proc. 3rd Int. Conf. Qual.Softw., 2003, pp. 410–417.
[32] M. Utting, A. Pretschner, and B. Legeard, “A taxonomy of model- based testing approaches,” Softw. Testing Verification Rel., vol. 22, no. 5, pp. 297–312, 2012.
[33] M. R. Zofka,S. Klemm, F. Kuhnt,T. Schamm, and J. M. Zöllner,“Testing and validating high level components for automated driving: Simulation framework for traffic scenarios,” in Proc. IEEE Intell. Veh. Symp., 2016, pp. 144–150.
[34] D. Wittmann, M. Lienkamp, and C. Wang, “Method for comprehensive and adaptive risk analysis for the development of automated driving,” in Proc. IEEE 20th Int. Conf. Intell. Transp. Syst., 2017, pp. 1–7.
[35] A. B. Frost,“MUSICC: Multi user scenario catalogue for CAVs, glossary of terms and definitions,” Catapult Transp. Syst., 2018.
[36]Z. Saigol, A. Peters, M. Barton, and M. Taylor, “Regulating and acceler- ating development of highly automated and autonomous vehiclesthrough simulation and modelling,” Catapult Transp. Syst., 2018.
[37] Special Interest Group (SIG) on SImulation and Modeling (SIM), “Mod- eling and simulation glossary,” 2021, Accessed: Dec. 2021. [Online].
Available:https://sigsim.acm.org/mskr/glossary.htm
[38]H. Elrofai, D. Worm, and O. Op den Camp, “Scenario identification for validation of automated driving functions,” in Proc. Adv. Microsyst. Automotive Appl., 2016, pp. 153–163.
[39]E. de Gelder, J. Manders, C. Grappiolo, J.-P. Paardekooper, O. Op den Camp, and B. De Schutter, “Real-world scenario mining for the assessment of automated vehicles,” in Proc. IEEE Int. Transp. Syst. Conf., 2020, pp. 1073–1080.
[40]E. de Gelder, H. Elrofai, A. Khabbaz Saberi, O. Op den Camp, J.-P.Paardekooper, and B. De Schutter, “Risk quantification for automated driving systems in real-world driving scenarios,” IEEE Access, vol. 9, pp. 168953–168970, 2021.
[41] W. V. Siricharoen, “Ontology modeling and object modeling in software engineering,” Int. J. Softw. Eng. Appl., vol. 3, no. 1, pp. 43–59, 2009.
[42]R. E. Johnson and B. Foote, “Designing reusable classes,” J. Object- Oriented Program., vol. 1, no. 2, pp. 22–35, 1988.
[43]P. Wegner, “Concepts and paradigms of object-oriented programming,”
ACM SIGPLAN OOPS Messenger, vol. 1, no. 1, pp. 7–87, 1990.
[44]C. Patridge, Business Objects: Re-Engineering for Re-Use.Tysons, VA, USA: The BORO Centre, 2005.
[45]E. Gamma, R. Helm, R. Johnson, and J. Vlissides, “Design patterns: Abstraction and reuse of object-oriented design,” in Proc. Eur. Conf. Object-Oriented Program., 1993, pp. 406–431.
[46] A. Snyder, “Encapsulation and inheritance in object-oriented program- ming languages,” in Proc. Object-Oriented Program. Syst. Lang. Appl., 1986, pp. 38–45.
[47]B. Meyer,“Reusability: The case for object-oriented design,” IEEE Softw., vol. 4, no. 2, pp. 50–64, Mar. 1987.
[48]P. W. F. van Notten,J. Rotmans, M. B. A. Van Asselt,and D. S. Rothman, “An updated scenario typology,” Futures, vol. 35, no. 5, pp. 423–443, 2003.
[49] P. Bishop, A. Hines, and T. Collins, “The current state of scenario devel- opment: An overview of techniques,” Foresight, vol. 9, no. 1, pp. 5–25, 2007.
[50]SAE International, “Taxonomy and definitions for terms relatedto driving automation systems for on-road motor vehicles,” Tech. Rep. J3016, Jun. 2018.
[51] K. Go and J. M. Carroll, “The blind men and the elephant: Views of scenario-based system design,” Interactions, vol. 11, no. 6, pp. 44–53, 2004.
[52] OpenSCENARIO 2.0, 2020, Accessed: Dec. 2021. [Online]. Avail- able:https://releases.asam.net/OpenSCENARIO/2.0-concepts/ASAM_ OpenSCENARIO_2-0_Concept_Paper.html
[53] H. Kahn, Thinking the Unthinkable. New York, NY, USA: HorizonPress, 1962.
[54] J. Alcamo, “Scenarios as tools for international environmental assess- ment,” Eur. Environ. Agency,Tech. Rep. 24, 2001.
[55] M. Dupuis, M. Strobl, and H. Grezlikowski, “Opendrive 2010 and beyond - Status and future of the de facto standard for the descrip- tion of road networks,” in Proc. Driving Simul. Conf. Europe, 2010, pp. 231–242.
[56] R. Breu et al.,“Towards a formalization of the unifiedmodeling language,” in Proc. Eur. Conf. Object-Oriented Program., 1997, pp. 344–366.
[57] P. E. Pfeiffer, Concepts of Probability Theory. Chelmsford, MA, USA: Courier Corp., 2013.
[58] M. S. Branicky,V. S. Borkar, and S. K. Mitter, “A unified frameworkfor hybrid control: Model and optimal control theory,” IEEE Trans. Autom. Control, vol. 43, no. 1, pp. 31–45, Jan. 1998.
[59] B. De Schutter, “Optimal control of a class of linear hybrid systems with saturation,” SIAM J. Control Optim., vol. 39, no. 3, pp. 835–851, 2000.
[60] R. Batres et al.,“An upper ontologybased on ISO 15926,” Comput. Chem. Eng., vol. 31, no. 5/6, pp. 519–534, 2007.
[61] W. P. M. H. Heemels, K. H. Johansson, and P. Tabuada, “An introduction to event-triggered and self-triggered control,” in Proc. 51st IEEE Conf. Decis. Control, 2012, pp. 3270–3285.
[62] R. Alur and D. L. Dill, “A theory of timed automata,” Theor. Comput. Sci., vol. 126, no. 2, pp. 183–235, 1994.
[63] P. Seiniger, A. Hellmann, O. Bartels, M. Wisch, and J. Gail, “Test pro- cedures and results for pedestrian AEB systems,” in Proc. 24th Int. Tech. Conf. Enhanced Saf. Veh., 2015, pp. 1–11.
[64] S. Childress, B. Nichols, B. Charlton, and S. Coe, “Using an activity-based model to explore the potential impacts of automated vehicles,” Transp. Res. Rec., vol. 2493, no. 1, pp. 99–106, 2015.
[65] G. Bagschik, T. Menzel, and M. Maurer, “Ontology based scene creationfor the development of automated vehicles,” in Proc. IEEE Intell. Veh. Symp., 2018, pp. 1813–1820.
[66] W. G. Najm, J. D. Smith,and M. Yanagisawa, “Pre-crash scenario typology for crash avoidance research,” U. S. Dept. Transp. Res. Innov. Technol. Admin., Tech.Rep. DOT HS 810 767, 2007.
[67] F. Fahrenkrog, L. Wang, C. Roesener, J. Sauerbier, and S. Breunig, “Deliverable D7.3 impact analysis for supervised automated driving ap- plications,” AdaptIVe, Tech. Rep. Deliverable D7.3, 2017.
[68] O. Op den Camp, A. Ranjbar, J. Uittenbogaard, E. Rosen, R. Fredriksson, and S. de Hair, “Overview of main accident scenarios in car-to-cyclist accidents for use in AEB-system test protocol,” in Proc. Int. CyclingSaf. Conf., 2014.
[69] J. Lenard, A. Badea-Romero, and R. Danton,“Typical pedestrian accident scenarios for the development of autonomous emergency braking test protocols,” Accident Anal. Prevention, vol. 73, pp. 73–80, 2014.
[70] Transport Systems Catapult,“Taxonomy of scenariosfor automated driv- ing,”Transp. Syst. Catapult, Tech. Rep., 2017.
[71] F. Hauer,T. Schmidt, B. Holzmüller, and A. Pretschner, “Did we test all scenarios for automated and autonomous drivingsystems?,” in Proc. IEEE Intell. Transp. Syst. Conf., 2019, pp. 2950–2955.
[72] E. de Gelder, J.-P. Paardekooper, O. Op den Camp, and B. De Schutter, “Safetyassessment of automatedvehicles: How to determine whetherwe have collected enoughfield data?,” TrafficInj. Prevention, vol. 20, no. S1, pp. 162–170, 2019.
[73] A. Lara, J. Skvarce, H. Feifel, M. Wagner, and T. Tengeiji, “Harmonized pre-crash scenarios for reaching global vision zero,” in Proc. 26th Int. Tech. Conf. Enhanced Saf. Veh., 2019, pp. 1–19. [Online]. Available: https:
//www-esv.nhtsa.dot.gov/Proceedings/26/26ESV-000110.pdf
[74] G. Smith, Tagging: People-Powered Metadata for the Social Web. Indi- anapolis, IN, USA: New Riders Publishing, 2007.
[75] D. H. Craft,P. A. Caro, J. Pasqua, and D. C. Brotsky, “Taggingdata assets,” U.S. Patent 6, 704, 739 B2, 2004.
[76] S. Molloy, T. Ramos,and S. Thakar, “Dynamic hierarchical tagging system and method,” U.S. Patent 9, 613,0 99 B2, 2017.
[77] S. Bonnin, T. H. Weisswange, F. Kummert,and J. Schmuedderich, “Gen- eral behavior prediction by a combination of scenario-specific mod- els,”IEEE Trans. Intell. Transp. Syst., vol. 15, no. 4, pp. 1478–1488, Aug. 2014.
[78] J.-P. Paardekooperet al., “Automatic identification of critical scenarios in a public dataset of 6000 km of public-road driving,” in Proc. 26th Int.Tech. Conf. Enhanced Saf. Veh., 2019, pp. 1–8. [Online]. Available: https:
//www-esv.nhtsa.dot.gov/Proceedings/26/26ESV-000255.pdf
[79] S. Al-Sultan, M. M. Al-Doori, A. H. Al-Bayatti, and H. Zedan, “A comprehensive survey on vehicular ad hoc network,” J. Netw. Comput. Appl., vol. 37, pp. 380–392, 2014.
[80] R. C. Dorf and R. H. Bishop,Modern Control Systems, 12th ed. Englewood Cliffs, NJ, USA: Prentice Hall, 2011.
[81] S. N. Norman, Control Systems Engineering. Hoboken, NJ, USA:Wiley, 2011.
分享不易，恳请点个【👍】和【在看】
