GPS部标平台的架构设计(九)-GPS监控客户端设计

交通部的部标过检,所有的测试都是从客户端发起的,也是在客户端体现的,在客户端承载了部标标准所要求的所有的功能,是整个部标平台当中工作量最大的部分,也是最繁琐的部分。

客户端设计面临两个问题:

1.基于CS还是基于BS,这是个问题

萝卜白菜各有所爱,客户要什么,我们就开发什么,从客户来讲,更适应桌面客户端,没有浏览器的七七八八问题,速度感觉上也比网页的快,操作方便。当然网页客户端也有很大的优势,部署和维护方便,不需要开发升级系统。

2.与服务端的交互通信,采用Socket, WebService还是WCF,这也是个问题

WebService的性能很差,这个基本上不考虑,Socket效率高,但开发效率低,难以维护,WCF是面向服务(Service Oriented)应用程序的统一框架,非常灵活,它可以跨进程、跨机器、跨子网、企业网乃至于 Internet;以宿主程序而论,可以以ASP.NET,EXE,WPF,Windows Forms,NT Service,COM+作为宿主(Host)。WCF可以支持的协议包括TCP,HTTP,跨进程以及自定义。

所以采用WCF框架,将传统的GPS软件转向了面向服务的GPS平台。通常我们在服务端,采用windows服务作为WCF的服务端宿主,采用tcp/ip协议作为传输协议,使得远距离互联网数据传输的性能大大提高,桌面客户端采用windows forms 作为wcf 客户端的宿主。客户端通信设计,参见:基于WCF的GPS平台数据通信设计

确定了两个问题后,开始确定两个设计:

1.服务端接口设计

面向服务开发,首先就要确定服务端为客户端提供什么样的服务,比如报警推送服务,报表分页查询服务,实时数据推送服务,基础数据服务,终端命令服务等。

2.客户端功能和界面设计

客户端的功能和服务端的接口是相辅相成的,功能的设计业决定了界面如何设计。

可以说部标平台的复杂性在于交互的复杂性,很多人对于开发的乐观,是因为在开发初期,无法清晰的看出具体的交互设计,更不能明确的估算工作量,由于交互,客户端的设计和服务端的设计是互相影响的,客户端增加一个功能,往往面临着服务端、通信端的功能逻辑的改变,虽然我们竭力从设计上采用面向服务的设计、面向对象的开发,仍然避免不了这种交互带来的互相影响和工作量的增加、测试难度的增加。购买部标平台源码联系[email protected]

GPS软件界面设计,参见:GIS、GPS和视频监控界面设计

下面着重说下功能设计。

功能模块主要包括:

1.地图操作

主要包含了拉框放大、缩小、测距、电子围栏、标注、历史轨迹、区域查车等功能,当然了还有些依赖于地图的附加功能。

我们采用基于GMap.NET SDK来作为地图引擎,可以灵活的采用和切换谷歌地图、高德地图等,采用local cache的模式,浏览过的地图图片将会被存储在本地硬盘当中,提升了用户浏览地图的用户体验。GMap.NET具体开发参见:GMap.NET二次开发

对于地图的电子围栏坐标,我们采用地图算法库,直接转换为原生的GPS坐标,存入数据库中,这样便于电子围栏算法模块的判断和分析。

2.终端命令下发

包含了部标808标准中所要求的所有的指令下发功能,以可视化的形式提供给用户操作。

终端命令很多,大部分是用户不常用或不需要的功能,但又是必须的,或者是部标过检必须的,所以设计时,需要要考虑权限功能限制的可伸缩的功能布局。

终端命令下发的用户体验设计也是比较有难度的,从命令下发、服务器执行下发给终端、终端执行后应答、数据上传最后反馈到客户端界面,是个时间未知的异步过程,必须要设计一个超时跟踪的定时器跟踪命令状态,来给用户一种同步的命令执行的感觉,在点击按钮后,可以跟踪到命令执行的最终状态。部标808指令的开发参见:基于部标JT/T 808协议及数据格式的GPS服务器

3.报表查询

部标中规定的所有的报表都需要显示在客户端,提供各种组合查询条件,当然了像BS网页客户端一样,也需要考虑分页查询和报表导出。

4.数据管理

平台所需要的用户、角色、权限分配、基础数据管理、车辆、车组、业户的管理、参数设置这些增删改查的功能,也必须要做入到客户端中;

5.报警推送

报警定义、报警推送、报警处理、报警弹窗声音地图展示的功能。

6.实时数据

实时数据的推送、状态刷新、地图显示等功能

7.图表

各种统计报表以柱状图、曲线等图表的形式显示出来,比如上线率统计、车速曲线图、油耗曲线图等。

8.运管平台对接

