WO2023276435A1 - 車載装置、サーバ及びシステム - Google Patents

車載装置、サーバ及びシステム Download PDF

Info

Publication number
WO2023276435A1
WO2023276435A1 PCT/JP2022/019003 JP2022019003W WO2023276435A1 WO 2023276435 A1 WO2023276435 A1 WO 2023276435A1 JP 2022019003 W JP2022019003 W JP 2022019003W WO 2023276435 A1 WO2023276435 A1 WO 2023276435A1
Authority
WO
WIPO (PCT)
Prior art keywords
vehicle
server
unit
data
vehicle device
Prior art date
Application number
PCT/JP2022/019003
Other languages
English (en)
French (fr)
Inventor
明紘 小川
Original Assignee
住友電気工業株式会社
住友電装株式会社
株式会社オートネットワーク技術研究所
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by 住友電気工業株式会社, 住友電装株式会社, 株式会社オートネットワーク技術研究所 filed Critical 住友電気工業株式会社
Publication of WO2023276435A1 publication Critical patent/WO2023276435A1/ja

Links

Images

Classifications

    • G—PHYSICS
    • G08—SIGNALLING
    • G08G—TRAFFIC CONTROL SYSTEMS
    • G08G1/00—Traffic control systems for road vehicles
    • G08G1/09—Arrangements for giving variable traffic instructions
    • G—PHYSICS
    • G16—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR SPECIFIC APPLICATION FIELDS
    • G16Y—INFORMATION AND COMMUNICATION TECHNOLOGY SPECIALLY ADAPTED FOR THE INTERNET OF THINGS [IoT]
    • G16Y10/00—Economic sectors
    • G16Y10/40—Transportation
    • G—PHYSICS
    • G16—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR SPECIFIC APPLICATION FIELDS
    • G16Y—INFORMATION AND COMMUNICATION TECHNOLOGY SPECIALLY ADAPTED FOR THE INTERNET OF THINGS [IoT]
    • G16Y10/00—Economic sectors
    • G16Y10/75—Information technology; Communication
    • G—PHYSICS
    • G16—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR SPECIFIC APPLICATION FIELDS
    • G16Y—INFORMATION AND COMMUNICATION TECHNOLOGY SPECIALLY ADAPTED FOR THE INTERNET OF THINGS [IoT]
    • G16Y40/00—IoT characterised by the purpose of the information processing
    • G16Y40/10—Detection; Monitoring
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04M—TELEPHONIC COMMUNICATION
    • H04M11/00—Telephonic communication systems specially adapted for combination with other electrical systems
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04Q—SELECTING
    • H04Q9/00—Arrangements in telecontrol or telemetry systems for selectively calling a substation from a main station, in which substation desired apparatus is selected for applying a control signal thereto or for obtaining measured values therefrom
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04W—WIRELESS COMMUNICATION NETWORKS
    • H04W4/00—Services specially adapted for wireless communication networks; Facilities therefor
    • H04W4/30—Services specially adapted for particular environments, situations or purposes
    • H04W4/38—Services specially adapted for particular environments, situations or purposes for collecting sensor information
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04W—WIRELESS COMMUNICATION NETWORKS
    • H04W4/00—Services specially adapted for wireless communication networks; Facilities therefor
    • H04W4/30—Services specially adapted for particular environments, situations or purposes
    • H04W4/40—Services specially adapted for particular environments, situations or purposes for vehicles, e.g. vehicle-to-pedestrians [V2P]
    • H04W4/44—Services specially adapted for particular environments, situations or purposes for vehicles, e.g. vehicle-to-pedestrians [V2P] for communication between vehicles and infrastructures, e.g. vehicle-to-cloud [V2C] or vehicle-to-home [V2H]
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04W—WIRELESS COMMUNICATION NETWORKS
    • H04W8/00—Network data management

