Multimodal transport management procedure and system

Abstract

Multimodal transport management procedure, comprehensive: Processing a transport request for a passenger, wherein the transport request identifies a starting point for the passenger, a destination for the passenger, and travel time information; and Identifying a multimodal timetable that meets the requirements of the transport request, wherein the multimodal timetable includes at least one vehicle segment and at least one additional segment; Monitoring the passenger's journey after the start of the multimodal timetable, for which current status or timetable information for a current segment of the multimodal timetable is obtained; characterized by Estimating a passenger arrival time at the departure point of an upcoming vehicle segment based on the received current status or timetable information; and controlling the dispatch time of an autonomous vehicle (10) according to the multimodal timetable and in response to the monitored journey of the passenger, in order to synchronize the arrival of the autonomous vehicle (10) with the arrival of the passenger at the departure point of the upcoming vehicle segment of the multimodal timetable.

Description

TECHNICAL FIELD

[0001] The present invention relates to a multimodal transport management method according to the preamble of claim 1 and a correspondingly designed system, as is essentially known from US 2016 0 298 979 A1.

[0002] Further prior art can be found in US 2016 / 0 033 289 A1. INTRODUCTION

[0003] An autonomous vehicle is a vehicle capable of sensing its surroundings and navigating with little or no user input. An autonomous vehicle senses its surroundings using sensor devices such as radar, lidar, image sensors, and the like. The autonomous vehicle system further utilizes information from global positioning systems (GPS), navigation systems, vehicle-to-vehicle communications, vehicle infrastructure technologies, and / or wired systems to navigate the vehicle.

[0004] Vehicle automation was categorized by numerical levels from zero, corresponding to no automation with full human control, to five, corresponding to full automation without human control. Various automated driver assistance systems, such as cruise control, adaptive cruise control, and parking assistance systems, correspond to lower levels of automation, while true "driverless" vehicles correspond to higher levels of automation.

[0005] Autonomous and conventional vehicles can be used to transport passengers to a desired destination. In this context, one or more vehicles can be deployed in a multimodal transportation system, allowing passengers to use other modes of transportation such as buses, trains, ferries, airplanes, subways, and the like. For example, a typical commute may involve a train ride, a bus ride, and a short taxi ride. As another example, a vacationer may fly to an airport and then take a subway or taxi to a hotel.

[0006] Accordingly, it is desirable to provide systems and methods that enable efficient and effective management of transportation routes using different modes of transport. In particular, it is desirable to have a methodology that proactively dispatches vehicles (including autonomous vehicles) to reduce passenger waiting times during a multimodal transportation route. Furthermore, other desirable functions and features of the present invention will become apparent from the following detailed description and the appended claims, taken in conjunction with the accompanying drawings, as well as the foregoing technical field and background. SUMMARY

[0007] According to the invention, a multimodal transport management method is presented which is characterized by the features of claim 1.

[0008] In addition, a computer-based system is presented which is characterized by the features of claim 6.

[0009] A computer-readable storage medium is also described. The storage medium includes computer-executable instructions stored thereon and configurable to cause a computer-based system to perform a method including the steps of: processing a transportation request for a passenger, the transportation request identifying a departure location for the passenger, a destination location for the passenger, and travel time information; identifying a multimodal schedule that meets the requirements of the transportation request, the multimodal schedule including at least one vehicle segment and at least one additional segment; monitoring the passenger's travel progress after initiating the multimodal schedule;and controlling the dispatch timing of a vehicle in accordance with the multimodal schedule and in response to the monitored passenger travel progress to synchronize the arrival of the vehicle with the arrival of the passenger at a departure location of an upcoming vehicle segment of the multimodal schedule;

[0010] This brief is provided to introduce a selection of concepts in a simplified form that are described below in the detailed description. BRIEF DESCRIPTION OF THE DRAWINGS

[0011] The exemplary embodiments are described below in conjunction with the following drawings, wherein like reference numerals denote like elements, and wherein: Fig. 1 is a functional block diagram illustrating an autonomous vehicle configured in accordance with various embodiments; Fig. 2 is a block diagram showing a multimodal transport system with one or more autonomous vehicles from Fig. 1 according to various embodiments; Fig. 3 is a functional block diagram illustrating an exemplary embodiment of a controller suitable for use in the Fig. 1 shown autonomous vehicle; Fig. 4 is a block diagram of an exemplary embodiment of a processor-based hardware platform suitable for use in various system components described herein; and Fig. Figure 5 is a flowchart illustrating an exemplary embodiment of a multimodal transportation management process. DETAILED DESCRIPTION

[0012] The following detailed description is provided for illustrative purposes only. Furthermore, there is no intention to be bound by any theory expressed or implied in the foregoing technical field, background, brief summary, or the following detailed description. As used herein, the term "module" refers to any hardware, software, firmware product, electronic control component, processing logic, and / or processor device, individually or in combination, including, but not limited to, an application-specific integrated circuit (ASIC), an electronic circuit, a processor (shared, dedicated, or grouped), and memory that executes one or more software or firmware programs, combinational logic circuitry, and / or other suitable components that provide the described functionality.

[0013] Embodiments of the present disclosure may be described herein as functional and / or logical block components and various processing steps. It should be noted that such block components may be constructed from any number of hardware, software, and / or firmware components configured to perform the required functions. For example, an embodiment of the present disclosure of a system or component may employ various integrated circuit components, such as memory elements, digital signal processing elements, logic elements, look-up tables, or the like, capable of performing multiple functions under the control of one or more microprocessors or other control devices.Furthermore, those skilled in the art will recognize that the exemplary embodiments of the present disclosure may be used in connection with any number of systems, and that the system described herein is merely one exemplary embodiment of the present disclosure.

