Program, information processing method, and information processing device

Abstract

To evaluate quality of a service.SOLUTION: An information processing device 10 includes a storage section 11 and a processing section 12. The storage section 11 stores a service condition being the condition related to provision of a service for operating a vehicle in response to a movement request of each one of a plurality of users. The processing section 12 performs a simulation related to the operation of the vehicle based on the movement request and the service condition. The processing section 12 outputs information expressing quality of the service with respect to the service condition based on the simulation result.SELECTED DRAWING: Figure 1

Description

[Technical Field]

[0001] The present invention relates to a program, an information processing method, and an information processing device. [Background technology]

[0002] Currently, in order to address gaps in public transportation and for elderly welfare, demand-based transportation services are increasingly being provided in place of scheduled route transportation such as route buses. Demand-based transportation is a method of operating transportation in response to users' travel requests. Demand-based transportation can take a variety of forms depending on the combination of operation method, timetable, and departure and arrival points. Shared transportation services are also sometimes provided, where multiple people share a single means of transportation. Services that combine demand-based transportation and shared transportation are called demand-based shared transportation.

[0003] For example, there has been proposed an information processing device that determines whether or not a vehicle can be operated based on the number of customers in a passenger car business that manages operations by reservation. There has also been a proposal for an information system that realizes a mobility service that provides bus service, a demand-responsive, shared vehicle that users can use in exchange for a fee.

[0004] There has also been proposed a vehicle operation system that creates an operation plan based on demands from users and operates vehicles in accordance with the created operation plan. Furthermore, a system has been proposed that manages multiple vehicles for ride-sharing, where multiple passengers share a vehicle, and plans transportation routes. [Prior art documents] [Patent documents]

[0005] [Patent Document 1] Patent Publication No. 2021-107985 [Patent Document 2] Japanese Patent Application Publication No. 2023-131019 [Patent Document 3] Japanese Patent Application Laid-Open No. 2009-294904 [Patent Document 4] US Patent Application Publication No. 2019 / 0311307 Summary of the Invention [Problem to be solved by the invention]

[0006] In order to determine whether to introduce a service to the market, it is possible to optimize the service conditions, which are the conditions for providing the service, and the service quality and revenue in relation to user demand. For example, in a transportation service such as a demand-based shared transportation service, service conditions may be considered, such as the allowable adjustment range of the actual boarding start time relative to the user's desired boarding time, and the required time for transportation from the user's desired departure point to the destination. However, the above-mentioned existing methods cannot evaluate the quality of the service in relation to the service conditions.

[0007] In one aspect, the present invention aims to enable the evaluation of quality of service. [Means for solving the problem]

[0008] In one aspect, a program is provided. The program causes a computer to perform the following processes: the computer accepts service conditions, which are conditions related to the provision of a service for operating a vehicle in response to travel requests from each of a plurality of users; the computer executes a simulation related to the operation of the vehicle based on the travel requests and the service conditions; and the computer outputs information indicating the quality of service for the service conditions based on the results of the simulation.

[0009] In one aspect, there is provided an information processing method executed by a computer, and in another aspect, there is provided an information processing device having a storage unit and a processing unit. [Effects of the Invention]

[0010] In one aspect, an evaluation of the quality of the service can be performed. [Brief explanation of the drawings]

[0011] [Figure 1] FIG. 1 is a diagram illustrating an information processing apparatus according to a first embodiment. [Figure 2] FIG. 10 illustrates an example of an information processing system according to a second embodiment. [Figure 3] FIG. 1 is a diagram illustrating an example of a digital twin. [Figure 4] FIG. 1 illustrates an example of hardware of an information processing device. [Figure 5] FIG. 1 is a diagram illustrating an example of demand-based shared transportation. [Figure 6] FIG. 2 is a diagram illustrating an example of functions of an information processing device. [Figure 7] FIG. 10 is a diagram illustrating an example of a simulation screen. [Figure 8] FIG. 10 is a diagram showing a specific example of a simulation screen. [Figure 9] 10 is a flowchart illustrating an example of a main process of the information processing device. [Figure 10] 10 is a flowchart showing an example of setting operation conditions and service conditions. [Figure 11] FIG. 10 is a diagram showing an example of data used to set operation conditions and service conditions. [Figure 12] 10 is a flowchart illustrating an example of setting a movement request condition. [Figure 13] FIG. 10 is a diagram illustrating an example of data used to set a movement request condition. [Figure 14] FIG. 10 is a diagram illustrating an example of data used to set a movement request condition. [Figure 15] 10 is a flowchart illustrating an example of setting a movement request condition. [Figure 16] FIG. 10 is a diagram illustrating an example of data used to set a movement request condition. [Figure 17] FIG. 10 is a diagram illustrating an example of data used to set a movement request condition. [Figure 18] 10 is a flowchart illustrating an example of generation of a movement request. [Figure 19] FIG. 10 is a diagram illustrating an example of data used to generate a movement request. [Figure 20] FIG. 10 is a diagram illustrating an example of data used to generate a movement request. [Figure 21] 10 is a flowchart illustrating an example of creating an initial schedule. [Figure 22] 10 is a flowchart showing an example (continuation) of initial schedule creation. [Figure 23] 10 is a flowchart showing an example (continuation) of initial schedule creation. [Figure 24] FIG. 10 is a diagram illustrating an example of data used to create an initial schedule. [Figure 25] FIG. 10 is a diagram illustrating an example of data used to create an initial schedule. [Figure 26] 10 is a flowchart showing an example of the progress of a simulation. [Figure 27] FIG. 10 is a diagram showing an example of data used in the progress of a simulation. [Figure 28] FIG. 10 is a diagram showing an example of data used in the progress of a simulation. [Figure 29] 10 is a flowchart illustrating an example of a boarding / exiting process. [Figure 30] FIG. 10 is a diagram illustrating an example of data used in the boarding and disembarking process. [Figure 31] 10 is a flowchart illustrating an example of a sudden request process. [Figure 32] 10 is a flowchart showing an example (continuation) of the unexpected request processing. [Figure 33] 10 is a flowchart showing an example (continuation) of the unexpected request processing. [Figure 34] FIG. 10 is a diagram illustrating an example of data used in a sudden request process. [Figure 35] 10 is a flowchart illustrating an example of request acceptance. [Figure 36] FIG. 10 is a diagram illustrating an example of data used for request acceptance. [Figure 37] 10 is a flowchart illustrating an example of metrics aggregation. [Figure 38]FIG. 10 is a diagram illustrating an example of data used for metrics aggregation. [Figure 39] 10 is a flowchart showing an example of a comparison display of simulation results. [Figure 40] FIG. 10 is a diagram showing an example of data used for displaying a comparison of simulation results. [Figure 41] FIG. 10 is a diagram illustrating an example of display of a simulation result. DETAILED DESCRIPTION OF THE INVENTION

[0012] The present embodiment will be described below with reference to the drawings. [First embodiment] A first embodiment will be described.

[0013] FIG. 1 is a diagram illustrating an information processing apparatus according to a first embodiment. The information processing device 10 supports evaluation of the quality of on-demand services such as on-demand transportation and on-demand shared transportation. The information processing device 10 includes a storage unit 11 and a processing unit 12.

[0014] The storage unit 11 may be a volatile semiconductor memory such as a random access memory (RAM), or a non-volatile storage such as a hard disk drive (HDD) or flash memory. The processing unit 12 is a processor such as a central processing unit (CPU), a graphics processing unit (GPU), or a digital signal processor (DSP). However, the processing unit 12 may also include an application-specific electronic circuit such as an application-specific integrated circuit (ASIC) or a field programmable gate array (FPGA). The processor executes a program stored in a memory such as a RAM (which may be the storage unit 11). A set of multiple processors is sometimes called a "multiprocessor" or simply a "processor."

[0015] The information processing device 10 is also connected to a display device 20. The display device 20 displays an image output by the information processing device 10. The display device 20 may be connected to another information processing device that communicates with the information processing device 10 via a network.

[0016] The memory unit 11 stores service conditions, which are conditions for providing a service to operate a vehicle in response to travel requests from each of multiple users. A vehicle is a means of transportation that travels on roads. A vehicle is, for example, a vehicle that can travel on roads, such as a passenger car or bus. The service conditions include, for example, an adjustment range for the reservation time (e.g., corresponding to the item "reservation time adjustment range" in Figure 1) and an increase range for the ride time. The adjustment range for the reservation time is the maximum time allowed from the user's scheduled departure time (scheduled boarding time) to the actual boarding. The increase range for the ride time is, for example, a multiplier that indicates how many times the ride time can be increased from the shortest route from the user's desired departure point to the destination.

[0017] The processing unit 12 accepts service conditions input by the operator and stores them in the memory unit 11. The processing unit 12 also accepts travel requests and operation conditions set by the operator. A travel request may include the departure point and destination of the service user, the time of reservation request, the scheduled departure time, the number of users, etc. Multiple travel requests are created for multiple users. Operation conditions may include the number of vehicles (number of cars) used for the service and the number of passengers per vehicle, etc. Here, the users and vehicles are virtual users and virtual vehicles for the simulation described below.

