Method and apparatus for improving vehicle maintenance planning

Abstract

The present disclosure relates to methods and apparatus for improving vehicle maintenance scheduling. A system includes a processor configured to wirelessly receive vehicle usage data. The processor is further configured to aggregate the received data over time. The processor is further configured to categorize vehicle usage into predetermined categories based on the aggregated received data. The processor is further configured to access a set of maintenance recommendations associated with the predetermined categories and transmit a maintenance recommendation based on a correspondence between a value associated with one of the maintenance recommendations and the aggregated data.

Description

Technical Field

[0001] The illustrative embodiments generally relate to methods and apparatus for improving vehicle maintenance scheduling. Background Art

[0002] Customers are often reluctant to spend an afternoon getting their vehicles serviced. Between the time spent, the potential for identifying further issues, and the often-expected push for products and services they don't actually need, public opinion of going to a dealership for maintenance is quite low. Furthermore, many people simply don't understand that their vehicles benefit from regular maintenance and often don't understand that dealer referrals are made to avoid incurring more expenses in the future.

[0003] A typical visit to a dealership for service involves a customer making an appointment and then spending 5 to 15 minutes with a check-in agent when they arrive for service. The check-in process is often cumbersome, requiring the employee to navigate multiple screens of an outdated computer system, ultimately resulting in a seemingly generic set of service recommendations.

[0004] Furthermore, while maintenance recommendations are typically tailored to a vehicle or a class of vehicles as a whole, a one-year service appointment can be tailored in a completely different way on a per-vehicle basis if the dealership takes into account actual usage and the driving conditions in which that usage occurs. Because dealerships typically don't have access to this information, they're left with the unpleasant scenario of either spending 10 minutes questioning a customer who isn't willing to spend significant time at the dealership, or providing the customer with a generic and standard set of recommendations to consider. Summary of the Invention

[0005] In a first illustrative embodiment, a system includes a processor configured to wirelessly receive vehicle usage data. The processor is further configured to aggregate the received data over time. The processor is further configured to categorize vehicle usage into predetermined categories based on the aggregated received data. The processor is further configured to access a set of maintenance recommendations associated with the predetermined categories and transmit a maintenance recommendation based on a correspondence between a value associated with one of the maintenance recommendations and the aggregated data.

[0006] According to an example of the present invention, the correspondence includes a time value being higher than a maintenance recommendation threshold associated with one of the maintenance recommendations.

[0007] According to one example of the present invention, different vehicle systems have different time values ​​stored in association with the different vehicle systems, the time values ​​representing a time since a last service.

[0008] In a second illustrative embodiment, a system includes a processor configured to wirelessly receive a set of maintenance recommendations from a manufacturer server. The processor is further configured to present a display of the received maintenance recommendations in a selectable manner, the display also including a representation of a vehicle usage classification. The processor is further configured to receive a selection of a maintenance recommendation from the display and transmit data indicating the selected maintenance recommendation to a preferred dealer.

[0009] According to an example of the present invention, the processor is further configured to include the representation of the vehicle usage classification as a graph showing mileage changes between a plurality of usage categories until maintenance, wherein a current usage category is visually indicated on the graph.

[0010] In a third illustrative embodiment, a system includes a processor configured to wirelessly receive a set of maintenance recommendations including a vehicle identifier from a manufacturer server. The processor is further configured to wirelessly receive a customer selection of a maintenance recommendation from a vehicle corresponding to the vehicle identifier and automatically order any parts required to service the selected maintenance recommendation.

[0011] According to an embodiment of the present invention, the processor is further configured to send at least one cross-sell or at least one up-sell offer to the vehicle in response to receiving the maintenance recommendation. BRIEF DESCRIPTION OF THE DRAWINGS

[0012] Figure 1 An illustrative vehicle computing system is shown;

[0013] Figure 2A shows a schematic example of data collection and classification for a vehicle;

[0014] Figure 2B A schematic example of additional data collection is shown;

[0015] Figure 2C shows a schematic example of dusty condition recording processing;

