JP2020107148A - Moving body management device, terminal device, data structure, control method, program and storage medium - Google Patents

Abstract

To provide a moving body management device capable of suitably acquiring statistical data regarding a state of a process in which a vehicle is instructed to execute.SOLUTION: A vehicle cloud server 30 generates a job request JR2 and transmits the job request JR2 to on-vehicle terminals 20 of a plurality of vehicles. Then, the vehicle cloud server 30 receives upload data UD2 including acquired data for the job request JR2, and status count information or status history information or status information and counts at least one of the number of active vehicles and a total number of active vehicles based on the status count information or status history information or status information. Then, the vehicle cloud server 30 transmits upload data UD1 based on the above-mentioned counting result to the service cloud server 40.SELECTED DRAWING: Figure 17

Description

The present invention relates to a state management technique in data collection.

2. Description of the Related Art Conventionally, a technique is known in which information of sensors installed in a vehicle is collected by a server device. For example, in Patent Document 1, 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, a driving assistance device that transmits change point information regarding the change point to a server device. Is disclosed.

JP, 2016-156973, A

Companies that provide various services related to vehicles operate their own servers to specify the data to be uploaded to the vehicles and to provide the vehicles required for service provision via a server (vehicle management server) that manages the vehicles. It is envisaged to collect various information on the future. In such a system, the vehicle is required to recognize as uploading the instructed data when a predetermined execution condition is satisfied, and to execute the job when the execution condition described above is satisfied. ..

On the other hand, the data collection request generated by the server of the service company is not guaranteed to be delivered to the vehicle, and when the vehicle management server has a high load or there is no vehicle that satisfies the collection condition and the vehicle to which the data collection request should be delivered is. If it does not exist, it will not be delivered to the vehicle. In addition, when the vehicle side has a high load and the data collection request is deleted from the vehicle, the data collection request is not properly executed by the vehicle. In consideration of the above, it is necessary to appropriately manage the state of the process instructed to execute each vehicle in order to accurately grasp the effectiveness, cost efficiency, reliability of the collected data, etc. of the data collection request.

The present invention has been made to solve the above problems, and provides a moving object management apparatus capable of suitably acquiring statistical data regarding the state of a process instructing a vehicle to execute. The main purpose is.

According to another aspect of the present invention, there is provided a mobile management device, wherein a first receiving unit that receives a request signal issued by an information management device, command information according to the request signal, and a status of the command information are: Generating transmission information including flag information indicating transmission of count information for counting the number of times of execution, which is a state of executing the command indicated by the command information when a predetermined condition is satisfied. A generation unit, a first transmission unit that transmits the transmission information to a plurality of moving bodies, a second reception unit that receives the response information to the command information and the count information, and based on the count information, Based on the counting result of the counting unit, and a counting unit that counts at least one of the number of mobile units whose command information is in the execution state and the number of times the command information of each mobile unit is in the execution state. A second transmitting unit that transmits information to the information management device.

Further, the invention described in the claims is a data structure of transmission data transmitted by the mobile management device for each mobile, and includes command information indicating the content of a command to be executed by the mobile, and a state of the command information. Is the flag information indicating that the count information for counting the number of times the execution state, which is the state of executing the command indicated by the command information, is transmitted when a predetermined condition is satisfied, and transmission data having It is a data structure.

Further, the invention described in the claims is a control method executed by a mobile management device, the first receiving step of receiving a request signal issued by the information management device, and command information according to the request signal, The state of the command information, flag information indicating that to transmit the count information for counting the number of times the execution state is a state of executing the command indicated by the command information when a predetermined condition is satisfied, A generation step of generating transmission information including: a first transmission step of transmitting the transmission information to a plurality of moving bodies; a second reception step of receiving response information to the command information and the count information; A counting step of counting at least one of the number of moving bodies in which the command information is in the execution state and the number of times in which the command information for each moving body is in the execution state based on the counting information; A second transmitting step of transmitting information based on the counting result of the counting section to the information management device.

Further, the invention described in the claims is a terminal device mounted on a mobile body, wherein the command information issued by the mobile body management device in response to a request signal issued by the information management device and the state of the command information are A flag information indicating that the count information for counting the number of times of execution in which the command indicated by the command information is executed when a predetermined condition is satisfied is transmitted to the mobile management device. A receiving unit that receives transmission information including the receiving unit from the mobile management device, a generation unit that generates the count information based on the flag information, the count information, and response information to the command information, to the mobile management device. And a transmitting unit for transmitting.

1 shows a schematic configuration of a job distribution system according to a first example. It is the figure which showed roughly the flow of the data between an in-vehicle terminal, a vehicle cloud server, and a service cloud server. It is a block diagram which shows the internal structure of a vehicle-mounted terminal. It is a figure which showed roughly the state transition of the in-vehicle terminal to a job. It is a block diagram which shows the internal structure of a vehicle cloud server and a service cloud server. It is an example of a data structure of a job request. It is an example of a data structure of transmission history information. It is an example of a data structure of upload data that the vehicle-mounted terminal transmits to the vehicle cloud server based on a job request. It is an example of the data structure of upload data which a vehicle cloud server transmits to a service cloud server based on a job request. It is a flow chart which shows a processing procedure which an in-vehicle terminal performs, when a job request containing a valid state management flag is received. 9 is a flowchart showing a processing procedure executed by a vehicle cloud server that receives a job request including a valid state management flag. The structural example of the job distribution system in an application example is shown. It is the bird's-eye view which showed the station front street of A station. It is a block diagram which shows the internal structure of the vehicle-mounted terminal which concerns on 2nd Example. It is an example of a data structure of upload data according to the second embodiment. It is a flowchart which shows the process procedure which the vehicle-mounted terminal which concerns on 2nd Example performs, when the job request containing the effective state management flag is received. 9 is a flowchart showing a processing procedure executed by the vehicle cloud server according to the second embodiment which receives a job request including a valid status management flag. It is an example of a data structure of upload data according to the third embodiment. It is the figure which showed roughly the internal structure of the vehicle cloud server which concerns on 3rd Example. It is a flowchart which shows the process procedure which the vehicle-mounted terminal which concerns on 3rd Example which received the job request containing the effective state management flag. 9 is a flowchart showing a processing procedure executed by the vehicle cloud server according to the third embodiment which receives a job request including a valid status management flag.

In a preferred embodiment, the mobile management device includes a first receiving unit that receives a request signal issued by an information management device, command information according to the request signal, and a state of the command information that meets a predetermined condition. And a flag information indicating that the count information for counting the number of times of execution, which is a state of executing the command indicated by the command information, is transmitted, and a generation unit that generates transmission information including A first transmitting unit that transmits the transmission information to a plurality of moving bodies, a second receiving unit that receives response information for the command information and the count information, and the command information based on the count information. A count unit for counting at least one of the number of mobile units in the execution state and the number of times the command information for each mobile unit has been in the execution state, and information based on the counting result of the count unit. A second transmitting unit for transmitting to the information management device. According to this aspect, the mobile management device provides the counting information for counting at least one of the number of mobiles whose command information is in the execution state and the number of times the command information of each mobile is in the execution state. Information based on the counting result using the counting information, which is received from the mobile body, can be transmitted to the information management device. The information based on the counting result is suitably used for various analyzes related to data collection based on the request signal, for example.

In one aspect of the mobile management device, the mobile management device is configured such that the count information is in a state in which the instruction information is in the execution state and the instruction is not executed when the condition is not satisfied. A state, including history information indicating a history of changes to the state, the counting unit, based on the history information received from the plurality of mobile bodies, the command information, the number of mobile bodies in the execution state and , And the number of times the command information for each moving body has entered the execution state. According to this aspect, the mobile unit management information preferably counts at least one of the number of mobile units whose command information is in the execution state and the number of times the command information of each mobile unit is in the execution state. You can

In another aspect of the mobile unit management apparatus, the count information is a state in which the state of the instruction information is the number of times the execution state is set, and the instruction is not executed when the condition is not satisfied. The number of times the state has been reached, and the number of times indicating the number of moving bodies, and the counting unit, based on the number of times information received from the plurality of moving bodies, the number of moving bodies in which the command information is in the execution state, At least one of the number of times the command information for each body is in the execution state is counted. Also according to this aspect, the mobile unit management apparatus can preferably count at least one of the number of mobile units whose command information is in the execution state and the number of times the command information of each mobile unit is in the execution state. it can.

In another aspect of the mobile management device, the flag information includes information indicating that the count information is transmitted to the mobile management device at predetermined time intervals, and the count information is indicated by the flag information. The state information indicating that the state of the command information at the transmission timing of the count information is one of the execution state and a non-execution state in which the command is not executed when the condition is not satisfied. Including, the counting unit, based on the state information received from the plurality of moving bodies, the number of moving bodies in which the instruction information is in the execution state, and the instruction information for each moving body is the execution state. And/or at least one of Also according to this aspect, the mobile unit management apparatus can preferably count at least one of the number of mobile units whose command information is in the execution state and the number of times the command information of each mobile unit is in the execution state. it can.

