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 Maneuvers that involve multiple instances of Entity, like Vehicles, Pedestrians and other traffic participants. The description of a scenario may be based on driver Actions (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, Acts, ManeuverGroups and Maneuvers

• Usage of Events triggered by Triggers, defined by Conditions. Events cause Actions executions

• References to logical road network descriptions

• Instantiation of instances of Entity, such as Vehicles, or Pedestrians, acting on and off the road

• Utilization of re-use mechanisms (i.e. Catalogs and ParameterDeclaration)

OpenSCENARIO定义了一个数据模型及以此为基础的文件格式，其用于描述驾驶与交通仿真模拟器、虚拟开发、测试与验证中使用的场景。OpenSCENARIO的主要应用体现在描述复杂的、同时发生的车辆操作Maneuvers，其中包括多个不同的实体Entity实例，例如车辆Vehicles，行人Pedestrians以及其他交通参与者。场景的描述可基于驾驶员的驾驶行为Actions（例如：变道）或运动轨迹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, Pedestrians, 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 Actions the instances of Entity would be performing. However, most of these Actions also depend on the static components that define the environment in which these Actions 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 Vehicles and Pedestrians), 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 Actions 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 Actions that Actors (instances of Entity which are involved in actions) ultimately take are triggered by Conditions. More generally, Conditions are used in Triggers to start Acts and Events or to stop Acts and the Storyboard. In this sense, Conditions 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. Catalogs 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 Acts 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 控制器

Controllers can be assigned to ScenarioObjects of type Vehicle or Pedestrian. Once assigned, Controllers 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. Controllers may be internal (part of the simulator) or external (defined in another file). Intended use cases for Controllers 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 路径

Routes are used to navigate instances of Entity through the road network based on a list of Waypoints on the road which are linked in order, resulting in directional Routes. An Entity's movement between the Waypoints is left to the simulator using the RouteStrategy as constraint. There may be more than one way to travel between a pair of Waypoints. 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 Routes, the user must specify a sufficient number of Waypoints. As long as the Waypoints describe an unambiguous path, the corresponding Route specifies a one-dimensional s coordinate system that enables unambiguous localization and positioning.

Routes may be assigned to Actors 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, Actions involving Routes are not lateral Actions and do not override or create lateral Actions. 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 Waypoints 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 Routes which pass over the same section of road more than once (see example in Figure 1). The Route in the example consists of four Waypoints (shown in boxes) which are linked in order. The part of the route highlighted in red is visited twice: once on the links between Waypoints 1 and 3, and once on the links between Waypoints 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 Waypoints, 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 Waypoints 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. Clothoids 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 Actions 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 TrafficActions. With the help of TrafficActions, the parameterization of traffic sources, traffic sinks and traffic swarms can be specified.

The definition of TrafficActions in OpenSCENARIO does not specify which maneuvers will be executed by the intelligent traffic agents. Instead, those Actions 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 Acts that define conditional groups of Actions. 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 ManeuverGroups 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 Maneuvers. ManeuverGroups can also include Catalog references to reuse existing Maneuvers. This concept is described in [Catalogs].

Maneuvers define "what" is happening in a scenario. They are containers for Events that need to share a common scope, whereas Events control the simulated world or corresponding instances of Entity. This is achieved through triggering Actions, given user-defined Conditions.

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 Vehicles or Pedestrians are called MiscObjects. 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.

Actions 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

• EntitySelections describes a list of instances of Entity

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

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

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

The motion of an Entity can be controlled via Actions, user assigned Controllers 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 Actions or user assigned Controllers 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 Actions and no user assigned Controllers are running

• Actions and/or user assigned Controllers are running and one motion domain, either lateral or longitudinal, is not addressed

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

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

#### 3.2.3. Entity Selections 实体选择

EntitySelections 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.

EntitySelections can also be purposefully formed from any combination of objects within the scenario.

One use case of EntitySelections 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 Maneuvers 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 Maneuvers to come. The Actors group may be left empty. This can occur in situations where the Maneuvers in a ManeuverGroup lead to Actions 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 Actors for a given ManeuverGroup. An Actors list may contain several instantiations of the type EntityRef. Additionally, extra instances of Entity may be added to the Actors, 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 Actors depends on runtime information and is therefore impossible to know at the time the scenario is defined.

When the selectTriggeringEntities property of the Actors of the ManeuverGroup is true, all instances of Entity whose states are used by the logical expressions in Conditions which evaluate to true and are contained in ConditionGroups which evaluate to true, are added to the EntitySelection that forms the Actors.

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 动作

Actions 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. Actions are divided in three categories:

• PrivateActions 专属动作

• GlobalActions 全局动作

• UserDefinedActions 用户定义的动作

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

##### Private Action 专属动作

PrivateActions have to be assigned to instances of Entity. With PrivateActions 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 PrivateActions exist:

PrivateAction包括以下类型：

LongitudinalAction 纵向动作

Controlling speed or relative distance to a target. SpeedActions are defined e.g. by an acceleration profile (dynamicShape) while longitudinalDistanceActions 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 Vehicles' 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 LateralActions 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 Actions.

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 Waypoints 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 Actions 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 Conditions just as other instances of Entity do. They may also perform Actions by being referred to through an entity Trigger, but since their names are determined by the simulation, no Actions 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 Actions which can incorporate a command or a script file. With UserDefinedActions, a completely customized Action can be performed that is specific to the respective simulation environment.

##### Conflicting Actions 冲突动作

