近年来，随着智能手机和计算机的标准化硬件逐渐接近物理极限，推动了IT行业的产品创新由硬件升级主导转向了软件开发和迭代。汽车，正由单一的地面移动工具转变为智能移动空间，由机械产品转化为“机械产品基础上的电子信息高科技产品”。

随着智能汽车技术的飞速发展，国内各个主机厂为了提升其在智能驾驶、智能座舱、智能服务等领域的竞争力，在逐步增加更多智能传感器和高算力芯片的同时，软件复杂度也在不断提升，进而带来了更多的功能和服务。这些传感器和软件产生的海量数据已远超GB32960和传统车联网采集的数据覆盖范围，传统车联网采集的数据已远远不能满足主机厂数据驱动的需求。

数据驱动能力是主机厂赢得市场竞争的关键能力

数据驱动产品的全生命周期迭代是车企的核心目标，如数据驱动研发（功能、性能开发）、数据驱动产品量产迭代（功能迭代/性能迭代/产品运维）、数据驱动服务（后市场服务、保险、二手车评估），而量产的高精度高质量数据才能充分的赋能创新业务场景。

当下，我们正处在从功能汽车到智能汽车转变的关键时期，那些主动拥抱数据时代，并积极投入资源、整合新技术的车企，在效率、成本、用户体验、产品迭代、流程与体系等方面将与保守者逐步拉开差距。

智能汽车数据价值

想要实现高精度、高质量数采，车端数据库是必然趋势

问题1-数据质量问题：数据采集链路对车端MCU–> 域控制器 -> 网关 -> TBOX ->(4/5G) -> 云端(TSP/云平台)之间的通讯带宽，以及CAN、CANFD、LIN、SOME IP等协议都提出了更高的要求。尤其是车云之间的4/5G无线通讯，受信号稳定性影响很大，在持续大量数据传输过程中，容易造成丢包、粘包、数值错乱等问题。

问题2-成本：数据精度的增加必然导致数据量的膨胀，致使云端的存储成本、计算成本、车云链路的流量传输成本都大幅增加，如何将成本控制在可接受范围内，是解决高精度、高质量数采的关键。

问题3-多种协议如何接入：车端存在多种信号协议（CAN、SOME/IP等），如何实现融合上传，云端能够统一方便的解析一直是个难题。

问题4-资源受限：汽车上的硬件计算资源是非常宝贵的，如果数采需要占用大量计算资源，或者资源占用幅度波动很大，都是无法接受的。

问题5-灵活筛选：车端信号数量非常多，而且一般为持续采集，而真正有价值的数据都集中在某时间段、某些信号中，是否有可能实现在车端只采集有价值的数据呢？

问题6-存储器刷写：量产车的硬件无法频繁更换，要支撑10年+的正常使用，这就需要在采集海量数据的同时，不能频繁刷写硬盘，从而降低硬盘使用寿命。

问题7-SOA架构体系中的应用如何灵活查询数据：在新的SOA架构中，各种应用都以服务的形式搭建，数据要实现灵活的被不同的应用获取，如果没有车端数据库，看似是个无解的难题。

既然千倍的数据量增长不可避免，那么是否存在一种解决方案既能保证数据质量和精度，又能避免过高的传输、存储、计算成本呢？

答案是肯定的，既然智能汽车会成为移动的超级计算机，采用边缘计算把计算前置到车端，就是最佳的解决方案。而这里面最关键的就是需要一个针对车联网场景的数据库。这个数据库需具备以下特点：

- 能够针对车端的几千个高频率信号数据进行高性能存储

- 能够对车辆数据进行高倍率压缩

- 能够自动排序，减少云端排序压力

- 能够自动切包，减少网络信号差等问题造成的丢包

- 不能占用过多的车端算力

- 对CPU消耗平稳，以保证整个系统的安全运行

- 高容错性

- 支持校验、补传机制，保障数据质量

- 支持在SOA架构下车端对数据的按需高效查询

智协慧同EXCEEDDATA解决方案提供的vData边缘数据库就是这样一款专门为车联网场景定制的车端信号数据库。

vData车端数据库就像MySQL、Oracle一样，是基础的数据管理方式

vData是运行在车端嵌入式环境的时序数据库，其能力就是将车端产生的各种信号数据按照时间顺序，有序、合理的以一种高压缩态存储，压缩倍率能够达到100~300倍。vData针对车端信号采集场景具有以下特点：

