Development and construction of OBD remote monitoring big data platform

1 Background of National VI OBD Remote Monitoring

The new regulations put forward the latest requirements for ECU, T-BOX and testing platform. The specific changes are as follows:

Requirements for ECU: Support at least one of the diagnostic protocols ISO15765, ISO27145, and J1939; need to have an anti-disassembly handshake protocol with TBOX; support a complete set of 19 data stream information such as environment, engine information, and post-processing sensor information (which can be provided through diagnosis or CAN outbound messages); can obtain diagnostic information in 10 dimensions such as vehicle identification number (VIN), software calibration identification number, and calibration verification code (CVN) through the diagnostic protocol.

Requirements for T-BOX: equipped with an authentication encryption chip, only accepting one-way command operations; data must be packaged and uploaded at least with data signature encryption to prevent data from being tampered with during network transmission; data must be collected within 60 seconds of engine start, with a collection cycle of 1 second; positioning accuracy of 1m (before the implementation of National VI b); OBD data must be uploaded once every 24 hours (low power consumption, timed wake-up); 7 days of data can be stored, and local access is supported.

Requirements for the monitoring platform: Vehicle manufacturers need to have a National VI monitoring data platform; accept information from their own National VI vehicles and forward the corresponding plain text information with signature to the national platform; the transmission cycle is 10s; the enterprise platform data is retained for at least 3 years.

02 National VI OBD Remote Monitoring Technical Requirements

Encryption mechanism is also used in information security. Plain text encryption transmission: digital signature

After TBOX arranges the original data collected from the vehicle according to the communication protocol, it uses a specific encryption algorithm and secret key to calculate the data content and generate an anti-counterfeiting label - a digital signature. When sending data, the original data and the digital signature are sent at the same time. After receiving the data, the receiver will perform a certain reverse operation on the data and the digital signature to determine whether the information has been modified. If it has been modified, it is considered invalid information.

During the communication process, the content of the data body can be viewed, but due to the digital signature, the data cannot be forged or modified.

Ciphertext encrypted transmission: data encryption

TBOX uses encryption algorithms to convert the raw data collected from vehicles into ciphertext. When data is sent, the ciphertext is sent directly instead of the raw data. When the receiver receives the ciphertext, it needs the corresponding secret key to reverse the ciphertext and derive the original data.

Data information in the communication process cannot be identified or modified. On the other hand, the asymmetric encryption process is more complicated for the communication process and consumes more resources for the server.

The upload method is as follows: after the terminal is powered on, data tamper-proof information must be filed with the national platform; the on-board terminal collects vehicle data in accordance with the requirements of GB17691-2018; the on-board terminal hard-encrypts the collected data through an encryption chip (on demand); the on-board terminal sends data with a digital signature (tamper-proof) to the enterprise platform; the enterprise platform forwards the vehicle plaintext data with the data signature to the national platform.

The enterprise platform must meet the following requirements when building:

• Data receiving function. The enterprise platform receives data from the vehicle terminal. The communication protocol between the vehicle terminal and the data platform can be found in Appendix Q of GB19691-2018.

• Data forwarding function. The enterprise platform forwards the received data to the national platform. When forwarding data, the data signature must be forwarded together.

• The transmission cycle is 10s, and the communication protocol complies with the requirements of Appendix Q of the National VI Standard. 

• Data storage requirements: Data within 3 years is stored as hot data, and data throughout its life cycle can be stored as cold backup data.

• Data integrity requirement: The platform forwarding data packet loss rate is less than 1%.

• Data accuracy requirement: The error rate of platform forwarding data is less than 1%.

At the same time, private protocols are not available, and data is public and cannot be tampered with. The database is hot stored for 3 years, and a file system is required for cold backup during the life cycle.

When building a monitoring system, the vehicle terminal needs to be provided by a qualified manufacturer, and the terminal product needs to obtain the corresponding qualification certification. The specific requirements are:

• Data collection function requirements. Collect data of the whole vehicle and each component from the vehicle bus , the parameter range must at least include the requirements of Appendix Q of GB17691-2018, and then send the data to the enterprise platform. 

• For vehicle terminal performance requirements and test methods, see Appendix Q.7 of GB17691-2018

• Vehicle terminal positioning security requirements. Vehicle terminals have the ability to prevent positioning forgery and tampering. Manufacturers must register (details to be determined) 

• The abnormality rate of data reported by the vehicle terminal is less than 1%;

• The packet loss rate of data reported by the vehicle terminal is less than 1%; 

• For vehicle terminal security strategy, please refer to Appendix Q.4 of GB17691-2018;

In terms of security strategy, security information is managed by the state. Equipment must be legally licensed before it can be put online.

•  The security chip manufacturer must have SAS security certification and commercial cryptographic model certification, and the security assurance level must be no less than EAL4+.

• Security chips are required to be equipped with a unique identification ID. The identification ID is managed by the national platform and is used to bind the public and private key pairs of the security chip.

• Qualified enterprise platforms submit chip identification ID applications through the national platform. At the same time, the next issuance threshold is controlled according to the activation ratio.

• Data is signed before transmission, and the signature is stored in the private key of the security chip.

• Bind and register the chip identification ID, chip public key, and vehicle VIN in a trinity, and submit the information to the national center platform.

04 Suggestions for building a remote monitoring system

GB17691-2018 defines that enterprises must have their own enterprise emission monitoring data platform. To build their own platform, enterprises must have: enterprise domain name, company logo, business permissions and data permissions. The responsibilities of the enterprise are: the ownership of the platform website belongs to the enterprise, daily vehicle data monitoring, data retention and statistical use, etc.

From the perspective of social resource integration, it does not mean that enterprises must build platforms independently, but only stipulates that enterprises must have corresponding management methods and be responsible for vehicle emissions issues.