In another aspect of the mobile unit management apparatus, the counting unit may include the number of mobile units in which the command information is in the non-execution state and the number of times the command information for each mobile unit is in the non-execution state. At least one of and is counted. According to this aspect, the mobile management device can suitably acquire information that serves as an index that can be used for analysis related to data collection based on the request signal.

In another preferred embodiment, the mobile object management device has a data structure of transmission data transmitted for each mobile object, and the command information indicating the content of the command to be executed by the mobile object and the state of the command information are: A data structure of transmission data having flag information indicating transmission of counting information for counting the number of times of execution, which is a state of executing the command indicated by the command information when a predetermined condition is satisfied Is. The mobile object management device transmits the transmission data having such a data structure for each mobile object, thereby providing the count information for counting the number of times of the execution state in which the command indicated by the command information is executed. , Can be suitably collected from a mobile body.

In still another preferred embodiment, a control method executed by a mobile management device, comprising: a first receiving step of receiving a request signal issued by an information management device; command information according to the request signal; The flag information indicating that the state of the command information is to transmit the count information for counting the number of times the command information indicated by the command information is in the execution state, which is the condition to execute the command when the predetermined condition is satisfied, and A generation step of generating transmission information including the first transmission step of transmitting the transmission information to a plurality of mobile bodies; a second reception step of receiving response information to the command information and the count information; A counting step of counting at least one of the number of moving bodies in which the command information is in the execution state and the number of times in which the command information for each moving body is in the execution state based on counting information; A second transmitting step of transmitting information based on the counting result of the set to the information management device. By executing this control method, the mobile management device counts at least one of the number of mobiles whose command information is in the execution state and the number of times the command information of each mobile is in the execution state. It is possible to preferably receive the count information for the use from the mobile body, and to appropriately send the information based on the count result using the count information to the information management device.

Yet 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 instruct the terminal device that is the transmission destination of the processing information to transmit the history information of the state transition of the processing indicated by the processing information. Preferably, the program is stored in a storage medium.

Yet another preferred embodiment is a terminal device mounted on a mobile body, wherein the command information issued by the mobile body management device in response to a request signal issued by the information management device and the state of the command information are: Flag information indicating that count information for counting the number of times of execution in which the command indicated by the command information is executed when a predetermined condition is satisfied is transmitted to the mobile management device. A reception unit that receives transmission information from the mobile management device, a generation unit that generates the count information based on the flag information, the count information, and response information to the command information are transmitted to the mobile management device. And a transmitting unit that does. According to this aspect, the terminal device preferably supplies to the mobile management device, together with the response information to the command information, the count information for counting the number of times of execution in which the command indicated by the command information is executed. be able to.

Hereinafter, preferred first to third embodiments of the present invention will be described with reference to the drawings.
<First embodiment>
(1) Overall Configuration FIG. 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 a vehicle sensor, and includes a vehicle V, a vehicle (VEHICLE) cloud server 30, and a service cloud server 40.

An in-vehicle terminal 20 is mounted on the vehicle V. The vehicle-mounted terminal 20 is an information processing device that is connected to various sensors for acquiring information about the state of the vehicle V or the surrounding environment and performs a predetermined process. The vehicle-mounted terminal 20 executes the processing requested by the service cloud server 40 (also simply referred to as “job”) based on the outputs of these sensors. In the present embodiment, the job mainly refers to a process of acquiring information about the state of the specific vehicle V designated by the service cloud server 40 or the surrounding environment from the sensor and uploading the information to the service cloud server 40. The vehicle V and the vehicle-mounted terminal 20 are examples of a “moving body”. The in-vehicle terminal 20 is an example of a “terminal device”. The “moving body” is not limited to the vehicle V and the in-vehicle terminal 20, and may be a moving body such as a bicycle, a wheelchair, a drone, or a ship.

The vehicle cloud server 30 is a server device that constitutes a vehicle cloud. The vehicle cloud is, for example, a cloud operated by an information collection company that manages a vehicle (for example, an autonomous vehicle) provided to a user and collects various kinds of information from the vehicle. The information collection company may be played by the automobile manufacturer itself, or may be directly or indirectly operated by the automobile manufacturer. For example, if there are three automobile manufacturers, A, B, and C, the information collection company operated by A, the information collection company operated by B, and the information collection company operated by C are individually Existing information collecting companies collect various kinds of information from vehicles manufactured by the operating automobile manufacturers. Alternatively, a form in which a plurality of automobile manufacturers such as D company, E company, and F company jointly commission/operate may be adopted. The vehicle cloud server 30 is an example of a “mobile body management device”.

The service cloud server 40 is a server device that constitutes a service cloud. The service cloud is, for example, a cloud operated by a service providing company that provides services related to vehicles. Service providers include insurance companies that provide insurance services, map service companies that provide map services, parking service companies that provide parking service, and route search service companies that provide route search service. Can be mentioned. The service cloud server 40 generates information (also referred to as “job request”) instructing a job to be executed by the vehicle-mounted terminal 20 according to the purpose, and delivers the information to the vehicle-mounted terminal 20 via the vehicle cloud server 30. The service cloud server 40 is an example of an “information management device”.

The vehicle-mounted terminal 20 mounted in the vehicle V, the vehicle cloud server 30, and the service cloud server 40 can communicate with each other via the network 5 in a wired or wireless manner. In the present embodiment, the vehicle-mounted terminal 20, the vehicle cloud server 30, and the service cloud server 40 exchange the job request generated by the service cloud server 40, and the data (the data generated by the vehicle-mounted terminal 20 in response to the job request). Also referred to as "upload data").

