Vehicle data-collection system, on-vehicle device, and program

Abstract

This vehicle data-collection system (DCS) includes: a driving support device (10) as an on-vehicle device mounted on a vehicle (1) that can participate in public road traffic; and a server (20) that is communicably connected to the vehicle (1) and collects vehicle data from the vehicle (1). The server (20) executes transmission of instruction information for instructing the vehicle data to be collected to the vehicle (1). The driving support device (10) is configured to execute: setting, on the basis of the instruction information, a condition for transmitting the vehicle data such that a review process of the instruction by the instruction information is included; and determining to transmit the vehicle data acquired in accordance with the condition to the server (20).

Description

Vehicle data collection system, on-board device and program CROSS-REFERENCE TO RELATED APPLICATIONS

[0001] This application is based on Patent Application No. 2024-91012 filed in Japan on June 4, 2024, the contents of which are incorporated by reference in their entirety.

[0002] TECHNICAL FIELD The disclosure herein relates to techniques for collecting data from vehicles that may participate in public road traffic.

[0003] Patent Document 1 discloses that a computing device in a server collects vehicle data from vehicles that can participate in public road traffic in accordance with a data collection policy included in the computing device.

[0004] US Patent Application Publication No. 2022 / 0204010

[0005] However, when collecting data from vehicles, there are limitations on the communication path capacity, and there are also limitations on the processing power and storage capacity of the server or vehicle. For these reasons, it may be difficult to collect vehicle data in accordance with the data collection policy, and as a result, the efficiency of data collection may decrease.

[0006] One of the purposes of the disclosure of this specification is to provide a vehicle data collection system, an in-vehicle device, and a program that can efficiently collect vehicle data.

[0007] One aspect disclosed herein is a vehicle data collection system including an on-board device mounted on a vehicle capable of participating in public road traffic, and a server communicatively connected to the vehicle and collecting vehicle data from the vehicle, wherein the server performs the following: transmitting instruction information to the vehicle indicating the vehicle data to be collected; and the on-board device is configured to perform the following: based on the instruction information, setting conditions for transmitting vehicle data to include a review process of the instructions given by the instruction information; and determining to transmit the vehicle data obtained in accordance with the conditions to the server.

[0008] Another disclosed aspect is an apparatus having at least one processor, which is mounted on a vehicle capable of participating in public road traffic and is communicatively connected to a server that collects vehicle data from the vehicle, and the at least one processor is configured to: acquire instruction information from the server that indicates the vehicle data to be collected; based on the instruction information, set conditions for transmitting the vehicle data to include a review process of the instructions given by the instruction information; and decide to transmit the vehicle data acquired in accordance with the conditions to the server.

[0009] Another disclosed aspect is a program used in an on-board device that is mounted on a vehicle capable of participating in public road traffic and is communicatively connected to a server that collects vehicle data from the vehicle, and causes at least one processor to: acquire instruction information from the server that indicates the vehicle data to be collected; set conditions for transmitting the vehicle data based on the instruction information so as to include a review process of the instructions given by the instruction information; and decide to transmit the vehicle data acquired in accordance with the conditions to the server.

[0010] According to these aspects, the instructions based on the instruction information from the server are reviewed by the vehicle side. That is, the conditions for transmitting vehicle data from the vehicle side to the server side can be flexibly changed in accordance with various restrictions. Therefore, it is possible to efficiently collect vehicle data.

[0011] Note that the symbols in parentheses included in the claims etc. are intended to exemplify the correspondence with the parts of the embodiments described below, and are not intended to limit the technical scope.

[0012] 1 is a diagram schematically showing a hardware configuration of a vehicle data collection system. 2 is a diagram schematically showing a functional configuration of a vehicle data collection system. 3 is a diagram explaining an example of instruction information. 4 is a flowchart illustrating a process related to data collection. 5 is a flowchart illustrating a process related to data collection. 6 is a flowchart illustrating a process related to data collection. 7 is a flowchart illustrating a process related to data collection. 8 is a diagram explaining an example of instruction information. 9 is a flowchart illustrating a process related to data collection. 10 is a flowchart illustrating a process related to data collection. 11 is a diagram explaining a driving assistance device. 12 is a flowchart illustrating a process related to data collection.

[0013] Hereinafter, several embodiments will be described with reference to the drawings. Note that corresponding components in each embodiment are given the same reference numerals, and redundant description may be omitted. When only a portion of the configuration is described in each embodiment, the configuration of another embodiment described previously can be applied to the remaining portion of the configuration. Furthermore, in addition to the combinations of configurations explicitly stated in the description of each embodiment, configurations of several embodiments can also be partially combined together even if not explicitly stated, as long as there is no particular problem with the combination.

[0014] (First Embodiment) A vehicle data collection system DCS of a first embodiment shown in Fig. 1 collects data from a vehicle 1. The collected data is used, for example, to develop the hardware of the vehicle 1 or applications used in the vehicle 1. The collected data may be used for urban planning, such as improving traffic signal control and road infrastructure. The collected data may also be used for planning the opening of commercial facilities, etc.

[0015] Vehicle 1 is a vehicle capable of participating in public road traffic. Vehicle 1 may be, for example, a four-wheeled automobile, truck, or other vehicle that can be manually driven by a driver. Vehicle 1 may also be capable of automated driving. The automation level of vehicle 1 is classified into levels 1 to 5, for example, as defined in SAE J3016. Vehicle 1 may be capable of driving at any of these levels.

[0016] At levels 0 to 2, the driver performs some or all of the dynamic driving task. Levels 0 to 2 may be classified as so-called manual driving. Level 0 indicates that driving is not automated. Level 1 indicates that the driver is assisted by the driving assistance device 10. Level 2 indicates that driving is partially automated. Levels 3 to 5 may be classified as so-called automated driving. Level 3 indicates that driving is conditionally automated. Level 4 indicates that driving is highly automated. Level 5 indicates that driving is fully automated.

[0017] The vehicle data collection system DCS includes a driving assistance device 10 and a server 20. The vehicle data collection system DCS may further include a development computer 30. Although one vehicle 1 and its driving assistance device 10 will be described below, the vehicle data collection system DCS may also be configured to collect data from multiple vehicles 1. In other words, the vehicle data collection system DCS may include multiple driving assistance devices 10 that individually correspond to each vehicle 1.

[0018] The vehicle data collection system DCS is suitable for collecting vehicle data in long-tail cases encountered by vehicles 1 that can participate in public road traffic. Long-tail cases are cases that cannot be covered by development in a closed environment. Collecting vehicle data in long-tail cases can improve the coverage of applications and their functions in real environments.

[0019] The driving assistance device 10 is an in-vehicle device that is mounted on the vehicle 1 and assists in driving the vehicle 1. The driving assistance device 10 may be capable of realizing driving at automation levels 1 to 2, or may be capable of realizing driving at automation level 3 or higher.

[0020] The driving assistance device 10 may be, for example, an ECU (Electronic Control Unit) mainly composed of a computer. The computer constituting the driving assistance device 10 has at least one memory 10a and one processor 10b. The memory 10a may be at least one type of non-transient physical storage medium, such as a semiconductor memory, a magnetic medium, or an optical medium, that non-temporarily stores computer programs and data that can be read by the processor 10b. Furthermore, the memory 10a may be provided with a rewritable volatile storage medium, such as a RAM (Random Access Memory). The processor 10b may include at least one type of core, such as a CPU (Central Processing Unit), a GPU (Graphics Processing Unit), or a RISC (Reduced Instruction Set Computer)-CPU. The computer further includes an interface 10c for exchanging data with the outside.

