GB/T 32960.3-2016 English PDF (GB/T32960.3-2016)

Delivery: 3 seconds. Download true-PDF + Invoice.
Get Quotation: Click GB/T 32960.3-2016 (Self-service in 1-minute)
Historical versions (Master-website): GB/T 32960.3-2016
Preview True-PDF (Reload/Scroll-down if blank)

GB/T 32960.3-2016: Technical specifications of remote service and management system for electric vehicles - Part 3: Communication protocol and data format
GB/T 32960.3-2016
Technical specifications of remote service and management system for electric vehicles - Part 3. Communication protocol and data format
ICS 43.040.99
T35
National Standards of People's Republic of China
Electric car remote service and management system technical specifications
Part 3. communication protocols and data formats
Issued on. 2016-08-29
2016-10-01 implementation
Administration of Quality Supervision, Inspection and Quarantine of People's Republic of China
Standardization Administration of China released
Table of Contents
Introduction Ⅲ
1 Scope 1
2 Normative references 1
3 Terms and definitions
4 2 General requirements
5 Communication Connection 2
5.1 connection is established 2
5.2 Information Transmission 3
Statistics reported 5.3 3
5.4 Disconnect 3
5.5 replacement mechanism 4
6 packet structure and definitions 4
6.1 Data Description 4
6.1.1 Data Types 4
6.1.2 Transport Rule 4
6.2 Packet Structure 4
6.3 Command Unit 5
6.3.1 command identifies 5
6.3.2 Acknowledge Flag 5
6.4 Time 6
7 data unit format and definitions 6
6 7.1 Vehicle Sign
7.2 real-time information reporting 7
7.2.1 real-time information reporting format 7
7.2.2 Types of information signs 7
7.2.3 message body 7
7.3 vehicle Sign 13
7.4 platform Sign 13
Sign 14 7.5 Platform
Appendix A (normative) Field Definitions section 15
Annex B (informative) vehicle terminal communication protocol to the platform 18
Foreword
GB/T 32960 "Electric Vehicles and Remote Service Management System technical specifications" is divided into three parts.
--- Part 1. General;
--- Part 2. vehicle terminal;
--- Part 3. communication protocols and data formats.
This section GB/T Part of 332,960.
This section drafted in accordance with GB/T 1.1-2009 given rules.
This part is proposed by the Ministry of Industry and Information Technology of the People's Republic of China.
This part of the National Automotive Standardization Technical Committee (SAC/TC114) centralized.
This section is drafted. Beijing Institute of Technology, China Automotive Technology and Research Center, Shanghai Automotive Group Co., Ltd., Neusoft Group shares
Parts Limited, Wuhan British Tai Site Electronic Technology Co., Ltd., Beijing Institute of a new source of Information Technology Co., Shanghai International Automobile City Group
Limited, Putian New Energy Co., Ltd., Huawei Technologies Co., Ltd., BYD Automobile Industry Co., Ltd., Zhengzhou Yutong Bus Shares
Ltd., Nantong swan Information Technology Co., Ltd., Brilliance China Automotive Holdings Limited, Beijing Products Quality Supervision and Inspection Institute, Shenzhen
BYD Daimler New Technology Co., Ltd., Beijing Automotive Research Institute Co., Ltd., Chongqing Changan New Energy Automobile Co., Ltd., Beijing New Energy
Source Automobile Co., Ltd., Shanghai Automotive Technology Co., Ltd. Shi Ying, Zhejiang Geely Automobile Research Institute Co., Ltd., Wuhan electric car technology
Development Co., Ltd., Pan Asia Technical Automotive Center Co., Ltd., SAIC-GM-Wuling Automobile Co., Ltd., Guangzhou Toyota Motor Co., Ltd.,
Shanghai Volkswagen Automobile Co., Ltd., FAW - Volkswagen Automotive Co., the South East (Fujian) Motor Co., Ltd.
The main drafters of this section. Wang Zhen slope, Zhou Rong, Liu Peng, Pu Huan, LONG Chao Hua, Lu Chun, Hou Yi, Meng Xiangfeng, Chen Han Jun, Wang Lei, Mi Feng,
Ding Xiaohua, Wu Zhiqiang, Fu Jing, Liu Kai, Yong-Jun Liu, Jiang Feng, Lv Shujun, Filling Zhaoya Tao, a single punch, Zhang Wenjie, Guan Peng Shu, Wang Xu, Zhu Junjun,
Wangwen Yang, Yang Xiantao, many, Gao pioneer Pengyong Lun, Fangfang, Yang Yang, Xiong Xiaofei, Huang Zhicheng, Yu Xuetao, Xu Yan, Li Runhua, Ma Tao,
Wang Ting, Zheng Yanting, Liang Lijuan, classes given East, Tan Huaqiang, Guo Wen Wen, Fan Dapeng.
Electric car remote service and management system technical specifications
Part 3. communication protocols and data formats
1 Scope
This section GB/T 32960 specifies the electric car with remote service management system protocol architecture, communication links, and data packet structure
Definitions, data unit format and definitions.
This section applies to electric vehicles and remote service management system transmitting communication between the vehicle terminal platform to platform should be implemented by reference.
2 Normative references
The following documents for the application of this document is essential. For dated references, only the dated version suitable for use herein
Member. For undated references, the latest edition (including any amendments) applies to this document.
GB/T 1988 Technical information interchange bit coded character set
GB 16735 Road vehicles - Vehicle identification number (VIN)
GB 18030 Information technology - Chinese coded character set
GB/T 19596 Electric Vehicle Terminology
GB/T 32960.1 electric car remote service and management system specification - Part 1. General
3 Terms and Definitions
GB/T 19596, GB/T 32960.1 defined and the following terms and definitions apply to this document.
3.1
Client platform clientplatform
Time data exchange platform as a vehicle data sender and remote service management platform.
3.2
Server platform serverplatform
Time data exchange platform, as vehicle data receiver and remote service management platform.
3.3
Register register
Client platform provides static information to the vehicle platform and server platform for vehicle platforms and authentication process.
NOTE. Vehicle static information defined in Appendix A of A.2.
3.4
Upstream upstream
The direction of data transmission from the client to the server.
3.5
Downstream downstream
End data transmission service from the direction of the client.
3.6
Vehicles Sign vehiclelogin
Before the vehicle status information reported to the client to the server to sign certification.
3.7
Vehicles Sign vehiclelogout
Client server data to confirm the vehicle to stop normally transmitted from the platform and logout.
3.8
Sign platformlogin platform
Client platform before the end of the service platform to report vehicle status information security certification.
3.9
Sign platformlogout platform
Client platform stopped for any reason data transfer and log out from the server platform.
3.10
Encryption encryption
Data transmission process of encryption.
3.11
Decryption deciphering
After receiving the data, the process of internet solutions password.
3.12
Assembly assembly
Real-time information of each message body part of the course of free combination.
4 General requirements
4.1 protocol structure to TCP/IP network control protocol as the underlying communication protocol bearer, as shown in FIG.
1 electric car with remote service management system communication protocol stack
Connected to the communication protocol between 4.2 platform should meet this part of Chapter 5, the provisions of Chapter 6 and Chapter 7.
4.3 vehicle terminal to the platform communication protocol should refer to Appendix B.
5 communication connection
5.1 connection establishment
Client platform initiates a connection request to the communication server platform, when the communication link connection is established, the client-side service platform should automatically
Sign in internet transmit identification information, the server platform to deal with the received data validation; when the check is correct, the server platform should
Returns success response; checksum error, the server platform should store error data records and notify the client platform. Login process shown in Figure 2
FIG.
Figure 2 platform sign a schematic flow diagram
Client platform should be completed by this sign transmitted after receiving the reply command server platform; client platform is not within the specified time
Received reply command, 1min should re-sign in each interval; after repeated three times in a row if the sign is no answer, the interval should be 30min, continued heavy
The new link and the data is not successfully transmitted before linking stored successfully resubmitted repeat sign in the interval can be set.
5.2 Information Transmission
5.2.1 client platform after a successful login, the server should be reported to the real-time information platform for electric vehicles, real-time information reporting process shown in Figure 3
FIG.
Figure 3 flow diagram information reporting
5.2.2 When a client server platform to platform reporting information, the server platform to deal with the received data validation. When the check is correct
When the server platform to do the right answer; when parity error occurs, the server platform to do the wrong answer. When answering message service client platform error, passenger
The client should resend vehicle real-time information under this section, shall be re-sent at intervals of 1min 1, failed three times longer sent.
5.2.3 Client server platform to platform reporting information, the following data should be completed in accordance with the actual situation 7.2.3. Number of drive motor
Data, vehicle data, fuel cell data, engine data and vehicle location data, extreme data, alarm data reported after assembly. Cross-platform
In other data, and user-defined data exists, data exchange platform should complete and user-defined data reporting.
5.2.4 Client server platform to platform reporting time period information should be adjusted. Maximum vehicle information reporting time period should not be
Over 30s; when a vehicle appears in Table 17 Level 3 alarm, reporting failure point in time before and after the data and information sampling period is not 30s
More than 1s, which fails before the data should be transmitted in the form of replacement.
5.2.5 When the terminal is encrypted when transmitting data, the client platform should first decrypt the data, re-encrypted and sent to the rear end of the service level
Taiwan, such as the transfer between platforms without re-encryption encryption requirement is not necessary.
Statistics reported 5.3
Statistics should be FTP, HTTP, or HTTPS transmitted to the server platform.
5.4 Disconnect
Server platform should disconnect the client platform based on the following sessions.
--- TCP connection is broken.
Client platform should be disconnected from the server platform based on the following sessions.
--- TCP connection is broken;
--- TCP connection is normal, to have not received a response after the number of retransmissions.
5.5 replacement mechanism
When abnormal data communications link, the client platform should be reported in real-time data stored locally. In the data communications link back to normal
After free time in sending real-time reporting of complete data reporting replacement data store. Replacement of data should be reported within 7 days of the communication link
During anomaly data storage, real-time data reporting format and the same data, and identifies the information reported for the replacement (0x03).
6 packet structure and definitions
6.1 Data Description
6.1.1 Data Types
Data transmission protocol types shown in Table 1.
Table 1 Data Type
Data type Description and Requirements
BYTE unsigned single byte integers (byte, 8)
WORD-byte unsigned integer (word 16)
DWORD unsigned four-byte integer (double-word, 32-bit)
BYTE [n] n bytes
STRING
ASCII character code, 0 if no data is put a terminator, the coded representation see GB/T the 1988;-containing Chinese characters, use area
Bit coding, 2 bytes, the coded representation see GB 18030
6.1.2 Transport Rules
Agreement should be big-endian mode network byte order to deliver words and double words.
6.2 Packet Structure
A complete packet should start character, the command unit identification code, data encryption, data unit length, and parity data unit
Code composed of packet structure and defined in Table 2.
Table 2 packet structure and definitions
Starting byte-defined data type description and requirements
0 start character STRING fixed ASCII character '
Command unit
Command logo
Acknowledge Flag
BYTE
BYTE
Command unit as defined in 6.3
4 unique identification code STRING
When the transfer vehicle data, you should use the vehicle VIN, their word should be consistent with the GB 16735
Provisions. Such as the transmission of other data, using a unique custom encoding
TABLE 2 (cont.)
Starting byte-defined data type description and requirements
BYTE data encryption unit 21
0x01. data is not encrypted; 0x02. Data through RSA encryption algorithm; 0x03. After data
AES128 bit encryption algorithm; "0xFE" represents the exception, "0xFF" indicates invalid, other
Reserved
22 WORD data unit length data unit length is the total number of bytes of data units, valid range. 0 to 65531
24 Data Unit - Data unit format and as defined in Chapter 7
Penultimate one checksum BYTE
Using BCC (XOR checksum) method, calibration range from the first byte command unit opening
Beginning with the latter byte XOR, until the previous byte checksum far, occupies a check code
Byte, when the data encryption unit exists, after calibration should be encrypted, decrypted first check
6.3 Command Unit
6.3.1 Command logo
Command should be identified uniquely identifies the party initiating the command identifier defined in Table 3.
Table 3 identifies the defined command
The coding direction
0x01 vehicle sign uplink
0x02 real-time information reporting uplink
0x03 replacement information reporting uplink
0x04 vehicle Sign uplink
0x05 platform Sign uplink
0x06 platform Sign uplink
0x07 ~ 0x08 reserved for uplink data terminal
0x09 ~ 0x7F uplink data uplink systems reserved
0x80 ~ 0x82 reserved for downlink data terminal
0x83 ~ 0xBF downlink data downlink system reserved
0xC0 ~ 0xFE platform custom custom data exchange
6.3.2 acknowledge flag
Initiate party answers the flag command is 0xFE, indicates that this package is a command packet; when you answer flag is not 0xFE, passive recipient should
It does not answer. When the command pass...