Method and device for recommending energy-saving vehicle usage changes

Abstract

System that includes the following: a processor (3) configured for the following: Receiving a desired departure time and route for an upcoming journey from a vehicle computer system; Determining traffic volume based on the received departure time and route; Determining a vehicle's state of charge; and Recommending a new route or departure time if it is predicted that the vehicle charge level is sufficient to complete a trip based on the new route and departure time, wherein the vehicle charge level is a predicted vehicle charge level based on a preferred charging start time, and wherein the processor (3) is further configured to recommend a new charging start time if it is predicted that the predicted vehicle charge level is insufficient to complete a trip based on the new route or To achieve the desired departure time.

Description

TECHNICAL FIELD

[0001] The embodiments generally relate to a method and apparatus for recommending energy-saving vehicle usage changes. BACKGROUND

[0002] Typically, electric vehicles are charged at regular intervals within approximately weekly periods while the vehicle is at a home location (or other long-term residence location, such as an office). Charging schedules, particularly when the user pays for electricity, can be varied based on observed utility costs, so that priority charging often occurs when costs are lowest. Low-cost periods can vary, with a vehicle sometimes requiring more charge than can be obtained during the lowest-price periods.To support charging decisions, automotive OEMs have deployed web-based charging configuration and / or automated systems that can initiate charging based on current low-price periods considered in conjunction with anticipated energy demand (e.g., based on defined routes and / or observed usage). Under such circumstances, vehicles typically upload a "go" time based on when an anticipated route will begin. Furthermore, vehicles typically prepare the interior temperature based on when an anticipated route will begin. Even if an execution schedule is set on the vehicle, it can be tracked or managed by a backend server, and the desired / anticipated start time can thus also be uploaded.

[0003] US 2013 / 0 226 441 A1 discloses a system for assisting a user of an electrically powered vehicle, comprising: a position information acquisition unit for obtaining position information indicating a position of the vehicle during travel, an electric power amount estimation unit for estimating a remaining electric power amount of an electric power source of the vehicle during travel, a shortage risk estimation unit for estimating an estimated risk of a shortage of an electric power amount during travel based on the estimated remaining electric power amount, and a notification unit for notifying a user if the estimated risk of a shortage of an electric power amount estimated by the shortage risk estimation unit exceeds a predetermined threshold.

[0004] US 2015 / 0 127 248 A1 shows a central server for electronic communication with EVs and with customer devices, configured to provide remote services, including dynamic, interactive support for electric vehicle (EV) users. The server also communicates with at least one EV charging station network, which in turn communicates with individual charging stations. Remote services include trip planning, locating charging stations, checking the availability and suitability of charging stations, reserving charging stations, and updating plans during the trip. The server collects EV data and analyzes it to generate various statistics. The system advises the user whether the vehicle is ready to complete the planned trip before recharging the vehicle's batteries.

[0005] DE 10 2011 003 993 A1 describes a charge controller for charging a battery of a plug-in vehicle with multiple electrical energy sources.The charge controller includes: a route estimation element; a predicted electric energy consumption amount calculator; a weather information acquisition element; a sunshine information acquisition element; a solar photovoltaic generation energy amount calculator; an energy shortage calculator for calculating an electric energy shortage when the solar photovoltaic generation energy amount is less than a predicted electric energy consumption amount; a charging schedule preparation element for preparing a charging schedule that maps a first charging time for charging the battery with the solar photovoltaic generation system and a second charging time for charging the battery by the electric energy shortage with another electric energy source; and a charge control element for regulating charging of the battery according to the charging schedule. SUMMARY

[0006] In one embodiment, a system includes a processor configured to receive a desired departure time and route for an upcoming trip from a vehicle computing system. The processor is also configured to determine a traffic volume based on the received time for the received route. The processor is further configured to determine a vehicle charge level and recommend a new route or departure time if the vehicle charge level is predicted to be sufficient to achieve trip completion based on the new route or departure time according to the recommendation.