[0021] The computer constituting the driving assistance device 10 may be a SoC (System on a Chip) in which the memory 10a, processor 10b, and interface 10c are integrated into a single chip, or may have at least one SoC as a component of a dedicated computer.

[0022] The driving assistance device 10 also includes a storage 10d for recording data of the vehicle 1 (hereinafter referred to as vehicle data), particularly data related to driving. The storage 10d is a rewritable non-volatile storage medium such as a semiconductor memory, a magnetic medium, or an optical medium. The storage 10d has a storage area with a finite storage capacity. The driving assistance device 10 is configured to transmit the vehicle data stored in the storage 10d to a server 20 using a DCM (Data Communication Module) 11.

[0023] The DCM 11 is a communication module mounted on the vehicle 1. The DCM 11 transmits and receives radio waves to and from base stations around the vehicle 1 through wireless communication conforming to communication standards such as LTE (Long Term Evolution) and 5G. By mounting the DCM 11, the vehicle 1 becomes a connected car that can connect to the Internet. The DCM 11 also cooperates with the driving assistance device 10 to transmit vehicle data to the server 20.

[0024] The server 20 is installed in an external environment relative to the vehicle 1. The server 20 is configured to be able to collect vehicle data generated by the driving assistance device 10 by being connected to the Internet, for example.

[0025] The server 20 may be configured by a single processing device or may be a cloud server. A cloud server is a server on a network realized by cloud computing, and is realized by multiple processing devices located in remote locations apart from each other.

[0026] The processing device of the server 20 is primarily composed of a computer. The computer constituting the processing device has at least one memory 20a and one processor 20b. The memory 20a may be at least one type of non-transient tangible storage medium, such as a semiconductor memory, a magnetic medium, or an optical medium, that non-temporarily stores computer programs and data that can be read by the processor 20b. Furthermore, the memory 20a may be provided with a rewritable volatile storage medium, such as a random access memory (RAM). The processor 20b may include at least one type of core, such as a central processing unit (CPU), a graphics processing unit (GPU), or a reduced instruction set computer (RISC)-CPU. Furthermore, the computer includes an interface 20c for exchanging data with the outside world, and storage 20d.

[0027] The storage 20d is a rewritable non-volatile storage medium such as a semiconductor memory, a magnetic medium, or an optical medium. The storage 20d has a limited storage area with a much larger storage capacity than the storage 20d of the driving assistance device 10. The server 20 stores the vehicle data collected from the vehicle 1 in the storage 20d.

[0028] The development computer 30 is a development device provided in the external environment of the vehicle 1. The development computer may be, for example, a personal computer operated by a developer of the vehicle 1 or the driving assistance device 10. The developer is, for example, an engineer who is knowledgeable about vehicle control and software.

[0029] The development computer 30 has at least one memory 30a and one processor 30b. The memory 30a may be at least one type of non-transient tangible storage medium, such as a semiconductor memory, a magnetic medium, or an optical medium, that non-temporarily stores computer programs and data that can be read by the processor 30b. Furthermore, the memory 10a may be a rewritable volatile storage medium, such as a random access memory (RAM). The processor 10b may include at least one type of core, such as a central processing unit (CPU), a graphics processing unit (GPU), or a reduced instruction set computer (RISC)-CPU.

[0030] Furthermore, development computer 30 includes interface 30c for exchanging data with the outside. Interface 30c includes a communications interface for connecting development computer 30 to the Internet, and an operation interface for inputting signals and operating devices such as a keyboard and mouse for accepting operations from the developer. Development computer 30 is communicably connected to server 20, and is able to exchange data required for development by the developer.

[0031] Next, an example of a logical architecture in the vehicle data collection system DCS will be described with reference to FIG.

[0032] The driving assistance device 10 may include a trigger management unit V1, a current application control unit V2, a development application control unit V3, and a storage and transmission unit V4 as processing units realized by the processor 10b executing a computer program stored in the memory 10a.

[0033] The server 20 may include a development application distribution unit C1, an instruction setting unit C2, and a data management unit C3 as processing units realized by the processor 20b executing a computer program stored in the memory 20a.

[0034] The development computer 30 may include a scene extraction unit D1, a labeling unit D2, a machine learning unit D3, a verification unit D4, and an upload unit D5 as processing units realized by the processor 30b executing a computer program stored in the memory 30a.

[0035] Each processing unit will be described in detail below. The trigger management unit V1 acquires, from the instruction setting unit C2, acquisition instruction information that indicates the vehicle data to be collected in the vehicle 1, using the DCM 11. Based on the acquisition instruction information, the trigger management unit V1 sets a trigger condition that serves as a trigger for recording and transmitting the vehicle data. The trigger condition may be the condition specified by the acquisition instruction information (hereinafter referred to as the instruction condition), or may be a changed condition that has been changed by a review process of the instruction condition.

[0036] While the vehicle is in use, the trigger management unit V1 successively determines whether the trigger condition is currently satisfied. As a result, if the state transitions from a state in which the trigger condition is not satisfied to a state in which the trigger condition is satisfied, the trigger management unit V1 requests the current application control unit V2 and the development application control unit V3 to start acquiring and recording vehicle data. As a result, if the state transitions from a state in which the trigger condition is satisfied to a state in which the trigger condition is not satisfied, the trigger management unit V1 requests the current application control unit V2 and the development application control unit V3 to stop acquiring and recording vehicle data. Note that the trigger condition here may basically be the same for both the current application control unit V2 and the development application control unit V3. However, different conditions may also be set.

[0037] The current application control unit V2 controls the current application, which is an application officially used to control the current vehicle 1. The application here may be a software unit that is operated by one or more pieces of software and realizes a specific function. An application that realizes a driving-related function may be, for example, an ADAS (Advanced Driver-Assistance Systems) application. Examples of ADAS applications include an Adaptive Cruise Control (ACC) application, a Lane Keeping Assist (LKA) application, a Pre-Crush Safety (PCS) application, and a Blind Spot Monitor (BSM) application.

[0038] Furthermore, the application that realizes a driving-related function may be an automated driving application. The automated driving application may be, for example, a planning application that autonomously plans vehicle behavior, or a risk confirmation application that confirms risks during automated driving.

[0039] The application may be an application that realizes a function related to an HMI (Human Machine Interface). For example, the application that realizes a function related to an HMI may be an application that provides a display or a warning, or an application that allows the driver to operate and set the air conditioning or the like.

[0040] The current application control unit V2 starts and operates the current application based on an operation by the occupant to enable the current application, etc. The current application control unit V2 may monitor the operation of the current application and diagnose an abnormality in the current application. If the current application control unit V2 detects an abnormality, it may forcibly terminate the current application or may decide to warn the driver of the abnormality using an HMI installed in the vehicle 1. Note that the abnormality here may be a malfunction, and may be represented by a malfunction code defined by OBD2 (On Board Diagnosis 2) or the like.

[0041] The current application control unit V2 also receives a request to record vehicle data from the trigger management unit V1. If a recording request has been received, the current application control unit V2 acquires the vehicle data requested to be recorded and related to the operation of the current application, and requests that the data be recorded in the storage and transmission unit V4.

