WO2024062786A1 - 車載装置、制御方法およびコンピュータプログラム - Google Patents

車載装置、制御方法およびコンピュータプログラム Download PDF

Info

Publication number
WO2024062786A1
WO2024062786A1 PCT/JP2023/028859 JP2023028859W WO2024062786A1 WO 2024062786 A1 WO2024062786 A1 WO 2024062786A1 JP 2023028859 W JP2023028859 W JP 2023028859W WO 2024062786 A1 WO2024062786 A1 WO 2024062786A1
Authority
WO
WIPO (PCT)
Prior art keywords
vehicle
communication
buffering
sensor data
control unit
Prior art date
Application number
PCT/JP2023/028859
Other languages
English (en)
French (fr)
Inventor
麻友 岩崎
明紘 小川
Original Assignee
住友電気工業株式会社
住友電装株式会社
株式会社オートネットワーク技術研究所
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by 住友電気工業株式会社, 住友電装株式会社, 株式会社オートネットワーク技術研究所 filed Critical 住友電気工業株式会社
Publication of WO2024062786A1 publication Critical patent/WO2024062786A1/ja

Links

Images

Classifications

    • G—PHYSICS
    • G08—SIGNALLING
    • G08G—TRAFFIC CONTROL SYSTEMS
    • G08G1/00—Traffic control systems for road vehicles
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04W—WIRELESS COMMUNICATION NETWORKS
    • H04W4/00—Services specially adapted for wireless communication networks; Facilities therefor
    • H04W4/30—Services specially adapted for particular environments, situations or purposes
    • H04W4/38—Services specially adapted for particular environments, situations or purposes for collecting sensor information
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04W—WIRELESS COMMUNICATION NETWORKS
    • H04W4/00—Services specially adapted for wireless communication networks; Facilities therefor
    • H04W4/30—Services specially adapted for particular environments, situations or purposes
    • H04W4/40—Services specially adapted for particular environments, situations or purposes for vehicles, e.g. vehicle-to-pedestrians [V2P]
    • H04W4/44—Services specially adapted for particular environments, situations or purposes for vehicles, e.g. vehicle-to-pedestrians [V2P] for communication between vehicles and infrastructures, e.g. vehicle-to-cloud [V2C] or vehicle-to-home [V2H]
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04W—WIRELESS COMMUNICATION NETWORKS
    • H04W72/00—Local resource management
    • H04W72/12—Wireless traffic scheduling
    • H04W72/1263—Mapping of traffic onto schedule, e.g. scheduled allocation or multiplexing of flows
    • H04W72/1268—Mapping of traffic onto schedule, e.g. scheduled allocation or multiplexing of flows of uplink data flows

