GPS和视频平台产品经理（2379423771@qq.com)(微信号:jt808_com) 致力于精致GPS部标软件产品和部标驾培计时平台开发服务,提供成品和源码，分享技术文章,理想的生活方式是：每天都能领悟、分享新的东西，再创造新的东西.

摘要： 部标808和809的出台，统一了产品的标准，统一了平台与终端之间的通讯协议，对于GPS运营商而言，只要平台支持部标，那可以选择任意一家的GPS车载终端，也不会受厂商的制约，GPS运营商在市场竞争过程中将更看重产品的质量及服务，从而也间接地促进市场上产品的稳定性和可靠性。 但是开发部标GPS服务器是一个繁琐苦逼的活，有各种各样的GPS终端需要兼容和支持，现在交通部颁发了统一的标准协议和数据格式，大部分车辆的GPS终端都需要支持，软件也需要支持，否则可能在市场准入的时候就遇到麻烦。 阅读全文

摘要： 很多人在看完交通运输部的JT/T809的标准后，单纯的以为这就是个转发平台，在实际的实现过程中，发现很复杂，所以在开发809平台的时候，第一要透彻地理解协议，第二就是要架构设计清楚，便于调试和扩展，否则会显得乱糟糟的。 阅读全文

摘要： 部标1078协议文档明确说明了，协议是在JT/T 808协议的基础上进行增加了大量的视频指令，以前的终端32位报警，由于增加了视频报警，拓展为64位报警。终端参数中也增加了大量与视频相关的参数设置。协议的通信方式、数据类型、传输规则和消息组成按照 JT/T 808-2011中第 ４ 章的要求。协议中信令数据报文的通信连接方式按照 JT/T 808-2011中第 ５ 章的要求。协议中信令数据报文的消息处理机制按照 JT/T 808-2011中第 ６ 章的要求。协议中信令数据报文的加密机制按照 JT/T 808-2011中第 ７ 章的要求。 阅读全文

摘要： JT809网关数据接口服务系统，是基于TCP协议开发的部标809协议服务软件系统。系统利用高并发的Netty通信框架，采用通信双方约定的809协议规范，完成对协议数据的解析、拦截、数据入库、报警分析和转发的工作。并实现协议数据与上级平台、下级平台（多方企业运营服务平台）之间的数据通信桥梁。从而实现多部标企业平台车辆动态数据通过拦截、转发、存储的功能推送至自有企业平台。 阅读全文

摘要： 因为自己经常做Socket开发，经常要调试和维护多个服务器端和客户端的通信、报文数据等，网上的工具都是功能简单，用的不爽，所以一直都想自己写一个。 年底不忙了，终于写了一个，提供给大家使用，源码可以随便使用和修改，欢迎多提意见，让这个工具更易用，方便Socket编程开发人鱼。主要的功能如下： 阅读全文

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

摘要： 很多国内开发者使用ArcGIS等地图引擎或者基于谷歌百度地图、GMap.NET开发地图应用程序，非常方便，可是在实际应用中傻眼了，因为GPS坐标的位置在谷歌地图上出现了严重的便宜，这个是要了命的，地图应用就是要给别人一个精确的Location，解决不了偏差，前面的开发都是白费。但是地图引擎只是一个对瓦片操作和客户端GDI输出的操作进行了较好的封装，对于有中国特色的国情，跟人家八竿子打不着。 阅读全文

摘要： 我经常对我的同事们讲的一个观点:在IT界成功真是太容易了： 1.最容易成功和获得一份不错薪资的行业就是IT，只要你有学习能力，因为你所有要学的东西，都在网上，通过Google可以获得你想要提高的所有东西。 2.只要你坚持不断的写程序，少说多写，你就很容易脱颖而出，因为你周围大部分人都在玩，有的在看垃圾小说，有的在聊天和微博，有的在低头玩弄智能手机。很少有人能够驱动自己从头到尾，从前端到后端，从页面到数据库，独立写一个完整的软件，并为之不断的改进。 阅读全文

