In-vehicle device, control method, and computer program

Abstract

This in-vehicle device, which is mounted on a vehicle, comprises: a communication unit that communicates with an external device and transmits sensor data detected by a sensor mounted on the vehicle to the external device; and a buffering control unit that, in accordance with the speed of wireless communication performed by the communication unit with the external device, determines whether or not to perform buffering in which the sensor data is not transmitted by the communication unit and is instead stored in a storage unit, and performs buffering in accordance with the result of the determination.

Description

[Technical Field]

[0001] This application claims priority to Japanese Patent Application No. 2022-148752 filed on September 20, 2022, and incorporates by reference all of the contents of that application. [Background technology]

[0002] Systems that aggregate and analyze sensor data from multiple sensors on a server computer (hereafter referred to as the server), and use the analysis results for driving assistance, are becoming increasingly common. Sensor data is transmitted from sensors mounted on vehicles and sensors attached to infrastructure equipment installed on the roadside (hereafter referred to as infrastructure sensors). In such systems, vehicles communicate with the server via wireless base stations. Vehicles with wireless communication capabilities can also communicate directly with each other without going through a server (so-called vehicle-to-vehicle communication). In vehicle-to-vehicle communication, sensor data from one vehicle can be transmitted to another vehicle, and information held by one vehicle can be transmitted to another vehicle.

[0003] Patent Document 1 below discloses an in-vehicle device (in-vehicle communication control device) that has the function of performing wireless communication with the outside of the vehicle. The in-vehicle communication control device communicates with a content provider outside the vehicle. This in-vehicle communication control device enables content playback without interruption even in sections of the vehicle's planned driving route where the radio wave environment is poor and sufficient download of stream content is not possible. To achieve this, the in-vehicle communication control device of Patent Document 1 buffers downloaded data for playback. The in-vehicle communication control device calculates the amount of data that can be buffered taking into account the vehicle's driving speed and determines whether download is possible. [Prior art documents] [Patent documents]

[0004] [Patent Document 1] Japanese Patent Application Laid-Open No. 2003-61149 Summary of the Invention

[0005] An in-vehicle device according to one aspect of the present disclosure is an in-vehicle device mounted on a vehicle, and includes a communication unit that communicates with an external device and transmits sensor data detected by a sensor mounted on the vehicle to the external device, and a buffering control unit that determines whether to perform buffering, in which the sensor data is stored in a memory unit without being transmitted by the communication unit, depending on the wireless communication speed between the communication unit and the external device, and performs buffering depending on the determination result. [Brief explanation of the drawings]

[0006] [Figure 1] FIG. 1 is a schematic diagram showing a usage pattern of an in-vehicle device according to an embodiment of the present disclosure. [Figure 2] FIG. 2 is a block diagram showing a hardware configuration of the in-vehicle device shown in FIG. [Figure 3] FIG. 3 is a block diagram showing a hardware configuration of the vehicle gateway shown in FIG. [Figure 4] FIG. 4 is a block diagram showing a hardware configuration of the first server shown in FIG. [Figure 5] FIG. 5 is a block diagram illustrating a hardware configuration of the second server illustrated in FIG. [Figure 6] FIG. 6 is a block diagram illustrating a functional configuration of the vehicle gateway illustrated in FIG. [Figure 7] FIG. 7 is a diagram showing a state in which the planned travel route of the vehicle is displayed on the communication history map. [Figure 8] FIG. 8 is a flowchart showing the process executed by the vehicle gateway. [Figure 9] FIG. 9 is a flowchart showing the process executed by the first server. [Figure 10] FIG. 10 is a flowchart showing the process executed by the second server. DETAILED DESCRIPTION OF THE INVENTION

[0007] [Problem to be solved by this disclosure] When a vehicle is located in an environment with low wireless communication speed, it is possible to transmit data successfully by lowering the data quality and reducing the data size. However, if the transmitted data does not meet the quality required for the service provided by the server, the transmitted data will not be used appropriately. In this case, the data transmission itself will be wasted.

[0008] The in-vehicle communication control device disclosed in Patent Document 1 is related to downloading streaming data, and therefore cannot solve the above-mentioned problems related to data transmission (ie, uploading).

[0009] Therefore, the present disclosure aims to provide an in-vehicle device, a control method, and a computer program that can transmit data to an external device without degrading the quality of the transmitted data, even if the vehicle is traveling in an environment with low wireless communication speeds.

[0010] [Effects of this disclosure] According to the present disclosure, it is possible to provide an in-vehicle device, a control method, and a computer program that can transmit data to an external device without degrading the quality of the transmitted data, even if the vehicle is traveling in an environment with low wireless communication speed.

[0011] [Description of the embodiments of the present disclosure] The contents of the embodiments of the present disclosure will be listed and described below. At least some of the embodiments described below may be combined in any desired manner.

[0012] (1) An in-vehicle device according to a first aspect of the present disclosure is an in-vehicle device mounted on a vehicle, and includes a communication unit that communicates with an external device and transmits sensor data detected by a sensor mounted on the vehicle to the external device, and a buffering control unit that determines whether to perform buffering, in which the sensor data is stored in a storage unit without being transmitted by the communication unit, depending on the wireless communication speed between the communication unit and the external device, and performs buffering depending on the determination result. As a result, even if the vehicle travels in an environment with a low wireless communication speed, the in-vehicle device can transmit data to the external device without degrading the quality of the transmitted data. Therefore, the external device can maintain its service.

[0013] (2) In the above (1), the buffering control unit determines to perform buffering when a low-speed communication state occurs in which the wireless communication speed is equal to or lower than a predetermined value within a predetermined range on the planned travel route of the vehicle, and can perform buffering while the vehicle is traveling within the predetermined range. This allows necessary and sufficient buffering to be performed.

[0014] (3) In the above (2), the communication unit may further receive information indicating a required data quality transmitted from the external device, and the required data quality may represent a data volume per unit time of the sensor data transmitted from the in-vehicle device to the external device. The buffering control unit may calculate a predicted time for the vehicle to travel a predetermined distance, and use the predicted time and the required data quality to calculate a storage capacity required for buffering, and determine whether the calculated storage capacity can be secured in the storage unit. This makes it possible to efficiently determine whether buffering is possible.

[0015] (4) In the above (3), the buffering control unit may calculate a predicted time and a storage capacity when the in-vehicle device approaches within a predetermined distance of the predetermined range, and determine whether the storage capacity can be secured in the storage unit. This allows for accurate determination of whether buffering is possible.

[0016] (5) In the above (3) or (4), if the buffering control unit cannot secure the storage capacity, the buffering control unit may cause the communication unit to transmit information indicating that the sensor data cannot be transmitted to the external device. This eliminates the need for the external device to wait for sensor data from the vehicle-mounted sensor, thereby avoiding wasting resources.

