Managing vehicle diagnostics

Abstract

A method for managing vehicle service may capture at least one of user attention / inputs related to a requested service or observed vehicle operating parameters. A method for managing vehicle service may implement diagnostics and filtering based on user input to identify a set of corrective actions to be performed and pre-service steps that may be needed prior to a service, where the diagnostics and filtering correspond to a diagnostic service suite to be deployed and implemented. A method for managing vehicle service may transmit at least one processing result associated with executing the diagnostic service suite, and may obtain a user's approval of the service request and schedule the service.

Description

[0001] CROSS-REFERENCE TO RELATED APPLICATIONS

[0002] This application claims the benefit of U.S. Provisional Application No. 63 / 365,263, filed on May 24, 2022, entitled “MANAGING VEHICLEDIAGNOSTICS,” the entire contents of which are incorporated herein by reference. Background Art

[0003] In general, computing devices and communication networks can be used to exchange data and / or information. In common applications, a computing device can request content from another computing device via a communication network. For example, a computing device can collect various data and use a software application to exchange content with a server computing device via a network (e.g., the Internet). In such an embodiment, the original computing device can collect or generate information and provide the collected information to the server computing device for further processing or analysis.

[0004] Generally speaking, various vehicles, such as electric vehicles, internal combustion engine vehicles, hybrid vehicles, etc., may be configured with various sensors and components to facilitate operating the vehicle or managing one or more systems included in the vehicle. In certain scenarios, a vehicle owner or vehicle user may wish to schedule a service with a service technician before the service technician performs any form of preliminary diagnosis or inspection. For example, the functionality of scheduling a service appointment by the vehicle owner / vehicle user may be provided. Summary of the invention

[0005] The devices, systems, and methods disclosed herein have several features, no single one of which is solely responsible for their desirable attributes. Without limiting the scope as expressed by the claims that follow, their more salient features will now be briefly discussed. After considering this discussion, and particularly after reading the section entitled "Detailed Description of the Invention," one will understand how the features of one or more embodiments of the system and method provide several advantages over conventional systems and methods.

[0006] In some aspects, the technology described herein relates to a method for managing vehicle services, comprising: capturing or receiving at least one of user attention / input related to a requested service or an observed vehicle operating parameter; causing execution of a diagnostic service suite in response to at least one received user input; transmitting at least one processing result associated with executing the diagnostic service suite; and determining whether to provide a first service request or obtain user approval of the service request and schedule at least one service based at least in part on the at least one processing result.

[0007] Another aspect is a method for capturing at least one user input, wherein the at least one user input corresponds to at least one of a requested service or an observed vehicle operating parameter; causing execution of a diagnostic service suite at a vehicle in response to the captured at least one user input; transmitting at least one processing result associated with executing the diagnostic service suite at the vehicle; and obtaining user approval of the service request and scheduling at least one service based at least in part on the at least one processing result.

[0008] Another aspect is a method for managing vehicle maintenance. The method includes: receiving at least one user input related to a vehicle component; causing execution of a diagnostic service kit at the vehicle in response to the received at least one user input; transmitting at least one processing result associated with executing the diagnostic service kit; and determining whether to provide a first service request. BRIEF DESCRIPTION OF THE DRAWINGS

[0009] These and other features, aspects, and advantages of the present invention are described herein with reference to the accompanying drawings of preferred embodiments, which are intended to illustrate rather than to limit the present invention.

[0010] Figure 1 depicts a block diagram of an illustrative environment for providing configuration and management of a diagnostic service suite based on customer input in accordance with one or more aspects of the present disclosure;

[0011] Figure 2 An illustrative architecture for implementing vehicle diagnostic services in accordance with aspects of the present application is depicted;

[0012] Figure 3 is a diagram illustrating the provision and execution of a diagnostic service suite according to various aspects of the present application Figure 1 A block diagram of the environment;

[0013] Figure 4 is a flow chart describing a routine for providing vehicle diagnostic management services according to one or more embodiments disclosed herein;

[0014] Figure 5 is a flow chart describing a routine for providing vehicle diagnostic management services according to one or more embodiments disclosed herein; and

[0015] Figure 6 is a flow chart describing a routine for providing vehicle diagnostic management services according to one or more embodiments disclosed herein. DETAILED DESCRIPTION

[0016] In general, one or more aspects of the present disclosure relate to the configuration and management of diagnostic services associated with a vehicle. Illustratively, a diagnostic service may respond to a customer / client's input, such as when an operational problem is identified or when a scheduled service appointment for a vehicle is anticipated. By way of illustrative example, aspects of the present application correspond to selecting, deploying, and executing one or more diagnostic services or diagnostic applications to collect and transmit operational attributes or measured attributes of a vehicle. One or more diagnostic services or diagnostic applications may generally be referred to as a diagnostic service suite.

[0017] Typically, the traditional method of performing vehicle service is based on on-site vehicle inspection, vehicle diagnosis and vehicle repair by technicians. More specifically, the customer hands over the vehicle to a service center, which provides physical access to the vehicle to the technician, and the customer explains the vehicle. Then, based on the customer's explanation, the technician performs diagnosis and repairs the vehicle. These traditional methods may lead to inefficiencies in customers and vehicle service centers. On the one hand, the customer must visit the service center (or the technician must be near the vehicle). On the other hand, the technician performs vehicle diagnosis based on the customer's explanation. In this regard, the diagnostic result may be different depending on the technician's knowledge or experience level. On the other hand, the technician performs vehicle repair based on the diagnostic result. In this regard, since the diagnostic result may be different depending on the technician's knowledge, the vehicle repair result may be different. For example, the technician may need to diagnose and perform vehicle repair, but the diagnostic result may be incorrect because the technician may not understand the customer's explanation. In addition, the customer may have to rearrange the service appointment and perform the above-mentioned vehicle service process. On the other hand, the repair only requires software update to the vehicle, but the customer may have to perform the above-mentioned vehicle service process. Therefore, the traditional method of vehicle service is inefficient for both customers and vehicle service centers.

