SYSTEM AND METHOD FOR REDUCING THE RISK OF VEHICLE RESOURCE DEBUSTION

Abstract

System (10) for reducing the risk of vehicle resource depletion, wherein the system (10) comprises: a memory (40) configured to contain one or more executable instructions; a controller that is configured to execute the executable instructions, wherein the controller is further configured to communicate with an efficiency module (400); The efficiency module (400) is configured to enable at least one fleet vehicle (12) to optimally perform a ride-sharing system task; a mobile computing device (57) is configured to generate initial location data, wherein the mobile computing device (57) is further configured to transmit the initial location data to the controller; The fleet vehicle (12) comprises a vehicle system and a vehicle control device (222), wherein the fleet vehicle (12) is configured to communicate with the control device, wherein the vehicle system is configured to generate secondary location data, and wherein the vehicle control device is configured to command the fleet vehicle (12) to autonomously perform one or more ride-sharing system tasks; and the executable instructions of the controller enable: Receiving the first user location data transmitted by the mobile computing device (57); Receiving the second location data sent by the fleet vehicle (12); Executing the efficiency module (400) to generate an output, wherein the output is partially based on the first location data and the second location data, wherein the output is configured to instruct the vehicle control device to instruct the fleet vehicle (12) to optimally perform the one or more ride-sharing system tasks; and Communicating the output to the fleet vehicle (12); the executable instructions of the controller further enable: to execute the efficiency module (400) to generate mapping data, resulting in a geosector-split geospatial map (500) containing one or more geosectors (502) with dynamic content data; and to calculate the dynamic content data of each geosector (502) and consequently generate a dynamic status indicator for each geosector (502).

Description

[0001] The present invention relates to a system and a method for reducing the risk of vehicle resource depletion.

[0002] The subsequently published state of the art is derived from the publications DE 10 2017 119 709 A1, WO 2017 / 164 922 A1 and DE 10 2017 101 499 A1.

[0003] For further background information, reference is made to publications US 2014 / 0 172 727 A1 and US 2016 / 0 364 678 A1. INTRODUCTION

[0004] Fleet management systems used for taxi services can deploy vehicles that are made available for customer trips. Once the system has delegated and deployed a vehicle for a customer trip, the vehicle will automatically move to the customer's location for pickup. Upon arrival, the vehicle will then transport the customer to their desired destination, drop them off, and then reposition itself to park or a central hub until the next customer trip is delegated. Understandably, this vehicle deployment and taxi process has the potential to consume significant vehicle resources.

[0005] The invention is therefore based on the objective of providing a system and a method that allow the fleet vehicles used to perform their respective taxi services while effectively reducing the risk of exhausting vehicle resources. SUMMARY

[0006] According to the invention, a system for reducing the risk of vehicle resource depletion is presented herein to solve this problem, characterized by the features of claim 1.

[0007] In certain cases, the optimal performance of one or more ride-sharing system tasks may include the fleet vehicle autonomously driving from the second location to the first location to pick up a ride-sharing system user for the purpose of taxi transportation from the first location to a subsequent third location selected by the ride-sharing system user. In one or more embodiments, the system may further include the vehicle control device being configured to monitor and analyze the output and then instruct the fleet vehicle to autonomously perform the one or more ride-sharing system tasks in accordance with the output.

[0008] In one or more embodiments, the system can comprise a plurality of fleet vehicles, each comprising a vehicle system and a vehicle control device, with each fleet vehicle configured to communicate with the controller. In these embodiments, each vehicle system is configured to generate secondary location data, and each vehicle control device is configured to command the matching fleet vehicle to autonomously perform one or more ride-sharing system tasks. Furthermore, the executable instructions in these embodiments also enable the controller to perform the efficiency module, which: receives secondary location data transmitted by each of the plurality of fleet vehicles; and selects a fleet vehicle from the plurality of fleet vehicles based at least partially on the secondary location data of the selected fleet vehicle relative to the primary location data.

[0009] The fleet vehicle may also have a power source configured to provide information about the state of charge, and the efficiency module can calculate the data of the dynamic content of each geosector, at least partially, based on the state of charge information.

[0010] In certain cases, after the output via the vehicle control device has been checked and analyzed, the vehicle control device may instruct the fleet vehicle to travel from the second location to the first location in a manner corresponding to one or more selected geosectors of the geospatial map, with each geosector being selected at least partially based on its corresponding dynamic status indicator.

[0011] Furthermore, to solve the aforementioned problem, a method for reducing the risk of vehicle resource depletion is also presented herein, which is characterized by the features of claim 5.

[0012] In one or more embodiments, the method further comprises the steps of: receiving (via the controller) updated vehicle location data transmitted by the fleet vehicle; and executing (via the controller) the efficiency module to generate an updated output, the output being based partly on the user location data and the updated vehicle location data. In one or more embodiments, the method further comprises the steps of: receiving (via the vehicle control device) the output; verifying and analyzing (via the vehicle control device) the output; and instructing (via the vehicle control device) the fleet vehicle to drive autonomously from the vehicle location to the user location. In one or more embodiments, the method further comprises the step of autonomous driving (via the fleet vehicle) from the vehicle location to the user location.

[0013] In certain cases, autonomous driving from the vehicle location to the user location may include the following steps: picking up (via the fleet vehicle) a ride-sharing user who is at the user location; and taxiing (via the fleet vehicle) the ride-sharing user to a subsequent destination selected by the ride-sharing user.

[0014] In one or more embodiments, the method further comprises the steps of: providing a plurality of fleet vehicles, each comprising a vehicle system and a vehicle control device, wherein each fleet vehicle is configured to communicate with the controller, wherein each vehicle system is configured to generate vehicle location data, and each vehicle control device is configured to command the matching fleet vehicle to autonomously drive from its respective vehicle location to the user location; receiving (via the controller) vehicle location data transmitted by each of the plurality of fleet vehicles; and selecting (at least some of) a fleet vehicle from the plurality of fleet vehicles (via the controller) based on the vehicle location data of the selected fleet vehicle with respect to the user location data.

[0015] In certain cases, the fleet vehicle may also include an energy source configured to provide state-of-charge information. In these cases, the efficiency module can calculate the dynamic content data for each geosector, at least partially, based on the state-of-charge information.

[0016] In one or more embodiments, the method further comprises the steps of: receiving (via the vehicle control device) the output; checking and analyzing (via the vehicle control device) the output; instructing (via the vehicle control device) the fleet vehicle to travel from the second location to the first location in a manner corresponding to one or more selected geosectors of the geoarea map, wherein the one or more geosectors are each selected at least partially based on their respective dynamic status indicator.

