Mobile device management device, control method, program and storage medium

Abstract

The present invention provides a mobile vehicle management device capable of suitably acquiring statistical data regarding the vehicle's status in relation to the process it has instructed to execute. [Solution] The vehicle cloud server 30 receives upload data UD2, which is a reception result indicating that the in-vehicle terminals 20 of multiple vehicles were able to successfully receive the job request JR2, and counts the number of inactive vehicles, which is the number of vehicles that were able to successfully receive the job request JR2, based on the upload data UD2. The vehicle cloud server 30 also receives upload data UD2 in which the number of active transitions of the job is one or more, and counts the number of active vehicles and the total number of active vehicles, which represent the number of vehicles that sent the upload data UD2 and the total number of vehicles. The vehicle cloud server 30 then sends upload data UD1, which includes information on the number of inactive vehicles, the number of active vehicles, and the total number of active vehicles, to the service cloud server 40.

Description

Technical Field

[0001] The present invention relates to a technique for state management in data collection.

Background Art

[0002] Conventionally, a technique for collecting information of sensors installed in a vehicle by a server device has been known. For example, Patent Document 1 discloses a driving support device that transmits change point information regarding a change point to a server device when a change point of a partial map is detected based on an output of a sensor installed in a moving body such as a vehicle.

Prior Art Documents

Patent Documents

[0003]

Patent Document 1

Summary of the Invention

Problems to be Solved by the Invention

[0004] Companies that provide various services related to vehicles each operate a server to specify data to be uploaded to the vehicle, and collect various information related to the vehicle necessary for service provision via a server (vehicle management server) that manages the vehicle. In such a system, the vehicle recognizes uploading the instructed data when a predetermined execution condition is satisfied as a job, and is required to execute the job when the above-described execution condition is satisfied.

[0005] On the other hand, there is no guarantee that data collection requests generated by the service company's server will be delivered to vehicles. If the vehicle management server is under heavy load, or if there are no vehicles that meet the collection conditions and therefore no vehicles to which data collection requests should be delivered, the requests will not be delivered to vehicles. Furthermore, if a vehicle becomes overloaded and deletes a data collection request from it, the data collection request may not be properly executed by the vehicle. Considering the above, in order to accurately grasp the effectiveness, cost efficiency, and reliability of data collection requests, it is necessary to properly manage the status of the processes instructed to be executed by each vehicle.

[0006] The present invention was made to solve the above-mentioned problems, and its main objective is to provide a mobile body management device that can suitably acquire statistical data regarding the status of processing instructed to be performed on a mobile body. [Means for solving the problem]

[0007] The invention described in the claims is a mobile body management device comprising: a first receiving unit that receives a request signal issued by an information management device; a generating unit that generates command information corresponding to the request signal; a first transmitting unit that transmits the command information to a plurality of mobile bodies; a second receiving unit that receives a reception result indicating that the plurality of mobile bodies have successfully received the command information; a first counting unit that counts the number of mobile bodies that have successfully received the command information based on the reception result; a third receiving unit that receives response information to the command information; and a second transmitting unit that transmits the number of mobile bodies that have successfully received the command information to the information management device. Furthermore, the invention described in the claims is a control method performed by a mobile body management device, comprising: a first receiving step of receiving a request signal issued by an information management device; a generation step of generating command information corresponding to the request signal; a first transmitting step of transmitting the command information to a plurality of mobile bodies; a second receiving step of receiving a reception result indicating that the plurality of mobile bodies were able to successfully receive the command information; a first counting step of counting the number of mobile bodies that were able to successfully receive the command information based on the reception result; a third receiving step of receiving response information to the command information; a second counting step of counting the number of mobile bodies that transmitted the response information based on the response information; and a second transmitting step of transmitting mobile body count information relating to the number of mobile bodies that were able to successfully receive the command information and the number of mobile bodies that transmitted the response information to the information management device. [Brief explanation of the drawing]

[0008] [Figure 1] The schematic configuration of the job distribution system according to the first embodiment is shown. [Figure 2] This diagram schematically shows the data flow between the in-vehicle terminal, the vehicle cloud server, and the service cloud server. [Figure 3] This is a block diagram showing the internal configuration of an in-vehicle terminal. [Figure 4] This diagram schematically shows the state transitions of the in-vehicle terminal in relation to a job. [Figure 5] This is a block diagram showing the internal configuration of the vehicle cloud server and the service cloud server. [Figure 6] This is an example of a job request data structure. [Figure 7] This is an example of a data structure for transmission history information. [Figure 8] This is an example of the data structure of upload data that an in-vehicle terminal sends to the vehicle cloud server based on a job request. [Figure 9] This is an example of the data structure of the upload data that the vehicle cloud server sends to the service cloud server based on a job request. [Figure 10]This flowchart shows the processing steps that the in-vehicle terminal executes when it receives a job request containing a valid status management flag. [Figure 11] This flowchart shows the processing steps performed by a vehicle cloud server upon receiving a job request that includes a valid status management flag. [Figure 12] This shows an example of the job distribution system configuration in an application example. [Figure 13] This is an overhead view showing the street in front of Station A. [Figure 14] This is a block diagram showing the internal configuration of an in-vehicle terminal according to the second embodiment. [Figure 15] This is an example of the data structure of the uploaded data according to the second embodiment. [Figure 16] This flowchart shows the processing procedure executed by the in-vehicle terminal according to the second embodiment when it receives a job request that includes a valid status management flag. [Figure 17] This flowchart shows the processing procedure executed by the vehicle cloud server in the second embodiment upon receiving a job request containing a valid status management flag. [Figure 18] This is an example of the data structure of the uploaded data according to the third embodiment. [Figure 19] This diagram schematically shows the internal configuration of the vehicle cloud server according to the third embodiment. [Figure 20] This flowchart shows the processing procedure executed by an in-vehicle terminal according to the third embodiment, upon receiving a job request containing a valid status management flag. [Figure 21] A flowchart shows the processing procedure executed by the vehicle cloud server according to the third embodiment upon receiving a job request containing a valid status management flag. [Modes for carrying out the invention]

[0009] One preferred embodiment is a mobile body management device, comprising: a first receiving unit that receives a request signal sent by an information management device; a generating unit that generates command information corresponding to the request signal; a first transmitting unit that transmits the command information to a plurality of mobile bodies; a second receiving unit that receives a reception result indicating that the plurality of mobile bodies have successfully received the command information; a first counting unit that counts the number of mobile bodies that have successfully received the command information based on the reception result; a third receiving unit that receives response information for the command information; a second counting unit that counts the number of mobile bodies that have transmitted the response information based on the response information; and a second transmitting unit that transmits mobile body number information regarding the number of mobile bodies that have successfully received the command information and the number of mobile bodies that have transmitted the response information to the information management device. The "number of mobile bodies" may be the total number. According to this aspect, the mobile body management device can suitably supply the information management device with mobile body number information regarding the number of mobile bodies that have successfully received the command information based on the request signal and the number of mobile bodies that have transmitted the response information for the command information.

[0010] In one aspect of the above mobile body management device, the command information includes condition information indicating conditions for the mobile body to execute the command indicated by the command information, and the response information includes information regarding the state that the command information can take depending on whether the conditions are satisfied. According to this aspect, the mobile body management device can obtain information regarding the state that the command information can take for each mobile body depending on whether the conditions indicated by the condition information are satisfied, so that the number of the above-mentioned mobile bodies can be accurately counted.

[0011] In another aspect of the above mobile body management device, the first transmitting unit transmits the command information and flag information instructing the transmission of information regarding the state that the command information can take to the plurality of mobile bodies. According to this aspect, the mobile body management device can suitably collect information regarding the state that the command information can take from the mobile bodies.

[0012] In another embodiment of the mobile body management device described above, the possible states of the command information include an execution state in which the command is executed when the conditions are met, and a non-execution state in which the command is not executed when the conditions are not met, and the second transmitting unit transmits to the information management device, as mobile body number information, information indicating the ratio of the number of mobile bodies in the execution state to the number of mobile bodies for which the command information was successfully received. This embodiment allows for the appropriate supply of information necessary for determining the effectiveness and cost-effectiveness of the request signal to the information management device.

[0013] In another embodiment of the mobile object management device described above, the mobile object management device further includes a storage unit that stores, in association with the identification information of the mobile object to which the first transmission unit transmitted the command information and the identification information of the command indicated by the command information. In this embodiment, the mobile object management device can suitably maintain the number of mobile objects to which the command information is transmitted for each transmitted command information.

[0014] In another embodiment of the mobile device management system described above, the reception result includes fail information indicating that the command information was not received correctly. In this embodiment, the mobile device management system can accurately count the number of mobile devices that have received the command information correctly.