The configuration of the job distribution system shown in FIG. 1 is an example, and the configuration to which the present invention is applicable is not limited to this. For example, as the service cloud, there may be a service cloud that generates a job request (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 content of the second service cloud, and based on the upload data received from the vehicle cloud to which the job request is transmitted, the second service cloud. Sends the information requested by the second service cloud.

FIG. 2 is a diagram schematically showing a data flow among the vehicle-mounted terminal 20, the vehicle cloud server 30, and the service cloud server 40.

As shown in FIG. 2, the service cloud server 40 transmits the generated job request “JR1” to the vehicle cloud server 30, and the vehicle cloud server 30 generates the job based on the job request JR1 received from the service cloud server 40. The request “JR2” is transmitted to the vehicle-mounted terminal 20. It should be noted that the job request JR1 can include a vehicle ID indicating a vehicle on which the job should be executed, a driver ID, and the like. The service cloud server 40 can transmit the vehicle ID to be transmitted and the vehicle ID to be transmitted, as necessary. The driver ID is included in the job request JR1. Thereby, the vehicle cloud server 30 transmits the job request JR2 to the vehicle-mounted terminal 20 of the corresponding vehicle.

The vehicle-mounted terminal 20 that has received the job request JR2 collects the data specified in the job request JR2 from the sensor, and transmits the collected data to the vehicle cloud server 30 as upload data “UD2”. When the vehicle cloud server 30 receives the upload data UD2 from the vehicle-mounted terminal 20, the vehicle cloud server 30 generates the upload data “UD1” based on the received upload data UD2, and transmits the generated upload data UD1 to the service cloud server 40 of the request source. .. The data structures of the job requests JR1 and JR2 and the upload data UD1 and UD2 will be described in detail in the section “(5) Data structure ”. The job request JR1 transmitted from the service cloud server 40 to the vehicle cloud server 30 is an example of a “request signal”, and the job request JR2 transmitted from the vehicle cloud server 30 to the vehicle-mounted terminal 20 is an example of “transmission information”. The upload data UD2 is an example of “reception result”.

(2) Configuration of In-Vehicle Terminal FIG. 3 is a block diagram showing the internal configuration of the in-vehicle terminal 20. As illustrated, the vehicle-mounted terminal 20 mainly includes 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 in the vehicle-mounted terminal 20 is connected to each other via a bus line 29. The interface 25 is also connected to the sensor unit 27.

Under the control of the control unit 24, the communication unit 21 transmits the upload data to the vehicle cloud server 30 and receives the map data for updating the map DB from the vehicle cloud server 30. The communication unit 21 may also perform a process of transmitting a signal for controlling the vehicle to the vehicle and a process of receiving a signal related to the state of the vehicle from the vehicle.

The storage unit 22 stores a program executed by the control unit 24 and information necessary for the control unit 24 to execute a predetermined process. The storage unit 22 includes a non-volatile memory (internal storage). In this embodiment, the storage unit 22 stores a map DB, a sensor data cache, vehicle attribute information, a job request JR2 received from the vehicle cloud server 30 by the communication unit 21, and state count information.

The map DB is a database including, for example, road data, facility data, and feature data around the road. Road data includes road/lane network data for route search, road shape data, traffic regulation data, and the like. The feature data includes information such as signboards such as road signs and road markings such as stop lines, road marking lines such as center lines and structures along the road. Further, the feature data may include highly accurate point cloud information of the feature for use in estimating the vehicle position. In addition, various data required for position estimation may be stored in the map DB.

The sensor data cache is a cache memory that temporarily holds the output data of the sensor unit 27. The vehicle attribute information indicates information on attributes of the vehicle V equipped with the on-vehicle terminal 20, such as vehicle type, vehicle ID, vehicle size such as vehicle length, vehicle width, vehicle height, and fuel type of the vehicle.

The state count information is information indicating the cumulative number of transitions for each state of the job requested by the job request JR2 during a valid period. The state count information is, for example, information in which the number of transitions to the state is associated with each possible state of the job. The control unit 24 updates the state count information every time the above-mentioned state transition is detected. The job state transition will be described later with reference to FIG. The state count information is an example of “count information”.

The input unit 23 is a button for a user to operate, a touch panel, a remote controller, a voice input device, or the like, and for example, an input for designating a destination for route search, an input for designating ON/OFF of automatic driving, and the like. Is received, and the generated input signal is supplied to the control unit 24. The output unit 26 is, for example, a display, a speaker, or the like that outputs under the control of the control unit 24.

The interface 25 performs an interface operation for supplying the output data of the sensor unit 27 to the control unit 24 and the sensor data cache. The sensor unit 27 includes a plurality of external sensors such as a rider and a camera for recognizing the surrounding environment of the vehicle, and internal sensors such as a GPS receiver, a gyro sensor, a position sensor, and a three-axis sensor. The lidar discretely measures the distance to an object existing in the external world, recognizes the surface of the object as a three-dimensional point cloud, and generates point cloud data. The camera generates image data taken from the vehicle. The position sensor is provided to detect the position of each external sensor, and the triaxial sensor is provided to detect the attitude of each external sensor. The sensor unit 27 may include any external sensor and internal sensor other than the external sensor and the internal sensor shown in FIG. For example, the sensor unit 27 may include an ultrasonic sensor, an infrared sensor, a microphone, or the like as the external sensor.

The control unit 24 includes a CPU that executes a predetermined program on one or more platforms, and controls the entire vehicle-mounted terminal 20. The control unit 24 functionally 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 computer that executes a “generation unit” and a program, and the communication unit 21 and the control unit 24 are examples of a “reception unit” and a “transmission unit”.

The position estimation unit estimates the vehicle position (including the vehicle attitude) based on the output data of the sensor unit 27 and the map DB held in the sensor data cache. The position estimation unit can execute various position estimation methods. The position estimation unit further compares the vehicle position estimation method by dead reckoning (autonomous navigation) based on the output of a self-contained positioning sensor such as a GPS receiver and a gyro sensor, and the road data of the map DB with the autonomous navigation ( A vehicle position estimation method for performing map matching), output data of an external sensor such as a rider or a camera based on a predetermined object (landmark) existing around, and position information of the landmark indicated by the feature information of the map DB. A vehicle position estimation method based on the above is executed. Then, the position estimation unit executes the position estimation method having the highest estimation accuracy among the currently-executable position estimation methods, and the vehicle position indicating the vehicle position etc. obtained based on the executed position estimation method. The information is supplied to the upload data generation unit.

The object detection unit detects a predetermined object based on the point cloud information, image data, audio data, etc. output by the sensor unit 27. In this case, for example, the object detection unit extracts the feature data corresponding to the object detected by the sensor unit 27 from the map DB based on the vehicle position estimated by the position estimation unit. Then, the object detection unit, for example, when 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 DB, or the map DB When there is no feature data corresponding to the above, the information about the object detected by the sensor unit 27 is supplied to the upload data generation unit.

The upload data generation unit generates the upload data UD2 based on the vehicle position information supplied from the position estimation unit, the object data supplied from the object detection unit, the output data of the sensor unit 27 supplied from the sensor data cache, and the like. To generate. In the present embodiment, the upload data generation unit includes the data specified by the data when the condition specified by the job request JR2 stored in the storage unit 22 is included in the upload data UD2, and the communication unit 21 causes the vehicle cloud server 30 to perform the upload. The upload data UD2 is transmitted to.

Here, the transition of the job state (also simply referred to as “job state”) indicated by the job request JR2 will be described.

FIG. 4 is a diagram schematically showing the transition of job states. In FIG. 4, an inactive state (non-execution state) that is a job state that does not satisfy the job execution condition indicated by the job request JR2, an active state (execution state) that is a job state that satisfies the job execution condition, and an exception Failing that transitions in a specific case is described.

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

Then, when the authentication process is successful, the job automatically transits to the inactive state. After that, if it is determined that the execution condition of the job indicated by the job request JR2 is satisfied, the job transitions to the active state, and if it is determined that the above execution condition is not satisfied after transitioning to the active state, the job is determined. Transitions to the inactive state.

On the other hand, if the authentication process fails, the job shifts to fail. Then, in this case, the vehicle-mounted terminal 20 transmits the upload data UD2 indicating that the failure has occurred to the vehicle cloud server 30. When a predetermined exception occurs, the job may be transferred from the active state or the inactive state to fail. Then, the vehicle-mounted terminal 20 terminates the job when the expiration date of the job has expired or when the job has failed, and deletes the job request JR2 from the storage unit 22. The upload data UD2 indicating that a failure has occurred is an example of “failure information”.

(3) Configuration of Vehicle Cloud Server Next, the vehicle cloud server 30 will be described in detail. FIG. 5A is a block diagram showing the internal configuration of the vehicle cloud server 30. As illustrated, the vehicle cloud server 30 includes a communication unit 31, a storage unit 32, and a control unit 33. The respective elements in the vehicle cloud server 30 are connected to each other via a bus line 39.

The communication unit 31 communicates with the vehicle-mounted terminal 20 of the vehicle V and the service cloud server 40 under the control of the control unit 33. Specifically, the communication unit 31 receives the job request JR1 from the service cloud server 40 and transmits the job request JR2 generated based on the job request JR1 to the vehicle-mounted terminal 20. Further, the communication unit 31 receives the upload data UD2 from the vehicle-mounted terminal 20 and transmits the upload data UD1 generated based on the upload data UD2 to the service cloud server 40.

The storage unit 32 includes ROM, RAM, and the like, and stores programs for various processes executed by the vehicle cloud server 30. The storage unit 32 is also used as a work memory when various processes are executed. The storage unit 32 also stores vehicle information and transmission history information Ih. The vehicle information is information about vehicles managed by the vehicle cloud. The vehicle information corresponds to, for example, a vehicle ID or/and a driver ID for each vehicle, communication address information for transmitting data to the in-vehicle terminal 20 of the corresponding vehicle, and information regarding a service used by the vehicle. It is attached table information. The transmission history information Ih is a table showing the history of transmitting the job request JR2 to the vehicle-mounted terminal 20 of each vehicle, and the detailed data structure will be described later.

Further, the storage unit 32 may further store the job request JR1 received by the vehicle cloud server 30 from the service cloud server 40 and the history data of the upload data UD2 obtained by the vehicle cloud server 30 from the vehicle-mounted terminal 20. In this case, for example, the upload data UD2 received from each in-vehicle terminal 20 is stored in the storage unit 32 in association with the vehicle ID of the vehicle V in which the in-vehicle terminal 20 is mounted, the reception time, and the like. Similarly, the job request JR1 received from the service cloud server 40 may be stored in the storage unit 32 in association with the information specifying the service cloud server 40 of the transmission source, the reception time, and the like.

The control unit 33 includes 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 storage unit 32. The control unit 33 is an example of a “generation unit”, a “counting unit”, a “first counting unit”, and a “second counting unit”. Further, the communication unit 31 and the control unit 33 are examples of the “first receiving unit”, the “first transmitting unit”, the “second receiving unit”, the “third receiving unit”, and the “second transmitting unit”.

(4) Configuration of Service Cloud Server Next, the service cloud server 40 will be described in detail. FIG. 5B is a block diagram showing the internal configuration of the service cloud server 40. As illustrated, the service cloud server 40 includes a communication unit 41, a storage unit 42, and a control unit 43. The respective elements in the service cloud server 40 are connected to each other via a bus line 49.

The communication unit 41 communicates with the vehicle cloud server 30 under the control of the control unit 43. Specifically, the communication unit 41 receives, from the vehicle cloud server 30, information corresponding to the provided information described below.

The storage unit 42 includes a ROM which is a non-volatile memory, a RAM which is a volatile memory, and the like, and stores programs for various processes executed by the service cloud server 40. The storage unit 42 is also used as a working memory when various processes are executed. Further, the storage unit 42 may store the job request JR1 transmitted from the service cloud server 40 to the vehicle cloud server 30 and the history of the upload data UD1 acquired by the service cloud server 40 from the vehicle cloud server 30. .. In this case, for example, the job request JR1 and the upload data UD1 are stored in the storage unit 42 in association with information specifying the transmission destination or transmission source vehicle cloud server 30 and the transmission/reception time.

The control unit 43 includes 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 storage unit 42.

(5) Data Structure Next, the data structure of various data will be described. Hereinafter, when the job request JR1 and the job request JR2 are not distinguished, they are simply described as “job request”, and when the upload data UD1 and the upload data UD2 are not distinguished, they are simply described as “upload data”. ..
(5-1) Job Request FIG. 6 shows an example of the data structure of a job request. As shown in the figure, the job request includes “version information”, “request identification information”, “attribute information”, “data collection condition information”, “state management flag”, and “collection data designation information”. including.

The “version information” is information for identifying the version of the specifications that specify the job request. The “attribute information” is information that defines the handling of the target job request.

The “request identification information” is identification information unique to the job request JR1 generated by the service cloud server 40. Each time the service cloud server 40 generates the job request JR1, the service cloud server 40 generates unique request identification information and includes it in the job request JR1. The "request identification information" of the job request JR2 may be the same as or different from the "request identification information" of the job request JR1. In the latter case, the vehicle cloud server 30 sets unique identification information for each job request JR2 transmitted to the vehicle-mounted terminal 20 as "request identification information" of the 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 the job request JR1 with the “request identification information” of the job request JR2 generated based on the job request JR1. In this embodiment, the "request identification information" of the job request JR1 is used as information (job ID) for identifying the job.

The “data collection condition information” is information indicating conditions for collecting data. For example, the “data collection condition information” is the geographical condition for the vehicle-mounted terminal 20 to generate the upload data UD2, the temporal condition for generating the upload data UD2, the event, the vehicle ID of the vehicle V, and/or the driver of the vehicle V. Is information indicating the driver ID of. Here, the geographical condition for generating the upload data UD2 is, for example, a condition for specifying a road or an area for generating the upload data UD2, and the temporal condition for generating the upload data UD2 is, for example, uploading. It is a condition for specifying a time constraint such as a time zone or an interval for generating the data UD2. In addition, the event indicates an event or the like that triggers the generation of the upload data UD2, and, for example, the occurrence of a shock (that is, an accident) of a predetermined degree or more, the occurrence of sudden braking, or the like is designated as the above-mentioned event. The data collection condition information is an example of “condition information”.

The “collected data designation information” is information that designates collected data to be included as upload data when the job execution condition indicated by the data collection condition information is satisfied. The collected data designation information is, for example, information about acceleration/deceleration of a vehicle, information about a vehicle speed, information about a traveling locus of a vehicle (that is, a position/orientation of the vehicle in time series), information about a departure place and a destination, predetermined information before and after an accident. For example, the shooting information of the camera in time. The contents designated as the data collection condition information and the collection data designation information are arbitrarily set by the service company operated by the service cloud server 40 that generates the job request. The data collection condition information and the collection data designation information are examples of “command information”.

The “state management flag” is a flag (also referred to as “state management flag Fs”) that specifies the necessity of uploading the state count information. For example, the status management flag Fs has a value of either "0" indicating that it is invalid or "1" indicating that it is valid, and if it is 1 (valid), the status count information is uploaded. It indicates that it is necessary, and if 0 (invalid), it indicates that uploading of the status count information is unnecessary. The state management flag Fs is an example of flag information. The state management flag Fs may be included in any field of the data collection condition information, the attribute information, or the collection data designation information, instead of being provided in a single field in the job request.

Here, when the job request JR1 transmitted from the service cloud server 40 to the vehicle cloud server 30 includes a valid state management flag Fs, the vehicle cloud server 30 sends a job to the job indicated by the job request JR1. The number of vehicles related to the condition is totaled. Then, the vehicle cloud server 30 transmits the totalized result to the service cloud server 40 as upload data UD1. The data structure of the upload data UD1 including the above-mentioned aggregation result will be described later with reference to FIG.

Further, when the job request JR2 transmitted from the vehicle cloud server 30 to each in-vehicle terminal 20 includes the valid state management flag Fs, the in-vehicle terminal 20 indicates that the vehicle cloud server 30 is the number of vehicles related to the above-mentioned job state. Generate the information required for the aggregation of. Then, the vehicle-mounted terminal 20 includes the generated information in the upload data UD2 and transmits it to the vehicle cloud server 30. The data structure of the upload data UD2 transmitted by the vehicle-mounted terminal 20 will be described later with reference to FIG.

The job request may include arbitrary information other than the information shown in FIG. For example, the job request may include address information that specifies a transmission destination for transmitting the upload data to the service cloud server 40 or the vehicle cloud server 30 that is the generation source of the job request. In another example, the job request may include a job ID for identifying the job, in addition to the request identification information. For example, when the service cloud server 40 transmits a job request JR1 indicating a job having the same content to a plurality of vehicle cloud servers 30, each job request JR1 includes different request identification information for each job request JR1 and all the job request JR1. A job ID common to the job request JR1 may be included.

(5-2) Transmission History Information FIG. 7 is an example of the data structure of the transmission history information Ih. The transmission history information Ih corresponds to the transmission history of the job request JR2, and in the example of FIG. 7, includes at least a “vehicle ID” and a “job ID”.

The “vehicle ID” is a vehicle ID corresponding to the vehicle-mounted terminal 20 of the transmission destination to which the vehicle cloud server 30 holding the transmission history information Ih has transmitted the job request JR2. The “job ID” is identification information of the job requested by the job request JR2 transmitted to the vehicle-mounted 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” of the transmission history information Ih.

Each time the vehicle cloud server 30 transmits the job request JR2 to the vehicle-mounted terminal 20, the vehicle cloud server 30 adds a record in which the vehicle ID and the job ID are associated with the transmission history information Ih held by itself. The transmission history information Ih may include any item other than the vehicle ID and the job ID. For example, the transmission history information Ih may further include the identification information of the service cloud that is the generation source of the job request JR1 used to generate the job request JR2 transmitted to the vehicle-mounted terminal 20. This identification information may be arbitrary information (for example, a communication address or the like) for identifying the service cloud.

Further, when the vehicle cloud server 30 receives from the vehicle-mounted terminal 20 the upload data UD2 indicating that the job request JR2 could not be normally received (that is, a failure has occurred), the vehicle cloud server 30 transmits a corresponding record. Delete from the history information Ih. That is, in this case, the vehicle cloud server 30 deletes the record including the vehicle ID corresponding to the vehicle-mounted terminal 20 that is the transmission source of the upload data UD2 and the job ID indicating the failed job from the transmission history information Ih. As a result, only the record indicating the combination of the vehicle ID of the vehicle-mounted terminal 20 that has normally received the job request JR2 and the job ID corresponding to the job instructed by the job request JR2 is recorded in the transmission history information Ih. become.

Here, the use of the transmission history information Ih shown in FIG. 7 will be described. The vehicle cloud server 30 can suitably calculate the number of inactive vehicles (also referred to as “inactive vehicle number”) by referring to the transmission history information Ih.

Specifically, the vehicle cloud server 30 calculates the number of records of the transmission history information Ih in which the job ID corresponding to the received job request JR1 is recorded, as the number of vehicles that transmitted the job request JR2. Here, as shown in FIG. 4, since the job state is automatically set to the inactive state when the authentication process is successful, the job indicated by the job request JR2 for which the authentication process is successful in the in-vehicle terminal 20 is It is always inactive. If the authentication process fails and a failure occurs, the upload data UD2 indicating the failure is transmitted to the vehicle cloud server 30, and the vehicle cloud server 30 deletes the corresponding record from the transmission history information Ih. To be done. Therefore, the vehicle cloud server 30 refers to the transmission history information Ih, and counts the number of vehicles that have transmitted the job request JR2 for each job, so that the number of vehicles that the job is authenticated and accepted (the number of inactive vehicles). ) Can be suitably specified for each job. As will be described later, the information on the specified number of inactive vehicles is included in the upload data UD1 and transmitted to the service cloud server 40.