[0017] A non-volatile and machine-readable medium on which executable instructions suitable for reducing the risk of vehicle resource depletion are stored is also described herein. When such instructions are provided to and executed by a controller, the command causes the controller to: execute a destination interface of an efficiency module to receive user location data, wherein the user location data is transmitted from a mobile computing device; execute a transit interface of the efficiency module to receive vehicle location data, wherein the vehicle location data is transmitted from a fleet vehicle; execute a mapping engine and search engine of the efficiency module to generate mapping data in the form of a geosector-split area map, wherein the geosector-split area map includes one or more geosectors with dynamic content data;Executing a route optimization engine of the efficiency module to calculate the data of the dynamic content of each geosector and, as a result, generate a dynamic status indicator for each geosector; executing an instruction engine of the efficiency module to generate an output based at least partially on the dynamic status indicators of each geosector, the output being formatted to instruct the vehicle control device to command the fleet vehicle to perform an autonomous journey from the vehicle location to the user location; and communicating the output to the fleet vehicle.

[0018] The non-volatile and machine-readable memory may further contain the instructions that cause the controller to: execute a transit interface of the efficiency module to receive vehicle location data containing multiple vehicle location coordinates, whereby the vehicle location coordinates of multiple fleet vehicles are transmitted; and select one fleet vehicle from the multitude of fleet vehicles, based at least partially on the vehicle location coordinates for the selected fleet vehicle with respect to the user location data.

[0019] The foregoing features and advantages, as well as further features and advantages of the present gauges, can easily be derived from the following detailed description of the best ways of carrying out the gauges when considered in conjunction with the accompanying drawings. BRIEF DESCRIPTION OF THE DRAWINGS

[0020] The present disclosure is described below in conjunction with the drawing figures below, wherein identical reference numerals denote identical elements and wherein: Fig. Figure 1 is a block diagram showing an exemplary embodiment of a communication system capable of using the system and method disclosed herein; Fig. Figure 2 is a schematic diagram of an autonomously controlled electric vehicle according to an embodiment of the communication system of Fig. 1; Fig. Figure 3 is a schematic block diagram of an exemplary automated drive system (ADS) for the vehicle of Fig. 2; and Fig. Figure 4 is a schematic representation of an exemplary segmented geo-route efficiency control module (efficiency module) according to one aspect of the system and procedure presented herein; Fig. Section 5 presents broad aspects of an exemplary map that demonstrates the performance of the efficiency module of Fig. 4 represents; Fig. Section 6 presents technical aspects of another exemplary map, which demonstrates the performance of the efficiency module of Fig. 4 represents; Fig. 7 represents one or more additional technical aspects of the map of Fig. 6 dar; Fig. 8 represents one or more additional technical aspects of the map of Fig. 6 dar; and Fig. Figure 9 is a flowchart for an exemplary methodology for providing vehicle instructions based on the one described in Fig. 4 efficiency model shown. DETAILED DESCRIPTION

[0021] The following detailed description serves only as an example. Furthermore, there is no intention to be bound to any theory explicitly or implicitly presented in the preceding background, summary, or detailed description. The term "module" as used herein refers to an application-specific integrated circuit (ASIC), an electronic circuit, a processor (shared, dedicated, or group processor), and memory executing one or more software or firmware programs or code segments, a combinational logic circuit, and / or other suitable components that provide the described functionality.

[0022] As in Fig. Figure 1 shows an example of a communication system 10, which can be used together with examples of the system disclosed herein and / or to implement examples of the methods disclosed herein. The communication system 10 generally includes a fleet of vehicles 12, a wireless carrier system 14, a fixed network 16, and a data center 18 (i.e., the backend). It should be noted that the overall architecture, setup, operation, and individual components of the system shown are merely examples, and that differently configured communication systems can also be used to implement the examples of the system and / or methods disclosed herein.

[0023] Each fleet vehicle 12 can be any type of user-operated or autonomous vehicle (discussed below), such as a motorcycle, car, truck, bicycle, recreational vehicle (RV), boat, aircraft, etc., and is equipped with suitable hardware and software that enables communication via the communication system 10. In certain embodiments, each vehicle 12 can include a powertrain system with several generally known torque-generating devices, including, for example, one or more electric motors or traction motors that convert electrical energy into mechanical energy for vehicle propulsion.

[0024] Some of the basic vehicle hardware (20) for each fleet vehicle is generally in Fig. Figure 1 shows a telematics unit 24, a microphone 26, a loudspeaker 28, and buttons and / or controls 30 connected to the telematics unit 24. A network connection or vehicle bus 32 is operationally connected to the telematics unit 24. Examples of suitable network connections include a CAN bus, a Media-Oriented System Transfer (MOST), a Local Area Linkage Network (LIN), Ethernet, a Dedicated Short Range Communication Channel (DSRC), and other suitable connections, such as those conforming to the known ISO (International Organization for Standardization), SAE (Society of Automotive Engineers), and IEEE (Institute of Electrical and Electronics Engineers) standards and specifications.

[0025] The telematics unit 24 is a communication system that provides a variety of services through its communication with the data center 18 and generally includes an electronic processing device 38, one or more types of electronic storage 40, a cellular chipset or cellular component 34, a wireless modem 36, a dual-mode antenna 70, and a navigation unit containing a GPS chipset / component 42 that can transmit information about the vehicle's location via a GPS satellite system 65. The GPS component 42 thus receives coordinate signals from a constellation of GPS satellites 65. From these signals, the GNSS component 42 can determine the vehicle's position, which can be used to provide navigation and other position-related services to the driver.Navigation information can be displayed on a screen of the telematics unit 24 (or another display within the vehicle) or presented verbally, as is the case, for example, with turn-by-turn navigation. The navigation services can be provided using an associated vehicle navigation module (which may be part of the GPS component 42), or some or all of the navigation services can be provided via the telematics unit 24, in which the position coordinate information for equipping the vehicle with navigation maps, map annotations, route calculations, and the like to a remote location is provided.

[0026] The telematics unit 24 can provide various services, including: detailed directions and other navigation-related services provided in conjunction with the GPS component 42; airbag deployment notification and other emergency or breakdown-related services provided in conjunction with various accident or impact sensor interface modules 66 and impact sensors 68 located throughout the vehicle; and / or infotainment-related services in which music, internet websites, movies, television programs, video games, and / or other content are downloaded from an infotainment center 46, which is operatively connected to the telematics unit 24 via a vehicle bus 32 and an audio bus 22. In one example, the downloaded content is saved for immediate or later playback.The services listed above do not constitute a complete list of all functions of the Telematics Unit 24, but merely an enumeration of some of the services that the Telematics Unit 24 has to offer. It is assumed that the Telematics Unit 24 may include a number of additional components besides and / or different components from those mentioned above.

[0027] Vehicle communication can use cellular communication to establish a voice channel with the wireless carrier system 14, enabling both voice and data transmissions to be sent and received over the voice channel. Vehicle communication is enabled via the cellular chipset / component 34 for voice communication and the wireless modem 36 for data transmission. Any suitable coding or modulation method can be used with the examples provided, including digital transmission technologies such as TDMA (time-division multiple access), CDMA (code-division multiple access), W-CDMA (wideband CDMA), FDMA (frequency-division multiple access), OFDMA (orthogonal frequency-division multiple access), etc. To achieve this effect, the dual-mode antenna 70 supplies the GPS component 42 as well as the cellular component 34.