[0015] In yet another preferred embodiment, a control method executed by a mobile body management device comprises: a first receiving step of receiving a request signal issued by an information management device; a generation step of generating command information corresponding to the request signal; a first transmitting step of transmitting the command information to a plurality of mobile bodies; a second receiving step of receiving a reception result indicating that the plurality of mobile bodies were able to successfully receive the command information; a first counting step of counting the number of mobile bodies that were able to successfully receive the command information based on the reception result; a third receiving step of receiving response information to the command information; a second counting step of counting the number of mobile bodies that transmitted the response information based on the response information; and a second transmitting step of transmitting mobile body count information relating to the number of mobile bodies that were able to successfully receive the command information and the number of mobile bodies that transmitted the response information to the information management device. By executing this control method, the mobile body management device can suitably supply the information management device with mobile body count information relating to the number of mobile bodies that were able to successfully receive the command information based on the request signal and the number of mobile bodies that transmitted the response information to the command information.

[0016] Another preferred embodiment is a program that causes a computer to execute the control method described above. By executing this program, the computer can suitably determine the number of terminal devices that have transmitted processing information, for each type of processing indicated by the processing information. Preferably, the program is stored in a storage medium. [Examples]

[0017] Hereinafter, preferred first to third embodiments of the present invention will be described with reference to the drawings. <First Example> (1) Overall structure Figure 1 shows a schematic configuration of a job distribution system according to the first embodiment. The job distribution system is a system for collecting various information generated by vehicle sensors and comprises a vehicle V, a vehicle cloud server 30, and a service cloud server 40.

[0018] Vehicle V is equipped with an in-vehicle terminal 20. The in-vehicle terminal 20 is an information processing device that connects to various sensors for acquiring information about the state of vehicle V or the surrounding environment and performs predetermined processing. Based on the output of these sensors, the in-vehicle terminal 20 executes processing (also simply called a "job") requested by the service cloud server 40. In this embodiment, a job mainly refers to the process of acquiring information about the state of a specific vehicle V or the surrounding environment specified by the service cloud server 40 using sensors and uploading it to the service cloud server 40. Vehicle V and the in-vehicle terminal 20 are examples of "mobile objects". The in-vehicle terminal 20 is also an example of a "terminal device". Note that "mobile objects" are not limited to vehicle V and the in-vehicle terminal 20, but may also be bicycles, wheelchairs, drones, ships, and other mobile objects.

[0019] The vehicle cloud server 30 is a server device that constitutes the vehicle cloud. The vehicle cloud is a cloud operated by an information collection company that manages vehicles provided to users (e.g., autonomous vehicles) and collects various information from them. The information collection company may be the automobile manufacturer itself, or it may be operated directly or indirectly by the automobile manufacturer. For example, if there are three automobile manufacturers, A, B, and C, then there may be separate information collection companies operated by A, B, and C, and each information collection company collects various information from vehicles manufactured by the automobile manufacturer that operates it. Alternatively, it may be a form in which multiple automobile manufacturers, such as D, E, and F, jointly outsource / operate the service. The vehicle cloud server 30 is an example of a "mobile vehicle management device".

[0020] The service cloud server 40 is a server device that constitutes a service cloud. A service cloud is, for example, a cloud operated by a service provider that provides services related to vehicles. Examples of service providers include insurance companies that provide insurance-related services, map service companies that provide map-related services, parking service companies that provide parking-related services, and route search service companies that provide route search-related services. The service cloud server 40 generates information (also called a "job request") that instructs the in-vehicle terminal 20 to execute jobs according to the purpose, and distributes it to the in-vehicle terminal 20 via the vehicle cloud server 30. The service cloud server 40 is an example of an "information management device".

[0021] The in-vehicle terminal 20, the vehicle cloud server 30, and the service cloud server 40, all mounted on the vehicle V, can communicate with each other via wired or wireless connection through the network 5. In this embodiment, the in-vehicle terminal 20, the vehicle cloud server 30, and the service cloud server 40 exchange job requests generated by the service cloud server 40, and exchange data (also called "upload data") generated by the in-vehicle terminal 20 in response to job requests.

[0022] Note that the configuration of the job distribution system shown in Figure 1 is just one example, and the configuration to which the present invention can be applied is not limited thereto. For example, there may be a service cloud that generates job requests (first service cloud) and a service cloud that requests the first service cloud to collect predetermined information (second service cloud). In this case, for example, the first service cloud generates a job request according to the request from the second service cloud, and sends the information requested by the second service cloud to the second service cloud based on the uploaded data received from the vehicle cloud to which the job request is sent.

[0023] Figure 2 is a schematic diagram illustrating the data flow between the in-vehicle terminal 20, the vehicle cloud server 30, and the service cloud server 40.

[0024] As shown in Figure 2, the service cloud server 40 sends the generated job request "JR1" to the vehicle cloud server 30, and the vehicle cloud server 30 sends the generated job request "JR2" based on the job request JR1 received from the service cloud server 40 to the in-vehicle terminal 20. The job request JR1 can include information such as the vehicle ID and driver ID that indicate the vehicle on which the job should be executed, and the service cloud server 40 includes the vehicle ID and driver ID to be sent to the job request JR1 as needed. As a result, the vehicle cloud server 30 sends the job request JR2 to the in-vehicle terminal 20 of the corresponding vehicle.

[0025] Upon receiving Job Request JR2, the in-vehicle terminal 20 collects the data specified in Job Request JR2 from the sensors and sends the collected data as upload data "UD2" to the vehicle cloud server 30. When the vehicle cloud server 30 receives upload data UD2 from the in-vehicle terminal 20, it generates upload data "UD1" based on the received upload data UD2 and sends the generated upload data UD1 to the requesting service cloud server 40. For the data structure of Job Requests JR1, JR2 and Upload Data UD1 and UD2, see "(5) data structure This will be explained in detail in the section. Job request JR1, which the service cloud server 40 sends to the vehicle cloud server 30, is an example of a "request signal," job request JR2, which the vehicle cloud server 30 sends to the in-vehicle terminal 20, is an example of "transmission information," and upload data UD2 is an example of a "received result."

[0026] (2) In-vehicle terminal configuration Figure 3 is a block diagram showing the internal configuration of the in-vehicle terminal 20. As shown in the figure, the in-vehicle terminal 20 mainly consists of a communication unit 21, a storage unit 22, an input unit 23, a control unit 24, an interface 25, and an output unit 26. Each element within the in-vehicle terminal 20 is interconnected via a bus line 29. The interface 25 is also connected to a sensor unit 27.

[0027] The communication unit 21 transmits uploaded data to the vehicle cloud server 30 and receives map data from the vehicle cloud server 30 to update the map database, based on the control of the control unit 24. The communication unit 21 may also perform processes to transmit signals to the vehicle for controlling the vehicle and processes to receive signals from the vehicle regarding the vehicle's status.

[0028] The memory unit 22 stores programs executed by the control unit 24 and information necessary for the control unit 24 to perform predetermined processes. The memory unit 22 includes non-volatile memory (internal storage). In this embodiment, the memory unit 22 stores a map database, a sensor data cache, vehicle attribute information, a job request JR2 received from the vehicle cloud server 30 by the communication unit 21, and status count information.

[0029] A map database is a database that includes, for example, road data, facility data, and feature data around roads. Road data includes roadway / lane network data for route planning, road shape data, and traffic law data. Feature data includes information on road signs and other signs, road markings such as stop lines, road markings such as center lines, and structures along roads. Feature data may also include high-precision point cloud information of features used for vehicle position estimation. Furthermore, the map database may store various other data necessary for position estimation.

[0030] The sensor data cache is a cache memory that temporarily holds the output data from the sensor unit 27. The vehicle attribute information indicates information about the attributes of the vehicle V equipped with the in-vehicle terminal 20, such as the vehicle type, vehicle ID, vehicle size including vehicle length, vehicle width, and vehicle height, and the vehicle's fuel type.

[0031] The status count information indicates the cumulative number of transitions for each state of a job requested by job request JR2 during the period in which the job is valid. For example, the status count information associates the number of transitions to each state that the job can take place in. The control unit 24 updates the status count information each time it detects a state transition. Job state transitions will be described later using Figure 4. The status count information is an example of "counting information".

[0032] The input unit 23 includes buttons, a touch panel, a remote controller, a voice input device, etc., for user operation. For example, it accepts inputs such as specifying a destination for route searching and inputs to specify whether to turn autonomous driving on or off, and supplies the generated input signals to the control unit 24. The output unit 26 includes, for example, a display or speaker that outputs based on the control of the control unit 24.

[0033] Interface 25 performs interface operations to supply output data from the sensor unit 27 to the control unit 24 and the sensor data cache. The sensor unit 27 includes multiple external sensors for recognizing the surrounding environment of the vehicle, such as a lidar and a camera, and internal sensors such as a GPS receiver, a gyro sensor, a position sensor, and a 3-axis sensor. The lidar discretely measures the distance to objects in the external environment, recognizes the surface of the object as a 3D point cloud, and generates point cloud data. The camera generates image data captured from the vehicle. The position sensor is provided to detect the position of each external sensor, and the 3-axis sensor is provided to detect the orientation of each external sensor. Note that the sensor unit 27 may have any external and internal sensors other than those shown in Figure 3. For example, the sensor unit 27 may include an ultrasonic sensor, an infrared sensor, a microphone, etc., as external sensors.

