Mobile object management device

Abstract

To provide a mobile object management device which can suitably acquire statistical data regarding a state of a vehicle to processing whose execution is instructed.SOLUTION: A vehicle cloud server 30 receives upload data UD2 as a reception result showing that on-vehicle terminals 20 of a plurality of vehicles could receive a job request JR2 and counts the number of inactive vehicles as the number of vehicles which could normally receive the job request JR2 on the basis of the upload data UD2. In addition, the vehicle cloud server 30 receives the upload data UD2 in which active transition frequencies of a job become one or more and counts the number of active vehicles and the total number of active vehicles representing the number of vehicles or the total number of vehicles which have transmitted the upload data UD2. Then, the vehicle cloud server 30 transmits upload data UD1 including information on the number of inactive vehicles, the number of active vehicles, and the total number of active vehicles to a service cloud server 40.SELECTED DRAWING: Figure 17

Description

[Technical field]

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

[0002] Conventionally, there is known a technique for collecting information from a sensor installed in a vehicle in a server device. For example, Patent Document 1 discloses a driving support device that, when a change point of a partial map is detected based on the output of a sensor installed in a moving body such as a vehicle, transmits change point information related to the change point to a server device. [Prior art documents] [Patent documents]

[0003] [Patent Document 1] JP 2016-156973 A Summary of the Invention [Problem to be solved by the invention]

[0004] It is expected that in the future, companies that provide various vehicle-related services will each operate their own servers, specify the data to be uploaded to the vehicle, and collect various vehicle-related information required for providing the service via a server that manages the vehicle (vehicle management server).In such a system, the vehicle will recognize that uploading the specified data when certain execution conditions are met is a job, and will be required to execute the job when the above-mentioned execution conditions are met.

[0005] On the other hand, there is no guarantee that the data collection request generated by the service company's server will be delivered to the vehicle, and it will not be delivered to the vehicle if the vehicle management server is heavily loaded, or if there are no vehicles that meet the collection conditions and therefore no vehicles to which the data collection request should be delivered. Also, if the vehicle side is heavily loaded and the data collection request is deleted from the vehicle, the data collection request will not be executed appropriately by the vehicle. Considering the above, in order to accurately grasp the effectiveness and cost efficiency of the data collection request, the reliability of the collected data, etc., it is necessary to properly manage the status of the process that each vehicle has been instructed to execute.

[0006] The present invention has been made to solve the above-mentioned problems, and its main object is to provide a mobile body management device that can preferably acquire statistical data regarding the status of processing that a mobile body has been instructed to execute. [Means for solving the problem]

[0007] The invention described in the claims is a mobile object management device comprising a first receiving unit that receives a request signal issued by an information management device, a generation unit that generates a job request in response to the request signal, a first transmitting unit that transmits the job request to a plurality of mobile objects, and a second receiving unit that receives upload data for the job request, wherein the upload data includes status count information. [Brief description of the drawings]

[0008] [Figure 1] 1 shows a schematic configuration of a job distribution system according to a first embodiment. [Diagram 2] 2 is a diagram illustrating a schematic diagram of data flow between an in-vehicle terminal, a vehicle cloud server, and a service cloud server. [Diagram 3] FIG. 2 is a block diagram showing an internal configuration of the in-vehicle terminal; [Figure 4] FIG. 13 is a diagram illustrating a schematic state transition of an in-vehicle terminal for a job. [Diagram 5] 2 is a block diagram showing the internal configuration of a vehicle cloud server and a service cloud server. FIG. [Figure 6] 13 is an example of a data structure of a job request. [Figure 7] 4 is an example of a data structure of transmission history information. [Figure 8] 13 is a diagram illustrating an example of a data structure of upload data that an in-vehicle terminal transmits to a vehicle cloud server based on a job request. [Figure 9] 13 is an example of a data structure of upload data that a vehicle cloud server transmits to a service cloud server based on a job request. [Figure 10] 10 is a flowchart showing a process performed by the vehicle-mounted terminal when a job request including a valid status management flag is received. [Figure 11] 13 shows a flowchart illustrating a processing procedure executed by a vehicle cloud server that receives a job request including a valid state management flag. [Figure 12] 1 shows an example of the configuration of a job distribution system in an application example. [Figure 13] This is an aerial view showing the street in front of Station A. [Figure 14] FIG. 11 is a block diagram showing an internal configuration of an in-vehicle terminal according to a second embodiment. [Figure 15] 13 is a diagram illustrating an example of a data structure of upload data according to a second embodiment. [Figure 16] 10 is a flowchart showing a processing procedure executed by the vehicle-mounted terminal according to the second embodiment when a job request including a valid status management flag is received. [Figure 17] 13 shows a flowchart illustrating a processing procedure executed by a vehicle cloud server according to a second embodiment when a job request including a valid state management flag is received. [Figure 18] 13 is an example of a data structure of upload data according to the third embodiment. [Figure 19] FIG. 13 is a diagram illustrating an internal configuration of a vehicle cloud server according to a third embodiment. [Figure 20]13 is a flowchart showing a processing procedure executed by an in-vehicle terminal according to a third embodiment that receives a job request including a valid status management flag. [Figure 21] 13 shows a flowchart illustrating a processing procedure executed by a vehicle cloud server according to a third embodiment when a job request including a valid state management flag is received. DETAILED DESCRIPTION OF THE PREFERRED EMBODIMENTS

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