[0018] The processing unit 12 executes a simulation of vehicle operation based on the travel request and the service conditions. During the simulation, the processing unit 12 generates travel requests from users of the service at each time during the simulation. The processing unit 12 also generates a travel schedule including the vehicle's travel route based on the set service conditions and travel conditions to match the generated travel requests. The travel schedule may include information such as the vehicle's identification information used in the travel schedule, the departure time from the vehicle's base, the arrival / departure time at the user's boarding point, and the arrival / departure time at the next point. In the case of demand-based shared transportation, one travel schedule may include pickup schedules for multiple users. The processing unit 12 updates the states of the vehicles and users according to the generated travel schedule to simulate the movement of vehicles in the real world. The vehicle state may include the vehicle's travel route, stop locations, current location, mileage, number of passengers on board, etc. The user state may include the departure location, arrival location, scheduled departure time, minimum boarding time, boarding start time, actual boarding time, whether the reservation request (travel request) was accepted, etc.

[0019] Here, when generating a travel request, the processing unit 12 generates travel requests in two types of reservation formats: advance reservations and unexpected reservations. For example, at the beginning of a simulation, the processing unit 12 creates a daily operation schedule using only advance reservations. Each time a sudden reservation occurs during the simulation, the processing unit 12 generates the unexpected reservation, determines whether the current operation schedule can accept the unexpected reservation request, and modifies the operation schedule to satisfy the service conditions.

[0020] The processing unit 12 outputs information representing the quality of service for the service conditions based on the results of the simulation. Specifically, the processing unit 12 obtains the state of each of the multiple vehicles and the state of each of the multiple users as a result of the simulation. The processing unit 12 calculates metrics based on the state of each of the multiple vehicles and the state of each of the multiple users. The processing unit 12 calculates, as vehicle metrics, for example, the boarded mileage, which is the distance traveled with passengers on board, the empty mileage, which is the distance traveled without passengers on board, and the shared ride rate. The processing unit 12 also calculates, as user metrics, for example, the average waiting time, the average rate of increase in boarding time, and the reservation success rate. The waiting time is the difference between the desired departure time and the boarding start time.

[0021] The processing unit 12 calculates the above metrics at regular intervals during the simulation and aggregates (e.g., averages) the metrics over the entire simulation to generate information representing the quality of service. The information representing the quality of service may include, for example, the average values ​​of the above-mentioned shared ride rate, reservation success rate, revenue, average waiting time, and increase rate of ride time.

[0022] In addition to the information representing the quality of service, the processing unit 12 may output revenue information based on the mileage of each vehicle and the mileage of each vehicle. The revenue information may include information such as the cost of operating the vehicle and fare revenue.

[0023] For example, the processing unit 12 provides the operator with a simulation screen 30 as a GUI (Graphical User Interface) that supports the execution of the above-mentioned simulation. The simulation screen 30 is displayed on the display device 20. For example, the simulation screen 30 has an input screen 31, a simulation execution screen 32, and a result output screen 33.

[0024] The input screen 31 is a screen for accepting input of operation conditions, travel requests, and service conditions. The input screen 31 has an operation condition setting field 31a, a travel request setting field 31b, a service condition field 31c, and a simulation start button 31d.

[0025] The operation condition setting field 31a accepts input of operation conditions including the number of vehicles to be simulated and the maximum number of passengers that can ride in one vehicle (vehicle capacity). The travel request setting field 31b accepts input of travel request information. As described above, the travel request information may include directly inputting the user's departure point, destination, time of reservation request, scheduled departure time, number of users, etc. Alternatively, the processing unit 12 may accept input of a condition regarding the number of travel requests generated for each time period (e.g., two in the 7:00 a.m. time slot, six in the 8:00 a.m. time slot, etc.) as travel request information, and automatically generate a travel request according to the condition based on a history of travel requests that have actually occurred in the past.

[0026] The service conditions field 31c accepts input of service conditions including the amount of adjustment for the reservation time and the amount of increase in the boarding time. The simulation start button 31d is a button for instructing the start of a simulation based on the input contents in the operation condition setting field 31a, the travel request setting field 31b, and the service condition field 31c. Note that the input screen 31 does not necessarily have to include the operation condition setting field 31a and the travel request setting field 31b. For example, the information on the operation conditions and travel request may be set in advance in the memory unit 11.

[0027] The simulation execution screen 32 is a screen that displays an image showing the execution status of the simulation. The simulation execution screen 32 has an area map 32a and a time bar 32b. The area map 32a is a map of the target area of ​​the simulation. For example, the processing unit 12 displays the operation route R1 of each vehicle at the time during the simulation indicated by the time bar 32b superimposed on the area map 32a. In this way, the processing unit 12 supports the operator in understanding the operation route R1 at each time.

[0028] The result output screen 33 is a screen that displays images representing the quality and profit of a service. The result output screen 33 has result display fields 33a, 33b, ... for when a simulation is performed under a plurality of service conditions. Each of the result display fields 33a, 33b, ... displays the quality and profit of a service for each service condition. Note that the result display fields 33a, 33b, ... show an example in which the quality and profit of a service are displayed using a radar chart, but the quality and profit of a service may also be displayed using other images, such as a bar graph.

[0029] For example, the operator can have the information processing device 10 execute a simulation using different service conditions (cases a, b, ...) for certain operating conditions and travel request settings, and display the service quality and profit corresponding to each service condition on the result output screen 33. This allows the operator to compare the service quality and profit corresponding to each service condition. Alternatively, the operator can have the information processing device 10 execute a simulation while changing each of the operating conditions, travel requests, and service conditions, and compare the service quality and profit corresponding to each combination of conditions on the result output screen 33.

[0030] As described above, the information processing device 10 accepts service conditions, which are conditions related to the provision of a vehicle operation service in response to travel requests from each of a plurality of users. A simulation related to the operation of the vehicle is executed based on the travel requests and the service conditions. Based on the results of the simulation, information indicating the quality of the service for the service conditions is output. This allows the information processing device 10 to evaluate the quality of the service.

[0031] In order to determine whether to introduce demand-based services such as demand-based transportation and demand-based shared transportation into the market, it is necessary to optimize the conditions of the service to be provided (service conditions), the quality of the service in relation to user demand (service level), and profits. However, existing technologies do not take into consideration the conditions under which the service should be introduced into the market, and it is not possible to evaluate the quality of the service in relation to the conditions.

[0032] Therefore, in one simulation, the information processing device 10 collects metrics for each vehicle and each user, such as the desired boarding time, the actual boarding time, and the number of passengers at each time, when the service is operated for a certain period under certain service and operating conditions. After the simulation is completed, the information processing device 10 calculates an index for evaluating the quality of the service based on the collected metrics. In this way, the information processing device 10 can evaluate the quality of the service according to the service conditions.

[0033] Furthermore, as exemplified by the simulation screen 30, the information processing device 10 displays an execution screen of the simulation and also displays an image corresponding to information indicating the quality of the service, thereby supporting the operator in properly understanding the quality evaluation results. That is, the information processing device 10 can provide prospective service providers with easy-to-understand information for deciding whether or not to introduce a demand-based service, such as demand-based transportation or demand-based shared transportation, into the market. As a result, the information processing device 10 can support prospective service providers in efficiently deciding under what service conditions to actually introduce the service into the market.

[0034] [Second embodiment] Next, a second embodiment will be described. FIG. 2 illustrates an example of an information processing system according to the second embodiment.

[0035] The information processing system of the second embodiment includes a terminal device 60 and an information processing device 100. The terminal device 60 and the information processing device 100 are connected to a network 40. The network 40 is, for example, the Internet or a wide area network (WAN). The information processing device 100 communicates with vehicles 51, 52, 53, ... via the network 40 and can acquire data from the vehicles 51, 52, 53, ....

[0036] The vehicles 51, 52, 53, ... are connected cars having communication devices that communicate with the network 40. The vehicles 51, 52, 53, ... can transmit data such as their current locations and driving routes to the information processing device 100 while traveling on roads.

[0037] The terminal device 60 is a client computer operated by a system user (operator) who uses the information processing device 100. The terminal device 60 communicates with the information processing device 100 via the network 40.

[0038] The information processing device 100 is a device that provides a digital twin. The information processing device 100 may be a server computer. Here, a digital twin is a technology that reproduces an object that actually exists in a physical space in a virtual space.

[0039] FIG. 3 is a diagram illustrating an example of a digital twin. For example, the information processing device 100 reproduces virtual vehicles 71, 72, 73, ... in a virtual space in real time based on data acquired from vehicles 51, 52, 53, ... that actually exist in a physical space, thereby enabling analysis and prediction of traffic conditions, etc. For example, the information processing device 100 simulates traffic dynamics on a digital twin based on instructions from the terminal device 60.

