TECHNICAL FIELD

[0001] Disclosed herein are personalized notification systems for repetitive road conditions.

BACKGROUND

[0002] Drivers often travel the same route on a daily basis. Oftentimes, road hazards are present on a particular route. Such road hazards may remain unresolved for a long period of time, thus causing a vehicle to encounter the hazard on a routine basis.

SUMMARY

[0003] A personalized vehicle notification system may include a controller configured to receive user input indicative of a road event and to catalog the road event and user input along with an event distance associated therewith, the controller further configured to generate, during a subsequent trip, an alert identifying the road event in response to a current distance being within a predefined threshold of the event distance.

[0004] A vehicle notification system may include a controller configured to generate an alert identifying a road event based on a current distance and a previously recorded road event having an event distance associated therewith, the current distance based on a duration and average speed of a current route, and generate a prompt for a user to confirm whether the road event is still present.

[0005] A method may include receiving a user input indicative of a road event, cataloging the road event and user input along with an event distance associated therewith, generating, during a subsequent trip, an alert identifying the road event in response to a current distance being within a predefined threshold of the event distance. BRIEF DESCRIPTION OF THE DRAWINGS

[0006] The embodiments of the present disclosure are pointed out with particularity in the appended claims. However, other features of the various embodiments will become more apparent and will be best understood by referring to the following detailed description in conjunction with the accompanying drawings in which:

[0007] Figures 1A and IB illustrate an example diagram of a system that may be used to provide telematics services to a vehicle;

[0008] Figure 2 illustrates an example block diagram of a personalized alert system;

[0009] Figure 3 illustrates an example diagram for a portion of the personalized alert system;

[0010] Figure 4 illustrates an example process for cataloging road events; and

[0011] Figure 5 illustrates an example process for issuing alerts for repetitive road conditions.

DETAILED DESCRIPTION

[0012] 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.

[0013] Most drivers travel repetitive routes during their daily commutes. Observed hazardous road conditions (such as potholes, bumps, ice, road obstructions, etc.) generally remain unresolved for long periods of time. Although drivers may routinely travel these routes, the driver may forget about certain conditions, resulting in repetitive contact with these conditions, which may lead to vehicle damage and subsequently, necessary vehicle repairs. [0014] Disclosed herein is a personalized notification system configured to alert the driver as to road conditions or events that may be problematic to the vehicle. For example, the notification system may warn a driver as to a pothole on the road. The road event may be recognized by the vehicle and cataloged in a database. The road event may be cataloged with an event distance, as well as a customized alert. In a subsequent trip, when the vehicle has traveled a distance similar to the event distance, the notification system may alert the driver as to the upcoming road event. The alert may come in several forms including an audible alert, visual alert via the vehicle human machine interface (HMI), etc. Furthermore, the system may receive user inputs to customize the alert. In one example, the system may record an audible message from the driver about the road event, and replay that message during the subsequent trip as part of the alert.

[0015] Figures 1 A and IB illustrate an example diagram of a system 100 that may be used to provide telematics services to a vehicle 102. The vehicle 102 may be one of various types of passenger vehicles, such as a crossover utility vehicle (CUV), a sport utility vehicle (SUV), a truck, a recreational vehicle (RV), a boat, a plane or other mobile machine for transporting people or goods. Telematics services may include, as some non-limiting possibilities, navigation, turn-by-turn directions, vehicle health reports, local business search, accident reporting, and hands-free calling. In an example, the system 100 may include the SYNC system manufactured by The Ford Motor Company of Dearborn, Michigan. It should be noted that the illustrated system 100 is merely an example, and more, fewer, and/or differently located elements may be used.

[0016] The computing platform 104 may include one or more processors 106 and controllers configured to perform instructions, commands and other routines in support of the processes described herein. For instance, the computing platform 104 may be configured to execute instructions of vehicle applications 110 to provide features such as navigation, accident reporting, satellite radio decoding, hands-free calling and parking assistance. Such instructions and other data may be maintained in a non-volatile manner using a variety of types of computer-readable storage medium 112. The computer-readable medium 112 (also referred to as a processor-readable medium or storage) includes any non-transitory medium (e.g., a tangible medium) that participates in providing instructions or other data that may be read by the processor 106 of the computing platform

