Disclaimer This document is the copyrighted property of ASAM e.V. Any use is limited to the scope described in the license terms (https://www.asam.net/license). In alteration to the regular license terms, ASAM allows unrestricted distribution of this standard. §2 (1) of ASAM’s regular license terms is therefore substituted by the following clause: "The licensor grants everyone a basic, non-exclusive and unlimited license to use the standard ASAM OpenSCENARIO". 免责声明 ASAM e.V. 拥有该文档的版权。 任何使用均局限于许可条款 (https://www.asam.net/license) 所描述的范围内。在常规许可条款的基础上，ASAM允许该标准不受限制地被分发。因此，ASAM常规许可条款 license terms 的 §2 (1) 可被以下条例所替代：许可方授予每个人使用标准ASAM OpenSCENARIO的基本、非排他性和无限制许可。

Foreword 前言

OpenSCENARIO comprises the specification and file schema for the description of the dynamic content in driving simulation applications. The primary use of OpenSCENARIO is the description of complex maneuvers that involve multiple vehicles.

OpenSCENARIO包含了仿真应用中动态内容的说明及文件组成模式。其主要用于描述多车复杂操作工况。

OpenSCENARIO is used in virtual development, test and validation of driver assistance functions, automated and autonomous driving. The standard may be used in conjunction with ASAM OpenDRIVE and ASAM OpenCRG, which describe static content in driving simulation.

OpenSCENARIO用于辅助驾驶及自动驾驶功能的虚拟开发、测试与验证。本标准可与ASAM OpenDRIVE和ASAM OpenCRG中关于驾驶仿真的静态内容结合使用。

After the standard was developed over several years in an industry consortium, it was transferred to ASAM e.V. in November 2018.

The standards' html documentation is accompanied by the more comprehensible User Guide. The specification is based on a UML data model from which XML schema files are derived. Thus, the standard comprises the following content:

• User Guide

• UML model

• Model documentation (html)

• XML schema files

• List of analyzed deficits and proposed improvements

• Examples

• 用户指南

• UML模型

• 模型文档（html）

• XML模式文件

• 已分析的不足之处及优化建议

• 示例

1. Introduction 介绍

1.1. Overview 概况

1.1.1. What is a Scenario? 什么是场景？

A scenario is a description of how the view of the world changes with time, usually from a specific perspective. In the context of vehicles and driving, this encompasses the developing view of both world-fixed (static) elements such as the road layout and furniture, and world-changing (dynamic) elements such as weather and lighting, vehicles, objects, people or traffic light states. This description is irrespective of whether the environment is simulative, real or any combination thereof.

1.1.2. What is OpenSCENARIO? 什么是OpenSCENARIO？

OpenSCENARIO defines the dynamic content of the (virtual) world (e.g. behavior of traffic participants). Static components (such as the road network) are not part of OpenSCENARIO but can be referenced by the format.

OpenSCENARIO定义了（虚拟）世界中的动态内容（例如：交通参与者的行为）。该标准并不包含静态内容（例如：道路网络），这部分内容通过引用相关标准进行补充。

OpenSCENARIO defines a data model and a derived file format for the description of scenarios used in driving and traffic simulators, as well as in automotive virtual development, testing and validation. The primary use-case of OpenSCENARIO is to describe complex, synchronized `Maneuver`s that involve multiple instances of `Entity`, like `Vehicle`s, `Pedestrian`s and other traffic participants. The description of a scenario may be based on driver `Action`s (e.g. performing a lane change) or on instances of `Trajectory` (e.g. derived from a recorded driving `Maneuver`). The standard provides the description methodology for scenarios by defining hierarchical elements, from which scenarios, their attributes and relations are constructed. This methodology comprises:

• Storyboarding, i.e. usage of a `Storyboard`, `Story` instances, `Act`s, `ManeuverGroup`s and `Maneuver`s

• Usage of` Event`s triggered by `Trigger`s, defined by `Condition`s. `Event`s cause `Action`s executions

• References to logical road network descriptions

• Instantiation of instances of` Entity`, such as `Vehicle`s, or `Pedestrian`s, acting on and off the road

• Utilization of re-use mechanisms (i.e. `Catalog`s and `ParameterDeclaration`)

OpenSCENARIO定义了一个数据模型及以此为基础的文件格式，其用于描述驾驶与交通仿真模拟器、虚拟开发、测试与验证中使用的场景。OpenSCENARIO的主要应用体现在描述复杂的、同时发生的车辆操作`Maneuver`s，其中包括多个不同的实体`Entity`实例，例如车辆`Vehicle`s，行人`Pedestrian`s以及其他交通参与者。场景的描述可基于驾驶员的驾驶行为`Action`s（例如：变道）或运动轨迹`Trajectory`的实例（例如从驾驶操作`Maneuver`记录中导出）。本标准使用从上至下不同的要素层次（hierarchical elements）作为场景描述的方法。这方法用于建立场景、场景的属性和相互关系。该方法包含：

• 场景剧本StoryBoarding，例如使用场景剧本`Storyboard`及场景内容`Story`、动作集`Act`、操作组`ManeuverGroup`和各种操作`Maneuver`

• 使用由触发器`Trigger`触发并由条件`Condition`定义的事件`Event`；事件`Event`促使动作`Action`的执行

• 引用逻辑道路网络等静态要素相关描述

• 对各类不同的实体`Entity`实例如路上及路边的车辆`Vehicle`和行人`Pedestrian`进行实例化

• 重复使用机制，如通过目录`Catalog`和参数声明`ParameterDeclaration`等形式

Other content, such as the description of the Ego Vehicle, driver appearance, `Pedestrian`s, traffic and environment conditions, is included in the standard as well.

The data for scenario descriptions in OpenSCENARIO is organized in a hierarchical structure and serialized in an XML file format.

OpenSCENARIO中的场景描述包含从上至下的多个层次，这些数据通过XML文件序列化转化为可读取文件格式。

The standard is based on an UML data model which is used to derive XML schema files for XML file validation. Moreover, the standard is comprised of a reference guide and this user guide.

The standard can be used together with road network descriptions defined according to the standard ASAM OpenDRIVE . The three standards complement each other in a way that they describe the entire content required to describe the virtual world for driving simulation, virtual test, development and validation.

1.2. Motivation 初衷

Scenario descriptions are essential for testing, validating and certifying the safety of driver assistance systems and autonomous driving cars. The industry, certification agencies and government authorities jointly work on the definition of scenario libraries, which can be used to test and validate the safe operation of such systems. A publicly developed and vendor-independent standard, such as OpenSCENARIO, supports this endeavor by enabling the exchange and usability of scenarios in various simulation applications.

With the help of OpenSCENARIO, large numbers of critical situations can be run across various simulators. Thus, compared to road testing in real traffic, the amount of driven test kilometers in field tests can be significantly reduced.

1.3. Scope 范围

In a simulation context a complete scenario is comprised of the following parts:

• Static environment description, including:

• Optionally physical and geometric road and environment descriptions

• Dynamic content description, including:

• Overall description and coordination of behavior of dynamic entities

• Optional behavior models of dynamic entities

• 静态环境：

• 道路网络逻辑

• 可选：道路路面物理信息，道路设计几何信息及环境的描述

• 动态环境：

• 运动物体的行为描述及相互关系

• 可选：运动行为模型

OpenSCENARIO describes the dynamic content, including the overall description and coordination of behavior of dynamic entities.

OpenSCENARIO描述了动态内容，其中包括运动物体的行为及相互关系。

OpenSCENARIO does not specify the behavior models themselves, nor their handling by the simulation engine, including initialization and setup, runtime interfaces, packaging, etc.

OpenSCENARIO并未详细说明行为模型本身，也未详细说明仿真器该如何对模型进行处理，包括初始化和设置、运行接口、封装等行为。

OpenSCENARIO also does not define the road network or any geometric, visual or physical assets and characteristics used in a simulation. These are instead employed through references to other established formats. Hence, in certain contexts, OpenSCENARIO can be considered as a top-level container. It references other specifications for other relevant parts of the overall scenario.

OpenSCENARIO不对如何在仿真中使用道路网络，或任何几何、视觉资源或物理特性进行定义，而是通过引用其他相关标准来与这些信息建立关联。因此，在某些情况下，OpenSCENARIO可以被视为顶层架构，它将通过引用其他相关部分来建立全方位的场景。

Beyond the pure scenario itself, many other pieces of information are needed to describe a full simulation setup and test case. OpenSCENARIO should not be regarded as a complete specification of a simulator, its system under test or its test case. The following features specifically are not considered in scope for the OpenSCENARIO standard:

 Test configuration description 测试配置说明 The standard neither describes the actual test instance nor its structure. 本标准既没有描述任何实际的测试实例，也没有描述其结构。 System under test 待测系统 The exact description of the system under test, e.g. detailed vehicle configuration, sensor placement, sensor models etc. is not part of OpenSCENARIO. OpenSCENARIO并不包含待测系统的准确说明，例如详细的车辆配置，传感器位置，传感器模型等。 Test case language 测试用例语言 Although including a set of driver input, the standard does not attempt to specify all possible user or system interactions with a vehicle. 即便包括了一些用于描述驾驶员输入的内容，本标准也并未详细说明驾驶员或驾驶系统与车辆之间所有可能产生的信息交互。 Test evaluation 测试评估 Even though the standard includes the evaluation of conditions for triggering actions, there is no concept for creating test verdicts. 即便本标准包含了对如何触发车辆动作条件的评估，但是它并不能作为测试结果的依据。 Driver model 驾驶员模型 The standard includes the physiological description of a driver such as height and weight. However, except for basic road following, the standard does not include behavioral driver models. 本标准包含了对于驾驶员基本生理特征的描述，例如身高和体重, 但并不包括驾驶员的行为模型。 Vehicle dynamics 车辆动力学 Although the standard describes maneuvers in a kinematic way, it also defines a very basic vehicle model, which can be used for more realistic vehicle dynamics simulation. The standard does not include all necessary elements to specify advanced motion dynamics. 尽管本标准以动力学的方式呈现了车辆操作（maneuvers），也定义了基本的车辆运动模型，但该标准并不包括高级动力学的所需要素。 Road network 道路网络 The standard does not include elements to describe roads, other than references to an external road network description. The OpenDRIVE standard can be used for this purpose . 本标准不包含道路信息要素，但可引用第三方的道路网络描述，例如OpenDRIVE标准。 3D environment models 3D环境模型 The standard only specifies how to refer to external 3D environment models. Further details, like file format or model structure, are not specified. 本标准仅规定了如何引用第三方提供的三维3D环境模型，但并未指定其他详细信息，例如文件格式或模型结构。 Environmental models 环境模型 The standard incorporates elements to specify the current time and weather information but does not describe how this is to be interpreted by the simulator. 本标准涵盖了当前的时间和天气信息要素，但未说明仿真器该如何表达该信息。

OpenSCENARIO hence focuses on information relevant to the dynamic scenario components, such as the sequence of `Action`s the instances of `Entity` would be performing. However, most of these `Action`s also depend on the static components that define the environment in which these `Action`s take place (e.g. a lane change `Action` may happen in a straight or a curved road, while a highway exit scenario could only be realized when the `Actors` are close to an actual highway exit). Therefore, OpenSCENARIO files contain references that bind the scripted dynamic movements to static environments.

2. Relations to Other Standards 与其他标准的关联

2.1. Backward Compatibility to Earlier Releases and Migration 向后兼容到早期版本和迁移

Standard version 1.0.0 and the predecessor version 0.9.1 differ in terms of semantics, naming and even structure. As consequence, the model version 1.0.0 cannot provide backward compatibility to version 0.9.1.

Instead, OpenSCENARIO provides an XSLT migration script to transform valid files of the earlier version 0.9.1 into valid OpenSCENARIO 1.0.0 files. Within this script, each element of the 0.9.1 version has a template that transforms and reshapes the element to OpenSCENARIO 1.0.0.

2.1.1. Migration Issues 迁移的问题

The following issues may arise when migrating between versions 0.9.1 and 1.0.0:

• Renaming of types and properties.

• Adding required properties and assign a default value to them

• Adding required properties even though there is no way to define default values for the new property

• Removing classes (de-supporting classes like traffic jam)

• Structural change (moving branches in combination with renaming types, or consolidate different branches into a single branch)

• Migrating from an unknown or unclear semantic in Version 0.9.1

• 类型和属性的重命名

• 添加必要属性并赋予其一个默认值

• 即使无法设置新属性的默认值，仍需添加所需属性

• 删除例如不再支持例如交通拥堵这样的类

• 结构更改：通过类型重命名来移动分支，或将不同的分支合并为一个分支

• 从0.9.1版本未知或不清晰的语义迁移到新版本。

Any of these specific issues are addressed in the documentation and in the XSLT-transformation script:

Table/表 1. HTML类文档的迁移内容
Documentation 文档 Content 内容

Forward

There is a mapping for each type declared in version 0.9.1 which enables tracking of what happened with that branch in version 1.0.0.

Backward

For each class in version 1.0.0, there is migration information that enables back tracking to the version 0.9.1.

2.1.2. Migration Execution 执行迁移

Any migration issue is addressed in the XSLT-transformation script. In rare cases, the migration cannot create a valid or a consistent document. If an invalid document is created, an error prompts/informs the user, that a manual check is necessary. If an inconsistent document is created, a warning will be shown to the user.

`WARNING: Review catalogs since driver catalog and pedestrian catalogs are merged into controller catalog.`

The original 0.9.1 description of a traffic source does not require a name property. Migration adds a name property that must be reviewed by the user.

`ERROR: OSCTrafficDefinition.DriverDistribution.Driver cannot be migrated automatically and will result in invalid XML output.`

The original 0.9.1 description of a driver distribution was semantically unclear. It cannot be consistently migrated to version 1.0.0.

2.1.3. Migration Prerequisites 迁移的前提条件

As a core task, migration should transform a document that is validated by the schema 0.9.1 into a valid XML document that validates against the schema 1.0.0.

As a minimum prerequisite, a 0.9.1 scenario description must validate against the 0.9.1 schema. Further, the 0.9.1 description must be semantically valid in respect to valid links (e.g. to catalogs, defined parameters etc.). Migration neither checks the semantic validity for the ingoing 0.9.1 description, nor the semantic validity of the resulting 1.0.0 description.

2.2. References to Other Standards 其他标准的引用

2.2.1. OpenDRIVE

In order to use semantic road network information within a scenario, the road network description OpenDRIVE [1] can be referenced. This also includes road surface profiles, as referenced by OpenCRG [2].

3. Concepts 方案

There are three mandatory concepts within every scenario. First, the fundamental concept of a scenario is that a` RoadNetwork` (the static driving infrastructure, including `TrafficSignals`) is populated by instances of `Entity` (e.g. road users, including `Vehicle`s and `Pedestrian`s), which interact according to a set of instructions defined in the `Storyboard`. Only in rare cases, no `RoadNetwork` description is referenced in a scenario. In this case, instances of `Entity` can only be positioned, moved and located using Cartesian coordinates and many `Action`s defined by OpenSCENARIO can only be used with restrictions.

Second, the scenario’s `Storyboard` contains at least one, but possibly multiple instances of `Story`. The elements of a `Story` are placed within a specific structure (as detailed in [Storyboard]):

• `Story` 场景内容

• `Act` 动作集

• `ManeuverGroup` 操作组

• `Maneuver` 操作

• `Event` 事件

• `Action` 动作

Third, the `Action`s that `Actor`s (instances of `Entity` which are involved in actions) ultimately take are triggered by `Condition`s. More generally, `Condition`s are used in `Trigger`s to start `Act`s and `Event`s or to stop `Act`s and the `Storyboard.` In this sense, `Condition`s are basic building blocks to define dynamic behavior and interactions.

There are two additional concepts, which are intended to make scenarios easy to re-use for different use cases. `Catalog`s are collections of OpenSCENARIO elements. Multiple scenarios can refer to the elements defined within a `Catalog`, thus precluding the need to define the same element multiple times. Additionally, a `ParameterDeclaration` provides the means to define parameters symbolically within a scenario or `Catalog`.

3.1. General Concepts 通用方案

3.1.1. Units 单位

All numeric values within this standard are using SI units (see Table/表 2), unless explicitly stated otherwise. Table/表 2 presents details of the used units.

Table/表 2. Units 单位
Unit of 单位所属 Unit 单位 Symbol 符号

Length 长度

Meter 米

m

Duration, (relative) time 时长，（相对）时间

Second 秒

s

Speed 速度

Meters per second 米/每秒

m/s

Acceleration 加速

Meters per second squared 米/每二次方秒

m/s²

Mass 重量

Kilogram 公斤

kg

Angle 角度

Light intensity 光照强度

Lux 勒克斯

lx

For the definition of date and time the ISO 8601 [3] Basic Notation shall be used. The following format pattern is used: "yyyy-MM-dd 'T' HH:mm:ss '.' FFFZ". Here 'T' is again used as time designator and '.' is used as separator for the following millisecond portion. An explanation is given in Table/表 3.

Table/表 3. Date and Time format specifiers 日期和时间格式说明
Specifiers 格式 Meaning 含义 Example 示例

yyyy

Year (four digits) 年份 (四位数)

`2011`

M, MM

Month in year (without / with leading zero) 月份 (无 / 带有0)

`9, 09`

d, dd

Day in month (without / with leading zero) 日 (无 / 带有0)

`3, 09`

H, HH

Hours, 0-23 count (without / with leading zero) 小时, 0-23的计算方式 (无 / 带有0)

`7, 07`

m, mm

Minutes (without / with leading zero) 分 (无 / 带有0)

`2, 02`

s, ss

Seconds (without / with leading zero) 秒 (无 / 带有0)

`4, 04`

F, FF, FFF

Milliseconds (without / with leading zeros) 毫秒 (无 / 带有0)

`357, 04, 002 `

Z

RFC 822 time zone (time shift to GMT) RFC 822 时区 (时间跳转到格林威治标准时间)

`+100`

At a given date and time of 2011-03-10 11:23:56 in the Central European Time zone (CET), the following standard-format output will be produced:

`2011-03-10T11:23:56.000+0100`

3.1.2. Naming 命名

Elements in scenario descriptions can be referenced from other parts of the description through their names. To ensure that all references can be unambiguously resolved, the following set of rules governs the lookup of names from a reference:

Name lookup proceeds from the referencing element, but encompasses all elements at all hierarchy levels of the scenario hierarchy.

Element names at each level must be unique at that level, i.e. there cannot be more than one element with the same name at the same level (i.e. within the same directly enclosing element). For example, within one `Story`, every `Act` must use a unique name ("MyStory1": "MyAct1", "MyAct2"…​), but the names of the `Act`s might be reused in another `Story` ("MyStory2": "MyAct1", "MyAct2"…​).

If the referenced name is globally unique, then it can be used directly as the only part of the reference.

If the referenced name is not globally unique, then enough name prefixes must be supplied to make the name unique.

A name prefix consists of the name of a directly enclosing element, which is prepended to the name using the separator '::', thus forming a new name reference. This implies that the '::' must not be used in names itself. It disambiguates the name by specifying a directly enclosing element name, thus only selecting names found within elements of the given prefix name.

Multiple prefixes of ever higher enclosing element names, up to, in extreme cases, the root element name, can and must be specified until a globally unique reference name is established.

If a reference cannot be resolved uniquely, for example if too few name prefixes have been specified to disambiguate fully, the result of the lookup is undefined.

3.1.3. Road Networks and Environment Models 道路网络和环境模型

In order to be able to properly describe the behavior of road users, OpenSCENARIO requires a reference to the description of the road network logic. Optionally, a geometric and visual representation of the environment in the form of 3D models may be referenced. Those references are established within the `RoadNetwork` language element. As an example, the OpenDRIVE file format is common when it comes to describing road network logic.

Scenario authors will often need to refer to items defined in the road network (e.g. to instruct a vehicle to drive in a specific lane). OpenSCENARIO does not impose its own naming system for these items; they should be referred to using the names allocated by their own file format.

The following features of the road network may be addressed using OpenSCENARIO:

• Traffic signal

• Traffic signal controller

• 自定义的道路

• 道路内的车道

• 交通信号灯

• 交通信号灯控制器

As mentioned before, a road network description supported by OpenSCENARIO is the OpenDRIVE format [1]. This format describes the logical information related to road structure, such as road id, lane id and road geometry. This information can be used to locate and position instances of `Entity `acting on the road and position traffic participants. If OpenDRIVE is used to represent the road network, its convention for lane numbering should be matched by the OpenSCENARIO file.

In addition to the road network description, 3D models representing the environment may be referenced in a scenario description. Essentially, files containing 3D models provide the geometric and visual representation (e.g. mesh and textures) for elements of the virtual environment including the road surface. Use-cases of 3D models referenced from scenarios are rendering, physical modeling and sensor simulation. Files containing 3D models are considered to be external elements to the OpenSCENARIO format.

 It is also possible to outsource some parts of the scenario description to an external `Catalog` file. The process for referencing these is described in [Catalogs]
 此外，场景描述的某些部分也可以被外部目录`Catalog`文件所收录中。对其进行再引用的方法会在[Catalogs]中做进一步讲解。

3.1.4. Controllers 控制器

`Controller`s can be assigned to `ScenarioObject`s of type `Vehicle` or `Pedestrian`. Once assigned, `Controller`s are activated for a given domain (i.e. longitudinal or lateral) using the `ActivateControllerAction` ([Private action]).

While the `ActivateControllerAction` is executing, the `Controller` assigned to that `ScenarioObject` will manage that domain. `Controller`s may be internal (part of the simulator) or external (defined in another file). Intended use cases for `Controller`s include:

• Specifying that a vehicle should be controlled by the system under test

• Defining "smart actor" behavior, where a `Controller` will take intelligent decisions in response to the road network and/or other vehicles. Hence, Controllers can be used, for example, to make agents in a scenario behave in a human-like way

• Assigning a vehicle to direct human control

• 车辆需由待测系统来控制的说明

• 定义“智能执行者”的行为。控制器`Controller`将对道路网络和/或其他车辆通过智能决策做出响应。因此，控制器的用途之一是让场景中的代理（agents）做出与类似人类的行为。

• 分配一辆车辆让其进入人为接管模式

The `Controller` element contains `Properties`, which can be used to specify `Controller` behavior either directly or by a `File` reference.

3.1.5. Routes 路径

`Route`s are used to navigate instances of `Entity` through the road network based on a list of `Waypoint`s on the road which are linked in order, resulting in directional `Route`s. An `Entity`'s movement between the `Waypoint`s is left to the simulator using the `RouteStrategy` as constraint. There may be more than one way to travel between a pair of `Waypoint`s. If this is the case, the `RouteStrategy` specified in the latter of the pair will be used. Note that the implementation of this strategy may vary between simulators. In order to create unambiguous `Route`s, the user must specify a sufficient number of `Waypoint`s. As long as the `Waypoint`s describe an unambiguous path, the corresponding `Route` specifies a one-dimensional s coordinate system that enables unambiguous localization and positioning.

`Route`s may be assigned to `Actor`s using `AcquirePositionAction` or `AssignRouteAction`. Once assigned, they remain in place until another `Route` overwrites them.

If an `Entity` is on a route, it will normally continue along the same route when it reaches a junction. However, `Action`s involving` Route`s are not lateral `Action`s and do not override or create lateral `Action`s. This means that a `Route` will not be followed if the corresponding` Entity` is in the wrong lane or conflicting lateral behavior is defined (e.g. an `Action` involving a `Trajectory`). In these cases, the route will be ignored.

 An `Actor` is still considered "on the route" if it is on a road section which does not have a `Waypoint` on it but is part of the `Route` between `Waypoint`s as calculated at execution time.
 如果行动者`Actor`正处于一个没有任何航点`Waypoint`的路段上，但只要其路段依旧属于在执行时被计算为航点`Waypoint`之间的路径`Route`的一部分，行动者则仍被视为“在路径上”。

If an `Entity` approaches a junction and is not on a `Route` (or is on a `Route` that cannot be followed) the road to follow will be selected at random from the available options.

Some additional rules apply to `Route`s which pass over the same section of road more than once (see example in Figure 1). The `Route` in the example consists of four `Waypoint`s (shown in boxes) which are linked in order. The part of the route highlighted in red is visited twice: once on the links between `Waypoint`s 1 and 3, and once on the links between `Waypoint`s 3 and 5. To avoid the `Entity` becoming stuck in a loop, the following rules are applied:

• Where an `Entity` is on a road which belongs to more than one link between `Waypoint`s, it should be treated as being on the earliest link which has not already been followed.

• If an `Entity` joins the `Route` just before `Waypoint` 2, it will be treated as being on the link between `Waypoint` 1 and `Waypoint` 2 (and not between 3 and 4).

• Instances of `Entity` will only follow later links than the one they are currently on.

• If an `Entity` joins the `Route` just after `Waypoint` 3, it will go towards `Waypoint` 4 then 5.

• When an `Entity` leaves then rejoins a `Route`, or reaches the final `Waypoint`, any previously visited `Waypoint`s should be ignored.

• If an `Entity` is teleported to `Waypoint` 1 after reaching `Waypoint` 4, it will follow the `Route` as if for the first time.

• 如果实体`Entity`位于一条道路上，且该道路归属航点`Waypoint`之间的多个连接线，则应将其视在尚未使用的最初（earliest）的连接线上。

• 如果实体`Entity`在航点`Waypoint` 2之前参与到路径`Route`中，则该实体将被认定为是位于航点`Waypoint` 1和航点`Waypoint` 2之间的连接线上（而不是在3和4之间）。

• 实体`Entity`将依次使用当前连接线之后的下一条连接线。

• 如果某个实体在航点`Waypoint` 3之后加入路径，它将依次进入航点`Waypoint` 4，然后是航点`Waypoint` 5。

• 当实体`Entity`离开然后重新参与到路径`Route`中或到达最终航点`Waypoint`时，任何先前接触的航点`Waypoint`都应被做忽略处理。

• 如果实体`Entity`在到达航点`Waypoint` 4之后被传送到航点`Waypoint` 1上 ，其对路径`Route`的跟踪将恢复到初始状态。

Figure/图 1. Route passing over the same section of road twice 路线通过同一路段两次

3.1.6. Trajectories 运动轨迹

Instances of `Trajectory` are used to define, in precise mathematical terms, an intended path for `Entity` motion. The motion path can be specified using different mathematical shapes:

• `Polyline` (a concatenation of simple line segments across a set of vertices)

• `Clothoid` (Euler spiral, i.e. a curve with linearly increasing curvature)

• Non-Uniform Rational B-Splines (`Nurbs`) of arbitrary order

• Polyline（通过链接多个线段实现）

• Clothoid （Euler螺旋曲线，即曲率线性增加的曲线）

• 任意阶的非均匀有理B-Splines曲线（Nurbs）

By using `Nurbs`, most relevant paths can be expressed either directly, or with arbitrary approximation: `Nurbs` curves form a strict superset of the curves expressible as Bézier curves, piecewise Bézier curves, or non-rational B-Splines, which can be trivially mapped to corresponding `Nurbs` curves. Since `Nurbs` curves directly support the expression of conic sections (such as circles and ellipses), approximation of e.g. `Clothoid`s using arc spline approaches is feasible.

Another advantage of `Nurbs` curves is the relative ease with which continuity up to a given derivative can be assured: A `Nurbs` curve of degree k (i.e. order k+1), is infinitely continuously differentiable in the interior of each knot span and k-M-1 times continuously differentiable at a knot, where M is the multiplicity of the knot, i.e. the number of consecutive knot vector elements with the same value.

Nurbs曲线的另一个优点是可以相对轻松的完成给定导数的连续性：可以对k阶（即k + 1阶）的Nurbs曲线在每个节点区间和k-M-1的节点无限连续地进行区分，节点中的M代表了节点的倍数，也就是说连贯的节点向量要素可被赋予相同价值。

Commonly used `Nurbs` curves are curves of quadratic (order = 3) and cubic (order = 4) degree, with higher order curves usually only needed to ensure continuity in higher derivatives. Since the effort to evaluate curves increases with higher orders, restricting instances of `Trajectory` to lower orders is recommended, where possible.

Instances of `Trajectory` can be specified using just the three positional dimensions (along the X, Y, and Z axes, see section [Coordinate Systems] for coordinate system definitions). Alternatively, instances of `Trajectory` can also be specified using the three positional dimensions and the three rotational dimensions (heading, pitch and roll) for six total dimensions. In the second case, the path not only specifies the movement of the entity along the path, but also the orientation of the corresponding `Entity` during that movement.

Additionally, an instance of `Trajectory` can be specified with or without a time dimension, allowing for the combined or separate specification of the `Entity`'s longitudinal domain: A `Trajectory` incorporating the time dimension completely specifies the motion of the entity, including its speed, whereas a trajectory without the time dimension does not specify the speed along the path, hence allowing separate control of the speed.

Whilst a `Trajectory` provides a mathematically precise definition of a motion path, the corresponding `Entity`'s behavior is dependent on the `Action`s employing it. Either an `Entity` will follow this path exactly or use it as guidance for the controller to follow as best as the `Entity`'s rules of motion allow.

Trajectory actions are further described in [Motion Control for Entities].

3.1.7. Coordinate Systems 坐标系

Following ISO 8855:2011 [4] convention a coordinate system consists of a set of three orthogonal directions associated with X, Y, Z axes (an axis system) and a coordinate origin. In OpenSCENARIO, there are two main types of coordinate systems:

• A right handed coordinate system, compliant with ISO 8855:2011 definition. Orientation is expressed by a heading(yaw)-pitch-roll sequence of rotations (see Figure/图 2)

• 符合ISO 8855：2011的右手坐标系，其方向通过航向角（Yaw）-俯仰角（Pitch）-横摆角(Roll)这样的旋转序列展现。（参见Figure/图 2

Figure/图 2. Heading, pitch and roll angle in an ISO 8855:2011 compliant coordinate system 符合ISO 8855：2011的右手坐标系中的航向角、俯仰角和横摆角
• A right handed, road based coordinate system defined by two coordinate axes associated with the reference line of the corresponding road (s-axis) and the direction orthogonal to it (t-axis) and pointing leftwards (see Figure/图 3)

• 基于道路的右手坐标系是由两个坐标轴定义的，其一是道路的参考线（s轴，红色），其二为与其垂直的t轴，箭头指向左方（见Figure/图 3）。

Figure/图 3. Road based s, t coordinate system with origin at the beginning of the road 基于道路的s，t坐标系，其坐标原点位于道路起点

The afore mentioned coordinate system types are referenced to create multiple coordinate systems listed in the upcoming subsections.

World Coordinate System (Xw, Yw, Zw) 世界坐标系 (Xw, Yw, Zw)

Coordinate system of type (X, Y, Z) fixed in the inertial reference frame of the simulation environment, with Xw and Yw axes parallel to the ground plane and Zw axis pointing upward.

X、Y、Z类型的坐标系固定在仿真环境的惯性参考坐标系中，Xw和Yw轴平行于地平面，Zw轴指向上方。

Neither origin nor orientation of the world coordinate system are defined by the standard. If a road network is referenced from a scenario, the world coordinate system is aligned with the inertial coordinate system present in this description.

Road Coordinate System (s, t) 道路坐标系 (s, t)

To every road specified in the world coordinate system there is an s, t-type coordinate system assigned. The s-axis follows road reference line while the t-axis, orthogonal to the s-axis, points left. The origin of the s-coordinate resides at the starting node of the road. The origin of the t-coordinate is fixed to the road centerline at the current s-position.

Vehicle Coordinate System (Xv, Yv, Zv) 车辆坐标系 (Xv, Yv, Zv)

The vehicle axis system of type (X, Y, Z), as defined in ISO 8855:2011, is fixed in the reference frame of the vehicle sprung mass, so that the Xv axis is substantially horizontal and forwards (with the vehicle at rest), and is parallel to the vehicle’s longitudinal plane of symmetry, and the Yv axis is perpendicular to the vehicle’s longitudinal plane of symmetry and points to left with Zv axis pointing upward. In OpenSCENARIO, the origin of this coordinate system is derived by projecting the center of the vehicle’s rear axis to the ground plane at neutral load conditions. Nevertheless, the origin remains fixed to the vehicle sprung mass (see Figure/图 4).

Figure/图 4. Vehicle coordinate system. Xv – longitudinal direction, Yv –transverse direction, Zv – vertical direction 车辆坐标系： Xv –纵向, Yv –横向、Zv –垂直方向
Pedestrian / MiscObject Coordinate System (Xp/m , Yp/m , Zp/m) 行人/其他对象坐标系 (Xp/m , Yp/m , Zp/m)

The axis system for a pedestrian (subscript p) or a miscellaneous object (subscript m) is fixed in the reference frame of the object’s bounding box. The X axis is horizontal and normal to the object’s front plane. The Y axis is horizontal and perpendicular to X and points to the left with the Z axis pointing upward.

The origin for this coordinate system is derived from the geometrical center of the object’s bounding box under neutral load conditions (if applicable) projected onto the ground plane.

Positioning 定位

OpenSCENARIO provides various ways to position or localize instances of `Entity` acting in the scenario:

• Absolute/relative in the world coordinate system

• Relative to another `Entity`

• Absolute/relative in the road coordinate system

• Absolute/relative in the lane coordinate system

• Relative to a `Route`

OpenSCENARIO提供了各种方法来定位或放置场景中的实体`Entity`实例：

• 绝对或相对于世界坐标系

• 相对于其他实体`Entity`（的坐标系）

• 绝对或相对于道路坐标系

• 绝对或相对于车道坐标系

• 相对于路径`Route`

3.1.8. Traffic Simulation 交通仿真

Besides the definition of deterministic behavior of instances of `Entity`, OpenSCENARIO also provides ways to define stochastic or not precisely defined behavior. This can be useful, e.g. to create traffic within a scenario or around defined instances of `Entity` increasing the overall realism of a scenario, inducing variance into the scenario sequence or defining parameters of the traffic, like traffic density. For this purpose, surrounding intelligent traffic agents can be defined using `TrafficAction`s. With the help of `TrafficAction`s, the parameterization of traffic sources, traffic sinks and traffic swarms can be specified.

The definition of `TrafficAction`s in OpenSCENARIO does not specify which maneuvers will be executed by the intelligent traffic agents. Instead, those `Action`s specify the initialization or termination of vehicles whose behavior is controlled by external traffic simulation models. Spawned traffic participants will make routing decisions based on their corresponding driver` `model, just as with the `ActivateControllerAction`.

OpenSCENARIO中的交通动作`TrafficAction`并不规定智能交通代理将执行哪些操作。与之恰恰相反的是，这些动作`Action`规定了由外部交通仿真模型控制的车辆的初始化或结束。和启动控制器动作`ActivateControllerAction`一样，被生成的交通参与者将根据其相应的驾驶员模型来做出相应路径决策。

3.2. Components of a Scenario 场景的组成

3.2.1. Storyboard 场景剧本

In OpenSCENARIO, the `Storyboard` encompasses the complete scenario description. The structure and naming of the `Storyboard` concept is similar to that of classical storytelling in narrative fiction e.g. in a theater play. The `Storyboard` provides the answers to the questions "who" is doing "what", and "when" in a scenario. It contains one initialization element (`Init`) followed by one or more `Story` elements.

`Init` is used to set the initial conditions for the scenario, such as the position and speed of instances of `Entity`. It is not possible to specify conditional behavior in this section.

`Init`主要用于设定场景的初始条件，例如实体`Entity`实例的位置和速度。在本节中并不能对条件行为进行说明。

`Story` allows scenario authors to group different aspects into a higher-level hierarchy and therefore provide a structure in large scenarios.

Instances of `Story` in OpenSCENARIO, as in narrative fiction, contain `Act`s that define conditional groups of `Action`s. Each `Act` should focus on answering the question "when" something happens in the timeline of a corresponding `Story`. Answer to that question is provided by the startTriggers and stopTriggers of an `Act`. If a startTrigger evaluates to true, then and only then the included` ManeuverGroup`s are executed.

A `ManeuverGroup` is part of an `Act` and answers the question "who" is doing something in the scenario by assigning instances of `Entity` as `Actors` (see [Maneuver groups and Actors]) to `Maneuver`s. `ManeuverGroup`s can also include `Catalog` references to reuse existing `Maneuver`s. This concept is described in [Catalogs].

`Maneuver`s define "what" is happening in a scenario. They are containers for `Event`s that need to share a common scope, whereas `Event`s control the simulated world or corresponding instances of `Entity`. This is achieved through triggering `Action`s, given user-defined `Condition`s.

The overarching hierarchy is called `Storyboard`. It contains all the elements introduced so far and is depicted in Figure/图 5.

Figure/图 5. Diagram showing the structure of a storyboard 场景剧本的结构展示

3.2.2. Entities 实体

In a scenario, instances of `Entity` are those objects that can - but do not have to - change their location dynamically over time. Instances of `Entity` which are not `Vehicle`s or `Pedestrian`s are called `MiscObject`s. This group comprises the following object classes (which are the same as in the OpenDRIVE format):

• none

• obstacle 障碍物

• pole 杆子

• tree

• vegetation 植物

• barrier 屏障

• building 建筑

• parkingSpace 停车位

• patch 修补

• railing 栏杆

• trafficIsland 交通岛

• crosswalk 人行横道

• streetLamp 路灯

• gantry 起重机架

• soundBarrier 隔音设备

• wind

Instances of `Entity` can be specified in the scenario format but the properties are specific to their type. For example, a `Vehicle` is an instance of `Entity` which provides properties like vehicleCategory and performance. In contrast, a `Pedestrian` is specified by properties like model, mass and name.

`Action`s can change the state of an `Entity`, e.g. its `Position`, speed, or `Controller`. On the other hand, the state of an `Entity` can be queried to trigger an `Action`.

Two main groups of instances of `Entity` are distinguished in OpenSCENARIO:

• `Entity` describes one specific object

• `EntitySelection`s describes a list of instances of `Entity`

• 实体`Entity`描述一个特定的对象

• 实体选择`EntitySelection`描述实体`Entity`实例的列表

Motion Control for Entities 对实体的运动控制

The motion of an `Entity` can be controlled via `Action`s, user assigned `Controller`s or a default `Controller`. It is assumed that each `Entity` has a default `Controller` which takes charge of a motion domain (lateral and/or longitudinal) when `Action`s or user assigned `Controller`s are lacking.

The default `Controller` is expected to maintain speed and lane offset of the `Entity`. In the following cases, the default `Controller` oversees an `Entity`'s motion domain (lateral and/or longitudinal):

• No `Action`s and no user assigned `Controller`s are running

• `Action`s and/or user assigned `Controller`s are running and one motion domain, either lateral or longitudinal, is not addressed

• 没有动作`Action`以及没有用户分配的控制器`Controller`正在运行

• 即使动作`Action`和/或用户指定的控制器正在运行，但并未产生一个横向或纵向运动范围时

3.2.3. Entity Selections 实体选择

`EntitySelection`s can be used to conveniently group instances of `Entity` present in the scenario. They can be referenced anywhere single instances of `Entity` can be used as well, allowing for the assignment of a new status to many instances of `Entity` at once or using their aggregated information as a `Trigger`.

`EntitySelection`s can also be purposefully formed from any combination of objects within the scenario.

One use case of `EntitySelection`s is to choose multiple instances of `Entity` to perform a certain `Maneuver` at the same time. The `EntitySelection` can be directly used as the name of the `Actor` in the `ManeuverGroup`. Then, a `Maneuver` can be created which is triggered e.g. at a certain `SimulationTimeCondition`.

3.3. ManeuverGroups, Maneuvers, Events and Actions 操作组、操作、事件和动作

3.3.1. ManeuverGroups and Actors 操作组和行动者

A `ManeuverGroup` singles out the instances of `Entity` that can be actuated, or referenced to, by the `Maneuver`s inside it. These instances of `Entity` are grouped and referred to as the `Actors` in a `ManeuverGroup`, since they will play a role in the `Maneuver`s to come. The `Actors` group may be left empty. This can occur in situations where the `Maneuver`s in a `ManeuverGroup` lead to `Action`s that are not related to instances of `Entity` but instead to world or simulation states.

An `Actor` can be defined using the `EntityRef` element. This element is then combined in an unbounded list in order to specify `Actor`s for a given `ManeuverGroup`. An `Actor`s list may contain several instantiations of the type `EntityRef`. Additionally, extra instances of `Entity` may be added to the `Actor`s, at triggering time, if the `selectTriggeringEntities` option is active.

The `EntityRef` element explicitly couples an existing `Entity` to an `Actor `in the `ManeuverGroup`. This is achieved by specifying the name of the desired `Entity` in the element. Usage of `EntityRef` is appropriate for situations where the instances of `Entity` of interest are known when the scenario is defined.

The selectTriggeringEntities property is used in situations where the choice of `Actor`s depends on runtime information and is therefore impossible to know at the time the scenario is defined.

When the selectTriggeringEntities property of the `Actor`s of the `ManeuverGroup` is true, all instances of `Entity` whose states are used by the logical expressions in `Condition`s which evaluate to true and are contained in `ConditionGroup`s which evaluate to true, are added to the `EntitySelection` that forms the `Actor`s.

It is possible to combine `EntityRef` with selectTriggeringEntities set to true. In this case, the resulting Actors are the Union of the two.

Finally, a `ManeuverGroup` is defined with a maximumExecutionCount. This setting specifies how many times the `ManeuverGroup` shall run, where the number of runs is incremented by one each time the endTransition occurs (see [Transitions]).

3.3.2. Actions 动作

`Action`s serve to create or modify dynamic elements of a scenario, e.g. change in lateral dynamics of a vehicle or change of the time of day. `Action`s are divided in three categories:

• `PrivateAction`s 专属动作

• `GlobalAction`s 全局动作

• `UserDefinedAction`s 用户定义的动作

In the initialization phase of a scenario, `Action`s are responsible for setting up initial states of dynamic objects, environment, infrastructure, etc. In any later phase of the scenario `Action`s are executed when `Event`s are triggered. In the following subchapters, the subtypes of `Action`s defined in OpenSCENARIO are briefly explained.

Private Action 专属动作

`PrivateAction`s have to be assigned to instances of `Entity`. With `PrivateAction`s one can describe motion, position, and visibility of an `Entity` in the scenario. Moreover, they can define longitudinal or lateral dynamic behavior of instances of `Entity`, such as speed or lane change.

The following types of `PrivateAction`s exist:

PrivateAction包括以下类型：

`LongitudinalAction` 纵向动作

Controlling speed or relative distance to a target. `SpeedAction`s are defined e.g. by an acceleration profile (dynamicShape) while `longitudinalDistanceAction`s are setup via actual distance or a headway time (e.g. using timeGap).

`LateralAction` 横向动作

Using `LaneChangeAction` or `LaneOffsetAction`, a lateral position within a lane can be targeted. Both actions support relative and absolute referencing of the action target. For the `LaneChangeAction`, relative target referencing works differently than absolute referencing. Here, the `Vehicle`s' Xv-axis serves as reference direction. Lane changes are evaluated positive if they’re aligned with the vehicles' positive Yv -axis. Thus, a positive lane change moves the corresponding vehicle to the next actual lane in its positive Yv-axis direction. The road center line is not counted as a lane and thus not considered in this counting. Finally, with `LateralDistanceAction`, a lateral distance to an object can be targeted. For each of the `LateralAction`s the lateral Dynamics can be restricted.

`VisibilityAction` 可视性动作

Enabling/disabling detectability of an `Entity` by sensors or other traffic participants and visibility in the image generator.

`SynchronizeAction` 同步动作

Takes over longitudinal control of an `Entity` in order to reach a desired position. At the same time a reference `Entity` reaches a given reference position. The controlled `Entity` is expected to regulate its speed, in relation to the reference `Entity`, in order to meet the explicit position constraint and implicit time constraint. Optionally, in addition to the desired position, the controlled `Entity` may also be given a `FinalSpeed`. This is the speed which the controlled `Entity` shall have when reaching the destination. This `FinalSpeed` can be specified either as an absolute value or relative to the reference entity.

The `SynchronizeAction` shall terminate when any one of the following occurs:

• At the moment the controlled `Entity` reaches the reference position, regardless of the states and position of the reference `Entity`

• When it is concluded that the controlled `Entity` can’t reach its destination for whatever reason

• 当受控实体`Entity`到达了参考位置时，无论参照实体`Entity`的状态和位置如何，动作都将结束。

• 当受控实体`Entity`无论出于何种原因无法到达其目的地时，动作都将结束。

`SynchronizeAction` does not influence routing or the lateral behavior of the controlled `Entity`. In other words, the destination should lie along the planned `Route` of the `Entity` as defined by the default behavior and/or additional `Action`s.

The purpose of the `SynchronizeAction` is to achieve specific repeatable traffic situations which are tolerant to flexible initial conditions and unpredicted vehicle behavior, e.g. in case of a human driver in the loop.

The example in Figure/图 6 shows how the `SychronizeAction` can be used to provoke an interception situation in an intersection. The dots indicate the respective destinations, which is also the point at which the `SynchronizeAction `ends.

Figure/图 6中的示例描写了如何通过使用同步动作`SychronizeAction`制造交通妨碍的情景。图中带有颜色的圆点代表了各自相应的目的地，这也是同步动作`SynchronizeAction`的终点。

The controlled `Entity` (c1, yellow) will arrive at its destination, indicated by a yellow dot, whenever the reference `Entity` (ego, blue) arrives at its destination, indicated by a blue dot. The `SynchronizeAction` will then terminate, and the synchronization will stop. The controlled `Entity` will move into the intersection according to default behavior or any other active `Action`, causing a dangerous situation for the reference `Entity`, who still have a chance to avoid collision.

Figure/图 6. SynchronizeAction example inducing an interceptor situation 同步动作SynchronizeAction如何触发交通妨碍者的情景

Figure/图 7 shows a very similar scenario to the previous example, but illustrates that the `SynchronizeAction` also works when the controlled `Entity` performs lateral operations in parallel, e.g. following an assigned `Route` or performing lane changes.

Figure/图 7. Example of SynchronizeAction combined with routing 同步动作与路径选择的搭配使用

Figure/图 8 shows a vehicle boxed in, or surrounded, by other vehicles. The `SynchronizeAction` is useful to form constellations at specific locations on the road network, typically proceeding a critical event - for example lead vehicle brakes.

Figure/图 8展示了本车被其他车辆不同程度包围的情景。同步动作`SynchronizeAction`可将图中目标聚集到道路网络中的特定位置，从而对如前车紧急刹车等事件进行演示。

Figure/图 8. SynchronizeAction constellation example 同步动作聚集示例

In this case there are four controlled instances of `Entity` (c[1-4]), each one having an individual `SynchronizeAction` referring to the blue ego car.

`ActivateControllerAction` 激活控制器动作

Explicitly (de-)activating a `Controller` model. This may be done for longitudinal, lateral or both domains.

`ControllerAction` 控制器动作

Assigning a driver model to instances of `Entity` of type `Vehicle` or a model controlling motion behavior for other moving instances of `Entity`. The `ControllerAction` can be alternatively used to override control signals, e.g. apply the brakes.

`TeleportAction` 传送动作

Defining a location or destination of an `Entity` in the scenario. The target position can be described as absolute coordinates or relative to other instances of `Entity`.

`RoutingAction` 路径选择动作

Specifying the `Route` that an `Entity` should follow. There are three ways of specifying a routing:

`AssignRouteAction` 分配路径动作

Using `Waypoint`s on the road network and a `RouteStrategy`.

`FollowTrajectoryAction` 跟随动作运动轨迹动作

Using vertices, timings (optionally) and a corresponding interpolation strategy.

`AcquirePositionAction` 获取位置动作

Specifying a target `Position` for the corresponding `Entity` to reach. The `Entity` will aim to take the shortest travelled `Route` from the current position to the target position along the road network.

Global Action 全局动作

Global `Action`s are used in order to set or modify non-entity related quantities.

`EnvironmentAction` 环境动作

Setting weather state, road condition and time.

`EntityAction` 实体动作

Removing or adding instances of `Entity`.

`ParameterAction` 参数动作

Setting/modifying values of parameters.

`InfrastructureAction` 道路设施动作

Setting/modifying the state of a traffic signal or a traffic signal controller phase.

`TrafficAction` 交通动作

Populating ambient traffic of the following kinds:

• Creation of sources and sinks

• A source will create vehicles, while a sink deletes vehicles. A source spawns new vehicles with the rate defined in the element. If no rate is given, a sink will delete all vehicles reaching its area of influence, but a rate can be defined to specify a maximum amount of vehicles to be removed per second. Removal of vehicles follows the "first in, first out" principle.

• An optional `TrafficDefinition` of a sink is the equivalent of a blacklist, meaning that only vehicles matching this list will be removed while all other vehicles may pass unhindered. However, if no definition is given, it means that all vehicles reaching the sink will be removed.

• Creation of swarm traffic following/surrounding a central object (see Figure/图 9)

• Swarm traffic is set up in the area between inner radius and the outline of the ellipsis defined by the two semi axis attributes (blue area in the picture). The blue area will never contain more swarm vehicles than defined in the numberOfVehicles. If a vehicle is leaving the blue area it is deleted and a new vehicle will be spawned instead.

• 创建源与接收点

• 源会创建车辆，接收点则会清除车辆。源按照其要素定义中的比率 rate 生成新的车辆。若不定义比率 rate，接收点则会清除所有在其影响范围内的车辆。可通过定义比率 rate 来详细说明每秒可清除车辆总数的最大值。对于车辆的清除遵循 “先入先出”原则。

• 接收点中可选的交通定义`TrafficDefinition`相当于一份黑名单，只有黑名单中的车辆才会被清除，其他车辆则可顺畅通过。请注意，如果没有定义黑名单，那么所有落到接收点的车辆都会被清除。

• 创建跟随/环绕中心目标的交通群集（见图9）

• 交通群集设定在内径与椭圆外轮廓之间的区域，该区域由椭圆的长半轴与短半轴的属性来定义（图中蓝色区域）。蓝色区域中包含的群集车辆总数绝不超过车辆总数 numberOfVehicles。若一辆车离开了蓝色区域，该车辆会被清除, 也就是说被新生成的车辆取代。

Figure/图 9. Swarm definition 群集定义

Vehicles spawned by a `TrafficSwarmAction` can trigger `Condition`s just as other instances of `Entity` do. They may also perform `Action`s by being referred to through an entity `Trigger`, but since their names are determined by the simulation, no `Action`s can be modeled by referring to these instances of `Entity` explicitly.

Spawned vehicles will make routing decisions based on their driver model, just as with the `ActivateControllerAction`. Optionally, a starting velocity for the spawned vehicles may be specified. If no velocity is given, the speed limit of the underlying road will be used. All elements make use of a `TrafficDefinition`, where the distribution of the spawned or removed vehicles can be defined by `VehicleCategoryDistribution`. Which vehicles of that category are actually spawned is up to the simulation engine.

User Defined Action 用户定义动作

Users can create their own `Action`s which can incorporate a command or a script file. With `UserDefinedAction`s, a completely customized `Action` can be performed that is specific to the respective simulation environment.

Conflicting Actions 冲突动作

At runtime, it may occur that coexisting `Action`s end up competing for the same resource thus creating a conflict. A quintessential example is the case where an `Action` which controls an `Entity`'s speed clashes with a newly triggered `Action` that tries to control the speed of the same `Entity`.

Where an `Action` acts on an `EntitySelection`, if there is a conflict for one `Entity`, all other instances of `Entity` within the selection are also treated as being in conflict. `Action`s are treated as conflicting if they are competing for control of the same domain of the same resource. For example, a `SpeedAction` always conflicts with any other `SpeedAction` if both target the same `Entity`. Conflicts of `Action`s of different types depend on how the `Action`s relate to each other and need to be identified in a case by case basis. Table/表 6 and Table/表 7 depict the possible runtime conflicts between `Action`s of different types.

If it is determined that a newly triggered `Action` conflicts with a currently ongoing `Action`, the latter is overridden. Overriding a running `Action` is equivalent to issuing a stopTrigger to that `Action`, see [Triggers].

Action Completion Criteria 动作完成标准

`Action`s are considered complete, i.e. they reach their completeState directly after they complete their stopTransitions or endTransitions.

Some `Action`s may not be able to reach the completeState via the endTransition (for details, see chapter 3.7). By definition, these `Action`s are assigned a task that requires constant monitoring or actuation, thus lacking end criteria. An example of such an `Action` is the `SpeedAction` when its `TargetSpeed` is set to continuous. The end criteria for `Action`s are depicted in Table/表 6 and Table/表 7.

An `Action` that cannot reach the completeState via the endTransition has an impact on its parents, preventing them from also reaching a completeState. Such continuous `Action`s can be terminated with a stopTrigger from the `Act` or `StoryBoard` they belong to. Alternatively, continuous `Action`s will also be terminated when overridden by conflicting `Action`s.

Acting on Entity Selections 在实体选择上执行

`PrivateAction`s may be requested to control more than one `Entity` at the time. This occurs when the `Actor`s resolve to an `EntitySelection`, in a `ManeuverGroup`. In these circumstances, all concerned instances of `Entity` shall be actuated simultaneously when the action starts.

`Action`s acting on `EntitySelection`s can only be considered complete if and only if all instances of `Entity` in the selection have completed the tasks specified in the `Action`. For example, a `SpeedAction` acting on five instances of `Entity` will only be complete once all five instances of `Entity` have reached the desired speed, regardless of the fact that some of them may reach that speed earlier than others.

Given any running `Action` acting on an `EntitySelection`, if any of the corresponding instances of `Entity` sparks a conflict with a newly started action, then the running `Action` is overridden. All its instances of `Entity` are supposed to fallback to default behavior simultaneously. For example, `SpeedAction` A controls five instances of `Entity` when `SpeedAction` B starts, aiming to control one `Entity` in Action A. Since the `Action`s are of the same nature, a conflict occurs and `Action` A is overridden. `Action` B will then resume control of the conflicting `Entity` while the remaining instances of `Entity` of `Action` A engage in default behavior.

3.3.3. Events 事件

`Action`s are singular elements which may need to be combined in order to create meaningful behavior in a scenario. This behavior is created by `Event`s which serve as containers for `Action`s. `Event`s also incorporate startTriggers. The latter not only determine when the `Event` starts. They are also used to start the contained `Action`s.

`Action`s always need to be wrapped by `Event`s with only one exception: In the `Init` phase, `Action`s are declared individually.

The maximumExecutionCount setting specifies how many times an `Event` is supposed to run, where the number of runs is incremented by one each time the endTransition is reached.

An `Event` is also parameterized with a definition of priority relatively to `Event`s that coexist in the same scope (`Maneuver`). Whenever an `Event` is started, the priority parameter is taken into consideration to determine what will happen to already ongoing `Event`s in the same `Maneuver`. The three choices concerning the corresponding `Priority` are:

 overwrite All other `Event`s in the scope are stopped and the `Event` starts. skip The `Event` does not leave the standbyState until other `Event`s have finished. parallel The `Event` starts without taking into consideration already running `Event`s.

 覆盖 所有在涉及范围内的其他事件`Event`会被停止，该事件`Event`则会启动。 跳过 该事件`Event`一直保持待机状态standbyState，直到其他事件Event结束。 平行 忽略其他运行中的事件`Event`并启动该事件。

Each `Event` defined in a scenario corresponds to a single runtime instantiation which implies that there cannot be multiple instantiations of the same `Event` running simultaneously. In turn, this means that startTriggers bear no meaning unless the `Event` is in a standbyState, as opposed to each startTrigger starting a new instantiation of the `Event`.

3.3.4. Maneuver 操作

A `Maneuver` groups `Events` together. The definition of a `Maneuver` can be outsourced to a `Catalog` and parameterized for easy re-use in a variety of scenarios. Examples for `Maneuver`s are driving `Maneuver`s, such as a (double) lane change, or an overtaker. Nevertheless, generic combinations of `Action`s can be grouped to `Maneuver`s, e.g. to simulate a weather change.

3.4. Re-Use Mechanisms 复用机制

3.4.1. Parameters 参数

In OpenSCENARIO, parameters are central to provide an extension mechanism for scenarios. With the help of parameters, a scenario designer can make parameterization points of a scenario explicit. External tools can read the provided parameters and thus implement sophisticated methods to assign concrete values to the parameters. By this extension method a scenario can be reused for a large space of concrete values, e.g. the re-simulation of one scenario with different speeds.

In `ParameterDeclaration` all parameters which are used in a scenario, have to be defined. Each parameter is defined by its name, the parameterType and a default, type-specific initialization value. Parameters are declared within `ParameterDeclaration` by their individual names (without any prefix). Assignment of values to parameters declared in a `Catalog` is allowed in `CatalogReference`s. Parameters can be referenced from within the scenario, e.g. for obtaining their values. In this case, a "$" prefix is used to indicate the referencing. 在参数声明`ParameterDeclaration`中，所有场景的参数都必须被定义。每个参数的定义均根据其名称，参数类型parameterType和默认的、类型特定的初始化值而定。 参数声明`ParameterDeclaration`中的参数均通过其各自不带任何前缀的名称来进行声明。在目录引用`CatalogReference`中，值可以分配给在目录`Catalog`中声明的参数。可在场景中对参数进行引用，其中一个目的在于获取它们的值。此处，将通过“$”前缀来识别引用。

Every attribute of an OpenSCENARIO language element can contain a parameter. There is a type inference check defined by the standard which ensures that the parameterType matches. The check is not ensured by the XML validator and therefore has to be implemented by the simulator.

OpenSCENARIO语言要素的每个属性都可包含一个参数。本标准定义了类型校对机制，以确保参数类型 parameterType 的匹配。XML校验器无法为校对提供保障，因此将由仿真器来执行校对。

parameters are set and evaluated at load time of the simulation. `ParameterAction`s and `ParameterCondition`s do not affect these parameters. Moreover, they act during simulation runtime.

parameter names starting with OSC are reserved for special use in future versions of OpenSCENARIO. Generally, it is forbidden to use the OSC prefix.

In parameter names, usage of symbols is restricted. Symbols that must not be used are:

• " " (blank space) (空格)

• $• ' • " Special rules apply to referencing parameters within `Catalog`s (see section 3.4.3). 特殊规则适用于在目录`Catalog`中引用参数（请参阅第3.4.3节）。 3.4.2. Catalogs 目录 Many elements of a scenario require a detailed description, which may not only be rather lengthy but can also be tedious to repeatedly write if the element is used in several different scenarios. `Catalog`s offer the possibility to outsource the description of certain elements from the scenario to a separate file, which can then be referenced from a scenario. 对大部分场景要素进行详细描述的工作是必不可免的，但这些描述普遍过于耗时且在使用要素于不同场景时，需要进行多次重复的描述工作。为了避免此类枯燥的工作，目录`Catalog`提供了一个解决方法，将场景特定要素的描述收录进一个单独的文件中，该文件继而可再被场景引用。 Using `Catalog`s enhances the reusability of elements and the readability of the scenario at the cost of technical detail in the scenario file. In order to refer to an element detailed within a `Catalog`, a reference to the `Catalog` has to be specified in the scenario and at the location where the element is being used the reference of both the `Catalog` and the specific element has to be given. 尽管使用目录`Catalog`会导致场景文件的技术细节丢失，但目录也会因此而提高要素的复用性和增强场景的可读性。为了在一个目录`Catalog`里详细地引用一个要素，必须在场景里详细说明对目录`Catalog`的引用，且在要使用要素的位置提供目录`Catalog`和特定要素的引用。 There are eight different kinds of elements that can be outsourced to a `Catalog`. All kinds of objects can be defined within `Catalog`s, i.e. `Vehicle`, `Pedestrian`, and `MiscObject`, as well as their respective `Controller`s. Navigational instructions in the form of `Trajectory` and `Route` can also be stored within `Catalog`s. Additionally, descriptions of the `Environment` and `Maneuver`s can be outsourced this way. 有八种不同要素可以在目录`Catalog`里得到描述。所有对象如车辆`Vehicle`、行人`Pedestrian`和其他对象`MiscObject`，以及它们相应的控制器`Controller`，都可以在目录`Catalog`中被定义。动作运动轨迹`Trajectory`和路径`Route`等导航性质的说明可以存储在目录`Catalog`里。另外，也可以用这种方式处理环境`Environment`和操作`Maneuver`的描述。 3.4.3. Parameters in Catalogs 目录中的参数 `Catalog` files are designed for reuse, and to support this store their own set of parameters. All `Parameter`s used within a catalog must be declared within its `ParameterDeclaration`, which sets a default value for each parameter. When a catalog is referenced, the `ParameterAssignment` element within `CatalogReference` can be used to override these defaults. 目录`Catalog`文件的目的在于复用以及为存储目录自身的参数提供支持。一个目录里的所有参数都必须在其参数声明`ParameterDeclaration`中，该参数声明会为每一个参数设定一个默认值。在引用一个目录时，可以用目录引用`CatalogReference`里的参数分配`ParameterAssignment`要素来对这些默认值进行覆盖。 For example, a catalog definition could contain the following `ParameterDeclaration`: 例如，一个目录定义可包含以下参数声明`ParameterDeclaration` ``````<ParameterDeclarations> <ParameterDeclaration name = "x" value = "5"/> <ParameterDeclaration name = "y" value = "7"/> </ParameterDeclarations>`````` When referenced in the main scenario, the value of x is overridden by using a `ParameterAssignment` within the `CatalogReference`: 在主要场景中进行引用时，使用目录引用`CatalogReference`里的一个参数分配`ParameterAssignment`来覆盖x的值： ``````<CatalogReference catalogName = "eg_catalog" entryName = "eg_entry"> <ParameterAssignments> <ParameterAssignment parameterRef = "x" value = "0"/> </ParameterAssignments> </CatalogReference>`````` This means that, for this use of the catalog, any reference to "$x" should be replaced with "0", and any reference to "$y" should be replaced with the default value of "7". No other parameters may be referenced from within the catalog. 这意味着，若将目录用于此用途，任何引用"$x"的地方都被"0"替代，任何引用"$y"的地方都被默认值"7"替代。目录中不得引用其他参数。  The value attribute of a `ParameterAssignment` may itself reference a parameter.  一个参数分配`ParameterAssignment`的属性值本身就可能会引用一个参数。 3.4.4. Resolving Catalog References 解析目录引用 Catalog references are resolved by locating the catalog by name and the entry within this catalog by its entry name (catalogName and entryName of the `CatalogReference`). A `CatalogReference` could hand over `ParameterAssignment`s to resolve parameters for this specific reference. 目录引用的解析可以通过从名称查找目录来完成，目录内的条目可通过其条目名称（目录引用`CatalogReference`的目录名称 catalogName 和条目名称 entryName ）来解析。目录引用`CatalogReference`可以为这类特定引用提供参数分配`ParameterAssignment`来解析参数。 A `Catalog` must be defined in a catalog file (e.g. VehicleCatalog.osc). An instance of a `Catalog` is identified by its name property. 目录`Catalog`必须在目录文件（如VehicleCatalog.osc）里被定义。一个目录`Catalog`的实例可以通过其名称 name 属性来查找。 Any valid catalog file of the correct catalog type and catalog name must be processed that resides in the defined directory. A directory for every catalog type can be defined in a scenario: 任何有正确目录类型和目录名称的有效目录文件都必须在定义好的文件夹里进行处理。也可以在场景中定义一个含所有目录类型的总目录： • `VehicleCatalogLocation` 车辆目录地点 • `ControllerCatalogLocation` 控制器目录地点 • `PedestrianCatalogLocation` 行人目录地点 • `MiscObjectCatalogLocation` 其他对象目录地点 • `EnvironmentCatalogLocation` 环境目录地点 • `ManeuverCatalogLocation` 操作目录地点 • `TrajectoryCatalogLocation` 运动轨迹目录地点 • `RouteCatalogLocation` 路径目录地点 3.5. Conditions and Triggers 条件和触发器 A scenario can be regarded as a collection of meaningful `Action`s whose activation is regulated by `Trigger`s. These `Trigger`s play an important role on how a scenario evolves since the same set of `Action`s can lead to a multitude of different outcomes and it all hinges on how `Action`s are triggered in relation to one other. A `Trigger` in OpenSCENARIO is the outcome arising from a combination of `Condition`s and will always evaluate to either true or false. 场景汇总了一系列有意义的动作`Action`，而触发器`Trigger`掌握着对此类动作的控制权。因此，触发器`Trigger`在场景如何衍变方面起着重要作用。同一组动作`Action`可以导致多种不同的结果，而这一切都取决于动作`Action`被触发的方式。 OpenSCENARIO中的触发器`Trigger`是条件`Condition`组合之后的结果并且总是真true或伪false。 In OpenSCENARIO a `Condition` is a logical expression that is assessed during run time and always evaluates to either true or false. A condition is a container for logical expressions and is assessed during runtime. The Condition operates on the current and previous evaluations of its logical expressions to produce a Boolean output which is used by triggers. 在OpenSCENARIO中，条件`Condition`将作为逻辑表达式的容器，会在运行时对其进行评定且始终为真true或伪false。条件根据其逻辑表达式的当前和先前评估进行运算，从而生成Boolean布尔值输出以供触发器使用。 3.5.1. Associating Conditions 条件关联 A single `Condition` may not suffice to represent a desired `Trigger`. In complicated scenarios, it may instead be required that the relation between a set of `Condition`s serve as a single `Trigger`. 单个条件可能不足以与所需触发器`Trigger`相提并论。因此，在复杂的场景中，单个触发器可能需要使用一整组条件`Condition`之间的关系。 A `ConditionGroup` is an association of `Condition`s that is assessed in run time and can be only evaluated to true if and only if all associated `Condition`s are true, otherwise it will evaluate to false. A `ConditionGroup` is thus a way to bundle any given number of `Condition`s into a single `Trigger`. 条件组`ConditionGroup`用于对条件`Condition`进行关联。对条件组的评估通常会在其运行过程中进行，并且只有在所有被关联的条件`Condition`为真true时，其评估结果才能同样是真true。反之，条件组则会被判定为伪false。由此可见，条件组`ConditionGroup`是一种将任何已知数量的条件`Condition`捆绑到单个触发器`Trigger`中的方法。 3.5.2. Triggers 触发器 To account for the fact that a desired `Trigger` will likely be represented by a relationship between several `Condition`s, the latter are never directly used as a `Trigger` in the format and are instead bundled in `ConditionGroup`s. 尽管事实上可能会用多个条件`Condition`之间的关系来代表所需触发器`Trigger`，但后者并不能在格式中直接等同于触发器`Trigger`。多个条件`Condition`仍然需要被绑定于条件组`ConditionGroup` A `Trigger` is then defined as an association of `ConditionGroup`s. A `Trigger` evaluates to true if at least one of the associated `ConditionGroup`s evaluates to true, otherwise it evaluates to false (OR operation). 触发器`Trigger`继而被定义为是由多个条件组`ConditionGroup`得出的关联。只有在至少有一个关联的条件组`ConditionGroup`为真true后，触发器`Trigger`才能是真true；否则将显示为伪false（“或”(OR)运算）。 Given the nature of individual `ConditionGroup`s (AND between its `Condition`s) and associations of `ConditionGroup`s (OR between its members), a `Trigger` embodies a comprehensive mapping of the relationship (AND, OR) between individual `Condition`s. 鉴于不同条件组的特性（条件`Condition`之间的关系是“与”(AND)）以及条件组的关联（成员之间的关系是“或”(OR)），触发器`Trigger`包含了每个条件`Condition`之间的关系（与/或运算AND, OR）的全面映射。 `Trigger`s are used to start or stop ongoing scenario elements and are referred to as startTrigger and stopTrigger, respectively. 触发器`Trigger`用于启动或停止正在进行的场景要素，并分别作为启动触发器 startTrigger 和停止触发器 stopTrigger 被引用。 Start Trigger 启动触发器 A startTrigger is used to move a runtime instantiation of a `Storyboard` element from the standbyState to the runningState. Only `Act` and `Event` host startTriggers and any element that does not contain a startTrigger inherits the startTrigger from its parent element. For example, starting an `Act` also starts its `ManeuverGroup`s and `Maneuver`s, but does not start the `Event`s since they have their own startTriggers. Furthermore, no `Event`s can start if they do not belong to an `Act` that is in the runningState. 启动触发器 startTrigger 用于将场景剧本`Storyboard`要素的运行时实例化从待机状态standbyState切换到运行状态 runningState。只有动作集`Act`和事件`Event`配有启动触发器 startTrigger，而任何不备有启动触发器 startTrigger 的要素将会从它的父级要素继承该启动触发器 startTrigger。例如，动作集`Act`的启动会连带着启动其操作组`ManeuverGroup`和操作`Maneuver`，但是并不会牵扯到事件`Event`，因为它们配有独立的启动触发器 startTrigger。此外，若事件`Event`不属于一个处在运行状态 runningState 的动作集`Act`，那么不能启动该事件。 The `Story` element is an exception to the rules above since it does not require a formal startTrigger given that starting a simulation is equivalent to starting the `Story`. 场景内容`Story`要素不受限于上述规则。考虑到启动仿真等同于是在启动场景内容`Story`，因此它并不需要正式的启动触发器 startTrigger Stop Trigger 停止触发器 A stopTrigger is used to force a runtime instantiation of a `StoryboardElement` to jump from its standbyState or runningState to the completeState. Only the `Story` and the `Act` elements host stopTriggers. Any `StoryboardElement` inherits the stopTrigger from its parent. This is true even if the `StoryboardElement` under consideration has its own stopTrigger. For example, if a `Story` is affected by a stopTrigger, so are all its `Act`s, even though they have their own stopTrigger. 停止触发器 stopTrigger 用于将场景剧本要素`StoryboardElement`的运行时实例化从其待机状态 standbyState 或运行状态 runningState 切换到完成状态 completeState。只有场景内容`Story`、动作集`Act`要素以及场景内容要素`StoryboardElement`备有停止触发器 stopTrigger。但尽管场景内容要素`StoryboardElement`配有自己的停止触发器 stopTrigger，它们也均从其父级继承停止触发器 stopTrigger。例如，如果一个场景内容`Story`受停止触发器 stopTrigger 影响，则其所有动作集`Act`也受其影响，即使它们拥有自己的停止触发器 stopTrigger When a stopTrigger is received, the concerned `StoryboardElement` is expected to move to the completeState (stopTransition) and clear all remaining number of executions, if applicable. If the `Trigger` occurs when the element is in the runningState, it is expected that its execution is terminated immediately. 当停止触发器 stopTrigger 被继承后，相关的场景内容要素`StoryboardElement`都需转换到完成状态 completeState（停止转换 stopTransition）并在适用的情况下，清除所有剩余的执行次数。如果触发器`Trigger`在要素处于运行状态 runningState 时生效，该要素的执行则需立即被终止。 Condition Type 条件类型 The base condition type contains three basic elements: name, delay, and conditionEdge. Whereas the first element is self-explanatory, the others require clarification. 基本的条件类型包含三个基本要素：名称 name，延迟 delay 和条件边缘 conditionEdge。第一个要素无需再详述，而其他要素则需要声明。 delay 延迟 This element refers to the amount of time that needs to elapse between meeting the `Condition` and reporting it as met. Regardless of other parameters that may be used to define the `Condition`, this element defines a pure delay on its output. 此要素涉及用于从满足条件`Condition`到报告满足状态之间所需的时间。无需考虑其他可用于定义条件`Condition`的参数，此要素都会在其输出中定义一个纯延迟。 conditionEdge 条件边缘 This element can be used to introduce a dynamic component to the `Condition` verification, since the previous states of its logical expression now play a role in the `Condition` output (example see Figure/图 10). 自(该要素)逻辑表达式的先前状态成为了条件`Condition`输出中的一个动态构成部分后，该要素可在条件`Condition`验证中引进动态部分（示例请参见Figure/图 10）。 A `Condition` with a rising edge returns true if its logical expression previously evaluated false but now evaluates true. 即使逻辑表达式先前为伪false，只要它现在是真true，含有上升 rising 边缘的条件`Condition`将返回真true。 A `Condition` set with a falling edge returns true if its logical expression previously evaluated true but now evaluates false. 反之，如果其逻辑表达式先前为真true，但现在为伪false，含有下降 falling 边缘的条件`Condition`组将返回伪false。 A `Condition` set with risingOrFalling edge will return true if either a rising or falling edge is verified. 在对上升边缘或下降边缘进行了验证后，含有上升或下降 risingOrFalling 边缘的条件`Condition`组将返回真true。 Finally, a `Condition` set with none will return true if its logical expression is true, and false if its logical expression is false. 最后，如果条件组的逻辑表达式为真true，该含有无 none`Condition`条件组将返回真true；如果逻辑表达式是伪false，该条件组则是伪false。 If the parameter risingEdge is set to rising, falling, or risingOrFalling, a `Condition` is not defined the first time it is checked since the previous evaluation of the logical expression is not defined. To address this, it is expected that all `Condition`s defined with rising, falling, or risingOrFalling, return false the first time they are checked by a simulation engine. 假如上升边缘参数被设定为上升 rising ，下降 falling 或上升或下降 risingOrFalling，由于逻辑表达式的先前评估并未被定义，因此条件在其第一次校对时也不会被定义。为解决这个问题，所有定义为上升 rising，下降 falling 或上升或下降 risingOrFalling 的条件`Condition`都会在仿真器对其进行第一次校对后返回伪false。 Figure/图 10. Illustration of edge dependent outputs of a speed `Condition` with a greaterThan rule 包含大于 规则的速度条件Condition的、与边缘相关的输出 All other elements of a `Condition` will depend on its sub-type, of which there are two, `ByEntityCondition` and `ByValueCondition`. 条件`Condition`的所有其他要素与其子类型息息相关，`ByEntityCondition``ByValueCondition`便是其中两个类型。 ByEntityConditions 通过实体条件 `ByEntityConditions` will use the states of instances of `Entity` to perform the conditional evaluation. The conditional evaluations may depend on the value of a single state, or how the value of any one given state relates to another state (within the `Entity`, between instances of `Entity`, and between the `Entity` and the corresponding characteristics of the` RoadNetwork`). `ByEntityConditions`将使用实体`Entity`实例的状态来执行条件评估。条件评估可能取决于单个状态的值，或者取决于任何一个给定状态的值与另一个状态的关联；另一个状态指的是与实体`Entity`实例之间以及实体`Entity`与道路网络`RoadNetwork`的相应特征之间的、在实体`Entity`内的状态。 Entity conditions require the definition of `TriggeringEntities` whose states are used in the conditional evaluation. In case more than one triggering `Entity` is defined, the user is given two alternatives to determine when the `Condition` evaluates to true; either all `TriggeringEntities` verify the logical expression or at least one `Entity` verifies the logical expression. 触发实体`TriggeringEntities`的定义对实体条件来说是不可缺少的，其状态将用于条件评估。如果定义了一个以上的触发实体，用户则拥有两种选择用于确定条件`Condition`何时为真true；同样的，逻辑表达式的验证需由所有触发实体`TriggeringEntities`或至少一个实体`Entity`来进行。 ByValueConditions 通过值条件 `ByValueConditions` represent logical expressions that are dependent on values not directly related to instances of `Entity`. For example, these can be scenario states, times or traffic signal information. `ByValueConditions`等同于某些逻辑表达式，而这些表达式依赖于与实体`Entity`实例非直接相关的值。值可以是场景状态、时间或交通信号信息。 `ByValueConditions` also provide a wrapper for external conditions that may depend on values which are not accessible from the scenario and are only available to the user implementation. Examples of these are button presses and custom signals or commands. `ByValueConditions`还可根据值的情况为外部条件提供包裹容器，值在此处指的是那些无法从场景中访问且在用户执行时可用的值，例如按钮和自定义信号或指令。 3.6. Properties 属性 Instances of `Property` are means to allow for the definition of test-instance specific or use-case specific properties of OpenSCENARIO sub elements. They are available for the following types: 属性`Property`实例作为一种方法，用于对特定于测试实例或特定于应用案例的OpenScenario子要素属性进行定义。属性适用于以下类型： • `Vehicle` 车辆 • `Pedestrian` 行人 • `MiscObject` 其他对象 • `Controller` 控制器 • `RoadCondition` 道路状况 Instances of `Property` are collected in the `Properties` container. Every `Properties` definition can contain one or more name-value pairs (i.e. instances of `Property`) and/or references to external files using the `File` mechanism. Thus, `Properties` are a powerful instrument for customizing scenarios, without the need of standardizing purpose-built features related to specific simulator, hardware and software setups. 属性`Properties`作为容器收录了多个属性`Property`的实例。属性`Properties`的每个定义可以包含一对或多对名称值（即属性`Property`的实例）。除此之外，定义还可通过文件`File`机制对外部文件进行引用。因此，属性`Properties`无需对特定于仿真器、硬件和软件设置而开发的功能进行标准化，它已然是一个作用于场景自定义化的强大工具。 Typical applications of `Properties` are extensions of vehicle dynamics specifications, additional driver behavior settings, color information of objects, etc. 属性`Properties`通常用于扩充车辆动力学详细说明、附加的驾驶员行为设置、目标的颜色信息等内容。 `Properties` might influence scenario execution (e.g. driver behavior) but scenarios still shall be executable without knowledge of their meaning. 即使属性`Properties`可能会影响场景的执行（例如，驾驶员行为），但场景仍然应该在其设定不明的情况下被执行。 3.7. States and Transitions of StoryboardElements 场景剧本要素的状态和转换 The progress of a runtime instantiation for a `StoryboardElement`s is marked by its runtime state. Runtime states must be referred to by the OpenSCENARIO standard since they can be used to create `Condition`s and to determine how `StoryboardElement`s interact with `Trigger`s. The transitions between states are also of interest since it is possible to reach the same state from different starting points and it may be of importance to a scenario developer how a state is reached. Both states and transitions of `StoryBoardElement`s are defined by `StoryBoardElementState.` 场景剧本要素`StoryboardElement`的运行时状态标明了运行时实例化的进度。由于运行时状态可用于创建条件`Condition`并确定场景剧本要素与触发器`Trigger`之间的交互方式，因此必须由OpenSCENARIO标准来引用运行时状态。由于不同的起点也可以到达相同的状态，所以状态之间的转换也可作为关注点。对于场景开发者来说，状态的到达方式也将作为重要因素。场景剧本要素`StoryBoardElement`的状态和转换都由场景剧本要素状态`StoryBoardElementState`来定义。 From the perspective of OpenSCENARIO, a `StoryboardElement` shall always be in one of three possible states: Standby, Running, and Complete (see Figure/图 11). OpenSCENARIO认为，场景剧本要素`StoryboardElement`应该始终处于以下三种状态之一：待机，运行和完成（参见Figure/图 11）。 Figure/图 11. State Machine for a runtime instantiation of a StoryboardElement 用于StoryboardElement运行时实例化的状态机 3.7.1. States 状态 Table/表 4. Storyboard states 场景剧本状态 State 状态 Description 描述 StandBy (standbyState) 待机 (待机状态) This is the default initialization state of a `StoryboardElement`. When it is in this state, the runtime instantiation of the `StoryboardElement` is ready to execute once given a startTrigger. A runtime instantiation of any `StoryboardElement` is created once its parent element is in the standbyState. From the standbyState, the `Story` element instantaneously transitions into the runningState. 待机状态是场景剧本要素`StoryboardElement`的默认初始化状态，当场景剧本要素处于初始化状态中，其运行时实例化将在指定启动触发器 startTrigger 后即将被执行。当场景剧本要素`StoryboardElement`的父级要素处于待机状态 standbyState 中，便会创建一个运行时实例化。场景内容`Story`要素立即从待机状态 standbyState 切换为运行状态 runningState Running (runningState) 运行 (运行状态) The runningState symbolizes that the execution of the runtime instantiation is now ongoing and has not yet accomplished its goal. 运行状态 _runningState_意味着运行时实例化的执行现在正在进行中且尚未达到其目标。 The concept of accomplishing a goal varies depending on the type of `StoryboardElement` under consideration: 根据场景剧本要素`StoryboardElement`的类型不同，实现目标的方案也会有所不同： `Action` 动作 An `Action`'s goal is a function of the `Action` type and cannot be generalized. Accomplishing an `Action`'s goal will involve meeting some arbitrary prerequisites related with the `Action `type (for example, a `SpeedAction` accomplishes its goal when the considered `Entity` is travelling at the prescribed speed). If an `Action` is acting on an `EntitySelection`, all instances of `Entity` within the selection have to complete in order to reach the completeState of the `Action`. 动作Action的目标在于实现一个动作`Action`类型的功能，且不能被通用化。在实现动作`Action`的目标前，需要先满足与动作`Action`类型有关的任意先决条件（例如，当所需实体以规定的速度行进时，速度动作`SpeedAction`便会实现其目标）。如果某个动作`Action`正在实体选择中`EntitySelection`执行，所有实体`Entity`实例需要在该选择中也完成，从而达到动作`Action`的完成状态 completeState `Event` 事件 An `Event`'s goal is accomplished when all its `Action`s are in the completeState. 当一个事件`Event`的所有动作`Action`都处于完成状态 completeState 时，则该事件`Event`完成其目标。 `Maneuver` 操作 A `Maneuver`'s goal is accomplished when all its `Event`s are in the completeState. 当一个操作`Maneuver`的所有事件`Event`都处于完成状态 completeState，则该操作`Maneuver`完成其目标。 `ManeuverGroup` 操作组 A `ManeuverGroup`'s goal is accomplished when all its `Maneuver`s are in the completeState. 当一个操作组`ManeuverGroup`的所有操作`Maneuver`都处于完成状态 completeState，则该操作组`ManeuverGroup`完成其目标。 `Act` 动作集 An `Act`'s goal is accomplished when all its `ManeuverGroup`s are in the completeState. 当一个动作集Act的所有操作组`ManeuverGroup`都处于完成状态 completeState，则该动作集`Act`则完成其目标。 `Story` 场景内容 A `Story`'s goal is accomplished when all its `Act`s are in the completeState. 当一个场景内容`Story`的所有动作集`Act`都处于完成状态 completeState，则该场景内容`Story`完成其目标。 Complete (completeState) 完成 ( 完成状态 ) The completeState signals that the runtime instantiation of the `StoryboardElement` cannot reach a running state without external interference. If the affected runtime instantiation of the `StoryboardElement` is defined with a maximumExecutionCount, to be complete implies that there are no more executions left to run, or a stopTransition has occurred. 完成状态 completeState 给出了一个信息：在没有外部介入的情况下，场景剧本要素`StoryboardElement`的运行时实例化则无法达到运行状态。 如果场景剧本要素`StoryboardElement`的运行时实例化受到了影响，且对其定义时使用了最大执行数 maximumExecutionCount，这意味着没有更多的执行要运行，或意味着停止转换 stopTransition 已经介入。 Checking for completeness involves verifying if the given runtime instantiation of the `StoryboardElement` still has executions left upon finishing the runningState. This check returns false if there are executions left. This check returns true if there are no executions left, or if the maximumExecutionCount is not defined in the `StoryboardElement`. 如果场景剧本要素`StoryboardElement`的指定运行时实例化仍然有剩余的执行量用于完成运行状态 runningState，则在校对的同时也对完整性进行验证。如果仍有执行量剩余，则该校对返回伪false。如果执行量没有剩余，或者场景剧本要素`StoryboardElement`中并未定义最大执行数 maximumExecutionCount，则该校对返回真true。 Resetting the completeState can only be achieved externally by the parent `StoryboardElement` whose child is in the completeState. This may only occur if the parent initiates a new execution. 只能从外部通过作为父级的场景剧本要素`StoryboardElement`（其子级处于完成状态 completeState 中）来重置完成状态 completeState。只有当父级要素发起新的执行时，重置才能被操作。 3.7.2. Transitions 转换 Table/表 5. Storyboard transitions 场景剧本转换 Transition 转换 Description 描述 Start (startTransition) 启动 (启动转换) The startTransition symbolizes that the execution of the runtime instantiation is now starting. The startTransition can be used in conditions to trigger based on this transition. 启动转换 startTransition 意味着现在开始执行运行时实例化。基于此转换，启用转换 startTransition 可条件中用于触发。 End (endTransition) 结束 (结束转换) The endTransition occurs when the runtime instantiation of the `StoryboardElement` accomplishes its goal. Once the endTransition occurs, a check for completeness is made. A positive outcome moves the state machine to the completeState, whereas a negative outcome moves the state machine to the standbyState. The endTransition can be used in conditions to trigger based on this transition. 当场景剧本要素`StoryboardElement`的运行时实例完成其目标时，则会启用结束转换 endTransition。随着结束转换 endTransition 的进行，对完整性的校对也会随之完成。正结果促使状态机进入完成状态 completeState，而负结果则促使状态机进入待机状态 standbyState。结束转换 endTransition 可基于此转换在条件中作为触发使用。 Stop (stopTransition) 停止 (停止转换) The stopTransition marks the reception of a stopTrigger or the storyboard element is overridden (applicable for `Event` and `Action`). This implies that the stopTransition cannot be reached other than with an external intervention to the runtime instantiation of the `StoryboardElement`. 停止转换 stopTransition 用于标记出停止触发器 stopTrigger 的接收或场景剧本要素被覆盖（适用于事件`Event`和动作`Action`）。这意味着，必须通过对场景剧本要素`StoryboardElement`的运行时实例进行外部干预来完成完成停止转换 stopTransition When a runtime instantiation of a `StoryboardElement` goes through a stopTransition, all of its child elements are also forced to go through the same transition. The stopTransition can be used in conditions to trigger based on this transition. 当场景剧本要素`StoryboardElement`的运行时实例被执行了停止转换 stopTransition 时，其所有子要素也将被强制进行相同的转换。停止转换 _stopTransition_可基于此转换在条件中作为触发使用。 Skip 跳过 Transition marking the moment an element is asked to move to the runningState but is instead skipped so it remains in the standbyState (only for `Event` instances). The skipTransition can be used in conditions to trigger based on this transition. 当一个要素被要求进入运行状态 runningState 时，转换会对此时间点作记录。如果这个时间点被跳过，该要素依然会保持其待机状态 standbyState 。该规则仅适用于事件`Event`实例。跳过转换 _skipTransition_可基于此转换在条件中作为触发使用。 4. Scenario Creation 场景创建 4.1. Example Description of a Scenario 场景描述示例 This scenario is written for left-hand side traffic country, but could easily be adapted if required. The Ego vehicle (Ego), an externally controlled vehicle, is driving along an urban road approaching a junction on the offside. It is being followed by two influencing vehicles, c1 and c2 (the movements of which are controlled by the scenario). A third influencing vehicle (c3) is waiting to turn right at the junction. As The Ego vehicle (Ego) approaches the junction, c1 and c2 start to overtake. Slightly later, c3 starts to turn right, which prompts c1 and c2 to make an emergency stop. The initial positions of the vehicles are shown in Figure/图 12. 此场景适用于靠左行车国家，也可根据需求对其轻松做出调整。该场景讲述的是：由外部控制的本车 Ego vehicle (Ego)行驶在城市道路上并驶向一个路口（车辆右侧朝向路口），跟随其后的是 c1c2 两辆会对之产生影响的车辆（两辆车的运动由场景来控制）。第三辆会产生影响的车辆（c3）则在路口等待右转。当本车 Ego vehicle (Ego)接近路口时，c1c2 开始超车。 c3 紧接着开始右转，从而迫使 c1c2 进行紧急刹车。Figure/图 12 标识了以上车辆的初始位置。 Figure/图 12. Initial positions of vehicles 车辆的初始位置 4.2. Init Section 初始段 The following XML example shows an `Action` which positions The Ego vehicle (Ego) using global coordinates. Similar `Action`s (not shown) are used to specify speeds and positions for the other vehicles. 以下 XML 示例展示了行动 `Action` 如何利用全局坐标系来定位本车 Ego vehicle (Ego) 。类似的行动 `Action`（未做展示）则用于说明其他车辆的速度和位置。 ``````<Storyboard> <Init> <Actions> <Private entityRef = "Ego"> <PrivateAction> <!-- Set Ego to its initial position --> <TeleportAction> <Position> <WorldPosition x = "-2.51" y = "-115.75" z = "0" h = "1.57" p = "0" r = "0" /> </Position> </TeleportAction> </PrivateAction> ... <!-- Similar actions --> </Private> </Actions> </Init> ... </Storyboard>`````` 4.3. Stories 场景内容 Instances of `Story` are used to group independent parts of the scenario, to make it easier to follow. It is never required to use more than one `Story`, and if an `Act` is moved from one `Story` to another the scenario will work in the same way (as long as there are no naming conflicts). In this example, two instances of `Story` are used: • one to describe the overtake and emergency stops • the other to describe the right turn 场景内容`Story`实例被用来聚类场景中独立的部分，以便对场景进行跟踪。不要求使用 多个场景内容`Story`，且如果一个动作集`Act`从一个场景内容`Story` 转移到另外一个，（如果没有命名冲突的话）场景的工作方式并不受影响。下述例子将使用以下两个场 景内容`Story`实例进行展示： • 其中一个场景内容描述超车和紧急刹车 • 另一个则描述右转 These are given the names AbortedOvertake and RightTurn respectively. 相应地，这两个场景内容分别被命名为 AbortedOvertake 和 RightTurn。 The `Story` AbortedOvertake contains two `Act`s: • one to control the overtaking behavior • and another to control the emergency stops 场景内容 `Story` AbortedOvertake 包含两个动作集`Act` • 一个用于控制超车行为 • 另一个则用于控制紧急刹车 RightTurn contains only a single `Act`. RightTurn 只包含一个单一动作 `Act` The following example shows the structure of instances of `Story` and `Act`s in this Scenario. 以下示例展示了此场景中场景内容 `Story` 实例和动作集 `Act` 的结构。 ``````<Story name = "AbortedOvertake"> <Act name = "AbortedOvertakeAct1"> ... <!-- Act content describing overtakes --> </Act> <Act name = "AbortedOvertakeAct2"> ... <!-- Act content describing emergency stops --> </Act> </Story> <Story name = "RightTurn"> <Act name = "RightTurnAct"> ... <!-- Act content describing right turn --> </Act> </Story>`````` 4.4. Acts 动作集 `Act`s, which contain `ManeuverGroup`s, allow a set of `Trigger`s to be applied to a substantial section of the scenario. 包含了操作组 `ManeuverGroup` 的动作集`Act` 确保触发器 `Trigger` 集将适用于场景大部分内容。  This example scenario contains startTriggers both at `Act` and `Event` level. At `Act` level, they are used to start the overtake. At the `Event` level they control its execution. It would be possible to define all `Trigger`s at an `Event` level, but this would result in much more complex, sometimes duplicated, `ConditionGroup`s.  这个示例场景在动作集 `Act` 和事件 `Event` 层级均配有启动触发器 `startTrigger`。在动 作集 `Act` 层级，启动触发器 `startTrigger` 被用于启动超车动作。在事件 `Event` 层级， 它们则控制事件的执行。虽然也可以在事件 `Event` 层级定义所有的触发器 `Trigger`，但 这会导致更多更复杂、有时还重复的条件组 `ConditionGroup`。 In this case, c1 and c2 should both start to overtake at the same time. This makes it convenient to put all content associated with both overtakes in the same `Act`. This has been named AbortedOvertakeAct1, is stored within the AbortedOvertake `Story`, and causes c1 and c2 to change lane and then begin to accelerate past the Ego vehicle. 在这个示例中，由于 c1c2 是同时开始超车的，因此将所有跟这两个超车动作相关的 内容放到同一个动作集`Act`里是更便利的做法。这个动作集被命名为 AbortedOvertakeAct1，它被存储在场景内容`Story` AbortedOvertake 里，是 c1c2 换道然后开始加速经过本车 Ego vehicle 的原因。  Instances of `Story`, `Act`s, `ManeuverGroup`s, `Maneuver`s and `Event`s may be executed in any order, as defined using `Trigger`s. The order in which they appear in an OpenSCENARIO file makes no difference.  依照用于触发器 `Trigger` 应用的定义，可以按照任意顺序执行场景内容 `Story`、动作集 `Act`、操作组 `ManeuverGroup`、操作 `Maneuver` 和事件 `Event` 的实例。而且它们在 OpenSCENARIO 中分别出现的顺序亦是无关大局的。 The example below shows the structure of an `Act`. This `Act` will trigger when the Ego vehicle is close to the junction. Movements of vehicles in this `Act` are defined in the `ManeuverGroup`s section, which is omitted here but described later in this chapter. 以下示例展示了一个动作集 `Act` 的结构。这个动作集 `Act` 会在本车 Ego vehicle 接近路口时触发。操作组`ManeuverGroup` 小节中，已对所属该动作集Act的车辆动作进行了定义，在此小节里不作过多描述，更多介绍参见本章节其他小节。 ``````<Act name = "RightTurnAct"> <!-- Maneuver Group --> ... <StartTrigger> <ConditionGroup> <Condition name = "EgoCloseToJunction" delay = "0" conditionEdge = "rising"> <!-- ByEntity condition: Ego close to junction --> ... </Condition> </ConditionGroup> </StartTrigger> </Act>`````` An `Act` can be terminated by a stopTrigger (see [Stop Trigger]). 停止触发器 stopTrigger 可用于终止动作集 `Act`（详见 [Stop Trigger]）。 4.5. ManeuverGroups 操作组 In AbortedOvertakeAct1, the two vehicles affected both perform the same `Action`s. However, not all of these `Action`s should happen at the same time. c1 and c2 should return to their original lane when they have passed the Ego vehicle (Ego), independent of what the other one is doing. 在 AbortedOvertakeAct1 中，被影响的两车将执行相同的动作 `Action`。但并非所有动 作 `Action` 都必须同时发生。比如当 c1c2 经过本车 Ego vehicle (Ego) 之后，无需考虑对方此刻的行为，它们都应该回到原来的车道上。 We have achieved this behavior by using a separate `ManeuverGroup` for each vehicle (named c1ManeuverGroup and c2ManeuverGroup) in the example below). Each `ManeuverGroup` allocates a `Maneuver` (from a `Catalog`) to one vehicle. This `Maneuver` instructs that vehicle to change lane, accelerate, and then return to the previous lane ahead of the Ego vehicle (Ego). It would also be possible to achieve the same result using the approach discussed in [Maneuver groups and Actors]. 通过为每辆车（在以下范例中命名为 c1ManeuverGroup 和 c2ManeuverGroup）使用单独 的操作组`ManeuverGroup` 即可以做到这个行为。每个操作组 `ManeuverGroup` 分别从目录 `Catalog` 中给一辆车分配一个操作 `Maneuver`。该操作 `Maneuver` 将指挥该车辆变道、加速，继而让该车辆回到原先车道上并行驶在本车 Ego vehicle (Ego) 前面。使用在[操作组与行动者] [Maneuver groups and Actors]中讨论过的方法也可以达到同样效果。 ``````<ManeuverGroup name = "c1ManeuverGroup" maximumExecutionCount = "1"> <Actors selectTriggeringEntities = "false"> <EntityRef entityRef = "c1"/> </Actors> <CatalogReference catalogName = "overtake" entryName = "Overtake Ego vehicle"> <!—Parameter assignment --> ... </CatalogReference> </ManeuverGroup> <ManeuverGroup name = "c2ManeuverGroup" numberOfExecutions = "1"> ... <!-- similar to above --> </ManeuverGroup>`````` 4.6. Maneuvers 操作 In a similar way to multi-instantiation of `Story`, it is never essential to use more than one `Maneuver`, and if an `Event` is moved from one `Maneuver` to another (within the same `ManeuverGroup`) the scenario will work in the same way. 与场景内容 `Story` 多实例化相似，使用超过一个操作 `Maneuver` 从不是必要的。如果在相同的操作组 `ManeuverGroup` 中，一个事件 `Event` 从一个操作 `Maneuver` 被挪到另外一 个，场景将还是以同样的方式运行。 In AbortedOvertakeAct1, vehicles c1 and c2 need to perform an overtake in the same way, but it must be specified in two different `ManeuverGroup` elements. Therefore, a `Catalog` `Maneuver` is defined: 在 AbortedOvertakeAct1 中，车辆 c1 和 c2 应该使用同一种超车方式，但该超车行为必须由两个不同的操作组 `ManeuverGroup` 要素来详细说明。为此，目录操作 `Catalog` `Maneuver` 被赋予了以下定义： ``````<Catalog name = "Overtake"> <Maneuver name = "Overtake Ego Vehicle"> <ParameterDeclarations> <ParameterDeclaration name = "$OvertakingVehicle"
parameterType = " string"
value = ""/>
<!-- "" will be overwritten by scenario -->
</ParameterDeclarations>
<!-- Events to define overtake behaviour -->
<Event > ... </Event>
...
</Maneuver>
</Catalog>``````