Definitions

  • the present disclosure relates to in-vehicle devices, servers and systems.
  • This application claims priority based on Japanese application No. 2021-110428 filed on July 2, 2021, and incorporates all the descriptions described in the Japanese application.
  • driving assistance systems Various systems (hereinafter referred to as driving assistance systems) have been proposed to assist drivers in driving automobiles, motorcycles, etc. (hereinafter referred to as vehicles).
  • sensor information is collected from devices (hereinafter referred to as infrastructure sensors) equipped with various sensor devices (eg cameras, radars, etc.) set on roads and their surroundings (hereinafter also referred to as roadsides). , and analyzes it to provide traffic-related information (for example, accidents, traffic jams, etc.) to the vehicle as driving support information.
  • traffic-related information for example, accidents, traffic jams, etc.
  • communication lines mobile communication lines
  • information is collected not only from sensor devices installed in infrastructure sensors, but also from sensor devices installed in vehicles and used for driving support. It is also proposed to make effective use of it.
  • Patent Document 1 in a system that transmits sensor information from a plurality of sensors to an information processing device via a communication network, a technique for selecting a desirable communication network and transmitting sensor information according to the situation is disclosed. disclosed. Since a wide variety of sensors are used in sensor networks, there is a wide variety of sensor information. These will change depending on the situation. In order to cope with this, in this system, a communication network is selected based on at least one of a sensor ID (an ID specifying an individual sensor) corresponding to sensor information to be transmitted, the type of sensor, and the amount of information. and send the sensor information.
  • a sensor ID an ID specifying an individual sensor
  • An in-vehicle device is an in-vehicle device that communicates with a server, and includes a function control unit that controls execution of functions of a vehicle in which the in-vehicle device is mounted, and services provided by the server from the server. receive a reply request with selection conditions for the in-vehicle device to select the data to be processed by the in-vehicle device, and transmit the reply data to the reply request to the server.
  • An in-vehicle communication unit and an in-vehicle intermediary unit that determines whether or not a selection condition is satisfied.
  • the vehicle-mounted communication unit determines whether or not at least one of the states of the control unit satisfies the selection condition, and transmits the result of the determination by the vehicle-mounted mediation unit to the server as reply data.
  • a server includes a communication unit that transmits a reply request to a plurality of the above-described in-vehicle devices and receives reply data; and an intermediary that identifies the in-vehicle device that satisfies the requirement.
  • a system includes a plurality of in-vehicle devices and a server.
  • a communication unit that transmits a reply request with a selection condition that is a condition for the in-vehicle device to select data to be processed that is to be processed by the in-vehicle device, and receives reply data to the reply request from the in-vehicle device; and an intermediary unit that identifies an in-vehicle device that satisfies a selection condition from among the plurality of in-vehicle devices based on the return data, and each of the plurality of in-vehicle devices executes a function of the vehicle in which the in-vehicle device is mounted.
  • an in-vehicle communication unit that receives a reply request from the server and transmits reply data to the server; and an in-vehicle mediation unit that determines whether or not the selection condition is satisfied, is the state of communication with the outside of the vehicle by the in-vehicle communication unit of the in-vehicle device, and the state of the function control unit of the in-vehicle device. It is determined whether or not at least one satisfies the selection condition, and the in-vehicle communication unit transmits the result of determination by the in-vehicle mediation unit of the in-vehicle device including the in-vehicle communication unit to the server as reply data.
  • FIG. 1 is a schematic diagram showing the configuration of a cooperation system according to an embodiment of the present disclosure.
  • FIG. 2 is a block diagram showing the hardware configuration of the server shown in FIG. 1.
  • FIG. 3 is a block diagram showing the hardware configuration of the in-vehicle device shown in FIG.
  • FIG. 4 is a block diagram showing the configuration of the vehicle-mounted gateway shown in FIG.
  • FIG. 5 is a block diagram showing the software configuration of the server shown in FIG.
  • FIG. 6 is a block diagram showing the software configuration of the in-vehicle device shown in FIG.
  • FIG. 7 is a flow chart showing processing by an intermediary unit executed by a server.
  • FIG. 8 is a flow chart showing the processing by the in-vehicle intermediation unit executed by the in-vehicle device.
  • FIG. 9 is a flow chart showing processing for evaluating the radio link state in the flow chart shown in FIG.
  • FIG. 10 is a schematic diagram showing a plurality of cooperative networks configured by the vehicles (in-vehicle devices) shown in FIG.
  • the driving support system when sensor data is sent from the in-vehicle device and infrastructure sensor to a server computer (hereinafter simply referred to as a server) and analyzed by the server, the response speed of the sensor device, the communication line used (5G, LTE, etc.) Depending on the communication speed, etc., the sensor data arrives at the server with a delay. Therefore, even if multiple pieces of sensor data are received at approximately the same time, sensor data with different sensor detection times (time when sensor data was generated) are mixed, so it is not appropriate to analyze them together. There is no problem.
  • the delay time includes a delay due to sensor response, a delay due to processing in the in-vehicle device, and a delay due to communication.
  • a plurality of in-vehicle devices that constitute a system that provides this cooperative service includes devices with various performances. That is, in addition to the differences in the specifications (basic performance) such as the communication speed and data processing capacity of the in-vehicle device, the state (load state of the CPU (Central Processing Unit), memory usage rate) also changes from moment to moment.
  • the present disclosure provides an in-vehicle device, a server, and a system that reduce the load on the server and enable the applications that provide each service to function efficiently in a cooperation system between the in-vehicle device and the server. With the goal.
  • an in-vehicle device, a server, and a system that reduce the load on the server and enable applications that provide each service to function efficiently in a system that links an in-vehicle device, an infrastructure sensor, and a server. can provide.
  • An in-vehicle device is an in-vehicle device that communicates with a server, and includes: a function control unit that controls execution of functions of a vehicle in which the in-vehicle device is mounted; Receives a reply request with selection conditions for the in-vehicle device to select the processed data to be processed by the in-vehicle device in order to realize the service provided by the in-vehicle device, and sends the server to the reply request It includes an in-vehicle communication unit that transmits reply data and an in-vehicle intermediary unit that determines whether or not the selection condition is satisfied.
  • the in-vehicle communication unit determines whether at least one of the state and the state of the function control unit satisfies the selection condition, and the in-vehicle communication unit transmits the result of determination by the in-vehicle mediation unit to the server as reply data.
  • the server can easily identify the in-vehicle device that satisfies the selection conditions of each service, and can easily use the data uploaded from the in-vehicle device. Therefore, the load on the server can be reduced, and the applications that provide each service can function efficiently.
  • the in-vehicle device can receive good and accurate service from the server.
  • the in-vehicle communication unit can further transmit sensor data acquired by the sensor to the server, and the processed data can include the sensor data. This enables services such as provision of driving support information by the server.
  • the in-vehicle intermediary unit determines whether or not the sensor satisfies the selection conditions, and the selection conditions can include conditions related to the type of sensor. As a result, it is possible to select an in-vehicle device capable of transmitting high-precision sensor data such as image resolution, so that the accuracy of the driving support information provided by the server is increased, and the reliability of the service is improved.
  • the in-vehicle intermediary unit determines whether or not the communication state of the in-vehicle communication unit satisfies the selection condition, and the selection condition may include a condition regarding at least one of communication speed and delay time.
  • the in-vehicle intermediary unit determines whether or not the state of the function control unit satisfies the selection condition, and the selection condition is the processing load state, processing delay time, memory usage rate, and vehicle may include conditions relating to at least one of communication speed and communication load inside the .
  • a server includes a communication unit that transmits a reply request to the plurality of in-vehicle devices and receives reply data; and an intermediary unit that identifies an in-vehicle device that satisfies the selection condition.
  • the server provides information used for a plurality of services executed by the in-vehicle device, and the intermediary unit provides the in-vehicle device specified as satisfying the selection condition and the service corresponding to the selection condition among the plurality of services.
  • the intermediary unit provides the in-vehicle device specified as satisfying the selection condition and the service corresponding to the selection condition among the plurality of services.
  • the intermediary unit may specify an on-vehicle device that satisfies the selection condition using an update cycle corresponding to each of a plurality of services, and update the network configuration data.
  • the network configuration data can be updated efficiently, and the load on the server can be suppressed.
  • unnecessary processing occurs due to updating network configuration data related to services that should be updated using a relatively long period in a short period of time.
  • useless processing can be suppressed by updating using an update cycle corresponding to each of a plurality of services.
  • a system includes a plurality of in-vehicle devices and a server, and the server realizes a service provided by the server to each of the plurality of in-vehicle devices. For this purpose, a reply request with a selection condition that is a condition for the in-vehicle device to select data to be processed by the in-vehicle device is transmitted, and reply data to the reply request is received from the in-vehicle device.
  • a communication unit a communication unit; and an intermediary unit that identifies an in-vehicle device that satisfies a selection condition based on the returned data from among a plurality of in-vehicle devices, and each of the plurality of in-vehicle devices is a function of the vehicle in which the in-vehicle device is mounted.
  • the in-vehicle intermediary unit detects sensors installed in the vehicle in which the in-vehicle device including the in-vehicle intermediary unit is installed, the state of communication with the outside of the vehicle by the in-vehicle communication unit of the in-vehicle device, and the function control unit of the in-vehicle device.
  • the server can easily identify the in-vehicle device that satisfies the selection conditions of each service, and can easily use the data uploaded from the in-vehicle device. Therefore, the load on the server can be reduced, and the applications that provide each service can function efficiently.
  • the in-vehicle device can receive good and accurate service from the server.
  • the cooperation system 100 includes a server 102, a base station 104, an infrastructure sensor 106, vehicles 110, 112, 114 and 116, and an in-vehicle device 118 mounted on the vehicle 110.
  • Vehicles 112 , 114 and 116 are also equipped with in-vehicle devices like vehicle 110 .
  • the server 102 provides various services in cooperation with vehicles (specifically, in-vehicle devices) and infrastructure sensors existing within a predetermined managed area. That is, the server 102 processes data (for example, sensor data) uploaded from the in-vehicle devices and infrastructure sensors, and uses the results to provide services such as providing driving support information.
  • data for example, sensor data
  • the destination of the service data from the server 102 is a vehicle (specifically, an in-vehicle device), a mobile terminal device, and the like existing within a predetermined area. uses the service.
  • the in-vehicle device 118 transmits and receives information via a mobile communication line (LTE line, 5G line, etc.) provided by the base station 104.
  • a Wi-Fi router (not shown) or the like may be installed around the road to provide the in-vehicle device 118 with a Wi-Fi communication service.
  • direct wireless communication can be performed between in-vehicle devices mounted in a plurality of vehicles without going through the base station 104 .
  • the infrastructure sensor 106 is installed on the roadside, is a device equipped with a function of acquiring roadside information, and has a communication function with the base station 104 .
  • the infrastructure sensor 106 is, for example, an image sensor (such as a digital surveillance camera), a radar (such as a millimeter wave radar), or a laser sensor (such as LiDAR (Light Detection and Ranging)).
  • server 102 includes control unit 120 , memory 122 , communication unit 124 , timer 126 , analysis processing unit 128 , operation unit 130 and bus 132 .
  • Server 102 is, for example, a computer. Data transmission between units occurs via bus 132 .
  • the control unit 120 includes, for example, a CPU, and controls each unit to realize various functions of the server 102 .
  • the memory 122 includes a rewritable non-volatile semiconductor memory and a mass storage device such as an HDD. Programs executed by control unit 120 are stored in memory 122, and various processes of server 102, which will be described later, are executed by control unit 120 reading and executing the programs. Memory 122 provides a work area for programs executed by control unit 120 .
  • the communication unit 124 receives sensor data and the like uploaded from the in-vehicle device 118 and the infrastructure sensor 106 .
  • the communication unit 124 includes an IC for modulation and multiplexing employed in wireless communication, an antenna for transmitting and receiving radio waves of a predetermined frequency, an RF circuit, and the like.
  • the communication unit 124 may have a Wi-Fi communication function.
  • the data received by communication unit 124 is transmitted to memory 122 and stored as a database.
  • Control unit 120 reads data from memory 122 , executes predetermined analysis processing (for example, analysis for obtaining driving support information) using analysis processing unit 128 , and stores the result in memory 122 .
  • the analysis for obtaining the driving support information includes, for example, a process of extracting objects (for example, people, vehicles, etc.) from the image data, and a process of calculating the movement direction, movement speed, etc. of the extracted objects.
  • Control unit 120 reads driving support information (including sensor data itself) and the like from memory 122 and transmits the information to in-vehicle device 118 and the like.
  • Timer 126 provides the current time upon request from control unit 120 .
  • the operation unit 130 is a device for an administrator or the like to input instructions to the control unit 120, and is an operation device such as a computer keyboard and mouse.
  • FIG. 3 an example of the hardware configuration of in-vehicle device 118 mounted in vehicle 110 is shown.
  • the in-vehicle device 118 includes a communication unit 140 , an in-vehicle gateway 142 , a plurality of ECUs (Electric Control Units) (1ECU 144 to nECU 146 ), and a bus 148 .
  • FIG. 3 also shows the sensor unit 150 mounted on the vehicle 110 .
  • the ECU is a function control unit that implements not only the driving function of the vehicle in which it is mounted, but also functions for improving safety.
  • the communication unit 140 performs wireless communication with an external device of the vehicle 110 (for example, communication with the server 102 via the base station 104).
  • the communication unit 140 includes an IC for modulation and multiplexing employed in wireless communication, an antenna for transmitting and receiving radio waves of a predetermined frequency, an RF circuit, and the like.
  • the communication unit 140 may have a Wi-Fi communication function.
  • the in-vehicle gateway 142 plays a role (for example, communication protocol conversion, etc.) that connects the communication function (that is, communication specification) with the outside of the vehicle and the communication function (that is, communication specification) inside the vehicle. Also, as will be described later, the in-vehicle gateway 142 has a function of receiving an instruction from the server 102 , executing processing according to the instruction, and returning the result to the server 102 .
  • in-vehicle gateway 142 includes control unit 160 , memory 162 and buffer 164 .
  • Control unit 160 includes, for example, a CPU.
  • the memory 162 includes a rewritable non-volatile semiconductor memory and a mass storage device such as an HDD.
  • control unit 160 A program executed by control unit 160 is stored in memory 162, and control unit 160 reads out and executes the program to connect the communication function with the outside of the vehicle and the communication function inside the vehicle as described above. It executes processing, processing according to instructions from the server 102, and the like.
  • Memory 162 provides a work area for programs executed by control unit 160 .
  • the buffer 164 When the in-vehicle gateway 142 communicates with each part of the in-vehicle device 118 via the bus 148, or communicates with an external device via the communication unit 140, the buffer 164 normally communicates according to the performance of the communication partner. It is a memory for temporarily storing data in order to perform
  • the sensor unit 150 includes sensors for acquiring information outside the vehicle 110 (for example, a video imaging device (for example, a digital camera (CCD camera, CMOS camera)), a laser sensor (LiDAR), etc.), and the vehicle itself. It includes sensors for acquiring information (acceleration sensors, load sensors, etc.).
  • the sensor section 150 includes an interface section (hereinafter referred to as an IF section), and the signal of the sensor section 150 is output to the bus 148 as digital data by the IF section.
  • Each of the 1st ECU 144 to the 1st nECU 146 also includes a control unit, a memory and a buffer, similar to the in-vehicle gateway 142 shown in FIG.
  • the 1st ECU 144 to the 1st nECU 146 may communicate with an external device via the in-vehicle gateway 142 and the communication unit 140 .
  • the in-vehicle gateway 142 controls communication mainly performed by the communication unit 140, the first ECU 144 to the nECU 146, etc. according to the communication environment at the location of the vehicle 110.
  • FIG. Data exchange between the units takes place via bus 148 .
  • the 1ECU 144 to the nECU 146 are function control units for realizing the functions of the vehicle 110, and control each unit related to the functions to be realized.
  • the first ECU 144 is a sensing ECU for implementing a function of monitoring the exterior of the vehicle 110 .
  • the first ECU 144 controls conditions for collecting sensor data by the sensor unit 150 and acquires sensor data from the sensor unit 150 .
  • the first ECU 144 may transmit the acquired sensor data to other ECUs via the bus 148 .
  • the first ECU 144 also transmits the sensor data to an external device via the in-vehicle gateway 142 and the communication unit 140 .
  • the nECU 146 is, for example, an automatic driving ECU for realizing an automatic driving function.
  • the first nECU 146 receives driving support information, traffic information, and the like from an external device via the communication unit 140 and the in-vehicle gateway 142, acquires sensor data from the sensor unit 150 from the first ECU 144, and uses the data related to automatic driving. control the mechanism that
  • FIG. 5 a software configuration regarding service provision in server 102 is shown.
  • the software is composed of three layers: an upper layer, a middle layer, and a lower layer.
  • the upper layer shows applications for providing each of a plurality of services (for example, providing driving assistance information, etc.). These services can be classified, for example, by the time from when some event occurs to when the information is provided.
  • the first through third services each provide real-time, near-real-time and non-real-time services.
  • Real-time, quasi-real-time, and non-real-time mean, for example, providing some service within less than about one second, between about one second and less than several seconds, and between several seconds and less than several minutes, respectively, after the occurrence of an event.
  • Applications for the first to third services are executed by the control unit 120 of the server 102 .
  • the middle layer acts as an intermediary between the upper layer (specifically each application) and the lower layer (specifically the communication unit), and the first to third intermediation corresponding to the applications of the first to third services, respectively. It is composed of departments.
  • the first to third intermediary units are software executed by control unit 120 of server 102 . As will be described later, each of the first to third intermediary units selects in-vehicle devices that can acquire data that can be used to provide the corresponding service, builds a cooperative network with the selected in-vehicle devices, and periodically updated accordingly. A cooperation network is constructed for each service.
  • the lower layer communication unit is composed of a device driver (that is, software) for operating the communication unit 124 shown in FIG.
  • the first to third intermediate units operate the communication unit 124 using a device driver, and communicate with the base station 104, the infrastructure sensor 106, and the in-vehicle devices of the vehicles 110 to 116 (eg, the in-vehicle device 118, etc.) shown in FIG. do.
  • FIG. 6 the software configuration of in-vehicle device 118 is shown. Assume here that the software is composed of three layers: an upper layer, a middle layer, and a lower layer. In the upper layer, applications for realizing the functions of each of a plurality of ECUs (that is, hardware) are shown as 1ECU to 3ECU.
  • the first to third ECUs (that is, applications) shown in FIG. 6 are, for example, applications for controlling the sensor unit 150 shown in FIG. 3, applications for automatic operation, applications for motor control, and the like.
  • Each of the 1ECU to the 3ECU is executed by the control unit of the corresponding ECU.
  • the middle layer acts as an intermediary between the upper layer 1ECU to 3ECU (ie application) and the lower layer (ie communication section).
  • the in-vehicle intermediary is software (that is, a program) executed by the in-vehicle gateway 142 .
  • the in-vehicle mediation unit performs a process of providing the server 102 with information for building a cooperative network by the server 102, as will be described later.
  • the lower layer communication unit is composed of a device driver (that is, software) for operating the communication unit 140 shown in FIG.
  • the in-vehicle mediation unit uses a device driver to operate the communication unit 140 to communicate with the server 102 shown in FIG.
  • FIG. 7 the operation of server 102 regarding construction and updating of a cooperation network will be described.
  • the processing shown in FIG. 7 is implemented by control unit 120 of server 102 shown in FIG. 2 reading out a predetermined program from memory 122 and executing it.
  • the processing shown in FIG. 7 corresponds to each of the first to third intermediary units shown in FIG. Run programs in parallel. That is, control unit 120 reads a plurality of programs from memory 122 and executes them by multitasking. In the following, one of a plurality of programs executed in parallel (that is, one intermediary section) will be described. It is assumed that the memory 122 stores in advance a predetermined time corresponding to each service.
  • control unit 120 determines whether or not to build a cooperation network. If a cooperative network has not been constructed, the determination result is YES. If a cooperative network has already been constructed, it is determined whether or not it is time to update it. Specifically, control unit 120 obtains the current time from timer 126, reads out the corresponding predetermined time from memory 122, compares them, and determines whether the predetermined time has passed since the last time the cooperation network was updated. determine whether If so, control passes to step 302 . Otherwise control passes to step 310 .
  • the predetermined time is the cycle for updating the cooperation network, and it is preferable that a different time be set depending on the type of service. For example, different data update times are required for real-time, near-real-time and non-real-time services.
  • a different time be set depending on the type of service. For example, different data update times are required for real-time, near-real-time and non-real-time services.
  • useless processing occurs.
  • updating a cooperative network for a service that needs to be updated using a relatively long period in a short period of time involves wasteful processing.
  • by updating using an update cycle corresponding to each of a plurality of services wasteful processing can be suppressed, the collaboration network can be updated efficiently, and the load on the server 102 can be suppressed.
  • the control unit 120 acquires the sorting conditions from the corresponding service application. Control then passes to step 304 .
  • the selection condition is a condition regarding data that can be used to provide the service, and differs for each service.
  • the selection conditions include, for example, collected data type, wireless link state, and vehicle interior state.
  • the collected data type includes, for example, the type of sensor mounted on the vehicle and its performance. For example, if the sensor is a video camera, its resolution and frame rate.
  • the wireless link state means the state of wireless communication (LTE, 5G, Wi-Fi, etc.) of the in-vehicle device of the vehicle existing in the managed area of the server 102.
  • the wireless communication speed and delay with the outside of the in-vehicle device It is at least one of the times, and conditions are specified for each type of wireless communication.
  • the in-vehicle state means the state of each ECU among the ECUs present in the vehicle, which is related to data transmitted to the server 102 for service. For example, it is at least one of the CPU load state, processing delay time, memory usage rate, and communication speed and communication load inside the vehicle in the ECU.
  • the control unit 120 transmits a reply request to the in-vehicle device existing in the management target area of the server 102 .
  • the control unit 120 broadcasts a predetermined command to which the conditions included in the selection conditions acquired in step 302 and information specifying the service (service ID, etc.) are attached.
  • the selection condition attached to the reply request is a condition related to the collected data type and the radio link state among the collected data type, the radio link state, and the in-vehicle state. Control then passes to step 306 .
  • control unit 120 stores in the memory 122 the data returned from the in-vehicle device in response to the reply request transmitted at step 304 .
  • Control then passes to step 308 .
  • this program corresponds to each intermediary unit shown in FIG. Sent from the device.
  • the service ID is attached to the data returned from the in-vehicle device. You can specify the reply data for the request.
  • control unit 120 selects an on-vehicle device that satisfies the selection conditions acquired at step 302 based on the data stored in the memory 122 at step 306 . Further, the control unit 120 stores information (for example, an in-vehicle device ID) specifying the selected in-vehicle device in the memory 122 in association with the service ID as a component of the cooperative network corresponding to the service. The stored data constitute network configuration data. Control then passes to step 310 .
  • information for example, an in-vehicle device ID
  • control unit 120 determines whether or not to end. For example, when the administrator of the server 102 operates the operation unit 130 (see FIG. 2) to instruct termination, it is determined that the processing should be terminated. If it is determined to end, the program ends. Otherwise control returns to step 300 .
  • each intermediary unit shown in FIG. 5 can construct a cooperative network corresponding to the corresponding service, and once the cooperative network is constructed, using a cycle (that is, a predetermined time) according to the corresponding service You can update your federation network.
  • data for example, sensor data
  • Each service application uses its own service ID to identify its own cooperation network, reads data transmitted from the in-vehicle device ID included in the cooperation network from memory 122, and analyzes it using analysis processing unit 128. , and the results can be used to provide services. That is, the application of each service can easily acquire the processing target data suitable for its own service from the uploaded data.
  • FIG. 8 The processing shown in FIG. 8 is realized by control unit 160 (see FIG. 4) of in-vehicle gateway 142 constituting in-vehicle device 118 reading out a predetermined program from memory 162 and executing the program.
  • the program shown in FIG. 8 corresponds to the in-vehicle mediation unit shown in FIG. It is assumed that an area for storing data to be returned to the server 102 (hereinafter referred to as a "reply data area”) is reserved in the memory 162 in advance.
  • the control unit 160 determines whether or not a reply request (for example, a predetermined command) has been received from the server 102 .
  • a reply request for example, a predetermined command
  • the reply request is broadcast by server 102 in step 304 of FIG. If so, control passes to step 402 . Otherwise control passes to step 416 .
  • control unit 160 determines whether or not the vehicle is equipped with a sensor that satisfies the conditions related to the type of collected data among the conditions added to the reply request received at step 400. If so, control proceeds to step 404 . Otherwise control passes to step 406 .
  • sensor data is acquired by controlling each sensor by the corresponding ECU, so the collected data type is determined by determining whether an ECU capable of generating desired data is installed. Equivalent to.
  • control unit 160 sets the first data in the reply data area of the memory 162 . Control then passes to step 408 .
  • control unit 160 sets second data different from the first data in the reply data area of the memory 162 . Control then passes to step 408 .
  • step 408 the control unit 160 evaluates the radio link state among the conditions added to the reply request received at step 400 .
  • the processing of step 408 is specifically shown in FIG. That is, in step 430, the control unit 160 switches the currently used communication interface to the one with the highest priority among the plurality of wireless interfaces (that is, wireless IFs) of the communication unit 140 (see FIG. 4). . Control then passes to step 432 . If the highest priority interface is the currently used communication interface, it remains unchanged. Also, if the communication unit 140 has only one wireless interface, it maintains the currently used communication interface.
  • the criteria for judging the highest priority of the wireless interface should be determined in advance for each in-vehicle device.
  • the actual wireless communication state for example, communication speed
  • the power consumption by wireless communication or the memory 162 of the in-vehicle gateway 142 generated by statistical processing by the server 102 and distributed in advance (see FIG. 4)
  • the criteria are determined based on information stored in the .
  • the information distributed from the server 102 includes, for example, wireless communication performance in the managed area of the server 102, traffic load of the entire communication line, communication charges, power consumption, and the like.
  • the communication unit 140 is currently in a state of wireless communication with the server 102, that wireless interface may be determined as the highest priority wireless interface.
  • control unit 160 monitors the state of communication via the wireless interface switched at step 430 and newly used. For example, the control unit 160 calculates the wireless communication speed.
  • control unit 160 determines whether or not the wireless communication speed calculated at step 432 satisfies the wireless link state condition among the selection conditions added to the reply request received at step 400 . If so, control passes to step 436 . Otherwise control passes to step 438 .
  • control unit 160 sets the third data in the reply data area of the memory 162 .
  • the third data is data different from both the first data and the second data. Control then returns to the flow chart of FIG. 8 and proceeds to step 410 .
  • control unit 160 determines whether the communication unit 140 has a wireless interface other than the wireless interface switched at step 430 . If not, control passes to step 440 . Otherwise, control transfers to step 442 .
  • control unit 160 sets the fourth data in the reply data area of the memory 162 .
  • the fourth data is data different from any of the first to third data. Control then returns to the flow chart of FIG. 8 and proceeds to step 410 .
  • step 442 control section 160 selects the currently used wireless interface as in step 430. switch. However, radio interfaces that have already been the target of step 432 are excluded. Control then returns to step 432 .
  • control unit 160 observes the vehicle interior state of the vehicle 110 . Specifically, control unit 160 controls the resource state (for example, CPU load state, processing delay time, Memory usage rate, communication speed and communication load inside the vehicle) are measured. Control unit 160 stores the measurement result in the return data area of memory 162 . Control then passes to step 412 .
  • resource state for example, CPU load state, processing delay time, Memory usage rate, communication speed and communication load inside the vehicle
  • control unit 160 reads the data stored in the reply data area of memory 162, adds its own in-vehicle device ID and the service ID attached to the reply request received at step 400, and communicates the data. It transmits to the server 102 via the unit 140 . Control then passes to step 414 .
  • control unit 160 determines whether or not to end. For example, when the driver of the vehicle 110 instructs to turn off the electric power system (for example, turn off the ignition button of the vehicle 110), it is determined that the program should end, and the program ends. Otherwise control returns to step 400 .
  • step 416 the control unit 160 determines whether or not to upload sensor data and the like to the server 102 . If so, control passes to step 418 . Otherwise control passes to step 414 .
  • the control unit 160 determines whether or not to upload based on whether new data (for example, data not yet transmitted to the server 102) is acquired by the sensor unit 150 (see FIG. 3) mounted on the vehicle 110. . If there is new data, it is determined to be uploaded. Alternatively, the upload may be performed using a fixed cycle. In this case, the control unit 160 determines whether or not a predetermined time has passed since the previous upload, and determines to upload if it has passed.
  • control unit 160 attaches its own in-vehicle device ID and transmits (that is, uploads) the sensor data to the server 102 via the communication unit 140 . Control then passes to step 414 .
  • each intermediary unit shown in FIG. 5 can identify the reply data to its own reply request from the service ID attached to the received reply data, and can identify the in-vehicle device that satisfies the selection condition.
  • the in-vehicle device ID can be recorded in the memory 122 as an element forming the cooperation network.
  • the intermediary unit For example, if the return data includes the first data or the third data, the intermediary unit records the in-vehicle device ID in the memory 122 as a component of the cooperation network. If it is already a component of a federation network, it will be maintained. On the other hand, if the reply data includes the second data or the fourth data, and the ID of the in-vehicle device is a component of the cooperation network, the intermediary unit excludes it from the components (that is, deletes it from the memory 122). )do. In addition, the intermediary unit checks whether the observation result of the vehicle interior state included in the reply data (see step 410 in FIG. 8) satisfies the condition of the vehicle interior state obtained from the service application (see step 302 in FIG. 7). judge. If it satisfies the requirements, the intermediary unit records the in-vehicle device ID in the memory 122 as a component of the cooperative network.
  • the server 102 can build a cooperation network corresponding to each service to be provided, and once the cooperation network is constructed, the cooperation network is updated using a period (that is, a predetermined time) according to the corresponding service.
  • federated network A is a network for providing real-time services and includes on-vehicle devices of vehicles 110 and 112 .
  • the in-vehicle device IDs of the vehicles 110 and 112 are stored as components of the cooperative network A.
  • Collaborative network B is a network for providing near real-time services and includes in-vehicle devices of vehicles 112 and 114 . In-vehicle device IDs of the vehicles 112 and 114 are stored in the memory 122 as components of the cooperation network B.
  • FIG. Collaborative network C is a network for providing non-real-time services and includes in-vehicle devices of vehicles 110-116. In-vehicle device IDs of vehicles 110 to 116 are stored in memory 122 as components of cooperative network C.
  • the server 102 can easily identify an in-vehicle device that satisfies the selection conditions of each service, and can easily use data uploaded from the in-vehicle device. Since the server 102 does not need to determine which service can be used each time data is received from an in-vehicle device or the like, the load can be reduced, and applications that provide each service can function efficiently. The in-vehicle device can receive good and accurate service from the server 102 .
  • the in-vehicle device 118 of the vehicle 110 appropriately transmits sensor data and the like to the server 102 if it has not received a reply request from the server 102 .
  • the server 102 stores the received sensor data and analyzes it by the analysis processing unit 128 or the like, thereby enabling services such as provision of driving support information.
  • a vehicle specifically, an in-vehicle device capable of transmitting high-precision sensor data such as image resolution can be selected. Therefore, the accuracy of the driving support information and the like provided by the server 102 is improved, and the reliability of the service is improved.
  • a condition that is, at least one of communication speed and delay time
  • the communication state for example, wireless link state
  • At least one of the processing load state, processing delay time, memory usage rate in the ECU, and the communication speed and communication load inside the vehicle can be used as the service selection condition.
  • an in-vehicle device with a short processing delay time can be selected as a component of the cooperative network. Therefore, data (for example, sensor data, etc.) transmitted from the in-vehicle device can be used, and the accuracy of services with high real-time nature can be improved.
  • step 304 shown in FIG. 7 is always executed. Even if the sorting conditions acquired in step 302 have not changed from the sorting conditions acquired last time, the state of the in-vehicle device may change. Also, if the update time is relatively long, the vehicles existing in the managed area of the server 102 may change. Therefore, it is preferable to send a reply request even if the sorting conditions obtained in step 302 have not changed. However, it is not limited to this. If the intermediary unit supports a service with a relatively short update cycle, it is not necessary to send a reply request if the selection conditions acquired in step 302 have not changed. Further, whether or not to transmit a reply request to the in-vehicle device may be determined in consideration of the presence or absence of a change in the selection condition and the update cycle.
  • the server 102 sends a reply request, and the in-vehicle device sends reply data in response to the reply request, but the present invention is not limited to this.
  • Each in-vehicle device may voluntarily transmit the collected data type, wireless link state, and vehicle state to the server 102 .
  • the reply data from the in-vehicle device may be stored in the memory 122 regardless of which intermediary unit has sent the reply data, so it may be stored in the memory 122 by another program. Whether or not the data is reply data can be determined by whether or not the data received by the server 102 includes a service ID. By doing so, it is not necessary for each intermediary unit to determine whether or not it is the reply data for the reply request sent by itself, which is efficient.
  • the in-vehicle device transmits the observation result of the in-vehicle state to the server, and the server (specifically, the intermediary unit) determines whether or not the condition of the in-vehicle state among the service selection conditions is met. Illustrated, but not limited to. If the condition of the in-vehicle state is included in the request transmitted from the server to the in-vehicle device, the in-vehicle device may determine whether or not the condition is satisfied, and transmit the determination result to the server. By doing so, it is possible to reduce the load on the server that executes a plurality of intermediary units (that is, software) in parallel.
  • a plurality of intermediary units that is, software