[0014] For the sake of brevity, conventional techniques associated with signal processing, data transmission, signaling, control, and other functional aspects of the systems (and the individual control elements of the systems) may not be described in detail herein. Furthermore, the connecting lines depicted in the various figures are intended to represent exemplary functional relationships and / or physical connections between the various elements. It should be noted that many alternative or additional functional relationships or physical connections may be present in an embodiment of the present disclosure.

[0015] As mentioned with reference to Fig. 1, a control system, generally depicted at 100, is associated with a vehicle 10 according to various embodiments. Generally, the control system 100 is configured to operate the vehicle 10 autonomously when needed.

[0016] As in Fig. 1, the vehicle 10 generally includes a chassis 12, a body 14, front wheels 16, and rear wheels 18. The body 14 is disposed on the chassis 12 and substantially encloses the other components of the vehicle 10. The body 14 and the chassis 12 may together form a frame. The wheels 16, 18 are each rotatably coupled to the chassis 12 near a respective corner of the body 14.

[0017] In various embodiments, the vehicle 10 is an autonomous vehicle, and the control system 100 is integrated into the autonomous vehicle 10 (hereinafter referred to as the autonomous vehicle 10). The autonomous vehicle 10 is, for example, a vehicle that is automatically controlled to transport passengers from one location to another. The vehicle 10 is shown as a passenger car in the illustrated embodiment, but it should be noted that any other vehicle, including motorcycles, trucks, sport utility vehicles (SUVs), recreational vehicles (RVs), vessels, aircraft, etc., may be used. In one exemplary embodiment, the autonomous vehicle 10 is a so-called Level Four or Level Five automation system.A Level Four system indicates "high automation," referring to the driving mode-specific performance by an automated driving system of all aspects of the dynamic driving task, even when a human driver fails to respond appropriately to a request. A Level Five system indicates "full automation," referring to the full-time performance of an automated driving system of all aspects of the dynamic driving task under all road and environmental conditions manageable by a human driver.

[0018] As illustrated, the autonomous vehicle 10 generally includes a propulsion system 20, a transmission system 22, a steering system 24, a braking system 26, a sensor system 28, an actuator system 30, at least one data storage device 32, at least one controller 34, and a communication system 36. The propulsion system 20, in various embodiments, may include an internal combustion engine, an electric machine such as a traction motor, and / or a fuel cell propulsion system. The transmission system 22 is configured to transfer power from the propulsion system 20 to the vehicle wheels 16, 18 according to selectable gear ratios. According to various embodiments, the transmission system 22 may include a stepped-ratio automatic transmission, a continuously variable transmission, or other suitable transmission. The braking system 26 is configured to provide braking torque to the vehicle wheels 16, 18.The braking system 26 may, in various embodiments, include friction brakes, brake-by-wire, a regenerative braking system such as an electric machine, and / or other suitable braking systems. The steering system 24 influences the position of the vehicle wheels 16, 18. While depicted as a steering wheel for illustrative purposes in some embodiments, the steering system 24 may not include a steering wheel.

[0019] The sensor system 28 includes one or more sensor devices 40a-40n that sense observable conditions of the external environment and / or the internal environment of the autonomous vehicle 10. The sensor devices 40a-40n may include radars, lidars, global positioning systems, optical cameras, thermal imaging cameras, ultrasonic sensors, and / or other sensors. The actuator system 30 includes one or more actuator devices 42a-42n that control one or more vehicle features, such as the propulsion system 20, the transmission system 22, the steering system 24, and the braking system 26. In various embodiments, the vehicle features may further include interior and / or exterior vehicle features, such as doors, a trunk, and interior features, such as air, music, lighting, etc.

[0020] The communication system 36 is configured to wirelessly transmit information to and from other units 48, such as other vehicles (“V2V” communication), infrastructure (“V2I” communication), remote systems, and / or personal devices (relating to Fig. 2). In an exemplary embodiment, the wireless communication system 36 is configured to communicate over a wireless local area network (WLAN) using the IEEE 802.11 standard, via Bluetooth, or via mobile data communication. However, additional or alternative communication methods, such as a dedicated short-range radio communication (DSRC) channel, are also contemplated within the scope of the present disclosure. DSRC channels refer to one-way or two-way short- to mid-range radio communication channels specifically designed for automotive applications and a corresponding set of protocols and standards.

[0021] The data storage device 32 stores data for use in automatically controlling the autonomous vehicle 10. In various embodiments, the data storage device 32 stores defined maps of the navigable environment. In various embodiments, the defined maps are predefined and retrieved from a remote system (in further detail with respect to Fig. 2). For example, the defined maps may be assembled by the remote system and communicated to the autonomous vehicle 10 (wirelessly and / or wired) and stored in the data storage device 32. As can be appreciated, the data storage device 32 may be part of the controller 34, separate from the controller 34, or part of the controller 34 and part of a separate system. In certain embodiments, the data storage device 32 stores and updates additional information, which may be described in more detail below.

[0022] The controller 34 includes at least one processor 44 and a computer-readable storage device or media 46. The processor 44 may be a custom-made or off-the-shelf processor, a central processing unit (CPU), a graphics processing unit (GPU) among multiple processors connected to the controller 34, a semiconductor-based microprocessor (in the form of a microchip or chipset), a macroprocessor, a combination thereof, or generally any device for executing instructions. The computer-readable storage device or media 46 may include volatile and non-volatile memory in read-only memory (ROM), random access memory (RAM), and keep-alive memory (KAM). KAM is persistent or non-volatile memory that can be used to store various operating variables while the processor 44 is powered off.The computer-readable storage device or media 46 may be implemented using any of a number of known storage devices, such as PROMs (programmable read-only memory), EPROMs (electrical PROMs), EEPROMs (electrically erasable PROMs), flash memory, or any other electrical, magnetic, optical, or combination storage devices capable of storing data, some of which represent executable instructions used by the controller 34 in controlling the autonomous vehicle 10.

