随着智能汽车时代的到来，数据作为智能汽车的核心受到越来越多的关注。结合前段时间Tesla的碰撞事件来讲，大家普遍关注两个问题。

问：现在车辆智能网联率越来越高，直接使用车联网数据能进行碰撞事故溯源吗？

答：车辆碰撞瞬间发生，碰撞期间车辆运动性能和驾驶员驾驶操作高频发生，一般都是在毫秒级别，而车联网数据上传频次一般是1s~30s，而且数据质量还不好，单纯依靠车联网数据是无法还原事故现场和支撑事故责任判定的。

问：既然车辆现在都联网了，是否可以把全量的高频数据上传到云平台呢？

答：5G技术的应用理论上是可以支持全量高频数据上传云端的，但是也会带来新的难题。首先，全量高频数据上传会产生巨大的流量费用，同时云端存储海量数据也会带来沉重的存储成本；其次，全量高频数据的上传会产生大量冗余数据，反而会降低数据利用的效率。因为对工程师来说最有价值的是异常或特定的相关数据，在全量数据里面找到有价值的数据特征无异于大海捞针。

网络上针对特斯拉的刹车系统到底是否真的存在安全隐患众说纷纭。这次碰撞事故责任如何认定、如何通过数据进行事故溯源就已经成为最大关注点。

（图片来自网络）

这次事件的持续发酵，让特斯拉不得不请出EDR（Event Data Recorder），汽车事件数据记录系统，可以被看做是汽车上的“黑匣子”。特斯拉的EDR记录了车辆碰撞前、碰撞时、碰撞后三个阶段中汽车的运行关键数据，包括速度、ABS状态、方向盘的转向角度、气囊状态、车辆制动状态等数据。通过这些有效的原始数据才能够还原事故发生前后的真实状态，做到让数据说话。

正如某高端智能电动车的自动驾驶项目负责人在接受经济观察网记者采访时所说：“原始数据放开是定位、分析、重现撞车原因的唯一的途径。因为解决问题的前提是要定位问题，定位问题的前提是要能够复现问题，即还原现场。因此，拿到原始数据的首要目标就是为了把问题复现出来，把场景重现出来。我们可以根据模拟的信号，分析出当时是在什么样的情况下，自动驾驶或者人为操作给了系统什么信号，最终导致了这样的结果。”

EDR毫秒级数据（图片来自网络）

原始数据=高精数据，这是实现场景重现的必要条件。但是，要采集和处理车辆的高精数据，付出的成本是巨大的。比如，踏板信号不是单个信号，而是连续信号，每秒钟采样最少几百次；再比如，现在的智能汽车上一个域控制器就可能超过2000个信号维度，跟底盘与动力相关的信号频率高达100-1000Hz（0.001-0.01s）。

所以，基于高精数据进行事件分析会带来两个维度的挑战：

维度一：高频率、多信号的数据采集，数据需快速接入和存储在内存里；

维度二：通过高性能实时计算判断是否发生碰撞，随后触发相关高精数据在车端的存储--切片--压缩--上传至云端。

Tesla则采用通过EDR将毫秒级高精数据进行公开，重现事故细节。那Tesla以外的各个车企应该如何应对此类挑战？许多车企选择采用传统车联网采集方案或者传统后装硬件采集方案，本来是为了避免踩类似事故的“坑”，结果却踩进了更多的“坑”。

传统车联网采集方案的挑战

• 数据压缩差，导致流量贵、存储I/O高、车端被迫存低频采样数据而不是原始数据

• 车联网数据通过一个很不稳定的通信链路到云端，往往伴随着数据丢失、乱序、数据跳变等质量问题，难以满足业务部门的需求

• 绝大多数车企的车联网数据采集频率都是1s~30s采集一次，对于毫秒级原始信号而言，这样的数据颗粒度较大，会丢失大量特征；如果车企选择高频的数据采集频率，随之而来的是成本的大幅提升，且难以保证云端数据质量

• 数据采集配置不够灵活，改配信号接入和监测需要改大量代码，周期很长

传统后装硬件采集方案的挑战

