ADASISv3简述，自动驾驶怎么进行地图数据传输？

1. 什么是 ADASIS v3h3>

ADASIS（Advanced Driver Assistance Systems Interface Specification）直译过来就是 ADAS 接口规格，它要负责的东西其实很简单，就是为自动驾驶车辆提供前方道路交通相关的数据，这些数据被抽象成一个标准化的概念：ADAS Horizon。

数据从地图应用来，要传输到车内的 ADAS 软件应用中。我们常见的互联 传输协议是 Http，内容封装协一般是 json、protocol buffer、xml 等等。但汽车中的数据通信不同于互联 ，一般走 CAN 通信，类似于 json，ADASIS v3 就定义了如何在汽车这个大平台下进行数据传输。

简而言之，ADASIS v3 就是一个用于地图数据传输的通信协议。

2. 为什么需要 ADASISh3>

做自动驾驶的公司很多，有主机厂、零部件供应商、图商等等。

如果是人驾驶车辆，用基本的导航地图就好了，精度大概在 10 米左右。

从 ADAS 开始，汽车会在某些时候自己进行驾驶，这对于道路感知的要求比较高，ADAS 地图正好可以解决这个问题，ADAS 地图精度大概在 1 米左右。

而未来高度自动驾驶的到来，ADAS 地图的精度就不够用了，因此图商就发力做高精度地图，精度可以达到分米级，配合高精度定位，定位精度能够到厘米级，这种精度能够满足汽车在道路上自动驾驶。

可有一个问题就是从普通的导航地图，再到 ADAS 地图，再到高精度地图，地图的信息是越来越丰富，但每公里的数据量也越来越大。

而汽车上的软件一般跑在 ECU 当中，或者域控制器当中，即使是 Tesla 安置超强的计算平台 FSD,针对这么多的数据量传输也是个头痛的事情。

所以，针对地图与汽车软件之间数据传输就需要好好规划，这需要一套高效、标准的通信协议。

ADASIS 就是这样的协议，它并不是唯一的协议，但它标准、规范，比较多的主机厂参与。

再强调一次，它标准、规范，这说明很多人用。

假设每个主机厂都有一套数据协议，每个图商也有自己的地图传输协议，那这就属于耦合过深，不同车型开发时，将要花费许多额外的时间去做适配，而时间就是金钱。

ADASIS v1 在 2005 年发布，但没有人用。

ADASIS v2 改进了很多，基于 CAN 通信。

ADASIS v3 面向车载以太 通信，带宽更大，所以能够支持高度自动驾驶。

3. ADASIS 基础概念

3.1 基本要素

地图信息很多，对于地图的表示也可以按照功能要求从简单到复杂。

ADASIS 倾向于尽可能简单。

如上图所示，你没有必要把每条街道推送给汽车软件，因为很多不需要，所以最简单也是可行的就是尽量推送少但有用的信息。

什么是少但有用的信息呢p>

ADASIS v3 给出答案是：

1. 前方道路
2. 可能的道路

于是，Path 的概念就应运而生，可以看看上图那根红线。

Path 精简了地图数据，它只关注汽车可能行驶的路线。

3.2 Path

世上的路千万条，但你每次驾驶时都是走一条确定的路线，这条路线就叫做 Path，它是一种驾驶的可能性。

有了 Path 就可以将路 压缩成线性地图表示。

说是线性，我们可以将 path 看作是一条线，线上挂着许多类别的铃铛、星星等等。

汽车要向前方行驶，Path 信息可以简略表达，也可以复杂点表达。

3.2.1 Simple Path Representation

Simple Path 代表简略表达路 的策略。

如果告诉汽车，要去上图中 Link235 处，那么，有 2 种路由：

• 200 -> 210 -> 230 -> 215 -> 235
• 200 -> 205 -> 220 -> 235

把每种可能的路径用 Path 表示出来，而不是把所有的 Link 展示出来就是 Simple Path 的思想，会产生如下结果。

ADAS Horizon 构造器会将汽车最有可能继续行驶的 Path 作为 root path，一般也是 MPP(Most Prefere Path)，而 root-path 下的第一层 sub-path 会作为备选路径。

比如，上图中汽车向前，大概率会沿着 Path2 的方向，但 Path4、Path1、Path3 也是有可能的。

Path 是 ADAS Horizon 最主要的实体，像道路上的路标、十字路口、车道几何信息什么的可以当作 Path 当中的 Attributes。

所以，AHP 首要任务是要传输 Path 信息，AHR 首要任务是要根据 Path 进行路径重建。

以 Step 为例说明，我们都知道在高速上限速是按区间的。

另外，需要注意的是 Position 中的时间戳是全局的，这代表 Provider 和 Reconstructor 的时间是同步没有偏差的，有这个前提才能进行时间对齐。

3.4.1 Preferred Path

Position 中还有一个重要的信息就是 Preferred Path，它代表倾向性的驾驶路径，可以用来描述 MPP(Most Preferred Path)，ADAS Horizon 假设汽车会最大可能沿着这条路径继续下去。

基础的 ADASIS v3 由一个 AHP 和多个 AHR 组成，它们分别代表内容提供者和内容重构者角色，中间进行数据通信。

通信可能走车内 络，如 CAN 或者是车载以太 。

也可能 AHP 和 AHR 就在同一台计算平台上。

这代表分布式和集中式两种架构。

把话题拉回来，通信要传输数据，如何保证高效又不出错呢需要建立一套同步机制。

4.1 同步机制

ADASIS v3 的同步机制有 2 个核心概念：

• Path Control
• Profile Control

一个负责建立骨架，一个负责向里面填充血肉。

4.1.1 路径同步

其实非常简单，和自动驾驶目标跟踪航迹管理差不多。

ADASIS v3 中 Path 有自己的生命周期，Path 上的 data 也有自己的生命周期。

当车辆在一条 path 上的位置相对 profile control offset 超过 trailing length 时，offset 前面的 data 就可以被删除掉了。也就是蓝色部分。绿色部分是要保留的内容。

当然，path1 继续保留，直到有明确机制它要被删除，这就是 path 和 path-data 生命周期分离的机制。

Profile 里面的数据同步也离不开这 3 个步骤：

• 创建
• 更新
• 删除

4.1.3 Value Update

每一个 Profile 有一个 ID 编 ，这让 AHP 和 AHR 之间可以有数值更新的基础。

所以，可以形成一个主 AHP,一个辅助性的 AHP.

5.2 上游融合

这个算前融合。

Provider 这一侧提前把信息进行融合，AHR 端直接做应用算法处理了。

因为前融合可以有效节省通信带宽，所以我个人而言倾向于这一种。

当然，具体使用哪种要结合实际更复杂的情况。

总结

因为篇幅有限，没有办法完完整整介绍所有的内容，实际开发如果要参考 ADASIS v3 需要自己仔细阅读文档及参考文档。

当然，前面已经讲过 ADASIS v3 只是地图数据通信协议的一种，你大可根据它的优缺点建立自己的一套体系，但我还是倾向于遵从它，因为汽车行业是个讲标准的行业。