摘要： GB28181的全称是指《公共安全视频监控联网系统信息传输、交换、控制技术要求》, JT1078主要是指交通部的车载视频监控协议, 两者适用于不同的领域, GB28181规定了城市监控报警联网系统中信息传输、交换、控制的互联结构、通信协议结构，传输、交换、控制的基本要求和安全性要求，以及控制、传输流程和协议接口等技术要求.主要是适用于公共场所的视频监控, 设计之初是适用于有线局域网环境, 2011第一版主要是UDP协议, 后来针对互联网的需求,进行了增补TCP的需求. 阅读全文

摘要： 而java语言是开发部标平台技术的非常理想的开发语言，因为他非常全面，各个方面的底层框架都有具备，高性能的socket通信框架比如netty、mina, 可以帮助你构建高并发大规模的Gps服务器，接入十几万的海量终端，之所以说全面，是因为我们不仅仅单单开发一个Gps服务器就完事了，一个完整的部标平台，还有复杂的web功能平台，提供给用户人性化的操作界面，进行GPS监控、报表统计、数据查询、报警提示等等，而Java平台的springMVC、Hibernate、spring等框架也是非常成熟的底层技术框架。而j2EE提供的基于RMI的RPC进程间调用框架，和spring结合的非常完美，可以方便web平台和808服务器、809服务器之间进行复杂的数据交互和转发。 阅读全文

摘要： 出租车jt/t 905协议，是jt/t 808协议的一个变种，设计者将部标808协议拿过来，并不是单纯的增加网约车相关的指令集，而且对原有的指令如定位0×0200指令也进行了修改，经过一通剧烈的修改，面目全非，协议已经与808协议本身并不兼容，这是比较失败的地方，保持兼容性，才能使协议更加让硬件和网约车平台接受和开发推广，没有经验的协议设计者和标准制定者高高在上不考虑兼容性，给硬件厂家和平台开发人员造成很大的麻烦，也增加了成本。 部标1078协议是在部标808协议的基础上，继续增加指令，并不修改原有的指令，这样也使得协议更加容易让人接受和推广。 在部标1078视频协议推出后，905终端就相对比较尴尬，以前的905协议本身没有视频指令和功能，很多厂家就集成基于私有协议的视频模块，五花八门，现在部标视频标准一出，就面临一个视频标准统一的问题，原有的私有协议需要抛弃掉，修改成1078协议。但是1078协议是基于808协议的指令集，并不是基于905协议的指令集，本质上不是为905协议终端设备设计的。这就需要硬件和平台后端都需要做一定的工作，才能让一个905网约车平台具备1078视频功能。 阅读全文

摘要： 为什么反对创业？因为对大多数人来，实在是没戏，你能想到的，别人都做到了，做了N年了，你没有想到的，别人也做到了，就这样。这年头看着身边的人一个一个离去创业，一大把年纪了，混的很不快乐，心里感到很痛，我以前一个同事，一个月一万的工资，还不错，项目经理，可能是意识膨胀吧，他的朋友劝他出来做Flash游戏吧，老赚钱了，他就辞职了，几个领导轮番劝，都留不住，越劝越来劲，毅然离开公司。辞职后，自然是混的很惨，于是想回来，领导也通达，那就回来吧，可是人力部门跳出来说，当初说走就走了，现在又想回来，当这是什么地？不行！现在这个人还没找着工作，为什么，都快四十了还要价那么高，好找吗？谁要啊。 阅读全文

摘要： GMap.NET的出现，解决了传统的依赖于地图引擎的代价高昂的解决方案，而且使用传统地图引擎，无法迁移，就连我们的地图放大缩小这样常规的方法，都是紧紧绑定在这些令人恶心的地图引擎开发包提供的SDK接口上，目前的Mapxtreme、 ArcEngine、SuperMap等，不仅开发方式迥异，而且收费昂贵。更要命的就是部署复杂，不适合常规的桌面GPS监控系统开发。所以将GMAP.NET二次开发的源码提供大家方便开发。 阅读全文

摘要： 今年交通部通信信息中心一口气推出了三个新标准, GB/T35658 道路运输车辆卫星定位平台技术要求, 部标808-2019协议标准, 部标809-2019协议标准, 将GPS监控平台的标准由原来的部标变为国标, 在2019年7月1日开始强制执行, 2019年6月份过检的,需要重新再次按照新标准通过后才给公示.这次变化中,变化最大的就是809协议,基本完全不考虑兼容了 阅读全文

