数据来源常见类别

数据采集

电动汽车采集数据需要上传至国家监控平台（主要是国家标准规定的数据字段）和企业自定义数据（企业自己定义要采集的数据）。

• 国标数据：主要包括车辆的位置、状态、速度、发动机、驱动电机、充电桩、电池及电池故障相关数据。
• 企业自定义数据：包括用户驾驶行为数据、车辆状态数据、车辆操作数据（如门、空调、车窗等）、IVI点击行为数据等。

常见名词说明

Tobx

汽车TBOX，全称为车载信息与定位传输系统，是安装在车辆上的一种高科技设备。TBOX主要用于采集车辆数据与TSP平台实时通信，数据上报，人车交互。

它不仅能够深度读取并解析汽车的CAN总线数据和私有协议，还能通过GPRS网络将这些重要信息实时传输到云服务器。TBOX的终端装备了具有双核处理能力的OBD模块和CPU构架，这使得它能够同时采集汽车总线中的Dcan、Kcan、PTcan等相关数据，并对私有协议进行反向控制。

即车联网系统，借助远程通信和技术手段，为汽车提供了丰富的行车数据采集、远程查询与控制、监控故障等服务。它的主要功能包括：

1. 收集并储存行车数据和行驶轨迹记录，对这些数据进行分析并在仪表盘上进行展示。
2. 通过T-BOX实现远程查询与控制，例如开启或关闭车门、鸣笛、闪灯、调节空调以及启动引擎等功能。
3. 实时检测并报告道路救援、故障诊断及异常情况等信息。当发生事故时，T-BOX会自动拨打救援电话，为用户提供及时援助；一旦出现故障，它会立即发出预警；而一旦发生被盗等情况，也会发出警报通知用户。

TBOX提供的功能有网络接入、OTA、远程控制、位置查询/车辆追踪、电池管理、位置提醒、eCall、远程诊断、平台监控/国家监管等。

T-BOX核心功能

• MPU：用来实现应用程序功能，例如通过APP查看车辆信息、车门解锁或远程启动车辆等。
• MCU：主要用来控制电源管理，以及接入汽车CAN总线。T-BOX与主机通过CAN BUS总线通信，实现指令与信息的传递，从而获取到包括车辆状态、按键状态等信息以及传递控制指令等；通过音频连接，实现双方共用麦克与喇叭输出。与手机APP是通过后台系统以数据链路的形式进行间接通信（双向）。

T-BOX与后台系统通信还包括语音和短信两种形式，使用短信形式主要实现一键导航及远程控制功能。

T-BOX可深度读取汽车CAN总线数据和私有协议，T-BOX的MCU部分具有强大处理功能的OBD模块。模块中内置了CPU构架，分别采集汽车总线的总线数据和私有协议，从而进行反向控制，并通过网络将数据传送到云服务器。

TBOX的基本功能

TBOX的功能模块主要包括4G模块、GPS模块、蓝牙模块、以太网模块、CAN通信模块、电话语言模块、电源模块、Airbag模块、E/B-call模块等，每个模块之间紧密联系在一起，形成一个完整的远程通信终端。

TBOX的主要功能

1. 联网
   联网是Tbox最重要的功能之一，可以支持移动、联通、电信三大运营商的网络。车机并没有联网功能，Tbox相当于SIM卡。Tbox与车机之间采用车用以太网通信，组成局域网，分享Tbox的4G和wifi热点上网通道。

2. 车辆信息实时上传
   Tbox不仅可以上网，而且还是车辆信息化的核心控制器，通过CAN以及以太网与整车进行通信，实时获取车辆信息包括实时油耗，发动机水温，发动机转速，车辆行驶里程，当前车速，电瓶电压，进气压力，冷却液温度，氧传感器电压发动机负载，节气门开度，空气流量，GPS车辆位置信息等。实现了对车辆行驶数据的实时监控。

3. 远程控制
   当车辆静止的时候，可以对车辆进行远程控制等功能。可以通过手机APP和TSP后台网页，输入车辆唯一的身份证号VIN，获取车辆现在的实时状态，如车窗是否关好、车门是否上锁、剩余油量电量、总里程、驾驶室温度等车辆信息，并进行相应的远程控制，如远程开车门、远程开车窗、远程打开后备箱、远程打开空调等操作。

