System for identifying failure of vehicle, method for identifying failure of vehicle, and recording medium

Abstract

An example of a technique for identifying a failure of a vehicle is described. In one example, a failure indicator displayed on a dashboard of the vehicle is scanned. On the basis of a failure database set in advance in a system, a failure corresponding to the failure indicator is identified. The failure database includes information related to a plurality of failure indicators associated with the vehicle. Furthermore, on the basis of the failure database, a priority level of the failure is identified. The priority level is defined in advance for each of the plurality of failures. Furthermore, one or more instructions corresponding to the failure to be displayed are extracted from the failure database. The one or more instructions are different depending on the priority level of the failure.

Description

System for identifying vehicle defects, method for identifying vehicle defects, and recording medium

[0001] The present subject matter relates generally to vehicle diagnostics, and more particularly to systems, methods, and media for identifying, classifying, and providing solutions to vehicle malfunctions.

[0002] Vehicles, particularly automobiles, are complex machines that contain numerous systems and subsystems that each play a role in the overall functioning of the vehicle. Examples of such systems include, but are not limited to, the engine, transmission, battery, braking system, and electrical system, as well as the numerous sensors and indicators designed to monitor their status. These components can fail for a variety of reasons, including normal wear and tear, environmental factors, or technical defects, which can adversely affect the vehicle's performance, compromise its safety, or both.

[0003] To quickly alert the driver to such potential malfunctions, vehicles are commonly equipped with a variety of indicators, commonly referred to as warning indicators or fault indicators. Fault indicators are typically located on the vehicle's instrument cluster, which is part of the vehicle's dashboard. These fault indicators illuminate, flash, or change color to serve as a visual cue indicating a malfunction within a particular system or subsystem of the vehicle. For example, a vehicle may be equipped with separate fault indicators for the engine, braking system, battery, hydraulics, etc., among others, which are designed to alert the driver to specific issues that require immediate attention or potential future repair. For these reasons, fault indicators are an essential feature for safely and efficiently operating a vehicle.

[0004] However, understanding the severity and impact associated with a malfunction indicator can be difficult, especially for novice or inexperienced drivers.

[0005] The present invention provides a system, a method for identifying vehicle faults, and a recording medium that prioritizes vehicle faults and communicates that information to the driver, thereby increasing vehicle reliability.

[0006] The present invention solves the above problem by identifying a defect corresponding to a defect indicator based on a defect database, identifying a predefined priority level for each of a plurality of defects based on the defect database, extracting one or more instructions from the defect database corresponding to the defect to be displayed, and making the one or more instructions different depending on the priority level of the defect.

[0007] According to the present invention, the reliability of the vehicle can be improved.

[0008] Figure 1 illustrates a network environment for implementing an example technique for identifying vehicle faults in one embodiment of the present subject matter. Figure 2 illustrates a system for identifying vehicle faults in another embodiment of the present subject matter. Figure 3 illustrates a method for identifying vehicle faults in another embodiment of the present subject matter. Figure 4 illustrates a method for identifying a fault as a high priority fault in another embodiment of the present subject matter. Figure 5 illustrates a computing environment for identifying vehicle faults in one embodiment of the present subject matter. Detailed Description of the Invention

[0009] The present subject matter relates to systems and methods for identifying vehicle faults.

[0010] Vehicles, particularly automobiles, now feature a variety of safety features intended to enhance the safety of both the driver and passengers. One such safety feature is the malfunction indicator. As mentioned above, a malfunction indicator is typically displayed on the instrument cluster on the vehicle's dashboard, directly in front of the vehicle driver. A malfunction indicator is a direct line of communication between the vehicle's various systems and the vehicle driver, providing information about vehicle malfunctions, ranging from low fuel levels to engine malfunctions, braking system issues, electrical system malfunctions, and more. The primary purpose of a malfunction indicator is to alert the driver when a malfunction is detected within a vehicle's systems, allowing the driver to take appropriate action to address the malfunction, thereby preventing further damage to the vehicle and mitigating potential safety risks. This may include, for example, anything from refilling fluid reservoirs to scheduling repairs or immediately pulling over the vehicle to avoid catastrophic engine damage.

[0011] The presence of fault indicators not only allows for proactive vehicle maintenance, but also improves overall safety by allowing any potential faults in the vehicle's systems to be addressed quickly. This is expected to extend the life of vehicle components, reduce repair costs, and, more importantly, lead to safer driving. As such, fault indicators remain a critical safety feature to this day, giving drivers confidence that their vehicle is operating as intended and alerting them to take corrective action if it is not.

[0012] However, understanding these malfunction indicators can be difficult, especially for novice or inexperienced drivers. When a malfunction indicator lights up or flashes on a vehicle's dashboard, it warns that a malfunction has occurred in one of the vehicle's systems or components. However, the meaning of these malfunction indicators may not be immediately clear to drivers who may not have a strong understanding of how automobiles work.

[0013] Aside from identifying what a malfunction indicator is trying to communicate, a serious issue is the fact that not all malfunction indicators are created equal in terms of the level of severity of the malfunction they indicate. That is, some malfunction indicators may indicate minor malfunctions that can be addressed at the driver's convenience, while others may indicate serious malfunctions that may require prompt action to prevent damage to the vehicle or ensure the safety of the vehicle's passengers and driver. For example, a flashing engine warning light may indicate a serious engine problem that, if ignored, could result in the vehicle immobilizing or posing a safety risk, whereas a tire pressure warning light may indicate that one or more tires are slightly under-inflated, which may be a relatively easy fix.

[0014] The lack of understanding among novice drivers of the severity and impact associated with these malfunction indicators is a pressing concern. Without proper information about what each malfunction indicator indicates and the urgency of the associated malfunction, drivers may inadvertently continue operating their vehicle in an unsafe situation. This not only creates a risk of damage to the vehicle, but also compromises the safety of the driver, passengers, and others on the road.

[0015] Traditionally, vehicle drivers are expected to consult their vehicle's manual to learn about a particular fault indicator and its corresponding fault. For example, if a particular fault indicator illuminates while driving a vehicle, the driver may need to consult the manual if they are unfamiliar with the illuminated fault indicator. However, this process can be time-consuming and tedious, especially while driving or in an emergency. Furthermore, the language used in these manuals can be difficult and technical, making this process even more tedious and challenging for non-technical drivers to understand the meaning and impact of the fault indicator. As a result, drivers may misinterpret the severity of the fault associated with the fault indicator displayed on the dashboard and fail to recognize that the vehicle is experiencing a serious malfunction. This misinterpretation can result in damage to the vehicle, increased repair costs, and even pose a safety risk if the malfunction affects a component essential to the safe operation of the vehicle.

[0016] Systems often rely on multiple components working together and the use of application program interface (API) calls to identify the fault corresponding to a given fault indicator. For example, a manual may be available on a website in the form of a list of faults, such as those provided by the vehicle manufacturer, so that a driver or other user can search the list to identify the corresponding fault. Using an app or web browser running on a user device, such as a smartphone, a user may be able to access the website, search the list, and understand the meaning of the fault indicator. However, such previously known systems are unable to effectively prioritize faults based on their potential impact on the operation of the vehicle. This lack of prioritization can lead to a number of problems. For example, a driver may mistakenly believe that a warning corresponding to a fault indicates a less serious fault, when in fact it indicates a higher-priority fault requiring immediate driver action. This misunderstanding can lead to serious consequences, such as the driver failing to promptly respond to a serious fault, thereby worsening the problem.