摘要： 百度一直以来都是个即想装出一副拥抱互联网开放的样子，又为了短期商业利益封闭自己的公司，模仿谷歌地图，开放了自己的百度地图 API，为了防止别人盗用其数据和用户自由迁移，地图相比于火星坐标，又更加封闭，在火星坐标的基础上进一步的加偏，偏上加偏。国际经纬度坐标标准为WGS-84,国内必须至少使用国测局制定的GCJ-02,对地理位置进行首次加密。百度坐标在此基础上，进行了BD-09二次加密措施,让开发人员倍感不爽。 阅读全文

摘要： 广东省道路运输协会在2020-12底发 布,2021年1月1日实施的广东省主动安全标准, 全称是[道路运输车辆智能视频监控报警系统 通讯协议规范]. 这个标准经过多家单位参与制定, 相对于苏标,做了很多重大的变化. 苏标协议是2017年开始实施的, 经过4年的发展, 也应该有一些丰富和功能迭代. 至此主动安全协议已经有粤标、苏标、渝标、陕标、吉标、湘标、川标、浙标、沪标九家地方标准, 其他地区比如海南, 还比较仁慈, 直接下文采用苏标主动安全标准, 大家都省事省心, 这才是最好的..广东省主动安全标准推出的比较晚,在2020年底才颁布, 距离江苏省2016年底发布的苏标主动安全协议标准已经过去整整三年了, 由于部标2019标准已经颁布了, 所以没有办法, 新的协议标准只能从协议的通讯方式、数据类型、传输规则和消息组成按照 JT/T 808-2019 中 4 的要求。对于视频1078标准, 也不得不做改造, 将视频RTP协议中的Sim卡号由12位扩展到20位长度. 阅读全文

摘要： 在开发工业系统的数据采集功能相关的系统时，由于数据都是定时上传的，如每20秒上传一次的时间序列数据，这些数据在经过处理和计算后，变成了与时间轴有关的历史数据（与股票数据相似，如下图的车辆行驶过程中的油量曲线、历史轨迹数据等）。当采集点多的时候，如上万个采集终端，再加上时间的累积，数据表会变得越来越大。数据库会越来越难以维护。 阅读全文

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

摘要： 最近集团董事长在自己的朋友圈看到其他老板在晒自己公司的微信平台，这年头公司没有一个微信平台，都没脸见人，董事长马上要求要有我们要整一个微信平台，把企业网站上的内容搬过去，我知道这个东西，搭架子容易，要是做的漂亮专业，满足领导的奇葩的审美，还得找专业公司做。我马上调研了几家本地的移动平台开发商，选中了一家，报价一万多，云后台，管理后台有很强大的模版支持内容推送，基本满足要求。结果老板很单独通知人力，要招聘一个能开发企业网站和微信网站的人，人力不会写招聘要求，又转到我手里，让我帮忙写。我当时差点憋出内伤。 阅读全文

摘要： 部标视频协议的支持程度，锐明和博实结支持的都比较糟糕，不知道他们是怎么过检的，大面积的不符合1078协议指令，锐明还是第一批过检，也是部标1078协议标准的起草单位之一，自己参与撰写的自己都支持的不完善。博实结开始只给客户看证书，没有量产设备，从GF-01到GF-02,给客户换了两次设备，都测试有毛病，最后还要换设备，客户也没耐心了去他妈的换货不换了也不用了。车载视频做的最好的几家公司，主要是在视频领域有一定研发积累，研发实力较强的，比如海康、大华等几家浙江的上市公司，锐明和这两家比起来还差点，但在车载领域做的还可以。博实结只是在GPS上做设备，做视频还很弱。视频设备的研发还是需要有一定的实力积累的，如果仅是买了块板子，用了几个海思芯片SDK开发包，就像你用百度SDK包开发地图一样，技术能力肯定比不上专业搞GIS地图的，后劲肯定不足，技术细节处理不到位，处理问题的能力也很差。 阅读全文

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

