NDS、KIWI 和 ADASIS 是智能驾驶与高精度地图领域中三个关键的技术标准或协议,分别服务于导航数据格式标准化、嵌入式地图数据存储和高级驾驶辅助系统(ADAS)与地图之间的信息交互。下面分别对它们进行简明扼要的解释,并说明三者之间的关系:
一、NDS(Navigation Data Standard)
全称:
Navigation Data Standard(导航数据标准)
背景与用途:
- 由NDS 协会(Navigation Data Standard Association)于2009年发起,成员包括宝马、大众、HERE、四维图新等。
- 目标是建立一种统一、开放、可互操作的车载导航数据格式,使不同地图供应商的数据能被不同车厂的导航系统使用。
- 支持离线/在线混合使用、增量更新、安全加密,适用于 L2~L4 级自动驾驶。
特点:
- 模块化结构(如 Base Map、Routing、POI、Lane 等子数据库)
- 支持高精地图(HD Map)属性
- NDS.Live 是其新一代演进版本,支持云-边-端协同分发
✅ 应用场景:车载导航系统、高精地图分发、OTA 地图更新
二、KIWI 格式
全称:
无官方全称,通常指KIWI-W Consortium 制定的汽车导航电子地图数据格式
背景与用途:
- 由日本主导开发,早期用于嵌入式车载导航系统
- 是一种紧凑型二进制地图数据格式,强调高效存储与快速读取
- 主要面向资源受限的嵌入式设备(如早期车载主机)
特点:
- 数据结构高度优化,适合低内存环境
- 支持道路网络、POI、地名等基本导航要素
- 虽不如 NDS 开放和模块化,但在日本及部分亚洲市场仍有应用
✅ 应用场景:传统车载导航、低成本嵌入式系统
三、ADASIS(Advanced Driver Assistance Systems Interface Specification)
全称:
ADAS Interface Specification
背景与用途:
- 由ADASIS Forum制定,旨在让ADAS 功能(如自适应巡航 ACC、车道保持 LKA)能提前“预知”前方道路特征(坡度、曲率、限速、车道数等)
- 实现地图与车辆控制系统的实时协同
核心功能:
- 将地图中的道路属性(如曲率、坡度、车道拓扑)以“eHorizon”(电子地平线)形式传递给 ADAS 控制器
- 支持预测性驾驶(Predictive Driving),提升安全性与能效
版本演进:
- ADASIS v2:基于静态地图,单向通信
- ADASIS v3:支持动态数据、双向通信、云连接,与 NDS.Live 深度集成
✅ 应用场景:ACC、预见性能量管理(PEM)、弯道预警、高精定位辅助
四、三者关系总结
| 技术 | 角色 | 与其他技术的关系 |
|---|---|---|
| NDS | 地图数据的标准化容器 | 可作为 ADASIS 的数据源;NDS.Live 支持 ADASIS v3 |
| KIWI | 轻量级地图存储格式 | 功能上类似 NDS,但封闭、老旧,逐渐被 NDS 取代 |
| ADASIS | 地图与 ADAS 控制器的桥梁 | 依赖 NDS 或 KIWI 提供的道路属性数据 |
🔄 典型工作流:
高精地图 → 编译为 NDS 格式 → 通过 ADASIS 协议生成 eHorizon → 发送给 ADAS ECU → 实现预测性控制
补充说明(2026年现状)
- NDS 已成为国际主流,尤其在欧洲和中国,广泛用于智能座舱与自动驾驶。
- KIWI 逐步退出主流市场,仅在部分日系老车型或特定嵌入式项目中保留。
- ADASIS v3 + NDS.Live是当前 L2+/L3 自动驾驶系统的黄金组合,支持 OTA 动态更新与云协同。
2.NDS.Live 架构
NDS.Live 是由NavInfo(四维图新)推出的新一代高精地图数据服务平台,基于NDS(Navigation Data Standard,导航数据标准)架构进行扩展和优化,旨在支持智能网联汽车、高级别自动驾驶(L3+)以及动态地图更新等场景。其核心目标是实现“车-云-图”一体化协同,提供高效、安全、可扩展的高精地图服务。
一、NDS.Live 的整体架构
NDS.Live 架构可以分为云端(Cloud)、车端(Vehicle)和通信通道(OTA/5G/V2X)三大部分:
+------------------+ +---------------------+ +------------------+ | 云端平台 |<----->| 通信通道(OTA等) |<----->| 车端系统 | | (NDS.Live Cloud) | | (Secure Channel) | | (NDS.Live Onboard)| +------------------+ +---------------------+ +------------------+1. 云端平台(NDS.Live Cloud)
- 高精地图数据湖:集中存储静态高精地图(如车道线、交通标志、道路拓扑)与动态数据(如交通事件、施工、天气)。
- 增量更新引擎:基于 NDS 标准的Delta Update(Δ更新)技术,仅下发变化部分,大幅减少带宽和存储开销。
- 版本管理与分发系统:支持多版本并行、区域灰度发布、回滚机制。
- 安全认证中心:提供 TLS/SSL、数字签名、证书管理,确保数据完整性与防篡改。
- AI 数据处理流水线:融合众包数据、传感器数据、第三方数据,通过 AI 算法自动质检与融合。
2. 车端系统(NDS.Live Onboard)
- NDS 兼容数据库:符合 NDS 4.0+ 规范,支持模块化数据组织(如 Base Map、Routing、Lane、ADAS 等 Layer)。
- 本地缓存与热更新:支持后台静默下载、差分合并、无缝切换。
- 定位与感知融合模块:将高精地图与 GNSS、IMU、摄像头、激光雷达数据融合,提升定位精度(厘米级)。
- 功能安全(ISO 26262 ASIL-B):满足车规级安全要求。
3. 通信通道
- OTA(Over-The-Air):通过 4G/5G 实现地图增量更新。
- V2X(C-V2X):支持实时动态信息(如红绿灯相位、紧急车辆预警)下发。
- 边缘计算节点(MEC):在靠近车辆的边缘节点缓存热点区域地图,降低延迟。
二、关键技术特性
| 特性 | 说明 |
|---|---|
| 增量更新(Delta Update) | 基于 NDS 的 ChangeSet 机制,只传输变化的数据块(Tile-Level 或 Feature-Level)。 |
| 按需下载(On-Demand) | 车辆根据当前位置和行驶路线,预加载前方 100~200km 区域的地图数据。 |
| 多源数据融合 | 融合专业采集车、众包车辆、政府开放数据、第三方服务商数据。 |
| 动态图层(Dynamic Layer) | 支持交通流、事故、施工、临时限速等实时信息叠加到静态高精地图上。 |
| 跨平台兼容 | 支持 AUTOSAR AP/CP、Linux、QNX 等车载操作系统。 |
三、与传统 NDS 的区别
| 维度 | 传统 NDS | NDS.Live |
|---|---|---|
| 更新频率 | 季度/月级 | 分钟级(动态数据)+ 周级(静态增量) |
| 数据粒度 | 整包或大区域更新 | Tile 级(如 1km×1km)甚至要素级更新 |
| 交互模式 | 单向下发 | 车云双向协同(车辆可上报异常数据) |
| 架构理念 | 静态地图库 | “活地图”(Living Map)服务化平台 |
四、典型应用场景
- 城市 NOA(Navigate on Autopilot):依赖高鲜度车道级地图。
- 自动泊车(AVP):需要停车场高精地图的实时更新。
- V2X 协同感知:将路侧感知结果通过 NDS.Live 动态图层广播给车辆。
- 仿真测试:利用 NDS.Live 生成高保真数字孪生场景。
五、生态与标准化
- 兼容NDS 4.0+标准,并参与 NDS 协会制定Live Map相关规范。
- 与AUTOSAR、COVESA、OpenDrive等组织对接。
- 支持Open Navigation Data(OND)开放格式探索。
3.ADASIS v3 协议细节
ADASIS v3(Advanced Driver Assistance Systems Interface Specification version 3)协议是用于高级驾驶辅助系统(ADAS)与数字地图数据源之间通信的标准化接口规范。其核心目标是为ADAS功能提供前瞻性的道路信息(即“地平线”数据),从而提升车辆对前方道路环境的理解能力,支持如自适应巡航控制(ACC)、车道保持辅助(LKA)、预测性能量管理(PHEV/BEV)等智能驾驶功能。
一、ADASIS v3 的核心目标
标准化地图与ADAS之间的接口
确保不同供应商的地图数据库、导航模块与ADAS控制器之间可互操作。提供预测性道路特征信息(Horizon Data)
包括:道路曲率、坡度、车道数、限速、交通标志、交叉口拓扑等。支持动态与静态数据融合
不仅传输静态高精地图信息,还可整合实时交通、施工区、临时限速等动态事件。
二、关键特性(相较于 V2)
| 特性 | ADASIS V2 | ADASIS V3 |
|---|---|---|
| 数据类型 | 主要静态地图数据 | 静态 + 动态 + 事件驱动数据 |
| 通信效率 | 固定结构,带宽占用高 | 更紧凑的编码(如 Protocol Buffers) |
| 地平线表示 | 简单路径链表 | 支持多路径分支(如匝道、变道选择) |
| 实时性 | 周期性更新 | 支持事件触发 + 动态采样率 |
| 扩展性 | 有限 | 模块化设计,支持 Profile 扩展 |
| 安全性 | 无明确安全机制 | 可集成 AUTOSAR SecOC 或 TLS(尤其在 Ethernet 传输中) |
三、ADASIS v3 协议架构
1.角色定义
- Provider(地图/导航模块):生成并发送地平线数据。
- Client(ADAS ECU):消费地平线数据,用于控制决策。
2.数据模型核心:Profile
- Profile是 ADASIS v3 中的核心数据单元,描述从当前位置向前延伸的一段道路的属性序列。
- 每个 Profile 包含:
- 距离偏移(沿路径)
- 曲率(Curvature)
- 坡度(Gradient)
- 车道信息(Lane count, width)
- 限速(Speed limit)
- 交通规则(如禁止超车)
- 事件标记(如施工区起点)
3.多路径支持(Multi-path Horizon)
- 在分叉路口(如高速出口),ADASIS v3 可同时提供主路和匝道两条路径的 Profile。
- Client 根据当前行驶意图(由路径规划模块提供)选择使用哪条路径。
四、通信机制
- 传输层:支持 CAN FD、Ethernet(SOME/IP)、FlexRay 等车载网络。
- 消息类型:
HorizonUpdate:主数据流HorizonRequest:Client 可请求特定范围或精度的数据EventNotification:突发性事件(如前方事故)触发推送
- 编码格式:通常采用Protocol Buffers(.proto 定义)以提高效率和跨平台兼容性。
五、典型应用场景
| 应用 | 依赖的 ADASIS v3 数据 |
|---|---|
| 自适应巡航(ACC) | 前方坡度、曲率 → 调整车速 |
| 预测性能量管理(PEM) | 坡度+限速 → 优化电机/制动能量回收 |
| 车道居中控制(LCC) | 车道几何、曲率变化率 |
| 自动变道 | 多路径 Horizon + 目标车道属性 |
| 弯道速度预警 | 曲率半径 + 湿滑路面标志(结合动态数据) |
六、最新版本:ADASIS v3.1.0(RC1)
- 发布状态:截至 2025 年底,v3.1.0.RC1 为候选发布版。
- 新增内容:
- 对高精地图(HD Map)属性的扩展支持(如 lanelet 模型映射)
- 增强动态事件(Dynamic Events)的语义描述
- 支持时间戳同步与数据新鲜度标记
- 提供C 语言参考实现和AUTOSAR 集成指南
注:官方协议文档由 ADASIS Consortium 维护,CSDN 等平台有中文翻译和实战解析资源。
七、优化挑战与对策(来自 2026 年最新实践)
如你知识库中提到的“地平线数据更新延迟”问题,主流优化策略包括:
- 动态采样间隔:根据驾驶场景(如急弯、变道)自动提高更新频率(最高达 50 Hz)。
- 优先级调度:在 AUTOSAR COM 层为 Horizon 数据分配高优先级 PDU。
- 预加载机制:结合车辆动力学模型,提前缓存下一路径段数据。
- I/O 优化:使用内存映射地图数据库减少查询延迟。
八、参考资料建议
- 官方:ADASIS v3 Protocol Reference 3.1.0.RC1
- 中文资源:
- CSDN《ADASIS v3协议含中文翻译资源下载》
- 《ADASIS V2/V3协议规范及参考手册深度解析》(2024年12月更新)
- 实战:《ADASIS v3地平线数据更新延迟如何优化?》(2026年1月)
4.KIWI 编码原理
“KIWI 编码”并不是一个在主流计算机科学、信息论或密码学中广泛认可的标准术语。截至目前(2026年),在公开的学术文献、工业标准(如 ISO、IEEE、RFC)或主流编程/通信协议中,并没有一个被普遍称为 “KIWI 编码” 的通用编码方案。
不过,根据上下文,“KIWI 编码”可能指以下几种情况之一:
1.特定系统或项目中的自定义编码
某些公司、研究团队或开源项目可能会将其内部使用的数据编码方式命名为 “KIWI 编码”。例如:
- 一种用于压缩传感器数据的轻量级编码;
- 一种专用于嵌入式设备通信的二进制格式;
- 某个区块链项目中的交易序列化方法。
在这种情况下,“KIWI 编码”的原理需参考其具体文档或源代码。
2.与 Kiwi 工具链相关的编码
“Kiwi” 是 SUSE 开发的一个用于构建 Linux 系统镜像的工具(KIWI - KIckstart for WIzards)。但该工具本身并不定义一种“编码”,而是使用标准的文件系统、压缩和打包格式(如 squashfs、gzip、tar 等)。因此,这里的“编码”更可能是镜像构建过程中的数据表示方式,而非独立的编码理论。
3.误写或混淆
有可能是以下术语的误写或混淆:
- Base64 编码:常用于将二进制数据转为文本;
- UTF-8 / UTF-16:字符编码;
- Kiwifruit 编码(极罕见):某些实验性编码的昵称;
- Quoted-Printable或MIME 编码:邮件中常用。
4.教育或竞赛中的虚构编码
在编程竞赛、CTF(夺旗赛)或教学示例中,有时会设计名为 “KIWI” 的简单替换编码,例如:
- 将字母按 Kiwi 水果相关单词映射(如 K→1, I→2, W→3);
- 使用 “KIWI” 作为密钥的 Vigenère 密码;
- 自定义 BaseXX 变种。
这类编码通常不具备通用性,仅用于特定题目。
建议
如果您是在某个具体场景(如某款软件、论文、CTF 题目、API 文档)中看到 “KIWI 编码”,请提供更多信息,例如:
- 上下文描述;
- 示例输入/输出;
- 相关技术栈(如物联网、区块链、图像处理等)。
这样可以更准确地解释其原理。