(5-3) Upload Data Next, the respective data structures of the upload data UD1 and UD2 will be specifically described.

FIG. 8 is an example of the data structure of the upload data UD2 transmitted from the vehicle-mounted terminal 20 to the vehicle cloud server 30 based on the job request JR2. As illustrated, the upload data UD2 includes “version information”, “request identification information”, “collected data”, and “state count information”.

The “version information” is information that identifies the version of the specification that defines the upload data UD2. For this "version information", for example, the same content as the "version information" included in the previously received job request JR2 is specified. The “request identification information” indicates the request identification information of the job request JR2 received earlier.

The “collected data” is data collected by the vehicle-mounted terminal 20 based on the previously received job request JR2 and corresponds to the execution result of the requested job. This collected data is data designated by the "collected data designation information" of the job request JR2 received earlier. The collected data is an example of “response information”.

The “state count information” is state count information stored in the storage unit 22 by the vehicle-mounted terminal 20 based on the previously received job request JR2, and includes “active transition count” and “inactive transition count”. The “number of active transitions” indicates the number of times the job has transitioned to the active state (that is, the number of times the active state has been reached) during the valid period of the job requested by the previously received job request JR2. The “number of times of transition to inactivity” indicates the number of times the job has transitioned to the inactive state (that is, the number of times of transition to the inactive state) during the valid period of the job requested by the previously received job request JR2. The state count information is an example of “number of times information”.

Here, a supplementary description will be given of the method of generating the state count information.

When the previously received job request JR2 includes the valid state management flag Fs, the vehicle-mounted terminal 20 starts counting the number of transitions of the active state and the inactive state for the target job, and detects the number of these transitions. The information is stored in the storage unit 22 as state count information. Then, the in-vehicle terminal 20 updates the status count information each time the job status of the target job is changed. Then, the in-vehicle terminal 20 includes the state count information stored in the storage unit 22 in the upload data UD2 when the upload data UD2 is generated.

