Onboard device, onboard system, server computer, control method, and computer program

Abstract

This onboard device is installed in a vehicle and comprises: a required real-time degree determination unit for determining a required real-time degree pertaining to received data received from outside the vehicle; an elapsed time calculation unit for calculating an elapsed time that is a time from when original data for the received data is generated until when the received data is received by the onboard device; an estimated time calculation unit for calculating an estimated time that is a time from when the received data is received until when the received data begins to be used; and an availability determination unit for determining availability of the received data on the basis of the required real-time degree, the elapsed time, and the estimated time. The required real-time degree represents an allowable extent for a delay time from when the original data is generated until when the received data is used. The received data includes added time information for identifying the time when the original data was generated. The elapsed time calculation unit calculates the elapsed time on the basis of the receipt time of the received data as well as time information.

Description

In-vehicle device, in-vehicle system, server computer, control method, and computer program

[0001] This application claims priority to Japanese Patent Application No. 2022-097693 filed on June 17, 2022, and incorporates by reference all of the contents of that application.

[0002] Low-latency communication environments such as 4G (fourth generation mobile communication system) and 5G (fifth generation mobile communication system) are becoming widespread. Furthermore, the installation of various electronic devices in automobiles, motorcycles, and other vehicles (hereinafter referred to as vehicles) is advancing. Accordingly, a system has been proposed in which an on-board device installed in a vehicle cooperates with a server computer to assist vehicle driving (hereinafter referred to as cooperative driving). In addition to conventional non-real-time information (e.g., statistical information such as traffic congestion information), cooperative driving also utilizes real-time information (e.g., dynamic information about moving objects detected by sensors). Because various types of data with different real-time characteristics are utilized, appropriate data processing according to the real-time characteristics is important.

[0003] Patent Document 1 below discloses a transfer system capable of transferring real-time data effectively. This transfer system includes a transfer server. The transfer server includes a non-real-time data filtering unit. The non-real-time data filtering unit filters (i.e., deletes) non-real-time data included in the received data. Specifically, the unit compares the date and time information (i.e., creation date and time) of a message included in the received data with the system date and time of the transfer server, and if there is a discrepancy between the two that is greater than a predetermined threshold, the message is deleted without being transferred.

[0004] Japanese Patent Application Laid-Open No. 2014-165675

[0005] An on-board device according to one aspect of the present disclosure is an on-board device mounted on a vehicle, and includes a real-time requirement determination unit that determines a real-time requirement degree for received data received from outside the vehicle, an elapsed time calculation unit that calculates an elapsed time, which is the time from the generation of original data of the received data until the received data is received by the on-board device, an estimated time calculation unit that calculates an estimated time, which is the time from the reception of the received data until the use of the received data begins, and a usability determination unit that determines the possibility of use of the received data based on the real-time requirement degree, the elapsed time, and the estimated time, wherein the real-time requirement degree represents the tolerable degree of delay time from the generation of the original data until the received data is used, and the received data is accompanied by time information for identifying the time the original data was generated, and the elapsed time calculation unit calculates the elapsed time based on the reception time of the received data and the time information.

[0006] FIG. 1 is a schematic diagram showing a usage form of an in-vehicle system according to an embodiment of the present disclosure. FIG. 2 is a block diagram showing the hardware configuration of the in-vehicle system 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 server shown in FIG. 1. FIG. 5 is a block diagram showing the software configuration of the in-vehicle system and the server. FIG. 6 is a diagram showing the timing of processing from the generation of original data to its use in a vehicle as driving assistance information. FIG. 7 is a flowchart showing processing executed by the server. FIG. 8 is a block diagram showing the functional configuration of the in-vehicle gateway. FIG. 9 is a flowchart showing processing executed by the in-vehicle gateway. FIG. 10 is a block diagram showing the functional configuration of a server according to a modified example. FIG. 11 is a schematic diagram showing information provision by the server shown in FIG. 10.

[0007] [Problem to be Solved by the Present Disclosure] The transfer system disclosed in Patent Document 1 ensures the real-time performance of transferred data by deleting non-real-time data. However, ensuring real-time performance also increases the amount of data wasted. Therefore, the technology described in Patent Document 1 cannot effectively utilize data communicated for cooperative operation without wasting it in a situation where data with different real-time performance requirements are mixed and communicated.

[0008] Therefore, an object of the present disclosure is to provide an in-vehicle device, an in-vehicle system, a server computer, a control method, and a computer program that can effectively utilize data in a situation where data with different real-time characteristics is communicated in a mixed manner.

[0009] Effect of the Present Disclosure The present disclosure provides an in-vehicle device, an in-vehicle system, a server computer, a control method, and a computer program that can effectively utilize data in a situation where data with different real-time characteristics is communicated in a mixed manner.