[0042] The vehicle data related to the operation of an application may be, for example, a result output by the application to achieve its function. For example, in the case of an LKA, the output result may be the steering amount for turning a curve along a lane marking. The vehicle data related to the operation of an application may be, for example, a parameter indicating the vehicle state when the vehicle is controlled in accordance with the result output by the application to achieve its function. For example, in the case of an LKA, the parameter indicating the vehicle state may be the vehicle speed, yaw rate, noise, vehicle vibration, etc. when the vehicle is controlled in accordance with the steering amount that is the output result.

[0043] The vehicle data related to the operation of the application may be, for example, data about the external environment recognized by an autonomous sensor of the vehicle 1 when the vehicle is controlled, corresponding to the result output by the application to achieve its function. The autonomous sensor may be, for example, a camera, millimeter-wave radar, LiDAR (Light Detection and Ranging / Laser Imaging Detection and Ranging), sonar, etc. The data about the external environment may include the recognition results of other vehicles, pedestrians, etc. around the vehicle 1, road conditions, etc.

[0044] The vehicle data related to the operation of the application may also be the above-mentioned fault code, or information about the scene where the abnormality occurred.

[0045] The development application control unit V3 controls a development application, which is an application under development and distributed from the server 20. The development application may be an application that is an improvement of a current application having similar functions, or may be an application with more advanced functions than the current application.

[0046] The development application control unit V3 operates the development application in a special mode, such as a shadow mode, a ghost mode, etc. In other words, the development application is tested under the special mode operation.

[0047] Shadow mode is a mode in which a development application runs in parallel with the current application behind the scenes, for example, when autonomous driving is in operation. Shadow mode runs the development application so that vehicle data related to the operation of the development application can be obtained in real time without activating the actual vehicle control function of the development application. Shadow mode makes it possible to evaluate the performance and behavior of the development application while restricting the impact on actual vehicle control and the driver.

[0048] Ghost mode is a mode in which a development application runs in parallel behind the scenes while, for example, a driver is actually driving. The development application here is an application that provides an automated driving function with an automation level of 3 or higher. In ghost mode, the driver's actions and the behavior of the vehicle 1 are tracked, and information on the performance of the development application can be collected by comparing the driver's driving with the behavior of the automated driving function. In ghost mode, differences between the driver's driving and the behavior of the automated driving function are evaluated, and improvements to the development application can be identified.

[0049] If the development application is an improved version of the current application, the development application control unit V3 may start and operate the development application so as to link with the current application based on an operation by the occupant to enable the current application, etc. However, as described above, unlike the current application, the output of the development application is not reflected in the actuators and HMI of the vehicle 1.

[0050] The development application control unit V3 may monitor the operation of the development application and diagnose any abnormalities in the development application. However, because the output of the development application does not affect vehicle control, the development application control unit V3 may not forcibly terminate the development application when it detects an abnormality, and may decide not to warn the driver of the abnormality using the HMI installed in the vehicle 1.

[0051] The development application control unit V3 also receives a request to record vehicle data from the trigger management unit V1. If a recording request has been received, the development application control unit V3 acquires the vehicle data requested to be recorded and that is related to the operation of the development application, and requests that the data be recorded in the storage and transmission unit V4.

[0052] The storage and transmission unit V4 sequentially records the requested vehicle data in the storage 10d in response to recording requests from the current application control unit V2 and the development application control unit V3. This recording may be temporary storage until the vehicle data is transmitted.

[0053] Before recording data to the storage 10d, the storage transmission unit V4 checks the remaining storage capacity of the storage 10d (hereinafter referred to as the remaining storage capacity). If the remaining storage capacity is greater than a preset threshold, the storage transmission unit V4 records the requested vehicle data. If the remaining storage capacity is equal to or less than the preset threshold, the storage transmission unit V4 deletes some or all of the data already stored in the storage 10d in order to record the requested vehicle data.

[0054] Furthermore, the storage transmission unit V4 transmits the data recorded in the storage 10d to the server 20 via the DCM 11. The data transmission may be performed at a timing that depends on the storage capacity, the communication environment of the vehicle 1, etc. The storage transmission unit V4 deletes the vehicle data that has been transmitted to the server 20 from the storage 10d.

[0055] In the server 20, the data management unit C3 manages the vehicle data transmitted from the vehicle 1. Specifically, the data management unit C3 sequentially stores in the storage 20d the vehicle data transmitted from the storage transmission unit V4 of the vehicle 1. When the server 20 is communicably connected to a plurality of vehicles 1 and collects vehicle data from the plurality of vehicles 1, the vehicle data transmitted from the plurality of vehicles 1 may be sequentially stored in a mixed state in the same storage 20d.

[0056] Furthermore, in response to a download request from development computer 30, data management unit C3 transmits vehicle data stored in storage 20d to development computer 30. The vehicle data transmitted at this time may be data corresponding to the download request, or may be all or a portion of the data stored in storage 20d.

[0057] In the development computer 30, at least one of the scene extraction unit D1 and the labeling unit D2 requests a download from the server 20. When the server 20 provides vehicle data in response to the download request, the scene extraction unit D1 and the labeling unit D2 classify the large amount of vehicle data. The scene extraction unit D1 extracts, from the vehicle data, vehicle data related to scenes required for verifying the development application. The extracted scenes may be scenes specified by the developer through input operations on the interface 30c, etc. The scenes here may be replaced with scenarios represented by a sequence of scenes that define a situation at a given moment.

[0058] The labeling unit D2 labels the downloaded vehicle data. The labeling here may be adding or associating information about the scene extracted based on the processing by the scene extraction unit D1 to the corresponding vehicle data. The labeling here may also be labeling of other information.

[0059] The vehicle data classified by the scene extraction unit D1 and the labeling unit D2 in this manner is used by the machine learning unit D3. The machine learning unit D3 performs machine learning using the vehicle data. The machine learning here may involve optimizing a model used in the development application and configured mainly using a neural network or the like, using the vehicle data. The development application can be further improved by the machine learning unit D3.

[0060] The verification unit D4 executes a process for verifying the improved developed application. The verification process here may be offline or online. The verification process here may be an autonomous verification without the involvement of the developer, in which a conclusion is reached as to whether the developed application has any defects through the processing of a verification program stored in memory 30a. The verification here may involve outputting verification data required for the developer to perform the verification through the processing of the verification program stored in memory 30a.

[0061] Based on the results of the verification using the verification unit D4, the developer may decide to use the developed application that has been tested on the driving assistance device 10 as is, or may decide to improve the developed application and test it again on the driving assistance device 10. In the latter case, the developer uses the functions of the upload unit D5.

[0062] The upload unit D5 uploads the development application created by the developer to the server 20. The upload unit D5 may further upload a data collection plan associated with the development application. The data collection plan may include the type of vehicle data to be collected in testing the development application and the scale of the vehicle data. The scale may include the number of vehicles from which vehicle data is to be collected, or the total number of specific vehicle data required to be acquired. The data collection plan may further include information for identifying the vehicles 1 from which data is to be collected. This information may, for example, directly and individually specify the vehicles from which data is to be collected, or may be specified by setting conditions such as vehicle type. When the vehicles from which data is to be collected are individually specified, the data collection plan may include the instruction information itself, as described below.