[0007] In a second embodiment, a computer-implemented method includes determining a new departure time or route that is expected to encounter less traffic than traveling via a received preferred route starting at a received preferred departure time, and sending the new departure time or route to a user device for confirmation.

[0008] A system includes a processor configured to determine a predicted travel time based on predicted traffic volume via a preferred route starting at a preferred departure time received from a vehicle computer. The processor is further configured to recommend an alternative departure time or an alternative route resulting in a shorter predicted travel time if a current vehicle charge level received from the vehicle computer is predicted to be sufficient to complete the trip using the alternative departure time or the alternative route. BRIEF DESCRIPTION OF THE DRAWINGS Fig. 1 shows an illustrative vehicle computer system; Fig. 2 shows an exemplary system for providing vehicle usage recommendations; Fig.Figure 3 shows an example process for implementing vehicle usage changes; Fig. 4 shows an example process for determining a recommended vehicle use change; and Fig. Figure 5 shows an example process for receiving and confirming a change of vehicle usage. DETAILED DESCRIPTION

[0009] As required, detailed embodiments of the present invention are disclosed herein; however, it should 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. The specific structural and functional details disclosed herein are, therefore, not to be interpreted as limiting, but merely as a representative basis for teaching one skilled in the art how to variously employ the present invention.

[0010] Fig.1 shows an exemplary block topology for a vehicle-based computing system 1 (VCS) 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 an in-vehicle visual front-end interface 4. The user may also be able to interact with the interface if it is equipped with a touchscreen, for example. In another exemplary embodiment, the interaction occurs through button presses, a voice dialog system with automatic speech recognition, and speech synthesis.

[0011] At the Fig.In the exemplary embodiment shown in Figure 1, a processor 3 controls at least part of the operation of the vehicle-based computing system. The processor is provided in the vehicle and allows onboard processing of instructions and routines. Further, the processor is connected to both non-persistent 5 and persistent memory 7. In this exemplary embodiment, the non-persistent memory is random access memory (RAM), and the persistent memory is a hard disk drive (HDD) or flash memory. In general, persistent (non-volatile) memory can include any type of storage that retains data when a computer or other device is turned off. This includes, but is not limited to, HDDs, CDs, DVDs, magnetic tapes, solid-state drives, portable USB drives, and any other suitable form of persistent memory.

[0012] The processor is also provided with a number of different inputs that allow the user to communicate with the processor. In this exemplary embodiment, a microphone 29, an auxiliary input 25 (for input 33), a USB input 23, a GPS input 24, a display 4, which may be a touchscreen, and a BLUETOOTH input 15 are provided. An input selector 51 is also provided to allow a user to select between different inputs. Inputs to both the microphone and the auxiliary connector are 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 connected to the VCS may utilize a vehicle network (such as, but not limited to, a CAN bus) to pass data to and from the VCS (or components thereof).

[0013] Outputs of the system may include, among others, a visual display 4 and a speaker 13 or a stereo system output. The speaker is connected to an amplifier 11 and receives its signal from the processor 3 through a digital-to-analog converter 9. The output may also be provided to a remote BLUETOOTH device such as PND 54 or a USB device such as a vehicle navigation device 60 along the bidirectional data streams shown at 19 and 21, respectively.

[0014] In one illustrative embodiment, system 1 uses Bluetooth transceiver 15 to communicate 17 with a user's nomadic device 53 (e.g., a cellular phone, smartphone, PDA, or any other device having wireless connectivity to remote networks). The nomadic device can then be used to communicate 59 with a network 61 external to vehicle 31, for example, by communicating 55 with a cellular tower 57. In some embodiments, tower 57 may be a Wi-Fi access point.

[0015] Exemplary communication between the nomadic device and the BLUETOOTH transceiver is represented by signal 14.

[0016] Pairing of a nomadic device 53 and the BLUETOOTH transceiver 15 can be instructed using a button 52 or similar input. Accordingly, the CPU is instructed to pair the onboard BLUETOOTH transceiver with a BLUETOOTH transceiver in a nomadic device.