[0017] (6) In any one of (3) to (5) above, the communication unit may further receive information indicating an allowable delay time transmitted from the external device, and the buffering control unit may cause the communication unit to transmit information indicating that the sensor data cannot be transmitted to the external device if the predicted time is equal to or greater than the allowable delay time. This eliminates the need for the external device to wait for sensor data from the vehicle-mounted sensor, thereby avoiding wasted resources.

[0018] (7) In any one of (1) to (6) above, the communication unit may further receive a communication history map from outside the in-vehicle device, the communication history map including information representing roads and information representing actual speeds of wireless communication on the roads in association with each other, and the buffering control unit may identify information representing a road corresponding to the planned driving route from the information representing roads included in the communication history map, and use the information representing the actual speed corresponding to the identified information as information representing the wireless communication speed to determine whether to perform buffering. This allows the in-vehicle device to easily determine whether buffering is necessary.

[0019] (8) In any one of (1) to (7) above, after buffering, if no further buffering is required, the buffering control unit may cause the communication unit to transmit the buffered sensor data stored in the storage unit to the external device. This allows the in-vehicle device to transmit the buffered sensor data to the external device without wasting it.

[0020] (9) A control method according to a second aspect of the present disclosure is a control method for an in-vehicle device mounted on a vehicle, the control method including: a communication step of communicating with an external device and transmitting sensor data detected by a sensor mounted on the vehicle to the external device; and a buffering control step of determining whether to perform buffering, in which the sensor data is stored in a storage unit without being transmitted in the communication step, depending on the wireless communication speed between the in-vehicle device and the external device in the communication step, and performing buffering in accordance with the determination result. This allows the in-vehicle device to transmit data to the external device without degrading the quality of the transmitted data, even if the vehicle is traveling in an environment with a low wireless communication speed. This allows the external device to maintain its service.

[0021] (10) A computer program according to a third aspect of the present disclosure causes a computer mounted on a vehicle to implement a communication function for communicating with an external device and transmitting sensor data detected by a sensor mounted on the vehicle to the external device, and a buffering control function for determining whether to perform buffering, in which the sensor data is stored in a storage unit without being transmitted via the communication function, depending on the wireless communication speed between the vehicle and the external device via the communication function, and performing buffering depending on the determination result. This allows the computer to transmit data to the external device without degrading the quality of the transmitted data, even if the vehicle is traveling in an environment with a low wireless communication speed. Therefore, the external device can maintain its service.

[0022] The present invention can be realized not only as an in-vehicle device having such a characteristic processing unit, but also as a control method having steps of such characteristic processing, as a program for causing a computer to execute such steps, as a semiconductor integrated circuit that realizes part or all of the in-vehicle device, or as a service providing system including the in-vehicle device.

[0023] [Details of the embodiments of the present disclosure] In the following embodiments, the same components are denoted by the same reference numerals, and their names and functions are also the same, so detailed descriptions thereof will not be repeated.

