车企基本背景build
1.车企自研自动驾驶系统成为趋势。
2.基于MBD的开发流程已经不能满足自动驾驶系统开发需求，需引入数据驱动的端到端的开发流程。
3.开发工具链的效率决定了整个系统开发的效率，工具链需要和pipeline数据流结合，当前工具链普遍存在割裂和“数据孤岛”现象。
4.数据处理是数据驱动的基石：智能化数据采集势在必行，数据标注的外包化和对高质低价的追求也趋于明显。
5.自动驾驶仿真是开发的加速器：要求仿真软件既要懂仿真，也要懂汽车；场景库被车企视为核心竞争力；仿真评价面临多样化和定制化的趋势；OpenX 得到了业内的普遍认可，仿真软件也逐渐标准化。
6.高精地图是工具链不可或缺的一环，合规性、复杂场景精度和动态更新仍是行业痛点。
7.自动驾驶上云是大趋势。
8.自动驾驶开发工具链的发展趋势是：高效（端到端）、开放和灵活合作。
现状：传统的汽车软件控制逻辑，包括L2的一些相对简单的ADAS功能，使用MBD+X在环的开发流程还可以满足需求，但是随着自动驾驶算法功能越来越复杂，以前基于MBD的开发流程已经显得有点力不从心了。
为了更有效率地开发自动驾驶系统，业内专家们找到了适用于基于深度学习的自动驾驶开发流程——也就是数据驱动的端到端的开发流程。
工具链：
上述环节中所使用的工具和平台（包括但不限于数据采集、处理、标注工具、模型训练平台、仿真平台、OTA工具和一些其他环节的开发工具），被称作“工具链”。工具链的效率决定了整个系统开发的效率。
以数据处理为例，单数据类型就多种多样，包括摄像头数据、毫米波雷达数据、激光雷达点云数据，需要先对这些数据进行去噪，也就是所谓的“数据清洗”。以图片为例，数据处理需要先把图片的地理位置信息等擦除，把人脸、车牌等敏感信息去除，再统一格式，这样才算处理完成。
数据处理完成后，下一步便开始数据标注。标注的类型大致可分为2D、3D目标物标注、联合标注、车道线标注和语义分割等，还要涉及到具体标注规范和标注质检流程，整个流程异常繁琐。
数据驱动）pipeline已经可以完整跑通，积累也比较多，为了进一步提升效率，他们也做了很多工具链的定制开发。
“工具链不是我们的竞争力，需求定义、系统集成和功能测试才是我们的竞争力”，某车企智能驾驶负责人说
数据相关的工具链，包括了数据采集、数据上传、数据清洗、数据标注等环节。
先说数据采集。
行业里有一些开源的数据集，可以用做基础算法训练，目前最常用的数据集有KITTI、nuScenes等，不过这些数据还是多半来自海外的公开测试集，中国本土特色的数据集，还是比较少的。
华为八爪鱼对场景进行智能化打标签
找到有价值的数据之后，就需要进行数据清洗和数据标注。
在以深度学习为主的感知模型中，主流的深度学习训练方法还是监督学习，用这种方法训练，需要向模型“喂养”海量有“真值（Ground Truth）”的数据。
那这些“真值”数据从哪来？人工标注出来的。
作为自动驾驶工具链中非常核心的一环，仿真系统主要由场景库、仿真平台和评测体系三部分组成，仿真系统的效率高低直接影响到了整个开发链路的效率
ASAM 发布的仿真领域标准 OpenX 得到了众多车企、供应商和科研机构的认可，目前大多数仿真软件也都开始支持OpenX标准。ASAM正在制定更多的标准。
上云，更是建立自动驾驶数据闭环开发链路的必要选项。以“华为八爪鱼”对Corner Case的优化链路为例，在车端发生人工接管后，“华为八爪鱼”自动触发并在线反馈至云端，云端进行跟踪回放并诊断确定原因，如果确认是自车责任（自身系统问题），那么数据采集服务会将接管前后的有效数据上传至云端，并进入数据处理流程。
如果是感知环节需要优化，则进行数据采集、清洗、标注，处理完后在云端进行感知模块的训练；如果需要优化规划控制模块，则将该问题场景一键转化为仿真场景库。优化后的算法系统要并行仿真测试和回归测试，若仿真评测也通过，则云端启动OTA推送服务，对车端系统进行升级，如此一个完整的闭环便完成了。
云的安全性
以数据为中心，是相对于传统的“以消息为中心”而言的，其本质区别在于通信中间件知道它存储了什么数据、并能控制如何共享这些数据。
对传统的以消息为中心的中间件，程序员必须为发送消息编写代码，而对以数据为中心的中间件，程序员只需为如何及何时共享数据编写代码，然后就可以直接共享数据值。
通信中间件包括点到点、消息队列和发布/订阅三种工作模式，SOME/IP和DDS都采用了发布/订阅模式。
点到点模式具有很强的时间和空间耦合性，使得通信灵活性受到很大限制；消息队列模式通过一个消息队列来传递消息，解决了通信双方时间和空间松耦合的问题，但不能实现消息消费者通信的异步，并且还存在服务器瓶颈和单点失效的问题，可靠性得不到保障；发布/订阅模型中，发布者和订阅者通过主题相关联，双方不必知道对方在何处，也不必同时在线，实现了通信双方在时间、空间和数据通信上的多维松耦合。
根据源代码是否开放，通信中间件可简单地分为闭源和开源两种。闭源的通信中间件主要有Vector公司的SOME/IP、RTI公司的DDS等;开源的通信中间件主要有OPEN DDS、FAST DDS、Cyclone DDS等。
现阶段，SOME/IP和DDS是自动驾驶上用得最多的两类通信中间件。上文已经提到，两者的共同点主要有：都是面向服务的通信协议；都采用了“以数据为中心”的发布和订阅模式。那么，两者的主要区别又有哪些呢？
01
应用场景不同
SOME/IP是专为汽车领域而生的，它针对汽车领域的需求，定义了一套通信标准，并且，在汽车领域深耕的时间比较长；DDS是一个工业级别的强实时的通信标准，它对场景的适应性比较强，但在用于汽车/自动驾驶领域时需要做专门的裁剪。
02
灵活性、可伸缩性不同
相较于SOME/IP，DDS引入了大量的标准内置特性，例如基于内容和时间的过滤、与传输无关的可靠性、持久性、存活性、延迟/截至时间监视、可扩展类型等。当AUTOSAR AP与DDS一起构建一个通信框架时，该框架不仅可以与现有ara::com api及应用程序兼容，而且在可靠性、性能、灵活性和可伸缩性等方面，都可以提供重要的好处。
03
订阅方和发布方是否强耦合
在SOME/IP中，在正常数据传输前，client需要与server建立网络连接并询问server是否提供所需服务，在这个层面上，节点间仍然具有一定耦合性。服务的订阅方需要知道server在哪里，服务的发布方需要告知server提供哪种服务，例如写一个程序，需要用到传感器数据，这个程序要去询问server是否可以提供传感器数据；而在DDS标准下，每个订阅方或发布方只需要在自己的程序里面订阅或发布传感器数据就行了，不需要关心任何连接。可以理解为，在DDS中，服务订阅方和发布方的解耦更加彻底，需要什么数据，写一行代码就行了，不需要再去做绑定。
04
服务策略不同
较好的QoS（服务策略）是DDS标准相比于SOME/IP最重要的特征。
SOME/IP只有一个QoS，即可靠性的定义；而RTI DDS和开源DDS里面分别有50多个和20多个QoS，这些QoS基本上能涵盖绝大多数可以预见到的智能驾驶场景。
QoS具体是个什么东西，它有何用途？华玉通软联合创始人兼技术副总裁毕晓鹏举了几个例子：
（1）通信中的传输优先级、数据可靠性、资源限制、时间过滤等，都需要在QoS里面设置。
（2）数据传输过程中可能会出现丢帧现象，也就是说，不是每一帧都能达到接收端。针对这种现象，我们需要考虑场景需求。如果是关键信息（报警指令），我们需要发送方重发，如果是非关键信息（高频传感数据），系统就不必把丢失的部分都找回来，这些都只需配置QoS的reliability就可以了。
（3）在感知系统有冗余的情况下，一旦一个传感器宕机，就需要第二个传感器补上来。针对这种情况，QoS可以配置一个ownership，对两个传感器的数据做优先级高低的区分。配置之后也不需要重新编译，因为它是动态部署的，配置完之后就可以按照最新配置运行，去完成不同节点之间的发布订阅。
（4）.DDS的解耦模式允许某一主题发布方在没有订阅方的情况下仍然发布数据，但后加入的订阅方也许对这一主题的历史记录感兴趣。例如，新节点上线后需要去监控其他节点的运行情况，这些节点也许每隔较长一段时间才发布一个信息说自己“运行正常”，那么这个新上线的节点就需要去了解其他节点发布的历史信息以确定其运行状态，也就是它希望能收到其上线之前其他节点发布的历史数据。这种情况，只需要简单配置QoS就可以实现，新节点可以获知上线之前多长时间、多长节点的数据流，去关注它的历史数据等等。
（5）负责监控的新节点上线后，需要去监控其他节点的运行情况。通常，这些节点每个小时发布一个信息说自己“运行正常”，但也有可能这个“运行正常”的节点先发布了，过半小时之后监控节点才发布，那这时候，监控节点是否还能收到其上线之前其他节点发布的数据？这种情况，也是需要通过QoS去配置的，QoS可以去配置订阅新节点上线之前多长时间、多长节点的数据流，去关注它的历史数据等等。
进一步说，QoS能够提供实时系统所要求的性能、可预测性和资源可控性，并且能够保证发布/订阅模型的模块性、可量测性和鲁棒性等。因此，DDS能够满足非常复杂、非常灵活的数据流要求。
相比之下，SOME/IP只解决了发布订阅问题，但由于没有这些QoS，结果便是，很多本来可用自动配置服务策略来实现的功能，都需要通过软件开发人员写代码才能实现，这会浪费大量的时间。
此外，由于没有QoS，SOME/IP在数据量大的时候，无法解决丢包的问题，进而造成指令被卡在某个地方发不出去，然后，整个系统就无法正常运作了。
05
应用场景不同
从应用场景的角度来看，SOME/IP比较偏向于车载网络，且只能在基于网络层为IP类型的网络环境中使用，而DDS在传输方式上没有特别的限制，对基于非IP类型的网络，如共享内存、跨核通讯、PCI-e等网络类型都可以支持。而且，DDS也有完备性的车联网解决方案，其独有的DDS Security，DDS Web功能可为用户提供车-云-移动端一站式的解决方案。
在商业落地中，DDS和SOME/IP是直接竞争关系。据一位RIT方面的代表透露,对用户而言，DDS和SOME/IP是“二选一”。
参考https://blog.csdn.net/jiuzhang_0402/article/details/123103006
https://blog.csdn.net/AgingMoon/article/details/104166715