[0034] The control unit 24 includes a CPU that executes a predetermined program on one or more platforms and controls the entire in-vehicle terminal 20. Functionally, the control unit 24 includes a position estimation unit, an object detection unit, and an upload data generation unit. The control unit 24 functions as a computer that executes a program. The control unit 24 is an example of a "generation unit" and a computer that executes a program, while the communication unit 21 and the control unit 24 are examples of a "receiving unit" and a "transmitting unit."

[0035] The position estimation unit estimates the vehicle's position (including its attitude) based on the output data of the sensor unit 27 and the map database, which are stored in the sensor data cache. The position estimation unit is capable of executing various position estimation methods. For example, the position estimation unit can perform a vehicle position estimation method using dead reckoning (autonomous navigation) based on the output of autonomous positioning sensors such as a GPS receiver and a gyro sensor; a vehicle position estimation method that further matches autonomous navigation with road data from the map database (map matching); and a vehicle position estimation method based on predetermined objects (landmarks) in the surroundings, using output data from external sensors such as a lidar and a camera, and the position information of landmarks indicated by feature information in the map database. The position estimation unit then executes the position estimation method that provides the highest estimation accuracy from among the currently executable position estimation methods, and supplies the vehicle position information, which indicates the vehicle's position, etc., obtained based on the executed position estimation method, to the upload data generation unit.

[0036] The object detection unit detects a predetermined object based on point cloud information, image data, audio data, etc., output by the sensor unit 27. In this case, for example, the object detection unit extracts feature data corresponding to the object detected by the sensor unit 27 from the map database based on the vehicle's position estimated by the position estimation unit. Then, if there is a difference between the position and shape of the object detected by the sensor unit 27 and the position and shape of the object indicated by the feature data extracted from the map database, or if there is no corresponding feature data in the map database, the object detection unit supplies information about the object detected by the sensor unit 27 to the upload data generation unit.

[0037] The upload data generation unit generates upload data UD2 based on the vehicle's position information supplied from the position estimation unit, object data supplied from the object detection unit, and output data from the sensor unit 27 supplied from the sensor data cache. In this embodiment, when the conditions specified by the job request JR2 stored in the storage unit 22 are met, the upload data generation unit includes the data specified by the job request JR2 in the upload data UD2 and transmits the upload data UD2 to the vehicle cloud server 30 via the communication unit 21.

[0038] Here, we will explain the transitions in the job state (also simply called the "job state") indicated by the job request JR2.

[0039] Figure 4 is a schematic diagram illustrating the transitions between job states. Figure 4 shows the inactive state (not running), which is the job state in which the job execution conditions indicated by job request JR2 are not met; the active state (running), which is the job state in which the job execution conditions are met; and the failed state, which is the transition to in exceptional cases.

[0040] Here, when the in-vehicle terminal 20 receives the job request JR2, it performs a predetermined authentication process to determine whether it is appropriate to accept the job request JR2. For example, as part of the authentication process, the in-vehicle terminal 20 determines whether the vehicle ID and / or driver ID specified in the job request JR2 matches the vehicle ID of vehicle V and / or the driver ID of the driver of vehicle V.

[0041] If the authentication process is successful, the job automatically transitions to an inactive state. Subsequently, if it is determined that the job execution conditions indicated by the job request JR2 are met, the job transitions to an active state. If, after transitioning to the active state, it is determined that the above execution conditions are not met, the job transitions to an inactive state.

[0042] On the other hand, if the authentication process fails, the job transitions to fail. In this case, the in-vehicle terminal 20 sends upload data UD2 indicating that the job has failed to the vehicle cloud server 30. In addition, if a predetermined exception occurs, the job may transition from the active or inactive state to fail. The in-vehicle terminal 20 then terminates the job when the job's expiration date or other conditions have expired or when the job has failed, and deletes the job request JR2 from the storage unit 22. Upload data UD2 indicating that the job has failed is an example of "fail information".

[0043] (3) Vehicle Cloud Server Configuration Next, the vehicle cloud server 30 will be described in detail. Figure 5(A) is a block diagram showing the internal configuration of the vehicle cloud server 30. As shown in the figure, the vehicle cloud server 30 comprises a communication unit 31, a storage unit 32, and a control unit 33. Each element within the vehicle cloud server 30 is interconnected via a bus line 39.

[0044] The communication unit 31 communicates with the vehicle's in-vehicle terminal 20 and the service cloud server 40 based on the control of the control unit 33. Specifically, the communication unit 31 receives job request JR1 from the service cloud server 40 and sends job request JR2, which is generated based on job request JR1, to the in-vehicle terminal 20. The communication unit 31 also receives upload data UD2 from the in-vehicle terminal 20 and sends upload data UD1, which is generated based on upload data UD2, to the service cloud server 40.

[0045] The storage unit 32 includes ROM, RAM, etc., and stores programs for various processes executed by the vehicle cloud server 30. The storage unit 32 is also used as working memory when various processes are executed. The storage unit 32 also stores vehicle information and transmission history information Ih. Vehicle information is information about vehicles managed by the vehicle cloud. For example, the vehicle information is a table that associates the vehicle ID and / or driver ID, communication address information for sending data to the corresponding vehicle's in-vehicle terminal 20, and information about the services the vehicle is using. The transmission history information Ih is a table that shows the history of sending job requests JR2 to each vehicle's in-vehicle terminal 20, and the detailed data structure will be described later.

[0046] Furthermore, the storage unit 32 may also store historical data of job requests JR1 received by the vehicle cloud server 30 from the service cloud server 40, and upload data UD2 acquired by the vehicle cloud server 30 from the in-vehicle terminal 20. In this case, for example, the storage unit 32 stores the upload data UD2 received from each in-vehicle terminal 20 in association with the vehicle ID of the vehicle V equipped with the in-vehicle terminal 20, the time of receipt, and so on. Similarly, the storage unit 32 may store job requests JR1 received from the service cloud server 40 in association with information identifying the source service cloud server 40 and the time of receipt, and so on.

[0047] The control unit 33 is composed of a computer such as a CPU and controls the entire vehicle cloud server 30. Specifically, the control unit 33 performs various processes by executing various programs stored in the memory unit 32. The control unit 33 is an example of a "generation unit," "counting unit," "first counting unit," and "second counting unit." The communication unit 31 and the control unit 33 are an example of a "first receiving unit," "first transmitting unit," "second receiving unit," "third receiving unit," and "second transmitting unit."

[0048] (4) Service Cloud Server Configuration Next, the service cloud server 40 will be described in detail. Figure 5(B) is a block diagram showing the internal configuration of the service cloud server 40. As shown in the figure, the service cloud server 40 comprises a communication unit 41, a storage unit 42, and a control unit 43. Each element within the service cloud server 40 is interconnected via a bus line 49.

[0049] The communication unit 41 communicates with the vehicle cloud server 30 based on the control of the control unit 43. Specifically, the communication unit 41 receives information from the vehicle cloud server 30 that corresponds to the information provided, as described later.

[0050] The storage unit 42 includes non-volatile memory such as ROM and volatile memory such as RAM, and stores programs for various processes executed by the service cloud server 40. The storage unit 42 is also used as working memory when various processes are executed. The storage unit 42 may also store the history of job requests JR1 sent by the service cloud server 40 to the vehicle cloud server 30, and upload data UD1 obtained by the service cloud server 40 from the vehicle cloud server 30. In this case, for example, the job requests JR1 and upload data UD1 are stored in the storage unit 42 in association with information identifying the destination or source vehicle cloud server 30 and the transmission and reception times.

[0051] The control unit 43 is composed of a computer such as a CPU and controls the entire service cloud server 40. Specifically, the control unit 43 performs various processes by executing various programs stored in the memory unit 42.

[0052] (5) data structure Next, we will explain the data structure of the various data. Hereafter, if we do not distinguish between Job Request JR1 and Job Request JR2, we will simply refer to them as "Job Request," and if we do not distinguish between Upload Data UD1 and Upload Data UD2, we will simply refer to them as "Upload Data." (5-1) Job Request Figure 6 shows an example of the data structure of a job request. As shown in the figure, a job request includes "version information," "request identification information," "attribute information," "data collection condition information," "status management flags," and "collection data specification information."

[0053] "Version information" is information that identifies the version of the specification defining the job request. "Attribute information" is information that defines how the target job request should be handled.

[0054] The "request identification information" is unique identification information for job request JR1 generated by the service cloud server 40. Each time the service cloud server 40 generates a job request JR1, it generates unique request identification information and includes it in the job request JR1. The "request identification information" for job request JR2 may be the same as or different from the "request identification information" for job request JR1. In the latter case, the vehicle cloud server 30 sets unique identification information for each job request JR2 to be sent to the in-vehicle terminal 20 as the "request identification information" for job request JR2. In this case, for example, the vehicle cloud server 30 stores a table or the like that associates the "request identification information" of job request JR1 with the "request identification information" of job request JR2 generated based on that job request JR1. In this embodiment, the "request identification information" of job request JR1 is used as information to identify the job (job ID).