[0023] The instructions may include one or more separate programs, each of which includes an ordered list of executable instructions for implementing logical functions. The instructions, when executed by processor 44, receive and process signals from sensor system 28, perform logic, calculations, methods, and / or algorithms to automatically control the components of autonomous vehicle 10, and generate control signals to actuator system 30 to automatically control the components of autonomous vehicle 10 based on the logic, calculations, methods, and / or algorithms. Although in Fig. 1 only one controller 34 is shown, embodiments of the autonomous vehicle 10 may include any number of controllers 34 that communicate and cooperate via a suitable communication medium or combination of communication media to process the sensor signals, perform logic, calculations, methods and / or algorithms, and generate control signals to automatically control the functions of the autonomous vehicle 10.

[0024] With reference to Fig. 2, the autonomous vehicle 10, which with reference to Fig. 1, in various embodiments, may be suitable for use within a transportation system in a specific geographic area (e.g., a city, a county, a school or business campus, a shopping center, or the like), or may simply be managed by a remote system. For example, the autonomous vehicle 10 may be associated with a multimodal transportation system. Fig. Figure 2 illustrates an exemplary embodiment of an operating environment for a multimodal transportation system 50. The system 50 includes an autonomous vehicle system 52 that includes one or more autonomous vehicles (in Fig. 2 as AVs 10a-10n), as described above with reference to Fig. 1. In various embodiments, system 50 further includes one or more user devices 54 that communicate with autonomous vehicle 10 and / or vehicle system 52 via a communications network 56.

[0025] The communications network 56 supports communication between devices, systems, and components supported by the system 50 (e.g., via physical communication links and / or wireless communication links). For example, the communications network 56 may include a wireless carrier system 60, such as a cellular phone system, including a plurality of cellular towers (not shown), one or more mobile switching centers (MSCs) (not shown), and any other network components necessary to connect the wireless carrier system 60 to the fixed network communications system 62. Each cellular tower includes transmit and receive antennas and a base station, with the base stations of various cellular towers connected to the MSCs, either directly or through intermediary devices, such as a base station controller.The wireless carrier system 60 may implement any suitable communications technology, for example, digital technologies such as CDMA (e.g., CDMA2000), LTE (e.g., 4G LTE or 5G LTE), GSM / GPRS, or other current or emerging wireless technologies. Other cell tower / base station / MSC arrangements are possible and could be used with the wireless carrier system 60. For example, the base station and cell tower could be co-located or remote from each other, each base station could serve a single cell tower, a single base station could serve multiple cell towers, or multiple base stations could be coupled to a single MSC, to name a few of the possible arrangements.

[0026] In addition to using the wireless carrier system 60, a second wireless carrier system in the form of a satellite communications system 64 may be used to provide unidirectional or bidirectional communications with the autonomous vehicle 10a-10n. This may be accomplished using one or more communications satellites (not shown) and an uplink transmitting station (not shown). Unidirectional communications may include, for example, satellite radio services, where programmed content data (news, music, etc.) is received from the transmitting station, packaged for upload, and then transmitted to the satellite, which broadcasts the programming to subscribers. Bidirectional communications may include, for example, satellite telephone services that use the satellite to relay telephone communications between the vehicle 10 and the station.Satellite telephony can be used either in addition to or instead of the mobile operator system 60.

[0027] A fixed-line communication system 62 may further include a conventional fixed-line telecommunications network connected to one or more landline telephones and connecting the wireless carrier system 60 to the vehicle system 52. For example, the fixed-line communication system 62 may be a public switched telephone network (PSTN) such as those used to provide wired telephony, packet-switched data communications, and the Internet infrastructure. One or more segments of the fixed-line communication system 62 could be implemented using a standard wired network, a fiber optic or other optical network, a cable network, power lines, other wireless networks such as wireless local area networks (WLANs) or networks providing wireless broadband access (BWA), or any combination thereof.Furthermore, the autonomous vehicle system 52 need not be connected via the fixed network communication system 62, but could include radiotelephone equipment so that it can communicate directly with a wireless network, such as the wireless carrier system 60.

[0028] Although in Fig. 2, embodiments of the transportation system 50 may support any number of user devices 54, including multiple user devices 54 owned, operated, or otherwise used by a person. Each user device 54 supported by the system 50 may be implemented using any suitable hardware platform. In this regard, the user device 54 may be implemented in a common form factor, including: a desktop computer; a mobile computer (e.g., a tablet computer, a laptop computer, or a netbook computer); a smartphone; a video game device; a digital media player; a component of a home entertainment device; a digital camera or video camera; a wearable computing device (e.g., a smart watch, smart glasses, smart clothing); or the like.Each user device 54 supported by system 50 is embodied as a computer-implemented or computer-based device having the hardware, software, firmware, and / or processing logic necessary to perform the various techniques and methods described herein. For example, user device 54 includes a microprocessor in the form of a programmable device that includes one or more instructions stored in an internal memory structure and is operable to receive binary inputs and generate binary outputs. In some embodiments, user device 54 includes a GPS module that can receive GPS satellite signals and generate GPS coordinates based on those signals.In further embodiments, user device 54 includes cellular communication functionality such that the device performs voice and / or data communications over communication network 56 using one or more cellular communication protocols, as explained herein. In various embodiments, user device 54 includes a visual display, such as a graphical touchscreen display or other display.