4. 远程诊断、本地诊断
   汽车远程故障诊断系统是指汽车在启动时，Tbox获知汽车的故障信息，并把故障码上传至数据处理中心。系统在不打扰车主的情况下复检故障信息。在确定故障后，并实施远程自动消除故障，无法消除的故障以短信方式发送给车主，使车主提前知道汽车存在的故障信息，防范于未然。

5. 车辆异常告警上传
   当车辆上的一些部件出现一些异常或者是严重故障的时候，如发动机温度过高、车门入侵、水温过高、油量较少等，Tbox会第一时间获取到出现故障或者异常的信息，并把这些信息传输给用户，提醒用户要及时处理这些问题。

6. E/B-call服务
   Ecall（汽车紧急呼叫系统）是拯救生命的重要环节，当车辆发生碰撞，安全气囊弹出的情况下触发了Ecall，Tbox迅速传递车辆的位置信息等基本信息给客服，客服中心则会根据的车辆的位置信息，在第一时间与当地的4S汽车维修店、医疗救护中心、警察局等相关机构进行联系，确保第一时间到达事故现场进行救援。Bcall（一键电话救援），主要是道路救援，按下后可以获得道路拖车等服务。

7. OTA功能
   汽车的OTA功能是指空中下载技术，通过移动通信实现对汽车软件版本的远程升级。相比之前到4S店通过整车OBD对相应的汽车部件进行软件升级，OTA技术极大的提高了便利性，让车主随时随地可以对自己爱车的电子部件进行软件升级，使其有更好的驾驶体验。

• SOTA: 软件升级，面向车载端上的应用软件升级。
• COTA: 配置升级，面向车端端上的配置升级。
• FOTA: 固件升级，面向车端上的固件升级，实现对动力域、底盘域、辅助驾驶域、信息娱乐域和车身域在内的重大功能更新。

OTA主要涉及两端，后台管理和客户端。后台管理包括升级包上传、版本控制、升级流程监控与统计、应用与数据升级等；客户端包括定时检查更新、手动检查更新、安全下载、断点续传、升级包校验等。

8. V2X
   V2X（合作式智能运输车用通信系统）是通过人、车、路信息交互，实现三者之间的智能协同与配合的一种智能运输系统体系，能够实现道路交通安全、通行效率的提升，以及信息服务等不同应用。

9. 位置查询/车辆追踪
   提供车辆的实时定位信息，可通过手机应用查询车辆的实时位置以及历史轨迹。

10. 平台监控/国家监管
    利用已经安装在车辆上的车载通讯单元（OCU）实现将国家要求的高压电相关静态数据、动态数据和故障状态实时传输到政府平台。相应的国家标准为《GB/T 32960-2016 电动汽车远程服务与管理系统技术规范》，从2017年4月1日起，所有新能源汽车必须强制实行国标 GB/T 32960。

车载设备（T-box，车机等）作为车辆运行数据的收集者，基于固定频率将车内各类控制器、传感器等数据打包发送到平台端。此类数据一般可以按照上报数据的车型、车架号、业务数据类型等多个层级进行设计。

ECU

不同功能的控制单元，如EPS/BMS/VCU等，一辆车由非常多大大小小的控制单元组成。

CAN

通过定义信号名，去描述车辆各ECU不同功能当前的状态的变量，如速度信号/电压信号/电流信号等。CAN即Controller Area Network，通过CAN总线可以对车辆上的各类电子控制系统进行统一通信，在实际车辆运行过程中，CAN总线数据是车辆安全性、可靠性和高性能的重要保证：