[0017] Another problem with conventional systems is that they rely on an internet connection to identify the fault associated with a particular fault indicator. Considering the example mentioned above, accessing the manual on a website would require an active internet connection on the user device. Only with this connection would the driver be able to access the website and use the manual to understand the meaning of the fault indicator. This dependency on an internet connection can be problematic because it assumes that the driver has uninterrupted internet access, which may not be practical in remote areas or areas with unreliable network connectivity.

[0018] Embodiments of the present subject matter describe techniques for identifying a fault in a vehicle. The present subject matter describes a method for identifying a fault that includes scanning a fault indicator displayed on an instrument cluster in a vehicle's dashboard. The scanning may be performed by a system, e.g., a user device such as a cell phone or tablet equipped with a camera. The fault indicator may be displayed, for example, by turning on, lighting up, or flashing a fault indicator located on the vehicle's instrument cluster when a fault is detected in the vehicle. For example, when a vehicle's electronic control unit (ECU) identifies a fault, the ECU may trigger the illumination of a fault indicator corresponding to the identified fault.

[0019] According to one embodiment of the present subject matter, based on the scanned fault indicator, a fault associated with the scanned fault indicator is identified. This identification process is performed based on a fault database pre-configured in the system. The pre-configured fault database contains detailed information about various fault indicators known to be associated with the vehicle. For example, the pre-configured fault database may contain information related to various fault indicators associated with a particular make and model of vehicle that is important to a user of the system. In one example, the pre-configured fault database may include a wide variety of diagnostic codes, descriptions of the fault indicator, and corresponding systems or subsystems of the vehicle that may be affected by the fault. To identify the fault associated with the scanned fault indicator, the database is queried to match the scanned indicator with information about the corresponding fault contained within the database.

[0020] According to one embodiment of the present subject matter, after identifying a fault, a priority level of the fault is determined. The priority level is predefined for each fault in a predefined fault database. That is, each type of fault has an associated priority level, such as a high priority fault, a medium priority fault, or a low priority fault. A high priority fault may be defined as a fault that requires immediate attention to prevent damage to the vehicle or ensure the safety of the occupants. A medium priority fault may be defined as a fault that may not require immediate attention but could lead to a more serious problem if not addressed within a timeframe. A low priority fault may be defined as a fault that does not pose an immediate significant impact on vehicle performance or safety, can be addressed at the driver's convenience, and therefore may not require immediate attention.

[0021] According to one embodiment of the present subject matter, after identifying the priority level of the fault associated with the fault indicator, one or more instructions are retrieved from a pre-established fault database corresponding to the identified fault. Such instructions are displayed to a vehicle user, such as by displaying them on a system display, to guide the user on how to address the fault. In one example, the instructions retrieved from the fault data vary depending on the priority level of the fault. For example, a high-priority fault may prompt a prompt response or expert assistance, while a low-priority fault may prompt a less urgent procedure or monitoring of the fault.

[0022] Thus, the subject matter of the present invention increases vehicle safety and reliability while reducing the risk of damage to the vehicle and associated repair costs by correctly prioritizing vehicle malfunctions based on their potential impact on vehicle operation and communicating that information to the driver.

[0023] Additionally, the present subject matter provides information about malfunctions even without an internet connection. This is achieved through a pre-populated malfunction database that is pre-populated with information related to multiple malfunction indicators associated with a vehicle and stored locally within the system. Having this database available locally eliminates dependency on external data sources or internet-based updates, which may be unavailable in an emergency. The pre-populated malfunction database allows for quick access to a comprehensive list of possible vehicle malfunctions and associated priority levels. Thus, the present subject matter may enhance a driver's ability to maintain their vehicle by providing a more efficient and user-friendly way to identify and prioritize malfunctions, improving vehicle maintenance practices and enhancing road safety.

[0024] The above-described system for identifying vehicle faults is further described with reference to Figures 1 to 5. It should be noted that the description and drawings merely illustrate the principles of the present subject matter using the examples described herein and should not be construed as limiting the present subject matter. Accordingly, it should be noted that various configurations illustrating the principles of the present subject matter are conceivable, although not explicitly described or shown herein. Furthermore, all statements herein describing principles, aspects, and examples of the present subject matter, as well as specific examples thereof, are intended to encompass equivalents thereof.

[0025] 1 illustrates a network environment 100 including a system 102 that, in one embodiment of the present subject matter, may identify, classify, and provide solutions for vehicle malfunctions, such as a vehicle 104, as shown in FIG. 1. Examples of a vehicle 104 include, but are not limited to, two-wheeled, three-wheeled, and four-wheeled vehicles.

[0026] In one embodiment, vehicle 104 may include an instrument cluster 106 and an electronic control unit (not shown). In another example, instrument cluster 106 may be a digital instrument panel that is typically located on the dashboard in front of the driver of vehicle 104. For example, instrument cluster 106 may be a human-machine interface (HMI) device.

[0027] In one example, the instrument cluster 106 may include, among other things, multiple fault indicators 108-1, 108-2, ..., 108-n (hereinafter, fault indicators 108-1), each configured to indicate a particular fault, safety issue, or malfunction within various systems and subsystems of the vehicle 104. For example, a fault indicator may be activated when an anomaly is detected in the vehicle's engine performance or emissions control system. Another fault indicator may be activated when a malfunction is detected in the vehicle's airbag system. Another fault indicator may indicate the status of the vehicle's braking system, such as low oil pressure, worn components, or malfunctioning electronics in the anti-lock braking system (ABS). In some cases, a fault indicator may alert a vehicle user, e.g., the driver of the vehicle, that a seat belt is not fastened. Another fault indicator may notify a user that a door is not properly closed. Thus, examples of vehicle malfunction indicators include indicators related to malfunctioning or problematic vehicle components, as well as indicators that can indicate that an operational component is not being used correctly.

[0028] In an exemplary embodiment, instrument cluster 106 may be communicatively coupled to an ECU of vehicle 104. In one example, the ECU may monitor and control the display state of each of a number of fault indicators 108-1, 108-2, ..., 108-n on instrument cluster 106. In doing so, vehicle 104's ECU may continuously monitor the performance and health of vehicle 104 through a network of sensors (not shown) installed throughout vehicle 104. When the ECU detects a deviation from normal operating parameters, the ECU responds by activating a particular fault indicator, such as fault indicator 108-1, located on instrument cluster 106.

[0029] In one example, the fault indicators 108-1, 108-2, ..., 108-n may each be represented by a uniquely designed symbol that corresponds to a particular system or subsystem within the vehicle 104. For example, there may be symbols representing the engine, transmission, braking system, and other critical subsystems of the vehicle 104. In one embodiment, the fault indicators 108-1, 108-2, ..., 108-n may be light emitting diodes (LEDs) of different colors, with each color associated with a particular type of fault within the vehicle 104. For example, a red LED may indicate a serious fault that requires immediate attention, a yellow LED may indicate a warning or caution so that a user of the vehicle 104 can respond as soon as possible, and a green LED may indicate that the system is functioning normally. These LEDs illuminate symbols that correspond to the various systems and subsystems of the vehicle, such as the engine, transmission, and braking system, to provide a user with clear visual cues regarding the operational status of the various systems or subsystems of the vehicle 104.