[0063] The data collection plan may be set by the developer through input operations into the interface 30c, or may be generated by the upload unit D5.

[0064] The development application distribution unit C1 in the server 20 identifies the vehicles 1 from which data will be collected based on the data collection plan. The development application distribution unit C1 distributes the development application received from the development computer 30 to the identified vehicles 1.

[0065] In the server 20, the instruction setting unit C2 sets collection instructions for each vehicle 1 that is a target for data collection and that is identified by the development application distribution unit C1 based on the data collection plan, and generates acquisition instruction information for sharing the instructions. The instruction setting unit C2 distributes the generated acquisition instruction information to each vehicle 1. The distribution of the development application and the acquisition instruction information may be performed at the same time or at different times.

[0066] Here, an example of instruction information for collecting specific vehicle data that may be distributed to a vehicle 1 will be described. The instruction information may include information that identifies the vehicle data to be acquired and acquisition instruction information associated with this information. As shown in FIG. 3, the acquisition instruction information may include, for example, a scene for which vehicle data should be acquired, a required number of vehicle data to be acquired for that scene, and a relative priority of that scene with respect to other scenes. The required number is the number of times vehicle data should be acquired. The priority may be a priority expressed, for example, as a natural number n. Note that some of the scene, required number, and priority may not be set in the acquisition instruction information.

[0067] Next, an example of a processing method by the vehicle data collection system DCS will be described using the flowchart in Figure 4. Steps S1 to S8 in this flowchart outline the overall processing flow. The series of processes in S1 to S8 may be realized, for example, by the processors 10b, 20b, and 30b of the driving assistance device 10, the server 20, and the development computer 30 executing computer programs stored in the memories 10a, 20a, and 30a.

[0068] In S1, the development computer 30 uploads the development application and data collection plan to the server 20.

[0069] In S2 after the processing of S1, the server 20 generates acquisition instruction information for each vehicle 1 based on the data collection plan. In S3 after the processing of S2, the server 20 distributes the developed application and the acquisition instruction information to each vehicle.

[0070] In S4 after processing S3, the driving assistance device 10 in each vehicle 1 sets a trigger condition, which is a condition that triggers starting to acquire and record vehicle data, based on the acquisition instruction information. In S5 after processing S4, the driving assistance device 10 acquires and records vehicle data based on the trigger condition. In S6 after processing S5, the driving assistance device 10 uploads the vehicle data to the server 20.

[0071] In S7 after the processing of S6, the development computer 30 downloads the vehicle data uploaded to the server 20 and executes processing to classify the vehicle data. In S8 after the processing of S7, the development computer 30 executes processing to verify the development application based on the classified vehicle data. The series of processes ends with S8.

[0072] Next, a more detailed example of a vehicle data processing method that can be employed in the driving assistance device 10, particularly the processing related to S4 to S5 in FIG. 4, will be described using the flowcharts of FIGS.

[0073] The processing method shown as S101 to S104 in the flowchart of FIG. 5 is a processing method for reviewing the instruction conditions based on the acquisition instruction information transmitted from the server 20 and setting the final trigger conditions.

[0074] In S101, the trigger management unit V1 determines whether or not a priority instruction is present in the acquisition instruction information. If the answer is Yes, the process proceeds to S102. If the answer is No, the process proceeds to S103.

[0075] In S102, the trigger management unit V1 sets trigger conditions according to the priority specified in the acquisition instruction information. The setting of trigger conditions as in S102 may be referred to as static setting. After the processing of S103, the process proceeds to S104.

[0076] In S103, the trigger management unit V1 sets a trigger condition according to the situation on the vehicle 1 side. After the processing of S103, the process proceeds to S104. Here, a first example and a second example will be described as specific processing of S103.

[0077] In a first example, the trigger management unit V1 sets a trigger condition such that the priority between scenes is changed as needed according to the current data acquisition rate. Specifically, the trigger management unit V1 calculates the data acquisition rate for each scene defined in the acquisition instruction information by dividing the current number of acquired data by the required number. The trigger management unit V1 assigns the highest priority to the scene with the lowest current data acquisition rate. The trigger management unit V1 assigns higher priorities to scenes with the lowest current data acquisition rate. The trigger management unit V1 assigns the lowest priority to the scene with the highest current data acquisition rate. Setting of trigger conditions in this manner may be referred to as dynamic setting.

[0078] In a second example, the trigger management unit V1 sets priorities between scenes based on at least one of the driving area of ​​the vehicle 1, driving time, attributes of the vehicle 1, and attributes of the driver. The attributes of the vehicle 1 include, for example, the type of the vehicle 1 (passenger car, truck, etc.) and the model of the vehicle 1. The attributes of the driver include, for example, the gender, age, driving skills, etc. of the driver. Setting of such trigger conditions may be referred to as semi-dynamic setting.

[0079] In S104 after processing S102 or S103, the trigger management unit V1, current application control unit V2, development application control unit V3, and storage and transmission unit V4 acquire and record vehicle data based on the set trigger conditions. Here, if the first example is adopted, the priority is calculated each time even during the processing of S104. If the second example is adopted, the priority is recalculated when the classification of the driving area, etc. is changed, etc. The series of processes ends with S104.

[0080] The processing method shown as S201 to S206 in the flowchart of Fig. 6 is a processing method for acquiring data based on the priority set in the trigger condition. This processing method can be said to show details of S104 shown in Fig. 5.

[0081] First, in step S201, the trigger management unit V1 determines whether or not there is a priority between scenes based on the trigger conditions. If the result is Yes, the process proceeds to step S202. If the result is No, the process proceeds to step S206.

[0082] In S202, the trigger management unit V1 sets the natural number n, which indicates the priority, to 1. In S203 after processing S202, vehicle data corresponding to the set priority n is acquired. Then, the current application control unit V2 and the development application control unit V3 each acquire vehicle data related to the operation of the application. The acquired data is stored in the storage 10d as described above. In this way, acquisition of vehicle data continues until the required number set for the scene of priority n is reached. When the required number is reached, processing of S203 ends and the process proceeds to S204.

[0083] In S204, the trigger management unit V1 determines whether a scene with priority n+1 exists in the acquisition instruction information. If priorities are specified for all scenes included in the acquisition instruction information, this determination essentially becomes a determination of whether all vehicle data specified in the acquisition instruction information has been acquired. If priorities are specified for only some of the scenes included in the acquisition instruction information, this determination essentially becomes a determination of whether all vehicle data for scenes with priorities specified in the acquisition instruction information has been acquired. If the answer is Yes, proceed to S205. If the answer is No, proceed to S206.

[0084] In S205, the trigger management unit V1 increments n. That is, the natural number n is replaced with n+1, and the subsequent processing is executed. After the processing of S205, the process returns to S203.

[0085] In S206, the trigger management unit V1 acquires vehicle data for all scenes encountered by the vehicle 1. After S206, the series of processes ends.

[0086] According to the first embodiment described above, the instruction based on the instruction information from the server 20 is reviewed on the vehicle 1 side. That is, the conditions for transmitting vehicle data from the vehicle 1 side to the server 20 side can be flexibly changed in accordance with various restrictions. Therefore, it becomes possible to efficiently collect vehicle data.