This is then referenced within both `ManeuverGroup`s:

``````<ManeuverGroup  name    = "c1ManeuverGroup"
maximumExecutionCount   = "1">
<Actors  selectTriggeringEntities    = "false">
<EntityRef  entityRef   =   "c1"/>
</Actors>
<CatalogReference   catalogName     = "Overtake"
entryName   = "OvertakeEgoVehicle">
<ParameterAssignments>
<ParameterAssignment parameterRef  = "OvertakingVehicle"
value = "c1"/>
</ParameterAssignments>
</CatalogReference>
</ManeuverGroup>

<ManeuverGroup  name    = "c2ManeuverGroup"
maximumExecutionCount   = "1">
<Actors     selectTriggeringEntities    = "false">
<EntityRef  entityRef   = "c2"/>
</Actors>
<CatalogReference   catalogName = "Overtake"
entryName   = "OvertakeEgoVehicle">
<ParameterAssignments>
<ParameterAssignment parameterRef  = "OvertakingVehicle"
value = "c2"/>
</ParameterAssignments>
</CatalogReference>
</ManeuverGroup>``````
 The `Catalog` reference does not define which vehicle executes the `Action`s, because this is defined by the `ManeuverGroup`. However, the `Catalog` reference does contain a `Condition` to check when the overtaking vehicle can return to its lane. This requires the names of the two vehicles involved to be specified. To achieve this, a Parameter with the name of the vehicle overtaking is included in the `Catalog` reference.
 目录 `Catalog` 引用并不定义具体哪辆车来执行动作 `Action`，因为定义是由操作组 `ManeuverGroup` 来进行的。尽管如此，仍可通过目录 `Catalog` 引用中的条件 `Condition` 而得知正在进行超车的车辆何时可以返回其原车道。这就要求对两辆相关车辆的名称 进行说明。要达到此目的，目录 `Catalog` 引用中需包括含有超车车辆名称的参数。