[0018] To address at least a portion of the inefficiencies identified above, one or more aspects of the present application relate to identifying, deploying, and executing a suite of diagnostic and corrective services in response to user input prior to vehicle maintenance. Illustratively, the deployment and execution of diagnostic services can be combined or integrated with the management of user input related to requested services or observed vehicle parameters. Illustratively, such integration can correspond to an automated workflow for resulting services provided by a vehicle service provider. More specifically, aspects of the present application incorporate automation that includes the following high-level steps implemented by management components within the vehicle.

[0019] According to an illustrative embodiment, the management component captures user attention / input related to requested services or observed vehicle operating parameters. Illustratively, a customer (or user) may utilize one or more interfaces to capture input associated with observed vehicle attributes, self-selected service requests (e.g., 10,000 mile service), and the like. The captured user attention / input may be facilitated by utilizing a mobile application (e.g., a mobile phone application) associated with an individual user, an interface included in a vehicle, a kiosk, a personal computing device, a tablet computing device, and the like.

[0020] Thereafter, the management component performs diagnosis and filtering on the user input to identify a set of corrective actions and pre-service steps that may be required to be performed before the service. The set of corrective actions and pre-service steps may be embodied as a diagnostic service suite executed by the vehicle or other computing devices associated with the vehicle, such as a mobile computing device. Illustratively, the diagnostic service suite is deployed for execution by at least one of the vehicle or associated computing devices. The diagnostic service suite may be based on user input and in response to the identified operating parameters. In addition, the diagnostic service suite may also be investigative in nature to measure different operating parameters or attempt to correlate observed parameters with other operating parameters of the vehicle. For the purposes of this application, reference to the diagnostic service suite is not intended to limit the functionality of individual services or applications, which may include collecting status information about the vehicle or environment, collecting status information about the user / operator, attempting to implement corrective or repair actions, attempting to identify faults or error conditions based on input provided to one or more components, and the like.

[0021] In addition, the diagnostic service suite can also process the processing results of other diagnostic services to determine whether the vehicle needs service. If it is determined that the vehicle needs service, the management component can provide the user with the option of approving the service. The diagnostic service suite can determine whether to provide services to the user / operator (or other relevant individuals) based on the results of the diagnostic service. In some embodiments, the determination of whether to provide services to the vehicle can be mainly based on the results of the diagnostic service for a specific vehicle (for example, whether the diagnostic service indicates that a specific vehicle needs service). The system can further determine the option of approving services based on supply chain information. Supply chain information can include parts availability or location-specific parts availability. The system can determine whether to provide services by comparing the severity of the condition with other users and combining parts availability. In other embodiments, the determination of whether to provide services to the vehicle can be based on a relative comparison of the diagnostic service results of multiple vehicles. In this embodiment, the service request can be based on the characteristics of the degree of maintenance demand relative to other vehicles, especially in scenarios where parts availability or service location availability is limited. For example, assume that the vehicle diagnostic processing results indicate that service is required, but the fault level is described as "low priority" or "low impact". Even though vehicle service may ultimately be required, service provision may be modified or configured to be postponed until the next execution of the diagnostic suite (e.g., delayed service) or until a future service process that exceeds a minimum threshold. Such service modification may be accomplished automatically (without any user input or notification) or in conjunction with user notification and input.

[0022] After the diagnosis and filtering process is completed, the management component obtains the user's approval of the service request and the arrangement of (multiple) services. For example, this may include accessing user profile information indicating a pre-approval or approval threshold. In other embodiments, this may include receiving affirmative user input, such as manipulation of a graphical interface, operation of vehicle control (e.g., manipulation of a pedal, presentation of a near field communication device, selection of a remote control / access input, etc.). In some embodiments, one or more aspects of the present application may include some form of feedback or processing results, which are provided to the user, indicating the execution results of the diagnostic service suite. For example, the feedback / processing results may be in the form of a result characterization (e.g., excellent, good, bad, etc.). In other examples, the feedback / processing results may be individual values ​​of the diagnostic service suite, the determined action groups, the potential causes of the fault, or the suggested severity levels of the potential faults. After the approval and feedback process, a network-based management component associated with a physical service provider that may perform vehicle services allocates and orders parts and coordinates payment and supporting documents. Illustratively, the output of the diagnostic service suite can be used to book parts, pre-arrange physical services to be performed, etc. In addition, the output of the diagnostic service suite can be used as an input to estimate the completion time of the scheduled service.

[0023] As an illustrative example, assume that a user / operator provides some input via a vehicle interface indicating operational observations of the vehicle's battery performance. In response, a diagnostic service suite is deployed on the vehicle to capture various states of the electrical system, including battery system state, charging system state, and operational usage data related to the battery system. Based on the results of the execution of the diagnostic service suite, the diagnostic service further determines that the required service is replacement of the vehicle's battery system. Based on this determination, the diagnostic service suite can further characterize the need for battery system replacement, including characterization of the extent of the fault, characterization of the likelihood of the fault, confidence factors in the diagnosis, and the like. Based on these processing results, the network-based management service can then provide the current status of the service demand for battery system replacement, as well as the inventory availability of the battery system and the service location availability to enable battery system replacement. The network-based management service can then provide input to the diagnostic service suite regarding scheduling the replacement of the battery system, and provide user input and approval.