[0010] In one aspect of the mobile object management device, the command information includes condition information indicating a condition under which the mobile object executes the command indicated by the command information, and the response information includes information regarding a state that the command information can take depending on whether or not the condition is satisfied. With this aspect, the mobile object management device can obtain, for each mobile object, information regarding a state that the command information can take depending on whether or not the condition indicated by the condition information is satisfied, and thus can accurately count the number of the above-mentioned mobile objects.

[0011] In another aspect of the mobile object management device, the first transmission unit transmits the command information and flag information instructing transmission of information on a state that the command information can take to the multiple mobile objects. With this aspect, the mobile object management device can suitably collect information on a state that the command information can take from the mobile objects.

[0012] In another aspect of the mobile object management device, the states that the command information can take include an execution state in which the command is executed when the condition is satisfied and a non-execution state in which the command is not executed when the condition is not satisfied, and the second transmission unit transmits, as the mobile object number information, information indicating a ratio of the number of mobile objects for which the command information has become the execution state information to the number of mobile objects that have been successfully received, to the information management device. With this aspect, information necessary for determining the validity and cost efficiency of a request signal can be suitably supplied to the information management device.

[0013] In another aspect of the mobile object management device, the mobile object management device further includes a storage unit that stores, in association with each other, identification information of the mobile object to which the first transmission unit has transmitted the command information and identification information of the command indicated by the command information. With this aspect, the mobile object management device can preferably hold, for each transmitted command information, the number of mobile objects to which the command information is transmitted.

[0014] In another aspect of the mobile object management device, the reception result includes fail information indicating that the command information was not normally received. With this aspect, the mobile object management device can accurately count the number of mobile objects that have normally received the command information.

[0015] In yet another preferred embodiment, a control method executed by a mobile object management device includes a first receiving step of receiving a request signal issued by an information management device, a generating step of generating command information corresponding to the request signal, a first transmitting step of transmitting the command information to a plurality of mobile objects, a second receiving step of receiving a reception result indicating that the plurality of mobile objects have successfully received the command information, a first counting step of counting the number of mobile objects that have successfully received the command information based on the reception result, a third receiving step of receiving response information to the command information, a second counting step of counting the number of mobile objects that have successfully received the command information based on the response information, and a second transmitting step of transmitting mobile object number information regarding the number of mobile objects that have successfully received the command information based on the request signal and the number of mobile objects that have successfully transmitted the response information to the information management device by executing this control method.

[0016] Yet another preferred embodiment is a program for causing a computer to execute the above-described control method. By executing this program, the computer can preferably grasp the number of terminal devices that have transmitted processing information for each content of the processing indicated by the processing information. Preferably, the program is stored in a storage medium. EXAMPLES

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

[0018] The vehicle V is equipped with an on-board terminal 20. The on-board 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 on-board terminal 20 executes a process (also simply called a "job") requested by the service cloud server 40 based on the output of these sensors. In this embodiment, the job mainly refers to a process of acquiring information about the state of a specific vehicle V or the surrounding environment specified by the service cloud server 40 using a sensor and uploading the information to the service cloud server 40. The vehicle V and the on-board terminal 20 are examples of a "mobile body". In addition, the on-board terminal 20 is an example of a "terminal device". Note that the "mobile body" is not limited to the vehicle V and the on-board terminal 20, and may be a bicycle, a wheelchair, a drone, a ship, or other mobile body.

[0019] 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 vehicles (for example, self-driving cars) provided to users and collects various information from the vehicles. The information collection company may be played by the automobile manufacturer itself, or may be operated directly or indirectly by the automobile manufacturer. For example, if there are three automobile manufacturers, A, B, and C, an information collection company operated by A, an information collection company operated by B, and an information collection company operated by C exist separately, and each information collection company collects various information from vehicles manufactured by the automobile manufacturer it operates. Alternatively, a form in which a plurality of automobile manufacturers such as D, E, and F jointly commission / operate the vehicle cloud server 30 may be used. The vehicle cloud server 30 is an example of a "mobile body management device."

[0020] The service cloud server 40 is a server device constituting a service cloud. A service cloud is, for example, a cloud operated by a service provider company that provides services related to vehicles. Examples of the service provider company include an insurance company that provides insurance-related services, a map service company that provides map-related services, a parking service company that provides parking-related services, and a route search service company that provides route search-related services. The service cloud server 40 generates information (also called a "job request") that instructs the vehicle-mounted terminal 20 to execute a job according to the purpose, and distributes it 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."

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

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

[0023] FIG. 2 is a diagram illustrating a schematic diagram of data flows between the in-vehicle terminal 20, the vehicle cloud server 30, and the service cloud server 40. As shown in FIG.

[0024] 2, the service cloud server 40 transmits the generated job request "JR1" to the vehicle cloud server 30, and the vehicle cloud server 30 transmits a job request "JR2" generated based on the job request JR1 received from the service cloud server 40 to the in-vehicle terminal 20. Note that the job request JR1 can include a vehicle ID and a driver ID indicating the vehicle to execute the job, and the service cloud server 40 includes the vehicle ID and driver ID to be transmitted in the job request JR1 as necessary. As a result, the vehicle cloud server 30 transmits the job request JR2 to the in-vehicle terminal 20 of the corresponding vehicle.

[0025] The in-vehicle terminal 20 that has received the job request JR2 collects data specified in the job request JR2 from a 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 in-vehicle terminal 20, it generates upload data "UD1" based on the received upload data UD2 and transmits the generated upload data UD1 to the service cloud server 40 that made the request. The data structures of the job requests JR1, JR2 and the upload data UD1, UD2 are described in "(5) Data Structure " section. The job request JR1 transmitted from the service cloud server 40 to the vehicle cloud server 30 is an example of a "request signal", the job request JR2 transmitted from the vehicle cloud server 30 to the in-vehicle terminal 20 is an example of "transmission information", and the upload data UD2 is an example of a "reception result".