[0010] [Description of 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 combination.

[0011] (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 real-time requirement determination unit that determines a real-time requirement level for received data received from outside the vehicle; an elapsed time calculation unit that calculates an elapsed time, which is the time from when original data of the received data is generated until the received data is received by the in-vehicle device; an estimated time calculation unit that calculates an estimated time, which is the time from when the received data is received until use of the received data begins; and a usability determination unit that determines the possibility of use of the received data based on the real-time requirement level, the elapsed time, and the estimated time, where the real-time requirement level represents an acceptable degree of delay time from when the original data is generated until use of the received data, and the received data includes time information added thereto for identifying the time when the original data was generated, and the elapsed time calculation unit calculates the elapsed time based on the reception time and the time information of the received data, thereby enabling the in-vehicle device to effectively use the received data (e.g., driving assistance information).

[0012] (2) In the above (1), the availability determination unit can determine that the received data is unavailable if the sum of the elapsed time and the estimated time does not satisfy the real-time requirement level. The in-vehicle device can further include a data conversion unit that, upon the determination that the received data is unavailable by the availability determination unit, converts the received data into low-requirement data with a real-time requirement level lower than the real-time requirement level of the received data. If the data conversion unit cannot generate low-requirement data, the received data can be discarded. This allows the in-vehicle device to more effectively use the received data (e.g., driving assistance information). Furthermore, because data that cannot be effectively used is discarded, wasteful storage of unused data can be reduced.

[0013] (3) In the above (1) or (2), the received data may be added with service specification information for specifying the service for which the received data is used, and the real-time requirement determination unit may determine the real-time requirement based on the service specification information. This makes it possible to easily determine the real-time requirement.

[0014] (4) In the above (1) or (2), the real-time requirement determination unit determines the real-time requirement based on at least one of the type of received data and the service in which the received data is used, thereby enabling accurate determination of the real-time requirement.

[0015] (5) In the above (4), the types may include dynamic information, prediction information, and statistical information, and the services may include driving assistance including control of the vehicle's driving speed, driving planning including control of the vehicle's driving lane, and route selection for controlling the vehicle's planned driving route. This allows for safe and accurate control of the vehicle's driving.

[0016] (6) In any one of (1) to (5) above, the received data may be used by an electronic control unit mounted on the vehicle, and the estimated time calculation unit may calculate the estimated time by adding a transfer delay, which is the time required to transfer the received data to the electronic control unit, a waiting time, which is the time it takes for the vehicle to reach a position where the received data is used, and a predetermined time, and the predetermined time may represent the sum of the processing time by the real-time requirement determination unit, the processing time by the elapsed time calculation unit, and the processing time by the availability determination unit. This allows the in-vehicle device to more effectively use the received data (e.g., driving assistance information).

[0017] (7) According to a second aspect of the present disclosure, there is provided an in-vehicle system mounted on a vehicle, the in-vehicle system including any one of the in-vehicle devices described above in (1) to (6), a communication unit that receives received data, and an electronic control unit to which the received data determined by the in-vehicle device to be usable is transferred, thereby enabling the in-vehicle system to effectively use the received data (e.g., driving assistance information).

[0018] (8) A server computer according to a third aspect of the present disclosure includes a communication unit that receives sensor data from an external device, an analysis unit that analyzes the sensor data and generates first driving assistance information, and a vehicle identification unit that identifies a first vehicle that can reach a point where the sensor data is generated within a first allowable delay corresponding to a first real-time requirement level that corresponds to the first driving assistance information. The communication unit further transmits the first driving assistance information to an in-vehicle device of the first vehicle. This allows the server computer to transmit the driving assistance information only to vehicles that can effectively use the information, thereby reducing unnecessary transmission to vehicles that cannot use the information. In the vehicle, the received data (driving assistance information) can be quickly transferred to an application service (e.g., an end ECU (Electronic Control Unit)) without determining whether the received data can be effectively used.

[0019] (9) In the above (8), the server computer may further include a data conversion unit that generates, from the first driving assistance information, second driving assistance information corresponding to a second real-time demand level that is a lower level than the first real-time demand level, the vehicle identification unit further identifies a second vehicle that can arrive at the occurrence point within a second allowable delay corresponding to the second real-time demand level, and the communication unit further transmits the second driving assistance information to an in-vehicle device of the second vehicle. This allows more vehicles to effectively use the driving assistance information.

[0020] (10) A control method according to a fourth aspect of the present disclosure is a control method for an in-vehicle system including an in-vehicle device mounted on a vehicle, the control method including: a real-time requirement determination step in which the in-vehicle device determines a real-time requirement level for received data received from outside the vehicle; an elapsed time calculation step in which the in-vehicle device calculates an elapsed time, which is a time from generation of original data of the received data to reception of the received data by the in-vehicle device; an estimated time calculation step in which the in-vehicle device calculates an estimated time, which is a time from reception of the received data to start of use of the received data; and an availability determination step in which the in-vehicle device determines availability of the received data based on the real-time requirement level, the elapsed time, and the estimated time, wherein the real-time requirement level represents an acceptable degree of delay time from generation of the original data to use of the received data, and the received data is accompanied by time information for identifying the time the original data was generated, and the elapsed time calculation step includes a step in which the in-vehicle device calculates the elapsed time based on the reception time and the time information, thereby enabling the in-vehicle device to effectively use the received data (e.g., driving assistance information).

[0021] (11) A computer program according to a fourth aspect of the present disclosure causes a computer mounted on a vehicle to implement a real-time requirement determination function that determines a real-time requirement level for received data received from outside the vehicle, an elapsed time calculation function that calculates an elapsed time that is a time from generation of original data of the received data to reception of the received data, an estimated time calculation function that calculates an estimated time that is a time from reception of the received data to start of use of the received data, and an availability determination function that determines the availability of the received data based on the real-time requirement level, the elapsed time, and the estimated time, wherein the real-time requirement level represents an acceptable degree of delay time from generation of the original data to use of the received data, time information for identifying the time when the original data was generated is added to the received data, and the elapsed time calculation function includes a function that calculates the elapsed time based on the reception time and the time information of the received data. This enables the on-board device to effectively use received data (e.g., driving assistance information).

[0022] [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. Therefore, detailed descriptions thereof will not be repeated.

[0023] (Overall Configuration) Referring to Fig. 1, an in-vehicle system 100 according to an embodiment of the present disclosure is mounted on a vehicle 102. The in-vehicle system 100 receives data for cooperative driving (i.e., driving assistance information) from a server 116, which is a server computer. Data with different real-time characteristics is transmitted from the server 116. Communication between the in-vehicle system 100 and the server 116 is performed via a base station 108.

[0024] The base station 108 provides mobile communication services using, for example, a 4G line and a 5G line. The base station 108 is connected to a network 114. The in-vehicle system 100 installed in the vehicle 102 has a communication function according to the communication specifications (4G line, 5G line, etc.) provided by the base station 108. Note that communication between the in-vehicle system 100 and the server 116 may be direct communication without going through the base station 108.

[0025] The infrastructure sensor 104 is a device that is fixedly installed on a road (including an intersection) and its surrounding area (hereinafter also referred to as roadside) and has a function of acquiring information on the roadside. The infrastructure sensor 104 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 a LiDAR (Light Detection and Ranging)). The infrastructure sensor 104 has a communication function with a base station 108 and transmits acquired sensor data to a server 116 via the base station 108 and a network 114.

[0026] 1 are detection targets of the infrastructure sensor 104. The vehicle 102 is equipped with a sensor as described below. The other vehicle 112 is equipped with an on-board system and a sensor, similar to the vehicle 102. The pedestrian 900 is also a detection target of the sensors equipped on the vehicle 102 and the other vehicle 112.

[0027] Sensor data acquired by sensors mounted on the vehicle 102 and other vehicles 112 is transmitted to the server 116 via the base station 108 and the network 114. The server 116 analyzes the sensor data received from the infrastructure sensors 104, the vehicle 102, and the other vehicles 112, and stores the analysis results as dynamic information. The server 116 transmits the dynamic information to an in-vehicle device mounted on the vehicle as driving assistance information.

[0028] Dynamic information is information about dynamic objects detected by sensors (infrastructure sensors and on-board sensors). Dynamic objects are not limited to moving objects (people, vehicles, etc.), but also include stationary objects that have the ability to move. Dynamic information may include information about the dynamic object itself (hereinafter referred to as attributes) and information about the displacement of the dynamic object (position, movement speed, movement direction, time, etc.). Dynamic information is used as driving assistance information for use in autonomous driving of the vehicle, and is also used to determine a recommended route, which will be described later.

[0029] The attributes include at least simple attributes (hereinafter referred to as simple attributes). The attributes may also include detailed attributes (hereinafter referred to as detailed attributes). The simple attributes are used to roughly classify dynamic objects and include, for example, people, bicycles, motorcycles, and automobiles. The detailed attributes are used to more precisely classify dynamic objects and include the state of the dynamic object. For example, if the simple attribute is "person," the detailed attributes may include children, adults, and elderly people, and may further include so-called "walking while looking at a smartphone" (the state of walking while looking at a smartphone, etc.) and ignoring traffic lights. For example, if the simple attribute is "automobile," the detailed attributes may include, for example, regular cars and large vehicles, and may further include buses, taxis, emergency vehicles (ambulances and fire engines), and inattentive driving. Note that the simple attributes and detailed attributes are not limited to these and may include any attributes. Among the information regarding the displacement of a dynamic object, time information is, for example, the time at which location information, movement speed information, and movement direction information were generated.

[0030] 1 shows one base station 108, one infrastructure sensor 104, two vehicles 102 equipped with an on-board system, and another vehicle 112. However, this is merely an example. Typically, multiple base stations are provided, and multiple vehicles are equipped with on-board systems. There may be vehicles that do not have an on-board system. Vehicles that do not have an on-board system are detected as dynamic objects.

[0031] (Hardware Configuration of In-Vehicle System) Referring to Figure 2, an example of the hardware configuration of the in-vehicle system 100 mounted on the vehicle 102 is shown. The in-vehicle system 100 includes a communication unit 120, an in-vehicle gateway 122, a sensor 124, an autonomous driving ECU 126, an ECU 128, a presentation unit 130, and a bus 132. Note that the in-vehicle system 100 includes multiple ECUs in addition to the autonomous driving ECU 126, and Figure 2 shows ECU 128 as a representative of these.

[0032] The communication unit 120 performs wireless communication with devices external to the vehicle 102 (for example, communication with the infrastructure sensor 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 communication function with a global navigation satellite system (GNSS) such as the global positioning system (GPS). The communication unit 120 may also have a communication function such as Wi-Fi.

[0033] The in-vehicle gateway 122, which is an in-vehicle device, plays a role in connecting communication functions (specifically, communication specifications) with communication functions within the vehicle (such as communication protocol conversion). The autonomous driving ECU 126 can communicate with external devices via the in-vehicle gateway 122 and the communication unit 120. The in-vehicle gateway 122 acquires, for example, dynamic information from information received from the outside via the communication unit 120, and generates and updates driving assistance information. The driving assistance information is transmitted to the autonomous driving ECU 126. The bus 132 handles communication functions within the vehicle, and communication (data exchange) between the in-vehicle gateway 122, the sensor 124, the autonomous driving ECU 126, and the ECU 128 is performed via the bus 132. For example, a CAN (Controller Area Network) is used as the bus 132.

[0034] The sensors 124 are mounted on the vehicle 102 and include sensors for acquiring information outside the vehicle 102 (video image capturing devices (e.g., digital cameras (CCD (Charge-Coupled Device) cameras and CMOS (Complementary Metal-Oxide Semiconductor) cameras)), laser sensors (LiDAR), etc.)), and sensors for acquiring information about the vehicle itself (acceleration sensors, load sensors, etc.). The sensors 124 acquire information within their detection ranges (imaging ranges in the case of cameras) and output it as sensor data. In the case of digital cameras, they output digital image data. The detection signals (analog or digital) of the sensors 124 are output as digital data to the bus 132 via an I / F unit (not shown) and transmitted to the in-vehicle gateway 122, the autonomous driving ECU 126, etc.

[0035] The autonomous driving ECU 126 controls the driving of the vehicle 102. For example, the autonomous driving ECU 126 acquires sensor data, analyzes it to understand the situation around the vehicle, and controls mechanisms related to autonomous driving (mechanisms such as the engine, transmission, steering, and brakes). The autonomous driving ECU 126 uses driving assistance information acquired from the in-vehicle gateway 122 for autonomous driving.

[0036] The presentation unit 130 is a device for presenting information, and is an image display device such as a liquid crystal display. The presentation unit 130 may also include an audio device. The presentation unit 130 displays a road map or the like and presents driving assistance information, such as a driving route to a destination and route guidance information, superimposed on the map.

[0037] (Hardware Configuration of Vehicle Gateway) Referring to FIG. 3 , the vehicle gateway 122 includes a control unit 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 the program executed by the control unit 140. The control unit 140 acquires data to be processed directly from the communication unit 120 and acquires data from sources other than the communication unit 120 via the bus 132. The control unit 140 stores data received from the communication unit 120 and 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.

[0038] (Hardware Configuration of Server) Referring to FIG. 4 , the server 116 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 sensor data uploaded from infrastructure sensors 104 and the like installed on the road via the base station 108. The data received by the communication unit 164 is transmitted to and stored in the memory 162. This allows the server 116 to generate traffic information (e.g., information on accidents, congestion, road regulations, and statistical information) and dynamic information, and transmit the information to the in-vehicle system 100 of the vehicle 102.

[0039] Referring to FIG. 5 , the software configuration for realizing the functions of the server 116 and the in-vehicle system 100 is shown. (Server Software Configuration) The software (i.e., programs) in the server 116 is composed of three layers: an upper layer, a middle layer, and a lower layer. The upper layer shows multiple applications (i.e., programs) that generate data used for vehicle services (such as automatic driving control and provision of driving assistance information). These applications are executed by the control unit 160 of the server 116, and the generated data is classified based on the time between the occurrence of an event and the provision of the information. That is, three applications are executed, one for generating real-time data, one for generating near-real-time data, and one for generating non-real-time data. Real-time, near-real-time, and non-real-time mean, for example, that an event can be effectively used for some service within a few hundred milliseconds, between a few hundred milliseconds and 10 seconds, and between 10 seconds and tens of minutes, respectively, after the event occurs.

[0040] Real-time data generation is a process of generating dynamic information. As described above, dynamic information is information about each dynamic object, i.e., information including the position, movement direction, speed, and attributes of traffic participants (pedestrians, vehicles, etc.) on the road. Near-real-time data generation is, for example, a process of generating predictive information. The predictive information is a predicted value t seconds from now of a traffic participant identified by the dynamic information (i.e., dynamic information t seconds from now). Non-real-time data generation is, for example, a process of generating statistical information. The statistical information is information such as the number of traffic participants and their movement speed (average speed, etc.). By transmitting this data to the vehicle, the vehicle's driving can be controlled safely and accurately. Note that the generated data may be other than dynamic information, predictive information, and statistical information.

[0041] The middle layer is composed of an intermediary unit (hereinafter referred to as a server intermediary unit) that mediates between the upper layer (each application) and the lower layer (communication unit). The server intermediary unit is executed by the control unit 160 of the server 116. The server intermediary unit identifies an application that can appropriately use each piece of information generated in the upper layer in the destination vehicle (specifically, the in-vehicle system) and periodically transmits (e.g., broadcasts) the information to the vehicle. Because delays occur due to transmission and processing in the vehicle, the data (i.e., information) generated by the application in the upper layer may be configured to be used in different ways in the vehicle depending on its type (i.e., used by different applications).

[0042] The lower-layer communication unit is composed of the communication unit 164 shown in Fig. 4 and a device driver (software) for operating it. The server intermediary unit operates the communication unit 164 using the device driver, and communicates with the base station 108, infrastructure sensor 104, and in-vehicle system 100 (specifically, communication unit 120) of the vehicle 102 shown in Fig. 1.

[0043] (Software Configuration of In-Vehicle System) The software configuration of the in-vehicle system 100 is composed of three layers: an upper layer, a middle layer, and a lower layer. In the upper layer, applications realized by multiple ECUs (hardware) are shown as the first to third ECUs. The first to third ECUs (applications) shown in Figure 5 are, for example, an application for controlling the sensor 124 shown in Figure 2, an application for the autonomous driving ECU 126, an application for motor control, or a combination thereof.

[0044] The applications in the upper layer are intended to realize services such as driving assistance, driving plans, and route selection, for example. Driving assistance is a service that updates information (including acceleration) related to the vehicle's speed and performs automatic driving control using the information. Driving planning is a service that updates information related to the vehicle's driving lane and performs automatic driving control using the information. Route selection is a service that updates information related to the vehicle's driving route and performs automatic driving control based on the information. These applications are executed in cooperation with the automatic driving ECU 126, ECU 128, etc., as described above. These applications enable safe and accurate control of vehicle driving. Note that the applications in the upper layer may also be intended to realize services other than driving assistance, driving plans, and route selection.

[0045] The middle layer is composed of an intermediation unit (hereinafter referred to as an in-vehicle intermediation unit) that mediates between the first to third ECUs (applications) in the upper layer and the lower layer (communication unit). The in-vehicle intermediation unit is executed by the in-vehicle gateway memory 142. As will be described later, the in-vehicle intermediation unit processes data received from the server 116 and provides it to the upper layer application either directly or after converting it as appropriate.

[0046] The lower-layer communication unit is configured by the communication unit 120 shown in Fig. 2 and a device driver for operating it. The in-vehicle intermediation unit uses the device driver to operate the communication unit 120 and communicates with the server 116 (specifically, the communication unit 164).

[0047] 6 provides an overview of a series of processes performed by the configuration shown in Fig. 5, from data (e.g., sensor data) collection by the server 116 to use of the data in the in-vehicle system 100. In Fig. 6, the horizontal axis represents time, and downward arrows indicate the timing at which an event occurred. Note that Fig. 6 is intended to show the time before and after an event, and the scale of the time axis is not constant, and the length along the time axis is not proportional to time.

[0048] At time T0, data is generated. That is, the infrastructure sensor 104, an on-board sensor, or the like starts generating sensor data (e.g., video data). At time T1, collection of sensor data starts. That is, the infrastructure sensor 104, an on-board sensor, or the like sends sensor data (e.g., video data) to the server 116, and the server 116 stores the received data in the memory 162. At time T2, collection of data is completed. That is, transmission of data generated at time T0 to the server 116 and storage in the memory 162 is completed. The period from time T0 to time T2 is called the collection time.

[0049] At time T3, server 116 starts analyzing the received data and completes the analysis at time T4. The analysis results are stored in memory 162. The period from time T2 to time T4 is referred to as the analysis time. At time T4, server 116 reads out the analysis results from memory 162 and starts distributing (e.g., broadcasting) them to vehicles, completing the distribution at time T6. The period from time T4 to time T6 is referred to as the distribution time. During the distribution time, for example, in-vehicle system 100 receives the data to be distributed.

[0050] The period from time T0 to time T6 is called the elapsed time. Elapsed time = collection time + analysis time + distribution time. The difference between time T0 and time T1, the difference between time T2 and time T3, and the difference between time T4 and time T5 indicate that there may be a slight interval between the completion of the previous process and the execution of the next process. These differences may be zero. In other words, the next process may start simultaneously (including almost simultaneously) with the completion of the previous process.

[0051] After the distribution is completed at time T6, at time T7, the in-vehicle system 100 performs data lifespan management, which will be described later, on the received data. Data lifespan management is a process that determines whether the received data can be used effectively, and if it cannot be used effectively, performs appropriate processing, as will be described later. Data lifespan management is completed at time T8. The period from time T6 to time T8 is called the data lifespan management time. Thereafter, at time T9, the process of transferring the received data to the ECU (hereinafter referred to as the end ECU) that will use the data is started. Thereafter, the transfer is completed at time T10. The period from time T8 to time T10 is called the transfer delay.

[0052] Even if the data transfer is completed at time T10, it usually takes some time for the data to be used by the end ECU. For example, when the end ECU uses the transferred data for driving control, the end ECU uses the transferred data when the vehicle 102 approaches the location where the original data (i.e., the data received from the server 116) was generated. Therefore, during the time it takes for the vehicle 102 to reach the location where the data was generated, the end ECU retains the transferred data without using it (for example, stores it in memory) and waits for the data to be used. At time T11, the end ECU begins using the transferred data. The period from time T10 to time T11 is called the standby time.

[0053] The period from time T6 to time T11 is called the estimated time. Estimated time = data lifespan management time + transfer delay + waiting time. The difference between times T6 and T7 and the difference between times T8 and T9 indicate that there may be a slight interval between the completion of the previous process and the execution of the next process, as described above. The difference between these may be zero.

[0054] (Server Operation) The operation of the server 116, i.e., data collection, analysis, and distribution to the vehicle, will be described with reference to Figure 7. The process shown in Figure 7 is realized by the control unit 160 of the server 116 shown in Figure 4 reading and executing a predetermined program from the memory 162. The process shown in Figure 7 corresponds to the respective upper-layer and middle-layer software shown in Figure 5, and multiple programs are executed in parallel. That is, the control unit 160 reads multiple programs from the memory 162 and executes them in a multitasking manner.

[0055] In step 300, the control unit 160 collects data (sensor data, etc.) transmitted from the infrastructure sensors 104, the vehicle 102, the other vehicles 112, etc. Then, control proceeds to step 302. Specifically, the control unit 160 receives data via the communication unit 164 and stores the received data in the memory 162. At this time, the control unit 160 adds time information to the received data (e.g., sensor data). If the received sensor data includes information on the time of generation of the sensor data (i.e., the time detected by the sensor), the control unit 160 adds the time of generation as the time information. If the sensor data does not include a time of generation, the control unit 160 adds the time of reception of the data by the communication unit 164 as the time information.

[0056] In step 302, the control unit 160 reads the data collected in step 300 from the memory 162, analyzes it, and stores the analysis results in the memory 162. The analysis is performed in parallel by each application in the upper layer shown in FIG. 5. Therefore, the same data may be the subject of analysis by different applications. Then, control proceeds to step 304.

[0057] In step 304, the control unit 160 reads the analysis results from step 302 from the memory 162, adds information identifying the application of the vehicle to which the analysis results are sent, and transmits (e.g., broadcasts) the results as driving assistance information. Control then proceeds to step 306. The analysis results may be, for example, dynamic information, prediction information, or statistical information. As described above, the application (i.e., service) that can be appropriately used in the vehicle to which the analysis results are sent varies depending on the type of analysis result. Therefore, the control unit 160 identifies the application in the vehicle to which the information is to be transmitted based on the type of analysis result read from the memory 162, adds the identification information (i.e., service-specific information), and transmits the analysis results. The vehicle application is, for example, for implementing driving assistance, driving planning, and route selection services. When transmitting to a specific vehicle, the address (MAC address or IP address) of the destination ECU and the destination port number can be used as the service-specific information. When transmitting by broadcast, the destination port number can be used as the service-specific information. Alternatively, a unique ID previously determined between the server 116 and the in-vehicle system 100 may be used.

[0058] In step 306, the control unit 160 determines whether an instruction to terminate has been received. The instruction to terminate is given, for example, by operating a keyboard or mouse operation unit (not shown) provided on the server 116. If it is determined that the program should be terminated, the program ends. If not, control returns to step 300, and the above processing is repeated.

[0059] (Functional Configuration of the Vehicle Gateway) The functions of the vehicle gateway 122 will be described with reference to Fig. 8. The vehicle system 100 acquires driving assistance information such as dynamic information from the server 116.

[0060] The vehicle gateway 122 includes a memory unit 200, a real-time requirement determination unit 202, an elapsed time calculation unit 204, an estimated time calculation unit 206, an availability determination unit 208, a data conversion unit 210, and an output unit 212. The memory unit 200 is implemented by the memory 142 in FIG. 3 . Other functions, described later, are implemented by the control unit 140. With respect to the configuration shown in FIG. 5 , the real-time requirement determination unit 202, the elapsed time calculation unit 204, the estimated time calculation unit 206, the availability determination unit 208, and the data conversion unit 210 are functions of a mid-level vehicle intermediary unit. The memory unit 200 stores analysis results (e.g., dynamic information, forecast information, and statistical information) and road map information. The road map information is, for example, pre-stored static information. The analysis results are data received from the server 116 by the communication unit 120. Note that the analysis results are not classified and stored. The real-time requirement determination unit 202, the elapsed time calculation unit 204, the estimated time calculation unit 206, and the availability determination unit 208 read the same data (analysis results) from the storage unit 200 and use them as the target of processing.

[0061] The real-time requirement determination unit 202 reads data stored in the storage unit 200 (specifically, any one of dynamic information, prediction information, and statistical information) and identifies the real-time requirement of the data. The storage unit 200 outputs the identified real-time requirement to the availability determination unit 208. The real-time requirement represents the allowable delay time from when the data (i.e., sensor data, etc.) that is the source of the data is generated (or acquired) until it is appropriately used in the vehicle (hereinafter referred to as the allowable delay). The real-time requirement is determined, for example, as shown in Table 1.

[0062]

[0063] The real-time requirement level may be determined in advance between the server 116 and the in-vehicle system 100. The server 116 can transmit driving assistance information (analysis results) with a predetermined ID indicating the real-time requirement level, so the real-time requirement level determination unit 202 can identify the real-time requirement level from the ID. This allows the real-time requirement level to be determined with high accuracy. For example, as shown in Table 2, the real-time requirement levels A to C are identified depending on the type of data.

[0064]

[0065] The real-time requirement determination unit 202 may also determine the real-time requirement level from the service to which the data received from the server 116 is applied (i.e., the application that delivers the received data). The service to which the received data is applied can be identified by the destination port number. This makes it easy to determine the real-time requirement level. The real-time requirement determination unit 202 (i.e., the in-vehicle intermediation unit) may also determine the real-time requirement level by observing the update period of the applied service (i.e., the operation period of the processing units (including software and hardware) in the in-vehicle system 100 and the server 116 related to the applied service). For example, as shown in Table 3, real-time requirements A to C are determined according to the applied service.

[0066]

[0067] In addition, if the target service processes multiple types of data, even if the target service can be identified, the real-time requirement level cannot be determined. In such a case, the real-time requirement level determination unit 202 may analyze the data received from the server 116 (for example, by analyzing the data format and data structure), identify the type of data, and determine the real-time requirement level.

[0068] The real-time requirement determination unit 202 may also determine the real-time requirement according to the type of data and the service to which it is applied, as described above. For example, as shown in Table 4, real-time requirements A to C are determined according to the combination of the type of data and the service to which it is applied.

[0069]

[0070] The elapsed time calculation unit 204 calculates the elapsed time related to the analysis result data (specifically, the dynamic information, the prediction information, and the statistical information) stored in the storage unit 200. The storage unit 200 outputs the calculated elapsed time to the availability determination unit 208. As described above, the elapsed time is the time from the generation of the data (time T0 shown in FIG. 6 ) to the completion of distribution of the analysis result data by the server 116 (time T6 shown in FIG. 6 ). For example, if the server 116 transmits the analysis result data with the time T0 attached thereto, the in-vehicle system 100 can calculate the elapsed information as the difference between the reception time of the data and the time T0 attached to the received data. Note that the information on time T0 may be attached to the sensor data by a device that transmits the sensor data, such as the infrastructure sensor 104, and transmitted to the server 116.

[0071] The estimated time calculation unit 206 calculates an estimated time for the analysis result data (specifically, dynamic information, prediction information, and statistical information) stored in the storage unit 200. The storage unit 200 outputs the calculated estimated time to the availability determination unit 208. As described above, the estimated time is the time from when the in-vehicle system 100 completes receiving the analysis result data from the server 116 (time T6 shown in FIG. 6 ) to when usage begins (time T11 shown in FIG. 6 ). The estimated time is determined at time T11, but is undetermined immediately after the in-vehicle system 100 receives the data from the server 116 (time T6 shown in FIG. 6 ). Therefore, the in-vehicle system 100 (in-vehicle gateway 122) calculates, i.e., estimates, the estimated time during the data life management time.

[0072] The estimated time includes the data lifespan management time, the transfer delay, and the standby time. The transfer delay is the time required to read the data to be transferred from the storage unit 200 and transfer it to the end ECU via the bus 132. It can be calculated based on the size of the data to be transferred and the current state (idleness and transfer speed) of the bus 132. The standby time is the time required for the vehicle 102 to travel from its current location to a location (included in the analysis result data) where the analysis result data will be used. The location where the analysis result data will be used can be determined, for example, from the location information of a dynamic object included in the dynamic information. Therefore, the distance from the current location of the vehicle 102 to the location where the analysis result data will be used can be calculated, and the standby time can be calculated by dividing the calculated distance by the speed of the vehicle 102 (for example, the current speed or the average speed over a predetermined period of time in the past).

[0073] The data lifetime management time includes the time required for the in-vehicle gateway 122 to calculate the transfer delay and standby time, as well as the time required for the in-vehicle gateway 122 to determine whether the in-vehicle system 100 can effectively use the received data (the function of the availability determination unit 208), as described below. These times can be predicted in advance based on the processing performance of the in-vehicle gateway 122, the number of processing steps, the processing time of each step, etc. Therefore, a predetermined value (i.e., a predetermined time) is used for the data lifetime management time. That is, the estimated time is calculated as follows: Estimated time = Transfer delay + Standby time + Predetermined time. Alternatively, a statistical value calculated from a set of processing times obtained by executing the corresponding process multiple times (e.g., actual measured values ​​of past processes) may be used for the data lifetime management time. Examples of the statistical value that can be used include the mean, median, or a value determined from a cumulative distribution function (CDF). Note that a statistical value may also be used for the transfer delay.

[0074] The availability determination unit 208 determines whether the data received from the server 116 (i.e., the analysis results) can be effectively used. Specifically, the availability determination unit 208 uses the real-time requirement level (specifically, the allowable delay td) input from the real-time requirement level determination unit 202, the elapsed time tp input from the infrastructure sensor 104, and the estimated time tf input from the estimated time calculation unit 206 to determine whether tp + tf < td holds. That is, the availability determination unit 208 determines whether the received data can be used before the allowable delay that allows effective use of the data has elapsed. If it is determined that tp + tf < td holds, the availability determination unit 208 outputs the target data to the output unit 212 along with information identifying the destination end ECU. The output unit 212 transfers the input data to the target ECU (end ECU). If tp + tf < td does not hold (i.e., tp + tf ≧ td), the availability determination unit 208 outputs the target data and the real-time requirement level to the data conversion unit 210.

[0075] The data conversion unit 210 lowers the input real-time requirement by one level, converts the input data to match the lowered real-time requirement, and outputs the converted data to the output unit 212 along with information identifying the destination end ECU. For example, if the input real-time requirement is dynamic information (real-time requirement = A), the data conversion unit 210 generates predicted information (real-time requirement = B). If the input real-time requirement is predicted information (real-time requirement = B), the data conversion unit 210 generates statistical information (real-time requirement = C). At this time, the data conversion unit 210 may appropriately change the destination end ECU of the converted data depending on the lowered real-time requirement. The output unit 212 transfers the input data to the target ECU (end ECU). If the input real-time requirement is at the lowest level and cannot be lowered, the data conversion unit 210 discards the target data.

[0076] As a result, the in-vehicle system 100 can effectively use the data (i.e., analysis results) received from the server 116 for driving control (e.g., automatic driving control, etc.) of the vehicle (i.e., vehicle 102) and for presenting driving assistance information (e.g., route guidance).

[0077] Even if the received data cannot be used as is, the in-vehicle system 100 converts it into usable data and uses it. Therefore, it is possible to prevent data transmission from the server 116 and data reception by the in-vehicle system 100 from going to waste. Furthermore, since data that cannot be used effectively is discarded, it is possible to prevent the waste of storing unused data.

[0078] As described above, the received data is used by the ECU installed in the vehicle 102. The estimated time calculation unit 206 (see FIG. 8 ) can calculate the estimated time by adding a transfer delay, which is the time required to transfer the received data to the ECU, a waiting time, which is the time from when the transfer of the received data is completed until the vehicle reaches a location where the received data is used, and a predetermined time. The predetermined time represents the sum of the processing time by the real-time requirement determination unit 202, the processing time by the elapsed time calculation unit 204, and the processing time by the availability determination unit 208. This allows the in-vehicle gateway 122 to use the received data (e.g., driving assistance information) more effectively.

[0079] (Operation of the Vehicle Gateway) With reference to Fig. 9, the operation of the vehicle gateway 122 will be described with reference to the functions shown in Fig. 8. The process shown in Fig. 9 is realized by the control unit 140 (see Fig. 3) reading and executing a predetermined program from the memory 142.

[0080] 9 , in step 400, the control unit 140 determines whether or not data (i.e., driving assistance information) has been received from the server 116. If it is determined that data has been received, the control proceeds to step 402. If not, the control proceeds to step 418.

[0081] In step 402, the control unit 140 determines the real-time requirement level for the data received in step 400. That is, the control unit 140 determines the real-time requirement level based on at least one of the service to which the data is applied and the type of data, as described above with respect to the real-time requirement level determination unit 202 shown in FIG. 8. Thereafter, control proceeds to step 404.

[0082] In step 404, the control unit 140 calculates the elapsed time for the received data. That is, the control unit 140 calculates the time from the generation of the original data to the reception of the data generated from the original data, as described above with respect to the elapsed time calculation unit 204 shown in FIG. 8, and sets this as the elapsed time. Thereafter, control proceeds to step 406.

[0083] In step 406, the control unit 140 calculates an estimated time for the received data. That is, the control unit 140 calculates the time from when the data is received until when usage begins, as described above with respect to the estimated time calculation unit 206 shown in FIG. 8, and sets this as the estimated time. Thereafter, control proceeds to step 408.

[0084] In step 408, the control unit 140 determines whether the data received in step 400 is effectively available for use in the host vehicle. That is, as described above with respect to the availability determination unit 208 shown in FIG. 8 , the control unit 140 determines whether tp + tf < td using the real-time requirement (specifically, the allowable delay td), elapsed time tp, and estimated time tf determined in steps 402 to 406. If it is determined that tp + tf < td, control proceeds to step 410. Otherwise, control proceeds to step 412.

[0085] In step 410, the control unit 140 transfers the data to be transferred to the end ECU that executes the service to which the data is applied. The data to be transferred is the data received in step 400 or the data converted in step 416, which will be described later. Then, control proceeds to step 418.

[0086] If the determination result in step 408 is NO (i.e., tp+tf≧td), in step 412, the control unit 140 determines whether the real-time requirement specified in step 402 is at the lowest level. For example, if the real-time requirement is defined as shown in Table 1, it determines whether the real-time requirement is C. If it is determined to be at the lowest level, control proceeds to step 414. If not, control proceeds to step 416.

[0087] In step 414, the control unit 140 discards the data received in step 400. That is, since the received data cannot be effectively used, the control unit 140 discards it without storing it in the memory 142. Thereafter, control proceeds to step 418.

[0088] In step 416, the control unit 140 converts the received data from step 406. That is, the control unit 140 reduces the real-time requirement of the received data by one level, as described above with respect to the data conversion unit 210 shown in FIG. 8, and converts the received data to match the reduced real-time requirement. Thereafter, control proceeds to step 410.

[0089] In step 418, the control unit 140 determines whether an instruction to end the program has been received. The instruction to end the program is given, for example, by turning off the start button of the vehicle 102. If it is determined that the program should be ended, the program ends. If not, control returns to step 400, and the above process is repeated.

[0090] As described above, the in-vehicle system 100 can effectively use the data received from the server 116 for controlling the driving of the vehicle (e.g., automatic driving control) and presenting driving assistance information (e.g., route guidance). Even if the received data cannot be used as is, the in-vehicle system 100 converts it into usable data and uses it. Therefore, it is possible to prevent data transmission from the server 116 and data reception by the in-vehicle system 100 from being wasted.

[0091] In the above, the case where control proceeds to step 410 after step 416 has been described, but this is not limiting. After step 416, control may proceed to step 408 instead of step 410. That is, it may be determined whether or not the data after the real-time requirement level has been changed can be effectively used by the host vehicle. For example, if the allowable delay is not satisfied when the real-time requirement level is lowered by one level from A to B and the data is converted, it is necessary to further lower the real-time requirement level from B to C and convert the data.

[0092] (Modification) In the above, a case has been described in which the in-vehicle system 100 mounted on the vehicle 102 determines whether or not the driving assistance information received from the server 116 can be effectively used, but this is not limiting. In a modification, before transmitting the driving assistance information, the server identifies a vehicle to which the driving assistance information can be effectively used and transmits the information.

[0093] The server according to the modified example has the same configuration as the server 116 shown in Fig. 4. In the following, the server 116 will be referred to as the server according to the modified example and the reference numerals in Fig. 4 will be referred to. The functions of the server 116 will be described with reference to Fig. 10. The storage unit 500 shown in Fig. 10 is realized by the memory 162 in Fig. 4. Other functions, which will be described later, are realized by the control unit 160.

[0094] The storage unit 500 stores sensor data received from the infrastructure sensors 104 and the like via the communication unit. The road map information is, for example, static information stored in advance. The storage unit 500 also stores the analysis results obtained by the analysis unit 502, which will be described later.

[0095] The analysis unit 502 reads out the sensor data stored in the storage unit 500, performs analysis, and stores the results (i.e., analysis results) in the storage unit 500. The analysis results may include, for example, dynamic information, prediction information, and statistical information.

[0096] The vehicle identification unit 504 identifies a vehicle to which the analysis results are to be transmitted, outputs the analysis results to the communication unit 164, and transmits them to the identified vehicle. The vehicle identification unit 504 identifies vehicles located within a predetermined area (e.g., rectangular or circular) centered on the point where the sensor data on which the analysis results are based is generated as the vehicle to which the analysis results are to be transmitted. That is, the vehicle identification unit 504 transmits the analysis results to vehicles that satisfy the real-time requirement of the analysis results, i.e., vehicles that can reach the point where the sensor data is generated within the allowable delay. For example, the predetermined area can be determined by referencing a road map stored in the storage unit 500 and multiplying the speed of vehicles surrounding the point where the sensor data is generated by the allowable delay (e.g., upper limit) of the analysis results, and using the resulting value (i.e., distance) as the distance from the point where the sensor data is generated to the outer edge of the predetermined area. For example, the legal speed limit or the average value of observed vehicle speeds may be used as the vehicle speed. The distance from the point where the sensor data is generated to the outer edge of the predetermined area may be a straight-line distance or a distance along the road. To identify the on-board devices of vehicles within a predetermined area, for example, a command to transmit the location information of the vehicle may be broadcast. The location information returned from the vehicle may be used to identify the vehicle that will transmit the analysis results.

[0097] To identify the location where the sensor data was generated, the location coordinates where the sensor data was detected may be added to the sensor data transmitted by the infrastructure sensor 104 or the like, and the data may be transmitted to the server 116. For a fixedly installed sensor such as the infrastructure sensor 104, if its location is registered in advance in the storage unit 500, information identifying the sender may be added to the sensor data before transmission. For example, if the storage unit 500 stores a table that associates MAC addresses with location coordinates, the sender may be identified by the MAC address of the sender included in a transmission packet containing the sensor data, and the location where the sensor data was generated may be identified.

[0098] The data conversion unit 506 converts the analysis result (e.g., dynamic information) into data corresponding to the reduced real-time requirement by lowering the real-time requirement. For example, if dynamic information (real-time requirement = A) is generated as the analysis result and the data conversion unit 506 lowers the real-time requirement by one level, prediction information (real-time requirement = B) is generated from the dynamic information. For the prediction information (real-time requirement = B), statistical information (real-time requirement = C) is generated from the prediction information. The data generated with the reduced real-time requirement is input to the vehicle identification unit 504. The vehicle identification unit 504 identifies the vehicle to which the input data (data generated with the reduced real-time requirement) is to be transmitted, as described above, using the allowable delay corresponding to the input data, and outputs the data to the communication unit. That is, the data generated with the reduced real-time requirement is transmitted to the on-board device of a vehicle located within the newly identified predetermined area.

[0099] For example, as shown in FIG. 11 , the range in which the analysis results are transmitted can be determined depending on the type of data in the analysis results. In FIG. 11 , the traveling direction of each vehicle is indicated by an arrow. The server 116 transmits dynamic information (real-time requirement level = A) to vehicles 102a and 102b located in an area defined by a thick solid boundary 180, with the data generation point 902 at the center. The server 116 transmits predicted information (real-time requirement level = B) to vehicles 102c to 102f located in an area defined by the boundary 180 and a thick solid boundary 182. The server 116 transmits statistical information (real-time requirement level = C) to vehicles located in other areas. Note that predicted information and statistical information may be transmitted to vehicles 102a and 102b in addition to the dynamic information. Statistical information may be transmitted to vehicles 102c to 102f in addition to the predicted information.

[0100] This allows the server 116 to transmit driving assistance information only to vehicles that can effectively use it, and prevents unnecessary transmission to vehicles that cannot effectively use it. In the vehicle, the received data can be quickly transferred to the application service (i.e., the end ECU) without determining whether the received driving assistance information can be effectively used. Therefore, the load on the in-vehicle gateway 122 of the in-vehicle system 100 is reduced.

[0101] The server 116 reduces the real-time requirement of the analysis results (e.g., dynamic information), converts them into data corresponding to the reduced real-time requirement, and transmits the data to the vehicle, thereby enabling more vehicles to effectively use the driving assistance information.

[0102] Each process (each function) in the above-described embodiments may be realized by a processing circuit (circuitry) 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 each of the processes. The one or more processors may execute each of the processes according to the program read from the one or more memories, or according to a logic circuit designed in advance to execute each of the 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 processes. For example, the processors installed in 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 processes.

[0103] 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 wording described therein.

[0104] REFERENCE SIGNS LIST 100 In-vehicle system 102 Vehicle 104 Infrastructure sensor 108 Base station 112 Other vehicle 114 Network 116 Server 120, 164 Communication unit 122 In-vehicle gateway 124 Sensor 126 Autonomous driving ECU 128 ECU 130 Presentation unit 132, 166 Bus 140, 160 Control unit 142, 162 Memory 180, 182 Boundary 200, 500 Storage unit 202 Real-time requirement determination unit 204 Elapsed time calculation unit 206 Estimated time calculation unit 208 Availability determination unit 210, 506 Data conversion unit 212 Output unit 300, 302, 304, 306, 400, 402, 404, 406, 408, 410, 412, 414, 416, 418 Step 502 Analysis unit 504 Vehicle identification unit 900 Pedestrian 902 Occurrence point

Claims

1. An in-vehicle device mounted in a vehicle, a real-time requirement determination unit that determines a real-time requirement regarding data received from outside the vehicle; an elapsed time calculation unit that calculates an elapsed time that is a time from generation of original data of the received data to reception of the received data by the in-vehicle device; an estimated time calculation unit that calculates an estimated time that is a time from reception of the received data to start of use of the received data; an availability determination unit that determines availability of the received data based on the real-time requirement, the elapsed time, and the estimated time; the real-time requirement indicates an allowable delay time from generation of the original data to utilization of the received data; time information for identifying the time when the original data was generated is added to the received data; The elapsed time calculation unit calculates the elapsed time based on a reception time of the reception data and the time information.

2. the availability determination unit determines that the received data is unavailable if a sum of the elapsed time and the estimated time does not satisfy the real-time requirement; a data conversion unit that converts the received data into low-request data having a real-time requirement lower than the real-time requirement of the received data upon receipt of the determination that the data is unavailable by the availability determination unit, The in-vehicle device according to claim 1 , wherein the received data is discarded when the data conversion unit is unable to generate the low request data.

3. the received data is added with service identification information for identifying a service in which the received data is used; The in-vehicle device according to claim 1 , wherein the real-time requirement determination unit determines the real-time requirement based on the service identification information.

4. 3. The in-vehicle device according to claim 1, wherein the real-time requirement determination unit determines the real-time requirement based on at least one of a type of the received data and a service in which the received data is used.

5. The types include dynamic information, predictive information, and statistical information; The in-vehicle device according to claim 4 , wherein the services include driving assistance including control of a driving speed of the vehicle, a driving plan including control of a driving lane of the vehicle, and a route selection for controlling a planned driving route of the vehicle.

6. The received data is utilized by an electronic control unit mounted on the vehicle; the estimated time calculation unit calculates the estimated time by adding a transfer delay, which is a time required to transfer the received data to the electronic control unit, a waiting time, which is a time required for the vehicle to reach a position where the received data is used, and a predetermined time; 3. The in-vehicle device according to claim 1, wherein the predetermined time represents a total of a processing time by the real-time requirement determination unit, a processing time by the elapsed time calculation unit, and a processing time by the availability determination unit.

7. An in-vehicle system installed in a vehicle, The in-vehicle device according to claim 1 or 2, A communication unit that receives the received data; an electronic control unit to which the received data determined to be available by the in-vehicle device is transferred.

8. A communication unit that receives sensor data from an external device; An analysis unit that analyzes the sensor data and generates first driving assistance information; a vehicle identification unit that identifies a first vehicle that can arrive at a point where the sensor data is generated within a first allowable delay corresponding to a first real-time requirement level corresponding to the first driving assistance information, The communication unit further transmits the first driving assistance information to an in-vehicle device of the first vehicle.

9. A data conversion unit that generates, from the first driving support information, second driving support information corresponding to a second real-time demand degree obtained by lowering the first real-time demand degree, The vehicle identification unit further identifies a second vehicle that can reach the occurrence point within a second allowable delay corresponding to the second real-time requirement; The server computer according to claim 8 , wherein the communication unit is further configured to transmit the second driving assistance information to an in-vehicle device of the second vehicle.

10. A method for controlling an in-vehicle system including an in-vehicle device mounted in a vehicle, comprising: a real-time requirement determination step of determining a real-time requirement level for data received from outside the vehicle by an in-vehicle device; an elapsed time calculation step in which the in-vehicle device calculates an elapsed time that is a time from generation of original data of the received data to reception of the received data by the in-vehicle device; an estimated time calculation step in which the in-vehicle device calculates an estimated time that is a time from reception of the reception data to start of use of the reception data; an availability determination step of determining availability of the received data based on the real-time requirement, the elapsed time, and the estimated time, by the in-vehicle device; the real-time requirement indicates an allowable delay time from generation of the original data to utilization of the received data; time information for identifying the time when the original data was generated is added to the received data; The control method, wherein the elapsed time calculation step includes a step of an in-vehicle device calculating the elapsed time based on a reception time of the reception data and the time information.

11. The vehicle's on-board computer a real-time requirement determination function for determining a real-time requirement regarding data received from outside the vehicle; an elapsed time calculation function for calculating an elapsed time that is a time from generation of the original data of the received data to reception of the received data; an estimated time calculation function for calculating an estimated time from reception of the received data to start of use of the received data; an availability determination function for determining the availability of the received data based on the real-time requirement, the elapsed time, and the estimated time; the real-time requirement indicates an allowable delay time from generation of the original data to utilization of the received data; time information for identifying the time when the original data was generated is added to the received data; The elapsed time calculation function includes a function for calculating the elapsed time based on a reception time of the reception data and the time information.