JP2019020928A - System, method and program for managing traffic information - Google Patents

Abstract

To secure a quality of traffic information to be obtained from probe information on a vehicle.SOLUTION: A service providing server 10 according to one embodiment of the present invention has a function for providing a service using a share-ride taxi, or a vehicle such as an article delivery (inclusive of a shopping substitute) and the like. The function includes managing of traffic information in a travelling area of the vehicle to be used in the service. Since a server 10 is configured to acquire probe information on the vehicle to accumulate the probe information in a storage 15 and the like; and generate traffic information between consecutive two stopping points to be included in a travel plan of the vehicle on the basis of the accumulated probe information, the traffic information to be generated has information corresponding to a stopping state according to the travel plan at the stopping point excluded.SELECTED DRAWING: Figure 1

Description

  The present invention relates to a system, method, and program for managing traffic information.

  Conventionally, various systems for analyzing probe information transmitted from a vehicle have been proposed (see, for example, Patent Document 1 below). In such a system, for example, current or past traffic information (for example, traffic jam information for each time zone) can be obtained by analyzing a vehicle position at each time included in probe information of each of a plurality of vehicles. . In addition, a business that provides a service using a vehicle can obtain traffic information in the service providing area by analyzing the probe information of the vehicle used in the service. The traffic information obtained in this way can be used, for example, when creating a vehicle allocation plan in a shared taxi service and a delivery plan in an article delivery service.

JP-A-2006-133875

  However, for example, the state of a vehicle that travels according to a vehicle allocation plan or the like is stopped due to a state where the vehicle is stopped according to the plan (for example, a state waiting for a user at a boarding place) and traffic conditions. Although states (for example, traffic jams, waiting for signals, etc.) are included, it is not easy to identify these states from vehicle probe information. And if such a state cannot be identified appropriately, the quality of the traffic information obtained will also be restrict | limited.

  An embodiment of the present invention has an object to ensure the quality of traffic information obtained from vehicle probe information. Other objects of the embodiments of the present invention will become apparent by referring to the entire specification.

  A system according to an embodiment of the present invention is a system for managing traffic information, and includes a storage device that stores a travel plan of a vehicle including a plurality of stop points, and one or more computer processors. The one or more computer processors acquire the probe information of the vehicle and store it in the storage device in response to execution of a readable instruction, and based on the probe information stored in the storage device And processing for generating traffic information between two consecutive stop points included in the travel plan.

  A method according to an embodiment of the present invention is a method for managing traffic information that is executed by one or more computers accessible to a storage device that stores a travel plan of a vehicle including a plurality of stop points. Obtaining the probe information of the vehicle and storing it in the storage device; and, based on the probe information stored in the storage device, traffic information between two consecutive stop points included in the travel plan. Generating.

  A program according to an embodiment of the present invention is a program for managing traffic information on one or more computers accessible to a storage device that stores a travel plan of a vehicle including a plurality of stop points. Depending on the execution, it is included in the travel plan based on the process of acquiring the probe information of the vehicle in the one or more computers and storing it in the storage device and the probe information stored in the storage device. Generating traffic information between two consecutive stop points.

  Various embodiments of the present invention ensure the quality of traffic information obtained from vehicle probe information.

