ASAM OpenSCENARIO: User Guide 用户指南

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.

场景描述了从某个观察角度对世间事物在时间序列中的变化。在车辆驾驶方面，场景包含了静态要素如道路基础设施及动态要素如天气、光照、车辆、移动目标、行人或道路交通信号。场景的定义在虚拟环境、现实环境或虚拟现实环境中同样适用。

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:

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

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

该标准中还包括其他内容，例如对于本车 Ego Vehicle 、驾驶员的状态（driver appearance）、行人Pedestrians、交通和环境情况的描述。

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.

本标准基于UML数据模型，该模型用于导出XML模式文件以进行XML文件验证。此外，本标准包含了一份引用方法说明和用户指南。

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.

本标准可与ASAM OpenDRIVE定义的道路网络描述搭配使用。这些标准相互补充，共同描述了用于进行驾驶仿真、虚拟测试、开发和验证的虚拟世界所需的全部内容。

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

在0.9.1版本和1.0.0版本之间做迁移时，可能会出现以下问题：

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

这些特定问题都可在文档和XSLT转换脚本中得到解决：

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.

所有迁移问题都会在XSLT转换脚本中得到解决。在极少数情况下，迁移会无法创建有效或一致的文档。如果创建了无效的文档，报错提示会提醒用户进行必要的手动检查。如果创建了不一致的文档，用户则会收到一个警告。

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.

迁移的一项核心任务是将已通过0.9.1模式验证过的文档转换成有效XML文件，此文件将针对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.

作为最低要求，0.9.1版本的场景描述必须针对0.9.1版本模式进行验证。除此之外，0.9.1版本的描述必须在语义及内容链接上也是有效的（例如目录，参数定义等）。迁移既不会检查导入的0.9.1版本描述的语义有效性，也不会检查作为结果的1.0.0版本描述的语义有效性。

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

为了能在场景中使用道路网络的语义信息，道路网络的描述标准OpenDRIVE [1] 可被引用至OpenSCENARIO中。同时，道路路面的性质描述OpenCRG [2] 也可被引用。

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.

本标准中的所有数值均使用SI（国际单位制）单位，除非另有标注。（请参见Table/表 2）。Table/表 2列出了所用单位的详细信息。

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.

使用ISO 8601 [3] 基本符号来规定时间和日期，其格式为：“yyyy-MM-dd‘T’HH:mm:ss ‘.’ FFFZ”。此处的“ T”会再次用作时间分割符，而“.”将用作对于毫秒部分的分隔符。详细解释在Table/表 3中。

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"…​).

每个层级的要素名称在该级中必须保持唯一性，也就是说不能有多个具有相同名称的要素存在。例如，在一个场景内容Story中，每个动作集Act必须使用唯一的名称（“ MyStory1”：“ MyAct1”，“ MyAct2”……），但是动作集Act的名称可能会在另一个场景内容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.

如果引用并不能遵循唯一性原则，例如，指定的名称前缀太少而无法完全消除二义性，这将会导致查找结果错误。

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.

为了确保能够正确地描述道路使用者的行为，OpenSCENARIO需要引用道路网络逻辑的描述。此外，也可以引用三维3D模型的形式对环境进行几何和视觉重现。以上的引用建立于道路网络RoadNetwork的描述中。例如，OpenDRIVE的文件格式就被常用来对道路网络逻辑进行描述。

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.

场景创建者经常需要参考道路网络中定义的项（例如，指挥车辆在特定车道上行驶）。OpenSCENARIO并不强制在这些外部引用中使用OpenSCENARIO本身的命名系统，只要在引用时，这些要素继续使用原文件格式分配的名称即可。

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

以下道路网络的内容可在OpenSCENARIO中使用：

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.

如前所述，OpenSCENARIO支持用OpenDRIVE格式对道路网络进行描述+[<<opendrive,1>>]+。此格式描述了与道路结构有关的逻辑信息，例如道路标识ID，车道标识ID和道路几何形状。这些信息可用于标识定位在道路上行动的实体Entity实例以及定位交通参与者。如果使用OpenDRIVE来再现道路网络，其车道序列需与OpenSCENARIO文件中的车道序列进行匹配。

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.

除了引用道路网络描述之外，也可以在场景描述中引用能够再现环境的三维3D模型。三维3D模型包含了几何及材质纹理等视觉信息，完整再现了虚拟环境(包括路面)。场景中引用的三维3D模型有以下应用案例：图像渲染，物理建模和传感器仿真。这些三维3D模型的文件属于OpenSCENARIO格式中的外部要素。

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]).

控制器Controller可以被分配给场景目标ScenarioObject如车辆Vehicle或行人Pedestrian等。在完成分配后，控制器启动动作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:

