TECHNICAL FIELD

[0001] The present subject matter relates generally to vehicle diagnostic systems and methods and more particularly, but not exclusively, to a cluster diagnostic system of the vehicle.

BACKGROUND

[0002] Generally, vehicle diagnostics involve remote execution of routines, or services on various electronic control units (ECUs) of the vehicle. In order to execute a routine, a request has to be sent to the vehicle ECU to which the ECU responds. Usually, the vehicle diagnostics is carried out with the help of commercially available diagnostic tools that uses diagnostic protocols containing standardized formats based on the services to be executed.

[0003] Vehicle diagnostics enable identifying and assessing the faults and anomalies in the ECUs, sensors and actuators of the vehicle, which otherwise would negatively affect the normal operation of a vehicle. Generally, vehicles may employ a wide range of techniques and tools in conductíng the diagnostics. These techniques and tools may range from cursory physical checks to more sophisticated techniques involving computer-based analysis. In order to ensure successful repair and smooth running of vehicles, effective diagnostic techniques are unavoidable.

[0004] With the advent of more and more electronic circuitry involved in current generation vehicles, the necessity to provide seamless vehicle diagnostics has increased. Creating proper communication channel with the vehicle ECUs largely helps in identifying and resolving anomalies and malfunctions. Virtually all modern road vehicles now come equipped with onboard diagnostics (OBD) ports, which work with the ECUs to continuously monitor various sensors and actuators and transmit faulty codes the instance any malfunction occurs.

BRIEF DESCRIPTION OF THE DRAWINGS

[0005] The detailed description is described with reference to the accompanying figures. In the figures, the left-most digit(s) of a reference number identifies the figure in which the reference number first appears. The same numbers are used throughout the drawings to reference like features and components.
[0006] FIG. 1 illustrates network implementation of a cluster diagnostic system for a two wheeled vehicle, in accordance with an embodiment of the present subject matter.

[0007] FIG. 2 illustrates a methodology of cluster based vehicle diagnosis for a two wheeled vehicle, in accordance with an embodiment of the present subject matter.

[0008] FIG. 3 illustrates a data flow between vehicle components of a two wheeled vehicle and a central diagnostic server through a cluster controller and at least one mobile device, in accordance with an embodiment of the present subject matter.

DETAILED DESCRIPTION

[0009] Conventionally, vehicle diagnostics in case of all vehicles including two, three and four wheeled vehicles involved serial communicatíon links having longer byte strings. Recent development of Controller Área Network (CAN)-based diagnostics enabled use of transport protocols that segments these longer byte strings into parts that can be transferred over the CAN bus, and which are capable of being reassembled at the receiver side. Similarly, UDS protocol also finds wide use in automotive diagnostic applications. The UDS describes the implementation of various diagnostic services that can be accessed through a protocol. UDS protocol uses messages of variable byte lengths. As like the CAN bus, the long UDS message is capable of being split into segments by the transport protocol before transferring over the network.

[00010] Diagnostic tools that are generally used for emission-related diagnosis includes On Board Diagnostics (OBD), which provides vehicles with self-diagnostic and reporting capability. The OBD allows for query status information for various vehicle sub-systems. Recent OBDs use a CAN communication port to provide real-time data and a standardized series of diagnostic trouble codes (DTCs), which identify and remedy malfunctions within the vehicle. For example, on board diagnostic tools are capable of enabling complete engine control in addition to monitoring and controlling parís of the chassis, and other vehicle components.

[00011] However, all such vehicle diagnostic tools rely either on mechanically controlling the functional components of the vehicle, or, by controlling the operation of different ECUs through computer. In either case, it requires specific attention from the servicing expert to detect the fault or anomalies in the ECUs or sensors by computationally manipulating the codes received. Such a vehicle diagnostic system, though helps in fixing the anomalies, is not dynamic and thus the fíxing provided is not always effective. Thus, there always exists a need for dynamically controlling and diagnosing the anomalies and faults of the functional components of the vehicle.

[00012] Recently, with the advent in telecommunication technology, communication devices like mobile phones found diverse applications. One such application has been controlling the functional components of the vehicle using a mobile device, which enabled dynamic updation of vehicle diagnostic data. It also enabled the rider of the vehicle to continuously monitor the different functional anomalies associated with the components of the vehicle. Further, controlling the vehicle diagnostics using mobile device also ensured that updates or fixes to the faulty codes received from the vehicle ECUs are transmitted wirelessly through the mobile devices.