摘要： 随着交通部796部标平台标准的公布，帮助我们开始对部标平台由了一个较统一的，或者是叫清晰的认识，同时越来越多的GPS软件厂商，需要获取到796平台的认证，这样才能在政府和国企的车载设备和软件平台采购项目中获得投标资格，或者是获取到地方市场准入的资格。很多人把部标平台看成一个门槛，由于过检费用成本很高，迟迟下定不了决心，但是部标平台不仅仅是个门槛，那只是第一步，它也是奠基石，事实上部标标准在2011年公布后，一直更新过程中，它所包含的东西也是与时俱进的，平台规定的功能标准也在一步一步的垫高，未来一年，将加入视频监控的标准，目前视频监控的草案正在征求意见当中，所以部标平台现在不过，未来更难。 阅读全文

摘要： 开发部标809协议的协议设计者把面向对象的思想带入到了协议当中，造成了协议的不容易阅读和不容易理解，但在协议本身的开发和实现非常适合用Mina框架。通过借用框架的过滤器模式，来降低协议开发的难度。 阅读全文

摘要： 对于经常做信息化的开发人员来说，如果第一次开发地图应用可能要走很多的弯路：1.购买地图, 因为现在的谷歌和百度地图API，都是基于Javascript的，如果要开发C/S架构的桌面地图应用非常不方便。 2.可能会去找想Mapinfo、ArcGis这些地图软件进行二次开发，这个弊端太多了，开发资源少，周期长，发布时更加麻烦，都是基于桌面License的，收费很高，非常黑，看到Mapinfo和ArcGis论坛一堆堆的开发者浪费时间在这个上面，太痛心了。 阅读全文

摘要： GPS平台，需要和各种地图打交道，需要解决以下的问题：1.GPS坐标偏移，这个不用多说，需要将原始坐标加偏，然后在百度地图或谷歌上显示出来，需要注意的是百度地图的加偏是偏上再偏，谷歌、高德地图等是火星坐标；2.坐标解偏，或者GPS纠偏，这个我们也是需要的，因为当用户在地图上画出的各种区域，标注，发送到后台存储的坐标都是基于地图所采用的坐标系统，因而是偏移的，这就面临一个严重的问题，因为在部标808协议中，对于区域报警，需要将区域的顶点坐标，下发给终端，终端在实际运行中，不断用GPS坐标和区域坐标进行比对，来判断是否是进入区域报警，还是离开区域报警。如果区域坐标是偏移的，那么判断出来必然是错误的。所以下发前，必须要将偏移的坐标逆向再还原成原始的基于wgs84坐标系的坐标出来。 阅读全文

摘要： 在GMap.NET 当中，我们可以自定义Marker,进行画圆形、矩形和多边形等操作，这个功能在GPS软件中很重要，需要基于此功能设置区域，就是我们常说的电子围栏。但是很多人做的时候，是基于窗口像素来进行画图操作，这样会造成画图的时候，严重失真，因为同一个像素长度，在不同的Zoom比例尺下，换算成地图距离是不一样的。这样会造成画出来的电子围栏非常不准确，再次打开地图重新加载的时候，围栏可能变大或者变小。 阅读全文

摘要： 无论是开发地理信息系统还是开发视频监控系统，都会面临者一个问题：界面如何设计，实质是信息数据的如何组合搭配的问题。因为需要展现的数据不单单是一个破地图和一个坐标，而是将一切与监控对象相关的所有的信息数据以可视化地图、定位地标、图表、报警动画等形式展现出来。比如物流运输行业监控的对象是车，那么围绕车的数据，如车辆的车牌号司机基本信息、运输配送的业务数据、该车辆的轨迹、定位数据、该车辆目的地、起始地的业务数据和GIS数据。进而延伸到配送路径优化、业务综合报表数据等更加复杂的数据。 阅读全文