[0029] The autonomous vehicle system 52 includes one or more backend server systems that may be cloud-based, network-based, or resident at the particular campus or geographic location served by the vehicle system 52. The vehicle system 52 may be staffed with at least one live advisor, at least one automated advisor, or a combination of both. The vehicle system 52 may communicate with the user devices 54 and the autonomous vehicles 10a-10n to plan trips, dispatch autonomous vehicles 10a-10n, provide notifications of transportation status, provide driving instructions, and the like. In various embodiments, the vehicle system 52 stores account information, such as subscriber authentication data, vehicle license plate numbers, profile records, behavior patterns, and other related subscriber information.

[0030] The system 50 may include any number of predefined vehicle pick-up and drop-off locations known to the vehicle system 52. Alternatively or additionally, the vehicle system 52 may utilize GPS technology (and / or other positioning techniques or methods) to pick up passengers at any location and / or drop them off at any destination. According to a typical use case workflow, a registered user of the vehicle system 52 creates a transportation request via the user device 54. The transportation request typically identifies the passenger's desired pick-up location (or current GPS location), the passenger's desired destination (which may identify a predefined vehicle stop and / or a user-specified passenger destination), and a pickup time.In this context, the travel time information may include: a specific departure time, a destination arrival time, an intermediate or intermediate destination arrival time (e.g., a transfer or layover time between two trip segments), a request for immediate passenger pickup, or any combination thereof. The vehicle system 52 receives the transportation request, processes the request as appropriate, and dispatches or controls one or more vehicles (e.g., an AV 10) so that the vehicle conveniently meets the passenger at a scheduled pickup point at the appropriate time. As explained in more detail below, the vehicle system 52 may interact with the navigation and mapping system 68 and / or any number of other transportation systems to control the dispatch of vehicles and otherwise support certain features and functions of the multimodal transportation system.

[0031] The navigation and mapping system 68 may be an independent and standalone subsystem or integrated with the vehicle system 52 and / or one of the other systems described herein. The navigation and mapping system 68 may be implemented with one or more backend server systems, which may be cloud-based, network-based, or resident at the geographic location served by the vehicle system 52. In some embodiments, the navigation and mapping system 68 includes or cooperates with compatible features, functions, or applications residing on the AVs 10 and / or on the user devices 54. For example, a user device 54 may include a locally installed navigation or mapping application that receives and processes data provided by the navigation and mapping system 68.In this context, the user device 54 may utilize cached map data or access map data provided via the communications network 56. The navigation and mapping system 68 may be used to determine the passenger transport routes to be followed by the vehicles, as well as to continuously locate and monitor the current position of passengers.

[0032] The transportation system 50 includes at least one vehicle system 52 and at least one additional transportation system available to users of the system 50. The illustrated example illustrates a variety of common transportation systems: a train / subway system 70, a ferry system 72, a bus system 74, and an airline system 76. Some or all of these transportation systems may be used in an embodiment of the system 50. In addition, any number of additional transportation systems 78 may be employed if desired. It should be noted that the concepts presented herein are applicable to any multimodal transportation system that may utilize at least one vehicle-based system and at least one non-vehicle system.

[0033] Each of the transportation systems other than the vehicle system 52 (i.e., the train / metro system 70, the ferry system 72, the bus system 74, the airline system 76, and the other transportation system(s) 78) provides a different type or mode of transportation. Any number of different modes of transportation (including vehicles) may be used to serve a route for a passenger. The different transportation systems may be operated, managed, controlled, and maintained by different entities, companies, suppliers, etc. For example, in most typical scenarios, the rail / metro system 70 and the bus system 74 are operated by a government agency or municipality, while the airline system 76 is operated by a private company or a public company. Accordingly, each transportation system may have its own backend systems.These backend systems handle the planning, billing, scheduling, monitoring, communications, and other aspects of the daily operation of the respective transportation systems. According to the embodiments described herein, each of the supported transportation systems is communicatively coupled to the vehicle system 52 (e.g., via the network 56) so that the vehicle system 52 can receive information and data to support the multimodal transportation features and functions described herein.In this context, the vehicle system 52 is configured to receive and process all or some of the following information: transportation schedules for the various transportation systems; status updates and notifications for the various transportation systems, including "on-time" status reports and the like; real-time or near-real-time location or geographic position information for trains, ferries, buses, subways, airplanes, boats, or the like; passenger preference data specific to the transportation systems; and user account and billing information specific to the transportation systems.

[0034] As explained in more detail below, the vehicle system 52 cooperates with the other transportation systems to manage multimodal transit routes for passengers. Accordingly, the vehicle system 52 obtains (or estimates) departure locations, arrival locations, departure times, and arrival times for the various transportation systems and intelligently dispatches vehicles at appropriate times coordinated with the schedules and real-time status of the other transportation systems. Furthermore, the vehicle system 52 is suitably configured to generate or retrieve one or more multimodal schedules upon a passenger request, wherein the schedules are determined based on the information received from the various transportation systems. For example, if a passenger wishes to travel from an airport to a hotel, the vehicle system 52 may recommend the following schedule: (1) Take train No.(2) Take bus number 858, which departs from the airport at 5:30 PM to the City Center station; (3) Take bus number 65, which departs from the city center bus stop at 6:50 PM, to the Main Street stop; and (4) take an autonomous vehicle from the bus stop to the hotel. Vehicle system 52 monitors the progress of the trip and dispatches an autonomous vehicle to the Main Street bus stop at a convenient time, resulting in little to no wait time for the passenger.