[00013] Conventional vehicle diagnostic systems that uses mobile devices as diagnostic tool enable wireless diagnosis of the faults and anomalies in the ECUs, sensors and actuators of the vehicle. Typically, mobile devices used for vehicle diagnosis includes applications to handle data like UDS routine that is received from the vehicle ECUs. Further, these mobile devices are also capable of communícating the diagnostic data to and from the vehicle ECUs and in tum display the data in a form understandable by the user.

[00014] Though the existing mobile devices were capable of acting as a dynamic interface for vehicle diagnostic applications, the wireless vehicle diagnostics control systems generally utilizes the mobile devices for data processing and storage, which in tura renders the mobile device more complex thereby slowing the operational capability of the device. Moreover, the existing vehicle diagnostic tools capable of being controlled through mobile devices are mostly platfónn and/or operating system dependent making it difficult for establishing complete control over all functional components of the vehicle. [00015] In an implementation, the present subject matter is aimed at reducing device end. For example, the present subject matter provides a vehicle diagnostic system having limited controls including certain interface and display fionctionalities at the mobile device end. Further, the vehicle diagnostic system of the present stfbject matter includes a cluster controller provided in the vehicle for diagnosing afld controlling the anomalies associated with the vehicle ECUs and sensors.

[00016] In an embodiment, the present subject matter provides a vehicle diagnostic system that includes a cluster controller providing cluster controlled diagnosis and at least one mobile device connected to the cluster controller and capable of ílynamically rendering the transfer of data between the cluster controller and a central diagnosis server capable of transmitting and receiving data with the cluster controller. In an implementation, the at least one mobile device along with the cluster controller is capable of wirelessly diagnosing the faults and anomalies in one or more vehicle ECU, sensors, and actuators. [00017] In one embodiment, the at least one mobile device includes one or more UDS routineS that enable effective communication with the cluster controller of the vehicle. For example, the at least one mobile device is wirelessly connected to the cluster controller after authentication with the help of at least one unique ID code activated through, for example, near field connection (NFC) established by the mobile device.

[00018] In an implementation, the cluster controller and the at least one mobile device is capable of receiving fault messages from the one or more ECUs and the sensors in the form of diagnostic data, which includes for example, diagnostic trouble codes (DTC), sensor data, actuator data, and ECU revisión data pertaining to different controllers in the vehicle.

[00019] In one embodiment, the cluster controller of the present subject matter is capable of functioning as a diagnostic means for all functional components of the vehicle. The cluster controller is also capable of communicating with the one or more ECUs in the vehicle. For example, the cluster controller is capable of converting CAN data into a form that can be wirelessly communicated to and fro with the at least one mobile device.

[00020] Further, in an embodiment, the cluster controller of the present subject matter is capable of communicating appropriate fault rectifícation codes to the one or more ECUs thereby providing a troubleshooting solution for the functional components of the vehicle. In one embodiment, the cluster controller of the present subject matter is capable of communicating user information to the at least one mobile device's display unit. Similarly, the cluster controller is also capable of receiving user commands from the at least one mobile device for controlling certain aspects of the one or more ECUs in the vehicle.

[00021] In one embodiment, the at least one mobile device of the vehicle diagnostic system of the present subject matter is capable of including one or more memory management data relevant to UDS fault codes of the one or more ECUs. Further, the at least one mobile device of the present subject matter is also capable of wirelessly communicating with at least one central diagnosis server that includes repository of data relating to vehicle diagnosis. For example, the at least one mobile device includes one or more applications capable of calling web services routine of webpages specific to the vehicle along with its credentials for transferring diagnostic data to the central diagnostic server.
[00022] In an embodiment, the cluster controller of the present subject matter is capable of performing to and fro communication with the one or more ECUs of the vehicle through the CAN data bus and capable of converting the plurality of messages received from the one more ECUs into UDS format. In one example, the data are further converted into Bluetooth protocol before being transmitted transmitting to the at least one mobile device. Further, the cluster controller of the present subject matter is also capable of establishing connection with the at least one mobile device through the unique ID created for authenticating the at least one mobile device. On establishing the communication, the interfacing application allows the user to effectively communicate with the cluster controller of the vehicle.