FIG. 9 is an example of a data structure of upload data UD1 that the vehicle cloud server 30 transmits to the service cloud server 40 based on the job request JR1. As illustrated, the upload data UD2 includes “version information”, “request identification information”, “collected data”, “inactive vehicle number”, “active vehicle number”, and “active total vehicle number”. And “the number of data collection vehicles”.

The “version information” is information for identifying the version of the specification that defines the upload data UD1. For this "version information", for example, the same content as the "version information" included in the previously received job request JR1 is specified. The “request identification information” indicates the request identification information of the job request JR1 received earlier.

The “collected data” corresponds to the execution result of the job requested by the job request JR1, and is the data designated by the “collected data designation information” of the job request JR1. The vehicle cloud server 30 transmits the job request JR2 generated based on the job request JR1 to the plurality of vehicle-mounted terminals 20, and receives the upload data UD2 which is the response from each vehicle-mounted terminal 20 to upload it as “collected data”. Collect the data to be included in the data UD1. In this case, the vehicle cloud server 30 may include the data obtained by directly extracting the collected data included in the upload data UD2 received from each vehicle-mounted terminal 20 as “collected data” in the upload data UD1 and included in each upload data UD2. The statistical data calculated by performing a predetermined statistical process on the collected data to be collected may be included in the upload data UD1 as “collected data”.

The “number of inactive vehicles” is the number of vehicles in which the status of the job requested by the job request JR1 is inactive. In this embodiment, in the first example, the vehicle cloud server 30 calculates the number of inactive vehicles for the job requested by the job request JR1 by referring to the transmission history information Ih. Specifically, the vehicle cloud server 30 records, in the records recorded in the transmission history information Ih, identification information (for example, request identification information) of a job requested by the job request JR1 as a “job ID”. Is calculated as the number of inactive vehicles. As described above, when the in-vehicle terminal 20 that receives the job request JR2 succeeds in the authentication of the job request JR2, the status of the job requested by the job request JR2 is always inactive, and the authentication of the job request JR2 is performed. Is failed, the record of the transmission history information Ih corresponding to the transmission history of the 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 the job requested by the job request JR1 by referring to the transmission history information Ih. In the second example, the vehicle cloud server 30 calculates based on the state count information included in the upload data UD2. In this case, the vehicle cloud server 30 calculates, as the number of inactive vehicles for the job, the number of in-vehicle terminals 20 from which the upload data UD2 having the number of inactive transitions indicated by the above-described state count information is one or more. ..

The “number of active vehicles” is the number of vehicles in which the status of the job requested by the job request JR1 has become active. In the present embodiment, the vehicle cloud server 30 refers to the number of active transitions indicated by the state count information of the upload data UD2 received from each in-vehicle terminal 20 as a response to the job request JR2 generated based on the job request JR1 to obtain the job. The number of active vehicles for the job requested by the request JR1 is calculated. Specifically, the vehicle cloud server 30 calculates, as the number of active vehicles of the job, the number of vehicle-mounted terminals 20 that have transmitted the upload data UD2 in which the number of active transitions of the job is 1 or more. As described above, the vehicle cloud server 30 is requested by the 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 vehicle-mounted terminal 20 that is the transmission destination of the job request JR2. The number of active vehicles for each job can be calculated appropriately.

The “number of active vehicles” is the total number of vehicles whose status of the job requested by the job request JR1 has become active. In this embodiment, the vehicle cloud server 30 accumulates the number of active transitions indicated by the state count information included in the upload data UD2 received from each vehicle-mounted terminal 20 as a response to the job request JR2 generated based on the job request JR1. , The total number of active vehicles for the job requested by the job request JR1 is calculated. As described above, the vehicle cloud server 30 is requested by the job request JR2 by referring to the number of active transitions indicated by the state count information included in the upload data UD2 received from the vehicle-mounted terminal 20 that is the destination of the job request JR2. It is possible to preferably calculate the total number of active vehicles for each job. The number of inactive vehicles, the number of active vehicles, and the total number of active vehicles are examples of the “moving body number information”.

The “number of data collection vehicles” is the number of vehicles that have uploaded collection data for the job requested by the job request JR1. In this embodiment, the vehicle cloud server 30 transmits the upload data UD2 including the collected data among the upload data UD2 received from each vehicle-mounted terminal 20 as a response to the job request JR2 generated based on the job request JR1. The number of vehicles is calculated as the number of data collection vehicles.

Next, a supplementary description will be given of the usage of the upload data UD1.

The service cloud server 40, which has received the upload data UD1 having the data structure shown in FIG. 9 as a response to the job request JR1, receives the reliability of the collected data based on the statistics of the number of vehicles included in the upload data UD1. And the effectiveness of data collection request and cost efficiency can be determined.

For example, the service cloud server 40 generates the ratio information indicating the ratio of the number of active vehicles or/and the number of data collection vehicles to the number of inactive vehicles, thereby improving the effectiveness and cost efficiency of the data collection request based on the job request JR1. The index shown can be calculated appropriately. For example, the service cloud server 40 can determine that the higher the ratio indicated by the ratio information, the higher the effectiveness and cost efficiency of the data collection request. Further, the service cloud server 40 suitably determines the reliability of the collected data included in the upload 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, and the like. can do. 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 higher the reliability of the collected data received from the vehicle cloud server 30.

Note that the data structure example of the upload data UD1 is not limited to that shown in FIG. For example, the upload data UD1 may include an inactive total vehicle number indicating the total number of vehicles in the inactive state. In this case, the vehicle cloud server 30 determines the above-mentioned total number of inactive vehicles by integrating the number of inactive transitions indicated by the state count information included in the upload data UD1 received from each vehicle-mounted terminal 20.

(6) Processing Flow Next, regarding the processing executed by the vehicle-mounted terminal 20 and the vehicle cloud server 30 when the job request JR1 and the job request JR2 including the valid state management flag Fs are generated, the flowcharts of FIGS. This will be specifically described with reference to.

(6-1) Processing of In-Vehicle Terminal FIG. 10 is a flowchart showing a processing procedure executed by the in-vehicle terminal 20 when the job request JR2 including the valid state management flag Fs is received. The in-vehicle terminal 20 repeatedly executes the process of the flowchart shown in FIG.

First, the vehicle-mounted terminal 20 receives the job request JR2 including the valid state management flag Fs from the vehicle cloud server 30 (step S101). Then, the vehicle-mounted terminal 20 performs a predetermined authentication process on the job request JR2 and determines whether or not the received job request JR2 has been authenticated (step S102).

Then, when the authentication process of the received job request JR2 is successful (step S102; Yes), the in-vehicle terminal 20 includes the valid state management flag Fs in the job request JR2, and therefore the state count for the job request JR2 is counted. Information is generated (step S103). Here, when the authentication process of the job request JR2 is successful, the in-vehicle terminal 20 automatically changes the job state to the inactive state, and therefore the state count information in which the number of active transitions is 0 and the number of inactive transitions is 1 is displayed. To generate.

On the other hand, when the authentication process of the received job request JR2 fails (step S102; No), the vehicle-mounted terminal 20 transmits the upload data UD2 indicating that the authentication has failed (that is, a failure) to the vehicle cloud server 30. (Step S110).

After generating the state count information in step S103, the vehicle-mounted terminal 20 determines whether or not the job execution condition indicated by the "data collection condition information" included in the received job request JR2 is satisfied (step S104). Then, when the vehicle-mounted terminal 20 determines that the job execution condition is satisfied (step S104; Yes), the data output from the sensor unit 27 is used to specify the “collected data specification information” included in the job request JR2. The collected data is collected (step S105). In this case, the job status of the job is active. On the other hand, when the in-vehicle terminal 20 determines that the job execution condition is not satisfied (step S104; No), the process proceeds to step S106 without performing the process of step S105. In this case, the job status of the job is inactive.

Next, the vehicle-mounted terminal 20 updates the status count information according to the presence/absence of a job status transition (step S106). Specifically, when the in-vehicle terminal 20 determines that the job has transitioned from the inactive state to the active state based on the determination process of step S104, the in-vehicle terminal 20 counts the state so as to increase the number of active transitions for the job by one. Update information. On the other hand, when the vehicle-mounted terminal 20 determines that the job has transitioned from the active state to the inactive state based on the determination process of step S104, the in-vehicle terminal 20 displays the state count information so as to increase the number of inactive transitions for the job by one. Update.

Next, the vehicle-mounted terminal 20 determines whether or not it is the transmission timing of the upload data UD2 (step S107). The transmission timing of the upload data UD2 may be determined by various rules. For example, the vehicle-mounted terminal 20 may transmit the upload data UD2 only once at the end of the job expiration date, or may transmit the upload data UD2 each time data collection is performed in step S105. Alternatively, the upload data UD2 may be transmitted at predetermined time intervals. The specific transmission timing of the upload data UD2 is set to, for example, the timing specified by the data collection condition information included in the job request JR2 received from the vehicle cloud server 30.