[0030] If the ECU detects a malfunction in any of the systems or subsystems of the vehicle 104, the associated malfunction indicator may illuminate continuously or begin to flash. For example, if the fuel level in the vehicle 104 falls below a predetermined threshold, the ECU may trigger a low fuel warning light, a specific malfunction indicator such as malfunction indicator 108-1 shown in FIG. 1 , designed to resemble a fuel pump or similar symbol. This malfunction indicator 108-1 may illuminate continuously to alert the user of the vehicle 104 that there is insufficient fuel in the vehicle 104.

[0031] In one example, if a fault indicator, such as fault indicator 108-1, illuminates on instrument cluster 106 and the user is unfamiliar with the particular fault signified by fault indicator 108-1, the user may use system 102 to determine what the fault is associated with the illuminated fault indicator 108-1. System 102 scans the details associated with the illuminated fault indicator 108-1 on instrument cluster 106 to identify the corresponding fault, thereby providing an efficient and easy-to-use process for identifying and classifying vehicle faults and providing solutions to the faults in real time.

[0032] The system 102 according to the present subject matter may be a user device. Examples of user devices include, at least, electronic data exchange devices such as mobile devices, tablets, wearable devices, laptops, computers, etc. The system 102 may interface with an image capture device, such as a camera, operable in conjunction with the system 102 to scan images or videos of the fault indicator 108-1. In one example, the camera may be built-in or integrated into the system, such as a mobile camera. Although not shown, in one example, the camera may be an external camera connected to the system 102, such as an external webcam connected to the system 102 via a universal serial bus (USB). As shown in FIG. 1 , the camera of the system 102 may be used to scan details of the illuminated fault indicator 108-1 on the instrument cluster 106. The camera may transmit the scanned information to other components, such as a processor (not shown) of the system 102, for further processing.

[0033] The network environment 100 may further include a central server 112. The central server 112 may include one or more databases (not shown) configured to store various information that may be needed to identify, classify, and provide solutions for vehicle faults, such as the vehicle 104. For example, the database of the central server 112 may include detailed information about the location of all fault indicators for all makes and models produced by a manufacturer, as well as faults, diagnostic procedures, and potential fault solutions associated with those fault indicators. In some embodiments, the information in the database may be organized by make and model. In some embodiments, the database may be searchable using search queries, such as specific search terms or images. In one example, the central server 112 may be managed by the manufacturer of the vehicle 104.

[0034] The central server 112 serves as a source of information for users of vehicles, such as the vehicle 104, including the vehicle's driver, and / or service personnel performing tasks related to the repair and maintenance of the vehicle. Users may access the central server 112 to obtain information related to vehicle malfunctions, for example, using their respective user devices, such as the system 102 described above.

[0035] In an exemplary embodiment, system 102 may interact with central server 112 via network 114 to receive data related to malfunctions in vehicle 104. Central server 112 may be a standalone server or, in one example, may be a remote server on a cloud computing platform to which system 102 may be connected via network 114.

[0036] As described above, the database of central server 112 may contain information about all fault indicators for every make and model produced by a manufacturer, as well as detailed information about the faults, diagnostic procedures, and possible fault resolutions associated with those fault indicators. However, system 102 may request and receive from central server 112's database a specific subset of data that may be relevant to the make and model of a user of system 102. For example, if a user drives a 2021 Model X sedan, system 102 may query central server 112 for information related to faults specific to that model and year to ensure that accurate and applicable diagnostic information and instructions for resolving the faults are presented to the user.

[0037] In one exemplary embodiment of the present subject matter, system 102 is configured to interact with central server 112 to retrieve data corresponding to faults in vehicle 104 and create a pre-configured fault database that is stored locally in memory of system 102. For example, during the configuration process, system 102 may connect to central server 112 via network 114 and obtain information from the central server's 112 database relating to faults in vehicle 104 and their fault indicators, diagnostic procedures, and potential solutions.

[0038] In one example, the setup process may be understood to be a one-time process in which a user of the system 102 connects the system 102 to the central server 112 and obtains data corresponding to a malfunction of the vehicle 104. For example, the user of the system 102 may perform the setup process when purchasing the vehicle 104 or when registering themselves as the owner of the vehicle 104. For example, the setup process may be part of a process in which a user registers a new vehicle for service by the manufacturer of the vehicle 104 or an authorized service center associated with the vehicle 104. In one example, the setup process may be performed when an internet connection between the system 102 and the central server 112 can be reliably established.

[0039] The setup process enables the system 102 to obtain and store information related to the make and model of a vehicle, such as vehicle 104, driven or used by a user of the system 102. Examples of information obtained by the system 102 during the setup process include, but are not limited to, various fault indicators specific to the vehicle 104, such as fault indicators 108-1, 108-2, ..., 108-n, detailed descriptions of faults associated with these fault indicators, step-by-step diagnostic procedures, and possible solutions or instructions for addressing such faults. The information obtained during the setup process may be stored directly in the memory of the user's user device. Alternatively, the information obtained during the setup process may be stored on an external memory device compatible with the system 102. Examples of such external memory devices include, but are not limited to, a memory card, USB drive, or other portable storage device that can be connected to the system 102 via a physical interface or wirelessly.

[0040] Once the configuration process is complete, the information obtained from the central server 112 is made accessible as a pre-configured fault database that the system 102 stores locally for quick and efficient access while the system 102 is in operation.

[0041] For example, network 114 may be a single network or a combination of networks, may use a variety of different communication protocols, may be a wireless or wired network, or a combination thereof. Examples of such individual networks include Global System for Mobile Communications (GSM) networks, Universal Mobile Telecommunications System (UMTS) networks, Personal Communications Service (PCS) networks, Time Division Multiple Access (TDMA) networks, Code Division Multiple Access (CDMA) networks, and Next Generation Networks (NGN). Network), Public Switched Telephone Network (PSTN). Depending on the technology, network 114 may include various network components such as gateways and routers, although such details are omitted from this description for the sake of brevity.

[0042] In one exemplary embodiment of the present subject matter, to identify an illuminated fault indicator 108-1 on the instrument cluster 106, the scanning module 110 of the system 102 may prompt a user to activate the camera of the system 102 to scan the fault indicator 108-1. The scanning process may include taking a snapshot or video of the fault indicator 108-1, which serves as an initial input for identifying the fault. The system 102 receives the image of the fault indicator 108-1 in response to the prompt and analyzes the image of the fault indicator 108-1 to identify the fault corresponding to the fault indicator 108-1. In doing so, the system 102 compares the image of the fault indicator 108-1 against a pre-established fault database. Through this comparison, the system 102 identifies the fault corresponding to the illuminated fault indicator 108-1.

[0043] In one example, once identified, details corresponding to the identified fault may be displayed on a display unit or screen of system 102. For example, if system 102 identifies that fault indicator 108-1 indicates a "low fuel" condition, details of the fault may be displayed on the screen of system 102 as a message such as "low fuel - please refuel as soon as possible." System 102 may also enable the driver to click on the message on the screen of system 102 to receive instructions for correcting the fault. For example, upon clicking on the "low fuel" message, system 102 may provide instructions in the form of displaying the location of the nearest gas station and directions to the gas station, thereby assisting the user in quickly responding to the low fuel condition.

[0044] By storing a pre-configured fault database locally on the user device in this manner, drivers can quickly access solutions to identify faults without relying on a network connection. This eliminates the need for the system 102 to communicate with the central server 112 beyond the configuration process to obtain relevant information, resulting in faster response times and an efficient and reliable method for users to address vehicle faults, even in areas with poor or no network connectivity. See FIG. 2 for a description of the implementation and operation of the system 102 for identifying, classifying, and providing solutions to vehicle faults.