[00023] In one implementation, the present subject matter provides a vehicle diagnostic system that involves establishing communication between the one or more ECUs of the vehicle with the cluster controller through wired channels, for example, CAN or Ethernet. In another embodiment, the communication between the one or more functional components of the vehicle and the cluster controller is established wirelessly, for example, Bluetooth, WLAN, or other wireless communication techniques known in the art. In one embodiment, the user inputs for different loads on the vehicle are also communicated through the cluster controller. Further, the at least one mobile device is capable of establishing a wireless communication with the cluster controller of the vehicle, for example, Bluetooth, WLAN, and GPRS, thereby ensuring efFective data transfer between the at least one mobile device and the cluster controller. In an implementation, the at least one mobile device is operated by the user and is capable of displaying the parameters and options that enable diagnosing the vehicle. The user interface at the mobile device also helps in achieving proper datábase coordination. [00024] In an implementation, the cluster controller has the capability to diagnose the data sent from the at least one mobile device, and for example, enable selection of appropriate controller for further actuatíon to effect ECU and/or sensor troubleshooting. Further, in one implementation, the vehicle diagnostic system of the present subject matter is capable of enabling connectivity with the central diagnostic server ensuring periodic updatíng of data from the cluster controller and the at least one mobile device authenticated to use for vehicle diagnosis. This ensures that the historie and archived data relating to vehicle diagnosis is flushed to the central diagnosis server and any such data are not unnecessarily retained either in the cluster controller or the mobile device. Moreover, the data repository created at the central diagnosis server act as a knowledge base enabling global fixing of similar faulty codes and anomalies observed in other vehicles. The data repository is also capable of being used for fiírther analysis and data representation.

[00025] In one implementation, the vehicle diagnostic system of the present subject matter enable periodic monitoring of the vehicle data by the one or more diagnostic means of the cluster controller so that any malfiínction or alerts received from the one or more fimctional components of the vehicle are first provided on a cluster display of the cluster controller. For example, the user is capable of receiving detailed alerts and details of malfunctions as soon as the authenticated mobile device is connected to the cluster controller. Further, in one implementation, the cluster controller is capable of sending all the relevant data and self-troubleshooting methodologies to the at least one mobile device. In another implementation, the at least one mobile device is capable of maintaining a list of all such self-troubleshooting methodologies. In an implementation, any vehicle diagnostic data from the cluster controller and/or the at least one mobile device is flushed for central storage to the central diagnostic server with appropriate authentication and permission received from the user. [00026] The present subject matter provides the vehicle diagnostic system that has several advantages. For example, the cluster controller of the present subject matter act as a vehicle diagnostic tool enabling control of diagnostic capabilities thereby ensuring the mobile device is not loaded with unnecessary diagnostic data. Further, the cluster controller is provided with a display feature enabling indication of malfunction alerts of the one or more functional components of the vehicle. For example, the cluster controller of the present subject matter is capable of indicatíng to the user whether the anomaly or malfunction is capable of being fixed by downloading an appropriate patch from the central server through the mobile device or requires special attention, which can be provided at a service station.

[00027] Further, the cluster controller of the present subject matter is capable of directly communicating with the central diagnosis server that acts a repository of many such diagnostic messages and the troubleshooting methods. The mobile device of the present subject matter is capable of communicating with the central diagnosis server to fix diagnostic issues on certain conditions. In one implementation, the present subject matter advantageously provides periodically flushing of unnecessary data from the cluster controller and/or the mobile device to the central diagnosis server. The central diagnosis server identifies common diagnostic issues based on the individual diagnostic data logged in its repository and enable global fixing of the issues by communicating with individual mobile device and/or cluster controller after acquiring necessary permission from the respective users.

[00028] These and other advantages of the present subject matter would be described in greater detail in conjunction with the figures in the following description.

