WO2011007553A1 - 運行実績を活用したオンデマンドバスの運行スケジューリングシステム及びその方法 - Google Patents

運行実績を活用したオンデマンドバスの運行スケジューリングシステム及びその方法 Download PDF

Info

Publication number
WO2011007553A1
WO2011007553A1 PCT/JP2010/004533 JP2010004533W WO2011007553A1 WO 2011007553 A1 WO2011007553 A1 WO 2011007553A1 JP 2010004533 W JP2010004533 W JP 2010004533W WO 2011007553 A1 WO2011007553 A1 WO 2011007553A1
Authority
WO
WIPO (PCT)
Prior art keywords
information
boarding
time
characteristic information
demand bus
Prior art date
Application number
PCT/JP2010/004533
Other languages
English (en)
French (fr)
Inventor
大和裕幸
坪内孝太
Original Assignee
国立大学法人東京大学
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by 国立大学法人東京大学 filed Critical 国立大学法人東京大学
Priority to KR1020127000928A priority Critical patent/KR101742833B1/ko
Publication of WO2011007553A1 publication Critical patent/WO2011007553A1/ja

Links

Images

Classifications

    • G—PHYSICS
    • G08—SIGNALLING
    • G08G—TRAFFIC CONTROL SYSTEMS
    • G08G1/00—Traffic control systems for road vehicles
    • G08G1/123—Traffic control systems for road vehicles indicating the position of vehicles, e.g. scheduled vehicles; Managing passenger vehicles circulating according to a fixed timetable, e.g. buses, trains, trams
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06Q—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
    • G06Q10/00—Administration; Management
    • G06Q10/06—Resources, workflows, human or project management; Enterprise or organisation planning; Enterprise or organisation modelling
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06Q—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
    • G06Q50/00—Information and communication technology [ICT] specially adapted for implementation of business processes of specific business sectors, e.g. utilities or tourism
    • G06Q50/40—Business processes related to the transportation industry