Definitions

  • the present disclosure relates to an in-vehicle device, a control method, and a computer program.
  • This application claims priority based on Japanese Application No. 2022-148752 filed on September 20, 2022, and incorporates all the contents described in the said Japanese application.
  • a server Systems that aggregate and analyze sensor data from a large number of sensors on a server computer (hereinafter referred to as a server) and use the analysis results for driving support are becoming popular.
  • Sensor data is transmitted from sensors mounted on a vehicle and sensors provided in infrastructure equipment provided on the roadside (hereinafter referred to as infrastructure sensors).
  • infrastructure sensors In such systems, vehicles communicate with servers via wireless base stations. Vehicles with wireless communication capabilities can also perform direct communication between vehicles (so-called vehicle-to-vehicle communication) without going through a server.
  • vehicle-to-vehicle communication sensor data from one vehicle is transmitted to another vehicle, and information held by one vehicle is transmitted to another vehicle.
  • Patent Document 1 discloses an in-vehicle device (in-vehicle communication control device) that has a 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 allows content to be played back without interruption even in sections where the radio wave environment along the vehicle's planned route is poor and stream-type content cannot be sufficiently downloaded.
  • the in-vehicle communication control device disclosed in Patent Document 1 performs buffering for reproducing downloaded data.
  • the in-vehicle communication control device calculates the amount of data that can be buffered in consideration of the traveling speed of the vehicle, and determines whether downloading is possible.
  • An in-vehicle device is an in-vehicle device installed in a vehicle, and includes a communication unit that communicates with an external device and transmits sensor data detected by a sensor installed in the vehicle to the external device; Depending on the wireless communication speed between the communication unit and the external device, it is determined whether or not to buffer the sensor data so that it is stored in the storage unit without being transmitted by the communication unit, and depending on the determination result, the buffering and a buffering control unit that performs ringing.
  • FIG. 1 is a schematic diagram showing a usage pattern of an in-vehicle device according to an embodiment of the present disclosure.
  • FIG. 2 is a block diagram showing the hardware configuration of the in-vehicle device shown in FIG. 1.
  • FIG. 3 is a block diagram showing the hardware configuration of the in-vehicle gateway shown in FIG. 2.
  • FIG. 4 is a block diagram showing the hardware configuration of the first server shown in FIG. 1.
  • FIG. 5 is a block diagram showing the hardware configuration of the second server shown in FIG. 1.
  • FIG. 6 is a block diagram showing the functional configuration of the in-vehicle gateway shown in FIG. 2.
  • FIG. 7 is a diagram illustrating a state in which a scheduled route of a vehicle is displayed on a communication record map.
  • FIG. 8 is a flowchart showing the processing executed by the in-vehicle gateway.
  • FIG. 9 is a flowchart showing the processing executed by the first server.
  • FIG. 10 is a flowchart showing the processing executed
  • Patent Document 1 Since the in-vehicle communication control device disclosed in Patent Document 1 is related to downloading streaming data, it cannot solve the above-mentioned problems related to data transmission (i.e., uploading).
  • the present disclosure provides 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 travels in an environment where the wireless communication speed is low. With the goal.
  • the in-vehicle device is an in-vehicle device installed in a vehicle, which communicates with an external device and transmits sensor data detected by a sensor installed in the vehicle to the external device. Based on the wireless communication speed between the communication unit and the external device, the communication unit determines whether to perform buffering to store the sensor data in the storage unit without transmitting it through the communication unit, and determines the determination result. and a buffering control unit that performs buffering according to the conditions. As a result, even if the vehicle travels in an environment where the wireless communication speed is low, the in-vehicle device can transmit data to an external device without degrading the quality of the transmitted data. Therefore, the external device can maintain service.
  • the buffering control unit determines that buffering is to be performed when a low communication speed state in which the wireless communication speed is less than or equal to a predetermined value occurs in a predetermined range on the vehicle's scheduled travel route; Buffering can be performed while the vehicle is traveling within a predetermined range. This allows sufficient buffering to be performed.
  • the communication unit may further receive information representing the required data quality transmitted from the external device, where the required data quality is the sensor data transmitted from the in-vehicle device to the external device. It may also represent the data capacity per unit time, and the buffering control unit calculates the predicted time for the vehicle to travel within a predetermined range, and uses the predicted time and required data quality to calculate the storage capacity required for buffering. It may be determined whether the calculated storage capacity can be secured in the storage unit. This makes it possible to efficiently determine whether buffering is possible.
  • the buffering control unit calculates the predicted time, calculates the storage capacity, and stores the storage capacity in the storage unit. It may be determined whether or not it can be secured. Thereby, it is possible to accurately determine whether buffering is possible or not.
  • the buffering control unit may cause the communication unit to transmit information to the external device indicating that the sensor data cannot be transmitted. This eliminates the need for the external device to wait for sensor data from the vehicle-mounted sensor, thereby avoiding the waste of resources.
  • the communication unit may further receive information indicating an allowable delay time transmitted from an external device, and the buffering control unit may receive information indicating a predicted delay time. If the delay time is greater than or equal to the allowable delay time, the communication unit may transmit information indicating that sensor data cannot be transmitted to the external device. Thereby, the external device does not need to wait for sensor data from the vehicle-mounted sensor, and resources can be avoided from being wasted.
  • the communication unit further receives a communication performance map from outside the in-vehicle device, and the communication performance map includes information representing the road and wireless communication on the road.
  • the buffering control unit identifies the information representing the road corresponding to the planned travel route from among the information representing the roads included in the communication performance map, and Information representing the actual speed corresponding to the information may be used as information representing the wireless communication speed to determine whether or not to perform buffering. Thereby, the in-vehicle device can easily determine whether buffering is necessary.
  • the buffering control unit after performing the buffering, if there is no need to perform the buffering, the buffering control unit sends the data to the storage unit by buffering.
  • the stored sensor data may be transmitted to an external device.
  • the in-vehicle device can transmit the buffered sensor data to the external device without wasting it.
  • a control method is a control method for an in-vehicle device installed in a vehicle, which communicates with an external device and transmits sensor data detected by a sensor installed in the vehicle to an external device. Judgment that determines whether to perform buffering to store sensor data in the storage unit without transmitting it through the communication step, depending on the wireless communication speed between the communication step for transmitting to the device and the external device through the communication step. and a buffering control step of performing buffering according to the determination result. As a result, even if the vehicle travels in an environment where the wireless communication speed is low, the in-vehicle device can transmit data to an external device without degrading the quality of the transmitted data. Therefore, the external device can maintain service.
  • a computer program provides a computer mounted on a vehicle with 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 or not to perform buffering, in which the sensor data is stored in a storage unit instead of being transmitted by the communication function, depending on the wireless communication speed between the vehicle and the external device via the communication function, and for performing buffering depending on the result of the determination.
  • 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. This allows the external device to maintain its service.
  • the present invention can be realized not only as an in-vehicle device equipped with such a characteristic processing unit, but also as a control method having such characteristic processing as steps, or as a program for causing a computer to execute such steps. You can do it. Further, it can be realized as a semiconductor integrated circuit that realizes part or all of an on-vehicle device, or as a service providing system including an on-vehicle device.
  • an in-vehicle device 100 is mounted on a vehicle 102.
  • 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 (for example, monitoring the traffic situation or monitoring the condition inside the vehicle (monitoring the driver's condition, etc.)).
  • the service provided by the first server 104 may be a service that provides a vehicle with information to support driving of the vehicle.
  • the data to be uploaded is sensor data acquired by an on-vehicle sensor mounted on the vehicle 102, as described later.
  • Vehicle 102 and other vehicles 112 transmit wireless communication performance data to second server 106, which generates, manages, and distributes a communication performance map.
  • the communication performance map is a road map divided into multiple areas (for example, rectangular areas) (hereinafter, the divided areas are referred to as "areas"), and each area has information on the wireless communication within that area. It corresponds to communication speed and signal strength.
  • the second server 106 receives a request from the in-vehicle device 100 and transmits the communication performance map to the in-vehicle device 100.
  • the base station 108 provides mobile communication services using, for example, 4G (4th Generation) lines and 5G (5th Generation) lines.
  • Base station 108 is connected to network 110.
  • the in-vehicle device 100 of the vehicle 102 and the in-vehicle devices of the other vehicle 112 have communication functions based on the communication specifications (4G line, 5G line, etc.) serviced by the base station 108.
  • the first server 104 also receives sensor data from infrastructure sensors 114 that are fixedly installed on the roadside (that is, on the road (including intersections) and its surroundings).
  • the infrastructure sensor 114 is, for example, an image sensor (such as a digital surveillance camera), a radar (such as a millimeter wave radar), or a laser sensor (such as LiDAR (Light Detection and Ranging)).
  • the infrastructure sensor has a communication function with the base station 108 and transmits the acquired sensor data to the first server 104 via the base station 108 and the network 110.
  • the vehicle 102, other vehicles 112, pedestrians 900, etc. are detection targets of the infrastructure sensor 114.
  • Vehicle 102 and other vehicles 112 are also equipped with on-vehicle sensors.
  • Other vehicles 112 and pedestrians 900 are detection targets of an on-vehicle sensor mounted on vehicle 102.
  • Vehicle 102 and pedestrian 900 are detection targets of an on-vehicle sensor mounted on another vehicle 112.
  • Sensor data acquired by the on-vehicle sensor mounted on the vehicle 102 is transmitted to the first server 104 via the base station 108 and the network 110.
  • the first server 104 analyzes sensor data received from the vehicle 102 and the infrastructure sensor 114 and uses it for services.
  • FIG. 1 shows one base station 108, one vehicle 102 equipped with an on-vehicle device 100, and one other vehicle 112.
  • multiple base stations are provided.
  • a plurality of vehicles that upload sensor data to the first server 104 are traveling, and a plurality of other vehicles 112 that upload communication performance data to the second server 106 are traveling.
  • the in-vehicle device 100 includes a communication unit 120, an in-vehicle gateway 122, an in-vehicle sensor 124, a vehicle state management unit 126, a driving control unit 128, and a bus 132.
  • the communication unit 120 performs wireless communication with an external device of the vehicle 102 (for example, communication with the first server 104 etc. via the base station 108).
  • the communication unit 120 includes an IC (Integrated Circuit) for modulating and multiplexing employed in wireless communication, an antenna for transmitting and receiving radio waves of a predetermined frequency, an RF (Radio Frequency) circuit, and the like.
  • the communication unit 120 also has a communication function with a global navigation satellite system (GNSS) such as a global positioning system (GPS).
  • GNSS global navigation satellite system
  • GPS global positioning system
  • the communication unit 120 may also have a communication function such as Wi-Fi.
  • the in-vehicle gateway 122 plays the role of connecting the communication function (specifically, communication specifications) with the outside of the vehicle and the communication function (communication specifications) inside 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 performs control to buffer the data to be uploaded, depending on the state of the wireless communication environment.
  • the bus 132 is responsible for the communication function within the vehicle, and communication (i.e., data exchange) between the in-vehicle gateway 122, the in-vehicle sensor 124, the vehicle status management section 126, and the driving control section 128 is performed via the bus 132.
  • a CAN Controller Area Network
  • a CAN Controller Area Network
  • 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 a 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.
  • the vehicle state management unit 126 manages the state of the vehicle 102 (eg, position, running speed, acceleration, and running direction).
  • the location may be obtained, for example, by GPS.
  • the traveling speed, acceleration, and traveling direction can be calculated, for example, from time-series position information and corresponding time information.
  • the driving control unit 128 controls the running of the vehicle 102.
  • the operation control unit 128 is, for example, an automatic operation ECU (Electronic Control Unit).
  • the driving control unit 128 acquires sensor data from the on-vehicle sensor 124, analyzes it to understand the surrounding situation of the vehicle 102, and uses mechanisms related to automatic driving (i.e., engine, transmission, steering, and (mechanisms such as brakes).
  • the vehicle 102 is not limited to a vehicle having an automatic driving function. If vehicle 102 does not have an automatic driving function, vehicle 102 does not include driving control unit 128.
  • in-vehicle gateway 122 includes a control section 140 and a memory 142.
  • the control unit 140 includes 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 programs executed by the control unit 140.
  • the control unit 140 acquires the data to be processed directly from the communication unit 120 and acquires it 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 them to the bus 132.
  • the first server 104 includes a control unit 150 for controlling each unit, a memory 152 for storing data, a communication unit 154 for communicating, and a bus 156 for exchanging data between each unit. including.
  • the control unit 150 includes a CPU, and realizes functions described below by controlling each unit.
  • Memory 152 includes a rewritable semiconductor nonvolatile memory and a mass 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. Data received by the communication unit 154 is transmitted to and stored in the memory 152. This allows the first server 104 to execute a predetermined service.
  • second server 106 is configured similarly to first server 104. That is, the second server 106 includes a control section 160 that controls each section, a memory 162 that stores data, a communication section 164 that performs communication, and a bus 166 that exchanges data between the sections.
  • the control unit 160 includes a CPU, and realizes functions described below by controlling each unit.
  • Memory 162 includes a rewritable semiconductor nonvolatile memory and a mass storage device such as a hard disk drive.
  • the communication unit 164 receives communication performance data uploaded from an in-vehicle device mounted on another vehicle 112 via the base station 108. The data received by the communication unit 164 is transmitted to and stored in the memory 162. Thereby, the second server 106 can generate and manage the communication record map, read the communication record map from the memory 162, and distribute it upon receiving a request from the outside.
  • the in-vehicle gateway 122 includes a communication record map information DB (Database) 200, a route calculation unit 202, a buffering control unit 206, a communication record recording unit 208, a communication record transmission unit 210, and a communication record acquisition unit 212.
  • FIG. 6 shows a part of the hardware configuration shown in FIGS. 2, 4, and 5.
  • the CAN 204 corresponds to the bus 132 shown in FIG. 2
  • the driving section 214 corresponds to the vehicle state management section 126 and the driving control section 128 shown in FIG.
  • the communication record map information DB 200 is realized by the memory 142 (see FIG. 3) of the in-vehicle gateway 122. Other functions of the in-vehicle gateway 122 are realized by a control unit 140 and a memory 142 (see FIG. 3).
  • the communication record map information DB 200 stores a communication record map.
  • the communication record map is a communication record map that the in-vehicle gateway 122 requests to the second server 106 via the communication unit 120 and receives from the second server 106 .
  • the route calculation unit 202 calculates the planned travel route of the vehicle 102 on which the in-vehicle device 100 is mounted.
  • the planned travel route of the vehicle 102 is calculated by the car navigation system mounted on the vehicle 102, for example, in response to a destination being set in the car navigation system.
  • the car navigation system can use the set destination and the current position of the vehicle 102, which can be obtained from GPS, to refer to a road map and calculate a planned driving route.
  • the route calculation unit 202 acquires the planned travel route calculated by the car navigation system from the car navigation system.
  • the route calculation unit 202 may independently obtain position information of the vehicle 102 from the vehicle status management unit 126 (see FIG. 2), and calculate the planned travel route of the vehicle 102, similar to a car navigation system.
  • the route calculation unit 202 outputs information about the calculated planned travel route to the buffering control unit 206.
  • the route calculation unit 202 requests the communication record acquisition unit 212 to transmit information on the planned travel route.
  • the communication record acquisition unit 212 receives a request from the route calculation unit 202 and transmits information on the planned travel route to the second server 106 (specifically, the communication record transmission unit 232) via the communication unit 120.
  • the communication performance 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.
  • the communication speed and signal strength of each area are representative values (for example, average values) obtained by statistical processing of communication performance data received from the on-board devices of vehicles traveling within the area during the same time period. .
  • the communication record map information 230 of the second server 106 includes, for example, a communication record map for each time period, and is stored in the memory 162 (see FIG. 5). As shown by the broken line arrow in FIG. The communication record map regarding the included area is read from the communication record map information 230.
  • the communication record transmitting unit 232 transmits the communication record map read from the communication record map information 230 to the vehicle 102 (specifically, the in-vehicle device 100) via the communication unit 164.
  • the communication record map transmitted from the second server 106 to the vehicle 102 is received by the communication record acquisition unit 212 via the communication unit 120 and stored in the communication record map information DB 200.
  • the communication record transmitting unit 232 of the second server 106 transmits the communication record map to the in-vehicle device 240 installed in a vehicle other than the vehicle 102, in the same way as transmitting the communication record map to the in-vehicle device 100. do.
  • the buffering control unit 206 reads the communication record map from the communication record map information DB 200 and determines whether the planned travel route input from the route calculation unit 202 includes an area where the wireless communication speed is low. For example, the buffering control unit 206 compares the wireless communication speed obtained from the communication performance map with a predetermined threshold value, identifies an area where the wireless communication speed ⁇ threshold value, and determines that the identified area is the area on the planned travel route. Determine whether or not they overlap. If they overlap, the overlapping portion on the planned travel route is specified as a predetermined range for buffering, which will be described later. Referring to FIG.
  • the buffering control unit 206 specifies the broken line portion included in the low-speed communication area 220 and the low-speed communication area 222 as a predetermined range for buffering.
  • the route calculation unit 202 identifies the predetermined range, it outputs information representing the predetermined range to the buffering control unit 206.
  • the second server 106 transmits only the communication performance map related to the area including the dashed arrow, it is necessary to determine whether the area where the wireless communication speed ⁇ the threshold value overlaps with the planned travel route. There isn't.
  • the buffering control unit 206 determines that the area specified as described above overlaps with the planned travel route and is a low-speed area. It is only necessary to determine whether the time period overlaps with the time period in which the vehicle 102 travels on the scheduled travel route.
  • the communication record recording unit 208 combines the communication results of the communication unit 120 (for example, communication speed and signal strength) with information that can be acquired from the CAN 204 (for example, vehicle status and vehicle position information), and creates communication record data. Record as.
  • the communication record data recorded by the communication record recording unit 208 is transmitted from the communication record transmitting unit 210 to the second server 106 via the communication unit 120.
  • the communication record data transmitted to the second server 106 is received by the communication record acquisition unit 234 via the communication unit 164 and is stored as communication record map information 230.
  • the communication record data recorded by the communication record recording unit 208 is also stored in the communication record map information DB 200.
  • the communication performance map information DB 200 may include communication results for each location (that is, area) and time period, and information recording the state of the vehicle 102 at that time.
  • the communication record acquisition unit 234 of the second server 106 also receives communication record data from an on-vehicle device 240 mounted on a vehicle other than the vehicle 102, and stores it as communication record map information 230.
  • Sensor data output from the on-vehicle sensor 124 mounted on the vehicle 102 and transmitted via the CAN 204 is input to the buffering control unit 206. If the predetermined range cannot be specified, the buffering control unit 206 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 is sent to the in-vehicle device 100 in advance from the communication unit 154 of the first server 104 (see step 400 in FIG. 9, which will be described later). For example, the first server 104 transmits to the in-vehicle device 100 a transmission request that includes information representing data quality required for the service (hereinafter referred to as required data quality) and allowable delay time.
  • required data quality data quality required for the service
  • the buffering control unit 206 transmits sensor data that satisfies required data quality and allowable delay to the first server 104.
  • the required data quality may be anything that represents the data capacity per unit time of sensor data transmitted from the in-vehicle device 100 to the first server 104, for example.
  • the required data quality may be specified, for example, by the resolution and frame rate of the sensor data.
  • the in-vehicle sensor 124 is a camera that outputs moving image data and it is possible to set a plurality of imaging conditions (resolution and frame rate of output data, etc.)
  • the buffering control unit 206 satisfies the required data quality.
  • the imaging conditions for the in-vehicle sensor 124 are set as follows.
  • Whether or not the allowable delay is satisfied is determined by, for example, whether the time required from when sensor data is generated in the vehicle 102 (that is, output from the in-vehicle sensor 124) until it is received by the first server 104 is less than or equal to the allowable delay time. It can be determined whether or not. Note that, as described later, when sensor data is buffered, the determination is made based on whether the time including the buffering time is less than or equal to the allowable delay time.
  • the buffering control unit 206 includes a buffer area (not shown).
  • the buffer area is a storage area secured to store sensor data output from the on-vehicle sensor 124 during buffering, which will be described later.
  • the buffer area is realized by the memory 142 shown in FIG.
  • the buffering control unit 206 stores the input sensor data in the buffer area (that is, buffers it) without transmitting the input sensor data to the first server 104.
  • Buffering control unit 206 performs buffering while vehicle 102 is traveling within a predetermined range. Thereafter, when the vehicle 102 completes traveling within a predetermined range, the buffering control unit 206 collectively transmits the sensor data buffered in the buffer area to the first server 104 (hereinafter referred to as batch transmission). Subsequently, the buffering control unit 206 transmits the sensor data newly input via the CAN 204 as described above to the first server 104.
  • the buffering control unit 206 predicts the time required for the vehicle 102 to travel within a predetermined range, and uses the predicted time (hereinafter referred to as predicted time) and the required data quality to determine the capacity of the buffer area (hereinafter referred to as predicted time). , also referred to as buffer capacity), and the calculated capacity is secured in the memory 142.
  • the buffering control unit 206 calculates the distance of the predetermined range from information representing the predetermined range, and calculates the traveling speed of the vehicle 102 from the driving unit 214 (specifically, the vehicle state management unit 126 (see FIG.
  • the predicted time is calculated by dividing the distance in the predetermined range by the traveling speed.
  • the buffering control unit 206 controls 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. Multiply all the values to calculate the lower limit of the buffer capacity. Note that if a buffer area of the calculated capacity cannot be secured, buffering is not performed. In that case, for example, the buffering control unit 206 notifies the first server 104 that buffering is not possible. Thereby, the first server 104 that requested the upload of sensor data can allocate resources for this purpose to another process without waiting for sensor data that cannot be received.
  • the sensor data that is transmitted all at once may satisfy the allowable delay time, as described above. 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 sensor data all at once. Even in that case, the buffering control unit 206 notifies the first server 104 that buffering is not possible. Thereby, the first server 104 that requested the upload of sensor data can allocate resources for this purpose to another process without waiting for sensor data that cannot be received.
  • the in-vehicle gateway 122 performs buffering to store the sensor data in the memory 142 without transmitting the sensor data, depending on the wireless communication speed with the first server 104 by the communication unit 120 that transmits the sensor data of the in-vehicle sensor 124. It is determined whether or not, and buffering is performed according to the determination result. That is, when the planned travel route of the in-vehicle device 100 includes a predetermined range where communication is in a low-speed state, the in-vehicle gateway 122 secures storage capacity for buffering in the memory 142 (see FIG. 3), and the vehicle 102 travels within the predetermined range. buffers sensor data while driving.
  • the in-vehicle gateway 122 transmits the buffered sensor data all at once. Therefore, even if the vehicle 102 travels in an environment where the wireless communication speed is low, the in-vehicle device 100 can transmit sensor data to the first server 104 without degrading the quality of the sensor data to be transmitted. Therefore, the first server 104 can maintain service. Furthermore, by collectively transmitting the buffered sensor data, the in-vehicle device 100 can transmit the buffered sensor data to the first server 104 without wasting the buffered sensor data.
  • the planned travel route may be calculated by an external device of the vehicle 102 (for example, a server that receives a request from the on-vehicle device 100), and may be transmitted from the external device to the on-vehicle device 100.
  • the buffering control unit 206 determines that buffering is to be performed when a low communication speed state in which the wireless communication speed is less than or equal to a predetermined value occurs in a predetermined range on the planned travel route, and the buffering control unit 206 determines that buffering is to be performed. Perform buffering while running. Thereby, the in-vehicle device 100 can perform necessary and sufficient buffering of sensor data.
  • 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 within a predetermined range, and uses the predicted time and required data quality to determine whether the buffer capacity necessary for buffering can be secured in the memory 142. judge. If the memory 142 can secure the storage capacity necessary for buffering, 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.
  • the in-vehicle device 100 receives the communication performance map from the second server 106 via the communication unit 120. Then, the buffering control unit 206 identifies a road corresponding to the planned travel route from among the roads included in the communication record map, uses the actual speed corresponding to the identified road as the wireless communication speed, and performs buffering. Determine whether or not to perform. Thereby, the in-vehicle device 100 can easily determine whether buffering is necessary.
  • FIG. 8 (Operation of in-vehicle gateway) Referring 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 a predetermined program from the memory 142 and executing it. It is assumed that a sensor data transmission request has been sent to the in-vehicle device 100 from the first server 104 in advance.
  • step 300 the control unit 140 transmits information representing the planned driving route to the second server 106 and requests the 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.
  • the in-vehicle gateway 122 obtains the driving route from, for example, a car navigation system mounted on the vehicle 102. Thereafter, control proceeds to step 302.
  • step 302 the control unit 140 receives the communication performance map from the second server 106.
  • the received communication performance map includes the transmitted scheduled travel route, as described above.
  • the control unit 140 stores the received communication record map in the communication record map information DB 200 (see FIG. 6). Control then moves to step 304.
  • step 304 the control unit 140 determines whether there is a low-speed communication area on the planned travel route. Specifically, the control unit 140 determines whether or not the communication performance map received in step 302 includes an area where the communication speed is equal to or less than a threshold value, and if it does, the control unit 140 changes the planned travel route. Determine whether or not overlaps with that area. If it is determined that they overlap, the control unit 140 specifies the overlapping portion (i.e., a predetermined range). That is, if the predetermined range is specified, it is determined that there is a low communication speed area, and control proceeds to step 306. If not (ie, no predetermined range is identified), control transfers to step 328.
  • the process in step 304 corresponds to the function of the buffering control unit 206 shown in FIG.
  • step 306 the control unit 140 determines whether the vehicle 102 has approached the low-speed communication area (that is, the predetermined range on the planned travel route identified in step 304). If it is determined that they have approached, control moves to step 310. Otherwise, control transfers to step 308.
  • Approaching a low communication speed area means that the distance from the vehicle 102 to the predetermined range has become less than the predetermined distance.
  • the predetermined distance can be set to a value in the range of 100 m to 10 m, for example.
  • step 308 the control unit 140 transmits the sensor data input to the communication record 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. Control then returns to step 306 and the above process is repeated.
  • step 310 the control unit 140 calculates the storage capacity required for buffering the sensor data. As described above regarding the buffering control unit 206, the control unit 140 calculates the required capacity of the buffer area from the required data quality and the time required to travel within a predetermined range (ie, predicted time). Control then transfers 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 easier to calculate the buffer capacity when the vehicle 102 is traveling far from the low-speed communication area. It is also possible to accurately determine whether buffering is possible.
  • the free capacity of memory 142 for securing a buffer area changes while vehicle 102 is running. Therefore, if the free capacity of the memory 142 when the vehicle 102 approaches a low-speed communication area is smaller than when the vehicle 102 is traveling in a remote location from the low-speed communications area, the vehicle 102 may be traveling in the remote location. There is a possibility that the calculated buffer capacity cannot be secured and buffering cannot be performed.
  • step 312 the control unit 140 determines whether the buffer capacity calculated in step 310 can be secured 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 it can be secured, control moves to step 314. Otherwise, control transfers to step 324.
  • step 314 the control unit 140 determines whether the sensor data to be buffered satisfies the allowable delay. This process corresponds to the function of the buffering control unit 206 in FIG. If it is determined that the allowable delay is met, control moves to step 316. Otherwise, control transfers to step 324.
  • step 316 the control unit 140 determines whether the vehicle 102 has started traveling in the low-speed communication area (ie, the predetermined range) and is currently traveling in the low-speed communication area. If it is determined that the vehicle is running, control proceeds to step 318. Otherwise (ie, if vehicle 102 has passed through a low speed communication area), control moves to step 320.
  • the low-speed communication area ie, the predetermined range
  • step 318 the control unit 140 buffers the sensor data output from the on-vehicle sensor 124. That is, the control unit 140 stores the sensor data output from the in-vehicle sensor 124 in the buffer area of the buffering control unit 206 (specifically, the memory 142 in FIG. 6) without transmitting it to the first server 104. . Control then returns to step 316. At this time, the sensor data is stored in chronological order, that is, in such a manner that the time order in which the sensor data was generated can be determined (for example, with time information attached).
  • step 320 the control unit 140 reads the sensor data stored in the buffer area of the buffering control unit 206, The information is sent in bulk to the first server 104 via the communication unit 120.
  • batch transmission refers to transmitting all sensor data stored in the buffer area of the buffering control unit 206 before transmitting new sensor data output from the in-vehicle sensor 124 to the first server 104. means. Control then transfers to step 322.
  • step 322 the control unit 140 determines whether or not there is any low-speed communication area in which the vehicle 102 has not yet traveled among the low-speed communication areas (i.e., the specified range) detected in step 304. This is a process to deal with the fact that multiple low-speed communication areas may be detected in step 304. If it is determined that there is an untraveled low-speed communication area, control returns to step 306. If not, control proceeds to step 330.
  • step 324 the control unit 140 transmits information indicating that sensor data cannot be transmitted to the first server 104. Control then passes to step 326.
  • step 326 similarly to step 316, the control unit 140 determines whether the vehicle 102 has started traveling in the low-speed communication area and is currently traveling in the low-speed communication area. Step 326 is repeated until the determination is NO (that is, until the vehicle 102 passes through the low speed communication area). Therefore, during this time, sensor data is not sent to the first server 104 and no buffering is performed. If the determination is NO, control moves to step 322.
  • step 328 the control unit 140 transmits the sensor data output from the on-vehicle sensor 124 to the communication unit 120. via the first server 104. Control then passes to step 330.
  • step 330 the control unit 140 determines whether or not to terminate. Specifically, the control unit 140 determines whether or not the vehicle 102 has completed traveling the planned route (e.g., 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 if it receives a notification from the first server 104 that sensor data transmission is not necessary.
  • the planned route e.g., arrived at destination A in FIG. 7
  • steps 328 and 330 are repeated while the vehicle 102 is traveling on the planned route.
  • the determination result in step 304 is NO
  • steps 328 and 330 are repeated while the vehicle 102 is traveling on the planned route.
  • the determination result in step 304 is YES
  • Steps 328 and 330 are repeated while the vehicle is traveling along the planned travel route.
  • step 326 sensor data is neither transmitted nor buffered while the vehicle 102 is traveling in each low-speed communication area (see step 326), and the vehicle 102 After passing through the last low-speed communication area, steps 328 and 330 are repeated while the vehicle is traveling the remaining planned travel route.
  • the in-vehicle gateway 122 secures storage capacity for buffering in the memory 142, and while the vehicle 102 is traveling in the low-speed communication area. Buffer the sensor data (see step 318). Thereafter, when the vehicle 102 passes through a low-speed communication area (the determination result in step 316 is NO), the in-vehicle gateway 122 transmits the buffered sensor data all at once (see step 320). Therefore, even if the vehicle 102 travels in an environment where the wireless communication speed is low, the in-vehicle device 100 can transmit sensor data to the first server 104 without degrading the quality of the sensor data to be transmitted. Therefore, the first server 104 can maintain service. Furthermore, by collectively transmitting the buffered sensor data, the in-vehicle device 100 can transmit the buffered sensor data to the first server 104 without wasting the buffered sensor data.
  • the in-vehicle gateway 122 executes the program shown in FIG. 8 again.
  • the operation of the first server 104 that is, the function of receiving sensor data from the in-vehicle device 100 and providing services will be described.
  • 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.
  • step 400 the control unit 150 requests a plurality of vehicles (specifically, in-vehicle devices) to transmit sensor data. Control then transfers to step 402. Transmission of this request may be performed, for example, by broadcast. At this time, the control unit 150 transmits a transmission request including information on required data quality and allowable delay time, as described above.
  • the in-vehicle gateway 122 of the in-vehicle device 100 transmits the sensor data output from the in-vehicle sensor 124 mounted on the vehicle 102 to the first server 104, as described above, and specifies the planned travel route. Then, the program shown in FIG. 8 is executed.
  • step 402 the control unit 150 determines whether sensor data has been received. If it is determined that the message has been received, control moves to step 404. Otherwise, control transfers to step 406.
  • step 404 the control unit 150 transfers the received sensor data to the application (i.e., program) of the corresponding service (for example, remote monitoring service) that is being executed by the first server 104. Control then transfers to step 406.
  • application i.e., program
  • the corresponding service for example, remote monitoring service
  • step 406 the control unit 150 determines whether an instruction to end has been received.
  • the instruction to terminate is given, for example, by operating a keyboard or mouse operation unit (not shown) provided in the first server 104. If it is determined that the process has ended, control moves to step 408. Otherwise, control returns to step 402 and the process described above is repeated.
  • step 408 the control unit 150 sends a notification to the vehicle that requested sensor data transmission in step 400 that sensor data transmission is unnecessary. Transmission of the request may be performed, for example, by broadcast. After that, the program ends.
  • the first server 104 can provide services using sensor data uploaded from the on-vehicle device of the vehicle. Furthermore, when the vehicle 102 is traveling in a low-speed communication area, the in-vehicle device 100 buffers the sensor data and uploads the sensor data to the first server 104 when the vehicle 102's planned travel route is calculated. When the sensor passes through a low-speed communication area, the buffered sensor data is sent all at once. Therefore, even if the vehicle 102 travels in an environment where the wireless communication speed is low, the in-vehicle device 100 can transmit sensor data to the first server 104 without degrading the quality of the sensor data to be transmitted. Therefore, the first server 104 can maintain service.
  • FIG. 10 the operation of the second server 106, that is, the function of generating a communication record map and transmitting the communication record map in response to a request, will be described.
  • the processing shown in FIG. 10 is realized by the control unit 160 of the second server 106 shown in FIG. 5 reading a predetermined program from the memory 162 and executing it.
  • the communication record map is stored in memory 162.
  • step 500 the control unit 160 determines whether a request for a communication performance map has been received. If it is determined that the message has been received, control moves to step 502. Otherwise, control transfers to step 504. For example, as described above, the in-vehicle device 100 requests transmission of a communication performance map with attached information representing the planned travel route (see step 300 in FIG. 8). When receiving this request, the control unit 160 determines YES.
  • step 502 the control unit 160 reads out from memory 162 the communication history map for 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. After that, control proceeds to step 508.
  • step 504 determines whether communication performance data has been received. If it is determined that it has been received, control moves to step 506. Otherwise, control transfers to step 508.
  • the communication performance data is, for example, data representing the actual state of wireless communication on each road (for example, communication speed and signal strength).
  • the in-vehicle device of each vehicle stores the communication speed and signal strength when the in-vehicle device performs wireless communication with the outside in chronological order with location information attached as communication performance data. Communication performance data is periodically transmitted to the second server 106.
  • step 506 the control unit 160 stores the communication performance data received in step 504 in the memory 162. At this time, the control unit 160 updates the existing communication record map using the received new communication record data as appropriate. Control then transfers to step 508.
  • step 508 the control unit 160 determines whether an instruction to end has been received.
  • the instruction to terminate is given, for example, by operating a keyboard or mouse operation unit (not shown) provided in the second server 106. If it is determined that the program is to be terminated, the program is terminated. Otherwise, control returns to step 500 and the process described above is repeated.
  • the second server 106 can generate and update a communication record map using the communication record data uploaded from the in-vehicle device of each vehicle, and transmit the communication record map upon request. Furthermore, when uploading sensor data to the first server 104, the in-vehicle device 100 uses the communication record map received from the second server 106 to determine whether or not the planned travel route of the vehicle 102 includes a low-speed communication area. It can be easily determined. When the planned travel route is calculated, the in-vehicle device 100 buffers the sensor data while the vehicle 102 is traveling in the low-speed communication area, and when the vehicle 102 passes through the low-speed communication area, transmits the buffered sensor data all at once. . Therefore, even if the vehicle 102 travels in an environment where the wireless communication speed is low, the in-vehicle device 100 can transmit sensor data to the first server 104 without degrading the quality of the sensor data to be transmitted.
  • the buffer capacity is calculated when the vehicle 102 approaches a low-speed communication area (i.e., a predetermined range), but the present invention is not limited to this.
  • the buffer capacity may be calculated at the time when the planned travel route is calculated and the corresponding communication performance map is acquired. For example, if the planned travel route is relatively short, the vehicle 102 can travel in a relatively short time, and the free capacity of the memory 142 will change relatively little. Therefore, the buffer capacity may be calculated in advance sufficiently before the vehicle 102 approaches the low-speed communication area.
  • the in-vehicle device 100 acquires the wireless communication speed on the planned travel route based on the communication record map received from the second server 106, but the present invention is not limited to this.
  • the in-vehicle device only needs to be able to acquire the wireless communication speed on the planned travel route of the vehicle 102 from the outside.
  • the vehicle 102 uses a map regarding wireless communication speeds provided by a wireless communication service company (for example, an area map of 5G and LTE (Long Term Evolution)) to determine the wireless communication speed on the planned route of the vehicle 102. may be specified.
  • the in-vehicle device 100 and the in-vehicle device of the other vehicle 112 transmit communication record data to the second server 106 transmit communication record data to the second server 106
  • the in-vehicle device 100 does not need to store the communication performance data or transmit the communication performance data to the second server 106. In that case, the in-vehicle device 100 does not need to include the communication record recording section 208 and the communication record transmitting section 210.
  • each process (each function) of the above-mentioned embodiments may be realized by a processing circuit (circuitry) including one or more processors.
  • the above-mentioned 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 each of the above processes.
  • the one or more processors may execute each of the above processes according to the programs read from the one or more memories, or may execute each of the above processes according to a logic circuit that has been designed in advance to execute each of the above 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 separated processors may cooperate with each other to execute the above processes.
  • the processors mounted on each of the 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 processes.
  • a recording medium that records a program that causes a computer to execute the processing of the in-vehicle device 100 (specifically, the process executed by the in-vehicle gateway 122 (for example, the process shown in FIG. 8)).
  • the recording medium is, for example, an optical disk (DVD (Digital Versatile Disc), etc.) or a removable semiconductor memory (USB (Universal Serial Bus) memory, etc.).
  • DVD Digital Versatile Disc
  • USB Universal Serial Bus
  • the computer readable non-transitory recording medium is In the computer installed in the vehicle, a communication function that communicates with an external device and transmits sensor data detected by a sensor mounted on the vehicle to the external device; Determine whether or not buffering is to be performed to store the sensor data in a storage unit without transmitting the sensor data by the communication function, depending on the wireless communication speed with the external device by the communication function, and based on the determination result. Accordingly, a computer program is stored for realizing the buffering control function for performing the buffering.

Landscapes

  • Engineering & Computer Science (AREA)
  • Computer Networks & Wireless Communication (AREA)
  • Signal Processing (AREA)
  • Physics & Mathematics (AREA)
  • General Physics & Mathematics (AREA)
  • Traffic Control Systems (AREA)

Abstract

車載装置は、車両に搭載される車載装置であって、外部装置と通信し、車両に搭載されたセンサにより検出されるセンサデータを外部装置に送信する通信部と、通信部による外部装置との間の無線通信速度に応じて、センサデータを通信部により送信せずに記憶部に記憶させるバッファリングを行うか否かを判定し、当該判定結果に応じて、バッファリングを行うバッファリング制御部とを含む。

Description

車載装置、制御方法およびコンピュータプログラム
　本開示は、車載装置、制御方法およびコンピュータプログラムに関する。本出願は、２０２２年９月２０日出願の日本出願第２０２２－１４８７５２号に基づく優先権を主張し、前記日本出願に記載された全ての記載内容を援用するものである。
　多数のセンサからのセンサデータをサーバコンピュータ（以下、サーバという）に集約して解析し、その解析結果を運転支援に利用するシステムが普及しつつある。センサデータは、車両に搭載されたセンサ、および、路側に設けられたインフラストラクチャ設備が備えるセンサ（以下、インフラセンサという）から送信される。こうしたシステムにおいては、車両は無線基地局を介してサーバと通信を行う。無線通信機能を持つ車両はまた、サーバを介さずに車両間における直接通信（いわゆる車々間通信）を行うことも可能である。車々間通信においては、ある車両のセンサデータを他の車両に送信したり、ある車両が持つ情報を他の車両に送信したりする。
　下記特許文献１には、車外との無線通信を行う機能を持つ車載用の装置（車載用通信制御装置）が開示されている。車載用通信制御装置は、車外のコンテンツプロバイダと通信する。この車載用通信制御装置は、車両の走行予定経路の電波環境が悪くストリーム型コンテンツの十分なダウンロードができない区間においても、中断することなくコンテンツの再生を可能とする。そのために特許文献１の車載用通信制御装置は、ダウンロードデータの再生用にバッファリングを行う。車載用通信制御装置は、車両の走行速度を考慮してバッファ可能なデータ量を算出し、ダウンロードの可否を判定する。
特開２００３－６１１４９号公報
　本開示のある局面に係る車載装置は、車両に搭載される車載装置であって、外部装置と通信し、車両に搭載されたセンサにより検出されるセンサデータを外部装置に送信する通信部と、通信部による外部装置との間の無線通信速度に応じて、センサデータを通信部により送信せずに記憶部に記憶させるバッファリングを行うか否かを判定し、当該判定結果に応じて、バッファリングを行うバッファリング制御部とを含む。
図１は、本開示の実施形態に係る車載装置の利用形態を示す模式図である。 図２は、図１に示した車載装置のハードウェア構成を示すブロック図である。 図３は、図２に示した車載ゲートウェイのハードウェア構成を示すブロック図である。 図４は、図１に示した第１サーバのハードウェア構成を示すブロック図である。 図５は、図１に示した第２サーバのハードウェア構成を示すブロック図である。 図６は、図２に示した車載ゲートウェイの機能構成を示すブロック図である。 図７は、通信実績地図に車両の走行予定経路を表示した状態を示す図である。 図８は、車載ゲートウェイにより実行される処理を示すフローチャートである。 図９は、第１サーバにより実行される処理を示すフローチャートである。 図１０は、第２サーバにより実行される処理を示すフローチャートである。
　［本開示が解決しようとする課題］
　無線通信速度が低い環境に車両が位置するときに、送信データを正常に送信するには、データの品質を低下させ、データサイズを小さくして送信することが考えられる。しかし、送信されたデータがサーバによるサービスに要求される品質を満たさなければ、送信されたデータが適切に利用されない。この場合、データ送信自体が無駄になる。
　特許文献１に開示された車載用通信制御装置は、ストリーミングデータのダウンロードに関するものであるため、データの送信（即ちアップロード）に関する上記の問題を解決できない。
　したがって、本開示は、無線通信速度が低い環境中を車両が走行することがあっても、送信データの品質を低下させることなく外部装置に送信できる車載装置、制御方法およびコンピュータプログラムを提供することを目的とする。
　［本開示の効果］
　本開示によれば、無線通信速度が低い環境中を車両が走行することがあっても、送信データの品質を低下させることなく外部装置に送信できる車載装置、制御方法およびコンピュータプログラムを提供できる。
　［本開示の実施形態の説明］
　本開示の実施形態の内容を列記して説明する。以下に記載する実施形態の少なくとも一部を任意に組み合せてもよい。
　（１）本開示の第１の局面に係る車載装置は、車両に搭載される車載装置であって、外部装置と通信し、車両に搭載されたセンサにより検出されるセンサデータを外部装置に送信する通信部と、通信部による外部装置との間の無線通信速度に応じて、センサデータを通信部により送信せずに記憶部に記憶させるバッファリングを行うか否かを判定し、当該判定結果に応じて、バッファリングを行うバッファリング制御部とを含む。これにより、車載装置は、無線通信速度が低い環境中を車両が走行することがあっても、送信データの品質を低下させることなく外部装置に送信できる。したがって、外部装置はサービスを維持できる。
　（２）上記（１）において、バッファリング制御部は、車両の走行予定経路上の所定範囲において、無線通信速度が所定値以下である通信低速状態が生じる場合、バッファリングを行うと判定し、車両が所定範囲を走行している間、バッファリングを行うことができる。これにより、必要十分なバッファリングを実行できる。
　（３）上記（２）において、通信部はさらに、外部装置から送信される所要データ品質を表す情報を受信してもよく、所要データ品質は、車載装置から外部装置に送信されるセンサデータの単位時間当たりのデータ容量を表していてもよく、バッファリング制御部は、車両が所定範囲を走行する予測時間を算出し、予測時間および所要データ品質を用いて、バッファリングに必要な記憶容量を算出し、算出された記憶容量を記憶部に確保できるか否かを判定してもよい。これにより、バッファリング可能か否かを効率的に判定できる。
　（４）上記（３）において、バッファリング制御部は、車載装置が所定範囲に所定距離以内に近づいたことを受けて、予測時間を算出し、記憶容量を算出し、記憶容量を記憶部に確保できるか否かを判定してもよい。これにより、バッファできるか否かを精度よく決定できる。
　（５）上記（３）または（４）において、バッファリング制御部は、記憶容量を確保できなければ、通信部に、センサデータを送信できないことを表す情報を外部装置に送信させてもよい。これにより、外部装置は、車載センサからセンサデータを待受ける必要がなく、リソースが無駄になることを回避できる。
　（６）上記（３）から（５）のいずれか１つにおいて、通信部はさらに、外部装置から送信される許容遅延時間を表す情報を受信してもよく、バッファリング制御部は、予測時間が許容遅延時間以上であれば、通信部に、センサデータを送信できないことを表す情報を外部装置に送信させてもよい。これにより、外部装置は、車載センサからセンサデータを待受ける必要がなく、リソースが無駄になることを回避できる。
　（７）上記（１）から（６）のいずれか１つにおいて、通信部はさらに、車載装置の外部から通信実績地図を受信し、通信実績地図は、道路を表す情報と、当該道路における無線通信の実績速度を表す情報とを対応させて含み、バッファリング制御部は、通信実績地図に含まれる道路を表す情報の中から走行予定経路に対応する道路を表す情報を特定し、特定された情報に対応する実績速度を表す情報を、無線通信速度を表す情報として用いて、バッファリングを行うか否かを判定してもよい。これにより、車載装置は、バッファリングの要否を容易に判定できる。
　（８）上記（１）から（７）のいずれか１つにおいて、バッファリング制御部は、バッファリングを行った後、バッファリングを行う必要がなければ、通信部に、バッファリングにより記憶部に記憶されているセンサデータを外部装置に送信させてもよい。これにより、車載装置は、バッファしていたセンサデータを無駄にすることなく、外部装置に送信できる。
　（９）本開示の第２の局面に係る制御方法は、車両に搭載される車載装置の制御方法であって、外部装置と通信し、車両に搭載されたセンサにより検出されるセンサデータを外部装置に送信する通信ステップと、通信ステップによる外部装置との間の無線通信速度に応じて、センサデータを通信ステップにより送信させずに記憶部に記憶させるバッファリングを行うか否かを判定する判定し、当該判定結果に応じて、バッファリングを行うバッファリング制御ステップとを含む。これにより、車載装置は、無線通信速度が低い環境中を車両が走行することがあっても、送信データの品質を低下させることなく外部装置に送信できる。したがって、外部装置はサービスを維持できる。
　（１０）本開示の第３の局面に係るコンピュータプログラムは、車両に搭載されるコンピュータに、外部装置と通信し、車両に搭載されたセンサにより検出されるセンサデータを外部装置に送信する通信機能と、通信機能による外部装置との間の無線通信速度に応じて、センサデータを通信機能により送信させずに記憶部に記憶させるバッファリングを行うか否かを判定し、当該判定結果に応じて、バッファリングを行うバッファリング制御機能とを実現させる。これにより、コンピュータは、無線通信速度が低い環境中を車両が走行することがあっても、送信データの品質を低下させることなく外部装置に送信できる。したがって、外部装置はサービスを維持できる。
　本発明は、このような特徴的な処理部を備える車載装置として実現できるだけでなく、かかる特徴的な処理をステップとする制御方法として実現したり、かかるステップをコンピュータに実行させるためのプログラムとして実現したりできる。また、車載装置の一部または全部を実現する半導体集積回路として実現したり、車載装置を含むサービス提供システムとして実現したりできる。
　［本開示の実施形態の詳細］
　以下の実施形態においては、同一の部品には同一の参照番号を付してある。それらの名称および機能も同一である。したがって、それらについての詳細な説明は繰返さない。
（全体構成）
　図１を参照して、本開示の実施形態に係る車載装置１００は、車両１０２に搭載される。車載装置１００は、サービスを提供する第１サーバ１０４からの要請を受けて、当該サービスに利用され得るデータをアップロードする。第１サーバ１０４から提供されるサービスは、例えば遠隔監視サービス（例えば、交通状況の監視または車内の状態の監視（運転者の状態の監視等））である。第１サーバ１０４から提供されるサービスは、車両に、当該車両の運転を支援するための情報等を提供するサービスであってもよい。アップロードされるデータは、後述するように、車両１０２に搭載されている車載センサにより取得されるセンサデータである。また、車両１０２と同様に車載装置を搭載した他車両１１２も走行している。車両１０２および他車両１１２は、通信実績地図を生成、管理および配信する第２サーバ１０６に、無線通信の実績データを送信する。通信実績地図は、後述するように、道路地図が複数の領域（例えば、矩形領域）に区分けされ（以下、区分けされた領域を「エリア」という）、各エリアに、そのエリア内における無線通信の通信速度および信号強度を対応させたものである。第２サーバ１０６は、車載装置１００からの要請を受けて、車載装置１００に通信実績地図を送信する。
　車載装置１００、他車両１１２の車載装置（図示せず）、第１サーバ１０４および第２サーバ１０６の間の通信は、基地局１０８を介して行われる。基地局１０８は、例えば、４Ｇ（４ｔｈ　Ｇｅｎｅｒａｔｉｏｎ）回線および５Ｇ（５ｔｈ　Ｇｅｎｅｒａｔｉｏｎ）回線等による移動通信サービスを提供している。基地局１０８はネットワーク１１０に接続されている。車両１０２の車載装置１００および他車両１１２の車載装置は、基地局１０８がサービスしている通信仕様（４Ｇ回線および５Ｇ回線等）による通信機能を有している。
　なお、第１サーバ１０４は、路側（即ち、道路（交差点を含む）およびその周辺）に固定して設置されたインフラセンサ１１４からもセンサデータを受信する。インフラセンサ１１４は、例えば、イメージセンサ（デジタルの監視カメラ等）、レーダ（ミリ波レーダ等）、またはレーザセンサ（ＬｉＤＡＲ（Ｌｉｇｈｔ　Ｄｅｔｅｃｔｉｏｎ　ａｎｄ　Ｒａｎｇｉｎｇ）等）である。インフラセンサは、基地局１０８との通信機能を有しており、取得したセンサデータを基地局１０８およびネットワーク１１０を介して第１サーバ１０４に送信する。
　車両１０２、他車両１１２および歩行者９００等は、インフラセンサ１１４の検出対象である。車両１０２および他車両１１２も車載センサを搭載している。他車両１１２および歩行者９００は、車両１０２に搭載された車載センサの検出対象である。車両１０２および歩行者９００は、他車両１１２に搭載された車載センサの検出対象である。
　車両１０２が搭載している車載センサにより取得されたセンサデータは、基地局１０８およびネットワーク１１０を介して第１サーバ１０４に送信される。第１サーバ１０４は、車両１０２およびインフラセンサ１１４から受信したセンサデータを解析し、サービスに利用する。
　図１には、１つの基地局１０８、車載装置１００が搭載された１つの車両１０２、および、１つの他車両１１２を示している。しかしこれは例示に過ぎない。通常、複数の基地局が設けられる。第１サーバ１０４にセンサデータをアップロードする複数の車両が走行しており、第２サーバ１０６に通信実績データをアップロードする複数の他車両１１２が走行している。車載装置を搭載していない車両が存在してもよい。車載装置を搭載していない車両は、動的物体として検出される。
（車載装置のハードウェア構成）
　図２を参照して、車両１０２に搭載されている車載装置１００のハードウェア構成の一例を示す。車載装置１００は、通信部１２０、車載ゲートウェイ１２２、車載センサ１２４、車両状態管理部１２６、運転制御部１２８およびバス１３２を含む。
　通信部１２０は、車両１０２の外部装置と無線通信（例えば、基地局１０８を介した第１サーバ１０４等との通信）を行う。通信部１２０は、無線通信において採用されている変調および多重化を行うためのＩＣ（Ｉｎｔｅｇｒａｔｅｄ　Ｃｉｒｃｕｉｔ）、所定周波数の電波を送信および受信するためのアンテナ、並びにＲＦ（Ｒａｄｉｏ　Ｆｒｅｑｕｅｎｃｙ）回路等を含む。通信部１２０は、ＧＰＳ（Ｇｌｏｂａｌ　Ｐｏｓｉｔｉｏｎｉｎｇ　Ｓｙｓｔｅｍ）等の全地球衛星測位システム（ＧＮＳＳ：Ｇｌｏｂａｌ　Ｎａｖｉｇａｔｉｏｎ　Ｓａｔｅｌｌｉｔｅ　Ｓｙｓｔｅｍ）との通信機能をも有する。通信部１２０は、Ｗｉ－Ｆｉ等の通信機能も有していてもよい。
　車載ゲートウェイ１２２は、車外との通信機能（具体的には通信仕様）と車内における通信機能（通信仕様）とを接合する役割（例えば通信プロトコル変換等）を担う。また、車載ゲートウェイ１２２は、後述するように、第１サーバ１０４にデータをアップロードする場合、無線通信環境の状態に応じて、アップロードするデータをバッファリングする制御を実行する。
　バス１３２は、車内における通信機能を担い、車載ゲートウェイ１２２、車載センサ１２４、車両状態管理部１２６および運転制御部１２８に関して、相互間の通信（即ちデータ交換）は、バス１３２を介して行われる。バス１３２には、例えば、ＣＡＮ（Ｃｏｎｔｒｏｌｌｅｒ　Ａｒｅａ　Ｎｅｔｗｏｒｋ）が使用される。
　車載センサ１２４は、車両１０２に搭載され、車両１０２外部の情報を取得するためのセンサ（ビデオ映像の撮像装置（例えば、デジタルカメラ（ＣＣＤ（Ｃｈａｒｇｅ－Ｃｏｕｐｌｅｄ　Ｄｅｖｉｃｅ）カメラまたはＣＭＯＳ（Ｃｏｍｐｌｅｍｅｎｔａｒｙ　Ｍｅｔａｌ－Ｏｘｉｄｅ　Ｓｅｍｉｃｏｎｄｕｃｔｏｒ）カメラ））、レーザセンサ（例えば、ＬｉＤＡＲ）等）、および、車両自体の情報を取得するためのセンサ（例えば加速度センサおよび荷重センサ）を含む。車載センサ１２４は、検知範囲（カメラの場合であれば撮像範囲）内の情報を取得してセンサデータとして出力する。デジタルカメラであれば、デジタルの画像データを出力する。車載センサ１２４の検出信号（即ちアナログまたはデジタル信号）は、Ｉ／Ｆ部（図示せず）を介して、デジタルデータとしてバス１３２に出力され、車載ゲートウェイ１２２に送信される。
　車両状態管理部１２６は、車両１０２の状態（例えば、位置、走行速度、加速度および走行方向）を管理する。位置は、例えば、ＧＰＳにより取得され得る。走行速度、加速度および走行方向は、例えば、時系列の位置情報と対応する時刻情報とにより算出され得る。
　運転制御部１２８は、車両１０２の走行を制御する。運転制御部１２８は、例えば、自動運転ＥＣＵ（Ｅｌｅｃｔｒｏｎｉｃ　Ｃｏｎｔｒｏｌ　Ｕｎｉｔ）である。例えば、運転制御部１２８は、車載センサ１２４からのセンサデータを取得し、それを解析して車両１０２の周囲の状況を把握し、自動運転に関連する機構（即ち、エンジン、変速機、ステアリングおよびブレーキ等の機構）を制御する。なお、車両１０２は自動運転機能を有する車両に限定されない。車両１０２が自動運転機能を有していなければ、車両１０２は運転制御部１２８を含まない。
（車載ゲートウェイのハードウェア構成）
　図３を参照して、車載ゲートウェイ１２２は、制御部１４０およびメモリ１４２を含む。制御部１４０は、ＣＰＵ（Ｃｅｎｔｒａｌ　Ｐｒｏｃｅｓｓｉｎｇ　Ｕｎｉｔ）を含んで構成されており、メモリ１４２を制御する。メモリ１４２は、例えば、書換可能な不揮発性の半導体メモリであり、制御部１４０が実行するコンピュータプログラム（以下、単にプログラムという）を記憶している。メモリ１４２は、制御部１４０が実行するプログラムのワーク領域を提供する。制御部１４０は処理対象のデータを、通信部１２０からは直接取得し、通信部１２０以外からはバス１３２を介して取得する。制御部１４０は、通信部１２０から受信したデータおよびバス１３２を介して受信したデータを適宜メモリ１４２に記憶する。制御部１４０は、処理結果をメモリ１４２に記憶し、バス１３２に出力する。
（第１サーバのハードウェア構成）
　図４を参照して、第１サーバ１０４は、各部を制御する制御部１５０と、データを記憶するメモリ１５２と、通信を行う通信部１５４と、各部の間においてデータを交換するためのバス１５６とを含む。制御部１５０は、ＣＰＵを含んで構成されており、各部を制御することにより、後述する機能を実現する。メモリ１５２は、書換可能な半導体の不揮発性メモリおよびハードディスクドライブ等の大容量記憶装置を含む。通信部１５４は、車載装置１００およびインフラセンサ１１４等からアップロードされるセンサデータを、基地局１０８を介して受信する。通信部１５４により受信されたデータは、メモリ１５２に送信されて記憶される。これにより、第１サーバ１０４は所定のサービスを実行できる。
（第２サーバのハードウェア構成）
　図５を参照して、第２サーバ１０６は、第１サーバ１０４と同様に構成されている。即ち、第２サーバ１０６は、各部を制御する制御部１６０と、データを記憶するメモリ１６２と、通信を行う通信部１６４と、各部の間においてデータを交換するためのバス１６６とを含む。制御部１６０は、ＣＰＵを含んで構成されており、各部を制御することにより、後述する機能を実現する。メモリ１６２は、書換可能な半導体の不揮発性メモリおよびハードディスクドライブ等の大容量記憶装置を含む。通信部１６４は、他車両１１２に搭載された車載装置等からアップロードされる通信実績データを、基地局１０８を介して受信する。通信部１６４により受信されたデータは、メモリ１６２に送信されて記憶される。これにより、第２サーバ１０６は、通信実績地図を生成および管理し、外部からの依頼を受けて通信実績地図をメモリ１６２から読出して配信できる。
（車載ゲートウェイの機能的構成）
　本開示に関する車載ゲートウェイ１２２の機能に関して説明する。図６を参照して、車載ゲートウェイ１２２は、通信実績地図情報ＤＢ（Ｄａｔａｂａｓｅ）２００、経路算出部２０２、バッファリング制御部２０６、通信実績記録部２０８、通信実績送信部２１０および通信実績取得部２１２を含む。図６には、図２、図４および図５に示したハードウェア構成の一部を示している。ＣＡＮ２０４は、図２に示したバス１３２に対応し、運転部２１４は、図２に示した車両状態管理部１２６および運転制御部１２８に対応する。第１サーバ１０４に関しては、図４に示した通信部１５４を示している。第２サーバ１０６に関しては、図５に示した通信部１６４を示し、車載ゲートウェイ１２２の機能と関連する通信実績地図情報２３０、通信実績送信部２３２および通信実績取得部２３４を示している。通信実績地図情報ＤＢ２００は、車載ゲートウェイ１２２のメモリ１４２（図３参照）により実現される。それ以外の車載ゲートウェイ１２２の機能は、制御部１４０およびメモリ１４２（図３参照）により実現される。通信実績地図情報ＤＢ２００は、通信実績地図を記憶している。通信実績地図は、車載ゲートウェイ１２２が通信部１２０を介して第２サーバ１０６に要求し、第２サーバ１０６から受信した通信実績地図である。
　経路算出部２０２は、車載装置１００が搭載された車両１０２の走行予定経路を算出する。車両１０２の走行予定経路は、例えば、車両１０２に搭載されているカーナビゲーションシステムに対して、目的地が設定されたことを受けて、カーナビゲーションシステムにより算出される。カーナビゲーションシステムは、設定された目的地と、ＧＰＳから取得できる車両１０２の現在位置とを用いて、道路地図を参照し、走行予定経路を算出できる。経路算出部２０２は、カーナビゲーションシステムにより算出された走行予定経路をカーナビゲーションシステムから取得する。経路算出部２０２は独自に、車両状態管理部１２６（図２参照）から車両１０２の位置情報等を取得し、カーナビゲーションシステムと同様に、車両１０２の走行予定経路を算出してもよい。経路算出部２０２は、算出した走行予定経路の情報を、バッファリング制御部２０６に出力する。
　また、経路算出部２０２は、走行予定経路の情報の送信を通信実績取得部２１２に要求する。通信実績取得部２１２は、経路算出部２０２からの要求を受けて、走行予定経路の情報を、通信部１２０を介して第２サーバ１０６（具体的には通信実績送信部２３２）に送信する。例えば、図７を参照して、通信実績地図は、道路地図が複数のエリアに区分けされ、各エリアに、そのエリア内における無線通信の通信速度および信号強度を対応させたものである。例えば、各エリアの通信速度および信号強度は、同じ時間帯にエリア内を走行している車両の車載装置から受信された通信実績データを統計処理して得られる代表値（例えば平均値）である。第２サーバ１０６の通信実績地図情報２３０は、例えば時間帯毎の通信実績地図を含み、メモリ１６２（図５参照）に記憶されている。図７の破線の矢印により示すように、現在の車両１０２の位置から目的地Ａまでの走行予定経路が決定されていた場合、第２サーバ１０６の通信実績送信部２３２は、少なくとも破線の矢印が含まれるエリアに関する通信実績地図を通信実績地図情報２３０から読出す。通信実績送信部２３２は、通信実績地図情報２３０から読出した通信実績地図を、通信部１６４を介して車両１０２（具体的には車載装置１００）に送信する。第２サーバ１０６から車両１０２に送信された通信実績地図は、通信部１２０を介して通信実績取得部２１２により受信され、通信実績地図情報ＤＢ２００に記憶される。なお、第２サーバ１０６の通信実績送信部２３２は、車載装置１００への通信実績地図の送信と同様に、車両１０２以外の車両に搭載されている車載装置２４０に対しても通信実績地図を送信する。
　バッファリング制御部２０６は、通信実績地図情報ＤＢ２００から通信実績地図を読出し、経路算出部２０２から入力された走行予定経路に無線通信速度が低速なエリアが含まれているか否かを判定する。例えば、バッファリング制御部２０６は、通信実績地図から得られる無線通信速度を所定のしきい値と比較し、無線通信速度≦しきい値であるエリアを特定し、特定されたエリアが走行予定経路と重なるか否かを判定する。重なる場合、走行予定経路上の重なる部分を、後述するバッファリングを行う所定範囲として特定する。図７を参照して、例えば、斜線を付した２つのエリア（即ち通信低速エリア２２０および通信低速エリア２２２）において、無線通信速度≦しきい値であるとする。その場合、バッファリング制御部２０６は、通信低速エリア２２０および通信低速エリア２２２に含まれる破線部分を、バッファリングを行う所定範囲として特定する。経路算出部２０２は、所定範囲を特定した場合、その所定範囲を表す情報をバッファリング制御部２０６に出力する。なお、第２サーバ１０６から破線の矢印が含まれるエリアに関する通信実績地図のみが送信される場合には、無線通信速度≦しきい値であるエリアが走行予定経路と重なるか否かを判定する必要はない。また、通信実績地図情報ＤＢ２００に時間帯毎の通信実績地図が記憶されている場合、バッファリング制御部２０６は、上記のように特定したエリアが走行予定経路と重なり、且つ、低速なエリアである時間帯が、車両１０２が走行予定経路を走行する時間帯と重なるか否かを判定すればよい。
　なお、通信実績記録部２０８は、通信部１２０の通信結果（例えば、通信速度および信号強度）と、ＣＡＮ２０４から取得できる情報（例えば、車両状態および車両の位置情報）とを組み合せて、通信実績データとして記録する。通信実績記録部２０８により記録された通信実績データは、通信実績送信部２１０から、通信部１２０を介して第２サーバ１０６に送信される。第２サーバ１０６に送信された通信実績データは、通信部１６４を介して通信実績取得部２３４により受信され、通信実績地図情報２３０として記憶される。また、通信実績記録部２０８により記録された通信実績データは、通信実績地図情報ＤＢ２００にも記憶される。したがって、通信実績地図情報ＤＢ２００には、位置（即ちエリア）および時間帯毎の通信結果と、そのときの車両１０２の状態を記録した情報とが含まれ得る。なお、第２サーバ１０６の通信実績取得部２３４は、車両１０２以外の車両に搭載されている車載装置２４０からも通信実績データを受信し、通信実績地図情報２３０として記憶する。
　バッファリング制御部２０６には、車両１０２に搭載された車載センサ１２４から出力され、ＣＡＮ２０４を介して伝送されるセンサデータが入力される。バッファリング制御部２０６は、所定範囲を特定できなければ、入力されるセンサデータを、通信部１２０を介して第１サーバ１０４に送信する。送信されたセンサデータは、第１サーバ１０４の通信部１５４により受信される。なお、車載装置１００には予め、センサデータの送信要求が第１サーバ１０４の通信部１５４から送信されている（後述する図９のステップ４００参照）。例えば、第１サーバ１０４は、サービスに要求されるデータ品質（以下、所要データ品質という）および許容遅延時間を表す情報を含む送信要求を車載装置１００に送信する。バッファリング制御部２０６は、所要データ品質および許容遅延を満たすセンサデータを第１サーバ１０４に送信する。所要データ品質は、例えば、車載装置１００から第１サーバ１０４に送信されるセンサデータの単位時間当たりのデータ容量を表すものであればよい。所要データ品質は、例えば、センサデータの解像度およびフレームレートにより指定され得る。例えば、車載センサ１２４が、動画像データを出力するカメラであり、複数の撮像条件（出力データの解像度およびフレームレート等）を設定可能であれば、バッファリング制御部２０６は、所要データ品質を満たすように、車載センサ１２４の撮像条件を設定する。許容遅延を満たすか否かは、例えば、車両１０２においてセンサデータが生成（即ち車載センサ１２４から出力）されてから第１サーバ１０４に受信されるまでに要する時間が、許容遅延時間以下であるか否かにより判定できる。なお、後述するように、センサデータがバッファリングされる場合には、バッファリング時間をも含めた時間が、許容遅延時間以下であるか否かにより判定される。
　バッファリング制御部２０６はバッファ領域（図示せず）を含む。バッファ領域は、後述するバッファリング中に、車載センサ１２４から出力されるセンサデータを記憶するために確保される記憶領域である。バッファ領域は、図３に示したメモリ１４２により実現される。バッファリング制御部２０６は、所定範囲を特定すると、入力されるセンサデータを第１サーバ１０４に送信せずに、バッファ領域に記憶する（即ち、バッファリングする）。バッファリング制御部２０６は、車両１０２が所定範囲を走行している間、バッファリングを行う。その後、車両１０２が所定範囲の走行を完了すると、バッファリング制御部２０６は、バッファ領域にバッファリングしていたセンサデータを第１サーバ１０４にまとめて送信する（以下、一括送信という）。それに続き、バッファリング制御部２０６は、上記したように新たにＣＡＮ２０４を介して入力されたセンサデータを、第１サーバ１０４に送信する。
　車両１０２が所定範囲を走行中にセンサデータをバッファリングするためには、適切な記憶容量を、バッファ領域としてメモリ１４２に確保する必要がある。そのために、バッファリング制御部２０６は、車両１０２が所定範囲を走行するのに要する時間を予測し、予測された時間（以下、予測時間という）と所要データ品質とから、バッファ領域の容量（以下、バッファ容量ともいう）を算出し、算出された容量をメモリ１４２に確保する。例えば、バッファリング制御部２０６は、所定範囲を表す情報から所定範囲の距離を算出し、運転部２１４（具体的には、車両状態管理部１２６（図２参照））から車両１０２の走行速度を取得し、所定範囲の距離を走行速度により除して予測時間を算出する。例えば、バッファリング制御部２０６は、フレームレート（即ち１秒間のフレーム数）、１フレームの解像度（即ち１フレームの画素数）、１画素のデータサイズ（例えばバイト単位）、および秒単位の予測時間を全て乗算し、バッファ容量の下限値を算出する。なお、算出された容量のバッファ領域を確保できなければ、バッファリングは行われない。その場合、例えば、バッファリング制御部２０６は、第１サーバ１０４にバッファリングできない旨を通知する。これにより、センサデータのアップロードを要求した第１サーバ１０４は、受信できないセンサデータを待受けずに、そのためのリソースを別の処理に割当てることができる。
　なお、一括送信されるセンサデータは、上記したように、許容遅延時間を満たしてもよい。バッファ領域に記憶されているセンサデータが許容遅延時間を満たさなければ、バッファリング制御部２０６は一括送信しない。その場合にも、バッファリング制御部２０６は、第１サーバ１０４にバッファリングできない旨を通知する。これにより、センサデータのアップロードを要求した第１サーバ１０４は、受信できないセンサデータを待受けずに、そのためのリソースを別の処理に割当てることができる。
　以上により、車載ゲートウェイ１２２は、車載センサ１２４のセンサデータを送信する通信部１２０による第１サーバ１０４との無線通信速度に応じて、センサデータを送信せずにメモリ１４２に記憶させるバッファリングを行うか否かを判定し、当該判定結果に応じて、バッファリングを行う。即ち、車載ゲートウェイ１２２は、車載装置１００の走行予定経路が通信低速状態となる所定範囲を含む場合、バッファリングのための記憶容量をメモリ１４２（図３参照）に確保し、車両１０２が所定範囲を走行している間、センサデータをバッファリングする。その後、車両１０２が、通信低速状態となる所定範囲を通過すると、車載ゲートウェイ１２２は、バッファリングしたセンサデータを一括送信する。したがって、車載装置１００は、無線通信速度が低い環境を車両１０２が走行することがあっても、送信するセンサデータの品質を低下させることなく、第１サーバ１０４に送信できる。したがって、第１サーバ１０４はサービスを維持できる。また、バッファリングしたセンサデータを一括送信することにより、車載装置１００は、バッファしていたセンサデータを無駄にすることなく、第１サーバ１０４に送信できる。なお、走行予定経路は、車両１０２の外部装置（例えば、車載装置１００からの要求を受けたサーバ）により算出され、外部装置から車載装置１００に送信されてもよい。
　上記したように、バッファリング制御部２０６は、走行予定経路上の所定範囲において、無線通信速度が所定値以下である通信低速状態が生じる場合、バッファリングを行うと判定し、車両１０２が所定範囲を走行している間、バッファリングを行う。これにより、車載装置１００は、必要十分なセンサデータのバッファリングを実行できる。
　上記したように、車載装置１００は、通信部１２０を介して、第１サーバ１０４から送信される所要データ品質を表す情報を受信する。そして、バッファリング制御部２０６は、車両１０２が所定範囲を走行する予測時間を算出し、予測時間および所要データ品質を用いて、バッファリングに必要なバッファ容量をメモリ１４２に確保できるか否かを判定する。バッファリング制御部２０６は、バッファリングに必要な記憶容量をメモリ１４２に確保できる場合、メモリ１４２に記憶容量を確保させる。これにより、バッファリング可能か否かを効率的に判定できる。
　上記したように、車載装置１００は、通信部１２０を介して、第２サーバ１０６ら通信実績地図を受信する。そして、バッファリング制御部２０６は、通信実績地図に含まれる道路の中から走行予定経路に対応する道路を特定し、特定された道路に対応する実績速度を、無線通信速度として用いて、バッファリングを行うか否かを判定する。これにより、車載装置１００は、バッファリングの要否を容易に判定できる。
（車載ゲートウェイの動作）
　図８を参照して、車載ゲートウェイ１２２の動作に関して、図６に示した機能を参照しつつ説明する。図８に示した処理は、制御部１４０（図３参照）が所定のプログラムをメモリ１４２から読出して実行することにより実現される。車載装置１００には予め、センサデータの送信要求が第１サーバ１０４から送信されているとする。
　図８を参照して、ステップ３００において、制御部１４０は、第２サーバ１０６に走行予定経路を表す情報を送信し、通信実績地図の送信を要求する。当該要求は、例えば、走行予定経路を表す情報に所定の要求コードを付して送信することにより行われる。車載ゲートウェイ１２２は、上記したように、例えば車両１０２に搭載されているカーナビゲーションシステムから走行経路を取得する。その後、制御はステップ３０２に移行する。
　ステップ３０２において、制御部１４０は、第２サーバ１０６から通信実績地図を受信する。受信された通信実績地図は、上記したように、送信した走行予定経路を含む。制御部１４０は、受信した通信実績地図を通信実績地図情報ＤＢ２００（図６参照）に記憶する。その後、制御はステップ３０４に移行する。
　ステップ３０４において、制御部１４０は、走行予定経路に通信低速エリアがあるか否かを判定する。具体的には、制御部１４０は、ステップ３０２により受信された通信実績地図に、通信速度がしきい値以下であるエリアが含まれるか否かを判定し、含まれていれば、走行予定経路がそのエリアと重なるか否かを判定する。重なると判定された場合、制御部１４０は重なる部分（即ち所定範囲）を特定する。即ち、所定範囲が特定された場合、通信低速エリアがあると判定され、制御はステップ３０６に移行する。そうでなれば（即ち所定範囲が特定されない場合）、制御はステップ３２８に移行する。ステップ３０４の処理は、図６に示したバッファリング制御部２０６の機能に対応する。
　ステップ３０６において、制御部１４０は、車両１０２が通信低速エリア（即ちステップ３０４により特定された走行予定経路上の所定範囲）に接近したか否かを判定する。接近したと判定された場合、制御はステップ３１０に移行する。そうでなければ、制御はステップ３０８に移行する。通信低速エリアに接近したとは、車両１０２から所定範囲までの距離が所定距離以下になったことを意味する。所定距離は、例えば１００ｍから１０ｍの範囲の値に設定できる。
　ステップ３０８において、制御部１４０は、通信実績地図情報ＤＢ２００に入力されるセンサデータを、通信部１２０を介して第１サーバ１０４に送信する。これは、図６に示したバッファリング制御部２０６の機能に対応する。その後、制御はステップ３０６に戻り、上記の処理が繰返される。
　車両１０２が通信低速エリア（即ち所定範囲）に接近すれば、ステップ３１０において、制御部１４０は、センサデータをバッファリングするために必要な記憶容量を算出する。バッファリング制御部２０６に関して上記したように、制御部１４０は、所要データ品質と所定範囲の走行に要する時間（即ち予測時間）とから、必要なバッファ領域の容量を算出する。その後、制御はステップ３１２に移行する。このように、車両１０２が通信低速エリア（即ち所定範囲）に接近したときにバッファ容量を算出することにより、車両１０２が通信低速エリアから遠い場所を走行しているときにバッファ容量を算出するよりも、バッファできるか否かを精度よく決定できる。バッファ領域を確保するためのメモリ１４２の空容量は、車両１０２の走行中に変化する。したがって、車両１０２が通信低速エリアに接近したときのメモリ１４２の空容量が、車両１０２が通信低速エリアから遠隔地を走行しているときよりも小さくなっていれば、当該遠隔地を走行しているときに算出されたバッファ容量を確保できず、バッファリングを実行できない可能性がある。
　ステップ３１２において、制御部１４０は、ステップ３１０により算出されたバッファ容量をメモリ１４２に確保可能か否かを判定する。この処理は、上記した図６のバッファリング制御部２０６の機能に対応する。確保可能と判定された場合、制御はステップ３１４に移行する。そうでなければ、制御はステップ３２４に移行する。
　ステップ３１４において、制御部１４０は、バッファリングされるセンサデータが許容遅延を満たすか否かを判定する。この処理は、図６のバッファリング制御部２０６の機能に対応する。許容遅延を満たすと判定された場合、制御はステップ３１６に移行する。そうでなければ、制御はステップ３２４に移行する。
　ステップ３１６において、制御部１４０は、車両１０２が通信低速エリア（即ち所定範囲）の走行を開始し、現在、通信低速エリアを走行中であるか否かを判定する。走行中であると判定された場合、制御はステップ３１８に移行する。そうでなければ（即ち、車両１０２が通信低速エリアを通過した場合）、制御はステップ３２０に移行する。
　ステップ３１８において、制御部１４０は、車載センサ１２４から出力されるセンサデータをバッファリングする。即ち、制御部１４０は、車載センサ１２４から出力されるセンサデータを第１サーバ１０４に送信せずに、バッファリング制御部２０６のバッファ領域（具体的には、図６のメモリ１４２）に記憶する。その後、制御はステップ３１６に戻る。このとき、センサデータは時系列に、即ちセンサデータが生成された時間順序を判別できるように（例えば時刻情報が付されて）記憶される。
　ステップ３１６による判定結果がＮＯの場合、即ち、車両１０２が通信低速エリアを通過した場合、ステップ３２０において、制御部１４０は、バッファリング制御部２０６のバッファ領域に記憶されているセンサデータを読出し、通信部１２０を介して第１サーバ１０４に一括送信する。なお、一括送信とは、車載センサ１２４から出力される新たなセンサデータを第１サーバ１０４に送信する前に、バッファリング制御部２０６のバッファ領域に記憶されているセンサデータを全て送信することを意味する。その後、制御はステップ３２２に移行する。
　ステップ３２２において、制御部１４０は、ステップ３０４により検出された通信低速エリア（即ち所定範囲）のうち、車両１０２がまだ走行していない通信低速エリアがあるか否かを判定する。これは、ステップ３０４により、通信低速エリアが複数検出され得るので、それに対応するための処理である。未走行の通信低速エリアが存在すると判定された場合、制御はステップ３０６に戻る。そうでなければ、制御はステップ３３０に移行する。
　ステップ３１２およびステップ３１４のいずれかの判定結果がＮＯであれば、ステップ３２４において、制御部１４０は、センサデータを送信できないことを表す情報を第１サーバ１０４に送信する。その後、制御はステップ３２６に移行する。
　ステップ３２６において、制御部１４０は、ステップ３１６と同様に、車両１０２が通信低速エリアの走行を開始し、現在、通信低速エリアを走行中であるか否かを判定する。ＮＯと判定されるまで（即ち、車両１０２が通信低速エリアを通過するまで）、ステップ３２６が繰返される。したがって、この間センサデータは第１サーバ１０４に送信されず、バッファリングも行われない。ＮＯと判定された場合、制御はステップ３２２に移行する。
　ステップ３０４の判定結果がＮＯであれば（即ち、走行予定経路に通信低速エリアが存在しない場合）、ステップ３２８において、制御部１４０は、車載センサ１２４から出力されるセンサデータを、通信部１２０を介して第１サーバ１０４に送信する。その後、制御はステップ３３０に移行する。
　ステップ３３０において、制御部１４０は、終了するか否かを判定する。具体的には、制御部１４０は、車両１０２が走行予定経路の走行を完了した（例えば、図７の目的地Ａに到着した）か否かを判定する。走行を完了したと判定された場合、本プログラムは終了する。そうでなければ、制御はステップ３２８に戻る。なお、制御部１４０は、第１サーバ１０４からセンサデータ送信が不要である旨の通知を受けた場合にも、終了すると判定してもよい。
　例えば、走行予定経路に通信低速エリアが存在しなければ（ステップ３０４の判定結果がＮＯの場合）、車両１０２が走行予定経路を走行中、ステップ３２８およびステップ３３０が繰返される。一方、走行予定経路に通信低速エリアが存在すれば（ステップ３０４の判定結果がＹＥＳ）、車両１０２が各通信低速エリアを走行中、バッファリングできればバッファリングし、一括送信した後、車両１０２が残りの走行予定経路を走行中、ステップ３２８およびステップ３３０が繰返される。また、走行予定経路に通信低速エリアが存在するが、バッファリングできなければ、車両１０２が各通信低速エリアを走行中、センサデータの送信もバッファリングも行われず（ステップ３２６参照）、車両１０２が最後の通信低速エリアを通過した後、残りの走行予定経路を走行中、ステップ３２８およびステップ３３０が繰返される。
　以上により、車載ゲートウェイ１２２は、車載装置１００の走行予定経路が通信低速エリアを含む場合、バッファリングのための記憶容量をメモリ１４２に確保し、車両１０２が通信低速エリアを走行している間、センサデータをバッファリングする（ステップ３１８参照）。その後、車両１０２が、通信低速エリアを通過すると（ステップ３１６の判定結果がＮＯ）、車載ゲートウェイ１２２は、バッファリングしたセンサデータを一括送信する（ステップ３２０参照）。したがって、車載装置１００は、無線通信速度が低い環境中を車両１０２が走行することがあっても、送信するセンサデータの品質を低下させることなく、第１サーバ１０４に送信できる。したがって、第１サーバ１０４はサービスを維持できる。また、バッファリングしたセンサデータを一括送信することにより、車載装置１００は、バッファしていたセンサデータを無駄にすることなく、第１サーバ１０４に送信できる。
　なお、新たに目的地が設定されて車両１０２の走行予定経路が新たに決定された場合には、車載ゲートウェイ１２２は、再度図８に示したプログラムを実行する。
（第１サーバの動作）
　図９を参照して、第１サーバ１０４による動作、即ち車載装置１００からセンサデータを受信し、サービスを提供する機能に関して説明する。図９に示した処理は、図４に示した第１サーバ１０４の制御部１５０が、所定のプログラムをメモリ１５２から読出して実行することにより実現される。
　ステップ４００において、制御部１５０は、複数の車両（具体的には車載装置）にセンサデータの送信を要求する。その後、制御はステップ４０２に移行する。この要求の送信は、例えばブロードキャストにより行われ得る。このとき、制御部１５０は、上記したように所要データ品質および許容遅延時間の情報を含む送信要求を送信する。これを受けて、車載装置１００の車載ゲートウェイ１２２は、上記したように、車両１０２に搭載されている車載センサ１２４から出力されるセンサデータを第１サーバ１０４に送信し、走行予定経路が特定されると、図８に示したプログラムを実行する。
　ステップ４０２において、制御部１５０は、センサデータを受信したか否かを判定する。受信したと判定された場合、制御はステップ４０４に移行する。そうでなければ、制御はステップ４０６に移行する。
　ステップ４０４において、制御部１５０は、受信したセンサデータを、第１サーバ１０４が実行している該当するサービス（例えば遠隔監視サービス）のアプリケーション（即ちプログラム）に転送する。その後、制御はステップ４０６に移行する。
　ステップ４０６において、制御部１５０は、終了の指示を受けたか否かを判定する。終了の指示は、例えば、第１サーバ１０４に備えられたキーボードまたはマウスの操作部（図示せず）が操作されることにより成される。終了すると判定された場合、制御はステップ４０８に移行する。そうでなければ、制御はステップ４０２に戻り、上記の処理が繰返される。
　ステップ４０８において、制御部１５０は、ステップ４００によりセンサデータの送信を要求した車両に対して、センサデータの送信が不要である旨の通知を送信する。要求の送信は、例えばブロードキャストにより行われ得る。その後、本プログラムは終了する。
　以上により、第１サーバ１０４は、車両の車載装置からアップロードされるセンサデータを用いてサービスを提供できる。また、車載装置１００は、第１サーバ１０４へのセンサデータのアップロードに際して、車両１０２の走行予定経路が算出されると、車両１０２が通信低速エリアを走行中、センサデータをバッファリングし、車両１０２が通信低速エリアを通過すると、バッファリングしたセンサデータを一括送信する。したがって、車載装置１００は、無線通信速度が低い環境中を車両１０２が走行することがあっても、送信するセンサデータの品質を低下させることなく、第１サーバ１０４に送信できる。したがって、第１サーバ１０４はサービスを維持できる。
（第２サーバの動作）
　図１０を参照して、第２サーバ１０６による動作、即ち、通信実績地図を生成し、要求を受けて通信実績地図を送信する機能に関して説明する。図１０に示した処理は、図５に示した第２サーバ１０６の制御部１６０が、所定のプログラムをメモリ１６２から読出して実行することにより実現される。通信実績地図はメモリ１６２に記憶される。
　ステップ５００において、制御部１６０は、通信実績地図の要求を受信したか否かを判定する。受信したと判定された場合、制御はステップ５０２に移行する。そうでなければ、制御はステップ５０４に移行する。例えば、上記したように、車載装置１００からは、走行予定経路を表す情報が添付されて、通信実績地図の送信が要求される（図８のステップ３００参照）。この要求を受信した場合、制御部１６０はＹＥＳと判定する。
　ステップ５０２において、制御部１６０は、要求に対応する該当エリアの通信実績地図をメモリ１６２から読出して送信する。送信先は、ステップ５００により受信された要求の送信元アドレス（例えばＩＰアドレス）により特定できる。その後、制御はステップ５０８に移行する。
　ステップ５００による判定結果がＮＯであれば、ステップ５０４において、制御部１５０は、通信実績データを受信したか否かを判定する。受信したと判定された場合、制御はステップ５０６に移行する。そうでなければ、制御はステップ５０８に移行する。通信実績データは、例えば、各道路における実際の無線通信の状態を表すデータ（例えば通信速度および信号強度）である。例えば、各車両の車載装置は、当該車載装置が外部と無線通信を行ったときの通信速度および信号強度を時系列に、位置情報を付して、通信実績データとして記憶し、記憶されている通信実績データを定期的に第２サーバ１０６に送信する。
　ステップ５０６において、制御部１６０は、ステップ５０４により受信した通信実績データをメモリ１６２に記憶する。このとき、制御部１６０は適宜、受信した新たな通信実績データを用いて、既存の通信実績地図を更新する。その後、制御はステップ５０８に移行する。
　ステップ５０８において、制御部１６０は、終了の指示を受けたか否かを判定する。終了の指示は、例えば、第２サーバ１０６に備えられたキーボードまたはマウスの操作部（図示せず）が操作されることにより成される。終了すると判定された場合、本プログラムは終了する。そうでなければ、制御はステップ５００に戻り、上記の処理が繰返される。
　以上により、第２サーバ１０６は、各車両の車載装置からアップロードされる通信実績データを用いて通信実績地図を生成および更新し、要求を受けて通信実績地図を送信できる。また、車載装置１００は、第１サーバ１０４へのセンサデータのアップロードに際して、第２サーバ１０６から受信した通信実績地図を用いて、車両１０２の走行予定経路に通信低速エリアが含まれるか否かを容易に判定できる。車載装置１００は、走行予定経路が算出されると、車両１０２が通信低速エリアを走行中、センサデータをバッファリングし、車両１０２が通信低速エリアを通過すると、バッファリングしたセンサデータを一括送信する。したがって、車載装置１００は、無線通信速度が低い環境中を車両１０２が走行することがあっても、送信するセンサデータの品質を低下させることなく、第１サーバ１０４に送信できる。
　上記においては、車両１０２が通信低速エリア（即ち所定範囲）に接近したときに、バッファ容量を算出する場合を説明したが、これに限定されない。走行予定経路が算出され、それに対応する通信実績地図を取得した時点において、バッファ容量を算出してもよい。例えば、走行予定経路が比較的短ければ、車両１０２は比較的短時間に走行可能であり、メモリ１４２の空容量の変化は比較的少ない。したがって、車両１０２が通信低速エリアに接近する十分前に、予めバッファ容量を算出しておいてもよい。
　上記においては、車載装置１００が、第２サーバ１０６から受信した通信実績地図により、走行予定経路上の無線通信速度を取得する場合を説明したが、これに限定されない。車載装置は、外部から車両１０２の走行予定経路における無線通信速度を取得できればよい。例えば、車両１０２は、無線通信サービス会社等が提供している無線通信速度に関するマップ（例えば、５ＧおよびＬＴＥ（Ｌｏｎｇ　Ｔｅｒｍ　Ｅｖｏｌｕｔｉｏｎ）のエリアマップ）を用いて、車両１０２の走行予定経路上の無線通信速度を特定してもよい。
　上記においては、車載装置１００および他車両１１２の車載装置が通信実績データを第２サーバ１０６に送信する場合を説明したが、これに限定されない。車載装置１００は、通信実績データを記憶せず、通信実績データを第２サーバ１０６に送信しなくてもよい。その場合、車載装置１００は、通信実績記録部２０８および通信実績送信部２１０を含んでいなくてもよい。
　なお、上述の実施形態の各処理（各機能）は、１または複数のプロセッサを含む処理回路（Ｃｉｒｃｕｉｔｒｙ）により実現されてもよい。上記処理回路は、上記１または複数のプロセッサに加え、１または複数のメモリ、各種アナログ回路および各種デジタル回路のいずれかが組み合わされた集積回路等により構成されてもよい。上記１または複数のメモリは、上記各処理を上記１または複数のプロセッサに実行させるプログラム（命令）を格納する。上記１または複数のプロセッサは、上記１または複数のメモリから読出した上記プログラムに従い上記各処理を実行してもよいし、予め上記各処理を実行するように設計された論理回路に従って上記各処理を実行してもよい。上記プロセッサは、ＣＰＵ、ＧＰＵ（Ｇｒａｐｈｉｃｓ　Ｐｒｏｃｅｓｓｉｎｇ　Ｕｎｉｔ）、ＤＳＰ（Ｄｉｇｉｔａｌ　Ｓｉｇｎａｌ　Ｐｒｏｃｅｓｓｏｒ）、ＦＰＧＡ（Ｆｉｅｌｄ　Ｐｒｏｇｒａｍｍａｂｌｅ　Ｇａｔｅ　Ａｒｒａｙ）およびＡＳＩＣ（Ａｐｐｌｉｃａｔｉｏｎ　Ｓｐｅｃｉｆｉｃ　Ｉｎｔｅｇｒａｔｅｄ　Ｃｉｒｃｕｉｔ）等、コンピュータの制御に適合する種々のプロセッサであってよい。なお物理的に分離した上記複数のプロセッサが互いに協働して上記各処理を実行してもよい。例えば物理的に分離した複数のコンピュータのそれぞれに搭載された上記プロセッサがＬＡＮ（Ｌｏｃａｌ　Ａｒｅａ　Ｎｅｔｗｏｒｋ）、ＷＡＮ（Ｗｉｄｅ　Ａｒｅａ　Ｎｅｔｗｏｒｋ）およびインターネット等のネットワークを介して互いに協働して上記各処理を実行してもよい。
　また、車載装置１００の処理（具体的には、車載ゲートウェイ１２２が実行する処理（例えば、図８に示した処理））をコンピュータに実行させるプログラムを記録した記録媒体を提供できる。記録媒体は、例えば光ディスク（ＤＶＤ（Ｄｉｇｉｔａｌ　Ｖｅｒｓａｔｉｌｅ　Ｄｉｓｃ）等）または着脱可能な半導体メモリ（ＵＳＢ（Ｕｎｉｖｅｒｓａｌ　Ｓｅｒｉａｌ　Ｂｕｓ）メモリ等）である。コンピュータプログラムは通信回線により伝送され得るが、記録媒体は非一時的な記録媒体を意味する。記録媒体に記憶されたプログラムをコンピュータに読込ませることにより、コンピュータは、上記したように、車載装置の外的環境の状態の悪化時にも、クラウド連携サービスを維持でき、サーバからのサービス提供を可能とする。
（付記）
　即ち、コンピュータ読取り可能な非一時的な記録媒体は、
　車両に搭載されるコンピュータに、
　外部装置と通信し、前記車両に搭載されたセンサにより検出されるセンサデータを前記外部装置に送信する通信機能と、
　前記通信機能による前記外部装置との間の無線通信速度に応じて、前記センサデータを前記通信機能により送信させずに記憶部に記憶させるバッファリングを行うか否かを判定し、当該判定結果に応じて、前記バッファリングを行うバッファリング制御機能とを実現させる、コンピュータプログラムを記憶している。
　以上、実施の形態を説明することにより本開示を説明したが、上記した実施の形態は例示であって、本開示は上記した実施の形態のみに制限されるわけではない。本開示の範囲は、発明の詳細な説明の記載を参酌した上で、請求の範囲の各請求項によって示され、そこに記載された文言と均等の意味および範囲内での全ての変更を含む。
１００、２４０　　車載装置
１０２　　車両
１０４　　第１サーバ
１０６　　第２サーバ
１０８　　基地局
１１０　　ネットワーク
１１２　　他車両
１１４　　インフラセンサ
１２０、１５４、１６４　　通信部
１２２　　車載ゲートウェイ
１２４　　車載センサ
１２６　　車両状態管理部
１２８　　運転制御部
１３２、１５６、１６６　　バス
１４０、１５０、１６０　　制御部
１４２、１５２、１６２　　メモリ
２００　　通信実績地図情報ＤＢ
２０２　　経路算出部
２０４　　ＣＡＮ
２０６　　バッファリング制御部
２０８　　通信実績記録部
２１０、２３２　　通信実績送信部
２１２、２３４　　通信実績取得部
２１４　　運転部
２３０　　通信実績地図情報
２２０、２２２　　通信低速エリア
３００、３０２、３０４、３０６、３０８、３１０、３１２、３１４、３１６、３１８、３２０、３２２、３２４、３２６、３２８、３３０、４００、４０２、４０４、４０６、４０８、５００、５０２、５０４、５０６、５０８　　ステップ
９００　　歩行者
Ａ　　目的地

Claims (10)

  1. 　車両に搭載される車載装置であって、
    　外部装置と通信し、前記車両に搭載されたセンサにより検出されるセンサデータを前記外部装置に送信する通信部と、
    　前記通信部による前記外部装置との間の無線通信速度に応じて、前記センサデータを前記通信部により送信せずに記憶部に記憶させるバッファリングを行うか否かを判定し、当該判定結果に応じて、前記バッファリングを行うバッファリング制御部とを含む、車載装置。
  2. 　前記バッファリング制御部は、
    　　前記車両の走行予定経路上の所定範囲において、前記無線通信速度が所定値以下である通信低速状態が生じる場合、前記バッファリングを行うと判定し、
    　　前記車両が前記所定範囲を走行している間、前記バッファリングを行う、請求項１に記載の車載装置。
  3. 　前記通信部はさらに、前記外部装置から送信される所要データ品質を表す情報を受信し、
    　前記所要データ品質は、前記車載装置から前記外部装置に送信される前記センサデータの単位時間当たりのデータ容量を表し、
    　前記バッファリング制御部は、
    　　前記車両が前記所定範囲を走行する予測時間を算出し、
    　　前記予測時間および前記所要データ品質を用いて、前記バッファリングに必要な記憶容量を算出し、
    　　算出された前記記憶容量を前記記憶部に確保できるか否かを判定する、請求項２に記載の車載装置。
  4. 　前記バッファリング制御部は、前記車載装置が前記所定範囲に所定距離以内に近づいたことを受けて、
    　　前記予測時間を算出し、
    　　前記記憶容量を算出し、
    　　前記記憶容量を前記記憶部に確保できるか否かを判定する、請求項３に記載の車載装置。
  5. 　前記バッファリング制御部は、前記記憶容量を確保できなければ、前記通信部に、前記センサデータを送信できないことを表す情報を前記外部装置に送信させる、請求項３または請求項４に記載の車載装置。
  6. 　前記通信部はさらに、前記外部装置から送信される許容遅延時間を表す情報を受信し、
    　前記バッファリング制御部は、前記予測時間が前記許容遅延時間以上であれば、前記通信部に、前記センサデータを送信できないことを表す情報を前記外部装置に送信させる、請求項３から請求項５のいずれか１項に記載の車載装置。
  7. 　前記通信部はさらに、前記車載装置の外部から通信実績地図を受信し、
    　前記通信実績地図は、道路を表す情報と、当該道路における無線通信の実績速度を表す情報とを対応させて含み、
    　前記バッファリング制御部は、前記通信実績地図に含まれる前記道路を表す情報の中から前記走行予定経路に対応する道路を表す情報を特定し、特定された前記情報に対応する前記実績速度を表す情報を、前記無線通信速度を表す情報として用いて、前記バッファリングを行うか否かを判定する、請求項１から請求項６のいずれか１項に記載の車載装置。
  8. 　前記バッファリング制御部は、前記バッファリングを行った後、前記バッファリングを行う必要がなければ、前記通信部に、前記バッファリングにより前記記憶部に記憶されている前記センサデータを前記外部装置に送信させる、請求項１から請求項７のいずれか１項に記載の車載装置。
  9. 　車両に搭載される車載装置の制御方法であって、
    　外部装置と通信し、前記車両に搭載されたセンサにより検出されるセンサデータを前記外部装置に送信する通信ステップと、
    　前記通信ステップによる前記外部装置との間の無線通信速度に応じて、前記センサデータを前記通信ステップにより送信させずに記憶部に記憶させるバッファリングを行うか否かを判定し、当該判定結果に応じて、前記バッファリングを行うバッファリング制御ステップとを含む、制御方法。
  10. 　車両に搭載されるコンピュータに、
    　外部装置と通信し、前記車両に搭載されたセンサにより検出されるセンサデータを前記外部装置に送信する通信機能と、
    　前記通信機能による前記外部装置との間の無線通信速度に応じて、前記センサデータを前記通信機能により送信させずに記憶部に記憶させるバッファリングを行うか否かを判定し、当該判定結果に応じて、前記バッファリングを行うバッファリング制御機能とを実現させる、コンピュータプログラム。
PCT/JP2023/028859 2022-09-20 2023-08-08 車載装置、制御方法およびコンピュータプログラム WO2024062786A1 (ja)

Applications Claiming Priority (2)

Application Number Priority Date Filing Date Title
JP2022148752 2022-09-20
JP2022-148752 2022-09-20

Publications (1)

Publication Number Publication Date
WO2024062786A1 true WO2024062786A1 (ja) 2024-03-28

Family

ID=90454347

Family Applications (1)

Application Number Title Priority Date Filing Date
PCT/JP2023/028859 WO2024062786A1 (ja) 2022-09-20 2023-08-08 車載装置、制御方法およびコンピュータプログラム

Country Status (1)

Country Link
WO (1) WO2024062786A1 (ja)

Citations (3)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
WO2019188343A1 (ja) * 2018-03-28 2019-10-03 住友電気工業株式会社 運転支援のためのシステム、車載装置、方法及びコンピュータプログラム
WO2020111134A1 (ja) * 2018-11-29 2020-06-04 住友電気工業株式会社 システム、サーバコンピュータ、車載装置、制御方法、半導体集積回路及びコンピュータプログラム
WO2022064802A1 (ja) * 2020-09-25 2022-03-31 株式会社デンソー データ送信装置、データ送信方法、及びデータ送信プログラム

Patent Citations (3)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
WO2019188343A1 (ja) * 2018-03-28 2019-10-03 住友電気工業株式会社 運転支援のためのシステム、車載装置、方法及びコンピュータプログラム
WO2020111134A1 (ja) * 2018-11-29 2020-06-04 住友電気工業株式会社 システム、サーバコンピュータ、車載装置、制御方法、半導体集積回路及びコンピュータプログラム
WO2022064802A1 (ja) * 2020-09-25 2022-03-31 株式会社デンソー データ送信装置、データ送信方法、及びデータ送信プログラム

Similar Documents

Publication Publication Date Title
US10810807B2 (en) Data collection system and data center
JP7396268B2 (ja) 運転支援のためのシステム、車載装置、方法及びコンピュータプログラム
US10862970B2 (en) Call-ahead downloading to vehicles
JPWO2020111134A1 (ja) システム、サーバコンピュータ、車載装置、制御方法、半導体集積回路及びコンピュータプログラム
JP2008199381A (ja) 移動体通信システム
US11455890B2 (en) Traffic-adaptive deployment of vehicle functions
WO2020235641A1 (ja) 情報送信装置、情報収集装置、情報送信方法、情報収集方法及び移動体
CN111866941B (zh) 一种网络资源调度方法及相关设备
WO2022049924A1 (ja) 車載装置、情報配信装置、運転支援システム、制御方法及びコンピュータプログラム
JP2019176311A (ja) 車載装置、その制御方法及びコンピュータプログラム
JP7293849B2 (ja) 情報転送装置、車載装置、システム、情報転送方法及びコンピュータプログラム
US11250703B2 (en) Highly localized weather data recorded by vehicles in a fleet
JP7070664B2 (ja) システム、そのサーバコンピュータ、制御方法及びコンピュータプログラム
WO2024062786A1 (ja) 車載装置、制御方法およびコンピュータプログラム
JP7283215B2 (ja) 車載装置、システム、制御方法、半導体集積回路及びコンピュータプログラム
WO2024024223A1 (ja) 車載装置、制御方法およびコンピュータプログラム
WO2023058305A1 (ja) 車載装置、集約装置、車載システム、サーバコンピュータ、制御方法及びコンピュータプログラム
WO2022071072A1 (ja) 通信管理装置、通信管理方法、および通信管理プログラム
WO2022071071A1 (ja) 通信制御装置、通信制御方法、および通信制御プログラム
US11852496B2 (en) Predictable and delay tolerant traffic management system
WO2024018748A1 (ja) データ送信装置、運転支援装置、リソース制御方法およびコンピュータプログラム
WO2023058306A1 (ja) 車載装置、車載システム、制御方法及びコンピュータプログラム
WO2023243324A1 (ja) 車載装置、車載システム、サーバコンピュータ、制御方法およびコンピュータプログラム
WO2023276435A1 (ja) 車載装置、サーバ及びシステム
WO2023106021A1 (ja) 車載装置、路側装置、制御方法およびコンピュータプログラム