[0028] The microphone 26 provides the driver or other vehicle occupants with a means of inputting verbal or other acoustic commands and can be equipped with an embedded speech processing unit using a human-machine interface (HMI) technology as known in the art. Conversely, the loudspeaker 28 provides verbal output for the occupants and can be either a standalone loudspeaker specifically for use with the telematics unit 24 or part of the vehicle's audio component 64. In either case, the microphone 26 and the loudspeaker 28 enable the vehicle's hardware 20 and the data center 18 to communicate with the occupants via audible speech. The vehicle hardware also includes one or more buttons and / or controls 30 for enabling the activation or adjustment of one or more of the vehicle's hardware components 20.For example, one of the buttons and / or controls 30 could be an electronic push button to initiate voice communication with the data center 18 (be it a live advisor, such as an assistant 58, or an automated call response system). In another example, one of the buttons and / or controls 30 could be used to initiate emergency services.

[0029] The audio component 64 is functionally connected to the vehicle bus 32 and the audio bus 22. The audio component 64 receives analog information and reproduces it as sound via the audio bus 22. Digital information is received via the vehicle bus 32. The audio component 64 provides AM (amplitude modulated) and FM (frequency modulated) radio, CD (Compact Disc), DVD (Digital Video Disc), and multimedia functions independently of the infotainment center 46. The audio component 64 can include a speaker system or can use a speaker 28 via arbitration on the vehicle bus 32 and / or the audio bus 22.

[0030] The vehicle accident and / or impact detection sensor interface 66 is functionally connected to the vehicle bus 32. Via the vehicle accident and / or collision detection sensor interface 66, the collision sensors 68 of the telematics unit 30 provide information regarding the severity of a vehicle collision, such as the impact angle and the magnitude of the impact force.

[0031] Vehicle sensors 72 are connected to various vehicle sensor modules 44 (VSMs) in the form of electronic hardware components located in each fleet vehicle. These VSMs use the acquired input to perform diagnostic, monitoring, control, monitoring, reporting, and / or other functions. Each VSM 44 is preferably connected to the other VSMs and the telematics unit 24 via the vehicle bus 32 and can be programmed to perform vehicle system and subsystem diagnostic tests. For example, a VSM 44 could be an engine control module (ECM) that controls various aspects of engine operation, such as fuel injection and ignition timing.According to one embodiment, the ECM is equipped with integrated diagnostic (OBD) features that provide a wealth of real-time data, such as that received from various sensors including vehicle emission sensors, fuel diagnostic sensors, and vehicle oil pressure sensors, and provides a standardized set of diagnostic trouble codes (DTCs) that enable a technician to quickly identify and rectify malfunctions within the vehicle. Similarly, VSM 44 can be a powertrain control module (PCM) that regulates the operation of one or more components of the powertrain system. Another VSM 44 can be a body control module (BCM) that monitors and controls various electrical components located in the vehicle body, such as central locking, air conditioning, tire pressure monitoring, the lighting system, engine ignition, vehicle seat adjustment and heating, mirrors, and headlights.Furthermore, experts in the field will recognize that the aforementioned VSMs are only examples of some of the modules that can be used in the vehicles 12, as numerous others are also possible.

[0032] A Passive Entry Module for Passive Start (PEPS), for example, is another of the numerous VSMs and provides passive detection of the absence or presence of a passive physical key or a virtual vehicle key. As the passive physical key approaches, the PEPS module can determine whether the passive physical key is authentic and belongs to the vehicle. The PEPS can also use authentication information received from the data center 18 to determine whether a mobile computing device 57 with a virtual vehicle key is authorized / authentic for the vehicle. If the virtual vehicle key is deemed authentic, the PEPS can send a command to the BCM 44 and allow access to its vehicle.It should be understood that the PEPS can be an electronic hardware component connected to the vehicle bus 32, or in an alternative embodiment, it can be one or more software modules (code segments) that are uploaded to the electronic memory 40.

[0033] The wireless carrier system 14 can be a mobile phone system or any other suitable wireless system that transmits signals between the vehicle hardware 20 and the fixed network 16. According to one example, the wireless carrier system 14 includes one or more cell towers 48.

[0034] The fixed network 16 can be a conventional telecommunications fixed network connected to one or more landline telephones and linking the wireless carrier system 14 to the data center 18. For example, the fixed network 16 can include a public switched telephone network (PSTN) and / or an Internet Protocol (IP) network, as recognized by experts. Naturally, one or more segments of the fixed network 16 can be implemented as a standard wired network, a fiber optic or other optical network, a cable network, other wireless networks such as wireless networks (WLAN), or networks providing broadband wireless access (BWA), or any combination thereof.

[0035] As disclosed above, one of the networked devices that can communicate directly or indirectly with the telematics unit 24 is a mobile computing device 57, such as a smartphone, a personal laptop computer, or a tablet computer with two-way communication capabilities, a wearable computer such as a smartwatch or glasses, or any suitable combination thereof. The mobile computing device 57 may include computing capabilities, a receiver 53 capable of communicating with remote locations (e.g., a data center 18), a digital camera 55, a user interface 59, and / or a GPS module 63 capable of receiving GPS satellite signals and generating GPS coordinates based on those signals. The user interface 59 may be embodied as a graphical touchscreen interface suitable for both user interaction and the display of information.The digital camera 55 may include the ability to generate bitmap data representations of captured images of material objects by generally known processes. Examples of the mobile computing device 57 include the iPhone™ and Apple Watch™ manufactured by Apple Inc., and the Droid™ smartphone manufactured by Motorola Inc., among others.

[0036] The mobile device 57 can be used inside or outside a vehicle and can be connected to the vehicle via a wired or wireless connection. The mobile device 57 can also be configured to provide services under a subscription agreement with a third-party provider or a mobile / telephone service provider. It should be noted that different service providers can use the wireless carrier system 14 and that the service provider of the telematics unit 30 does not necessarily have to be the same as the service provider of the mobile device 57.

[0037] When using a (SRWC) protocol (e.g., Bluetooth / Bluetooth Low Energy or Wi-Fi), the mobile computing device 57 and the telematics unit 24 can connect (or link) to each other on a case-by-case basis when they are within a wireless range; SRWC pairing is known to professionals in the field. The SRWC protocol can be an aspect of the telematics unit 24 or can be part of one or more independent VSMs 44, such as the PEPS and / or BCM 44. Once SRWC is established, the devices can be considered connected to each other (i.e., they can recognize each other and / or connect automatically when they are within a predetermined proximity or range of each other. In other words, they can become network participants, at least temporarily).

[0038] This unique coupling allows, for example, the mobile computing device 57 to function as the virtual key fob mentioned above. To illustrate this, after receiving a request, the call center 18 will generate an encrypted virtual vehicle key to enable vehicle access via the mobile computing device 57. The call center 18 then transmits aspects of this encrypted virtual vehicle key information via the telematics unit 24 to both the mobile computing device 57 and the PEPS module 44. Once the connection is established, the mobile computing device 57 sends its virtual vehicle key aspect to the telematics unit 24 for recognition in relation to its stored corresponding virtual key aspect, and the PEPS can, in turn, configure the mobile computing device 57 as a key fob for the vehicle.The call center 18 can also transmit one or more time parameters with the encrypted virtual vehicle key information to temporarily set up the virtual vehicle key of the mobile device 57.