104. Computer-executable instructions may be compiled or interpreted from computer programs created using a variety of programming languages and/or technologies, including, without limitation, and either alone or in combination, Java, C, C++, C#, Objective C, Fortran, Pascal, Java Script, Python, Perl, and PL/SQL.

[0017] The computing platform 104 may be provided with various features allowing the vehicle occupants to interface with the computing platform 104. For example, the computing platform 104 may include an audio input 114 configured to receive spoken commands from vehicle occupants through a connected microphone 116, and auxiliary audio input 118 configured to receive audio signals from connected devices. The auxiliary audio input 118 may be a physical connection, such as an electrical wire or a fiber optic cable, or a wireless input, such as a BLUETOOTH audio connection. In some examples, the audio input 114 may be configured to provide audio processing capabilities, such as pre-amplification of low-level signals, and conversion of analog inputs into digital data for processing by the processor 106.

[0018] The computing platform 104 may also provide one or more audio outputs 120 to an input of an audio module 122 having audio playback functionality. In other examples, the computing platform 104 may provide the audio output to an occupant through use of one or more dedicated speakers (not illustrated). The audio module 122 may include an input selector 124 configured to provide audio content from a selected audio source 126 to an audio amplifier 128 for playback through vehicle speakers 130 or headphones (not illustrated). The audio sources 126 may include, as some examples, decoded amplitude modulated (AM) or frequency modulated (FM) radio signals, and audio signals from compact disc (CD) or digital versatile disk (DVD) audio playback. The audio sources 126 may also include audio received from the computing platform 104, such as audio content generated by the computing platform 104, audio content decoded from flash memory drives connected to a universal serial bus (USB) subsystem 132 of the computing platform 104, and audio content passed through the computing platform 104 from the auxiliary audio input 118.

[0019] The computing platform 104 may utilize a voice interface 134 to provide a hands-free interface to the computing platform 104. The voice interface 134 may support speech recognition from audio received via the microphone 116 according to grammar associated with available commands, and voice prompt generation for output via the audio module 122. In some cases, the system may be configured to temporarily mute or otherwise override the audio source specified by the input selector 124 when an audio prompt is ready for presentation by the computing platform 104 and another audio source 126 is selected for playback.

[0020] The computing platform 104 may also receive input from human-machine interface

(HMI) controls 136 configured to provide for occupant interaction with the vehicle 102. For instance, the computing platform 104 may interface with one or more buttons or other FDVII controls configured to invoke functions on the computing platform 104 (e.g., steering wheel audio buttons, a push-to-talk button, instrument panel controls, etc.). The computing platform 104 may also drive or otherwise communicate with one or more displays 138 configured to provide visual output to vehicle occupants by way of a video controller 140. In some cases, the display 138 may be a touch screen further configured to receive user touch input via the video controller 140, while in other cases the display 138 may be a display only, without touch input capabilities.

[0021] The computing platform 104 may be further configured to communicate with other components of the vehicle 102 via one or more in-vehicle networks 142. The in-vehicle networks 142 may include one or more of a vehicle controller area network (CAN), an Ethernet network, and a media oriented system transfer (MOST), as some examples. The in-vehicle networks 142 may allow the computing platform 104 to communicate with other vehicle 102 systems, such as a vehicle modem 144 (which may not be present in some configurations), a global positioning system (GPS) module 146 configured to provide current vehicle 102 location and heading information, and various vehicle ECUs 148 configured to cooperate with the computing platform 104. As some non-limiting possibilities, the vehicle ECUs 148 may include a powertrain control module configured to provide control of engine operating components (e.g., idle control components, fuel delivery components, emissions control components, etc.) and monitoring of engine operating components (e.g., status of engine diagnostic codes); a body control module configured to manage various power control functions such as exterior lighting, interior lighting, keyless entry, remote start, and point of access status verification (e.g., closure status of the hood, doors and/or trunk of the vehicle 102); a radio transceiver module configured to communicate with key fobs or other local vehicle 102 devices; and a climate control management module configured to provide control and monitoring of heating and cooling system components (e.g., compressor clutch and blower fan control, temperature sensor information, etc.), and other sensors, etc. [0022] As shown, the audio module 122 and the HMI controls 136 may communicate with the computing platform 104 over a first in-vehicle network 142- A, and the vehicle modem 144, GPS module 146, and vehicle ECUs 148 may communicate with the computing platform 104 over a second in-vehicle network 142-B. In other examples, the computing platform 104 may be connected to more or fewer in-vehicle networks 142. Additionally or alternately, one or more HMI controls 136 or other components may be connected to the computing platform 104 via different in-vehicle networks 142 than shown, or directly without connection to an in-vehicle network 142.

