This standard was drafted according to the rules given in GB/T 1.1-2009.
This standard was proposed and is under the jurisdiction of National Technical Committee on Road Transport of Standardization Administration of China.
Drafting organizations of this standard: China Transport Telecommunications & Information Center, Research Institute of Highway Ministry of Transport and Fujian Provincial Communications Department.
Chief drafting staffs of this standard: Liu Jian, Cai Fengtian, Luo Guanwei, Feng Quan, Liu Yingji, Liang Jinyan, Wang Hongyu, Zhou Yi, Qiu Shejin, Niu Wenjiang, Dong Xuan, Lin Yuanhong, He Fanglin, Li Wenliang, Hong Maozhi, Li Mingying, Zhang Xuewen, Shen Bing and Shang Jiang.
GNSS System for Operating Vehicles - General Specifications for Data Exchange between Platforms
道路運輸車輛衛星定位系統 平臺數據交換
1 Scope
This standard specifies technical requirements for data exchange between monitoring and management platforms of the GNSS system for operating vehicles, including communication mode, safety certificate, function realization process, protocol message format and data entity format.
This standard is applicable to data exchange between monitoring and management platforms of GNSS system for operating vehicles.
2 Normative References
The following references are indispensable for the application of this standard. For dated reference, only the dated editions apply. For the undated normative references, the latest editions (including all amendments) apply.
GB/T 2260 Codes for the Administrative Divisions of the People's Republic of China
GB/T 19056 Vehicle Travelling Data Recorder
JT/T 415-2006 Electronic Government Platform for Administration of Road Transportation - Cataloguing and Coding Rules
JT/T 808-2011 GNSS System for Operational Vehicles - General Specifications for Vehicle Terminal Communication Protocol and Data Format
3 Terms, Definitions and Abbreviations
3.1 Terms and Definitions
For the purpose of this standard, the following terms and definitions apply.
3.1.1
Number plate
The number plate of the motor vehicle issued by the public security traffic management department, excluding color of the license plate, for example, Beijing AJ 3030.
3.1.2
Superior platform
Government monitoring and management platform that provides access to other platforms.
3.1.3
Inferior platform
Monitoring and management platforms, in the enterprise monitoring and management platform and government monitoring and management platform, that access to the superior platform.
3.1.4
Vehicle's positioning information
A general term for the current vehicle position information and vehicle warn state information received from the vehicle terminal to the navigation satellite and delivered to the surveillance & control center, including latitude/longitude, speed and direction.
3.1.5
Vehicle's dynamic information
Relevant vehicle information generated during the operation and traveling, including vehicle's positioning information, traveling state, personnel, goods and line information.
3.1.6
Vehicle's static information
Vehicle's administration and operation management information that is related to the road transportation and operation activities and remains constant during a given period, including operating vehicle, the owner, employees, operation management organization and operation line information.
3.1.7
Main links
Two TCP protocol-based virtual channels are adopted between superior and inferior platforms, including one-way uplink virtual channel constructed after the inferior platform, as the TCP server, is successfully connected to the TCP client of the superior platform.
3.1.8
Subordinate links
Two TCP protocol-based virtual channels are adopted between superior and inferior platforms, including one-way downlink virtual channel constructed after the superior platform, as the TCP client, is successfully connected to the TCP server of the inferior platform.
3.2 Abbreviations
For the purpose of this standard, the following abbreviations apply.
CCITT - Consultative Committee for International Telegraphy and Telephony
CRC - Cyclic Redundancy Check
CRC 16-CCITT - CRC-16 Code of CCITT Standard
UTC - Universal Time Coordinated
4 Technical Requirements
4.1 Communication mode
Double-link communication mode is adopted between the superior platform and the inferior platform; and the specific requirements are as follows:
a) TCP protocol-based long connection mode is adopted as the communication mode between the superior and inferior platforms;
b) The superior platform provides IP address, port No., user name and password for the access of the inferior platform;
c) The inferior platform initiates a request for the connection of the main link to the superior platform; after the main link is successfully established, the superior platform initiates a request for the connection of the subordinate link to the inferior platform;
d) The inferior platform may send data to the superior platform via main link while the superior platform may send data to the inferior platform via subordinate link;
e) In case of any interruption in either of the main or subordinate link, all the data will be transmitted via the other link; when the interrupted link is recovered, the data continues to be transmitted from the two links according to those stipulated in this standard;
f) The communication link is sent via the TCP client to maintain the connection of data package testing link and realize reliable connection between the links.
4.2 Safety certification
According to communication mode proposed in Section 4.1, the superior platform carries out the safety verification on the access request of the inferior platform so as to guarantee that reliable and creditable communication link is established; however, the inferior platform needn't carry out safety verification on the access request of the superior platform.
Safety verification process of the superior platform for the inferior platform shall comply with the following requirements:
a) The superior platform assigns corresponding access code, access user name, password and data encryption/decryption parameters to the inferior platform;
b) When the inferior platform and the superior platform are connected with each other, the "log-in request" message is sent. After the superior platform receives the connection request of the inferior platform, it will firstly verify the requested IP address. In case of any inconsistency between the requested IP address and stipulated access IP address, it will return to the verification failure result. Secondly, the superior platform verifies the access code, user name and password of the inferior platform and returns corresponding result value to the inferior platform according to verification results.
c) Encryption mode may be adopted for the data transmission between the superior and inferior platforms so as to realize instant encryption of the transmission data; specific encryption algorithm is in accordance with those specified in Article 4.4.7.
4.3 Function realization process
4.3.1 Link management process
4.3.1.1 Log-in and hold request of main link from inferior platform to the superior platform.
4.3.1.1.1 Log-in process of main link for the inferior platform
Log-in process of main link for the inferior platform shall comply with the following requirements:
a) The inferior platform sends a log-in request to the superior platform. The log-in request data package includes platform access code, log-in user name and password, TCP service IP address and port No. necessary for the establishment of subordinate link;
b) The superior platform carries out safety certification on the log-in request of the inferior platform and records log-in conditions in the log. If the certification is successful, response to successful log-in will be given; otherwise, the response to log-in failure will be given and failure reason code will be given.
c) After the inferior platform successfully logs in the superior platform, the superior platform requests to establish connection with the subordinate link according to the TCP service IP address and port No. provided during the log-in of the inferior platform;
d) After successful establishment of the subordinate link, follow-up downlink data package may be sent from the subordinate link.
4.3.1.1.2 Hold process of main link
Hold process of main link shall comply with the following requirements:
a) After successful log-in of the inferior platform, in case of any application service data package transmission between superior platforms, hold data package of the main link need not be sent; otherwise, the inferior platform shall send one hold request data package of the main link to the superior platform every 1min so as to keep link connection;
b) If there is without application data package transmission and the superior platform fails to receive the hold request data package of the main link sent from the inferior platform for consecutive 3min, it shall be considered that its connection with the inferior platform is interrupted and it will initiate to interrupt the main link of data transmission;
c) If there is without application data package transmission and the superior platform fails to receive the hold acknowledge data package of the subordinate link sent from the superior platform for consecutive 3min, it shall be considered that its connection with the superior platform is interrupted and it will initiate to interrupt the subordinate link of data transmission;
4.3.1.2 Log-out request of main link from inferior platform to superior platform
When the inferior platform initiates to exit, it will firstly send a log-out request of the main link. After the superior platform receives it, it will return to the link, log out the response and record it in the log. Then the superior platform interrupts the main link.
4.3.1.3 Inferior platform's initiative closure of the main-subordinate link connection with the superior platform
With the inferior platform as the server, in case of any abnormal connection of the subordinate link, the subordinate link initiates to send a message to close the main-subordinate link connection to the superior platform and records it in the log, and then the inferior platform interrupts the connection between the main and subordinate links.
4.3.1.4 Connection and hold request of the subordinate link from superior platform to inferior platform
4.3.1.4.1 Connection request process of subordinate link for superior platform
Connection request process of the subordinate link for the superior platform shall comply with the following requirements:
a) After the inferior platform successfully logs in the superior platform and the main link is established, the superior platform, by obtaining information such as TCP service IP address and port No. provided by the inferior platform, initiates a connection request of the subordinate link to the inferior platform;
b) After the inferior platform receives the connection request of the subordinate link sent from the superior platform, the connection between the subordinate link and the superior platform is immediately established.
4.3.1.4.2 Hold process of subordinate link
Hold process of the subordinate link shall comply with the following requirements:
a) After successful connection of the subordinate link, in case of any application service data package transmission between the superior platform and the inferior platform, hold data package of the subordinate link needs not be sent; otherwise, the inferior platform shall send one hold request data package of the subordinate link to the superior platform every 1min so as to keep connection of the subordinate link;
b) If there is without application data package transmission between the inferior platform and the superior platform, and the inferior platform fails to receive the hold acknowledge data package of the subordinate link sent from the superior platform for consecutive 3min, it shall be considered that its connection with the superior platform have been lost and it will initiate to interrupt the subordinate link of data transmission;
c) If there is without application data package transmission between the superior platform and the inferior platform, and the superior platform fails to receive the hold acknowledge data package of the subordinate link sent from the inferior platform for consecutive 3min, it shall be considered that its connection with the inferior platform have been lost and it will initiate to interrupt the subordinate link of data transmission.
4.3.1.5 Log-out request of main link from superior platform to inferior platform
When the inferior platform initiates to exit, it will firstly send a log-out request of the subordinate link. After the inferior platform receives it, it will return to the link, log out the response and record it in the log. Then the superior platform will interrupt the subordinate link.
4.3.1.6 Superior platform's initiative closure of the main-subordinate link connection with the inferior platform
With the superior platform as the server, in case of any abnormal connection of the main link, the main link initiates to send a message to close the main-subordinate link connection to the superior platform and records it in the log, and then the superior platform interrupts the connection between the main and subordinate links.
4.3.2 Information statistics service process
The reception of notification on the amount of the positioning information shall comply with the following requirements:
a) The superior platform will receive the amount of vehicle's positioning information, periodically conduct statistics on it and periodically notify the statistical data to the inferior platform;
b) The superior and inferior platforms shall receive vehicle's positioning information and check its amount according to the data.
4.3.3 Exchange service process of the vehicle's dynamic information
4.3.3.1 Uploading of the vehicle's registration information from inferior platform to superior platform
The inferior platform shall upload the vehicle's registration information after it receives the vehicle's terminal authentication information each time.
4.3.3.2 Real-time uploading of the vehicle's positioning information from inferior platform to superior platform
The inferior platform shall upload the vehicle's registration information in real time after it receives the vehicle's positioning information.
4.3.3.3 Real-time exchange of the vehicle's positioning information from superior platform to inferior platform
Before the superior platform exchanges the vehicle's positioning information with the inferior platform, it sends the request to start the exchange of the vehicle's positioning information. After the inferior platform receives and responds to the request, the superior platform starts the real-time exchange of vehicle's positioning information with the inferior platform.
The request to start exchange of the vehicle's positioning information from the superior platform to the inferior platform shall include the following conditions:
a) When the superior platform analyzes the geographic area of non-attribution area with any vehicle entry, it shall inform the inferior platform of the non-attribution area of the entry.
b) When the superior platform manually designates the vehicle's positioning information to be exchanged to the designated inferior platform, it shall notify the inferior platform that the vehicle's positioning information shall be exchanged to the superior platform;
c) When the superior platform monitors and manages certain vehicle in emergency state, it shall send the uploaded vehicle's positioning information to the inferior platform to which the vehicle is attributed and send the command to the inferior platform.
When the superior platform ends up sending vehicle's positioning information to the inferior platform, the exchange shall comply with the following requirements:
a) When the vehicle entering the geographic area of the non-attribution area leaves the geographic area, the superior platform shall send the request to end up the exchange of vehicle's positioning information to the inferior platform and notify it to stop the data exchange;
b) When the superior platform itself cancels exchanging of the designated vehicle's positioning information to the designated inferior platform, it shall send the request to end up the exchange of the vehicle's positioning information to the inferior platform and cancel the exchange;
c) When the superior platform completes the vehicle monitoring and management in emergency, it shall send the request to end up the exchange of the vehicle's positioning information to the inferior platform to which the vehicle is attributed and no longer send the vehicle's positioning information to the above inferior platform.
4.3.3.4 Supplementary report of the vehicle's positioning information from inferior platform to superior platform
If the main and subordinate communication links between the superior and inferior platforms are interrupted, the vehicle's positioning information during the interruption shall be supplemented after the recovery of the communication between the main and subordinate links.
The supplementary report process of the vehicle's positioning information from the inferior platform to the superior platform shall comply with the following requirements:
a) When the inferior platform link is interrupted with the superior platform link during the uploading of the positioning data to the superior platform, the interruption time shall be recorded (if without interaction of application service data package between the two platforms, the receipt time of the hold acknowledge data package of the last subordinate link from the superior platform shall prevail; otherwise, the last receipt time of complete interaction of application service data package with the superior platform prevails);
b) After the inferior platform log in again, vehicle's positioning information received during the interruption is automatically sent to the superior platform according to the interruption time.
4.3.3.5 Supplementary sending of the vehicle's positioning information from superior platform to inferior platform
If the main and subordinate communication links between the superior and inferior platforms are interrupted, the vehicle's positioning information during the interruption shall be supplemented to send after the recovery of the communication between the main and subordinate links.
The supplementary sending process of the vehicle's positioning information from the superior platform to the inferior platform shall comply with the following requirements:
a) When the inferior platform link is interrupted with the superior platform link during the exchanging of the data to the superior platform, the interruption time shall be recorded (if without interaction of application service data package between the two platforms, the receipt time of the hold acknowledge data package of the last subordinate link from the superior platform shall prevail; otherwise, the last receipt time of complete interaction of application service data package with the superior platform prevails);
b) After the main and subordinate communication links are established again, the inferior platform sends the request for supplementary sending of the vehicle's positioning information according to the recorded platform interruption time;
c) After the superior platform receives and responses to the request for supplementary sending of the vehicle's positioning information, it carries out the supplementary sending process of the vehicle's positioning information according to the requirements of Article 4.5.3.2.3.
Foreword I
1 Scope
2 Normative References
3 Terms, Definitions and Abbreviations
4 Technical Requirements
5 Constant Definition
道路運輸車輛衛星定位系統
平臺數據交換
1 范圍
本標準規定了道路運輸車輛衛星定位系統監管／監控平臺之間數據交換的技術要求，包括通信方式、安全認證、功能實現流程、協議消息格式和數據實體格式等內容。
本標準適用于道路運輸車輛衛星定位系統監管／監控平臺之間的數據交換。
2 規范性引用文件
下列文件對于本文件的應用是必不可少的。凡是注日期的引用文件，僅注日期的版本適用于本文件。凡是不注日期的引用文件，其最新版本（包括所有的修改單）適用于本文件。
GB/T 2260 中華人民共和國行政區劃代碼
GB/T 19056 汽車行駛記錄儀
JT/T 415—2006 道路運輸電子政務平臺 編目編碼規則
JT/T 808—2011 道路運輸車輛衛星定位系統終端通訊協議及數據格式
3 術語、定義和縮略語
3.1 術語和定義
下列術語和定義適用于本文件。
3.1.1
車牌號 number plate
公安交通管理部門頒發的機動車車牌號碼，不包括車輛牌照的顏色。例：京AJ3030。
3.1.2
上級平臺 superior platform
提供其他平臺接入的政府監管平臺。
3.1.3
下級平臺 inferior platform
企業監控平臺、政府監管平臺中接入上級平臺的監管／監控平臺。
3.1.4
車輛定位信息 vehicle's positioning information
由車載終端從導航衛星接收并發送到監控中心的，與該車輛當前位置有關的信息以及車輛報警狀態信息的統稱，如經緯度、速度、方向等。
3.1.5
車輛動態信息 vehicle's dynamic information
車輛在運營行駛過程中產生的相關信息，包括車輛定位信息、運行狀態、人員、貨物、線路等方面的信息。
3.1.6
車輛靜態信息 vehicle's static information
車輛從事道路運輸經營活動相關的、在一定時期內固定不變的行政管理和經營管理信息，包括營運車輛、業戶、從業人員、運管機構、營運線路等信息。
3.1.7
主鏈路 main links
在上下級平臺之間采用兩條基于TCP協議的虛擬通道，其中，因下級平臺作為TCP客戶端連接上級平臺的TCP服務端成功后而構建的上行單向虛擬通道。
3.1.8
從鏈路 subordinate links
在上下級平臺之間采用兩條基于TCP協議的虛擬通道，其中，因上級平臺作為TCP客戶端連接下級平臺的TCP服務端成功后而構建的下行單向虛擬通道。
3.2 縮略語
下列縮略語適用于本文件。
CCITT——國際電報電話咨詢委員會
CRC——循環冗余校驗(Cyclic Redundancy Check)
CRC16-CCITT——CCITT標準的CRC-16檢驗碼
UTC——協調世界時(Universal Time Coordinated)
4 技術要求
4.1 通信方式
上級平臺與下級平臺之間采用雙鏈路通信方式，具體要求如下：
a) 上下級平臺間通信方式采用TCP協議長連接方式；
b) 上級平臺提供服務的IP地址、端口號以及用戶名、密碼等信息，供下級平臺接入；
c) 下級平臺向上級平臺發起建立主鏈路連接請求，主鏈路成功建立后，上級平臺向下級平臺發起從鏈路連接請求；
d) 下級平臺可以通過主鏈路向上級平臺發送數據，上級平臺可以通過從鏈路向下級平臺發送數據；
e) 主從鏈路中其中一條鏈路中斷時，所有的數據都通過另外一條鏈路進行數據傳輸，斷開的鏈路恢復時，繼續按照標準的約定繼續從兩條鏈路進行數據傳輸；
f) 通信鏈路通過其中的TCP客戶端方發送鏈路保持數據包檢測鏈路連接狀態，實現鏈路的可靠連接。
4.2 安全認證
根據4.1中提出的通信方式，上級平臺對下級平臺的接入請求進行安全驗證，確保建立可靠、可信的通信鏈路，下級平臺無需對上級平臺的接入請求進行安全驗證。
上級平臺對下級平臺安全驗證流程應遵循以下規定：
a) 上級平臺為下級平臺分配相應的接入碼、接入用戶名、密碼以及數據加解密相關參數；
b) 下級平臺與上級平臺連接時，發送“登錄請求”消息，上級平臺收到下級平臺連接請求后，首先驗證請求的IP地址，如果請求IP地址與約定的接入IP地址不一致，則返回驗證失敗結果；其次，上級平臺對下級平臺的接入碼、用戶名以及密碼進行驗證，根據驗證的結果向下級平臺返回相應的結果值；
c) 上下級平臺間的數據傳輸可采用加密模式傳輸，實現對傳輸數據的即時加密，具體加密算法按照4.4.7中的規定。
4.3 功能實現流程
4.3.1 鏈路管理類流程
4.3.1.1 下級平臺向上級平臺請求登錄和主鏈路保持
4.3.1.1.1 下級平臺主鏈路登錄流程
下級平臺主鏈路登錄流程應遵循以下規定：
a) 由下級平臺向上級平臺發送登錄請求。登錄請求數據包內容包括平臺接入碼、登錄用戶名、密碼、建立從鏈路所需的TCP服務IP地址及端口號；
b) 上級平臺對下級平臺的登錄請求進行安全認證，同時在日志中記錄登錄情況，如果認證成功，應答登錄成功，否則應答登錄失敗及給出失敗原因碼；
c) 下級平臺登錄上級平臺成功后，上級平臺根據下級平臺登錄時提供的T CP服務IP地址、端口號請求建立從鏈路連接；
d) 從鏈路建立成功后，后續下行數據包可由從鏈路進行發送。
4.3.1.1.2 主鏈路保持流程
主鏈路保持流程應遵循以下規定：
a) 下級平臺登錄成功后，在與上級平臺之間如果有應用業務數據包往來的情況下，不需要發送主鏈路保持數據包；否則，下級平臺應每1min發送一個主鏈路保持請求數據包到上級平臺，以保持鏈路連接；
b) 在沒有應用數據包往來的情況下，上級平臺連續3min未收到下級平臺發送的主鏈路保持請求數據包，則認為與下級平臺的連接中斷，將主動斷開數據傳輸主鏈路；
c) 在沒有應用數據包往來的情況下，下級平臺連續3min未收到上級平臺發送的從鏈路保持應答數據包，則認為與上級平臺的連接中斷，將主動斷開數據傳輸從鏈路。
4.3.1.2 下級平臺向上級平臺請求主鏈路注銷
當下級平臺主動退出時，首先發送主鏈路注銷請求，上級平臺收到注銷請求后返回鏈路注銷應答并記錄日志，上級平臺即斷開該主鏈路。
4.3.1.3 下級平臺主動關閉與上級平臺之間的主從鏈路連接
當下級平臺作為服務端發現從鏈路連接異常時，通過從鏈路主動向上級平臺發送關閉主從鏈路連接的消息，并記錄到日志，下級平臺即中斷主從鏈路連接。
4.3.1.4 上級平臺向下級平臺請求從鏈路連接和鏈路保持
4.3.1.4.1 上級平臺從鏈路連接請求流程
上級平臺從鏈路連接請求流程應遵循以下規定：
a) 下級平臺成功登錄上級平臺并建立主鏈路后，上級平臺通過獲取來自下級平臺提供的TCP服務IP地址和端口號等信息，向下級平臺發起從鏈路連接請求；
b) 下級平臺收到上級平臺發送的從鏈路連接請求后，立即建立與上級平臺之間的從鏈路連接關系。
4.3.1.4.2 從鏈路保持流程
從鏈路保持流程應遵循以下規定：
a) 從鏈路連接成功后，如果上級平臺與下級平臺之間有應用業務數據包往來的情況下，不需要發送從鏈路保持數據包；否則，上級平臺應每1min發送一個從鏈路保持請求數據包到下級平臺以保持從鏈路連接；
b) 如果與上級平臺之間沒有應用業務數據包往來的情況下，下級平臺連續3min未收到上級平臺發送的從鏈路保持請求數據包，則認為上級平臺已經失去連接，將主動斷開數據傳輸從鏈路；
c) 如果與下級平臺之間沒有應用業務數據包往來的情況下，上級平臺連續3 min未收到下級平臺發送的從鏈路保持應答數據包，則認為下級平臺已經失去連接，將主動斷開數據傳輸從鏈路。
4.3.1.5 上級平臺向下級平臺請求從鏈路注銷
當上級平臺主動退出時，首先發送從鏈路注銷請求，下級平臺收到注銷請求后返回鏈路注銷應答并記錄日志，下級平臺即斷開該從鏈路。
4.3.1.6 上級平臺主動關閉與下級平臺之間的主從鏈路連接
當上級平臺作為服務端發現主鏈路連接異常時，通過主鏈路主動向下級平臺發送關閉主從鏈路連接的消息，并記錄到日志，上級平臺即中斷主從鏈路連接。
4.3.2 信息統計業務類流程
接收定位信息數量通知應遵循以下規定：
a) 上級平臺將收到來自下級平臺的車輛定位信息數量定期予以統計，并定期給下級平臺發送通知該統計數據；
b) 上下級平臺根據此數據進行車輛定位信息接收與發送數量核對。
4.3.3 車輛動態信息交換業務類流程
4.3.3.1 下級平臺向上級平臺上傳車輛注冊信息
下級平臺每次收到車載終端鑒權信息后，應向上級平臺上傳該車輛注冊信息。
4.3.3.2 下級平臺向上級平臺實時上傳車輛定位信息
下級平臺在收到車輛定位信息后，應實時向上級平臺上傳該車輛定位信息。
4.3.3.3 上級平臺向下級平臺實時交換車輛定位信息
上級平臺在向下級平臺交換車輛定位信息前，向下級平臺發送啟動車輛定位信息交換請求消息。下級平臺在收到該消息并應答后，上級平臺開始向下級平臺實時交換車輛定位信息。
上級平臺向下級平臺發出啟動車輛定位信息交換請求消息包括以下三種情況：
a) 當上級平臺分析有車輛進入非歸屬地區地理區域時，應向該非歸屬地區的下級平臺下發該命令通知下級平臺，有車輛進入該地理區域；
b) 當上級平臺人工指定車輛交換到指定下級平臺時，應向該指定下級平臺下發該命令通知下級平臺，指定車輛定位信息應交換到該平臺；
c) 當上級平臺在應急狀態監控某車輛時，應將該車輛上傳車輛定位信息下發給該車輛歸屬下級平臺，并向該車輛歸屬下級平臺下發該命令。
上級平臺結束向下級平臺發送車輛定位信息交換應遵循以下規定：
a) 當進入非歸屬地區地理區域的車輛離開該地理區域時，上級平臺向下級平臺發送結束車輛定位信息交換請求消息，通知下級平臺將停止車輛定位信息數據交換；
b) 當上級平臺人工取消指定車輛交換到指定下級平臺時，應向該指定下級平臺發送結束車輛定位信息交換請求消息，并取消該車輛定位信息交換到該平臺；
c) 當上級平臺結束應急狀態完成某車輛監控時，應向該車輛歸屬的下級平臺發送結束車輛定位信息交換請求消息，并不再向該車輛歸屬的下級平臺發送車輛定位信息。
4.3.3.4 下級平臺向上級平臺補報車輛定位信息
如雙方平臺之間主從通信鏈路中斷，需在雙方主從鏈路通信恢復后補發鏈路中斷期間的車輛定位信息。
下級平臺向上級平臺補報車輛定位信息流程應遵循以下規定：
a) 下級平臺上傳定位數據過程中與上級平臺鏈路中斷時，應記錄斷開時間（在雙方沒有應用業務數據包交互的情況下，以接收到上級平臺最后一條從鏈路保持應答數據包的時間為準；否則，以最后一次與上級平臺進行完整應用業務數據包交互的時間為準）；
b) 下級平臺重新登錄后，根據斷開時間自動向上級平臺發送中斷時間段內收到的車輛定位信息。
4.3.3.5 上級平臺向下級平臺補發車輛定位信息
如雙方平臺之間主從通信鏈路中斷，需在雙方主從鏈路通信恢復后補發鏈路中斷期間的車輛定位信息。
上級平臺向下級平臺補發車輛定位信息流程應遵循以下規定：
a) 下級平臺在交換數據過程中與上級平臺鏈路中斷時，應記錄斷開時間（在雙方沒有應用業務數據包交互的情況下，以接收到上級平臺最后一條從鏈路保持應答數據包的時間為準；否則，以最后一次與上級平臺進行完整應用業務數據包交互的時間為準）；
b) 在主從通信鏈路再次建立后，下級平臺根據記錄的平臺斷開時間，向上級平臺發送補發車輛定位信息請求；
c) 上級平臺在收到下級平臺的補發車輛定位信息請求后進行應答，并按照4.5.3.2.3的約定進行車輛定位信息的補發流程。
4.3.3.6 交換指定車輛定位信息
由于跨域車輛離開該跨域地區地理地域，上級平臺即終止向下級平臺的車輛f定位信息交換流程，若下級平臺仍需要獲得駛出本地理地域的指定車輛的實時定位信息，應按照交換指定車輛定位信息流程操作。
交換指定車輛定位信息流程應遵循以下規定：
a) 下級平臺向上級平臺發送“申請交換指定車輛定位信息”請求消息，上級平臺對下級平臺“申請交換指定車輛定位信息”請求消息進行應答后，開始實時向下級平臺發送車輛定位信息；
b) 下級平臺需要停止指定車輛定位信息的交換時，發送“取消申請交換指定車輛定位信息”請求消息，上級平臺收到該消息后進行應答，并終止指定車輛定位信息的發送。
4.3.3.7 上報駕駛員身份識別信息
上級平臺通過向下級平臺發送某車輛上報駕駛員身份識別信息的請求，下級平臺接收到請求后，應將指定車輛的當前營運駕駛員身份識別信息上報給上級平臺。上級平臺接收到駕駛員身份識別消息后，進行入庫記載并給下級平臺應答。
4.3.3.8 上報車輛電子運單
上級平臺通過向下級平臺發送上報車輛電子運單的請求，下級平臺接收到請求后，應將指定車輛當前電子運單信息上報給上級平臺，上級平臺接收到電子運單信息后．進行入庫記載并給下級平臺應答。
4.3.4 平臺間信息交互業務類流程
4.3.4.1 平臺查崗
上級平臺對于接入的下級平臺進行平臺值守情況查詢，確保下級平臺時刻處于人員值守狀態。實現流程應遵循以下規定：
a) 上級平臺不定期對接入平臺下發相關常識性問題；
b) 下級平臺接到信息后，通過監控客戶端實時提醒在線值班人員；
c) 在線值班人員在查看信息后，根據信息要求回復相應內容。
4.3.4.2 下發平臺間報文
上級平臺不定期向下級平臺下發報文信息，下級平臺收到報文信息后向上級平臺應答接收成功標識。
4.3.5 車輛報警信息交互業務類流程
營運車輛在運行過程中，產生的相關報警處理流程應遵循以下規定：
a) 車輛車載終端設備或下級平臺產生報警信息后，即刻上報上級平臺；
b) 下級平臺對報警信息應及時做出處理，并將處理報警信息結果上報上級平臺；
c) 上級平臺在收到下級平臺的報警信息后，等待下級平臺上報相應的報警處理結果信息；若在一定時間間隔內未收到相應報警處理結果信息，則向下級平臺下發報警督辦請求；
d) 上級平臺可根據車輛定位數據分析產生報警預警信息，或者將跨域車輛的報警信息，即刻下發到相關下級平臺，下級平臺不必處理報警預警信息和轉發跨域車輛報警信息。
4.3.6 車輛監管業務類流程
4.3.6.1 單向監聽
上級平臺通過對下級平臺下發單向監聽請求，實現對指定車輛的監聽。實現流程應遵循以下規定：
a) 下級平臺在接收到上級平臺的單向監聽請求消息后，即刻對指定的車輛下發監聽命令；
b) 車輛車載終端設備收到監聽信息后，即刻與指定的監聽電話號碼進行連接，下級平臺在收到車載終端反饋的連接結果后，將連接結果上報給上級平臺。
4.3.6.2 車輛拍照
上級平臺向下級平臺下發拍照請求，下級平臺轉發上級平臺發送的拍照請求參數到指定車輛的車載終端設備，由車載終端設備完成拍照并實現上傳到下級平臺，下級平臺將收到的圖片信息上報給上級平臺。
4.3.6.3 下發車輛報文
上級平臺向下級平臺發送“下發車輛報文”請求，由下級平臺向指定車輛的車載終端設備下發報文信息，信息發送狀態返回給上級平臺。
4.3.6.4 上報車輛行駛記錄信息
上級平臺向下級平臺下發讀取指定車輛行駛記錄信息的請求，下級平臺接收到請求后向相應的車輛下發行駛記錄信息上報的指令，下級平臺在收到車輛車載終端設備返回的行駛記錄信息后，立即上報給上級平臺。
4.3.6.5 車輛應急接入
在應急情況下，上級平臺需要及時監控某車輛時，上級平臺向下級平臺下發車輛應急接人監管平臺命令，下級平臺轉發上級平臺發送的命令到指定車輛的車載終端，并將車載終端返回的信息上傳到上級平臺。車載終端按照命令要求向接人的政府監管平臺申請鑒權，接人該監管平臺并斷開與原監控平臺的連接。此時，被接入的政府監管平臺按照監控平臺的要求實現對車輛的監控。應急狀態結束后，該政府監管平臺應按照JT/T 808—2011中8.11的要求，直接向車載終端發送終端控制命令，將車載終端的控制權轉交給車輛原監控平臺。
4.3.7 車輛靜態信息交換業務類流程
上級平臺向下級平臺請求補報車輛靜態信息，流程應遵循以下規定：
a) 下級平臺向上級平臺進行車輛定位信息上報時，發現車輛的靜態信息缺失后，即刻向下級平臺發送補報車輛靜態信息請求；
b) 下級平臺在收到請求后，即刻將相應車輛的靜態信息數據補報給上級平臺；
c) 上級平臺接收到車輛的靜態信息數據后，進行入庫記載并給下級平臺應答。
4.4 協議消息格式
4.4.1 消息說明
每條信息包含數據頭和數據體兩部分。數據流遵循大端（big-endian，即高字節在前，低字節在后）排序方式的網絡字節順序，未使用的數據位皆填0x00。
4.4.2 數據類型
基本數據類型規定見表1。
表1 基本數據類型
time_t 64位無符號整型，8字節
BYTE 單字節
BYTES 多字節
Octet String 定長字符串，位數不足時，右補十六進制0x00，漢字采用CBK編碼
uint16_t 16位無符號整型，2字節
uint32_t 32位無符號整型，4字節
4.4.3 數據結構
在兩個平臺之間進行數據交換時，采用的數據結構規定見表2。
表2 數據結構
Head Flag 頭標識
Message Header 數據頭
Message Body 數據體
CRC Code CRC校驗碼
End Flag 尾標識
4.4.4 頭標識
頭標識為字符0x5b。
4.4.5 尾標識
尾標識為字符0x5d。
數據內容進行轉義判斷，轉義規則如下：
a) 若數據內容中有出現字符0x5b的，需替換為字符0x5a緊跟字符0x01;
b) 若數據內容中有出現字符0x5a的，需替換為字符0x5a緊跟字符0x02；
c) 若數據內容中有出現字符0x5d的，需替換為字符0x5e緊跟字符0x01;
d) 若數據內容中有出現字符0x5e的，需替換為字符0x5e緊跟字符0x02。
4.4.6 數據頭
在兩個平臺之間進行數據交換時，采用數據結構的數據頭部分規定見表3。
表3 數據頭格式
字段 類型 描述及要求
MSC_LENGTH uint32_t 數據長度（包括頭標識、數據頭、數據體和尾標識）
MSG_SN uint32_t 報文序列號a
MSG_ID uint16_t 業務數據類型
MSG_GNSSCENTERID uint32_t 下級平臺接入碼，上級平臺給下級平臺分配的唯一標識號
VERSION_FLAG BYTES 協議版本號標識，上下級平臺之間采用的標準協議版本編號；長度為三個字節來表示：0x01 0x02 0x0F表示的版本號是V1.2.15，依此類推
ENCRYPT_FLAG BYTE 報文加密標識位b:0表示報文不加密，1表示報文加密
ENCRYPT_KEY uint32_t 數據加密的密鑰，長度為四個字節
注：
a 占用四個字節，為發送信息的序列號，用于接收方檢測是否有信息的丟失。上級平臺和下級平臺按自己發送數據包的個數計數，互不影響。程序開始運行時等于零，發送第一幀數據時開始計數，到最大數后自動歸零。
b 用來區分報文是否進行加密，如果標識為1，則說明對后續相應業務的數據體采用ENCRYPT_KEY對應的密鑰進行加密處理。如果標識為0，則說明不進行加密處理。
4.4.7 數據加密
4.4.7.1 數據密鑰格式
數據傳輸中所采用的數據密鑰格式規定見表4。
表4 數據密鑰格式
字 段 類 型 描述及要求
ENCRYPT_KEY uint32_t 數據加密的密鑰，長度為四個字節
4.4.7.2 數據加密要求
數據加密具體要求如下：
a) 加密只針對報文的數據體部分進行。密鑰通過網絡進行傳輸，不同的報文可采用不同的密鑰進行加密；
b) 在數據包發送之前，將數據包內容與偽隨機序列按字節進行異或運算；
c) 加密算法如下：用N模偽隨機序列發生器產生偽隨機字節序列。將待傳輸的數據與偽隨機碼按字節進行異或運算；
d) 不同的上下級平臺之間，加密的算法是一致的，但是針對M1、IA1、IC1的不同。數據先經過加密而后解密。
4.4.7.3 加密算法
加密算法見表5。
表5 加密算法
Const unsigned uint32_t M1 = A;
Const unsigned uint32_t IA1 = B;
Const unsigned uint32_t IC1 = C;
Void encrypt( uint32_t key , unsigned char * buffer, uint32_t size )
｛
uint32_t idx = 0;
if( key = = 0 )
key = 1;
while(idx < size )
｛
key = IAl * ( key % M1 ) + IC1;
buffer [ idx + + ]^ = ( unsigned char) (( key > > 20) &0xFF) ;
｝
｝
4.4.8 數據校驗
從數據頭到校驗碼前的CRC16_CClrIT的校驗值，遵循大端排序方式的規定．，
數據CRC校驗碼格式規定見表6。
表6 校驗碼格式
字 段 字節數 類 型 描述及要求
CRC CODE 2 uint16_t 數據CRC校驗碼
4.5 數據實體格式
4.5.1鏈路管理業務類
4.5.1.1 主鏈路登錄請求消息
鏈路類型：主鏈路。
消息方向：下級平臺往上級平臺。
業務數據類型標識：UP_CONNECT_REQ。
描述：下級平臺向上級平臺發送用戶名和密碼等登錄信息。
下級平臺登錄請求消息數據體規定見表7。
表7 主鏈路登錄請求消息數據體
字段名 字節數 類型 描述及要求
USERID 4 uint32_t 用戶名
PASSWORD 8 Octet String 密碼
DOWN_LINK_IP 32 Octet String 下級平臺提供對應的從鏈路服務端IP地址
DOWN_LINK_PORT 2 uint16_t 下級平臺提供對應的從鏈路服務端口號
4.5.1.2 主鏈路登錄應答消息
鏈路類型：主鏈路。
消息方向：上級平臺往下級平臺。
業務數據類型標識：UP_CONNECT_RSP。
描述：上級平臺對下級平臺登錄請求信息進行安全驗證后，返回相應的驗證結果。
主鏈路登錄應答消息數據體規定見表8。