[0024] According to some aspects of the present application, user attention and input that cause the selection and deployment of the diagnostic service suite can be captured by interacting with a vehicle interface, a mobile application, or other computing device (e.g., a kiosk, a tablet, etc.). This interaction can be based on predefined categories that the user can select via the interface. This interaction can also be based on narrative type input, such as via spoken language, typed comments, etc., which can be processed to extract key terms, etc. Illustratively, a network service provider can utilize a third-party service to facilitate the collection or processing of user input. In addition, in some aspects, user input can also include the collection of vehicle operating parameters, such as frozen screens, frequent system resets, or low voltages. User input can also include responses to suggestions or prompts, for example, a service management component can provide the user with the option of running battery diagnostics in response to a sensed low voltage. The system can provide suggestions based on several data points, and the suggestions can focus on certain systems, some example vehicle characteristics that can be sensed or determined based on vehicle history, or suggestions initiated by the network. The user can respond to instructions to complete the suggested action. In an alternative example, the service management component can provide the user with the option of running system or infotainment diagnostics in response to frequent system resets or frozen screens.

[0025] In some embodiments, the diagnostic service suite may be preloaded in a vehicle or software application (s) associated with a customer. In other embodiments, in response to an action group, a network service provider may transmit to the vehicle a diagnostic service suite that has been modified or updated based on processed input. In addition, in other embodiments, the vehicle may maintain a set of common or common diagnostic services that may be instantiated based on user input. Specifically, each iteration of the diagnostic service suite may be implemented based on an action group or user input, thereby customizing the diagnostic service (s) or execution order / sequence.

[0026] In some embodiments, the diagnostic service suite can be continuously updated by the network service and transmitted to the vehicle. This transmission can be completed in response to determining to deploy and execute one or more diagnostic services. Alternatively, the network service can provide periodic or asynchronous updates to the vehicle or vehicle application before determining to deploy and execute the diagnostic service.

[0027] In another aspect of the present application, the vehicle or vehicle application may also maintain some historical information related to the output or results of the diagnostic service suite. Historical information can be used to determine trends or provide comparison points about the operating state of the vehicle at the measurement time point. This historical information can be provided to the service provider, especially if the vehicle has not been repaired before. For example, a vehicle service repair of a particular system (e.g., a charging component) may include the results of one or more diagnostic services related to the operating properties of the charging component in the current state, but also include results from previous instances of the same or similar diagnostic services.

[0028] Figure 1 A block diagram of an illustrative environment for a system 100 for providing configuration and management of services associated with a vehicle based on customer input according to one or more aspects of the present disclosure is depicted. The system 100 may include a network 160 that connects a group of vehicles 110, a network service provider 120, and one or more customer devices 130. The components may correspond to software modules implemented or executed by one or more external computing devices, which may be separate independent external computing devices. Therefore, the components of the network service provider 120 should be viewed as logical representations of services without requiring any specific implementation on one or more external computing devices.

[0029] like Figure 1As depicted in , client device 130 may be any computing device, such as a desktop, laptop, personal computer, tablet computer, wearable computer, server, personal digital assistant (PDA), hybrid PDA / mobile phone, mobile phone, smart phone, set-top box, voice command device, digital media player, etc. Client device 130 may execute an application (e.g., a browser, standalone application, etc.) that allows a user to access an interactive user interface, view images, analyze, aggregate data, and / or the like as described herein. In some embodiments, client device 130 may be implemented in conjunction with vehicle 110 and may provide some functionality associated with vehicle 110. For example, vehicle 110 may utilize client device 130 and utilize resources of the vehicle, such as a processor and memory of the vehicle, to perform one or more functions.

[0030] like Figure 1 As depicted in , the network 160 can connect the vehicle 110, the customer device 130, and the network service provider 120. The network 160 can connect any number of devices. In some embodiments, the network service provider 120 provides network-based services to the customer device 130 via the network. The network service provider implements network-based services and refers to a large shared pool of network-accessible computing resources (such as computing, storage or networking resources, applications or services), which can be virtualized or bare metal. The network service provider can provide on-demand network access to a shared pool of configurable computing resources, which can be allocated in a programmatic manner and released in response to customer commands. These resources can be dynamically allocated and reconfigured to adapt to variable loads. Therefore, the concept of "cloud computing" or "network-based computing" can be viewed as applications delivered as services over the network and the hardware and software in the network service provider that provides these services.

[0031] The network 160 may include any combination of wired and / or wireless networks, such as one or more direct communication channels, a local area network, a wide area network, a personal area network, and / or the Internet. In some embodiments, communication between the vehicle 110 and the client device 130 may be performed via a short-range communication protocol, such as Bluetooth, Bluetooth Low Energy ("BLE"), and / or near field communication ("NFC"). Communication between the vehicle 110 and the network service provider 120 may occur via the network 160, such as via one or more secure networks, such as a local area network that communicates securely with the network service provider 120 via the Internet. However, the network 160 may include some or all of the same communication protocols, services, hardware, etc. Therefore, although the discussion herein may describe communication between the vehicle 110 and the client device 130 via the network 160 and communication between the vehicle 110 and the network service provider 120 via the network 160, communication between the devices is not limited to this approach. The various communication protocols discussed herein are merely examples, and the present application is not limited thereto.

[0032] In some embodiments, network 160 can utilize high-speed 4G LTE or other wireless communication technologies, such as 5G communications. Therefore, in some embodiments, network 160 may include one or more wireless networks, such as a global system for mobile communications (GSM) network, a code division multiple access (CDMA) network, a long-term evolution (LTE) network, or any other type of wireless network. Network 160 may use protocols and components for communicating via the Internet or any other type of network described above. For example, the protocols used by network 160 may include hypertext transfer protocol (HTTP), HTTP security (HTTPS), message queue telemetry transmission (MQTT), and restricted application protocol (CoAP), etc. The protocols and components for communicating via the Internet or any other type of communication network described above are well known to those skilled in the art, and therefore, are not described in detail herein.

