在2011年交通部的796标准推出后,随着各地交管部门的硬性要求,大多数的GPS监控系统或者车辆管理系统或者物流管理系统,无论是旧的,还是新开发的,都必须要以796标准为基础蓝本,首先要满足796的要求,然后在此基础上增加行业应用的个性化要求,如物流运输车辆非常关心的油耗管理,冷链运输非常关心温度控制等等. 所以开发GPS平台的时候,必须要首先阅读交通部的jt/t 796 , jt/t808和jt/t809的文档,以此作为自己的功能设计的需求来源,行业需求或用户需求是排在后面的.很多开发团队做出…

基于交通部796标准开发部标监控平台,选择开发语言和技术也是团队要思考的因素,其实这由团队自己擅长的技术来决定,如果擅长C#和Asp.NET, 当然开发效率就高很多.当然了技术选型一定要选用当前主流的技术,现在Asp.NET技术已经发展到5.0, 如果你还是用旧的ASP技术写程序,无疑是为以后的项目维护埋下地雷,后面新来人手学习不到技术,没有兴趣去改进,不愿意维护,没有人愿意接手.代码最关键的是要不断的重构,保持与当前的技术和需求同步,平台才有生命力,否则就会越来越臃肿而变得难以维护.开发一个基…

最近一个客户要求将gps部标平台移植到bootStrap框架作为前端框架,符合交通部796部标只是他们的一个基本要求,重点是要和他们的冷链云物流平台进行适配.我自己先浏览了客户的云物流平台的界面,采用的是bootStrap框架,自适应页面大小,基于html5开发,界面设计非常的简洁,清爽,冷色调,有点像苹果或者锤子的官方商城页面,这样可以快速的关注到自己想看到的内容.不像传统的物流网站千人一面,充斥着大量的物流广告还配有slider动图效果让人眼晕,显得很cheap. 显然如果直接将一个以后台数…

部标gps监控平台的架构,随着平台接入的车辆越来越多,架构也面临越来越大的负载挑战,我们当然希望软件尽可能的优化并能够接入更多的车辆,减少在硬件上的投资.但是当车辆增多到某一个临界点的时候,仍然要面临的三个问题: 1)连接的限制 服务器软件接入终端的连接数是有限的,无论如何优化,都是有限的,接入的增多就会排队,超时timeout重置reset等问题就会出现; 2)部标808服务器软件的内存限制的问题 内存的限制,服务器操作系统中一个进程所承受的内存是有限制的,超过则导致服务器软件进程内存溢出而退…

部标监控平台的压力测试是部标检测流程的最后一个检测环节,也是最难的,很多送检的企业平台都是卡壳在这一个环节.企业平台面临的问题如下: 1.对于压力测试的具体指标要求理解含糊,只知道是模拟一万辆车终端进行数据包传输,不知道具体的检测标准是那些指标,等进京考试后落榜了,才知道压力测试失败了,这个时候,还要通知后方的同志改进,耽误的时间和差旅费用成本惊人.很多检测人员需要在京住上几十天,算算得多少钱.因为不知道方向,所以改进也是盲目改进,不知道行不行,应付任务再次送检,也是摇骰子,祈求上天让我们通过吧…

总体来讲,GPS部标平台的软件开发是一个对网络通信和应用程序之间通信的技术应用密集型的开发工作,也是有一定设计技术含量的工作. 1.设计通信接口 在设计的时候,根据职责划分,拆分成不同的应用子系统,对各个子系统进行功能隔离,并通过设计接口规定子系统直接的调用规约. 首先我们根据部标平台的要求,设计和开发出各个主要的服务器子系统,这是平台中最核心的子系统,在实际的应用中,由于车辆规模的大小和行业需求,还会扩展出各种业务子系统.核心子系统如下: 1)808GPS服务器,采用交通部的部标808协议,负…

现在地方上由于运输车辆的GPS数据都分散在地方上已有的各种企业平台上面,不利于大数据的分析和智能应用,而开发智能的基于大数据的Gps监控平台,往往需要和各种第三方的部标GPS监控平台对接,获取到第三方的企业平台转发的数据,然后进行大数据的分析和应用,经过分析.统计和梳理后的数据,在web页面上进行各种复杂的地图.报表统计等功能的展现. 由于各地的企业平台基本都是符合交通部部标标准的,都具备809协议的转发功能,要和这些企业平台对接,不需要再一个一个的敲定接口标准了,只需要开发出809协议的网关应…

部标1078视频监控平台,是一个庞杂的工程,涵盖了多层协议,部标jt808,jt809,jt1078,苏标Adas协议等,多个平台功能标准,部标796标准,部标1077标准和苏标主动安全标准,视频方面的协议有RTSP, RTMP, RTP, 音视频编码有H.264, AAC,  726,711等,消化这些协议和功能标准就已经是需要一个较长的周期了,而构建一个视频平台的架构,也是比较复杂的,后端不仅有网关,还要有流媒体服务器,转发服务器,播放器,RTSP或RTMP服务器等多个服务器模块,需要的技术…

基于C#和Asp.NET MVC开发GPS部标监控平台 目前整理了基于.NET技术的部标平台开发文章,可以参考: 1.部标Jt808协议模拟终端的设计和开发 2.C#版的808GPS服务器开发->基于部标JT/T 808协议及数据格式的GPS服务器 3.C#版的809GPS服务器开发->基于JT/T809-2011的(已过检)GPS平台数据交换及转发服务器 4.Asp.NET版的部标平台开发->基于Asp.NET MVC构建GPS部标平台 5.基于C# winform桌面客户端的部标平台…

设计和开发一个GPS系统似乎并不太难,很多人马上就想到了地图,放大,缩小之类的功能,最多就是在加点报表之类的东西,就成了. 这种观点造成了业界内,很多GPS系统粗制滥造,不堪大用. 事实上,设计和开发一个GPS平台往往耗费数年时间,虽然这不是客户和领导所期望的,但是往往都摆脱不了三年周期的宿命: 第一年满足基本需求能够稳定下来已经很不错, 第二年增加差异化.个性化.有市场竞争力的功能,让平台功能壮大,提升用户体验: 第三年随着功能的堆砌,数据量的增大,接入车辆的增多,需要对平台进行较大规模的重构…