Landscapes

  • Engineering & Computer Science (AREA)
  • Computer Networks & Wireless Communication (AREA)
  • Signal Processing (AREA)
  • Computing Systems (AREA)
  • Economics (AREA)
  • Development Economics (AREA)
  • Accounting & Taxation (AREA)
  • General Business, Economics & Management (AREA)
  • Business, Economics & Management (AREA)
  • Databases & Information Systems (AREA)
  • Operations Research (AREA)
  • Physics & Mathematics (AREA)
  • General Physics & Mathematics (AREA)
  • Traffic Control Systems (AREA)

Abstract

車載装置は、サーバと通信する車載装置であって、当該車載装置が搭載された車両の機能の実行を制御する機能制御部と、サーバから、サーバにより提供されるサービスを車載装置が実現するために車載装置が処理対象とする被処理データを車載装置が選別するための選別条件が付された返信要求を受信し、且つ、サーバに返信要求に対する返信データを送信する車載通信部と、選別条件が満たされるか否かを判定する車載仲介部とを含み、車載仲介部は、車両に搭載されたセンサ、車載通信部による車両の外部との通信状態、及び、機能制御部の状態の少なくともいずれか１つが選別条件を満たすか否かを判定し、車載通信部は、車載仲介部による判定の結果を、返信データとしてサーバに送信する。

