让视频、ADAS 告警与驾驶行为进入决策：行车记录仪数据接入的三层架构

设备上线只是开始。如何把视频、ADAS 告警与驾驶行为接入车队视频平台、保险风控与 TMS，建立告警、报表与闭环，是行车记录仪项目真正的分水岭。

架构：设备、边缘、平台三层

行车记录仪项目的数据链路通常分为三层：设备负责采集视频、ADAS 告警与驾驶行为；边缘层负责协议解析、缓存与本地规则；平台层负责存储、告警、报表与业务集成。三层各司其职，任何一层都不应该承担不属于它的职责。

如果设备直接连业务系统，短期看很快，长期会失控。建议设备统一接入物联网平台，再由平台向车队视频平台、保险风控与 TMS提供稳定的数据服务。

• 设备层：通过 4G / Wi-Fi / CAN 上报原始数据，保留设备编号与时间戳。
• 边缘层：做单位换算、异常过滤、断网缓存和本地联动。
• 平台层：做资产模型、告警规则、权限、审计与 API。
• 业务层：把事故率、急刹/疲劳事件与理赔周期嵌入车队视频平台、保险风控与 TMS的日常流程。

数据模型先于大屏

大屏是最容易做、也最容易过时的部分。先定义资产模型：一个“设备”属于哪个“场区”、哪个“资产”、由谁负责、当前状态是什么。模型稳定后，大屏、报表和告警都可以复用。

以行车记录仪为例，至少需要四类对象：场区、资产、设备、事件。每类对象有唯一编码和生命周期，设备更换时只迁移绑定关系，不丢历史数据。

告警不是越多越好

一线人员很快会对高频、低价值的告警脱敏。设计告警时，先问三个问题：这条告警对应什么动作？谁负责？多久内必须处理？答不上来的，先不要上线。

建议把告警分为三级：提示、需要关注、必须处置。只有“必须处置”才触发电话或强提醒，其余进入日报或工作台。每季度复盘一次误报率，持续收敛规则。

• 把事故取证难、疲劳驾驶、盲区与理赔纠纷拆成可观测的信号，而不是直接映射成告警。
• 为每条告警定义明确的处置动作和责任人。
• 设置合理的持续时长与恢复条件，避免抖动刷屏。
• 把处理结果写回事件，形成可统计的闭环率。

从一个可衡量的试点开始

不要从“全量上线”开始。选择一个场区、一个班组、一个明确的事故率、急刹/疲劳事件与理赔周期指标，运行 4–6 周，形成前后对比。

试点结束后，用三个问题决定是否扩展：数据是否被真实使用？异常是否被更快处理？一线是否愿意继续用？如果答案是否定的，先修流程，再谈扩容。

1. 选定一个基线清晰、痛点具体的场区。
2. 定义 1 个主指标和 2 个辅助指标。
3. 打通设备到业务系统的最小闭环。
4. 每周复盘一次数据质量与告警处理。
5. 用结果而不是功能清单，决定下一阶段投入。