[0026] (2) Vehicle-mounted terminal configuration 3 is a block diagram showing the internal configuration of the in-vehicle terminal 20. As shown in the figure, the in-vehicle terminal 20 mainly 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. The elements in the in-vehicle terminal 20 are connected to each other via a bus line 29. The interface 25 is also connected to a sensor unit 27.

[0027] Based on the control of the control unit 24, the communication unit 21 transmits upload data to the vehicle cloud server 30 and receives 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 vehicle state from the vehicle.

[0028] The storage unit 22 stores programs executed by the control unit 24 and information required for the control unit 24 to execute predetermined processes. 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.

[0029] The map DB is a database including, for example, road data, facility data, and feature data around the road. The road data includes roadway / lane network data for route search, road shape data, traffic law data, and the like. The feature data includes information on signs such as road signs, road markings such as stop lines, road dividing lines such as center lines, and structures along the road. The feature data may also include highly accurate point cloud information of features to be used for vehicle position estimation. In addition, the map DB may store various other data necessary for position estimation.

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

[0031] The state count information is information that indicates the cumulative number of transitions for each state of a job requested by job request JR2 during the period in which the job is valid. The state count information is, for example, information in which the number of transitions to each state that a job can take is associated with the number of transitions to that state. The control unit 24 updates the state count information every time it detects a transition of the above-mentioned states. Job state transitions will be described later with reference to FIG. 4. The state count information is an example of "counting information".

[0032] The input unit 23 is a button, a touch panel, a remote controller, a voice input device, etc. for the user to operate, and receives, for example, an input specifying a destination for route search, an input specifying on / off of autonomous driving, etc., and supplies the generated input signal to the control unit 24. The output unit 26 is, for example, a display, a speaker, etc. that performs output based on the control of the control unit 24.

[0033] The interface 25 performs an interface operation for supplying output data of the sensor unit 27 to the control unit 24 and a sensor data cache. The sensor unit 27 includes a plurality of external sensors for recognizing the surrounding environment of the vehicle, such as a lidar and a camera, and internal sensors, such as a GPS receiver, a gyro sensor, a position sensor, and a 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 photographed from the vehicle. The position sensor is provided for detecting the position of each external sensor, and the three-axis sensor is provided for detecting the attitude of each external sensor. The sensor unit 27 may have any external sensor and internal sensor other than the external sensor and internal sensor shown in FIG. 3. For example, the sensor unit 27 may include an ultrasonic sensor, an infrared sensor, a microphone, etc. as an external sensor.

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

[0035] The position estimation unit estimates the vehicle position (including the vehicle attitude) based on the output data of the sensor unit 27 stored in the sensor data cache and the map DB. The position estimation unit can execute various position estimation methods. For example, the position estimation unit executes a vehicle position estimation method using dead reckoning (autonomous navigation) based on the output of an autonomous positioning sensor such as a GPS receiver and a gyro sensor, a vehicle position estimation method that performs a process (map matching) of further matching road data in the map DB with autonomous navigation, and a vehicle position estimation method based on output data from an external sensor such as a lidar or a camera and position information of the landmark indicated by the feature information in the map DB, using a predetermined object (landmark) existing in the surroundings as a reference. Then, the position estimation unit executes a position estimation method with the highest estimation accuracy among the currently executable position estimation methods, and supplies the vehicle position information indicating the vehicle position, etc. obtained based on the executed position estimation method to the upload data generation unit.

[0036] The object detection unit detects a predetermined object based on 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 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, for example, when there is a difference between the position, shape, etc. of the object detected by the sensor unit 27 and the position, shape, etc. of the object indicated by the feature data extracted from the map DB, or when there is no corresponding feature data in the map DB, the object detection unit supplies information on the object detected by the sensor unit 27 to the upload data generation unit.

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

[0038] Here, the transition of the job state (also simply called the "job state") indicated by the job request JR2 will be described.

[0039] Fig. 4 is a diagram showing the outline of the job state transitions. Fig. 4 shows an inactive state (not in execution), which is a job state that does not satisfy the execution conditions of the job indicated by the job request JR2, an active state (in execution), which is a job state that satisfies the execution conditions of the job, and a Failed state, which is a transition state in exceptional cases.

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

[0041] If the authentication process is successful, the job automatically transitions to an inactive state. After that, if it is determined that the execution conditions of the job indicated by the job request JR2 are satisfied, the job transitions to an active state, and if it is determined that the execution conditions are not satisfied after the transition to the active state, the job transitions to an inactive state.

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

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

[0044] The communication unit 31 communicates with the in-vehicle 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 a job request JR1 from the service cloud server 40, and transmits a job request JR2 generated based on the job request JR1 to the in-vehicle terminal 20. The communication unit 31 also receives upload data UD2 from the in-vehicle terminal 20, and transmits upload data UD1 generated based on the upload data UD2 to the service cloud server 40.

[0045] The storage unit 32 includes a ROM, a RAM, etc., and stores programs for various processes executed by the vehicle cloud server 30. The storage unit 32 is also used as a working 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 is, for example, table information that associates, for each vehicle, a vehicle ID and / or a driver ID, communication address information for transmitting data to the vehicle-mounted terminal 20 of the corresponding vehicle, and information about services used by the vehicle. The transmission history information Ih is a table that shows the history of transmitting a job request JR2 to the vehicle-mounted terminal 20 of each vehicle, and a detailed data structure will be described later.