[0016] Figure 3A and 3B shows a schematic example of an interactive process for providing maintenance recommendations;

[0017] Figure 4 Illustrative examples of mobile device displays are shown. DETAILED DESCRIPTION

[0018] As required, specific embodiments are disclosed herein; however, it should be understood that the disclosed embodiments are merely illustrative and may be embodied in many alternative forms. The drawings are not necessarily drawn to scale; some features may be exaggerated or minimized to illustrate details of particular components. Therefore, the specific structural and functional details disclosed herein should not be interpreted as limiting, but merely as a representative basis for teaching one skilled in the art to variously employ the claimed subject matter.

[0019] Figure 1 An example block diagram of a vehicle-based computing system (VCS) 1 for a vehicle 31 is shown. An example of such a vehicle-based computing system 1 is the SYNC system manufactured by Ford Motor Company. A vehicle equipped with a vehicle-based computing system may include a visual front-end interface 4 located within the vehicle. If the interface is provided with, for example, a touch-sensitive screen, a user may also be able to interact with the interface. In another exemplary embodiment, interaction occurs through button presses or a voice dialogue system with automatic speech recognition and speech synthesis.

[0020] exist Figure 1 In the illustrated exemplary embodiment 1, a processor 3 controls at least a portion of the operation of a vehicle-based computing system. The processor, located within the vehicle, allows for onboard processing of commands and routines. Additionally, the processor is connected to both non-persistent memory 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. Generally speaking, persistent (non-temporary) memory can include all forms of memory that retain data when a computer or other device loses power. These include, but are not limited to, HDDs, CDs, DVDs, magnetic tapes, solid-state drives, portable USB drives, and any other suitable form of persistent memory.

[0021] The processor is also provided with a number of different inputs that allow the user to interact 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, a screen 4 (which may be a touchscreen display), and a Bluetooth input 15 are all provided. An input selector 51 is also provided to allow the user to switch between the various inputs. Inputs from both the microphone and the auxiliary connector are converted from analog to digital by a converter 27 before being transmitted to the processor. Although not shown, the numerous vehicle components and auxiliary components that communicate with the VCS may use a vehicle network (such as, but not limited to, a CAN bus) to transmit data to and from the VCS (or its components).

[0022] The outputs of the system may 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 via a digital-to-analog converter 9. Outputs may also be generated to a remote Bluetooth device (such as a personal navigation device (PND) 54) or a USB device (such as a vehicle navigation device 60) along the bidirectional data streams shown at 19 and 21, respectively.

[0023] In one exemplary embodiment, the system 1 communicates (17) with a user's mobile device 53 (e.g., a cell phone, smartphone, PDA, or any other device with wireless remote network connectivity) using a Bluetooth transceiver 15. The mobile device can then be used to communicate (59) with a network 61 outside the vehicle 31, for example, by communicating (55) with a cellular tower 57. In some embodiments, the cellular tower 57 can be a WiFi access point.

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

[0025] The nomadic device 53 may be instructed to pair with the Bluetooth transceiver 15 via a button 52 or similar input. Accordingly, the CPU is instructed that the onboard Bluetooth transceiver will pair with the Bluetooth transceiver in the nomadic device.

[0026] Data may be transferred between the CPU 3 and the network 61 using, for example, a data plan associated with the nomadic device 53, data over voice, or DTMF tones. Optionally, it may be desirable to include an onboard modem 63 having an antenna 18 to transfer data (16) between the CPU 3 and the network 61 over the voice band. The nomadic device 53 may then be used to communicate (59) with the network 61 outside the vehicle 31, for example, by communicating (55) with a cellular tower 57. In some embodiments, the modem 63 may establish communication 20 with the cellular tower 57 to communicate with the network 61. As a non-limiting example, the modem 63 may be a USB cellular modem, and the communication 20 may be a cellular communication.

