0.说明
→ 方块是程序，圆柱是数据； 黑色是通信协议，灰色是用户组件，橙色是 VTD 组件，黄色是硬件
→ 八大进程：SimServer / TaskControl / ParameterServer / GUI ModuleManager / Traffic / ScenarioEditor / IG
→ 三大标准：OpenDRIVE / OpenCRG / OpenSCENARIO OdrMgr OdrViewer → 工具组件：ROD / RDBSniffer / OdrGateway / Docker / RosGateway / etc
→ 开发 SDK：Communication / Module / Traffic / IG / Content(Cars) / etc
1.四大流程
→ 建立静态道路（更广泛的理解：静态内容开发） 输入:国家道路规范，外部模型合格，现有 tile 输出：逻辑道路数据库 xodr，图形道路数据库 osgb
→ 建立动态工况(更广泛的理解:模拟故事的脚本) 输入：逻辑道路数据库 oxdr(关键)图形道路数据库 osgb若不在乎 IG 这里可以随便赋值) 输出：场景文件 xml
→ 仿真 输入：Setup（根据 simServer.xml 启动每个过程，配置文件)和 Project 及 Scenario 输出：traffic 数据输出(RDB)，IG 数据输出(Monitor or Shm or RDB)
→ 后处理 输入：仿真结果，评价标准 输出:评价结论，测试报告
2.最小系统描述 （standard SampleProject/trafficDemo.xml）
→ 当在 bin 执行文件夹$ ./vtdStart.sh -select 而且选了一个 Setup 后 脚本会启动 SimServer，并且根据 setup/config/SimServer/simServer.xml 中的 process 标签逐一启动 GUI 启动，也就是图形界面 TaskControl 启动，没有图形界面，但有一个 Xterm 小窗户显示其状态 ParamServer 启动，同上 Traffic 待命， ModuleManager 待命，igGroup 待命，ScenarioEditor 待命
→ 当在 GUI 上按下 Apply 以后，除了 TC 和 PS，以外 Traffic,IG,MM 还可以看到他们三个的小窗户 Traffic 启动，即它知道需要执行的场景文件 xml 逻辑道路文件 xodr 是谁 ig 启动，即它知道需要执行的场景文件 osfb，天空模型材料数据，车辆模型等。 MM 启动，即它使其管理的传感器和动力学模型初始化，并准备开始工作 注：刚按下按钮的操作实际上是 GUI 向 TC 发送了一条 SCP 报文导致上述行为
→ 当在 GUI 上按下 Start 按钮后，仿真正式开始。 TC 根据我们在 ParamServer 配置开始协调模拟所有模块，同步等具体细节再次被忽略。
1.Traffic 根据场景文件 xml 开始运算第一帧下交通场景的状况 比如这帧交通灯 phase，internal 这一帧车辆的位置姿势，每一帧 trigger 状态等。 根据 extern 车辆驾驶员配置，制作当前此帧的驾驶行为信息。 当然了，Traffic 还需要通过 OdrMgr 访问 xodr 计算文件获取信息。
2.TC 从 Traffic 得到场景全部逻辑信息后进行分发。 例如：传递驾驶信息 MM，还应提供场景信息 MM，如果 SE 启动后，也会给它。重要的是给它 IG。
3.MM 从 Traffic 得到数据后，按照 plug-in 优先调用他们 如：传感器 plugin 根据传感器的参数，对数据进行过滤，然后组织结果，发送到指定的端口。 动力学 plugin 计算数据 extern 发送给车辆的位置姿态 TC
4.SE 从 TC 获取数据后，交通参与者在场景中的状态可以实时显示。 SE 也可以用 Monitor 向 TC 发出 SCP 指令；GUI 也可以发 SCP 影响下一个模拟状态的指令。 如果 SCP 是关于交通的，比如让车换道，那么信息就会给出 Traffic 执行中的驾驶员模型。 如果 SCP 是关于环境的，比如改变天气，那么信息就会给出 IG 渲染去除相应的雨雪效果。
5.IG 从 TC 获取数据后，渲染 如：根据当前环境调整关照，根据当前摄像头信息进行画面渲染，根据当前交通信息摆放车辆等。 如：如果 IG 有 plug-in，激光雷达的感知工作也应根据优先级进行调用。 → 就这样，每个模块都有自己的工作，每个模块的具体置文件的影响。 例如 IG 配置文件很多，MM 只需维护一份文件。
→ 参与外部模块，即通过 SCP 和 RDB 的方式。 Mockup 方向盘和踏板实际上是 USB 信号进行分析并打包 RDB 发给 Dynamics 了。 Sound 进来就是通过 TC 获取汽车信息，触发声音作为参数。 任何 3rd Party 只要知道 RDB 和 SCP 的数据结构和含义，就可以影响整个仿真。 比如用手机发指令改变天气，或者用手机在路上开车，当然需要开发手机客户端。 → 如果生成数据需要外部设备，则根据具体情况进行分析。例如，如果视频流需要到处，则可能需要集成器。 如果 RDB 需要给出数据 ECU，然后需要转换成 CAN 信号。 具体工程问题需要具体分析。
总结:以上过程是四个过程中的模拟过程，涉及到 八个过程。数据流通信使用 RDB/SCP。
→ 就这样，每个模块都有自己的工作，每个模块的具体置文件的影响。 例如 IG 配置文件很多，MM 只需维护一份文件。
→ 参与外部模块，即通过 SCP 和 RDB 的方式。 Mockup 方向盘和踏板实际上是 USB 信号进行分析并打包 RDB 发给 Dynamics 了。 Sound 进来就是通过 TC 获取汽车信息，触发声音作为参数。 任何 3rd Party 只要知道 RDB 和 SCP 数据结构和意义会影响整个模拟。 比如用手机发指令改变天气，或者用手机在路上开车，当然需要开发手机客户端。
→ 如果生成数据需要外部设备，则根据具体情况进行分析。例如，如果视频流需要到处，则可能需要集成器。 如果 RDB 需要给出数据 ECU，然后需要转换成 CAN 信号。 具体工程问题需要具体分析。
总结:以上过程是四个过程中的模拟过程，涉及到 八个过程。数据流通信使用 RDB/SCP。
3.自动驾驶数据流框架(最简单形式)
1.环境：交通环境和自然环境，也就是 VTD 提供的核心部分。 交通环境包括静态道路（ROD 制作，依照 OpenDRIVE）和动态场景 ScenarioEditor 由自然环境决定 IG 进行渲染
2.传感器:直接获得完美传感器 Object List 信息源息，信息源是 Traffic 物理传感器，根据传感器类型，通过 IG 或者 MM 计算的 Raw Data，主要提供感知算法
3.感知算法:被测设备之一 Raw Data 处理语义学信息。
4.集成算法：感知和决策之间的桥梁，统一输入多传感器之间的不同结果
5.决策算法:被测设备之一，给出顶级指令，属于规划范畴
6.控制算法：根据测量和动力学之间的桥梁，最终实现车辆的横向和纵向控制
7.动力学：根据车辆本身的参数、道路信息、控制信息和上一刻的状态计算当前状态。
总结：VTD 传感器从模拟环境中的环境车辆(背景车辆)控制 Traffic 实现模块。 使用 VTD 模拟环境模拟被测车辆，可根据上述过程进行有针对性的拆分。
4.八大进程
→ SimServer 初始化管理过程
→ TaskControl 操作和管理过程 IO
→ ParamServer 管理基本参数
→ GUI 用户界面 → Traffic 交通仿真
→ ModuleManager 管理 Module Plugin 完美的传感器和动力学
→ ScenarioEditor 编辑和模拟动态场景监控
→ ImageGenerator 相机仿真/激光雷达仿真
5.三大标准
→ OpenDRIVE 道路的逻辑描述包括几何信息、车道线信息、交通信息、建筑信息
→ OpenCRG 减速带等道路的微观特征
→ OpenSCENARIO 交通动态信息
6.数据流和通信
→ RDB 每个模拟布长都会改变高频信息内容的数量
→ SCP 低频信息内容，命令型
→ TCP/UDP/SHM 通信方式包括网络和共享内存