[0040] FIG. 4 is a diagram illustrating an example of hardware of an information processing device. The information processing device 100 has a processor 101, a RAM 102, a HDD 103, a GPU 104, an input interface 105, a medium reader 106, and a communication interface 107. These units of the information processing device 100 are connected to a bus inside the information processing device 100. The processor 101 corresponds to the processing unit 12 of the first embodiment. The RAM 102 or the HDD 103 corresponds to the storage unit 11 of the first embodiment.

[0041] The processor 101 is an arithmetic device that executes program instructions. The processor 101 is, for example, a CPU. The processor 101 loads at least a portion of the program and data stored in the HDD 103 into the RAM 102 and executes the program. The processor 101 may include multiple processor cores. The information processing device 100 may also have multiple processors. The processing described below may be executed in parallel using multiple processors or processor cores. A set of multiple processors may also be called a "multiprocessor" or simply a "processor." A processor may also be called a "processor circuitry."

[0042] The RAM 102 is a volatile semiconductor memory that temporarily stores programs executed by the processor 101 and data used in calculations by the processor 101. Note that the information processing device 100 may include a type of memory other than RAM, or may include multiple memories.

[0043] The HDD 103 is a nonvolatile storage device that stores software programs such as an OS (Operating System), middleware, and application software, as well as data. Note that the information processing device 100 may also include other types of storage devices, such as a flash memory or an SSD (Solid State Drive), or may include multiple nonvolatile storage devices.

[0044] The GPU 104 outputs an image to a display 41 connected to the information processing device 100 in accordance with an instruction from the processor 101. The display 41 may be any type of display, such as a CRT (Cathode Ray Tube) display, a liquid crystal display (LCD: Liquid Crystal Display), a plasma display, or an organic EL (OEL: Organic Electro-Luminescence) display.

[0045] The input interface 105 acquires an input signal from an input device 42 connected to the information processing device 100 and outputs the signal to the processor 101. The input device 42 may be a pointing device such as a mouse, a touch panel, a touch pad, or a trackball, a keyboard, a remote controller, or a button switch. In addition, multiple types of input devices may be connected to the information processing device 100.

[0046] The medium reader 106 is a reading device that reads programs and data recorded on the recording medium 43. For example, a magnetic disk, an optical disk, a magneto-optical disk (MO: Magneto-Optical disk), a semiconductor memory, etc. can be used as the recording medium 43. Magnetic disks include flexible disks (FD: Flexible Disks) and HDDs. Optical disks include compact discs (CDs) and digital versatile discs (DVDs).

[0047] The medium reader 106 copies programs and data read from the recording medium 43 to another recording medium such as the RAM 102 or the HDD 103. The read programs are executed by the processor 101, for example. The recording medium 43 may be a portable recording medium, which may be used to distribute programs and data. The recording medium 43 and the HDD 103 may also be referred to as computer-readable recording media.

[0048] The communication interface 107 is connected to the network 40 and communicates with other information processing devices via the network 40. The communication interface 107 may be a wired communication interface connected to a wired communication device such as a switch or a router, or may be a wireless communication interface connected to a wireless communication device such as a base station or an access point.

[0049] The information processing device 100 provides a function for supporting evaluation of service quality (service level) when introducing on-demand shared transportation in a digital twin. On-demand shared transportation service is a service in which a vehicle operates according to user requests without a set route, and transports a user and another user together in a single vehicle.

[0050] FIG. 5 is a diagram showing an example of demand-based shared transportation. In a demand-based shared transportation service, vehicles are operated according to user requests, and multiple users can share one vehicle. For example, assume that User A's ride reservation (travel request) is "a request to travel from home to the supermarket at 9 o'clock." Also, assume that User B's ride reservation is "a request to travel from home to the hospital at 9 o'clock."

[0051] The travel route 80 indicates the route that the vehicle 51 will take in response to these two requests. First, the vehicle 51 arrives at the home of user A at 9:00. User A gets into the vehicle 51. The vehicle 51 then departs with user A on board for the home of user B and continues traveling.

[0052] Vehicle 51 arrives at user B's house at 9:10. User B gets into vehicle 51. Vehicle 51 departs for the supermarket with users A and B on board and continues driving. At this time, users A and B are on board vehicle 51, resulting in a multiplicative combination.

[0053] Vehicle 51 arrives at the supermarket at 9:30. User A gets off vehicle 51. Vehicle 51 departs for the hospital with user B on board and continues driving. Vehicle 51 arrives at the hospital at 9:45. User B gets off vehicle 51.

[0054] In this way, the vehicle 51 establishes a shared ride for users A and B in accordance with the requests of users A and B, and transports users A and B to their respective destinations. The information processing device 100 performs a simulation to reproduce the operation schedule of each vehicle used in such demand-based shared transportation using a digital twin, and outputs a service level based on the results of the simulation. In the simulation, traffic dynamics that approximate the actual day of the week and time period are reproduced for the day of the week and time period that are the subject of the simulation.

[0055] FIG. 6 is a diagram illustrating an example of functions of the information processing device. The information processing device 100 has an input information receiving unit 110, a travel request generating unit 111, a simulation executing unit 112, a result collecting unit 113, and a display control unit 114. The input information receiving unit 110, the travel request generating unit 111, the simulation executing unit 112, the result collecting unit 113, and the display control unit 114 are realized by the processor 101 executing a program stored in the RAM 102.

[0056] The input information receiving unit 110 receives input information entered by a system user into the terminal device 60. The input information includes operation conditions, service conditions, and travel request conditions used to execute the simulation. The operation conditions include the number of vehicles and the number of passengers per vehicle. The service conditions include the adjustment range of the reservation time (how many minutes the reservation time can be shifted from the scheduled departure time) and the increase range of the travel time (how many times the travel time can be increased from the shortest route). The travel request conditions are conditions for generating a travel request. The travel request includes the departure point, destination, time of reservation request, scheduled departure time, and number of users. The travel request conditions include, for example, the number of travel requests to be generated in each time period. However, the travel request itself may be input as input information instead of the travel request conditions.

[0057] The input information receiving unit 110 supplies information on operation conditions and service conditions to the simulation executing unit 112. The input information receiving unit 110 supplies travel request conditions to the travel request generating unit 111.

[0058] The travel request generation unit 111 generates a user's travel request to be used in the simulation based on the travel request conditions. The travel request generation unit 111 generates the travel request as follows: If there is past data for the travel request, the travel request generation unit 111 uses the past data as the travel request as is. Alternatively, the travel request generation unit 111 may mix past data for the same time period on the same day of the week, and randomly select from there to create an average travel request.

[0059] If there is no past data on travel requests, the travel request generation unit 111 randomly selects a departure point from the residential location, lists potential destinations in daily life, and selects a destination from the potential destinations at a certain rate. The potential destinations include, for example, hospitals, supermarkets, and other commercial facilities. The system user also specifies to the travel request generation unit 111 the selection rates for various categories, such as the hospital category and the commercial facility category. Furthermore, the system user also specifies to the travel request generation unit 111 the expected number of users for each time period.

[0060] The simulation execution unit 112 executes a simulation of demand-based shared transportation based on operation conditions, service conditions, and travel requests. The simulation execution unit 112 includes a vehicle control unit 120 and a state management unit .

[0061] The vehicle control unit 120 creates a vehicle operation schedule and manages the time of the simulation in accordance with the travel requests that occur based on the set service conditions and operation conditions of the demand-based shared transportation.

[0062] The vehicle control unit 120 includes a condition DB (DataBase) 121 , an advance reservation DB 122 , a sudden reservation DB 123 , a simulation time management unit 124 , and a schedule creation unit 125 .

[0063] The condition DB 121 stores the operating conditions and service conditions set by the system user. The advance reservation DB 122 holds advance reservation movement requests generated by the movement request generation unit 111 .

[0064] The unexpected reservation DB 123 holds the unexpected reservation movement requests generated by the movement request generation unit 111 . The simulation time management unit 124 manages the time for the entire simulation.

[0065] The schedule creation unit 125 creates a vehicle operation schedule based on the operation conditions, service conditions, and travel requests, and transmits the schedule to the state management unit 130. For advance reservations, the schedule creation unit 125 schedules vehicle operations for all advance reservations for the target period of the simulation at the beginning of the simulation. For unexpected reservations, the schedule creation unit 125 changes the schedule when the unexpected reservation occurs and notifies the state management unit 130.

[0066] Here, the schedule creation unit 125 creates a schedule as follows. First, the schedule creation unit 125 searches for the shortest route and travel time between the two points, the departure point and destination point, of the relevant travel request. Next, the schedule creation unit 125 searches for the shortest route and travel time between each point when incorporated into a certain point in the current schedule, for all patterns of incorporation. Then, the schedule creation unit 125 selects the schedule that satisfies the service conditions and operation conditions and optimizes the profit and service level, i.e., the best schedule.

[0067] The state management unit 130 updates the states of the vehicle and the user based on instructions from the vehicle control unit 120, and simulates the movement of the vehicle in the real world. The state management unit 130 includes a vehicle state DB 131, a user state DB 132, a vehicle state management unit 133, and a user state management unit 134.