[0027] In one exemplary embodiment, the processor is provided with an operating system including an API for communicating with modem application software. The modem application software can access an embedded module or firmware on the Bluetooth transceiver to complete wireless communication with a remote Bluetooth transceiver (such as found in a mobile device). Bluetooth is a subset of the IEEE 802 PAN (Personal Area Network) protocol. The IEEE 802 LAN (Local Area Network) protocol includes WiFi and has considerable cross-functionality with IEEE 802 PAN. Both are suitable for wireless communication within the vehicle. Another communication method that can be used in this field is free space optical communication (such as IrDA) and non-standardized consumer infrared (IR) protocols.

[0028] In another embodiment, the 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 (FDM) can be implemented, allowing the owner of the nomadic device to speak over the device while data is being transferred. At other times, when the owner is not using the device, data transfer can utilize the entire bandwidth (300 Hz to 3.4 kHz in one example). While FDM was common for analog cellular communications between the vehicle and the internet and is still used, it has largely been replaced by a mix of code domain multiple access (CDMA), time domain multiple access (TDMA), and spatial domain multiple access (SDMA) for digital cellular communications. If the user has a data plan associated with the nomadic device, the data plan may allow for broadband transmission, and the system can utilize a much wider bandwidth (speeding up data transfer). In another embodiment, the nomadic device 53 is replaced by a cellular communication device (not shown) installed in the vehicle 31. In another embodiment, the nomadic device (ND) 53 may be a wireless local area network (LAN) device capable of communicating over, for example (but not limited to), an 802.11g network (i.e., WiFi) or a WiMax network.

[0029] In one embodiment, incoming data may pass through the nomadic device via a data-over-voice or data plan, through the onboard Bluetooth transceiver, and into the vehicle's internal processor 3. For example, in the case of certain temporary data, the data may be stored on a HDD or other storage medium 7 until the data is no longer needed.

