关闭

终于找到问题所在了,原来不是程序问题,而是数据质量问题

标签: 报表工作服务器算法通讯任务
954人阅读 评论(0) 收藏 举报
分类:

本篇仅仅是本人工作中的感想,非做本行业软件人员看不明白的

我写的服务程序,任务有如下:

1、接受通讯服务器得自车辆的消息

2、分析消息,并按消息类别保存

3、自动划分班次,即车辆来的消息,是线性的,服务要根据线路各个站点的拓扑关系,将线性发上来的消息,按段分割,使其分属不同的班次

      当掉头,并且掉头后报上来的站点多于一个站点,则理解为掉头,原来班次结束,新班次开始;

      当到达终点站后,再报上来始发站消息,则将首次报始发站前的消息,归结为前一班次,后面的为新班次。

4、对于停车消息:

      a> 须整理上下车、留车人数

      b> 须将每次停车,归属于某个班次

5、实时统计技术指标

      断面按小时统计平均需用时间

      断面按小时统计留车人数

      断面按小时统计通过次数

      站点按小时统计上下车人数

。。。

      原来,断面车距与通过班次 的报表,显示的各个站点按时间段的通过差别很大,这肯定是有问题,因为,在一天内,除去中途掉头的特殊情况外,各个站点通过的班次,应该是一样的,而不同时间段即便有差别,也不会太大,并且应该是按照站点顺序线性分布的,可报表显示,各个班次无规律差别很大。

      本周的工作,就是修改服务,以解决此问题,幸亏服务有消息录放机,可以快速(约半小时可以播放并处理一天的数据)地模拟出一天的车辆消息,即便如此,也是修改了n次,模拟了n次,检查了n次报表,还是无果。

      终于,在今天半夜,找到了问题症结:数据源----车辆发来的消息有问题,在一个班次中间,会多次错报反方向站点的信息。

       虽然找到问题来源,但要解决,还是很困难,或者修改车辆终端的程序,或者试着修改兴趣点,或者上层服务来通过算法屏蔽这种情况。

      修改底层程序,需要时间可能会很长;

      检查是否兴趣点设置不合适,或许是最容易解决的方法;

      修改服务屏蔽这种错报,也比较麻烦,因为,这样的话,就不能实时分析统计了。如怀疑某个消息错误,则必须在其后续报上来的多个消息,最多要等到下个站点的消息上来后才能确定是真的掉头还是错报,这样的话,就必须也要阻塞本车辆后续消息的分析、怀疑错报站点的其他车辆报该站点的消息的分析。

      明天将问题提交,再由领导确定如何解决吧。

0
0

查看评论
* 以上用户言论只代表其个人观点,不代表CSDN网站的观点或立场
    个人资料
    • 访问:82778次
    • 积分:1191
    • 等级:
    • 排名:千里之外
    • 原创:36篇
    • 转载:2篇
    • 译文:0篇
    • 评论:29条
    文章分类