[0017] Data may be communicated between the CPU 3 and the network 61, for example, using a data plan, data over voice, or DTMF tones associated with the nomadic device 53. Alternatively, it may be desirable to include an onboard modem 63 with antenna 18 to transmit data between the CPU 3 and the network 61 over the voice band 16. The nomadic device 53 may then be used to communicate 59 with a network 61 external to the vehicle 31, for example, via connection 55 to a cellular tower 57. In certain 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.

[0018] In an exemplary embodiment, the processor is equipped with an operating system that includes an API (Application Program Interface) for communicating with modem application software. The modem application software can access an embedded module or firmware on the BLUETOOTH transceiver to establish wireless communication with a remote BLUETOOTH transceiver (such as one 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 Wi-Fi and have considerable cross-functionality with IEEE 802 PAN. Both are suitable for wireless communication in a vehicle. Other communication means that can be used in this area are free-space optical communication (such as IrDA) and non-standard consumer IR protocols.

[0019] In another embodiment, the nomadic device 53 includes a modem for voiceband or broadband data communication. In the Data Over Voice embodiment, a technique known as frequency division multiplexing may be implemented when the owner of the nomadic device can speak through the device while data is being transferred. At other times, when the owner is not using the device, the data transfer may utilize the entire bandwidth (in one example, 300 Hz to 3.4 kHz). Although frequency division multiplexing may be common for analog cellular communication between the vehicle and the Internet and continues to be used, it has largely been replaced by hybrids of CDMA (Code Domain Multiple Access), TDMA (Time Domain Multiple Access), SDMA (Space-Domain Multiple Access) for digital cellular communication.These are all ITU IMT-2000 (3G) compliant standards and offer data rates of up to 2 mbs for stationary or walking users and 385 kbps for users in a moving vehicle. 3G standards are now being replaced by IMT-Advanced (4G), which can offer 100 mbs or higher downlink speeds. If the user has a data plan associated with the nomadic device, it is possible that the data plan allows broadband transmission and that the system could use a much larger bandwidth (speeding up data transmission). In another embodiment, the mobile device 53 is replaced by 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 communicating, for example (and without limitation), over an 802.11g network (i.e., WiFi) or a WiMax network.

[0020] In one embodiment, incoming data may be routed through the mobile device via Data-over-Voice or data plan, through the onboard BLUETOOTH transceiver, and into the vehicle's internal processor 3. In the case of certain temporary data, the data may be stored, for example, on the HDD or other storage medium 7 until the data is no longer needed.

[0021] Additional sources that may be connected to 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 connection 62 or other connection, an on-board 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™ (Apple), i.LINK™ (Sony), and Lynx™ (Texas Instruments)), 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 standards for serial device-to-device communication. Most of the protocols can be implemented for either electrical or optical communication.

[0022] Furthermore, 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 healthcare devices, portable computers, and the like.

[0023] Likewise, or alternatively, the CPU could be connected to a vehicle-based wireless router 73, for example, using a WiFi transceiver (IEEE 803.11) 71. This could allow the CPU to connect to remote networks within range of the local router 73.

[0024] In addition to representative processes being performed by a vehicle computing system located in a vehicle, in certain embodiments, the representative processes may be performed 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., but not limited to, a cellular phone) or a remote computing system (e.g., but not limited to, a server) connected by the wireless device. Collectively, such systems may be referred to as a vehicle-associated computing system (VACS). In certain embodiments, certain components of the VACS may perform certain portions of a process depending on the particular implementation of the system.By way of example and without limitation, if a process includes a step in which it sends or receives information to or from a paired wireless device, then the wireless device is likely not to perform that part of the process because the wireless device would not "send" information to itself and would not "receive" information from itself. One of ordinary skill in the art will know when it is inappropriate to apply a particular computer system to a given solution.