[0030] Other sources that may interact with the vehicle include a personal navigation device 54 having, for example, a USB connection 56 and / or antenna 58, a vehicle navigation device 60 having a USB 62 or other connection, an onboard GPS device 24, or a remote navigation system (not shown) having connectivity to a network 61. USB is one of a class of serial networking protocols. IEEE 1394 (FireWire TM (Apple), i.LINK TM (Sony) and Lynx TM (Texas Instruments), EIA (Electronic Industries Association) serial protocol, IEEE 1284 (Centronics port), S / PDIF (Sony / Philips Digital Interconnect Format), and USB-IF (USB Implementers Forum) form the backbone of device-to-device serial standards. Most protocols can be implemented for electrical or optical communication.

[0031] Additionally, the CPU may communicate with various other auxiliary devices 65. These devices may be connected via wireless connections 67 or wired connections 69. Auxiliary devices 65 may include, but are not limited to, personal media players, wireless healthcare devices, portable computers, and the like.

[0032] Additionally or alternatively, the CPU may be connected to a vehicle based wireless router 73 using, for example, a WiFi (IEEE 803.11) transceiver 71. This may allow the CPU to connect to a remote network while within range of the local router 73.

[0033] In addition to the example processes being performed by a vehicle computing system located in the vehicle, in certain embodiments, the example processes may also be performed by a computing system in communication with the vehicle computing system. Such systems may include, but are not limited to, wireless devices (e.g., but not limited to, mobile phones) or remote computing systems (e.g., but not limited to, servers) connected via wireless devices. Such systems may be collectively referred to as vehicle-associated computing systems (VACS). In certain embodiments, specific components of the VACS may perform specific portions of the processes depending on the specific implementation of the system. By way of example and not limitation, if a process has a step that involves sending or receiving information with a paired wireless device, it is likely that the wireless device will not perform that portion of the process because the wireless device does not "send and receive" information with itself. One of ordinary skill in the art will understand when it is inappropriate to apply a particular computing system to a given solution.

[0034] Each of the illustrative embodiments discussed herein illustrates an exemplary, non-limiting example of a process that may be performed by a computing system. For each process, it is feasible for the computing system performing the process to be configured as a dedicated processor for the limited purpose of performing the process. Not all processes need be performed, and are understood to be examples of various types of processes that may be performed to implement elements of the present invention. Additional steps may be added to or removed from the exemplary processes as needed.

[0035] With respect to the illustrative embodiments described in the accompanying figures illustrating exemplary process flows, it should be noted that a general-purpose processor may be temporarily used as a special-purpose processor for the purpose of performing some or all of the exemplary methods illustrated by these figures. While executing code providing instructions for performing some or all of the steps of the described methods, the processor may be temporarily repurposed as a special-purpose processor until the method is completed. In another example, to the extent appropriate, firmware running on a pre-configured processor may cause the processor to function as a special-purpose processor provided for the purpose of performing the described methods or some reasonable variations of the described methods.

[0036] The illustrative embodiments provide methods and apparatus for assisting in providing more targeted maintenance recommendations for a particular vehicle. In many cases, it still makes sense to consider vehicles as part of a "group," but for maintenance recommendation purposes, it doesn't necessarily make sense to consider all 2018 Ford Explorers as a single vehicle group, for example.

[0037] There is a sweet spot between highly customized maintenance recommendations and more generic ones. Recommendations can be highly customized to specific components of a specific vehicle, but they can also be customized based on observations of a selected group of vehicles driven under similar conditions.

[0038] For example, instead of saying, "All 2018 Ford Explorers should have their air filters replaced after one year," it's reasonable to say, "All 2018 Ford Explorers that experience moderate or higher use in normal climates, or all 2018 Ford Explorers that experience light or higher use in dusty climates, should have their air filters replaced after one year." While this example is illustrative, if "moderate" use is defined as "driven five or more days per week" or "driven 9,000 miles or more," and if "light" use is defined as "driven three or more days per week" or "driven 6,000 miles or more," dealers can offer recommendations that are not universally applicable to all 2018 Ford Explorers, regardless of use or location. Furthermore, dealers can even provide a rationale for the recommendation: "Although your vehicle appears to be lightly used, because you primarily drive in dusty climates, we recommend replacing the air filter." This demonstrates the personalized aspect of the recommendation, even if the recommendation is otherwise largely universal for all lightly used vehicles driven in dusty climates.

[0039] By modeling vehicles based on measured usage characteristics and features that are likely to trigger maintenance needs, a customized model can be created for selectively grouping vehicles, providing a degree of customization for vehicle owners without requiring an on-site mechanic to disassemble a portion of the engine to determine the actual vehicle-specific needs. Using inferences (e.g., 90% of vehicles have N usage in M ​​conditions), dealers can reasonably assume and recommend specific maintenance, and customers can actually benefit from this guided maintenance.

[0040] And, while not a preferred outcome, customers who ignore maintenance recommendations are statistically more likely to experience actual problems that could have been prevented by the maintenance. Actually experiencing some problems will help build trust that the dealer is actually recommending meaningful service, but it's certainly better for the customer if they simply accept the recommendation in the first place. By providing a reason for the recommendation that appears customized to the vehicle, dealers may hope to encourage customers not to simply ignore the recommendation and think, "That doesn't really apply to me."

[0041] The illustrative embodiments provide an example of an Intelligent Maintenance Tool (IMT) that connects a maintenance planning service of a customer interface with an original equipment manufacturer's (OEM) scheduled maintenance tool (SMT) and a dealer's interface.

[0042] Dealers currently use SMT to make service recommendations based on manual input from service representatives when customers arrive at the dealership for a service appointment. These manual inputs include the vehicle's VIN, past service history, current odometer, and a driver profile selected based on the service representative's limited knowledge of vehicle usage and the customer's driving habits. This can be an inconvenient and time-consuming process for both the customer and the service representative.

[0043] While SMT can be a recommendation tool used by dealers when planning maintenance service appointments, it can result in a very low percentage of repair orders being placed by dealers. The illustrative vehicle usage application leverages vehicle data sets available (via IMT) to optimize the SMT functionality for both the customer experience and the dealer experience, increasing revenue for both dealers and OEMs.

[0044] In one example, a vehicle usage application leverages unsupervised clustering algorithms, supervised classification machine learning algorithms, and a large dataset of connected vehicles to improve the quality, speed, and transparency of dealer service recommendations via SMT.

[0045] In this example, vehicle usage classification uses 8 parameters, including: 1) average engine speed; 2) engine speed standard deviation; 3) average vehicle speed; 4) vehicle speed standard deviation; 5) average accelerator pedal position; 6) accelerator pedal position standard deviation; 7) average oil life change rate; 8) standard deviation of the oil life change rate.