Description

車載装置、サーバ及びシステム
　本開示は、車載装置、サーバ及びシステムに関する。本出願は、２０２１年７月２日出願の日本出願第２０２１－１１０４２８号に基づく優先権を主張し、前記日本出願に記載された全ての記載内容を援用するものである。
　自動車及び自動二輪車等（以下、車両という）の運転に関して運転者を支援する種々のシステム（以下、運転支援システムという）が提案されている。運転支援システムにおいては、道路及びその周辺（以下、路側ともいう）に設定された種々のセンサ機器（例えばカメラ、レーダ等）を備えた装置（以下、インフラセンサという）からセンサの情報を収集し、それを解析して交通に関する情報（例えば事故、渋滞等）を、運転支援情報として車両に提供する。また、移動体通信回線（以下、通信回線ともいう）の高速化に伴い、インフラセンサに装備されたセンサ機器に限らず、車両に搭載されているセンサ機器からの情報を収集し、運転支援に有効利用することも提案されている。
　後掲の特許文献１には、複数のセンサからセンサ情報を、通信網を介して情報処理装置に伝送するシステムにおいて、状況に応じて、望ましい通信網を選択してセンサ情報を伝送する技術が開示されている。センサネットワークにおいては、多種多様なセンサを利用するため、センサ情報も多種多様であり、情報量が多いもの、少ないもの、伝送のリアルタイム性が要求されるもの、要求されないもの等がある。これらは状況に応じて変化する。これに対応するために、このシステムにおいては、伝送すべきセンサ情報に対応するセンサＩＤ（個々のセンサを特定するＩＤ）、センサの種類及び情報量のうち少なくとも１つに基づいて通信網を選択し、センサ情報を送信する。
特開２００３－１１０７４９号公報
　本開示のある局面に係る車載装置は、サーバと通信する車載装置であって、当該車載装置が搭載された車両の機能の実行を制御する機能制御部と、サーバから、サーバにより提供されるサービスを車載装置が実現するために車載装置が処理対象とする被処理データを車載装置が選別するための選別条件が付された返信要求を受信し、且つ、サーバに返信要求に対する返信データを送信する車載通信部と、選別条件が満たされるか否かを判定する車載仲介部とを含み、車載仲介部は、車両に搭載されたセンサ、車載通信部による車両の外部との通信状態、及び、機能制御部の状態の少なくともいずれか１つが選別条件を満たすか否かを判定し、車載通信部は、車載仲介部による判定の結果を、返信データとしてサーバに送信する。
　本開示の別の局面に係るサーバは、複数の上記の車載装置に、返信要求を送信し、返信データを受信する通信部と、複数の車載装置の中から、返信データに基づいて選別条件を満たす車載装置を特定する仲介部とを含む。
　本開示のさらに別の局面に係るシステムは、複数の車載装置と、サーバとを含み、サーバは、複数の車載装置の各々に、サーバにより提供されるサービスを当該車載装置が実現するために当該車載装置が処理対象とする被処理データを当該車載装置が選別するための条件である選別条件を付した返信要求を送信し、且つ、当該車載装置から返信要求に対する返信データを受信する通信部と、複数の車載装置の中から、返信データに基づいて選別条件を満たす車載装置を特定する仲介部とを含み、複数の車載装置の各々は、当該車載装置が搭載された車両の機能の実行を制御する機能制御部と、サーバから返信要求を受信し、且つ、サーバに返信データを送信する車載通信部と、選別条件が満たされるか否かを判定する車載仲介部とを含み、車載仲介部は、当該車載仲介部を含む車載装置が搭載された車両に搭載されたセンサ、当該車載装置の車載通信部による当該車両の外部との通信状態、及び、当該車載装置の機能制御部の状態の少なくともいずれか１つが選別条件を満たすか否かを判定し、車載通信部は、当該車載通信部を含む車載装置の車載仲介部による判定の結果を返信データとしてサーバに送信する。
図１は、本開示の実施形態に係る連携システムの構成を示す模式図である。 図２は、図１に示したサーバのハードウェア構成を示すブロック図である。 図３は、図１に示した車載装置のハードウェア構成を示すブロック図である。 図４は、図３に示した車載ゲートウェイの構成を示すブロック図である。 図５は、図２に示したサーバのソフトウェア構成を示すブロック図である。 図６は、図３に示した車載装置のソフトウェア構成を示すブロック図である。 図７は、サーバにより実行される仲介部による処理を示すフローチャートである。 図８は、車載装置により実行される車載仲介部による処理を示すフローチャートでる。 図９は、図８に示したフローチャートにおける無線リンク状態を評価する処理を示すフローチャートである。 図１０は、図１に示した車両（車載装置）により構成される複数の連携ネットワークを示す模式図である。
　［本開示が解決しようとする課題］
　運転支援システムにおいて、車載装置及びインフラセンサからセンサデータをサーバコンピュータ（以下、単にサーバという）に送信し、サーバにより解析する場合、センサ機器の反応速度、使用する通信回線（５Ｇ、ＬＴＥ等）の通信速度等により、センサデータがサーバに遅れて届く。したがって、ほぼ同じ時刻に複数のセンサデータを受信したとしても、センサの検出時刻（センサデータが生成された時刻）が異なるセンサデータが混在するので、それらをまとめて解析対象とすることは適切ではないという問題がある。遅延時間には、センサ応答による遅延、車載装置における処理による遅延、通信による遅延がある。
　したがって、複数の車載装置からセンサデータがサーバにアップロードされる場合、同時刻に受信されたセンサデータを解析対象とすれば、第１車両に装備されたセンサにより検知された対象（人）と、第２車両に装備されたセンサにより検知された対象（人）とは異なるにもかかわらず、異なる対象を同一対象として誤検出してしまう等により、誤った検出結果が得られてしまう可能性がある。同様に、同じ対象を異なる複数台の車載装置により検知した場合には、各車載装置からのセンサデータの遅延時間が大きく異なると、サーバによりほぼ同時刻には受信されず、異なる処理対象とされてしまい、解析結果の精度が低下する原因となる。この問題は、特許文献１に開示された技術によっては解決できない。
　この問題を解決するために、車載装置とサーバとの連携（協調）において、車載装置からセンサデータをサーバに送信するときに、遅延時間に応じてセンサデータを適切に分類及び解析することが考えられる。しかし、この連携サービス（コネクティッドサービス）を提供するシステムを構成する複数の車載装置には、種々の性能のものが含まれている。即ち、車載装置の通信速度、データ処理能力等の仕様（基本性能）が異なることに加えて、その状態（ＣＰＵ（Ｃｅｎｔｒａｌ　Ｐｒｏｃｅｓｓｉｎｇ　Ｕｎｉｔ）の負荷状態、メモリ使用率）も刻々と変化する。したがって、車載装置から送信されるセンサデータを、一律に処理する場合には、十分に精度の高いサービスを提供できない問題がある。その対策として、サーバのサービスを提供するソフトウェア（以下、アプリケーションという）毎に、受信したセンサデータから、処理対象とするセンサデータを選別することが考えられる。しかし、サーバが複数のサービスを同時に提供するには、複数のアプリケーションを並行して実行する必要があり、サーバの負荷が大きくなる問題がある。
　したがって、本開示は、車載装置とサーバとの連携システムにおいて、サーバの負荷を低減し、各サービスを提供するアプリケーションが効率的に機能することを可能にする車載装置、サーバ及びシステムを提供することを目的とする。
　［本開示の効果］
　本開示によれば、車載装置及びインフラセンサとサーバとの連携システムにおいて、サーバの負荷を低減し、各サービスを提供するアプリケーションが効率的に機能することを可能にする車載装置、サーバ及びシステムを提供できる。
　［本開示の実施形態の説明］
　本開示の実施形態の内容を列記して説明する。以下に記載する実施形態の少なくとも一部を任意に組合せてもよい。
　（１）本開示の第１の局面に係る車載装置は、サーバと通信する車載装置であって、当該車載装置が搭載された車両の機能の実行を制御する機能制御部と、サーバから、サーバにより提供されるサービスを車載装置が実現するために車載装置が処理対象とする被処理データを車載装置が選別するための選別条件が付された返信要求を受信し、且つ、サーバに返信要求に対する返信データを送信する車載通信部と、選別条件が満たされるか否かを判定する車載仲介部とを含み、車載仲介部は、車両に搭載されたセンサ、車載通信部による車両の外部との通信状態、及び、機能制御部の状態の少なくともいずれか１つが選別条件を満たすか否かを判定し、車載通信部は、車載仲介部による判定の結果を、返信データとしてサーバに送信する。これにより、サーバは、複数の車載装置と連携してサービスを提供する場合に、各サービスの選別条件を満たす車載装置を容易に特定でき、その車載装置からアップロードされたデータを容易に使用できる。したがって、サーバの負荷を低減でき、各サービスを提供するアプリケーションを効率的に機能させることができる。車載装置はサーバから、良好であり且つ精度の高いサービスを受けることができる。
　（２）車載通信部はさらに、センサにより取得されたセンサデータをサーバに送信し、被処理データは、センサデータを含むことができる。これにより、サーバによる運転支援情報の提供等のサービスが可能になる。
　（３）車載仲介部は、センサが選別条件を満たすか否かを判定し、選別条件は、センサの種類に関する条件を含むことができる。これにより、画像解像度等の高精度のセンサデータを送信できる車載装置を選択できるので、サーバにより提供される運転支援情報等の精度が高くなり、サービスの信頼性が向上する。
　（４）車載仲介部は、車載通信部の通信状態が選別条件を満たすか否かを判定し、選別条件は、通信速度及び遅延時間のうちの少なくとも１つに関する条件を含んでもよい。これにより、通信速度が速く、遅延時間が短い車載装置を選択できるので、リアルタイム性の高いサービスにおける精度を向上できる。
　（５）車載仲介部は、機能制御部の状態が選別条件を満たすか否かを判定し、選別条件は、機能制御部における、処理の負荷状態、処理遅延時間、メモリ使用率、並びに、車両の内部における通信速度及び通信負荷のうちの少なくとも１つに関する条件を含んでもよい。これにより、処理の遅延時間が短い車載装置から送信されたデータ（センサデータ等）を用いることができ、リアルタイム性の高いサービスにおける精度を向上できる。
　（６）本開示の第２の局面に係るサーバは、複数の上記の車載装置に、返信要求を送信し、返信データを受信する通信部と、複数の車載装置の中から、返信データに基づいて選別条件を満たす車載装置を特定する仲介部とを含む。これにより、サーバは、複数の車載装置と連携してサービスを提供する場合に、各サービスの選別条件を満たす車載装置を容易に特定でき、その車載装置からアップロードされたデータを容易に使用できる。したがって、サーバの負荷を低減でき、各サービスを提供するアプリケーションを効率的に機能させることができる。
　（７）サーバは、車載装置により実行される複数のサービスに用いる情報を提供し、仲介部は、選別条件を満たすとして特定した車載装置と、複数のサービスのうち、選別条件に対応するサービスとを対応させ、対応させた車載装置及びサービスを表す情報をネットワーク構成データとして記憶できる。これにより、各サービスと、それに適したデータ（センサデータ等）を送信する車載装置との対応関係を効率的に管理でき、各サービスを実行するアプリケーションのデータ処理効率を向上できる。
　（８）仲介部は、複数のサービスの各々に応じた更新周期を用いて、選別条件を満たす車載装置を特定し、ネットワーク構成データを更新してもよい。これにより、効率的にネットワーク構成データを更新でき、サーバの負荷を抑制できる。複数のネットワーク構成データを同じ周期を用いて更新する場合には、比較的長い周期を用いて更新できればよいサービスに関するネットワーク構成データを短時間に更新することによる無駄な処理が発生する。それに対して、複数のサービスの各々に応じた更新周期を用いて更新することにより、無駄な処理を抑制できる。
　（９）本開示の第３の局面に係るシステムは、複数の車載装置と、サーバとを含み、サーバは、複数の車載装置の各々に、サーバにより提供されるサービスを当該車載装置が実現するために当該車載装置が処理対象とする被処理データを当該車載装置が選別するための条件である選別条件を付した返信要求を送信し、且つ、当該車載装置から返信要求に対する返信データを受信する通信部と、複数の車載装置の中から、返信データに基づいて選別条件を満たす車載装置を特定する仲介部とを含み、複数の車載装置の各々は、当該車載装置が搭載された車両の機能の実行を制御する機能制御部と、サーバから返信要求を受信し、且つ、サーバに返信データを送信する車載通信部と、選別条件が満たされるか否かを判定する車載仲介部とを含み、車載仲介部は、当該車載仲介部を含む車載装置が搭載された車両に搭載されたセンサ、当該車載装置の車載通信部による当該車両の外部との通信状態、及び、当該車載装置の機能制御部の状態の少なくともいずれか１つが選別条件を満たすか否かを判定し、車載通信部は、当該車載通信部を含む車載装置の車載仲介部による判定の結果を返信データとしてサーバに送信する。これにより、サーバは、複数の車載装置と連携してサービスを提供する場合に、各サービスの選別条件を満たす車載装置を容易に特定でき、その車載装置からアップロードされたデータを容易に使用できる。したがって、サーバの負荷を低減でき、各サービスを提供するアプリケーションを効率的に機能させることができる。車載装置はサーバから、良好であり且つ精度の高いサービスを受けることができる。
　［本開示の実施形態の詳細］
　以下の実施形態においては、同一の部品には同一の参照番号を付してある。それらの名称及び機能も同一である。したがって、それらについての詳細な説明は繰返さない。
［全体構成］
　図１を参照して本開示の実施形態に係る連携システム１００は、サーバ１０２、基地局１０４、インフラセンサ１０６、車両１１０、１１２、１１４及び１１６、並びに、車両１１０に搭載された車載装置１１８を含む。車両１１２、１１４及び１１６にも、車両１１０と同様に車載装置が搭載されている。サーバ１０２は、所定の管理対象領域内に存在する車両（具体的には車載装置）及びインフラセンサと連携して、種々のサービスを提供する。即ち、サーバ１０２は、車載装置及びインフラセンサからアップロードされるデータ（例えばセンサデータ等）を処理し、その結果を用いて、運転支援情報の提供等のサービスを行う。図１において、４台の車両は、サーバ１０２と連携する車両を代表的に表している。また、基地局１０４及びインフラセンサ１０６も代表的に示しており、複数台存在している。なお、サーバ１０２からのサービス用データの送信先は、所定の領域内に存在する車両（具体的には車載装置）及び携帯端末装置等であり、車両の運転者及び携帯端末装置の利用者等がサービスを利用する。
　車載装置１１８は、基地局１０４が提供している移動体通信回線（ＬＴＥ回線及び５Ｇ回線等）により情報を送信及び受信する。道路の周囲には、Ｗｉ－Ｆｉルータ（図示せず）等が設置され、車載装置１１８にＷｉ－Ｆｉによる通信サービスが提供されていてもよい。また、複数の車両に搭載された車載装置間において基地局１０４を介さずに直接無線通信することもできる。
　インフラセンサ１０６は路側に設置され、路側における情報を取得する機能を備えた装置であり、基地局１０４との通信機能を有している。インフラセンサ１０６は、例えば、イメージセンサ（デジタルの監視カメラ等）、レーダ（ミリ波レーダ等）、又はレーザセンサ（ＬｉＤＡＲ（Ｌｉｇｈｔ　Ｄｅｔｅｃｔｉｏｎ　ａｎｄ　Ｒａｎｇｉｎｇ）等）等である。
［サーバのハードウェア構成］
　図２を参照して、サーバ１０２は、制御部１２０、メモリ１２２、通信部１２４、タイマ１２６、解析処理部１２８、操作部１３０及びバス１３２を含む。サーバ１０２は、例えばコンピュータである。各部の間のデータ伝送は、バス１３２を介して行われる。制御部１２０は、例えばＣＰＵを含み、各部を制御してサーバ１０２の種々の機能を実現する。メモリ１２２は、書換可能な不揮発性の半導体メモリ及びＨＤＤ等の大容量記憶装置を含む。メモリ１２２には、制御部１２０が実行するプログラムが記憶されており、制御部１２０がそのプログラムを読出して実行することにより、後述するサーバ１０２の種々の処理が実行される。メモリ１２２は、制御部１２０が実行するプログラムのワーク領域を提供する。
　通信部１２４は、車載装置１１８及びインフラセンサ１０６からアップロードされるセンサデータ等を受信する。通信部１２４は、無線通信において採用されている変調及び多重化を行うためのＩＣ、所定周波数の電波を送信及び受信するためのアンテナ、並びにＲＦ回路等を含む。通信部１２４は、Ｗｉ－Ｆｉ通信機能を有していてもよい。通信部１２４により受信されたデータは、メモリ１２２に伝送され、データベースとして記憶される。制御部１２０は、メモリ１２２からデータを読出し、解析処理部１２８を用いて所定の解析処理（例えば、運転支援情報を得るための解析）を実行し、その結果をメモリ１２２に記憶する。運転支援情報を得るための解析には、例えば、画像データから対象物（例えば人、車両等）を抽出する処理、抽出された対象物の移動方向、移動速度等を算出する処理が含まれる。制御部１２０は、メモリ１２２から運転支援情報（センサデータ自体を含む）等を読出し、車載装置１１８等に送信する。タイマ１２６は、制御部１２０からの要求を受けて現在時刻を提供する。操作部１３０は、管理者等が制御部１２０に対する指示を入力するための装置であり、コンピュータ用のキーボード及びマウス等の操作装置である。
［車載装置のハードウェア構成］
　図３を参照して、車両１１０に搭載されている車載装置１１８のハードウェア構成の一例を示す。車載装置１１８は、通信部１４０、車載ゲートウェイ１４２、複数のＥＣＵ（Ｅｌｅｃｔｒｉｃ　Ｃｏｎｔｒｏｌ　Ｕｎｉｔ）（第１ＥＣＵ１４４～第ｎＥＣＵ１４６）及びバス１４８を含む。図３には、車両１１０に搭載されているセンサ部１５０も示している。ＥＣＵは、それが搭載されている車両の走行機能に限らず、安全性向上のための機能等を実現するための機能制御部である。
　通信部１４０は、車両１１０の外部装置と無線通信（例えば、基地局１０４を介したサーバ１０２との通信）を行う。通信部１４０は、無線通信において採用されている変調及び多重化を行うためのＩＣ、所定周波数の電波を送信及び受信するためのアンテナ、並びにＲＦ回路等を含む。通信部１４０は、Ｗｉ－Ｆｉ通信機能を有していてもよい。
　車載ゲートウェイ１４２は、車外との通信機能（即ち通信仕様）と車内における通信機能（即ち通信仕様）とを接合する役割（例えば通信プロトコル変換等）を担う。また、車載ゲートウェイ１４２は、後述するように、サーバ１０２からの指示を受けて、それに応じた処理を実行し、その結果をサーバ１０２に返信する機能を有する。図４を参照して、車載ゲートウェイ１４２は、制御部１６０、メモリ１６２及びバッファ１６４を含む。制御部１６０は、例えばＣＰＵを含む。メモリ１６２は、書換可能な不揮発性の半導体メモリ及びＨＤＤ等の大容量記憶装置を含む。メモリ１６２には、制御部１６０が実行するプログラムが記憶されており、制御部１６０がそのプログラムを読出して実行することにより、上記したように、車外との通信機能と車内における通信機能との接合処理、及び、サーバ１０２の指示に応じた処理等を実行する。メモリ１６２は、制御部１６０が実行するプログラムのワーク領域を提供する。バッファ１６４は、車載ゲートウェイ１４２が、バス１４８を介して車載装置１１８の各部と通信する場合、又は、通信部１４０を介して外部装置と通信する場合に、通信相手の性能に合わせて正常に通信を行うために、データを一時的に記憶するためのメモリである。
　センサ部１５０は、車両１１０外部の情報を取得するためのセンサ（例えばビデオ映像の撮像装置（例えば、デジタルカメラ（ＣＣＤカメラ、ＣＭＯＳカメラ））、レーザセンサ（ＬｉＤＡＲ）等）、及び、車両自体の情報を取得するためのセンサ（加速度センサ、荷重センサ等）を含む。センサ部１５０は、インターフェイス部（以下、ＩＦ部という）を含み、センサ部１５０の信号はＩＦ部によりデジタルデータとしてバス１４８に出力される。
　第１ＥＣＵ１４４～第ｎＥＣＵ１４６の各々も、図４に示した車載ゲートウェイ１４２と同様に、制御部、メモリ及びバッファを含む。第１ＥＣＵ１４４～第ｎＥＣＵ１４６は、車載ゲートウェイ１４２及び通信部１４０を介して、外部装置と通信してもよい。車載ゲートウェイ１４２は、車両１１０の位置における通信環境に応じて、通信部１４０、第１ＥＣＵ１４４～第ｎＥＣＵ１４６等が主体となる通信を制御する。各部間のデータ交換は、バス１４８を介して行われる。
　上記したように、第１ＥＣＵ１４４～第ｎＥＣＵ１４６は、車両１１０の機能を実現するための機能制御部であり、実現する機能に関連する各部を制御する。例えば、第１ＥＣＵ１４４は、車両１１０の外部を監視する機能を実現するためのセンシング用ＥＣＵである。第１ＥＣＵ１４４は、センサ部１５０によるセンサデータの収集条件を制御し、センサ部１５０からセンサデータを取得する。第１ＥＣＵ１４４は、取得したセンサデータを、バス１４８を介して他のＥＣＵに伝送してもよい。また、第１ＥＣＵ１４４は、センサデータを、車載ゲートウェイ１４２及び通信部１４０を介して外部装置に送信する。第ｎＥＣＵ１４６は、例えば、自動運転機能を実現するための自動運転用ＥＣＵである。第ｎＥＣＵ１４６は、外部装置から、通信部１４０及び車載ゲートウェイ１４２を介して運転支援情報及び交通情報等を受信し、第１ＥＣＵ１４４からセンサ部１５０のセンサデータを取得し、それらを用いて自動運転に関連する機構を制御する。
［サーバのソフトウェア構成］
　図５を参照して、サーバ１０２におけるサービス提供に関するソフトウェア構成を示す。ここでは、ソフトウェアは、上位層、中位層及び下位層の３層により構成されているとする。上位層には、複数のサービス（例えば運転支援情報の提供等）の各々を提供するためのアプリケーションを示している。これらのサービスは、例えば、何らかの事象（即ちイベント）が発生してから情報を提供するまでの時間によって分類され得る。例えば、第１～第３サービスはそれぞれ、リアルタイム、準リアルタイム及び非リアルタイムのサービスを提供する。リアルタイム、準リアルタイム及び非リアルタイムとは、例えば、イベントが発生してからそれぞれ約１秒未満、約１秒以上数秒未満、及び、数秒以上数分未満に、何らかのサービスを提供することを意味する。第１～第３サービスのアプリケーションは、サーバ１０２の制御部１２０により実行される。
　中位層は、上位層（具体的には各アプリケーション）と下位層（具体的には通信部）との仲介を行い、第１～第３サービスのアプリケーションにそれぞれ対応する第１～第３仲介部により構成されている。第１～第３仲介部は、サーバ１０２の制御部１２０により実行されるソフトウェアである。第１～第３仲介部の各々は、後述するように、対応するサービスを提供するために利用できるデータを取得可能な車載装置を選別し、選別された車載装置により連携ネットワークを構築し、定期的に更新する。連携ネットワークは、サービス毎に構築される。
　下位層の通信部は、図２に示した通信部１２４を動作させるためのデバイスドライバ（即ちソフトウェア）により構成される。第１～第３仲介部は、デバイスドライバを用いて通信部１２４を動作させ、図１に示した基地局１０４、インフラセンサ１０６及び車両１１０～１１６の車載装置（例えば車載装置１１８等）と通信する。
［車載装置のソフトウェア構成］
　図６を参照して、車載装置１１８におけるソフトウェア構成を示す。ここでは、ソフトウェアは、上位層、中位層及び下位層の３層により構成されているとする。上位層には、複数のＥＣＵ（即ちハードウェア）の各々の機能を実現するためのアプリケーションを、第１ＥＣＵ～第３ＥＣＵとして示している。図６に示した第１ＥＣＵ～第３ＥＣＵ（即ちアプリケーション）は、例えば、図３に示したセンサ部１５０の制御用アプリケーション、自動運転用アプリケーション及びモータ制御用アプリケーション等である。第１ＥＣＵ～第３ＥＣＵの各々は、対応するＥＣＵの制御部により実行される。
　中位層は、上位層の第１ＥＣＵ～第３ＥＣＵ（即ちアプリケーション）と下位層（即ち通信部）との仲介を行う。車載仲介部は、車載ゲートウェイ１４２により実行されるソフトウェア（即ちプログラム）である。車載仲介部は、後述するように、サーバ１０２による連携ネットワークの構築のための情報をサーバ１０２に提供する処理を行う。
　下位層の通信部は、図３に示した通信部１４０を動作させるためのデバイスドライバ（即ちソフトウェア）により構成される。車載仲介部は、デバイスドライバを用いて、通信部１４０を動作させ、図１に示したサーバ１０２と通信する。
［サーバの動作］
　図７を参照して、連携ネットワークの構築及びその更新に関するサーバ１０２の動作を説明する。図７に示した処理は、図２に示したサーバ１０２の制御部１２０が、所定のプログラムをメモリ１２２から読出して実行することにより実現される。図７に示した処理は、図５に示した第１～第３仲介部の各々に対応し、サーバ１０２は、第１～第３サービスの各々に対応して、図７に示した複数のプログラムを並列に実行する。即ち、制御部１２０は、複数のプログラムをメモリ１２２から読出し、マルチタスクにより実行する。以下、並列に実行される複数のプログラムのうちの１つ（即ち１つの仲介部）に関して説明する。なお、メモリ１２２には、サービス毎に対応させた所定時間が予め記憶されているとする。
　ステップ３００において、制御部１２０は、連携ネットワークを構築するか否かを判定する。連携ネットワークが構築されていない場合には、判定結果はＹＥＳとなる。既に連携ネットワークが構築されている場合には、それを更新する時間になったか否かを判定する。具体的には、制御部１２０は、タイマ１２６から現在時刻を取得し、対応する所定時間をメモリ１２２から読出し、それらを比較して、前回連携ネットワークを更新した時間から所定時間が経過したか否かを判定する。経過したと判定された場合、制御はステップ３０２に移行する。そうでなければ、制御はステップ３１０に移行する。
　所定時間は、連携ネットワークを更新する周期であり、サービスの種類により異なる時間が設定されることが好ましい。例えば、リアルタイム、準リアルタイム及び非リアルタイムのサービスに応じて、要求されるデータの更新時間は異なる。複数の連携ネットワークを同じ周期を用いて更新する場合、無駄な処理が発生する。例えば、比較的長い周期を用いて更新できればよいサービスに関する連携ネットワークを短時間に更新することは、無駄な処理を含む。それに対して、複数のサービスの各々に応じた更新周期を用いて更新することにより、無駄な処理を抑制でき、効率的に連携ネットワークを更新でき、サーバ１０２の負荷を抑制できる。
　ステップ３０２において、制御部１２０は、対応するサービスのアプリケーションから選別条件を取得する。その後、制御はステップ３０４に移行する。選別条件は、そのサービスを提供するために利用できるデータに関する条件であり、サービス毎に異なる。選別条件には、例えば、収集データ種別、無線リンク状態及び車内状態を含む。収集データ種別は、例えば、車両に搭載されているセンサの種類及びその性能を含む。例えば、センサがビデオカメラであれば、その解像度及びフレームレート等である。無線リンク状態は、サーバ１０２の管理対象領域に存在する車両の車載装置の無線通信（ＬＴＥ、５Ｇ、Ｗｉ－Ｆｉ等）の状態を意味し、例えば、車載装置の外部との無線通信速度及び遅延時間のうちの少なくとも１つであり、無線通信の種類毎に条件が指定される。車内状態は、車両内に存在するＥＣＵのうち、サービスのためにサーバ１０２に送信するデータに関係する各ＥＣＵの状態を意味する。例えば、ＥＣＵにおける、ＣＰＵの負荷状態、処理遅延時間、メモリ使用率、並びに、車両内部における通信速度及び通信負荷のうちの少なくとも１つである。
　ステップ３０４において、制御部１２０は、サーバ１０２の管理対象領域に存在する車両の車載装置に返信要求を送信する。具体的には、制御部１２０は、ステップ３０２により取得した選別条件に含まれる条件と、サービスを特定する情報（サービスＩＤ等）とを付した所定のコマンドをブロードキャストする。ここで、返信要求に付する選別条件は、上記の収集データ種別、無線リンク状態及び車内状態のうち、収集データ種別及び無線リンク状態に関する条件とする。その後、制御はステップ３０６に移行する。
　ステップ３０６において、制御部１２０は、ステップ３０４により送信した返信要求に対して車載装置から返信されたデータをメモリ１２２に記憶する。その後、制御はステップ３０８に移行する。上記したように本プログラムは、図５に示した各仲介部に対応するので、並列に動作している複数の仲介部の各々から返信要求が送信され（ステップ３０４）、それに対する返信データが車載装置から送信される。後述するように、車載装置から返信されるデータには、サービスＩＤが付されているので、各仲介部（具体的には制御部１２０）は、サービスＩＤにより、自己がステップ３０４により送信した返信要求に対する返信データを特定できる。
　ステップ３０８において、制御部１２０は、ステップ３０６によりメモリ１２２に記憶されたデータに基づき、ステップ３０２により取得した選別条件を満たす車載装置を選択する。制御部１２０はさらに、選択された車載装置を特定する情報（例えば車載装置ＩＤ）を、そのサービスに対応する連携ネットワークの構成要素として、サービスＩＤと対応させてメモリ１２２に記憶する。記憶されたデータは、ネットワーク構成データを構成する。その後、制御はステップ３１０に移行する。
　ステップ３１０において、制御部１２０は、終了するか否かを判定する。例えば、サーバ１０２の管理者により操作部１３０（図２参照）が操作され、終了が指示された場合に、終了すると判定される。終了すると判定された場合、本プログラムは終了する。そうでなければ、制御はステップ３００に戻る。
　以上により、図５に示した各仲介部は、対応するサービスに対応する連携ネットワークを構築でき、一度連携ネットワークが構築された後には、対応するサービスに応じた周期（即ち所定時間）を用いて連携ネットワークを更新できる。後述するように、サーバ１０２の管理対象領域に存在するインフラセンサ１０６及び車載装置１１８等からアップロードされるデータ（例えばセンサデータ等）は、順次メモリ１２２の所定領域にデータベースとして記憶される。各サービスのアプリケーションは、自己のサービスＩＤを用いて自己の連携ネットワークを特定し、その連携ネットワークに含まれる車載装置ＩＤから送信されたデータをメモリ１２２から読出して解析処理部１２８を用いて解析し、その結果をサービスの提供に利用できる。即ち、各サービスのアプリケーションは、アップロードされたデータの中から、自己のサービスに適した処理対象データを容易に取得できる。
［車載装置の動作］
　図８を参照して、サーバ１０２からの返信要求を受けて車載装置及びインフラセンサの各々が行う動作を説明する。ここでは、代表として車載装置１１８により実行される処理を説明する。図８に示した処理は、車載装置１１８を構成する車載ゲートウェイ１４２の制御部１６０（図４参照）が、所定のプログラムをメモリ１６２から読出して実行することにより実現される。図８に示したプログラムは、図６に示した車載仲介部に対応する。なお、メモリ１６２には、サーバ１０２に返信するデータを記憶する領域（以下、返信データ領域という）が予め確保されているとする。
　ステップ４００において、制御部１６０は、サーバ１０２から返信要求（例えば所定のコマンド）を受信したか否かを判定する。上記したように、返信要求は、図７のステップ３０４においてサーバ１０２によりブロードキャストされる。受信したと判定された場合、制御はステップ４０２に移行する。そうでなければ、制御はステップ４１６に移行する。
　ステップ４０２において、制御部１６０は、ステップ４００により受信した返信要求に付加された条件のうちの収集データ種別に関する条件を満たすセンサが、当該車両に搭載されているか否かを判定する。搭載されていると判定された場合、制御はステップ４０４に移行する。そうでなければ、制御はステップ４０６に移行する。上記したように、各センサが対応するＥＣＵにより制御されることによりセンサデータが取得されるので、収集データ種別は、所望のデータを生成可能なＥＣＵが搭載されているか否かを判定することに相当する。
　ステップ４０４において、制御部１６０は、メモリ１６２の返信データ領域に第１データをセットする。その後、制御はステップ４０８に移行する。
　ステップ４０６において、制御部１６０は、メモリ１６２の返信データ領域に第１データとは異なる第２データをセットする。その後、制御はステップ４０８に移行する。
　ステップ４０８において、制御部１６０は、ステップ４００により受信した返信要求に付加された条件のうちの無線リンク状態を評価する。ステップ４０８の処理は、具体的には図９に示されている。即ち、ステップ４３０において、制御部１６０は、現在使用している通信インターフェイスを、通信部１４０（図４参照）が有する複数の無線インターフェイス（即ち無線ＩＦ）のうち、最も優先度が高いものに切替える。その後、制御はステップ４３２に移行する。最優先度インターフェイスが現在使用している通信インターフェイスであれば、そのまま維持する。また、通信部１４０が１つの無線インターフェイスしか有していなければ、現在使用している通信インターフェイスを維持する。
　無線インターフェイスの最優先度を判断する基準は、車載装置毎に予め定められていればよい。例えば、通信部１４０による実際の無線通信状態（例えば通信速度）、無線通信による消費電力、又は、サーバ１０２により統計処理されて生成され、予め配信されて車載ゲートウェイ１４２のメモリ１６２（図４参照）に記憶された情報等に基づき、基準は決定される。サーバ１０２から配信される情報には、例えば、サーバ１０２の管理対象領域における無線通信の性能、通信回線全体のトラフィック負荷、通信料金及び消費電力等が含まれる。また、通信部１４０が現在サーバ１０２と無線通信している状態であれば、その無線インターフェイスを、最優先の無線インターフェイスと判定してもよい。
　ステップ４３２において、制御部１６０は、ステップ４３０により切替えられ新たに使用される無線インターフェイスを介しての通信状態を監視する。例えば、制御部１６０は無線通信速度を算出する。
　ステップ４３４において、制御部１６０は、ステップ４３２により算出した無線通信速度が、ステップ４００により受信した返信要求に付加された選別条件のうちの無線リンク状態に関する条件を満たすか否かを判定する。満たすと判定された場合、制御はステップ４３６に移行する。そうでなければ、制御はステップ４３８に移行する。
　ステップ４３６において、制御部１６０は、メモリ１６２の返信データ領域に第３データをセットする。第３データは、第１データ及び第２データのいずれとも異なるデータである。その後、制御は図８のフローチャートに戻り、ステップ４１０に移行する。
　ステップ４３８において、制御部１６０は、ステップ４３０により切替えた無線インターフェイスとは別の無線インターフェイスを通信部１４０が有するか否かを判定する。有しないと判定された場合、制御はステップ４４０に移行する。そうでなければ、制御はステップ４４２に移行する。
　ステップ４４０において、制御部１６０は、メモリ１６２の返信データ領域に第４データをセットする。第４データは、第１～第３データのいずれとも異なるデータである。その後、制御は図８のフローチャートに戻り、ステップ４１０に移行する。
　一方、ステップ４３８の判定結果がＹＥＳの場合（即ち、通信部１４０が別の無線インターフェイスを有する場合）、ステップ４４２において、制御部１６０は、ステップ４３０と同様に、現在使用している無線インターフェイスを切替える。但し、既にステップ４３２の対象となった無線インターフェイスは除外する。その後、制御はステップ４３２に戻る。
　図８に戻り、ステップ４１０において、制御部１６０は、車両１１０の車内状態を観測する。具体的には、制御部１６０は、車両１１０内部に存在する複数のＥＣＵのうち、サーバ１０２にデータをアップロードする処理に関係するＥＣＵに関して、リソース状態（例えば、ＣＰＵの負荷状態、処理遅延時間、メモリ使用率、並びに、車両内部における通信速度及び通信負荷）を測定する。制御部１６０は、測定結果をメモリ１６２の返信データ領域に記憶する。その後、制御はステップ４１２に移行する。
　ステップ４１２において、制御部１６０は、メモリ１６２の返信データ領域に記憶されたデータを読出し、自己の車載装置ＩＤと、ステップ４００により受信した返信要求に付されたサービスＩＤとを付して、通信部１４０を介してサーバ１０２に送信する。その後、制御はステップ４１４に移行する。
　ステップ４１４において、制御部１６０は、終了するか否かを判定する。例えば、車両１１０の運転者により電力系統のオフ（例えば、車両１１０のイグニッションボタン等のオフ）が指示された場合に、終了すると判定され、本プログラムを終了する。そうでなければ、制御はステップ４００に戻る。
　一方、ステップ４００における判定結果がＮＯであった場合、ステップ４１６において、制御部１６０は、サーバ１０２にセンサデータ等をアップロードするか否かを判定する。アップロードすると判定された場合、制御はステップ４１８に移行する。そうでなければ、制御はステップ４１４に移行する。制御部１６０は、車両１１０に搭載されたセンサ部１５０（図３参照）により新たなデータ（例えば、サーバ１０２に未送信のデータ）が取得されたか否かにより、アップロードするか否かを判定する。新たなデータがあれば、アップロードすると判定する。また、一定の周期を用いてアップロードしてもよい。その場合、制御部１６０は、前回アップロードしてから所定時間が経過したか否かを判定し、経過していれば、アップロードすると判定する。
　ステップ４１８において、制御部１６０は、自己の車載装置ＩＤを付してセンサデータを、通信部１４０を介してサーバ１０２に送信（即ちアップロード）する。その後、制御はステップ４１４に移行する。
　以上により、車両１１０の車載装置１１８は、サーバ１０２から返信要求を受信すれば、それに付加された条件を満たすか否かを判定し、判定結果を、車両１１０の車内状態の観測結果と共にサーバ１０２に返信できる。これにより、図５に示した各仲介部は、受信した返信データに付されたサービスＩＤから、自己の返信要求に対する返信データであることを特定し、選別条件を満たす車載装置を特定でき、その車載装置ＩＤを、連携ネットワークを構成する要素としてメモリ１２２に記録できる。
　例えば、仲介部は、返信データに第１データ又は第３データが含まれていれば、その車載装置ＩＤを連携ネットワークの構成要素としてメモリ１２２に記録する。既に連携ネットワークの構成要素となっていれば、それを維持する。一方、仲介部は、返信データに第２データ又は第４データが含まれており、その車載装置のＩＤが連携ネットワークの構成要素になっていれば、構成要素から除外（即ち、メモリ１２２から消去）する。また、仲介部は、返信データに含まれる車内状態の観測結果（図８のステップ４１０参照）が、サービスのアプリケーションから取得した車内状態の条件（図７のステップ３０２参照）を満たすか否かを判定する。満たす場合には、仲介部は、その車載装置ＩＤを連携ネットワークの構成要素としてメモリ１２２に記録する。
　このように、サーバ１０２は、提供する各サービスに対応する連携ネットワークを構築でき、一度連携ネットワークが構築された後には、対応するサービスに応じた周期（即ち所定時間）を用いて連携ネットワークを更新できる。例えば、図１０を参照して、図１に示した複数の車両１１０～１１６の車載装置は、連携ネットワークＡ～Ｃの構成要素となる。例えば、連携ネットワークＡは、リアルタイムサービスを提供するためのネットワークであり、車両１１０及び１１２の車載装置を含む。サーバ１０２のメモリ１２２には、連携ネットワークＡの構成要素として、車両１１０及び１１２の車載装置ＩＤが記憶される。連携ネットワークＢは、準リアルタイムサービスを提供するためのネットワークであり、車両１１２及び１１４の車載装置を含む。メモリ１２２には、連携ネットワークＢの構成要素として、車両１１２及び１１４の車載装置ＩＤが記憶される。連携ネットワークＣは、非リアルタイムサービスを提供するためのネットワークであり、車両１１０～１１６の車載装置を含む。メモリ１２２には、連携ネットワークＣの構成要素として、車両１１０～１１６の車載装置ＩＤが記憶される。
　サーバ１０２は、複数の車載装置と連携してサービスを提供する場合に、各サービスの選別条件を満たす車載装置を容易に特定でき、その車載装置からアップロードされたデータを容易に使用できる。サーバ１０２は、車載装置等からデータを受信する度に、どのサービスに利用できるかを判定する必要がないので、負荷を低減でき、各サービスを提供するアプリケーションを効率的に機能させることができる。車載装置はサーバ１０２から、良好であり且つ精度の高いサービスを受けることができる。
　上記したように、車両１１０の車載装置１１８は、サーバ１０２から返信要求を受信していなければ、適宜センサデータ等をサーバ１０２に送信する。サーバ１０２は、受信したセンサデータを記憶し、解析処理部１２８等により解析することにより、運転支援情報の提供等のサービスが可能になる。
　上記したように、サービスの選別条件として、車両１１０に搭載されたセンサ部１５０の種類に関する条件を用いることにより、画像解像度等の高精度のセンサデータを送信できる車両（具体的には車載装置）を選択できる。したがって、サーバ１０２により提供される運転支援情報等の精度が高くなり、サービスの信頼性が向上する。
　上記したように、サービスの選別条件として、車載装置１１８の通信部１４０の通信状態（例えば無線リンク状態）に関する条件（即ち、通信速度及び遅延時間のうちの少なくとも１つ）を使用できる。これにより、通信速度が速く、遅延時間が短い車載装置を選択できるので、リアルタイム性の高いサービスにおける精度を向上できる。
　上記したように、サービスの選別条件として、ＥＣＵにおける、処理の負荷状態、処理遅延時間、メモリ使用率、並びに、車両内部における通信速度及び通信負荷のうちの少なくとも１つを使用できる。これにより、処理の遅延時間が短い車載装置を連携ネットワークの構成要素として選択できる。したがって、その車載装置から送信されたデータ（例えば、センサデータ等）を用いることができ、リアルタイム性の高いサービスにおける精度を向上できる。
　図７～図９に示した処理は種々変更されて実行され得る。上記では、図７に示したステップ３０４が常に実行される場合を説明した。ステップ３０２により取得した選別条件が、前回取得した選別条件から変化していない場合においても、車載装置の状態は変化し得る。また、更新時間が比較的長ければ、サーバ１０２の管理対象領域に存在する車両は変化し得る。したがって、ステップ３０２により取得した選別条件が変化していなくても、返信要求を送信することが好ましい。しかし、これに限定されない。更新周期が比較的短いサービスに対応する仲介部であれば、ステップ３０２により取得した選別条件が変化していない場合には、返信要求を送信しなくてもよい。また、選別条件の変化の有無と更新周期とを考慮して、車載装置に返信要求を送信するか否かを判定してもよい。
　上記においては、サーバ１０２から返信要求を送信し、それに対して車載装置から返信データを送信する場合を説明したが、これに限定されない。各車載装置が、自発的に、収集データ種別、無線リンク状態及び車両状態をサーバ１０２に送信してもよい。
　上記においては、図７に示したステップ３０６において、仲介部が返信データを記憶する場合を説明したが、これに限定されない。車載装置からの返信データは、どの仲介部が送信した返信要求に対するものであるかに拘わらず、メモリ１２２に記憶されればよいので、別のプログラムによりメモリ１２２に記憶されてもよい。返信データであるか否かは、サーバ１０２が受信したデータにサービスＩＤが含まれているか否かにより判定できる。そのようにすれば、各仲介部が、自己が送信した返信要求に対する返信データであるか否かを判定する必要がなく、効率的である。
　上記においては、車載装置から車内状態の観測結果をサーバに送信し、サーバ（具体的には仲介部）において、サービスの選別条件のうちの車内状態の条件を満たすか否かを判定する場合を説明したが、これに限定されない。サーバから車載装置に送信する要求に車内状態の条件を含めておけば、車載装置がその条件を満たすか否かを判定し、判定結果をサーバに送信してもよい。そのようにすれば、複数の仲介部（即ちソフトウェア）を並列して実行するサーバの負荷を軽減できる。
　以上、実施の形態を説明することにより本開示を説明したが、上記した実施の形態は例示であって、本開示は上記した実施の形態のみに制限されるわけではない。本開示の範囲は、発明の詳細な説明の記載を参酌した上で、請求の範囲の各請求項によって示され、そこに記載された文言と均等の意味及び範囲内での全ての変更を含む。
１００　　連携システム
１０２　　サーバ
１０４　　基地局
１０６　　インフラセンサ
１１０、１１２、１１４、１１６　　車両
１１８　　車載装置
１２０、１６０　　制御部
１２２、１６２　　メモリ
１２４、１４０　　通信部
１２６　　タイマ
１２８　　解析処理部
１３０　　操作部
１３２、１４８　　バス
１４２　　車載ゲートウェイ
１４４　　第１ＥＣＵ
１４６　　第ｎＥＣＵ
１５０　　センサ部
１６４　　バッファ
３００、３０２、３０４、３０６、３０８、３１０、４００、４０２、４０４、４０６、４０８、４１０、４１２、４１４、４１６、４１８、４３０、４３２、４３４、４３６、４３８、４４０、４４２　　ステップ
Ａ、Ｂ、Ｃ　　連携ネットワーク