[0033] As applied to various aspects of the present application, a group of vehicles 110 corresponds to one or more vehicles configured with a diagnostic service suite 112 that is executed by the vehicle 110 or other computing device associated with the vehicle, such as a mobile computing device 130. As described above, reference to the diagnostic service suite 112 is not intended to limit the functionality of the individual services or applications, which may include collecting status information about the vehicle or environment, collecting status information about the user / operator, attempting to implement corrective or repair actions, attempting to identify a fault or error condition based on input provided to one or more components, and the like.

[0034] Illustratively, the network service provider 120 may include a vehicle network-based management component 122 that may provide functionality responsive to processing customer input to provide configuration and management of services associated with the vehicle based on the processed customer input applied to various aspects of the present application. As described above, the network-based management component 122 may be associated with a physical service provider that may be performing vehicle services, allocating and facilitating input to an inventory or parts ordering system to cause parts orders and coordinate payment and support filing. In addition, the network-based management component 122 may also process processing results from multiple vehicles 110 to facilitate prioritization, filtering, or other relative comparison of the diagnostic processing described herein. The network-based service may include multiple data stores 124 for maintaining various information associated with various aspects of the present application. Figure 1 The network-based management component 122 in is logical in nature and can be implemented in the network service provider 120 in a variety of ways.

[0035] Reference now Figure 2 , an illustrative architecture for implementing a diagnostic service suite 112 on one or more local resources or network services in a vehicle 110 will be described. The diagnostic service suite 112 may be part of a component / system that provides functionality associated with a vehicle service provider or the like.

[0036] Figure 2 The architecture is illustrative in nature and should not be construed as requiring any particular hardware or software configuration of the vehicle 110 (or computing device 130 associated with the vehicle). Figure 2 The overall architecture of the vehicle 110 depicted in FIG. 1 includes an arrangement of computer hardware and software components that can be used to implement various aspects of the present disclosure. As illustrated, the vehicle 110 includes a processing unit 204, a network interface 206, a computer-readable medium drive 207, and an input / output device interface 208, all of which can communicate with each other via a communication bus. The components of the vehicle 110 can be physical hardware components, or can be implemented in a virtualized environment.

[0037] Network interface 206 may provide access to one or more networks or computing systems, such as Figure 1 The processing unit 204 may also communicate with the memory 250 and further provide output information to an optional display (not shown) via the input / output device interface 208. In some embodiments, the vehicle 110 may include a plurality of Figure 2 More (or fewer) components than those shown.

[0038] The memory 250 may include computer program instructions that the processing unit 204 executes to implement one or more embodiments. The memory 250 typically includes RAM, ROM, or other persistent or non-transitory memory. The memory 250 may store interface software 252 and an operating system 254 that provide computer program instructions for use by the processing unit 204 in the general management and operation of the network-based management component 122. The memory 250 may also include computer program instructions and other information for implementing various aspects of the present disclosure.

[0039] The memory 250 may include an input processing component 256 for processing customer input. In these embodiments, the input processing component 256 may correspond to one or more machine learning models for processing natural human language, such as narrative language input, to be used to identify one or more symptoms associated with the vehicle. In some embodiments, the machine learning model.

[0040] The memory 250 may also include an input processing component 258. In some embodiments, the customer may provide customer input by utilizing the customer device 130, and the input processing component 256 may filter the customer input to be used to predict one or more symptoms associated with the customer input. For example, the input processing component 258 extracts one or more key terms from the customer input, where the key terms may be used to predict the symptoms. In these embodiments, the customer input may be provided to the input processing component 258 in a textual form or in the context of a spoken expression.

[0041] In some embodiments, the customer may provide customer input in the form of natural language. In these embodiments, the customer input may be narrative. For example, the customer may type one or more sentences related to the vehicle, or talk about the vehicle in the context of natural human language. In some embodiments, the input processing component 256 processes these customer inputs to determine one or more customer inputs that can be used to predict vehicle symptoms. For example, the customer input may be "My car has a yellow border around the touch screen." In this example, the input processing component 256 may filter the customer input and determine "Touch screen failure." In another example, the customer input may be "My car is driving left on the highway." In this example, the input processing component 258 processes the customer input and determines the customer input as "The wheels are misaligned."

[0042] In some embodiments, the input processing component 256 can be configured to utilize a machine learning model to process the natural language provided as the customer input. For example, if the customer input is "My car smells bad", the machine learning model can process the customer input and determine the customer input as "Heating, Ventilation and Air Conditioning (HVAC) system failure".

[0043] In some embodiments, input processing component 256 receives customer input as a set of vehicle symptoms. In these embodiments, customer device 130 may provide a list of vehicle symptoms, and the customer may select one or more symptoms from the list of vehicle symptoms. For example, customer device 130 may have a list of predefined vehicle symptoms, such as "check engine light on", "vehicle vibrations", "safety features not functioning", "battery failure", etc. In this example, the customer may select one or more symptoms from the list of predefined vehicle symptoms.

[0044] The memory 250 may also include a vehicle symptom analysis component 258, which illustratively corresponds to the diagnostic service suite 112. As described above, reference to the diagnostic service suite 112 is not intended to limit the functionality of individual services or applications, which may include collecting status information about the vehicle or environment, collecting status information about the user / operator, attempting to implement corrective or repair actions, attempting to identify faults or error conditions based on input provided to one or more components, and the like. As described below, in some embodiments, user input may be associated with one or more action groups that facilitate logical grouping of natural language input into potential symptoms for vehicle maintenance. In turn, these diagnostic service suites 112 may be associated with action groups in some manner to collect necessary information, attempt corrective actions, and provide additional input based on processing user input mapped to action groups.

