In-vehicle device, in-vehicle 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

[Technical Field]

[0001] This disclosure relates to an in-vehicle device, an in-vehicle system, a server computer, a control method, and a computer program. 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 Japanese application. [Background technology]

[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 also progressing. 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 that can transfer 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 the 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. [Prior art documents] [Patent documents]

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

[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. [Brief explanation of the drawings]

[0006] [Figure 1] FIG. 1 is a schematic diagram showing a usage form of an in-vehicle system according to an embodiment of the present disclosure. [Figure 2] FIG. 2 is a block diagram showing the hardware configuration of the in-vehicle system shown in FIG. [Figure 3] FIG. 3 is a block diagram showing a hardware configuration of the vehicle gateway shown in FIG. [Figure 4] FIG. 4 is a block diagram showing a hardware configuration of the server shown in FIG. [Figure 5] FIG. 5 is a block diagram showing the software configuration of the in-vehicle system and the server. [Figure 6] FIG. 6 is a diagram showing the timing of processing from the generation of original data to its use as driving assistance information in a vehicle. [Figure 7] FIG. 7 is a flowchart showing the processing executed by the server. [Figure 8]FIG. 8 is a block diagram showing the functional configuration of the vehicle gateway. [Figure 9] FIG. 9 is a flowchart showing the processing executed by the vehicle gateway. [Figure 10] FIG. 10 is a block diagram showing a functional configuration of a server according to a modified example. [Figure 11] FIG. 11 is a schematic diagram showing information provided by the server shown in FIG. DETAILED DESCRIPTION OF THE INVENTION

[0007] [Problem to be solved by this disclosure] The transfer system disclosed in Patent Document 1 ensures the real-time nature of the transferred data by deleting non-real-time data. However, ensuring real-time nature also increases the amount of data wasted. Therefore, in the technology described in Patent Document 1, in a situation where data with different real-time natures are communicated, it is not possible to effectively utilize the data communicated for cooperative operation without wasting it.

[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] [Effects of this disclosure] According to the present disclosure, it is possible 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.

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

[0011] (1) An on-board device according to a first 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 level for received data received from outside the vehicle; an elapsed time calculation unit that calculates an elapsed time, which is the time from 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 reception of the received data 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, wherein the real-time requirement level represents an allowable degree of delay time from generation of the original data until 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 unit calculates the elapsed time based on the reception time and the time information of the received data. This allows the on-board 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 of unavailability 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, it is possible to reduce the waste of storing unused data.

[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, forecast 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, thereby enabling 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 total time 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) An in-vehicle system according to a second aspect of the present disclosure is an in-vehicle system mounted on a vehicle, and includes 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. This allows 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, and 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 it, and prevents unnecessary transmission to vehicles that cannot use it. The vehicle quickly transmits the received data to an application service (for example, an end ECU (Electronic Control Unit)) without determining whether the received data (driving assistance information) can be effectively used. on The information can be transmitted to an electronic control unit (IC Control Unit).

[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 requirement level that is a lower level than the first real-time requirement 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 requirement level, and the communication unit further transmits the second driving assistance information to the 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 until the received data is received 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 until use of the received data is started; and an availability determination step in which the in-vehicle device 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 allowable degree of delay time from generation of the original data until use of the received data, and time information for identifying the time when the original data was generated is added to the received data, 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 of the received data, thereby enabling the in-vehicle device to effectively use the received data (e.g., driving assistance information).

[0021] (11) The first part of this disclosure 5 The computer program according to the aspect 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 the 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 the time from reception of the received data to start of use of the received data, and a usability determination function that determines the possibility of use 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 allowable degree of delay time from generation of the original data to use of the received data, time information for specifying 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 the 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, so detailed descriptions thereof will not be repeated.

[0023] (Overall composition) 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, for example, via 4G and 5G lines. 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 and 5G lines, 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 the roadside) and has the 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 the base station 108 and transmits acquired sensor data to the server 116 via the base station 108 and the network 114.

[0026] 1 are detection targets of the infrastructure sensor 104. The vehicle 102 is equipped with a sensor as will be described later. 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 as driving assistance information to an in-vehicle device mounted on the vehicle.

[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 objects that have the ability to move but are stationary. 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, moving speed, moving 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] FIG. 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 on-board systems. Vehicles that do not have on-board systems are detected as dynamic objects.

[0031] (Hardware configuration of in-vehicle system) 2, an example of the hardware configuration of an in-vehicle system 100 mounted on a 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 FIG. 2 shows ECU 128 as a representative of these.

[0032] The communication unit 120 performs wireless communication with external devices of 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 function of communicating with a global navigation satellite system (GNSS) such as a global positioning system (GPS). The communication unit 120 may also have a communication function such as Wi-Fi.

[0033] The in-vehicle gateway 122, which is an in-vehicle device, plays a role in connecting communication functions (specifically, communication specifications) with the outside of the vehicle and communication functions (communication specifications) 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 is responsible for 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 for 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 (for example, 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 are then 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 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 thereon.

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

[0038] (Server hardware configuration) 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), dynamic information, and the like, 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 the 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 that generate real-time data, near-real-time data, and 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 several hundred milliseconds, between several hundred milliseconds and 10 seconds, and between 10 seconds and several 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 predicted information. The predicted 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, predicted 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 so that its usage in the vehicle changes depending on its type (i.e., it may be 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 systems) 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 a plurality of ECUs (hardware) are shown as the first to third ECUs. The first to third ECUs (applications) shown in Fig. 5 are, for example, an application for controlling the sensor 124 shown in Fig. 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 intermediary unit (hereinafter referred to as an in-vehicle intermediary unit) that mediates between the first to third ECUs (applications) in the upper layer and the lower layer (communication unit). The in-vehicle intermediary unit is executed by the in-vehicle gateway memory 142. As will be described later, the in-vehicle intermediary unit performs processing to provide data received from the server 116 to the upper layer application either directly or after converting it as appropriate.

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

[0047] Fig. 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 its use 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 transmits sensor data (e.g., video data) to the server 116, and the server 116 stores the received data in 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 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 time 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. At time T8, the data lifespan management is completed. The period from time T6 to time T8 is called the data lifespan management time. Then, 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 begins. Then, at time T10, the transfer is completed. 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 to use the data. At time T11, the end ECU starts 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, as mentioned above, indicate that there may be a slight interval between the completion of the previous process and the execution of the next process. The difference between these may be zero.

[0054] (Server behavior) 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 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. After that, 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 information on the time of generation of the sensor data (i.e., the time detected by the sensor) is added to the received sensor data, the control unit 160 adds the time of generation as the time information. If the time of generation is not added to the sensor data, 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, control unit 160 reads the data collected in step 300 from memory 162, analyzes it, and stores the analysis results in 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, depending 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 realizing 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, 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 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 in-vehicle gateway) The function 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 storage 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 storage unit 200 is implemented by the memory 142 in FIG. 3. Other functions, which will be 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 storage 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. 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 out 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] [Table 1]