Claims (9)

  1. 　サーバと通信する車載装置であって、
    　当該車載装置が搭載された車両の機能の実行を制御する機能制御部と、
    　前記サーバから、前記サーバにより提供されるサービスを前記車載装置が実現するために前記車載装置が処理対象とする被処理データを前記車載装置が選別するための選別条件が付された返信要求を受信し、且つ、前記サーバに前記返信要求に対する返信データを送信する車載通信部と、
    　前記選別条件が満たされるか否かを判定する車載仲介部とを含み、
    　前記車載仲介部は、前記車両に搭載されたセンサ、前記車載通信部による前記車両の外部との通信状態、及び、前記機能制御部の状態の少なくともいずれか１つが前記選別条件を満たすか否かを判定し、
    　前記車載通信部は、前記車載仲介部による判定の結果を、前記返信データとして前記サーバに送信する、車載装置。
  2. 　前記車載通信部はさらに、前記センサにより取得されたセンサデータを前記サーバに送信し、
    　前記被処理データは、前記センサデータを含む、請求項１に記載の車載装置。
  3. 　前記車載仲介部は、前記センサが前記選別条件を満たすか否かを判定し、
    　前記選別条件は、前記センサの種類に関する条件を含む、請求項１又は請求項２に記載の車載装置。
  4. 　前記車載仲介部は、前記車載通信部の前記通信状態が前記選別条件を満たすか否かを判定し、
    　前記選別条件は、通信速度及び遅延時間のうちの少なくとも１つに関する条件を含む、請求項１から請求項３のいずれか１項に記載の車載装置。
  5. 　前記車載仲介部は、前記機能制御部の状態が前記選別条件を満たすか否かを判定し、
    　前記選別条件は、前記機能制御部における、処理の負荷状態、処理遅延時間、メモリ使用率、並びに、前記車両の内部における通信速度及び通信負荷のうちの少なくとも１つに関する条件を含む、請求項１から請求項４のいずれか１項に記載の車載装置。
  6. 　請求項１から請求項５のいずれかに記載の複数の前記車載装置に、前記返信要求を送信し、前記返信データを受信する通信部と、
    　複数の前記車載装置の中から、前記返信データに基づいて前記選別条件を満たす前記車載装置を特定する仲介部とを含む、サーバ。
  7. 　前記サーバは、前記車載装置により実行される複数のサービスに用いる情報を提供し、
    　前記仲介部は、
    　　前記選別条件を満たすとして特定した前記車載装置と、前記複数のサービスのうち、前記選別条件に対応するサービスとを対応させ、
    　　対応させた前記車載装置及び前記サービスを表す情報をネットワーク構成データとして記憶する、請求項６に記載のサーバ。
  8. 　前記仲介部は、前記複数のサービスの各々に応じた更新周期において、前記選別条件を満たす前記車載装置を特定し、前記ネットワーク構成データを更新する、請求項７に記載のサーバ。
  9. 　複数の車載装置と、
    　サーバとを含み、
    　前記サーバは、
    　　前記複数の車載装置の各々に、前記サーバにより提供されるサービスを当該車載装置が実現するために当該車載装置が処理対象とする被処理データを当該車載装置が選別するための条件である選別条件を付した返信要求を送信し、且つ、当該車載装置から前記返信要求に対する返信データを受信する通信部と、
    　　前記複数の車載装置の中から、前記返信データに基づいて前記選別条件を満たす前記車載装置を特定する仲介部とを含み、
    　前記複数の車載装置の各々は、
    　　当該車載装置が搭載された車両の機能の実行を制御する機能制御部と、
    　　前記サーバから前記返信要求を受信し、且つ、前記サーバに前記返信データを送信する車載通信部と、
    　　前記選別条件が満たされるか否かを判定する車載仲介部とを含み、
    　前記車載仲介部は、当該車載仲介部を含む前記車載装置が搭載された前記車両に搭載されたセンサ、当該車載装置の前記車載通信部による当該車両の外部との通信状態、及び、当該車載装置の前記機能制御部の状態の少なくともいずれか１つが前記選別条件を満たすか否かを判定し、
    　前記車載通信部は、当該車載通信部を含む前記車載装置の前記車載仲介部による判定の結果を前記返信データとして前記サーバに送信する、システム。