[0046] The storage unit 32 may further store history data of the job request JR1 received by the vehicle cloud server 30 from the service cloud server 40, and the upload data UD2 acquired by the vehicle cloud server 30 from the in-vehicle 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, etc. Similarly, the storage unit 32 may store the job request JR1 received from the service cloud server 40 in association with information identifying the service cloud server 40 that sent the request, the reception time, etc.

[0047] The control unit 33 is configured by 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." Additionally, the communication unit 31 and the control unit 33 are an example of a "first receiving unit," a "first transmitting unit," a "second receiving unit," a "third receiving unit," and a "second transmitting unit."

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

[0049] 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 information corresponding to provided information, which will be described later, from the vehicle cloud server 30.

[0050] The storage unit 42 includes a ROM which is a non-volatile memory and a RAM which is a volatile memory, 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. The storage unit 42 may also store a history of a job request JR1 transmitted by the service cloud server 40 to the vehicle cloud server 30, and 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 identifying the destination or source vehicle cloud server 30, the transmission and reception time, and the like.

[0051] The control unit 43 is configured with a computer such as a CPU, and controls the entire service cloud server 40. Specifically, the control unit 43 executes various programs stored in the storage unit 42 to perform various processes.

[0052] (5) Data Structure Next, the data structures of various data will be described. Hereinafter, when there is no need to distinguish between job requests JR1 and JR2, they will simply be referred to as "job requests," and when there is no need to distinguish between upload data UD1 and upload data UD2, they will simply be referred to as "upload data." (5-1) Job Requests 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”, “status management flag”, and “collection data specification information”.

[0053] "Version information" is information for identifying the version of the specifications that define the job request, etc. "Attribute information" is information that defines how to handle the target job request.

[0054] The "request identification information" is identification information unique to the job request JR1 generated by the service cloud server 40. The service cloud server 40 generates unique request identification information and includes it in the job request JR1 every time the job request JR1 is generated. 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 in-vehicle terminal 20 as the "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) that identifies the job.

[0055] The "data collection condition information" is information indicating the conditions for collecting data. For example, the "data collection condition information" is information indicating the geographical conditions under which the in-vehicle terminal 20 generates the upload data UD2, the time conditions under which the upload data UD2 is generated, an event, the vehicle ID of the vehicle V, and / or the driver ID of the driver of the vehicle V. Here, the geographical conditions under which the upload data UD2 is generated are, for example, conditions that specify the road or area under which the upload data UD2 is generated, and the time conditions under which the upload data UD2 is generated are, for example, conditions that specify time constraints such as the time period or interval under which the upload data UD2 is generated. In addition, the event indicates an event that triggers the generation of the upload data UD2, and for example, the occurrence of an impact of a predetermined degree or more (i.e., an accident) or the occurrence of sudden braking is specified as the above-mentioned event. The data collection condition information is an example of the "condition information".

[0056] "Collected data designation information" is information that designates collected data to be included as upload data when the job execution conditions indicated by the data collection condition information are satisfied. The collected data designation information is, for example, information regarding the acceleration and deceleration of the vehicle, information regarding the vehicle speed, information regarding the vehicle's travel trajectory (i.e., the vehicle's position and attitude over time), information regarding the departure point and destination, and camera image information for a specified time before and after the occurrence of an accident. The contents designated as the data collection condition information and the collected data designation information are each 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 collected data designation information are examples of "command information".

[0057] The "status management flag" is a flag (also called "status management flag Fs") that specifies whether or not uploading of status count information is required. For example, the status management flag Fs can be either "0" indicating that it is invalid, or "1" indicating that it is valid. When it is 1 (valid), it indicates that uploading of status count information is required, and when it is 0 (invalid), it indicates that uploading of status count information is not required. The status management flag Fs is an example of flag information. Note that instead of being set in a separate field in the job request, the status management flag Fs may be included in any of the fields of the data collection condition information, attribute information, or collection data specification information.

[0058] Here, when a valid status management flag Fs is included in the job request JR1 transmitted from the service cloud server 40 to the vehicle cloud server 30, the vehicle cloud server 30 counts the number of vehicles related to the job status for the job indicated by the job request JR1. Then, the vehicle cloud server 30 transmits the counting result to the service cloud server 40 as upload data UD1. The data structure of the upload data UD1 including the above-mentioned counting result will be described later with reference to FIG. 9.

[0059] Furthermore, when a valid status management flag Fs is included in the job request JR2 transmitted from the vehicle cloud server 30 to each vehicle-mounted terminal 20, the vehicle-mounted terminal 20 generates information required for the vehicle cloud server 30 to count the number of vehicles related to the above-mentioned job status. Then, the vehicle-mounted terminal 20 includes the generated information in 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. 8.

[0060] Note that the job request may include any information other than the information shown in Fig. 6. For example, the job request may include address information specifying a destination for transmitting upload data to the service cloud server 40 or the vehicle cloud server 30 that is the 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 job requests JR1 indicating jobs of the same content to a plurality of vehicle cloud servers 30, each job request JR1 may include request identification information that differs for each job request JR1 and a job ID that is common to all job requests JR1.

[0061] (5-2) Transmission history information Fig. 7 shows 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".

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

[0063] Each time the vehicle cloud server 30 transmits a job request JR2 to the in-vehicle terminal 20, it adds a record associating the vehicle ID and the job ID to the transmission history information Ih held by the vehicle cloud server 30. The transmission history information Ih may include any items other than the vehicle ID and the job ID. For example, the transmission history information Ih may further include identification information of the service cloud that is the source of the job request JR1 used to generate the job request JR2 transmitted to the in-vehicle terminal 20. This identification information may be any information (e.g., a communication address) for identifying the service cloud.