[0087] According to the first embodiment, the instruction information includes an instruction to collect vehicle data from a plurality of scenes. The review process includes a process of setting conditions depending on whether or not the instruction information includes an instruction regarding the priority of the scenes. Scenes from which vehicle data should be acquired can be selected in consideration of the priority instruction from the server 20 and the vehicle's status, enabling efficient collection of vehicle data.

[0088] Furthermore, according to the first embodiment, the vehicle data collection system DCS further includes a development computer 30 that is communicatively connected to the server 20 and serves as a development device used to develop applications to be used in the vehicle 1. The driving assistance device 10, which serves as an in-vehicle device, acquires a development application under development that has been uploaded from the development computer 30 to the server 20, and operates the development application in parallel behind the scenes with a current application currently being used in the vehicle 1. The vehicle data includes data related to the operation of the development application. This makes it possible to verify the operation of the development application under conditions similar to its operation in a vehicle, while restricting the development application from affecting the actual motion, etc., of the vehicle 1.

[0089] Second Embodiment As shown in Fig. 7, the second embodiment is a modification of the first embodiment. The second embodiment will be described, focusing on the differences from the first embodiment.

[0090] In the second embodiment, the priority of vehicle data to be acquired within a specific scene is taken into consideration, because there are limitations on communication channel capacity, processing power, storage capacity, etc., and it may be better to impose restrictions rather than acquiring and storing all vehicle data that should be acquired.

[0091] Specifically, in the server 20, the acquisition instruction information generated by the instruction setting unit C2 may include priorities between multiple vehicle data to be acquired within a specific scene, in addition to priorities between scenes. The priorities between vehicle data may be set commonly for each scene, or may be set individually for each scene.

[0092] For example, as an example of setting priorities among vehicle data within a specific scene, a scene in which vehicle 1 travels through an intersection will be described. In this scene, the vehicle data set as priority 1, which has the highest priority, is stop position data indicating the position where vehicle 1 will stop at the intersection. The vehicle data set as priority 2 is travel trajectory data indicating the travel trajectory of vehicle 1 within the intersection. Priorities may be set according to the need to solve problems during development, for example.

[0093] In the driving assistance device 10, the trigger management unit V1 sets the trigger condition by referring to the priority among the vehicle data included in the acquisition instruction information.

[0094] Here, an example of a processing method for reviewing instruction conditions based on acquisition instruction information transmitted from the server 20 and setting final trigger conditions will be described in detail using the flowchart in Fig. 7. The processing of S301 to S304 in Fig. 7 is for one specific scene, but if it is necessary to process multiple specific scenes individually, the processing may be repeated for each specific scene.

[0095] In the first step S301, the trigger management unit V1 determines whether the acquisition instruction information includes an instruction on the priority of vehicle data to be acquired within a specific scene. If the answer is Yes, the process proceeds to S302. If the answer is No, the process proceeds to S304.

[0096] In S302, the trigger management unit V1 sets a trigger condition according to the priority specified in the acquisition instruction information. In S303 after processing S302, the trigger management unit V1 determines to acquire a portion of vehicle data with a relatively high priority among the vehicle data to be acquired in the specific scene. The series of processes ends with S303.

[0097] On the other hand, if there is no priority instruction in the acquisition instruction information, in S304, the trigger management unit V1 determines to acquire all vehicle data that should be acquired within the specific scene. After S304, the series of processes ends.

[0098] According to the second embodiment described above, the instruction information includes instructions regarding multiple vehicle data to be acquired in a specific scene. The review process includes a process of setting conditions depending on whether or not an instruction is given regarding the priority of the vehicle data in the specific scene. Therefore, among the vehicle data instructed by the server 20, vehicle data with a relatively low priority can be abandoned from collection depending on the situation on the vehicle 1 side, while data with a relatively high priority can be quickly provided to the server 20. This allows for efficient collection of vehicle data.

[0099] Third Embodiment As shown in Fig. 8, the third embodiment is a modification of the first embodiment. The third embodiment will be described, focusing on the differences from the first embodiment.

[0100] In the third embodiment, the trigger management unit V1 reviews the instructions in the acquisition instruction information and sets trigger conditions, including conditions for transmitting vehicle data in the storage transmission unit V4. Specifically, the trigger management unit V1 references the storage capacity of the storage 10d and sets thresholds T1 and T2 for the remaining storage capacity related to determining whether to transmit vehicle data. The trigger management unit V1 sets trigger conditions according to the set thresholds T1 and T2 and the transmission priority.

[0101] The transmission priority may be specified by the acquisition instruction information, or may be newly set by the trigger management unit V1 based on the acquisition instruction information. The transmission priority may be a priority between scenes, a priority between vehicle data independent of scenes, or a priority between vehicle data in a specific scene.

[0102] The storage and transmission unit V4 determines whether or not to transmit the vehicle data to the server 20 based on the set trigger conditions.

[0103] Here, a detailed example of the processing method of S6 in Fig. 1 will be described using the flowchart of Fig. 8. In S401, the storage transmission unit V4 determines whether the current remaining storage capacity of the storage 10d is equal to or less than the threshold T1. If the answer is Yes, proceed to S402. If the answer is No, the storage transmission unit V4 does not immediately transmit the vehicle data, but suspends transmission, and ends the series of processes.

[0104] In S402, the storage and transmission unit V4 and the trigger management unit V1 determine whether or not there is a transmission priority based on the trigger condition. If Yes, proceed to S403. If No, proceed to S408.

[0105] In S403, the storage and transmission unit V4 determines to transmit the vehicle data with the highest priority among the vehicle data to be transmitted. Then, the DCM 11 transmits the vehicle data to the server 20. In S404 after the processing of S403, the storage and transmission unit V4 deletes the vehicle data whose transmission has been completed from the storage 10d.

[0106] In S405 after the processing of S404, the storage transmission unit V4 determines whether the current remaining storage capacity of the storage 10d is equal to or less than a threshold T2. Here, T2 may be a value greater than T1. If the answer is Yes, proceed to S406. If the answer is No, the storage transmission unit V4 suspends transmission of other vehicle data and ends the series of processes.

[0107] In S406, the storage / transmission unit V4 determines whether the vehicle data set with the lowest priority remains in the storage 10d without being transmitted. If the determination is Yes, the process proceeds to S407. If the determination is No, the process ends without transmitting or deleting the other vehicle data.

[0108] In S407, the storage transmission unit V4 deletes the vehicle data set with the lowest priority from the storage 10d without transmitting it. This increases the remaining storage capacity of the storage 10d, and prepares for the future transmission of vehicle data with higher priority. After processing S407, the process returns to S402, and the process is repeated for the vehicle data remaining in the storage 10d that has not been transmitted.

[0109] On the other hand, if the answer is No in S402, in S408, the storage transmission unit V4 determines to transmit the vehicle data with the largest amount of data among the vehicle data remaining in the storage 10d that has not been transmitted to the server 20 in order to ensure storage capacity. Then, the DCM 11 transmits the vehicle data to the server 20. In S409 after processing S408, the storage transmission unit V4 deletes the vehicle data that has been transmitted from the storage 10d. The series of processes ends with S409.

[0110] According to the third embodiment described above, the conditions for transmitting vehicle data include a condition for selecting vehicle data to be transmitted to the server 20 in accordance with the remaining storage capacity of the storage 10d. By responding flexibly to the limitations of the remaining storage capacity of the storage 10d, it becomes possible to efficiently collect vehicle data.

