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 . fig1 illustrates an example 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 contain a visual front end interface 4 located in the vehicle . the user may also be able to interact with the interface if it is provided , for example , with a touch sensitive screen . in another illustrative embodiment , the interaction occurs through , button presses , spoken dialog system with automatic speech recognition and speech synthesis . in the illustrative embodiment 1 shown in fig1 , a processor 3 controls at least some portion of the operation of the vehicle - based computing system . provided within the vehicle , the processor allows onboard processing of commands and routines . further , the processor is connected to both non - persistent 5 and persistent storage 7 . in this illustrative embodiment , the non - persistent storage is random access memory ( ram ) and the persistent storage is a hard disk drive ( hdd ) or flash memory . the processor is also provided with a number of different inputs allowing 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 swap between various inputs . 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 , numerous 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 pass data to and from the vcs ( or components thereof ). outputs to the system can include , but are not limited to , a visual display 4 and a speaker 13 or 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 . output can also be made to a remote bluetooth device such as pnd 54 or a usb device such as vehicle navigation device 60 along the bi - directional data streams shown at 19 and 21 respectively . in one illustrative embodiment , the system 1 uses the bluetooth transceiver 15 to communicate 17 with a user &# 39 ; s nomadic device 53 ( e . g ., cell phone , smart phone , pda , or any other device having wireless remote network connectivity ). the nomadic device can then be used to communicate 59 with a network 61 outside the vehicle 31 through , for example , communication 55 with a cellular tower 57 . in some embodiments , tower 57 may be a wifi access point . exemplary communication between the nomadic device and the bluetooth transceiver is represented by signal 14 . pairing a nomadic device 53 and the bluetooth transceiver 15 can be instructed through a button 52 or similar input . accordingly , the cpu is instructed that the onboard bluetooth transceiver will be paired with a bluetooth transceiver in a nomadic device . data may be communicated between cpu 3 and network 61 utilizing , for example , a data - plan , data over voice , or dtmf tones associated with nomadic device 53 . alternatively , it may be desirable to include an onboard modem 63 having antenna 18 in order to communicate 16 data between cpu 3 and network 61 over the voice band . the nomadic device 53 can then be used to communicate 59 with a network 61 outside the vehicle 31 through , for example , communication 55 with a cellular tower 57 . in some embodiments , the modem 63 may establish communication 20 with the tower 57 for communicating with network 61 . as a non - limiting example , modem 63 may be a usb cellular modem and communication 20 may be cellular communication . in one illustrative embodiment , the processor is provided with an operating system including an api to communicate with modem application software . the modem application software may access an embedded module or firmware on the bluetooth transceiver to complete wireless communication with a remote bluetooth transceiver ( such as that found in a nomadic 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 realm is free - space optical communication ( such as irda ) and non - standardized consumer ir protocols . in another embodiment , nomadic device 53 includes a modem for voice band 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 talk over the device while data is being transferred . at other times , when the owner is not using the device , the data transfer can use the whole bandwidth ( 300 hz to 3 . 4 khz in one example ). while 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 ) compliant standards and offer data rates up to 2 mbs for stationary or walking users and 385 kbs for users in a moving vehicle . 3g standards are now being replaced by imt - advanced ( 4g ) which offers 100 mbs for users in a vehicle and 1 gbs for stationary users . if the user has a data - plan associated with the nomadic device , it is possible that the data - plan allows for broad - band transmission and the system could use a much wider bandwidth ( speeding up data transfer ). in still another embodiment , nomadic device 53 is replaced with a cellular communication device ( not shown ) that is installed to 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 can be passed through the nomadic device via a data - over - voice or data - plan , through the onboard bluetooth transceiver and into the vehicle &# 39 ; s internal processor 3 . in the case of certain temporary data , for example , the data can be stored on the hdd or other storage media 7 until such time as the data is no longer needed . 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 remote navigation system ( not shown ) having connectivity to 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 device - device serial standards . most of the protocols can 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 can be connected through a wireless 67 or wired 69 connection . auxiliary device 65 may include , but are 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 , using for example a wifi 71 transceiver . this could allow the cpu to connect to remote networks in range of the local router 73 . in addition to having exemplary processes 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 through the wireless device . collectively , such systems may be referred to as vehicle associated computing systems ( vacs ). in certain embodiments particular components of the vacs may perform particular portions of a process depending on the particular 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 , since the wireless device would not “ send and receive ” information with itself . one of ordinary skill in the art will 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 exemplary processes . although modern electric vehicles may offer the convenience of home - charging , while a user is away from a vehicle , potential problems with a power connection ( e . g ., without limitation , unplugging , outlet failure , power outage ) can leave an owner unaware that a vehicle is not actually charging . the illustrative embodiments present some exemplary aspects of the invention which can aid in notifying a user when a power connection has been interrupted . while all embodiments are capable of near - constant or constant notification , repeated and endless communication may annoy a user . accordingly , it is understood that repetitive warnings can be truncated after a certain number of warnings ( including a single warning ) and that brief interruptions in the power supply can be accounted for in all cases . while optional , these considerations may prevent users from being overwhelmed with warnings , and may also allow brief power interruptions to go unwarned , as they may generally tend not to greatly impact the overall charge state . fig2 shows an illustrative example of a charging alert process . in this illustrative example , the process ( which can be , for example , an on - board monitoring process , running off of the battery or a backup power supply ) first checks to see if a vehicle is currently charging 201 . in this example , if the vehicle is charging , then the process for reporting a charge interruption may not be needed . a delay ( not shown ) of some time period can be interspersed before checking charging again , or the process can simply continue to monitor charging continuously until a charging interruption registers . if the vehicle charging ceases , the process may check a remaining amount of time needed to charge 203 . in at least one implementation , the process may have a known vehicle start time ( i . e ., the time the next day , or later the same day , the vehicle is needed ) and a known needed charge level . this information can be fully or partially input by a user , or it can be fully or partially determined based on observations of a user &# 39 ; s travel habits . for example , in one instance , a user may note that on weekdays the vehicle is needed at approximately 7 am , and that a 20 - mile each way round - trip journey is contemplated . based on fuel economy statistics , and any other known information ( weather , traffic , etc .) the process can “ know ” how much power is required to complete such a trip . this information can then be used to determine a minimum charge requirement for trip completion , with a buffer built in if desired . based on a current charging rate , and known minimum charge , a total time needed to charge the vehicle to the minimum level can be determined 203 . additionally , the user may only wish to charge a vehicle during certain power company “ windows ”. for example , power usage may be cheaper between certain hours , given a particular locale and power company guidelines . if the optimal pricing on usage is obtained from midnight to five am , the user may only wish to charge during this window . accordingly , in this example , even if the vehicle is not charging , the process checks to see if the time is within a charging window 205 before alerting the user of the charging interruption . also , in this example , the process determines whether sufficient time to charge the vehicle remains 207 . for example , if a user arrived home at 3 am and plugged in a vehicle , and needed the vehicle at 7 am , four total hours to charge the vehicle would remain . if charging were interrupted at 3 : 30 am , and the full four hours were needed to charge the vehicle , the process may determine that insufficient total time to fully charge the vehicle remains 207 . in such a case , the process may alert a user 209 that the vehicle will not be fully charged to a predicted sufficient level to complete the next day &# 39 ; s journey . in this case , the user may correct any charging interruption process , and take action to achieve the remaining charge . this can include , but is not limited to , setting a later end point for a window and sleeping in , stopping for additional power on the way to / from the destination , etc . if sufficient time remains , the process checks to see if a no - charge condition is approaching a warning range . if a charging window was from midnight to 7 am , and power went out at 1 am , but only three hours was needed to charge the vehicle , the 1 am power outage does not necessarily present a sufficient problem at 1 am worthy of alerting a user . but as 3 or 4 am approaches , if charging has not yet resumed , a problem could arise . in this case , as a warning range ( in this example , some suitable period of time wherein sufficient time remains to charge the vehicle as needed still remains ) is approached , the process may alert the user to the continued no - charging state 213 , so the user can take appropriate action . the configuration of the time range can be up to the user . some users may want to be alerted any time charging is interrupted prior to reaching a needed charge , other users may only want to be alerted if a critical situation is imminent . the user can set conditions for warning , and can also configure a window prior to a critical point in which warnings should be sent . the particulars of these choices are all contemplated to be within the scope of the invention . fig3 shows a second illustrative example of a charging alert process . in this illustrative example , the process again checks to see if the vehicle is charging 301 . if the vehicle is not charging , the process determines if the time of day is within a designated charging window 303 ( assuming any window has been designated at all ). if the time of day is within the charging window , the process may additionally check to see if a suitable delay has passed since the no - charge state was detected 305 . for example , it may not be desirable to notify a user for an interruption of only a few minutes in charging . in this embodiment , a delay ( user or oem defined , for example ) can be set such that only delays in charging over a certain length result in user notification . if the delay has not passed , the process continues to check to see if charging is on - going or has resumed . once a suitable delay has passed , the process determines if a departure time is known 307 . if the user has established or entered a departure time , it may be specifically or generally known to the process . if there is not a known departure time , the process may attempt to predict a departure time 309 . this can be done , for example , based on previously observed behavior and will be discussed in greater detail with respect to fig4 a and 4b . one a departure time is known , the process can determine an amount of time remaining prior to departure 311 . the process can also check a current charge level 313 , which may be additionally useful for determining if an alert should be sent to a user . the process also checks to see if a particular required charge level is known 315 . again , this could be based on user input data ( trip duration , distance , etc .). if there is insufficient information to “ know ” the needed charge , the process may attempt to predict a needed charge level 317 , again discussed in more detail below . once the departure time , time remaining and needed charge level have been analyzed ( and / or guessed , as appropriate ) the process may determine if it is even possible , in the time remaining , to achieve the needed charge level 319 . if it is not possible , the process may alert the owner to the situation 321 , and then resume charge monitoring . since the process relies on the owner to rectify a no - charging situation , the resumption of monitoring can result in additional warnings , if needed , that can help the owner perform the needed corrections . if there is sufficient total time remaining , but the process is not yet nearing a critical point 323 ( e . g ., if there is more than a predetermined amount of surplus time remaining ), the process may simply continue monitoring . once there is less than the predetermined amount of surplus time remaining 323 , the process may alert the owner that a critical window is approaching 325 , so that the owner can take appropriate steps to rectify any problems . fig4 a shows an illustrative example of a stop / power recording process . this is just one example of how data can be recorded , to aid in future power need / time need evaluations , and it shows how a predictive process can be implemented with little overhead . other predictive processes may also be used , as desired by one implementing the warning system . in this illustrative example , the process detects that a vehicle engine has been started 401 . generally , this will correspond to the start of a trip , and a time of day and day of week are recorded 403 . the recording of this information can be done so that predictions can be made for similar days of the week in following weeks , since many people follow a somewhat common schedule in terms of vehicle usage . also , a current power level is recorded 405 . this can be used when a park state is detected to determine how much power was used during the course of a journey . in addition to the above information , a vehicle location is recorded 407 . in this example , the vehicle location is also useful in predicting vehicle usage needs , since time and power needs are most likely to be common when the vehicle is departing from a common location . in other words , if the user lives in michigan and the vehicle is parked in ohio , then it is likely that the next day &# 39 ; s journey will not be the typical journey for that day of the week ( since the user is likely on a trip of some sort ). the process then continues to check whether or not the vehicle has entered a “ park ” state 409 . a park state is used here as a proxy for stop detection , although other suitable determinations correlating to a journey end point may also be used . also , in at least one embodiment , the process may require that the vehicle remain in the park state for some period of time , to ensure that more than a mere temporary stop is being made ( e . g ., fuel , food , etc .). once the process has determined that the vehicle has reached a destination , through an appropriate mechanism , the process may proceed to record the location of the destination 411 and an amount of power used to reach the destination 413 . recorded power usage can be later used to predict needed power to reach a destination . recorded destination location can be later used to predict if a change in weather / traffic / etc . will require increased / decreased power to reach the destination . the destination can also , on a day by day basis , for example , be compared to other destinations to which the user travels on the same day of the week , to determine commonality of a certain destination , thus providing statistical likelihood of traveling to that destination . fig4 b shows an illustrative example of a stop / power usage prediction process . in this illustrative example , a warning process may utilize the present process to help guess where a vehicle is headed , when a vehicle is needed , and how much power will be needed by the vehicle to reach the predicted destination . the process first accesses a stored profile for one or more drivers of the vehicle 421 . which profile ( s ) is / are selected may depend on how many drivers a vehicle has , how frequently each driver uses the vehicle , etc . the process then determines if a current day of week matches any stored days of the week 423 . for example , if today ( or tomorrow morning , depending on the time ) is tuesday , the process will check to see if data has been stored for previous tuesdays . if there is data stored for similar days from previous weeks , the process may check to see if a significant non - earliest time exists 425 . by significant non - earliest time , this example refers to a time , later than the earliest recorded usage time , that occurs a statistically significant number of times . for example , if a user typically goes to work at 8 am , but one day left at 6 am , then the earliest recorded data may be 6 am , but the 8 am departures would accumulate as being statistically significant . this check is made , in this example , because in the absence of such a time , the process will select the earliest known time 427 , in an attempt to ensure that the user &# 39 ; s vehicle will be suitably charged at the earliest likely moment of need . additionally , a buffer zone may be built in around recorded times , such that times within , for example , fifteen minutes of each other are all treated as a median time ( or other suitable approximation ). if there is a significant time , other than the earliest time , the process may select that time for use 429 . regardless of which time is selected , the process proceeds to retrieve an associated power requirement , saved with respect to that time 431 . since , in this portion of this example , at least some data has been previously observed and recorded , the process can guess , even roughly , an approximation of how much power will be needed . if only one or two data points exist , the guess may have a higher likelihood of being incorrect , but if sufficient data points exist then the guess may be closer to an accurate one based on previously observed behavior . if there is no data that matches the current day of the week 423 , the process may determine whether or not the relevant day is a weekday 433 . since the majority of the population works on weekdays , the process may make some assumptions about usage until data can be recorded . if the process is implemented as soon as or soon after a vehicle is purchased , this “ standard ” data will only be needed on a short term basis . if the day is a weekday , the process will select generic weekday data 437 , otherwise the process will select generic weekend data 435 . next , in this example , the process determines if there is any data at all for a weekend day or a weekday 439 . for example , if a vehicle process was first activated on a wednesday , and it is the following tuesday , there will be no wednesday data , but there will be some saved weekday data . if there is weekday data , the process will use the closest day 441 ( for example , utilizing a monday or wednesday for a tuesday ) or any other suitable combination of existing data . the process can then continue as previously described , substituting the data from the selected day ( s ) for the data that is not yet recorded for the current day of the week . if there is no data suitable to use as a proxy for the current day of the week , the process will use a “ standard time ” 443 . this could be , for example 7 : 30 am , or any other suitable time likely to cover a significant portion of users , without creating situations likely to annoy too many users . for example , if 5 am was selected , it would probably ensure a higher percentage of user coverage , but it may also ensure a much higher percentage of false positives on the charging results ( i . e ., vehicles that would be charged when they &# 39 ; re actually needed , may not be charged by 5 am ). based on a particular implementation &# 39 ; s needs , the give and take between the two constraints ( and any other constraints ) can be considered and adjustments can be made accordingly . once the process has selected a departure time , it may also guess at a standard power need . in one example , this could always be “ full ,” but again , a full power cell may be more than most people need and may result in many false positives . the manufacturer or other implementer of the process can determine a suitable compromise likely to result in a desired number of false positives while at the same time still maintain sufficient coverage for a desired number of customers . while 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 . additionally , the features of various implementing embodiments may be combined to form further embodiments of the invention .