[0039] The data center 18 is designed such that the vehicle's hardware 20 is supported by a number of different back-end functions of the system and, according to the example shown here, generally includes one or more switches 52, servers 54, databases 56, dispatchers 58, and a variety of telecommunications / computer equipment 60. These various data center components are appropriately coupled to one another via a network connection or bus 62, such as the one(s) previously described in connection with the vehicle's hardware 20. Switch 52, which may be a private branch exchange (PBX) switch, forwards incoming signals so that voice transmissions are generally sent either to the live operator 58 or to an automated response system, and data transmissions are routed to a modem or other components of the telecommunications / computer equipment 60 for demodulation and further signal processing.The modem or other telecommunications / computer equipment 60 may, for example, include an encoder, as explained above, and may be connected to various devices, such as a server 54 and a database 56. Although the illustrated example has been described as being used in conjunction with a manned version of the data center 18, it is understood that the data center 18 may be a variety of suitable centralized or decentralized facilities, manned or unmanned, mobile or fixed, for which it is desirable to exchange voice and data.

[0040] The Server 54 may contain a data controller that essentially controls its operation. The Server 54 can control data information and act as a receiver to send and / or receive data information (i.e., data transmissions) from one or more of the Databases 54, the Telematics Unit 24, and the Mobile Computing Device 57, Remote Database 441. The controller can furthermore read executable instructions stored in a non-transitory machine-readable storage medium and may include one or more components consisting of a processor, a microprocessor, a central processing unit (CPU), a graphics processing unit, application-specific integrated circuits (ASICs), field-programmable gate arrays (FPGAs), state machines, and a combination of hardware, software, and firmware components.

[0041] The remote database 441 can be one of a multitude of computers accessible via a private or public network such as the Internet (e.g., a server system). Each such computer 441 can be used for one or more purposes, for example, to store one or more providers of dynamic content that can provide dynamic content for map data.