Definitions

  • the present invention relates to an on-demand bus system that operates in response to a request from a user, and more particularly to an operation scheduling system and an operation scheduling method.
  • On-demand buses are being studied to eliminate traffic congestion and save energy in transportation.
  • an on-demand bus system receives a boarding request specifying a boarding position, a destination, a desired boarding time, and the number of passengers from a passenger, an appropriate route to the destination that satisfies the request is determined.
  • the route of on-demand bus described in Patent Document 1 is the boarding point of use requested by all passengers, the destination of passengers, the current position of each of a plurality of buses, the current schedule of each bus It is determined as a function of the route and traffic conditions.
  • each passenger's request (boarding position, destination, desired boarding time) is satisfied by determining the route.
  • the on-demand bus system becomes larger, for example, the operation area expands, the number of operating buses increases, the number of passengers increases, it takes time to determine the route, and there is a time margin before the desired boarding time.
  • there is an operation that secures the time required to determine the route for example, 30 minutes before the desired boarding time or 1 hour before the desired boarding time. Such operation impairs the essential convenience of an on-demand bus.
  • the operation scheduling system extracts the characteristic information about passenger boarding / exiting in advance from the database that stores the operation results related to reservations and results, and the operation results stored in the database, regarding passenger boarding / exiting on-demand buses.
  • the operation scheduling system relates to reservations and actual results relating to passenger boarding / exiting, at least the passenger boarding / departing position, at least one of the boarding / exiting times, and the weather of the date and time when the on-demand bus was operated as a result Contains information.
  • a more desirable operation scheduling system extracts characteristic information from the operation results based on the regularity of at least one of the passenger boarding position and boarding time.
  • a more desirable operation scheduling system is based on the correlation between each information of the passenger's boarding / exiting position, at least one of the boarding / exiting times, and the weather information of the date and time when the on-demand bus was operated as a result. Extract information.
  • the time required for determining the operation schedule can be shortened, or an operation plan with many passengers can be generated.
  • FIG. 1 shows a configuration diagram of the on-demand bus system of the present embodiment.
  • the on-demand system is based on a reservation reception system 2 that receives a request from a user who wishes to board an on-demand bus (hereinafter referred to as a bus) 1 that operates, reservation information from the reservation reception system 2, and the operation results of the bus 1.
  • the operation scheduling system 3 that determines the operation schedule of the bus 1 and the operation information system 4 that collects the operation information of the bus 1 and stores it in the operation database 5 as the operation results are provided.
  • the operation results of the bus 1 used by the operation scheduling system 3 are stored in the operation database 5.
  • the current information on the area where the on-demand bus system is operated is the congestion information (congestion degree) of each road (or road section between intersections).
  • congestion information congestion degree
  • travel time of a road section or a predetermined section weather conditions, and the like are collected and stored in the operation database 5 in association with date / time information (year, month, day, holiday, time, etc.).
  • Figure 1 shows one bus, but the number is determined according to the size of the operating area and the number of customers using the on-demand bus system.
  • the number of buses is based on geographical features such as shopping streets, hospitals, public facilities, and the presence of steep slopes, as well as certain areas within the operation area, between one area and other areas, etc. As determined.
  • a bus that is not assigned to a region may be prepared and temporarily allocated to a region where there are few users who want to board the vehicle in response to a request from the user.
  • the operation scheduling system 3 that determines the operation schedule of the bus so as to satisfy the passenger's desire to board the dispatched one bus will be described in detail.
  • the reservation reception system 2 the operation scheduling system 3, the operation information system 4, and the operation database 5 are shown separately, but they are realized by a single computer having a database system. Alternatively, it may be realized by a distributed system using a plurality of computers according to the load and function of each system.
  • the bus 1 includes a wireless communication device for communication with the operation scheduling system 3 and the operation information system 4, and also includes a GPS (Global Positioning System) device for grasping the position of the bus 1 and the current time. Yes. The position and current time of the bus 1 are transmitted to the operation information system 4 as operation information.
  • GPS Global Positioning System
  • the reservation acceptance system 2 accepts a request from a user who wishes to board by e-mail or telephone.
  • the operator may accept a ride request from the user and input the received content into the reservation reception system 2; however, when the user gets used to (a desired ride position, a desired drop-off position, a desired ride time or a desired get-off time, and If you get used to transmitting the necessary requirements for boarding, such as passengers), automatic reception is possible.
  • e-mails e-mails using a predetermined format are used, or the e-mail text is analyzed and semantically analyzed in the reservation receiving system 2 to extract the desired content as reservation information.
  • the speech recognition apparatus is operated before the mechanism for accepting by e-mail, and the sentence is extracted. The reservation information is extracted from this sentence as in the case of e-mail.
  • FIG. 2 A configuration example of the reservation information table included in the operation database 5 is shown in FIG. 2, and a configuration example of the performance information table is shown in FIG.
  • the reservation information table stores the reservation information received by the reservation receiving system 2 by a program in the operation scheduling system 3. This program is activated by a reception interruption from the reservation reception system 2, stores reservation information in the reservation information table via the operation scheduling system 3, and acquires a response to the received reservation information from the operation scheduling system 3. A response is returned to the user and the process is terminated.
  • the reservation information table has columns for reservation number 50, passenger information 51, reservation information 52, and reservation confirmation flag 53.
  • Reservation information 52 includes the following fields: month 54, day 55, boarding (hope) time 56, boarding (hope) time 57, boarding (hope) position 58, boarding (hope) position, boarding (hope) 60 people
  • the reservation number 52 is used to respond to the user that the reception has been completed, and is used by the operation scheduling system 2 to identify the reservation information 52 to be reflected in the operation schedule. As will be described later, when the operation result is stored in the operation database 5, it is also used to identify which reservation information corresponds to the operation result.
  • the passenger information 51 is a passenger identifier for identifying a passenger (synonymous with a user), for example. Using a passenger identifier as a key, a passenger database storing attribute information such as passenger name, address, and telephone number is searched.
  • the reservation confirmation flag 53 is a flag indicating that the reservation information 52 is reflected in the operation schedule and the confirmed reservation information is returned as a response to the user. In other words, the operation scheduling system 2 indicates that the reservation information whose reservation confirmation flag 53 is ON is reflected in the operation schedule of the bus 1.
  • a blank in the reservation confirmation flag 53 indicates OFF, and * indicates a pending state. The pending state will be described later.
  • Each item of the reservation information 52 will be clarified by an example described later. However, the time in parentheses in the column for the boarding time 56 and-(hyphen) in the column for the boarding time 57 will be described. As requirements necessary for boarding by the reservation reception system 2, the boarding desired position, the boarding desired position, the boarding desired time or the boarding desired time, and the boarding personnel were described. If both the desired boarding time and the desired boarding time are required, there will be a situation where the bus 1 cannot be operated strictly at the desired boarding position and at the desired boarding position. . When the desired boarding time is specified,-(hyphen) is stored in the column for the getting-off time 57.
  • the estimated arrival time of the bus 1 at the boarding (desired) position 58 determined by the operation scheduling system 2 is stored in parentheses in the boarding time 58 field. By including this estimated arrival time in a response sent back to the user as confirmed reservation information, the user can wait for the bus 1 before the estimated arrival time at the desired boarding position.
  • the desired ride time and the desired get-off time have an allowable range of ⁇ 2 minutes, ⁇ 5 minutes, for example. It is operated.
  • reservation information table shown in FIG. 2 shows a state of 10:10 on Sunday, June 21, in order to explain a specific example later.
  • the operation information received from the bus 1 by the operation information system 4 is stored by the operation information system 4 as the contents of the result information table.
  • the operation information from the bus 1 includes not only information related to bus travel (position, speed, etc.) but also boarding / exit information (position, time, etc.) of each passenger.
  • the operation schedule of the bus 1 is determined based on each passenger's boarding / alighting information as a track record, the information relating to the travel of the bus is omitted.
  • the performance information table has columns for reservation number 50, passenger information 51, and performance information 61.
  • the track record information 52 further includes columns such as boarding time 62, boarding time 63, boarding position 64, boarding position 65, number of passengers 66, car number 67, and the like.
  • the reservation number 50 and the passenger information 51 are the same as the reservation number 50 and the passenger information 51 in the reservation information table, and each record in the record information table shows the operation record corresponding to each reservation information 52 in the reservation information table. Store. Therefore, the reservation information and the result information are collectively referred to as an operation result.
  • the reservation information table and the performance information table will be described separately, but the reservation number 50 and the passenger information 51 may be configured as one table.
  • Each item of the record information 61 is clarified by an example described later.
  • the performance information table shown in FIG. 3 shows a state of 10:10 on Sunday, June 21, for the purpose of explaining a specific example later.
  • FIG. 4 shows a configuration example of the characteristic information table included in the operation database 5.
  • the characteristic information table has a characteristic column 70 for storing the characteristics of passengers obtained from the operation results stored in the reservation information table and the result information table, and a column for a reservation number 71 indicating the characteristics.
  • Passenger characteristics are obtained by data mining techniques that look for correlations and regularities (patterns) between items in the operation results (the contents of the reservation information table and the contents of the result information table) and other techniques based on mathematical programming .
  • the characteristic of No. 1 in FIG. 4 is that “passenger A gets on from Sunday at position ⁇ and gets off at position ⁇ at 10:25”. This is a characteristic based on regularity obtained from the table reservation numbers 25, 75, 102, 126, and the like.
  • the characteristic of No.2 is “Passenger B gets on 10:15 from position ⁇ and gets off at position ⁇ when it rains on Sunday.” Reservation information indicating the operation results This is a characteristic based on the regularity obtained from the reservation numbers 26 and 127 of the table and the record information table, and the correlation between the items of the ride item 62, the getting-off time 63, and the weather 68.
  • FIG. 5 shows a flowchart of processing in which the operation scheduling system 3 determines the operation schedule. This processing starts to be executed before the daily operation of the on-demand bus system starts.
  • the criterion for this determination is date / time information associated with the current information stored in the operation database 5 described briefly, and in particular the current time. That is, it is determined whether there is characteristic information including the boarding time within a predetermined time from the current time. The predetermined time is, for example, 10 minutes. If it is too long, there will be many corrections to the operation schedule determined for the reservation for a new ride, and if it is too short, there is a possibility that the operation schedule cannot be determined by the time it should be determined. Come out. In other words, this determination determines whether or not the current situation (including time) for determining the operation schedule is consistent with the situation indicated by any of the characteristic information.
  • reservation information there is reservation information that the user wants to board after 5 hours. If there is reservation information, the operation schedule corresponding to the reservation information is determined. This is because the user waits for a response indicating whether or not the user can get on the bus 1 according to the ride request.
  • the provisional getting-on time at the boarding position is obtained by subtracting the travel time between the getting-off position and the getting-off position.
  • the running time may be longer than the proven running time, and need not be a strict value.
  • the operation schedule is determined using the characteristic information and the reservation information (step 120), and if not, the operation schedule is determined using the characteristic information (step 140).
  • step 100 if there is no characteristic information, it is determined whether there is reservation information (step 150). If there is reservation information, an operation schedule is determined using the reservation information (step 160). If there is no reservation information, the process returns to step 100. That is, if there is no characteristic information within a predetermined time from the current time and there is no reservation information, an idle loop is formed by executing Step 100 and Step 150.
  • step 130 The operation schedule determined in any of step 120, step 140 and step 160 (including the case where the already determined one is corrected) is notified to bus 1 (step 130).
  • FIG. 6 An example of the process for determining the operation schedule is shown.
  • the target area of the bus 1 operation in this example is shown in FIG.
  • a solid line indicates a road on which the bus 1 can travel.
  • the broken lines show some examples of travel routes determined as the bus 1 operation schedule.
  • Greek letters ( ⁇ , ⁇ , ⁇ ,...) Represent the user's boarding position or getting-off position.
  • x1, x2,... indicate intersection positions.
  • the first example will be described.
  • the current time is 10:00 on June 7 (Sunday), and the predetermined time set in step 100 in FIG. 5 is 10 minutes.
  • the No. 1 characteristic 70 is determined as characteristic information (step 100).
  • a reservation number corresponding to the No. 1 characteristic information is obtained.
  • the latest reservation number is 75 when viewed from the current time in the column of reservation number 71.
  • the reservation content with a reservation number value of 75 is copied, and 102 is added to the reservation number 50 as new reservation information, and stored in the reservation information table together with the copied content.
  • the reservation confirmation flag is * (pending).
  • step 140 the operation schedule using the characteristic information is determined (step 140). In this step, the operation schedule is determined on the assumption that the reservation information whose value in the reservation number column 50 corresponding to the characteristic information is 102 is reserved.
  • the operation schedule shown in FIG. 7A is obtained.
  • the schedule of operations shown in FIG. 7A shows that bus 1 departs from position ⁇ at 10:10 and arrives at position ⁇ at 10:25 via intersections x1, x2, x3, x4, x5. .
  • the operation schedule is determined by searching for the shortest time route or the shortest distance route from the departure point to the destination. These include a table of travel times for each up and down line direction corresponding to the distance for each road section (for example, between intersections), and the distance or the travel time is added for each candidate route to indicate the minimum value. This is a method of selecting a candidate route. When the travel time varies depending on the degree of congestion on the road, the travel time corresponding to the degree of congestion is provided in the table and used.
  • the operation scheduling system 3 changes the reservation confirmation flag 53 from * to ON and notifies the user A via the reservation reception system 2 that the reservation has been made. Notify
  • the bus 1 By notifying the determined operation schedule to the bus 1 (step 130), the bus 1 operates so as to arrive at the position ⁇ at 10:10. At 10:10 arriving at the position ⁇ , when the reservation is not yet made by the user A, the operation scheduling system 3 cancels the operation of the bus 1 unless the operation schedule corresponds to the reservation information from other users.
  • FIG. 7A When the operation schedule is determined anew by reflecting the reservation information in which the value of the reservation number 50 is 103, the operation schedule is as shown in FIG. 7B. That is, an operation route to the position ⁇ and the position ⁇ is obtained via the position ⁇ at time 10:17. Similarly, a route search from the position ⁇ to the position ⁇ and a route search from the position ⁇ to the position ⁇ are executed.
  • FIG. 7B shows that the operation schedule was determined by correcting the operation schedule of bus 1 determined at 10:00 on Sunday, June 7th.
  • the reservation information whose value in the column of reservation number 50 is 103 is the schedule of other buses. Used for decision.
  • the schedule cannot be incorporated into any bus schedule, it is not possible to make a reservation for the user C who has sent the reservation information whose value in the reservation number 50 column is 103, and the reservation information that can be reserved Notify the proposal.
  • Step 160 As a result, the operation schedule No. 3 in FIG. 8 is obtained.
  • the determination of the operation schedule including the case where the reservation information whose reservation number 50 is 160, cannot be reflected, is omitted because it is the same as the above example.
  • the time required for determining the operation schedule can be shortened. Since the request during execution of the operation schedule is reflected in the operation schedule being executed, the time required to determine the operation schedule can be further shortened, and the occurrence of situations where passenger requests cannot be met can be reduced. . As a result, it is possible to determine an operation schedule with many passengers.

