# 车辆数据中台产品化参考

## 参考产品共性

- Samsara、Geotab、Verizon Connect、Motive 这类车队平台都把实时车辆位置放在主入口，地图是调度、监控和异常处置的第一视角。
- 主导航通常围绕车辆业务组织：实时地图、车辆/资产、轨迹回放、告警、安全或维护、报表统计，而不是围绕接入协议组织。
- 历史数据查询通常服务于 trip history、route replay、reports 和 alerts 的复核，原始接入数据不应成为客户主路径。
- 告警和通知需要从“发现异常”延伸到“责任人、升级、闭环”，而不是只展示技术链路状态。
- 运维链路、消息队列、存储状态适合放在内部视图，作为客户问题排查的支撑层。

## 2026-07-05 外部产品对标补充

- Geotab 的公开资料强调一体化车队平台：GPS 车辆位置可近实时查看，并保留完整 trip history。这说明首页主任务应是“车在哪里”和“历史怎么回放”，原始协议只能是证据层。参考：https://www.geotab.com/
- Samsara 的车队远程信息产品强调实时 GPS、车辆诊断、路线导航、燃料/能源监控和风险告警。这对应本项目的客户主路径：实时地图、车辆状态、轨迹、统计、告警。参考：https://www.samsara.com/products/telematics
- Verizon Connect 的车队管理公开页面把 dashboards、reports、alerts、near real-time location、driver behavior、routing visibility 放在核心能力中。这说明客户视角需要“监控、报表、告警、路线/位置”并列，而不是把 Kafka、Redis、TDengine 放在第一层。参考：https://www.verizonconnect.com/
- Geotab 关于远程车队管理的说明把数据流描述为：车辆采集位置和健康信息，经网络到云端，再在 Web/Mobile dashboard 展示实时报告和告警。这与本项目架构一致，但产品表达应从 dashboard 和 alerts 开始，而不是从接入来源开始。参考：https://www.geotab.com/blog/remote-fleet-management/

## 对标后的产品改造规则

- 首页第一屏只回答客户任务：看车在哪、查某段时间、导出证据、处理告警。
- “32960 / 808 / MQTT”不作为主任务名称，只在车辆档案、历史证据、运维质量中作为来源可信度出现。
- 自定义时间窗必须成为跨页面共享的查询意图：轨迹、里程、历史数据、告警复盘使用同一组参数。
- 内部可观测性继续保留，但默认折叠在运维/依据层，避免客户把系统理解为“协议接入平台”。

## 本项目采用的产品原则

- 三个接入来源只是数据通道，最终服务对象是车辆。
- 第一屏必须回答客户最关心的问题：有多少车在线、车在哪里、哪些车异常、如何按时间复盘。
- 车辆服务主路径固定为：车辆地图 -> 实时监控 -> 轨迹回放 -> 里程统计 -> 历史查询导出 -> 告警通知。
- 自定义时间窗要贯穿轨迹、里程、历史查询和告警，避免用户在多个页面重复录入条件。
- 协议、来源覆盖、Kafka、Redis、TDEngine、MySQL 等信息只在内部运维或复核层展示。

## 当前迭代落点

- 首页保留客户主路径：实时地图总览、车辆服务指挥台、自定义时间监控。
- 重复入口、KPI 和辅助服务收进“更多车辆服务入口”。
- 来源覆盖、地图配置、告警预览和链路状态继续放在“运维和依据层”折叠区。