[0068] The vehicle state DB 131 holds the state for each vehicle instance. The user state DB 132 holds the state for each user instance. The vehicle state management unit 133 manages the vehicle state for each vehicle instance. The vehicle state includes information on the driving route, stopping positions, current location, driving distance, and number of passengers. An instance is a unit of data that manages one vehicle or one user in the simulation.

[0069] The user state management unit 134 manages the user state for each user instance. The user state includes information such as the departure location, arrival location, scheduled departure time, minimum boarding time, boarding start time, actual boarding time, and whether the reservation request has been accepted.

[0070] The result collection unit 113 collects the results of the simulation performed by the simulation execution unit 112. The result collection unit 113 includes a metrics collection unit 140, a result calculation unit 150, and a result storage DB160.

[0071] The metrics collection unit 140 collects metrics and includes a vehicle metrics collection unit 141 and a user metrics collection unit 142. The vehicle metrics collection unit 141 collects vehicle-related metrics, including travel distance (ridden travel distance, empty travel distance) and shared ride ratio.

[0072] The user metrics collection unit 142 collects metrics related to users, including waiting time (the difference between the scheduled departure time and the boarding start time), the rate of increase in boarding time, and the rate of reservation success.

[0073] The result calculation unit 150 calculates the service level and revenue from the metrics collected by the metrics collection unit 140. The service level includes the average value of the shared ride rate, the reservation success rate, the average waiting time, and the increase rate of the boarding time. The revenue includes the cost and fare income.

[0074] The result storage DB 160 stores the service level and profit calculated by the result calculation unit 150 for each simulation condition (operation condition and service condition). The display control unit 114 transmits screen information to the terminal device 60 that allows comparison of the service levels and profits calculated for multiple simulation conditions selected by the system user, and displays a screen based on the screen information on the display of the terminal device 60.

[0075] The condition DB 121 , the advance reservation DB 122 , the unexpected reservation DB 123 , the vehicle state DB 131 , the user state DB 132 , and the result storage DB 160 are held in a storage unit realized by the storage areas of the RAM 102 and the HDD 103 .

[0076] Here, the display control unit 114 provides the terminal device 60 with the following GUI. FIG. 7 is a diagram showing an example of a simulation screen. The simulation screen 200 is a GUI provided to the terminal device 60 by the display control unit 114. The simulation screen 200 has a simulation condition input screen 210, a simulation execution display screen 220, and an evaluation index display screen 230.

[0077] The simulation condition input screen 210 is a screen that accepts input of travel requests, service conditions, and operation conditions by the system user. The simulation execution display screen 220 is a screen that displays the movements of vehicles and people as the simulation progresses.

[0078] The evaluation index display screen 230 is a screen that displays evaluation indexes such as revenue and service level for each simulation condition, making them comparable. The simulation screen 200 may be displayed on the display 41. In this case, the system user can use the information processing device 100 by inputting information to the simulation screen 200 using the input device 42.

[0079] FIG. 8 is a diagram showing a specific example of the simulation screen. The simulation condition input screen 210 has an input field 211 and a simulation start button 212 .

[0080] The input field 211 is an input form that accepts input of operation conditions, travel requests, service conditions, etc. For example, the input field 211 includes a parameter input field, an environment setting field, and a past data selection field. The parameter input field accepts input of operation conditions such as the number of vehicles and the number of passengers that can be accommodated. The environment setting field and past data selection field accept input of travel request conditions. The environment setting field accepts input of the number of users for each time period. The past data selection field accepts selection of which day of the week to use as past data for the travel request. Note that in Figure 8, the input field that accepts input of service conditions is not shown.

[0081] The simulation start button 212 is a button for instructing the start of a simulation based on the input content in the input field 211 . The simulation execution display screen 220 includes an area map 221 and a time bar 222 .

[0082] The area map 221 represents a map of the area (region) to be simulated, although detailed depiction of the area map 221 is omitted in FIG. The time bar 222 displays the entire period of the simulation (7:00 to 20:00 in the example of FIG. 8) and the time corresponding to the travel route displayed on the area map 221 (10:23 in the example of FIG. 8).

[0083] The area map 221 is superimposed with an operation route 223 of each vehicle corresponding to the time indicated by a time bar 222. On the operation route 223, for example, an icon 224 indicating the departure point of each vehicle, an icon 225 indicating the planned boarding location of the user, and an icon 226 indicating the destination of each vehicle are displayed.

[0084] The evaluation index display screen 230 is a screen that displays images representing service levels and revenues. The evaluation index display screen 230 has a result display field 231 for each of a plurality of simulation conditions. The result display field 231 displays the service level and revenues for each simulation condition. Note that, although the result display field 231 shows an example in which the service quality and revenues are displayed using a radar chart, the service quality and revenues may also be displayed using other images, such as bar graphs.

[0085] Next, the processing procedure executed by the information processing device 100 will be described. FIG. 9 is a flowchart illustrating an example of main processing of the information processing device. (S10) The input information receiving unit 110 executes the operation condition / service condition setting subprocess. The input information receiving unit 110 accepts input of operation conditions (operation time, number of vehicles, number of passengers, map data, service area, etc.) and service conditions (reservation time adjustment range, boarding time increase range, etc.) by the system user, and sets them in the simulation executing unit 112. The operation condition / service condition setting subprocess will be described in detail later.

[0086] (S11) The movement request generation unit 111 determines whether or not there is past data for the movement request. If there is no past data for the movement request, the process proceeds to step S12. If there is past data for the movement request, the process proceeds to step S13. For example, whether or not there is past data for the movement request may be specified in advance to the movement request generation unit 111 by the system user.

[0087] (S12) The movement request generation unit 111 executes a movement request condition setting sub-process (without past data). Then, the process proceeds to step S14. The movement request condition setting sub-process (without past data) will be described in detail later.

[0088] (S13) The movement request generation unit 111 executes a movement request condition setting sub-process (with past data). The movement request condition setting sub-process (with past data) will be described in detail later. (S14) The simulation execution unit 112 starts a simulation based on the operation conditions, service conditions, and travel requests.

[0089] (S15) The travel request generation unit 111 executes a travel request generation subprocess. The travel request generation unit 111 generates a travel request (scheduled departure time, departure point, arrival point, reservation type, etc.) to be generated within the simulation based on the set travel request conditions. The travel request generation unit 111 sends information about the generated travel request to each instance (user A, user B, ...) of the user state management unit 134 and the user metrics collection unit 142. The travel request generation unit 111 sends only travel requests whose reservation type is advance reservation to the advance reservation DB 122. Details of the travel request generation subprocess will be described later.

[0090] (S16) The schedule creation unit 125 executes an initial schedule creation subprocess. The schedule creation unit 125 references the information on the operation conditions and service conditions in the condition DB 121 and schedules all reservations in the advance reservation DB 122. The schedule creation unit 125 transmits the created schedule to each instance (user A, user B, ...) of the user state management unit 134 and each instance (vehicle A, vehicle B, ...) of the vehicle state management unit 133. Details of the initial schedule creation subprocess will be described later.

[0091] (S17) The simulation execution unit 112 executes the simulation progress sub-process. The simulation execution unit 112 progresses the simulation, updates the state, and collects metrics. The simulation progress sub-process will be described in detail later.

[0092] (S18) The result collection unit 113 executes a metrics aggregation subprocess. After the simulation is completed, the result collection unit 113 calculates metrics throughout the entire simulation from the metrics collected at regular time intervals during the simulation. The metrics aggregation subprocess will be described in detail later.

[0093] (S19) The display control unit 114 executes a simulation result comparison and display sub-process. The simulation result comparison and display sub-process will be described in detail later. Then, the main processing of the information processing device 100 ends.

[0094] In step S18, the metrics are calculated as follows: Revenue is calculated from the time, boarding status, and location information in the vehicle's metrics. Shared ride rate is the rate at which shared rides are established, and is calculated from the time, number of passengers, and location information in the vehicle's metrics. Reservation establishment rate is calculated from whether or not a reservation request can be accepted in the user's metrics. The deviation from the reservation time is calculated from the difference between the scheduled departure time and the boarding start time in the user's metrics. The rate of increase in boarding time is calculated from the shortest boarding time and the actual boarding time (the time interval between the boarding start time and the disembarking time) in the user's metrics. The shortest boarding time is the boarding time using the shortest route.

[0095] FIG. 10 is a flowchart showing an example of setting operation conditions and service conditions. The operation conditions / service conditions setting subprocess corresponds to step S10. (S20) The input information receiving unit 110 registers the operation conditions input by the system user in the condition DB 121.

[0096] (S21) The input information receiving unit 110 registers the service conditions input by the system user in the condition DB 121. Then, the operation condition / service condition setting sub-process ends.

[0097] FIG. 11 is a diagram showing an example of data used to set operation conditions and service conditions. 11A shows data 301, which is an example of data registered in step S20. The data 301 includes the number of vehicles, the number of passengers allowed, and business hours (7:00-21:00).