[0045] 2 illustrates a system 102 for identifying faults in a vehicle, such as vehicle 104, in one embodiment of the present subject matter. The subject system 102 allows a user, such as a driver of vehicle 104, to quickly and easily understand vehicle faults and their solutions. By simply scanning the instrument cluster 106 of vehicle 104, the user of vehicle 104 could learn details about any illuminated fault indicators and receive concise instructions for correcting the associated fault.

[0046] As depicted in FIG. 2 , in one embodiment of the present subject matter, system 102 may include at least one processor 202 and memory 204 coupled to processor 202. In one example, processor 202 may be implemented as a microprocessor, microcomputer, microcontroller, digital signal processor, central processing unit, state machine, logic circuit, and / or any device that manipulates signals based on operational instructions. Examples of memory 204 include any computer-readable storage medium known in the art, including, for example, volatile memory (e.g., RAM) and / or non-volatile memory (e.g., EPROM, flash memory, etc.). Memory 204 may also be an external memory unit, such as a flash drive, compact disk drive, external hard disk drive, etc.

[0047] 2, in one embodiment, an interface 206 may be coupled to the processor 202. Examples of the interface 206 include various software and hardware interfaces that enable the system 102 to interact with other communication and computing devices, such as network components, external storage locations, and peripherals. The interface 206 may enable components of the system 102 to connect to one another. Additionally, in one example, the interface 206 may connect the system 102 to the central server 112.

[0048] The system 102 may also include modules 208 and data 222 coupled to the processor 202. In one example, the modules 208 and data 222 may reside in the memory 204.

[0049] In one example, data 222 may include fault indicator data 224, fault history data 226, and other data 228. Modules 208 may include routines, programs, objects, components, data structures, etc. that perform particular tasks or implement particular abstract data types. Modules 208 may further include modules that supplement applications on system 102, such as operating system modules. Modules 208 further include modules that implement certain functions of system 102, such as processing information received by system 102 from a user, such as a driver. Data 222 serves as a repository for data that one or more modules 208 may retrieve, process, receive, or generate, among other things. Examples of modules 208 include scanning module 210, fault identification module 212, recommendation module 214, display module 216, and other modules 220. Examples of other modules 220 include programs or coded instructions that supplement applications and functions, such as programs within the operating system of system 102.

[0050] To identify a fault associated with a fault indicator, such as fault indicator 108-1, system 102 may accept user input regarding the fault indicator 108-1 to be identified. System 102 may accept user input when fault indicator 108-1 is activated and illuminated to help the user determine the fault that caused the activation of fault indicator 108-1, or when the user wishes to understand the fault associated with a particular fault indicator, such as fault indicator 108-1 provided by the manufacturer of vehicle 104 on instrument cluster 106, regardless of whether fault indicator 108-1 is currently illuminated.

[0051] Thus, in one exemplary embodiment, scanning module 210 may activate a camera of system 102 and generate a prompt to prompt a user to scan an available fault indicator 108-1 on dashboard instrument cluster 106. Here, scanning module 210 is similar to scanning module 110 described with reference to FIG. 1 . In response to the prompt, scanning module 210 scans fault indicator 108-1. As previously described, in some embodiments, scanning may include activating a camera to scan an image or video of fault indicator 108-1. System 102 then uses the scanned information to identify the fault associated with fault indicator 108-1. Information about fault indicator 108-1 received by scanning module 210 is stored as fault indicator data 224 in memory 204 of system 102.

[0052] The system 102 may use the information collated in the pre-defined fault database to identify, classify, and provide solutions for faults in the vehicle 104. To this end, when the scanning module 210 receives data related to the fault indicator 108-1, such as a scan of the fault indicator 108-1, the scanning module 210 forwards this information to the fault identification module 212. The fault identification module 212 then compares the received information about the fault indicator 108-1 with existing data in the pre-defined fault database. The purpose of this comparison is to find a correspondence between the fault indicator 108-1 and one of the entries in the pre-defined fault database. By identifying a match, the system 102 may determine the fault indicated by the fault indicator 108-1. For example, the fault indicator 108-1 may display a symbol resembling a fuel pump, a common symbol used to indicate problems related to the fuel system of the vehicle 104, as shown in FIG. 1 . When the scanning module 210 scans this symbol, it transmits this information to the fault identification module 212. For example, upon receiving a fuel pump symbol in the form of scanned image data, the fault identification module 212 begins a process of comparing the fuel pump symbol with entries in a pre-defined fault database. The pre-defined fault database includes various fault indicators, each associated with a particular vehicle fault and its corresponding symbol. The pre-defined fault database may include an entry for the fuel pump symbol that may be associated with a particular fault, such as a low fuel level. The fault identification module 212 matches the received fuel pump symbol with the correct entry in the pre-defined fault database. If a match is found, the system 102 may identify the fault as, for example, a "low fuel fault."Based on the fault identification module 212 identifying a fault associated with the fault indicator 108-1, the display module 216 of the system 102 displays the fault on a screen of the system 102.

[0053] Further, in one example, once a fault corresponding to fault indicator 108-1 is identified, system 102 may proceed to query a pre-configured fault database, identify a fault classification based on the fault's priority level, and provide the user with an appropriate solution or instructions for addressing the fault.

[0054] In one example, the manufacturer of the vehicle 104 may determine whether each fault is classified as a high priority fault, a medium priority fault, or a low priority fault. Information regarding the priority level of the fault, along with other relevant data regarding the fault, may be stored in the central server 112 by the manufacturer of the vehicle 104. As described above, during initialization of the system 102, the system 102 retrieves, among other information, detailed fault descriptions associated with the fault indicators 108-1, 108-2, ..., 108-n of the vehicle 104 from the central server 112. The detailed fault descriptions also include the priority level associated with each fault, as defined by the manufacturer of the vehicle 104. Once retrieved, this information is stored in a pre-configured fault database within the system 102.

[0055] In one example, the pre-configured fault database may be internal to the system 102, meaning that the database is created locally in the memory 204 of the system 102 and is directly accessible to the processor 202. Alternatively, the pre-configured fault database may be external to the system 102. For example, the pre-configured fault database may be provided on a memory device, such as a memory card, that may be external to the system 102. The external component may be connected to the system 102 during use.

[0056] In one example, the manufacturer of the vehicle 104 may classify faults in the vehicle 104 as high-priority, medium-priority, or low-priority based on the urgency or severity of the fault and the nature of the appropriate solution for the fault. A fault in the vehicle 104 may be determined to be low-priority if it is not considered serious enough to affect the immediate operation of the vehicle 104 and does not affect safe operation. Furthermore, a fault may also be classified as low-priority if the user of the vehicle 104 can address and resolve the fault on their own without the assistance of a professional, such as a mechanic. For example, the manufacturer of the vehicle 104 may classify a fault with an interior light or a non-essential auxiliary function as a low-priority fault. In contrast, the manufacturer of the vehicle 104 may consider a fault that is urgent, affects the safe operation of the vehicle 104, and requires the user to stop the vehicle as a high-priority fault. Such a fault may be serious and may not be resolvable by the user without professional intervention. For example, the manufacturer may classify a brake system malfunction or an engine overheating condition as a high-priority fault. A medium priority fault falls between the other two faults in terms of urgency. A medium priority fault allows the user to continue driving the vehicle 104 for a period of time, but still requires professional intervention to resolve. While a medium priority fault is less dangerous than a high priority fault, a medium priority fault is more serious than a low priority fault and may develop into a more serious problem if left untreated. For example, a manufacturer may classify a fault in the exhaust system of the vehicle 104 as a medium priority fault because, while the vehicle 104 may still be drivable, the vehicle 104 may ultimately need to be repaired to prevent a more serious fault.