[0023] The computing platform 104 may also be configured to communicate with mobile devices 152 of the vehicle occupants. The mobile devices 152 may be any of various types of portable computing devices, such as cellular phones, tablet computers, smart watches, laptop computers, portable music players, or other devices capable of communication with the computing platform 104. In many examples, the computing platform 104 may include a wireless transceiver 150 (e.g., a BLUETOOTH module, a ZIGBEE transceiver, a Wi-Fi transceiver, an IrDA transceiver, an RFID transceiver, etc.) configured to communicate with a compatible wireless transceiver 154 of the mobile device 152. Additionally or alternately, the computing platform 104 may communicate with the mobile device 152 over a wired connection, such as via a USB connection between the mobile device 152 and the USB subsystem 132.

[0024] The communications network 156 may provide communication services, such as packet-switched network services (e.g., Internet access, VoIP communication services), to devices connected to the communications network 156. An example of a communications network 156 may include a cellular telephone network. Mobile devices 152 may provide network connectivity to the communications network 156 via a device modem 158 of the mobile device 152. To facilitate the communications over the communications network 156, mobile devices 152 may be associated with unique device identifiers (e.g., mobile device numbers (MDNs), Internet protocol (IP) addresses, etc.) to identify the communications of the mobile devices 152 over the communications network

156. In some cases, occupants of the vehicle 102 or devices having permission to connect to the computing platform 104 may be identified by the computing platform 104 according to paired device data 160 maintained in the storage medium 112. The paired device data 160 may indicate, for example, the unique device identifiers of mobile devices 152 previously paired with the computing platform 104 of the vehicle 102, such that the computing platform 104 may automatically reconnected to the mobile devices 152 referenced in the paired device data 160 without user intervention.

[0025] When a mobile device 152 that supports network connectivity is paired with the computing platform 104, the mobile device 152 may allow the computing platform 104 to use the network connectivity of the device modem 158 to communicate over the communications network 156 with the remote telematics services 162. In one example, the computing platform 104 may utilize a data-over-voice plan or data plan of the mobile device 152 to communicate information between the computing platform 104 and the communications network 156. Additionally or alternately, the computing platform 104 may utilize the vehicle modem 144 to communicate information between the computing platform 104 and the communications network 156, without use of the communications facilities of the mobile device 152.

[0026] Similar to the computing platform 104, the mobile device 152 may include one or more processors 164 configured to execute instructions of mobile applications 170 loaded to a memory 166 of the mobile device 152 from storage medium 168 of the mobile device 152. In some examples, the mobile applications 170 may be configured to communicate with the computing platform 104 via the wireless transceiver 154 and with the remote telematics services 162 or other network services via the device modem 158. The computing platform 104 may also include a device link interface 172 to facilitate the integration of functionality of the mobile applications 170 into the grammar of commands available via the voice interface 134 as well as into display 138 of the computing platform 104. The device link interface 172 may also provide the mobile applications 170 with access to vehicle information available to the computing platform 104 via the in-vehicle networks 142. Some examples of device link interfaces 172 include the SYNC APPLINK component of the SYNC system provided by The Ford Motor Company of Dearborn, Michigan, the CarPlay protocol provided by Apple Inc. of Cupertino, California, or the Android Auto protocol provided by Google, Inc. of Mountain View, California. The vehicle component interface application 174 may be one such application installed to the mobile device 152.