[0111] Furthermore, according to the third embodiment, the conditions for transmitting vehicle data include a condition for selecting vehicle data to be deleted before transmitting to the server 20, depending on the remaining storage capacity of the storage 10d. By responding flexibly according to the limitations on the remaining storage capacity of the storage 10d, it becomes possible to efficiently collect vehicle data.

[0112] According to the third embodiment, the vehicle data is selected based on the priority set through the review process. For example, when the remaining storage capacity is low, vehicle data with a relatively high priority can be handled preferentially, thereby enabling efficient collection of vehicle data.

[0113] 9 to 11, the fourth embodiment is a modification of the first embodiment. The fourth embodiment will be described, focusing on the differences from the first embodiment.

[0114] The data collection plan of the fourth embodiment is a plan to run the current application and the development application in parallel in the same scene and compare the processing results of each application as vehicle data.

[0115] The acquisition instruction information generated based on such a plan includes instructions specifying the conditions under which the current application and the development application will operate when the vehicle data to be collected are output, as shown in Fig. 9. The conditions may be the same or different between the two applications.

[0116] The current application and the development application compared here may be applications that realize driving-related functions or applications that realize HMI-related functions.

[0117] As an example, the current application and the application under development are applications for avoiding obstacles on a road in autonomous driving or driver assistance. The specified operating conditions of the application may be parameters used in the application. The parameters may be thresholds for judgment. The thresholds may be, for example, extension accelerations that actually occur or that are predicted to occur when controlling the vehicle 1 to avoid an obstacle.

[0118] In the example of Fig. 9, the threshold value specified as the condition for operating the current application is "Ta." This threshold value is preferably specified within a range that is permitted for proper operation in the current application. The threshold value in the current application is a parameter that can be customized by, for example, the driver or a maintenance facility for the vehicle 1, and may be specified within a range that is permitted for the parameter.

[0119] 9, the threshold value specified as the condition for running the developed application is "Ta or Tb." "Ta or Tb" means that the developed application may be run at the threshold value Ta or at the threshold value Tb.

[0120] Then, in the driving assistance device 10, the trigger management unit V1 sets the trigger condition by referring to the instruction specifying the condition included in the acquisition instruction information.

[0121] 10, an example of a processing method for reviewing instruction conditions based on acquisition instruction information transmitted from the server 20 and setting final trigger conditions will be described. This processing method can be applied to various applications and acquisition instruction information, but the following description will be given assuming the acquisition instruction information in FIG.

[0122] In S501, the trigger management unit V1 receives acquisition instruction information from the server 20. After the processing of S501, the process proceeds to S502.

[0123] In S502, the trigger management unit V1 determines whether the remaining storage capacity of the storage 10d is equal to or less than a preset threshold. If the determination is Yes, the process proceeds to S503. If the determination is No, the process proceeds to S504.

[0124] In S503, the trigger management unit V1 determines whether the threshold value of the developed application can be changed. Here, "changeable" refers to whether the threshold value Ta can be changed from the same threshold value Ta as the threshold value Ta used in the current application to another threshold value. If the answer is Yes, proceed to S504. If the answer is No, proceed to S505.

[0125] In S504, the trigger management unit V1 determines to acquire vehicle data under the condition that the threshold of the current application is set to Ta and the threshold of the development application is set to Tb. After S504, the series of processes ends.

[0126] In S505, the trigger management unit V1 determines to acquire vehicle data under the condition that the threshold of the current application is set to Ta and the threshold of the development application is set to Ta. After S505, the series of processes ends.

[0127] Furthermore, if the answer to S502 is No, in S506, the trigger management unit V1 determines to suspend acquisition of vehicle data until the remaining storage capacity increases. The increase in the remaining storage capacity may be achieved, for example, by the storage transmission unit V4 deleting the vehicle data stored in the storage 10d as the storage transmission unit V4 transmits the vehicle data. If the storage 10d is also used for a function other than data collection, the increase in the remaining storage capacity may be achieved by a decrease in the amount of data used for the other function. The series of processes ends with S506.

[0128] Moreover, instead of the processing method shown in the flowchart of FIG. 10, the processing method shown in the flowchart of FIG. 11 may be adopted.

[0129] S601 is the same as S501. In S602 after processing S601, the trigger management unit V1 determines whether the remaining storage capacity of the storage 10d is equal to or less than a preset threshold and whether the data collection time is within an allowable range. The data collection time here refers to the estimated time required to complete data collection for the instructed vehicle 1. The allowable range is a range that has either an upper limit or a lower limit, or both. If the answer is Yes, proceed to S603. If the answer is No, proceed to S607.

[0130] S603 is the same as S503. If Yes, proceed to S604. If No, proceed to S606.

[0131] In S604, the trigger management unit V1 determines whether the application being compared is an application that realizes a function related to driving. An application that is determined as No here is, for example, an application that realizes a function related to HMI. If Yes, proceed to S605. If No, proceed to S606. S605 and S606 are the same as S504 and S505, respectively. A series of processes ends with S605 and S606. On the other hand, if the result of S602 is No, S607 is the same as S607. A series of processes ends with S607.

[0132] According to the fourth embodiment described above, the instruction information includes instructions for the operating conditions of the application when the vehicle data to be collected is output. Setting the conditions for transmitting the vehicle data includes setting the operating conditions of the actual application within the range of the operating conditions instructions. This makes it possible to efficiently collect vehicle data corresponding to specific operating conditions that the developer wants to verify.

[0133] According to the fourth embodiment, setting the conditions for transmitting vehicle data includes setting the operating conditions of the actual application in accordance with the application's functions. Since the operating conditions are set in consideration of the application's functions, it is possible to efficiently collect vehicle data corresponding to specific operating conditions that the developer wants to verify.

[0134] 12 and 13, the fifth embodiment is a modification of the first embodiment. The fifth embodiment will be described, focusing on the differences from the first embodiment.

[0135] A driving assistance device 210 of the fifth embodiment includes the hardware shown in Fig. 1 and the functions schematically shown in Fig. 12. The driving assistance device 210 acquires detection results from a plurality of autonomous sensors. The plurality of autonomous sensors here are, for example, the camera 2 and millimeter-wave radar 3 shown in Fig. 12, but other combinations may also be used.

[0136] The driving assistance device 210 may include a recognition unit V10, a judgment unit V20, a control unit V30, a recognition comparison verification unit V41, a trigger information assignment unit 42, and a data upload unit V43 as processing units realized by the processor 10b executing a computer program stored in the memory 10a.

[0137] The recognition unit V10 analyzes the detection data from the autonomous sensors and outputs the results to the determination unit V20 in a form that enables the driving assistance function to be realized. The recognition unit V10 may include a camera recognition unit V11, a radar recognition unit V12, and a sensor fusion unit V13.

[0138] The camera recognition unit V11 acquires image data captured by the camera 2 and recognizes targets captured within the angle of view of the camera 2. The camera recognition unit V11 may be configured to recognize the type of target by classifying the target using semantic segmentation. The recognition result of the camera recognition unit V11 is output to the sensor fusion unit V13 and also to the recognition comparison and verification unit V41.

[0139] The radar recognition unit V12 acquires detection data from the millimeter wave radar 3 and recognizes the positions of targets around the vehicle 1. The recognition results of the radar recognition unit V12 are output to the sensor fusion unit V13 and also to the recognition comparison and verification unit V41.