[0057] Thus, to identify the fault classification, the fault identification module 212 queries a preset fault database. By querying the preset fault database, the fault identification module 212 obtains a priority level of the identified fault. Once the priority level of the identified fault is determined, the recommendation module 214 may proceed to retrieve one or more instructions corresponding to the fault from the preset fault database, which instructions may be displayed on a screen of the system 102, to resolve the fault. In one example, the one or more instructions may vary depending on the priority level of the fault. For example, if the fault is identified as a high-priority fault, the recommendation module 214 may, e.g., via the interface 206, cause the display module 216 to display an instruction on a screen of the system 102 to immediately stop using the vehicle 104 and obtain professional assistance. For medium-priority faults, the recommendation module 214 may cause the display module 216 to display an instruction stating that it is safe to continue driving for a while, but that the fault requires professional attention and advises the user to arrange for repairs as soon as possible. For low-priority faults, the recommendation module 214 may cause the display module 216 to display instructions that allow the user to resolve the fault themselves, or may inform the user that the fault does not affect the drivability of the vehicle 104 and therefore does not require immediate attention, allowing the user to address the issue at their convenience.

[0058] In some embodiments, the display module 216 may provide step-by-step instructions for faults categorized as either low-priority or medium-priority faults. That is, if the fault identification module 212 determines that a fault falls into these categories, the display module 216 may display step-by-step instructions for the user to follow to resolve the fault. For example, for a low-priority fault that does not require immediate attention, the display module 216 may first display instructions encouraging the user to monitor the condition or schedule a maintenance inspection at a later time. Similarly, for a medium-priority fault that may require more immediate attention than a low-priority issue but is not as urgent as a high-priority fault, the display module 216 may provide step-by-step instructions guiding the user to take appropriate action. This may include instructions for performing a specific inspection or emergency repair that the user may be able to perform safely. Displaying step-by-step instructions may facilitate interaction with the system 102, allowing the user to focus on each step without being overwhelmed with information. This may be particularly beneficial in reducing the difficulty of vehicle maintenance for users who may not have a high level of technical knowledge of vehicle systems.

[0059] In one example, when the system 102 displays a fault on the screen, the user is expected to interact with the system 102 by clicking on the screen where the fault is displayed. This action may trigger the system 102 to display instructions corresponding to the identified fault. This may allow the system 102 to provide a clean initial display and make more details available upon request, thereby avoiding information overload and allowing the user to access the instructions when they are ready to address the fault. Alternatively, in another example, when the system 102 identifies a fault and displays it on the screen, the system 102 may simultaneously display all relevant instructions. That is, the user does not need to take any additional action to view the instructions. The user may immediately see the instructions along with the displayed fault. This may allow the user to have all relevant information at hand, which may be beneficial for quickly understanding and addressing the fault.

[0060] In some embodiments, multiple fault indicators, such as fault indicators 108-1, 108-2, ..., 108-n, may be activated simultaneously. This may occur when the vehicle 104 experiences several simultaneous faults, each associated with a different system or component of the vehicle 104 that may be relevant to its operation. When the system 102 detects multiple fault indicators 108-1, 108-2, ..., 108-n on the instrument cluster 106 of the vehicle 104 based on scanning, the system 102 may organize and display the faults corresponding to these fault indicators 108-1, 108-2, ..., 108-n in a prioritized order. The prioritization may be based on the severity of the fault as determined by the fault identification module 212, which classifies each fault as a high-priority fault, a medium-priority fault, or a low-priority fault. The display of the system 102 may then display a list of the detected faults in an order that reflects this hierarchy of priority levels. High-priority faults may require immediate attention because they could affect the safety or performance of the vehicle and may be displayed at the top of the list. High-priority faults are followed by medium-priority faults, which may not require immediate attention but still require attention to prevent future problems. Low-priority faults are the least urgent and may not affect the immediate drivability of the vehicle and may be displayed at the end of the list. Displaying the faults corresponding to the fault indicators 108-1, 108-2, ..., 108-n in this ordered manner allows the user to quickly identify the most pressing faults requiring attention and address those faults in a manner that prioritizes the safety and integrity of the vehicle 104. This approach also helps manage the repair process by focusing on the severity of the fault and guiding the user to take appropriate action for each level of fault severity.

[0061] In one embodiment, instead of generating a list of faults after scanning the instrument cluster 106 of the vehicle 104, the system 102 may identify faults corresponding to a fault indicator, e.g., fault indicator 108-1, and display them directly superimposed on a scanned image of the instrument cluster 106 in which the fault indicator 108-1 is located. When a user uses the system 102 to scan the instrument cluster 106, which includes various fault indicators, such as fault indicators 108-1, 108-2, ..., 108-n, the scanning module 210 scans the image of the instrument cluster 106. If the fault indicator 108-1 is illuminated, the fault identification module 212 identifies the corresponding fault based on a pre-established fault database. Rather than presenting a separate list that the user must read before matching to the appropriate fault indicator 108-1 on the instrument cluster 106, the system 102 simplifies the process by displaying the fault name or description directly in the location of the fault indicator 108-1 on the image of the instrument cluster 106. This may allow the user to more easily understand which particular fault indicator indicates a fault and what that fault is, without having to match a separate element. This provides an intuitive and immediate visual association between the fault indicator and its meaning, improving usability.

[0062] According to embodiments of the present subject matter, this may be accomplished through augmented reality (AR) or similar overlay technology to assist a user in more efficiently diagnosing vehicle problems. Here, AR technology may be used to create a virtual replica of the vehicle's instrument cluster 106 in which the fault indicators 108-1, 108-2, ..., 108-n are located. Information about the various faults corresponding to each of the fault indicators 108-1, 108-2, ..., 108-n may be mapped onto the AR-generated replica of the instrument cluster 106. This mapping enables the system 102 to associate each virtual fault indicator 108-1, 108-2, ..., 108-n with the associated fault details from a pre-established fault database. When a user views this AR-generated replica using a user device, such as a smartphone or AR glasses, the user may be able to interact with the virtual replica of the instrument cluster 106 in a manner similar to the way the user interacts with the real instrument cluster 106. When a user "clicks" or selects a particular fault indicator within this AR-generated replica, the system 102 may respond by displaying corresponding details about the fault. For example, if a user clicks on a virtual representation of a coolant warning light within the virtual replica of the instrument cluster 106, the system 102 may display details about the fault associated with the coolant warning. This information may include the nature of the fault, the severity of the fault, and instructions for resolving the fault.

[0063] In an exemplary embodiment, the system 102 may record and store each fault detected by the fault identification module 212 as fault history data 226 in the memory 204 of the system 102. This fault history data 226 may include various information about the fault identified by the fault identification module 212, such as the date and time the fault was detected, the corrective action taken to resolve the fault, an error code associated with the fault, and conditions observed while the fault was occurring, such as the speed or engine temperature of the vehicle 104. When a user subsequently uses the system 102 to diagnose a fault indicated by a fault indicator, such as the fault indicator 108-1, the display module 216 may present historical data related to the identified fault from the fault history data 226 along with the fault associated with the fault indicator 108-1. This historical data may be displayed on a screen of the system 102 and may include a chronological list of each instance in which a fault was previously detected, along with the date of its occurrence. Additionally, a history of the corrective actions previously taken to resolve each instance of the fault may be displayed. This focus on history will allow users to understand not only the frequency and severity of failures, but also the effectiveness of past corrective actions, providing information that will help them make better decisions when troubleshooting and repairing, both now and in the future.

