[OpenSCENARIO]标准解析（平民版）
⽬录
1. 背景介绍
在⾃动驾驶仿真领域，场景⼀直是⼤家关注的重中之重。因为⾃动驾驶仿真与传统的仿真的最⼤区别就是缺少了⼈。⾯对复杂的交通状况做出灵活应对，在⾃动驾驶之前⼀直是⼈类驾驶员的责任，⽽在⾃动驾驶⾯世之后，车辆本⾝需要对⾃⼰负责、对乘坐在其上的乘客负责。因此，需要在⾃动驾驶车辆上路之前，尽可能多的经历不同场景的测试和考验，才能让消费者放⼼，让⼚商⾃⼰安⼼。
⽬前维智，没有⼈敢拍着胸脯说，TA家的场景可以覆盖任何⼀种有可能存在的情况，这还有很长的路要⾛，需要集合众⼈的智慧和付出才有可能。为了让⾃动驾驶的安全性⾄少在技术层⾯上能够早⽇令⼈放⼼，在我看来，全⼈类的合作是在所难免了，众⼈拾柴⽕焰⾼，可以以最⾼的效率尽快地尽可能多的完善⾃动驾驶场景库。⽽在这个愿景实现之前，统⼀标准是基础，如果没有⼀个统⼀的标准，⼤家各说各话，那么合作这件事就纯粹是痴⼈说梦。因此，业界都在期待有⼀种公开、共⽤的⼀套场景描述标准，在未来的产业分⼯合作中，⼤家能够实现场景共享。以上都是基于我个⼈的臆想，如果⽬的不是这样，那么可能是我把它给升华了，见谅！
OpenSCENARIO起源于VTD的企业标准，⾃被ASAM收购之后，⽬前的趋势很可能会实现⼤⼀统，⾄少在国内，它的呼声很⾼，⽬前都已经成⽴了C-ASAM⼯作组，在中汽研-数据中⼼的管辖下。也得⼒于这个中国⼩组，让我们国内的⽤户有幸可以看到中⽂版的技术标准。点赞！
⾸先声明，本⼈只是仿真⼯具从业者，⾮标准⼯作组相关⼈员，⾃⼰在⼯作中读了⼀遍标准后，遂撰⽂记录下学习⼼得，如果有同⾏业者，望赐教！
2. 本⽂参考
ASAM OpenSCENARIO: Ur Guide ⽤户指南
⾄于详细的标准内容，可参考以上链接。下⾯开始详细解释什么是OpenSCENARIO.
宽慰3. 标准详解
3.1 什么是场景
场景，对于车辆驾驶⽽⾔，就是描述驾驶员驾驶着本车，在何时何地何种天⽓条件下⾏驶在⼤马路上，可能会遭遇各种其他交通参与者（车、⼈）或者路边的设施的动态变化情况。
当然，本车及其他交通参与者都不会毫⽆⽬的地⾏驶在道路上，他们都会按照⼀定的策略（如导航到某⼀个⽬的地）参与其中。
这么看来，场景的定义其实是很宽泛的，也是很多变的。这也好理解，因为我们⽆时⽆刻都处在⾃⼰的场景或者他⼈的场景中，在我们⾃⾝的认知中，⾃⼰属于本体，但其实我们⾃⼰同时也处在别⼈的场景中扮演着⼀个匆匆过客。
钻的成语
那么OpenSCENARIO的职责就是要⽤⼀种语⾔去描述上述场景，让每个⼈⼿⾥拿到OpenSCENARIO⽂件时都能看懂这是怎么样的⼀个场景。
3.2 OpenSCENARIO的范围
由于场景的细节太多，OpenSCENARIO⽆法将其全部囊括其中。在标准中，也详细描述了其范畴。在这⾥，抓⼏个重点解释⼀下。
台机电源定义了动态内容（如交通参与者的⾏为），该标准不包含静态内容（如道路⽹络）。其实在OpenSCENARIO中，静态内容是采取索引的⽅式链接到其兄弟标准OpenDRIVE和OpenCRG中
OpenSCENARIO并不包含待测系统的准确说明，例如详细的车辆配置，传感器位置，传感器模型等。在OpenSCENARIO中，重点是在描述主车可能遭遇的驾驶环境的变化，对于待测系统的准确说
明，它是留给了各家的仿真⼯具来定义的，毕竟待测系统因各家仿真器(simulator）⽽异。实际上，OpenSCENARIO并不能被视为仿真器和其待测系统或其测试⽤例的完整说明。
本标准包含了对于驾驶员基本⽣理特征的描述，例如⾝⾼和体重, 但并不包括驾驶员的⾏为模型。这⼀点对于市⾯上绝⼤多数的仿真器⽽⾔可能都没有太多的考虑，可能⼤多数的仿真器都是在做⽆⼈驾驶仿真的，驾驶员并不是⼀个需要考虑的因素，因为没有驾驶员啊。
⽽对于驾驶辅助⽽⾔，在真实世界的驾驶环境中，驾驶员模型其实是很重要的。因为不同的场景对于不同的驾驶员来说，其边界条件不
⼀样，造成的结果也不⼀样。这⼀点可以这么理解，为什么交警部门要求⼤家要⼩⼼驾驶，不要超速、不要酒驾？原因就是在规范我们的驾驶员要合规驾驶。对于那些激进驾驶员来说，我想他们也需要配备更加⾼级的驾驶辅助吧。
尽管本标准以动⼒学的⽅式呈现了车辆操作（maneuvers），也定义了基本的车辆运动模型，但该标准并不包括⾼级动⼒学的所需要素。因为场景落实到不同的仿真器中，车辆动⼒学模型就受限于仿真器本⾝了，因为有些仿真器⾥⾯就没有详细的车辆动⼒学，所以OpenSCENARIO不会对其有详细的描述。这个其实也和上⾯第⼆点相关联。
龙遇以上，就是我觉得有必要备注的OpenSCENARIO的范围，更多详细内容，请参考标准。
黄色的英语单词3.3 概念
3.3.1 场景的构成：三个要素
1. 道路⽹络：路⽹络RoadNetwork作为静态交通基础设施（包括交通信号灯TrafficSignals），需由实体Entity实例组成，此处的实体实例
指的是车辆Vehicle和⾏⼈Pedestrian等道路使⽤者。
2. 场景剧本：组成⽅案要求场景剧本Storyboard 内⾄少有⼀个或多个场景内容Story的实例存在。该场景内容Story的要素则被置于⼀
个特定结构内
3. 触发条件：定了⾏动者Actor最终采取的动作Action是由条件Condition来触发的，此处的⾏动者Actor指的是参与动作的实体Entity实
爆发力例。
以上三个定义都是直接从标准中拷贝出来的概念，但在我详细看了OpenSCENARIO的数据后，我个
⼈其实并不是按照标准上写的三个要素来理解的。在OpenSCENARIO数据⽂件中，其XML的层级结构其实是RoadNetwork, Entities, StoryBoard，我个⼈觉得这个更好⽅便我理解，场景其实是在⼀个道路⽹路中，每⼀个交通参与者（实体Entities）将按照场景剧本如何推演。⽽触发条件如果放到场景剧本中，貌似更加好⼀些。Anyway，并没有质疑标准的意思，只是提出了我的疑问。为何标准没有与XML的层级结构匹配？
3.3.2 场景剧本
场景剧本是⼀个场景的核⼼所在，这⾥⾯回答了场景中“谁”在“什么时候”做“什么”这些基本问题。每个场景剧本包含⼀个初始化要素（Init），其次是⼀个或多个场景内容Story要素。
下⾯总结了⼀个导图，通过⼀个例⼦来解释场景剧本⾥⾯各个元素的关系。
Init 初始化要素，定义了场景的初始条件，例如实体的初始位置和速度等信息。这⾥以变道超车做⼀个例⼦，初始化两辆车，分别⾏驶在道路的哪个位置，分别以多少的时速在⾏进。
Story 场景内容，定义了这个场景将会发⽣的内容
Act 动作集，回答诸如事情在场景内容时间线中何时发⽣这⼀问题，包含ManeuverGroup和StartTrigger。只有在启动触发
器 startTrigger 的判定为真时，动作集所包含的操作组ManeuverGroup才能被执⾏。
ManeuverGroup 操作组，定义了⼀个操作序列。解答了哪个实体Entity实例（谁）在场景中作为⾏动者Actor被分配到操
作Maneuver这⼀问题
Actors 动作实体，即是”谁“在操作
Maneuver 操作，即“做什么”的定义。⼀个变道超车操作可以想象⾄少包含有两个“事情”要发⽣：⾸先是借道超车，
然后再回到原车道
Event 事件，往左变道
Action 动作，⽤于创建或修改场景的动态要素，这⾥才是⼀个场景真正起到“变化”的核⼼，只有发⽣了具体
的动作，场景的动态要素才发⽣变化
StartTrigger 启动触发器，条件判定为“真”时，触发Action动作的执⾏，如在这个例⼦中，只有当后车与前
车的距离⼩于30m时，才触发“往左变道”这个动作
Event 事件，往右变道
Action 动作，往右变道 - 超车后回原车道（这才是应该有的驾驶操作，国内交通基本不考虑这个问题）...
StartTrigger 启动触发器 ...
StartTrigger 启动触发器，规定了这个操作组是从什么时候就开始触发，⽐如，在仿真⼀开始就触发这个变道超车操作组
注意：动作集Act的启动会连带着启动其操作组ManeuverGroup和操作Maneuver，但是并不会牵扯到事件Event，因为它们配有独⽴的启动触发器 startTrigger
3.3.3 动作
苹果自动重启在场景定义中，除了动作，其他部分基本上都只是描述，⽽动作是涉及到仿真器的执⾏层⾯的。个⼈觉得这个部分是仿真器需要重点考虑的部分。
动作分为三类：
PrivateAction s 专属动作
GlobalAction s 全局动作
UrDefinedAction s ⽤户定义的动作
在标准的附录A中，定义了完整的Action Tables动作表
下⾯，就拿上⾯变道超车场景中发⽣的三个动作做⼀下简要分析。
这三个动作分别是纵向动作LongitudinalAction、横向动作LateralAction和传送动作TeleportAction，这应该是三个最常⽤的动作。
1）纵向动作
在【变道超车】这个场景中，初始化中⽤到了纵向动作，初始化的时候两车都是以⼀定的速度直线⾏驶在道路上，这就是⼀个纵向动作。
在纵向动作中，⼀类是速度动作SpeedAction，这个动作的转换动⼒学特性SpeedActionDynamics是：指定⼀种转换⽅式（有step阶跃, linear线性, cubic三次⽅, sinusoidal正弦）、值和值的语义（rate变化率、time时间、distance距离）；这个动作还需要指定⼀个速度⽬标SpeedActionTarget。
在此例中，转换⽅式dynamicsShape="step“ 阶跃⽅式，值value="0"，值的语义dynamicsDimension=
节约粮食的资料
"time”；翻译过来就是：在时间跨度为零范围内，以阶跃⽅式达到⽬标速度3.61e+01 m/s (130km/h)。
在动作表中，纵向动作还有⼀个值-连续性 continuous ，如果连续 = "伪"时，⽬标为"绝对"或"相对"，动作在达到纵向速度后⽴即结束。连续 = "真"时，⽬标为"相对"，纵向速度达到后并保持相对纵向速度继续⾏驶。
但是，在此例中没有看到这个值的定义。
2）传送动作
在传送动作中，定义实体需要传送到的位置，定位的⽅式有好⼏种，此例中⽤到的是世界坐标位置worldPosition，有6个参数，分别是位置x,y,z，和朝向h,p,r。通过传送动作给实体定义了⼀个初始位置。
3）横向动作
在横向动作中，⼀类是变道动作LaneChangeAction，这个动作的转换动⼒学特性与上述的纵向-速度动作⼀样，并指定⼀个变道⽬标LaneChangeTarget（相对⽬标车道RelativeTargetLane，1为往左变
⼀个车道，-1为往右变⼀个车道）。在此例中，转换⽅式dynamicsShap="sinussoidal"，值value="5"，值的语义dynamicsDimension="time"；翻译过来是：在时间跨度为5秒内，以正弦转换⽅式往左变换⼀个车道。
3.3.4 条件和触发器
场景汇总了⼀系列有意义的动作Action，⽽触发器Trigger掌握着对此类动作的控制权。因此，触发器Trigger在场景如何衍变⽅⾯起着重要作⽤。在复杂的场景中，单个触发器可能需要使⽤⼀整组条件Condition之间的关系。
条件Condition有两种控制⽅式，分别是byEntityCondition和byValueCondition，前者以场景中某⼀个实体的状态作为判定条件，后者是以场景中的⼀个值作为判定条件。
在此例中，以实体的状态作为判定条件，⽽实体条件EntityCondition则选取了距离条件DistanceCondition，判定规则为如果$owner的位置与"Ego“的相对位置⼩于3.0e+01(30m)。
这⾥⾯涉及到很多对象的属性，罗列如下：
1) Condition的属性
Condition Properties
Name Type Cardinality AppliedStereotypes Description
name string 1..1XSDattribute Name of the condition.
delay double 1..1XSDattribute Time elapd after the edge condition is verified, until the condition returns true to the scenario. Unit: s; Range: [0..inf[.
conditionEdge 1..1XSDattribute Specifies the edge when the condition is evaluated to true (rising, falling, any).
byEntityCondition0..1xor A condition that refers to an entity.
byValueCondition0..1xor A condition that refers to a runtime value.
ConditionEdge有⼏种条件边界的判定⽅式，主要是基于当前时间点和前⼀个采样时间点的逻辑表达式的结果作为返回值的判定（解释起来好拗⼝），直接看下图和下表的整理。
说实话，这个条件在实际中是如何⼯作的，有和具体区别，本⼈还不是很清楚。望有了解的同学赐教。
ConditionEdge Previous
Logical expr
Now
Logical expr
Return
Rising
fal true true
true fal fal Falling
true fal true
fal true fal risingOrFalling
fal true true
true fal true
none return true if its logical expression is true, and fal if its logical expression is fal.
2）byEndityCondition的属性
byEntityCondition Properties
Name Type Cardinality AppliedStereotypes Description
triggeringEntities 1..1 A list of entities triggering this condition.
entityCondition 1..1The condition which is related to the triggering entities.
3）EntityCondition的属性
EntityCondition Properties
Name Type Cardinality AppliedStereotypes Description
value double 1..1XSDattribute The distance value. Unit: s; Range: [0..inf[.
freespace boolean 1..1XSDattribute True: distance is measured between clost bounding box points. Fal: reference point distance is ud.