在执行控制器激活动作ActivateControllerAction时，被分配给该场景目标ScenarioObject的控制器Controller将得到其领域的管理权。控制器Controller可以是内部的（仿真器的一部分）或外部的（在另一个文件中）。控制器Controller的设想应用案例包括：

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

控制器Controller包含多种属性Properties，这些属性将用于直接或借助文件File引用而对控制器Controller行为进行详细说明。

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.

路径Route用于对实体Entity实例进行导航，其方式则是通过基于道路上的航点Waypoint列表来生成定向的路径Route。仿真器将利用其路径策略RouteStrategy来限制实体Entity实例在航点Waypoint中的运动。一对航点Waypoint之间可能有不止一种运动方式。如果是这种情况，将只采用该对中的后一个航点指定的路径策略RouteStrategy。请注意，此策略的实现方式在仿真器之间可能会有所不同。为了创建明确的路径Route，用户必须规定足够数量的航点Waypoint。只要航点Waypoint能够描述明确的路线，相应的路径Route会输出一维的s坐标系，从而能够进行明确的定位。

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

在执行获取位置动作AcquirePositionAction或赋予路径动作AssignRouteAction后，路径Route会被分配给行动者Actor。分配结束后，它们将继续被保留在原位置，直到另一条路径覆盖它们为止。

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.

如果实体Entity已在行进路径中，通常会在到达路口时继续跟进同一条路径。不管怎样，参与到行进路径Route中的动作Action并不是横向的动作Action，它不会覆盖或建立新的横向动作Action。这意味着如果相应的实体Entity在错误的车道中或被定义了冲突性的横向行为（例如，动作Action包含了运动轨迹Trajectory），在这种情况下路径不会被继续跟进。因此当发生这些情况时，路径会被作为无视处理。

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.

如果一个实体Entity正在接近道路交界处并且不在路径Route上，又或者在一条不能被继续跟随的路径Route上，那么将从可用选项中随机选择是否要继续跟随这条道路。

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:

当一条路径Route多次通过同一个路段，便可启用其他附加的规则（参见图1中的示例）。该示例中的路径Route由四个相连接的航点Waypoint（方框中）组成。用红色标出的路径部分被访问过两次。航点Waypoint 1和航点3之间, 航点Waypoint 3和5之间的链接各被访问了一次。使用以下规则可避免实体Entity陷入无限循环：

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:

运动轨迹Trajectory实例可通过数学公式来精准定义及预测实体Entity运动的轨迹。以下不同的数学模型可用于规划活动路线：

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.

通过使用Nurbs曲线，可以直接或使用任意近似值来展示最相关的路线：Nurbs曲线建立了严格的曲线超集，其涵盖了Bézier曲线、分段Bézier曲线或非有理B-Spline。以上曲线均可简单地映射到相应的Nurbs曲线上。此外，Nurbs曲线可直接支持圆锥形截面（例如圆形和椭圆形）的展示，因此可使用与Clothoid曲线相似的弧线样条（arc spline）作为替代。

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.

常用的Nurbs曲线是二次（阶数=3）和三次（阶数=4）方的曲线，通常为了确保较高阶导数的连续性，我们只需要使用较高阶的曲线。由于评估会根据较高阶曲线而需要满足更多算力需求，所以我们会建议在可能的情况下去降低运动轨迹Trajectory实例的阶数。

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.

运动轨迹Trajectory实例的详细说明可以仅通过三个位置维度（沿X，Y和Z轴，请参见[Coordinate Systems]以了解坐标系定义）来实现。另一种方式则为使用包含三个位置维度和三个旋转维度（航向角，俯仰角和横摆角）的六个完整维度来对运动轨迹Trajectory进行详细说明。使用第二种方式，路线不仅会详细说明实体沿着路线运动的情况，同时对相应实体Entity在其运动期间的方向也会作出详细说明。

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.

此外，无论是否考虑时间维度，都可以详细说明运动轨迹Trajectory实例以便对实体Entity的纵向域进行详细说明或做出单独的说明：其中包含时间维度的运动轨迹Trajectory可以完全说明实体的运动，包括其速度。而没有包含时间维度的轨迹不会说明在路线上的速度，因此速度可以额外被控制。

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通过数学方法精确定义了运动路线，采用了其运动路线的动作Action仍会影响相关的实体Entity。实体Entity可严格跟随这一路线，或在实体Entity运动规则允许的情况下，将路线用于引导控制器。

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

将在[Motion Control for Entities]中对运动轨迹做进一步描述。

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:

根据ISO 8855：2011 [4+]+的规定，坐标系包含三个相互垂直方向的集及与其关联的X，Y，Z轴（轴系）和一个坐标原点。OpenSCENARIO有两种主要类型的坐标系：

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

如上所述的坐标系类型可用于创建多个坐标系并且在以下小节中具体列出。

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.