[0046] For example, since a modem-equipped vehicle only reports approximately every 5 minutes, while an oil life monitor may be running continuously on the vehicle, the oil life from the smart oil life monitor in the vehicle can be used as an indicator to capture higher frequency events that are not reported at the normal modem-equipped vehicle transmission rate.

[0047] Examination of the oil life data can demonstrate how more aggressive driving results in increased oil life usage per mile driven, meaning that, based on this observation, an aggressive driver who drives 3,000 miles may need an oil change more urgently than a cautious driver who drives the same number of miles.

[0048]

[0049] The preceding table illustrates some illustrative vehicle system measurements that have been associated with different usage categories (light, medium, and heavy). Additional data can also be measured, such as, but not limited to, time spent off-road and dust levels experienced. This data can be used to tailor specific recommendations, but may not be meaningful for others. By utilizing a defined, measurable dataset of vehicles, drivers can be categorized into defined subcategories, and dealers can provide detailed recommendations for a given category without having to spend extensive time inspecting a specific vehicle to determine its precise maintenance needs. In many cases, customers are reluctant to wait hours for a dealer to inspect every component of a vehicle that may need repair or replacement, and vehicle categories that statistically represent expected customer demand can be appropriate for all parties involved.

[0050] Figure 2A A schematic example of data collection and classification for a vehicle is shown. A remote system or onboard vehicle computer may collect engine speed data (201), collect vehicle speed data (203), and collect pedal position data (205). This data may be compared to a model (as shown in the example table above) to generally classify the vehicle. The vehicle may collect data while driving and report the data periodically (e.g., where data is needed for modeling) or collect data when maintenance is requested (for remote comparison with existing modeling data). The remote system (such as an IMT) may classify the vehicle (207) and report the classification to the SMT at the dealership.

[0051] Figure 2BAn illustrative example of additional data collection for off-road conditions is shown. In this example, GPS data is recorded and correlated with known road coordinates to determine off-road conditions. While the vehicle can collect data continuously or at very short intervals, the vehicle can also use state transitions to switch back and forth between on-road and off-road conditions, recording only mileage or driving time during the transition.

[0052] In this example, the process obtains GPS data (211) and compares the GPS data to map data (213) to determine whether the current coordinates still correspond to a known road. If the known road is determined to be " <blank>(<blank>)”(215), said <blank>” indicates that there are no known roads, the process may record any time in that condition as “off-road” driving (217) and track the total “off-road” driving time (219). If the vehicle returns to a road, or if the vehicle never leaves a known road, the process may record the driving time as “normal” driving time (219). Whenever calculations are needed, the process may calculate the off-road time as a percentage of the total driving time (normal + off-road) that was off-road (221). This is just one example of how off-road driving or any other abnormal driving state / condition may be calculated.

