WO2013096675A1 - Automated system for preventing vehicle bunching - Google Patents
Automated system for preventing vehicle bunching Download PDFInfo
- Publication number
- WO2013096675A1 WO2013096675A1 PCT/US2012/071050 US2012071050W WO2013096675A1 WO 2013096675 A1 WO2013096675 A1 WO 2013096675A1 US 2012071050 W US2012071050 W US 2012071050W WO 2013096675 A1 WO2013096675 A1 WO 2013096675A1
- Authority
- WO
- WIPO (PCT)
- Prior art keywords
- vehicle
- vehicles
- station
- status data
- vehicle controller
- Prior art date
Links
Classifications
-
- G—PHYSICS
- G08—SIGNALLING
- G08G—TRAFFIC CONTROL SYSTEMS
- G08G1/00—Traffic control systems for road vehicles
- G08G1/09—Arrangements for giving variable traffic instructions
- G08G1/0962—Arrangements for giving variable traffic instructions having an indicator mounted inside the vehicle, e.g. giving voice messages
- G08G1/0967—Systems involving transmission of highway information, e.g. weather, speed limits
- G08G1/096708—Systems involving transmission of highway information, e.g. weather, speed limits where the received information might be used to generate an automatic action on the vehicle control
- G08G1/096716—Systems involving transmission of highway information, e.g. weather, speed limits where the received information might be used to generate an automatic action on the vehicle control where the received information does not generate an automatic action on the vehicle control
-
- G—PHYSICS
- G08—SIGNALLING
- G08G—TRAFFIC CONTROL SYSTEMS
- G08G1/00—Traffic control systems for road vehicles
- G08G1/09—Arrangements for giving variable traffic instructions
- G08G1/0962—Arrangements for giving variable traffic instructions having an indicator mounted inside the vehicle, e.g. giving voice messages
- G08G1/0967—Systems involving transmission of highway information, e.g. weather, speed limits
- G08G1/096733—Systems involving transmission of highway information, e.g. weather, speed limits where a selection of the information might take place
- G08G1/096741—Systems involving transmission of highway information, e.g. weather, speed limits where a selection of the information might take place where the source of the transmitted information selects which information to transmit to each vehicle
-
- G—PHYSICS
- G08—SIGNALLING
- G08G—TRAFFIC CONTROL SYSTEMS
- G08G1/00—Traffic control systems for road vehicles
- G08G1/09—Arrangements for giving variable traffic instructions
- G08G1/0962—Arrangements for giving variable traffic instructions having an indicator mounted inside the vehicle, e.g. giving voice messages
- G08G1/0967—Systems involving transmission of highway information, e.g. weather, speed limits
- G08G1/096766—Systems involving transmission of highway information, e.g. weather, speed limits where the system is characterised by the origin of the information transmission
- G08G1/096775—Systems involving transmission of highway information, e.g. weather, speed limits where the system is characterised by the origin of the information transmission where the origin of the information is a central station
-
- G—PHYSICS
- G08—SIGNALLING
- G08G—TRAFFIC CONTROL SYSTEMS
- G08G1/00—Traffic control systems for road vehicles
- G08G1/09—Arrangements for giving variable traffic instructions
- G08G1/0962—Arrangements for giving variable traffic instructions having an indicator mounted inside the vehicle, e.g. giving voice messages
- G08G1/0967—Systems involving transmission of highway information, e.g. weather, speed limits
- G08G1/096766—Systems involving transmission of highway information, e.g. weather, speed limits where the system is characterised by the origin of the information transmission
- G08G1/096791—Systems involving transmission of highway information, e.g. weather, speed limits where the system is characterised by the origin of the information transmission where the origin of the information is another vehicle
-
- 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
- G08G1/127—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 to a central station ; Indicators in a central station
-
- 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
- G08G1/133—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 within the vehicle ; Indicators inside the vehicles or at stops
Definitions
- At least one embodiment of the present invention pertains to a distributed automatic control system for preventing bus bunching and promoting schedule adherence in transit systems.
- Bus bunching also referred to as clumping, clustering, or platooning
- Bus bunching describes the tendency of buses along a particular transit route to pair or bunch together despite being scheduled to appear at constant intervals. If buses are scheduled to run a certain headway time apart, passengers arriving to a station should not expect to wait more than the headway time for the next bus to arrive. If passengers arrive at a random time, the average waiting time is a half of the headway time. If two buses pair, passengers may wait as long as two headways. If more than two buses bunch up, the wait can be even longer.
- Bus bunching or clustering is discussed in several references, such as US Pat. 3,772,691 , US Pat. 5,739,774, US Pat. 6,006,159, US Pat. 6,374,176 and US Patent Publication 2010/0299177, all of which are incorporated herein by reference in their entireties.
- Techniques introduced here provide a distributed automatic control system for preventing the vehicle bunching.
- Information of vehicle locations is automatically detected and used to determine the positions and velocities of vehicles along a route.
- Vehicles pass predetermined points, such as stations, along the route.
- Information about whether the vehicle skipped the station, arrived at the station, or departed from the station, is automatically calculated based on the position and velocity information. This information is distributed among the vehicles that belong to the same route.
- An in-vehicle controller dynamically calculates holding times at each station and displays the information to the driver so that buses do not get too close to one another, thereby preventing bunching while maintaining appropriate speeds of the vehicles.
- a distributed transportation control system for vehicles of a transportation route includes a plurality of in-vehicle controllers. Each in-vehicle controller is placed in one of the vehicles of the transportation route. Each in-vehicle controller includes a network interface, a spatial positioning device, a signaling device and a processor.
- the network interface is configured to exchange status data of the vehicles, with other in- vehicle controllers of the plurality of in-vehicle controllers.
- the spatial positioning device is configured to continuously collect status data of a individual vehicle in which that in-vehicle controller is placed.
- the signaling device is configured to provide an operating instruction to an operator of the individual vehicle in which that in-vehicle controller is placed.
- the processor is configured to determine the operating instruction based on the status data of the vehicles.
- a method for scheduling a vehicle of a transportation route includes steps of receiving status data of other vehicles of the transportation route, via a network from other in- vehicle controllers placed in the other vehicles; detecting status data of the vehicle; determining an operating instruction based on the status data of the other vehicles and the status data of the vehicle; and presenting the operating instruction to an operator of the vehicle.
- FIG. 1 illustrates an example of a transportation route having multiple buses utilizing a distributed transportation control system.
- FIG. 2 illustrates an example of an in-vehicle controller of a distributed transportation control system for preventing the vehicle bunching.
- FIG. 3 illustrates relevant information for determining vehicle status.
- FIG. 4 illustrates an example process of determining vehicle status events.
- FIG. 5 illustrates an example of a vehicle operator interface of a signaling device.
- FIG. 6 illustrates another example of a vehicle operator interface of a signaling device.
- FIG. 7 illustrates an example process of scheduling a vehicle of a transportation route.
- FIG. 8 is a high-level block diagram showing an example of the architecture of a device, which may represent any of the in-vehicle controllers.
- FIG. 1 illustrates an example of a transportation route having multiple buses utilizing a distributed transportation control system.
- the distributed transportation control system includes a plurality of in-vehicle controllers 120.
- Each bus 130 has one in-vehicle controller 120 placed inside of the bus.
- the in-vehicle controllers 120 collect status data of the buses 130.
- the in- vehicle controllers 120 exchange status data via a network 140.
- the network 140 can include a WiFi network, a mobile phone network, a satellite network, a wireless data network, the Internet, or any combinations thereof.
- the techniques disclosed herein can be used in any type of vehicles for transportation, such as buses, taxis, automobiles, trains, aircrafts, motorcycles, bicycles, planes, boats, ships, or spaceships.
- FIG. 2 illustrates an example of an in-vehicle controller of a distributed transportation control system for preventing the vehicle bunching.
- the control system solves the scheduling problems incurred by both users and operators of transit systems.
- Information of vehicle locations is automatically detected and used to determine the positions and velocities of vehicles along a route.
- Vehicles pass predetermined points, such as stations, along the route.
- Information about whether the vehicle skipped the station, arrived at the station, or departed from the station, is automatically calculated based on the position and velocity information.
- the in-vehicle controller 200 (also referred to as in- vehicle unit) includes a GPS (Global Positioning System) unit 210. While in operation, the GPS unit 210 continuously collects the location coordinates of the GPS unit 210, which is also the location coordinates of the bus in which the in- vehicle controller 200 is placed. The GPS unit 210 can further generate velocity data of the bus. The GPS unit 210 transmits the location and velocity data to a network interface 220 (also referred to as communication unit). Using the location and velocity data, the in-vehicle controller 200 can further detect status of bus using a detector 230.
- GPS Global Positioning System
- the detector 230 can determine a status value indicating whether the bus is during station arrival, station departure, or station skipping.
- the status value can also be transmitted to the network interface 220.
- the location information of the vehicles may be collected from satellite navigation devices, such as GPS devices, or other types of spatial positioning devices.
- the network interface 220 transmits these data to other in-vehicle controllers 290 via a network channel 280.
- the network interface 220 also receives status data of other buses from the other in-vehicle controllers 290 via the network channel 280.
- the network interface 220 forward these received status data to a bunch prevention controller 240.
- the bunch prevention controller 240 generates an operation instruction to an operator of the bus, based on the received status data of other buses as well as the status data of the bus.
- the operation instruction includes a holding time, which is a time period for which the operator is to hold the bus at a station.
- the operation instruction includes a visual indication of an extent of the bus being ahead of or behind a schedule.
- the operating instruction may further include an audio signal to prompt the operator to move the individual vehicle.
- the detector 230 and the bunch prevention controller 240 are implemented as a single processor configured to operate as both the detector 230 and the bunch prevention controller 240.
- a signaling device is responsible for presenting the operation instruction to the operator of the bus.
- the signal device can visualize the time period for which the operator is to hold the bus at a station, or the extent of the bus being ahead of or behind a schedule.
- the signaling device can play an audio message to prompt the operator to start moving the bus along the route.
- the in-vehicle controller 200 can further include a passenger information service 260.
- the passenger information service 260 can present minimum arrival guarantee, or next arrival estimation to a passenger on the bus.
- the passenger information service can be implemented as a device separated from and connected to the in-vehicle controller 200.
- a central operator module 270 there may be a central operator module 270.
- the central operator module 270 can listen and receive the status data from the in- vehicle controllers.
- the central operator module 270 can analyze the status data and present visualized information to a central operator. Based on the visualized information, the central operator can send manual control input via the communication channel 280 to manually instruct operators of the buses along the route.
- an analytics engine 272 can be included in the central operator module 270.
- the analytics engine 272 provides a virtual schedule for buses to follow and calculate parameters to be used in the control system.
- a human operator is able to adjust the parameters in the analytics engine or send messages manually to the operators of the vehicles.
- the system is capable of running automatically without manual intervention. This simplifies or eliminates the operator's task and is capable of making the high rate of pre-emptive, measured control decisions before noticeable disruptions to service can arise.
- the status information of the vehicle is distributed among the vehicles that belong to the same route.
- An in- vehicle controller dynamically calculates holding times at each station and displays the information to the driver so that buses do not get too close to one another, thereby preventing bunching while maintaining appropriate speeds of the vehicles.
- the Information about whether the vehicle skipped the station, arrived at the station, or departed from the station is automatically calculated based on the position and velocity information as illustrated in FIG. 3. Based on the GPS coordinates and the velocity data of the vehicle, the position and speed of the vehicle are projected onto the route path. A station buffer range is predetermined around the station location. Judging from the relative position of the vehicle from the station buffer along the route path, as well as the speed of the vehicle, the distributed transportation control system determines the vehicle status of station arrival, station departure, or station skipping.
- FIG. 4 illustrates an example process of determining vehicle status events.
- the vehicle status events include station arrivals (approaching a station); departures (leaving a station), and skips (passing through a station without stopping).
- the in-vehicle controller determines the status event based on the velocity of the bus and the projection of its GPS coordinates along the route. As shown in the FIG. 4, for instance, when the in-vehicle controller detects that the vehicle is between stations and the vehicle is projected to be reaching a station buffer at a low speed, the in-vehicle controller determines the status event as station arrival. When the in-vehicle controller detects that the vehicle is within a station buffer at a low speed and the vehicle changes to a high speed, the in-vehicle controller determines the status event as station departure.
- the in-vehicle controller determines the status event as station arrival.
- the in-vehicle controller determines the status event as station skipping.
- the in-vehicle device transmits the time at which the vehicle arrived, departed or skipped a particular station, which helps limiting the amount of communication required for the system to work.
- FIG. 5 illustrates an example of a vehicle operator interface of a signaling device. Detection of vehicle status events allows the vehicle operator interface to switch between different display modes. In one embodiment, the operation of the vehicle operator interface does not rely on any communication with a centralized server. Between stations, a vehicle operator receives visual cues how far ahead of or behind schedule he is, so the vehicle operator can regulate the speeds of his vehicle accordingly. As shown in the FIG. 5, the vehicle operator interface visualizes a tab above a middle line to indicate the vehicle is ahead of the schedule, or a tab below the middle line to indicate the vehicle is behind the schedule. The extent that the visualized tab deviates from the middle line indicates the extent that the vehicle is ahead of or behind the schedule.
- the in-vehicle controller in the vehicle calculates a holding time based on previous bus arrivals and the display will count down time until the bus is released from the station. This control information is presented to the vehicle operator through audio and visual signals as shown in FIG. 5.
- the in-vehicle controller determines that the holding time lapses, it visualizes a "go" message and plays an audio message to prompt the vehicle operator to start moving the vehicle for departure.
- FIG. 6 illustrates another example of a vehicle operator interface of a signaling device.
- the vehicle operator interface 600 includes a schedule bar 640 with a middle line 630.
- the vehicle operator interface 600 visualizes a color tab 650 above a middle line to indicate the vehicle is ahead of the schedule, or a tab below the middle line to indicate the vehicle is behind the schedule.
- the extent that the visualized tab deviates from the middle line indicates the extent that the vehicle is ahead of or behind the schedule.
- the color tab 650 is filled with red color when it is above the middle line 630, and filled with green color when it is above the muddle line 630.
- the filled color increases its brightness when the color tab 650 deviates from the middle line 630.
- the upper circle 610 fills with red color when the vehicle is ahead of the schedule.
- the color and brightness of the upper circle 610 is synchronized with the color and brightness of the color tab 650, when color tab 650 is above the middle line 630.
- the lower circle 620 fills with green color when the vehicle is behind the schedule.
- the color and brightness of the lower circle 620 is synchronized with the color and brightness of the color tab 650, when color tab 650 is below the middle line 630.
- the upper and lower circles filled with colors 610 and 620 make the vehicle operator easy to recognize whether he is ahead of or behind the schedule.
- FIG. 7 illustrates an example process of scheduling a vehicle of a transportation route.
- an in-vehicle controller receives status data of other vehicles of the transportation route, via a network from other in-vehicle controllers placed in the other vehicles.
- the in-vehicle controller detects status data of the vehicle.
- the in-vehicle controller determines an operating instruction based on the status data of the other vehicles and the status data of the vehicle.
- the status data of the other vehicles includes position and velocity data of the other vehicles.
- the status data of the other vehicles includes status values indicating whether the other vehicles are during station arrival, station departure, or station skipping.
- the in-vehicle controller presents the operating instruction to an operator of the vehicle.
- the operating instruction includes a time period for which the operator is to hold the vehicle at a station, or a visual indication of an extent of the vehicle being ahead of or behind a schedule.
- the operating instruction can further include an audio signal to prompt the operator to move the vehicle.
- vehicle riders can receive real-time estimates of the time until the next bus arrives at a particular stop, accessed through any internet enabled device, including cell phones, desktop web-browsers, supplementing in- vehicle information displays.
- additional in-vehicle devices can be positioned in the bus to display passenger relevant information such as the location of the bus, connecting lines with arrival times, landmarks and local maps.
- a passenger may find that even if she arrives at a station prior to the estimated arrival time, the bus has already left. There is some uncertainty with bus arrival prediction.
- the control feature enables guarantees that the next bus at a particular station will not depart earlier than a specified time. If a rider requests a guaranteed minimal arrival time, the central controller notifies the control system, instructing the driver to hold the bus at the corresponding stop, thus honoring the guarantee. It should be noted that the guarantee time is calculated so that it is very unlikely that the bus will arrive before that time; therefore the holding times required to honor guarantees will not affect overall system performance substantially.
- the in-vehicle computing device and automated dispatching system can be used to adjust to unexpected vehicle failures, dynamically rescheduling the route if necessary. This is different from the pre-scheduled systems, which tend to experience widespread problems stemming from local disruptions.
- the in-vehicle computing device and automated dispatching system can be used to synchronize transfers between intersecting routes or hierarchical "branch-trunk" systems. Buses on overlapping or intersecting lines can be made to arrive at certain hub stations in close temporal proximity. They can then be held long enough for passengers to transfer to one another, thereby guaranteeing connections.
- the in-vehicle computing device can be used to sense bus maintenance needs and log maintenance activities.
- the in-vehicle computing device can be used to quickly process passenger payments, speeding up the boarding process.
- the in-vehicle computing device can be used to monitor and evaluate the driving performance of bus drivers.
- the in-vehicle computing device and automated dispatching system can be used to dynamically schedule driver breaks at the convenience of drivers.
- the in-vehicle device can solicit customer feedback on the ride experience.
- the in-vehicle device can display real-time location- based advertising.
- FIG. 8 is a high-level block diagram showing an example of the architecture of a device 800, which may represent any of the in-vehicle controllers.
- the device 800 includes one or more processors 810 and memory 820 coupled to an interconnect 830.
- the interconnect 830 shown in FIG. 8 is an abstraction that represents any one or more separate physical buses, point to point connections, or both connected by appropriate bridges, adapters, or controllers.
- the interconnect 830 may include, for example, a system bus, a Peripheral Component Interconnect (PCI) bus or PCI-Express bus, a HyperTransport or industry standard architecture (ISA) bus, a small computer system interface (SCSI) bus, a universal serial bus (USB), IIC (I2C) bus, or an Institute of Electrical and Electronics Engineers (IEEE) standard 1394 bus, also called "Firewire”.
- PCI Peripheral Component Interconnect
- ISA industry standard architecture
- SCSI small computer system interface
- USB universal serial bus
- I2C IIC
- IEEE Institute of Electrical and Electronics Engineers
- the processor(s) 810 is/are the central processing unit (CPU) of the storage controller 800 and, thus, control the overall operation of the device 800. In certain embodiments, the processor(s) 810 accomplish this by executing software or firmware stored in memory 820.
- the processor(s) 810 may be, or may include, one or more programmable general-purpose or special-purpose microprocessors, digital signal processors (DSPs), programmable controllers, application specific integrated circuits (ASICs), programmable logic devices (PLDs), trusted platform modules (TPMs), or the like, or a combination of such devices.
- the memory 820 is or includes the main memory of the device 800.
- the memory 820 represents any form of random access memory (RAM), read-only memory (ROM), flash memory, or the like, or a combination of such devices.
- the memory 820 may contain, among other things, code 870 embodying at least a portion of an operating system of the device 800. Code 870 may also include instructions for executing the techniques disclosed herein.
- the network adapter 840 provides the device 800 with the ability to communicate with devices, such as other in-vehicle controllers, over a network and may be, for example, an Ethernet adapter or Fibre Channel adapter. In some embodiments, a device may use more than one network adapter to deal with the communications within and outside of the data storage cluster separately.
- the storage adapter 850 allows the device 800 to access a persistent storage, and may be, for example, a Fibre Channel adapter or SCSI adapter.
- Device 800 can further includes a spatial positioning adapter 860 for collecting spatial navigation data.
- the code 870 stored in memory 820 may be implemented as software and/or firmware to program the processor(s) 810 to carry out actions described below.
- such software or firmware may be initially provided to the device 800 by downloading it from a system through the device 800 (e.g., via network adapter 840).
- programmable circuitry e.g., one or more microprocessors
- Special-purpose hardwired circuitry may be in the form of, for example, one or more application-specific integrated circuits (ASICs), programmable logic devices (PLDs), field-programmable gate arrays (FPGAs), etc.
- ASICs application-specific integrated circuits
- PLDs programmable logic devices
- FPGAs field-programmable gate arrays
- Machine-readable storage medium includes any mechanism that can store information in a form accessible by a machine (a machine may be, for example, a computer, network device, cellular phone, personal digital assistant (PDA), manufacturing tool, any device with one or more processors, etc.).
- a machine-accessible storage medium includes recordable/non- recordable media (e.g., read-only memory (ROM); random access memory (RAM); magnetic disk storage media; optical storage media; flash memory devices; etc.), etc.
- logic can include, for example, programmable circuitry programmed with specific software and/or firmware, special-purpose hardwired circuitry, or a combination thereof.
Landscapes
- Physics & Mathematics (AREA)
- General Physics & Mathematics (AREA)
- Life Sciences & Earth Sciences (AREA)
- Atmospheric Sciences (AREA)
- Engineering & Computer Science (AREA)
- Radar, Positioning & Navigation (AREA)
- Remote Sensing (AREA)
- Traffic Control Systems (AREA)
Abstract
The present invention contemplates a distributed automatic control system for preventing the vehicle bunching. Information of vehicle locations is automatically detected and used to determine the positions and velocities of vehicles along a route. Vehicles pass predetermined points, such as stations, along the route. Information about whether the vehicle skipped the station, arrived at the station, or departed from the station, is automatically calculated based on the position and velocity information. This information is distributed among the vehicles that belong to the same route. An in-vehicle controller dynamically calculates holding times at each station and displays the information to the driver so that buses do not get too close to one another, thereby preventing bunching while maintaining appropriate speeds of the vehicles.
Description
AUTOMATED SYSTEM FOR PREVENTING VEHICLE BUNCHING CROSS-REFERENCE TO RELATED APPLICATION
[0001] This application claims to the benefit of U.S. Provisional Patent Application No. 61/578,179, entitled "AUTOMATED SYSTEM FOR PREVENTING VEHICLE BUNCHING", which was filed on December 20, 201 1 , which is incorporated by reference herein in its entirety.
TECHNICAL FIELD
[0002] At least one embodiment of the present invention pertains to a distributed automatic control system for preventing bus bunching and promoting schedule adherence in transit systems.
BACKGROUND
[0003] Bus bunching (also referred to as clumping, clustering, or platooning) describes the tendency of buses along a particular transit route to pair or bunch together despite being scheduled to appear at constant intervals. If buses are scheduled to run a certain headway time apart, passengers arriving to a station should not expect to wait more than the headway time for the next bus to arrive. If passengers arrive at a random time, the average waiting time is a half of the headway time. If two buses pair, passengers may wait as long as two headways. If more than two buses bunch up, the wait can be even longer.
[0004] These unfavorable outcomes are familiar to regular bus riders. Studies of bus systems reveal that they are prone to instability and bunching. This is at least partially due to the undesired feedback loop between bus headways and the time it takes to load passengers at each station. If a bus falls behind schedule, more passengers tend to accumulate than if it were running the scheduled time ahead of it. Increased passenger accumulation requires the laggard bus to wait even longer at each station, further retarding its progress. Conversely, buses ahead of schedule tend to pick up fewer passengers and can go even further ahead of schedule. The result is bus bunching.
[0005] Bus bunching or clustering is discussed in several references, such as US Pat. 3,772,691 , US Pat. 5,739,774, US Pat. 6,006,159, US Pat. 6,374,176 and US
Patent Publication 2010/0299177, all of which are incorporated herein by reference in their entireties.
[0006] Conventional ways to control bus bunching involve the insertion of a fixed slack time into the schedule at certain points along the route. This slack artificially delays buses and the passengers on board. This conventional technique has limited effectiveness in reducing bus bunching, while bus operators must use more buses to cover the same route, adding operating cost. Furthermore, passengers in the transit must wait longer at each station as the slack time is absorbed. The slack technique is not adaptive to severe disruptions in which the amount of slack is insufficient and thus bunching can still occur.
SUMMARY
[0007] Techniques introduced here provide a distributed automatic control system for preventing the vehicle bunching. Information of vehicle locations is automatically detected and used to determine the positions and velocities of vehicles along a route. Vehicles pass predetermined points, such as stations, along the route. Information about whether the vehicle skipped the station, arrived at the station, or departed from the station, is automatically calculated based on the position and velocity information. This information is distributed among the vehicles that belong to the same route. An in-vehicle controller dynamically calculates holding times at each station and displays the information to the driver so that buses do not get too close to one another, thereby preventing bunching while maintaining appropriate speeds of the vehicles.
[0008] According to one embodiment, a distributed transportation control system for vehicles of a transportation route is disclosed herein. The system includes a plurality of in-vehicle controllers. Each in-vehicle controller is placed in one of the vehicles of the transportation route. Each in-vehicle controller includes a network interface, a spatial positioning device, a signaling device and a processor. The network interface is configured to exchange status data of the vehicles, with other in- vehicle controllers of the plurality of in-vehicle controllers. The spatial positioning device is configured to continuously collect status data of a individual vehicle in which that in-vehicle controller is placed. The signaling device is configured to provide an operating instruction to an operator of the individual vehicle in which that
in-vehicle controller is placed. The processor is configured to determine the operating instruction based on the status data of the vehicles.
[0009] According to another embodiment, a method for scheduling a vehicle of a transportation route is disclosed herein. The method includes steps of receiving status data of other vehicles of the transportation route, via a network from other in- vehicle controllers placed in the other vehicles; detecting status data of the vehicle; determining an operating instruction based on the status data of the other vehicles and the status data of the vehicle; and presenting the operating instruction to an operator of the vehicle.
[0010] Other aspects of the technology introduced here will be apparent from the accompanying figures and from the detailed description which follows.
BRIEF DESCRIPTION OF THE DRAWINGS
[0011] These and other objects, features and characteristics of the present invention will become more apparent to those skilled in the art from a study of the following detailed description in conjunction with the appended claims and drawings, all of which form a part of this specification. In the drawings:
[0012] FIG. 1 illustrates an example of a transportation route having multiple buses utilizing a distributed transportation control system.
[0013] FIG. 2 illustrates an example of an in-vehicle controller of a distributed transportation control system for preventing the vehicle bunching.
[0014] FIG. 3 illustrates relevant information for determining vehicle status.
[0015] FIG. 4 illustrates an example process of determining vehicle status events.
[0016] FIG. 5 illustrates an example of a vehicle operator interface of a signaling device.
[0017] FIG. 6 illustrates another example of a vehicle operator interface of a signaling device.
[0018] FIG. 7 illustrates an example process of scheduling a vehicle of a transportation route.
[0019] FIG. 8 is a high-level block diagram showing an example of the architecture of a device, which may represent any of the in-vehicle controllers.
DETAILED DESCRIPTION
[0020] References in this specification to "an embodiment," "one embodiment," or the like, mean that the particular feature, structure, or characteristic being described is included in at least one embodiment of the present invention. Occurrences of such phrases in this specification do not all necessarily refer to the same embodiment, however.
[0021] FIG. 1 illustrates an example of a transportation route having multiple buses utilizing a distributed transportation control system. As showed in the FIG.1 , there are three buses 130 running along a transportation route 1 10. Buses are scheduled to stop at a plurality of bus stations 1 15 along the transportation route 1 10. The distributed transportation control system includes a plurality of in-vehicle controllers 120. Each bus 130 has one in-vehicle controller 120 placed inside of the bus. The in-vehicle controllers 120 collect status data of the buses 130. The in- vehicle controllers 120 exchange status data via a network 140. The network 140 can include a WiFi network, a mobile phone network, a satellite network, a wireless data network, the Internet, or any combinations thereof. The techniques disclosed herein can be used in any type of vehicles for transportation, such as buses, taxis, automobiles, trains, aircrafts, motorcycles, bicycles, planes, boats, ships, or spaceships.
[0022] FIG. 2 illustrates an example of an in-vehicle controller of a distributed transportation control system for preventing the vehicle bunching. The control system solves the scheduling problems incurred by both users and operators of transit systems. Information of vehicle locations is automatically detected and used to determine the positions and velocities of vehicles along a route. Vehicles pass predetermined points, such as stations, along the route. Information about whether the vehicle skipped the station, arrived at the station, or departed from the station, is automatically calculated based on the position and velocity information.
[0023] As shown in the FIG. 2, the in-vehicle controller 200 (also referred to as in- vehicle unit) includes a GPS (Global Positioning System) unit 210. While in operation, the GPS unit 210 continuously collects the location coordinates of the GPS unit 210, which is also the location coordinates of the bus in which the in- vehicle controller 200 is placed. The GPS unit 210 can further generate velocity data
of the bus. The GPS unit 210 transmits the location and velocity data to a network interface 220 (also referred to as communication unit). Using the location and velocity data, the in-vehicle controller 200 can further detect status of bus using a detector 230. For example, comparing the location and velocity data of the bus with the locations of the stations of the route, the detector 230 can determine a status value indicating whether the bus is during station arrival, station departure, or station skipping. The status value can also be transmitted to the network interface 220. In one embodiment, the location information of the vehicles may be collected from satellite navigation devices, such as GPS devices, or other types of spatial positioning devices.
[0024] The network interface 220 transmits these data to other in-vehicle controllers 290 via a network channel 280. The network interface 220 also receives status data of other buses from the other in-vehicle controllers 290 via the network channel 280. The network interface 220 forward these received status data to a bunch prevention controller 240.
[0025] The bunch prevention controller 240 generates an operation instruction to an operator of the bus, based on the received status data of other buses as well as the status data of the bus. In one embodiment, the operation instruction includes a holding time, which is a time period for which the operator is to hold the bus at a station. In another embodiment, the operation instruction includes a visual indication of an extent of the bus being ahead of or behind a schedule. The operating instruction may further include an audio signal to prompt the operator to move the individual vehicle.
[0026] In some embodiments, the detector 230 and the bunch prevention controller 240 are implemented as a single processor configured to operate as both the detector 230 and the bunch prevention controller 240.
[0027] A signaling device is responsible for presenting the operation instruction to the operator of the bus. For example, the signal device can visualize the time period for which the operator is to hold the bus at a station, or the extent of the bus being ahead of or behind a schedule. The signaling device can play an audio message to prompt the operator to start moving the bus along the route.
[0028] The in-vehicle controller 200 can further include a passenger information service 260. The passenger information service 260 can present minimum arrival guarantee, or next arrival estimation to a passenger on the bus. In some embodiments, the passenger information service can be implemented as a device separated from and connected to the in-vehicle controller 200.
[0029] In one embodiment, there may be a central operator module 270. The central operator module 270 can listen and receive the status data from the in- vehicle controllers. The central operator module 270 can analyze the status data and present visualized information to a central operator. Based on the visualized information, the central operator can send manual control input via the communication channel 280 to manually instruct operators of the buses along the route.
[0030] In one embodiment, an analytics engine 272 can be included in the central operator module 270. The analytics engine 272 provides a virtual schedule for buses to follow and calculate parameters to be used in the control system. In one embodiment, if desired, a human operator is able to adjust the parameters in the analytics engine or send messages manually to the operators of the vehicles. The system is capable of running automatically without manual intervention. This simplifies or eliminates the operator's task and is capable of making the high rate of pre-emptive, measured control decisions before noticeable disruptions to service can arise.
[0031] Using the techniques disclosed herein, the status information of the vehicle is distributed among the vehicles that belong to the same route. An in- vehicle controller dynamically calculates holding times at each station and displays the information to the driver so that buses do not get too close to one another, thereby preventing bunching while maintaining appropriate speeds of the vehicles.
[0032] The Information about whether the vehicle skipped the station, arrived at the station, or departed from the station, is automatically calculated based on the position and velocity information as illustrated in FIG. 3. Based on the GPS coordinates and the velocity data of the vehicle, the position and speed of the vehicle are projected onto the route path. A station buffer range is predetermined around the station location. Judging from the relative position of the vehicle from the station
buffer along the route path, as well as the speed of the vehicle, the distributed transportation control system determines the vehicle status of station arrival, station departure, or station skipping.
[0033] FIG. 4 illustrates an example process of determining vehicle status events. In one embodiment, the vehicle status events include station arrivals (approaching a station); departures (leaving a station), and skips (passing through a station without stopping). The in-vehicle controller determines the status event based on the velocity of the bus and the projection of its GPS coordinates along the route. As shown in the FIG. 4, for instance, when the in-vehicle controller detects that the vehicle is between stations and the vehicle is projected to be reaching a station buffer at a low speed, the in-vehicle controller determines the status event as station arrival. When the in-vehicle controller detects that the vehicle is within a station buffer at a low speed and the vehicle changes to a high speed, the in-vehicle controller determines the status event as station departure.
[0034] Similarly, when the in-vehicle controller detects that the vehicle is within a station buffer at a high speed and the vehicle is projected in the station buffer at a high speed, the in-vehicle controller determines the status event as station arrival. When the in-vehicle controller detects that the vehicle is within a station buffer at a high speed and the vehicle is projected out of the station buffer, the in-vehicle controller determines the status event as station skipping.
[0035] In one embodiment, once the status event changes, the in-vehicle device transmits the time at which the vehicle arrived, departed or skipped a particular station, which helps limiting the amount of communication required for the system to work.
[0036] FIG. 5 illustrates an example of a vehicle operator interface of a signaling device. Detection of vehicle status events allows the vehicle operator interface to switch between different display modes. In one embodiment, the operation of the vehicle operator interface does not rely on any communication with a centralized server. Between stations, a vehicle operator receives visual cues how far ahead of or behind schedule he is, so the vehicle operator can regulate the speeds of his vehicle accordingly. As shown in the FIG. 5, the vehicle operator interface visualizes a tab above a middle line to indicate the vehicle is ahead of the schedule, or a tab
below the middle line to indicate the vehicle is behind the schedule. The extent that the visualized tab deviates from the middle line indicates the extent that the vehicle is ahead of or behind the schedule.
[0037] When an arrival at a station is detected, the in-vehicle controller in the vehicle calculates a holding time based on previous bus arrivals and the display will count down time until the bus is released from the station. This control information is presented to the vehicle operator through audio and visual signals as shown in FIG. 5. When the in-vehicle controller determines that the holding time lapses, it visualizes a "go" message and plays an audio message to prompt the vehicle operator to start moving the vehicle for departure.
[0038] FIG. 6 illustrates another example of a vehicle operator interface of a signaling device. The vehicle operator interface 600 includes a schedule bar 640 with a middle line 630. The vehicle operator interface 600 visualizes a color tab 650 above a middle line to indicate the vehicle is ahead of the schedule, or a tab below the middle line to indicate the vehicle is behind the schedule. The extent that the visualized tab deviates from the middle line indicates the extent that the vehicle is ahead of or behind the schedule. In one embodiment, the color tab 650 is filled with red color when it is above the middle line 630, and filled with green color when it is above the muddle line 630. In another embodiment, the filled color increases its brightness when the color tab 650 deviates from the middle line 630.
[0039] The upper circle 610 fills with red color when the vehicle is ahead of the schedule. In one embodiment, the color and brightness of the upper circle 610 is synchronized with the color and brightness of the color tab 650, when color tab 650 is above the middle line 630. Similarly, the lower circle 620 fills with green color when the vehicle is behind the schedule. In one embodiment, the color and brightness of the lower circle 620 is synchronized with the color and brightness of the color tab 650, when color tab 650 is below the middle line 630. The upper and lower circles filled with colors 610 and 620 make the vehicle operator easy to recognize whether he is ahead of or behind the schedule.
[0040] FIG. 7 illustrates an example process of scheduling a vehicle of a transportation route. At step 710, an in-vehicle controller receives status data of other vehicles of the transportation route, via a network from other in-vehicle
controllers placed in the other vehicles. At step 720, the in-vehicle controller detects status data of the vehicle. At step 730, the in-vehicle controller determines an operating instruction based on the status data of the other vehicles and the status data of the vehicle. In one embodiment, the status data of the other vehicles includes position and velocity data of the other vehicles. In another embodiment, the status data of the other vehicles includes status values indicating whether the other vehicles are during station arrival, station departure, or station skipping.
[0041] At step 740, the in-vehicle controller presents the operating instruction to an operator of the vehicle. In one embodiment, the operating instruction includes a time period for which the operator is to hold the vehicle at a station, or a visual indication of an extent of the vehicle being ahead of or behind a schedule. The operating instruction can further include an audio signal to prompt the operator to move the vehicle.
[0042] In addition to controlling bus bunching, the system can be leveraged to provide additional functionality disclosed in the following paragraphs.
[0043] In one embodiment, vehicle riders can receive real-time estimates of the time until the next bus arrives at a particular stop, accessed through any internet enabled device, including cell phones, desktop web-browsers, supplementing in- vehicle information displays.
[0044] In one embodiment, additional in-vehicle devices can be positioned in the bus to display passenger relevant information such as the location of the bus, connecting lines with arrival times, landmarks and local maps.
[0045] In one embodiment, a passenger may find that even if she arrives at a station prior to the estimated arrival time, the bus has already left. There is some uncertainty with bus arrival prediction. To supplement most likely arrival estimates, the control feature enables guarantees that the next bus at a particular station will not depart earlier than a specified time. If a rider requests a guaranteed minimal arrival time, the central controller notifies the control system, instructing the driver to hold the bus at the corresponding stop, thus honoring the guarantee. It should be noted that the guarantee time is calculated so that it is very unlikely that the bus will arrive before that time; therefore the holding times required to honor guarantees will not affect overall system performance substantially.
[0046] In one embodiment, the in-vehicle computing device and automated dispatching system can be used to adjust to unexpected vehicle failures, dynamically rescheduling the route if necessary. This is different from the pre-scheduled systems, which tend to experience widespread problems stemming from local disruptions.
[0047] In one embodiment, the in-vehicle computing device and automated dispatching system can be used to synchronize transfers between intersecting routes or hierarchical "branch-trunk" systems. Buses on overlapping or intersecting lines can be made to arrive at certain hub stations in close temporal proximity. They can then be held long enough for passengers to transfer to one another, thereby guaranteeing connections.
[0048] In one embodiment, the in-vehicle computing device can be used to sense bus maintenance needs and log maintenance activities.
[0049] In one embodiment, the in-vehicle computing device can be used to quickly process passenger payments, speeding up the boarding process.
[0050] In one embodiment, the in-vehicle computing device can be used to monitor and evaluate the driving performance of bus drivers.
[0051] In one embodiment, the in-vehicle computing device and automated dispatching system can be used to dynamically schedule driver breaks at the convenience of drivers.
[0052] In one embodiment, the in-vehicle device can solicit customer feedback on the ride experience.
[0053] In one embodiment, the in-vehicle device can display real-time location- based advertising.
[0054] FIG. 8 is a high-level block diagram showing an example of the architecture of a device 800, which may represent any of the in-vehicle controllers. The device 800 includes one or more processors 810 and memory 820 coupled to an interconnect 830. The interconnect 830 shown in FIG. 8 is an abstraction that represents any one or more separate physical buses, point to point connections, or both connected by appropriate bridges, adapters, or controllers. The interconnect 830, therefore, may include, for example, a system bus, a Peripheral Component
Interconnect (PCI) bus or PCI-Express bus, a HyperTransport or industry standard architecture (ISA) bus, a small computer system interface (SCSI) bus, a universal serial bus (USB), IIC (I2C) bus, or an Institute of Electrical and Electronics Engineers (IEEE) standard 1394 bus, also called "Firewire".
[0055] The processor(s) 810 is/are the central processing unit (CPU) of the storage controller 800 and, thus, control the overall operation of the device 800. In certain embodiments, the processor(s) 810 accomplish this by executing software or firmware stored in memory 820. The processor(s) 810 may be, or may include, one or more programmable general-purpose or special-purpose microprocessors, digital signal processors (DSPs), programmable controllers, application specific integrated circuits (ASICs), programmable logic devices (PLDs), trusted platform modules (TPMs), or the like, or a combination of such devices.
[0056] The memory 820 is or includes the main memory of the device 800. The memory 820 represents any form of random access memory (RAM), read-only memory (ROM), flash memory, or the like, or a combination of such devices. In use, the memory 820 may contain, among other things, code 870 embodying at least a portion of an operating system of the device 800. Code 870 may also include instructions for executing the techniques disclosed herein.
[0057] Also connected to the processor(s) 810 through the interconnect 830 are a network adapter 840 and a storage adapter 850. The network adapter 840 provides the device 800 with the ability to communicate with devices, such as other in-vehicle controllers, over a network and may be, for example, an Ethernet adapter or Fibre Channel adapter. In some embodiments, a device may use more than one network adapter to deal with the communications within and outside of the data storage cluster separately. The storage adapter 850 allows the device 800 to access a persistent storage, and may be, for example, a Fibre Channel adapter or SCSI adapter. Device 800 can further includes a spatial positioning adapter 860 for collecting spatial navigation data.
[0058] The code 870 stored in memory 820 may be implemented as software and/or firmware to program the processor(s) 810 to carry out actions described below. In certain embodiments, such software or firmware may be initially provided
to the device 800 by downloading it from a system through the device 800 (e.g., via network adapter 840).
[0059] The techniques introduced herein can be implemented by, for example, programmable circuitry (e.g., one or more microprocessors) programmed with software and/or firmware, or entirely in special-purpose hardwired circuitry, or in a combination of such forms. Special-purpose hardwired circuitry may be in the form of, for example, one or more application-specific integrated circuits (ASICs), programmable logic devices (PLDs), field-programmable gate arrays (FPGAs), etc.
[0060] Software or firmware for use in implementing the techniques introduced here may be stored on a machine-readable storage medium and may be executed by one or more general-purpose or special-purpose programmable microprocessors. A "machine-readable storage medium", as the term is used herein, includes any mechanism that can store information in a form accessible by a machine (a machine may be, for example, a computer, network device, cellular phone, personal digital assistant (PDA), manufacturing tool, any device with one or more processors, etc.). For example, a machine-accessible storage medium includes recordable/non- recordable media (e.g., read-only memory (ROM); random access memory (RAM); magnetic disk storage media; optical storage media; flash memory devices; etc.), etc.
[0061] The term "logic", as used herein, can include, for example, programmable circuitry programmed with specific software and/or firmware, special-purpose hardwired circuitry, or a combination thereof.
[0062] In addition to the above mentioned examples, various other modifications and alterations of the invention may be made without departing from the invention. Accordingly, the above disclosure is not to be considered as limiting and the appended claims are to be interpreted as encompassing the true spirit and the entire scope of the invention.
Claims
1 . A distributed transportation control system for vehicles of a transportation route comprising:
a plurality of in-vehicle controllers, each in-vehicle controller being placed in one of the vehicles of the transportation route;
wherein each in-vehicle controller of the plurality of in-vehicle controllers includes:
a network interface configured to exchange status data of the vehicles, with other in-vehicle controllers of the plurality of in-vehicle controllers,
a spatial positioning device configured to continuously collect status data of an individual vehicle in which that in-vehicle controller is placed, and
a signaling device configured to provide an operating instruction to an operator of the individual vehicle in which that in-vehicle controller is placed.
2. The distributed transportation control system of claim 1 , wherein the status data of the individual vehicle in which that in-vehicle controller is placed include position and velocity data of the vehicle.
3. The distributed transportation control system of claim 1 , wherein the plurality of in-vehicle controllers are interconnected by a network, and the network includes a WiFi network, a mobile phone network, a satellite network, or a wireless data network.
4. The distributed transportation control system of claim 1 , wherein each in-vehicle controller of the plurality of in-vehicle controllers further includes:
a processor configured to determine the operating instruction based on the status data of the vehicles of the transportation route.
5. The distributed transportation control system of claim 1 , wherein the status data of the vehicles are determined based on the position and velocity data collected by the plurality of in-vehicle controllers and positions of a plurality of stations of the route;
wherein the vehicles are scheduled to stop at least one of the stations.
6. The distributed transportation control system of claim 1 , wherein the status data of the vehicles includes status values indicating whether the other vehicles are during station arrival, station departure, or station skipping.
7. The distributed transportation control system of claim 1 , wherein the operating instruction includes a time period for which the operator is to hold the individual vehicle at a station.
8. The distributed transportation control system of claim 1 , wherein the operating instruction includes a visual indication of an extent of the individual vehicle being ahead of or behind a schedule.
9. The distributed transportation control system of claim 1 , wherein the operating instruction further includes an audio signal to prompt the operator to move the individual vehicle.
10. The distributed transportation control system of claim 1 , wherein the plurality of in-vehicle controllers exchange status data via a network without the data traveling through a centralized server.
1 1 . An in-vehicle controller comprising:
a network interface configured to receive status data of other vehicles of a transportation route, via a network from other in-vehicle controllers placed in the other vehicles;
a spatial positioning device configured to continuously collect status data of the vehicle in which the in-vehicle controller is placed; a signaling device configured to provide an operating instruction to an operator of the vehicle in which the in-vehicle controller is placed; and a processor configured to determine the operating instruction based on the status data of the vehicles.
12. The in-vehicle controller of claim 1 1 , wherein the operating instruction includes a time period for which the operator is to hold the vehicle at a station, or a visual indication of an extent of the vehicle being ahead of or behind a schedule.
13. The in-vehicle controller of claim 12, wherein the time period is determined such that the vehicle will not leave a station before a guaranteed time.
14. The in-vehicle controller of claim 1 1 , wherein the processor is further configured to determine a real-time estimate of a time until a next vehicle arrives at a station.
15. The in-vehicle controller of claim 1 1 , wherein the network interface is further configured to receive status data from vehicles from a second route, and the processor is further configured to determine the operation instruction such that the vehicle at which the in-vehicle controller is placed and a second vehicle from the second route arrive at a hub station in a predetermined temporal proximity.
16. The in-vehicle controller of claim 1 1 , wherein the processor is further configured to dynamically generate a new vehicle schedule based on the status data of the vehicles.
17. The in-vehicle controller of claim 1 1 , further comprising:
a passenger display configured to display passenger information, passenger information including a location of the vehicle, connecting transportation lines with arrival times, landmarks, local maps, or realtime location-based advertisements.
18. The in-vehicle controller of claim 1 1 , wherein the processor is further configured to determine maintenance needs of the vehicle or to record maintenance activities of the vehicle.
19. The in-vehicle controller of claim 1 1 , further comprising:
a payment module configured to process passenger payments.
20. The in-vehicle controller of claim 1 1 , further comprising:
a monitoring module configured to monitor driving performance of the operator.
21 . The in-vehicle controller of claim 1 1 , wherein the processor is further configured to dynamically determine operator break schedule.
22. The in-vehicle controller of claim 1 1 , further comprising:
a feedback module configured to collect passenger feedback on ride experience.
23. The in-vehicle controller of claim 1 1 , further comprising:
a feedback module configured to collect passenger feedback on ride experience.
24. The in-vehicle controller of claim 1 1 , wherein the spatial position device is a satellite navigation device.
25. A method for scheduling a vehicle of a transportation route comprising: receiving status data of other vehicles of the transportation route, via a network from other in-vehicle controllers placed in the other vehicles; detecting status data of the vehicle;
determining an operating instruction based on the status data of the other vehicles and the status data of the vehicle; and
presenting the operating instruction to an operator of the vehicle.
26. The method of claim 25, wherein the status data of the other vehicles includes status values indicating whether the other vehicles are during station arrival, station departure, or station skipping.
27. The method of claim 25, wherein the status data of the other vehicles includes position and velocity data of the other vehicles.
28. The method of claim 25, wherein the operating instruction includes a time period for which the operator is to hold the vehicle at a station, or a visual indication of an extent of the vehicle being ahead of or behind a schedule.
29. The method of claim 25, wherein the operating instruction includes an audio signal to prompt the operator to move the vehicle.
Priority Applications (3)
Application Number | Priority Date | Filing Date | Title |
---|---|---|---|
EP12860778.5A EP2795603A4 (en) | 2011-12-20 | 2012-12-20 | Automated system for preventing vehicle bunching |
US14/367,873 US9224295B2 (en) | 2011-12-20 | 2012-12-20 | Automated system for preventing vehicle bunching |
HK15100895.9A HK1200585A1 (en) | 2011-12-20 | 2015-01-27 | Automated system for preventing vehicle bunching |
Applications Claiming Priority (2)
Application Number | Priority Date | Filing Date | Title |
---|---|---|---|
US201161578179P | 2011-12-20 | 2011-12-20 | |
US61/578,179 | 2011-12-20 |
Publications (1)
Publication Number | Publication Date |
---|---|
WO2013096675A1 true WO2013096675A1 (en) | 2013-06-27 |
Family
ID=48669504
Family Applications (1)
Application Number | Title | Priority Date | Filing Date |
---|---|---|---|
PCT/US2012/071050 WO2013096675A1 (en) | 2011-12-20 | 2012-12-20 | Automated system for preventing vehicle bunching |
Country Status (4)
Country | Link |
---|---|
US (1) | US9224295B2 (en) |
EP (1) | EP2795603A4 (en) |
HK (1) | HK1200585A1 (en) |
WO (1) | WO2013096675A1 (en) |
Cited By (5)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
US20150332354A1 (en) * | 2014-05-15 | 2015-11-19 | Ting Wang | Flexible fare bus framework to reduce bus bunching |
CN106448139A (en) * | 2016-11-18 | 2017-02-22 | 山东浪潮云服务信息科技有限公司 | Intelligent bus scheduling method and intelligent bus scheduling device |
EP3206199A1 (en) * | 2016-02-12 | 2017-08-16 | ALSTOM Transport Technologies | Predictive multimodal land transportation supervision |
CN111311909A (en) * | 2020-02-19 | 2020-06-19 | 河海大学 | Method for controlling vehicles leaving station at bay bus stop in lane and road cooperative environment |
CN114613123A (en) * | 2022-02-17 | 2022-06-10 | 华录智达科技股份有限公司 | Public transportation intelligent scheduling method based on big data |
Families Citing this family (7)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
US9659492B2 (en) * | 2013-01-11 | 2017-05-23 | Here Global B.V. | Real-time vehicle spacing control |
US9858542B2 (en) | 2013-07-31 | 2018-01-02 | International Business Machines Corporation | Real-time prediction and correction of scheduled service bunching |
CN108399779B (en) * | 2018-04-26 | 2020-11-24 | 中国联合网络通信集团有限公司 | Vehicle scheduling processing method, device, equipment and storage medium |
US10911572B2 (en) * | 2018-10-01 | 2021-02-02 | Renovo Motors, Inc. | Systems and methods for dynamic application management with an autonomous vehicle |
JP6973435B2 (en) * | 2019-03-18 | 2021-11-24 | トヨタ自動車株式会社 | Operation control device, operation control method, and vehicle |
EP3942377B1 (en) | 2019-03-22 | 2023-08-23 | Volvo Truck Corporation | A method for controlling vehicles in a mission along a route |
CN110211406B (en) * | 2019-05-27 | 2021-03-26 | 同济大学 | Bus arrival speed guide control method and system |
Citations (8)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
US5390120A (en) * | 1992-12-08 | 1995-02-14 | Eaton Corporation | Method and apparatus for determining a need for vehicle braking system maintenance |
US5808565A (en) * | 1996-02-20 | 1998-09-15 | E-Systems, Inc. | GPS triggered automatic annunciator for vehicles |
US6374176B1 (en) * | 1996-08-13 | 2002-04-16 | Nextbus Information Systems, Inc. | Public transit vehicle arrival information system |
US6405112B1 (en) * | 1998-02-09 | 2002-06-11 | Gary A. Rayner | Vehicle operator performance monitor with enhanced data retrieval capabilities |
US6700506B1 (en) * | 2000-09-14 | 2004-03-02 | Everyday Wireless, Inc. | Bus arrival notification system and methods related thereto |
US6791471B2 (en) * | 2002-10-01 | 2004-09-14 | Electric Data Systems | Communicating position information between vehicles |
US6965829B2 (en) * | 2002-09-05 | 2005-11-15 | Kabushiki Kaisha Toshiba | On-vehicle electronic apparatus |
US20080012733A1 (en) * | 2006-07-06 | 2008-01-17 | Agustin Bermudez | System for information, location and schedule control for passenger transport vehicle |
Family Cites Families (25)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
US6437743B1 (en) * | 1992-12-04 | 2002-08-20 | Yosef Mintz | Method and system for mapping and tracking information from a plurality of remote stations |
US5948040A (en) * | 1994-06-24 | 1999-09-07 | Delorme Publishing Co. | Travel reservation information and planning system |
US6006159A (en) * | 1995-08-14 | 1999-12-21 | Schmier; Kenneth J. | Public transit vehicle arrival information system |
US5799263A (en) * | 1996-04-15 | 1998-08-25 | Bct Systems | Public transit system and apparatus and method for dispatching public transit vehicles |
US5739774A (en) * | 1996-07-12 | 1998-04-14 | Olandesi; Antonio Carlos Tambasco | Mass transit monitoring and control system |
JP3127918B1 (en) * | 1999-07-14 | 2001-01-29 | 住友電気工業株式会社 | Road-to-vehicle communication system, roadside communication station and on-vehicle mobile station |
US6934137B2 (en) * | 2001-02-20 | 2005-08-23 | Radiant Power Corporation | Peer-to-peer control and decision making system |
EP1391862B1 (en) * | 2002-08-20 | 2007-10-17 | Telefonaktiebolaget LM Ericsson (publ) | Traffic management system based on packet switching technology including packet to object synchronization mechanisms |
US20050137754A1 (en) * | 2002-10-21 | 2005-06-23 | Bartlett Alan L. | Transportation notification, emergency response, and surveillance system |
US7188025B2 (en) * | 2003-12-18 | 2007-03-06 | International Business Machines Corporation | Method and apparatus for exchanging traffic condition information using peer to peer networking |
US7515064B2 (en) * | 2005-06-16 | 2009-04-07 | Global Traffic Technologies, Llc | Remote activation of a vehicle priority system |
US7469827B2 (en) * | 2005-11-17 | 2008-12-30 | Google Inc. | Vehicle information systems and methods |
EP1895485A1 (en) * | 2006-08-31 | 2008-03-05 | Hitachi, Ltd. | Road congestion detection by distributed vehicle-to-vehicle communication systems |
US7609172B2 (en) * | 2006-10-12 | 2009-10-27 | Garmin Ltd. | System and method for providing real-time traffic information |
US7999701B1 (en) * | 2008-06-26 | 2011-08-16 | Bin Xu | Transportation notification system |
US8515654B2 (en) * | 2008-09-23 | 2013-08-20 | Microsoft Corporation | Mobile data flow collection and dissemination |
US8818258B2 (en) * | 2008-10-14 | 2014-08-26 | Cirrus Systems, Llc | Geographically-based information distribution system |
US20100169803A1 (en) * | 2008-12-05 | 2010-07-01 | Elizabeth Mazzei | Method and System for Implementing User Generated Preferences in a Communication System |
US8433341B2 (en) * | 2009-02-05 | 2013-04-30 | Universal Metaphor, Llc | System and methods for distributed tracking of public transit vehicles |
US8576069B2 (en) * | 2009-10-22 | 2013-11-05 | Siemens Corporation | Mobile sensing for road safety, traffic management, and road maintenance |
US8400294B2 (en) * | 2009-12-21 | 2013-03-19 | Garmin Switzerland Gmbh | Transit stop detection |
AU2011226623B2 (en) * | 2010-03-11 | 2014-07-17 | Inrix, Inc. | Learning road navigation paths based on aggregate driver behavior |
US8878695B2 (en) * | 2011-06-27 | 2014-11-04 | Stc, Inc. | Signal light priority system utilizing estimated time of arrival |
US10382555B2 (en) * | 2012-11-13 | 2019-08-13 | Gogo Llc | Vehicle data distribution system and method |
US9659492B2 (en) * | 2013-01-11 | 2017-05-23 | Here Global B.V. | Real-time vehicle spacing control |
-
2012
- 2012-12-20 EP EP12860778.5A patent/EP2795603A4/en not_active Withdrawn
- 2012-12-20 WO PCT/US2012/071050 patent/WO2013096675A1/en active Application Filing
- 2012-12-20 US US14/367,873 patent/US9224295B2/en not_active Expired - Fee Related
-
2015
- 2015-01-27 HK HK15100895.9A patent/HK1200585A1/en unknown
Patent Citations (8)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
US5390120A (en) * | 1992-12-08 | 1995-02-14 | Eaton Corporation | Method and apparatus for determining a need for vehicle braking system maintenance |
US5808565A (en) * | 1996-02-20 | 1998-09-15 | E-Systems, Inc. | GPS triggered automatic annunciator for vehicles |
US6374176B1 (en) * | 1996-08-13 | 2002-04-16 | Nextbus Information Systems, Inc. | Public transit vehicle arrival information system |
US6405112B1 (en) * | 1998-02-09 | 2002-06-11 | Gary A. Rayner | Vehicle operator performance monitor with enhanced data retrieval capabilities |
US6700506B1 (en) * | 2000-09-14 | 2004-03-02 | Everyday Wireless, Inc. | Bus arrival notification system and methods related thereto |
US6965829B2 (en) * | 2002-09-05 | 2005-11-15 | Kabushiki Kaisha Toshiba | On-vehicle electronic apparatus |
US6791471B2 (en) * | 2002-10-01 | 2004-09-14 | Electric Data Systems | Communicating position information between vehicles |
US20080012733A1 (en) * | 2006-07-06 | 2008-01-17 | Agustin Bermudez | System for information, location and schedule control for passenger transport vehicle |
Non-Patent Citations (1)
Title |
---|
See also references of EP2795603A4 * |
Cited By (8)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
US20150332354A1 (en) * | 2014-05-15 | 2015-11-19 | Ting Wang | Flexible fare bus framework to reduce bus bunching |
US9842375B2 (en) * | 2014-05-15 | 2017-12-12 | Sap Se | Flexible fare bus framework to reduce bus bunching |
EP3206199A1 (en) * | 2016-02-12 | 2017-08-16 | ALSTOM Transport Technologies | Predictive multimodal land transportation supervision |
US10460607B2 (en) | 2016-02-12 | 2019-10-29 | Alstom Transport Technologies | Predictive multimodal land transportation supervision |
RU2738773C2 (en) * | 2016-02-12 | 2020-12-16 | Альстом Транспорт Текнолоджис | Predicative control over multimodal ground transportation |
CN106448139A (en) * | 2016-11-18 | 2017-02-22 | 山东浪潮云服务信息科技有限公司 | Intelligent bus scheduling method and intelligent bus scheduling device |
CN111311909A (en) * | 2020-02-19 | 2020-06-19 | 河海大学 | Method for controlling vehicles leaving station at bay bus stop in lane and road cooperative environment |
CN114613123A (en) * | 2022-02-17 | 2022-06-10 | 华录智达科技股份有限公司 | Public transportation intelligent scheduling method based on big data |
Also Published As
Publication number | Publication date |
---|---|
EP2795603A1 (en) | 2014-10-29 |
EP2795603A4 (en) | 2015-08-19 |
US20150046073A1 (en) | 2015-02-12 |
US9224295B2 (en) | 2015-12-29 |
HK1200585A1 (en) | 2015-08-07 |
Similar Documents
Publication | Publication Date | Title |
---|---|---|
US9224295B2 (en) | Automated system for preventing vehicle bunching | |
CN103503044B (en) | Driving supporting device | |
US7394404B2 (en) | System and method for controlling public transportation | |
JP6422812B2 (en) | Driving support device and driving support method | |
US9744981B2 (en) | Operation management device, operation management method, vehicle, vehicular traffic system, and program | |
US20180082590A1 (en) | Vehicle-to-vehicle cooperation to marshal traffic | |
US20180158331A1 (en) | Traffic intersection driving assistance method and system | |
CN104678414B (en) | Vehicle location, which makes corrections, control device and possesses its system and method | |
CN108898824A (en) | A kind of intersection bus signal priority control system and control method based on C-V2X | |
CN107944797A (en) | The monitoring method of transport task, apparatus and system | |
US11155263B2 (en) | Network computer system to control freight vehicle operation configurations | |
JP7027832B2 (en) | Operation management system and operation management program | |
CN109564728A (en) | Wireless communication system, computer program, is used to determine whether the method for using the information provided at information acquisition terminal | |
US20160210851A1 (en) | Operating management system, operating management method, and program | |
JP2014233989A5 (en) | ||
WO2014192328A1 (en) | Operation management device, operation management method, vehicle, vehicular traffic system, and program | |
TW200540038A (en) | Railway train operation control system | |
SE1251407A1 (en) | Device and method for evaluation of forward speed including vehicle train formation | |
CN109255951B (en) | Service control method and device | |
JP2016177638A (en) | Roadside control device, computer program, and information processing method | |
AU2020289820A1 (en) | Vehicle control method, vehicle-mounted device and vehicle in automatic driving fleet | |
JP2020076757A (en) | Dispersion type route determination system | |
US10150491B2 (en) | Device and method for controlling train | |
JP2020095478A (en) | Traffic management device, traffic management system, traffic management method, and computer program for traffic management | |
JPH10329718A (en) | Train operation control system |
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: 12860778 Country of ref document: EP Kind code of ref document: A1 |
|
REEP | Request for entry into the european phase |
Ref document number: 2012860778 Country of ref document: EP |
|
WWE | Wipo information: entry into national phase |
Ref document number: 2012860778 Country of ref document: EP |
|
NENP | Non-entry into the national phase |
Ref country code: DE |
|
WWE | Wipo information: entry into national phase |
Ref document number: 14367873 Country of ref document: US |