[0042] Database 56 could be designed to store numerous application programming interface (API) suites. Furthermore, these API suites could, in certain cases, be accessible to the system user, data center 18, or one or more third parties. For example, an API suite could be a ride-sharing service suite containing numerous records of the ride-sharing system records (i.e., vehicle reservation information), each containing information about the vehicles in Fleet 12, such as ride-sharing vehicle records (e.g., vehicle serial number information), user-related information, such as reservation account records (e.g., vehicle comfort setting information, telematics unit settings, or vehicle manufacturer model preferences, etc.), and information related to organizing vehicle reservations, such as reservation profile information (e.g.,Reservation calendar information, vehicle assignment information, third-party contact information, etc., as well as fleet management information (e.g., vehicle fleet feedback data, localization and mapping module data, route planning module feedback data, etc.) or other relevant ride-sharing system information. The records can also be copied, organized, and / or stored in a tabular format to allow for continuous, real-time updates. Additionally, the records can work with a reservation account (discussed below) to support, for example, reservation management.

[0043] Another example of an API suite is a route efficiency control module that provides a geographic map and generates route instructions that enable a fleet vehicle to perform tasks optimally. The geographic map contains identifiable static and dynamic resources in a variety of defined raster geographic sectors and can use these resources to provide a task performance status for each geographic sector (discussed below). The route instructions cause the fleet vehicle to take an optimally efficient route to reach a specific location (discussed below), based on the geographic map.

[0044] The user of mobile computing device 57 can create their own personalized vehicle reservation account for storage in mobile storage 61, which can access the ride-sharing records on the backend. The user can perform tasks to generate this account through a variety of frontend devices, such as a remote computer and mobile computing device 57. This reservation account can be uploaded to or made accessible on server 54 (e.g., to support backend functions). Data center 20 can also access one or more additional remote servers and / or remote databases (e.g., vehicle databases, weather databases, traffic databases, etc.) to obtain information for supporting the reservation account, as well as a specific reservation and one or more records from the ride-sharing system.

[0045] The reservation account may contain validation data to check and / or validate whether future login attempts are secure (e.g., granting access only to the user). The validation data may include a username and account password, as well as user information (e.g., driver's license information) and information about mobile computing devices, such as the unique identifier for the mobile computing device (e.g., serial number). The user account may also store a variety of user settings.

[0046] The user of the mobile device 57 can visit an online software application store or web service and download the reservation account as a software module. The reservation account may also include one or more prompts to instruct the user to provide information (e.g., validation data) to support account creation.

[0047] The reservation account can also provide one or more requests to assist a ride-sharing user in reserving a fleet vehicle by accessing and communicating with the backend ride-sharing records (to obtain transportation to specific destinations). Once a reservation is made, the mobile computing device 57 will send this reservation information to one or more of the ride-sharing records to update them. On the backend, the server 54 works with the database 56 and one or more ride-sharing records to establish a subset of the fleet available for the reservation. For example, the server 54 can manage the use of a fleet of twenty (20) vehicles at a particular geographic location and determine that five (5) of these vehicles are available to fulfill the requested reservation.Server 54 then selects one of these fleet vehicles using a vehicle identifier and assigns this identifier to the reservation account and corresponding ride records for use during the requested reservation. Server 54 then communicates the provided pick-up coordinates to the selected fleet vehicle via telematics unit 24, enabling the vehicle to navigate itself to the pick-up location. As vehicles are requested and used, Server 54 can determine the identities of the currently used vehicles and monitor various aspects of the other fleet vehicles to understand which vehicles are available at any given time. This monitoring process can thus be carried out by checking one or more ride records. ELECTRIC VEHICLE GAS SPECTS

[0048] With reference to Fig. In 2, each fleet vehicle 12 is an electric vehicle (EV) that generally comprises vehicle wheels 215 rotatably supporting a vehicle body 211. The fleet vehicle 12 further comprises a drive system 213 with at least one electric motor 219. In one embodiment, an electric motor 219 is operatively connected to each of the vehicle wheels 215 to transmit torque to them and thus drive the fleet vehicle 12. These motors can also be connected directly or indirectly to their respective wheels via a transmission 214 (shown as a direct connection arrangement).

[0049] The drive system 213 can also include a power source 218, configured as a battery for the purpose of providing direct current (DC) to operate each of the motors as well as other vehicle systems. Each motor can be a permanent magnet motor that uses alternating current (AC). Consequently, the drive system 213 can include an inverter component 220, which is operatively connected to the output of the power source 218 to enable conversion of the DC to AC before it is supplied to the motors. The drive system 213 can additionally be connected to a vehicle control device 222, discussed below, to regulate the amount of energy transferred from the power source 218 in order to effectively control the torque output by each motor 219. The drive system 213 can further include an input component, which in some embodiments may be operated by a person (i.e.,a selectively depressible foot pedal) can be actuated to provide an input for a desired torque output. The drive system 213 can also be connected to the vehicle bus 32 to communicate with one or more VSMs 44 (not shown). For example, the OBD 44 can provide the power source 218 with information about the state of charge (SoC) based on information received by the VSM from one or more energy measurement sensors.

[0050] Although shown as a single unit for illustrative purposes, the vehicle control device 222 may additionally include one or more other controllers, collectively referred to as a "control device" or "vehicle control device." Control device 222 may include a microprocessor, such as a central processing unit (CPU) or a graphics processing unit (GPU), which communicates with various types of computer-readable storage devices or media. Computer-readable storage devices or media may include volatile and non-volatile memory in read-only memory (ROM), direct-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 CPU is powered off.Computer-readable storage devices or media may be implemented using any 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 combined storage devices capable of storing data, some of which constitute executable instructions used by the control device 222 in controlling the vehicle. ASPECTS OF THE AUTONOMOUS VEHICLE

[0051] In addition to the fleet vehicle aspects discussed above, the transmission 214 can be installed to transmit power from the drive system 213 to the vehicle wheels 215 at selectable speed ratios. Depending on the embodiment, the transmission 214 can include a gear-ratio automatic transmission, a continuously variable transmission, or another suitable transmission. The fleet vehicle 12 also includes wheel brakes 217 configured to deliver a braking torque to the vehicle wheels 215. The wheel brakes 217 can, in various embodiments, include friction brakes, a regenerative braking system such as an electric motor, and / or other suitable braking systems. It is understood that the transmission 214 does not necessarily have to be installed for the drive system 213 to power the fleet vehicle 12.

[0052] Each fleet vehicle 12 also includes a steering system 216. Although shown as a steering wheel for illustrative purposes, the steering system 16 may not include a steering wheel in some embodiments. The telematics unit 24 is additionally configured to communicate wirelessly with other vehicles (“V2V”) and / or infrastructure (“V2I”) and / or pedestrians (“V2P”). These communications can be collectively referred to as “vehicle-to-entity” communication (“V2X”). In one exemplary embodiment, this communication system communicates via at least one dedicated short-range communication channel (DSRC channel). DSRC channels refer to one-way or two-way short-range to medium-range radio communication channels specifically designed for the automotive industry and a corresponding set of protocols and standards.

[0053] The drive system 213 (explained above), the transmission 214, the steering system 216, and the wheel brakes 217 are connected to or under the control of a control device 222. The vehicle control device 222 includes an automated driving system (ADS) 224 for automatically controlling various actuators in the vehicle. In an exemplary embodiment, the ADS 224 is a so-called Level Four or Level Five automation system. A Level Four system indicates a “high level of automation” with reference to the driving mode-specific performance of an automated driving system in all aspects of the dynamic driving task, even if a human driver is unable to respond appropriately to a request.A Level Five system indicates “full automation” and refers to the full-time performance of an automated driving system of all aspects of the dynamic driving task under all road and environmental conditions that can be managed by a human driver. In an exemplary embodiment, the ADS 224 is configured to communicate automated driving information with and control the drive system 213, transmission 214, motors 219, steering system 216, and wheel brakes 217 to control vehicle acceleration, steering, and braking without human intervention via a variety of actuators 30 in response to inputs from a variety of driving sensors 226, such as GPS, radar, lidar, optical cameras, thermal cameras, ultrasonic sensors, and / or additional sensors.

[0054] In various configurations, the instructions of the ADS 224 can be structured according to function or system. For example, the ADS 224 can be, as in Fig. Figure 3 shows a sensor fusion system 232 (computer vision system), a positioning system 234, a steering system 236, and a vehicle control system 238. As can be seen, the instructions can be divided into any number of systems (e.g., combined, further subdivided, etc.) in various embodiments.

[0055] In various embodiments, the sensor fusion system 232 synthesizes and processes sensor data and predicts the presence, location, classification and / or trajectory of objects and features in the vehicle's environment 12. In various embodiments, the sensor fusion system 232 can incorporate information from multiple sensors, including cameras, lidars, radars and / or any number of other types of sensors.In one or more exemplary embodiments described herein, the sensor fusion system 232 supports or otherwise performs the ground reference determination processes and correlates image data with LiDAR point cloud data, the vehicle's reference frame, or some other reference coordinate frames, using calibrated conversion parameter values ​​associated with the pairing of the appropriate camera and reference frames to relate LiDAR points to pixel positions, to assign depth to the image data, to identify objects in one or more of the image data, or to otherwise synthesize associated image data and LiDAR data. In other words, the sensor output from the sensor fusion system 232, which is sent to the vehicle control system 238 (e.g.,Displays of detected objects and / or their locations relative to the vehicle 10) are provided, which represent calibrations and associations between the camera images, LIDAR point cloud data and the like.

[0056] The positioning system 234 processes sensor data together with other data to determine a position (e.g., a local position relative to a map, a precise position relative to a road lane, vehicle direction, speed, etc.) of the vehicle 12 in relation to its environment. The guidance system 236 processes sensor data together with other data to determine a route that the vehicle 12 is to follow (e.g., route plan data). The vehicle control system 238 generates control signals to control the vehicle 12 according to the determined route.

[0057] In various embodiments, the vehicle control device 222 implements machine learning techniques to support the functionality of the vehicle control device 222, such as feature recognition / classification, obstacle mitigation, route crossing, mapping, sensor integration, ground truth determination, and the like.

[0058] The output of the vehicle control device 222 is transmitted to the actuators 230. In an exemplary embodiment, the actuators 230 include a steering control, a shift control, a throttle control, and a brake control. The steering control can, for example, control a steering system 216, as shown in Fig. Figure 2 illustrates this. The gearshift control can, for example, control a 214 transmission, as shown in Fig. 2 illustrates. The throttle valve control can, for example, control a drive system 213, as shown in Fig. Figure 2 illustrates this. The brake control can, for example, control the wheel brakes 217, as shown in Fig. 2 illustrated. GEO-ROUTE EFFICIENCY CONTROL MODULE

[0059] Fig. Figure 4 is a block diagram that schematically shows a detailed exemplary embodiment of the segmented geo-route efficiency control module 400 (also known as the "efficiency module"), which contains certain functional blocks that do not actually correspond to any physical separation of functions, since these blocks correspond to software modules (code segments). The efficiency module 400 can be executed to instruct the one or more delegated fleet vehicles 12 to optimally perform at least one ride-sharing system task.An exemplary ride-sharing task can be considered as one in which the delegated fleet vehicle arrives at a first specified destination (user location) to transport a ride-sharing user for the purpose of taxi transportation from the first specified destination to a subsequent specified second destination selected by the ride-sharing user (destination location). Thus, optimal performance would be that which allows the delegated fleet vehicle to complete the ride-sharing task while consuming fewer vehicle resources than if the task were performed in an alternative manner.

[0060] The route efficiency control module 400 comprises several different components – a transit interface 410, a destination interface 420, a mapping engine 430, a search engine 440, a route optimization engine 450, and an instruction engine 460. These components can be combined to provide an optimal route from a starting point (figurative point A) to an end point (figurative point B) for one or more delegated transport fleet vehicles 12.

[0061] The efficiency module 400 can receive GPS data as vehicle location coordinates from the telematics unit 24 of a delegated fleet vehicle 12 via the transit interface 410. This GPS data is provided by the GPS component 42 and corresponds to the vehicle's location, which can be determined at different times. For example, the fleet vehicle may be located at specific coordinates at time t = T1 (e.g., identified by a latitude and longitude). Accordingly, the telematics unit 24 will provide the server 54 with GPS data containing the latitude and longitude at time t = T1, as well as a timestamp of the GPS data transmission. If the fleet vehicle 12 is in transit, it will be located at different coordinates at time t = T2. As a result, updated GPS data and timestamps (t = T2) can also be provided to the efficiency module 400.In this way, GPS component 42 can periodically update GPS data measurements of the current status or position of its fleet vehicle (e.g., every three or four seconds), and telematics unit 24 will then provide the updated GPS data to server 54. In another example, GPS component 42 can provide GPS data after new or updated GPS measurements have been taken, or when such measurements become available.

[0062] The efficiency module 400 can receive endpoint coordinates for a delegated fleet vehicle 12 via the target interface 420. The endpoint coordinates correspond to the position provided by the user (e.g., they are identified by a latitude and longitude). For example, a user provides their user location to the server 54 via the mobile computing device 57. Such coordinates can be provided via one or more reservation account prompts; alternatively, such coordinates can be provided via the GPS module 63 of the mobile computing device 57.

[0063] On behalf of the Efficiency Module 400, the Mapping Engine 430 generates a digital geospatial map of these geographic locations within an area encompassing the GPS data coordinates of the fleet vehicle 12 and the endpoint coordinates (i.e., a route). For example, in response to a request to provide a map of a given route, the Mapping Engine 430 retrieves the necessary information from the Information Store 431 and then filters and formats the map data appropriately. Conversely, the Search Engine 440 receives and serves the Efficiency Module 400 to locate specific geographic features for the map, such as a city plan, streets, parking areas, vehicle charge units, and building addresses.

[0064] The Efficiency Module 400 can use data from one or more remote databases 441 to support the generation of map data. For example, the Search Engine 440 can access a third-party geocode database 441 to determine the geosectors (map grid sectors) of specific regions, as well as roads, parking areas, vehicle charging stations, and other geographic features within each geosector. The Search Engine 440 can also access various dynamic content providers 441 (e.g., traffic data feeds, weather data feeds, media channels, municipalities, etc.), each of which provides dynamic content data for each of the many map geosectors. The Efficiency Module 400 can also work with the Server 54 to collect data from ride-sharing system datasets (e.g., SLAM feedback data).This information from the remote database 441 can also be collected periodically or randomly to support updates to the map data.

[0065] The Route Optimization Engine 450 can determine the optimal path of movement for the delegated fleet vehicle from its current position to the specified endpoint coordinates. To do this, the Optimization Engine 450 aggregates the dynamic content data provided for each map geosector to associate the geosector with a corresponding status (discussed below). Server 54 will then examine the dynamic content data for each configured geosector, assign scores to different parts of the dynamic content data, aggregate the assigned scores, and, for example, use a statistical / probabilistic technique to arrive at a geosector status. Based on these calculated states, the Optimization Engine 450 will provide a status indicator for each geosector (discussed below).

[0066] Additionally, the instruction engine 460 compiles the relevant map data (e.g., road data) for the most applicable route based on the geosector status to generate a set of instructions 470 for one or more fleet vehicles to reach the designated endpoint coordinates. As a result, the instructions 470 provide that the respective one or more delegated fleet vehicles 12 can autonomously operate in such a way as to arrive at specific endpoint coordinates in a manner that should consume fewer vehicle resources than one or more alternative routes. For example, the instructions 470 can enable the delegated fleet vehicle 12 to arrive at specific endpoint coordinates (and additionally be able to subsequently arrive at at least one vehicle charging station) without the power source 218 dropping below a safe baseline (i.e., falling to a dangerously low state of charge).

[0067] Instructions 470 are then provided by the Efficiency Module 400 and indirectly transmitted via Server 54 to one or more selected fleet vehicles. Instructions 470 are also in a format suitable for understanding by the Route Planning Module 350. It should be understood that Instructions 470 can be sent to Server 54 upon request from Server 54 or Vehicle 12; conversely, Instructions 470 can be automatically sent to Server 54 or Vehicle 12 when they are generated or when one or more updates occur.

[0068] Peripherally, the vehicle control device 222 can check and analyze the suitably formatted instructions 470 upon receipt in the fleet vehicle 12. The vehicle control device 222 can then compile the instructions 470 to cause the fleet vehicle 12 to optimally perform one or more ride-sharing system tasks (i.e., autonomously drive from the vehicle location to the user location, pick up the user, and then transport the user to a subsequent destination selected by the user). GEOLAND MAP

[0069] Fig. Figure 5 shows the mapping data generated by the mapping engine 430 in the form of a geosector-divided geoarea map 500 for an entire region. As shown, the map 500 contains a raster with several geosectors 502, each of which has its own (x, y) ordered paired coordinate identifiers 501 (i.e., row, column). It should be understood that these geosectors do not necessarily have to be uniform or square in shape.

[0070] Each geosector 502 itself contains identifiable route resources provided by the search engine 440. For example, in Fig. As shown in Figure 6, these resources can be data attributes for static content in the form of, for example, route entry / exit points 504, road segments 506, parking areas 508, parking spaces 510, and EF charging stations 512. As shown in Fig. As shown in Figure 7, these resources can alternatively be dynamic content data attributes in the form of, for example, route entry / exit congestion indicators 514, traffic jam indicators 516, parking space availability indicators 518, parking space availability indicators 520, vehicle availability indicators 522, charging station availability indicators 524, vehicle location indicators 525, vehicle movement statistics 526 (i.e., the number of fleet vehicles within a given geosector 502), road obstacle indicators 528, and destination indicators 529.

[0071] For example, the dynamic attributes for geosector 502 located at (0, 0) can establish a parking space availability indicator 518, representing an available parking space; a parking space availability indicator 520, representing a number of available parking spaces; charging station availability indicators 524, representing availability; multiple available vehicles 522; a route entry / exit congestion indicator 514, representing that vehicles are permitted to enter and leave geosector 502; and traffic jam indicators 516, representing relatively light traffic on the roads. Furthermore, based on the static attributes, the dynamic attributes for geosector 502 located at (0, 1) can easily establish traffic jam indicators 516, reflecting light traffic on the roads of this geosector (displayed as two vehicles 526).In contrast, the dynamic attributes for geosector 502 located at (2, 1) can establish a parking space availability indicator 518, which represents a closed parking area (not available), consequently an unavailable charging station 524 and no available vehicles 522, one or more route entry / exit congestion indicators 514, which represent that vehicles cannot enter geosector 502 at one or more locations (e.g. due to road obstruction 528), and traffic jam indicators 516, which represent that traffic is at a standstill on the roads of this geosector (e.g. due to road obstruction 528).

[0072] As in Fig. As shown in Figure 8, in one embodiment, the route optimization engine 450 can apply a statistical / probabilistic technique to such dynamic attributes for each geosector 502 to successively arrive at a matching dynamic status indicator 530. These status indicators 530, as explained above, can be displayed, for example, by a color and can be used to determine the most applicable route for a fleet vehicle based on vehicle resources. For example, a status indicator 530 can be designated as "green," and it can be assumed that it consumes minimal vehicle resources when a delegated fleet vehicle travels through the matching geosector.Consequently, a status indicator designated as "yellow" can be considered to be consuming a safe amount of vehicle resources, and a fleet vehicle should be instructed to enter such a geosector only if traversing a green geosector is not currently an option. A status indicator designated as "red" can be considered to be consuming a maximum amount of vehicle resources, and a fleet vehicle should be instructed to avoid traversing these geosectors whenever possible. It should be understood that dynamic attributes can also be aggregated periodically or randomly to update the status indicators for one or more geosectors.

[0073] To arrive at the above status indicators 530, each dynamic attribute can itself provide a weighted score. For example, due to high traffic volume, the route entry / exit congestion indicators 514 of one geosector can be considered to have a score of 0.05; whereas the route entry / exit congestion indicators 514 for another, far less congested geosector 530 can be considered to have a score of 0.20. Furthermore, the traffic jam indicators 516 of one route in one geosector can be considered to have a score of 0.08; whereas the traffic jam indicators 516 for another, less congested geosector 530 can be considered to have a score of 0.15.Additionally, the parking availability indicators 520 for a geosector 530 can be considered as having a score of 0.01, compared to a score of 0.02 for a geosector 530 with more available parking.

[0074] Furthermore, the dynamic attributes for each geosector 502 can be aggregated to provide an overall score for the geosector. For example, a status indicator labeled "green" might require a high score between 0.67 and 1.0 (e.g., vehicles traverse the geosector's road segments at or near specified speed limits, there is an abundance of available parking and charging stations, etc.). A status indicator labeled "green" might also indicate, for example, that a large number of fleet vehicles are available in geosector 53, thereby reducing the transit loads for a delegated fleet vehicle by allowing vehicle chaining within geosector 502. A status indicator labeled "yellow" might require a score between 0.34 and 0.66 (i.e.,(a moderate traffic congestion, a limited number of available charging stations, a limited number of available parking spaces, etc.). Finally, a status indicator designated as "red" may require a low score between 0.00 and 0.33 (i.e., there is significant road congestion and traffic standstill, no available charging stations, no available parking spaces, etc.).

[0075] The state of charge (SoC) information can also be used to adjust the parameters for geosector scores to improve accuracy. For example, if the SoC information indicates that power source 218 has approximately 90% charge remaining, a "green" status might require a score between 0.55 and 1.0, a "yellow" status between 0.20 and 0.55, and a "red" status below 0.20. However, if the SoC information indicates that power source 218 has approximately 65% ​​charge remaining, a "green" status might require a score between 0.75 and 1.0, a "yellow" status between 0.45 and 0.75, and a "red" status below 0.45.

[0076] Based on the dynamic attributes of the in Fig. 8, Sections 502 of the example shown: (0, 0), (0, 1), (2, 0), (3, 0), (3, 1) and (3, 2) can be referred to as a “green” status, Sections 502: (0, 2), (1, 0), (1, 1) and (1, 2) can be referred to as a “yellow” status, and Geosectors 502: (2, 1) and (2, 2) can be referred to as a “red” status. Based on these results, the efficiency module 76 would instruct a fleet vehicle to follow the following route: (0,0) → (0,1) → (0,2) → (1,2) → (1,1) → (1,0) → (2,0) → (3,0) → (3,1) → (3,2), which is (G) → (G) → (Y) → (Y) → (Y) → (Y) → (G) → (G) → (G). In this way, each geosector 502 acts as a node of the map 500, connected to other geosectors by the route entry / exit points 504.

[0077] Efficiency module 76 would also avoid placing geosectors (2, 1) and (2, 2) along the route, since crossing just one “red” geosector creates a considerable risk of excessive consumption of the remaining vehicle resources, thus preventing the fleet vehicle from reaching its destination. PROCEDURE

[0078] As explained at least in part above, ride-sharing systems are those that allow a user (ride-sharing user) to download a reservation account to a mobile computing device and then register their reservation account by providing personal and / or payment information. The user can then use the ride-sharing system to request a ride from an autonomous electric vehicle (discussed above) within a certain radius of their location (e.g., 5-10 miles). Upon confirmation, the reservation account may display, for example, the name and type of vehicle, feedback / ratings from one or more previous users, and images of the requested vehicle.During the ride-sharing service window, the delegated vehicle will autonomously drive to the user's location, pick up the user, autonomously transport the user to their selected destination, and then drop the user off at the selected destination. After the ride-sharing service is completed, the user may be given the opportunity to submit their own feedback / rating for one or more ride-sharing services. The vehicle may also autonomously drive to the next request, a parking location, or a vehicle charging station (i.e., to complete the ride-sharing task).

[0079] With current reference to Fig.Figure 9 shows an application of a method for instructing delegated fleet vehicles to optimally execute one or more ride-sharing system tasks using the segmented geo-route efficiency control module 400. Aspects of this method can be executed by the controller 52, for example, by implementing the backend functionality of the efficiency module 400 stored in database 56. Peripheral aspects can be executed by the control device 222 of the delegated fleet vehicle 12, for example, to implement the generated commands and ensure that the fleet vehicle follows the generated route correctly and optimally executes the ride-sharing system task.

[0080] In step 610, a user provides a user location (initial location) to the Efficiency Module 400. As discussed above, the Efficiency Module 400 then executes the destination interface 420 to determine the user location and subsequently filters and formats these coordinates in a suitable form. In step 620, the Efficiency Module 400 can receive GPS data from any / all available fleet vehicles 12 (t = Tn) that are most recently known to be near the user location (e.g., within 5 miles). The transit interface 410 is then executed to determine the vehicle location coordinates (for t = Tn) for each of these fleet vehicles.After all location coordinates have been filtered and formatted in a suitable form, the efficiency module 400 can select one of the fleet vehicles 12 that has been found to be near the user's location and designate this vehicle for the ride-sharing task.

[0081] In step 630, the efficiency module 400, with respect to the vehicle location coordinates (t = Tn), executes the mapping engine 430, the search engine 440, and the route optimization engine 450 to generate a map with multiple geosectors, providing each geosector with a status indicator, as discussed above. In this step, the efficiency module can optionally check the user's location relative to the generated map to ensure that the designated fleet vehicle does not traverse any geosectors with a status indicator considered "red." If one or more geosectors are considered "red," the efficiency module 400 can return to step 620 to select another fleet vehicle 12 located near the user's location.

[0082] In step 640, the efficiency module 400 executes the instruction engine 460 to generate a series of instructions to be delegated to the selected fleet vehicle 12 and to cause this vehicle to drive a route from the vehicle location to the user location that corresponds to the map generated earlier (step 630). In step 650, the efficiency module 400 will communicate with the server 54 to delegate the designated fleet vehicle 12 by sending the generated instructions to the vehicle's telematics unit 24. In this step, the delegated fleet vehicle will also process these instructions (via the route planning module 350) to drive this route. As a result, the fleet vehicle will pick up the user at the user location, transport the user to a subsequent destination selected by the user, and then continue to another user location, a parking location, or a charging station.

[0083] At a specific point after step 650, in step 660, the efficiency module will either receive or retrieve additional GPS data from the delegated fleet vehicle 12 (t = T(n + 1)). As a result, the efficiency module 400 will re-execute the transit interface 410 to estimate the updated vehicle location coordinates. If it is determined that the coordinates of the new vehicle location (t = T(n + 1)) remain sufficiently far from the user location (e.g., 0.5 miles), then the procedure 600 proceeds to step 670; otherwise, the procedure 600 proceeds to completion. In step 670, with respect to the updated vehicle coordinates (t = T(n + 1)), the efficiency module 400 executes the mapping engine 430, the search engine 440, and the route optimization engine 450 to generate an updated map.

[0084] After the updated map is completed, procedure 600 returns to step 640 (where t = T (n + 1) becomes t = Tn).

[0085] The processes, methods, or algorithms disclosed herein can be provided and / or implemented by a processing device, controller, or computer, which may include any existing programmable electronic control unit or a dedicated electronic control unit. Likewise, the processes, methods, or algorithms can be stored by a controller or computer as data or executable instructions in a variety of ways, including permanent storage on non-writable storage media such as ROM, and as modifiable information on writable storage media such as floppy disks, magnetic tapes, CDs, RAM, and other magnetic and optical media. The processes, methods, or algorithms can also be implemented in a software-executable object.Alternatively, the processes, procedures or algorithms can be embodied wholly or partially with suitable hardware components, such as application-specific integrated circuits (ASICs), field-programmable gate arrays (FPGAs), state motors, controllers or other hardware components or devices, or a combination of hardware, software and firmware components.

Claims

[1] A system (10) for reducing the risk of vehicle resource depletion, the system (10) comprising: a memory (40) configured to include one or more executable instructions; a controller configured to execute the executable instructions, the controller further configured to communicate with an efficiency module (400); the efficiency module (400) is configured to enable at least one fleet vehicle (12) to optimally perform a ride-sharing system task; a mobile computing device (57) is configured to generate first location data, wherein the mobile computing device (57) is further configured to transmit the first location data to the controller; the fleet vehicle (12) comprises a vehicle system and a vehicle control device (222), wherein the fleet vehicle (12) is configured to communicate with the controller, wherein the vehicle system is configured to generate second location data, wherein the vehicle control device is configured to command the fleet vehicle (12) to autonomously perform one or more ride-sharing system tasks; and where the executable instructions of the controller enable: Receiving the first user location data transmitted by the mobile computing device (57); Receiving the second location data sent by the fleet vehicle (12); performing the efficiency module (400) to generate an output, the output based in part on the first location data and the second location data, the output configured to instruct the vehicle controller to instruct the fleet vehicle (12) to optimally perform the one or more ride-sharing system tasks; and Communicating the output to the fleet vehicle (12); wherein the executable instructions of the controller further enable: execute the efficiency module (400) to generate mapping data resulting in the form of a geosector-divided geo-area map (500) containing one or more geosectors (502) with dynamic content data; and to calculate the dynamic content data of each geosector (502) and consequently to generate a dynamic status indicator for each geosector (502). [2] The system (10) of claim 1, further comprising: the vehicle controller further configured to review and analyze the output and then instruct the fleet vehicle (12) to autonomously perform the one or more ride-sharing system tasks in accordance with the output. [3] The system (10) of claim 1, wherein the optimal performance of the one or more ride-sharing tasks comprises the fleet vehicle (12) performing an autonomous trip from the second location to the first location to pick up a ride-sharing user for the purpose of taxiing the ride-sharing user from the first location to a subsequent third location selected by the ride-sharing user. [4] The system (10) of claim 1, further comprising: a plurality of fleet vehicles (12), each comprising a vehicle system and a vehicle control device, each fleet vehicle (12) configured to communicate with the controller, each vehicle system configured to generate second location data, each vehicle control device configured to instruct the matching fleet vehicle (12) to autonomously perform one or more ride-sharing system tasks; and wherein the executable instructions further allow the controller to execute the efficiency module (400) for: Receiving second location data transmitted from each of the plurality of fleet vehicles (12); and Selecting a fleet vehicle (12) from the plurality of fleet vehicles (12) based at least in part on the second location data of the selected fleet vehicle (12) with respect to the first location data. [5] A method for reducing the risk of vehicle resource depletion, the method comprising: Providing a memory (40) configured to include one or more executable instructions; Providing a controller configured to execute the executable instructions, the controller further configured to communicate with an efficiency module (400), wherein the efficiency module (400) is configured to enable at least one fleet vehicle (12) to optimally perform a ride-sharing system task Providing a mobile computing device (57) configured to generate user location data, the mobile computing device (57) further configured to communicate the user location data to the controller; wherein providing the fleet vehicle (12) comprises a vehicle system and a vehicle control device, wherein the fleet vehicle (12) is configured to communicate with the controller, wherein the vehicle system is configured to generate vehicle location data, wherein the vehicle control device commands the fleet vehicle (12) to drive autonomously from the vehicle location to the user location; receiving) the user location data transmitted by the mobile computing device (57); Receiving the vehicle location data transmitted from the fleet vehicle (12); performing the efficiency module (400) to generate an output, the output based in part on the user location data and the vehicle location data, the output configured to instruct the vehicle controller to instruct the fleet vehicle (12) to optimally perform an autonomous trip from the vehicle position to the user location; and Transmitting the output to the fleet vehicle (12); wherein the efficiency module (400) is further configured to generate mapping data resulting in the form of a geosector-divided geo-area map (500) containing one or more geosectors (502) with dynamic content data; and wherein the efficiency module (400) is executed to calculate the dynamic content data of each geosector (502) and consequently generate a dynamic status indicator for each geosector (502). [6] The method of claim 5, further comprising: Receiving updated vehicle location data sent by the fleet vehicle (12) and Performing the efficiency module (400) to generate an updated output, the output based in part on the user location data and the updated vehicle location data. [7] The method of claim 5, further comprising: Providing a plurality of said fleet vehicles (12), each comprising a vehicle system and a vehicle control device, each fleet vehicle (12) configured to communicate with the controller, each vehicle system configured to generate vehicle location data, and each vehicle control device configured to command the matching fleet vehicle (12) to travel autonomously from its respective vehicle location to the user location; Receiving vehicle location data transmitted from each of the plurality of fleet vehicles (12); and Selecting a fleet vehicle (12) from the plurality of fleet vehicles (12) based on the vehicle location data of the selected fleet vehicle (12) with respect to the user location data.

Images