[0098] 11(B) shows data 302, which is an example of data registered in step S21. The data 302 includes the adjustment range of the reservation time and the increase range of the boarding time. FIG. 12 is a flowchart showing an example of setting a movement request condition.

[0099] The movement request condition setting sub-process in Fig. 12 is a case where there is no past data. The movement request condition setting sub-process (without past data) corresponds to step S12. (S30) The travel request generation unit 111 registers the travel request type and the occurrence rate of the destination input by the system user in the travel request condition DB. Here, the travel request condition DB is a DB that holds information on the travel request conditions used by the travel request generation unit 111.

[0100] (S31) The travel request generation unit 111 registers the conditions of a travel request for demand-based shared transportation in the travel request condition DB. (S32) The travel request generation unit 111 sets a residence area / destination list.

[0101] (S33) The travel request generation unit 111 extracts one location each from the residence area list and the destination list, and comprehensively generates travel requests in which each location becomes a departure point and a destination point. (S34) The movement request generation unit 111 registers the created movement request in the movement request DB. Here, the movement request DB is a DB that holds information on movement requests used by the movement request generation unit 111.

[0102] (S35) When the movement request generation unit 111 has created a comprehensive set of movement requests, it ends the repetition. Then, the movement request condition setting sub-process (without past data) ends. FIG. 13 is a diagram showing an example of data used to set a movement request condition.

[0103] 13(A) shows data 311, which is an example of data registered in step S30. Data 311 includes a travel request type and a travel request occurrence rate as travel request conditions. The travel request type is set to "no past data." The occurrence rate is set to the rate at which travel requests occur for "hospitals," "commercial facilities," and "other" facilities.

[0104] 13(B) shows data 312, which is an example of data registered in step S31. Data 312 includes the distribution of the number of users by time period and the day of the week as conditions for the travel request. The distribution of the number of users by time period is set with the number of users of the service in each time period, such as 7:00, 8:00, etc. The day of the week on which the service is expected to be operated is set.

[0105] FIG. 14 is a diagram showing an example of data used to set a movement request condition. 14(A) shows data 313, which is an example of data set in step S32. The coordinate range of the residential area and the coordinates of destination candidates such as hospitals, commercial facilities, and schools are set in data 313. The coordinates are represented by a combination of latitude and longitude on area map 221.

[0106] 14(B) shows data 314, which is an example of data registered in step S34. The coordinates of the departure point, the coordinates of the arrival point, and the destination type are set as the contents of the travel request in data 314. The destination type is set to the type of destination, such as "hospital" or "commercial facility."

[0107] FIG. 15 is a flowchart showing an example of setting a movement request condition. The movement request condition setting sub-process in Fig. 15 is a case where past data is present. The movement request condition setting sub-process (with past data) corresponds to step S13.

[0108] (S40) The travel request generation unit 111 registers the conditions of the travel request for demand-based shared transportation in the travel request condition DB. (S41) The movement request generation unit 111 acquires past movement request data from a movement request DB that stores past movement requests.

[0109] (S42) The movement request generation unit 111 determines whether or not to use the past movement request data as is as a movement request. If the past movement request data is to be used as is as a movement request, the process proceeds to step S43. If the past movement request data is not to be used as is, the process proceeds to step S44.

[0110] (S43) The movement request generation unit 111 registers the past movement request data in the movement request DB. Then, the process proceeds to step S47. (S44) The travel request generation unit 111 classifies the acquired past travel request data by day of the week and by time period.

[0111] (S45) The movement request generation unit 111 registers the classified movement request data in the movement request DB. (S46) The travel request generation unit 111 ends the repetition when all past travel request data has been classified and registered by day of the week and time period.

[0112] (S47) The movement request generation unit 111 registers the type of movement request in the movement request condition DB. Then, the movement request condition setting sub-process (with past data) ends. FIG. 16 is a diagram showing an example of data used to set a movement request condition.

[0113] 16(A) shows data 321, which is an example of data registered in step S40. Data 321 includes the distribution of the number of users by time period and the day of the week as conditions for the travel request. The distribution of the number of users by time period is set with the number of users of the service in each time period, such as 7:00, 8:00, etc. The day of the week on which the service is expected to be operated is set.

[0114] 16B shows data 322, which is an example of data acquired in step S41. The data 322 includes the coordinates of the departure point, the coordinates of the arrival point, the date, the day of the week, and the departure time as the contents of the travel request.

[0115] FIG. 17 is a diagram showing an example of data used to set a movement request condition. 17(A) shows data 323, which is an example of data registered in step S45. The coordinates of the departure point, the coordinates of the arrival point, and the departure time are set as the contents of the travel request in data 323. The contents of the travel request are categorized by day of the week and by time period, such as 7:00 a.m. on Monday.

[0116] 17B shows data 324, which is an example of data registered in step S47. In data 324, "past data available" is set as the transfer request type in the contents of the transfer request.

[0117] FIG. 18 is a flowchart showing an example of generating a movement request. The movement request generation subprocess corresponds to step S15. (S50) The movement request generation unit 111 acquires movement request conditions from the movement request condition DB.

[0118] (S51) The movement request generation unit 111 repeats the generation of the following movement request until the movement request conditions are satisfied. (S52) The movement request generation unit 111 acquires a movement request that matches the movement request conditions from the movement request DB and generates a movement request. At this time, the movement request generation unit 111 randomly sets an advance reservation or a sudden reservation for the movement request.

[0119] (S53) The travel request generation unit 111 determines whether the created travel request is an advance reservation. If it is an advance reservation, the process proceeds to step S54. If it is not an advance reservation, that is, if it is a sudden reservation, the process proceeds to step S55.

[0120] (S54) The travel request generator 111 registers the created travel request in the advance reservation DB 122. Then, the process proceeds to step S56. (S55) The travel request generation unit 111 registers the created travel request in the unexpected reservation DB 123.

[0121] (S56) The migration request generation unit 111 acquires the user instance from the user state management unit 134. (S57) The travel request generation unit 111 determines whether a user instance of the created travel request already exists. If not, the process proceeds to step S58. If it exists, the process proceeds to step S59. Here, for example, if the travel request created this time is a return travel request for an outward travel request that has already been created for user A, user A is associated with the created travel request in advance at the time of creation. In this case, a user instance of the created travel request already exists.

[0122] (S58) The migration request generation unit 111 creates a new user instance in the user state management unit 134. (S59) The migration request generation unit 111 registers the created migration request in the corresponding instance of the user state management unit 134 and the user metrics collection unit 142.

[0123] (S60) The movement request generation unit 111 ends the repetition when it has generated movement requests until the movement request conditions are satisfied, and the movement request generation sub-process ends. FIG. 19 is a diagram illustrating an example of data used to generate a movement request.

[0124] 19A shows data 331, which is an example of data acquired in step S50. The data 331 includes, as the contents of the travel request conditions, the distribution of the number of users by time period, the day of the week, and the travel request type.

[0125] 19(B) shows data 332, an example of data created in step S52. Data 332 includes the coordinates of the departure point, the coordinates of the arrival point, the scheduled departure time, and the reservation type as the contents of the travel request. The reservation type is set to either "advance," which indicates an advance reservation, or "sudden," which indicates a sudden reservation.

[0126] FIG. 20 is a diagram showing an example of data used to generate a movement request. 20(A) shows data 333, which is an example of data registered in the user state management unit 134 in step S59. The data 333 includes, as a user instance, user identification information, coordinates of the departure point, coordinates of the arrival point, scheduled departure time, and reservation type.

[0127] 20(B) shows data 334, which is an example of data registered in the user metrics collector 142 in step S59. Data 334 includes the user's identification information, scheduled departure time, and reservation type. If the reservation type is "sudden," the reservation request time, which is the time when the user makes a reservation request, may be registered in data 334. In the case of a sudden reservation, the reservation request time may be treated as the user's scheduled departure time.

[0128] FIG. 21 is a flowchart showing an example of creating an initial schedule. The initial schedule creation sub-process corresponds to step S16. (S70) The schedule creation unit 125 acquires all reservation data from the advance reservation DB 122.

[0129] (S71) The schedule creation unit 125 repeatedly performs the following process for all patterns of rearrangement of all reservation data. (S72) The schedule creation unit 125 rearranges the acquired reservation data, thereby creating one rearrangement pattern for all reservation data.

[0130] (S73) The schedule creation unit 125 takes out the rearranged reservation data one by one in order, and repeatedly performs the following process to schedule all the reservation data. (S74) The schedule creation unit 125 acquires all schedules from the “provisional schedule data.”

[0131] (S75) The schedule creation unit 125 determines whether or not there is tentative schedule data. If there is no tentative schedule data, the process proceeds to step S77. If there is tentative schedule data, the process proceeds to step S76.

[0132] (S76) The schedule creation unit 125 determines the schedule position of the retrieved reservation data by referring to the operation conditions and service conditions stored in the condition DB 121. Then, the process proceeds to step S78.