[0064] Furthermore, when the vehicle cloud server 30 receives upload data UD2 from the in-vehicle terminal 20 indicating that the job request JR2 could not be normally accepted (i.e., a failure has occurred), the vehicle cloud server 30 deletes the corresponding record from the transmission history information Ih. That is, in this case, the vehicle cloud server 30 deletes from the transmission history information Ih a record including the vehicle ID corresponding to the in-vehicle terminal 20 that transmitted the upload data UD2 and the job ID indicating the failed job. As a result, only a record indicating a combination of the vehicle ID of the in-vehicle terminal 20 that normally received the job request JR2 and the job ID corresponding to the job indicated by the job request JR2 is recorded in the transmission history information Ih.

[0065] Here, a description will be given of the use of the transmission history information Ih shown in Fig. 7. The vehicle cloud server 30 can appropriately calculate the number of vehicles that have become inactive (also called the "number of inactive vehicles") by referring to the transmission history information Ih.

[0066] Specifically, the vehicle cloud server 30 calculates the number of records in the transmission history information Ih 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, the job state is automatically set to the inactive state when the authentication process is successful, so the job indicated by the job request JR2 for which the authentication process is successful in the vehicle-mounted terminal 20 is always set to the inactive state. If the authentication process fails, upload data UD2 indicating the failure is transmitted to the vehicle cloud server 30, and the corresponding record is deleted from the transmission history information Ih by the vehicle cloud server 30. Thus, the vehicle cloud server 30 can appropriately specify the number of vehicles for which the job has been authenticated and accepted (the number of inactive vehicles) for each job by referring to the transmission history information Ih and counting the number of vehicles that transmitted the job request JR2 for each job. As will be described later, information on the specified number of inactive vehicles is transmitted to the service cloud server 40 in the form of being included in the upload data UD1.

[0067] (5-3) Upload Data Next, the data structure of each of the upload data UD1 and UD2 will be specifically described.

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

[0069] "Version information" is information that identifies the version of the specifications that define the upload data UD2. For example, this "version information" is specified to have the same content as the "version information" included in the previously received job request JR2. "Request identification information" indicates the request identification information of the previously received job request JR2.

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

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

[0072] Here, a supplementary explanation will be given on the method of generating the state count information.

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

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

[0075] "Version information" is information that identifies the version of the specifications that define the upload data UD1. For example, this "version information" is specified to have the same content as the "version information" included in the previously received job request JR1. "Request identification information" indicates the request identification information of the previously received job request JR1.

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

[0077] The "number of inactive vehicles" is the number of vehicles whose state of the job requested by the job request JR1 has become inactive. In the first example of this embodiment, 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 calculates the number of records in which the identification information (e.g., request identification information) of the job requested by the job request JR1 is recorded as the "job ID" among the records recorded in the transmission history information Ih as the number of inactive vehicles. As described above, in the vehicle-mounted terminal 20 that receives the job request JR2, if the authentication of the job request JR2 is successful, the state of the job requested by the job request JR2 is always inactive, and if the authentication of the job request JR2 fails, 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 appropriately 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 the number of inactive vehicles for the job based on the state count information included in the upload data UD2. In this case, the vehicle cloud server 30 calculates the number of inactive vehicles for the job as the number of in-vehicle terminals 20 that are the transmission sources of the upload data UD2 for which the number of inactive transitions indicated by the above-mentioned state count information is one or more.

[0078] The "number of active vehicles" is the number of vehicles whose state of the job requested by the job request JR1 has become active. In this embodiment, the vehicle cloud server 30 calculates the number of active vehicles for the job requested by the job request JR1 by referring to the number of active transitions indicated by the state count information of 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. Specifically, the vehicle cloud server 30 calculates the number of vehicle-mounted terminals 20 that have transmitted upload data UD2 that results in the number of active transitions of the job being one or more as the number of active vehicles for the job. In this way, the vehicle cloud server 30 can suitably calculate the number of active vehicles for the job 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.

[0079] The "total number of active vehicles" is the total number of vehicles whose state of the job requested by the job request JR1 has become active. In this embodiment, the vehicle cloud server 30 calculates the total number of active vehicles for the job requested by the job request JR1 by accumulating 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. In this way, the vehicle cloud server 30 can suitably calculate the total number of active vehicles for the job 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 to which the job request JR2 is sent. The number of inactive vehicles, the number of active vehicles, and the total number of active vehicles are examples of "mobile object number information."

[0080] The "number of data-collected vehicles" is the number of vehicles that uploaded collected data for the job requested by the job request JR1. In this embodiment, the vehicle cloud server 30 calculates the number of data-collected vehicles as the number of vehicles that are the senders of the upload data UD2 that includes collected data, among 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.

[0081] Next, a supplementary explanation will be given regarding the use of the upload data UD1.

[0082] The service cloud server 40, which receives upload data UD1 having the data structure shown in FIG. 9 as a response to the job request JR1, can determine the reliability of the returned collected data, the validity and cost-effectiveness of the data collection request, and the like, based on statistics on the number of vehicles included in the upload data UD1.

[0083] For example, the service cloud server 40 can generate ratio information indicating the ratio of the number of active vehicles and / or the number of data collection vehicles to the number of inactive vehicles, thereby suitably calculating an index indicating the effectiveness and cost efficiency of the data collection request based on the job request JR1. For example, the service cloud server 40 can determine that the effectiveness and cost efficiency of the data collection request is higher as the ratio indicated by the above-mentioned ratio information is higher. Furthermore, the service cloud server 40 can suitably determine 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. For example, the service cloud server 40 can determine that the reliability of the collected data received from the vehicle cloud server 30 is higher as the number of active vehicles, the total number of active vehicles, and the number of data collection vehicles are higher.