[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 the 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] [Table 2]

[0065] The real-time requirement determination unit 202 may also determine the real-time requirement 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. The real-time requirement determination unit 202 (i.e., the in-vehicle intermediation unit) may also determine the real-time requirement 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, the real-time requirement levels A to C are determined according to the applied service.

[0066] [Table 3]

[0067] In addition, if the target service processes multiple types of data, even if the target service can be identified, the real-time requirement degree cannot be identified. In such a case, the real-time requirement degree 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 degree.

[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 specified above. For example, as shown in Table 4, real-time requirement levels A to C are determined according to the combination of the type of data and the service to which it is applied.

[0069] [Table 4]

[0070] The elapsed time calculation unit 204 calculates the elapsed time related to 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 elapsed time to the availability determination unit 208. As described above, the elapsed time is the time from when the data is generated (time T0 shown in FIG. 6) until the server 116 completes distribution of the analysis result data (time T6 shown in FIG. 6). For example, if the server 116 transmits the analysis result data with time T0 attached, the in-vehicle system 100 calculates the elapsed time as the difference between the time when the data was received and the time T0 attached to the received data. time The information on time T0 may be attached to the sensor data by the device that is the source of 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 starts (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 lifespan 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 of the bus 132 (idleness and transfer speed). 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 vehicle gateway 122 to calculate the transfer delay and standby time, as well as the time required for the vehicle gateway 122 to perform a process (the function of the availability determination unit 208) to determine whether the vehicle system 100 can effectively use the received data, as described below. These times can be predicted in advance based on the processing performance of the vehicle gateway 122, the number of processing steps, the processing time of each step, and the like. 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. For example, the average, median, or a value determined from a cumulative distribution function (CDF) may be used as the statistical value. Note that a statistical value may also be used for the transfer delay.

[0074] The availability determination unit 208 determines whether the data (i.e., the analysis result) received from the server 116 can be effectively utilized. That is, the availability determination unit 208 uses the real-time requirement degree (specifically, the allowable delay td) input from the real-time requirement degree determination unit 202, the elapsed time tp input from the infra sensor 104, and the estimated time tf input from the estimated time calculation unit 206 to determine whether tp + tf < td. That is, it determines whether the utilization of the received data can be started before the allowable delay for effectively utilizing the data elapses. If it is determined that tp + tf < td, the availability determination unit 208 outputs the target data to the output unit 212 together with the information specifying the destination end ECU. The output unit 212 transfers the input data to the target ECU (end ECU). If tp + tf is not less than td (i.e., tp + tf ≥ td), the availability determination unit 208 outputs the target data and the real-time requirement degree to the data conversion unit 210.

[0075] The data conversion unit 210 reduces the input real-time requirement degree by one level, converts the input data according to the reduced real-time requirement degree, and outputs the converted data to the output unit 212 together with the information specifying the destination end ECU. For example, if it is dynamic information (real-time requirement degree = A), predictive information (real-time requirement degree = B) is generated. If it is predictive information (real-time requirement degree = B), statistical information (real-time requirement degree = C) is generated. At this time, the data conversion unit 210 may appropriately change the destination end ECU of the converted data according to the reduced real-time requirement degree. The output unit 212 transfers the input data to the target ECU (end ECU). If the input real-time requirement degree is at the lowest level and cannot be reduced, the data conversion unit 210 discards the target data.

[0076] As described above, the in-vehicle system 100 can effectively utilize the data (i.e., the analysis result) received from the server 116 for the driving control (e.g., autonomous driving control, etc.) of the host vehicle (i.e., vehicle 102) and the presentation of driving support 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. This prevents data transmission from the server 116 and data reception by the in-vehicle system 100 from going to waste. Furthermore, data that cannot be used effectively is discarded, preventing the waste of storing unused data.

[0078] As described above, the received data is used by the ECU mounted on 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 total time 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 in-vehicle gateway) With reference to Fig. 9, the operation of the in-vehicle gateway 122 will be described with reference to the functions shown in Fig. 8. The processing shown in Fig. 9 is realized by the control unit 140 (see Fig. 3) reading out a predetermined program from the memory 142 and executing it.

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

[0081] In step 402, the control unit 140 specifies the real-time requirement degree for the data received in step 400. That is, as described above regarding the real-time requirement degree determination unit 202 shown in FIG. 8, the control unit 140 specifies the real-time requirement degree based on at least either the applicable service or the type of data. After that, the control proceeds to step 404.

[0082] In step 404, the control unit 140 calculates the elapsed time for the received data. That is, as described above regarding the elapsed time calculation unit 204 shown in FIG. 8, 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, and uses it as the elapsed time. After that, the control proceeds to step 406.

[0083] In step 406, the control unit 140 calculates the estimated time for the received data. That is, as described above regarding the estimated time calculation unit 206 shown in FIG. 8, the control unit 140 calculates the time from the reception of the data to the start of its use, and uses it as the estimated time. After that, the control proceeds to step 408.

[0084] In step 408, the control unit 140 determines whether the data received in step 400 can be effectively used in the host vehicle. That is, as described above regarding the usability determination unit 208 shown in FIG. 8, the control unit 140 uses the real-time requirement degree (specifically, the allowable delay td), the elapsed time tp, and the estimated time tf determined in steps 402 to 406 to determine whether tp + tf < td. If it is determined that tp + tf < td, the control proceeds to step 410. Otherwise, the 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 applicable service of the data. The data to be transferred is the received data in step 400 or the data after being converted in step 416 described later. After that, the 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. Otherwise, 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, the control returns to step 400, and the above processing is repeated.

[0090] As described above, the in-vehicle system 100 can effectively use the data received from the server 116 for driving control of the vehicle (e.g., automatic driving control) and presentation of driving assistance information (e.g., route guidance). Even if the received data cannot be used as is, the in-vehicle system 100 converts the data into usable data for use. 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 proceeding to 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] (Variation) In the above description, 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 the present invention is not limited to this. In a modified example, 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 server 116 shown in Fig. 4. In the following, 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 server 116 will be described with reference to Fig. 10. Storage unit 500 shown in Fig. 10 is realized by memory 162 in Fig. 4. Other functions, which will be described later, are realized by 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 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. As the analysis results, for example, dynamic information, prediction information, and statistical information are stored.