[0055] "Data collection condition information" is information that indicates the conditions for collecting data. For example, "data collection condition information" is information that indicates the geographical conditions under which the in-vehicle terminal 20 generates the uploaded data UD2, the temporal conditions under which the uploaded data UD2 is generated, events, the vehicle ID of vehicle V, and / or the driver ID of the driver of vehicle V. Here, the geographical conditions under which the uploaded data UD2 is generated are, for example, conditions that specify the road or area under which the uploaded data UD2 is generated, and the temporal conditions under which the uploaded data UD2 is generated are, for example, conditions that specify temporal constraints such as the time of day or interval under which the uploaded data UD2 is generated. Events refer to events that trigger the generation of uploaded data UD2, for example, the occurrence of an impact of a certain degree or more (i.e., an accident) or the occurrence of sudden braking may be specified as such events. Data collection condition information is an example of "condition information".

[0056] "Collection data specification information" is information that specifies the data to be included as uploaded data when the job execution conditions indicated by the data collection condition information are met. Examples of collection data specification information include information on vehicle acceleration and deceleration, vehicle speed, vehicle trajectory (i.e., vehicle position and attitude in time series), origin and destination information, and camera footage taken at a predetermined time before and after an accident. The contents specified as collection condition information and collection data specification information are arbitrarily set by the service company operating the service cloud server 40 that generates the job request. Collection condition information and collection data specification information are examples of "command information".

[0057] The "status management flag" is a flag (also called the "status management flag Fs") that specifies whether or not status count information needs to be uploaded. For example, the status management flag Fs can be either "0" which indicates invalidity or "1" which indicates validity. A value of 1 (valid) indicates that the status count information needs to be uploaded, while a value of 0 (invalid) indicates that the status count information does not need to be uploaded. The status management flag Fs is an example of flag information. Note that instead of being a separate field in the job request, the status management flag Fs may be included in one of the fields of data collection condition information, attribute information, or data collection specification information.

[0058] If the job request JR1 sent from the service cloud server 40 to the vehicle cloud server 30 includes a valid status management flag Fs, the vehicle cloud server 30 aggregates the number of vehicles related to the job status for the job indicated by the job request JR1. The vehicle cloud server 30 then sends the aggregated result to the service cloud server 40 as upload data UD1. The data structure of upload data UD1, which includes the above-mentioned aggregated result, will be described later with reference to Figure 9.

[0059] Furthermore, if the job request JR2 sent from the vehicle cloud server 30 to each in-vehicle terminal 20 includes a valid status management flag Fs, the in-vehicle terminal 20 generates the information necessary for the vehicle cloud server 30 to aggregate the number of vehicles related to the job status described above. The in-vehicle terminal 20 then includes the generated information in the upload data UD2 and sends it to the vehicle cloud server 30. The data structure of the upload data UD2 sent by the in-vehicle terminal 20 will be described later with reference to Figure 8.

[0060] Furthermore, a job request may include any information other than the information shown in Figure 6. For example, a job request may include address information specifying the destination for sending the uploaded data to the service cloud server 40 or vehicle cloud server 30 that generated the job request. In another example, a job request may include a job ID to identify the job, separate from the request identification information. For example, if the service cloud server 40 sends job request JR1 indicating the same job to multiple vehicle cloud servers 30, each job request JR1 may include different request identification information for each job request JR1 and a job ID common to all job request JR1s.

[0061] (5-2) Transmission history information Figure 7 shows an example of the data structure of transmission history information Ih. Transmission history information Ih corresponds to the transmission history of job request JR2, and in the example in Figure 7, it includes at least "vehicle ID" and "job ID".

[0062] The "Vehicle ID" is the vehicle ID corresponding to the in-vehicle terminal 20 to which the vehicle cloud server 30, which holds the transmission history information Ih, sent the job request JR2. The "Job ID" is the identification information of the job requested by the job request JR2 sent to the in-vehicle terminal 20. For example, the vehicle cloud server 30 may record the request identification information of the job request JR1 used to generate the job request JR2 as the "Job ID" in the transmission history information Ih.

[0063] Each time the vehicle cloud server 30 sends a job request JR2 to the in-vehicle terminal 20, it adds a record associated with the vehicle ID and job ID to the transmission history information Ih it maintains. The transmission history information Ih may also include any items other than the vehicle ID and job ID. For example, the transmission history information Ih may further include identification information of the service cloud that generated the job request JR1 used to generate the job request JR2 sent to the in-vehicle terminal 20. This identification information may be any information used to identify the service cloud (e.g., a communication address).

[0064] Furthermore, if the vehicle cloud server 30 receives upload data UD2 from the in-vehicle terminal 20 indicating that it was unable to successfully accept job request JR2 (i.e., that it failed), it deletes the corresponding record from the transmission history information Ih. Specifically, in this case, the vehicle cloud server 30 deletes from the transmission history information Ih the record containing the vehicle ID corresponding to the in-vehicle terminal 20 that sent the upload data UD2, and the job ID indicating the failed job. As a result, the transmission history information Ih will only contain records showing the combination of the vehicle ID of the in-vehicle terminal 20 that successfully received job request JR2 and the job ID corresponding to the job instructed by job request JR2.

[0065] Here, we will explain the use of the transmission history information Ih shown in Figure 7. The vehicle cloud server 30 can suitably calculate the number of inactive vehicles (also called the "number of inactive vehicles") by referring to the transmission history information Ih.

[0066] Specifically, the vehicle cloud server 30 calculates the number of records in the transmission history information Ih, which contains the job ID corresponding to the received job request JR1, as the number of vehicles that sent job request JR2. As shown in Figure 4, the job status automatically becomes inactive when the authentication process is successful, so jobs indicated by job request JR2 that have been successfully authenticated on the in-vehicle terminal 20 will always be inactive. If the authentication process fails and the job fails, upload data UD2 indicating that it has failed is sent to the vehicle cloud server 30, and the corresponding record is deleted from the transmission history information Ih by the vehicle cloud server 30. Therefore, by referring to the transmission history information Ih and counting the number of vehicles that sent job request JR2 for each job, the vehicle cloud server 30 can suitably identify the number of vehicles that have authenticated and accepted the job (number of inactive vehicles) for each job. As will be described later, the identified number of inactive vehicles is included in upload data UD1 and sent to the service cloud server 40.

[0067] (5-3) Uploaded data Next, we will explain in detail the data structures of the uploaded data UD1 and UD2.

[0068] Figure 8 shows an example of the data structure of the upload data UD2 that the in-vehicle terminal 20 sends to the vehicle cloud server 30 based on the job request JR2. As shown in the figure, the upload data UD2 includes "version information", "request identification information", "collected data", and "status count information".

[0069] "Version information" is information that identifies the version of the specification defining the uploaded data UD2. This "version information" may be the same as, for example, the "version information" included in the previously received job request JR2. "Request identification information" indicates the request identification information of the previously received job request JR2.

[0070] "Collected data" is data collected by the in-vehicle terminal 20 based on the previously received job request JR2, and corresponds to the execution result of the requested job. This collected data is the data specified by the "collected data specification information" of the previously received job request JR2. Collected data is an example of "response information".

[0071] The "status count information" is status count information stored in the storage unit 22 by the in-vehicle terminal 20 based on the previously received job request JR2, and includes the "number of active transitions" and the "number of inactive transitions". The "number of active transitions" indicates the number of times the job transitioned to the active state (i.e., the number of times it became active) during the validity period of the job requested by the previously received job request JR2. The "number of inactive transitions" indicates the number of times the job transitioned to the inactive state (i.e., the number of times it became inactive) during the validity period of the job requested by the previously received job request JR2. The status count information is an example of "count information".

[0072] Here, I will provide some additional information on how the state count information is generated.

[0073] If the previously received job request JR2 contains a valid state management flag Fs, the in-vehicle terminal 20 starts counting the number of transitions between the active and inactive states for the target job, and stores this transition count information as state count information in the storage unit 22. The in-vehicle terminal 20 then updates the state count information whenever there is a change in the job state for the target job. When generating the upload data UD2, the in-vehicle terminal 20 includes the state count information stored in the storage unit 22 in the upload data UD2.

[0074] Figure 9 shows an example of the data structure of the upload data UD1 that the vehicle cloud server 30 sends to the service cloud server 40 based on the job request JR1. As shown in the figure, the upload data UD2 includes "version information", "request identification information", "collected data", "number of inactive vehicles", "number of active vehicles", "total number of active vehicles", and "number of vehicles from which data was collected".

[0075] "Version information" is information that identifies the version of the specification defining the uploaded data UD1. This "version information" may be the same as the "version information" included in the previously received job request JR1. "Request identification information" indicates the request identification information of the previously received job request JR1.

[0076] "Collected data" corresponds to the execution result of the job requested by job request JR1, and is the data specified by the "Collected data specification information" of job request JR1. The vehicle cloud server 30 sends job request JR2, which it has generated based on job request JR1, to multiple in-vehicle terminals 20, and receives the upload data UD2, which is the response, from each in-vehicle terminal 20, thereby collecting the data to be included in upload data UD1 as "collected data". In this case, the vehicle cloud server 30 may include the data extracted directly from the collected data contained in the upload data UD2 received from each in-vehicle terminal 20 as "collected data" in upload data UD1, or it may include statistical data calculated by performing a predetermined statistical processing on the collected data contained in each upload data UD2 as "collected data" in upload data UD1.