• 车辆系统监测和控制：CAN总线数据可用于监测和控制系统中的各种设备和组件。传感器通过CAN总线发送其测量值，如温度、压力、位置等，以便其他设备或控制器实时监测和采取相应的措施。同时，控制器可以通过CAN总线向执行器发送控制指令，如调节阀门、驱动电机等，以实现对系统的控制。
• 车辆信息实时反馈：CAN总线数据可用于提供实时反馈信息。例如在车辆控制系统中，传感器通过CAN总线传输车速、转向角度、制动状态等数据，控制器可以根据这些数据进行实时决策和调整，以确保车辆的安全性和性能。
• 数据共享和协调：CAN总线数据允许不同设备之间进行数据共享和协调。通过CAN总线，不同的控制器和设备可以交换信息，共享状态和控制命令，有利于提高系统的整体性能和效率。
• 网络管理和故障诊断：CAN总线数据用于网络管理和故障诊断。通过CAN总线，可以进行设备的自动识别、配置和监控，以便进行网络管理和故障排查，提高系统的可靠性和可维护性。

CAN数据解析前世与今生

18年以前，车辆的数据，车载大屏端，会解析完数据后（解析数据过程包括大小端转换和数理计算），以一种协定的数据格式，进行数据上报；

• 缺点：上传数据具有确定性，增加采集数据，需要发布新的版本；上传的数据项较少；
• 优点：服务端不需要关注车型差异性、版本差异性带来的数据差异，差异性由大屏端处理；

在效率优先，迭代优先的造车新势力面前，这种方式与整体节奏显得格格不入；

18年后，车辆CAN数据由大屏端解析上报，变更为透传上报，服务端进行数据解析；

• 优点：上传数据包更小，且数据维度更丰富，增加新维度数据采集，不涉及开发及发版，通过更新配置即可获得。

期间我们为了节省流量，做了一些策略，如不同类别的数据，采集频率不同；但目前情况反观当时的做的策略，是那么多余，需求方不同，对数据频率要求不同，数据开发需要思考的，除了成本的节约，还有数据的可追溯性。

DBC

一份记录CAN信号解析规则的配置和车辆CAN网络结构的描述文件，通过这个描述文件，你可以快速知道一个二进制数值需要进行怎样的转换即可得到真实的信号数值。

TSP

TSP（Telematics Service Provider，全文简称TSP）是汽车远程服务提供商，位于车联网产业链的核心位置。整车厂商、内容服务提供商、电信运营商、互联网应用服务提供商将软硬件应用、互联网服务、通信业务等内容输入到汽车远程服务提供商，然后TSP负责对各类应用服务进行整合、管理并呈现给车主，作为“车—人”的桥梁直接面向车主提供服务。

在传统的汽车行业，互联网运营模式并不流行，智慧驾驶体验的需求并未被激发，所以传统TSP行业基本仅仅需要去车企进行合作，专注于为车主提供车载信息服务和车载娱乐服务。传统的车载信息系统主要是使驾驶员在行驶过程中，能够通过车载电子装备及时了解汽车运行的状况信息和外界信息的装置，一般是机械式仪表盘加报警功能的显示系统，这种显示系统只能向驾驶员提供车速、累计里程、温度以及利用灯光显示汽车左、右转向及倒车的相关信息；传统的车载娱乐系统也较为单调，主要提供包括视频、影音等多媒体服务。

但随着智能网联的迅猛发展，尤其是5G技术的普及，车联网对汽车远程服务的要求早已不仅仅局限在传统服务中。TSP行业的业务核心不再是为车主提供传统的信息娱乐服务，而是要在与车企密切合作、拓展前装市场的同时，更紧密地与智能驾驶、云计算、互联网和运营商等行业的龙头企业进行合作来获取最多样化的、拥有高新技术的增值服务和内容，为车主提供更为智能的、应用场景更为丰富的远程服务，增强企业的核心竞争力。在这个万物互联的智能时代下，TSP的业务范围发生了变化，从传统的信息服务和娱乐服务，拓展到为整车厂提供车联网服务及其智能网联汽车整体解决方案，包括但不限于汽车安全信息服务、大数据车险服务、高精度地图导航服务、远程诊断及保养提醒服务、路线及行程管理服务、影音娱乐、社交等车载服务。

车联网TSP主要由三个基本组成部分组成：汽车端、通信网络和云端。