PCT/JP2022/019003 2021-07-02 2022-04-27 車載装置、サーバ及びシステム WO2023276435A1 (ja)

Applications Claiming Priority (2)

Application Number Priority Date Filing Date Title
JP2021-110428 2021-07-02
JP2021110428 2021-07-02

Publications (1)

Publication Number Publication Date
WO2023276435A1 true WO2023276435A1 (ja) 2023-01-05

Family

ID=84692693

Family Applications (1)

Application Number Title Priority Date Filing Date
PCT/JP2022/019003 WO2023276435A1 (ja) 2021-07-02 2022-04-27 車載装置、サーバ及びシステム

Country Status (1)

Country Link
WO (1) WO2023276435A1 (ja)

Citations (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JP2018136754A (ja) * 2017-02-22 2018-08-30 株式会社日立製作所 情報処理装置、モビリティデータ収集システム
WO2020111133A1 (ja) * 2018-11-29 2020-06-04 住友電気工業株式会社 交通支援システム、サーバ及び方法、車載装置及びその動作方法、コンピュータプログラム、記録媒体、コンピュータ、並びに半導体集積回路

Patent Citations (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JP2018136754A (ja) * 2017-02-22 2018-08-30 株式会社日立製作所 情報処理装置、モビリティデータ収集システム
WO2020111133A1 (ja) * 2018-11-29 2020-06-04 住友電気工業株式会社 交通支援システム、サーバ及び方法、車載装置及びその動作方法、コンピュータプログラム、記録媒体、コンピュータ、並びに半導体集積回路

Similar Documents

Publication Publication Date Title
JP7484721B2 (ja) システム、サーバコンピュータ、車載装置、制御方法、半導体集積回路及びコンピュータプログラム
KR102353558B1 (ko) 통신 파트너 국, 이동국 및 차량에 대한 계획된 분산 무선 통신의 채널 품질을 예측하도록 제1 이동국을 지원하는 방법
EP3347886B1 (en) Methods and devices for requesting and providing information
US10567251B2 (en) Accurate mobile traffic information acquisition with minimal transmission cost and optional V2V extension
JP7396268B2 (ja) 運転支援のためのシステム、車載装置、方法及びコンピュータプログラム
EP3809647B1 (en) Network management device, method and program
WO2021171828A1 (ja) 車内外連携装置及び方法
JP2008199381A (ja) 移動体通信システム
CN111866941B (zh) 一种网络资源调度方法及相关设备
KR102206559B1 (ko) 데이터를 캡처 및 전송하기 위한 장치, 방법, 및 컴퓨터 프로그램
JP2019176311A (ja) 車載装置、その制御方法及びコンピュータプログラム
JP6020798B2 (ja) センシングデータ提供システム
WO2019187041A1 (ja) システム、そのサーバコンピュータ、制御方法及びコンピュータプログラム
JP7293849B2 (ja) 情報転送装置、車載装置、システム、情報転送方法及びコンピュータプログラム
US10154393B2 (en) Method, motor vehicle, and system for determining a transmission path
KR102555082B1 (ko) 셀룰러 모바일 통신 시스템의 기지국과 적어도 하나의 이동 통신 파트너 사이의 통신을 관리하기 위한 방법 및 장치, 컴퓨터 프로그램, 상기 방법의 단계를 수행하기 위한 장치, 및 차량
WO2023276435A1 (ja) 車載装置、サーバ及びシステム
US11400957B2 (en) Control device and control method of vehicle environment data transmission
CN112533172B (zh) 信息传输方法和信息传输装置
CN114051633A (zh) 收集基于车辆的、涉及地点的数据集
JP2020184673A (ja) 車載装置、システム、制御方法、半導体集積回路及びコンピュータプログラム
WO2023058305A1 (ja) 車載装置、集約装置、車載システム、サーバコンピュータ、制御方法及びコンピュータプログラム
WO2024024223A1 (ja) 車載装置、制御方法およびコンピュータプログラム
JP7292552B2 (ja) 運転支援システム、サーバ装置、制御回路、記憶媒体、プログラムおよび運転支援情報生成方法
JP7331399B2 (ja) センサ設備装置及びその制御方法、車載装置及びその制御方法、並びに交通支援システム

Legal Events

Date Code Title Description
121 Ep: the epo has been informed by wipo that ep was designated in this application

Ref document number: 22832595

Country of ref document: EP

Kind code of ref document: A1

NENP Non-entry into the national phase

Ref country code: DE