除了定义实体Entity实例的确定性行为外，OpenSCENARIO还可以定义随机或模糊行为。这类定义可以用于例如建立场景内或实体Entity实例周围的交通环境，从而进一步增加场景整体的真实性，并在场景排序中引入更多的变化，以及定义交通环境的参数（比如交通密度）。在实现的过程中，可以使用交通动作TrafficAction来定义周围的智能交通代理，也可以借助交通动作TrafficAction对交通源、交通接收点和交通群集的参数进行详细说明。

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一样，被生成的交通参与者将根据其相应的驾驶员模型来做出相应路径决策。

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.

在OpenSCENARIO中，场景剧本Storyboard涵盖了完整的场景描述。场景剧本这个概念的结构和命名与戏剧之类的叙事小说中的经典叙事方式有异曲同工之意。场景剧本Storyboard回答了场景中“谁”在“什么时候”做“什么”这些基本问题。每个场景剧本包含一个初始化要素（Init）,其次是一个或多个场景内容Story要素。

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.

场景内容Story允许场景创建者对不同详情进行分组，场景作者可将这些详情分组到更高的层次结构中，从而达到在大型场景中提供结构的目的。

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.

与叙事小说一样，OpenSCENARIO中的场景内容Story实例包含动作集Act，它们定义了执行动作Action所需的条件组。动作集Act专注于回答诸如事情在场景内容时间线中何时发生这一问题。这可以通过动作集Act的两个功能来实现：启动触发器 startTrigger 和停止触发器 stopTrigger 。只有在启动触发器 startTrigger 的判定为真时，动作集所包含的操作组ManeuverGroup才能被执行。

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

操作组ManeuverGroup是动作集Act的一部分，它很好解答了哪个实体Entity实例（谁）在场景中作为行动者Actor被分配到操作Maneuver（见[Maneuver groups and Actors]）这一问题。操作组ManeuverGroup中还包含了目录Catalog的引用以便能够再次使用已有的Maneuver。关于这个方案详情请参见[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.

操作Maneuver定义了场景中正在发生什么“事情”，它们相当于Event可以共享的公共范围。在该范围之内，事件会通过触发动作Action以及给定的用户定义的条件Condition来控制仿真的世界及相关的实体Entity实例。

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

场景剧本Storyboard是整体最高层次结构的名称，如Figure/图 5所示，它涵盖了到目前为止介绍过的所有要素。

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):

在一个场景中，实体Entity实例是那些可以随着时间的流逝动态地改变位置的目标物体。其他目标MiscObject是非车辆Vehicle或行人Pedestrian的实体Entity实例。其他目标MiscObject组包括以下对象类（与OpenDRIVE格式相同）：

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.

实体Entity实例可在场景格式中被详细说明，属性则特定于其不同的类型。例如，车辆Vehicle是一个实体Entity实例，它拥有诸如车辆类别 vehicleCategory 和性能 performance 之类的属性。相反，行人Pedestrian是通过诸如模型 model ，体重 mass 和名称 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.

动作Action可以影响并改变实体Entity的状态，例如实体的位置Position、速度或控制器Controller。另外，在触发动作Action前可先查询实体Entity的状态。

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

在OpenSCENARIO中，实体Entity实例被分为两组：

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.

实体选择EntitySelection可以用于对场景中存在的实体Entity实例进行快速分组，它们可以在任何地方被引用。通过一个被引用的实例可以立即将新状态分配给实体Entity的多个实例，其汇总信息也可作为触发器Trigger使用。

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

实体选择EntitySelection也可以通过场景中任意目标对象的组合而有目的地生成。

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.

实体选择EntitySelection的应用案例之一：选择实体Entity的多个实例以便在同一时间实现一个特定的操作Maneuver。操作组ManeuverGroup中的行动者Actor可以直接使用该实体选择EntitySelection作为其名称，继而一个操作Maneuver被创建，该操作将会在某个仿真时间条件SimulationTimeCondition下被触发。

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.

一个根据其操作组ManeuverGroup中的操作Maneuver而单独挑选出的实体Entity实例可以被用作于驱动或引用。在实体Entity实例在操作Maneuver中发挥作用前，他们会被分组并将作为操作组ManeuverGroup中的行动者Actor被引用。行动者Actor组可以是空的，这种现象发生在当操作组ManeuverGroup中的操作Maneuver引发了动作Action，而该动作与实体Entity实例并无关联, 但却与外部世界或仿真状态相关。

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.

实体引用EntityRef要素可以用于定义行动者Actor。此要素会被合并到一个开放列表中并用于定义已知操作组ManeuverGroup所属的行动者Actor。一份行动者Actor的名单可能包含了多个不同类别的实体引用EntityRef的实例。另外，如果选择触发实体 selectTriggeringEntities 选项处于激活状态，则可以在触发时将实体Entity的其他实例添加到行动者Actor中。

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.