摘要： 由于交通部部标平台过检的标准信息相对不是很透明，大家对796标准和jt/t 808 协议、jt/t809协议都是通过文档的字面意思各自去理解的，误差难免，误差大的，到北京过检的时候，就要耽误的时间长，过的就非常不顺，花费的差旅费和检测费就很大，得不偿失。很多去过检的企业都不是北京公司，在北京检测要背负额外的时间成本和费用成本，所以要追求较高的成功率，不然遇到问题，要面临两难选择，要么回来，改完了再坐一趟飞机去检测，要么呆在酒店里，改完了，重新预约下次检测时间，一直到过了为止。过完检的人都会感慨良多，不过不知道，过了感觉里面全是大坑，仅靠理解简单的功能列表是不行的，差的太远。 阅读全文

摘要： 2019年交通部GPS平台检测标准发生了重大变化, 原来的796平台功能标准, 变更为GB/T35658标准, 这个标准其实2017年就公布了, 实际上还是796标准, 但是检测项目,以前是可选的, 现在统统变成了必选,检测标准比以前拔高了很多.但是由于是2017年的标准, 很遗憾没有与时俱进.但是要按照这个标准开发,即使有以前通过的gps平台, 由于增加了几十个功能点, 比较琐碎,改造开发的工作量是很大的.同时由于部标协议在2019年推出了新标准, 所以协议上的变动,需要重新解读, 并按照2019标准开发,同时还要兼容旧标准, 从16年的部标1078视频标准, 17年的苏标,19年的部标协议2019标准, 也是让开发人员不得喘息的机会, 对开发人员要求具备必要的协议标准知识, 平台的功能复杂度也大大增加.平台过检,首先必须要符合这三个标准, 即GB/T35658平台功能标准,JT/T 808-2019, JT/T 809-2019部标协议标准.开发人员必须要先认真学习这三个文档,然后才能着手开发. 当然了还有一个<<道路运输车辆卫星定位系统平台检测方法>>可以 阅读全文

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

摘要： 考虑到目前的基于部标808的GPS平台，我们决定使用WCF来作为平台的基础服务架构，而WCF的回调模式可以满足GPS报警复杂的业务模式：报警推送数据在很多软件中都有需求，比如任务提醒、消息广播、实时的监控报警等等。凡是对实时性要求越高的场景，越是需要服务器及时、准确地向客户端推送数据。 阅读全文

摘要： 交通部的部标过检，所有的测试都是从客户端发起的，也是在客户端体现的，在客户端承载了部标标准所要求的所有的功能，是整个部标平台当中工作量最大的部分，也是最繁琐的部分。客户端设计面临两个问题：1.基于CS还是基于BS，这是个问题，萝卜白菜各有所爱，客户要什么，我们就开发什么，从客户来讲，更适应桌面客户端，没有浏览器的七七八八问题，速度感觉上也比网页的快，操作方便。当然网页客户端也有很大的优势，部署和维护方便，不需要开发升级系统。 阅读全文

摘要： 由于现在主流的部标GPS和1077视频监控平台，都是BS架构，在网页上播放视频，早期的很多平台用的都是ActiveX控件的形式，依赖于IE浏览器，需要降低浏览器的安全设置，而且非常难用。同时由于win10以后的操作系统上的浏览器，对于安全的把控非常严格，ActiveX插件做成的播放器嵌入到网页当中的形式，基本上要被扫入到历史的垃圾堆里面了。 HTML5虽然日臻成熟，VIDEO标签，可以播放服务器的视频文件，实现了真正的网页播放视频，但是原则上只能播放服务器上面的文件流，不能播放实时的视频流, 也就是不支持常说的live streaming。 阅读全文

摘要： 在项目繁忙的时候，和团队成员、跨部门同事需要进行各种交流，最烦听到，“我哪知道啊，你问我我问谁啊，你问我干什么？这不是我的事”， 真的很恼火。很多人还怀揣着做管理带团队的愿望，就这个工作沟通习惯，怎么可能！可能由于工作的关系，太封闭了，做事切割的太清楚，自己把自己限定在一亩三分地了，这个样子可能会影响自己的职业生涯，想成为项目经理是回事，能不能做，领导和团队认不认可你又是一回事。 阅读全文