支持高精度采集

vData能够支持10ms精度以上，上万个信号数据的写入，同时能将车端的不同协议按照统一的规则排序以列进行存储。

支持高质量采集

EXD vData信号数据库在车端MPU最接近报文的源头接入存储，车端生成数据块的CRC，云端校验数据块的CRC，是最短的链路也是最可靠的数据存储。高质量的车端数据包将大幅提升整体车联网数据质量，传统车联网平台在云端用复杂ETL试图修改错误数据的难题也将迎刃而解。

支持边缘计算

可以通过在边缘计算实现对数据的查询和处理，并筛选需要的数据进行上传，使传输的数据都是有价值的数据。一方面控制了数据量，优化了成本，另一方面还大幅减少云端数据处理的工作量。

极大节省云端计算和存储成本，提高使用时效

传统车联网的云端数据排序工作非常繁重，需要单独的计算集群（庞大的硬件成本），把每天的车辆数据迁移、解压缩、在数据规模膨胀百倍以后，再对膨胀后的数据集做排序整理，整理后直接存CSV的话可以直接使用，但存储代价很高，所以大部分还要重新再压缩后存对象存储，使用起来很不方便。

以上工作造成了数据的可用时间为T+1，无法满足某些业务的高时效性需求。

使用EXD vData，云端不再需要计算集群用于排序，所有解压、重排序、再压缩等工作都可以省略，而且在云端以高压缩态直接存储，在节省存储成本的同时，使用便利性跟CSV相差无几。

对原有技术架构改造成本极低，数据支持随用随解，直接集成SDK即可，支持多种类SDK：JAVA、Python、Javascript、Hadoop、Spark、Hive、Jupyter、Presto等。

数据使用时效从T+1提高到T+0，效率大幅提升。

信号以列存储

信号数据因为物理设计有天然的变化规律，在高质量采集下这些信号数值的详细变化过程可以被精准的识别，而且有数千个的时候以单信号列来存储的格式将比传统以报文条的行存储格式有更高的压缩率。我们在EXD vData里以信号列存储，支持数千到万个信号列以内存缓存 + 按需落盘存储的模式延长车载件的刷写寿命。

行存储和列存储的形态示意图

以流压缩算法平摊CPU消耗

车端对于服务使用CPU的稳定性非常关注。一是边缘资源有限， 二是全局压缩算法容易造成压缩时CPU峰值飙高，这时候如果其他服务也出现CPU使用飙高造成超过警戒线，对于整个E/E架构的服务优先级管理来讲很难处理。

EXD vData对每列里的信号时间和数值做了针对流式数据的4层无损压缩算法，使用二进制位运算符等低CPU的高效比较计算和BIT ENCODING,实现以100Hz接入频率下仍然保持10%的稳定CPU占用率。

数据包按时间分块

车端数据上传需要满足一定的实时性要求、同时要兼容考虑周期太长、上传数据包过大、上传容易导致失败重传，周期太频繁服务器压力大、压缩率低、流量高等复杂现实问题，所以数据包的上传会是相对不频繁也不长的周期 （30秒到分钟级别）。

但到了云端分析数据的时候业务部门需要应用较长时段（小时到周）的车辆数据，这时候如果按条读取解析再合并（条数量大）会造成非常大的资源消耗。而数据包内部以时间分块，支持二进制byte array直接衔接，将大幅提升云端分析效率。

EXD vData里支持按时间切数据块（Bucket）。一个数据块等同一个时间分区（time partition），由vData锁机制保障即使出现乱序，数据到达时间分区之间的时间也不重叠。由于每个信号以列存储的数据点保存在Bucket块中，对数据点的压缩也会在Bucket块中进行。如若信号接入量大到即使时间未到但Bucket已满，则会创建新的Bucket块进行存储。

格式自描述

传统数采格式BLF/ASC需要配套对应车型和版本的DBC才能解析，但在现实量产环境中，不同车辆的信号矩阵版本都可能不一样，实际车端可能和云端记录也不一样，诸如此类的问题会让车辆数据解析非常复杂。

传统车联网以JSON格式上传数值，JSON灵活但文本格式导致上传包/流量非常大。综合考虑，智协慧同原创了EXD vData文件格式VSW，具有自描述的特点，数据包到云端时能够自解析，无需寻找DBC版本比对，规避了DBC多版本管理的问题，是目前最佳的车辆数据文件格式。