[00029] Figure 1 illustrates a network environment 100 implementing a cluster based vehicle diagnostic system 102 hereinafter called as cluster diagnostic system 102, configured to process diagnostics of anomalies and faulty codes of one or more functional components 140 included in a vehicle, for example, a two-wheeled vehicle 138. In one embodiment, the one or more functional components 140 include one or more ECUs 140-1, one or more sensors 140-2, and one or more actuators 140-3, according to an embodiment of the present subject matter. The cluster diagnostic system 102 may be configured to diagnose and control the one or more functional components 140 of the vehicle 138.

[00030] In an implementation, the cluster diagnostic system 102 is implemented in a cluster controller 103 located in an instrument cluster (not shown) of the vehicle 138. In one implementation, the cluster controller 103 is communicatively coupled to the one or more functional components 140 through a network 134 for effecting to and fro transmission of data between the one or more functional components 140 including one or more ECUs 140-1 and the cluster controller 103. In one embodiment, the network 134 is a wired network, for example, CAN, Ethernet etc. In another embodiment, the network 134 is a wireless network, for example, WLAN, Bluetooth etc. Further, it will be understood that users may access the cluster diagnostic system 102 through one or more client devices 142-1, 2,..., N (collectively referred to as client devices 104).. Examples of the client devices 104 include, but are not limited to, a mobile device, a personal digital assistant, a handheld device etc. As shown in the figure, such client devices 142 are communicatively coupled to the cluster diagnostic system 102 through a network 136 for facilitating the cluster diagnostic system 102 to receive one or more data from the users, using, for example, a mobile device 142-1.

[00031] The network 136 may be a wireless network, wired network or a combination thereof. The network 136 can be implemented as one of the different types of networks, such as intranet, local área network (LAN), wide área network (WAN), the internet, and such. The network 136 may either be a dedicated network or a shared network, which represents an association of the different types of networks that use a variety of protocols, for example, Hypertext Transfer Protocol (HTTP), Transmission Control Protocol/Internet Protocol (TCP/IP), Wireless Application Protocol (WAP), etc., to communicate with each other. Further, the network 136 may include a variety of network devices, including routers, bridges, servers, computing devices, storage devices, etc.

[00032] In one implementation, the cluster diagnostic system 102 includes a processor(s) 104, interface(s) 106, and a memory 108 coupled to the processor(s) 104. The processor(s) 104 may be implemented as one or more microprocessors, microcomputers, microcontroUers, digital signal processors, central processing units, state machines, logic circuitries, and/or any devices that manipúlate signáis based on operational instructions. Among other capabilities, the processor(s) 104 are configured to fetch and execute computer-readable instructions stored in the memory 108.

[00033] The interface(s) 106 may include a variety of software and hardware interfaces, for example, a web interface, a graphical user interface, etc., allowing the cluster diagnostic system 102 to interact with the mobile device(s) 142-1,142-2. Further, the interface(s) 106 may enable the cluster diagnostic system 102 to communicate with other computing devices, such as web servers and external data servers, for example, a central diagnosis server 144. The interface(s) 106 can facilítate múltiple Communications within a wide variety of networks and protocol types, including wired networks, for example LAN, cable, etc., and wireless networks such as WLAN, ceJlular, or satellite. The interface(s) 106 may include one or more ports for connecting a number of devices to each other or to another server. In an implementation, the interface(s) 106 also includes a display device (not shown).

[00034] The memory 108 can include any computer-readable médium known in the art including, for example, volatile memory (e.g., RAM), and/or non-volatile memory (e.g., EPROM, flash memory, etc.). In one embodiment, the memory 108 includes module(s) 110 and data 112. The modules 110 further include an analog/digital input signal-conditioning module 114, a diagnostic module 116, a controller selection module 118, a calibration module 120, and other module(s) 122. It will be appreciated that such modules may be represented as a single module or a combination of difíerent modules. Additionally, the memory 110 further includes data 112 that serves, amongst other things, as a repository for storing data fetched processed, received and generated by one or more of the modules 110. The data 112 includes, for example, sensor data 124, ECU(s) data 126, diagnostic trouble code (DTC) 128, UDS routines 130, and other data 132. In one embodiment, the stored data 112 can be in the form of data structures. Additionally, the aforementioned data can be organized using data models, such as relational or hierarchical data models.