[0084] Note that the data structure example of the upload data UD1 is not limited to that shown in Fig. 9. For example, the upload data UD1 may include a total number of inactive vehicles indicating the total number of vehicles that have become inactive. In this case, the vehicle cloud server 30 determines the total number of inactive vehicles by accumulating the number of inactive transitions indicated by the state count information included in the upload data UD1 received from each vehicle-mounted terminal 20.

[0085] (6) Processing Flow Next, the processes executed by the in-vehicle 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 will be specifically described with reference to the flowcharts of FIGS.

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

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

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

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

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

[0091] Next, the in-vehicle terminal 20 updates the state count information according to whether or not the job state has transitioned (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 updates the state count information to increase the active transition count for the job by 1. On the other hand, when the in-vehicle 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 updates the state count information to increase the inactive transition count for the job by 1.

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

[0093] Then, when it is time to transmit the upload data UD2 (step S107; Yes), the on-board terminal 20 transmits the upload data UD2 (see FIG. 8) including the collected data collected in step S105 and the state count information indicating the number of inactive transitions and the number of active transitions to the vehicle cloud server 30 (step S108). In a mode in which the on-board terminal 20 transmits the upload data UD2 at multiple timings, the state count information may be included only in the upload data UD2 transmitted at the last transmission timing. In addition, the on-board terminal 20 may transmit the upload data UD2 including at least the state count information at the end of the validity period of the job to the vehicle cloud server 30 in order to include in the upload data UD2 the final number of active transitions and the number of inactive transitions during the validity period of the job. In this case, the upload data UD2 may not include the collected data. That is, in this case, the on-board terminal 20 may not necessarily match the transmission timing of the collected data and the state count information.

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

[0095] (6-2) Vehicle Cloud Server Processing FIG. 11 is a flowchart showing a processing procedure executed by the vehicle cloud server 30 that receives a job request JR1 including a valid state management flag Fs.

[0096] First, the vehicle cloud server 30 receives a job request JR1 including a 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 a job request JR2 generated based on the job request JR1 to the in-vehicle terminal 20 of the vehicle managed by the vehicle cloud server 30 (step S202).

[0097] After that, the vehicle cloud server 30 receives the upload data UD2 from the in-vehicle terminal 20 to which the job request JR2 was sent, and stores the upload data UD2 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 for the upload data UD2 ends (step S204; No). In this way, the vehicle cloud server 30 stores the upload data UD2 provided from the in-vehicle terminals 20 of multiple vehicles.

[0098] As an embodiment not shown in the flowchart, for example, for information that requires a certain degree of real-timeness, the vehicle cloud server 30 may transmit the upload data UD2 received periodically or intermittently during the collection period of the upload data UD2 as upload data UD1 to the service cloud server 40 one by one without storing the received upload data UD2 in the storage unit 32. In this case, the vehicle cloud server 30 transmits only the state count information collected in step S205 (to be described later) to the service cloud server 40 after the collection period of the upload data UD2 ends.

[0099] Then, when the vehicle cloud server 30 determines that the collection period of the upload data UD2 has ended (step S204; Yes), it counts the number of inactive vehicles, the number of active vehicles, the total number of active vehicles, the number of data-collected vehicles, and the like (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. The vehicle cloud server 30 also calculates the number of inactive vehicles based on either the transmission history information Ih or the number of inactive transitions indicated by the state count information, and calculates the number of data-collected vehicles by counting the in-vehicle terminals 20 that are the transmission sources of the upload data UD2 including the collected data. Note that, when the vehicle cloud server 30 has received upload data UD2 related to the same job from the same in-vehicle terminal 20 multiple times, it is preferable to perform the above-mentioned counting based on the state count information included in the last-received upload data UD2.

[0100] Next, the vehicle cloud server 30 transmits upload data UD1 (see FIG. 9) including the counting result in step S205 to the service cloud server 40 that requested the job request JR1 (step S206). After that, the service cloud server 40 that generated the job request JR1 receives the upload data UD1 from the vehicle cloud server 30. In this case, the service cloud server 40 judges the reliability of the returned collected data, the validity and cost efficiency of the data collection request, etc. based on the received upload data UD1.

[0101] (7) Application Examples Next, an application example of this embodiment will be described. Here, an example will be described in which a municipality or other local government uses the job distribution system to obtain detailed information on traffic congestion and road usage as part of urban development and road usage analysis.

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

[0103] A municipality has two train stations (Station A and Station B). The roads in front of each station are congested, so it is necessary to expand the roads in front of the stations. To systematically expand the roads in front of the stations, congestion data is collected. Taxi vehicles V are vehicles that frequently run on the roads in front of the two train stations, and there are a total of 80 vehicles. In addition, there is a taxi pool at each station.

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

[0105] Here, the first service cloud server 40A generates a job request JR1 that specifies the driving time and dwell (stop) time when leaving the taxi pool 52 and passing through the station road 51 from the intersection 53 to the intersection 54, and the driving time and dwell time from the intersection 54 to entering the taxi pool 52, as the "collection data specification information" shown in FIG. 6. This job request JR1 further includes "data collection condition information" (see FIG. 6) that specifies one week from the following Monday to Sunday as the validity period of the job and specifies 6:00 a.m. to 7:00 p.m. as the execution time period of the job. Then, the first service cloud server 40A calculates the average driving time and average dwell time for each time period 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. Then, the first service cloud server 40A transmits the calculated average driving time and average dwell time to the second service cloud server 40B as upload data. In this case, the second service cloud server 40B examines the contents of the congestion information based on the upload data received from the first service cloud server 40A. Similarly, for Station B, the first service cloud server 40A calculates the average travel time and average residence time for the road in front of the station based on the upload data UD1 received from the vehicle cloud server 30, and transmits upload data including the calculation results to the second service cloud server 40B.

[0106] In such a case, the first service cloud server 40A receives statistical data on the number of vehicles related to the job status, etc. from the vehicle cloud server 30 by including a valid status management flag Fs in the job request JR1, and supplies the statistical data to the second service cloud server 40B. As a result, when examining the contents of the congestion information in front of each station, the second service cloud server 40B can take into account the statistical data on the number of vehicles related to the job status, etc., and can accurately examine the congestion information. In addition, it is possible to infer that a time period in which there are no or very few measured vehicles (i.e., the number of active vehicles is very small) may be a time period in which there is no inflow of taxis into the road in front of the station due to severe congestion, or a time period in which there is no demand for taxis (i.e., a time period in which many taxi vehicles V wait in the taxi pool). Based on the collected data and the above-mentioned statistical data on the number of vehicles, the local government consults with taxi companies, etc. as necessary and adjusts the acquisition conditions and analysis methods of congestion information.

[0107] <Second Example> The in-vehicle terminal 20 according to the second embodiment transmits history information (also called "state history information") relating to the transition of the job state to the vehicle cloud server 30, instead of transmitting state count information indicating the number of transitions to each job state to the vehicle cloud server 30. Hereinafter, 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, etc. are the same as those in the first embodiment, so that the description thereof will be omitted.

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

[0109] 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 state count information. When a valid state management flag Fs is included in the corresponding job request JR2, the in-vehicle terminal 20 transmits the state history information corresponding to the job together with the collected data, which is the execution result of the job requested by the job request JR2, to the vehicle cloud server 30. As a result, the vehicle cloud server 30 that receives the upload data UD2 can appropriately 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. The state history information is an example of "counting information".

[0110] 16 is a flowchart showing a process performed by the vehicle-mounted terminal 20 according to the second embodiment when a job request JR2 including a valid status management flag Fs is received. The vehicle-mounted terminal 20 repeatedly executes the process of the flowchart shown in FIG.

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

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

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

[0114] Thereafter, as in the first embodiment, if it is time to send the upload data UD2 (step S307; Yes), the in-vehicle terminal 20 sends the upload data UD2 (see FIG. 15) including the collected data and state history information collected in step S305 to the vehicle cloud server 30 (step S308). If the in-vehicle terminal 20 determines that the job is completed (step S309; ​​Yes), it ends the processing of the flowchart. On the other hand, if it is not time to send the upload data UD2 (step S307; No) or if the job is not completed (step S309; ​​No), the processing returns to step S304.

[0115] FIG. 17 shows a flowchart illustrating a processing procedure executed by the vehicle cloud server 30 according to the second embodiment when the job request JR1 including the valid state management flag Fs is received.

[0116] First, the vehicle cloud server 30 receives a job request JR1 including a 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 a job request JR2 generated based on the job request JR1 to the in-vehicle terminal 20 of the vehicle managed by the vehicle cloud server 30 (step S402).

[0117] After that, the vehicle cloud server 30 receives the upload data UD2 including the state history information from the in-vehicle 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).

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

[0119] Then, the vehicle cloud server 30 tally up 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. The vehicle cloud server 30 also calculates the number of inactive vehicles based on either the transmission history information Ih or the number of inactive transitions calculated in step S405, and calculates the number of data collection vehicles by counting the in-vehicle terminals 20 that are the transmission sources of the upload data UD2 including the collected data.

[0120] Next, the vehicle cloud server 30 transmits upload data UD1 (see FIG. 9) including the counting result in step S405 to the service cloud server 40 that requested the job request JR1 (step S407). After that, the service cloud server 40 that generated the job request JR1 receives the upload data UD1 from the vehicle cloud server 30. In this case, the service cloud server 40 judges the reliability of the returned collected data, the validity and cost efficiency of the data collection request, etc. based on the received upload data UD1.

[0121] <Third Example> The in-vehicle terminal 20 according to the third embodiment transmits information indicating the current job state (also simply called "state information"), instead of state count information or state history information, to the vehicle cloud server 30. Hereinafter, the configuration of the service cloud server 40, the data structure of the job requests JR1 and JR2, the data structure of the upload data UD1, etc. are the same as those in the first and second embodiments, and therefore will not be described again.

[0122] Fig. 18 shows 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.

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

[0124] FIG. 19 is a diagram showing an outline of 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 state history information for each job and for each vehicle ID, for example, based on state information included in the upload data UD2 received from the in-vehicle terminal 20. In this case, for example, the state history information is information that associates the job state indicated by the state information with the reception time or generation time of the state information for each request identification information and vehicle ID. By holding such state history information, the vehicle cloud server 30 can suitably perform the counting of the number of inactive vehicles, the number of active vehicles, the total number of active vehicles, the number of data-collected vehicles, and the like, as in the first and second embodiments.

[0125] 20 is a flowchart showing a process performed by the vehicle-mounted terminal 20 according to the third embodiment when a job request JR2 including a valid status management flag Fs is received. The vehicle-mounted terminal 20 repeatedly executes the process of the flowchart shown in FIG.

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

[0127] Next, the vehicle-mounted terminal 20 determines whether it is time to transmit 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 multiple jobs. If it is time to transmit the upload data UD2 (step S505; Yes), the vehicle-mounted terminal 20 generates status information indicating the current job status (step S505). Specifically, if the execution conditions of the job are not met, the vehicle-mounted terminal 20 generates status information indicating that the job is inactive, and if the execution conditions of the job are met, the vehicle-mounted terminal 20 generates status information indicating that the job is active.

[0128] Then, the in-vehicle 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). If the in-vehicle terminal 20 determines that the job should be ended (step S508; Yes), it ends the processing of the flowchart.