4.7. Events 事件

In this example, the lane change `Action` should start straight away when its parent `Act` is triggered. `Events` are required to apply `Trigger`s to `Actions`, so in this case a trivial `Condition` is used to trigger immediate execution.

``````<Event  name    = "brake event"
priority    = "overwrite">
...
<!-- Emergency stop action -->
<StartTrigger>
<ConditionGroup>
<Condition  name = "StartConditionOfAbortedOvertakeAct2"
delay = "0"
conditionEdge = "none">
<ByValueCondition>
<SimulationTimeCondition value = "0"
rule  = "greaterThan"/>
</ByValueCondition>
</Condition>
</ConditionGroup>
</StartTrigger>
</Event>``````

For other `Event`s, `Condition`s are used to ensure a certain state is reached before the `Action` is applied (for example, the acceleration `Event` must not start until the vehicle has changed lane).

5. Examples 示例

The following paragraphs describe the examples provided with OpenSCENARIO. The examples are defined for right-hand traffic.

5.1. Cut-In 切入

This example describes a traffic situation where the Ego vehicle drives behind a slower vehicle on the rightmost lane of a two-lane straight highway. At the same time, the Ego vehicle is overtaken by a faster vehicle on the left lane. After overtaking, the faster vehicle cuts in to the Ego vehicle’s lane.