平台能够响应政府平台基于交通部部标809协议下发的岗位巡检指令,上报到政府平台。平台在收到车辆上报动态位置信息后,即刻向政府平台实时上报车辆的位置、状态信息和报警信息,响应政府平台对车辆的拍照和监听等车辆远程控制指令,并显示政府平台下发信息。809的开发,参见:基于JT/T 809-2011的(已过检)GPS平台数据交换及转发服务器

时间: 2024-10-06 23:46:12

GPS部标平台的架构设计(九)-GPS监控客户端设计的相关文章

GPS部标平台的架构设计(四)-百度地图设计

部标GPS软件平台之百度地图设计 地图是客户端中不可缺少的一个模块,很多人在设计和画图时候,喜欢加上地图引擎这样高大上的字眼,显得自己的平台有内涵,说白了就是用第三方的SDK来开发,早期的GPS监 控软件用的都是mapx.mapxtrem.acrgis之类的,使用的都是本地地图.不仅要购买正版地图,还要购买价格不菲的地图引擎license,服务器版的部署的时候,还要绑定到服务器ID上,现在这种开发方式已被抛弃.现在的百度地图.谷歌地图提供的SDK接口丰富,开发方便,系统稳定,大家都用的很爽. 在

GPS部标平台的架构设计(十)-基于Asp.NET MVC构建GPS部标平台

在当前很多的GPS平台当中,有很多是基于asp.NET+siverlight开发的遗留项目,代码混乱而又难以维护,各种耦合和关联,要命的是界面也没见到比Javascript做的控件有多好看,随着需求的增多,平台已经臃肿不堪. 设计基于.NET的GPS部标平台,我们坚定不移的选择了基于JQUERY+Asp.NET MVC来作为前端交互和后台处理的框架.选用一个灵活的脚手架,同时团队又能掌握这个脚手架为团队所用. 对于一个web应用项目,基于MVC的框架,前面文章提到过,最大的优点就是结构清晰,强制

GPS部标平台的架构设计(六)-Android手机客户端和手机查车设计

对于GPS软件平台,虽然有功能非常丰富的PC端或BS客户端,但是客户也是需要移动客户端来作为自己的辅助工具,也是需要的.做为GPS平台的设计者和开发者,在开发移动客户端的时候,也需要从常规的服务器开发和客户端开发的思维中,转变过来,当然客户的需求也需要转变,因为毕竟不能随心所欲的将PC端的所有功能需求照搬到手机客户端,手机的开发环境.网络环境.使用环境都决定了设计理念与PC端的设计是完全不一样的. 通常我们成为GPS部标平台的手机客户端为手机查车,实际上现在的功能不仅仅是查车,由于客户需求的推进

GPS部标平台的架构设计(五)-地图服务算法库

GPS平台,需要和各种地图打交道,需要解决以下的问题: 1.坐标偏移,这个不用多说,需要将原始坐标加偏,然后在百度地图或谷歌上显示出来,需要注意的是百度地图的加偏是偏上再偏,谷歌.高德地图等是火星坐标: 2.坐标解偏,或者纠偏,这个我们也是需要的,因为当用户在地图上画出的各种区域,标注,发送到后台存储的坐标都是基于地图所采用的坐标系统,因而是偏移的,这就面临一个严重的问题,因为在部标808协议中,对于区域报警,需要将区域的顶点坐标,下发给终端,终端在实际运行中,不断用GPS坐标和区域坐标进行比对

GPS部标监控平台的架构设计(八)-基于WCF的平台数据通信设计

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

基于BootStrap框架构建快速响应的GPS部标监控平台

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

GPS部标监控平台的功能设计(一)-功能列表

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

交通部796部标平台开发索引

1.为什么部标平台的开发周期长? 1)首先对于交通部部标标准文档的阅读.理解和消化需要很长时间,你面对的是冷冰冰的交通部信息中心颁发的jt/t 796.808.809协议文档,面对文字的歧义,这个消化.曲解.走弯路的时间成本,伴随在整个软件开发周期当中,一直到你进京赶考,进行部标检测,最终过检.所以这个时间是无法估计的,理解完毕,将理解的文档转化成开发团队必须要完成的功能用例,中间的误差极大,这也是很多开发者容易自信.乐观冒进的原因. 你必须需要阅读和理解的协议文档有四份: 796文档.808协

数据交换平台的架构设计

序言 说到架构设计,不敢妄自牛逼.只能默默地向Linux致敬,没有强大的linux系统,我们做的架构设计,做的程序一天说不定挂几次.(windows系统就不说了,呵呵) 数据交换平台的架构发展 架构不是一蹴而就的,是随着团队技术能力的积累,随着公司数据平台的逐步完善,随着相关开源产品的深入学习,逐步形成和进化的. 不同阶段,需要不同的架构.因此,不能单纯地说,哪个架构就好,哪个架构就不好.只要适合当时的环境,就是最好的.对公司业务的发展,对其他模块的项目支撑,没有起到约束和限制的作用,就OK.如