[00035] In operation, the cluster diagnostic system 102 receives anomaly data from the one or more functional components 140 of the two-wheeled vehicle 138 through the network 134 established between the one or more functional components 140 and the cluster diagnostic system 102. In an implementation, the analog/digital signal conditioning module 114 of the cluster diagnostic system 102 is capable of conditioning the data received from the one or more functional components 140, for example, sensor data 124, ECU data 126, and DTC 128 to ensure that all data are in one uniform format. For example, under many circumstances, the sensors 140-2 may transmit the sensor data 124 that is analog in nature, while the faulty codes received from one or more ECUs 140-1, for example, ECU data 126 is digital in nature. Under those circumstances, the analog/digital input signal conditioning module 114 ensures that both the data are conditioned before transmitting to the diagnostic module 116.

[00036] In an implementation the diagnostic module 116 of the present subject matter is capable of receiving diagnostic trouble codes 128 and other diagnosis related data 124, 126 from the one or more functional components 140 of the two-wheeled vehicle 138. In one embodiment, the diagnostic module 116 receives conditioned data from the analog/digital input signal conditioning module 114. The diagnostic module 116 acts on the received data and enable fixing of anomalies and faulty codes. For example, the diagnostic module 116 is capable of performing one or more of the following functions. For example, the diagnostic module 116 reads the diagnostic fault codes and trouble codes 128 received from sensors 140-2 and critical ECU functions 140-1. Further, the diagnostic module 116 enables in flashing of the cluster controller 103. For example, in one implementation, the diagnostic module 116 also enables ofíline calibration of critical ECU parameters 140-1. Further, the diagnostic module 116 enables troubleshooting of sensors 140-2 and actuators 140-3 of the vehicle 138. [00037] In one implementation, the diagnostic trouble codes 128 are also called as faulty messages received from one or more ECUs 140-1 of the vehicle 138. The diagnostic module 116, in an implementation, is capable of reading the fault codes 128 received from the ECU 140-1 and display them in the display device (not shown) provided in the cluster controller 103 of the vehicle 138. In another embodiment, the diagnostic module 116 communicates with the at least one mobile device 142-1 and displays the fault codes 128 in the display of the mobile device 142-1. In an implementation, the diagnostic module 116 is capable of retaining the DTC 128 in a dedicated memory of the cluster controller 103 along with the description of each of the DTC 128. In another implementation, the diagnostic module 116 is capable of flushing the DTCs 128 and the respective description to the at least one mobile device 142-1, or the central diagnosis server 144, or both. Further, in one implementation, the diagnostic module 116 is capable of displaying the description associated with one or more DTC 128 through the display device of the cluster controller 103, or the mobile device 142-1, or both. In another implementation, the diagnosis module 116 is capable of clearing the DTC 128 data from the one or more ECU 140-1 after completion of the diagnosis.

[00038] Further, in one implementation, the diagnostic module 116 is capable of flashing of one or more data 112. For example, the diagnostic module 116 has the capability of configuring one or more ECU parameters for flashing, such as storing the bin file (.mod) that has to be flashed in the memory of the mobile device 142-1. Other examples of flashing of data includes, reading the received data 112 and sending the data 112 over Bluetooth to the one or more ECU 140-1, generating flash commands and responses between the mobile device 142-1 and the one or more ECU 140-1. In an implementation, the diagnostic module 116 is also responsible for continuously updating the user interface of the display device in the cluster controller 103 or the display of the mobile device 142-1 about the status of flashing.

[00039] In an implementation, the diagnostic module 116 enables data acquisition both from the one or more functional components 140 of the vehicle 138 and from the at least one mobile device 142-1, and/or the central diagnosis server 144. For example, the data acquisition capabilities of the diagnostic module 116 includes but not limited to measurement of the defined variables, configuration of the variables, configuring the unit of measurement, configuring appropriate setungs for each functional components 140 that is to be diagnosed, displaying the measured variables, measuring continuously at predefined intervals etc. Further, the data acquisition capabilities of the diagnostic module 116 also includes updating the user interface of the display device of the cluster controller 103 or the mobile device 142-1 as and when there is a status change in the diagnostic data of the one or more functional components 140. The diagnostic module 116 also enables recording and plotting of graphs for the diagnosed data. [00040] In an implementation, the calibration module 120 of the cluster diagnostic system 102 enables calibration of critical ECU parameters. Further, in an implementation, the calibration module 120 is capable of carrying out the calibration of the ECU parameters in an offline mode of the cluster controller 103. In an implementation, the calibration module 120 ensures that the user inputs for the ECU parameters selected to be configured are received. Further, the calibration module 120 enables save/update of the ECU parameters in the memory 108. The calibration module 120 also configures the calibrated ECU parameters in the respective ECUs 140-1.