At the initialization phase, the environment conditions are set. The Ego vehicle is instantiated in the rightmost lane, driving at 100 km/h. A vehicle, driving at the same speed and in the same lane, is instantiated 84 m ahead of the Ego vehicle. A second car, driving at 110 km/h, is instantiated 100 m behind the Ego vehicle in the lane left of it.

At simulation runtime, after the second car has passed the Ego vehicle by 20 m, it cuts in to the Ego vehicle’s lane, using a prescribed trajectory.

This scenario teaches the use of the `EnvironmentAction`, instantiation of instances of `Entity`, usage of `Event`s, `Condition`s and instances of `Trajectory`.

Figure/图 13. Cut-in scenario example 切入场景示例

5.2. Slow Preceding Vehicle 前方慢速车辆

This scenario describes a traffic situation where the Ego vehicle approaches a slower vehicle in the same lane of a two-lane curved highway.

At the initialization phase, the environment conditions are set. The preceding vehicle is instantiated at the rightmost lane. It is driving at a constant speed of 80 km/h. The Ego vehicle is instantiated relative to this vehicle in the same lane, but 200 m behind, driving at 100 km/h.

This scenario teaches the instantiation of instances of `Entity` and the usage of `ParameterDeclaration`s.

Figure/图 14. Slow preceding scenario example 前方慢速场景示例