[0064] There may be situations in which a fault indicator, such as fault indicator 108-1, displayed on instrument cluster 106 does not accurately reflect a genuine fault within a system or subsystem of vehicle 104. Such situations may arise for a variety of reasons, such as a sensor error, a temporary fault, or a misinterpretation of the vehicle's state by the vehicle's diagnostic system. For example, a seat belt indicator may remain illuminated even after the fault has been resolved, or the indicator may continue to glow despite the seat belt being fastened. According to embodiments of the present subject matter, fault identification module 212 may operate to address such false indications of a fault.

[0065] According to an embodiment, the fault identification module 212 is configured to specifically check for fault indicators associated with high priority faults to avoid falsely displaying high priority faults to the user. If the fault identification module 212 interprets a fault indicator as indicating a high priority fault, but no such fault actually exists (a false high priority fault), this is referred to as a false high priority fault. To address the issue of false high priority faults, in an exemplary embodiment, the system 102 may incorporate a verification process that utilizes Controller Area Network (CAN) data from the vehicle 104 to verify whether a fault identified by the system 102 is a false high priority fault.

[0066] According to an embodiment of the present subject matter, information related to high-priority faults may be stored as part of the CAN data in the ECU of the vehicle 104. The CAN data stored in the vehicle's ECU may be replicated on a database of the central server 112, for example, using a process in which the ECU collects and temporarily stores the relevant data and securely transmits the data to the central server 112 over the network 114. After updating the database of the central server 112, an application program interface (API) is triggered, which serves as an interface between the system 102 and the central server 112. The API is responsible for updating the database of the system 102 to ensure that the system 102 accurately reflects the most up-to-date information regarding high-priority faults. For example, if the ECU of the vehicle 104 detects a malfunction in the vehicle's anti-lock braking system (ABS), the malfunction may be classified as a high-priority malfunction because it impacts the safety of the vehicle 104. The ECU records the malfunction as CAN data, which includes details such as the time of occurrence, an error code, and the system status. This CAN data is then temporarily stored within the ECU. The ECU then initiates a secure transmission process to send the recorded CAN data to the central server 112 over the network 114. If the transmission is successful, the central server 112 updates its database with the latest information regarding high-priority malfunctions from the vehicle 104. Once the database of the central server 112 is updated, an API is invoked. Using this API, the system 102 sends a request to the central server 112 to obtain the updated information regarding high-priority malfunctions. The central server 112 responds to this request by providing the relevant data to the system 102. The system 102 then uses the data received from the API to update its fault database. Based on the information received from the central server 112, the system 102 determines whether the ABS is a false high priority fault.

[0067] In operation, when the fault identification module 212 of the system 102 identifies a fault corresponding to a fault indicator classified as a high-priority fault, the communications module 218 accesses updated CAN data on the central server 112 using a JavaScript Object Notation (JSON) construct for communication. This process enables data synchronization between the system 102 and the central server 112, enabling accurate identification of high-priority faults. In one embodiment, the system 102 may synchronize its database with the central server 112 using the Internet to determine whether the high-priority fault identified by the fault identification module 212 is a false high-priority fault. If the system 102 determines that the ABS fault is not a false high-priority fault, the system 102 may maintain the ABS fault as a high priority and proceed with appropriate notifications and recommendations. This ensures that the system 102 has current information regarding the ABS fault to accurately diagnose the fault and provide recommendations to the user. For example, the system 102 may alert the driver to an ABS problem, recommend prompt repair, and provide the location of the nearest authorized service center. However, if the system 102 determines that the fault identified by the fault identification module 212 is a false high-priority fault, the system 102 may indicate to the user that no high-priority fault exists and therefore no warning is warranted. For activated fault indicators that falsely indicate a high-priority fault, the recommendation module 214 may instruct the user to seek expert assistance to determine why the fault indicator was activated and to obtain a solution.

[0068] In this manner, if a false high-priority fault is identified, the system 102 may display a warning on the screen of the system 102 to inform the user that the previously indicated high-priority fault is not, in fact, an immediate concern. The warning may include details explaining the nature of the false warning and may reassure the user that no immediate action is required. Such confirmation may thus help to avoid unnecessary repair visits or repairs, reduce potential stress for the user, and ensure that the actual condition of the vehicle 102 is accurately recognized and appropriately managed.

[0069] 3 illustrates a method 300 for identifying a fault in a vehicle, such as vehicle 104, in one embodiment of the present subject matter. The order in which method 300 is described is not intended to be construed as limiting, and the described method blocks may be combined in any number and in any order to implement method 300 or alternative methods. Furthermore, method 300 may be performed by a processor or computing device using any suitable hardware, non-transitory machine-readable instructions, or combination thereof.

[0070] It will be understood that the steps of method 300 (the processes in each step) may be performed by a programmed computing device or based on instructions stored on a non-transitory computer-readable recording medium. Examples of non-transitory computer-readable recording media include digital memory, magnetic storage media such as magnetic disks and magnetic tapes, hard drives, or optically readable digital data storage media. In one example, method 300 may be performed by system 102.

[0071] 3, at block 302, a fault indicator, such as fault indicator 108-1, displayed on an instrument cluster, such as instrument cluster 106, on the dashboard of a vehicle 104 is scanned. As previously described, when scanning, system 102 may interface with an image capture device, such as a camera, operable in conjunction with system 102 to scan and capture an image or video of fault indicator 108-1.

[0072] In block 304, for example, the fault identification module 212 identifies a fault corresponding to the fault indicator 108-1 based on a preset fault database in the system 102. As previously described, the preset fault database may include detailed information about various fault indicators known to be associated with the vehicle 104. In some embodiments, the preset fault database may include information about various fault indicators associated with a particular make and model of vehicle that is important to a user of the system 102. In one example, the preset fault database may include a wide variety of diagnostic codes, descriptions of the fault indicators, and corresponding systems or subsystems of the vehicle 104 that may be affected by the fault.

[0073] In block 306, for example, the fault identification module 212 determines a priority level of the fault associated with the fault indicator 108-1 based on a preset fault database. As described above, a priority level for each fault in the vehicle 400 is predefined in the preset fault database. That is, each type of fault in the vehicle 104 has an associated priority level: a high-priority fault (high-level fault), a medium-priority fault (medium-level fault), or a low-priority fault (low-level fault). If a fault is something that the user of the vehicle 104 may be able to address themselves or if the fault does not affect the operation of the vehicle 104, the fault may be classified as a low-priority fault. Conversely, if the occurrence of the fault requires the user to stop operating the vehicle 104 and requires professional intervention to resolve the fault, the fault is classified as a high-priority fault. Similarly, a medium-priority fault may allow the driver to continue operating the vehicle, but may still require professional assistance to resolve the fault.