基于vData，可以生长出丰富的行业应用

vData优秀的架构设计，使得智能汽车的许多应用拥有了生长的土壤和基础。

灵活数采

拥有车端数据库以后，所有信号数据都已经处在一个高压缩且高可用的状态，主机厂可以灵活的定义需要采集数据的场景，设置触发条件，灵活采集所需要的数据。不用担心数据丢失，数据精度不够的问题。同时也能将数据的传输、存储、计算等成本控制在一个可控的范围内。智协慧同EXCEEDDATA方案在行业内也率先与多家主机厂合作，并已将整套车云数据平台部署到量产车中，是国内首个实现高精高质量灵活数采的量产方案。

自动驾驶

自动驾驶需要海量的结构化、非结构化数据进行建模分析，在以往的开发过程当中，往往需要价格昂贵的数据采集盒子来采集数据，成本高昂的同时，只能收集路测阶段的数据。基于vData车端数据库，尤其在结构化的数据采集当中，完全可以在不增加硬件设备的情况下，实现触发式灵活采集，灵活打标，极大降低开发成本和工作量，覆盖研发和量产阶段，赋能车辆全生命周期数据采集。

远程诊断

vData车端数据库可以支持在车端全量存储一定时间的信号数据。这使得对车辆进行远程诊断、智能诊断成为可能。通过大数据建模形成的诊断推理机，解析车辆监控数据，对车辆进行精准诊断，预测故障发生而提前进行维护修理。甚至还能在“刹车失效门”等舆论发酵时远程提取监控数据，快速解析车辆信息及驾驶行为，澄清责任，避免品牌形象受损。

基于vData的丰富行业应用

车端数据库自研OR外采？

在智能汽车软件高速发展的今天，很多主机厂都拥有实力强大的软件团队，在强调自研的大背景下，主机厂自研车端数据库是否可行呢？

自研数据库在全球来说并不是一个通行做法

世界级主流的OS企业，比如谷歌开发的Android，其内置的数据库是SQLite，SQLite并不是谷歌开发的，但并没有人因此而抹杀Android的重要性和原创性。

相比数据库这种底层软件，体现主机厂价值的是其对应用的开发和创新

主机厂的一个重要目标是打造自己的软件生态，这个生态要基于主机厂自研的OS之上。从Android来看，决定生态的是Android的framework层，SQLite被封装在framework下面，对生态没有任何影响，所以谷歌并不是没有能力开发数据库，而是认为用自研还是外采数据库对自己建立的应用生态来说不重要，所以用一个市场上已经成熟的通用技术肯定比自研要风险/成本更低。

市场上缺乏能够开发车端数据库的人才

在车上开发一个嵌入式的时序数据库，之前行业里没有公司或团队做过，智协慧同是第一个。数据库的开发是很窄很细分的专业技术，很难在市场上找到能从0到1设计开发数据库的团队和人。在一个车端的嵌入式环境里，难度进一步升级。所以主机厂要想自研，从组建团队开始，就是很大的一个挑战，基本找不到有相关工作经验的人。

市场上缺乏开发车端数据库可用的经验和技术

目前还没有一个真正意义上，被国际广泛认可成功的中国原创的商业数据库产品，几乎市场上主流的成功数据库产品从商业到开源都是来自于美国。

在车上开发一个时序数据库，不是基于开源代码改一改可以实现的，开源社区里没有为汽车打造的任何开源数据库资料，云端的开源时序数据库也根本无法移植到车上来。这是一个真正从0到1的工作，需要从架构设计开始进行原创的设计。

对任何主机厂来讲，尝试去开发一个数据库都是疯狂的想法，就好像任何主机厂现阶段都不会去考虑自己开发一个操作系统内核一样。

车端数据库需要具备跨品牌跨车型部署的能力，主机厂由于其角色局限性，很难实现

数据库是典型的通用型技术类产品，它必须要跨多个主机厂甚至跨多个行业，在一个主机厂内开发通用性技术很难获得成功。

综上所述，主机厂自研数据库是一个投入大、风险高、价值低的事情，采用市面上已经量产的成熟技术，无疑是最优选择。

vData作为智协慧同为汽车行业打造的一个高效、专门为汽车定制的数据库产品，在为主机厂提供各类成熟解决方案的同时，更是作为一个数据库中间件，为主机厂和开发者打造各类应用开发的基础设施，赋能车企拥抱数据驱动的智能汽车时代。