5.3. End of Traffic Jam 交通拥堵的结束

This scenario describes a traffic situation where the Ego vehicle approaches two slower vehicles driving side-by-side on a straight two-lane highway running over a crest.

The environment conditions are set in the initialization phase. The Ego vehicle is instantiated at a constant velocity of 100 km/h on the rightmost lane of the road. 200 m ahead of Ego vehicle, two vehicles are instantiated at a velocity of 80 km/h in the rightmost lane and the neighboring lane to the left.

At simulation runtime, after the two vehicles have travelled a distance of 100 m / 200 m respectively, they linearly decelerate by 5 m/s2 until they reach a target speed of 70 km/h.

This example extends the Slow Preceding Vehicle example by parallel execution of `Act`s and the usage of `Condition`s.

Figure/图 15. End of traffic jam scenario example 交通拥堵结束场景示例

5.4. End of Traffic Jam, Neighboring Lane Occupied 交通拥堵结束以及占用邻道

This scenario extends the End of Traffic Jam Scenario by a fourth vehicle on a three-lane highway with limited friction. The rightmost and the leftmost lanes of this highway are blocked by stationary vehicles. A third vehicle performs a lane change to the centermost lane in order to prevent a collision with the stationary vehicle on the rightmost lane. At the same time, it decelerates until it arrives at a full stop.