• 约车主时间再从实车硬件拷贝数据较困难，而且容易造成车主负面品牌形象

• 额外硬件大幅拉高成本

• 后续改动和OTA工作量大

这些”坑“会给车企带来更大的经济成本、时间成本和人力成本。

事故溯源需要高精数据闭环来解决

要解决之前提到的两个维度的挑战，首先得回到如何采集到车企所需的高精数据这个问题上，我们在之前的文章：从边缘计算到车云计算，赋能面向未来的智能出行提出了边缘计算的观点：在最靠近数据源头的边缘端做计算和存储，解决车联网数据质量问题，既要高精度、高质量，还要低成本。EXD车云计算的边缘套件可很好的利用纯软件方案解决此类问题，即：边缘计算环境vCompute，边缘数据库vData。

OEM可基于EXD边缘套件快速构建很多解决方案或能力，灵活数采便是其中一个。灵活数采能够赋能主机厂及时识别各类意外事故，主动采取救援措施的同时快速获得事件前后的高保真原始数据，客观、真实的呈现事故缘由，避免事件被恶意炒作而导致品牌形象的破坏。

EXD影子模式解决方案的技术架构

该解决方案主要由车端边缘计算环境vCompute和车端高性能数据库vData构成，vCompute和vData可轻量化部署于QNX、Linux和Android等主流OS上。

车端边缘计算环境vCompute：

• 支持从云端下发的算法在车端进行秒级部署

• 支持接入数千个1000Hz级别的原始信号

• 支持毫秒级流计算

• 并且拥有很低的CPU占用率

车端高性能数据库vData：

• 支持车端实时高频的信号写入和查询

• 应用4层压缩技术(减少刷写量/同空间存更多数据)，无损压缩100~300倍

• 增量式存储：接收的数据放在内存里，到达一定量后整个写出（减少刷写次数/车载件的寿命）

• 支持4种模式（纯内存消息站模式、T-Box填充模式、原始记录模式、黑匣模式）

当碰撞事件发生时，vCompute运行着对异常事件进行监测的算法模型，通过毫秒级计算对碰撞事件进行识别，识别完成后通过中转服务发送请求给vData，vData对前后1分钟（时间长短可配置）碰撞相关的高精数据进行存储、切片、压缩后上传至云端（信号包括：速度、ABS状态、方向盘的转向角度、气囊状态、车辆制动状态等...），采取分包上传，并通过checksum校验码进行数据完整性验证，确保数据质量。

通过EXD边缘计算，可第一时间进行碰撞事故提醒，客户运营作出快速事故处理响应，将客户生命财产损失降低到最小，同时，云端工程师可以对高精数据进行分析，快速查明原因给出真相，避免事情被恶意炒作。如果真是汽车设计缺陷，车企可以进行针对性的优化。EXD车云计算相比于特斯拉EDR方案，无需配置额外的硬件即可实现。

vCompute与vData 具体业务流程：

1. 实时信号接收：车载信号数据库vData和边缘计算vCompute同步通过AP SOA服务订阅SOME/IP数据；

2. 灵活算法设计：云端实现算法的创建与信号维度和时间维度的灵活配置，经过仿真测试后下发到车端vCompute进行实时计算；

3. 异常触发：触发发生时，vCompute发送指令到查询服务；

4. 数据查询：查询服务向车载信号数据库vData发起触发前后时间维度的相关信号请求，然后对采集的数据进行切片、压缩、分包；

5. 结果上传：查询服务将数据经SOME/IP发送至TBOX上传，在云端自动组合通过checksum校验码进行完整性验证，主机厂工程师可第一时间基于完整的高精数据进行业务分析。

   
   

EXD影子模式方案架构适配参数

本文通过EXD车云计算方案对如何应对碰撞事件溯源进行一次推演，可以用通过边缘计算与存储的技术实现纯软件的解决方案，而车云计算不仅仅能灵活应对这突如其来的棘手事件，还能实现千人千面的个性化智能。

未来的智能汽车就是一个移动的计算机和数据库，正好对应EXD的边缘计算套件：vCompute和vData，边缘计算与云计算协同，必将全面赋能未来的智能出行。