Landscapes

  • Engineering & Computer Science (AREA)
  • Business, Economics & Management (AREA)
  • Economics (AREA)
  • General Physics & Mathematics (AREA)
  • Human Resources & Organizations (AREA)
  • Strategic Management (AREA)
  • Physics & Mathematics (AREA)
  • Entrepreneurship & Innovation (AREA)
  • Tourism & Hospitality (AREA)
  • Theoretical Computer Science (AREA)
  • Marketing (AREA)
  • General Business, Economics & Management (AREA)
  • Game Theory and Decision Science (AREA)
  • Quality & Reliability (AREA)
  • Operations Research (AREA)
  • Educational Administration (AREA)
  • Development Economics (AREA)
  • Radar, Positioning & Navigation (AREA)
  • Remote Sensing (AREA)
  • Health & Medical Sciences (AREA)
  • General Health & Medical Sciences (AREA)
  • Primary Health Care (AREA)
  • Traffic Control Systems (AREA)
  • Management, Administration, Business Operations System, And Electronic Commerce (AREA)

Abstract

オンデマンドバスの運行スケジューリングシステムは、乗客の乗降に関し、その予約と実績に係る運行実績を格納するデータベースと、データベースに格納される運行実績から予め乗客の乗降に関する特性情報を抽出し、抽出した特性情報と抽出した特性情報に対応する運行実績に含まれる予約を示す情報とを対応付けてデータベースに格納する手段と、運行スケジュールを決定する現在の状況が、特性情報が示す状況に整合するとき、整合した特性情報に対応する運行実績に含まれる予約情報に基づいて、オンデマンドバスの運行スケジュールを決定する手段とを設ける。

Description

運行実績を活用したオンデマンドバスの運行スケジューリングシステム及びその方法 参照による取込
  本出願は、平成21年（2009年）7月13日に出願された日本特許出願　特願2009-164678号の優先権を主張し、その内容を参照することにより、本出願に取り込む。