[0024] (Overall composition) Referring to FIG. 1, an in-vehicle device 100 according to an embodiment of the present disclosure is mounted on a vehicle 102. Upon receiving a request from a first server 104 that provides a service, the in-vehicle device 100 uploads data that can be used for the service. The service provided by the first server 104 is, for example, a remote monitoring service (e.g., monitoring of traffic conditions or monitoring of the interior of the vehicle (monitoring of the driver's condition, etc.)). The service provided by the first server 104 may also be a service that provides information to the vehicle to assist in driving the vehicle. The uploaded data is sensor data acquired by an in-vehicle sensor mounted on the vehicle 102, as will be described later. In addition, another vehicle 112 equipped with an in-vehicle device similar to the vehicle 102 is also traveling. The vehicle 102 and the other vehicle 112 transmit wireless communication history data to a second server 106 that generates, manages, and distributes a communication history map. As will be described later, the communication history map is a road map divided into a plurality of regions (e.g., rectangular regions) (hereinafter, the divided regions are referred to as "areas"), and each area is associated with the communication speed and signal strength of wireless communication within that area. The second server 106 transmits the communication history map to the in-vehicle device 100 upon request from the in-vehicle device 100.

[0025] Communication between the on-board device 100, on-board devices (not shown) of other vehicles 112, the first server 104, and the second server 106 is performed via a base station 108. The base station 108 provides mobile communication services using, for example, 4G (4th Generation) lines and 5G (5th Generation) lines. The base station 108 is connected to a network 110. The on-board device 100 of the vehicle 102 and the on-board devices of the other vehicles 112 have communication functions according to the communication specifications (4G lines, 5G lines, etc.) provided by the base station 108.

[0026] The first server 104 also receives sensor data from infrastructure sensors 114 that are fixedly installed on the roadside (i.e., on roads (including intersections) and their surrounding areas). The infrastructure sensors 114 are, for example, image sensors (digital surveillance cameras, etc.), radars (millimeter-wave radars, etc.), or laser sensors (LiDAR (Light Detection and Ranging)), etc.). The infrastructure sensors have a communication function with the base station 108, and transmit acquired sensor data to the first server 104 via the base station 108 and the network 110.

[0027] The vehicle 102, the other vehicle 112, the pedestrian 900, etc. are detection targets of the infrastructure sensor 114. The vehicle 102 and the other vehicle 112 are also equipped with on-board sensors. The other vehicle 112 and the pedestrian 900 are detection targets of the on-board sensor mounted on the vehicle 102. The vehicle 102 and the pedestrian 900 are detection targets of the on-board sensor mounted on the other vehicle 112.

[0028] Sensor data acquired by on-board sensors installed in the vehicle 102 is transmitted to the first server 104 via the base station 108 and the network 110. The first server 104 analyzes the sensor data received from the vehicle 102 and the infrastructure sensors 114 and uses the data for its services.

[0029] FIG. 1 shows one base station 108, one vehicle 102 equipped with an on-board device 100, and one other vehicle 112. However, this is merely an example. Typically, multiple base stations are provided. Multiple vehicles are traveling and upload sensor data to the first server 104, and multiple other vehicles 112 are traveling and upload communication history data to the second server 106. There may be vehicles that do not have an on-board device. Vehicles that do not have an on-board device are detected as dynamic objects.

[0030] (Hardware configuration of the in-vehicle device) 2, an example of the hardware configuration of the on-board device 100 mounted on the vehicle 102 is shown. The on-board device 100 includes a communication unit 120, an on-board gateway 122, an on-board sensor 124, a vehicle state management unit 126, a driving control unit 128, and a bus 132.

[0031] The communication unit 120 performs wireless communication with external devices of the vehicle 102 (for example, communication with the first server 104 via the base station 108). The communication unit 120 includes an integrated circuit (IC) for performing modulation and multiplexing employed in wireless communication, an antenna for transmitting and receiving radio waves at a predetermined frequency, and an RF (Radio Frequency) circuit. The communication unit 120 also has a function of communicating with a global navigation satellite system (GNSS) such as a global positioning system (GPS). The communication unit 120 may also have a communication function such as Wi-Fi.

[0032] The in-vehicle gateway 122 plays a role in connecting the communication function (specifically, communication specifications) with the outside of the vehicle and the communication function (communication specifications) within the vehicle (for example, communication protocol conversion, etc.) Furthermore, as will be described later, when uploading data to the first server 104, the in-vehicle gateway 122 controls buffering of the data to be uploaded depending on the state of the wireless communication environment.

[0033] The bus 132 is responsible for communication functions within the vehicle, and communication (i.e., data exchange) between the in-vehicle gateway 122, the in-vehicle sensors 124, the vehicle state management unit 126, and the driving control unit 128 is performed via the bus 132. For example, a CAN (Controller Area Network) is used for the bus 132.

[0034] The on-board sensor 124 is mounted on the vehicle 102 and includes sensors for acquiring information outside the vehicle 102 (video image capturing devices (e.g., digital cameras (CCD (Charge-Coupled Device) cameras or CMOS (Complementary Metal-Oxide Semiconductor) cameras)), laser sensors (e.g., LiDAR), etc.), and sensors for acquiring information about the vehicle itself (e.g., acceleration sensors and load sensors). The on-board sensor 124 acquires information within its detection range (imaging range in the case of a camera) and outputs it as sensor data. In the case of a digital camera, it outputs digital image data. The detection signal (i.e., analog or digital signal) of the on-board sensor 124 is output as digital data to the bus 132 via an I / F unit (not shown) and transmitted to the on-board gateway 122.

[0035] The vehicle state management unit 126 manages the state (e.g., location, traveling speed, acceleration, and traveling direction) of the vehicle 102. The location can be acquired, for example, by a GPS. The traveling speed, acceleration, and traveling direction can be calculated, for example, from time-series location information and corresponding time information.

[0036] The driving control unit 128 controls the driving of the vehicle 102. The driving control unit 128 is, for example, an autonomous driving ECU (Electronic Control Unit). For example, the driving control unit 128 acquires sensor data from the on-board sensors 124, analyzes the data to understand the situation around the vehicle 102, and controls mechanisms related to autonomous driving (i.e., mechanisms such as the engine, transmission, steering, and brakes). Note that the vehicle 102 is not limited to a vehicle with an autonomous driving function. If the vehicle 102 does not have an autonomous driving function, the vehicle 102 does not include the driving control unit 128.

[0037] (Hardware configuration of the in-vehicle gateway) Referring to FIG. 3, the in-vehicle gateway 122 includes a control unit 140 and a memory 142. The control unit 140 is configured to include a CPU (Central Processing Unit) and controls the memory 142. The memory 142 is, for example, a rewritable nonvolatile semiconductor memory, and stores a computer program (hereinafter simply referred to as a program) executed by the control unit 140. The memory 142 provides a work area for the program executed by the control unit 140. The control unit 140 obtains data to be processed directly from the communication unit 120 and obtains the data from sources other than the communication unit 120 via the bus 132. The control unit 140 stores the data received from the communication unit 120 and the data received via the bus 132 in the memory 142 as appropriate. The control unit 140 stores the processing results in the memory 142 and outputs the results to the bus 132.

[0038] (Hardware configuration of the first server) 4, the first server 104 includes a control unit 150 that controls each unit, a memory 152 that stores data, a communication unit 154 that performs communication, and a bus 156 for exchanging data among the units. The control unit 150 includes a CPU and realizes functions described below by controlling each unit. The memory 152 includes a rewritable semiconductor nonvolatile memory and a large-capacity storage device such as a hard disk drive. The communication unit 154 receives sensor data uploaded from the in-vehicle device 100, the infrastructure sensor 114, etc. via the base station 108. The data received by the communication unit 154 is transmitted to and stored in the memory 152. This allows the first server 104 to perform a predetermined service.

[0039] (Hardware configuration of the second server) Referring to FIG. 5, the second server 106 has the same configuration as the first server 104. That is, the second server 106 includes a control unit 160 that controls each unit, a memory 162 that stores data, a communication unit 164 that performs communication, and a bus 166 for exchanging data among the units. The control unit 160 includes a CPU and realizes the functions described below by controlling each unit. The memory 162 includes a rewritable semiconductor nonvolatile memory and a large-capacity storage device such as a hard disk drive. The communication unit 164 receives communication history data uploaded from an in-vehicle device or the like installed in the other vehicle 112 via the base station 108. The data received by the communication unit 164 is transmitted to and stored in the memory 162. As a result, the second server 106 can generate and manage a communication history map and, upon external request, read and distribute the communication history map from the memory 162.

[0040] (Functional configuration of the in-vehicle gateway) The functions of the in-vehicle gateway 122 related to the present disclosure will be described. Referring to FIG. 6, the in-vehicle gateway 122 includes a communication history map information database (DB) 200, a route calculation unit 202, a buffering control unit 206, a communication history recording unit 208, a communication history transmission unit 210, and a communication history acquisition unit 212. FIG. 6 shows part of the hardware configuration shown in FIGS. 2, 4, and 5. The CAN 204 corresponds to the bus 132 shown in FIG. 2, and the driving unit 214 corresponds to the vehicle state management unit 126 and the driving control unit 128 shown in FIG. 2. The first server 104 is shown as the communication unit 154 shown in FIG. 4. The second server 106 is shown as the communication unit 164 shown in FIG. 5, which also shows the communication history map information 230, the communication history transmission unit 232, and the communication history acquisition unit 234, which are related to the functions of the in-vehicle gateway 122. The communication history map information DB 200 is implemented by the memory 142 (see FIG. 3) of the in-vehicle gateway 122. Other functions of the in-vehicle gateway 122 are realized by the control unit 140 and the memory 142 (see FIG. 3). The communication history map information DB 200 stores a communication history map. The communication history map is a communication history map that the in-vehicle gateway 122 requests from the second server 106 via the communication unit 120 and receives from the second server 106.

[0041] The route calculation unit 202 calculates a planned driving route for the vehicle 102 equipped with the in-vehicle device 100. The planned driving route for the vehicle 102 is calculated by a car navigation system installed in the vehicle 102, for example, when a destination is set in the car navigation system. The car navigation system can calculate the planned driving route by referring to a road map using the set destination and the current position of the vehicle 102, which can be obtained from a GPS. The route calculation unit 202 acquires the planned driving route calculated by the car navigation system from the car navigation system. The route calculation unit 202 may independently acquire position information and the like of the vehicle 102 from the vehicle state management unit 126 (see FIG. 2 ) and calculate the planned driving route for the vehicle 102 in the same way as the car navigation system. The route calculation unit 202 outputs information on the calculated planned driving route to the buffering control unit 206.

[0042] Furthermore, the route calculation unit 202 requests the communication history acquisition unit 212 to transmit information about the planned driving route. Upon receiving the request from the route calculation unit 202, the communication history acquisition unit 212 transmits information about the planned driving route to the second server 106 (specifically, the communication history transmission unit 232) via the communication unit 120. For example, referring to FIG. 7, the communication history map is a road map divided into a plurality of areas, and each area is associated with the communication speed and signal strength of wireless communication within that area. For example, the communication speed and signal strength of each area are representative values ​​(e.g., average values) obtained by statistically processing communication history data received from on-board devices of vehicles traveling within the area during the same time period. The communication history map information 230 of the second server 106 includes, for example, a communication history map for each time period, and is stored in the memory 162 (see FIG. 5). 7, when a planned driving route from the current position of the vehicle 102 to the destination A has been determined, the communication history transmission unit 232 of the second server 106 reads out a communication history map relating to at least the area included in the dashed arrow from the communication history map information 230. The communication history transmission unit 232 transmits the communication history map read out from the communication history map information 230 to the vehicle 102 (specifically, the in-vehicle device 100) via the communication unit 164. The communication history map transmitted from the second server 106 to the vehicle 102 is received by the communication history acquisition unit 212 via the communication unit 120 and stored in the communication history map information DB 200. The communication history transmission unit 232 of the second server 106 also transmits the communication history map to in-vehicle devices 240 mounted on vehicles other than the vehicle 102, in the same way as transmitting the communication history map to the in-vehicle device 100.

[0043] The buffering control unit 206 reads the communication history map from the communication history map information DB 200 and determines whether the planned driving route input from the route calculation unit 202 includes an area with a low wireless communication speed. For example, the buffering control unit 206 compares the wireless communication speed obtained from the communication history map with a predetermined threshold, identifies an area where the wireless communication speed is equal to or less than the threshold, and determines whether the identified area overlaps with the planned driving route. If there is an overlap, the buffering control unit 206 identifies the overlapping portion on the planned driving route as a predetermined range for buffering, which will be described later. With reference to FIG. 7 , for example, assume that the wireless communication speed is equal to or less than the threshold in the two shaded areas (i.e., the low communication speed area 220 and the low communication speed area 222). In this case, the buffering control unit 206 identifies the dashed line portion included in the low communication speed area 220 and the low communication speed area 222 as a predetermined range for buffering. When the route calculation unit 202 identifies the predetermined range, it outputs information representing the predetermined range to the buffering control unit 206. Note that, when only the communication history map for the area included in the dashed arrow is transmitted from the second server 106, it is not necessary to determine whether or not the area where the wireless communication speed is equal to or less than the threshold overlaps with the planned driving route. Also, when the communication history map information DB 200 stores communication history maps for each time period, the buffering control unit 206 only needs to determine whether or not the area identified as described above overlaps with the planned driving route and whether or not the time period in which the area is a low speed area overlaps with the time period in which the vehicle 102 travels along the planned driving route.

[0044] The communication history recording unit 208 combines the communication results of the communication unit 120 (e.g., communication speed and signal strength) with information obtainable from the CAN 204 (e.g., vehicle status and vehicle location information), and records the combined results as communication history data. The communication history data recorded by the communication history recording unit 208 is transmitted from the communication history transmitting unit 210 to the second server 106 via the communication unit 120. The communication history data transmitted to the second server 106 is received by the communication history acquiring unit 234 via the communication unit 164, and stored as communication history map information 230. The communication history data recorded by the communication history recording unit 208 is also stored in the communication history map information DB 200. Therefore, the communication history map information DB 200 may include communication results for each location (i.e., area) and time period, and information recording the status of the vehicle 102 at that time. The communication history acquisition unit 234 of the second server 106 also receives communication history data from on-board devices 240 installed in vehicles other than the vehicle 102 , and stores the data as communication history map information 230 .

[0045] The buffering control unit 206 receives sensor data output from the on-board sensors 124 mounted on the vehicle 102 and transmitted via the CAN 204. If the buffering control unit 206 cannot identify the predetermined range, it transmits the input sensor data to the first server 104 via the communication unit 120. The transmitted sensor data is received by the communication unit 154 of the first server 104. Note that a sensor data transmission request has been transmitted in advance from the communication unit 154 of the first server 104 to the on-board device 100 (see step 400 in FIG. 9 , which will be described later). For example, the first server 104 transmits a transmission request to the on-board device 100, the transmission request including information indicating a data quality required for a service (hereinafter referred to as a required data quality) and an allowable delay time. The buffering control unit 206 transmits sensor data that satisfies the required data quality and the allowable delay to the first server 104. The required data quality may, for example, represent the data volume per unit time of the sensor data transmitted from the on-board device 100 to the first server 104. The required data quality may be specified by, for example, the resolution and frame rate of the sensor data. For example, if the on-board sensor 124 is a camera that outputs video image data and multiple imaging conditions (such as the resolution and frame rate of the output data) can be set, the buffering control unit 206 sets the imaging conditions of the on-board sensor 124 so as to satisfy the required data quality. Whether the allowable delay is satisfied can be determined, for example, by whether the time required from when the sensor data is generated in the vehicle 102 (i.e., output from the on-board sensor 124) until it is received by the first server 104 is equal to or less than the allowable delay time. Note that, as will be described later, when the sensor data is buffered, the determination is made by whether the time including the buffering time is equal to or less than the allowable delay time.

[0046] The buffering control unit 206 includes a buffer area (not shown). The buffer area is a storage area reserved for storing sensor data output from the on-board sensor 124 during buffering, which will be described later. The buffer area is realized by the memory 142 shown in FIG. 3. After identifying the predetermined range, the buffering control unit 206 stores the input sensor data in the buffer area (i.e., buffers the data) without transmitting the data to the first server 104. The buffering control unit 206 performs buffering while the vehicle 102 is traveling within the predetermined range. Thereafter, when the vehicle 102 has completed traveling within the predetermined range, the buffering control unit 206 transmits the sensor data buffered in the buffer area to the first server 104 in a lump (hereinafter referred to as "batch transmission"). Subsequently, the buffering control unit 206 transmits the sensor data newly input via the CAN 204 to the first server 104 as described above.

[0047] In order to buffer sensor data while the vehicle 102 is traveling within a predetermined range, an appropriate storage capacity must be reserved in the memory 142 as a buffer area. To this end, the buffering control unit 206 predicts the time required for the vehicle 102 to travel within the predetermined range, calculates the capacity of the buffer area (hereinafter also referred to as buffer capacity) from the predicted time (hereinafter referred to as predicted time) and the required data quality, and reserves the calculated capacity in the memory 142. For example, the buffering control unit 206 calculates the distance of the predetermined range from information representing the predetermined range, obtains the traveling speed of the vehicle 102 from the driving unit 214 (specifically, the vehicle state management unit 126 (see FIG. 2 )), and calculates the predicted time by dividing the distance of the predetermined range by the traveling speed. For example, the buffering control unit 206 multiplies the frame rate (i.e., the number of frames per second), the resolution of one frame (i.e., the number of pixels in one frame), the data size of one pixel (e.g., in bytes), and the predicted time in seconds, to calculate the lower limit of the buffer capacity. If a buffer area of ​​the calculated capacity cannot be secured, buffering is not performed. In this case, for example, the buffering control unit 206 notifies the first server 104 that buffering is not possible. This allows the first server 104, which has requested uploading of sensor data, to allocate resources for that purpose to another process without waiting for sensor data that cannot be received.

[0048] As described above, the sensor data to be transmitted in a batch may satisfy the allowable delay time. If the sensor data stored in the buffer area does not satisfy the allowable delay time, the buffering control unit 206 does not transmit the data in a batch. In this case, the buffering control unit 206 also notifies the first server 104 that buffering is not possible. This allows the first server 104, which has requested uploading of sensor data, to allocate resources for that purpose to another process without waiting for sensor data that cannot be received.

[0049] As described above, the in-vehicle gateway 122 determines whether to buffer the sensor data stored in the memory 142 instead of transmitting it, depending on the wireless communication speed between the communication unit 120, which transmits the sensor data of the in-vehicle sensor 124, and the first server 104, and performs buffering depending on the determination result. That is, when the planned driving route of the in-vehicle device 100 includes a predetermined range where communication speed is low, the in-vehicle gateway 122 reserves storage capacity for buffering in the memory 142 (see FIG. 3 ) and buffers the sensor data while the vehicle 102 is driving through the predetermined range. Thereafter, when the vehicle 102 passes through the predetermined range where communication speed is low, the in-vehicle gateway 122 transmits the buffered sensor data all at once. Therefore, even if the in-vehicle device 100 drives the vehicle 102 in an environment where wireless communication speed is low, the in-vehicle device 100 can transmit the sensor data to the first server 104 without degrading the quality of the data to be transmitted. Therefore, the first server 104 can maintain its service. Furthermore, by transmitting the buffered sensor data in a lump, the in-vehicle device 100 can transmit the buffered sensor data to the first server 104 without wasting the data. Note that the planned driving route may be calculated by an external device of the vehicle 102 (for example, a server that has received a request from the in-vehicle device 100) and transmitted from the external device to the in-vehicle device 100.

[0050] As described above, when a low-speed communication state occurs in which the wireless communication speed is equal to or lower than a predetermined value within a predetermined range on the planned driving route, the buffering control unit 206 determines to perform buffering, and performs buffering while the vehicle 102 is driving within the predetermined range. This allows the in-vehicle device 100 to perform necessary and sufficient buffering of sensor data.

[0051] As described above, the in-vehicle device 100 receives information indicating the required data quality transmitted from the first server 104 via the communication unit 120. Then, the buffering control unit 206 calculates a predicted time for the vehicle 102 to travel a predetermined distance, and determines whether the buffer capacity required for buffering can be secured in the memory 142 using the predicted time and the required data quality. If the storage capacity required for buffering can be secured in the memory 142, the buffering control unit 206 causes the memory 142 to secure the storage capacity. This makes it possible to efficiently determine whether buffering is possible.

[0052] As described above, the in-vehicle device 100 receives the communication history map from the second server 106 via the communication unit 120. Then, the buffering control unit 206 identifies a road corresponding to the planned driving route from among the roads included in the communication history map, and determines whether to perform buffering using the actual speed corresponding to the identified road as the wireless communication speed. This allows the in-vehicle device 100 to easily determine whether buffering is necessary.

[0053] (Operation of the in-vehicle gateway) With reference to Fig. 8, the operation of the in-vehicle gateway 122 will be described with reference to the functions shown in Fig. 6. The processing shown in Fig. 8 is realized by the control unit 140 (see Fig. 3) reading and executing a predetermined program from the memory 142. It is assumed that a request to transmit sensor data has been transmitted to the in-vehicle device 100 from the first server 104 in advance.

[0054] 8, in step 300, the control unit 140 transmits information representing the planned driving route to the second server 106 and requests transmission of a communication history map. The request is made, for example, by attaching a predetermined request code to the information representing the planned driving route and transmitting it. As described above, the in-vehicle gateway 122 acquires the driving route from, for example, a car navigation system installed in the vehicle 102. Thereafter, control proceeds to step 302.

[0055] In step 302, the control unit 140 receives a communication history map from the second server 106. As described above, the received communication history map includes the transmitted planned driving route. The control unit 140 stores the received communication history map in the communication history map information DB 200 (see FIG. 6). Thereafter, control proceeds to step 304.

[0056] In step 304, the control unit 140 determines whether or not there is a low communication speed area on the planned driving route. Specifically, the control unit 140 determines whether or not the communication history map received in step 302 includes an area where the communication speed is equal to or lower than a threshold, and if so, determines whether or not the planned driving route overlaps with that area. If it is determined that there is an overlap, the control unit 140 identifies the overlapping portion (i.e., a predetermined range). In other words, if the predetermined range is identified, it is determined that there is a low communication speed area, and control proceeds to step 306. If not (i.e., if the predetermined range is not identified), control proceeds to step 328. The processing of step 304 corresponds to the function of the buffering control unit 206 shown in FIG. 6.

[0057] In step 306, the control unit 140 determines whether the vehicle 102 has approached a low-speed communication area (i.e., a predetermined range on the planned travel route identified in step 304). If it is determined that the vehicle 102 has approached, control proceeds to step 310. Otherwise, control proceeds to step 308. Approaching a low-speed communication area means that the distance from the vehicle 102 to the predetermined range is equal to or less than a predetermined distance. The predetermined distance can be set to a value in the range of 100 m to 10 m, for example.

[0058] In step 308, the control unit 140 transmits the sensor data to be input into the communication history map information DB 200 to the first server 104 via the communication unit 120. This corresponds to the function of the buffering control unit 206 shown in Fig. 6. Thereafter, control returns to step 306, and the above processing is repeated.

[0059] When the vehicle 102 approaches a low-speed communication area (i.e., a predetermined range), in step 310, the control unit 140 calculates the storage capacity required to buffer the sensor data. As described above with respect to the buffering control unit 206, the control unit 140 calculates the required buffer area capacity based on the required data quality and the time required to travel the predetermined range (i.e., the predicted time). Then, control proceeds to step 312. In this way, by calculating the buffer capacity when the vehicle 102 approaches the low-speed communication area (i.e., a predetermined range), it is possible to more accurately determine whether buffering is possible than by calculating the buffer capacity when the vehicle 102 is traveling far from the low-speed communication area. The free space in the memory 142 for reserving the buffer area changes while the vehicle 102 is traveling. Therefore, if the free space in the memory 142 when the vehicle 102 approaches the low-speed communication area is smaller than when the vehicle 102 is traveling far from the low-speed communication area, it may be impossible to reserve the buffer capacity calculated when the vehicle 102 is traveling in the distant location, and buffering may not be performed.

[0060] In step 312, the control unit 140 determines whether the buffer capacity calculated in step 310 can be reserved in the memory 142. This process corresponds to the function of the buffering control unit 206 in FIG. 6 described above. If it is determined that the buffer capacity can be reserved, control proceeds to step 314. If not, control proceeds to step 324.

[0061] In step 314, the control unit 140 determines whether the buffered sensor data satisfies the allowable delay. This process corresponds to the function of the buffering control unit 206 in Fig. 6. If it is determined that the allowable delay is satisfied, the control proceeds to step 316. If not, the control proceeds to step 324.

[0062] In step 316, the control unit 140 determines whether the vehicle 102 has started traveling through the low communication speed area (i.e., a predetermined range) and is currently traveling through the low communication speed area. If it is determined that the vehicle 102 is traveling through the low communication speed area, control proceeds to step 318. If not (i.e., if the vehicle 102 has passed through the low communication speed area), control proceeds to step 320.

[0063] In step 318, the control unit 140 buffers the sensor data output from the on-board sensor 124. That is, the control unit 140 stores the sensor data output from the on-board sensor 124 in a buffer area of ​​the buffering control unit 206 (specifically, the memory 142 in FIG. 6 ) without transmitting the sensor data to the first server 104. Thereafter, the control returns to step 316. At this time, the sensor data is stored in chronological order, that is, so that the time order in which the sensor data was generated can be determined (for example, with time information attached).

[0064] If the determination result in step 316 is NO, that is, if the vehicle 102 has passed through a low-speed communication area, in step 320, the control unit 140 reads out the sensor data stored in the buffer area of ​​the buffering control unit 206 and transmits the data in a batch to the first server 104 via the communication unit 120. Note that batch transmission means transmitting all of the sensor data stored in the buffer area of ​​the buffering control unit 206 before transmitting new sensor data output from the on-board sensor 124 to the first server 104. Thereafter, control proceeds to step 322.

[0065] In step 322, the control unit 140 determines whether or not there is a low communication speed area in which the vehicle 102 has not yet traveled among the low communication speed areas (i.e., the predetermined range) detected in step 304. This is a process to deal with the possibility that multiple low communication speed areas may be detected in step 304. If it is determined that there is a low communication speed area in which the vehicle 102 has not yet traveled, control returns to step 306. Otherwise, control proceeds to step 330.

[0066] If the determination result in either step 312 or step 314 is NO, in step 324, the control unit 140 transmits information indicating that the sensor data cannot be transmitted to the first server 104. Thereafter, the control proceeds to step 326.

[0067] In step 326, the control unit 140 determines whether the vehicle 102 has started traveling through the low communication speed area and is currently traveling through the low communication speed area, similar to step 316. Step 326 is repeated until the determination is NO (i.e., until the vehicle 102 passes through the low communication speed area). Therefore, during this time, the sensor data is not transmitted to the first server 104, and no buffering is performed. If the determination is NO, control proceeds to step 322.

[0068] If the determination result in step 304 is NO (i.e., if there is no low-speed communication area on the planned travel route), in step 328, the control unit 140 transmits the sensor data output from the on-board sensor 124 to the first server 104 via the communication unit 120. Thereafter, control proceeds to step 330.

[0069] In step 330, the control unit 140 determines whether to terminate. Specifically, the control unit 140 determines whether the vehicle 102 has completed traveling along the planned traveling route (for example, whether the vehicle 102 has arrived at destination A in FIG. 7). If it is determined that the traveling has been completed, the program terminates. If not, control returns to step 328. Note that the control unit 140 may also determine to terminate when it receives a notification from the first server 104 that sensor data transmission is not necessary.

[0070] For example, if there is no low-communication speed area on the planned driving route (if the determination result in step 304 is NO), steps 328 and 330 are repeated while the vehicle 102 is traveling along the planned driving route. On the other hand, if there is a low-communication speed area on the planned driving route (if the determination result in step 304 is YES), while the vehicle 102 is traveling through each low-communication speed area, buffering is performed if possible, and the data is transmitted en bloc. After that, steps 328 and 330 are repeated while the vehicle 102 is traveling along the remainder of the planned driving route. Also, if there is a low-communication speed area on the planned driving route but buffering is not possible, neither transmission nor buffering of sensor data is performed while the vehicle 102 is traveling through each low-communication speed area (see step 326), and after the vehicle 102 has passed the last low-communication speed area, steps 328 and 330 are repeated while the vehicle 102 is traveling along the remainder of the planned driving route.

[0071] As described above, when the planned driving route of the on-board device 100 includes a low-speed communication area, the on-board gateway 122 reserves storage capacity for buffering in the memory 142 and buffers the sensor data while the vehicle 102 is driving through the low-speed communication area (see step 318). Thereafter, when the vehicle 102 passes through the low-speed communication area (the determination result in step 316 is NO), the on-board gateway 122 transmits the buffered sensor data in a batch (see step 320). Therefore, even if the vehicle 102 is driving through an environment with low wireless communication speed, the on-board device 100 can transmit the sensor data to the first server 104 without degrading the quality of the data to be transmitted. Therefore, the first server 104 can maintain its service. Furthermore, by transmitting the buffered sensor data in a batch, the on-board device 100 can transmit the buffered sensor data to the first server 104 without wasting it.

[0072] When a new destination is set and a new planned travel route for the vehicle 102 is determined, the vehicle gateway 122 executes the program shown in FIG. 8 again.

[0073] (Operation of the first server) The operation of the first server 104, i.e., the function of receiving sensor data from the in-vehicle device 100 and providing a service, will be described with reference to Fig. 9. The process shown in Fig. 9 is realized by the control unit 150 of the first server 104 shown in Fig. 4 reading a predetermined program from the memory 152 and executing it.

[0074] In step 400, the control unit 150 requests a plurality of vehicles (specifically, on-board devices) to transmit sensor data. Thereafter, control proceeds to step 402. This request may be transmitted by broadcast, for example. At this time, the control unit 150 transmits a transmission request including information on the required data quality and the allowable delay time, as described above. In response to this, the on-board gateway 122 of the on-board device 100 transmits the sensor data output from the on-board sensors 124 mounted on the vehicle 102 to the first server 104, as described above. Once the planned driving route is identified, the on-board gateway 122 executes the program shown in FIG. 8.

[0075] In step 402, the control unit 150 determines whether or not sensor data has been received. If it is determined that sensor data has been received, the control proceeds to step 404. If not, the control proceeds to step 406.

[0076] In step 404, the control unit 150 transfers the received sensor data to an application (i.e., a program) of the corresponding service (e.g., a remote monitoring service) executed by the first server 104. Thereafter, control proceeds to step 406.

[0077] In step 406, control unit 150 determines whether an instruction to end has been received. The instruction to end is given, for example, by operating a keyboard or mouse operation unit (not shown) provided on first server 104. If it is determined that the process should be ended, control proceeds to step 408. If not, control returns to step 402, and the above processing is repeated.

[0078] In step 408, the control unit 150 transmits a notification to the vehicle that requested the transmission of sensor data in step 400 that the transmission of sensor data is not necessary. The request may be transmitted by broadcast, for example. Then, the program ends.

[0079] As described above, the first server 104 can provide services using sensor data uploaded from the vehicle's on-board device. Furthermore, when uploading sensor data to the first server 104, the on-board device 100 calculates the planned driving route of the vehicle 102, buffers the sensor data while the vehicle 102 is driving through a low-speed communication area, and transmits the buffered sensor data in bulk when the vehicle 102 passes through the low-speed communication area. Therefore, even if the vehicle 102 is driving through an environment with low wireless communication speed, the on-board device 100 can transmit the sensor data to the first server 104 without degrading the quality of the data to be transmitted. Therefore, the first server 104 can maintain its services.

[0080] (Operation of the second server) 10, the operation of second server 106, that is, the function of generating a communication history map and transmitting the communication history map in response to a request, will be described. The processing shown in FIG. 10 is realized by control unit 160 of second server 106 shown in FIG. 5 reading and executing a predetermined program from memory 162. The communication history map is stored in memory 162.

[0081] In step 500, the control unit 160 determines whether or not a request for a communication history map has been received. If it is determined that the request has been received, control proceeds to step 502. If not, control proceeds to step 504. For example, as described above, the in-vehicle device 100 requests transmission of a communication history map accompanied by information indicating the planned driving route (see step 300 in FIG. 8). If this request has been received, the control unit 160 determines YES.

[0082] In step 502, the control unit 160 reads out from the memory 162 the communication history map of the area corresponding to the request and transmits it. The transmission destination can be specified by the source address (e.g., IP address) of the request received in step 500. Thereafter, control proceeds to step 508.

[0083] If the determination result in step 500 is NO, in step 504, the control unit 150 determines whether or not communication history data has been received. If it is determined that communication history data has been received, control proceeds to step 506. If not, control proceeds to step 508. The communication history data is, for example, data (e.g., communication speed and signal strength) that represents the actual state of wireless communication on each road. For example, the on-board device of each vehicle stores the communication speed and signal strength when the on-board device performs wireless communication with the outside in chronological order, along with location information, as communication history data, and periodically transmits the stored communication history data to the second server 106.

[0084] In step 506, the control unit 160 stores the communication history data received in step 504 in the memory 162. At this time, the control unit 160 appropriately updates the existing communication history map using the received new communication history data. Thereafter, control proceeds to step 508.

[0085] In step 508, control unit 160 determines whether an instruction to end has been received. The instruction to end is given, for example, by operating a keyboard or mouse operation unit (not shown) provided on second server 106. If it is determined that the program should end, the program ends. If not, control returns to step 500, and the above processing is repeated.

[0086] As described above, the second server 106 can generate and update a communication history map using communication history data uploaded from the in-vehicle device of each vehicle and transmit the communication history map upon request. Furthermore, when uploading sensor data to the first server 104, the in-vehicle device 100 can easily determine whether a low-communication-speed area is included in the planned driving route of the vehicle 102 by using the communication history map received from the second server 106. Once the planned driving route is calculated, the in-vehicle device 100 buffers the sensor data while the vehicle 102 is driving through the low-communication-speed area, and transmits the buffered sensor data in a lump when the vehicle 102 passes through the low-communication-speed area. Therefore, even if the vehicle 102 is driving in an environment with low wireless communication speed, the in-vehicle device 100 can transmit the sensor data to the first server 104 without degrading the quality of the data.

[0087] In the above, the buffer capacity is calculated when the vehicle 102 approaches a low-speed communication area (i.e., a predetermined range), but this is not limiting. The buffer capacity may be calculated when a planned driving route is calculated and the corresponding communication history map is acquired. For example, if the planned driving route is relatively short, the vehicle 102 can travel in a relatively short time, and the change in the free space in the memory 142 is relatively small. Therefore, the buffer capacity may be calculated in advance well before the vehicle 102 approaches the low-speed communication area.

[0088] In the above description, the on-board device 100 acquires the wireless communication speed on the planned driving route from the communication history map received from the second server 106, but the present invention is not limited to this. The on-board device may acquire the wireless communication speed on the planned driving route of the vehicle 102 from an external source. For example, the vehicle 102 may identify the wireless communication speed on the planned driving route of the vehicle 102 using a map related to wireless communication speeds (e.g., an area map of 5G and LTE (Long Term Evolution)) provided by a wireless communication service company or the like.

[0089] In the above description, the on-board device 100 and the on-board devices of the other vehicles 112 transmit communication history data to the second server 106, but the present invention is not limited to this. The on-board device 100 may not store the communication history data and may not transmit the communication history data to the second server 106. In this case, the on-board device 100 may not include the communication history recording unit 208 and the communication history transmitting unit 210.

[0090] Each process (each function) in the above-described embodiments may be realized by a processing circuit including one or more processors. The processing circuit may be configured by an integrated circuit or the like that combines one or more memories, various analog circuits, and various digital circuits in addition to the one or more processors. The one or more memories store programs (instructions) that cause the one or more processors to execute the respective processes. The one or more processors may execute the respective processes according to the programs read from the one or more memories, or according to logic circuits pre-designed to execute the respective processes. The processor may be any of various processors suitable for computer control, such as a CPU, a GPU (Graphics Processing Unit), a DSP (Digital Signal Processor), an FPGA (Field Programmable Gate Array), and an ASIC (Application Specific Integrated Circuit). The physically separate processors may execute the respective processes in cooperation with each other. For example, the above-mentioned processors mounted on each of a plurality of physically separated computers may cooperate with each other via a network such as a LAN (Local Area Network), a WAN (Wide Area Network), or the Internet to execute the above-mentioned processes.

[0091] Furthermore, a recording medium can be provided that stores a program that causes a computer to execute the processing of the in-vehicle device 100 (specifically, the processing executed by the in-vehicle gateway 122 (e.g., the processing shown in FIG. 8 )). The recording medium is, for example, an optical disc (such as a DVD (Digital Versatile Disc)) or a removable semiconductor memory (such as a USB (Universal Serial Bus) memory). Although a computer program can be transmitted over a communication line, the recording medium refers to a non-transitory recording medium. By having a computer load the program stored in the recording medium, the computer can maintain cloud-linked services and enable service provision from the server even when the external environmental conditions of the in-vehicle device deteriorate, as described above.

[0092] (Addendum) That is, the computer-readable non-transitory recording medium is The computer installed in the vehicle a communication function for communicating with an external device and transmitting sensor data detected by a sensor mounted on the vehicle to the external device; The computer program stores a computer program that determines whether to perform buffering, which stores the sensor data in a memory unit without transmitting it via the communication function, depending on the wireless communication speed between the communication function and the external device, and that realizes a buffering control function that performs the buffering depending on the determination result.

[0093] Although the present disclosure has been described above by explaining the embodiments, the above-described embodiments are merely examples, and the present disclosure is not limited to only the above-described embodiments. The scope of the present disclosure is defined by the claims in the scope of the claims, taking into consideration the description of the detailed description of the invention, and includes all modifications within the meaning and scope equivalent to the wordings described therein. [Explanation of symbols]

[0094] 100, 240 In-vehicle equipment 102 vehicles 104 First Server 106 Second Server 108 Base Station 110 Network 112 Other vehicles 114 Infrastructure Sensors 120, 154, 164 Communications Department 122 In-vehicle gateway 124 In-vehicle sensors 126 Vehicle Status Management Department 128 Operation control unit Buses 132, 156, and 166 140, 150, 160 Control unit 142, 152, 162 memory 200 Communication performance map information DB 202 Route calculation unit 204 CAN 206 Buffering control section 208 Communication Performance Recording Section 210, 232 Communication performance transmission unit 212, 234 Communication Performance Acquisition Department 214 Driving Department 230 Communication performance map information 220, 222 low speed communication area 300, 302, 304, 306, 308, 310, 312, 314, 316, 318, 320, 322, 324, 326, 328, 330, 400, 402, 404, 406, 408, 500, 502, 504, 506, 508 steps 900 pedestrians A destination

Claims

1. An in-vehicle device mounted on a vehicle, a communication unit that communicates with an external device and transmits sensor data detected by a sensor mounted on the vehicle to the external device; a buffering control unit that determines whether to perform buffering of the sensor data, in which the sensor data is stored in a storage unit without being transmitted by the communication unit, according to a speed of wireless communication between the communication unit and the external device, and performs the buffering according to a result of the determination, The buffering control unit determining that the buffering is to be performed when a low communication speed state occurs in which the wireless communication speed is equal to or lower than a predetermined value within a predetermined range on a planned travel route of the vehicle; An in-vehicle device that performs the buffering while the vehicle is traveling within the predetermined range.

2. The communication unit further receives information indicating a required data quality transmitted from the external device; the required data quality represents a data volume per unit time of the sensor data transmitted from the in-vehicle device to the external device; The buffering control unit calculating a predicted time for the vehicle to travel the predetermined range; calculating a storage capacity required for said buffering using said predicted time and said required data quality; The in-vehicle device according to claim 1 , further comprising: determining whether the calculated storage capacity can be secured in the storage unit.

3. When the in-vehicle device approaches within a predetermined distance of the predetermined range, the buffering control unit Calculating the predicted time; Calculating the storage capacity; The in-vehicle device according to claim 2 , wherein the in-vehicle device determines whether the storage capacity can be secured in the storage unit.

4. 4. The in-vehicle device according to claim 2, wherein the buffering control unit causes the communication unit to transmit to the external device information indicating that the sensor data cannot be transmitted if the storage capacity cannot be secured.

5. the communication unit further receives information indicating an allowable delay time transmitted from the external device; 4. The in-vehicle device according to claim 2, wherein the buffering control unit causes the communication unit to transmit, to the external device, information indicating that the sensor data cannot be transmitted, if the predicted time is equal to or greater than the allowable delay time.

6. the communication unit further receives a communication history map from outside the vehicle-mounted device; the communication history map includes information representing roads and information representing actual speeds of wireless communication on the roads, in association with each other; 4. The in-vehicle device according to claim 1, wherein the buffering control unit identifies information representing a road corresponding to the planned driving route from the information representing the roads included in the communication history map, and determines whether to perform the buffering by using information representing the actual speed corresponding to the identified information as information representing the wireless communication speed.

7. 4. The in-vehicle device according to claim 1, wherein, after performing the buffering, if there is no need to perform the buffering, the buffering control unit causes the communication unit to transmit the sensor data stored in the memory unit by the buffering to the external device.

8. A method for controlling an in-vehicle device mounted on a vehicle, comprising: a communication step of communicating with an external device and transmitting sensor data detected by a sensor mounted on the vehicle to the external device; a buffering control step of determining whether or not to perform buffering, in which the sensor data is stored in a storage unit without being transmitted in the communication step, according to a speed of wireless communication with the external device in the communication step, and performing the buffering according to a result of the determination, The buffering control step includes: determining that the buffering should be performed when a low communication speed state occurs in which the wireless communication speed is equal to or lower than a predetermined value within a predetermined range on a planned travel route of the vehicle; performing the buffering while the vehicle is traveling within the predetermined range.

9. The computer installed in the vehicle a communication function for communicating with an external device and transmitting sensor data detected by a sensor mounted on the vehicle to the external device; a buffering control function that determines whether to perform buffering, in which the sensor data is stored in a storage unit without being transmitted by the communication function, according to a wireless communication speed between the communication function and the external device, and performs the buffering according to the determination result; The buffering control function is a function of determining to perform the buffering when a low communication speed state occurs in which the wireless communication speed is equal to or lower than a predetermined value within a predetermined range on a planned travel route of the vehicle; and a function of performing the buffering while the vehicle is traveling within the predetermined range.

Images