[0077] The "number of inactive vehicles" is the number of vehicles whose job status has become inactive after being requested by job request JR1. In this embodiment, in the first example, the vehicle cloud server 30 calculates the number of inactive vehicles for the job requested by job request JR1 by referring to the transmission history information Ih. Specifically, the vehicle cloud server 30 calculates the number of inactive vehicles as the number of records among the records recorded in the transmission history information Ih in which the identification information of the job requested by job request JR1 (e.g., request identification information) is recorded as "job ID". As described above, if the authentication of job request JR2 is successful in the in-vehicle terminal 20 that received job request JR2, the status of the job requested by job request JR2 will always become inactive, and if the authentication of job request JR2 fails, the record in the transmission history information Ih corresponding to the transmission history of job request JR2 is deleted by the vehicle cloud server 30. Therefore, the vehicle cloud server 30 can suitably calculate the number of inactive vehicles for a job requested by job request JR1 by referring to the transmission history information Ih. In the second example, the vehicle cloud server 30 calculates based on the status count information included in the upload data UD2. In this case, the vehicle cloud server 30 calculates the number of in-vehicle terminals 20 that are the source of the upload data UD2 and whose number of inactive transitions indicated by the status count information above is one or more as the number of inactive vehicles for the job.

[0078] The "number of active vehicles" is the number of vehicles whose status has become active for the job requested by job request JR1. In this embodiment, the vehicle cloud server 30 calculates the number of active vehicles for the job requested by job request JR1 by referring to the number of active transitions indicated by the status count information of the upload data UD2 received from each in-vehicle terminal 20 as a response to job request JR2, which was generated based on job request JR1. Specifically, the vehicle cloud server 30 calculates the number of active vehicles for the job by the number of in-vehicle terminals 20 that sent upload data UD2 that resulted in one or more active transitions for the job. In this way, the vehicle cloud server 30 can suitably calculate the number of active vehicles for the job requested by job request JR2 by referring to the number of active transitions indicated by the status count information included in the upload data UD2 received from the in-vehicle terminals 20 that are the destinations of job request JR2.

[0079] The "total number of active vehicles" is the total number of vehicles whose status as a job requested by job request JR1 was in the active state. In this embodiment, the vehicle cloud server 30 calculates the total number of active vehicles for the job requested by job request JR1 by accumulating the number of active transitions indicated by the status count information contained in the upload data UD2 received from each in-vehicle terminal 20 as a response to job request JR2, which was generated based on job request JR1. In this way, the vehicle cloud server 30 can suitably calculate the total number of active vehicles for the job requested by job request JR2 by referring to the number of active transitions indicated by the status count information contained in the upload data UD2 received from the in-vehicle terminal 20 to which job request JR2 is sent. The number of inactive vehicles, the number of active vehicles, and the total number of active vehicles are examples of "mobile vehicle information".

[0080] The "number of data collection vehicles" is the number of vehicles that uploaded the data to the job requested by Job Request JR1. In this embodiment, the Vehicle Cloud Server 30 calculates the number of data collection vehicles as the number of vehicles that sent the upload data UD2 containing the data to be collected, from the upload data UD2 received from each in-vehicle terminal 20 as a response to Job Request JR2 generated based on Job Request JR1.

[0081] Next, I will provide a supplementary explanation regarding the use of the uploaded data UD1.

[0082] Upon receiving the uploaded data UD1, which has the data structure shown in Figure 9, as a response to the job request JR1, the service cloud server 40 can determine the reliability of the returned collected data, the effectiveness of the data collection request, and the cost-effectiveness based on the statistics of the number of vehicles included in the uploaded data UD1.

[0083] For example, the service cloud server 40 can suitably calculate indicators showing the effectiveness and cost efficiency of data collection requests based on job request JR1 by generating ratio information showing the ratio of active vehicles and / or data collection vehicles to the number of inactive vehicles. For example, the service cloud server 40 can determine that the higher the ratio shown in the above-mentioned ratio information, the more effective and cost-efficient the data collection request is. In addition, the service cloud server 40 can suitably determine the reliability of the collected data contained in the uploaded data UD1 received from the vehicle cloud server 30 by referring to the number of active vehicles, the total number of active vehicles, the number of data collection vehicles, etc. For example, the service cloud server 40 can determine that the higher the number of active vehicles, the total number of active vehicles, and the number of data collection vehicles, the more reliable the collected data received from the vehicle cloud server 30 is.

[0084] Note that the data structure example for the uploaded data UD1 is not limited to that shown in Figure 9. For example, the uploaded data UD1 may include the total number of inactive vehicles, which indicates the total number of vehicles that have entered an inactive state. In this case, the vehicle cloud server 30 determines the total number of inactive vehicles by accumulating the number of inactive transitions indicated by the state count information included in the uploaded data UD1 received from each in-vehicle terminal 20.

[0085] (6) Processing flow Next, the processes executed by the in-vehicle terminal 20 and the vehicle cloud server 30 when job requests JR1 and JR2 containing a valid state management flag Fs are generated will be specifically explained with reference to the flowcharts in Figures 10 and 11.

[0086] (6-1) Processing at in-vehicle terminals Figure 10 is a flowchart showing the processing steps that the in-vehicle terminal 20 executes when it receives a job request JR2 containing a valid status management flag Fs. The in-vehicle terminal 20 repeatedly executes the processes shown in the flowchart in Figure 10.

[0087] First, the in-vehicle terminal 20 receives a job request JR2 containing a valid status management flag Fs from the vehicle cloud server 30 (step S101). Then, the in-vehicle terminal 20 performs a predetermined authentication process on the job request JR2 and determines whether or not the received job request JR2 was authenticated (step S102).

[0088] Then, if the authentication process for the received job request JR2 is successful (step S102; Yes), the in-vehicle terminal 20 generates state count information for the job request JR2 because the job request JR2 contains a valid state management flag Fs (step S103). Here, if the authentication process for the job request JR2 is successful, the in-vehicle terminal 20 generates state count information with the number of active transitions set to 0 and the number of inactive transitions set to 1, because the job status automatically becomes inactive.

[0089] On the other hand, if the authentication process for the received job request JR2 fails (step S102; No), the in-vehicle terminal 20 sends upload data UD2 to the vehicle cloud server 30 indicating that authentication failed (i.e., that it failed) (step S110).

[0090] After generating the status count information in step S103, the in-vehicle terminal 20 determines whether the job execution conditions indicated by the "data collection condition information" included in the received job request JR2 are met (step S104). If the in-vehicle terminal 20 determines that the job execution conditions are met (step S104; Yes), it uses the data output by the sensor unit 27 to collect the data specified by the "collection data specification information" included in the job request JR2 (step S105). In this case, the job status becomes active. On the other hand, if the in-vehicle terminal 20 determines that the job execution conditions are not met (step S104; No), it proceeds to step S106 without performing the processing in step S105. In this case, the job status becomes inactive.

[0091] Next, the in-vehicle terminal 20 updates the status count information according to whether or not there has been a job status transition (step S106). Specifically, if the in-vehicle terminal 20 determines, based on the determination process in step S104, that the job has transitioned from an inactive state to an active state, it updates the status count information to increase the number of active transitions for that job by 1. On the other hand, if the in-vehicle terminal 20 determines, based on the determination process in step S104, that the job has transitioned from an active state to an inactive state, it updates the status count information to increase the number of inactive transitions for that job by 1.

[0092] Next, the in-vehicle terminal 20 determines whether or not it is time to send the upload data UD2 (step S107). The timing for sending the upload data UD2 may be determined by various rules. For example, the in-vehicle terminal 20 may send the upload data UD2 only once at the end of the job's validity period, or it may send the upload data UD2 each time data collection is performed in step S105, or it may send the upload data UD2 at predetermined time intervals. The specific timing for sending the upload data UD2 is set, for example, to the timing specified by the data collection condition information included in the job request JR2 received from the vehicle cloud server 30.

[0093] Then, if it is time to send the upload data UD2 (step S107; Yes), the in-vehicle terminal 20 sends the upload data UD2 (see Figure 8), which includes the collected data collected in step S105 and status count information indicating the number of inactive transitions and active transitions, to the vehicle cloud server 30 (step S108). Note that if the in-vehicle terminal 20 sends the upload data UD2 at multiple timings, it may include the status count information only in the upload data UD2 sent at the last timing. In addition, the in-vehicle terminal 20 may send the upload data UD2 to the vehicle cloud server 30 which includes the status count information at least at the end of the job's validity period, in order to include the final number of active transitions and inactive transitions in the upload data UD2. In this case, the upload data UD2 does not have to include the collected data. That is, in this case, the in-vehicle terminal 20 does not necessarily have to synchronize the timing of sending the collected data and the status count information.