[00041] Further, in an implementation, the calibration module 120 controls enabling or disabling of one or more applications in the mobile device 142-1 depending upon different types of diagnostic requirements. For example, the calibration module 120 is capable of controlling the access of data being displayed depending on users and/or mobile devices 142-1. For ínstance, user ñame and password enabled with one or more levéis of access can be provided by the calibration module 120. Further, the user interface displayed in the mobile device 142-1 is controlled by the calibration module 120.

[00042] In one implementation, the controller selection module 118 enables selection of appropriate controllers to send the fixing codes, for example, fixing codes received from the central diagnosis server 144. The one or more controllers that are selected on the basis of the fixing codes by the controller selection module 118 includes but not limited to power train controller, motor controller, battery controller, magneto controller, body module controller, electronic brake controller, vehicle theft determent controller, transmission controller, remote start enable/disable controller, backlight dimming controller etc. [00043] Furthermore, the other modules 122 of the cluster diagnostic system 102 may include a data transferring module that enables the cluster controller 103 and the mobile device 142-1 to transfer data securely to the central diagnosis server 144. The transferred vehicle diagnostic data 112 is stored in the central diagnosis server 144 for further analysis.

[00044] Fig. 2 illustrates a methodology of cluster based vehicle diagnosis for a two wheeled vehicle, in accordance with an embodiment of the present subject matter. The exemplary method 200 may be described in the general context of computer executable instructions. Generally, computer executable instructions can include routines, programs, objects, components, data structures, procedures, modules, ftmctions, and the like that perform particular functions or implement particular abstract data types.

[00045] The order in which the method is described is not intended to be construed as a limitation, and any number of the described method blocks can be combined in any order to implement the method, or altérnate methods. Additionally, individual blocks may be deleted from the method without departing from the spirit and scope of the subject matter described herein. Furthermore, the method can be implemented in any suitable hardware, software, firmware, or combination thereof. The method described herein is with reference to the cluster diagnostic system 102 and in the context of diagnosing anomalies and faults in the one or more functional components 140 of the two-wheeled vehicle 138. Furthermore, the method can be implemented in other similar systems albeit with a few variations as will be best understood by a pef son skilled in the art. [00046] At block 202, the cluster controller 103 receives diagnostic fault codes and trouble codes 128 from the one or more ECUs 140-1 and the one or more sensors 140-2 of the two-wheeled vehicle 138. In $n implementation, the received diagnostic fault codes 128 are conditioned by the analog/digital input signal conditioning module 114 of the cluster controller 103. At block 204, a determination is made to find out whether the cluster controller 103 and more particularly, the diagnostic module 116 of the cluster controller 103 at its current state is capable of diagnosing the received trouble codes 128. If the answer to the determination is 'yes', then the diagnostic niodule 116 communicates in affirmative to the at least one mobile device 142-1 stating that the diagnostic module 116 in its current state is capable of diagnosing the faulty or trouble codes 128 received from the one or more ECUs 140-1 or sensors 140-2, at block 208. [00047] At block 210, after affirmatively communicating to the at least one mobile device 142-1, the diagnostic module 116 of the cluster controller 103 troubleshoots the faulty code 128 based on the diagnostic capabilities that is available at the cluster controller 103.

[00048] At block 206, if the answer to the determination made in block 204 is 'no\ then the diagnostic module 116 communicates to the central diagnosing server 144 directly or through the at least one mobile device 142-1 about the inability of the cluster controller 103 to diagnose the faulty code 128 at its current state. At block 212, based on the input message received from the diagnostic module 116 of the cluster controller 103, the mobile device 142-1 determines whether the fixing codes are available, if not, receive the fixing codes from the central diagnosing server 144 and enable the cluster controller 103 to diagnose the faulty code 128.