[0129] On the other hand, if it is not time to transmit the upload data UD2 (step S505; No), or if the job is not completed (step S508; No), the vehicle-mounted terminal 20 returns to step S503. As a result, the vehicle-mounted terminal 20 repeatedly executes the processes of steps S503 to S507 until the validity period of the job expires.

[0130] FIG. 21 shows a flowchart illustrating a processing procedure executed by the vehicle cloud server 30 according to the third embodiment when the job request JR1 including a valid state management flag Fs is received.

[0131] First, the vehicle cloud server 30 receives a job request JR1 including a 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 a job request JR2 generated based on the job request JR1 to the in-vehicle terminal 20 of the vehicle managed by the vehicle cloud server 30 (step S602).

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

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

[0134] Then, the vehicle cloud server 30 tally up 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. The vehicle cloud server 30 also calculates the number of inactive vehicles based on either the transmission history information Ih or the number of inactive transitions calculated in step S605, and calculates the number of data collection vehicles by counting the in-vehicle terminals 20 that are the transmission sources of the upload data UD2 including the collected data.

[0135] Next, the vehicle cloud server 30 transmits upload data UD1 (see FIG. 9) including the counting result in step S605 to the service cloud server 40 that requested the job request JR1 (step S608). After that, the service cloud server 40 that generated the job request JR1 receives the upload data UD1 from the vehicle cloud server 30. In this case, the service cloud server 40 judges the reliability of the returned collected data, the validity and cost efficiency of the data collection request, etc. based on the received upload data UD1.