[0096] The vehicle identification unit 504 identifies the 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 referring to 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 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 originated, 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 then 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 in which MAC addresses correspond to location coordinates, the sender can be identified by the MAC address of the sender included in the transmitted packet containing the sensor data, and the location where the sensor data originated can 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 data is to be transmitted, as described above, using the allowable delay corresponding to the input data (data generated with the reduced real-time requirement), 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 for transmitting the analysis results 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 request 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 request 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 request 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 implemented by a processing circuit including one or more processors. The processing circuit may be configured by an integrated circuit or the like that combines one or more memories, various analog circuits, and various digital circuits in addition to the one or more processors. The one or more memories store programs (instructions) that cause the one or more processors to execute the respective processes. The one or more processors may execute the respective processes according to the programs read from the one or more memories, or according to logic circuits pre-designed to execute the respective processes. The processor may be various processors suitable for computer control, such as a CPU, a GPU (Graphics Processing Unit), a DSP (Digital Signal Processor), an FPGA (Field Programmable Gate Array), and an ASIC (Application Specific Integrated Circuit). The physically separate processors may execute the respective processes in cooperation with each other. For example, the above-mentioned processors mounted on each of a plurality of physically separated computers may cooperate with each other via a network such as a LAN (Local Area Network), a WAN (Wide Area Network), or the Internet to execute the above-mentioned processes.