[0133] (S77) The schedule creation unit 125 finalizes the retrieved reservation data. (S78) The schedule creation unit 125 updates the confirmed schedule to “provisional schedule data.” The provisional schedule data is stored in the RAM 102, for example.

[0134] (S79) When all reservation data has been scheduled using one rearrangement pattern, the schedule creation unit 125 ends the repetition, and the process proceeds to step S80.

[0135] FIG. 22 is a flowchart showing an example (continuation) of the initial schedule creation. (S80) The schedule creation unit 125 acquires optimal schedule data. (S81) The schedule creation unit 125 determines whether or not there is optimal schedule data. If there is optimal schedule data, the process proceeds to step S82. If there is no optimal schedule data, the process proceeds to step S83.

[0136] (S82) The schedule creation unit 125 registers the "provisional schedule data" or the "optimal schedule data," whichever has better revenue and service level, as the "optimal schedule data." The optimal schedule data is stored, for example, in RAM 102. The "better revenue and service level" may be determined based on at least one of the revenue and the service level. Then, the process proceeds to step S84. Note that, when there are multiple service level indicators, the schedule creation unit 125 may determine the quality of the service level by comparing index values ​​obtained by comprehensively evaluating the multiple indicators, or may determine the quality of the service level based on a prioritized indicator among the multiple indicators.

[0137] (S83) The schedule creation unit 125 registers the provisional schedule data as the “optimal schedule data.” (S84) The schedule creation unit 125 empties the “provisional schedule data”.

[0138] (S85) The schedule creation unit 125 ends the repetition when all reservation data has been scheduled using all rearrangement patterns. (S86) The schedule creation unit 125 acquires a schedule from the “optimal schedule data.” Then, the process proceeds to step S87.

[0139] FIG. 23 is a flowchart showing an example (continuation) of creating an initial schedule. (S87) The schedule creation unit 125 loops the following process for the number of vehicles included in the schedule.

[0140] (S88) The schedule creation unit 125 creates an instance of the vehicle in the vehicle state management unit 133, and registers the schedule in the created instance. Then, the process proceeds to step S92.

[0141] (S89) The schedule creation unit 125 loops the following process for the number of users present in the schedule for each vehicle. (S90) The schedule creation unit 125 registers the schedule in the instance of the corresponding user in the user state management unit 134.

[0142] (S91) The schedule creation unit 125 ends the repetition when it has completed the loop for the number of users present in the schedule for each vehicle. (S92) The schedule creation unit 125 ends the repetition when it has completed the loop for the number of vehicles present in the schedule, and the initial schedule creation sub-process ends.

[0143] FIG. 24 is a diagram showing an example of data used to create an initial schedule. 24A shows data 341, which is an example of data acquired in step S70. The data 341 includes the coordinates of the departure point, the coordinates of the arrival point, the scheduled departure time, and the reservation type as reservation details.

[0144] FIG. 24(B) shows data 342, which is an example of data processed in step S78. Data 342 includes a timetable ID (identifier), which is identification information for the timetable, the vehicle ID of the vehicle responsible for the timetable, and the timetable. The timetable registers the operating route from the initial departure point of the vehicle in question. The operating route includes the coordinates of the initial departure point, the coordinates of intermediate points such as each user's boarding point, and the coordinates of the final destination. The timetable also includes the time the vehicle will arrive at each point and the time it will depart from each point.

[0145] FIG. 25 is a diagram showing an example of data used to create an initial schedule. 25A shows data 343, which is an example of data registered in steps S82 and S83. The items included in data 343 are the same as those in data 342.

[0146] 25B shows data 344, which is an example of data registered for each vehicle instance in step S88. Data 344 is obtained by extracting the schedule for each vehicle from data 343.

[0147] 25C shows data 345, which is an example of data registered for each user instance in step S90. Data 345 is obtained by extracting schedules for each user from data 343.

[0148] FIG. 26 is a flowchart showing an example of the progress of the simulation. The simulation progress sub-process corresponds to step S17. (S100) The simulation execution unit 112 loops the following processing at regular intervals from the start time to the end time within the simulation.

[0149] (S101) The simulation time management unit 124 notifies the state management unit 130 of the time. (S102) The state management unit 130 loops the following process for the number of vehicle instances.

[0150] (S103) The state management unit 130 acquires the vehicle schedule and the number of passengers from the instance of the vehicle state management unit 133. (S104) The state management unit 130 determines whether or not there are passengers getting on or off the vehicle. If there are passengers getting on or off, the process proceeds to step S105. If there are no passengers getting on or off, the process proceeds to step S106.

[0151] (S105) The state management unit 130 executes a boarding / alighting processing sub-process. The boarding / alighting processing sub-process will be described in detail later. (S106) The state management unit 130 updates the state of the vehicle, the current location information, and the number of passengers in the vehicle state management unit 133.

[0152] (S107) The state management unit 130 registers the current state of the vehicle in question in the vehicle metrics collection unit 141. (S108) When the state management unit 130 has processed all vehicle instances, it ends the repetition of vehicle-related processing.

[0153] (S109) The state management unit 130 acquires the riding state of each user from the user instance in the user state management unit 134. (S110) The state management unit 130 loops the following process for the number of instances of users who are not in a vehicle.

[0154] (S111) The state management unit 130 acquires the reservation request time from the instance of the user who is not in the vehicle in the user state management unit 134. (S112) The state management unit 130 determines whether the current time in the simulation is the reservation request time. If it is the reservation request time, the process proceeds to step S113. If it is not the reservation request time, the process proceeds to step S114.

[0155] (S113) The schedule creation unit 125 executes a sudden request processing sub-process. The sudden request processing sub-process will be described in detail later. (S114) When the state management unit 130 has processed the instances of all users who are not in the vehicle, it ends the repetition of the processing related to the users.

[0156] (S115) The state management unit 130 repeats the above process until the operation in the simulation ends, and ends the repetition when the operation ends, and the simulation progress sub-process ends.

[0157] FIG. 27 is a diagram showing an example of data used in the progress of a simulation. 27A shows data 351, which is an example of data acquired in step S103. The data 351 includes a vehicle ID, a timetable, coordinates of the current location, and the number of passengers.

[0158] 27(B) shows data 352, which is an example of data registered in step S107 in the vehicle metrics collection unit 141. The data 352 includes the vehicle ID, the number of passengers, the current time, and the coordinates of the current location.

[0159] FIG. 28 is a diagram showing an example of data used in the progress of a simulation. 28(A) shows data 353, which is an example of data acquired in step S109. The data 353 includes a user ID and a boarding / alighting status for each user. The boarding / alighting status is set to "riding" or "not riding."

[0160] 28B shows an example of data 354 acquired in step S111. The data 354 includes a user ID and a reservation request time. FIG. 29 is a flowchart showing an example of the boarding and disembarking process.

[0161] The boarding and disembarking processing sub-process corresponds to step S105. (S120) The state management unit 130 changes the number of passengers in the vehicle state for the relevant vehicle. For example, if a new passenger gets on, the number of passengers increases, and if a passenger gets off, the number of passengers decreases.

[0162] (S121) The state management unit 130 loops the following process for the number of passengers getting on and off. (S122) The state management unit 130 registers the boarding and alighting times and riding status in the instance of the user state management unit 134 and the user metrics collection unit 142.

[0163] (S123) The state management unit 130 ends the repetition when all passengers have been processed, and the boarding and alighting processing sub-process ends. FIG. 30 is a diagram showing an example of data used in the boarding and disembarking process.

[0164] FIG. 30(A) shows data 361, which is an example of data registered in the user state management unit 134 in step S122. Here, data 361 is data related to a user who has disembarked. Data 361 includes a user ID, boarding / alighting status, and disembarking time. If the user disembarks, the boarding / alighting status will be "not boarding." Note that for a user who has boarded, the boarding / alighting status will be "boarding," and the boarding time will be registered.

[0165] Figure 30(B) shows data 362, which is an example of data registered in the user metrics collector 142 in step S122. Here, data 362 is data related to users who have disembarked. Data 362 includes the user ID and the time of disembarking. For users who have boarded the vehicle, the boarding / disembarking status will be "boarding" and the boarding time will be registered.

[0166] FIG. 31 is a flowchart illustrating an example of a sudden request process. The unexpected request processing sub-process corresponds to step S113. (S130) The schedule creation unit 125 acquires the unexpected reservation corresponding to the current time of the simulation from the unexpected reservation DB 123.

[0167] (S131) ​​The schedule creation unit 125 empties the “optimal schedule data”. (S132) The schedule creation unit 125 acquires all schedules from the vehicle state management unit 133.

[0168] (S133) The schedule creation unit 125 acquires service conditions from the condition DB 121. (S134) The schedule creation unit 125 loops the following process for each vehicle in the schedule.

[0169] (S135) The schedule creation unit 125 loops the following process for the number of times that a ride point can be added to the trip of the vehicle in question. Here, the trip indicates a timetable included in the schedule.