[0094] Next, the in-vehicle terminal 20 determines whether the job has finished (step S109). For example, if the "data collection condition information" included in the received job request JR2 indicates the job's expiration date, it determines whether the job's expiration date has expired. If the in-vehicle terminal 20 determines that the job has finished (step S109; Yes), it terminates the flowchart processing. On the other hand, if the in-vehicle terminal 20 determines that it is not time to send the upload data UD2 (step S107; No), or determines that the job has not finished (step S109; No), it returns to step S104.

[0095] (6-2) Vehicle cloud server processing Figure 11 shows a flowchart illustrating the processing steps performed by the vehicle cloud server 30 upon receiving a job request JR1 containing a valid status management flag Fs.

[0096] First, the vehicle cloud server 30 receives a job request JR1 containing a valid status management flag Fs from the service cloud server 40 (step S201). Then, the vehicle cloud server 30 refers to the vehicle information stored in the storage unit 32 and sends a job request JR2, generated based on the job request JR1, to the in-vehicle terminal 20 of the vehicle managed by the vehicle cloud server 30 (step S202).

[0097] Subsequently, the vehicle cloud server 30 receives the upload data UD2 from the in-vehicle terminal 20, which is the destination of the job request JR2, and stores it in the storage unit 32 (step S203). The vehicle cloud server 30 then repeatedly receives and stores the upload data UD2 in step S203 until the predetermined collection period for the upload data UD2 ends (step S204; No). In this way, the vehicle cloud server 30 stores the upload data UD2 supplied from the in-vehicle terminals 20 of multiple vehicles.

[0098] Furthermore, as an embodiment not shown in the flowchart, for example, for information requiring a certain degree of real-time processing, the vehicle cloud server 30 may, during the collection period for the upload data UD2, send the regularly or intermittently received upload data UD2 directly to the service cloud server 40 as upload data UD1 without accumulating it in the storage unit 32. In this case, after the collection period for the upload data UD2 ends, the vehicle cloud server 30 sends only the status count information aggregated in step S205, described later, to the service cloud server 40.

[0099] Then, if the vehicle cloud server 30 determines that the collection period for the uploaded data UD2 has ended (step S204; Yes), it performs aggregations of the number of inactive vehicles, the number of active vehicles, the total number of active vehicles, the number of vehicles collecting data, etc. (step S205). For example, the vehicle cloud server 30 calculates the number of active vehicles and the total number of active vehicles based on the number of active transitions indicated by the status count information included in the uploaded data UD2 received and stored in step S203. The vehicle cloud server 30 also calculates the number of inactive vehicles based on either the transmission history information Ih or the number of inactive transitions indicated by the status count information, and calculates the number of vehicles collecting data by counting the number of in-vehicle terminals 20 that are the source of the uploaded data UD2 containing the collected data. If the vehicle cloud server 30 has received uploaded data UD2 for the same job multiple times from the same in-vehicle terminal 20, it is preferable to perform the above aggregations based on the status count information included in the last received uploaded data UD2.

[0100] Next, the vehicle cloud server 30 sends the upload data UD1 (see Figure 9), which includes the aggregation results from step S205, to the service cloud server 40, which is the source of the job request JR1 (step S206). Subsequently, the service cloud server 40, which generated the job request JR1, receives the upload data UD1 from the vehicle cloud server 30. In this case, the service cloud server 40 uses the received upload data UD1 to determine the reliability of the returned collected data, the effectiveness of the data collection request, and the cost-effectiveness.

[0101] (7) Application examples Next, we will describe an example of how this embodiment can be applied. Here, we will describe an example in which a local government, such as a city or town, uses the job distribution system to grasp detailed traffic congestion information and road usage conditions as part of urban planning and road use analysis.

[0102] Figure 12 shows an example configuration of the job distribution system in this application example. The job distribution system shown in Figure 12 includes a first service cloud server 40A operated by a map company, a first service cloud server 40A operated by a local government, a vehicle cloud server 30 operated by a taxi company, and a taxi vehicle V equipped with an in-vehicle terminal 20. Here, the first service cloud server 40A functions as the service cloud server 40 of the embodiment, and the second service cloud server 40B receives data collected by the first service cloud server 40A from the first service cloud server 40A.

[0103] The municipality has two train stations (Station A and Station B), and the streets in front of each station are congested, so widening of the station front streets is necessary. To systematically widen the station front streets, traffic congestion data will be collected. There are a total of 80 taxi vehicles (V) that frequently travel on the streets in front of the two train stations. In addition, there is a taxi stand at each station.

[0104] Figure 13 is an overhead view showing the street in front of Station A. As shown in the figure, near Station A there is a main road 50, a station front road 51 that branches off from the main road 50, and a taxi stand 52 that can merge with station front road 51. Station front road 51 has an intersection 53 that leads to taxi stand 52 and an intersection 54 that serves as an entrance to the main road 50.

[0105] Here, the first service cloud server 40A generates a job request JR1 as "collection data specification information" as shown in Figure 6, specifying the driving time and dwell (stopping) time when leaving the taxi pool 52 and passing through the station front road 51 from intersection 53 to intersection 54, and the driving time and dwell time when returning from intersection 54 to the taxi pool 52. This job request JR1 also includes "data collection condition information" (see Figure 6) which sets the job's validity period to one week from the following Monday to Sunday, and the job's execution time to be from 6 a.m. to 7 p.m. Then, based on the upload data UD1 received from the vehicle cloud server 30 as a response to the job request JR1, the first service cloud server 40A calculates the average driving time and average dwell time for each time period divided into 10-minute intervals. Then, the first service cloud server 40A sends the calculated average driving time and average dwell time as upload data to the second service cloud server 40B. In this case, the second service cloud server 40B examines the content of the traffic congestion information based on the uploaded data received from the first service cloud server 40A. Similarly, the first service cloud server 40A calculates the average travel time and average dwell time for the road in front of Station B based on the uploaded data UD1 received from the vehicle cloud server 30, and sends the uploaded data including the calculation results to the second service cloud server 40B.

[0106] In such cases, the first service cloud server 40A includes a valid status management flag Fs in the job request JR1, receives statistical data on the number of vehicles related to the job status, etc., from the vehicle cloud server 30 via uploaded data UD1, and supplies it to the second service cloud server 40B. This allows the second service cloud server 40B to consider the statistical data on the number of vehicles related to the job status, etc., when examining the content of the congestion information in front of each station, thereby enabling an accurate examination of the congestion information. Furthermore, for time periods when there are no or very few measured vehicles (i.e., very few active vehicles), it is possible to infer that these were times when there was no influx of taxis onto the road in front of the station due to severe congestion, or times when there was no demand for taxis (i.e., times when many taxi vehicles V were waiting in the taxi pool). Based on the collected data and the aforementioned statistical data on the number of vehicles, the local government will consult with taxi companies, etc., as necessary, to adjust the conditions for acquiring congestion information and the methods for analysis.

[0107] <Second Example> In the second embodiment, the in-vehicle terminal 20 transmits to the vehicle cloud server 30 status count information indicating the number of transitions to each job state, instead of transmitting status count information indicating the number of transitions to each job state, transmits history information regarding job state transitions (also called "status history information") to the vehicle cloud server 30. Hereafter, the configuration of the vehicle cloud server 30 and the service cloud server 40, the data structure of job requests JR1 and JR2, the data structure of uploaded data UD1, etc., are the same as in the first embodiment, so their explanation will be omitted.

[0108] Figure 14 is a block diagram showing the internal configuration of an in-vehicle terminal 20 according to the second embodiment. As shown in the figure, the storage unit 22 of the in-vehicle terminal 20 stores state history information. The state history information is the history information of the state transitions of a job requested by a job request JR2 during the period in which the job is valid. The state history information is, for example, table information that associates the state to which a job has transitioned with the time of the transition for each requested job (for example, for each request identification information). The in-vehicle terminal 20 stores the job state transitions for the target job as state history information in the storage unit 22 when a valid state management flag Fs is included in the job request JR2 that was received earlier.

[0109] Figure 15 shows an example of the data structure of the uploaded data UD2 according to the second embodiment. As shown in Figure 15, the uploaded data UD2 according to the second embodiment includes "state history information" instead of state count information. When a valid state management flag Fs is included in the corresponding job request JR2, the in-vehicle terminal 20 sends the state history information corresponding to the job, along with the collected data which is the execution result of the job requested by the job request JR2, to the vehicle cloud server 30 in the uploaded data UD2. As a result, the vehicle cloud server 30, upon receiving the uploaded data UD2, can refer to the state history information to suitably calculate the number of inactive transitions and active transitions of the in-vehicle terminal 20 that sent the uploaded data UD2. The state history information is an example of "counting information".

[0110] Figure 16 is a flowchart showing the processing procedure executed by the in-vehicle terminal 20 according to the second embodiment when it receives a job request JR2 containing a valid status management flag Fs. The in-vehicle terminal 20 repeatedly executes the process shown in the flowchart in Figure 16.

[0111] The in-vehicle terminal 20 receives a job request JR2 containing a valid status management flag Fs from the vehicle cloud server 30 (step S301). If the authentication process for the received job request JR2 is successful (step S302; Yes), it generates status history information for the job requested by the job request JR2 (step S303). In this case, the job status automatically becomes inactive, so the in-vehicle terminal 20 generates status history information that records the transition to the inactive state.