　本発明は、ユーザからの要求に応じて運行するオンデマンドバスシステムに係り、特にその運行スケジューリングシステム及び運行スケジューリング方法に関する。
　交通渋滞の解消や交通機関の省エネルギー化を図るためにオンデマンドバスが検討されている。オンデマンドバスシステムに関して、利用客からの、乗車位置、目的地、希望乗車時刻、乗客の数を特定した乗車の要求を受信すると、その要求を満足する目的地へ適切なルートが決定されるシステムが特許文献1に開示されている。特許文献1に記載されるオンデマンドバスのルートは、すべての乗客が要求している利用の乗車地点、乗客の目的地、複数あるバスのそれぞれの現在の位置、それぞれのバスの現在予定されているルート、交通状況、の関数として決定される。
特開平10－241091
　特許文献１に記載の技術によれば、各乗客の要求（乗車位置、目的地、希望乗車時刻）は、ルートが決定されることにより、満足される。しかしながら、オンデマンドバスシステムの大規模化、たとえば、運行地域の拡大、運行するバスの台数の増加、乗客の増加に伴い、ルートの決定までに時間を要し、希望乗車時刻までに時間的余裕の少ない要求には応えられない場合が発生する。このような要求に応えられない場合を解消するために、たとえば、希望乗車時刻の30分前までや1時間前までのように、ルートの決定に要する時間を確保した運用があるが、このような運用はオンデマンドバスの本質的な利便性を損なう。
　このような状況において、ルートの決定に要する時間を短縮した、オンデマンドバスシステムの運行スケジュールシステムが必要とされる。
　上記課題を解決するために、次のような運行実績を活用したオンデマンドバスの運行スケジューリングシステム及びその方法が開示される。
　運行スケジューリングシステムは、オンデマンドバスの乗客の乗降に関し、その予約と実績に係る運行実績を格納するデータベースと、データベースに格納される運行実績から予め乗客の乗降に関する特性情報を抽出し、抽出した特性情報と抽出した特性情報に対応する運行実績に含まれる予約を示す情報とを対応付けてデータベースに格納する手段と、
運行スケジュールを決定する現在の状況が、特性情報が示す状況に整合するとき、整合した特性情報に対応する運行実績に含まれる予約情報に基づいて、オンデマンドバスの運行スケジュールを決定する手段とを設ける。
　さらに望ましい運行スケジューリングシステムは、乗客の乗降に関する予約と実績に係る運行実績が、少なくとも、乗客の乗降位置、乗降時刻の少なくとも一方の時刻、および、実績として前記オンデマンドバスを運行した日時の天候に関する情報を含む。
　さらに望ましい運行スケジューリングシステムは、乗客の乗降位置および乗降時刻の少なくとも一方の時刻の規則性に基づいて、運行実績から特性情報を抽出する。
　さらに望ましい運行スケジューリングシステムは、乗客の乗降位置、乗降時刻の少なくとも一方の時刻、および、実績としてオンデマンドバスを運行した日時の天候に関する情報の各情報間の相関関係に基づいて、運行実績から特性情報を抽出する。
　本発明によれば、運行実績から予め運行スケジュールを決定しておくので、運行スケジュールの決定に要する時間を短くできたり、乗り合いの多い運行計画を生成できたりする。
本実施形態のオンデマンドバスシステムの構成図である。 予約情報テーブルの構成例である。 実績情報テーブルの構成例である。 特性情報テーブルの構成例である。 運行スケジュールを決定する処理のフローチャートである。 バスの運行の対象地域の例示である。 決定した運行スケジュールの例である。 決定した運行スケジュールの例である。 決定した運行スケジュールの例である。
　以下、本発明の実施形態について図面を用いて説明する。図1に、本実施形態のオンデマンドバスシステムの構成図を示す。オンデマンドシステムは、運行するオンデマンドバス（以下、バス）1への乗車を希望するユーザからの要求を受け付ける予約受付システム２、予約受付システム２からの予約情報およびバス１の運行実績などに基づいて、バス１の運行スケジュールを決定する運行スケジューリングシステム３、バス１の運行情報を収集し、その運行実績として運行データベース５に格納する運行情報システム４を有する。運行スケジューリングシステム３が用いるバス１の運行実績は、運行データベース５に格納されている。なお、詳細を省略するが、オンデマンドバスシステムを運用する地域（運用地域：バスを運行する全域）の現在情報として、各道路（または、交差点間のような道路区間）の渋滞情報（混雑度や道路区間又は所定区間の走行時間）、気象条件などを収集し、運行データベース５に日時情報（年月日、曜日、祝日、時刻など）に対応付けて格納しておく。
　図1では、1台のバスを示しているが、運用地域の広さやオンデマンドバスシステムの利用客数に応じて、台数は決定される。バスの台数は、商店街、病院、公共施設、さらには急坂の存在などの地勢的特徴及び時間帯に基づいて、運用地域の中のある地域、ある地域と他の地域との間などを単位として決定される。地域に割当てていないバスを用意しておき、乗車を希望するユーザが少ない地域に、ユーザからの要求に応じて臨時に割当ててもよい。
　本実施形態の説明では、配車された1台のバスへの乗客の乗車希望を満足するように、そのバスの運行スケジュールを決定する運行スケジューリングシステム３について詳しく示す。
　図1では、理解を容易にするために、予約受付システム２、運行スケジューリングシステム３、運行情報システム４、及び運行データベース５を分けて示しているが、データベースシステムを有する1台のコンピュータで実現してもよいし、各システムの負荷や機能に応じた、複数台のコンピュータによる分散システムによって実現してもよい。
　また、バス１は、運行スケジューリングシステム３、運行情報システム４との通信のための無線通信装置を備えると共に、バス１の位置や現在時刻を把握するためのGPS(Global Positioning System)装置を備えている。バス１の位置や現在時刻は、運行情報として運行情報システム４に送信される。
　予約受付システム２は、乗車を希望するユーザからの要求をメールや電話で受け付ける。オペレータがユーザからの乗車希望を受け付け、受け付けた内容を予約受付システム２に入力してもよいが、ユーザが慣れてくると（乗車希望位置、降車希望位置、乗車希望時刻または降車希望時刻、および、乗車人員などの、乗車希望に必要な要件の伝達に慣れてくると）、自動受付が可能である。メールの場合は、所定のフォーマットを使用するメールを用いるか、予約受付システム２においてメールの文章を構文解析、意味解析することにより、乗車希望の内容を予約情報として抽出する。電話の場合は、メールで受け付ける仕組みの前段で音声認識装置を動作させ、文章を抽出する。この文章から予約情報を抽出するのは、メールの場合と同様である。
　メールの場合であっても、電話の場合であっても、自動受付の場合に、乗車希望に必要な要件の欠落が、予約情報を抽出する段階で判明する。この場合、欠落情報の追加を返信メールや電話のコールバックで要請する。
　運行データベース５に含まれる、予約情報テーブルの構成例を図２に、実績情報テーブルの構成例を図３に示す。予約情報テーブルの内容は、予約受付システム２で受け付けた予約情報を運行スケジューリングシステム３内のプログラムによって格納される。このプログラムは、予約受付システム２からの受信割り込みによって起動し、予約情報を運行スケジューリングシステム３を介して予約情報テーブルへ格納し、受け付けた予約情報に対する応答を運行スケジューリングシステム３から取得し、取得した応答をユーザへ返送して処理を終了する。
　予約情報テーブルは、予約番号50、乗客情報51、予約情報52、予約確定フラグ53の各欄を有する。予約情報52は、さらに月日54、曜日55、乗車(希望)時刻56、降車(希望)時刻57、乗車(希望)位置58、降車(希望)位置、乗車(希望)人数60、などの欄を有する。
　予約番号52は、ユーザに受付を完了した旨を応答する際に用いると共に、運行スケジューリングシステム２で、運行スケジュールに反映する予約情報52を識別するために用いる。後述するが、運行実績を運行データベース５に格納する際に、どの予約情報に対応する運行実績かを識別するためにも用いる。
　乗客情報51は、たとえば乗客（ユーザと同義）を識別する乗客識別子である。乗客識別子をキーにして、乗客の氏名、住所、電話番号などの属性情報を格納した乗客データベースを検索する。予約確定フラグ53は、予約情報52を運行スケジュールに反映し、確定した予約情報をユーザへの応答として返送したことを示すフラグである。換言すると、運行スケジューリングシステム２が、予約確定フラグ53がONの予約情報をバス１の運行スケジュールに反映したことを示している。予約確定フラグ53が空欄はOFFをあらわし、＊はペンディング状態を表す。ペンディング状態については後述する。
　予約情報52の個々の項目は、後述する例示によって明らかにされる。ただし、乗車時刻56の欄の括弧付きの時刻、降車時刻57の欄の－(ハイフン)について説明しておく。予約受付システム２による乗車希望に必要な要件として、乗車希望位置、降車希望位置、乗車希望時刻または降車希望時刻、および、乗車人員などと説明した。乗車希望時刻及び降車希望時刻の両方を要件とすると、乗車希望位置と降車希望位置とにおいて、指定された希望時刻を厳守したバス1の運行ができない状況が発生するので、その一方を要件とする。乗車希望時刻が指定されたとき、降車時刻57の欄に－(ハイフン)を格納する。降車希望時刻が指定されたとき、乗車時刻58の欄に、運行スケジューリングシステム２が決定した乗車(希望)位置58へのバス１の到着予想時刻を括弧付きで格納する。この到着予想時刻は、確定した予約情報としてユーザへ返送する応答の中に含むことにより、ユーザは乗車希望位置でその到着予想時刻より前にバス１を待つことができる。
　本実施形態のオンデマンドバスシステムの実運用においては、交通事故などによる突然の道路障害などを考慮して、乗車希望時刻や降車希望時刻は、たとえば±２分、±５分などの許容幅を持って運用される。
　なお、図２に示す予約情報テーブルは、後に具体例を説明するために、6月21日(日)の10：10の状態を示している。
　実績情報テーブルの内容は、運行情報システム４がバス１から受信した運行情報が、運行情報システム４によって格納される。バス１からの運行情報には、バスの走行（位置、速度など）に係る情報だけではなく、各乗客の乗降情報（位置、時刻など）が含まれる。本実施形態では、実績としての各乗客の乗降情報に基づいて、バス１の運行スケジュールを決定するので、バスの走行に係る情報については省略する。実績情報テーブルは、予約番号50、乗客情報51、実績情報61の各欄を有する。実績情報52は、さらに乗車時刻62、降車時刻63、乗車位置64、降車位置65、乗車人数66、号車67、などの欄を有する。予約番号50および乗客情報51は、予約情報テーブルの予約番号50および乗客情報51と同じであり、実績情報テーブルの各レコードは、予約情報テーブルの各予約情報52に対応して、その運行実績を格納する。したがって、予約情報と実績情報を併せて運行実績と呼ぶ。ここでは、予約情報テーブルと実績情報テーブルとを分けて説明するが、予約番号50および乗客情報51を共通にした1つのテーブルとして構成してもよい。実績情報61の個々の項目は、後述する例示によって明らかにされる。
　なお、図３に示す実績情報テーブルは、後に具体例を説明するために、6月21日(日)の10：10の状態を示している。
　図４に、運行データベース５に含まれる特性情報テーブルの構成例を示す。特性情報テーブルは、予約情報テーブルと実績情報テーブルとに格納される運行実績から得られる乗客の特性を格納する特性欄70とその特性を示す予約番号71の欄を有する。乗客の特性は、運行実績（予約情報テーブルの内容と実績情報デーブルの内容）の各項目間の相関関係や規則性(パターン)を探すデータマイニング技術や数理計画法に基づく他の技術によって得られる。図４のNo.1の特性は、「乗客Ａは、毎週日曜日に位置αから乗車し、位置βで10：25に降車する。」というものであり、運行実績を示す予約情報テーブル及び実績情報テーブルの予約番号25、75、102、126などから得られた、規則性に基づく特性である。No.2の特性は、「乗客Ｂは、日曜日に雨が降ると、二人で位置γから10：15に乗車し、位置βで降車する。」というものであり、運行実績を示す予約情報テーブル及び実績情報テーブルの予約番号26、127などから得られた、規則性および乗車事項62、降車時刻63などと天候68との項目間の相関関係に基づく特性である。
　図５に、運行スケジューリングシステム３が運行スケジュールを決定する処理のフローチャートを示す。この処理は、オンデマンドバスシステムの一日の運用開始前に実行を開始する。まず、特性情報があるか否かを判定する(ステップ100)。この判定の基準は、簡単に説明した運行データベース５に格納されている現在情報に対応付けてある日時情報であり、特に現在時刻である。すなわち、現在時刻から所定時間内に乗車時刻を含む特性情報があるか否かを判定する。所定時間は、たとえば10分であり、長すぎると新たな乗車希望の予約のために決定した運行スケジュールの修正が多くなり、短すぎると、運行スケジュールを決定すべき時刻までに決定できない可能性が出てくる。この判定は、換言すると、運行スケジュールを決定する現在の状況（時刻を含む）が、いずれかの特性情報が示す状況に整合するか否かを判定している。
　特性情報があれば、予約情報があるか否かを判定する(ステップ110)。予約情報には、5時間後に乗車を希望するような予約情報もあるが、予約情報があれば、その予約情報に対応する運行スケジュールを決定する。なぜならば、ユーザは乗車希望に沿ってバス1に乗車できるか否かを示す応答を待っているからである。前述したように、降車希望時刻を指定した予約情報の場合は、乗車位置における仮の乗車希望時刻を、降車希望時刻から降車位置との間の走行時間を減算して求める。走行時間は、実績のある走行時間より長めの時間を用いればよく、厳密な値である必要はない。
　予約情報があれば、特性情報と予約情報を用いて運行スケジュールを決定し(ステップ120)、なければ、特性情報を用いて運行スケジュールを決定する(ステップ140)。
　ステップ100において、特性情報がなければ、予約情報があるか否かを判定し(ステップ150)、予約情報があれば、予約情報を用いて運行スケジュールを決定する(ステップ160)。予約情報がなければ、ステップ100に戻る。すなわち、現在時刻から所定時間内に特性情報がなく、予約情報もなければ、ステップ100とステップ150との実行によるアイドルループを構成する。
　ステップ120、ステップ140及びステップ160のいずれかで決定された（すでに決定されていたものを修正した場合を含む）運行スケジュールをバス1へ通知する(ステップ130)。
　運行スケジュールを決定する処理の例を示す。この例のバス１の運行の対象地域を図６に示す。図６において、実線は、バス1が走行可能な道路を示す。破線は、バス1の運行スケジュールとして決定された走行経路のいくつかの例を示す。ギリシャ文字（α、β、γ、・・・）はユーザの乗車位置又は降車位置を表す。ｘ1、ｘ2、・・・などは、交差点位置を示す。乗車位置、降車位置などの位置情報には、実際は緯度・経度を用いるが、ここでは記号（ギリシャ文字及びxn（ｎ＝1、2、3、・・・））を用いる。
　第１の例を説明する。現在時刻を6月7日(日)の10：00とし、図5のステップ100に設定してある所定時間を10分とする。図４に示す特性テーブルを参照すると、No.1の特性70が特性情報として判定される(ステップ100)。No.1の特性情報に対応する予約番号を得る。予約番号71の欄の現在時刻から見て最新の予約番号は75である。予約番号の値が75の予約内容をコピーし、新たな予約情報として、予約番号50に102を付し、コピーした内容と共に予約情報テーブルに格納する。このとき、予約確定フラグは＊(ペンディング)とする。
　所定時間の10分以内に予約情報はないので(ステップ110：No)、特性情報を用いた運行スケジュールを決定する(ステップ140)。このステップは、特性情報に対応した予約番号欄50の値が102の予約情報が仮に予約されたとして、運行スケジュールを決定する。
　図７Ａに示す運行スケジュールが得られる。図７Ａに示す運行スケジュールは、バス1が位置αを10：10に出発し、交差点ｘ1、ｘ2、ｘ3、ｘ4、ｘ5を経由して、位置βに10：25に到着することを示している。
　運行スケジュールの決定は、出発地から目的地への最短時間経路探索または最短距離経路探索による。これらは、道路区間（たとえば、交差点間）毎に、距離と対応させた上下線方向毎の走行時間のテーブルを備え、それらの距離又は走行時間を候補経路毎に加算し、最小の値を示す候補経路を選択する方法である。走行時間が道路の混雑度によって変化する場合は、その混雑度に応じた走行時間をテーブルに設けて使用する。
　予約番号欄50の値が102の予約情報が予約されたならば、運行スケジューリングシステム３は、予約確定フラグ53を＊からONに変更し、予約できた旨を予約受付システム２を介してユーザＡに通知する。
　決定した運行スケジュールをバス1へ通知することにより(ステップ130)、バス1は10：10に位置αに到着するように運行する。位置αに到着する10：10に、ユーザＡから未だ予約されないとき、他のユーザからの予約情報にも対応する運行スケジュールでないならば、運行スケジューリングシステム３はバス1の運行をキャンセルする。
　第２の例を説明する。第1の例から時間が経過し、現在時刻を6月7日(日)の10：07とする。図４に示す特性テーブルを参照すると、特性情報はなく(ステップ100：No)、予約番号50の欄の値が103の予約情報があるので(ステップ150：Yes)、予約情報を用いた運行スケジュールを決定する(ステップ160)。なお、図２の予約情報テーブルは、6月21日(日)の10：10の状態を示しているので、予約番号50の欄の値が103の行の予約確定フラグ53はONを示しているが、6月7日(日)の10：07の時点では、OFF(空欄)である。10：07の時点では、すでに図７Ａに示す運行スケジュールによって、バス1が位置αに向けて運行されている。予約番号50の欄の値が103の予約情報を反映して、運行スケジュールを改めて決定すると、図７Ｂの運行スケジュールのようになる。すなわち、時刻10：17に位置Δを経由して、位置β、位置ηへの運行経路を得る。同様に、位置Δから位置βへの経路探索、位置βから位置ηへの経路探索を実行する。図７Ｂは、6月7日(日)の10：00に決定したバス1の運行スケジュールを修正して、運行スケジュールを決定したことを示している。
　経路探索した結果、位置Δに10：17、位置βに10：25の到着という制約条件を満足できなければ、予約番号50の欄の値が103の予約情報は、他のバスの運行スケジュールの決定に用いられる。いずれのバスの運行スケジュールにも組み入れることができないときは、予約番号50の欄の値が103の予約情報を送ってきたユーザＣに対して、予約がとれない旨と共に、予約可能な予約情報の案を通知する。
　第３の例を説明する。第２の例から日時が経過し、現在時刻を6月21日(日)の10：10、雨天とする。すでに、図４に示す特性テーブルを参照して、10：00に予約番号50の欄の値が158の予約情報に対応して、特性情報のNo.1を使用して運行スケジュールを決定し、10：05に予約番号50の欄の値が159の予約情報に対応して、特性情報のNo.2を使用して運行スケジュールを決定している。これらを図8の運行スケジュールNo.1及びNo.2に示す。10：10には、新たな特性情報はなく(ステップ100：No)、予約番号50の欄の値が160の予約情報があるので(ステップ150：Yes)、予約情報を用いた運行スケジュールを決定する(ステップ160)。結果として、図８の運行スケジュールNo.3が得られる。予約番号50の欄の値が160の予約情報を反映できない場合を含めて、運行スケジュールの決定については前述の例と同じであるので省略する。
　本実施形態によれば、運行実績から予め運行スケジュールを決定しておくので、運行スケジュールの決定に要する時間を短くできる。運行スケジュールの実行中の要求を、実行中の運行スケジュールに反映するようにするので、運行スケジュールの決定に要する時間をさらに短くでき、乗客の要求に応えられない状況の発生を少なくすることができる。結果として、乗り合いの多い運行スケジュールを決定できる。
　1：オンデマンドバス、２：予約受付システム、３：運行スケジューリングシステム、４：運行情報システム、５：運行データベース。