[0025] In each of the embodiments discussed herein, an illustrative, non-limiting example of a process performable by a computer system is shown. With respect to each process, the computer system executing the process may be configured as a special-purpose processor for the limited purpose of executing the process. Not all processes need to be performed in their entirety and are intended as examples of types of processes that may be performed to achieve elements of the invention. Additional steps may be added or removed from the example processes as desired.

[0026] In current telematics systems, electric vehicles such as battery electric vehicles (BEVs) and plug-in hybrid electric vehicles (PHEVs) typically upload their departure time to the backend server after setting their charging schedule. However, the current system lacks the ability to remind vehicle owners if the departure time or preferred route conflicts with known or predicted high traffic. By recommending a change to the route and / or departure time, additional energy can be saved and a more time-efficient journey to a destination can be achieved.

[0027] Fig.Figure 2 shows an exemplary system for providing vehicle usage recommendations. In this illustrative example, a vehicle 201 is in wireless communication 205 with the cloud 207 through a telematics control unit (TCU) 203. The vehicle can use this connection (which ultimately connects to a backend server 209) to upload predicted usage data, including, but not limited to, a predicted "start" time, a preferred route / destination, and a battery charge percentage.

[0028] The backend server, after receiving data for a particular vehicle, can use traffic information 211 (both actual and predicted information, where appropriate) to determine if a better route or start time exists for the desired trip. Interestingly, this may correspond to higher traffic volumes, which can reduce wind resistance and increase regenerative braking if energy conservation is more important to the driver than travel time. Of course, lighter traffic conditions may be considered if travel time is important to the driver. This consideration may also include a battery charge percentage. For example, if a user wants to travel 80 miles to a predefined destination at 7:30 a.m., the system may determine that the route would have much less traffic if the vehicle left at 6:30 a.m.However, if the current vehicle charge only supports a 20-mile trip, the system may also consider whether there is enough time between the current time and 6:30 a.m. to charge the vehicle for the trip. Such considerations may include, for example, the charge needed to return home and / or the charge needed to reach a known alternative charging location.

[0029] If a "better" route or start time is recommended and appropriate, the process may use a cellular network 213 to send the recommendation to a user's phone 215. The user may then confirm or reject the change (which may also require an increase in a charging start time based on a current charge and a required charge).

[0030] Fig.Figure 3 shows an illustrative process for implementing vehicle usage changes. With respect to the illustrative embodiments described in this figure, it should be noted that a general-purpose processor may be temporarily enabled as a special-purpose processor for the purpose of performing some or all of the example methods shown herein. When code providing instructions for performing some or all steps of the method is executed, the processor may be temporarily repurposed as a special-purpose processor until such time as the method is completed. In another example, where appropriate, firmware acting in accordance with a preconfigured processor may cause the processor to act as a special-purpose processor provided for the purpose of performing the method or any reasonable variation thereof.

[0031] In the illustrative example from Fig. 3, the vehicle uploads data related to planned usage (over an upcoming period) to a remote server for processing and recommending alternative usage plans 301. If changes to a departure time, route changes, and / or changes to charging schedules result from the recommendations, the process receives the recommended changes 303. In this example, the vehicle-based process then communicates with the user directly 305 to confirm implementation 307 of the suggested changes (or to receive a selection from a list of possible changes). If the user accepts or selects a change, the vehicle implements the changes, for example, to a route planning process and / or a charging schedule. Any preconditioning based on the predicted start time may also be changed according to the recommendation.

[0032] In another example, the backend server manages the confirmation with the user and can transmit any required changes to the vehicle as confirmed by the user. Any communication model that results in the vehicle implementing confirmed / selected changes is suitable.

[0033] Fig.Figure 4 shows an illustrative process for determining vehicle usage changes. With respect to the illustrative embodiments described in this figure, it should be noted that a general-purpose processor may be temporarily enabled as a special-purpose processor for the purpose of performing some or all of the example methods shown herein. When code providing instructions for performing some or all steps of the method is executed, the processor may be temporarily repurposed as a special-purpose processor until such time as the method is completed. In another example, where appropriate, firmware acting in accordance with a preconfigured processor may cause the processor to act as a special-purpose processor provided for the purpose of performing the method or any reasonable variation thereof.