1 is a configuration diagram schematically showing a configuration of a network including a service providing server 10 according to an embodiment of the present invention. FIG. 2 is a block diagram schematically showing functions of a service providing server 10. The figure which illustrates the information managed in a dispatch request information table. The figure which illustrates the information managed in a travel plan information table. The figure which illustrates the information managed in a probe information table. The figure which illustrates the information managed in a traffic information table. The flowchart which illustrates the process which the server 10 performs according to a vehicle allocation request | requirement. The figure which illustrates the vehicle allocation application screen. The figure which illustrates standby time selection screen 70. The figure which shows the specific example of the information managed in a travel plan information table. The figure for demonstrating the travel plan corresponding to the specific example of FIG. The figure which illustrates boarding time frame selection screen 90. The figure for demonstrating a mode that a new boarding / alighting point is added to the travel plan illustrated in FIG. The figure which illustrates the getting-off time frame selection screen 100. The figure which shows the specific example of the information managed in the travel plan information table after an update. The figure for demonstrating the travel plan corresponding to the specific example of FIG. The flowchart which illustrates the process which the server 10 performs when producing | generating traffic information. The figure for demonstrating the method to determine actual arrival time. The figure for demonstrating the learned model. The flowchart which illustrates the process which the server 10 performs when updating the learned model.

  Hereinafter, embodiments of the present invention will be described with reference to the drawings.

  FIG. 1 is a configuration diagram schematically showing the configuration of a network including a service providing server 10 according to an embodiment of the present invention. As illustrated, the server 10 is communicably connected to a vehicle terminal 32 and a user terminal 34 via a network 20 such as the Internet. In FIG. 1, only one vehicle terminal 32 and user terminal 34 are shown, but the server 10 is connected to a plurality of vehicle terminals 32 and user terminals 34 so as to communicate with each other. The server 10 has a function for providing a service using a vehicle such as a shared taxi or an article delivery (including shopping agency), and the function includes traffic information in a travel area of the vehicle used in the service. Including managing. The service providing server 10 is an example of a device that implements all or part of the system of the present invention.

  The service providing server 10 is configured as a general computer, and as shown in FIG. 1, a CPU (computer processor) 11, a main memory 12, a user I / F 13, a communication I / F 14, a storage ( A storage device) 15, and these components are electrically connected via a bus or the like (not shown).

  The CPU 11 reads various programs stored in the storage 15 or the like into the main memory 12 and executes various instructions included in the programs. The main memory 12 is configured by, for example, a DRAM.

  The user I / F 13 is various input / output devices for exchanging information with the user. The user I / F 13 includes, for example, an information input device such as a keyboard and a pointing device (for example, a mouse and a touch panel), a voice input device such as a microphone, and an image input device such as a camera. The user I / F 13 includes an image output device (display device) such as a display and an audio output device such as a speaker.

  The communication I / F 14 is implemented as hardware such as a network adapter, various types of communication software, and combinations thereof, and is configured to realize wired or wireless communication via the network 20 or the like.

  The storage 15 is configured by, for example, a magnetic disk or a flash memory. The storage 15 stores various programs including an operating system, various data, and the like.

  In the present embodiment, the server 10 may be configured using a plurality of computers each having the hardware configuration described above. For example, the server 10 can be configured by a plurality of server devices.

  The vehicle terminal 32 and the user terminal 34 have a configuration as a general computer, and are configured as, for example, a smartphone, a tablet terminal, a personal computer, and a wearable device. The vehicle terminal 32 is operated by the driver of the vehicle. The user terminal 34 is operated by a user who is a service user.

  In the present embodiment, the vehicle terminal 32 includes various sensors for obtaining vehicle probe information. The probe information is time-series data obtained by a sensor or the like, and includes, for example, a position (longitude / latitude), a direction, acceleration, an image, and the like, and these pieces of information are associated with time. The sensors and the like included in the vehicle terminal 32 include a GPS receiver, a direction sensor (such as a geomagnetic sensor), an acceleration sensor, an illuminance sensor, and a camera. Further, the vehicle terminal 32 can be configured to be connected to the CAN of the vehicle. In this case, the probe information includes CAN information (for example, engine speed, fuel injection amount, steering angle, etc.). May be included.

  In the present embodiment, the service providing server 10 can be configured to have a function as a web server and an application server. In this case, a request from a web browser or other application that the vehicle terminal 32 or the user terminal 34 has. In response to this, various processes are executed, and screen data (for example, HTML data) and control data according to the results of the processes are transmitted. The vehicle terminal 32 and the user terminal 34 display a web page or other screen based on the received data.

  Next, functions of the service providing server 10 of this embodiment will be described. FIG. 2 is a block diagram schematically showing the functions of the server 10. As illustrated, the server 10 includes an information storage management unit 40 that stores and manages information, a vehicle travel management unit 42 that manages vehicle travel, and a traffic information management unit 44 that manages traffic information. These functions are realized by the cooperation of hardware such as the CPU 11 and the main memory 12 and various programs and data stored in the storage 15 and the like. For example, the functions are read into the main memory 12. This is realized by the CPU 11 executing instructions included in the program. 2 may be realized by cooperation of the service providing server 10 with the vehicle terminal 32 or the user terminal 34.

  The information storage management unit 40 includes a storage 15 and the like, and stores and manages various information. For example, the information storage management unit 40 stores a travel plan of a vehicle used for the service. The travel plan includes a plurality of stop points. The order of stopping is typically set for the plurality of stop points.

  The vehicle travel management unit 42 executes various processes related to management of vehicle travel. For example, the vehicle travel management unit 42 executes processing for updating a travel plan of the vehicle.

  The traffic information management unit 44 executes various processes related to management of traffic information. In the present embodiment, the traffic information management unit 44 is configured to acquire vehicle probe information and store it in the storage 15 or the like. For example, the traffic information management unit 44 receives probe information transmitted from each of the plurality of vehicle terminals 32 and accumulates the received probe information in the storage 15 or the like in association with the corresponding vehicle terminal 32.

  The traffic information management unit 44 is configured to generate traffic information between two consecutive stop points included in the vehicle travel plan, based on the probe information stored in the storage 15 or the like. For example, the traffic information management unit 44 specifies probe information corresponding to two stop points that are continuous (the order of stopping is around) from the accumulated probe information, and is based on at least a part of the specified probe information. Traffic information between the stop points is generated.

  As described above, the service providing server 10 according to the present embodiment acquires the probe information of the vehicle and accumulates it in the storage 15 or the like, and based on the accumulated probe information, the continuous two included in the travel plan of the vehicle. Since the traffic information between the stop points is generated, the generated traffic information excludes information corresponding to the state where the vehicle is stopped according to the travel plan at the stop point. Thus, the service providing server 10 of the present embodiment ensures the quality of the traffic information obtained from the vehicle probe information.

  In the present embodiment, the traffic information management unit 44 determines the actual arrival and departure times at the stop point included in the travel plan based on the vehicle position included in the probe information, and the determined actual arrival and departure times. On the basis of the traffic information between the stop points. For example, the traffic information management unit 44 determines that the time when the vehicle position included in the probe information has entered the predetermined range from the stop point is the actual arrival time, and the vehicle position leaves the predetermined range from the stop point. The determined time is determined as the actual departure time. Such a configuration allows easy determination of actual arrival and departure times based on vehicle position.

  In addition, the traffic information management unit 44 may be configured to determine the actual arrival time at the stop point based on probe information in a range based on the estimated arrival time associated with the stop point. For example, the traffic information management unit 44 is configured to determine the actual arrival time based on the probe information in the temporal range close to the estimated arrival time among the probe information accumulated in the storage 15 or the like. In such a configuration, it is considered that there is a high possibility that the probe information in the range close to the estimated arrival time includes the actual arrival time, so that the probe information can be efficiently analyzed.

  In addition, the traffic information management unit 44 can be configured to determine actual arrival and departure times at the stopping point based on the vehicle speed included in the probe information. For example, the traffic information management unit 44 determines the time when the vehicle position included in the probe information is within a predetermined range from the stop point and the vehicle speed included in the probe information is reduced to 0 (that is, the vehicle is stopped). Time) when the vehicle position included in the probe information is within a predetermined range from the stop point, and the vehicle speed included in the probe information is also increased from zero. (That is, the time when the vehicle starts moving) is determined to be the actual departure time at the stop point. Such a configuration allows easy determination of actual arrival and departure times based on vehicle position and vehicle speed.

  In the present embodiment, the generated traffic information between the stop points may be configured to include the required travel time between the stop points. For example, the traffic information management unit 44 determines the actual arrival and departure times at the stop point based on the probe information, and subtracts the actual departure time at the previous stop point from the actual arrival time at the subsequent stop point. The travel time between the stop points is calculated. In addition to the travel time, the traffic information between the stop points is various information based on the probe information included in the time range from the actual departure time at the previous stop point to the actual arrival time at the subsequent stop point. Can be included.

  Further, the traffic information management unit 44 can be configured to store the generated traffic information between the stop points in the storage 15 or the like. In this case, the vehicle travel management unit 42 is stored in the storage 15 or the like. The vehicle travel plan may be updated based on traffic information between the stop points. For example, the vehicle travel management unit 42 predicts the required travel time between the stop points included in the travel plan based on the travel required time included in the traffic information between the stop points stored in the storage 15 or the like, The travel plan is updated based on the travel required time. In this case, the traffic information management unit 44 is based on a comparison between the predicted value of the required travel time between the stop points included in the travel plan and the actual value of the required travel time included in the generated traffic information between the stop points. , May be configured to determine a predicted quality of travel time. Such a configuration makes it possible to update the travel plan based on the predicted value of the required travel time and to grasp the predicted quality (accuracy) of the required travel time.

  Further, the traffic information management unit 44 can be configured to acquire probe information from a vehicle that is running (running a travel plan). In this case, the vehicle travel management unit 42 is stored in the storage 15 or the like. Based on the traffic information between the current stop points, the arrival time at the next stop point of the traveling vehicle is predicted, and warning information is issued when the predicted arrival time is delayed from the expected arrival time at the next stop point. May be configured to output. The warning information may be transmitted to the vehicle terminal 32 and / or the user terminal 34. In this case, the traffic information management unit 44 may be configured to determine the predicted quality of the required travel time based on the output frequency of the warning information between the stopping points. For example, the traffic information management unit 44 is configured to determine the predicted quality of the required travel time so as to decrease as the number of times the warning information is output between the stop points increases. Such a configuration, for example, lowers the prediction quality in a section where the estimated arrival time is in time (the actual value of the required travel time is smaller than the predicted value), but frequently delayed in the middle. It can be considered as a section.

  In addition, the traffic information management unit 44 generates a learned model for predicting the travel time between arbitrary points by machine learning using the traffic information between stop points stored in the storage 15 or the like as teacher data. In this case, the vehicle travel management unit 42 can be configured to predict the required travel time between the stop points included in the travel plan using the learned model. The learned model is configured as a model including a neural network, for example.

  In addition, the traffic information management unit 44 maintains the learned model when the determined predicted quality is equal to or higher than a predetermined threshold, and stores the learned model in the storage 15 or the like when the determined predicted quality is lower than the predetermined threshold. The learned model can be updated by re-machine learning using the accumulated traffic information between the stop points as teacher data. That is, the traffic information management unit 44 regularly monitors and predicts the predicted quality of the learned model while continuously generating and accumulating traffic information between the stop points based on the probe information, and the predicted quality is equal to or higher than a predetermined threshold value. While the trained model is maintained while the predicted quality falls below a predetermined threshold, the latest traffic information (the traffic information that has not been reflected as teacher data) is used as the teacher data. It may be configured to update the learned model by re-machine learning. Such a configuration makes it possible to manage the update of the learned model based on the predicted quality of the travel time.

  Next, a specific example of the service providing server 10 of this embodiment having such a function will be described. In this specific example, the service providing server 10 has a function for providing a shared taxi service, and manages traffic information in a traveling area of a vehicle used in the shared taxi service.

  FIG. 3-6 illustrates information managed in each table included in the storage 15 of the server 10 in this example. FIG. 3 illustrates information managed in the dispatch request information table. The dispatch request information table manages information related to the dispatch request of the vehicle in the shared taxi service, and identifies the user who made the dispatch request in association with the “request ID” that identifies the individual dispatch request as shown in the figure. “User ID”, “Vehicle allocation date”, “Vehicle ID” that identifies the vehicle assigned to the vehicle allocation request, “Boarding point (longitude / latitude)”, “Boarding time frame”, “Boarding time”, “Boarding” Information such as “standby time”, “alighting point (longitude / latitude)”, “alighting time frame”, “scheduled time for alighting”, “alighting time for alighting” is managed.

  FIG. 4 illustrates information managed in the travel plan information table. The travel plan information table manages information related to the travel plans of each of a plurality of vehicles used in the shared taxi service, and as shown in the figure, identifies “vehicle ID”, “date”, and travel “State type”, “start point (longitude / latitude)”, “end point (longitude / latitude)”, “scheduled start time” in association with the combination of “state ID” that identifies the state of each individual vehicle included in the plan ”,“ Scheduled end time ”,“ request ID ”, and the like are managed. As the status type, a value corresponding to either “movement” or “standby” is set. The start point and end point are set to the start point (start point of movement) and the target point (end point of movement) when the state type is movement, and the same point for both when the state type is standby (Standby point) is set.

  FIG. 5 illustrates information managed in the probe information table. The probe information table manages the probe information of each of a plurality of vehicles, and as shown in the drawing, the “position (longitude / latitude)” is associated with a combination of “vehicle ID” and “date / time” for identifying individual vehicles. , “Speed”, “direction” and other information are managed. In this example, the probe information is transmitted at a predetermined time interval (for example, every 60 seconds) from the vehicle that is traveling (running the travel plan), and the server 10 registers the received probe information in the probe information table. To do.

  FIG. 6 illustrates information managed in the traffic information table. The traffic information table manages the traffic information generated based on the probe information, and as shown in the figure, the “vehicle ID” identifies the corresponding vehicle in association with the “traffic information ID” that identifies individual traffic information. ”,“ Date ”,“ departure point (latitude and longitude) ”,“ target point (latitude and longitude) ”,“ departure time ”,“ arrival time ”,“ travel time ”, and the like are managed. As described above, the traffic information includes the required travel time between two consecutive stop points (departure point and target point).

  Next, processing executed by the service providing server 10 of this example will be described. First, processing according to a vehicle allocation request from a user will be described. FIG. 7 is a flowchart illustrating processing executed by the server 10 in response to a vehicle allocation request from the user. First, as shown in the figure, the server 10 receives a date of dispatch and a boarding / alighting point from the user (step S100). FIG. 8 illustrates a vehicle allocation application screen 50 displayed on the user terminal 34. As shown in the figure, the dispatching application screen 50 displays a destination input area 52 for inputting a destination (alighting point), a boarding place input area 54 for inputting a boarding place (boarding point), and a dispatch date. It has a dispatch date input area 56 for inputting, and a continue button 58 displayed as “next”. The destination input area 52 and the boarding place input area 54 are configured so that a specific point (longitude / latitude) on the map can be input with a search using keywords such as an address and a facility name. In addition, when inputting a destination and a boarding place, a map may be displayed on a screen and a user may specify a destination and boarding place by selecting the arbitrary points on a map. At this time, when a point other than the road on the map is selected by the user, a point on the road closest to the selected point may be automatically selected. Further, when the boarding place is input via the boarding place input area 54 or the like, the traveling direction of the vehicle at the boarding place (that is, one of both sides of the road) may be specified.

  When the user selects the continue button 58, the date of dispatch and the boarding / alighting point (boarding place and destination) are received by the server 10. A record is generated in the dispatch request information table along with reception of the dispatch date and the boarding / departing point, and the request ID, user ID, dispatch date, boarding point, and unloading point are set.

  Next, the server 10 accepts selection by the user of the waiting time of the vehicle at the boarding location (step S110). FIG. 9 illustrates a standby time selection screen 70 for the user to select a standby time. The screen 70 is overlaid on the screen 50 in accordance with the selection of the continue button 58 on the vehicle allocation application screen 50.

  As shown in FIG. 9, the standby time selection screen 70 is displayed with a first button 72 displayed as “10 minutes”, a second button 74 displayed as “5 minutes”, and “next”. And a continue button 76. The first button 72 is an object for setting 10 minutes as a waiting time, and the second button 74 is an object for setting 5 minutes as a waiting time. The user can select the vehicle standby time at the boarding place by selecting one of the first button 72 and the second button 74 and then selecting the continue button 76.

  When the user selects the continue button 76, the waiting time selected by the user is accepted by the server 10. With the reception of the waiting time, the boarding waiting time in the dispatch request information table is set. In this example, the waiting time at the place of getting off is a predetermined time (for example, 5 minutes) without selection by the user, and this time is set as the waiting time for getting off in the dispatch request information table. .

  Next, the server 10 specifies a vehicle that can be assigned to the current dispatch request (step S115). The allocatable vehicles are identified based on the boarding / exiting points and waiting times in the current dispatch request, and the existing travel plans of each of the plurality of vehicles. A vehicle to which a boarding / exiting point in the vehicle allocation request can be added is specified as an assignable vehicle.

  Here, a specific example of an existing travel plan will be described. FIG. 10 shows a specific example of information managed in the travel plan information table, and FIG. 11 is a diagram for explaining a travel plan corresponding to this specific example. As shown in FIG. 10, this specific example shows a travel plan on June 1, 2017 for a vehicle whose vehicle ID is “001”. The state ID “001” is a state corresponding to the movement from the point P0 (start point) to the point P1 (end point), and the movement start scheduled time is 10:30, and the movement end scheduled time (point The estimated arrival time at P1 is 10:50 (travel time is 20 minutes). The state ID “002” is a state corresponding to the standby at the point P1 (start point and end point), the standby start scheduled time is 10:50, and the standby end scheduled time is 11:10 ( Stop time is 20 minutes). The movement and standby corresponding to these state IDs “001” and “002” are associated with the request ID “001”, and correspond to the movement to the boarding point P1 and the waiting for boarding in the dispatch request corresponding to the request ID. To do.

  Here, as shown in FIG. 11, in the dispatch request with the request ID “001”, the boarding scheduled time at the boarding point P1 is set to 11:00, and the boarding waiting time at the boarding point P1 is 10 minutes. Is set. The travel plan is set so that the scheduled arrival time at the boarding point is a time before the scheduled boarding time. In the example of FIG. 10, the scheduled arrival time (10:50) at the boarding point P1 is set to a time before the scheduled boarding time (11:00). The travel plan is set so that the scheduled departure time (scheduled end time of standby) at the boarding point is a time after the time when the standby time has elapsed from the scheduled boarding time. In the example of FIG. 10, the scheduled departure time (11:10) at the boarding point P1 is set to the same time as the time (11:10) when the waiting time (10 minutes) has elapsed from the scheduled boarding time (11:00). ing.

  The state ID “003” is a state corresponding to the movement from the point P1 (start point) to the point P2 (end point), and the scheduled start time of the movement is 11:10. (Scheduled arrival time at point P2) is 11:40 (required travel time is 30 minutes). The state ID “004” is a state corresponding to standby at the point P2 (start point and end point), the standby start scheduled time is 11:40, and standby standby end time is 12:10 ( Stop time is 30 minutes). The movement and standby corresponding to these state IDs “003” and “004” are associated with the request ID “001”, and correspond to the movement to the drop-off point P2 and the standby for getting off in the dispatch request corresponding to the request ID. To do. As described above, a travel plan for one vehicle is configured by a plurality of states (moving or waiting) that are temporally continuous, and as a result, a plurality of stop points (boarding points) are ordered.

  Here, as shown in FIG. 11, in the dispatch request of the request ID “001”, the scheduled getting-off time at the getting-off point P2 is set to 12:00, and the getting-off waiting time at the getting-off point P2 is 5 minutes. Is set. Similar to the boarding point, the travel plan is set so that the estimated arrival time at the getting-off point is a time before the scheduled getting-off time. In the example of FIG. 10, the estimated arrival time (11:40) at the getting-off point P2 is set to a time before the scheduled getting-off time (12:00). The travel plan is set such that the scheduled departure time (scheduled end time for waiting) at the disembarking point is a time after the time when the waiting time has elapsed from the scheduled getting off time. In the example of FIG. 10, the scheduled departure time (12:10) at the getting-off point P2 is set to a time after the time (12:05) when the waiting time (5 minutes) has elapsed from the scheduled getting-off time (12:00). ing.

  In step S115, it is determined whether or not a boarding / exiting point in the current dispatch request can be added to such an existing travel plan. Specifically, arrival at the boarding / exiting point included in the existing travel plan is determined. A new boarding / exiting point is added in the current dispatch request while the scheduled time is before the scheduled boarding / exiting time and the scheduled departure time at the boarding / exiting point is after the time when the waiting time has elapsed from the boarding / departing time It is determined whether it is possible. At this time, the required travel time between the boarding / exiting points included in the existing travel plan and the newly added boarding / exiting point is predicted, and based on the predicted value of the traveling time, A determination is made as to whether or not to add. The required travel time is predicted using a learned model described later.

  Once the allocatable vehicles are identified in this way, the server 10 presents a plurality of candidates for the boarding time frame, and accepts the user's selection of the time frame (step S120). FIG. 12 illustrates a boarding time frame selection screen 90 for the user to select a boarding time frame. The screen 90 is displayed in place of the screen 70 and the vehicle allocation application screen 50 according to the selection of the continue button 76 on the standby time selection screen 70.

  As shown in FIG. 12, the boarding time frame selection screen 90 includes a first button 92 displayed as “Previous time zone”, a second button 94 displayed as “Next time zone”, and a plurality of time periods. It has a time frame selection area 96 for displaying a selectable frame, and a continue button 98 displayed as “Next”. In addition, the boarding time frame selection screen 90 displays information relating to the dispatch date and the fare received via the dispatch application screen 50. The fare is calculated based on the distance between the boarding point and the getting-off point, for example.

  The time frame selection area 96 displays a plurality of time frames included in a specific time zone (10:00 to 12:00 in the example of FIG. 12). The time slot for displaying the time frame in the time frame selection area 96 is switched by selecting the first button 92 or the second button 94.

  In the time frame selection area 96, time frame candidates having a predetermined length (in this example, 30 minutes) are displayed. In the time frame selection area 96, only the time frame candidates to which the boarding points can be added can be selected in the travel plan of the assignable vehicle specified in step S115, and the time frame candidates from which the boarding points cannot be added are selected. It is configured so that it cannot be selected.

  For example, as illustrated in FIG. 13, when the boarding point PX1 is added to the existing travel plan illustrated in FIG. 11, the corresponding vehicle is between 10: 00-11: 00: 00. If the arrival at PX1 and the waiting time (5 minutes) cannot be ensured, as shown in FIG. 12, candidates 961 corresponding to the time frame of 10: 00-10: 30, and 10: 30-11: 0 Candidate 962 corresponding to the time frame is configured so that it cannot be selected by the user. It should be noted that if a vehicle other than the vehicle corresponding to the existing travel plan illustrated in FIG. 11 arrives at the point PX1 between 10:00 and 11:00 and can secure the standby time, these candidates 961 , 962 can also be selected.

  When the user selects the continue button 98, the boarding time frame selected by the user is received by the server 10. With the reception of the boarding time frame, the vehicle ID and the boarding time frame in the vehicle allocation request information table are set. The vehicle ID is the vehicle ID of the vehicle in the travel plan corresponding to the selected boarding time frame.

  Next, the server 10 presents a plurality of candidates for the time frame of the getting-off time, and accepts selection by the user of the time frame (step S130). FIG. 14 illustrates a getting-off time frame selection screen 100 for the user to select a time frame for getting-off time. The screen 100 is displayed in place of the screen 90 according to the selection of the continue button 98 on the boarding time frame selection screen 90.

  As shown in FIG. 14, the getting-off time frame selection screen 100 is similar to the boarding time frame selection screen 90 illustrated in FIG. 12, and includes a first button 102 displaying “previous time zone” and “next time”. A second button 104 displaying “band”, a time frame selection area 106 displaying a plurality of time frames in a selectable manner, and a confirmation button 108 displaying “confirmed”. Display information about. The time frame selection area 106 displays a plurality of time frames included in a specific time slot (11:00 to 13:00 in the example of FIG. 14), and the time slot for displaying the time slot in the time frame selection area 106 Is switched by selection of the first button 102 or the second button 104.

  In the time frame selection area 106, time frame candidates having a predetermined length (in this example, 30 minutes) are displayed. In the time frame selection area 106, in the travel plan corresponding to the time frame of the boarding time selected via the boarding time frame selection screen 90, only time frame candidates that can be added to the boarding point can be selected. It is configured so that candidates for time frames that cannot be added cannot be selected.

  For example, as illustrated in FIG. 13, when the drop-off point PX <b> 2 is added to the existing travel plan illustrated in FIG. 11, the corresponding vehicle gets off between 11:00 and 12:00. When the arrival at the point PX2 and the waiting time (5 minutes) cannot be secured, as shown in FIG. 14, candidates 1061 corresponding to the time frame of 11: 00-11: 30 and 11: 30-12: 0 The candidate 1062 corresponding to the time frame is configured so as not to be selected by the user.

  When the user selects the confirm button 108, the getting-off time frame selected by the user is received by the server 10. With the reception of the getting-off time frame, the getting-off time frame in the dispatch request information table is set.

  Next, the server 10 sets the getting-on / off schedule time and updates the travel plan (step S140). Specifically, the scheduled boarding time is set so as to be included in the time frame selected via the boarding time frame selection screen 90, and is included in the time frame selected via the getting-off time frame selection screen 100. Is set to the scheduled departure time, and the boarding / exiting point in the current dispatch request is added to the corresponding vehicle travel plan. In the updated travel plan, the scheduled arrival time at each boarding point is before the scheduled boarding time, and the scheduled departure time at each boarding point is after the time when the waiting time has elapsed from the scheduled boarding time Is maintained. The required travel time between each getting-on / off point is predicted using a learned model described later. Further, the updated travel plan is provided to the vehicle terminal 32 of the driver of the vehicle.

  FIG. 15 shows a specific example of information managed in the updated travel plan information table, and FIG. 16 is a diagram for explaining a travel plan corresponding to the specific example of FIG. As shown in FIGS. 15 and 16, with the addition of the boarding point PX1, the end point in the record of movement of the state ID “003” is changed from P2 to PX1, and the scheduled end time and the request ID correspond to each other. The values have been changed (11:25 and “002”). The state ID “003” after the change is a state corresponding to the movement from the point P1 to the point PX1, and the required movement time is 15 minutes. Further, the estimated arrival time (11:25) at the point PX1 is the time before the scheduled boarding time (11:30).

  In addition, a record with a state ID “005” corresponding to standby at the boarding point PX1 is newly added, its scheduled start time is 11:25, and its scheduled end time is 11:35 (stop time is 10 minutes) ). The scheduled end time (11:35) of standby at the point PX1 is a time after the time (11:35) when the standby time of 5 minutes has elapsed from the scheduled boarding time (11:30) at the point PX1.

  Furthermore, a record with a state ID “006” corresponding to the movement from the point PX1 to the point P2 is newly added, its scheduled start time is 11:35, and its scheduled end time (scheduled arrival time at the point P2) Is 11:55 (travel time required is 20 minutes). Furthermore, the scheduled start time in the standby record with the status ID “004” is changed to 11:55. The estimated arrival time (11:55) at the point P2 is the time before the scheduled departure time (12:00).

  Along with the addition of the alighting point PX2, a record with a state ID “007” corresponding to the movement from the point P2 to the point PX2 is newly added, its scheduled start time is 12:10, and its scheduled end The time (scheduled arrival time at the point PX2) is 12:20 (travel time is 10 minutes). The estimated arrival time (12:20) at the point PX2 is the time before the scheduled departure time (12:25).

  Furthermore, a record with a state ID “008” corresponding to waiting at the getting-off point PX2 is newly added, its scheduled start time is 12:20, its scheduled end time is 12:30 (stop time is 10 minutes) ). The scheduled end time (12:30) of the standby at the point PX2 is a time after the time (12:30) when the standby time of 5 minutes has elapsed from the scheduled departure time (12:25) at the point PX2.

  In the above, the process according to the vehicle allocation request from a user was demonstrated. Next, a process for generating traffic information based on probe information transmitted from each of a plurality of vehicles will be described. FIG. 17 is a flowchart illustrating a process executed by the server 10 when generating traffic information. These processes are executed periodically (for example, at midnight every day). First, as shown in the figure, the server 10 specifies a target vehicle for generating traffic information and a target movement state in the travel plan (steps S200 and S210). The target vehicle is specified in a predetermined order from a plurality of vehicles used in the service. In addition, as the target moving state, a plurality of moving states included in a travel plan for a specific period (for example, the previous day) of the target vehicle are specified in order from the top.

  Once the target movement state is specified, the server 10 next determines the actual departure time at the departure point of the target movement state based on the probe information (step S220). Specifically, the actual departure time includes the vehicle position within a predetermined range (for example, within 50 m) from the departure point based on the accumulated probe information, and the vehicle speed has increased from zero. This is determined by searching for the time. When the head movement state in the travel plan is an object, the server 10 searches the time in order from the head (the earliest time) probe information in the time progress direction.

  Once the actual departure time is determined in this way, the server 10 next determines the actual arrival time at the target point in the target moving state (step S230). FIG. 18 is a diagram for explaining a method of determining an actual arrival time. Specifically, the actual arrival time includes the vehicle position within a predetermined range (for example, within 50 m) from the target point based on the accumulated probe information, and the vehicle speed decreases to zero. It is determined by searching for the set time. The server 10 searches for the time from the probe information corresponding to the range of the next state (usually the standby state) after the target moving state. In the example of FIG. 18, the probe information corresponding to the range of “standby (P1)” that is the next state of “movement (P0 → P1)” that is the target movement state (that is, the scheduled start time of standby at the point P1) The probe information corresponding to the range from the end time to the scheduled end time ((range 1) in FIG. 18) is searched for the actual arrival time. In the example of FIG. 18, the actual arrival time is included in the range 1, but when the actual arrival time is not included in the range 1, next, the range corresponding to the target movement state is corresponded. The actual arrival time is searched for the probe information (in the example of FIG. 18, probe information corresponding to the range from the scheduled departure time at the point P0 to the estimated arrival time at the point P1. (Range 2) in FIG. 18). The If the actual arrival time is not included in this range 2, next, it corresponds to the range of the next (next next) state (usually the moving state) after the target moving state. The actual arrival time is searched for target probe information (in the example of FIG. 18, probe information corresponding to the range from the scheduled departure time at the point P1 to the estimated arrival time at the point PX1 (range 3) in FIG. 18). Is done. Thus, the actual arrival time is preferentially searched from a range close to the estimated arrival time at the target point in the target moving state. In addition, when the actual arrival time is not found for these three ranges, the generation of traffic information corresponding to the target moving state is skipped.

  When the actual arrival time is thus determined, the server 10 next generates traffic information between the departure point and the target point (between the stop points) in the target moving state (step S240). Specifically, a new record is generated in the traffic information table, and corresponding information (date, departure point, target point, departure time, arrival time, travel time) is registered. As the travel time, a value obtained by subtracting the actual departure time from the determined actual arrival time is set.

  If the next movement state exists in the travel plan of the target vehicle (YES in step S250), the process returns to the identification of the target movement state in step S210. In the determination of the actual departure time in the second and subsequent movement states (step S220), the actual departure time is searched from the probe information corresponding to the actual arrival time of the previous movement state in order in the time direction. The When traffic information is generated for all the movement states included in the travel plan for one vehicle (NO in step S250), the process proceeds to generation of traffic information for the next vehicle. This is repeated until traffic information is generated for the vehicle (step S260).

  The process for generating traffic information based on probe information has been described above. Next, a learned model used for predicting the required travel time between arbitrary points will be described. FIG. 19 is a diagram for explaining a learned model. As illustrated, the learned model is generated by machine learning using traffic information generated based on probe information as teacher data, and is configured as a model including a neural network. In this example, when the departure model, the target point, and the dispatch date (month, day of the week, and time zone) are input, the learned model is a predicted value of the required travel time from the input departure point to the target point. Is output. The parameters input to the learned model are not limited to these. For example, the vehicle traveling direction at the departure point or the target point, the weather, the train operation information, and the presence or absence of holidays within a predetermined day before and after are used. You can also In this case, these pieces of information are added to teacher data in machine learning as part of traffic information or as other information.

  FIG. 20 is a flowchart illustrating the processing executed by the server 10 when updating the learned model. These processes are executed every specific period (for example, every week). First, as shown in the figure, the server 10 determines the predicted quality of the required travel time in the travel plan for the target period (step S300). Specifically, for all vehicles, the server 10 estimates the required travel time (in the travel plan) for each movement state included in the travel plan for the target period (for example, a travel plan for one week). Value) and the actual value (value in the traffic information generated based on the probe information). When the difference between the predicted value and the actual value is within a predetermined range (for example, when the actual value is within a range of ± 5% of the predicted value), the movement state is determined as “predictive”. On the other hand, if the difference between the predicted value and the actual value is outside the predetermined range, the movement state is determined as “unexpected”. Then, the ratio of the number of moving states determined to be “predictive” with respect to the number of all moving states (predictive target) is determined as the prediction quality.

  If the determined prediction quality (predictive hit rate) is less than a predetermined threshold (for example, 70%) (YES in step S310), the learned model is updated by re-machine learning (step S310). S320). On the other hand, when the determined prediction quality is equal to or higher than the predetermined threshold (NO in step S310), the learned model is maintained (no operation is performed). Updating the learned model by machine learning again is performed by machine learning in which the latest traffic information is added as teacher data. That is, the traffic information accumulated after the previous update of the learned model is added as new teacher data.

  In the example described above, the server 10 may monitor the delay of the traveling vehicle and transmit warning information corresponding to the delay to the vehicle terminal 32 and / or the user terminal 34. For example, the server 10 periodically predicts the required travel time from the current location of the vehicle (e.g., can be determined from the probe information) to the current target location (next stop location) using the learned model described above. When the arrival time based on the estimated travel time (which can be calculated by adding the predicted value of the travel time to the current time) is delayed from the estimated arrival time, warning information is transmitted. For example, when weather, train operation information, etc. are applied as input parameters for a learned model, the values of these parameters may change between when the travel plan is updated and when it is actually traveled (when the plan is executed). However, the monitoring function described above makes it possible to cope with such a change (for example, depart by raising the waiting time).

  In this case, the output frequency of the warning information in the moving state may be taken into consideration when the above-described prediction quality is determined. For example, the number of times of output of warning information for each moving state can be managed in a travel plan information table or the like. Regardless of the difference between the predicted value and the actual value of the required travel time, the travel state is configured to be determined as “unexpected”, or the number of times the warning information is output per unit time is equal to or greater than a predetermined threshold value. When the ratio of the number of certain moving states is equal to or greater than a predetermined threshold, the trained model may be updated regardless of the predicted hit rate described above.

  Further, the output value of the loss function in the learned model may be used for the prediction quality determination. For example, the server 10 maintains the learned model when the output value of the loss function is less than a predetermined threshold, and updates the learned model when the output value of the loss function is greater than or equal to the predetermined threshold. Configured as follows.

  In the example described above, the server 10 may create a travel route together with the travel plan and provide the travel route to the vehicle terminal 32. In this case, when searching for the travel route, the server 10 predicts the travel time between arbitrary points included in the travel route candidates using the learned model described above, and the predicted value of the travel time The travel route may be determined based on the above. Further, the vehicle terminal 32 may realize a general navigation function for supporting the traveling of the vehicle according to the received traveling route. In this case, the actual arrival time described above may be determined using the navigation function. For example, the destination (target point) is specified using the state in the navigation route of the navigation function, and the specified destination is reached. You may make it determine arrival. When determining the arrival at the destination, in addition to the vehicle position, the traveling direction of the vehicle in the lane (information on the road lane, etc.) can be considered. Further, when following the state in the guidance route, passage of a checkpoint on the route such as a landmark can be considered as an auxiliary. Thus, in the present embodiment, information on external functions such as a navigation function can be used to determine the actual arrival time.

  In the above-described example, the actual arrival time at the target point is determined based on the vehicle position and the vehicle speed included in the probe information. However, when the traveling direction of the vehicle at the getting-on / off point is specified by the user, The actual arrival time can be determined further based on the direction of the vehicle included in the probe information.

  As described above, the service providing server 10 of the present embodiment is not limited to the shared taxi service, and can be configured to provide other services such as an article delivery service. In another specific example of the present embodiment applied to the article delivery service, the travel plan includes an article collection point and a receiving point as stop points in place of the boarding / exiting points. In addition, the article delivery service may be configured as a service for delivering an article via a locker mounted on the vehicle. In this case, the waiting time at the pickup / receiving point is determined by the user operating the locker. It can also be said to be the time for depositing / removing. In addition, information (such as locker lock / release signal) transmitted from the user's terminal or the like may be taken into consideration when specifying the collection point / reception point and determining the actual arrival time at the point.

  The service providing server 10 according to the present embodiment described above acquires the probe information of the vehicle and accumulates it in the storage 15 or the like, and based on the accumulated probe information, the two continuous services included in the travel plan of the vehicle Since traffic information between the stop points (for example, travel time from the departure point to the target point) is generated, the generated traffic information excludes information corresponding to the state where the vehicle is stopped according to the travel plan at the stop point. ing. Thus, the embodiment of the present invention ensures the quality of traffic information obtained from vehicle probe information.

  In other embodiments of the present invention, the vehicle may be configured as an autonomous vehicle. In this case, the autonomous driving vehicle is configured to receive a travel plan including a travel route from the service providing server 10 and autonomously move and stop according to the travel plan.

  The processes and procedures described in the present specification are implemented by software, hardware, or any combination thereof other than those explicitly described. For example, the processes and procedures described in this specification are realized by mounting logic corresponding to the processes and procedures on a medium such as an integrated circuit, a volatile memory, a nonvolatile memory, and a magnetic disk. The processing and procedure described in this specification can be implemented as a computer program corresponding to the processing / procedure and executed by various computers.

  Even if the processes and procedures described herein are described as being performed by a single device, software, component, or module, such processes or procedures may be performed by multiple devices, multiple software, multiple Component and / or multiple modules. Also, the software and hardware elements described herein can be implemented by integrating them into fewer components or by disassembling them into more components.

  In the present specification, when the constituent elements of the invention are described as one or a plurality, or when they are described without being limited to one or a plurality of cases, they should be understood separately in context. The component may be either singular or plural.

