lingniu-vehicle-ingest/vehicle-data-platform/docs/fleet-platform-product-research.md

车辆数据中台产品化参考

参考产品共性

• 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/
• Fleetio 的车辆资产和报表资料把 Vehicle List、Vehicle Details、Service History、Service Schedule 等作为车队管理的高频入口。这说明车辆中心不能只是数据覆盖表，还要提供最近车辆、待维护车辆、服务历史/报表导出的资产作业入口。参考：https://www.fleetio.com/ 和 https://www.fleetio.com/blog/fleet-management-reports
• Azuga 的车队跟踪资料强调实时跟踪、车辆资产保护、维护告警和洞察报表。这对应本项目车辆中心的作业栏：最近上报、待关注车辆、身份维护和报表导出。参考：https://www.azuga.com/
• Verizon Connect 把 live map 与 historic replays 放在同一个 GPS tracking 叙事里，Geotab Trips History 支持查看车辆实时位置和历史行程，Samsara GPS tracking 也把 Trip history 作为分析车辆行程效率的核心入口。因此历史页要先呈现“车辆 + 时间窗 + 轨迹回放 + 证据导出”的客户复盘路径，而不是先暴露 RAW/字段表。参考：https://www.verizonconnect.com/solutions/gps-fleet-tracking-software/、https://support.geotab.com/help/mygeotab/fleet-activity/trips/trips-history、https://www.samsara.com/products/telematics/gps-fleet-tracking
• Samsara、Geotab、Verizon Connect 的公开页面都把客户问题翻译成任务入口：车辆在哪里、这一趟怎么跑、哪些风险要通知、报表如何导出。因此首页右侧需要问题式入口，先回答客户语言，再下钻到地图、轨迹、统计、历史证据和告警。
• Geotab、Fleetistics、FleetRabbit 等资料都把 Trip History、Mileage、Reports、Excel/PDF 导出放在一起：客户不是只看一张里程表，而是需要“统计口径 + 轨迹复核 + 明细导出 + 可发送结论”的报告路径。
• Verizon Connect GPS Fleet Tracking、Samsara GPS Fleet Tracking 和 Motive Fleet View 都把 live map、历史回放、筛选分组、告警和调度决策放在同一条作业链路里。因此实时页需要一个“实时地图调度台”：客户先看在线位置，再处理异常、轨迹、导出和通知，而协议来源只作为位置可信度证据。参考：https://www.verizonconnect.com/solutions/gps-fleet-tracking-software/、https://www.samsara.com/products/telematics/gps-fleet-tracking、https://gomotive.com/fleet-view/

对标后的产品改造规则

• 首页第一屏只回答客户任务：看车在哪、查某段时间、导出证据、处理告警。
• 第一屏需要有“客户问题处理台”：现在车辆在哪里、这段时间跑了多少、轨迹能不能回放、需要导出哪些证据、哪些车需要通知处理。
• “32960 / 808 / MQTT”不作为主任务名称，只在车辆档案、历史证据、运维质量中作为来源可信度出现。
• 自定义时间窗必须成为跨页面共享的查询意图：轨迹、里程、历史数据、告警复盘使用同一组参数。
• 车辆中心要像资产系统一样把车辆清单变成作业入口：最近上报、待关注、身份维护、报表导出，而不是只提供表格筛选。
• 轨迹/历史页要像 Trips History：先锁定车辆和时间，随后回放路线、核对里程、导出证据；RAW 和字段裁剪只作为复盘依据。
• 里程统计页要像客户报告工作台：先确认统计口径和闭合状态，再进入轨迹复核、历史明细、CSV 导出和交付结论。
• 内部可观测性继续保留，但默认折叠在运维/依据层，避免客户把系统理解为“协议接入平台”。

2026-07-14 Replay 深化对标

• Verizon Connect Reveal 的官方 Replay 说明默认展示当天，并把多日回放限制为最多 7 天；多日先按天呈现 Journey，再进入具体行程。这支持本项目采用“默认今天 + 单次最多 7 天 + 明确覆盖边界”，避免把无限时间窗的最新切片误读成全量。参考：https://reveal-help.verizonconnect.com/hc/en-us/articles/1500004436922-View-a-vehicle-or-asset-s-journey-in-Replay
• Reveal 的时间轴按 Moving、Stopped、Idling 分段，并在详情中展示时间、时长、行驶距离、地址和驾驶事件。本项目 vehicle_locations 没有 ignition，所以只把低速小位移称为“GPS 推断停车”，不冒充熄火/怠速；数据间隔作为独立分段。参考：https://reveal-help.verizonconnect.com/hc/en-us/articles/360010566999-View-all-of-your-vehicles-and-assets-in-Replay
• Reveal Spotlight 的 Journey Summary 同时展示距离、行驶时间、停车次数、停车时间，详细时间轴能下钻到停车位置、移动段和超速点。因此本项目轨迹摘要增加移动/停车时长、停车/分段数，关键事件与分段边界必须在地图抽稀后仍能精确定位。参考：https://reveal-help.verizonconnect.com/hc/en-ca/articles/1500003198622-Review-a-vehicle-or-asset-s-activity-with-Replay-in-Spotlight
• 停车时长阈值是产品配置而非自然事实。Reveal 报表允许隐藏小于指定分钟数的停车；本项目一期先采用 3 分钟固定门槛并在 API 证据中公开，后续再进入可版本化配置。参考：https://reveal-help.verizonconnect.com/hc/en-us/articles/360050801533-Travel-and-stops-report

2026-07-14 大数据导出对标

• Geotab 官方 GetFeed 用持久化 toVersion/fromVersion 游标连续读取数据，并明确要求客户端保存版本令牌以便停止后无缝继续；单次通常最多 50,000 条。这验证了大历史数据应采用单调游标而不是越来越慢的 OFFSET。本项目一期对 TDengine 采用 (ts, protocol, frame_id) 复合前向游标和 5,000 行批次，先保证单 ECS 的稳定内存边界；多实例阶段再把任务与游标迁移到数据库队列。参考：https://developers.geotab.com/myGeotab/guides/dataFeed/index.html 和 https://developers.geotab.com/myGeotab/apiReference/methods/GetFeed/index.html
• Geotab 还建议“批次达到上限就立即继续、少量或空批次再退避”，说明进度必须来自服务端已处理记录而不是前端估算。本项目任务卡展示 processedRows/totalRows，每个成功批次才持久化进度。
• Samsara 的车队报表 API 把报表类型、时间范围和 RFC3339 时区作为显式合同，而不是导出当前页面偶然加载的行。本项目 CSV 因此写入查询起止时间、车辆范围、数据类型、协议和指标单位元数据，并使用带时区的绝对时间查询 TDengine。参考：https://developers.samsara.com/reference/getfuelenergyvehiclereports

本项目采用的产品原则

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

当前迭代落点

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