[0045] The memory 250 may also include a service feedback component 260 for providing feedback (or feedback representation) to the customer. As described above, the feedback may illustratively include a request for additional diagnostic services or user observations. In other aspects, the feedback may include approval or input related to service scheduling, parts ordering, financial commitments, etc.

[0046] Now go to Figure 3 , an exemplary interaction of the components of system 100 to provide vehicle services based on the processing results of customer input will be described. For ease of explanation, it can be assumed that network service provider 120 has been configured to implement network-based management component 122 on behalf of a group of customers. The present application is not intended to be limited to any particular type of service provider or the number of individual services that can be accessed or generate processing results as part of executing an application on behalf of a customer. In addition, the present application is not intended to be limited to the number of network service providers, such as Figure 1 As depicted in .

[0047] like Figure 3As shown in , at (1), a customer may provide customer input to the network-based management component 122 by transmitting the customer input via the customer device 130. The customer input corresponds to text, images, and / or natural language. In some aspects, the customer input may also include a set of vehicle operating parameters that may be applicable to or related to the customer input, such as sensor / instrument values, warnings or notifications, recommended action items, and the like.

[0048] Illustratively, the customer may provide customer input by utilizing an interface in the vehicle 110 (such as an integrated display screen or microphone) or via a customer device 130 associated with the vehicle 110. The vehicle or customer device 130 may execute an application (e.g., a browser, a standalone application, etc.) that allows the customer to enter the customer input and access an interactive user interface, view images, analytics, aggregated data, and / or the like as described herein.

[0049] In some embodiments, the customer input may be provided to the network-based management component 122 in the context of text or verbal expression. In some embodiments, the customer may provide the customer input in the form of natural language. In these embodiments, the customer input may be narrative. For example, the customer may type one or more sentences related to the vehicle, or talk about the vehicle in the context of natural human language.

[0050] By way of illustrative example, user input can be characterized as a possibility associated with one or more of a set of defined action groups. Each action group defines associated symptoms / causes and confidence values ​​for mapping symptoms / causes to captured user inputs. Then, each action group defines one or more corrective actions or response actions that can be implemented by a vehicle, a technician, other third parties, etc. Therefore, based on the mapping of inputs to action groups, a network service provider can define and execute actions (e.g., diagnostic actions, information collection actions, or corrective actions) that can be utilized to complete the requested service or resolve observed vehicle parameters. Although described herein for illustrative purposes, in some embodiments, action groups or aspects of action groups do not need to be used.

[0051] Illustratively, the network service provider can select the associated action group by first applying some form of threshold or filtering any action group that does not meet the minimum threshold of the confidence value. For example, the action group with a confidence value not greater than 60%, 65%, 70%, 75% or other specified values ​​can be excluded from consideration. The confidence value can be attributed to / assigned to the action group symptom based on manual input, machine learning implementation, etc., and can be updated based on historical information based on personal experience unique to the customer or vehicle, organizational experience unique to the defined individual or vehicle subset, or thresholds that are more generally applicable. Thereafter, the remaining potential applicable action groups can be ranked or sorted in a way to select the most likely applicable action group. The sorting or ranking can be strictly based on numerical principles or via a weighting scheme, such as weighting based on historical interactions with users, vehicles, vehicle groups, user groups, or combinations thereof. In some embodiments, if the confidence value of any action group does not meet a threshold (which can be a threshold that is the same or different from the filtering threshold), the network service provider can enable the system to collect additional user input or perform preliminary diagnosis before selecting the action group.

[0052] Each individual action group (once selected) then defines a set of actions, such as diagnostic actions, information actions, or corrective actions, that facilitate a service workflow based on user input that may be embodied in the diagnostic service suite 112. For example, the diagnostic service suite 112 may include executing an automated information collection tool / application that can collect vehicle data and identify patterns in the data. In another example, an action may include executing an automated diagnostic tool that may be executed by the vehicle. A technician may access output generated by the diagnostic service suite provided by the vehicle, such as a high-level transmission from the vehicle or a service application.

[0053] In some embodiments, there may be a single or multiple action groups mapped to the initial user input. As a result of mapping to one or more action groups, the service management component may determine additional action groups. Additional action groups may be determined based on the confidence values ​​of the first action group or other action groups. For example, if the network-based management component 122 determines that it is 50% confident that it is action group 1, 45% confident that it is action group 2, and 5% confident that it is action group 3, the service management component may perform all or part of the actions associated with group 1 and action group 2 (e.g., diagnostic actions, information collection actions, or corrective actions). The network-based management component 122 may implement the diagnosis associated with action group 1 and action group 2 to determine the root cause of the problem. When determining whether to perform the physical implementation of action group 1 and action group 2, the network-based management component 122 may also analyze the corrective actions associated with each group, for example, the parts and labor required for action group 1 and action group 2.

[0054] In some embodiments, the network-based management component 122 can map to additional action groups or actions based on the determined action group, or the diagnostic action, information collection action, or corrective action of the action group. The additional action group may be independent of the initial user input. The additional action group can be determined based on criteria associated with the action group, including diagnostics, vehicle history, vehicle age, and services required for the determined action group.

[0055] In some embodiments, some action groups can specify multiple actions, which can be in a logical order (e.g., information collection / diagnosis / repair). In other embodiments, action groups can be limited to specific types of actions, such as diagnostic services that rely on other diagnostic service results. Actions can also be constructed or sorted in the following manner so that the achievements / results of the previous action can have a dependency or influence on subsequent actions (e.g., the values ​​from the information collection can determine which diagnostic actions to select). Therefore, in some aspects of the present application, the selection of diagnostic service suites, the order of execution, and the parameters transmitted between the executed diagnostic services can be based on user input and the determined action groups.