Claims (8)

  1. オンデマンドバスの乗客の乗降に関し、その予約と実績に係る運行実績を格納するデータベースと、
    前記データベースに格納される前記運行実績から予め前記乗客の乗降に関する特性情報を抽出し、抽出した前記特性情報と抽出した前記特性情報に対応する前記運行実績に含まれる前記予約を示す情報とを対応付けて前記データベースに格納する手段と、
    運行スケジュールを決定する現在の状況が、前記特性情報が示す状況に整合するとき、整合した前記特性情報に対応する前記運行実績に含まれる前記予約情報に基づいて、前記オンデマンドバスの前記運行スケジュールを決定する手段とを設けることを特徴とするオンデマンドバスの運行スケジューリングシステム。
  2. 前記乗客の乗降に関する前記予約と前記実績に係る前記運行実績は、少なくとも、前記乗客の乗降位置、乗降時刻の少なくとも一方の時刻、および、前記実績として前記オンデマンドバスを運行した日時の天候に関する情報を含むことを特徴とする請求項１記載のオンデマンドバスの運行スケジューリングシステム。
  3. 前記乗客の前記乗降位置および前記乗降時刻の少なくとも一方の時刻の規則性に基づいて、前記運行実績から前記特性情報を抽出することを特徴とする請求項２記載のオンデマンドバスの運行スケジューリングシステム。
  4. 前記乗客の前記乗降位置、前記乗降時刻の少なくとも一方の時刻、および、前記実績として前記オンデマンドバスを運行した日時の前記天候に関する情報の各情報間の相関関係に基づいて、前記運行実績から前記特性情報を抽出することを特徴とする請求項２記載のオンデマンドバスの運行スケジューリングシステム。
  5. オンデマンドバスの乗客の乗降に関し、その予約と実績に係る運行実績を格納するデータベースを有するコンピュータによる、前記オンデマンドバスの運行スケジュールの決定方法であって、前記コンピュータは、
    前記データベースに格納される前記運行実績から前記乗客の乗降に関する特性情報を抽出し、
    抽出した前記特性情報と抽出した前記特性情報に対応する前記運行実績に含まれる前記予約を示す情報とを対応付けて前記データベースに格納し、
    運行スケジュールを決定する現在の状況が、前記特性情報が示す状況に整合するとき、整合した前記特性情報に対応する前記運行実績に含まれる前記予約情報に基づいて、前記オンデマンドバスの前記運行スケジュールを決定することを特徴とするオンデマンドバスの運行スケジューリング方法。
  6. 前記データベースに格納される、前記乗客の乗降に関する前記予約と前記実績に係る前記運行実績は、少なくとも、前記乗客の乗降位置、乗降時刻の少なくとも一方の時刻、および、前記実績として前記オンデマンドバスを運行した日時の天候に関する情報を含むことを特徴とする請求項５記載のオンデマンドバスの運行スケジューリング方法。
  7. 前記コンピュータは、前記乗客の前記乗降位置および前記乗降時刻の少なくとも一方の時刻の規則性に基づいて、前記運行実績から前記特性情報を抽出することを特徴とする請求項６記載のオンデマンドバスの運行スケジューリング方法。
  8. 前記コンピュータは、前記乗客の前記乗降位置、前記乗降時刻の少なくとも一方の時刻、および、前記実績として前記オンデマンドバスを運行した日時の前記天候に関する情報の各情報間の相関関係に基づいて、前記運行実績から前記特性情報を抽出することを特徴とする請求項６記載のオンデマンドバスの運行スケジューリング方法。
