3、GPS数据采集架构：车载终端、通信协议（TCP/MQTT）、数据上云链路

在途追踪系统的数据质量，从源头就取决于采集架构的可靠性。本章拆解从车载终端硬件、通信协议选型到数据上云的全链路设计，帮助工程师理解每一层可能引入的脏数据与延迟瓶颈。

3.1 车载终端：数据采集的第一公里

车载终端（Tracker / OBU）是GPS信号的物理入口，其硬件组成直接决定原始数据的精度与完整性。

3.2 通信协议：TCP vs MQTT 选型对比

终端与云端之间的通信协议决定了数据传输的实时性、可靠性与带宽消耗。当前主流方案为TCP长连接与MQTT协议，两者在轨迹场景下的关键差异如下：

3.3 数据上云链路：从终端到存储的完整路径

一条GPS数据从车载终端发出，到落入数据湖，通常经过以下5个环节。每个环节都可能成为数据质量衰减点。

1. 终端采集：GNSS芯片输出NMEA语句 → MCU解析并组装成协议帧。
2. 网络传输：通过4G/NB-IoT基站 → 运营商核心网 → 公网/专线 → 云入口。
3. 接入层：负载均衡（如NLB/ALB）分发到协议网关集群。
4. 协议解析与清洗：网关解码二进制帧，校验CRC、时间戳、经纬度合法性。
5. 消息队列与存储：清洗后的数据写入Kafka/Pulsar → 流处理 → 最终落入HBase/ClickHouse/OSS。

3.4 协议帧结构示例（TCP私有协议）

以下是一个典型的车载终端TCP上报协议帧，采用小端字节序，包含CRC16校验：

// 帧结构定义（C语言风格）
typedef struct {
    uint16_t  head;          // 帧头 0xAA55
    uint16_t  length;        // 数据体长度（含CRC）
    uint32_t  imei;          // 终端IMEI号
    uint32_t  timestamp;     // Unix时间戳（秒）
    int32_t   latitude;      // 纬度 * 10^7
    int32_t   longitude;     // 经度 * 10^7
    uint16_t  speed;         // 速度 km/h * 10
    uint16_t  direction;     // 航向 0~3599（0.1度）
    uint8_t   status;        // 定位状态：0x01有效 0x00无效
    uint16_t  crc16;         // CRC16校验（从head到status）
} __attribute__((packed)) GpsReportFrame;

3.5 MQTT主题设计与QoS策略

采用MQTT协议时，主题（Topic）设计直接影响数据路由的灵活性。推荐按“业务线/设备类型/设备ID”三级结构组织：

• tracking/truck/{imei}/gps — 实时GPS位置
• tracking/truck/{imei}/status — 车辆状态（点火/熄火/报警）
• tracking/truck/{imei}/diagnostic — 终端诊断日志

QoS选择建议：

3.6 链路延迟与数据质量的关系

从终端上报到数据落盘，端到端延迟通常由以下因素构成：

• 终端上报间隔：30s/60s/120s 可配置，间隔越长，轨迹稀疏度越高。
• 网络RTT：4G网络典型RTT 30~80ms，弱网环境可能超过1s。
• 网关处理时间：CRC校验+协议解析+字段清洗，单点耗时通常 < 5ms。
• 消息队列排队：Kafka分区数不足时，积压导致延迟秒级到分钟级。