[0027] The vehicle component interface application 174 of the mobile device 152 may be configured to facilitate access to one or more vehicle features made available for device configuration by the vehicle 102. In some cases, the available vehicle features may be accessible by a single vehicle component interface application 174, in which case such the vehicle component interface application 174 may be configured to be customizable or to maintain configurations supportive of the specific vehicle 102 brand/model and option packages. In an example, the vehicle component interface application 174 may be configured to receive, from the vehicle 102, a definition of the features that are available to be controlled, display a user interface descriptive of the available features, and provide user input from the user interface to the vehicle 102 to allow the user to control the indicated features. An appropriate mobile device 152 to display the vehicle component interface application 174 may be identified (e.g., mobile display 176), and a definition of the user interface to display may be provided to the identified vehicle component interface application 174 for display to the user.

[0028] Systems such as the system 100 may require mobile device 152 pairing with the computing platform 104 and/or other setup operations. However, as explained in detail below, a system may be configured to allow vehicle occupants to seamlessly interact with user interface elements in their vehicle or with any other framework-enabled vehicle, without requiring the mobile device 152 or wearable device to be paired with or be in communication with the computing platform 104.

[0029] Figure 2 illustrates an example block diagram of a personalized notification system

200. The notification system 200 may be configured as part of computing platform 104. The notification system 200 may also be a standalone system, or configured as part of mobile device 152 and/or remote server 162. The notification system 200 may include a controller 204 having a processor and a memory for carrying out certain processes and instructions described herein. Although shown as a separate component, the controller 204 may be within or part of the computing platform 104. Similarly, a database 206 may be maintained within the computer readable medium 112, which may also participate in providing instructions and other data that may be read by the processor 106 of the computing platform 104.

[0030] The controller 204 may be configured to catalog certain driving events and recall those events to further alert the driver in future routes which may recognize similar events. For example, a driver may encounter a pothole on his or her drive to work each morning. The controller 204 may catalog this pothole and alert the driver in future routes. This process is discussed in greater detail herein. Other types of events may include ice, road obstructions, construction locations, etc.

[0031] The various driving events and road conditions may be maintained within the database 206. The database 206, as explained, may be part of the non-volatile storage 112, as illustrated in Figure 1 A. The database 206 may also be a standalone database. The database 206 may maintain a road condition or driving event, as well as an event distance and alert associated therewith. The event distance may be the distance traveled by the vehicle up until the event. The database 206 may also store an alert associate with the event, as well as other attributes such as driver identification, time of day, average speed, etc., associated with the event.

[0032] The controller 204 may be programmed to determine whether the vehicle 102 is likely to recognize a past event on the current route by comparing the current traveling distance with that of a distance stored in the database 206. If the traveling distance is within a certain threshold of the event distance, the controller 204 may issue an alert to the driver to warn of the upcoming event. For example, if a vehicle is five miles into its current trip, and during the last trip at approximately five miles a pothole was recognized, then the controller 204 may issue an alert to warn the driver of the upcoming pothole.

[0033] The personalized notification system 200 may include a user interface 202. The user interface 202 may include a device configured to interact with the driver. In the example shown in Figure 2, the user interface 202 may include a microphone, such as microphone 116 illustrated in Figure 1. The microphone 116 may be configured to receive spoken commands from the user. Such commands may include alerts from the user as to the previously logged events. In one example, when a user sees, or actually drives over, a pothole on his or her route, the user may say a command such as "warning, pothole." Such a command may trigger the controller 204 to catalog the event and associated distance in the database 206. Additionally or alternatively, the vehicle 102 may recognize a bump and prompt the user to input the event. This is described in more detail below with respect to Figure 4.