[0170] (S136) The schedule creation unit 125 determines whether or not the points for the relevant ride satisfy the service conditions. If the service conditions are satisfied, the process proceeds to step S137. If the service conditions are not satisfied, the process proceeds to step S144.

[0171] FIG. 32 is a flowchart showing an example (continuation) of the unexpected request processing. (S137) The schedule creation unit 125 loops the following process for the number of times that a drop-off point can be added to the trip of the vehicle.

[0172] (S138) The schedule creation unit 125 determines whether the corresponding drop-off point satisfies the service conditions. If the service conditions are satisfied, the process proceeds to step S139. If the service conditions are not satisfied, the process proceeds to step S143.

[0173] (S139) The schedule creation unit 125 acquires the “optimal schedule data.” (S140) Schedule creation unit 125 determines whether or not an optimal schedule exists. If optimal schedule data exists, the process proceeds to step S141. If optimal schedule data does not exist, the process proceeds to step S142.

[0174] (S141) The schedule creation unit 125 registers the "newly created schedule data" or the "optimal schedule data," whichever has better profit and service level, as the "optimal schedule data." The "better profit and service level" may be determined based on at least one of the profit and service level. In addition, the "newly created schedule data" is the schedule diagram for the corresponding vehicle to which boarding points and disembarking points for unexpected reservations have been added so as to satisfy the service conditions. Then, the process proceeds to step S143.

[0175] (S142) The schedule creation unit 125 registers the “newly created schedule data” in the “optimal schedule data.” (S143) The schedule creation unit 125 loops for the number of times that a drop-off point can be added to the trip, and then ends the repetition.

[0176] (S144) The schedule creation unit 125 loops the number of times that a ride point can be added to the trip, and then ends the repetition. Then, the process proceeds to step S145.

[0177] FIG. 33 is a flowchart showing an example (continuation) of the unexpected request processing. (S145) The schedule creation unit 125 acquires the “optimal schedule data”.

[0178] (S146) Schedule creation unit 125 determines whether or not there is optimal schedule data. If there is no optimal schedule data, the process proceeds to step S147. If there is optimal schedule data, the process proceeds to step S149.

[0179] (S147) The schedule creation unit 125 determines whether a single trip that satisfies the service conditions can be added to the vehicle. If a single trip can be added, the process proceeds to step S148. If a single trip cannot be added, the process proceeds to step S149.

[0180] (S148) The schedule creation unit 125 creates schedule data including the single trip that was determined to be addable in step S147, and registers the created schedule data in the "optimal schedule data."

[0181] (S149) The schedule creation unit 125 ends the repetition when it has looped the number of times equal to the number of vehicles in the schedule. (S150) The schedule creation unit 125 acquires the “optimal schedule data”.

[0182] (S151) Schedule creation unit 125 determines whether or not there is optimal schedule data. If there is optimal schedule data, the process proceeds to step S152. If there is no optimal schedule data, the process proceeds to step S153.

[0183] (S152) The schedule creation unit 125 executes a request acceptance sub-process, the details of which will be described later. (S153) The schedule creation unit 125 registers whether or not the reservation request can be accepted in the instance of the user state management unit 134 that sent the reservation request (sudden reservation request) and in the user metrics collection unit 142. Then, the sudden request processing sub-process ends.

[0184] FIG. 34 is a diagram illustrating an example of data used in the unexpected request process. 34(A) shows data 371, which is an example of data handled in steps S132, S141, S142, and S148. Data 371 includes a timetable ID, a vehicle ID of the vehicle responsible for the timetable, and the timetable. New boarding points (boarding locations) and disembarking points (disembarking locations) added by unexpected reservations are set in the timetable.

[0185] 34(B) shows data 372, which is an example of data registered in step S153. Data 372 contains the user ID and whether the reservation request can be accepted. If the reservation request can be accepted, that is, if new "optimal schedule data" has been created for the unexpected reservation, "accept" is set as the acceptance status. On the other hand, if the reservation request cannot be accepted, that is, if new "optimal schedule data" has not been created for the unexpected reservation, "not acceptable" is set.

[0186] FIG. 35 is a flowchart showing an example of request acceptance. The request acceptance subprocess corresponds to step S152. (S160) The schedule creation unit 125 loops the following process for each vehicle whose schedule has been changed.

[0187] (S161) The schedule creation unit 125 registers the changed schedule in an instance of the vehicle state management unit 133. (S162) The schedule creation unit 125 loops the following process for each user whose schedule has been changed.

[0188] (S163) The schedule creation unit 125 registers the changed schedule in an instance of the user state management unit 134. (S164) The schedule creation unit 125 ends the repetition after looping the number of times equal to the number of users whose schedules have been changed.

[0189] (S165) The schedule creation unit 125 ends the repetition after looping the number of times equal to the number of vehicles whose schedules have been changed, and the request acceptance sub-process ends. FIG. 36 is a diagram showing an example of data used for request acceptance.

[0190] 36(A) shows data 381, which is an example of data registered in step S161. Data 381 includes a timetable ID, a vehicle ID of the vehicle in charge of the timetable, and the timetable for the relevant vehicle. New boarding points (boarding locations) and disembarking points (disembarking locations) added by unexpected reservations are set in the timetable.

[0191] 36(B) shows data 382, ​​which is an example of data registered in step S163. The data 382 includes the user ID, reservation request time, departure time, and arrival time for the user.

[0192] FIG. 37 is a flowchart showing an example of metrics aggregation. The metrics aggregation subprocess corresponds to step S18. (S170) The result calculation unit 150 acquires all metrics from the user metrics collection unit 142.

[0193] (S171) The result calculation unit 150 acquires all metrics from the vehicle metrics collection unit 141. (S172) The result calculation unit 150 calculates metrics throughout the time that the simulation is executed, and registers the calculation results in the result storage DB 160. Then, the metrics aggregation sub-process ends.

[0194] FIG. 38 is a diagram illustrating an example of data used for metrics aggregation. 38(A) shows data 391, which is an example of user metrics acquired in step S170. The data 391 includes, for each user, a user ID, a reservation request time, a departure time, an arrival time, a shortest travel time, and whether or not the reservation request can be accepted.

[0195] 38(B) shows data 392, which is an example of vehicle metrics acquired in step S171. Data 392 includes a vehicle ID and time-series data for each vehicle. The time-series data includes, for each time during the simulation period, the number of passengers in the vehicle at that time and coordinates representing the location of the vehicle at that time.

[0196] FIG. 39 is a flowchart showing an example of a comparison display of simulation results. The simulation result comparison and display sub-process corresponds to step S19. (S180) Display control unit 114 accepts selection of simulation results to be compared and displayed. For example, on simulation screen 200, the system user can select multiple simulation results to be compared and displayed.

[0197] (S181) The display control unit 114 acquires the selected simulation result from the result storage DB 160. (S182) The display control unit 114 displays the corresponding simulation results on the GUI (simulation screen 200), and the simulation result comparison and display sub-process ends.

[0198] FIG. 40 is a diagram showing an example of data used for displaying a comparison of simulation results. Data 401 is an example of data acquired in step S181. The data 401 includes, for each executed simulation, a simulation ID, simulation conditions, shared ride rate, reservation success rate, revenue, waiting time (average waiting time), and riding time (average increase rate of riding time). The simulation conditions are operation conditions and service conditions. The simulation conditions may include travel request conditions used to generate the travel request. The shared ride rate, reservation success rate, waiting time, and average increase rate of riding time correspond to the service level.

[0199] Based on the data 401, the display control unit 114 displays a result display field 231 for each simulation condition (for example, case a, case b, . . . ) on the evaluation index display screen 230 on the simulation screen 200.

[0200] FIG. 41 is a diagram showing an example of displaying the simulation results. The radar chart 231a shows an example of displaying the service level and revenue. The service level is represented by the shared ride rate, the reservation success rate, the waiting time, and the boarding time. The higher the shared ride rate and the reservation success rate, the better the service level. The shorter the waiting time and the boarding time, the better the service level. Furthermore, revenue may include at least one of costs and fare revenue. Revenue may also be fare revenue minus costs.

[0201] In this way, the display control unit 114 can help the system user to easily understand the service level and profit according to the service conditions by displaying the service level and profit using the radar chart 231a. Also, the display control unit 114 can help the system user to easily compare the service level and profit for each service condition by displaying multiple radar charts side by side for each simulation condition.

[0202] Although radar chart 231a has been used as an example of a method for displaying the simulation results, the display control unit 114 may use other display methods, such as displaying the ride-sharing rate, reservation success rate, waiting time, increase rate of riding time, and revenue using bar graphs.

[0203] According to the information processing device 100 of the second embodiment, the simulation results are stored in the result storage DB 160 for each simulation condition, and a plurality of selected simulation results are extracted from the result storage DB 160 and displayed for comparison. This allows the information processing device 100 to display a plurality of simulation results for comparison.