[0140] The sensor fusion unit V13 fuses the recognition results of multiple autonomous sensors to derive a more reliable target recognition result. The sensor fusion unit V13 may fuse map information, information acquired through V2X communication, and the like in addition to the results of the autonomous sensors. The sensor fusion unit V13 may generate an environmental model representing the environment around the vehicle 1 as the recognition result. The sensor fusion unit V13 outputs the recognition result to the determination unit V20.

[0141] The determination unit V20 determines the driving-related functions based on the recognition results. When the driving assistance device 210 realizes functions of automation levels 1 to 2, the determination unit V20 determines whether to intervene in driving to assist the driver. When the driving assistance device 210 realizes functions of automation level 3 or higher, the determination unit V20 plans the driving of the vehicle 1. The control unit V30 outputs a request to the vehicle control device 40 to execute control based on the determination result by the determination unit V20. The vehicle control device 40 can control the movement of the vehicle 1 by controlling driving actuators related to driving, braking, and steering.

[0142] The recognition comparison verification unit V41, the trigger information assignment unit V42, and the data upload unit V43 are processing units provided for the data collection function of the vehicle data collection system DCS, and realize functions corresponding to the storage and transmission unit V4 of the first embodiment.

[0143] The recognition comparison verification unit V41 compares the target recognition results from multiple autonomous sensors and verifies the reliability of the vehicle data to be provided to the server 20. Specifically, the recognition comparison verification unit V41 compares the target recognition position from the camera 2 with the target recognition position from the millimeter-wave radar 3. The recognition comparison verification unit V41 determines whether the difference between the target recognition position from the camera 2 and the target recognition position from the millimeter-wave radar 3 exceeds a preset tolerance.

[0144] If the tolerance is exceeded, the recognition comparison verification unit V41 determines which autonomous sensor's reliability has decreased. The recognition comparison verification unit V41 determines whether the scene corresponding to the recognition result is a scene in which the robustness of the camera 2 is expected to decrease, or a scene in which the robustness of the millimeter-wave radar 3 is expected to decrease.

[0145] Scenes in which the robustness of the camera 2 is expected to decrease include, for example, nighttime scenes where backlighting occurs, etc. Scenes in which the robustness of the millimeter-wave radar 3 is expected to decrease include, for example, scenes in which a target with low reflectivity is detected, scenes in which freezing or condensation may occur on the sensor surface due to weather conditions, etc.

[0146] The trigger information assigning unit V42 assigns trigger information to the vehicle data. When the scene corresponding to the recognition result is a scene where robustness is expected to decrease in the camera 2, the trigger information assigning unit V42 assigns attribute information of the scene as trigger information to the vehicle data related to the recognized target. When the scene corresponding to the recognition result is a scene where robustness is expected to decrease in the millimeter-wave radar 3, the trigger information assigning unit V42 assigns attribute information of the scene as trigger information to the vehicle data related to the recognized target.

[0147] The addition here may involve generating a file that compiles the vehicle data and the attribute information, or may involve generating an additional file of the attribute information associated with the vehicle data. Such a file is stored in the storage 10d.

[0148] The attribute information may include, for example, the location and time when the scene occurred. The attribute information may further include information about the weather in the scene and the brightness of the outside of the vehicle. The information about the weather may be acquired through V2X communication. The information about the brightness of the outside of the vehicle may be provided by, for example, an illuminance sensor mounted on the vehicle 1.

[0149] The data upload unit V43 uploads the above-mentioned files stored in the storage 10d to the server 20 at a timing according to a predetermined condition, using the DCM 11. The data upload unit V43 deletes the uploaded files from the storage 10d.

[0150] Here, an example of a processing method for adding trigger information to acquired vehicle data and transmitting the data to the server 20 will be described with reference to the flowchart of FIG.

[0151] In S701, the recognition comparison and verification unit V41 determines whether there is a discrepancy in the target recognition between the camera 2 and the millimeter-wave radar 3. If Yes, proceed to S702. If No, proceed to S706 without providing trigger information.

[0152] In S702, the recognition comparison and verification unit V41 determines whether the scene corresponding to the recognition result is a scene in which robustness is expected to decrease in camera 2. If Yes, proceed to S703. If No, proceed to S704.

[0153] In S703, the trigger information adding unit V42 adds to the vehicle data attribute information of a scene in which the robustness is expected to decrease in the camera 2. After the processing of S703, the process proceeds to S706.

[0154] In S704, the recognition comparison and verification unit V41 determines whether the scene corresponding to the recognition result is a scene in which the robustness of the millimeter-wave radar 3 is expected to be reduced. If the result is Yes, the process proceeds to S705. If the result is No, the process proceeds to S706 without providing trigger information.

[0155] In S705, the trigger information adding unit V42 adds, to the vehicle data, attribute information of a scene in which the robustness of the millimeter wave radar 3 is expected to be reduced. After the processing of S705, the process proceeds to S706.

[0156] In S706, the vehicle data to which trigger information is not attached or the vehicle data to which trigger information is attached is stored in the storage 10d. Thereafter, the data upload unit V43 uploads this vehicle data to the server 20. After S706, the series of processes ends.

[0157] According to the fifth embodiment described above, vehicle data acquired in accordance with conditions is provided with information related to the reliability of the target recognition results based on the autonomous sensor mounted on the vehicle 1. By providing this information, the accuracy of subsequent vehicle data classification processing and verification processing is improved, thereby increasing the usefulness of the vehicle data.

[0158] (Other Embodiments) Although multiple embodiments have been described above, the present disclosure should not be construed as being limited to those embodiments, and can be applied to various embodiments and combinations within the scope that does not deviate from the gist of the present disclosure.

[0159] As another embodiment of S103 in FIG. 5, the trigger management unit V1 may set a trigger condition such that the priority between scenes is changed as needed, in accordance with the remaining required number of scenes, instead of the current data acquisition rate.

[0160] In another embodiment, the storage 10d that stores the vehicle data before transmitting it to the server 20 may be provided outside the housing of the driving assistance device 10 and communicatively connected to the driving assistance device 10, or may be provided detachably with respect to the driving assistance device 10.

[0161] In another embodiment, the in-vehicle device that sets the conditions for transmitting vehicle data and determines whether to transmit the vehicle data to the server 20 may be a device other than the driving assistance device 10. For example, the in-vehicle device may be an HMI control device that controls the HMI of the vehicle 1, a communication device that performs V2X communication, or a dedicated device provided for data collection.

[0162] In another embodiment, the development application may be installed in a device other than the in-vehicle device that sets the conditions for transmitting vehicle data and determines whether to transmit the vehicle data to the server 20. For example, the development application may be installed in an in-vehicle processing device that is provided as a redundant system and is not normally used.

[0163] In another embodiment, the vehicle 1 may be a right-hand drive vehicle or a left-hand drive vehicle. Furthermore, the traffic environment in which the vehicle 1 travels may be a traffic environment where traffic is assumed to be on the left side of the road, or a traffic environment where traffic is assumed to be on the right side of the road. The driving assistance device 10 according to the present disclosure may be optimized as appropriate, taking into account the road traffic laws, customs, data (protection) laws, etc. of each country and region.

