JP2018005848A - On-vehicle communication device - Google Patents

Abstract

PROBLEM TO BE SOLVED: To reduce a communication load when an on-vehicle device transmits vehicle data to be buffered to a server.SOLUTION: An on-vehicle communication device is the device to be mounted on a vehicle and includes: a buffer section for buffering multiple kinds of vehicle data flowing in an in-vehicle communication network; a table generation section for generating a table where the kind of selection object vehicle data and a compression method of the vehicle data of the selection object kind are regulated on the basis of information to be received from a server; a transmission data generation method for selecting the vehicle data of the selection object kind from the buffered multiple kinds of vehicle data on the basis of the table generated by the table generation section, and compressing the selected vehicle data; and a transmission section for transmitting the vehicle data compressed by the transmission data generation section to the server.SELECTED DRAWING: Figure 3

Description

  The present invention relates to an in-vehicle communication device.

  Conventionally, in an information collection system including an in-vehicle device and a center (server), an information collection system in which the in-vehicle device buffers vehicle data and uploads the data to a server is known (for example, see Patent Document 1).

JP 2007-293536 A

  However, vehicle data buffered by the in-vehicle device is diversified, and if all of the vehicle data is transmitted to the server as it is, the communication load may increase.

  Accordingly, an object of the present invention is to reduce a communication load when transmitting vehicle data buffered by an in-vehicle device to a server.

According to one aspect of the present disclosure, an in-vehicle communication device mounted on a vehicle,
A buffer unit for buffering a plurality of types of vehicle data flowing through the in-vehicle communication network;
A table creation unit that creates a table that defines a type of vehicle data to be sorted and a compression method of the type of vehicle data to be sorted based on information received from the server;
Based on the table created by the table creation unit, the type of vehicle data to be sorted is selected from among a plurality of types of the vehicle data buffered by the buffer unit, and the sorted vehicle data is compressed. A transmission data generation unit to perform,
There is provided an in-vehicle communication device including a transmission unit that transmits the vehicle data compressed by the transmission data generation unit to the server.

  ADVANTAGE OF THE INVENTION According to this invention, the communication load at the time of transmitting the vehicle data buffered by a vehicle-mounted apparatus to a server can be reduced.