DESCRIPTION OF SYMBOLS 10 Service provision server 20 Network 32 Driver terminal 34 User terminal 40 Information storage management part 42 Vehicle travel management part 44 Traffic information management part 50 Vehicle dispatch application screen 70 Standby time selection screen 90 Boarding time frame selection screen 100 Alighting time frame selection screen

Claims (13)

A system for managing traffic information,
A storage device that stores a travel plan of a vehicle including a plurality of stop points, and one or more computer processors,
The one or more computer processors are responsive to execution of readable instructions,
Processing for acquiring probe information of the vehicle and storing it in the storage device;
Based on the probe information stored in the storage device, a process of generating traffic information between two consecutive stop points included in the travel plan is executed.
system. The process of generating the traffic information is based on the vehicle position included in the probe information, determining the actual arrival and departure times at the stop point included in the travel plan, and based on the determined actual arrival and departure times Generating traffic information between the stop points,
The system of claim 1. The stop point is associated with an estimated arrival time,
The process of generating the traffic information includes determining an actual arrival time at the stop based on probe information in a range based on an estimated arrival time associated with the stop.
The system of claim 2. The process of generating the traffic information includes determining actual arrival and departure times at the stop based on the vehicle speed included in the probe information.
The system according to claim 2 or 3. The process of generating the traffic information is based on the time when the vehicle position included in the probe information is within a predetermined range from the stop point and the vehicle speed included in the probe information is reduced to 0 at the stop point. In addition to determining the actual arrival time, the time at which the vehicle position included in the probe information is within a predetermined range from the stop point and the vehicle speed included in the probe information is increased from 0 is the actual time at the stop point. Including determining the departure time of
The system of claim 4. The traffic information between the stop points includes the travel time between the stop points.
The system according to any one of claims 1 to 5. The process of generating the traffic information includes storing the generated traffic information between the stop points in the storage device,
The one or more computer processors further execute a process of updating the travel plan based on traffic information between the stop points stored in the storage device.
The system according to claim 1. The traffic information between the stop points includes the travel time between the stop points,
The process of updating the travel plan predicts the travel time required between the stop points included in the travel plan based on the travel time included in the traffic information between the stop points stored in the storage device. Including
The one or more computer processors further compare the predicted value of the required travel time between the stop points included in the travel plan and the actual value of the required travel time included in the generated traffic information between the stop points. Based on the above, execute the process of determining the predicted quality of the travel time,
The system of claim 7. The stopping point included in the travel plan is associated with an estimated arrival time,
The process of accumulating the probe information includes obtaining probe information from a running vehicle,
The one or more computer processors further perform a process of predicting an arrival time at a next stop point of a running vehicle based on traffic information between the stop points stored in the storage device. A process of outputting warning information when the arrival time is delayed from the estimated arrival time at the next stop point, and
The process of determining the predicted quality includes determining the predicted quality based on an output frequency of the warning information between the stopping points.
The system of claim 8. The one or more computer processors are further learned for predicting the required travel time between arbitrary points by machine learning using traffic information between the stop points stored in the storage device as teacher data. Execute the process to generate the model,
The process of updating the travel plan includes predicting a travel time between stop points included in the travel plan using the generated learned model.
10. A system according to claim 8 or 9. The process of generating the learned model maintains the learned model when the determined prediction quality is equal to or higher than a predetermined threshold, and when the determined prediction quality is lower than the predetermined threshold, Updating the learned model by re-machine learning using the traffic information between the stopping points stored in the storage device as teacher data,
The system of claim 10. A method for managing traffic information, executed by one or more computers accessible to a storage device that stores a travel plan of a vehicle including a plurality of stopping points,
Acquiring probe information of the vehicle and storing it in the storage device;
Generating traffic information between two consecutive stopping points included in the travel plan based on the probe information stored in the storage device,
Method. A program for managing traffic information,
In response to execution on one or more computers accessible to a storage device that stores a vehicle travel plan including a plurality of stop points, the one or more computers are
Processing for acquiring probe information of the vehicle and storing it in the storage device;
Generating traffic information between two consecutive stopping points included in the travel plan based on the probe information stored in the storage device;
program.

Images