• 汽车端：汽车端主要是指车载设备和传感器等硬件，以及车辆状态监控等软件。这些设备和软件能够将车辆的实时状态传输到云端，并接收来自云端的指令和数据；同时，还能够使车联网TSP提供的相关功能及时在车内展现，实现驾驶员对车辆状态的监控和控制。
• 通信网络：通信网络主要是指连接汽车和云端的网络，包括4G、5G网络、Wi-Fi、蓝牙等无线通信技术。通过这些通信网络，车联网TSP可以实现车辆状态监控、远程指挥、数据传输等功能。
• 云端：云端主要是指云计算平台，包括基于云的数据处理和分析平台，以及提供云存储服务的平台。通过云端，车联网TSP可以实现车辆数据分析、数据挖掘、人工智能算法、智能维保和预测维护等服务。

DCS

集成控制系统（DCS）

OTA

OTA（Over-The-Air，空中下载技术）是一种无线传输技术，用于在物联网设备之间进行远程更新和配置。OTA指的是通过无线通信网络来远程更新或升级嵌入式系统中的软件或固件。OTA更新是一种方便的方法，用于将新功能、改进后的性能、安全补丁或其他更改推送到嵌入式设备，而无须物理接触设备或用户手动干预。

远程软件升级(SOTA)

SOTA（Software Over-The-Air），即远程软件升级，是指在操作系统的基础上对应用程序进行远程升级。SOTA通过远程下载并给车辆安装“应用程序升级包”，来实现控制器功能的一个“增量”更新，一般应用于娱乐系统和智驾系统。SOTA一般涉及应用层小范围的功能局部更新，不包括汽车核心系统，对整车性能和安全影响较小，升级前置条件要求较低。SOTA的增量更新策略，可以大幅减小升级包文件大小、从而节约网络流量和存储空间。

远程固件升级(FOTA)

FOTA（Firmware Over-The-Air），即远程固件升级，是指囊括车辆底层算法至顶层应用的综合升级，在不改变车辆原有配件的前提下，通过远程下载并写入新的固件程序进行设备升级。FOTA包括驱动、系统、功能、应用等的升级，与硬件的更换没有关系。FOTA涉及车辆的核心系统，包括但不限于汽车动力控制系统、底盘电子系统、自动驾驶系统、车身控制系统等核心零部件的控制系统，可以改变车辆的充放电、动能回收、加速性能、辅助驾驶系统逻辑等与深度驾控有关的体验。理论上所有支持固件更新的电子控制单元（ECU）都可以涵盖在FOTA范围中。

远程配置(COTA)

COTA（Configuration Over-The-Air），即远程配置，是指通过OTA的方式实现远程修改配置字，以达到修改软件功能配置的目的。配置字是一组以数据标识码(DID)方式存储在ECU上的数据，可通过诊断指令进行读取和修改。它根据特定的编码规则与车辆功能特征码一一对应，通过配置可判断车辆的功能配置，软件可根据配置实现相应的功能。远程配置常见的应用场景是远程开启和关闭某项功能，例如软件订阅功能。

远程诊断/远程数据更新(DOTA)

DOTA有两种常见解释：

• DOTA(DataOver-The-Air)，即远程数据更新，是指一些独立于软件程序存在的数据包的更新，比如，地图数据、语音数据和算法模型数据等。这类更新的特点是数据量比较大，更新流程相对独立，比如，地图数据通常由地图应用自行更新，而数据量也可能高达几G到几十G。
• DOTA(DiagnosticOver-The-Air)，即远程诊断，通过云平台实时数据采集监控，主动性地检查汽车系统异常问题，为远程问题修复与人工问题修复提供决策依据。远程诊断的触发方式有两种，一种是用户在车辆上发现异常状况的响应式；另一种是周期性收集通讯网络、应用程序、硬件效能、使用操作记录、系统程序等状态信息，利用大数据后台分析监测故障。

其他类型(XOTA)

随着汽车智能化程度越来越高，除了车辆本身软件的升级外，还可能会涉及到外部智能设备交互功能的软件更新，比如，智能钥匙、AR设备等。目前有些企业和组织将所有与车辆相关联的软件升级统称为XOTA，即Everything Over-The-Air的意思。

OTA主控功能模块

OTA升级流程

车辆终端（车载系统数据、传感器、控制系统等数据）

通过TCU上报数据到设备网关，原始上报的数据经过数据解析服务完成数据的解码，然后将语义化的消息推送到数据接入层的消息队列中。

TSP数据