PCT/JP2010/004533 2009-07-13 2010-07-13 運行実績を活用したオンデマンドバスの運行スケジューリングシステム及びその方法 WO2011007553A1 (ja)

Priority Applications (1)

Application Number Priority Date Filing Date Title
KR1020127000928A KR101742833B1 (ko) 2009-07-13 2010-07-13 운행 실적을 활용한 온 디맨드 버스의 운행 스케줄링 시스템 및 그 방법

Applications Claiming Priority (2)

Application Number Priority Date Filing Date Title
JP2009-164678 2009-07-13
JP2009164678A JP5594754B2 (ja) 2009-07-13 2009-07-13 運行実績を活用したオンデマンドバスの運行スケジューリングシステム及びその方法

Publications (1)

Publication Number Publication Date
WO2011007553A1 true WO2011007553A1 (ja) 2011-01-20

Family

ID=43449163

Family Applications (1)

Application Number Title Priority Date Filing Date
PCT/JP2010/004533 WO2011007553A1 (ja) 2009-07-13 2010-07-13 運行実績を活用したオンデマンドバスの運行スケジューリングシステム及びその方法

Country Status (3)

Country Link
JP (1) JP5594754B2 (ja)
KR (1) KR101742833B1 (ja)
WO (1) WO2011007553A1 (ja)