[00049] At block 214, the controller selectiofl module 118 of the cluster controller 103 selects the appropriate controller for troubleshooting. At block 216, the calibration module 120 of the cluster controller 103 evaluates the controller to determine whether there exists a need for calibration based on the result of the troubleshooting that is recently performed by the diagnostic module 116. Based on the evaluation, at block 218, the calibration module 120 calibrates the appropriate controller by receiving corresponding ECU parameters from the central diagnosing server 144, or, from the mobile device 142-1, if available in the mobile device 142-1.

[00050] At block 220, the other module 122, for example, a data transmission module, enables identifying and transferring the data that has to be flushed out to the central server 144 from the cluster controller 103 and/or the mobile device 142-1. This enables global fíxing solution for faulty codes 128, which was currently fixed for a particular vehicle 138.

[00051] Although implementations of diagnosing anomalies and faulty codes received from the one or more functional components of the two-wheeled vehicle have been described in language specific to structural features and/or methods, it is to be understood that the present subject matter is not necessarily limited to the specific features or methods described. Rather, the specific features and methods are disclosed as implementations for diagnosing faulty and troubleshooting codes of the one or more ECUs, sensors, and actuators.

[00052] FIG. 3 illustrates a data flow between vehicle components of a two wheeled vehicle and a central diagnostic server through a cluster controller and at least one mobile device, in accordance with an embodiment of the present subject matter. The cluster controller 103 manages the diagnosis and controls the data transferred between the plurality of entities, say for example, vehicle ECUs 140-1, sensors 140-2, actuators 140-3, and mobile devices 142, and central diagnosing server 144.

[00053] In one implementation, a faulty code or troubleshooting code 128 ís received from the vehicle ECUs 140-1, and sensors 140-2 by the diagnostic module 116 of the cluster controller 103 (steps 302, 304). The diagnostic module 116 in turn processes the received diagnostic data from the ECUs 140-1, and the sensors 140-2 and displays the description of the faulty codes 128 in the display device of the cluster controller 103 and/or the mobile device 142. In addition, the diagnostic module 116 also determines if it do not contain the fíxing codes for diagnosing the faulty codes 128 received from the functional components 140 and communicates the same to the mobile device 142 (step 306). [00054] Upon receiving the request from the diagnostic module 116 at step 306, the mobile device 142 delivers the required fixing codes to the diagnostic module 11, and based on the input data received from the mobile device 142, the diagnostic module 116 processes the faulty codes 128 and sends the corresponding fixing codes (step 308).

[00055] The controller module 118 identifies the appropriate controller that has to be selected for troubleshooting the faulty codes based on the fixing codes transferred at step 308 (step 310). The selected controller at step 310, is evaluated to determine the need for calibration based on the troubleshooting, and the need for calibration is communicated to the calibration module 120 by the controllers (step 312).

[00056] The central diagnosing server 144 determines the appropriate ECU parameters for calibrating the actuators 140-3 and sends to the calibration module 120 through the mobile device 142 (step 314). Based on the parameters received from the central server 144, the calibration module 120 calibrates the selected controller/actuator (step 316).

[00057] After successful calibration by the calibration module 120, the diagnostic module 116 identifies the diagnostic data for the diagnosis carried out and transfers the identified data to the central server 144 from the memory 108 of the cluster controller 103 (step 318). Similarly, the diagnostic module 116 enables the mobile device 142 to identify the diagnostic data for the carried out diagnosis and enables transferring of the identified data to the central server 144 (step 320). [00058] Although implementations for the present subject matter have been described in language specific to structural features and/or methods, it is to be understood that the present subject matter is not necessarily limited to the specific features or methods described. Rather, the specific features and methods are disclosed as exemplary implementations of the present invention.

IAVe claim:

1. A vehicle diagnostic system (102) for diagnosing one or more functional components (140) of a two-wheeled vehicle (138), said vehicle diagnostic system (102)comprising: a processor (104); and a memory (106) coupled to the processor (104), the memory (106) comprising:
a diagnostic module (116) confígured to receive diagnostic trouble codes (128) and other diagnosis related data (124, 126) from the one or more functional components (140) of the two-wheeled vehicle (138) and diagnosing the received diagnostic trouble codes (128) and the other diagnosis related data (124,126); a controller module (VIS) confígured to determine, at least one controller capable of troubleshooting the one or more diagnosed trouble codes (128), based at least on a corresponding set of one or more fixiflg codes received from a central diagnosis server (144); and a calibration module (120) confígured to evalúate the at least one controller and determine whether there exists a need for calibration based at least on the result of the troubleshooting performed by the diagnostic module (116), said calibration module (120) capable of calibrating the at least one controller based on one or more parameters received from the central diagnosis server (144).

