Method and device for vehicle route planning.

Abstract

A computer-implemented method comprising:receiving a vehicle route;receiving data relating to a vehicle charge level;estimating a power requirement required to travel a length of the vehicle route conditioned on a vehicle charge level insufficient to meet the power requirement; comparing the vehicle route with power outage data to determine power outage areas along the vehicle route; andsending an alert for at least a portion of the route containing a power outage area to a vehicle computing system (1) for communication to a driver.

Description

The illustrative embodiments relate generally to a method and apparatus for vehicle routing.The availability and incorporation of navigation systems into vehicles has created a variety of opportunities related to driver navigation and routing. Drivers may be provided with a fastest route, a no expressway route, a fuel efficient route, etc. Navigation systems may be provided as part of a standard vehicle package, on a portable telephone, or as stand-alone devices usable in a vehicle.JP 2011-196 826 A provides solutions for assisting battery charge in the vehicle, which is capable of reliably charging a target charge energy amount until the target time even when power supply is interrupted due to power failure. When charging a battery, a basic charging plan 8 is prepared from target charging energy and target time, on the other hand, power failure information or the like is acquired from a charging device, a network, or a learning value. A predicted power failure time zone in which power failure may occur in the charging facility where the battery is charged is predicted based on the acquired power failure information or the like. A charging plan in the case of power failure in consideration of the interruption of the power supply due to the power failure is created based on the predicted time zone for the predicted power failure. The charging process takes place according to the basic charging plan selected by the user or the charging plan in the event of a power failure.In an electric power amount information output apparatus for a vehicle according to DE 10 2010 039 075 A1, a control section checks whether the remaining electric power amount of a battery of a motor-driven vehicle at a departure location is less than the total electric power amount required for the vehicle to travel to a destination location. The control section controls an output section to output shortage information indicating that the remaining amount of electric power of the battery is insufficient when the remaining amount of electric power is less than the total amount of electric power required.JP 2007-72 074 A provides a power / momentary power failure display system capable of accurately displaying power failure / momentary power failures on a large-area card. The power failure / instantaneous voltage drop region display system includes: a first storage section in which a region powered via a generation line and a distribution line is divided into a plurality of regions and map information for displaying a map of the plurality of regions is stored; a second storage section for storing generation line information for displaying the generation line, distribution line information for displaying the distribution line, and customer information for displaying an address of the customer powered via the distribution line by being related to each other; An identification display control section in which, when a power failure / short-term voltage drop occurs at least in the generation line or the distribution line, the map information is read out from the first storage section and the customer information corresponding to the generation line information and the distribution line information of a power failure / short-term voltage drop occurrence position is read out from the second storage section, and the area corresponding to the occurrence position in the map information from the customer information is indicated, and the indicated area in the map information is identified and displayed as a power failure / short-term voltage drop occurrence area.Through existing infotainment systems, such as the FORD SYNC system, vehicle computing systems may access cloud-based services. This may help to typically integrate off-board computing services into a vehicle computing system. Through a connection established, for example, via a wireless device, a vehicle computing system may access and bidirectionally communicate with a cloud-based computing system.The off-board computer, server, etc., may use resources that are not locally available in the vehicle, such as increased computing power, database access, Internet access, etc., and include these available data / computing power in its processes. This can extend the range of options and options available for providing services in the vehicle.In a first illustrative embodiment, a computer-implemented method includes receiving a vehicle route. The example method further includes receiving data related to a vehicle charge level. The method also includes estimating a power requirement required to travel the length of the vehicle route.The method also includes, due to a vehicle state of charge insufficient to meet the power demand, comparing the vehicle route to power failure data to determine the presence of power failure areas along the vehicle route. The method further includes sending an alert for at least a portion of the route that includes a power outage area to a vehicle computing system for delivery to a driver.In a second illustrative embodiment, a computer-implemented method includes receiving a vehicle route and storing the vehicle route. The method also includes comparing the vehicle route to power failure data to determine the presence of power failure areas along the vehicle route while a vehicle is traveling along the route. The method further includes sending an alert for at least a portion of the route that includes a power outage area to a vehicle computing system for delivery to a driver.In a third illustrative embodiment, a computer-implemented method includes receiving a vehicle route. The method also includes comparing the vehicle route to power failure data to determine the presence of power failure areas along the vehicle route. The method further includes sending an alert for at least a portion of the route that includes a power outage area to a vehicle computing system for delivery to a driver.BRIEF DESCRIPTION OF THE DRAWINGSFIG. 1 shows an illustrative vehicle computing system; FIG. 2 is an explanatory failure map; FIG. 3 shows an illustrative process for processing failures; FIG. 4 shows an illustrative process for updating a route; FIG. 5 shows an explanatory process for alarming a driver; and FIG. 6 shows an explanatory process for route processing.As required, detailed embodiments of the present invention are disclosed herein; however, it is to be understood that the disclosed embodiments are merely exemplary of the invention that may be embodied in various and alternative forms. The figures are not necessarily to scale; some features may be exaggerated or minimized to show details of particular components. Therefore, specific structural and functional details disclosed herein are not to be interpreted as limiting, but merely as a representative basis for teaching one skilled in the art to variously employ the present invention.FIG. 1 illustrates an example block topology for a vehicle-based computing system (VCS) 1 for a vehicle 31. An example of such a vehicle-based computing system 1 is the SYNC system manufactured by THE FORD MOTOR COMPANY. A vehicle enabled with a vehicle-based computing system may include a visual front end interface 4 disposed in the vehicle. The user can also cooperate with the interface if, for example, it is provided with a touch-sensitive screen. In another illustrative embodiment, the interaction is by keystrokes, audible speech, and speech synthesis.In illustrative embodiment 1 shown in FIG. 1, a processor 3 controls at least some portion of the operation of the vehicle-based computing system. Provided within the vehicle, the processor enables onboard processing of commands and routines. Further, the processor is provided with both a non-persistent 5 and a persistent memory 7. In this illustrative embodiment, the non-persistent storage is random access memory (RAM), and the persistent storage is hard disk drive (HDD) or flash memory.The processor is also provided with a number of different inputs which allow the user to interface with the processor. In this illustrative embodiment, a microphone 29, an auxiliary input 25 (for input 33), a USB input 23, a GPS input 24, and a BLUETOOTH input 15 are all provided. An input selector 51 is also provided to allow a user to switch between different inputs. The input to both the microphone and the auxiliary connector is converted from analog to digital by a converter 27 before being passed to the processor. Although not shown, many of the vehicle components and auxiliary components in communication with the VCS may use a vehicle network (such as, but not limited to, a CAN bus) to route data to and from the VCS (or components thereof).Outputs from the system may include, but are not limited to, a visual display 4 and a speaker 13 or stereo system output. The loudspeaker is connected to an amplifier 11 and receives its signal from the processor 3 via a digital-to-analog converter 9. output may also be performed to a remote BLUETOOTH device such as PND 54 or a USB device such as a car navigation device 60 along the bi-directional data streams shown at 19 and 21, respectively.In an illustrative embodiment, the system 1 uses the BLUETOOTH transmitter / receiver 15 to communicate 17 with a user's mobile device 53 (e.g., mobile phone, smart phone, PDA, or any other device having wireless wide area network connectivity) The mobile device may then be used to communicate 59 with a network 61 external to the vehicle 31 by, for example, communication 55 with a cell tower 57. In some embodiments, the tower 57 may be a WiFi access point.The example communication between the mobile device and the BLUETOOTH transmitter / receiver is represented by signal 14.Pairing of mobile device 53 and BLUETOOTH transmitter / receiver 15 may be instructed by button 52 or similar input. Thus, the CPU is instructed that the onboard BLUETOOTH transmitter / receiver will be paired with a BLUETOOTH transmitter / receiver in a mobile device.Data may be transmitted between the CPU 3 and the network 61 using, for example, a data plan, data on voice, or DTMF tones associated with the mobile device 53. Alternatively, it may be desirable to incorporate an onboard modem 63 with an antenna 18 to transmit data between the CPU 3 and the network 61 over the voice band 16. The mobile device 53 may then be used to communicate 59 with a network 61 external to the vehicle 31 by, for example, communication 55 with a cell tower 57. In some embodiments, the modem 63 may establish communication 20 with the tower 57 for communication with the network 61. As a non-limiting example, the modem 63 may be a USB cellular modem and the communication 20 may be cellular communication.In an illustrative embodiment, the processor is provided with an operating system having an API to communicate with modem application software. The modem application software may access an embedded module or firmware on the BLUETOOTH transmitter / receiver to complete wireless communication with a remote BLUETOOTH transmitter / receiver (such as that found in a mobile device). Bluetooth is a subset of the IEEE 802 PAN (Personal Area Network) protocols. IEEE 802 LAN (local area network) protocols include WiFi and have considerable cross functionality with IEEE 802 PAN. Both are suitable for wireless communication within a vehicle. Another communication means that can be used in this area is free-space optical communication (such as IrDA) and non-standardized consumer IR protocols.In another embodiment, mobile device 53 includes a modem for voice band or broadband data communication. In the voice data embodiment, a technique known as frequency division multiplexing may be implemented when the owner of the mobile device can talk over the device while data is being transmitted. At other times, when the owner is not using the device, the data transmission may use the entire bandwidth (300 Hz to 3.4 kHz in one example). Although frequency division multiplexing may be common for analog cellular communication between the vehicle and the Internet and is still used, it has been largely replaced by hybrids of code domain multiple access (CDMA), time domain multiple access (TDMA), space domain multiple access (SDMA) for digital cellular communication. These are all ITU IMT-2000 (3G) compatible standards and provide data rates up to 2 mbs for stationary or current users and 385 kbs for users in a moving vehicle. 3G standards are now being replaced by IMT-Advanced (4G), which provides 100 mbs for users in a vehicle and 1 gbs for stationary users. If the user has a data plan associated with the mobile device, it is possible that the data plan enables broad band transmission and the system could use a much wider bandwidth (which speeds up data transmission). In yet another embodiment, the mobile device 53 is replaced with a cellular communication device (not shown) installed in the vehicle 31. In yet another embodiment, the ND 53 may be a wireless local area network (LAN) device capable of communication over, for example (and without limitation), an 802.11g network (i.e., WiFi) or a WiMax network.In one embodiment, incoming data may be routed through the mobile device via voice or data plan, through the onboard BLUETOOTH transmitter / receiver, and into the vehicle's internal processor 3. In the case of certain temporary data, the data may be stored on the HDD or other storage media 7, for example, until such time as the data is no longer required.Additional sources that may interface with the vehicle include a personal navigation device 54 having, for example, a USB connection 56 and / or an antenna 58, a vehicle navigation device 60 having a USB 62 or other connection, an onboard GPS device 24, or a remote navigation system (not shown) having connectivity to the network 61. USB is one of a class of serial networking protocols. IEEE 1394 (Firewire), EIA (Electronics Industry Association) serial protocols, IEEE 1284 (Centronics Port), S / PDIF (Sony / Philips Digital Interconnect Format) and USB-IF (USB Implementers Forum) form the backbone of the serial device-device standards. Most protocols may be implemented for either electrical or optical communication.Further, the CPU could be in communication with a variety of other auxiliary devices 65. These devices may be connected via a wireless 67 or wired 69 connection. The auxiliary device 65 may include, but is not limited to, personal media players, wireless health devices, portable computers, and the like.Also or alternatively, the CPU could be connected to a vehicle-based wireless router 73, for example, using a WiFi transmitter / receiver 71. This could allow the CPU to connect to remote networks within the range of the local router 73.In addition to exemplary processes being executed by a vehicle computing system located in a vehicle, in certain embodiments, the exemplary processes may be executed by a computing system in communication with a vehicle computing system. Such a system may include, but is not limited to, a wireless device (e.g., and without limitation, a mobile phone) or a remote computing system (e.g., and without limitation, a server) connected via the wireless device. Collectively, such systems may be referred to as vehicle-associated computing systems (VACS). In certain embodiments, specific components of the VACS may perform specific portions of a process depending on the specific implementation of the system. By way of example and not limitation, if a process has a step of sending or receiving information with a paired wireless device, then it is likely that the wireless device is not performing the process because the wireless device would not "send and receive" information with itself. One of ordinary skill in the art would understand when it is inappropriate to apply a particular VACS to a given solution. In all solutions, it is contemplated that at least the vehicle computing system (VCS) located within the vehicle itself is capable of performing the example processes.A primary concern of customers of a battery electric vehicle (BEV) is whether they can achieve their destination with the charge available in their electric vehicle. This condition is commonly known as "charge anxiety.". For BEVs and other full or partial electric vehicles, some type of range projection is often provided that allows a driver to see approximately how much range remains in the vehicle. Preferably, the driver reaches a destination including a charge point before the vehicle runs out of charge. If not, the driver must stop anywhere along the path to charge the vehicle.Although the driver needs to know the current vehicle state of charge to some extent (much more than in a gasoline vehicle due to the relative sparsity of charging stations), the driver is likely to know local charging points as well, so the routing does not always need to be within range of a single charge. For example, if a driver needs to drive thirty miles to work and a charging station is midway between the driver and the office, the driver needs to have only fifteen to twenty miles of charge in a vehicle as he exits the home or office, and in such a scenario, may stop and recharge. Despite the fact that this can add time to the pendulum route, the driver has at least the option of recharging the vehicle.Of course, if the driver were to reach the charging station and detected that the power had failed, the driver would be in a difficult situation. Because there would likely not be enough charge to reach a next charging station, the driver would be gracefully stuck at that charging point for the duration of the power failure (except for towing). Or, if a driver had charge for thirty five miles in the above scenario and was driving home without charging, only to discover that power has failed at home (but is powered on at the charging station), the driver may have insufficient time or capacity to recharge the vehicle at home to drive the next day to work. If the driver had rejected the failure, the driver would have been able to stop along the path at the charging station and provide sufficient charge to the vehicle for the next day to drive.FIG. 2 is an explanatory failure map. This non-limiting example of a power failure map may be generated by a remote server and / or obtained from, for example, a power provider. In an illustrative example, a company, such as, but not limited to, an automotive OEM, may contact a power company or access a power company website or database for a list of failures. The information may appear in the form of a map, data, etc.If the information is data, it may include, but is not limited to, geographic fences around failure areas defining the failures. This information can be used to generate a map, or simply used as data points to determine whether routes are going through or ending in failures.If the information is a map, the OEM (supplier, seller, data service provider, etc.) may determine a geographic decay from the map or use other suitable methods to determine where failures exist. If the information is in an alternative form, it may be used as appropriate.In this example, the card shows several usable pieces of information. In addition to failures, in this example, multiple routes were overlaid on the map to define an example "optimal charging route" versus a "optimal recharging availability route.". Both routes are from point A 201 to point B 203.The first route is an optimal load route 205, which may also include optimizations such as traffic, weather, and other fuel economy considerations. Additionally or alternatively, the route or another alternative route could be simply based on time efficiency. Other suitable "optimal" routes may be determined in conjunction with driver or manufacturer settings / desires / etc.The second route 207 here is the optimum recharging route. This route may be used when the vehicle is at low load, when heavy traffic on the main route indicates that a driver with the current load cannot travel through the failure region(s) if the driver wants to be simply careful, etc.In addition, the map shows different failure areas 209, 211, 213. Failures are encoded by affected customers so that designations between high failure and low failure areas can be determined. If there were sufficient charging stations, it may even be possible for charging stations to report conditions online, so that the data could be used to determine whether a given station or stations along a route were involved.Fig. 3 shows an illustrative process for processing failures. In this illustrative embodiment, route planning decisions or at least failure route planning decisions are made by a remote server. In another example, the data may be downloaded to a vehicle for processing in the vehicle.In this illustrative example, the process contacts a power company or other data provider 301 to obtain 303 current outage data. Additionally or alternatively, a permanent connection could be established or connections could be automatically established in the event of likely power failure conditions (e.g., triggered by power failures, storms, heavy winch, snowfall, etc.).Once the failures are downloaded, the process may identify one or more failure areas 305. The failure areas may be generally identified or may be associated with severity indicators. For example, it may not be necessary or desirable to steer a user around a large area that is only affected by a few point failures. On the other hand, a careful driver may want to avoid all failure areas to ensure that the power supply is present throughout a trip.Also, in this embodiment, a list of known recharging stations is compared 307 with the failure areas. These may include commercial stations, known charging points, and other points at which charging may be obtained. In this example, the charging stations are labeled 309, such that if a route were to suggest recharging at a particular station or point, the route planning engine would know with at least some degree of accuracy (e.g., without limitation low, medium, high, etc.) whether or not the station is likely to be operational.Given the limited number of known charging stations and charging points, currently, cross-referencing charging points / charging stations to a fault network may aid in determining whether or not a vehicle should travel through a "fault" area. For example, if a relatively comprehensive list of stations / points is available and none are known along a particular optimal route, it would make little sense to steer a user off this route, as charging could not likely be obtained in any case. On the other hand, if an alternative route were recommended in any case, it would be useful to know whether there is a failure near a recommended charging point to obtain charging. Charging points may also include points designated by the driver (e.g., relatives, friends, etc.) where the driver has entered a location as a charging point and / or the vehicle has been previously charged (and thus potentially stored the location as a charging point).FIG. 4 shows an illustrative process for updating a route. Again, in this example, the route calculation is performed off-board the vehicle, although this process could be performed by a navigation device (GPS device, smart phone, etc.) in communication with a vehicle computing system or by the vehicle computing system itself.Once an optimal route (according to any desired parameters) has been calculated 401, the process compares the route to known failures 403. As previously stated, this may be done using geographic data (comparing points on the route to geographic decay), by overlaying the route on a map showing failures, or by any other suitable technique. If there are no affected areas 405 (or no affected areas above a certain threshold), the process ends.If affected areas are along a route, the process summarizes the affected areas to determine what degree of diversion is required 407. This is only an illustrative example of how failure areas can be handled. In another example, each failure region may be handled individually. In this example, all "threshold" areas along a route are referred to as "non-driving zones", "warning zones", etc., so that route re-calculation avoids all areas without the need for repeated routing. For example, without limitation, roads passing through these areas may be treated as if the roads end at the boundary of the affected area (e.g., if the affected area is a "non-driving" area).Additionally, although not shown, if a recharging station is within a "safe" area, not far from any affected area (or anywhere along a recommended diversion), the process may recommend a stop at the station and then potentially ignore any other non-driving points depending on whether or not the driver is expected (or indicates) to perform a charging stop.In addition to determining affected areas along a route, the process takes actions as needed 409. In a non-limiting example, there are at least "non-driving" and "warning" zones. "non-driving" zones are bypassed as required, while "warning" zones can only provide a warning to the driver that stations within these zones may not be operational. If there are any non-driving zones on the route, the process may proceed to bypass 411 any zones where the travel would likely result in a no-power condition. A new optimal route may then be delivered to the vehicle as determined 413 by the system if necessary.FIG. 5 shows an explanatory process for alarming a driver. In this illustrative example, it is not necessarily known where a driver is driving. This may be a common scenario for many drivers driving from a known point to a known point. The driver may not wish to enter a specific route or may not even be safe where a route ends (e.g., a shopping trip). In such a situation, it would be useful for a driver to know a potential charging problem. For example, if a charging station were to be near a shopping stop, the driver may wish to charge a vehicle while engaged in shopping. If the charging station were powered down, the driver may only reach the goal of determining that recharging is not available and insufficient charge remains to return to the home.In this illustrative example, the process receives range data (again running remotely for example purposes) from a vehicle 501. The range data may specify a maximum travel distance, a back and forth travel distance, a radial travel distance based on road speeds, traffic (e.g., when one direction is rural and another direction is urban), etc. To be safe, additional fault tolerance may be incorporated into the range data (e.g., without limitation, subtracting X % from the projected range to account for unknown energy consumption). The radial travel range (or another suitable measure of travel range) may then be compared 503 to known failures.In at least one example, if charging stations are present and / or deployed in an area, a maximum travel range may be initially used (designating a range in which a vehicle may travel until power is exhausted) and then calculation may be set to a more conservative estimate (e.g., without limitation, a back and forth range) if there is a significant power loss in original radius.Once the general driving range has been selected, it is determined whether any affected areas are within a likely driving area 505. This process, as noted above, may also be a recursive process to help ensure that a driver does not encounter a no-load situation.If one or more affected areas are within the projected travel range, appropriate action may be taken. Actions include, but are not limited to, warning a driver of failures generally, warning a driver of areas to avoid, repeatedly checking failures when a driver is driving to ensure that a low charge no-current area is not entered, etc. Any suitable alerts may then be provided to the driver as needed 509.In one example, if charging locations are known / accessible, the process may determine that a driver is approaching an electroless or high failure region (or any suitable threshold range). For example, the process could determine that a charging station that is likely to be powered is three miles from a driver's current location and that if the driver is driving more than X miles in the current direction, the likelihood of recharging or returning to a known / likely functioning charging station is very low. In such a case, the process may warn the driver that the driver is approaching a point where there is no return, and the charge should be obtained before any further travel in the current direction so that the driver does not reach a point where no charge can be obtained / likely obtained.FIG. 6 shows an explanatory process for route processing. In this illustrative example, various actions that a process may take based on various failure scenarios are shown in a non-limiting embodiment. These examples are merely exemplary and are not intended to limit the scope of the invention in any way.In this illustrative process, at least one area of possible driver interest has been indicated in elements 405 and / or 505 as shown in the illustrative example. In this embodiment, the analysis of the "first step" reveals that a certain portion of a driver's route passes through an area where at least a certain level of power failure is indicated.The anxiety levels in this embodiment are low, medium and high, although these boundaries are chosen for illustrative purposes only. More specific terms may be selected or broader generalizations may be used, if desired. Actions according to a known / detected risk of power failure may then be taken.In this example, the process determines whether the affected area along the route (and the process may repeat until all affected areas have been viewed) is a low risk area 601. For example, low risk may correspond to only some failures (as indicated by data from the power company) or a low percentage of failures (as indicated by data from the power company), or any other suitable data indicating that a recharging station encountered is still quite likely to have power.If there is a low risk, in this example a driver is alerted 603 to the condition. In this example, all alerts for all areas along a route are merged 619 so that a comprehensive list of alerts and route planning suggestions can be provided to a driver. The alarm(s) may(s) include a percentage / number of failures and any other appropriate data.In at least one example, if locations of charging points (commercial or private points previously used by a driver or otherwise indicated) are known, it may only be relevant to inform a driver of a failure if a charging point is within the failure area. That is, when no charging point is in the failure area, the driver may not stop in this area to recharge regardless of whether or not there would be a power failure, so that the power failure is of little concern to the ability of a driver to recharge. On the other hand, drivers may want to know of all failures along a route if they know a station that the computer does not know, or if they need to engage an emergency stop, etc.Once the alert alerts for one or more low risk areas have been noted, the process checks whether any intermediate risk areas are along a route 605. Medium risk areas in this example may correspond to a higher percentage or number of failures and introduce a higher probability that a particular station or charging point will not have current. Again, in one example, this information may be presented only for the areas where a known charging point or station exists.In this embodiment, since there is a higher possibility that the driver cannot recharge along a route in a medium risk area, the process may recommend 607 a previous charging to at least a certain level. This could correspond to charging a vehicle until an estimated amount of power required to reach a known usable charging point is obtained; until an estimated amount of power to reach a destination is obtained, etc.In addition to the possible recommendation for a previous charge, particularly when a vehicle is at low power, the process may also add 609 one or more alerts to the alert / suggestion entity. These warnings could differ in severity from the low risk warnings and could provide the driver with additional information about the medium risk failures.In this example, the process also checks for any areas where there is a high risk that charging points will not have current 611. This could correspond to any areas where the risk is above a mid point and a charging station / point is quite likely not to have current if the driver wants to stop there. In this example, several potential specific warning conditions may be considered. In one case, a "do not drive" warning may be sent 613 to the driver. This could be for example if the route is long enough that at least one stop must be made regardless of the initial state of charge, and significant portions of the route are included in high risk zones. For example, if a vehicle has a range of four hundred miles and a trip of six hundred miles through a region of heavy snowfall, failures, and winter towers is scheduled, the driver must stop at least once. If the middle four hundred miles of the route are included in high failure zones, or even if only known charging points along the route are all in high failure zones, the process may recommend that the driver be driving only at a later time.In another example, the process may recommend 615 a new route that avoids the riskest(s) region(s) along the route. A diversion can be performed so that a new route is found that avoids areas of high failure as far as possible, while at the same time attempting to minimize the travel time and, if desired, to provide the user with at least one recharging point in a zone with little or no risk in the event of an emergency. In another example, not shown, diversion could be recommended even with respect to medium risk or low risk zones, such that a known charging point lower by at least one level is included in a route.The redirection may be attempted by a route planning engine, and if no possible route is available, the process may return to recommend "do not drive" or at least a previous boost if the distance along the route (plus any known delays) is less than the entire maximum range (i.e., short enough that a vehicle charged to a certain level may travel the entire route).Warnings to the driver may also be added 617 in the high risk cases. If desired, these warnings could be more severe and configured to ensure that the driver is watching them, at least more than the lesser warnings associated with other low risk areas. Once all warnings for all desired zones have been added, the warnings are merged 619 for delivery to the vehicle. The data provided to the vehicle may also include any recommended diversions or previous power charging.Data may also be included in a conditional form. For example, if redirection is recommended and the driver selects not to override, then information recommending a previous boost may be presented. If the driver selects to follow the redirection suggestion, the information regarding the previous charging may be ignored, in this example, because the driver is driving through a zone where charging is possible.In at least one illustrative embodiment, in addition to receiving data and providing diversions and / or warnings at the beginning of a trip, a remote server may at least temporarily store route data. When power failures are updated, the server may compare updated failures to stored route data for multiple vehicles. If certain failure changes affect the vehicle routes, the server may take appropriate action (according to the described illustrative embodiments) and send alerts, redirects, etc., according to the newly available data. This may help drivers to bypass or stop new failures earlier and charge a vehicle than may have been scheduled when the driver approaches an area along a route that is in a failure state and the power may be insufficient to drive the driver through the area.Although the above examples have been given with respect to electric vehicles, the techniques described and taught herein could also be applied to vehicles using gasoline as the fuel. In such a case, the "boost points" listed above would instead correspond to gas stations or other refueling options, including, but not limited to, fuel cell / pack renewal, hydrogen, natural gas, liquid nitrogen, compressed air, etc.Although exemplary embodiments are described above, it is not intended that these embodiments describe all possible forms of the invention. Rather, the words used in the specification are words of description rather than limitation, and it is understood that various changes may be made without departing from the spirit and scope of the invention. In addition, the features of various implementation embodiments may be combined to form further embodiments of the invention.Explanation of CharactersFIG. 1 61 Network 4 Display 51 Input selector 11 Shown. 52 BT pairing 25 auxiliary input 73 wireless module 65 auxiliary device 54 personal navigation device 60 vehicle navigation device

Claims

A computer-implemented method comprising: receiving a vehicle route; receiving data relating to a vehicle charge level; estimating a power demand required to travel a length of the vehicle route; due to a vehicle charge condition insufficient to meet the power demand, comparing the vehicle route to power failure data to identify power failure areas along the vehicle route; and sending a warning for at least a portion of the route that includes a power failure area to a vehicle computing system (1) for delivery to a driver.Method according to Claim 1, wherein the route is transmitted by requesting a vehicle computing system (1).The method of claim 1, wherein the alert comprises a recommendation to override at least one power failure.The method of claim 3, wherein the alert comprises a new recommended route.The method of claim 1, wherein the alert comprises a recommendation to charge a vehicle (31) to at least a predetermined level prior to continuing a trip.The method of claim 1, wherein the comparing comprises comparing the vehicle route to power failure data to determine the power failure along the vehicle route, wherein the power failure areas are also examined to determine known charging points.The method of claim 6, wherein sending an alert comprises sending an alert for only the at least a portion of the route that includes (a) power failure area(s) that also include a known charging point.

Images