[0074] In block 308, for example, the recommendation module 214 retrieves one or more instructions corresponding to the fault from a preset fault database to be displayed to the user. As previously described, the instructions for resolving the identified fault may be displayed on the screen of the system 102 along with details corresponding to the identified fault. As previously described, the displayed instructions for resolving the fault may vary depending on the priority level of the fault and are intended to guide the user on the appropriate action to take in response to the fault. For example, if the fault identification module 212 identifies the fault as a low-priority fault based on a query of the preset fault database, the instructions presented to the user on the screen of the system 102 may include a step-by-step process that the user should follow to resolve the fault themselves. If the fault is identified as a medium-priority fault, the instructions presented to the user on the screen of the system 102 may include steps to schedule repairs for the vehicle 104 or to find the nearest service station. If the malfunction is identified as a high priority malfunction, instructions presented to the user on the screen of the system 102 may include instructions to stop the vehicle 104 as soon as possible or to not drive the vehicle if it is already stopped. Examples of further instructions include finding a dealer or requesting roadside assistance.

[0075] These instructions will help the user understand the severity of the malfunction and take appropriate steps to resolve the vehicle malfunction. Thus, the present subject matter increases vehicle safety and reliability while reducing the risk of damage to the vehicle and associated repair costs.

[0076] 4 illustrates a method 400 for verifying that a fault is a high priority fault. The order in which method 400 is described is not intended to be construed as limiting, and the described method blocks may be combined in any number and in any order to implement method 400 or alternative methods. Furthermore, method 400 may be performed by a processor or computing device using any suitable hardware, non-transitory machine-readable instructions, or combination thereof.

[0077] It will be appreciated that the steps of method 400 may be performed by a programmed computing device or based on instructions stored on a non-transitory computer-readable storage medium. Examples of non-transitory computer-readable storage media include digital memory, magnetic storage media such as magnetic disks and magnetic tapes, hard drives, or optically readable digital data storage media. In one example, method 400 may be performed by system 102.

[0078] 4, at block 402, a fault indicator, such as fault indicator 108-1, displayed on an instrument cluster, such as instrument cluster 106, of a vehicle, such as vehicle 104, is scanned, for example, by using an image capture device in communication with system 102. The image capture device may be a camera operable in communication with system 102 to scan an image or video of fault indicator 108-1.

[0079] At block 404, a fault corresponding to the fault indicator 108-1 is identified based on a pre-established fault database. As previously described, the pre-established fault database may include a comprehensive list of fault indicators, diagnostic codes, and detailed descriptions of possible vehicle faults and corresponding systems or subsystems of the vehicle 104 that may be affected.

[0080] In block 406, the fault identification module 212 identifies a priority level for the fault, for example, by querying a pre-defined fault database. As previously described, the priority level is a predetermined classification stored in the pre-defined fault database, and the priority level provides an indication of the severity and urgency of the fault. The priority level of the fault identified by the fault identification module 212 may be at least one of a high priority fault, a medium priority fault, and a low priority fault.

[0081] At block 408, for example, the fault identification module 212 evaluates whether the fault, as determined by querying a pre-established fault database, is high priority. If the evaluation is affirmative, the method 400 proceeds to block 410. At block 410, communication is established with a remote server, such as the central server 112, to access the vehicle 104's CAN data. To this end, the communication module 218 sends a request to the remote server, such as the central server 112, to obtain CAN data containing information about updated high priority faults. The central server 112 responds to the request by providing the relevant data to the system 102. The system 102 then uses the data received from the API to update its fault database.

[0082] At block 412, it is determined whether the identified fault is a high priority fault based on the CAN data received from the central server 112. For example, the fault determination module 212 performs a determination to evaluate whether the identified fault is a high priority fault.

[0083] At block 414, a further evaluation is performed to determine whether the priority level of the identified fault is confirmed to be high based on the CAN data. If the evaluation at block 414 is affirmative, method 400 proceeds to block 416, where display module 216 displays corrective actions or instructions for the user to follow to resolve the high-priority fault. For example, if the fault is a low brake fluid fault, which may be considered a high-priority fault, display module 216 may instruct the user to immediately stop vehicle 104 if it is in motion, or to refrain from driving if vehicle 104 is currently stationary. Further, the instructions may include a recommendation to contact a dealer for repair, and display module 216 may display on-screen options to help the user find a nearby dealer or contact roadside assistance.

[0084] However, if at block 414 it is determined that the fault is not of high priority according to the CAN data, then method 400 proceeds to block 418. At block 418, display module 216 displays on the screen of system 102 that the notification from fault indicator 108-1 was false and that no high priority fault has occurred.

[0085] Further, if at block 408 it is determined that the priority level of the fault is not high, method 400 proceeds to block 420. At block 420, the display module displays the priority level of the fault, either a medium priority fault or a low priority fault, along with recommendations for resolving the fault.

[0086] This identification of false high priority faults prevents unnecessary panic among users who may become unduely stressed thinking their vehicle is in imminent danger, saves money by avoiding unnecessary emergency repairs and restorations, and allows resources such as service centres and roadside assistance to be used more efficiently, focusing on truly urgent faults rather than false alarms.

[0087] 5 illustrates a computing environment 500 for identifying faults in a vehicle, such as vehicle 104, in one embodiment of the present subject matter. Computing environment 500 includes a processing resource 502 communicatively coupled to a non-transitory computer-readable storage medium 504 (hereinafter referred to as non-transitory computer-readable medium 504) via a communication link 506. In one example, processing resource 502 may be a processor of system 102, which reads and executes computer-readable instructions from non-transitory computer-readable medium 504.

[0088] The non-transitory computer-readable medium 504 may be, for example, an internal memory device or an external memory device. In one embodiment, the communication link 506 may be a direct communication link, such as a read / write interface of any memory. In another embodiment, the communication link 506 may be an indirect communication link, such as a network interface. In such a case, the processing resource 502 may access the non-transitory computer-readable medium 504 through a network 512. The network 512 may be a single network or a combination of networks, and may use a variety of different communication protocols.

[0089] The processing resource 502 and the non-transitory computer-readable medium 504 may be communicatively coupled to a data source 508. The data source 508 may be used, for example, to store data corresponding to a defect database.

[0090] In one embodiment, non-transitory computer-readable medium 504 includes executable instructions 510 for scanning a fault indicator, such as fault indicator 108-1, displayed on an instrument cluster, such as instrument cluster 106, on the dashboard of vehicle 104. As previously described, scanning may involve the use of an image capture device in communication with system 102. The image capture device may be a camera operable in communication with system 102 to scan an image or video of fault indicator 108-1.

[0091] In one embodiment, the non-transitory computer-readable medium 504 includes executable instructions 510 for identifying a fault corresponding to the fault indicator 108-1 based on a preset fault database in the system 102. As previously described, the fault database includes information related to multiple fault indicators associated with the vehicle 104. To identify a fault associated with the scanned fault indicator 108-1, for example, the fault identification module 212 queries the preset fault database to match the scanned fault indicator 108-1 with information about the corresponding fault contained within the preset fault database.

[0092] In one embodiment, the non-transitory computer-readable medium 504 includes executable instructions 510 for identifying a priority level of a fault based on a preset fault database. As previously described, a priority level is predefined for each of a plurality of vehicle faults in the preset fault database, and the faults may be classified as high priority, medium priority, or low priority.

