沈阳交通部794认证优势*

5.7 通话

终端可具有电路域通话功能和通话管理功能，包括通话限制、语音存储、电话簿管理、电话回拨、

音量调节、来电自动摘机。终端通话功能应符合以下技术要求：

——通话时将需要上传的数据保存，通话结束后上传；

——终端电话簿应具有不少于 20 名联系人的存储容量；

——终端可由监控中心设定只允许呼入号码和只允许呼出号码。

5.8 休眠

终端应具有车辆 ACC 点火检测功能，当车辆熄火后终端向监控中心发送车辆熄火信号并自动进入

休眠状态。终端在休眠状态下应满足以下技术要求：

——关闭除无线通讯模块外其它不必要设备，卫星定位模块在需要上传时自动唤醒；

——数据上传频率可由监控中心远程设置或者按照初始化时设置的参数自动持续降低数据上传频

率；

——终端应在电瓶欠压报警后，转由内置备用电池供电，在内置备用电池电量用完时自动关机；

——终端在休眠期间，其平均功率不**过 2w。

5.9 警示

终端触发警示时应立即向监控中心上传警示信息或根据需要向*手机发送短消息警示信息，并能

接收监控中心指令取消警示，警示手机号码可由监控中心远程设置。当监控中心依据车辆上传的车辆位

置信息、状态信息或者安全监管需要向终端下指令时，终端应以语音报读方式，可结合声、光、文字等

方式向驾驶员提示警示信息。

终端警示功能分为人工报警与自动提醒：

a) 人工报警是驾驶员根据现场实际情况触发的报警，应包括：当遇到抢劫、交通事故、车辆故障

等紧急情况，驾驶员通过触动应急报警按钮向监控中心上传报警信息，同时关闭语音报读模块。

如果终端具有图像、视频、音频采集功能，应立即启用该功能。人工报警应具备防止误操作功

能。 

7

b) 自动提醒是驾驶员不对终端进行任何操作，终端根据监控中心设定的条件触发，应包括以下内

容：

1) 区域提醒：终端中应存储有不少于 24 个多边形或圆形区域，当车辆驶入禁入区域或驶出

禁出区域时触发，监控区域可由监控中心远程设置；

2) 路线偏离提醒：终端中应存储有不少于 24 条路线，每条路线应是 16 个或以上点构成的折

线。当车辆驶离设定的路线时触发，监控路线可由监控中心远程设置；

3) **速提醒：终端可根据预设的速度阈值或通过接收监控中心下发的信息触发，以提醒驾驶

员当前处于**速状态；

4) 疲劳行驶提醒：车辆或者驾驶员连续驾驶时间**过疲劳驾驶时间阈值时触发，疲劳驾驶时

间阈值可由监控中心远程设置，默认为 4h；

5) 电瓶欠压提醒：终端检测车辆电瓶电压低于预设值时触发，同时终端须停止从车辆电瓶取

电，转由终端内置备用电池供电；

6) 断电提醒；终端在被切断主供电源时触发；

7) **时停车提醒：停车时间**过系统预设时间时触发；

8) 终端故障提醒：当终端主机及与终端主机连接的外部设备工作异常时触发，并上传至监控

中心。

9) 碰撞提醒：当终端检测到强力碰撞时触发预警，触发后终端应采用较小报送时间间隔上传

车辆状态及定位信息，以便监控中心确认碰撞提醒。

10) 侧翻提醒：当终端检测到侧翻时触发预警，触发后终端应采用较小报送时间间隔上传车辆

状态及定位信息，以便监控中心确认侧翻提醒。

5.10 终端管理

终端应支持无线网络远程方式实现终端在监控中心注册和注销功能、固件更新功能、固件参数的修

改和查询功能、终端的复位或恢复出厂设置功能。固件更新、参数修改过程中遇到掉电等意外情况时应

支持自动恢复功能，保证更新失败时终端能够正常使用。同时固件更新和固件参数修改功能也应支持本

地（SD卡、USB或其它数字接口）方式实现。

终端可同时支持通过USB口和串口对终端进行设置和输出。

5.11 人机交互

终端应具有人机交互功能，与驾驶员进行信息交互。终端应能通过语音报读设备与显示设备，可结

合信号灯或蜂鸣器等设备向驾驶员提供信息，驾驶员能通过按键或触摸屏或遥控器等方式操作终端。

货运车辆终端的显示设备应不小于5英寸，并支持触摸输入方式，可采用外接或内置的形式。

5.12 信息服务

终端可具有以下信息服务功能：

——终端应支持驾驶员主动上报信息以及监控中心直接下发信息，并进行分类管理；

——终端应支持语音报读和弹出窗口方式显示**下发的通知公告类信息；

——终端支持监控中心直接下发信息以及驾驶员主动上报信息；

——终端可通过显示设备、语音报读设备向驾驶员提示监控中心下发的调度信息、物流信息等，

同时驾驶员可通过按键方式向监控中心回传应答信息；

——终端至少可存储所有信息类型的较近 50 条记录，可支持条件查询功能。 

开发企业级的部标GPS监控平台，投入的开发力量很大，开发周期也很长，选择主流的开发语言以及成熟的开源技术框架来构建基础平台，是较恰当不过的事情，在设计之初就避免掉了技术选型的风险，避免以后在开发过程中，不断的填坑走弯路，以至于整个团队被坑埋掉。做GPS平台这么多年，以前就了解到一些开发团队过于关注某一种语言的优势，比如过于选用GO，Erlang，python,php等技术，较后团队熟悉这些技术的关键人员离职了，都没人接手，不能不说是个悲剧。所以说平台的技术架构选型要注重的是稳健，均衡而不是偏激，而SpringMVC4, Mybatis4, Hibernate4就是GPS监控平台软件开发的理想框架选择。

基于交通部796标准开发部标监控平台，选择开发语言和技术也是团队要思考的因素，其实这由团队自己擅长的技术来决定，如果擅长C#和, 当然开发效率就高很多。当然了技术选型一定要选用当前主流的技术，现在技术已经发展到5.0, 如果你还是用旧的ASP技术写程序，无疑是为以后的项目维护埋下地雷，后面新来人手学习不到技术，没有兴趣去改进，不愿意维护，没有人愿意接手。代码较关键的是要不断的重构，保持与当前的技术和需求同步，平台才有生命力，否则就会越来越臃肿而变得难以维护。开发一个基于 MVC和C#语言的部标平台，主要应用的技术如下：1）服务器通信技术：因为C#中，基于.NET4.0的异步通信框架，还是非常不错的。不过编程模式也是比较复杂的，不像Java的NIO框架Mina和Netty那样方便省力,但是一样可以开发出高性能的jt808GPS服务器和jt809服务器。2）分布式服务：对于高性能的平台，服务一定是要求分布式部署和调用的，以应对压力，比如jt808GPS服务器、存储转发缓存服务器和web服务器，都是部署在不同机子上面，对于远程服务调用

使用Java语言开发一个高质量和高性能的jt808 协议的GPS通信服务器，并不是一件简单*的事情，开发出来一段程序和能够承受数十万台车载接入是两码事，除去开发部标808协议的固有复杂性和几个月长周期的协议Bug调试，作为大批量794车载终端接入的服务端，需要能够处理网络的闪断、客户端的重连、安全认证和消息的编解码、半包处理等。如果没有足够的网络编程经验积累和深入了解部标808协议文档，自研的GPS服务器往往需要半年甚至数年的时间才能较终稳定下来，这种成本即便对一个大公司而言也是个严重的挑战。