[0035] Fig. 3 is a functional block diagram illustrating an exemplary embodiment of the controller 34 shown in Fig. 1. According to various embodiments, the controller 34 implements an autonomous propulsion system (ADS) 100, as shown in Fig. 3. That is, suitable software and / or hardware components of the controller 34 (e.g., the processor 44 and the computer-readable storage medium 46) are used to provide an autonomous propulsion system 102 used in conjunction with the vehicle 10.

[0036] In various embodiments, the instructions of the autonomous driving system 102 may be organized by function or system. For example, the autonomous driving system 102 may, as shown in Fig. 3, include a sensor fusion system 104, a positioning system 106, a steering system 108, and a vehicle control system 110. As can be seen, in various embodiments, the instructions may be divided into any number of systems (e.g., combined, further subdivided, etc.).

[0037] In various embodiments, the sensor fusion system 104 synthesizes and processes sensor data and predicts the presence, location, classification, and / or history of objects and features of the environment of the vehicle 10. In various embodiments, the sensor fusion system 104 may include information from multiple sensors, including, but not limited to, cameras, lidars, radars, and / or any number of other types of sensors.

[0038] The positioning system 106 processes sensor data along with other data to determine a position (e.g., a local position relative to a map, an exact position relative to the lane of a road, vehicle direction, speed, etc.) of the vehicle 10 relative to its surroundings. The guidance system 108 processes sensor data along with other data to determine a route for the vehicle 10 to follow. The vehicle control system 110 generates control signals for controlling the vehicle 10 according to the determined route.

[0039] In various embodiments, the controller 34 implements machine learning techniques to support the functionality of the controller 34, such as feature detection / classification, obstacle mitigation, route traversal, mapping, sensor integration, ground truth determination, and the like.

[0040] The various systems, devices, and components of the transport system 50 may include or interact with computer- or processor-based hardware. In this context, Fig. 4 is a block diagram of an exemplary embodiment of a hardware platform 300 suitable for use in the system 50. For example, at least one instantiation of the hardware platform 300 (or the like) may be associated with each of the Fig. 2 may be used. In this context, at least one instantiation of the hardware platform 300 (or similar) may be used in each of the AVs 10, for example, as an on-board electronic control unit. The hardware platform 300 is implemented as a processor- or computer-based device, system, or component that is designed, configured, and programmed according to the requirements of the respective system or subsystem.

[0041] The illustrated embodiment of hardware platform 300 includes: a processor architecture 302 having at least one processor device; a suitable amount of memory 304 including at least one computer / processor-readable media element; a data storage device 306; device-specific hardware, software, firmware, and / or features 308; a user interface 310; a communications module 312; and a display element 314. Of course, hardware platform 300 may include additional elements, components, modules, and functions configured to support various functions unrelated to the subject matter described herein. For example, hardware platform 300 may include certain features and elements for supporting conventional functions, which may be related to the particular implementation and use of hardware platform 300.Conversely, an embodiment of the hardware platform 300 need not include all of the illustrated components. For example, an onboard control unit or a server computing device need not include a user interface 310 or a display element 314. In practice, the elements of the hardware platform 300 may be coupled together via a bus or suitable interconnect architecture 318.

[0042] Processor architecture 302 may be implemented with a general-purpose processor, a content-addressable memory, a digital signal processor, an application-specific integrated circuit, a field-programmable gate array, any suitable programmable logic device, discrete gate or transistor logic, discrete hardware components, or any combination designed to perform the functions described herein. Furthermore, at least processor architecture 302 may be implemented as a combination of computing devices, e.g., a combination of digital signal processors and a microprocessor, a plurality of microprocessors, one or more microprocessors in conjunction with a digital signal processor core, or any other configuration.

[0043] The memory 304 may be implemented as RAM, flash memory, EPROM memory, EEPROM memory, registers, a hard disk, a removable storage device, CD-ROM, or any other form of storage medium. In this context, the memory 304 may be coupled to the processor architecture 302 so that the processor architecture 302 can read information from and write information to the memory 304. Alternatively, the memory 304 may be an integral part of the processor architecture 302. As an example, the processor architecture 302 and the memory 304 may be located in an ASIC. At least a portion of the memory 304 may be implemented as a computer storage medium, e.g., a tangible, computer-readable media element on which non-transitory, processor-executable instructions are stored.The computer-executable instructions may be configurable so that, when read and executed by processor architecture 302, they cause hardware platform 300 to perform certain tasks, operations, functions, and processes, which are described in more detail herein. In this regard, memory 304 may represent a suitable implementation of such computer-readable media. Alternatively or additionally, hardware platform 300 could receive and cooperate with computer-readable media (not separately shown) implemented as a portable or mobile component or platform, e.g., a portable hard drive, a USB flash drive, an optical disk, or the like.

[0044] Data storage device 306 may be implemented with memory 304, or it may be implemented as a physically separate component. Data storage device 306 utilizes non-volatile memory technology to store and manage data on demand. For example, data storage device 306 may include flash memory and / or a hard disk formatted to store the data generated and used by the corresponding host system.

[0045] The device-specific hardware, software, firmware, and functions 308 may vary from one embodiment of the hardware platform 300 to another. For example, the device-specific hardware, software, firmware, and functions 308 support telephone functions and features when the hardware platform 300 is implemented as a mobile phone, traditional PC functions and features when the hardware platform 300 is implemented as a laptop or tablet computer, vehicle-centric functions and features when the hardware platform 300 is implemented as an on-board electronic control unit, etc. For the exemplary embodiments described herein, the autonomous vehicles 10 and the user devices 54 may include GPS receivers and / or other location-determining hardware and functionality.Thus, the vehicles 10 and / or the user devices 54 may communicate with GPS satellites and process geographic location information to calculate their current geographic location. In practice, certain portions or aspects of the device-specific hardware, software, firmware, and functions 308 may be incorporated into one or more of the other embodiments described in . Fig. 4 blocks shown can be implemented.