Cited By (4)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
EP3330157A1 (en) * 2016-11-21 2018-06-06 Hitachi, Ltd. Transportation demand-and-supply matching system and transportation demand-and-supply matching method
CN108417020A (zh) * 2018-03-06 2018-08-17 苏州登阳信息技术有限公司 一种预计算预支付智能公交运行方法及其系统
WO2019204257A1 (en) 2018-04-16 2019-10-24 Arrys Therapeutics, Inc. Ep4 inhibitors and use thereof
CN111599172A (zh) * 2020-04-30 2020-08-28 广东中科臻恒信息技术有限公司 基于车路协同的自动驾驶公交调度方法、设备、存储介质

Families Citing this family (19)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
DE112012006589T5 (de) * 2012-06-29 2015-04-02 Toyota Jidosha Kabushiki Kaisha Bedarfsfahrzeugbetriebsverwaltungsvorrichtung, Bedarfsfahrzeugbetriebsverwaltungsverfahren und Bedarfsfahrzeugbetriebsverwaltungssystem
JP5935887B2 (ja) 2012-07-02 2016-06-15 トヨタ自動車株式会社 オンデマンド車両運行管理装置、オンデマンド車両運行管理方法及びオンデマンド車両運行管理システム
JP5642118B2 (ja) * 2012-07-03 2014-12-17 ヤフー株式会社 乗換検索装置、乗換検索方法および乗換検索プログラム
JP5538499B2 (ja) * 2012-09-05 2014-07-02 ヤフー株式会社 スケジュール検索装置、スケジュール検索方法およびスケジュール検索プログラム
EP2899710B8 (en) 2012-09-20 2022-12-28 Toyota Jidosha Kabushiki Kaisha On-demand vehicle operation management device, on-demand vehicle operation management method, and on-demand vehicle operation management system
JP5831917B1 (ja) * 2015-05-01 2015-12-09 コガソフトウェア株式会社 通知サーバ、通知方法および通知プログラム
JP6272596B1 (ja) * 2017-05-31 2018-01-31 三菱電機株式会社 運行計画装置、運行計画方法および運行計画プログラム
JP6537580B2 (ja) * 2017-11-20 2019-07-03 ヤフー株式会社 情報処理装置、情報処理方法および情報処理プログラム
JP6901511B2 (ja) * 2017-11-20 2021-07-14 ヤフー株式会社 情報処理装置、情報処理方法および情報処理プログラム
JP2019175390A (ja) * 2018-03-29 2019-10-10 パナソニックＩｐマネジメント株式会社 搭乗管理システム、搭乗管理方法、プログラム、及び移動体
JP7278044B2 (ja) 2018-09-18 2023-05-19 松之進 山口 情報処理装置
JP7141933B2 (ja) * 2018-11-30 2022-09-26 ダイハツ工業株式会社 車両台数計算システム
JP7172777B2 (ja) * 2019-03-19 2022-11-16 トヨタ自動車株式会社 情報処理システム、サーバ、及びプログラム
CN110097233A (zh) * 2019-05-10 2019-08-06 佛山市木记信息技术有限公司 一种班车运作体系
JP6940574B2 (ja) * 2019-10-18 2021-09-29 ソフトバンク株式会社 管理装置、運用システム、プログラム及び運用方法
JP7344755B2 (ja) * 2019-10-28 2023-09-14 スズキ株式会社 運行管理装置、運行管理方法、および端末
JP7369101B2 (ja) * 2020-07-13 2023-10-25 Kddi株式会社 配車管理システム、配車管理方法及びコンピュータプログラム
JP7294365B2 (ja) * 2021-03-30 2023-06-20 トヨタ自動車株式会社 ライドシェア車両のルート検索装置及びルート検索方法
JP7051164B1 (ja) 2021-06-14 2022-04-11 祐次 廣田 自動運転トラム