At the initialization phase, the environment conditions are set. The Ego vehicle is instantiated at a constant velocity of 80 km/h on the rightmost lane of the road. 300 m ahead of the Ego vehicle, a vehicle is instantiated in the same lane at a velocity of 70 km/h. 1000 m ahead of the Ego vehicle, a third vehicle is instantiated in the same lane as the other two vehicles. This vehicle is stationary (velocity 0 km/h). It is accompanied by a fourth vehicle, which is situated two lanes left and 1000 m ahead of the Ego vehicle.

At simulation runtime, the vehicle driving in front of the Ego vehicle at a velocity of 70 km/h performs a lane change to the left as soon as it approaches the stationary vehicle in the same lane by 55 m. In parallel to the lane change, it decreases its speed linearly by 10 m/s2 until it arrives at a full stop.

This scenario teaches the instantiation of instances of `Entity`, the use of `ParameterDeclaration`s, and use of parallel `Action`s.

Figure/图 16. Neighboring lane occupied scenario example 占用邻道场景示例

5.5. Double Lane Changer 双车道变道

This scenario describes a traffic situation where the Ego vehicle is driving at the rightmost lane behind another vehicle driving at the same speed, leaving a gap. A faster vehicle approaches the Ego vehicle from behind on the centermost lane. This vehicle changes lane into the gap on the rightmost lane after it has passed the Ego vehicle. In order to avoid collision with the vehicle driving ahead of the Ego vehicle, it immediately changes back to the center lane.