Then, when it is the transmission timing of the upload data UD2 (step S107; Yes), the in-vehicle terminal 20 includes the collected data collected in step S105 and the upload data UD2 including the state count information indicating the number of inactive transitions and the number of active transitions. (See FIG. 8) is transmitted to the vehicle cloud server 30 (step S108). In the mode in which the in-vehicle terminal 20 transmits the upload data UD2 at a plurality of timings, the state count information may be included only in the upload data UD2 transmitted at the last transmission timing. In addition, since the vehicle-mounted terminal 20 includes the final number of active transitions and the number of inactive transitions in the valid period of the job in the upload data UD2, the in-vehicle terminal 20 stores the upload data UD2 including at least the state count information at the end of the job valid period. It may be transmitted to the vehicle cloud server 30. The upload data UD2 in this case may not include the collected data. That is, in this case, the vehicle-mounted terminal 20 does not necessarily have to match the transmission timings of the collected data and the state count information.

Next, the vehicle-mounted terminal 20 determines whether the job is completed (step S109). For example, when the expiration date of the job is indicated in the “data collection condition information” included in the received job request JR2, it is determined whether or not the expiration date of the job has expired. Then, when the in-vehicle terminal 20 determines that the job is completed (step S109; Yes), the process of the flowchart is completed. On the other hand, when the vehicle-mounted terminal 20 determines that it is not the transmission timing of the upload data UD2 (step S107; No) or determines that the job has not ended (step S109; No), the process proceeds to step S104. return.

(6-2) Processing of Vehicle Cloud Server FIG. 11 is a flowchart showing a processing procedure executed by the vehicle cloud server 30 which has received the job request JR1 including the valid state management flag Fs.

First, the vehicle cloud server 30 receives the job request JR1 including the valid state 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 transmits the job request JR2 generated based on the job request JR1 to the vehicle-mounted terminal 20 of the vehicle managed by the vehicle cloud server 30. (Step S202).

After that, the vehicle cloud server 30 receives the upload data UD2 from the vehicle-mounted terminal 20 that is the transmission destination of the job request JR2, and stores it in the storage unit 32 (step S203). Then, the vehicle cloud server 30 repeatedly receives and stores the upload data UD2 in step S203 until the predetermined collection period of the upload data UD2 ends (step S204; No). Thereby, the vehicle cloud server 30 stores the upload data UD2 supplied from the vehicle-mounted terminals 20 of the plurality of vehicles.

In addition, as an aspect not shown in the flowchart, for example, for information that requires a certain degree of real-time property, the vehicle cloud server 30 receives the upload data UD2 that is received periodically or intermittently within the collection period of the upload data UD2. May be sequentially transmitted to the service cloud server 40 as the upload data UD1 without being stored in the storage unit 32. In this case, the vehicle cloud server 30 transmits to the service cloud server 40 only the state count information aggregated in step S205 described below after the collection period of the upload data UD2 ends.

When the vehicle cloud server 30 determines that the collection period of the upload data UD2 has ended (step S204; Yes), the vehicle cloud server 30 collects the number of inactive vehicles, the number of active vehicles, the total number of active vehicles, the number of data collection vehicles, and the like. Perform (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 state count information included in the upload data UD2 received and stored in step S203. Further, the vehicle cloud server 30 calculates the number of inactive vehicles based on either the transmission history information Ih or the number of inactive transitions indicated by the state count information, and regarding the number of data collection vehicles, upload data including collected data. It is calculated by counting the in-vehicle terminals 20 that are the senders of UD2. When the vehicle cloud server 30 receives the upload data UD2 related to the same job from the same vehicle-mounted terminal 20 a plurality of times, the vehicle cloud server 30 receives the above-described status count information included in the upload data UD2 that is received last. It is good to do a tally.

Next, the vehicle cloud server 30 transmits the upload data UD1 (see FIG. 9) including the aggregation result in step S205 to the service cloud server 40 that is the request source of the job request JR1 (step S206). After that, the service cloud server 40 that has generated the job request JR1 receives the upload data UD1 from the vehicle cloud server 30. In this case, the service cloud server 40 determines the reliability of the returned collection data, the validity of the data collection request, and the cost efficiency based on the received upload data UD1.

(7) Application Example Next, an application example of this embodiment will be described. Here, an example will be described in which a municipality such as a municipality uses a job distribution system in order to grasp traffic congestion information and road use conditions in detail as part of a town planning/road use analysis.

FIG. 12 shows a configuration example of the job distribution system in this application example. The job distribution system shown in FIG. 12 is equipped with 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 an in-vehicle terminal 20. A taxi vehicle V that has been driven. 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 the data collected by the first service cloud server 40A from the first service cloud server 40A. I shall.

There are two railway stations (A station and B station) in the municipality, and the streets in front of each station are congested, so it is necessary to expand the station front streets, and to obtain the congestion data in order to systematically expand the station front streets. .. The taxi vehicle V is a vehicle that frequently runs on the front street of two railway stations, and there are a total of 80 taxi vehicles. There is a taxi pool at each station.

FIG. 13 is a bird's-eye view showing the street in front of the station A. As shown in the figure, a trunk road 50, a station road 51 branched from the trunk road 50, and a taxi pool 52 that can join the station road 51 exist near the A station. On the road 51 in front of the station, there are an intersection 53 connected to the taxi pool 52 and an intersection 54 which is an entrance to the main road 50.

Here, the first service cloud server 40A, as the “collected data designation information” shown in FIG. 6, travel time and retention (stop) when exiting the taxi pool 52 and passing through the station road 51 from the intersection 53 to the intersection 54. ) A job request JR1 is generated that specifies the time and the running time and the staying time from the intersection 54 to entering the taxi pool 52. In this job request JR1, "data collection condition information" (1 week from Monday to Sunday is set as the job expiration date, and 6 am to 7 pm is set as the job execution time period) ( (See FIG. 6) is further included. Then, the first service cloud server 40A calculates the average running time and the average residence time in each time zone divided into 10-minute intervals based on the upload data UD1 received from the vehicle cloud server 30 as a response to the job request JR1. To do. Then, the first service cloud server 40A transmits the calculated average travel time and average residence 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 jam information based on the upload data received from the first service cloud server 40A. Similarly, for the B station, the first service cloud server 40A calculates the average running time and the average staying time for the road in front of the station based on the upload data UD1 received from the vehicle cloud server 30, and the second service cloud server 40A. The upload data including the calculation result is transmitted to 40B.

In such a case, the first service cloud server 40A includes the valid state management flag Fs in the job request JR1 to receive the statistical data of the number of vehicles related to the job state and the like from the vehicle cloud server 30 by the upload data UD1. , The second service cloud server 40B. As a result, the second service cloud server 40B can consider the statistical data of the number of vehicles related to the job status and the like when examining the contents of the traffic jam information in front of each station, and therefore the traffic jam information should be accurately examined. You can In addition, when there are no or very few measured vehicles (that is, very few active vehicles), there is no inflow of taxi to the road in front of the station due to severe traffic congestion, or there is no demand for taxis. It is also possible to infer that it may have been in the time zone (that is, the time zone in which many taxi vehicles V were waiting in the taxi pool). Based on the collected data and the statistical data on the number of vehicles described above, the local government will discuss with the taxi company etc., as necessary, and adjust the conditions for obtaining traffic congestion information and the analysis method.

<Second embodiment>
The vehicle-mounted terminal 20 according to the second embodiment, instead of transmitting the state count information indicating the number of transitions to each job state to the vehicle cloud server 30, history information regarding job state transitions (also referred to as “state history information”). ) Is transmitted to the vehicle cloud server 30. After that, the configurations of the vehicle cloud server 30 and the service cloud server 40, the data structures of the job requests JR1 and JR2, the data structure of the upload data UD1 and the like are the same as those in the first embodiment, and therefore the description thereof will be omitted.

FIG. 14 is a block diagram showing the internal configuration of the vehicle-mounted terminal 20 according to the second embodiment. As illustrated, the storage unit 22 of the vehicle-mounted terminal 20 stores the state history information. The state history information is history information of the state transition of the job requested by the job request JR2 during a valid period. The state history information is, for example, table information in which a transition state of a job and a transition time are associated with each requested job (for example, with each request identification information). When the valid state management flag Fs is included in the previously received job request JR2, the vehicle-mounted terminal 20 stores the transition of the job state for the target job in the storage unit 22 as the state history information.

FIG. 15 is an example of the data structure of the upload data UD2 according to the second embodiment. As shown in FIG. 15, the upload data UD2 according to the second embodiment includes “state history information” instead of the state count information. When the valid state management flag Fs is included in the corresponding job request JR2, the vehicle-mounted terminal 20 collects the collected data, which is the execution result of the job requested by the job request JR2, and the state history corresponding to the job. The information is included in the upload data UD2 and transmitted to the vehicle cloud server 30. Accordingly, the vehicle cloud server 30 that has received the upload data UD2 can suitably calculate the number of inactive transitions and the number of active transitions of the in-vehicle terminal 20 that is the transmission source of the upload data UD2 by referring to the state history information. It will be possible. The state history information is an example of “counting information”.

FIG. 16 is a flowchart showing a processing procedure executed by the vehicle-mounted terminal 20 according to the second embodiment when the job request JR2 including the valid state management flag Fs is received. The in-vehicle terminal 20 repeatedly executes the process of the flowchart shown in FIG.