[0046] A user interface 310 may include or cooperate with various functions to enable a user to interact with the hardware platform 300. Accordingly, the user interface 310 may include various human-to-machine interfaces, such as a keypad, buttons, a keyboard, knobs, switches, buttons, a touchpad, a joystick, a pointing device, a virtual whiteboard, a touch screen, a microphone, or any other device, component, or function that allows the user to select options, input information, or otherwise control the operation of the hardware platform 300. The user interface 310 may include one or more graphical user interface (GUI) controls that enable a user to manipulate or otherwise interact with an application via the display element 314.

[0047] The communication module 312 facilitates data communication between the hardware platform 300 and other components required during operation of the hardware platform 300. Again with reference to Fig. 2, the communication module 312 (of the user device 54) enables the user device 54 to communicate with the vehicle system 52 and / or the navigation and mapping system 68, as needed. In practice, an embodiment of the hardware platform 300 may support wireless data communication and / or wired data communication using various data communication protocols. For example, the communication module 312 could support one or more wireless data communication protocols, techniques, or methodologies, including the following: RF; IrDA (infrared); Bluetooth; ZigBee (and other variations of the IEEE 802.15 protocol); IEEE 802.11 (any variation); IEEE 802.16 (WiMAX or any other variation); Direct Sequence Spread Spectrum; Frequency Hopping Spread Spectrum; Frequency Hopping Spread Spectrum; mobile / wireless / cordless telecommunications protocols; wireless home network communication protocols; paging network protocols; magnetic induction; satellite data communication protocols; wireless network protocols for hospitals or healthcare facilities, such as those used in the WMTS bands; GPRS; and proprietary wireless data communication protocols, such as variants of Wireless USB. In addition, the communication module 312 could include one or more wireless / wired data communication protocols, including the following: Ethernet; home network communication protocols; USB; IEEE 1394 (Firewire); hospital network communication protocols; and proprietary data communication protocols.

[0048] The display element 314 is suitably configured so that the hardware platform 300 can display and present various screens, GUIs, GUI controls, drop-down menus, auto-fill fields, text input fields, message fields, or the like. Of course, the display element 314 can also be used to display other information during operation of the hardware platform 300, as is generally known. In particular, the specific configuration, operating characteristics, size, resolution, and functionality of the display element 314 can vary depending on the practical implementation of the hardware platform 300. For example, if the hardware platform 300 is a laptop computer, the display element 314 can be a relatively large monitor. Alternatively, if the hardware platform 300 is a mobile phone, the display element 314 can be a relatively small integrated screen, which can be implemented as a touchscreen.When the hardware platform 300 is implemented in a vehicle, the display element 314 may be integrated into a dashboard, an instrument cluster, a head-up display, or the like.

[0049] Any number of autonomous vehicles 10 and / or conventional driver-assisted vehicles may be deployed in a multimodal transportation system that controls the scheduling, routing, and operation of vehicles in a manner that cooperates with at least one other mode of transportation (e.g., airplane, bus, train, subway, ferry, light rail, or the like). The non-vehicular modes of transportation do not have to be managed or operated by the same entity, agency, or company that manages the vehicles. In certain implementations, the vehicle-based transportation system includes at least one driverless vehicle that is automatically controlled to transport passengers from one location to another. In practice, however, the concepts presented herein may also be used with a transportation system that includes conventional (non-autonomous) vehicles.The subject matter disclosed herein provides enhanced features and functionality for what may be considered a standard or baseline autonomous vehicle system. To this end, an autonomous vehicle-based transportation system may be modified, enhanced, or otherwise supplemented to provide the additional functionality noted below.

[0050] The vehicle system 52 described herein can be configured to organize and manage multimodal transportation routes for passengers. In accordance with certain embodiments, the system 52 coordinates the dispatch of autonomous and / or conventional vehicles based on the arrival / departure schedules and the operational status of other available modes of transportation. In this context, Fig. 5 is a flowchart illustrating an exemplary embodiment of a multimodal transportation management process 400. The various tasks to be performed in connection with the process 400 may be performed by software, hardware, firmware, or any combination thereof. For illustrative purposes, the following description of the process 400 may refer to elements mentioned above in connection with the Fig. 1-4. It should be noted that an embodiment of the process 400 may include any number of additional or alternative tasks, and the Fig. 5 need not be performed in the order given, and the process 400 may be integrated into a larger method or process with additional functionality not described in detail herein. In addition, one or more of the tasks listed in Fig.5 may be omitted from one embodiment of process 400 as long as the intended overall functionality is maintained.