Citations (3)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JP2002140788A (ja) * 2000-10-31 2002-05-17 Toshiba Corp 乗合車両運行スケジューリングシステム
JP2003108743A (ja) * 2001-09-27 2003-04-11 Toshiba Corp 需要発生量を予測する方法及びプログラム
JP2007249952A (ja) * 2006-02-14 2007-09-27 Av Planning Center:Kk 車両運行情報処理方法及び車両運行情報処理システム

Family Cites Families (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JP2003345873A (ja) 2002-05-23 2003-12-05 Fujitsu Ten Ltd バス運行管理装置、バス運行管理システム、センター装置、施設端末、及びバス端末

Patent Citations (3)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JP2002140788A (ja) * 2000-10-31 2002-05-17 Toshiba Corp 乗合車両運行スケジューリングシステム
JP2003108743A (ja) * 2001-09-27 2003-04-11 Toshiba Corp 需要発生量を予測する方法及びプログラム
JP2007249952A (ja) * 2006-02-14 2007-09-27 Av Planning Center:Kk 車両運行情報処理方法及び車両運行情報処理システム

Cited By (4)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
EP3330157A1 (en) * 2016-11-21 2018-06-06 Hitachi, Ltd. Transportation demand-and-supply matching system and transportation demand-and-supply matching method
CN108417020A (zh) * 2018-03-06 2018-08-17 苏州登阳信息技术有限公司 一种预计算预支付智能公交运行方法及其系统
WO2019204257A1 (en) 2018-04-16 2019-10-24 Arrys Therapeutics, Inc. Ep4 inhibitors and use thereof
CN111599172A (zh) * 2020-04-30 2020-08-28 广东中科臻恒信息技术有限公司 基于车路协同的自动驾驶公交调度方法、设备、存储介质

Also Published As

Publication number Publication date
KR101742833B1 (ko) 2017-06-01
JP5594754B2 (ja) 2014-09-24
KR20120047899A (ko) 2012-05-14
JP2011022646A (ja) 2011-02-03

Similar Documents

Publication Publication Date Title
JP5594754B2 (ja) 運行実績を活用したオンデマンドバスの運行スケジューリングシステム及びその方法
JP6273656B2 (ja) デマンド型運行管理システムの制御方法及びデマンド型運行管理システム
RU2717114C2 (ru) Система для контроля совместных поездок ни транспортном средстве (варианты) и способ контроля совместных поездок на транспортном средстве
US8355936B2 (en) Managing a travel itinerary
JP5967205B2 (ja) オンデマンド車両運行管理装置、オンデマンド車両運行管理方法及びオンデマンド車両運行管理システム
US20170330111A1 (en) Systems and methods for managing travel options
US20190303806A1 (en) Boarding management system, boarding management method, and system
CN108921762B (zh) 一种车辆混合调度方法、装置及设备
JP2018163578A (ja) アクティブ迎車システムにおける迎車制御サーバ、車載端末、制御方法及び制御プログラム
JP7063172B2 (ja) 情報処理装置、乗車車両調整方法及び乗車車両調整プログラム
KR20040047736A (ko) 정보 표시 시스템
JP7044002B2 (ja) 車両予約システム、車両予約方法およびプログラム
JP2020173589A (ja) 乗車予約利用者支援装置及び乗車予約利用者支援方法
JP4679159B2 (ja) 予約処理システム、予約処理方法、およびコンピュータプログラム
JP2004227262A (ja) 即応型車両乗降システム、方法およびプログラム
JP2013191016A (ja) 情報提供装置および方法
JP4311504B2 (ja) メッセージ交換システム
JP2003130664A (ja) 情報表示システム
JP2007127655A (ja) 情報表示システム
JP2004213509A (ja) 乗り換え案内情報提供システムおよび乗り換え案内情報提供方法
CN113597635A (zh) 信息处理装置、移动体、程序和方法
KR102642575B1 (ko) 탑승객용 통근버스 이용 프로그램
JP7371431B2 (ja) 経路情報提供システム、経路情報提供方法、及び経路情報提供プログラム
CN113574578B (zh) 信息处理装置、移动体、计算机可读存储介质以及方法
JP2023019298A (ja) 配車管理システム、配車予約管理方法及びコンピュータプログラム

Legal Events

Date Code Title Description
121 Ep: the epo has been informed by wipo that ep was designated in this application

Ref document number: 10799617

Country of ref document: EP

Kind code of ref document: A1

ENP Entry into the national phase

Ref document number: 20127000928

Country of ref document: KR

Kind code of ref document: A

NENP Non-entry into the national phase

Ref country code: DE

122 Ep: pct application non-entry in european phase

Ref document number: 10799617

Country of ref document: EP

Kind code of ref document: A1