[0164] The controller and methods described herein may be implemented by a special-purpose computer comprising a processor programmed to perform one or more functions embodied in a computer program. Alternatively, the apparatus and methods described herein may be implemented by special-purpose hardware logic circuitry. Alternatively, the apparatus and methods described herein may be implemented by one or more special-purpose computers comprising a processor executing a computer program in combination with one or more hardware logic circuits. Furthermore, the computer program may be stored as instructions executed by a computer on a computer-readable non-transitory storage medium.

[0165] (Disclosure of Technical Ideas) This specification discloses multiple technical ideas described in the following multiple clauses. Some clauses may be described in a multiple dependent form, where the subsequent clause alternatively cites the preceding clause. These multiple dependent clauses define multiple technical ideas.

[0166] <Technical Idea 1> A vehicle data collection system including an on-board device (10, 210) mounted on a vehicle (1) capable of participating in public road traffic, and a server (20) communicatively connected to the vehicle and collecting vehicle data from the vehicle, wherein the server executes transmitting, to the vehicle, instruction information instructing the vehicle data to be collected, and the on-board device executes, based on the instruction information, setting conditions for transmitting vehicle data to include a review process of instructions given by the instruction information, and determining to transmit the vehicle data acquired in accordance with the conditions to the server.

[0167] <Technical Idea 2> The vehicle data collection system according to Technical Idea 1, wherein the instruction information includes an instruction to collect the vehicle data in a plurality of scenes, and the review process includes a process of setting the conditions depending on whether or not the instruction information includes an instruction regarding priority between the scenes.

[0168] <Technical Idea 3> The vehicle data collection system described in Technical Idea 1 or 2, wherein the instruction information includes instructions regarding a plurality of the vehicle data to be acquired in a specific scene, and the review process includes a process of setting the conditions depending on whether or not there is an instruction regarding the priority between the vehicle data in the specific scene.

[0169] <Technical Idea 4> The vehicle data collection system described in any one of Technical Ideas 1 to 3, wherein the in-vehicle device includes a storage medium (10d) that stores the acquired vehicle data, and the conditions for transmitting the vehicle data include a condition for selecting the vehicle data to be transmitted to the server depending on the remaining storage capacity of the storage medium.

[0170] <Technical Idea 5> The vehicle data collection system according to any one of Technical Ideas 1 to 4, wherein the on-board device includes a storage medium (10d) that stores the acquired vehicle data, and the conditions for transmitting the vehicle data include a condition for selecting the vehicle data to be deleted before transmitting to the server depending on the remaining storage capacity of the storage medium.

[0171] <Technical Concept 6> The vehicle data collection system according to Technical Concept 4 or 5, wherein the selection of the vehicle data is based on priorities set through the review process.

[0172] <Technical Idea 7> A vehicle data collection system described in any one of Technical Ideas 1 to 6, wherein the instruction information includes instructions for the operating conditions of an application when the vehicle data to be collected is output, and setting the conditions for transmitting the vehicle data includes setting the actual operating conditions of the application within the range of the instructions for the operating conditions.

[0173] <Technical Idea 8> The vehicle data collection system according to Technical Idea 7, wherein setting the conditions for transmitting the vehicle data includes setting actual operating conditions for the application according to a function of the application.

[0174] <Technical Idea 9> The vehicle data collection system according to any one of Technical Ideas 1 to 8, wherein the on-board device is further configured to add, to the vehicle data acquired in accordance with the conditions, information related to the reliability of a target recognition result based on an autonomous sensor (2, 3) mounted on the vehicle.

[0175] <Technical Idea 10> A vehicle data collection system as described in any one of Technical Ideas 1 to 9, further including a development device (30) communicatively connected to the server and used for developing an application to be used in the vehicle, wherein the in-vehicle device further executes the following: acquiring the development application under development uploaded to the server from the development device, and running the development application in parallel behind the scenes with a current application currently being used in the vehicle, and the vehicle data includes data related to the operation of the development application.

Claims

1. A vehicle data collection system including an on-board device (10, 210) mounted on a vehicle (1) capable of participating in public road traffic, and a server (20) communicatively connected to the vehicle and collecting vehicle data from the vehicle, wherein the server executes the following: sending to the vehicle instruction information instructing the vehicle data to be collected; and the on-board device, based on the instruction information, sets conditions for transmitting vehicle data to include a review process of the instructions given by the instruction information; and determines to transmit the vehicle data acquired in accordance with the conditions to the server.

2. The vehicle data collection system of claim 1, wherein the instruction information includes instructions to collect the vehicle data in multiple scenes, and the review process includes a process of setting the conditions depending on whether or not the instruction information includes an instruction regarding priority between the scenes.

3. The vehicle data collection system of claim 1, wherein the instruction information includes instructions regarding a plurality of the vehicle data to be acquired in a specific scene, and the review process includes a process of setting the conditions depending on whether or not there is an instruction regarding the priority between the vehicle data in the specific scene.

4. The vehicle data collection system of claim 1, wherein the in-vehicle device is provided with a storage medium (10d) for storing the acquired vehicle data, and the conditions for transmitting the vehicle data include a condition for selecting the vehicle data to be transmitted to the server depending on the remaining storage capacity of the storage medium.

5. The vehicle data collection system of claim 1, wherein the in-vehicle device is provided with a storage medium (10d) for storing the acquired vehicle data, and the conditions for transmitting the vehicle data include a condition for selecting the vehicle data to be deleted before transmitting to the server depending on the remaining storage capacity of the storage medium.

6. The vehicle data collection system according to claim 4 or 5, wherein the selection of the vehicle data is based on priorities set through the review process.

7. The vehicle data collection system of claim 1, wherein the instruction information includes instructions for the operating conditions of the application when the vehicle data to be collected is output, and setting the conditions for transmitting the vehicle data includes setting the actual operating conditions of the application within the range of the instructions for the operating conditions.

8. The vehicle data collection system according to claim 7, wherein setting the conditions for transmitting the vehicle data includes setting actual operating conditions for the application according to the function of the application.

9. The vehicle data collection system according to claim 1, wherein the on-board device is further configured to add information related to the reliability of target recognition results based on autonomous sensors (2, 3) mounted on the vehicle to the vehicle data acquired in accordance with the conditions.

10. The vehicle data collection system of claim 1, further comprising a development device (30) communicatively connected to the server and used for developing applications to be used in the vehicle, wherein the on-board device further executes the following: retrieving the development application under development uploaded to the server from the development device; and running the development application in parallel behind the scenes with a current application currently being used in the vehicle; and the vehicle data includes data related to the operation of the development application.

11. An on-board device comprising at least one processor (10b), mounted on a vehicle (1) capable of participating in public road traffic, and communicatively connected to a server (20) that collects vehicle data from the vehicle, wherein the at least one processor is configured to: acquire from the server instruction information indicating the vehicle data to be collected; set, based on the instruction information, conditions for transmitting the vehicle data to include a review process of the instructions given by the instruction information; and determine to transmit the vehicle data acquired in accordance with the conditions to the server.

12. A program used in an on-board device mounted on a vehicle (1) capable of participating in public road traffic and communicatively connected to a server (20) that collects vehicle data from the vehicle, the program causing at least one processor (10b) to: acquire instruction information from the server indicating the vehicle data to be collected; set conditions for transmitting the vehicle data based on the instruction information to include a review process of the instructions provided by the instruction information; and decide to transmit the vehicle data acquired in accordance with the conditions to the server.

Images