[0034] The user interface 202 may also include one or more speakers, such as vehicle speakers 130. The speakers 130 may be configured to, in addition to other vehicle functions such as playing audio from the vehicle stereo systems, etc., emit an audible alert. For example, upon determining that the current traveling distance is within the predefined threshold of an event distance stored in the database 206, the speakers 130 may emit a "warning, pothole ahead" message in an effort to alert the user to the upcoming event.

[0035] The user interface 202 may include a vehicle display, such as the vehicle display 138 shown in Figure 1. The vehicle display 138 may both receive user input and display alerts. The display 138 may present information and alerts to the driver regarding upcoming events and road conditions. The alert may include a textual or pictorial indication relating to the upcoming event. For example, the words "pothole ahead" may be displayed via the display 138. Additionally or alternatively, an image of a pothole may also be presented.

[0036] The display 138 may also be configured to receive user inputs indicating an event.

For example, a selectable icon may be presented and may be selected by the user in response to the user recognizing an event such as a pothole. Upon selecting the icon, the controller 204 may catalog the event in the database 206. Furthermore, the selectable icon may, in response to being selected, prompt a plurality of event icons to be displayed, each being a selectable icon associated with a specific type of event. For example, upon selecting the icon, a plurality of icons listing various types of road events such as potholes, construction, object in the road, etc., may be presented. Thus, the type of event may be cataloged based on user selection at the display 138.

[0037] The personalized notification system 200 may include the global position system module 146 (also referred to herein as GPS module 146 and location module and as shown in Figure 1) which may be configured to determine a location of the vehicle 102. The GPS module 146 may transmit the vehicle location to the controller 204 and/or computing platform 104. The GPS module 146 may be used to catalog the vehicle location within the database 206. The controller 204 may use the vehicle location supplied by the GPS module 146 to determine whether the current route is one that has been previously traveled before.

[0038] The personalized notification system 200 may also include an accelerometer 210 configured to detect and transmit a vehicle speed to the controller 204. The vehicle speed may be used by the controller 204 to determine a distance traveled by the vehicle 102. This distance may also be used to catalog an event.

[0039] The personalized notification system 200 may include a timer 212 or an internal clock configured to provide a time stamp for various vehicle events. In one example, the vehicle event may include the route event, e.g., the recognition of a pothole or other similar event. In another example, the vehicle event may include a vehicle start, or vehicle shut down, etc. The timer 212 may be a separate timer or it may be included in another vehicle system such as other vehicle ECUs 148, etc.

[0040] The timer 212 may, in combination with the speed of the vehicle, be used by the controller 204 to determine a distance. For example, the timer 212 may transmit a start time to the controller 204. The accelerometer may transmit one or more speeds to the controller 204. Based on the amount of time the vehicle has been traveling (e.g., the difference between the start time and a current time) and an average speed of the vehicle during that time, the controller 204 may determine the distance traveled. The same process may be used to determine both the event distance and the current traveling distance. Additionally or alternatively, a dynamic speed calculation may be used to determine the distance traveled. In this example, multiple average speeds may be used to calculate multiple distances. For example, if the vehicle starts off by traveling at a slower speed for a certain amount of time, a first distance may be determined. After a while, the vehicle may enter a highway and travel at a higher speed. The duration and second distance at the higher average speed may be determined. The distance traveled may be determined by adding the first distance to the second distance.

[0041] Figure 3 illustrates an example diagram for a portion of the personalized notification system 200 illustrating a driver 302 in communication with various vehicle modules 304. The vehicle modules may include various vehicle ECUs 148, as discussed above with respect to Figure 1. In one example, the vehicle modules 304 may include a brake control module 308, an instrument panel module 310, a steering wheel module 312, an HMI such as the display 138, among others. The vehicle modules 304 may communicate with the controller 204 using SYNC, as described above with respect to Figure 1. The timer 212 may also be in communication with the controller 204. [0042] Figure 4 illustrates an example process 400 for cataloging road events. The process

