交通部的部标过检,所有的测试都是从客户端发起的,也是在客户端体现的,在客户端承载了部标标准所要求的所有的功能,是整个部标平台当中工作量最大的部分,也是最繁琐的部分。
客户端设计面临两个问题:
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平台数据交换及转发服务器