At the initialization phase, the Ego vehicle is initialized at the rightmost lane at a speed of 130 km/h. A second vehicle is initialized 13 m behind the Ego vehicle at the centermost lane driving at a speed of 170 km/h. A third vehicle is initialized 70 m ahead of the Ego vehicle on the rightmost lane driving at 130 km/h.

At simulation runtime, when the fast vehicle on the centermost lane has passed the Ego vehicle by 5 m, it performs a sinusoidal lane change to the rightmost lane. When this action is completed, the vehicle immediately changes back to the centermost lane, using another sinusoidal lane change.

This scenario teaches instantiation of instances of `Entity` using Cartesian coordinates, use of `Condition`s and consecutive execution of `LaneChangeAction`s.

Figure/图 17. Double lane changer scenario example 双车道换道场景示例

5.6. Fast Overtake with Re-Initialization 利用重新初始化快速超车

This scenario describes a traffic situation were the Ego vehicle approaches a truck that slows down on the right lane of a three-lane highway. An overtaking vehicle is initialized in the centermost lane when the truck performs this action.

At the initialization phase, the Ego vehicle is initialized at a velocity of 130 km/h on the rightmost lane. A truck driving at a velocity of 90 km/h is initialized 120 m ahead of it in the same lane. The overtaking vehicle is initialized at an arbitrary position and orientation.