400 may begin at block 405 where the controller 204 may receive route data including time and speed. As explained above, the controller 204 may receive the speed from the accelerometer 210 and the time from the timer 212. The time may include a start and the current time, both supplied by the timer. The controller 204 may use the start and current time to determine the time the vehicle has been on the route.

[0043] At block 410, the controller 204 may determine whether a road event has been recognized by the vehicle 102 based on the event data such as whether the vehicle 102 has recognized a pothole.

[0044] During the initial route recording as the system records distance traveled based on elapsed time and speed, road event data is manually/verbally/ (HMI) in the system. If a road event is recognized, the process 400 proceeds to block 415. If not, the process 400 returns to block 410.

[0045] At block 415, the controller 204 may determine the event distance based on the route data. That is, how far has the vehicle traveled during this route (e.g., since vehicle start). The event distance may be determined by taking the product of the route time and average speed. The process 400 may then proceed to block 420.

[0046] At block 420, the controller 204 may instruct the user interface 202 to prompt the user for input relating to the road event. In one example, the speakers 130 may emit an audible phrase asking the user whether a road event has been recognized. For example, the microphone 1 16 may emit "Have you hit a pothole?" or "Is there a road hazard?" The display 138 may also present a prompt such as by updating the display 138 to present various selectable preset options indicative of various event types such as a pothole, road hazard, etc. In addition, the user may, via the display 138, type a custom description of the road event, such as "tree in road," or other specific hazards.

[0047] At block 425, the controller 204 may receive the user input indicating the type of event. The type of event may be received from the microphone 116 where the user may, in response to the prompt, describe the road event. In one example, the user may say "hit a pothole" or "pothole." The microphone 116 may transmit the audio input to the controller 204. Additionally or alternatively, the user input may be received regardless of whether a prompt is issued. For example, upon recognizing the pothole, the user may say "pothole!" The microphone 116 may recognize this command via various voice command features, and transmit the audio input to the database 206.

[0048] At block 430, the controller 204 may catalog the road event, associated event distance, and user input into database 206. The user input may be the recorded audio input received at the microphone 116. For example, an audio file may be saved and associated with the road event. The user input may also be data indicative of the event type as selected at the display 138.

[0049] The process 400 may then end.

[0050] Figure 5 illustrates an example process 500 for issuing alerts for repetitive road conditions. The process 500 may begin at block 505 where the controller 204 may receive route data including time and speed. As explained above, the controller 204 may receive the speed from the accelerometer 210 and the time from the timer 212. The time may include a start and the current time, both supplied by the timer. The controller 204 may use the start and current time to determine the time the vehicle has been on the route.

[0051] At block 510, the controller 204 may determine the current traveling distance by taking the route time and the route data by taking the product of the route time and average speed.

[0052] At block 515, the controller 204 may compare the current traveling distance with the event distances stored within the database 206.

[0053] At block 520, the controller 204 may determine whether the current traveling distance is within a predefined distance threshold of one of the stored event distances. The predefined distance threshold may be approximately one mile. If so, the process 500 proceeds to block 525. If not, the process 500 returns to block 510.

[0054] At block 525, the controller 204 may determine whether a time to reach the road event is within a predefined time threshold. The time to reach the road event may be the time in minutes and seconds that, based on the current vehicle speed, the vehicle will reach the road event. In one example, the time threshold may be one minute. If the time to reach the road event is within the predefined time threshold, the process 500 proceeds to block 530. If not, the process 500 remains at block 525 until the vehicle is within a reasonable distance (e.g., 1 minute away from) the road event.

[0055] At block 530, the controller 204 may issue the alert associated with the specific upcoming road event. The alert may be defined in the database and may be associated with the specific upcoming road event. In one example, the alert may include an audible alert emitted from the speakers. The alert may include a portion of a previously recorded message from the driver, such as explained above. In this example, the audible alert may include a previously recorded message that states "pothole." This audio file may be cataloged within the database to be recalled when the vehicle 102 is to pass the associated road event. In other examples, the alert may include a visual alert on the display 138. Once vehicle passes the road event, the controller 204 may prompt the driver asking if the road event still exists and provide directions how to registered road event.