[0093] In one embodiment, the non-transitory computer-readable medium 504 includes executable instructions 510 for retrieving, from a pre-configured fault database, one or more instructions corresponding to the fault that the display module 216 should display on the screen of the system 102, for example. As previously described, the one or more instructions may vary depending on the priority level of the fault. For example, if the fault is identified as a high-priority fault, the recommendation module 214, e.g., via the interface 206, may cause the display module 216 to display on the screen of the system 102 instructions to immediately stop using the vehicle 104 and obtain professional assistance. For medium-priority faults, the recommendation module 214 may cause the display module 216 to display instructions stating that it is safe to continue driving for a while, but that the fault requires professional attention and advising the user to arrange for repairs as soon as possible. For low-priority faults, the recommendation module 214 may cause the display module 216 to display instructions that allow the user to resolve the fault themselves, or may inform the user that the fault does not affect the drivability of the vehicle 104 and therefore does not require immediate attention, allowing the user to address the issue at their convenience.

[0094] In one example, the instructions 510 may cause the processing resource 502 to record and store each fault detected by the fault identification module 212 as fault history data 226 in the memory 204 of the system 102. This fault history data 226 may include various information about the faults identified by the fault identification module 212, such as the date and time the fault was detected, the corrective action taken to resolve the fault, an error code associated with the fault, and conditions observed while the fault was occurring, such as the speed or engine temperature of the vehicle 104. Thereafter, when a user uses the system 102 to diagnose a fault indicated by a fault indicator, such as the fault indicator 108-1, the display module 216 may present historical data related to the identified fault from the fault history data 226 along with the fault associated with the fault indicator 108-1. This historical data may be displayed on a screen of the system 102 and may include a chronological list of each instance in which a fault was previously detected, along with the date of its occurrence. Additionally, a history of the corrective actions previously taken to resolve each instance of the fault may be displayed. This focus on history will allow users to understand not only the frequency and severity of failures, but also the effectiveness of past corrective actions, providing information that will help them make better decisions when troubleshooting and repairing, both now and in the future.

[0095] In one example, the instructions 510 may cause the processing resource 502 to communicate with a remote server, such as the central server 112, using, for example, the communications module 218. The communications module 218 may establish communication with the central server 112 to access the CAN data of the vehicle 104. After accessing the CAN data, the CAN data may be stored in the memory 204 of the system 102. The fault identification module 212 then uses the stored CAN data to verify whether the detected fault is indeed a high-priority fault. If the fault identification module 212 determines that the fault is not, in fact, a high-priority fault, the system 102 may display a warning. The warning may inform the user that the previously indicated high-priority fault is a false high-priority fault, preventing them from taking unnecessary action based on an assumed high-priority fault.

[0096] Thus, the present disclosure improves safety and maintenance efficiency by using augmented reality to accurately identify and prioritize vehicle faults. The present disclosure provides easy-to-use guidelines for troubleshooting, reduces false alarms by verifying faults against the vehicle's CAN data, and leverages historical data for predictive maintenance. The present subject matter simplifies the diagnostic process for drivers, potentially reducing reliance on professional repairs for minor issues, and supports remote diagnostics, providing a comprehensive solution for modern vehicle maintenance management.

Claims

A system for identifying vehicle malfunctions, comprising: at least one processor; a scanning module coupled to the at least one processor for scanning a fault indicator displayed on a dashboard of the vehicle; a fault identification module coupled to the at least one processor, identifying a fault corresponding to the fault indicator based on a fault database pre-configured in the system, the fault database including information related to a plurality of fault indicators associated with the vehicle; a defect identification module for identifying a priority level of the defect based on the defect database, the priority level being predefined for each of the plurality of defects; a recommendation module coupled to the at least one processor and configured to retrieve from the fault database one or more instructions to provide to a user corresponding to the fault, the one or more instructions varying depending on the priority level of the fault. 　 The system of claim 1 , wherein the fault identification module is further configured to store a history of each of the identified faults in the fault database. 　 a display module coupled to the at least one processor for displaying information about the history of the identified faults on a display unit of the system; The system of claim 2 , wherein the information includes dates of past occurrence of each of the identified malfunctions and corresponding corrective actions taken to resolve the identified malfunctions. 　 The system of claim 1 , wherein the priority level of each of the plurality of faults is predefined as at least one of a high priority fault, a medium priority fault, and a low priority fault. 　 The system of claim 1 , wherein the priority level of each of the plurality of faults is predefined as at least one of a high priority fault and a low priority fault. 　 a communications module coupled to the at least one processor for communicating with a remote server to access Controller Area Network (CAN) data for the vehicle and for storing the CAN data in a memory device coupled to the system; the fault identification module uses the stored CAN data to identify the fault as the high priority fault; 6. The system of claim 4, wherein a display module connected to the at least one processor displays a warning on a display unit of the system when the fault is determined to be a false high priority fault.

6. The system of claim 4 or 5, wherein a display module connected to the at least one processor sequentially displays the one or more instructions when the fault is identified as at least one of the low priority fault and the medium priority fault.

1. A method for identifying a malfunction in a vehicle, comprising: scanning a fault indicator displayed on a dashboard of the vehicle; identifying a fault corresponding to the fault indicator based on a fault database pre-configured in the system, the fault database including information related to a plurality of fault indicators associated with the vehicle; identifying a priority level of the defect based on the defect database, the priority level being predefined for each of the plurality of defects; retrieving from the fault database one or more indications corresponding to the fault to be displayed, the one or more indications varying depending on the priority level of the fault. 　 The method of claim 8 , including storing a history of each identified defect. 　 displaying information about the history of the identified defects; The method of claim 9 , wherein the information includes dates of past occurrences of the malfunction and corresponding corrective actions taken to resolve the malfunction.

9. The method of claim 8, wherein the priority level of each of the plurality of faults is predefined as at least one of a high priority fault, a medium priority fault, and a low priority fault. 　 The method of claim 8 , wherein the priority level of each of the plurality of faults is predefined as at least one of a high priority fault and a low priority fault. 　 communicating with a remote server to access Controller Area Network (CAN) data for the vehicle and storing the CAN data for the vehicle; using the stored CAN data to confirm that the fault is the high priority fault; and displaying a warning when the fault is determined to be a false high priority fault.

13. The method of claim 11 or 12, comprising sequentially displaying the one or more instructions when the fault is identified as at least one of the low priority fault and the medium priority fault. 　 A recording medium for recording a program including instructions executable by a processing resource, scanning the vehicle's dashboard for malfunction indicators; identifying a fault corresponding to the fault indicator based on a fault database pre-configured in the system, the fault database including information related to a plurality of fault indicators associated with the vehicle; determining a priority level of the defect based on the defect database, the priority level being predefined for each of the plurality of defects; and extracting from the fault database one or more instructions corresponding to the faults to be displayed, the one or more instructions varying depending on the priority level of the fault; A non-transitory computer-readable recording medium on which a program for executing the above is recorded.

16. The non-transitory computer-readable medium of claim 15, further comprising instructions executable by the processing resource for storing a history of each identified fault in the fault database.

16. The non-transitory computer-readable medium of claim 15, wherein the priority level of each of the plurality of faults is predefined as at least one of a high priority fault, a medium priority fault, and a low priority fault. 　 communicating with a remote server to access Controller Area Network (CAN) data for the vehicle and storing the CAN data for the vehicle; using the stored CAN data to confirm that the fault is the high priority fault; 18. The non-transitory computer-readable recording medium according to claim 17, wherein a program is recorded to execute a process of displaying a warning when the fault is determined to be an erroneously high-priority fault.

18. A non-transitory computer-readable recording medium as described in claim 17, having recorded thereon a program for executing a process of sequentially displaying the one or more instructions when the defect is identified as at least one of the low priority defect and the medium priority defect.

Images