[0112] Then, if the in-vehicle terminal 20 finds that the job execution conditions indicated by the "data collection condition information" included in the received job request JR2 are met (step S304; Yes), it uses the data output by the sensor unit 27 to collect the data specified by the "collection data specification information" included in the job request JR2 (step S305). In this case, the job status becomes active. On the other hand, if the in-vehicle terminal 20 determines that the job execution conditions are not met (step S304; No), it proceeds to step S306 without performing the processing in step S305. In this case, the job status becomes inactive.

[0113] Next, the in-vehicle terminal 20 updates the status history information depending on whether or not there has been a job status transition (step S306). Specifically, the in-vehicle terminal 20 compares the current job status with the latest job status indicated by the status history information and, if it determines that the current job status has transitioned from an inactive state to an active state, adds a record indicating the transition to an active state to the status history information for the target job. If it determines that the job status has transitioned from an active state to an inactive state, it adds a record indicating the transition to an inactive state to the status history information for the target job.

[0114] Subsequently, similar to the first embodiment, if it is time to send the upload data UD2 (step S307; Yes), the in-vehicle terminal 20 sends the upload data UD2 (see Figure 15), which includes the collected data and status history information collected in step S305, to the vehicle cloud server 30 (step S308). Also, if the in-vehicle terminal 20 determines that the job has finished (step S309; ​​Yes), it terminates the flowchart processing. On the other hand, if it is not time to send the upload data UD2 (step S307; No), or if the job has not finished (step S309; ​​No), processing returns to step S304.

[0115] Figure 17 shows a flowchart illustrating the processing procedure executed by the vehicle cloud server 30 in the second embodiment upon receiving a job request JR1 containing a valid state management flag Fs.

[0116] First, the vehicle cloud server 30 receives a job request JR1 containing a valid status management flag Fs from the service cloud server 40 (step S401). Then, the vehicle cloud server 30 refers to the vehicle information stored in the storage unit 32 and sends a job request JR2, generated based on the job request JR1, to the in-vehicle terminal 20 of the vehicle managed by the vehicle cloud server 30 (step S402).

[0117] Subsequently, the vehicle cloud server 30 receives the upload data UD2, which includes status history information, from the in-vehicle terminal 20 and stores it in the storage unit 32 (step S403). The vehicle cloud server 30 then repeatedly receives and stores the upload data UD2 in step S403 until the predetermined collection period for the upload data UD2 ends (step S404; No).

[0118] Then, if the vehicle cloud server 30 determines that the collection period for the uploaded data UD2 has ended (step S404; Yes), it calculates the number of active transitions for each vehicle based on the state history information contained in the uploaded data UD2 received and stored in step S403 (step S405). In this case, the vehicle cloud server 30 may also calculate the number of inactive transitions in addition to the number of active transitions based on the state history information. If the vehicle cloud server 30 has received uploaded data UD2 for the same job multiple times from the same in-vehicle terminal 20, it is preferable to perform the above calculations based on the state history information contained in the last received uploaded data UD2.

[0119] The vehicle cloud server 30 then aggregates the number of inactive vehicles, the number of active vehicles, the total number of active vehicles, the number of vehicles collecting data, etc. (step S406). For example, the vehicle cloud server 30 calculates the number of active vehicles and the total number of active vehicles based on the number of active transitions for each vehicle calculated in step S405. The vehicle cloud server 30 also calculates the number of inactive vehicles based on either the transmission history information Ih or the number of inactive transitions calculated in step S405, and calculates the number of vehicles collecting data by counting the number of in-vehicle terminals 20 that are the source of the uploaded data UD2 containing the collected data.

[0120] Next, the vehicle cloud server 30 sends the upload data UD1 (see Figure 9), which includes the aggregation results from step S405, to the service cloud server 40, which is the source of the job request JR1 (step S407). Subsequently, the service cloud server 40, which generated the job request JR1, receives the upload data UD1 from the vehicle cloud server 30. In this case, the service cloud server 40 performs the following based on the received upload data UD1: determining the reliability of the returned collected data, determining the effectiveness and cost-effectiveness of the data collection request, etc.

[0121] <Third Example> In the third embodiment, the in-vehicle terminal 20 transmits information indicating the current job status (also simply called "status information") to the vehicle cloud server 30 instead of status count information or status history information. Hereafter, the configuration of the service cloud server 40, the data structure of job requests JR1 and JR2, the data structure of uploaded data UD1, etc., are the same as in the first and second embodiments, so their explanation will be omitted.

[0122] Figure 18 shows an example of the data structure of the uploaded data UD2 according to the third embodiment. As shown in Figure 18, the uploaded data UD2 according to the third embodiment includes "status information" instead of the status count information of the first embodiment or the status history information of the second embodiment.

[0123] If a valid status management flag Fs is included in the job request JR2, the in-vehicle terminal 20 sends the upload data UD2 to the vehicle cloud server 30, along with the collected data which is the execution result of the job requested by the job request JR2, and status information indicating the current job status corresponding to that job. In this case, the in-vehicle terminal 20 sends the upload data UD2 to the vehicle cloud server 30 at time intervals specified by the data collection condition information included in the job request JR2 received from the vehicle cloud server 30. The timing of sending the upload data UD2 in this case may be determined for each job, or it may be uniform for multiple jobs. Status information is an example of "counting information".

[0124] Figure 19 is a schematic diagram showing the internal configuration of the vehicle cloud server 30 according to the third embodiment. As shown in Figure 19, the vehicle cloud server 30 stores state history information in the storage unit 32. Here, the vehicle cloud server 30 generates state history information for each job and for each vehicle ID based on the state information contained in the upload data UD2 received from the in-vehicle terminal 20. In this case, for example, the state history information is information that associates the job state indicated by the state information with the reception time or generation time of the state information for each request identification information and vehicle ID. By holding such state history information, the vehicle cloud server 30 can suitably perform aggregations of the number of inactive vehicles, the number of active vehicles, the total number of active vehicles, the number of data collection vehicles, etc., similar to the first and second embodiments.

[0125] Figure 20 is a flowchart showing the processing procedure executed by the in-vehicle terminal 20 according to the third embodiment when it receives a job request JR2 containing a valid status management flag Fs. The in-vehicle terminal 20 repeatedly executes the process shown in the flowchart in Figure 20.

[0126] The in-vehicle terminal 20 receives a job request JR2 containing a valid status management flag Fs from the vehicle cloud server 30 (step S501). If the authentication process for the received job request JR2 is successful (step S502; Yes), it determines whether the execution conditions for the job indicated by the received job request JR2 are met (step S503). If the job execution conditions are met (step S503; Yes), it collects the data specified by the job request JR2 using the data output by the sensor unit 27 (step S504). On the other hand, if the in-vehicle terminal 20 determines that the job execution conditions are not met (step S503; No), it proceeds to step S505 without performing the process in step S504.

[0127] Next, the in-vehicle terminal 20 determines whether it is time to send the upload data UD2 (step S505). In this case, the timing for sending the upload data UD2 may be determined for each job, or it may be uniform for multiple jobs. If it is time to send the upload data UD2 (step S505; Yes), the in-vehicle terminal 20 generates status information indicating the current job status (step S505). Specifically, if the job execution conditions are not met, the in-vehicle terminal 20 generates status information indicating that the job is in an inactive state, and if the job execution conditions are met, it generates status information indicating that the job is in an active state.

[0128] Then, the in-vehicle terminal 20 sends the upload data UD2, which includes the status information generated in step S506 and the collected data collected in step S504, to the vehicle cloud server 30 (step S507). If the in-vehicle terminal 20 determines that the job should be terminated (step S508; Yes), it terminates the flowchart processing.

[0129] On the other hand, if it is not time to send the uploaded data UD2 (step S505; No), or if the job has not finished (step S508; No), the in-vehicle terminal 20 returns to step S503. As a result, the in-vehicle terminal 20 repeatedly executes steps S503 to S507 until the job's expiration date is reached.

[0130] Figure 21 shows a flowchart illustrating the processing procedure executed by the vehicle cloud server 30 in the third embodiment upon receiving a job request JR1 containing a valid state management flag Fs.

[0131] First, the vehicle cloud server 30 receives a job request JR1 containing a valid status management flag Fs from the service cloud server 40 (step S601). Then, the vehicle cloud server 30 refers to the vehicle information stored in the storage unit 32 and sends a job request JR2, generated based on the job request JR1, to the in-vehicle terminal 20 of the vehicle managed by the vehicle cloud server 30 (step S602).

[0132] Subsequently, the vehicle cloud server 30 receives the upload data UD2 containing status information from the in-vehicle terminal 20 and stores it in the storage unit 32 (step S603). Then, the vehicle cloud server 30 updates the status history information corresponding to the job and vehicle ID indicated by the received upload data UD2 (step S604). For example, the vehicle cloud server 30 adds a record to the target status history information that includes the job status indicated by the status information of the received upload data UD2 and the time information. Then, the vehicle cloud server 30 repeats steps S603 and S604 until the predetermined collection period for upload data UD2 ends (step S605; No).