实体引用EntityRef要素对现存的实体Entity和操作组ManeuverGroup中的行动者Actor进行了明确的配对，并通过在要素中详细说明所需实体Entity的名称来实现配对。实体引用EntityRef的使用方式适用于在场景被定义后，所关注的实体已然明确的情况。

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.

当行动者Actor的选择依赖于运行时的信息而因此无法得知场景是否在此刻被定义时，便可使用选择触发实体 selectTriggeringEntities 属性。

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.

当操作组ManeuverGroup中行动者Actor包含的选择触发实体 selectTriggeringEntities 属性为真，只要实体实例的状态用于条件Condition（判定为真）中的逻辑表达式，并且该状态存在于同样为真的条件组ConditionGroup中，所有这些实体Entity的实例会被添加到用于形成行动者Actor的实体选择EntitySelection中。

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

此外，如果实体引用EntityRef和选择触发实体 selectTriggeringEntitie 的组合也被设定为真，最终的行动者Actor将会是两者的结合。

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]).

最后，操作组ManeuverGroup和最大执行数 maximumExecutionCount 的共同定义将会详细说明操作组ManeuverGroup应运行的次数，每一次的结束转换 endTransition 都将同时增加一次运行次数。（请参见[Transitions]）。

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:

动作Action用于创建或修改场景的动态要素，例如，车辆横向动态的变化或一天中时间的变化。动作分为三类：

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.

在场景的初始化阶段，动作Action负责设置动态对象、环境、基础设施等的初始状态。在场景的任何后续阶段中，事件Event被触发，从而引发动作Action执行。在以下子章节中，我们会简要解释OpenSCENARIO定义的动作Action的子类型。

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.

动作Action是单一性的，需要通过组合才能使其在场景中产生有意义的行为。此行为由事件Event创建，所以事件可被认作为是动作Action的容器。Event事件还包含启动触发器startTrigger。启动触发器不仅能决定事件Event开始的时间，它还可以用于启动事件中的动作Action。

Actions always need to be wrapped by Events with only one exception: In the Init phase, Actions are declared individually.

一般情况下，动作Action都需要事件Event来作为包裹容器，只有一个例外：动作Action在初始Init阶段已被单独声明。

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.

最大执行数 maximumExecutionCount 详细说明了事件Event应运行的次数，运行次数会随着每次结束转换 endTransition 的结束而增加。

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:

事件Event是可以被参数化的。参数化通过定义同一操作内共存事件的优先级 priority 来实现。每当事件开始时，优先级 priority 参数都将作为考虑因素以确定在同一操作Maneuver中正在运行的事件Event会遇到的情况。关于相应优先级Priority的三个选择分别是：

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.

场景中定义的每个事件Event都对应着一个单一的运行时实例化，这意味着同一个事件Event不能同时进行多次实例化。因此，除非事件Event处于待机状态，不然启动触发器 startTrigger 不具备任何意义。相反地，每个启动触发器 startTrigger 启动一个新的事件Event实例化则具备意义。

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.

操作Maneuver可将事件Event组合到一起。目录Catalog会收录操作Maneuver并对其进行定义和参数化，以便能在不同场景中重复使用参数化的操作Maneuver。操作Maneuver包含例如一次或双车道变道、超车这样的驾驶操作。除此之外，操作Maneuver中也包含动作Action的通用组合，例如将其用于仿真天气的变化。

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.

在OpenSCENARIO中，参数是场景扩展机制的关键。借助参数，场景设计者可以让场景的参数化过程变得更为明确。外部工具可以读取提供的参数，并通过复杂的方法来为参数分配具体值。通过这种扩展方法，场景可以被赋予较大的具体值空间以供使用，例如场景将以不同的速度重新被仿真。

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.

对参数的设置和评估发生在仿真加载期间。这些参数不受参数动作ParameterActions和参数条件ParameterConditions影响，后两者则将在仿真运行期间得以实施。

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

以OSC开头的参数名称在之后的OpenSCENARIO版本中有特别用途，因此OSC被禁止作为参数名称前缀使用。

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

另外，以下特殊字符也不可以出现在参数名称中：

Special rules apply to referencing parameters within Catalogs (see section 3.4.3).

特殊规则适用于在目录Catalog中引用参数（请参阅第3.4.3节）。

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的描述。

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：

When referenced in the main scenario, the value of x is overridden by using a ParameterAssignment within the CatalogReference:

在主要场景中进行引用时，使用目录引用CatalogReference里的一个参数分配ParameterAssignment来覆盖x的值：

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"替代。目录中不得引用其他参数。

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:

任何有正确目录类型和目录名称的有效目录文件都必须在定义好的文件夹里进行处理。也可以在场景中定义一个含所有目录类型的总目录：

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中的方法。

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 被引用。