出租车Jt/T 905协议与部标1078协议融合的网约车视频监控平台

出租车jt/t 905协议,是jt/t 808协议的一个变种,设计者将部标808协议拿过来,并不是单纯的增加网约车相关的指令集,而且对原有的指令如定位0×0200指令也进行了修改,经过一通剧烈的修改,面目全非,协议已经与808协议本身并不兼容,这是比较失败的地方,保持兼容性,才能使协议更加让硬件和网约车平台接受和开发推广,没有经验的协议设计者和标准制定者高高在上不考虑兼容性,给硬件厂家和平台开发人员造成很大的麻烦,也增加了成本。 

部标1078协议是在部标808协议的基础上,继续增加指令,并不修改原有的指令,这样也使得协议更加容易让人接受和推广。 

在部标1078视频协议推出后,部标905终端就相对比较尴尬,以前的jt/t905协议本身没有视频指令和功能,很多厂家就集成基于私有协议的视频模块,五花八门,现在部标视频标准一出,就面临一个视频标准统一的问题,原有的私有协议需要抛弃掉,修改成1078协议。但是1078协议是基于808协议的指令集,并不是基于905协议的指令集,本质上不是为905协议终端设备设计的。这就需要硬件和平台后端都需要做一定的工作,才能让一个部标905网约车平台具备1078视频功能。 

一种比较理想的方案是深度集成,将1078协议中的指令集添加到905的指令集中,这样使得jt905协协议赋予了视频指令交互的能力,这种方案好的地方在于它仍然保持了一个指令通道,一个视频数据通道,但是需要硬件开发人员一定的工作量。 

另一种方案就是粗暴简单,905模块和1078模块,分别与平台后端建立独立的指令交互的连接,基于jt/t905的连接只交互905的指令,1078的连接只交互1078的指令,各自为战,这种方案的优势在于硬件拿来即用,不需要过多的开发,但是后遗症很多,苦了平台开发人员,设计两个指令网关,一个是905指令网关,一个是1078指令网关,在平台上下发指令的时候,需要判断指令类型,来决定指令的走向,是下给905网关,还是下给1078网关。

还有一个麻烦的地方,就是上线和离线不同步,比如1078连接断开了,而905的连接还是正常,这就在前端界面的上线状态上给用户容易造成困惑,有时候905明明在线,但是视频指令却下发失败,无法看到视频。 

在上级平台对接方面,也是麻烦,首先要基于905协议第四部分中数据交互与共享单元中的数据交换协议(是809协议的变种,做了修改,不兼容809),开发转发服务器,将数据转发给出租车监管平台。

但是还要基于原有的809协议,开发转发服务器,将数据转发给省级监管平台。 

这样开放下来,一个网约车后端,就有N多的服务器模块了,主要有:

1905协议网关;

21078协议网关;

3)基于905协议数据交换部分的上级平台转发服务器;

4)基于809协议的转发服务器;

5)基于905 UDP升级协议的的升级服务器;

出租车Jt/T 905协议与部标1078协议融合的网约车视频监控平台_第1张图片

 

转载于:https://www.cnblogs.com/productivity/p/10897702.html

你可能感兴趣的:(golang,移动开发)