[0133] Then, if the vehicle cloud server 30 determines that the collection period for the uploaded data UD2 has ended (step S605; Yes), it calculates the number of active transitions for each vehicle based on the state history information stored in the storage unit 32 (step S606). In this case, the vehicle cloud server 30 may also calculate the number of inactive transitions in addition to the number of active transitions based on the state history information.

[0134] The vehicle cloud server 30 then aggregates the number of inactive vehicles, the number of active vehicles, the total number of active vehicles, the number of vehicles collecting data, etc. (step S607). For example, the vehicle cloud server 30 calculates the number of active vehicles and the total number of active vehicles based on the number of active transitions for each vehicle calculated in step S605. The vehicle cloud server 30 also calculates the number of inactive vehicles based on either the transmission history information Ih or the number of inactive transitions calculated in step S605, and calculates the number of vehicles collecting data by counting the number of in-vehicle terminals 20 that are the source of the uploaded data UD2 containing the collected data.

[0135] Next, the vehicle cloud server 30 sends the upload data UD1 (see Figure 9), which includes the aggregation results from step S605, to the service cloud server 40, which is the source of the job request JR1 (step S608). Subsequently, the service cloud server 40, which generated the job request JR1, receives the upload data UD1 from the vehicle cloud server 30. In this case, the service cloud server 40 performs the following based on the received upload data UD1: determining the reliability of the returned collected data, determining the effectiveness and cost-effectiveness of the data collection request, etc.

[0136] As explained above, the vehicle cloud server 30 receives job request JR1 issued by the service cloud server 40 and sends job request JR2 corresponding to job request JR1 to the in-vehicle terminals 20 of multiple vehicles. The vehicle cloud server 30 also receives upload data UD2, which is the reception result indicating that the in-vehicle terminals 20 of multiple vehicles have successfully received job request JR2, and counts the number of inactive vehicles, which is the number of vehicles that have successfully received job request JR2, based on the upload data UD2. The vehicle cloud server 30 also receives upload data UD2 in which the number of active transitions for the job is one or more, and counts the number of active vehicles and the total number of active vehicles, which represent the number of vehicles that sent the said upload data UD2 and the total number of vehicles. Finally, the vehicle cloud server 30 sends upload data UD1, which contains information on the number of inactive vehicles, the number of active vehicles, and the total number of active vehicles, to the service cloud server 40.

[0137] As described above, the vehicle cloud server 30 receives the job request JR1 issued by the service cloud server 40. The vehicle cloud server 30 then generates a job request JR2 which includes data collection condition information and data collection specification information corresponding to the job request JR1, and a state count information or state history information or a state management flag Fs indicating that state information should be transmitted to count the number of active transitions, which is the number of times the job status indicated by the data collection condition information and data collection specification information has entered an active state, which is the state in which the job is executed when predetermined conditions are met. The vehicle cloud server 30 then transmits the job request JR2 to the in-vehicle terminals 20 of multiple vehicles. The vehicle cloud server 30 then receives the upload data UD2 which includes the collected data and state count information or state history information or state information for the job request JR2, and counts at least one of the number of active vehicles or the total number of active vehicles based on the state count information or state history information or state information. The vehicle cloud server 30 then transmits the upload data UD1 based on the above counting result to the service cloud server 40.

[0138] <Variation> Next, preferred modifications of the first to third embodiments described above will be explained. The following modifications may be applied to the above embodiments in any combination.

[0139] (Variation 1) In the first to third embodiments, a function equivalent to the in-vehicle terminal 20 may be built into the vehicle V. In this case, the vehicle's electronic control unit (ECU) executes a program stored in the vehicle's memory, thereby performing processing equivalent to the control unit 24 of the in-vehicle terminal 20. In this case, the vehicle V is an example of a "mobile body," and the vehicle V's electronic control unit is an example of a "terminal device."

[0140] (Modification 2) In the first embodiment, the state count information included information about the number of inactive transitions. Alternatively, the state count information does not need to include information about the number of inactive transitions.

[0141] In this case, the in-vehicle terminal 20 counts only the number of active transitions in steps S103 and S106 of Figure 10, and includes the counted number of active transitions in the upload data UD2 and sends it to the vehicle cloud server 30. In this case, the vehicle cloud server 30 calculates the number of inactive vehicles in step S205 of Figure 11 based on the transmission history information Ih. The vehicle cloud server 30 also calculates the number of data collection vehicles by counting the number of in-vehicle terminals 20 that are the source of the upload data UD2.

[0142] Similarly, the status history information in the second embodiment does not necessarily have to include information regarding the transition to an inactive state. In this case as well, the vehicle cloud server 30, which receives the uploaded data UD2 containing the status history information, can calculate the number of inactive vehicles based on the transmission history information Ih in step S406 of Figure 17.

[0143] (Variation 3) In the first embodiment, the in-vehicle terminal 20 may generate state count information from the state history information when transmitting the upload data UD2 and include the state count information in the upload data UD2. In this case, the in-vehicle terminal 20 stores the state history information in the storage unit 22, as in Figure 14. Then, at the timing of transmitting the upload data UD2, the in-vehicle terminal 20 generates state count information by referring to the state history information stored in the storage unit 22 and transmits it to the vehicle cloud server 30 as upload data UD2 together with the collected data, etc.

[0144] (Modification 4) In the first to third embodiments, there may be multiple jobs included in job requests JR1 and JR2. In this case, common execution conditions may be set for multiple jobs, or different execution conditions may be set for each job. If different execution conditions are set for each job, each job will have its own job state. For example, the transition from an inactive state to an active state will occur when jobs that meet their execution conditions individually transition to the active state.

[0145] (Variation 5) In the first to third embodiments, the vehicle cloud server 30 may generate ratio information indicating the ratio of active vehicles to inactive vehicles, or the ratio of data collection vehicles to inactive vehicles, and include this ratio information in the uploaded data UD1 and send it to the service cloud server 40. This allows the vehicle cloud server 30 to suitably send to the service cloud server 40 information necessary for determining the effectiveness and cost efficiency of data collection requests. In this modified example, the ratio information described above is an example of "mobile vehicle number information". [Explanation of symbols]

[0146] 20 In-vehicle terminals 27. Recovery Department 30 Vehicle Cloud Servers 40 Service Cloud Servers

Claims

1. A first receiving unit that receives a request signal issued by an information management device, A generation unit that generates command information corresponding to the aforementioned request signal, A first transmission unit that transmits the command information to multiple mobile units, A second receiving unit receives a reception result indicating that the plurality of mobile bodies were able to successfully receive the command information, Based on the reception results, a first counting unit counts the number of mobile units that were able to successfully receive the command information, A third receiving unit that receives response information to the command information, A mobile object management device characterized by comprising a second transmission unit that transmits the number of mobile objects that have been successfully received to the information management device.

2. The system further includes a second counting unit that counts the number of mobile bodies that transmitted the response information based on the response information, The mobile body management device according to claim 1, characterized in that the second transmitting unit transmits to the information management device mobile body count information relating to the number of mobile bodies that transmitted the response information, in addition to the number of mobile bodies that were successfully received.

3. The command information includes condition information indicating the conditions under which the mobile body will execute the command indicated in the command information, The mobile body management device according to claim 2, characterized in that the response information includes information about the states that the command information can take depending on whether or not the conditions are met.

4. The mobile body management device according to claim 3, wherein the first transmitting unit transmits the command information and flag information that instructs the transmission of information regarding the states that the command information can take to the plurality of mobile bodies.

5. The states that the command information can take include an execution state in which the command is executed when the conditions are met, and a non-execution state in which the command is not executed when the conditions are not met. The mobile body management device according to claim 3 or 4, wherein the second transmitting unit transmits to the information management device information indicating the ratio of the number of mobile bodies for which the command information has been executed to the number of mobile bodies for which the command information has been successfully received, as the mobile body number information.

6. The mobile body management device according to any one of claims 1 to 5, further comprising a storage unit that stores in association the identification information of a mobile body from which the first transmission unit has transmitted the command information and the identification information of the command indicated by the command information.

7. The mobile device management device according to any one of claims 1 to 6, wherein the reception result includes fail information indicating that the command information was not properly received.

8. A control method performed by a mobile device management device, A first receiving step in which a request signal is received from an information management device, A generation step that generates command information corresponding to the request signal, A first transmission step of transmitting the command information to multiple mobile bodies, A second receiving step involves receiving a reception result indicating that the plurality of mobile bodies were able to successfully receive the command information, Based on the reception results, a first counting step is performed to count the number of mobile units that were able to successfully receive the command information, A third receiving step of receiving response information to the command information, A second counting step is performed to count the number of mobile bodies that transmitted the response information based on the response information, A control method characterized by comprising a second transmission step of transmitting information about the number of mobile bodies that were successfully received and the number of mobile bodies that transmitted the response information to the information management device.

9. A program that causes a computer to execute the control method described in claim 8.

10. A storage medium characterized by storing the program described in claim 9.

Images