[0204] Furthermore, the information processing device 100 obtains the revenue and service level when operating a public transportation service for a certain period of time under certain service conditions and operating conditions in a single simulation. Therefore, the information processing device 100 can compare the revenue and service level under a plurality of service conditions by changing the service conditions and repeating the simulation. Furthermore, the information processing device 100 can compare the revenue and service level under a plurality of operating conditions for a certain service condition by changing the operating conditions and repeating the simulation. This allows the information processing device 100 to evaluate transportation services with respect to different service conditions and operating conditions.

[0205] Furthermore, when generating travel requests, the information processing device 100 generates travel requests in two types of reservation formats: advance reservations and unexpected requests without reservations. Specifically, the information processing device 100 first creates a daily schedule using advance reservations only at the beginning of the simulation. Then, each time an unexpected request occurs, the information processing device 100 determines whether the current schedule can accommodate the request and modifies the schedule to optimize the service level. In this way, the information processing device 100 can perform a simulation of demand-based shared transportation that takes unexpected requests without advance reservations into consideration.

[0206] Furthermore, in one simulation, the information processing device 100 collects metrics for each vehicle and each user, such as the desired boarding time (scheduled departure time), actual boarding time, and number of passengers at each time, when a public transport service is operated for a certain period under certain service and operating conditions. After the simulation is completed, the information processing device 100 calculates an index for evaluating the service level based on the collected metrics, and evaluates the service level. This allows the information processing device 100 to evaluate the service level for the service conditions.

[0207] As described above, the information processing device 100 executes the following process, for example. The processor 101 receives service conditions, which are conditions for providing a service of operating a vehicle in response to travel requests from each of a plurality of users. The processor 101 executes a simulation of the operation of the vehicle based on the travel requests and the service conditions. The processor 101 outputs information indicating the quality of the service for the service conditions based on the results of the simulation.

[0208] This allows the information processing device 100 to evaluate the quality (service level) of the service for the service conditions. Note that a vehicle is an example of a vehicle. For example, the process of accepting service conditions may be a process of accepting a plurality of service conditions. The process of executing a simulation may be a process of executing a simulation for each of the plurality of service conditions based on a movement request and each of the plurality of service conditions. The process of outputting information representing the quality of service may be a process of outputting information representing the quality of service for each of the plurality of service conditions to a screen in a comparable form based on a simulation result for each of the plurality of service conditions.

[0209] This allows the information processing device 100 to assist the system user in easily comparing the quality of services for a plurality of service conditions. The process of accepting the service conditions may be a process of accepting the service conditions and operation conditions, which are conditions related to the vehicle. The process of executing the simulation may be a process of executing the simulation based on the travel request, the service conditions, and the operation conditions.

[0210] This allows the information processing device 100 to evaluate the quality of the service for the service conditions and the operation conditions. By taking the operation conditions into consideration in addition to the service conditions, the information processing device 100 can improve the accuracy of the evaluation of the quality of the service.

[0211] Furthermore, the process of executing the simulation may be a process of, when a movement request occurs after the start of the simulation, reflecting the movement request that occurred after the start of the simulation in the simulation and executing the simulation.

[0212] This allows the information processing device 100 to evaluate the quality of the service against the service conditions, taking into account unexpected travel requests. For example, the information processing device 100 can improve the accuracy of the evaluation of the quality of the service by simulating in more detail how users use the service in the real world.

[0213] Furthermore, the process of executing a simulation may be a process of executing a simulation in a digital twin based on a travel request and service conditions. This allows the information processing device 100 to perform a simulation tailored to actual traffic conditions. For example, the information processing device 100 can use a digital twin reproduced using data on vehicles (e.g., vehicles 51, 52, 53, ...) in physical space as a base environment for simulating the operation of vehicles used in the service. Therefore, the information processing device 100 can appropriately perform a simulation of demand-based shared transportation that takes into account actual traffic conditions involving a large number of vehicles. In this way, the information processing device 100 can improve the accuracy of evaluation of service quality by simulating traffic dynamics that may actually occur in more detail.

[0214] Furthermore, the service may be, for example, a demand-based shared transportation service. In this case, the service conditions may include, for example, at least one of a first deviation degree and a second deviation degree. The first deviation degree is, for example, an index indicating the maximum time allowed between the user's scheduled departure time and the time the user boards the vehicle. The second deviation degree is, for example, an index indicating the maximum time allowed between the time required for the shortest route from the user's desired departure point to the destination by vehicle and the user's boarding time from the departure point to the destination by vehicle. The aforementioned adjustment range of the reservation time is an example of the first deviation degree. The increase range of the boarding time is an example of the second deviation degree.

[0215] This allows the information processing device 100 to appropriately evaluate the quality of the demand-based shared transportation service. Furthermore, with regard to demand-based shared transportation services, the quality of service may include at least one of the following: the share rate, the acceptance rate of travel requests, the average waiting time, and the average value of the increase rate of ride time. The share rate is the rate at which a vehicle is shared by two or more users. The acceptance rate of travel requests is the rate at which travel requests can be incorporated into the vehicle's operation schedule out of all travel requests. The acceptance rate of travel requests may also be referred to as the reservation success rate. The average waiting time is the average, across multiple users, of the difference between the user's scheduled departure time specified by the travel request and the boarding start time at which the user boards the vehicle. The average increase rate of ride time is the average, across multiple users, of the increase rate of ride time, calculated as the ratio between the boarding time, which is the time the user boards the vehicle, and the shortest boarding time, which indicates the boarding time via the shortest route.

[0216] This allows the information processing device 100 to appropriately evaluate the quality of the demand-based shared transportation service. The information processing of the first embodiment can be realized by causing the processing unit 12 to execute a program. The information processing of the second embodiment can be realized by causing the processor 101 to execute a program. The program can be recorded on a computer-readable recording medium 43.

[0217] For example, the program can be distributed by distributing recording medium 43 on which the program is recorded. Alternatively, the program may be stored in another computer and distributed via a network. For example, a computer may store (install) a program recorded on recording medium 43 or a program received from another computer in a storage device such as RAM 102 or HDD 103, and then read and execute the program from the storage device. [Explanation of symbols]

[0218] 10. Information processing equipment 11 Storage section 12 Processing section 20 Display device 30 Simulation screen 31 Input screen 31a Operation condition setting field 31b Move request setting field 31c Terms of Service 31d Simulation start button 32 Simulation execution screen 32a Area Map 32b Time Bar 33 Result output screen 33a,33b Result display field R1 Route

Claims

1. On the computer, Accepting service conditions that are conditions regarding the provision of a service of operating a vehicle in response to a travel request from each of the plurality of users; running a simulation of the operation of the vehicle based on the travel request and the service conditions; outputting information representing the quality of the service for the service conditions based on the results of the simulation; A program that executes a process.

2. The receiving process is a process of receiving a plurality of the service conditions, the process to be executed is a process of executing the simulation for each of a plurality of service conditions based on the movement request and each of the plurality of service conditions; the outputting process is a process of outputting the information for each of the plurality of service conditions on a screen in a comparable format based on a simulation result for each of the plurality of service conditions. The program according to claim 1.

3. The receiving process is a process of receiving the service conditions and operation conditions that are conditions related to the vehicle, the process to be executed is a process of executing the simulation based on the travel request, the service conditions, and the operation conditions; The program according to claim 1.

4. the process to be executed is a process of, when the movement request occurs after the start of the simulation, reflecting the movement request that occurred after the start of the simulation in the simulation and executing the simulation. The program according to claim 1.

5. The process of executing the simulation is a process of executing the simulation in a digital twin based on the movement request and the service conditions. The program according to claim 1.

6. The service is a demand-based shared transportation service, The service conditions include at least one of a first deviation degree allowed between the scheduled departure time of the user and the boarding time of the vehicle, and a second deviation degree allowed between the time required for the shortest route by the vehicle from the departure point desired by the user to the destination and the boarding time of the user in the vehicle from the departure point to the destination. The program according to claim 1.

7. The service is a demand-based shared transportation service, The quality of service includes at least one of a shared ride rate, which is the rate at which the vehicle is shared by two or more of the users; an acceptance rate of the travel request; an average waiting time, which is the average of the difference between the scheduled departure time of the user specified by the travel request and the ride start time at which the user boards the vehicle; and an average increase rate of ride time, which is the average of the ratio between the ride time, which is the time at which the user boards the vehicle, and the shortest ride time, which indicates the ride time on the shortest route. The program according to claim 1.

8. The computer Accepting service conditions that are conditions regarding the provision of a service of operating a vehicle in response to a travel request from each of the plurality of users; running a simulation of the operation of the vehicle based on the travel request and the service conditions; outputting information representing the quality of the service for the service conditions based on the results of the simulation; Information processing methods.

9. a storage unit that stores service conditions that are conditions regarding the provision of a service of operating a vehicle in response to travel requests from each of a plurality of users; a processing unit that executes a simulation of the operation of the vehicle based on the travel request and the service conditions, and outputs information representing the quality of the service for the service conditions based on the results of the simulation; An information processing device having the above.

Images