[0056] Action groups can be illustratively mapped or clustered based on the organization of the vehicle so that the action groups can be matched to the main organizational groups of the vehicle (e.g., powertrain, HVAC, etc.). Other action groups can be mapped to individual components or services. The network service provider can also continuously monitor, adjust, or update other action groups based on the processing results. For example, action groups that are rarely selected can be modified or mixed. In another example, action groups that do not cause appropriate service experience or misdiagnosis can be eliminated, updated, or divided.

[0057] At (2), the network-based management component 122 causes the vehicle to perform diagnostics and filtering on the user input to identify a set of corrective actions and pre-service steps to be performed that may be required prior to service. The set of corrective actions and pre-service steps can be embodied as a diagnostic service suite 112 executed by the vehicle or other computing device associated with the vehicle, such as a mobile computing device. Illustratively, the diagnostic service suite is deployed for execution by at least one of the vehicle or associated computing device. The diagnostic service suite can be based on the user input and in response to the identified operating parameters. In addition, the diagnostic service suite can also be investigative in nature to measure different operating parameters or attempt to correlate observed parameters with other operating parameters of the vehicle.

[0058] At (3), the diagnostic service suite may also process the processing results of other diagnostic services to determine whether the vehicle requires service. If it is determined that the vehicle requires service, the management component may provide the user with an option to approve the service. The diagnostic service suite may determine whether to provide service to the user / operator (or other relevant individual) based on the results of the diagnostic service. In some embodiments, the determination of whether to provide service to the vehicle may be based primarily on the results of the diagnostic service for a specific vehicle (e.g., whether the diagnostic service indicates that a specific vehicle requires service). The system may further determine the option to approve the service based on supply chain information. The supply chain information may include parts availability or location-specific parts availability. The system may determine whether to provide service by comparing the severity of the condition with other users and combining parts availability. In other embodiments, the decision whether to provide service to the vehicle may be based on a relative comparison of the diagnostic service results of multiple vehicles. In this embodiment, the service request may be based on characteristics of the degree of service demand relative to other vehicles, particularly in scenarios where parts availability or service location availability is limited. For example, assume that the vehicle diagnostic processing results indicate that service is required, but the fault level is described as "low priority" or "low impact." Even though vehicle service may ultimately be required, service provision may be modified or configured to be postponed until the next execution of the diagnostic suite (e.g., deferring service) or until a future service process that exceeds a minimum threshold. Such service modification may be accomplished automatically (without any user input or notification) or in conjunction with user notification and input.

[0059] After the diagnosis and filtering process is completed, at (4), the network-based management component 122 obtains the user's approval of the service request and the arrangement of (multiple) services. For example, this may include accessing user profile information indicating a pre-approval or approval threshold. In other embodiments, this may include receiving affirmative user input, such as operation of a graphical interface, operation of vehicle controls (e.g., operation of a pedal, presentation of a near-field communication device, selection of a remote control / access input, etc.). In some embodiments, one or more aspects of the present application may include some form of feedback or processing results that are provided to the user to indicate the results of the execution of the diagnostic service suite. For example, the feedback / processing results may be in the form of a characterization of the results (e.g., excellent, good, poor, etc.). In other examples, the feedback / processing results may be individual values ​​of the diagnostic service suite, determined action groups, potential causes of faults, or recommended severity levels of potential faults.

[0060] After the approval and feedback process, at (5), the web-based management component 122 can interface with an inventory and ordering system that allocates and orders parts and coordinates payment and supporting documentation. Illustratively, the output of the diagnostic service suite can be utilized to pre-order parts, pre-arrange physical services to be performed, and the like. In addition, the output of the diagnostic service suite can be used as input to estimate the completion time of the scheduled service.

[0061] Figure 4 is a flow chart describing a routine 400 for providing vehicle diagnostic management services according to one or more embodiments disclosed herein. The routine 400 begins at block 402, where at least one user input is captured. The user input may be user initiated, e.g., a user reports a problem with the vehicle; the user input may be management component initiated, e.g., the management component makes a suggestion to the user, to which the user may respond; or some combination. The user input may be captured in an associated vehicle, on a mobile device, or by any relevant method. The user may issue a verbal command, a verbal phrase, enter touch mode, type a phrase, type a command, or any other relevant form of input. The input may be a report of a vehicle problem, such as "screen frozen," "car won't unlock," or alternatively, the management component may display a message saying "potential battery problem, run diagnostics?"

[0062] At block 404, in response to at least one captured user input, the vehicle deploys and executes a diagnostic service suite 112. The diagnostic service suite 112 may include identifying a set of corrective actions or pre-service steps to be performed. Corrective actions may also be determined by first identifying action groups. One or more action groups may be based on user input and may be determined prior to block 404. The determined action groups may determine the diagnostic service suite, which may include communications with a network or corrective actions. Analysis, processing, and / or determination associated with the execution of the diagnostic suite may occur at the vehicle, or it may occur at or in conjunction with a network service provider.

[0063] The diagnostic service suite 112 may be investigative in nature to measure different operating parameters or attempt to correlate observed parameters with other operating parameters of the vehicle. The diagnostic service suite may be action-oriented in nature, such as updating software, resetting a system, or adjusting operating parameters. The diagnostic service suite that identifies user input of a set of corrective actions to be performed may include determining an action group based on the user input. The diagnostic service suite that responds to the user input to identify a set of corrective actions to be performed may include obtaining at least one diagnostic service from a service provider. Diagnosing and filtering the user input that identifies a set of corrective actions to be performed (the diagnostic service suite) may include modifying at least one diagnostic service.

[0064] The diagnostic service suite may include communicating with a network service provider. The service management component may communicate with the network service provider to determine an action group. The network service provider may further perform actions including diagnostic actions, information collection actions, or corrective actions.