[0051] The multimodal transportation management process 400 begins by receiving and processing a transportation request for a requester / passenger (task 402). In this example, it is assumed that the request is submitted from a wireless user device, such as a smartphone owned or operated by the passenger. The request may be generated by an app running on the user device, where the app is maintained by or otherwise connected to the vehicle transportation system. The content of the request may vary from one embodiment to another and depends on the settings and configuration of the mobile application. As previously mentioned, this description assumes that the request includes a starting location for the passenger, an end destination for the passenger, and relevant travel time information (e.g.,the desired departure time, the desired arrival time, or the like). According to an exemplary use case, the request also includes or identifies relevant passenger preferences. In this context, the passenger preferences may be stored on the user device in conjunction with the mobile app and / or the passenger preferences may be loaded into the vehicle system 52 and stored / updated as needed. A passenger's preference data may influence the manner in which the vehicle system 52 creates, recommends, or presents multimodal schedules to respond to the transportation requests made by the passenger.In this context, passenger preference data can be defined as follows: reducing monetary costs for the passenger; reducing travel time; preferring certain modes of transport; minimizing or limiting the number of travel segments in the multimodal timetable; minimizing or limiting the number of different modes of transport in the multimodal timetable; and / or preferring scenic or preferential routes. In practice, any combination of passenger preferences can be used to influence the current timetable. Furthermore, some passenger preferences can be given higher weight than others to determine the current timetable.

[0052] Process 400 checks the transportation request to generate, retrieve, or otherwise obtain at least one schedule that meets the requirements of the request (task 404). Note that process 400 is capable of creating monomodal schedules with only one mode of transport and / or multimodal schedules with a plurality of different modes of transport (or multiple routes with the same mode of transport). Furthermore, task 404 may return only one schedule or a plurality of different schedules that meet the passenger request.

[0053] Although this description is not a requirement of the exemplary embodiment, task 404 assumes that it generates a plurality of multimodal schedules for the passenger. Each candidate schedule preferably meets the requirements of the transportation request. Accordingly, task 404 may consider any of the following information in any combination: the current time of day; the passenger's desired departure time; the passenger's desired arrival time (final destination or waypoint destination); the initial departure location; the final destination location; any identified waypoint destination; the current GPS position of the user device; the scheduling data for the various transportation systems; current status information for the various transportation systems; traffic or accident data; weather data; and the like.If process 400 cannot identify a schedule that meets all the requirements of the request, task 404 can generate a schedule that meets as many requirements as possible. This example assumes that process 400 receives or accesses preference data for the passenger and generates at least one candidate schedule according to the preference data. Ideally, all candidate schedules are generated according to the preference data.

[0054] In certain embodiments, process 400 may utilize any number of suitable pathfinding, graph traversal, or node matching techniques, methodologies, and algorithms to determine the candidate schedules. For example, the A* algorithm, the D* algorithm, a branch-and-bound algorithm, the Dijkstra algorithm, and similar approaches may be used in this context. More specifically, all transportation options may be integrated into a single graph, and a corresponding algorithm (e.g., A*) is applied to the graph to return a schedule that can utilize multiple modes. When using the A* algorithm, the heuristic used may be important. In this context, the A* algorithm is expressed as f(n) = g(n) + h(n), where g(n) represents the cost of traveling from the starting node n.The term h(n) is the heuristic used to estimate the cost of the lower-cost paths to the destination node. For the A* algorithm to work, the heuristic h(n) must be smaller than the cost function g(n), otherwise the A* algorithm becomes infeasible.

[0055] Process 400 may continue by sending the schedules to a user device associated with the passenger (task 406). In practice, the mobile app running on the user device is used to present (display) the candidate schedules to the passenger. This simple example assumes that at least one candidate schedule is acceptable to the passenger and the passenger can therefore simply confirm / select the desired schedule. In practice, however, the vehicle system 52 and process 400 may be configured to provide passengers with individual customizations or options that allow the passenger to view or select changes to the recommended travel plans.For example, the mobile app may display drop-down menus or interactive tables that show the transit system's schedules, the corresponding departure and destination locations, and the resulting time adjustments relative to a suggested schedule. In other words, the process 400 and the vehicle system 52 may be configured to allow the passenger to "override" a recommended schedule and / or change one or more legs of a recommended multimodal schedule.

[0056] The mobile app allows the passenger to select one of the candidate schedules, and the data identifying the selected schedule is returned to the vehicle system 202. Accordingly, the process 400 receives a selected one of the candidate schedules (task 408) to be used as the current schedule for the passenger. In this example, the identified schedule is assumed to be a multimodal schedule that includes at least one autonomous vehicle segment (a route in the total route) and at least one additional segment that uses a mode of transport other than an autonomous vehicle. The vehicle system 52 is configured to manage the current schedule, and the process 400 continues by sending an acknowledgment and, if appropriate, a first instruction to the user device (task 410).The mobile app on the user device presents (shows) the confirmation and any instructions to the passenger. The content and context of the initial instructions vary depending on the scenario. For example, they may include instructions to assist the passenger in proceeding with an upcoming section of the multimodal schedule. In this context, the instructions may direct the passenger to a specific departure location (e.g., a bus stop, train platform, road intersection, ferry terminal, airport terminal, shuttle bus pickup location, or the like) and remind the passenger of the desired departure time. The instructions may also include navigation instructions directing the passenger to the desired departure location. The instructions may also include a route or a summary of the itinerary, a map showing the planned route, billing or account information, etc.shown.

[0057] If the current schedule requires a vehicle for the first leg of the trip (the "Yes" branch of query task 412), then process 400 dispatches a vehicle at an appropriate time to the passenger's current location specified by the schedule and / or the requirements of the transportation request (task 414). Although not always required, this description assumes that task 414 dispatches an autonomous vehicle to pick up the passenger. According to certain embodiments, process 400 obtains or determines the passenger's current location and movement (if any) for the purpose of controlling and routing the dispatched vehicle. Thus, the system can calculate a dispatch path for the vehicle based on a static or dynamic passenger location.