When the vehicle-mounted terminal 20 receives the job request JR2 including the valid state management flag Fs from the vehicle cloud server 30 (step S301) and the authentication processing of the received job request JR2 is successful (step S302; Yes), the job request is issued. The state history information for the job requested by JR2 is generated (step S303). In this case, since the job state is automatically set to the inactive state, the vehicle-mounted terminal 20 generates the state history information recording the transition to the inactive state.

When the vehicle execution condition satisfies the job execution condition indicated by the “data collection condition information” included in the received job request JR2 (step S304; Yes), the in-vehicle terminal 20 uses the data output from the sensor unit 27 to request the job. The data designated by the “collected data designation information” included in JR2 is collected (step S305). In this case, the job status of the job is active. On the other hand, when the vehicle-mounted terminal 20 determines that the job execution condition is not satisfied (step S304; No), the process proceeds to step S306 without performing the process of step S305. In this case, the job status of the job is inactive.

Next, the vehicle-mounted terminal 20 updates the state history information according to the presence/absence of a job state transition (step S306). Specifically, the in-vehicle terminal 20 compares with the latest job state indicated by the state history information, and when it determines that the current job state is transiting from the inactive state to the active state, the in-vehicle terminal 20 changes to the active state. If a record indicating the transition is added to the status history information for the target job and it is determined that the transition from the active status to the inactive status is made, the record indicating the transition to the inactive status is added to the target job. Add to status history information.

After that, as in the first embodiment, when it is the transmission timing of the upload data UD2 (step S307; Yes), the vehicle-mounted terminal 20 uploads data UD2 including the collected data and the status history information collected in step S305 (FIG. 15). Reference) to the vehicle cloud server 30 (step S308). When the vehicle-mounted terminal 20 determines that the job is completed (step S309; Yes), the process of the flowchart is completed. On the other hand, if it is not the transmission timing of the upload data UD2 (step S307; No) or if the job is not completed (step S309; No), the process is returned to step S304.

FIG. 17 is a flowchart showing a processing procedure executed by the vehicle cloud server 30 according to the second embodiment which receives the job request JR1 including the valid state management flag Fs.

First, the vehicle cloud server 30 receives the job request JR1 including the valid state 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 transmits the job request JR2 generated based on the job request JR1 to the vehicle-mounted terminal 20 of the vehicle managed by the vehicle cloud server 30. (Step S402).

After that, the vehicle cloud server 30 receives the upload data UD2 including the state history information from the vehicle-mounted terminal 20 and stores it in the storage unit 32 (step S403). Then, the vehicle cloud server 30 repeatedly receives and stores the upload data UD2 in step S403 until the predetermined collection period of the upload data UD2 ends (step S404; No).

Then, when the vehicle cloud server 30 determines that the collection period of the upload data UD2 has ended (step S404; Yes), it is determined for each vehicle based on the state history information included in the upload data UD2 received and stored in step S403. The number of active transitions is calculated (step S405). In this case, the vehicle cloud server 30 may calculate the number of inactive transitions in addition to the number of active transitions based on the state history information. When the vehicle cloud server 30 has received the upload data UD2 relating to the same job from the same vehicle-mounted terminal 20 a plurality of times, the vehicle cloud server 30 determines whether or not the above-mentioned status history information included in the upload data UD2 received last is used. It is good to calculate.

Then, the vehicle cloud server 30 totals the number of inactive vehicles, the number of active vehicles, the total number of active vehicles, the number of data collection vehicles, 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. Further, the vehicle cloud server 30 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 regarding the number of data collection vehicles, upload data including collected data. It is calculated by counting the in-vehicle terminals 20 that are the senders of UD2.

Next, the vehicle cloud server 30 transmits the upload data UD1 (see FIG. 9) including the aggregation result in step S405 to the service cloud server 40 that is the request source of the job request JR1 (step S407). After that, the service cloud server 40 that has generated the job request JR1 receives the upload data UD1 from the vehicle cloud server 30. In this case, the service cloud server 40 determines the reliability of the returned collection data, the validity of the data collection request, and the cost efficiency based on the received upload data UD1.

<Third embodiment>
The vehicle-mounted terminal 20 according to the third embodiment transmits information indicating the current job state (also simply referred to as “state information”) to the vehicle cloud server 30 instead of the state count information or the state history information. After that, the configuration of the service cloud server 40, the data structures of the job requests JR1 and JR2, the data structure of the upload data UD1 and the like are the same as those in the first and second embodiments, and therefore the description thereof will be omitted.

FIG. 18 is an example of the data structure of the upload data UD2 according to the third embodiment. As shown in FIG. 18, the upload 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.

When the effective request management flag Fs is included in the job request JR2, the vehicle-mounted terminal 20 collects the collected data which is the execution result of the job requested by the job request JR2 and the current job status corresponding to the job. Is included in the upload data UD2 and transmitted to the vehicle cloud server 30. In this case, the vehicle-mounted terminal 20 transmits the upload data UD2 to the vehicle cloud server 30 at a time interval designated by the data collection condition information included in the job request JR2 received from the vehicle cloud server 30. The transmission timing of the upload data UD2 in this case may be determined for each job, or may be uniform for a plurality of jobs. The state information is an example of “count information”.

FIG. 19 is a diagram schematically showing the internal configuration of the vehicle cloud server 30 according to the third embodiment. As shown in FIG. 19, the vehicle cloud server 30 stores state history information in the storage unit 32. Here, the vehicle cloud server 30 generates, for example, state history information for each job and each vehicle ID based on the state information included in the upload data UD2 received from the vehicle-mounted terminal 20. In this case, for example, the status history information is information that associates the job status indicated by the status information with the reception time or generation time of the status information for each request identification information and vehicle ID. By holding such state history information, the vehicle cloud server 30 stores the number of inactive vehicles, the number of active vehicles, the total number of active vehicles, the number of data collection vehicles, etc., as in the first and second embodiments. The tabulation can be performed appropriately.

FIG. 20 is a flowchart showing a processing procedure executed by the vehicle-mounted terminal 20 according to the third embodiment when the job request JR2 including the valid state management flag Fs is received. The vehicle-mounted terminal 20 repeatedly executes the process of the flowchart shown in FIG.

The vehicle-mounted terminal 20 receives the job request JR2 including the valid state management flag Fs from the vehicle cloud server 30 (step S501), and when the received job request JR2 is successfully authenticated (step S502; Yes), the vehicle-mounted terminal 20 receives the job request JR2. It is determined whether or not the execution condition of the job indicated by the job request JR2 is satisfied (step S503). When the job execution condition is satisfied (step S503; Yes), the data output by the sensor unit 27 is used to collect the data specified by the job request JR2 (step S504). On the other hand, when the vehicle-mounted terminal 20 determines that the job execution condition is not satisfied (step S503; No), the process proceeds to step S505 without performing the process of step S504.

Next, the vehicle-mounted terminal 20 determines whether or not it is the transmission timing of the upload data UD2 (step S505). In this case, the transmission timing of the upload data UD2 may be determined for each job, or may be uniform for a plurality of jobs. Then, when it is the transmission timing of the upload data UD2 (step S505; Yes), the in-vehicle terminal 20 generates status information indicating the current job status (step S505). Specifically, the in-vehicle terminal 20 generates status information indicating that the job is in the inactive state when the execution condition of the job is not satisfied, and when the execution condition of the job is satisfied, , Generates status information indicating that the job is in the active status.

Then, the vehicle-mounted terminal 20 transmits the upload data UD2 including the state information generated in step S506 and the collected data collected in step S504 to the vehicle cloud server 30 (step S507). Then, when the in-vehicle terminal 20 determines that the job should be ended (step S508; Yes), the process of the flowchart is ended.

On the other hand, when it is not the transmission timing of the upload data UD2 (step S505; No) or when the job is not completed (step S508; No), the vehicle-mounted terminal 20 returns the process to step S503. As a result, the in-vehicle terminal 20 repeatedly executes the processes of steps S503 to S507 until the expiration date of the job ends.

FIG. 21 is a flowchart showing a processing procedure executed by the vehicle cloud server 30 according to the third embodiment which receives the job request JR1 including the valid state management flag Fs.

First, the vehicle cloud server 30 receives the job request JR1 including the valid state 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 transmits the job request JR2 generated based on the job request JR1 to the vehicle-mounted terminal 20 of the vehicle managed by the vehicle cloud server 30. (Step S602).

After that, the vehicle cloud server 30 receives the upload data UD2 including the status information from the vehicle-mounted 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 including the job status indicated by the status information of the received upload data UD2 and the time information to the target status history information. Then, the vehicle cloud server 30 repeats step S603 and step S604 until the predetermined collection period of the upload data UD2 ends (step S605; No).

When the vehicle cloud server 30 determines that the collection period of the upload data UD2 has ended (step S605; Yes), the vehicle cloud server 30 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 calculate the number of inactive transitions in addition to the number of active transitions based on the state history information.

Then, the vehicle cloud server 30 totals the number of inactive vehicles, the number of active vehicles, the total number of active vehicles, the number of data collection vehicles, 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. Further, the vehicle cloud server 30 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 regarding the number of data collecting vehicles, upload data including collected data. It is calculated by counting the in-vehicle terminals 20 that are the senders of UD2.