主要包含：Tbox数据、充电桩数据、Hu数据、第三方数据

Tbox数据：主要包含车辆的行驶数据、位置轨迹数据、车辆状态数据、车辆操作数据、OTA数据、充电数据、CAN数据。

设备终端（埋点数据）

通过数据采集SDK将智能终端产生的数据上报到服务网关，同样在数据解析服务模块完成数据解析，并注入到数据接入层的消息队列中。

APP数据

主要包含：用户行为数据（流量数据），可划分为静态埋点数据和动态埋点数据。静态的采集策略，应当采取的原则是：按需采集。从需求角度出发，要看什么数据，就采集什么数据，在计算成本和应用效率上找一个平衡。动态的采集策略是在交互动作前后，参数的采集策略。

业务数据（业务数据库数据）

主要包含常见业务系统数据：SAP、MES、CRM、营销、SCM、BOM、研发、生产、客服数据
下线管理：车辆线下检测数据
售后系统：售后诊断数据
...

基础设施数据

风光电系统：充电桩数据

数据采集与上报

1. 数据上报必要性

按照GB32960.3国标定义，新能源车辆需要进行车辆数据上报，数据包含：

• 常规车辆状态：速度/总里程/位置/车辆状态/SOC等常规车辆状态信息；
• 三电相关信息：如电池电压/电流/电机转速/电机转矩/充电相关信息等；
• 告警信息：车辆一级/二级/三级告警，及告警时候车辆的状态相关信息；

所以数据采集，并非车企窥私，而是应国家相关规定要求，保障用户相关人身安全，更多的车企一方面为了遵守相关规定，另一方面则是为了做智能相关服务更好服务用户。

2. 车辆数据的特殊性

在常见的数据采集场景里，采集的数据都是由业务定义，研发进行采集上报；不管是手动埋点还是自动埋点，这里的共同属性是数据是定义的，含义是明确的，内容是理解的；但是车辆由大大小小几十个ECU组成，每个ECU可以产生非常多的信号，而每个信号又是以不同频率(10ms/20ms/50ms/100ms/200ms)产生，一款车少则小几千信号需要采集，多则上万个信号需要采集，这对采集/上报/传输都是不小的成本考验。

我们来算下这笔帐：
如果一辆车1s采集1次，1次采集5000个信号，按常规数据结构设计，用一个MAP存储，这得5000个Key，然后打包上传，这得多少流量？所以，如何节省流量是个首要需要考虑的问题？主要思考方向有：

• 减少采集数据和频率，降低数据上报流量；
• 优化数据上报结构，并通过压缩，减少单个数据包大小，达到降低数据上报流量的目的；

前期我们采用按需上传，需要才采集，但后续发现增加采集信号的周期过长，开发一个需求，缺省信号，端增加上传需要排版本且需要近一个月的时间响应，且不能有效对数据进行历史回溯，所以我们后续便废弃了该模式。采用了非按需数据上报的方式，按某个频率对车辆数据以CAN原始数据形式进行上报（原始数据形式指按二进制原数据形式）。

通过调整，我们解决了数据可溯源和快速响应需求的问题。

3. 车辆数据上报的不稳定性

车辆数据上报为什么会存在不稳定性，可能是由以下原因造成：

1. 有些车企使用的是2G网络，网络较慢/较差；
2. 车辆经常出入于信号差的区域，如隧道/停车场等；
3. 假基站的存在，使模组连接后不能正常使用，需要一定时长后才能恢复，如超时；
4. 2G/3G/4G网络切换，带来的网络不稳定；

以上的常见情况，都会导致数据上传慢和中断，也确定了，车辆数据上传属于弱网络数据上传的场景。往常的数据上报，我们一般采用HTTP类/日志文件类进行上报；而车辆数据上传，由于弱网络条件下，我们得保证协议体够轻且数据上报时候，就做到一定的有序，我们采用了MQTT协议进行数据的上报传输，并对数据通道作了实时和离线通道的定义。

实时数据通过MQTT进行上报数据，离线数据通过文件进行日志上报。对实时和离线通道的区分，主要是源于后续业务流处理逻辑依赖于数据的有序性，无序会影响逻辑执行。