[0034] In this illustrative example, the backend server (which is the entity that performs the recommendation calculation in this example) receives the relevant data related to the planned usage from the vehicle 401. This data could also be received from, for example, a schedule input to a user's phone, and / or the phone itself could act as the entity providing a recommendation (if it is directly or indirectly associated with the vehicle). In yet another example, the vehicle itself could perform the recommendation processing if suitable processing power and resources are available for use by a vehicle computing system.

[0035] In this example, the process then accesses traffic data 403. This may include current traffic data (for recommendations made on the spot) and predicted traffic data based on observed traffic patterns for a particular day of the week, time of day, and / or date. If a high (or threshold) traffic volume is not anticipated via a preferred route (or observed on a route to be taken in the near future), the process may send a confirmation to the vehicle that the proposed usage is appropriate 407. It is also possible to take no action, in which case the process may later update a recommendation based on a change in the observed or predicted traffic patterns (e.g., if an accident occurs).

[0036] If high traffic volume (or a high traffic threshold) is observed or predicted, the process may determine whether a vehicle charge, based on a preferred charge start time, is sufficient to complete the preferred route at the preferred start time. If the charge is insufficient, a recommendation to change the charge start time may be sent to the user 411. In other examples, the recommendation may be added to a list of possible recommendations to be sent at a time for user selection (such that the user does not confirm a charge start time change and subsequently receives a recommendation to take a different route or use a different departure time a few seconds later).

[0037] If it is determined that a better departure time exists 413 (i.e., a departure time that will result in a faster trip based on current or predicted traffic over a route starting at the recommended start time), then the process may determine whether a sufficient state of charge will exist to complete the route (and / or return home or reach another charging location) 415 based, for example, on a current charging start time and a current state of charge. If the state of charge will not be sufficient or is not already sufficient, the process may recommend a new charging start time 417. In this case, or if the state of charge is or will be sufficient, the process may also recommend the new departure time 419. Again, this recommendation may be part of a list of possible actions based on various recommendations.

[0038] For a related example, if a user typically departs at 7:30 a.m. but a 6:30 a.m. departure is recommended, one of the following scenarios may arise: a) the vehicle may already have an appropriate amount of charge for any predicted usage demand, even if the route starts earlier; b) the vehicle may achieve the appropriate amount of charge based on a current charge start time at the time the new departure occurs (this is often the case when a later departure is recommended); c) the vehicle may achieve the appropriate amount of charge based on a new charge start time at the time the new departure occurs; or d) there is not enough time left before the new departure time for the vehicle to achieve the appropriate amount of charge.

[0039] As an illustrative example, cases a) and b) above may simply result in a recommendation to change a departure time. Case c) may result in a recommendation to change a departure time and a recommendation to change a charging start time. Case d) may result in a decision not to recommend the new departure time, as it is likely to leave the user stranded. In case d), the new departure time may also be recommended, but it may also be advisable to inform the user of a predicted charge deficit so that the user is aware that charging may be required later in the day.

[0040] Next, the illustrative process determines whether one or more better routes (i.e., faster routes and / or routes with less traffic or a lower traffic probability) exist 421. If no better routes exist, the process may maintain the current settings 429 and / or send recommendations to the user related to any recommended changes not yet sent. A confirmation according to user selections (if any) may also be sent at this time 431 upon receipt of a user selection and / or confirmation.

[0041] If better routes or a single better route exist, the process redetermines whether a state of charge is or will be sufficient to complete the trip via the new route(s). As above, this consideration may include a current state of charge, a predicted state of charge, and a charge determined to be needed to return home and / or reach a recharging location. If the charge is or will be insufficient, the process may recommend 425 a new charge start time as above. If the charge is or will be sufficient, or in conjunction with the recommendation to change the charge start time, the process may then recommend one or more new routes.