Next, the vehicle cloud server 30 transmits the upload data UD1 (see FIG. 9) including the aggregation result in step S605 to the service cloud server 40 that is the request source of the job request JR1 (step S608). After that, the service cloud server 40 that has generated the job request JR1 receives the upload data UD1 from the vehicle cloud server 30. In this case, the service cloud server 40 determines the reliability of the returned collection data, the validity of the data collection request, and the cost efficiency based on the received upload data UD1.

As described above, the vehicle cloud server 30 receives the job request JR1 issued by the service cloud server 40 and transmits the job request JR2 corresponding to the job request JR1 to the vehicle-mounted terminals 20 of a plurality of vehicles. Further, the vehicle cloud server 30 receives the upload data UD2, which is a reception result indicating that the vehicle-mounted terminals 20 of a plurality of vehicles have successfully received the job request JR2, and normally executes the job request JR2 based on the upload data UD2. The number of inactive vehicles, which is the number of vehicles that can be received by the vehicle, is counted. In addition, the vehicle cloud server 30 receives the upload data UD2 in which the number of active transitions of the job is 1 or more, and indicates the number of active vehicles and the total number of active vehicles that represent the number of vehicles and the total number of vehicles that transmitted the upload data UD2. Count. Then, the vehicle cloud server 30 transmits, to the service cloud server 40, upload data UD1 including information on the number of inactive vehicles, the number of active vehicles, and the number of active total vehicles.

As described above, the vehicle cloud server 30 receives the job request JR1 issued by the service cloud server 40. Then, the vehicle cloud server 30 determines whether the data collection condition information and the collected data designation information corresponding to the job request JR1 and the job status indicated by the data collection condition information and the collected data designation information satisfy the predetermined condition. A job request JR2 including state count information for counting the number of active transitions, which is the number of times the job is in the active state, that is, the state history information, or a state management flag Fs indicating that the state information is transmitted. To generate. Then, the vehicle cloud server 30 transmits the job request JR2 to the vehicle-mounted terminals 20 of the plurality of vehicles. Then, the vehicle cloud server 30 receives the upload data UD2 including the collected data for the job request JR2 and the state count information or the state history information or the state information, and based on the state count information or the state history information or the state information, the active vehicle At least one of the number of vehicles and the number of active vehicles is counted. Then, the vehicle cloud server 30 transmits the upload data UD1 based on the above counting result to the service cloud server 40.

<Modification>
Next, modified examples suitable for the above-described first to third embodiments will be described. The following modifications may be applied to the above-described embodiment in any combination.

(Modification 1)
In the first to third examples, the function corresponding to the in-vehicle terminal 20 may be built in the vehicle V. In this case, an electronic control unit (ECU: Electronic Control Unit) of the vehicle executes a program stored in the memory of the vehicle to execute a process corresponding to the control unit 24 of the vehicle-mounted terminal 20. In this case, the vehicle V is an example of a “moving body”, and the electronic control device of the vehicle V is an example of a “terminal device”.

(Modification 2)
The state count information of the first embodiment includes information about the number of inactive transitions. Alternatively, the state count information may not include information regarding the number of inactive transitions.

In this case, in step S103 and step S106 of FIG. 10, the vehicle-mounted terminal 20 counts only the number of active transitions, includes the information of the counted number of active transitions in the upload data UD2, and transmits it to the vehicle cloud server 30. In this case, the vehicle cloud server 30 calculates the number of inactive vehicles based on the transmission history information Ih in step S205 of FIG. Further, the vehicle cloud server 30 calculates the number of data collection vehicles by counting the number of the vehicle-mounted terminals 20 that are the transmission sources of the upload data UD2.

Similarly, the state history information of the second embodiment may not include the information regarding the transition to the inactive state. Also in this case, the vehicle cloud server 30 that has received the upload data UD2 including the status history information may calculate the number of inactive vehicles based on the transmission history information Ih in step S406 of FIG.

(Modification 3)
In the first embodiment, the vehicle-mounted terminal 20 may generate the 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 vehicle-mounted terminal 20 stores the state history information in the storage unit 22, as in FIG. Then, at the transmission timing of the upload data UD2, the in-vehicle terminal 20 refers to the state history information stored in the storage unit 22 to generate the state count information, and transmits it to the vehicle cloud server 30 as the upload data UD2 together with the collected data and the like. ..

(Modification 4)
In the first to third embodiments, the job requests JR1 and JR2 may include a plurality of jobs. In this case, common execution conditions may be set for a plurality of jobs, or different execution conditions may be set for each job. If different execution conditions are set for each job, the job has individual job status. For example, in the transition from the inactive state to the active state, jobs that satisfy the execution conditions individually transition to the active state.

(Modification 5)
In the first to third embodiments, the vehicle cloud server 30 generates ratio information indicating the ratio of the number of active vehicles to the number of inactive vehicles, or the ratio of the number of data collection vehicles to the number of inactive vehicles, and the ratio. The information may be included in the upload data UD1 and transmitted to the service cloud server 40. Thereby, the vehicle cloud server 30 can suitably transmit the information necessary for determining the validity and cost efficiency of the data collection request to the service cloud server 40. In the present modification, the above-mentioned ratio information is an example of “moving body number information”.

20 In-vehicle terminal 27 Sensor section 30 Vehicle cloud server 40 Service cloud server

Claims (10)

A first receiving unit for receiving a request signal issued by the information management device;
Count information for counting the number of times the command information corresponding to the request signal and the state of the command information are in the execution state, which is the state of executing the command indicated by the command information when a predetermined condition is satisfied. And flag information indicating that the transmission is performed, and a generation unit that generates transmission information including
A first transmission unit that transmits the transmission information to a plurality of mobile bodies;
A second receiver for receiving response information for the command information and the counting information;
A count unit that counts at least one of the number of mobile units in which the command information is in the execution state, and the number of times the command information in each mobile unit is in the execution state, based on the count information,
A second transmitting unit that transmits information based on the counting result of the counting unit to the information management device;
A mobile unit management apparatus comprising: The counting information, the state of the command information, the execution state, a non-execution state is a state in which the command is not executed when the condition is not satisfied, and history information indicating a history of changes to the state of,
The counting unit, based on the history information received from the plurality of mobile bodies, the number of mobile bodies in which the command information is in the execution state, and the number of times the command information for each mobile body is in the execution state. The mobile object management device according to claim 1, wherein at least one of the following items is counted. The count information is frequency information indicating the number of times the command information is in the execution state and the number of times the command is not executed when the condition is not satisfied. Including,
The counting unit, based on the number-of-times information received from the plurality of mobile units, the number of mobile units in which the command information is in the execution state and the number of times the command information for each mobile unit is in the execution state. The mobile object management device according to claim 1, wherein at least one of the following items is counted. The flag information includes information indicating that the count information is transmitted to the mobile management device at predetermined time intervals,
The count information includes a state of the command information at the transmission timing of the count information indicated by the flag information, the execution state, and a non-execution state in which the command is not executed when the condition is not satisfied. Including status information that indicates one of them,
The counting unit, based on the state information received from the plurality of mobile bodies, the number of mobile bodies in which the command information is in the execution state, and the number of times the command information for each mobile body is in the execution state. The mobile object management device according to claim 1, wherein at least one of the following items is counted. 3. The counting unit counts at least one of the number of moving bodies in which the instruction information is in the non-execution state and the number of times in which the instruction information of each moving body is in the non-execution state. The mobile unit management device according to any one of items 1 to 4. The data structure of the transmission data transmitted by the mobile management device for each mobile,
Command information indicating the content of the command to be executed by the moving body,
The state of the command information, flag information indicating that to transmit the count information for counting the number of times the execution state is a state of executing the command indicated by the command information when a predetermined condition is satisfied, The data structure of the transmitted data having. A control method executed by a mobile management device, comprising:
A first receiving step of receiving a request signal issued by the information management device,
Count information for counting the number of times the command information corresponding to the request signal and the state of the command information are in the execution state, which is the state of executing the command indicated by the command information when a predetermined condition is satisfied. Flag information indicating that the transmission is to be performed, and a generation step of generating transmission information including
A first transmitting step of transmitting the transmission information to a plurality of mobile bodies;
A second receiving step of receiving response information for the command information and the counting information;
A counting step of counting at least one of the number of mobile units in which the command information is in the execution state and the number of times the command information for each mobile unit is in the execution state based on the counting information,
A second transmitting step of transmitting information based on the counting result of the counting section to the information management device;
A control method comprising: A program that causes a computer to execute the control method according to claim 7. A storage medium storing the program according to claim 8. A terminal device mounted on a mobile body,
Command information issued by the mobile object management device in response to a request signal issued by the information management device, and the state of the command information is an execution state in which the command indicated by the command information is executed when a predetermined condition is satisfied. A flag information indicating that the count information for counting the number of times the flag has been transmitted to the mobile management device, and a reception unit that receives transmission information including the flag information from the mobile management device,
A generation unit that generates the count information based on the flag information,
A transmission unit that transmits the count information and response information to the command information, to the mobile management device,
A terminal device comprising:

Images