At simulation runtime, when the Ego vehicle approaches the truck by 60 m, the latter linearly reduces its velocity to 60 km/h. This action triggers the relocation of the overtaking vehicle to the centermost lane at a velocity of 200km/h at 200m behind of the truck. This action is delayed by 2 s.

This scenario teaches consecutive execution of `Act`s and `Action`s.

Figure/图 18. Fast overtake with re-initialization scenario example 利用重新初始化快速超车场景示例

5.7. Overtaker 超车者

This scenario describes a traffic situation where the Ego vehicle is approached by a faster vehicle driving on the rightmost lane of a three-lane motorway.

At the initialization phase, the Ego vehicle is initialized at the rightmost lane driving at a velocity of 130 km/h. The other vehicle is initialized 79 m behind of the Ego vehicle driving in the same lane at a velocity of 150 km/h.

At simulation runtime, when the faster vehicle approaches the Ego vehicle by 30 m, it performs a sinusoidal lane change to the left. As soon as the vehicle is 5 m ahead of the Ego vehicle, it changes its lane back to the rightmost lane.

This scenario teaches the use of `Condition`s and consecutive execution of `LaneChangeAction`s.

Figure/图 19. Overtaker scenario example 超车场景示例

5.8. Traffic Jam 交通拥堵

This scenario describes a traffic situation where the Ego vehicle approaches a traffic jam of six other vehicles on a three-lane motorway.

At the initialization phase, the Ego vehicle is initialized at a velocity of 130 km/h at the leftmost lane. The vehicles forming the traffic jam are initialized 145 m ahead of the Ego vehicle at a velocity of 0 km/h. Pairs of vehicles block all three lanes of the motorway. Each of the pairs features a longitudinal gap of 8 m between its two corresponding vehicles.

This scenario teaches instantiation of instances of `Entity` using Cartesian coordinates.

Figure/图 20. Traffic jam scenario example 交通拥堵场景示例

5.9. Synchronized Arrival at Intersection 同步到达十字路口

This scenario recreates a critical situation at an intersection where the Ego vehicle and another vehicle are in a collision course. The Ego vehicle is instantiated with an initial speed of 10m/s and is assigned a route guiding it straight through an intersection (south to north). A second vehicle is instantiated with no speed and a route which will guide it straight through the same intersection (west to east).

The moment at which the distance between the vehicles becomes less than 70m, a `SynchronizeAction` is triggered. At this stage, the crossing vehicle is regulating its speed in order to reach its synchronization position, at the same time as the Ego vehicle reaches its synchronization position. Additionally, the crossing vehicle is constrained to reach its synchronization position with a final speed of 7m/s.

When the vehicles reach their synchronization positions, the action is complete and vehicle c1 resumes default behavior driving through the intersection at 7m/s.

This scenario teaches the usage of the `SynchronizeAction`.

Figure/图 21. Synchronized arrival at intersection scenario example 同步到达十字路口场景示例

Terms and Definitions 术语和定义

For the purposes of this ASAM standard the following terms and definitions apply (in alphabetical order). These are consistent with [5].

 OpenSCENARIO language elements (indicated using `monospaced font`) are defined within the body of this document, and their complete semantics are given in the Reference Guide ( [6]). Therefore they do not appear in this table.
 OpenSCENARIO语言要素在英语原文中一致使用等宽字体`monospaced font`。此表不包含OpenSCENARIO语言要素的定义与其完整语义。OpenSCENARIO语言要素的定义参见本文档的正文，其完整语义则可参见《引用指南》（ [6] ）。
 Ego vehicle 本车 The vehicle(s) which is(are) the focus of a scenario, i.e. the vehicle(s) under test. For evaluation of automated driving systems, the Ego vehicle will be the one controlled by the system-under-test. For human driver experiments, the Ego vehicle will be the one driven by the human driver. Note there can be zero, one or multiple Ego vehicles within a scenario. 本车 _Ego vehicle_指的是作为场景重点的待测车辆。在评估自动驾驶系统时，本车将由被测系统控制。而在实施人类驾驶员的实验时，本车则由人类驾驶员驾驶。 要注意的是，一个场景中可以出现零辆，一辆或多辆本车。 Parameterization 参数化 The use of parameters, which are symbols that can be replaced by concrete values at a later stage according to either user needs or stochastic selection. 参数化指的是参数的使用，参数作为符号可在后期根据用户需求或通过随机选择被具体值取代。 World 世界 Everything that falls within the spatial extent of a scenario, and therefore may form part of the scenario description. 世界指的是场景空间范围内的所有内容，因此它可以成为场景描述的一部分。

Symbols and Abbreviated Terms 符号和缩略语

Term 用语 Definition 定义

3D

Three-dimensional 三维

ASAM

Association for Standardization of Automation and Measuring systems 自动化及测量系统标准协会

CET

Central European Time 欧洲中部时间

CRG

Curved Regular Grid ASAM OpenX系列之一

OSC

OpenSCENARIO ASAM OpenX系列之一

HTML

Hypertext Markup Language 超文本标记语言

SI

Systéme international (d' unités) 国际单位制

UML

Unified Modeling Language 统一建模语言

XML

Extensible Markup Language 可拓展标记语言

XSLT

Extensible Stylesheet Language Transformation 可拓展样式表语言转换

Bibliography 参考目录

[1] OpenDRIVE. ASAM e.V., 2020.

[2] OpenCRG. ASAM e.V., 2020.

[3] ISO 8601:2019 Data elements and interchange formats — Information interchange — Representation of dates and times. International Organization for Standardization, Geneva, Switzerland., 2004-12.

[4] ISO8855:2011 Road vehicles — Vehicle dynamics and road-holding ability — Vocabulary. International Organization for Standardization, Geneva, Switzerland., 2011-12.

[5] DIN SAE SPEC 91381 Terms and Definitions Related to Testing of Automated Vehicle Technologies. 2019-06.

[6] OpenSCENARIO Model Reference. ASAM e.V., 2020.

Appendix A: Action Tables 动作表

Table/表 6. Action Table: Private Actions 动作表：专属动作
Action

Settings (time, space, domain)

Goal

Longitudinal axis controlled by

Lateral axis controlled by

Action Ends

LongitudinalAction. SpeedAction

target is "absolute" or "relative" with continuous = "false"

reach a longitudinal speed

action

unchanged

on reaching the speed

LongitudinalAction. SpeedAction

target is "relative" with continuous = "true"

reach and keep a relative longitudinal speed

action

unchanged

never

LongitudinalAction. LongitudinalDistanceAction

continuous = "false"

reach a longitudinal distance to another object

action

unchanged

by reaching the targeted distance

LongitudinalAction. LongitudinalDistanceAction

continuous = "true"

reach and keep a longitudinal distance to another object

action

unchanged

never

LateralAction. LaneChangeAction

not applicable

reach a lane

unchanged

action

by reaching the lane

LateralAction. LaneOffsetAction

continuous = "false"

reach a lane offset

unchanged

action

by reaching the targeted lane offset

LateralAction. LaneOffsetAction

continuous = "true"

reach and keep a lane offset

unchanged

action

never

LateralAction. LateralDistanceAction

continuous = "false"

reach a lateral distance

unchanged

action

by reaching the targeted lateral distance

LateralAction. LateralDistanceAction

continuous = "true"

reach and keep a lateral distance

unchanged

action

never

VisibilityAction

not applicable

change an objects visibility

unchanged

unchanged

immediately

SynchronizeAction

not applicable

reach a destination with timing constraints

action

unchanged

controlled vehicle reaching the target point

ActivateControllerAction

longitudinal = "false", lateral = "false"

deactivate controller model (e.g. driver model) for both axis

unchanged

unchanged

immediately

ActivateControllerAction

longitudinal = "false", lateral = "true"

activate controller model (e.g. driver model) for lateral axis

unchanged

action

immediately

ActivateControllerAction

longitudinal = "true", lateral = "false"

activate controller model (e.g. driver model) for longitudinal axis

action

unchanged

immediately

ActivateControllerAction

longitudinal = "true", lateral = "true"

activate controller model (e.g. driver model) for both axis

action

action

immediately

ControllerAction. AssignControllerAction

not applicable

assign a controller model (e.g. driver model) to a vehicle

unchanged

unchanged

immediately

ControllerAction. OverrideControllerValueAction. [throttle;brake;clutch;parkingBrake;gear]

active = “true”

override longitudinal controls

action

unchanged

never

ControllerAction. OverrideControllerValueAction. [throttle;brake;clutch;parkingBrake;gear]

active = “false”

deactivate overriding longitudinal controls

unchanged

unchanged

immediately

ControllerAction. OverrideControllerValueAction. SteeringWheel

active = “true”

override lateral controls

unchanged

action

never

ControllerAction. OverrideControllerValueAction. SteeringWheel

active = “false”

override lateral controls

unchanged

unchanged

immediately

TeleportAction

not applicable

instant change an objects position

unchanged

unchanged

immediately

RoutingAction. AssignRouteAction

not applicable

use a specific route as routing target

unchanged

unchanged

immediately

RoutingAction. FollowTrajectoryAction

`TimeReference` = timing; `TrajectoryFollowingMode` = position
`时间参考` = timing; `运动轨迹跟踪模式` = position

use a specific trajectory and move the actor along that trajectory without any controller behavior

action

action

by reaching the end of the trajectory

RoutingAction. FollowTrajectoryAction

`TimeReference` = none; `TrajectoryFollowingMode` = position
`时间参考` = none; `运动轨迹跟踪模式` = position

use a specific trajectory and move the actor along that trajectory with the current longitudinal control (e.g. speed keeping); time information contained in the trajectory is ignored

unchanged

action

by reaching the end of the trajectory

RoutingAction. FollowTrajectoryAction

`TimeReference` = none; `TrajectoryFollowingMode` = follow
`时间参考` = none; `运动轨迹跟踪模式` = follow

use a specific trajectory as steering input for a controller; time information contained in the trajectory is ignored

unchanged

action

by reaching the end of the trajectory

RoutingAction. FollowTrajectoryAction

`TimeReference` = timing; `TrajectoryFollowingMode` = follow
`时间参考` = timing; `运动轨迹跟踪模式` = follow

use a specific trajectory as steering and timing input for a controller

action

action

by reaching the end of the trajectory

RoutingAction. AcquirePositionAction

not applicable

use the specified position as routing target; i.e. a route with two waypoints will be created: current position as first and specified position as last waypoint

unchanged

unchanged

immediately

CustomCommandAction

not applicable

activate a custom action native to the specific user environment

unspecified

unspecified

immediately

Table/表 7. Action Table: Global Actions 动作表：全局动作
Action

Settings

Goal

Action Ends

EnvironmentAction

not applicable

set weather, road conditions and time of the day

immediately

not applicable

add an entity to the scenario, at a predefined position

immediately

EntityAction.DeleteEntityAction

not applicable

delete an entity at runtime from the simulation

immediately

ParameterAction.ParameterSetAction

not applicable

set a parameter to a given value

immediately

ParameterAction.ParameterModifyAction

not applicable

modify a global parameter according to given rules

immediately

InfrastructureAction.TrafficSignalAction.TrafficSignalControllerAction

not applicable

set a specific phase of a traffic signal controller, typically affecting a collection of signals

immediately

InfrastructureAction.TrafficSignalAction.TrafficSignalStateAction

not applicable

control the state of a traffic signal

immediately

TrafficAction.TrafficSourceAction

not applicable

define a source of traffic at a specific position

immediately

TrafficAction.TrafficSinkAction

not applicable

define a sink of traffic at a specific position

immediately

TrafficAction.TrafficSwarmAction

not applicable

define swarm traffic within an elliptical planview around a given central entity

immediately

CustomCommandAction

not applicable

activate a custom action native to the specific user environment

immediately

List of Figures 插图目录

 Figure/图 1 Route which passes over the same section of road twice 路线通过同一路段两次 Figure/图 2 Heading, Pitch and Roll angle in an ISO 8855:2011 compliant coordinate system 符合ISO 8855：2011的右手坐标系中的航向角、俯仰角和横摆角 Figure/图 3 Road based s, t coordinate system with origin at the beginning of the road 基于道路的s，t坐标系，其坐标原点位于道路起点 Figure/图 4 Vehicle coordinates system. Xv – longituidnal direction, Yv –transverse direction, Zv – Vertical direction 车辆坐标系： Xv–纵向, Yv–横向、Zv–垂直方向 Figure/图 5 Diagram showing the structure of a storyboard 场景剧本的结构展示 Figure/图 6 SynchronizeAction example inducing an interceptor situation 同步动作SynchronizeAction如何触发交通妨碍者的情景 Figure/图 7 Example of SynchronizeAction combined with routing 同步动作与路径选择的搭配使用 Figure/图 8 SynchronizeAction constellation example 同步动作聚集示例 Figure/图 9 Swarm definition 群集定义 Figure/图 10 Illustration of edge dependent outputs of a Speed Condition with a greaterThan rule 包含 大于 规则的速度条件Condition的、与边缘相关的输出 Figure/图 11 State Machine for a Runtime Instantiation of a StoryboardElement 用于StoryboardElement运行时实例化的状态机 Figure/图 12 Initial positions of vehicles 车辆的初始位置 Figure/图 13 Cut-In scenario example 切入场景示例 Figure/图 14 Slow preceding scenario example 前方慢速场景示例 Figure/图 15 End of traffic jam scenario example 交通拥堵结束场景示例 Figure/图 16 Neighboring Lane Occupied scenario example 占用邻道场景示例 Figure/图 17 Double Lane changer scenario example 双车道换道场景示例 Figure/图 18 Fast Overtake during Lane Change scenario example 利用重新初始化快速超车场景示例 Figure/图 19 Overtaker scenario example 超车场景示例 Figure/图 20 Traffic jam scenario example 交通拥堵场景示例 Figure/图 21 Synchronized arrival at intersection scenario example 同步到达十字路口场景示例

List of Tables 表格目录

 Table/表 1 HTML class documentation migration content HTML类文档的迁移内容 Table/表 2 Units 单位 Table/表 3 Date and Time format specifiers 日期和时间格式说明 Table/表 4 Storyboard states 场景剧本状态 Table/表 5 Storyboard transitions 场景剧本转换 Table/表 6 Action Table: Private Actions 动作表：专属动作 Table/表 7 Action Table: Global Actions 动作表：全局动作