[0042] In each of the above cases, one or more recommendations may be provided. For example, a complete set of recommendations may include: 1) A notification that traffic will be heavy and, if a desired start time is to be maintained, charging must begin one hour earlier to avoid an energy deficit due to delays; 2) A recommendation to change a departure time from 7:30 a.m. to 8:30 a.m., including, if desired, a predicted travel time difference and / or energy usage difference; 3) A recommendation to change a departure time from 7:30 a.m. to 6:30 a.m. and a recommendation to start charging 30 minutes earlier, including any changes to travel time and energy consumption, if applicable; 4) A recommendation to use an alternative route A, including any changes to travel time and energy consumption, if applicable.5) a recommendation to use an alternative route B and a recommendation to start charging 45 minutes earlier, including any changes to travel time and energy consumption, if any; and 6) a recommendation to depart at 7:10 a.m., to use an alternative route B and a recommendation to start charging 25 minutes earlier, including any changes to travel time and energy consumption, if any.

[0043] As can be seen from the example above, recommendation 6) provides a departure time that most closely approximates the desired departure time, but also uses an alternative route to ensure a faster arrival and / or lower energy consumption. In this case, route B may be slightly longer and require a minor adjustment to the recharge time, which could also be based on the earlier start time. The user could select any desired recommended change, and the process could then send instructions to the vehicle to make the appropriate changes, for example, to departure time, route data, and / or preconditioning start time.

[0044] Fig.Figure 5 shows an illustrative process for receiving and acknowledging a vehicle usage change. Regarding the illustrative embodiments described in this figure, it should be noted that a general-purpose processor may be temporarily enabled as a special-purpose processor for the purpose of performing some or all of the example methods shown herein. When code providing instructions for performing some or all of the steps of the method is executed, the processor may be temporarily repurposed as a special-purpose processor and remain so until the method is completed. In another example, where appropriate, firmware acting in accordance with a preconfigured processor may cause the processor to act as a special-purpose processor provided for the purpose of performing the method or any reasonable variation thereof.

[0045] In this illustrative example, the process represents a user confirmation process, e.g., executed on a user device. Here, the user receives a notification of a recommended change 501, including one or more recommendations for changes to departure time, route, and / or charging start time. The process receives a user selection of the corresponding recommendation and then checks, in this case, to ensure that a new charging start time has also been selected and is suitable for obtaining sufficient charge before the trip 505. If the charge will be sufficient, the process sends the new settings to the vehicle 511 (this may be done indirectly through the server, depending on the communication system used).If the user selects a new departure or route but does not wish to make changes to the charging start time, the process can warn the driver that insufficient charge is likely for the predicted usage. 507 If the driver confirms this is OK (for example, if the driver knows they can charge the vehicle at their workplace, although the process may not be aware of this fact), then the process can send the changes to the vehicle. Otherwise, the driver can reject the change based on a desire not to change the charging start time, and the process can exit without sending the changes.