摘要： 809协议指令在JT/T 1078协议文档中的第六章开始部分，分为下发指令和视频播放两个部分，两个请求环节，也就是说要先完成视频指令下发给设备的闭环操作，然后再开始请求视频播放的请求操作。这两个环节完成了上级平台播放下级企业平台的设备视频的流程。 下级平台必须要实现1078协议中的809指令部分，必须要按照809协议的要求，提供接口，上级平台才能完成播放。所以双方对接的时候，首先要确认对方是否实现了809视频指令及接口。 下级平台提供给上级平台的接口，按照规定下级平台要扮演Http Server的角色，提供Http API供上级平台调用指定的API，上级平台调用Http API接口获取到视频流，进行转发或者直接播放。所谓的HttpAPI接口，其实就是一个URL，上级平台要扮演一个Http Client的角色去调用这个URL，在Response中获取到视频数据进行播放处理。 阅读全文

摘要： 交通运输部发布了《道路运输车辆卫星定位系统终端通讯协议及数据格式》(JT/T808-2011)和《道路运输车辆卫星定位系统平台数据交换》(JT/T809-2011)两份技术标准文件。这两份文件中严格规定了车载卫星定位终端与企业监控平台之间，企业监控平台与政府监控平台之间的通信技术要求。同时，中国交通通信信息中心开始组织实施JT/T808和JT/T809标准的平台符合性检测工作和JT/T794-2011标准的车载硬件终端符合性检测工作。即企业平台，政府平台和车载终端的部标认证检测。 阅读全文

摘要： 计时终端的检测主要依据以下3项标准和技术规范：《机动车驾驶员计时培训系统计时终端技术规范》（交通运输部2016年第17号公告）、《机动车驾驶员计时培训系统平台技术规范》（交通运输部2016年第17号公告）、JT/T 794-2011 《道路运输车辆卫星定位系统 车载终端技术要求》。 计时终端的检测主要针对《机动车驾驶员计时培训系统计时终端技术规范》要求的各项功能进行，终端与平台的通讯协议依据《机动车驾驶员计时培训系统平台技术规范》附录B的要求，在功能检测时同步进行检测，不再单独检测。计时终端的卫星定位功能依据JT/T 794中5.2的要求进行。 阅读全文

摘要： 在开发部标GPS平台中，部标808GPS服务器是系统的核心关键，决定了部标平台的稳定性和行那个。Linux服务器是首选，为了跨平台，开发语言选择Java自不待言。 阅读全文

摘要： 开发GPS平台的时候，必须要首先阅读交通部的jt/t 796 , jt/t808和jt/t809的文档，以此作为自己的功能设计的需求来源，行业需求或用户需求是排在后面的。很多开发团队做出来的平台为什么不能过检测，就是因为没有沉下心来，仔细阅读文档，以为是个概念，可以随性而来，在设计的时候，过于偏向行业需求，而对与交通部的标准制定，理解有偏差。其实在平台检测的时候，是一个标准化的检测过程，是以检测工具为准的，合不合要求，检测工具说了算。如果你没有严格的按照标准开发，哪里有什么机会让你解释：我这么做是因为考虑到什么原因等等。这样的思想等你过检测的时候，你自己会觉得很幼稚的。 阅读全文

摘要： 部标1078视频监控平台，是一个庞杂的工程，涵盖了多层协议，部标808，809,1078，苏标Adas协议等，多个平台功能标准，部标796标准，部标1077标准和苏标主动安全标准，视频方面的协议有RTSP, RTMP, RTP, 音视频编码有H.264, AAC, 726,711等，消化这些协议和功能标准就已经是需要一个较长的周期了，而构建一个视频平台的架构，也是比较复杂的，后端不仅有网关，还要有流媒体服务器，转发服务器，播放器，RTSP或RTMP服务器等多个服务器模块，需要的技术需要跨越多种语言，如平台主流语言是Java语言，采用主流的Spring框架和生态，如Hibernate, Mybatis, Springmvc, Netty, Mina, 分布式消息架构如ActiveMq, RabbitMQ, Kafka等，分布式缓存如Redis, 分布式数据库如Mongodb， Hbase等，而构建流媒体服务器，如果采用Java语言，则会性能不足，在高频的内存交换场景，java的内存分配效率会很低，内存泄露也会很严重，所以主流的语言是C, C++等。很多公司对此态度轻慢，随便找个程序员就 阅读全文