[0058] If the first leg of the schedule does not require an automobile (the "No" branch of query task 412), then process 414 need not execute task 414 at that time. This description assumes that the first leg of the multimodal schedule begins on time with the passenger boarding the appropriate mode of transport. Process 400 continues by monitoring the passenger's travel progress after initiating the multimodal schedule (task 416). The monitoring may be based on information and data from any number of sources. In certain embodiments, for example, the monitoring determines the passenger's current location and movement in real time, substantially in real time, or on any schedule.The passenger's current location may be derived or estimated from any of the following: GPS data obtained from the passenger's mobile device; the current status or schedule information for the current leg of the itinerary (which may be reported by a control system associated with the current mode of transport); passenger status information (e.g., user interaction with the mobile application running on the passenger's device); traffic monitoring systems, or the like.

[0059] Monitoring by process 400 can be used to update the current schedule, as needed, to compensate for transportation delays, traffic, emergencies, road closures, or the like (task 418). The current schedule can also be updated or otherwise modified at the passenger's request. If the existing schedule is changed, process 400 provides confirmation and updated instructions to the user device, if needed (task 420). The updated instructions can include all of the information and functionality described above as part of the initial instructions (see task 410 and the associated description). Monitoring by process 400 is also used to control the dispatch timing and routing of vehicles according to the multimodal schedule.More specifically, accurate monitoring of the passenger's travel progress can be used to synchronize the arrival of a vehicle (autonomous or conventional) with the passenger's arrival at a departure location of an upcoming vehicle segment or leg of the schedule. Accordingly, during the current or a previous leg of the travel route, process 400 estimates or calculates the arrival time of the passengers at a departure location of an upcoming vehicle segment.The estimated arrival time may be calculated based on any of the following factors: the monitored current location and / or movement of the passenger or user device; the status or schedule information for the current mode of transport; the status or schedule information for one or more approaching modes of transport (for travel distances between the current leg and the approaching vehicle leg); traffic data; weather data; notifications from police or emergency services; etc. Again, the goal is to determine a good rendezvous time for vehicle dispatch that results in little to no wait time for the passenger at the upcoming departure location. With the passenger's desired arrival time established, the system can control the operation of a vehicle to arrive at the desired departure location at the rendezvous time.In practice, the system can estimate the travel time of the dispatched vehicle using existing techniques and technologies. In this context, the travel time can be estimated based on the required mileage, traffic data, accident data, weather data, time of day, and the like.

[0060] If a vehicle is required for the next (or an upcoming) leg of the schedule (the "Yes" branch of query task 422), then process 400 continues by scheduling an autonomous vehicle to meet the passenger at the upcoming departure location (task 424). The vehicle system controls the operation of the autonomous vehicle to route it to the desired departure location at the requested time. If a vehicle is not required for the next leg (the "No" branch of query task 422), then process 400 does not need to dispatch a vehicle. As indicated in query task 426, process 400 continues to the end of the route by continuously monitoring the status and progress of the multimodal schedule and intelligently dispatching a vehicle (if necessary) at an appropriate time.Thus, more than one vehicle can be dispatched in a controlled manner if the schedule includes multiple vehicle legs. Process 400 ends or is terminated after the passenger has reached the final destination.

Claims

[1] Multimodal transport management procedure, comprising: processing a transportation request for a passenger, the transportation request identifying a departure location for the passenger, a destination location for the passenger, and travel time information; and identifying a multimodal schedule that meets the requirements of the transport request, the multimodal schedule including at least one vehicle segment and at least one additional segment; monitoring the passenger's journey after the start of the multimodal timetable, for which purpose current status or timetable information is obtained for a current segment of the multimodal timetable; characterized by estimating a passenger arrival time at the departure location of an upcoming vehicle segment based on the received current status or schedule information; and controlling a dispatch time of an autonomous vehicle (10) according to the multimodal schedule and in response to the monitored passenger trip history to synchronize the arrival of the autonomous vehicle (10) with the arrival of the passenger at the departure location of the upcoming vehicle segment of the multimodal schedule. [2] The method of claim 1, further comprising: generating a plurality of candidate schedules that meet the requirements of the transport request; sending the plurality of candidate schedules to a user device associated with the passenger; and receiving a selected one of the plurality of candidate schedules from the user device, wherein the identifying step identifies the selected one of the plurality of candidate schedules for use as a multimodal schedule. [3] The method of claim 1, wherein the monitoring step further comprises: obtaining current status or schedule information for at least one upcoming segment of the multimodal timetable; and estimating a passenger arrival time at the departure location of the upcoming vehicle segment based on the received current status or schedule information. [4] The method of claim 1, wherein the identifying step comprises: accessing passenger preference data; and generating the multimodal timetable according to the passenger's preference data. [5] The method of claim 1, wherein the identifying step comprises: obtaining scheduling data from at least one candidate transport system providing a means of transport; and generating the multimodal timetable according to the scheduling data. [6] A computer-based system comprising a memory element and a processor device (44, 302) communicatively coupled to the memory element (46, 304), the memory element (46, 304) having computer-executable instructions stored thereon and executable by the processor (44, 302) to cause the computer-based system to perform the steps of the multimodal transportation management method of claim 1. [7] The system of claim 6, wherein the computer-executable instructions are configurable to cause the computer-based system to: Generating a plurality of candidate schedules that meet the requirements of the transport request; Sending the plurality of candidate schedules to a user device associated with the passenger; and Receiving a selected one of the plurality of candidate schedules from the user device, wherein the identifying step identifies the selected one of the plurality of candidate schedules for use as a multimodal schedule. [8] The system of claim 6, wherein the computer-executable instructions are configurable to cause the computer-based system to: Obtaining scheduling data from at least one candidate transport system providing a means of transport; and Generate the multimodal timetable according to the scheduling data.

Images