[0065] Block 406 includes transmitting the results of the diagnostic service kit. The results of the diagnostic service kit may be transmitted to the network-based management component 122. Additionally or alternatively, the results of the diagnostic service kit may be transmitted to a service shop or technician.

[0066] Block 408 includes obtaining approval of the requested service from the user. Approval may be obtained via a user device, such as a mobile phone, or via an interface in the vehicle. Block 408 may also include scheduling the service. The service may be scheduled based on parts availability, workshop availability, and the urgency of the service request.

[0067] Figure 5 is a flow chart describing a routine 500 for providing vehicle diagnostic management services according to one or more embodiments disclosed herein. Routine 500 begins at block 502 by capturing at least one user input. The capturing of user input 502 may be performed in conjunction with block 402 ( Figure 4 ) are similar or identical.

[0068] At block 504, the vehicle 110 deploys and executes a diagnostic service suite 112 in response to at least one captured user input. The diagnostic service suite 112 can be used to determine corrective actions. In some embodiments, the diagnostic service suite can be selected by first identifying an action group. One or more action groups can be based on mapping a natural language input provided by a user to potential symptoms. In other embodiments, the diagnostic service suite can be configured to be directly mapped to a user input (such as via a touch interface) or hierarchically structured to iterate various diagnoses. By including communication with a network 160 through the diagnostic service suite 112, action groups and / or corrective actions associated with action groups can be determined.

[0069] The results of the diagnostic service kit may be transmitted in block 506. It should be understood that blocks 504 and 506 may be in any order or may be combined. The transmitted results may be sent to a technician or a network, as described with respect to block 406. The results of the diagnostic service kit may include the severity of the problem and / or the severity of the corrective action.

[0070] Block 508 includes determining whether to provide a first service request. The determination of whether to provide a first service request can be based on the severity of the problem, the corrective action required, the parts required, the parts availability, the workshop availability, the results of the diagnostic service kit, and many other factors. The determination can be made by the network. The network can compare the severity or urgency of the problem with the severity or urgency of the problem associated with another user's vehicle to determine who to prioritize. This type of determination is most useful when there are a limited number of parts available. The system can further determine or modify the corrective action based on (multiple) other vehicles 110 in the network and the availability of parts. For example, the vehicle 110 may have a hardware problem that requires a new infotainment unit, but the number of infotainment units available is limited. Therefore, software-related corrective actions can be prescribed to the user until parts are available or the severity of the problem rises to the point where the user's vehicle needs to be prioritized.

[0071] The determination of whether to provide the first service request may also be based on the second problem. The second problem may be associated with a second action group and (multiple) second corrective actions. The network may determine not to provide the first service request until parts or time are available to complete the second service request, such that the first service request and the second service request may be completed simultaneously.

[0072] Figure 6 6 is a flow chart describing a routine 600 for providing vehicle diagnostic management services according to one or more embodiments disclosed herein. Routine 600 begins at block 602 by capturing at least one user input. The capture of user input may be performed in conjunction with blocks 402 and 502 ( Figure 4 and Figure 5 ) are similar or identical.

[0073] Block 604 includes causing execution of a diagnostic service suite at the vehicle in response to the captured at least one user input. As described above, the diagnostic service suite 112 can be used to determine vehicle status information, attempt one or more corrective actions, or otherwise provide additional diagnostic information. The analysis, processing, and / or determination associated with execution of the diagnostic service suite 112 can occur at the vehicle, or it can occur at or in conjunction with a network service provider.

[0074] Block 606 includes determining a set of additional actions based on the processing results of the initial diagnostic service suite 112 or additional user input. Block 606 may include additional diagnostic services in response to the attempted corrective actions. The additional actions may be related to the corrective actions determined during the diagnostic services and filtering of the user input. The additional actions may be determined by analyzing the corrective actions.

[0075] For example, the corrective action required may be replacing a wheel bearing. Replacing a wheel bearing may require removal of the brake assembly and wheel. Based on vehicle age, mileage, usage data, last service, and other factors, the system can determine whether the brakes require service or will require service in the near future. Thus, it can be determined based on filtering of the corrective actions associated with the diagnostic service and user input that the brakes should also be replaced. In an alternative example, the additional action may be completely unrelated. For example, the corrective action required may be replacing a wheel bearing. Based on a determination that the vehicle will require service, additional diagnostics covering all or a portion of the vehicle may be run.

[0076] In one example, it may be determined based on sensor data, age, usage, voltage, or other criteria that the battery should also be replaced while the vehicle is undergoing its corrective action. This step allows for optimization of shop time and labor. The system may analyze overlapping repair requests to determine if other components should be replaced during the repair of the first component. In some embodiments, block 606 is performed after obtaining approval for the service request 610 or after determining that the service request should be provided.

[0077] Block 608 includes transmitting the results of the diagnostic service kit. The results of the diagnostic service kit can be transmitted to the cloud, network, or processor. The results of the diagnostic service kit can be transmitted to a service shop or technician. The results can also be transmitted to both.

[0078] Block 610 includes obtaining approval from the user for the requested service. Approval may be obtained via a user device, such as a mobile phone, or via an interface in the vehicle. Block 608 may also include scheduling service. Service may be scheduled based on parts availability, workshop availability, and the urgency of the service request.

[0079] Although various aspects will be described in terms of illustrative embodiments and combinations of features, those skilled in the relevant art will appreciate that the examples and combinations of features are illustrative in nature and should not be construed as limiting. More specifically, various aspects of the present application may be applicable to various types of vehicle data or vehicle processes. However, those skilled in the relevant art will appreciate that various aspects of the present application are not necessarily limited to application to any particular type of vehicle data, data communications, or exemplary interactions between third parties, customers, and network service providers.

