JP2019020787A - System, method and program for managing travel schedule of vehicles - Google Patents

Abstract

To suppress deterioration in prediction accuracy of a vehicle movement required time.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 service providing server 10 is configured to: calculate a prediction value of a movement required time between two points included in a plurality of specific stopping points on the basis of characteristic information on a drive of the specific vehicle; and update a travel schedule of the specific vehicle including the plurality of specific stopping points on the basis of the calculated prediction value of the movement required time.SELECTED DRAWING: Figure 1

Description

  The present invention relates to a system, a method, and a program for managing a traveling schedule of each of a plurality of vehicles.

  2. Description of the Related Art Conventionally, a system for supporting the operation of a demand-type shared taxi that can get on and off at an arbitrary place and a bus has been proposed (for example, see Patent Document 1 below). In such a system, it is required to accurately predict the time required for moving the vehicle so that the user can get on and off as scheduled at the time selected by the user. The required travel time is predicted based on, for example, the travel distance and traffic conditions (congestion prediction information or the like).

JP 2014-135002 A

  However, even if the travel distance, traffic conditions, and the like are the same, the actual travel time may vary depending on the driver driving the vehicle, which may hinder accurate prediction of the travel time. Such accurate prediction of travel time is not limited to demand-type shared taxis and the like, but is also required in goods delivery services that deliver goods at the time selected by the user. Therefore, it is desired to suppress the deterioration of the prediction accuracy of the time required for moving the vehicle in services such as shared taxis and article delivery.

  An embodiment of the present invention has an object of suppressing deterioration in prediction accuracy of a required time for moving a vehicle. 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 a driving schedule of each of a plurality of vehicles, and includes a storage device that stores characteristic information of each of a plurality of drivers, and one or more computer processors. And the one or more computer processors, based on the characteristic information of the driver of the specific vehicle included in the plurality of vehicles, according to execution of the readable instructions, A process of calculating a predicted value of the required travel time between two points included, and a process of updating a travel schedule of the specific vehicle including the specific stop points based on the calculated predicted value of the required travel time And execute.

  A method according to an embodiment of the present invention is executed by one or a plurality of computers accessible to a storage device that stores characteristic information of each of a plurality of drivers, and manages a driving schedule of each of a plurality of vehicles. A method for calculating a predicted value of travel time between two points included in a plurality of specific stopping points based on characteristic information of a driver of the specific vehicle included in the plurality of vehicles; Updating a travel schedule of the specific vehicle including the specific stop points based on the predicted value of the required travel time.

  A program according to an embodiment of the present invention is a program for managing a traveling schedule of each of a plurality of vehicles, and is capable of accessing a storage device that stores characteristic information of each of a plurality of drivers. Depending on the execution on the computer, the one or more computers may move between two points included in a plurality of specific stopping points based on characteristic information of a driver of the specific vehicle included in the plurality of vehicles. A process of calculating a predicted value of the required time and a process of updating a travel schedule of the specific vehicle including the specific stop points based on the calculated predicted value of the required travel time are executed.

  Various embodiments of the present invention suppress the deterioration of the prediction accuracy of the required travel time of the vehicle.

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 driving schedule information table. The figure which shows the specific example of the information managed in a driving schedule information table. The figure for demonstrating the driving schedule corresponding to the specific example of FIG. The figure which illustrates the information managed in a driver information table. The figure which illustrates the information managed in a charge driver information table. The flowchart which illustrates the process which the server 10 performs. The figure which illustrates the vehicle allocation application screen. The figure which illustrates standby time selection screen 70. The figure for demonstrating the learned model for estimating a movement required time. The figure which shows the specific example of a movement required time estimated value management table | surface. The figure for demonstrating a mode that a new boarding / alighting point is added to the driving schedule illustrated in FIG. The figure for demonstrating a mode that a new boarding / alighting point is added to the travel required time estimated value management table illustrated in FIG. The figure which illustrates boarding time frame selection screen 90. The figure which illustrates the getting-off time frame selection screen 100.

  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 services using vehicles such as shared taxis and article delivery (including shopping agency). 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 a vehicle driver. The user terminal 34 is operated by a user who is a service user.

  In the present embodiment, the vehicle terminal 32 may be configured to include various sensors for acquiring 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 shown in the figure, the server 10 manages an information storage management unit 40 that stores and manages information, a required travel time prediction unit 42 that predicts a required travel time between two points, and a traveling schedule of each of a plurality of vehicles. A traveling schedule management unit 44 that manages the vehicle and a driver management unit 46 that manages the driver of the vehicle. 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 characteristic information of each of a plurality of drivers.

  The required travel time prediction unit 42 executes various processes related to the prediction of the required travel time. In the present embodiment, the required travel time prediction unit 42 is configured to calculate a predicted value of the required travel time between two points included in a plurality of specific stop points based on the characteristic information of the driver of the specific vehicle. Has been.

  The travel schedule management unit 44 executes various processes related to the management of the travel schedule. In the present embodiment, the travel schedule management unit 44 updates the travel schedule of the specific vehicle including the specific plurality of stop points based on the predicted travel time calculated by the travel required time prediction unit 42. It is configured as follows. The travel schedule may be managed in the storage 15 or the like and provided to the vehicle terminal 32, for example. Each stop point included in the travel schedule may be associated with arrival and departure scheduled times set based on the predicted value of the required travel time.

  The driver management unit 46 executes various processes related to driver management. For example, the driver management unit 46 executes various processes related to management of driver characteristic information.

  As described above, the service providing server 10 according to the present embodiment calculates the predicted value of the required travel time between two points included in the specific plurality of stop points based on the characteristic information of the driver of the specific vehicle, Based on the calculated predicted travel time, the travel schedule of the specific vehicle including the specific stop points is updated. Therefore, the predicted value of the required travel time is a value that takes into account the characteristic information of the driver, and as a result, the deterioration of the predicted accuracy of the required travel time due to the variation for each driver is suppressed.

  In the present embodiment, information related to the driver in charge of each of the plurality of vehicles can be managed in the storage 15 or the like. For example, in this embodiment, in-charge driver information (also referred to as driver shift information) to which a driver in charge of a combination of a vehicle and a time zone is assigned can be stored in the storage 15 or the like. In this case, the travel required time prediction unit 42 identifies a driver in a specific time zone of a specific vehicle based on the driver information in charge, and moves in the specific time zone based on the characteristic information of the specified driver. It may be configured to calculate a predicted value of the required time. Such a configuration makes it possible to deal with different drivers (driver changes) for each time zone.

  Further, the required travel time prediction unit 42 is included in a plurality of stop points including an existing stop point included in the travel schedule of a specific vehicle and a new stop point specified in response to a vehicle dispatch request from the user. The travel schedule management unit 44 calculates a predicted value of the required travel time between the two points, and the travel schedule management unit 44 calculates the new value at a specific timing (time or time zone) based on the predicted value of the required travel time between the two points. It may be configured to determine whether a particular vehicle can arrive at a particular stop.

  In addition, the travel schedule management unit 44 can be configured to transmit a response according to a determination result of whether or not the vehicle can arrive at the new stop point at a specific timing to the user. For example, the travel schedule management unit 44 transmits to the user terminal 34 whether or not the vehicle can arrive at the timing specified by the user, or transmits the timing determined to be reachable to the user terminal 34 as a candidate for timing at which the vehicle can be dispatched. Configured as follows.

  In the present embodiment, the predicted value of the required travel time between two points can be calculated by applying various algorithms. For example, the travel required time prediction unit 42 is configured to calculate the predicted value of the travel required time between the two points using a learned model for calculating the predicted value of the travel required time between arbitrary points. Can be done. For example, when a parameter including at least a departure point (latitude and longitude), a target point (latitude and longitude), and driver characteristic information is input, the learned model needs to move from the input departure point to the target point. It is configured to output a predicted value of time. The input parameters may further include the month, day of the week, time zone, traveling direction of the vehicle at the departure point or target point, weather, train operation information, and the presence / absence of holidays within a predetermined day before and after. The learned model is generated by machine learning using, for example, actual values of travel time based on vehicle probe information as teacher data, and is configured as a model including a neural network.

  In the present embodiment, the driver characteristic information includes various information related to the driving characteristics of the driver. For example, the characteristic information includes the classification of drivers and numerical values determined based on various information (for example, driving history (years), license type (gold license, etc.), etc.) that can affect driving of the vehicle. Etc. For example, the driver management unit 46 may be configured to calculate driver characteristic information using a learned model for calculating driver characteristic information. The learned model is configured to output driver characteristic information, for example, when various parameters that may affect driving of the vehicle are input. The learned model is generated by machine learning using, for example, actual values of characteristic information based on vehicle probe information and the like as teacher data, and is configured as a model including a neural network.

  Further, the driver characteristic information may be configured as information depending on the geographical area and other parameters such as weather. For example, the characteristic information may include information indicating that the road condition in a specific geographical area is detailed, information indicating that driving tends to be cautious in rainy weather, and the like.

  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 provides a demand-type shared taxi service that allows passengers to get on and off at any place.

  3-4 and 7-8 illustrate information managed in each table of the storage 15 of the server 10 in this example. FIG. 3 illustrates information managed in the dispatch request information table. The vehicle allocation request information table manages information related to vehicle allocation requests from users, and identifies the user who made the vehicle allocation request in association with a “request ID” that identifies individual vehicle allocation requests 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 schedule information table. The travel schedule information table manages information related to the travel schedule of each of a plurality of vehicles used in the shared taxi service, and as shown in the figure, “vehicle ID”, “date”, and individual Information such as “stop point (longitude / latitude)”, “scheduled arrival time”, “scheduled departure time”, “request ID”, etc. is managed in association with a combination of “schedule IDs” for identifying the schedule. Thus, the vehicle travel schedule includes a plurality of stop points associated with arrival and departure scheduled times.

  FIG. 5 shows a specific example of information managed in the travel schedule information table, and FIG. 6 is a diagram for explaining a travel schedule corresponding to this specific example. As shown in FIG. 5, this specific example shows a travel schedule on June 1, 2017 for a vehicle whose vehicle ID is “001”. For example, the schedule ID “01” is a schedule related to the stop point P0, and its scheduled departure time is 10:00. As shown in FIG. 6, the stop point P0 is a point corresponding to the sales office / garage of the vehicle.

  Further, for example, the schedule ID “02” is a schedule related to the stop point P1, and the scheduled arrival time is 10:20. As described above, since the scheduled departure time of the stop point P0 is 10:00, the required travel time from the stop point P0 to the stop point P1 is predicted to be 20 minutes. Further, in the schedule ID “02”, the scheduled departure time of the stop point P1 is 10:40, and the request ID is “001”. As shown in FIG. 6, the request ID “001” is a vehicle allocation request from the user 1, and the stop point P <b> 1 is a boarding point of the user 1 in the vehicle allocation request.

  Further, for example, the schedule ID “04” is a schedule related to the stop point P3, and its scheduled arrival time is 11:20. Since the scheduled departure time of the immediately preceding stop P2 is 11:10 (see the record of schedule ID “03” in FIG. 5), the required travel time from the stop P2 to the stop P3 is predicted to be 10 minutes. Yes. As shown in FIG. 6, the stop point P3 is a stop point for the driver to take a break / change. In this example, a change from the driver A to the driver B is planned at the stop point P3. Information regarding the driver in charge of the vehicle is managed in a driver information table to be described later.

  FIG. 7 illustrates information managed in the driver information table. The driver information table manages information related to the driver of the vehicle, and manages information such as “driving level” in association with “driver ID” for identifying individual drivers as shown in the figure.

  In this example, any one of three values of levels 1 to 3 is set as the driving level, and the traveling time is shorter (the driving level is higher) as the level value is larger. The driving level is automatically set based on the response contents of the driver to the questionnaire. The questionnaire includes, for example, objective contents such as driving history and license type, as well as subjective contents such as driving caution (speed priority / safety priority), use frequency of back roads, and the like. In this example, the driving level is determined using a learned model in which characteristic information is output when a questionnaire response content is input. The learned model includes the response value to the questionnaire and the actual value of the driving level of the driver based on the probe information of the vehicle (for example, the predicted value of the required travel time in the travel schedule and the actual value of the required travel time in the probe information). Is generated by machine learning using teacher data.

  FIG. 8 illustrates information managed in the assigned driver information table. The in-charge driver information table manages information related to drivers in charge of driving each of a plurality of vehicles, and as shown in the figure, a combination of “vehicle ID”, “date” and “time zone” for identifying individual vehicles. Correspondingly, information such as “driver ID” is managed.

  FIG. 9 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. 10 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 location is input via the boarding location input area 54 or the like, the traveling direction of the vehicle at the boarding location (that is, one of the both sides of the road, for example, information on the road lane is included. ) 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. 11 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. 11, the standby time selection screen 70 is displayed with a first button 72 displaying “10 minutes”, a second button 74 displaying “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 identifies vehicles that can be allocated to the current dispatch request (step S112). Specifically, among a plurality of vehicles, one or a plurality of vehicles in charge of a geographical area including the boarding point and / or the getting-off point in the dispatch request are specified as vehicles that can be allocated to the current dispatch request. . The correspondence between the vehicle and the geographical area in charge is managed, for example, in the storage 15 or the like.

  Then, the server 10 calculates a predicted value of the required travel time between the existing stop point included in the identified vehicle travel schedule and the boarding / exiting point in the current dispatch request (step S114). In this example, the predicted value of the required travel time between two points is calculated using a learned model for predicting the required travel time between arbitrary points.

  FIG. 12 is a diagram for explaining a learned model for predicting the required travel time. As shown in the figure, the learned model is generated by machine learning using traffic information generated based on vehicle probe information and the like as teacher data, and is configured as a model including a neural network. In this example, the learned model is input when the departure point (latitude and longitude), the target point (latitude and longitude), the driving level of the driver, and the dispatch date (month, day of the week, and time zone) are input. A predicted value of the required travel time from the departure point to the target point is output. That is, the traffic information (teacher data) includes the departure point, the target point, the driving level of the driver, the dispatch date and time, and the actual value of the required travel time from the departure point to the target point. 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.

  In this example, the predicted value of the required travel time between two points is calculated and managed for each combination of time zone and driving level. FIG. 13 shows a specific example of a travel required time predicted value management table for managing predicted values of travel required time between two points. FIG. 13 shows an example in which the time zone is “10-12 o'clock” and the operation level is “1”, and a similar management table includes a plurality of time zones (for example, all the hours within business hours). Time zone) and a combination of a plurality of driving levels.

  In the predicted travel time management value management table, as shown in the figure, predicted travel time values are set for combinations of departure points and target points. In step S114, the boarding / exiting points in the current dispatch request are added to the travel required time predicted value management table. The management table of FIG. 13 shows a state in which the predicted value of the required travel time between two points in the existing stop points P0 to P5 included in the travel schedule of FIG. 6 is managed. For example, as illustrated in FIG. 14, when the boarding point PX1 and the getting-off point PX2 are newly added to the travel schedule of FIG. 6 in the current dispatch request, the travel time required as illustrated in FIG. 15. Points PX1 and PX2 are added to the starting point and the target point in the predicted value management table, and the predicted value of the travel time calculated using the learned model is set for the newly generated blank cell. Is done. In the travel required time predicted value management table, calculation and setting of predicted values may be omitted for some combinations of departure points and target points. For example, for a combination where the distance between points is remarkably large (greater than a predetermined value), a travel schedule that moves between the points is clearly inefficient and is not considered to be adopted. You may make it abbreviate | omit calculation and the setting of the predicted value of movement required time. In addition, when the arrival and scheduled departure times at existing stop points included in the travel schedule are taken into account, calculation and setting of the predicted value of the required travel time can also be omitted between points where movement in the corresponding time zone is not assumed.

  When the predicted value of the required travel time between the two points is calculated in this way, the server 10 next specifies a time zone in which the arrival time at the boarding / exiting point in the current dispatch request can be reached (step S116). Specifically, the scheduled arrival time at the existing boarding / exiting point included in the travel schedule is before the scheduled boarding / exiting time of the corresponding user (vehicle allocation request), and the scheduled departure time at the boarding / exiting point is from the scheduled boarding / exiting time While maintaining the state after the time when the waiting time has elapsed, the time zone in which the boarding / exiting points in the current dispatch request can be added is specified. At this time, by referring to the responsible driver information table and the driver information table, the driving level of the driver for each time zone is specified, and the estimated travel time management value corresponding to each time zone and the corresponding driving level combination is managed. The value in the table (the predicted value of the required travel time between two points) is used.

  Next, the server 10 presents a plurality of candidates for the time frame of the boarding time, and accepts selection by the user of the time frame (step S120). FIG. 16 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. 16, 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 times. 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. 16). 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 time frame candidates included in the time zone that can arrive at the boarding point specified in step S116 can be selected, and time frame candidates that are not included in the reachable time zone cannot be selected. Configured as follows.

  For example, as illustrated in FIG. 14, when the boarding point PX1 is added to the existing travel schedule illustrated in FIG. 6, the corresponding vehicle is between 10: 00-10: 30. When the arrival at PX1 and the waiting time cannot be ensured, as shown in FIG. 16, the candidate 961 corresponding to the time frame of 10: 00-10: 30 is configured so that it cannot be selected by the user. If a vehicle other than the vehicle corresponding to the existing travel schedule illustrated in FIG. 6 arrives at the point PX1 between 10: 00-10: 30 and can secure the standby time, the candidate 961 is also selected. Selectable.

  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 schedule 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. 17 illustrates the 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. 17, the getting-off time frame selection screen 100 is similar to the boarding time frame selection screen 90 illustrated in FIG. 16, and the 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. 17), 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, only time frame candidates included in the time zone that can arrive at the getting-off point specified in step S116 can be selected, and time frame candidates that are not included in the reachable time zone cannot be selected. Configured as follows.

  For example, as illustrated in FIG. 14, when the getting-off point PX <b> 2 is added to the existing travel schedule illustrated in FIG. 6, the corresponding vehicles are 11: 00-11: 30 and 12: If the arrival time at the drop-off point PX2 and the waiting time cannot be ensured between 30-13: 00, candidates 1061 and 12 corresponding to the time frame of 11: 00-11: 30 are shown in FIG. The candidate 1064 corresponding to the time frame of 3: 30-13: 00 is configured so that it cannot 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 scheduled getting-on / off time and updates the travel schedule (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 schedule. In the updated travel schedule, the estimated arrival time at each boarding / exiting point is before the scheduled getting-on / off time of the corresponding user (request for dispatch), and the scheduled departure time at each boarding / exiting point is the waiting time from the scheduled getting-on / off time The state after the time when has passed is maintained. The updated travel schedule is provided to the vehicle terminal 32 of the driver of the vehicle.

  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 schedule 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 receiving point is for the user to operate the locker to take out the article. It can also be called time.

  The service providing server 10 according to the present embodiment described above predicts the required travel time between two points included in a plurality of specific stopping points based on the characteristic information (for example, driving level) of the driver of the specific vehicle. A value is calculated, and a travel schedule of a specific vehicle including the specific plurality of stop points is updated based on the calculated predicted value of the required travel time. Therefore, the predicted value of the required travel time is a value that takes into account the characteristic information of the driver, and as a result, the deterioration of the predicted accuracy of the required travel time due to the variation for each driver is suppressed.

  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 schedule including a travel route from the service providing server 10 and autonomously move and stop according to the travel schedule. In this case, the characteristic information of the driver includes characteristic information of software for automatic driving in the autonomous driving vehicle. That is, in the embodiment of the present invention, the driver of the vehicle includes software for automatic driving in the autonomous driving vehicle.

  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 Travel time prediction part 44 Travel schedule management part 46 Driver management part 50 Vehicle allocation application screen 70 Standby time selection screen 90 Boarding time frame selection screen 100 Alighting Time frame selection screen

Claims (7)

A system for managing a driving schedule of each of a plurality of vehicles,
A storage device for storing characteristic information of each of the plurality of drivers, and one or a plurality of computer processors,
The one or more computer processors are responsive to execution of readable instructions,
Based on the characteristic information of the driver of a specific vehicle included in the plurality of vehicles, a process of calculating a predicted value of the required travel time between two points included in the specific plurality of stopping points;
A process of updating a travel schedule of the specific vehicle including the specific plurality of stop points based on the calculated estimated value of the required travel time;
system. The storage device stores driver information assigned to a driver in charge of a combination of a vehicle and a time zone,
The process of calculating the predicted value of the required travel time identifies a driver in a specific time zone of the specific vehicle based on the driver information in charge, and determines the specific time zone based on characteristic information of the specified driver. Calculating a predicted value of travel time between the two points in
The system of claim 1. The specific plurality of stop points include an existing stop point included in the travel schedule of the specific vehicle, and a new stop point specified in accordance with a vehicle dispatch request from the user,
The one or more computer processors further execute a process of determining whether or not the specific vehicle can arrive at the new stop point at a specific timing based on a predicted value of the required travel time between the two points. To
The system according to claim 1 or 2. In the process of calculating the predicted value of the required travel time, the predicted value of the required travel time between the two points is calculated using a learned model for calculating the predicted value of the required travel time between arbitrary points. Including that,
The system according to claim 1. The one or more computer processors further execute a process of calculating driver characteristic information using a learned model for calculating driver characteristic information.
The system according to claim 1. A method for managing a running schedule of each of a plurality of vehicles, executed by one or more computers accessible to a storage device storing characteristic information of each of a plurality of drivers,
Calculating a predicted value of travel time between two points included in a plurality of specific stopping points based on characteristic information of a driver of the specific vehicle included in the plurality of vehicles;
Updating a travel schedule of the specific vehicle including the specific plurality of stop points based on the calculated estimated value of the required travel time,
Method. A program for managing the driving schedule of each of a plurality of vehicles,
In response to execution on one or more computers accessible to a storage device that stores characteristic information of each of a plurality of drivers,
Based on the characteristic information of the driver of a specific vehicle included in the plurality of vehicles, a process of calculating a predicted value of the required travel time between two points included in the specific plurality of stopping points;
A process of updating a travel schedule of the specific vehicle including the specific plurality of stop points based on the calculated predicted value of the required travel time;
program.

Images