[0136] 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 the multiple vehicles. The vehicle cloud server 30 also receives the upload data UD2 which is a reception result indicating that the vehicle-mounted terminals 20 of the multiple vehicles have successfully received the job request JR2, and counts the number of inactive vehicles which is the number of vehicles which have successfully received the job request JR2 based on the upload data UD2. The vehicle cloud server 30 also receives the upload data UD2 in which the number of active transitions of the job is one or more, and counts the number of active vehicles and the total number of active vehicles which indicate the number of vehicles and the total number of vehicles which have transmitted the upload data UD2. The vehicle cloud server 30 then transmits the upload data UD1 including information on the number of inactive vehicles, the number of active vehicles, and the total number of active vehicles to the service cloud server 40.

[0137] As described above, the vehicle cloud server 30 receives the job request JR1 issued by the service cloud server 40. Then, the vehicle cloud server 30 generates a job request JR2 including data collection condition information and collected data designation information according to the job request JR1, and a state management flag Fs indicating that state count information, state history information, or state information is to be transmitted for counting the number of active transitions, which is the number of times that the state of the job indicated by the data collection condition information and collected data designation information becomes an active state in which the job is executed when a predetermined condition is satisfied. Then, the vehicle cloud server 30 transmits the job request JR2 to the vehicle-mounted terminals 20 of the multiple vehicles. Then, the vehicle cloud server 30 receives upload data UD2 including the collected data and state count information, state history information, or state information for the job request JR2, and counts at least one of the number of active vehicles or the total number of active vehicles based on the state count information, state history information, or state information. Then, the vehicle cloud server 30 transmits upload data UD1 based on the above-mentioned counting result to the service cloud server 40.

[0138] <Modification> Next, a description will be given of preferred modifications to the above-mentioned first to third embodiments. The following modifications may be applied to the above-mentioned embodiments in any combination.

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

[0140] (Variation 2) The state count information in the first embodiment includes information about the number of inactive transitions. Alternatively, the state count information does not need to include information about the number of inactive transitions.

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

[0142] Similarly, the state history information in the second embodiment does not need to include information about the transition to the inactive state. Even in this case, the vehicle cloud server 30 that receives the upload data UD2 including the state history information may calculate the number of inactive vehicles based on the transmission history information Ih in step S406 in FIG.

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

[0144] (Variation 4) In the first to third embodiments, the job requests JR1 and JR2 may each include a plurality of jobs. In this case, common execution conditions may be set for the plurality of jobs, or different execution conditions may be set for each job. When different execution conditions are set for each job, the jobs have individual job states. For example, when transitioning from an inactive state to an active state, each job that satisfies the execution conditions transitions to the active state individually.

[0145] (Variation 5) In the first to third embodiments, the vehicle cloud server 30 may generate 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 collecting vehicles to the number of inactive vehicles, and transmit the ratio information to the service cloud server 40 by including it in the upload data UD1. This allows the vehicle cloud server 30 to suitably transmit information required to determine the validity and cost efficiency of the data collection request to the service cloud server 40. In this modification, the above-mentioned ratio information is an example of "mobile object number information". [Explanation of symbols]

[0146] 20 Vehicle-mounted terminal 27 Sensor section 30 Vehicle Cloud Server 40 Service Cloud Server

Claims

[Claim 1] A first receiving unit that receives a request signal issued by the information management device; a generation unit that generates a job request in response to the request signal; a first transmission unit that transmits the job request to a plurality of moving objects; a second receiving unit for receiving upload data for the job request; Equipped with The mobile management device, wherein the upload data includes status count information.

Images