[0053] Figure 2C 1 shows an illustrative example of a dusty condition recording process. In one example, if an area identified as chronically dusty is defined by known coordinates, data can be collected (see Figure 2B In this case, the processing simply replaces the state transition from road to off-road with the state transition from dust-free to dusty, and the data can be recorded and tracked in the same manner.

[0054] However, many dusty areas are not dusty for long periods of time. Unless the driver lives in or drives in a desert regularly, there is a high probability that the driver will only encounter dusty conditions on a limited basis. The process identifies the time when the drive begins (231) and records the coordinates of the route of travel (233). The process can then correlate these coordinates with known weather or environmental conditions (which may include, for example, dustiness) (235). This allows the process to determine the percentage of time or distance the vehicle was operated in dusty conditions (which may indicate a particular type of accelerated wear) (237). Modifications can also be made for other weather conditions that affect the results (e.g., the same model can be used to track driving in heavy rain, snow, etc.).

[0055] Figure 3A and 3B An illustrative example of an interactive process for providing maintenance recommendations is shown. In this example, a vehicle 301 collects and sends usage data (311) (e.g., as described above in Figures 2A to 2C ), sends the vehicle identification (such as VIN or other identifier) ​​(313) and sends mileage or other relevant data (315). Mileage can be used as both a reference point (as a basis for how much new data has been provided since the last report) and as a parameter for maintenance recommendations.

[0056] The schematic SMT 303 receives various transmitted vehicle data (321) and aggregates this data with previously received vehicle data (323) as necessary. Different vehicle serviceable systems may have different data sets associated with them, and these data sets may be reset or modified based on when maintenance actually occurs. For example, brakes may be replaced at 25,000 miles and tires may be replaced at 20,000 miles (typically). At the 20,000 mile interval, when the tires are replaced, new tires are added and thus the data regarding recommended tire maintenance may be reset, but the data for the brakes (which have not yet been replaced) will still have data from 0 miles associated with the brakes.

[0057] The process can utilize aggregated vehicle data (e.g., since the last maintenance appointment or over the life of the vehicle) to categorize vehicles into broad usage categories (325). Rather than modeling a very detailed profile for each vehicle, the process considers categorizing vehicles into broad categories that may have specific, highly recommended maintenance procedures associated with the vehicle. For example, a heavily used vehicle that frequently experiences dusty driving may receive an air filter replacement recommendation every 1,500 miles. This does not mean that any particular vehicle necessarily requires a filter replacement, but rather that the recommendation has been observed to be useful for a threshold percentage of vehicles categorized into such a category.

[0058] After the vehicle is classified, the process checks the maintenance recommendations for that category (327) and determines whether the current vehicle parameters meet any recommended maintenance (329). In the example using the air filter described above, for example, the process may determine that a heavily used vehicle that frequently experiences dust requires a new filter every 1500 miles, and then determine that the current vehicle has only traveled 750 miles since the last filter change (for example). This would lead to the conclusion that filter maintenance is not currently recommended for the vehicle. If the vehicle has traveled 1600 miles since the last filter change, the process would issue a recommendation.

[0059] It is worth noting that vehicle usage can change over time, leading to reclassification of the vehicle. Continuous data feeds and the ability to reset classifications at the time of maintenance allow for dynamic reclassification of vehicles. Even individual vehicle systems (e.g., tires, brakes, etc.) can be classified so that systems that have not been replaced are associated with a lifetime category (0 miles to current mileage), while replaced systems are associated with the category observed since replacement. This allows the system to adapt to changing usage patterns without neglecting older systems that may still be affected by previous usage.

[0060] In this example, when the SMT process determines that a maintenance recommendation exists, the process branches to push data to the user device 307 (eg, smartphone) ( 331 ) and to the dealer system 305 ( 333 ).

[0061] The user device processes the received maintenance recommendation (341) and may display the recommendation (343) for the user's consideration (e.g. Figure 4 If the user selects any recommended maintenance (345), the process can then offer the user a time to schedule the maintenance (347). This option can exist in the background of the smart device until the appointment is scheduled or the maintenance is performed (or the user clears the selection). For example, the process can also use the recommendation to issue a periodic warning via an app notification on the device, and the severity, timing, and date of the warning can depend on the criticality of the recommendation.

[0062] On the dealer side, the process also receives the recommendation (351) and waits until the customer schedules an appointment (353) to resolve at least one of the issues. Once the appointment has been scheduled, the process pulls the current warranty data (355) and populates the user profile (357). This data can also be used to send other options or recommendations back to the user device. This interaction can serve as a proxy for what would normally happen when the user arrives and can allow the dealer to confirm the maintenance selection and determine if accessories are needed before the user arrives (359), which can speed up the entire maintenance process. The dealer also has the opportunity to upsell or cross-sell at this time (for example, if you choose to purchase 2 new premium tires, we will include a free tire rotation; or if you purchase an oil change, you can upgrade the oil type to premium synthetic by buying premium synthetic now for 50% off). If the customer requires and / or confirms any accessories, the process can also order them (361).

[0063] Figure 4 1 shows an example of a mobile device display. In this example, device 401 has received service data recommended based on SMT analysis of vehicle usage. If a warning exists, a warning 403 appears at the top of the window. The display also includes the distance 405 until the service is recommended.

[0064] In this example, the process also shows a variable parameter column based on usage. The variable parameter column represents the distance until maintenance, which is recommended based on light usage 407, medium usage 409, and high usage 411. The shaded area covering the portion 409 and the portion 411 indicates that this is a recommendation based on a medium-used vehicle that shifts slightly towards high usage. Because feedback is provided over time, the movement of the shaded area allows customers to observe how driving frequency, conditions, and behavior affect the category of vehicle recommendations, and allows drivers to change their behavior or usage depending on whether maintenance costs are an issue. For example, college students may change their behavior to avoid maintenance expenses, while on-demand taxi drivers (such as multiple app-driven services allow) can factor observed changes in maintenance recommendations / costs based on excessive usage into their cost-benefit analysis.

[0065] The display also includes a list 415 of all recommended services currently needed or recommended. Arrows 417 can be used to expand categories to view options, further recommendations, the basis for the recommendation, etc. Check boxes 413 or other functions allow specific options to be selected. The cost of the selected option 419 and the total cost of all options 421 are also displayed.

[0066] Once the user submits the selected options, the data may be transmitted to the dealer / service center and the dealer may use the data to pre-order any necessary accessories or make any cross-sell / upsell offers.

[0067] Although exemplary embodiments have been 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 should be understood that various changes may be made without departing from the spirit and scope of the invention. In addition, the features of the various implementing embodiments may be combined in a logical manner to produce context-appropriate variations of the embodiments described herein.< / blank> < / blank>

Claims

1. A system for vehicle maintenance recommendation, comprising: The processor is configured to: Wirelessly receive vehicle usage data; Aggregate received data over time; categorizing vehicle usage into predetermined categories based on the aggregated received data, wherein the predetermined categories include light usage, moderate usage, and heavy usage based on vehicle travel distance or vehicle travel time; accessing a set of maintenance recommendations associated with a predetermined category; sending a maintenance recommendation based on a correspondence between a value associated with one of the maintenance recommendations and said aggregated received data, The vehicle usage data includes additional data including time spent off-road and dust levels experienced and is used to adjust maintenance recommendations.

2. The system of claim 1, wherein: The vehicle usage data includes average engine speed.

3. The system of claim 2, wherein: The vehicle usage data includes a standard deviation of engine speed.

4. The system of claim 1, wherein: The vehicle usage data includes average vehicle speed.

5. The system of claim 4, wherein: The vehicle usage data includes a standard deviation of vehicle speed.

6. The system of claim 1, wherein: The vehicle usage data includes average pedal position.

7. The system of claim 6, wherein: The vehicle usage data includes a standard deviation of pedal position.

8. The system of claim 1, wherein: The vehicle usage data includes an average oil life change rate.

9. The system of claim 1, wherein: The vehicle usage data includes the standard deviation of the oil life change rate.

10. The system of claim 1, wherein: Where the experienced dust level indicates dusty conditions, the vehicle usage data further includes a percentage of time or distance the vehicle was operated in dusty conditions, the percentage being indicative of a particular type of accelerated wear.

11. The system of claim 1, wherein: The processor is configured to send the maintenance recommendation to the customer's smartphone application.

12. The system of claim 1, wherein: The processor is configured to send the maintenance recommendation to a dealer service system.

13. The system of claim 1, wherein: The correspondence includes the vehicle mileage being greater than a maintenance recommendation threshold associated with one of the maintenance recommendations.

14. The system of claim 13, wherein: Different vehicle systems have different mileage values ​​saved in association with the different vehicle systems, the mileage values ​​representing the mileage since the last service.

15. The system of claim 1, wherein: The correspondence includes a usage time value being above a maintenance recommendation threshold associated with one of the maintenance recommendations.

Images