1 is a diagram illustrating an example of an information collection system 1. FIG. It is a figure which shows each example of CAN data, a shift table, and the data after a compression process. It is a flowchart which shows an example of the process performed by ECU212.

  Hereinafter, embodiments will be described in detail with reference to the accompanying drawings.

  FIG. 1 is a diagram illustrating an example of an information collection system 1. FIG. 2 is a diagram illustrating each example of CAN data, a shift table, and data after compression processing. The information collection system 1 includes an in-vehicle device 21 and a server 41.

  The vehicle-mounted device 21 includes a data communication module (DCM: Data Communication Module) 211 and an ECU (Electronic Control Unit) 212. The ECU 212 is connected to various electronic components (sensors such as a vehicle speed sensor and various ECUs) in the vehicle via a CAN (controller area network) 90.

  The data communication module 211 communicates with the server 41. The in-vehicle device 21 exchanges various information with the server 41 via the data communication module 211.

  ECU 212 includes a buffer unit 213, a table creation unit 214, a transmission data generation unit 215, and a transmission unit 216.

  The buffer unit 213 buffers (accumulates) a plurality of types of CAN data flowing in the CAN 90 in the data buffer. The data buffer is, for example, a ring buffer that can be formed by a RAM (Read Only Memory). The CAN data to be buffered is, for example, a predetermined type of CAN data. The CAN data to be buffered may include data relating to control such as CAN data relating to brake control, CAN data relating to engine control, CAN data relating to various vehicle support controls, and the like. In addition, the CAN data to be buffered may include diagnostic data, data on the state of various devices, data on vehicle behavior (speed, acceleration, etc.), and the like.

  Note that a CAN frame (data frame) in the standard format of the CAN protocol is not shown, but SOF (Start Of Frame, 1 bit), ID (11 bits), RTR (1 bit), control field (6 bits), data A field (0 to 64 bits), a CRC sequence (15 bits), a CRC delimiter (1 bit), an ACK slot (1 bit), an ACK delimiter (1 bit), and an EOF (End Of Frame, 7 bits). CAN data transmitted by a CAN frame (hereinafter also referred to as “CAN data body”) is included in the data field, and the CAN frame can transmit up to 8 bytes of data in units of 1 byte. The length of the CAN data included in the CAN frame is set between 0 and 8 by 4-bit DLC (Data Length Code) in the control field.

  The table creation unit 214 creates the shift table 101 (see FIG. 2) based on the mask information received from the server 41. As shown in FIG. 2, the shift table 101 includes CAN-ID (Identification) of CAN data to be collected (selection target) and columns of “0” and “1” indicating a shift mode (compression method). The mask information from the server 41 includes all information necessary for generating the shift table 101. For example, the mask information may be substantially the shift table 101 itself. The shift table 101 is stored in a nonvolatile memory (not shown) in the vehicle-mounted device 21 such as an EEPROM (Electrically Erasable Programmable Read-Only Memory).

  Based on the shift table 101, the transmission data generation unit 215 selects CAN data of the type to be collected from a plurality of types of CAN data buffered by the buffer unit 213, and compresses the selected CAN data. . More specifically, the transmission data generation unit 215 selects and extracts CAN data having a CAN-ID defined in the shift table 101 from a plurality of types of CAN data buffered by the buffer unit 213. . Then, the transmission data generation unit 215 compresses the extracted CAN data according to the shift mode defined in the shift table 101. The transmission data generation unit 215 transmits the compressed CAN data to the output buffer.

  For example, FIG. 2 shows a plurality of types of CAN data 102 buffered by the buffer unit 213 (in this example, for a period from time 396 ms to 408 ms). In FIG. 2, the CAN data 102 includes data related to one CAN-ID (CAN data body) at each time, but in reality, data related to a large number of CAN-IDs at each time ( CAN data body). In the example shown in FIG. 2, as shown in the shift table 101, all CAN data of the CAN data 102 is a selection target. When the CAN data body related to the CAN data 102 is compressed according to the shift table 101, data 103 after compression processing is obtained. In FIG. 2, compression is performed in units of nibbles (1 digit in hexadecimal notation). Specifically, the portion where “0” is written in the shift table 101 is deleted / shifted in nibble units. For example, CAN-ID “0x024” is described in the shift table 101 and is a selection target. At this time, the CAN data body “02 5F 01 B0 61 F4 00 00” (hexadecimal notation) of CAN-ID “0x024” is the shift mode “01 11 01 11 11 11 00 00” described in the shift table 101. Accordingly, the data portion where “0” is written is deleted in nibble units, and the remaining data portion is shifted to the position of the deleted data portion (shifted upward). As a result, as shown in the data 103, the data is compressed to “25 F1 B0 61 F4”. If the final byte is a 4-bit fraction when compressed, the upper 4 bits are stored and the lower 4 bits are padded with zeros. That is, in the data portion of the data 103 at time 400 ms in FIG. 2, “0” is assigned to the least significant bit and the next least significant 4 bits (see P).

  The transmission unit 216 transmits the CAN data (CAN data in the output buffer) compressed by the transmission data generation unit 215 to the server 41 via the data communication module 211.

  FIG. 3 is a flowchart illustrating an example of processing executed by the ECU 212.

  When the process shown in FIG. 3 is started, a timer is started (step S300). If the timer is not successfully started, the retry is made until the number of retries reaches a predetermined number (for example, 3 times) in step S304. When the number of retries reaches a predetermined number (YES in step S304), the process ends abnormally.

  When the timer has been successfully started, the process proceeds to step S306, where the timer waits for exceeding a predetermined value (for example, an arbitrary value between 100 ms and 500 ms). When the timer exceeds a predetermined value (YES in step S306), the CAN data accumulated in the data buffer is acquired for one frame (step S308). At this time, the acquired frame in the data buffer is cleared (step S310). Then, the CAN-ID of the acquired frame is extracted (step S312), and it is determined whether or not the extracted CAN-ID is defined in the shift table (see FIG. 2). When the extracted CAN-ID is not defined in the shift table (see FIG. 2) (NO in step S314), the process proceeds to step S328.

  When the extracted CAN-ID is defined in the shift table (see FIG. 2) (YES in step S314), the CAN data acquired in step S308 is compressed according to the shift table (step S316 to step S324). Specifically, it is compared with the shift table in units of 1 nibble (step S316). When the nibble in the shift table is “0” (YES in step S318), the nibble in the CAN data is deleted (step S320). The data for one nibble is shifted (step S322). Thus, when collation of all nibbles in the shift table is completed (YES in step S324), the compression of the CAN data acquired in step S308 is completed, and the process proceeds to step S326.

  When the compression of the CAN data acquired in step S308 is completed, the CAN data for one frame acquired in step S308 is transmitted to the output buffer (step S326). The above steps S306 to S326 are executed until no CAN data is accumulated in the data buffer (YES in step S328).

  According to the present embodiment, the following effects are achieved, among others.

  According to the present embodiment, the various CAN data accumulated by the buffer unit 213 is not transmitted as it is to the server 41 as described above, but is selected and compressed based on the shift table. It is transmitted to the server 41. Thereby, the communication load can be reduced as compared with the comparative example in which all the various CAN data accumulated by the buffer unit 213 is transmitted to the server 41 as it is. Accordingly, the storage capacity for the information collection system 1 in the vehicle-mounted device 21 and the storage capacity for the information collection system 1 in the server 41 can be reduced. In addition, unlike the comparative example, a sorting process for sorting desired CAN data out of various CAN data sent from the vehicle-mounted device 21 becomes unnecessary on the server 41 side, so the processing load on the server 41 side is reduced. it can. Further, since the CAN data is compressed according to a predetermined compression method (a compression method defined in the shift table), the confidentiality of the transmission data can be improved as compared with the comparative example in which the CAN data is sent to the server in plain text. This is a useful effect for CAN data (which can include control data) that requires particularly high confidentiality. The server 41 can decode (decompress) the received CAN data based on the mask information that is the original data of the shift table. Further, since the shift table can be created so that the portion corresponding to the necessary data portion of the CAN data to be collected becomes “1”, the server 41 can acquire the necessary information without excess or deficiency.

  Further, according to the present embodiment, the shift table is created based on the information from the server 41 as described above, so that the contents of the shift table can be easily changed (added, deleted, etc.). Thereby, it is possible to flexibly cope with a change in the CAN data to be collected.

  Although each embodiment has been described in detail above, it is not limited to a specific embodiment, and various modifications and changes can be made within the scope described in the claims. It is also possible to combine all or a plurality of the components of the above-described embodiments.

1 Information collection system 21 OBE 41 Server 90 CAN
101 Shift table 211 Data communication module 212 ECU
213 Buffer unit 214 Table creation unit 215 Transmission data generation unit 216 Transmission unit

Claims (1)

An in-vehicle communication device mounted on a vehicle,
A buffer unit for buffering a plurality of types of vehicle data flowing through the in-vehicle communication network;
A table creation unit that creates a table that defines a type of vehicle data to be sorted and a compression method of the type of vehicle data to be sorted based on information received from the server;
Based on the table created by the table creation unit, the type of vehicle data to be sorted is selected from among a plurality of types of the vehicle data buffered by the buffer unit, and the sorted vehicle data is compressed. A transmission data generation unit to perform,
A vehicle-mounted communication device comprising: a transmission unit that transmits the vehicle data compressed by the transmission data generation unit to the server.

Images