通过上文描述，可大概知道，数据采集上报流程如下图：

车联网场景消息吞吐设计的关联因素

车联网的消息分为上行和下行。上行消息一般是传感器及车辆发出的告警等消息，把设备的信息发送给云端的消息平台。下行消息一般有远程控制指令集消息和消息推送，是由云端平台给车辆发送相应的指令。

在车联网消息吞吐设计中，我们需要重点考虑以下因素：

消息频率

车在行驶过程中，GPS、车载传感器等一直不停地在收集消息，为了收到实时的反馈信息，其上报接收的消息也是非常频繁的。上报频率一般在100ms-30s不等，所以当车辆数量达到百万量级时，平台就需要支持每秒百万级的消息吞吐。

消息包大小

消息是通过各种传感器来采集自身环境和状态信息（车联网场景常见的有新能源国标数据和企标数据）。整个消息包大小一般在500B到几十KB不等。当大量消息包同时上报时，需要车联网平台拥有更强的接收、发送大消息包的能力。

消息延时

车辆在行驶过程中，消息数据只能通过无线网络来进行传输。在大部分车联网场景下，对车辆的时延要求是ms级别。平台在满足百万级吞吐条件下，还需要保持低延时的消息传输。

Topic数量和层级

在考虑百万级消息吞吐场景时，还需要针对消息Topic数量和Topic树层级进行规范设计。

Payload编解码

当消息包比较大的时候，需要重点考虑消息体的封装。单纯的JSON封装在消息解析时不够高效，可以考虑采用Avro、Protobuf等编码格式进行Payload格式化封装。对于百万级消息吞吐场景，基于MQTT客户端共享订阅消息或通过规则引擎实时写入关系型数据库的传统架构显然无法满足。目前主流的架构选型有两种：一种是消息接入产品/服务+消息队列（Kafka、Pulsar、RabbitMQ、RocketMQ等），另外一种是消息接入产品/服务+时序数据库（InfluxDB、TDengine、Lindorm等）来实现。

exactly-once

需要保证消息不丢不重，确保维护其offset和重置消费。接下来我们将基于上述的关联因素和客户案例的最佳实践，以云原生分布式物联网消息服务器EMQX作为消息接入层，分别介绍这两种架构的实现方式。

车联网大数据架构平台常见架构

1: 使用云厂商的产品

2：EMQX+Kafka

3：Tbox上传数据到云端服务器上

Tbox+TSP平台网络上传(SDK、TCP、Flume)

其它

远程诊断实时故障分析

里程行程相关

电子围栏分析

DROP TABLE IF EXISTS `electric_fence`;
CREATE TABLE `electric_fence` (
  `id` int(11) NOT NULL AUTO_INCREMENT COMMENT '自增id',
  `vin` varchar(255) NOT NULL COMMENT '车架号',
  `inTime` varchar(25) DEFAULT NULL COMMENT '进电子围栏时间',
  `outTime` varchar(25) DEFAULT NULL COMMENT '出电子围栏时间',
  `gpsTime` timestamp NOT NULL DEFAULT CURRENT_TIMESTAMP ON UPDATE CURRENT_TIMESTAMP COMMENT '位置时间',
  `lat` double NOT NULL COMMENT '位置纬度',
  `lng` double NOT NULL COMMENT '位置经度',
  `eleId` int(11) DEFAULT NULL COMMENT '电子围栏ID',
  `eleName` varchar(255) NOT NULL COMMENT '电子围栏名称',
  `address` varchar(255) NOT NULL COMMENT '中心点地址',
  `latitude` double NOT NULL COMMENT '中心点纬度',
  `longitude` double NOT NULL COMMENT '中心点经度',
  `radius` float NOT NULL COMMENT '电子围栏半径',
  `terminalTime` varchar(255) DEFAULT NULL COMMENT '终端时间',
  `processTime` timestamp NULL DEFAULT NULL ON UPDATE CURRENT_TIMESTAMP COMMENT '插入数据的时间',
  PRIMARY KEY (`id`),
  KEY `vin` (`vin`)
) ENGINE=InnoDB AUTO_INCREMENT=3 DEFAULT CHARSET=utf8 COMMENT='电子围栏';

end