[0046] Although exemplary embodiments are described above, it is not intended that these embodiments describe all possible forms of the invention. Rather, the terms used in the specification are terms 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 implementing embodiments may be combined to form further embodiments of the invention. Key to symbols: Fig. 1: Fig. 1: 61: Network 61: Network 53: ND 53: ND 63: Mdm 63: Mdm 15: BTT 15: BTT 4: Display 4: Display 51: Input Selector 51: Input selector 52: BT Pair 52: BT pair 11: Amp 11: Vers. 9: D / A 9: D / A 3: CPU 3: CPU 73: Router 73: Router 7: HDD 7: HDD 5: RAM 5: RAM 27: A / D 27: A / D 24: GPS 24: GPS 25: Aux 25: Aux 65: Aux Device 65: Auxiliary device 23, 69, 56, 62: USB 23, 69, 56, 62: USB 54: Personal Nav. Dev. 54: Personal navigation reserve 60: Vehicle Nav. Dev. 60: Vehicle Navigation Pre-arrangement Fig. 2: Fig. 2: Upload data to cloud: Uploading data to cloud: - "Go" time - "Start" time - route / destination - Route / Destination - % of battery charged - % charged battery 203: TCU 203: TCU Local traffic department Local traffic department Traffic information Traffic information Backend server backend server Determine if there is a need to update the route based on: Determine whether there is a need to update the route based on: - "Go" time - route / destination - "Start" time - % of battery charged - Route / Destination - traffic information - % charged battery - Traffic information Sends more preferred route plans to the customer's mobile phone - more preferred "go" time - more preferred "route" Sending more preferred route plans to the customer's mobile phone - more preferred "departure" time - more preferred "route" Fig. 3: Fig. 3: 301: Upload data 301: Uploading data 303: Receive schedule changes 303: Receiving plan changes 305: Communicate with user 305: Communicate with user 309: Implement changes 309: Implementing Changes YES YES NO NO 307: Implement suggestions? 307: Implement suggestions? Exit Finish Fig. 4: Fig. 4: 401: Receive data 401: Receiving data 403: Access traffic data 403: Accessing traffic data 405: High traffic? 405: High traffic volume? YES YES NO NO 407: Send confirmation 407: Sending Confirmation 417: Send new recommended start change time 417: Sending new recommended start change time 409: Change sufficient? 409: Change sufficient? 411: Send new recommended start change time 411: Sending new recommended start change time 415: Change sufficient? 415: Change sufficient? 413: Better departure times? 413: Better departure times? 419: Send new departure time(s) 419: Sending new departure time(s) Fig. 4 (cont.): Fig. 4 (continued): 421: Better route? 421: Better route? 423: Change sufficient? 423: Change sufficient? YES YES NO NO 425: Send new recommended start change time 425: Sending new recommended start change time 429: Maintain settings 429: Retaining settings 427: Send new route(s) 427: Sending new route(s) 431: Send confirmation 431: Sending confirmation Fig. 5: Fig. 5: 501: Receive notification 501: Received notification 503: Receive selection 503: Receiving Selection 505: New change time acceptable? 505: New modification time acceptable? YES YES NO NO 507: Warning driver 507: Warning the driver 511: Send new settings to vehicle 511: Send new settings to vehicle 509: Confirmed? 509: Confirmed? YES YES NO NO

Claims

[1] System comprising: a processor (3) configured to: Receiving a desired departure time and route for an upcoming trip from a vehicle computer system; Determining a traffic volume based on the received departure time and route; Determining a vehicle charge level; and Recommending a new route or departure time if the vehicle charge level is predicted to be sufficient to achieve a trip completion based on the new route and departure time, wherein the vehicle charge level is a predicted vehicle charge level based on a preferred charge start time, and wherein the processor (3) is further configured to recommend a new charge start time if the predicted vehicle charge level is predicted to be insufficient to achieve a trip completion based on the new route or departure time. [2] The system of claim 1, wherein the traffic volume is a current traffic volume. [3] The system of claim 1, wherein the traffic volume is a predicted traffic volume. [4] The system of claim 1, wherein the vehicle charge state is a current vehicle charge state. [5] The system of claim 1, wherein the processor (3) is configured to recommend the new route or departure time in a message to a user device. [6] The system of claim 5, wherein the processor (3) is configured to receive an acceptance confirmation of the new departure time from the user device. [7] The system of claim 6, wherein the processor (3) is configured, upon acknowledgment of receipt, to send instructions to the vehicle computer system informing the vehicle computer system of the assumed new departure time. [8] System comprising: a processor (3) configured to: Determining a predicted travel time based on a predicted traffic volume over a preferred route starting at a preferred departure time received from a vehicle computer; and Recommend an alternative departure time that results in a shorter predicted travel time if a current vehicle charge level is predicted, received from the vehicle computer is sufficient to complete the trip using the alternative departure time, wherein the processor (3) is further configured to recommend a vehicle charging start time that is expected to result in a charging period that provides a sufficient vehicle charge level, to complete the trip using the alternative departure time or an alternative route if the current vehicle charge level is predicted to be insufficient to complete the trip using the alternative departure time or the alternative route.

Images