为了实现自动驾驶场景设计的标准化，德国自动化及测量系统标准协会（ASAM）推出了OpenX系列标准。
例如OpenDrive标准用于描述场景静态信息的路网，OpenCRG描述路面信息，而OpenSCENARIO则是用来描述动态场景的。
这里会对学习到的OpenSCENARIO 1.0（下称OSC）相关内容进行记录。
部分翻译根据个人理解做了调整，一切以英文为准（特别的，*/概念名称*是我认为相对值得一提但没有采用的官方文档翻译；更特别的，这官方中文真够烂的）。
参考：
场景的基础概念是“谁，在哪里，做什么”，即实体在路网上根据故事板定义的一组指令进行交互。
场景定义的五个基本概念（Concept*/方案*）是：
- Entity：实体，车辆行人等参与者。
- RoadNetwork：路网，静态的场景元素，包括OpenDRIVE、交通信号、环境模型等。
- StroyBoard：故事板/场景剧本**，（完整的动态描述。
- 另有两个内容：ParameterDeclaration参数声明和Catalog目录，将在将来用到时提及。
OSC通过StoryBoard描述整个场景的完整内容，它有下述构成：
- Story：故事，即最高层次的场景描述单位；至少1个。
- Act：幕，包含了触发开始条件（和触发结束条件，可选），只有触发时下述内容才会执行；至少1个。
- ManeuverGroup：操作组，明确交互主体和交互动作，即连接Entity和Maneuver；至少1个。
- Actors：角色，即被影响的实体。
- EntityRef：被引用实体，即被影响的实体列表；至少0个（因为操作组有可能并不影响实体）。
- CatalogReference：可被重复使用的内容；至少0个。
- Maneuver：操作，即事件组，包含若干事件；至少0个。
- Event：事件，有触发开始条件；至少1个。
- Action：动作，与场景产生交互，例如改变天气、改变设置、定位车辆；至少1个。
以上的所有内容都被称为StoryBoardElement（故事板元素/场景剧本要素）。
StoryBoardElement拥有3种状态，即为StoryBoardElementState（故事板元素状态）：
对于在这3种状态中切换，有4种Transition（转换）：
Entity有两类：
Entity默认拥有一个Controller（控制器），用于接收来自控制算法之类的指令。
此外，Entity的实例会被分为两种：
EntitySelection是将场景中已经存在的若干Entity进行快速分组。
这样分组，是为了能一同在其他地方被引用（例如批量生成Entity实例，并执行相同的动作）。
在Act以及Event中，都需要使用这两种主要的Trigger（触发器）来控制流程的启停：StartTrigger和StopTrigger。
StartTrigger将故事板元素从standByState切换到runningState；而StopTrigger将其从其他状态（待机或运行）切换到completeState。
一个Trigger的结果是一个T/F值，这是由它所含有的Condition（条件）以逻辑运算共同决定的。
为此，OSC将Condition的逻辑运算设计成这样：
拥有StartTrigger的故事板元素：
没有StartTrigger的故事板元素，例如ManeuverGroup和Maneuver，它们会继承父级的StartTrigger，也就是从Act中继承；具体表现也就是当Act启动后，其底下的ManeuverGroup都会自动启动。
但是，如果拥有自己的StartTrigger，那它们的启动就要满足它们自己的Condition；而如果它们的父级Act不在runningState（运行状态），则不能启动，这是不言自明的。
此外，Story也不需要startTrigger，毕竟在仿真启动时它就自然被启动了。
拥有StopTrigger的故事板元素：
同StartTrigger，其他故事板元素会继承父级的StopTrigger；但有所不同的是，一旦父级故事板元素停止了（进入completeState），无论自己有没有StartTrigger，它底下的所有故事板元素同样都要立刻停止。
正如上文所述，ManeuverGroup主要包含Actors和Maneuver这两部分。前者决定哪些Entity会被影响，而后者描述具体是什么Action影响（以及是怎么被触发Event的）。
对于Action有以下3种分类，具体可见官方文档：
为了实现自动驾驶场景设计的标准化，德国自动化及测量系统标准协会（ASAM）推出了OpenX系列标准。
例如OpenDrive标准用于描述场景静态信息的路网，OpenCRG描述路面信息，而OpenSCENARIO则是用来描述动态场景的。
这里会对学习到的OpenSCENARIO 1.0（下称OSC）相关内容进行记录。
部分翻译根据个人理解做了调整，一切以英文为准（特别的，*/概念名称*是我认为相对值得一提但没有采用的官方文档翻译；更特别的，这官方中文真够烂的）。
参考：
场景的基础概念是“谁，在哪里，做什么”，即实体在路网上根据故事板定义的一组指令进行交互。
场景定义的五个基本概念（Concept*/方案*）是：
- Entity：实体，车辆行人等参与者。
- RoadNetwork：路网，静态的场景元素，包括OpenDRIVE、交通信号、环境模型等。
- StroyBoard：故事板/场景剧本，（完整的动态描述。
- 另有两个内容：ParameterDeclaration参数声明和Catalog目录，将在将来用到时提及。
OSC通过StoryBoard描述整个场景的完整内容，它有下述构成：
- Story：故事，即最高层次的场景描述单位；至少1个。
- Act：幕，包含了触发开始条件（和触发结束条件，可选），只有触发时下述内容才会执行；至少1个。
- ManeuverGroup：操作组，明确交互主体和交互动作，即连接Entity和Maneuver；至少1个。
- Actors：角色，即被影响的实体。
- EntityRef：被引用实体，即被影响的实体列表；至少0个（因为操作组有可能并不影响实体）。
- CatalogReference：可被重复使用的内容；至少0个。
- Maneuver：操作，即事件组，包含若干事件；至少0个。
- Event：事件，有触发开始条件；至少1个。
- Action：动作，与场景产生交互，例如改变天气、改变设置、定位车辆；至少1个。
以上的所有内容都被称为StoryBoardElement（故事板元素/场景剧本要素）。
StoryBoardElement拥有3种状态，即为StoryBoardElementState（故事板元素状态）：
对于在这3种状态中切换，有4种Transition（转换）：
Entity有两类：
Entity默认拥有一个Controller（控制器），用于接收来自控制算法之类的指令。
此外，Entity的实例会被分为两种：
EntitySelection是将场景中已经存在的若干Entity进行快速分组。
这样分组，是为了能一同在其他地方被引用（例如批量生成Entity实例，并执行相同的动作）。
在Act以及Event中，都需要使用这两种主要的Trigger（触发器）来控制流程的启停：StartTrigger和StopTrigger。
StartTrigger将故事板元素从standByState切换到runningState；而StopTrigger将其从其他状态（待机或运行）切换到completeState。
一个Trigger的结果是一个T/F值，这是由它所含有的Condition（条件）以逻辑运算共同决定的。
为此，OSC将Condition的逻辑运算设计成这样：
拥有StartTrigger的故事板元素：
没有StartTrigger的故事板元素，例如ManeuverGroup和Maneuver，它们会继承父级的StartTrigger，也就是从Act中继承；具体表现也就是当Act启动后，其底下的ManeuverGroup都会自动启动。
但是，如果拥有自己的StartTrigger，那它们的启动就要满足它们自己的Condition；而如果它们的父级Act不在runningState（运行状态），则不能启动，这是不言自明的。
此外，Story也不需要startTrigger，毕竟在仿真启动时它就自然被启动了。
拥有StopTrigger的故事板元素：
同StartTrigger，其他故事板元素会继承父级的StopTrigger；但有所不同的是，一旦父级故事板元素停止了（进入completeState），无论自己有没有StartTrigger，它底下的所有故事板元素同样都要立刻停止。
正如上文所述，ManeuverGroup主要包含Actors和Maneuver这两部分。前者决定哪些Entity会被影响，而后者描述具体是什么Action影响（以及是怎么被触发Event的）。
对于Action有以下3种分类，具体可见官方文档：