[0080] The foregoing disclosure is not intended to limit the disclosure to the precise form disclosed or to the specific field of use. Thus, it is contemplated that various alternative embodiments of the disclosure and / or modifications to the disclosure, whether explicitly described or implied herein, are possible. Having thus described the embodiments of the disclosure, one of ordinary skill in the art will recognize that changes may be made in form and detail without departing from the scope of the disclosure. Therefore, the disclosure is limited only by the claims.

[0081] In the foregoing description, the present disclosure has been described with reference to specific embodiments. However, as will be appreciated by those skilled in the art, the various embodiments disclosed herein may be modified or implemented in various other ways without departing from the spirit and scope of the present disclosure. Therefore, this description should be considered illustrative, with the purpose of teaching those skilled in the art to make and use the various embodiments of the disclosed vent assembly. It should be understood that the disclosed forms shown and described herein should be considered as representative embodiments. Equivalent elements, materials, processes or steps may replace the elements, materials, processes or steps represented and described herein. In addition, certain features of the present disclosure may be used independently of the use of other features, all of which will be apparent to those skilled in the art after benefiting from the description of the present disclosure. Expressions such as "including", "comprising", "combining", "consisting of", "having", "being" used to describe and claim the present disclosure are intended to be interpreted in a non-exclusive manner, i.e., allowing items, parts or elements not explicitly described to also exist. References to the singular should also be interpreted as being related to the plural.

[0082] In addition, the various embodiments disclosed herein should be understood in an illustrative and explanatory sense, and should never be interpreted as limitations to the present disclosure. All link references (e.g., attachment, fixing, coupling, connection, etc.) are only used to help readers understand the present disclosure, and may not cause limitations, especially the position, direction or use of the system and / or method disclosed herein. Therefore, if there is a link reference, it should be widely interpreted. In addition, such link references do not necessarily mean that two elements are directly connected to each other.

[0083] Furthermore, all numerical terms, such as but not limited to "first," "second," "third," "primary," "secondary," "primary" or any other general and / or numerical terms, shall also be used merely as identifiers to assist the reader in understanding the various elements, embodiments, variations and / or modifications of the present disclosure and shall not create any limitations, especially with respect to the order or preference of any element, embodiment, variation and / or modification relative to or over another element, embodiment, variation and / or modification.

[0084] It will also be appreciated that one or more of the elements depicted in the drawings / figures may also be implemented in a more separate or integrated manner, or even removed or rendered inoperable in some cases, as may be useful depending on the particular application.

Claims

1. A system for managing vehicle maintenance, comprising: A first computing device associated with a vehicle, the first computing device having a processor and a memory, the processor and the memory executing computer-readable instructions that cause the first computing device to: capturing at least one user input, wherein the at least one user input corresponds to at least one of a requested service or an observed vehicle operating parameter; executing a diagnostic service suite in response to the captured at least one user input; transmitting at least one processing result associated with the diagnostic service suite; a second computing device associated with the network-based management component, the second computing device having a processor and a memory, the processor and the memory executing computer-readable instructions that cause the network-based management component to: obtaining at least one transmitted processing result associated with the diagnostic service suite; as well as Determining whether to provide the service request based on the transmitted processing result, wherein the first computing device is further operable to receive a determined provision for the service request.

2. The system of claim 1, wherein the computer-readable instructions further cause the network-based management component to obtain user approval of the service request. 3 . The system of claim 1 , wherein executing the diagnostic service suite includes identifying corrective actions or pre-service steps to be performed. 4 . The system of claim 3 , wherein determining whether to provide the service request is based on availability of a vehicle component, wherein the vehicle component is based on the corrective action. The system of claim 1 , wherein the first computing device is integrated into the vehicle.

6. A method for managing vehicle maintenance, comprising: capturing at least one user input, wherein the at least one user input corresponds to at least one of a requested service or an observed vehicle operating parameter; causing execution of a diagnostic service suite at the vehicle in response to the captured at least one user input; transmitting at least one processing result associated with performing the diagnostic service suite at the vehicle; as well as A user approval of the service request is obtained and at least one service is scheduled based at least in part on the at least one processing result. 7 . The method of claim 6 , wherein executing the diagnostic service suite includes identifying a set of corrective actions or pre-service steps to be performed. 8 . The method of claim 7 , wherein executing a diagnostic service suite includes executing the set of corrective actions or the pre-service steps to be performed. 9 . The method of claim 6 , wherein causing execution of a diagnostic service suite at the vehicle includes obtaining at least one diagnostic service from a service provider. 10 . The method of claim 6 , wherein causing execution of a diagnostic service suite at the vehicle includes modifying at least one diagnostic service. The method of claim 6 , wherein the diagnostic service suite corresponds to a series of diagnostic services.

12. The method of claim 6, further comprising maintaining historical information corresponding to multiple executions of the diagnostic service suite.

13. A method for managing vehicle maintenance, comprising: receiving at least one user input related to a vehicle component; causing execution of a diagnostic service suite at the vehicle in response to the at least one user input received; transmitting at least one processing result associated with executing the diagnostic service suite; as well as A determination is made as to whether to provide the first service request. The method of claim 13 , wherein the vehicle component is a battery system. The method of claim 13 , further comprising prompting a user to enter the user input. 16 . The method of claim 13 , further comprising generating a recommendation for additional vehicle diagnostics based on the at least one processing result associated with performing the diagnostic service suite.

17. The method of claim 13, wherein executing the diagnostic service suite includes identifying corrective actions or pre-service steps to be performed.

18. The method of claim 17, wherein determining whether to provide the first service request is based on availability of a vehicle component, wherein the vehicle component is based on the corrective action.

19. The method of claim 17, wherein determining whether to provide the first service request is based on a severity of a first problem compared to a plurality of other users, wherein the first problem is associated with the corrective action.

20. The method of claim 13, further comprising obtaining user approval of the service request.

Images