At runtime, it may occur that coexisting Actions 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. Actions 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 Actions of different types depend on how the Actions 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 Actions 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 动作完成标准

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

Some Actions may not be able to reach the completeState via the endTransition (for details, see chapter 3.7). By definition, these Actions 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 Actions 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 Actions can be terminated with a stopTrigger from the Act or StoryBoard they belong to. Alternatively, continuous Actions will also be terminated when overridden by conflicting Actions.

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

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

Actions acting on EntitySelections 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 Actions 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 事件

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

Actions always need to be wrapped by Events with only one exception: In the Init phase, Actions 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 Events 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 Events in the same Maneuver. The three choices concerning the corresponding Priority are:

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

 覆盖 所有在涉及范围内的其他事件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 Maneuvers are driving Maneuvers, such as a (double) lane change, or an overtaker. Nevertheless, generic combinations of Actions can be grouped to Maneuvers, 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 CatalogReferences. 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. ParameterActions and ParameterConditions 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 Catalogs (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. Catalogs 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 Catalogs 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 Catalogs, i.e. Vehicle, Pedestrian, and MiscObject, as well as their respective Controllers. Navigational instructions in the form of Trajectory and Route can also be stored within Catalogs. Additionally, descriptions of the Environment and Maneuvers 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 Parameters 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 ParameterAssignments 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 Actions whose activation is regulated by Triggers. These Triggers play an important role on how a scenario evolves since the same set of Actions can lead to a multitude of different outcomes and it all hinges on how Actions are triggered in relation to one other. A Trigger in OpenSCENARIO is the outcome arising from a combination of Conditions 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 Conditions serve as a single Trigger. 单个条件可能不足以与所需触发器Trigger相提并论。因此，在复杂的场景中，单个触发器可能需要使用一整组条件Condition之间的关系。 A ConditionGroup is an association of Conditions that is assessed in run time and can be only evaluated to true if and only if all associated Conditions are true, otherwise it will evaluate to false. A ConditionGroup is thus a way to bundle any given number of Conditions 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 Conditions, the latter are never directly used as a Trigger in the format and are instead bundled in ConditionGroups. 尽管事实上可能会用多个条件Condition之间的关系来代表所需触发器Trigger，但后者并不能在格式中直接等同于触发器Trigger。多个条件Condition仍然需要被绑定于条件组ConditionGroup A Trigger is then defined as an association of ConditionGroups. A Trigger evaluates to true if at least one of the associated ConditionGroups evaluates to true, otherwise it evaluates to false (OR operation). 触发器Trigger继而被定义为是由多个条件组ConditionGroup得出的关联。只有在至少有一个关联的条件组ConditionGroup为真true后，触发器Trigger才能是真true；否则将显示为伪false（“或”(OR)运算）。 Given the nature of individual ConditionGroups (AND between its Conditions) and associations of ConditionGroups (OR between its members), a Trigger embodies a comprehensive mapping of the relationship (AND, OR) between individual Conditions. 鉴于不同条件组的特性（条件Condition之间的关系是“与”(AND)）以及条件组的关联（成员之间的关系是“或”(OR)），触发器Trigger包含了每个条件Condition之间的关系（与/或运算AND, OR）的全面映射。 Triggers 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 ManeuverGroups and Maneuvers, but does not start the Events since they have their own startTriggers. Furthermore, no Events 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 Acts, 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，该含有无 noneCondition条件组将返回真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 Conditions 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的所有其他要素与其子类型息息相关，ByEntityConditionByValueCondition便是其中两个类型。 ##### 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 StoryboardElements is marked by its runtime state. Runtime states must be referred to by the OpenSCENARIO standard since they can be used to create Conditions and to determine how StoryboardElements interact with Triggers. 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 StoryBoardElements 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 Actions are in the completeState. 当一个事件Event的所有动作Action都处于完成状态 completeState 时，则该事件Event完成其目标。 Maneuver 操作 A Maneuver's goal is accomplished when all its Events are in the completeState. 当一个操作Maneuver的所有事件Event都处于完成状态 completeState，则该操作Maneuver完成其目标。 ManeuverGroup 操作组 A ManeuverGroup's goal is accomplished when all its Maneuvers are in the completeState. 当一个操作组ManeuverGroup的所有操作Maneuver都处于完成状态 completeState，则该操作组ManeuverGroup完成其目标。 Act 动作集 An Act's goal is accomplished when all its ManeuverGroups are in the completeState. 当一个动作集Act的所有操作组ManeuverGroup都处于完成状态 completeState，则该动作集Act则完成其目标。 Story 场景内容 A Story's goal is accomplished when all its Acts 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 Actions (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 Acts: • 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 Acts 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 动作集 Acts, which contain ManeuverGroups, allow a set of Triggers 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 Triggers at an Event level, but this would result in much more complex, sometimes duplicated, ConditionGroups.  这个示例场景在动作集 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, Acts, ManeuverGroups, Maneuvers and Events may be executed in any order, as defined using Triggers. 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 ManeuverGroups 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 Actions. However, not all of these Actions 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 ManeuverGroups:

<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 Actions, 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 Triggers 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 Events, Conditions 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 Events, Conditions 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 ParameterDeclarations.

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 Acts and the usage of Conditions.

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 ParameterDeclarations, and use of parallel Actions.

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 Conditions and consecutive execution of LaneChangeActions.

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 Acts and Actions.

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 Conditions and consecutive execution of LaneChangeActions.

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

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

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

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

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 动作表：全局动作