2. The vehicle diagnostic system (102) as cteimed in claim 1, wherein said system (102) further includes an analog/digjtal signal-conditioning module (114) confígured to condition the data received from the one or more functional components (140).

3. The vehicle diagnostic system (102) as claimed in claim 1, wherein the one or more functional components (140) comprises one or more ECU(s), one or more sensor(s), and one or more actuator(s).

4. A two-wheeled vehicle (138) comprising:
a cluster controller (103) located in an instrument cluster of the vehicle (138), said cluster controller (103) communicatively coupled to one or more functional components (140) through a network (134) for effecting to and fro transmission of data between the one or more functional components (140) and one or more client devices (142), and a central diagnosis server (144); wherein said cluster controller (103) includes:
a diagnostic module (116) configured to receive diagnostic trouble codes (128) and other diagnosis related data (124, 126) from the one or more functional components (140) of the two-wheeled vehicle (138) and diagnosing the received diagnostic trouble codes (128) and the other diagnosis related data (124, 126); a controller module (118) configured to determine at least one controller capable of troubleshooting the one or more diagnosed trouble codes (128), based at least on a corresponding set of one or more fixing codes received from a central diagnosis server (144); and a calibration module (120) configured to evalúate the at least one controller and determine whether there exists a need for calibration based at least on the result of the troubleshooting performed by the diagnostic module (116), said calibration module (120) capable of calibrating the at least one controller based on one or more parameters received from the central diagnosis server (144).

5. The two-wheeled vehicle (138) as claimed in claim 4, wherein the one or more client devices (142) includes at least one mobile device (142-1), said at least one mobile device (142-1) communicatively coupled to the cluster controller (103) and capable of dynamically rendering the transfer of data between the cluster controller (103) and the central diagnosis server (144).

6. The two-wheeled vehicle (138) as claimed in claim 5, wherein the at least one mobile device (142-1) includes one or more UDS routines enabling to and fro communication with the cluster controller (103).

7. The two-wheeled vehicle (138) as claimed in claim 4, wherein the cluster controller (103) comprises a display for dynamically indicating malfunction alerts of the one or more functional components (140) of the vehicle (138) to a rider.

8. A method (200) for diagnosing one or more functional components (140) of a two-wheeled vehicle (138), said method (200) comprising: receiving, by a diagnostic module (116) of a cluster controller (103), diagnostic trouble codes (128) and other diagnosis related data (124, 126) from the one or more functional components (140) of the two-wheeled vehicle (138); selecting, by a controller module (118) of the cluster controller (103), an appropriate controller capable of troubleshooting; determining, by the controller module (118), whether the selected controller is capable of diagnosing the received diagnostic trouble codes (128) and the other diagnosis related data (124, 126), if yes, cornmunicating to at least one mobile device (142-1) and troubleshooting based on available diagnostic tools, if no, communicating to central diagnosis server (144), and diagnosing based on inputs received from the central diagnosis server (144); and evaluating, by a calibration module (120) of the cluster controller (103), the controller to determine the need for calibration based on troubleshooting, and calibrating the at least one controller based on one or more parameters received from the central diagnosis server (144).

9. The method (200) as claimed in claim 8, wherein the method further comprises: identifying and transferring, by a data transmission module (122) of the cluster controller (103), the data to be flushed out to the central diagnosis server (144) from the cluster controller (103) and/or the at least one mobile device (142-1) for enabling global fixing of the one or more diagnostic trouble codes (128).

10. The method (200) as claimed in claim 8, wherein the method comprises establishing communication between the at least one mobile device (142-1) and the cluster controller (103), based at least on authentication by means of at least one unique ID code activated through a near fíeld connection (NFC) established between the at least one mobile device (142-1) and the cluster controller (103).