[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. [Explanation of symbols]

[0104] 100 In-Vehicle Systems 102 vehicles 104 Infrastructure Sensors 108 Base Station 112 Other vehicles 114 Network 116 servers 120, 164 Communications Department 122 In-vehicle gateway 124 sensors 126 Autonomous Driving ECU 128 ECU 130 Presentation section Buses 132 and 166 140, 160 control unit 142, 162 memory 180, 182 boundary 200, 500 storage section 202 Real-time requirement determination unit 204 Elapsed time calculation unit 206 Estimated time calculation unit 208 Availability determination section 210, 506 Data conversion unit 212 Output section 300, 302, 304, 306, 400, 402, 404, 406, 408, 410, 412, 414, 416, 418 steps 502 Analysis Department 504 Vehicle Identification Department 900 pedestrians 902 Location

Claims

1. An in-vehicle device mounted on a vehicle, 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 that is a time from generation of the original data of the received data until the received data is received by the in-vehicle device; an estimated time calculation unit that calculates an estimated time that is a time from when the received data is received until when use of the received data is started; 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 acceptable degree of delay time from generation of the original data until use of the received data; time information for specifying 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 the reception time of the reception data and the time information.

2. the availability determination unit determines that the received data is unavailable if the 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 in response to 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 specification information for specifying a service for which the received data is used, 3. 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 the 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 the driving speed of the vehicle, driving planning including control of the driving lane of the vehicle, and 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 mounted on a vehicle, an on-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 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.

9. a data conversion unit that generates, from the first driving assistance information, second driving assistance information corresponding to a second real-time requirement obtained by lowering the first real-time requirement, 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 requirement; The server computer according to claim 8 , wherein the communication unit further transmits the second driving assistance information to an in-vehicle device of the second vehicle.

10. A control method for an in-vehicle system including an in-vehicle device mounted in a vehicle, comprising: 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 that is a time from generation of the original data of the received data until the received data is received 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 when the received data is received until when use of the received data is started; 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 acceptable degree of delay time from generation of the original data until use of the received data; time information for specifying the time when the original data was generated is added to the received data; The control method, wherein the elapsed time calculating step includes a step in which an in-vehicle device calculates the elapsed time based on a reception time of the reception data and the time information.

11. The vehicle's onboard computer a real-time requirement determination function for determining a real-time requirement level for received data received from outside the vehicle; an elapsed time calculation function for calculating an elapsed time, which 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 the reception of the received data to the start of use of the received data; an availability determination function for determining availability of the received data based on the real-time requirement, the elapsed time, and the estimated time; the real-time requirement indicates an acceptable degree of delay time from generation of the original data until use of the received data; time information for specifying the time when the original data was generated is added to the received data; The computer program includes a function in which the elapsed time calculation function calculates the elapsed time based on the reception time of the received data and the time information.

Images