出租車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多的服務器模塊了，主要有：

1）905協議網關；

2）1078協議網關；

3）基於905協議數據交換部分的上級平臺轉發服務器；

4）基於809協議的轉發服務器；

5）基於905 UDP升級協議的的升級服務器；