这个项目难在哪
每个案例的难点都不一样。先把难点说清楚,方案才有意义。
车辆装了定位,但轨迹数据没人看,因为一条轨迹说明不了这趟出车合不合规
加油卡消费记录和车辆里程对不上,但没有基线,说不清差多少算异常
非工作时间出车分不清是公务还是私用,一刀切禁止会把应急处置也卡死
三十多个用车单位的派车流程不统一,有的走纸质单,有的走 OA,有的口头派车
项目背景:定位装完了,然后呢
这是一个地市本级的公务用车监管项目,纳管 200 余台车,涉及 30 多个用车单位,包括机要通信、应急保障、执法执勤、接待调研等不同用途。
项目启动前,绝大部分车辆已经装了北斗定位终端。上级的要求是「实现公务用车全流程监管」,落到纸面上就是几个指标:车辆在线率、轨迹完整率、派车单覆盖率、违规用车数量。
接手之后发现一个尴尬的事实:**定位数据每天都在产生,但没有任何一个人在用它做判断。** 车管科的人偶尔打开看看某台车在哪,仅此而已。原因很简单——一条轨迹只能说明「这台车某时某刻在某个坐标」,它不能回答「这趟出车该不该发生」。
所以这个项目真正要解决的不是「怎么定位」,是「**怎么让轨迹变成能用来判断的东西**」。
难点一:轨迹不是证据,派车单才是锚点
一条从单位出发、经过市区、到达某小区、停留两小时、返回单位的轨迹,它合规吗?
单独看这条轨迹,永远判断不了。如果这两小时是去某局送文件,合规;如果是接送孩子,不合规。**区别不在轨迹里,在单据里。**
所以平台的核心设计是:**以派车单为锚点,让轨迹去匹配单据**。没有派车单的出车,本身就是一条异常记录;有派车单但轨迹偏离,是另一条异常记录。
| 比对维度 | 数据来源 | 异常判定 |
|---|---|---|
| 是否派车 | 派车单系统 | 有轨迹无单据 → 未派车出车 |
| 出车时间 | 派车单 vs 首次点火 | 实际出车早于审批时间 30 分钟以上 |
| 行驶路线 | 派车单目的地 vs 轨迹路径 | 轨迹经过点与申请路线偏离且无合理说明 |
| 返回时间 | 派车单预计 vs 实际入库 | 超时未归且无延时申请 |
| 使用人 | 派车单驾驶人 vs 实际驾驶 | 非申请驾驶人操作车辆 |
这套比对逻辑不难,难的是**派车单从哪来**。30 多个单位的派车流程完全不统一:一部分走 OA 审批,一部分还在填纸质派车单,还有一部分是科室负责人打个电话就派车。
项目的做法是分层处理,不追求一步到位:
- 1**能对接的对接**。走 OA 的单位,通过接口把派车单实时同步过来,这是最理想的情况。
- 2**不能对接的补录**。纸质派车的单位,驾驶员出车前在移动端补一条派车记录,扫车牌、选目的地、填事由,30 秒能填完。
- 3**完全不配合的先标记**。对于暂时不愿改流程的单位,平台仍然采集轨迹,但在报表里标注「该单位派车单覆盖率为 0」,把这个数字摆在领导看的页面上。
第三层看起来是妥协,实际是最有效的一招。监管平台最怕的不是数据不全,是数据不全还没人知道。把覆盖率做成排名公示,比发十份整改通知管用。
难点二:加油卡和里程对不上,但说不清差多少算异常
公车监管里最容易出问题、也最难查实的是油。一辆车一年加多少油、跑多少公里,理论上有个油耗比。但实际算起来全是坑:
- **车型差异大**。同一批车里既有 1.6L 轿车也有 3.0T 越野,百公里油耗差一倍,不能用一个标准卡。
- **路况差异大**。市区拥堵和高速长途,同一台车油耗能差 40%。
- **加油记录不全**。有的车在单位内部油库加,有的在加油站刷加油卡,有的临时现金加油后补报,三套数据对不上。
- **里程表读数靠人填**。驾驶员每月报一次里程,报多报少没人核。
所以「油耗异常」不能靠一条公式判定。平台用的是**同车型横向对比 + 单车纵向趋势**两条线:
| 分析方式 | 做法 | 能发现什么 |
|---|---|---|
| 同车型横向对比 | 同型号车辆按季度算百公里油耗,取中位数 | 某台车明显高于同型车,可能存在问题 |
| 单车纵向趋势 | 同一台车与上一季度、去年同期比 | 油耗突然抬升,可能是车况或使用问题 |
| 加油量与里程匹配 | 两次加油间的里程增量 vs 加油量 | 加油量与行驶里程严重不匹配 |
| 加油地点异常 | 加油卡消费地点 vs 车辆当时位置 | 车在 A 区,卡在 B 区加油站消费 |
第四条是最硬的证据。**车在城东、卡在城西加油站刷了 400 块**,这种记录不需要任何模型判断,直接就是异常。这一条能查出来的问题,比所有油耗模型加起来都多。
但要实现这一条,必须把加油卡的消费流水接进来,而且要有消费时间戳和加油站坐标。很多地方的加油卡数据在石油公司手里,协调难度不小——这是项目里花时间最多的一件事,不是技术问题。
别急着定性,先分级
所有稽核结果分三级:**提示、预警、待核查**。加油量与里程偏差在 15% 以内只做提示,15% 到 30% 预警,超过 30% 或者出现地点矛盾才进待核查队列。
分级的意义在于控制核查工作量。如果所有偏差都推给车管科,一天能推几百条,最后没人看。**监管系统的死法不是查不出问题,是推得太多没人处理。**
难点三:夜间出车,一刀切会把应急处置也卡死
非工作时间用车是最敏感的场景。很多地方的做法是简单粗暴:工作日 18 点到次日 8 点、周末全天,只要出车就报警。
这个规则上线第一周就会被打爆。因为真的有事:半夜防汛调度、凌晨突发事件、周末接待上级检查。这些用车都是合规的,但如果每次都要写说明,用车单位很快就会学会「提前把车开出去停在外面」,反而更失控。
平台的做法是**把非工作时间出车拆成四类,分别处理**:
| 类型 | 特征 | 处理方式 |
|---|---|---|
| 应急保障 | 有应急事件编号或值班记录 | 自动放行,事后补单 |
| 值班备勤 | 车辆属于值班序列,停在值班点 | 不报警,只统计 |
| 临时公务 | 有派车单但时间在非工作时段 | 正常记录,不报警 |
| 无单出车 | 非工作时段出车且无任何单据 | 进待核查队列,次日推送 |
关键在第一类。**应急用车不能事后追责,只能事前备案。** 平台跟应急指挥系统打通,有应急事件编号的车辆自动进入放行名单,不需要任何人审批。这条打通之后,用车单位的抵触情绪明显下降。
还有一个必须做的东西:停放点
车辆夜间停在哪,比白天去了哪更能说明问题。平台给每台车维护一个「常停点」,通过历史轨迹自动算出夜间最常停留的位置。如果某台车连续多天夜间停在住宅小区而不是单位或指定停车点,这就是一条需要核实的记录。
常停点是自动算的,不需要人工维护。算法很简单:统计每台车在 20 点到次日 7 点之间停留超过 4 小时的位置,取出现频次最高的坐标,按 200 米半径聚簇。
技术侧:双模定位与断点补传
定位这块有两个工程问题必须解决,否则数据根本不可用。
问题一:地库和隧道的定位空洞
北斗定位在室内、地下车库、隧道里没有信号。一台车进了地库停三小时,出来才重新定位,中间那段轨迹是空的。如果只看轨迹,会误判成「设备故障」或「轨迹异常」。
平台用的是**北斗 + 基站辅助定位**双模。地库里北斗没信号时,靠基站和 WiFi 指纹给出一个精度 50 到 200 米的粗略位置。这个精度不能用来判断「停在哪栋楼」,但足够判断「在不在单位范围内」。
另外对「轨迹中断」做了单独的标记,不跟「轨迹异常」混在一起。中断是技术问题,异常是管理问题,混在一起会制造大量误报。
问题二:山区和信号盲区的数据补传
这个地市有部分县域在山区,通信信号覆盖不全。终端在无信号时会本地缓存轨迹点,恢复信号后补传。补传的数据要带原始时间戳,不能按补传时间入库,否则轨迹会乱序。
平台在入库时按时间戳排序,并且对「时间戳早于已入库最新点」的补传数据做插入处理,不是追加。这一点如果做错,历史轨迹看起来就像车在来回跳跃。
12 类稽核规则,按可查实程度排序
规则不是越多越好。平台上线时定了 12 类,排序原则是「**能直接查实的排前面,需要推断的排后面**」:
| 优先级 | 规则 | 查实难度 |
|---|---|---|
| 高 | 加油地点与车辆位置矛盾 | 直接可查,证据明确 |
| 高 | 同一时间同一车辆两条轨迹 | 数据冲突,需查设备 |
| 高 | 非工作时间无单出车 | 单据缺失,容易核实 |
| 中 | 轨迹偏离申请路线且无说明 | 需结合实际路况判断 |
| 中 | 常停点连续多日为住宅区 | 需核实居住情况 |
| 中 | 派车单申请人与实际驾驶人不同 | 需查审批流程 |
| 低 | 油耗高于同型车中位数 30% | 需排除路况与车况因素 |
| 低 | 月度里程与加油量不匹配 | 需排除补报漏报 |
排序的实际意义是:**车管科只有两三个人,只能处理前面几条。** 把高优先级规则的准确率做到 90% 以上,比把 12 条规则都做到 60% 有用得多。
几条可以带走的判断
- **轨迹不是证据,单据才是锚点。** 没有派车单的轨迹只是一堆坐标,判断不了合规性。做公车监管,第一件事是把派车流程电子化,不是装定位。
- **派车单覆盖率要公示,不要私下催。** 把各单位的覆盖率做成排名摆在领导页面上,推进速度比发通知快十倍。
- **加油地点与车辆位置矛盾,是最硬的证据。** 这一条查出来的问题,比所有油耗模型加起来都多。但它依赖加油卡流水的对接,是协调工作不是技术工作。
- **非工作时间出车不能一刀切。** 应急用车必须事前备案自动放行,否则用车单位会想办法绕开系统,反而更失控。
- **常停点比行踪更能说明问题。** 夜间连续多日停在住宅小区,这条记录的价值高于任何白天轨迹分析。
- **监管系统的死法不是查不出问题,是推得太多没人处理。** 规则要分级,把核查量控制在车管科能消化的范围内。
- **轨迹中断和轨迹异常必须分开。** 地库没信号是技术问题,绕路是管理问题,混在一起会制造大量误报,最终让系统失去信任。
用到的技术
这些技术在其他项目里也用过,完整的协议支持清单和已实测规模见技术能力
有类似的项目?
把你的现场情况说清楚就行,不用先写需求文档。我们会告诉你从哪切入最划算、哪些环节其实可以不花钱。