[0056] The process 500 may then end.

[0057] In addition to emitting an audible alert, a follow up prompt may also be included as part of the process 500. For example, after passing the road event, the controller 204 may instruct the speakers 130 to emit a follow up request, such as "Is the pothole still present?" The user may audibly answer this follow up prompt with either a "yes" or a "no." An answer in the negative may cause the controller 204 to remove the road event from the database 206. Furthermore, an existing road event may be modified. After passing the road event, the user may audible answer with an update such as "road now closed." The corresponding road event may then be updated. This increases efficiency, user satisfaction and accuracy of the personalized notification system 200.

[0058] Furthermore, road events may be shared among user and vehicles. This may be done via the communications network 156, the remote server 162, as well as via the mobile device 152, BLUETOOTH, etc. Various road events may be cataloged and stored for future recall. In some situations, for example, snow may cover a pothole; the alert may be helpful in recalling a previous road event when that event is not necessarily visible. Other examples may be during the dark, or times of poor visibility.

[0059] The above system may also be implemented to set reminders for various routes. For example, alerting the driver to make a stop at a certain location based on a distance traveled. In this example, the road event may be a routine errand such as stopping at a bank or a post office at a certain point in a trip. The system may also be implemented to set reminders for delivery trucks in an effort to alert the drivers as to specific events at various locations or houses such as dogs, fences, etc.

[0060] Accordingly, disclosed herein is a personalized notification system that uses existing on-board electronic systems and HMIs to provide alerts to the driver regarding various road events. The system accepts and catalogs driver inputs regarding road events and associates these road events with an event distance. Since most drivers travel the same route at the same time of day for their daily commutes, the navigation system may use a traveled distance to determine whether a road condition has been previously logged at a similar distance. The distance traveled may be based on an average speed and amount of travel time (e.g., distance multiplied by time), without the use of GPS infrastructure. During operation, a timer may recognize a leaving time (e.g., vehicle start-up) and an accelerometer may recognize a speed. A controller within the system may continually calculate the traveling distance. The traveling distance, or current distance, may then be compared with the stored event distances in the database. If the traveling distance is within a distance threshold of an event distance, the controller may transmit instructions for an alert to be issued as to the road event associated with that event distance.

[0061] Thus, a personalized notification system is designed using existing components to infer upcoming hazards on a route and alert the driver to these hazards. Additionally, costs of vehicle maintenance may be reduced due to the possible avoidance of road hazards.

[0062] Computing devices, such as the computing platform, processors, controllers, etc., generally include computer-executable instructions, where the instructions may be executable by one or more computing devices such as those listed above. Computer-executable instructions may be compiled or interpreted from computer programs created using a variety of programming languages and/or technologies, including, without limitation, and either alone or in combination, Java™, C, C++, Visual Basic, Java Script, Perl, etc. In general, a processor (e.g., a microprocessor) receives instructions, e.g., from a memory, a computer-readable medium, etc., and executes these instructions, thereby performing one or more processes, including one or more of the processes described herein. Such instructions and other data may be stored and transmitted using a variety of computer-readable media. [0063] Databases, data repositories or other data stores described herein may include various kinds of mechanisms for storing, accessing, and retrieving various kinds of data, including a hierarchical database, a set of files in a file system, an application database in a proprietary format, a relational database management system (RDBMS), etc. Each such data store is generally included with in a computing device employing a computer operating system such as one of those mentioned above, and are accessed via a network and any one or more of a variety of manners. A file system may be accessible for a computer operating system, and make the files stored in various formats. An RDBMS generally employs the Structure Query Language (SQL) in addition to language for creating, storing, editing, and executing stored procedures, such as PL/SQL language mentioned above.

[0064] In some examples, system elements may be implemented as computer-readable instructions (e.g., software) on one or more computing devices (e.g., servers, personal computers, etc.) stored on computer readable media associated there with (e.g., disks, memories, etc.). A computer program product may comprise such instructions stored in computer readable media for carrying out the functions described herein.

[0065] 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.