Patent Description:
Generally, machines, such as construction machines, require periodic maintenance/servicing to function in an optimal manner. Several techniques are used to generate an aftermarket servicing lead for such machines. Typically, a number of monitoring elements are considered for generating the aftermarket servicing lead for minimizing a downtime of the machine. Such monitoring elements may include, for example, operating hours of the machines, time elapsed since a previous maintenance schedule, and the like.

However, generation of the aftermarket servicing lead based on such monitoring elements may lack precision, transparency, and accuracy, which may affect aftermarket sales operations. Further, the aftermarket servicing lead may not provide a detailed information and insight of a condition of the machine. Thus, the aftermarket servicing lead generated based on such monitoring elements may lead to undesirable increase in a repair downtime of the machine and/or cost of maintenance and may also reduce productivity. Further, in some cases, lack of relevant information presented by the aftermarket servicing lead may cause rejection of such aftermarket servicing leads at customer end. Furthermore, such aftermarket servicing leads do not provide a root cause of failure in machine components as they do not provide real-time insights related to condition-based challenges.

<CIT>, hereinafter referred to as '<NUM> patent, describes a system, method, and apparatus for retrieving trouble codes from a motor vehicle and retrieving only relevant diagnostic information relative to the returned codes from one or more remote diagnostic libraries. An electronic diagnostic library contains generalized diagnostic vehicle information tagged with trouble code identification IDs at a first location, and a diagnostic tool at a second location requests only relevant diagnostic information from the electronic library that is tagged with trouble code identification IDs corresponding to the retrieved trouble codes. The diagnostic tool receives the specific diagnostic vehicle information at the first location and may store the specific vehicle information locally prior to displaying an index to the information to a repair technician. Further, the second specific diagnostic information is different than the first specific diagnostic information. However, the '<NUM> patent does not describe usage of real-time conditions or faults associated with a machine or the components of the machine for generation of a servicing/maintenance schedule. Further, the '<NUM> patent does not describe and upfront presentation of the real-time machine conditions or faults.

<CIT> discloses systems and methods for an online predictive diagnostic and prognostic maintenance system. The systems and methods may be configured for use with networked gaming machines. The systems and methods may operate in real time and may detect and analyze data representing various indicators of machine performance or a current or future decrease in machine performance. The data may represent or be used to predict machine performance and risk of failure and to identify necessary or recommended repair, maintenance or other performance issues. In another embodiment systems and methods are disclosed for automated analysis of data regarding machine operation and generation of rules related to predicting the future performance, repair and maintenance needs of machines.

In one aspect of the present disclosure, a system according to claim <NUM> is provided.

In another aspect of the present disclosure, a method according to claim <NUM> is provided.

Other features and aspects of this disclosure will be apparent from the following description and the accompanying drawings.

Wherever possible, the same reference numbers will be used throughout the drawings to refer to the same or the like parts. Wherever possible, corresponding or similar reference numbers will be used throughout the drawings to refer to the same or corresponding parts.

<FIG> illustrates a block diagram of a system <NUM> for generating a servicing schedule for a machine <NUM>. In an example, the machine <NUM> may include any type of an on-highway machine or an off-highway machine. For example, the machine <NUM> may include an excavator, a wheel loader, a haul truck, a paving machine, and the like. The machine <NUM> includes an Electronic Control Module (ECM) <NUM> to control a number of machine operations. For example, the ECM <NUM> may be used to control operations related to an engine of the machine <NUM> or a hydraulic system of the machine <NUM>, without any limitations. The ECM <NUM> may include a memory device (not shown) to store and collect data from a number of sensors associated with the machine <NUM>.

Further, the term "servicing schedule" as used herein may be defined as a periodic servicing event of the machine <NUM> that may be generated to service, repair, or replace certain components <NUM> of the machine <NUM>. The servicing schedule may include an approach towards machine management and may be performed either periodically or as per operating conditions of the machine <NUM> from a time period when the machine <NUM> is purchased until an end of a useful life of the machine <NUM>. The servicing schedule may be generated to perform a regular systematic inspection, modification, and replacement of the components <NUM> of the machine <NUM> as well as for performance testing and analysis. The components <NUM> of the machine <NUM> may be hereinafter interchangeably referred to as "machine components <NUM>", without any limitations. The servicing schedule may assist in identification of potential causes of failures of the machine components <NUM>. The failure may include a sudden failure, an intermittent failure, a gradual failure, thermally induced failure, mechanically induced failure, erratic failure, and the like. The servicing schedule may aim to prevent failures in the machine components <NUM> by predicting a root cause of such failures.

In an example, the servicing schedule for the machine <NUM> may be a proactive measure to prevent unplanned repair downtime of the machine <NUM>. In another example, the servicing schedule may highlight a fault associated with one or several components <NUM> of the machine <NUM>. Further, regular servicing may help to predict failure of machine components <NUM>. The servicing schedule may also help an owner to detect and troubleshoot faults in the machine components <NUM> before any failure or breakdown. During the servicing of the machine <NUM>, a number of corrective actions may be taken to ensure reliability and performance of the machine <NUM>.

Further, the system <NUM> includes a controller <NUM>. The controller <NUM> may be communicably coupled with the ECM <NUM> of the machine <NUM>. The ECM <NUM> and the system <NUM> may be communicably coupled via a wireless transmission system. Such an arrangement allows the system <NUM> to retrieve real time data associated with the machine <NUM> from the ECM <NUM> of the machine <NUM>. Although the single machine <NUM> is illustrated herein, the controller <NUM> may be in communication with ECMs of a number of different machines, without any limitations. The controller <NUM> and the ECM <NUM> may be embodied as a single microprocessor or multiple microprocessors. Numerous commercially available microprocessors may be configured to perform the functions of the controller <NUM> and the ECM <NUM>. It should be appreciated that the controller <NUM> and the ECM <NUM> may embody a microprocessor capable of controlling numerous functions. A person of ordinary skill in the art will appreciate that the controller <NUM> and the ECM <NUM> may additionally include other components and may also perform other functions not described herein.

Further, the controller <NUM> receives a servicing information pertaining to the machine <NUM> for generating the servicing schedule. Specifically, the controller <NUM> receives an input signal pertaining to the servicing information for the machine <NUM>. In some examples, the servicing information is used to detect and analyze a condition of the machine <NUM>. The servicing information provides information related to the components <NUM> of the machine <NUM>, and more particularly, faults prevailing in the components <NUM>. The servicing information includes an aftermarket servicing lead, a fault code from the machine <NUM>, a fluid test result for the machine <NUM>, and/or an inspection data for the machine <NUM>.

Further, the system <NUM> may include an input device (not shown) to feed the servicing information into the system <NUM>. The system <NUM> may also include a database <NUM> to store some servicing information therein. It should be noted that the controller <NUM> may receive the servicing information from a number of external sources. For example, the controller <NUM> may receive the servicing information from various service providers, customers/end users/owners of the machine <NUM>, contractors, and the like. Further, the controller <NUM> may be communicably coupled with various external sources for obtaining the servicing information via a cloud computing system, a mobile application, wireless transmission systems, and the like. Moreover, the controller <NUM> analyzes the input signal for generating a service report that contains the servicing information. The service report is used for generating the servicing schedule for the machine <NUM>. In one example, the controller <NUM> may generate the servicing schedule using all factors, i.e., the aftermarket servicing lead, the fault code from the machine <NUM>, the fluid test result for the machine <NUM>, and/or the inspection data for the machine <NUM>. In another example, a combination of the aftermarket servicing lead and one or all of the fault code, the fluid test result, and/or the inspection data may be used to generate the servicing schedule, without any limitations.

The service report is presented on a user interface <NUM>. Specifically, the system <NUM> includes the user interface <NUM> for receiving the service report from the controller <NUM>. The user interface <NUM> is communicably coupled with the controller <NUM>. The user interface <NUM> of the system <NUM> allows interactions between a servicing personnel and the system <NUM>. This interaction allows the servicing personnel to take effective and necessary actions on the machine <NUM> based on the generated service report. The user interface <NUM> may include a command line interface, a menu-driven interface, a graphical user interface, a touchscreen, and the like. In some examples, the user interface <NUM> may include a handheld or portable device that may be present with the servicing personnel. The user interface <NUM> may include a mobile phone, a tablet, a laptop, and the like. Alternatively, the user interface <NUM> may include a laptop or a display device that is present at a location where the servicing personnel is present. The service report may include a text report, an audio report, a video report, and the like.

In an example, the term "aftermarket servicing lead" as used herein in relation to the servicing information may relate to a servicing schedule that may include a series of programs scheduled for repair and maintenance of the machine <NUM>. The various programs may be customized to meet specific requirements of the machine <NUM>. The aftermarket servicing lead may include a number of condition monitoring elements. The condition monitoring elements may include management of all maintenance aspects such as performance monitoring, preventive maintenance, general repairs, component overhauls that may be required to assure optimal equipment performance, and the like.

In an example, the aftermarket servicing lead may be generated by the controller <NUM>. In another example, the aftermarket servicing lead may be received by the controller <NUM> from an external source, without any limitations. For example, the aftermarket servicing lead may be generated by the ECM <NUM> of the machine <NUM> and the controller <NUM> may retrieve the data from the ECM <NUM> of the machine <NUM>, the memory device associated with the ECM <NUM>, or the database <NUM> of the system <NUM>. Further, the aftermarket servicing lead is generated based on an operating hours of the machine <NUM>, a historical repair data of the components <NUM> of the machine <NUM>, a predicted lifespan of the components <NUM> of the machine <NUM>, and/or a manufacturing date of the machine <NUM>. The operating hours of the machine <NUM> are vital in repair and service of the machine <NUM> as the machine <NUM> with higher number of operating hours may have to be examined frequently. In some examples, the system <NUM> may be programmed to generate the aftermarket servicing lead if the operating hours of the machine <NUM> exceeds beyond a predefined number of hours.

The historical repair data of the machine components <NUM> may provide an insight of the machine components <NUM> that have been recently serviced, replaced, and the like. This information may be important when some machine components <NUM> have a requirement of servicing or replacement after a predefined amount of time. Further, the predicted lifespan of the components <NUM> of the machine <NUM> and the manufacturing date of the machine <NUM> provide an average time frame for which the machine components <NUM> are expected to work effectively and efficiently. Moreover, the aftermarket servicing lead may be generated using maintenance and repair agreements, site inspections, field services, in-shop services, asset details, and the like. It should be noted that the system <NUM> may also consider other factors apart from those mentioned herein for generating the aftermarket servicing lead.

Further, the controller <NUM> also receives a fault diagnosis data associated with the aftermarket servicing lead. The fault diagnosis data includes information pertaining to faults in the components <NUM> of the machine <NUM> that are associated with the aftermarket servicing lead. The fault may be associated with the components <NUM> such as the engine, the transmission, the hydraulic system, and the like. The fault diagnosis data for a particular machine component <NUM> may be generated based on a sales date of the machine <NUM>, an application of the machine components <NUM>, operating hours of a particular component <NUM>, historical failure data associated with the machine components <NUM>, historical repair data associated with the machine components <NUM>, historical inspection data associated with the machine components <NUM>, historical fluid test results associated with the machine components <NUM>, and the like.

Further, the fault code is received from the machine <NUM> and is representative of a faulty operation of the components <NUM> of the machine <NUM>. The fault code may be generated based on real time machine events. In an example, the fault code may include input signals transmitted to the controller <NUM> by the ECM <NUM>. The ECM <NUM> may continuously receive inputs corresponding to faults associated with the machine components <NUM>. For example, the ECM <NUM> may include an On-Board Diagnostics (OBD) system that may receive data from sensors of the machine <NUM>. The sensors may include a mass airflow sensor, an engine speed sensor, an oxygen sensor, a spark knock sensor, a coolant sensor, a manifold absolute pressure sensor, a fuel temperature sensor, a voltage sensor, and the like, without limiting the scope of the present disclosure. Any undesired output from the sensor may be indicative of a fault associated with a particular component <NUM> with which the sensor is associated.

Further, the fluid test result is generated based on analysis of fluid samples associated with the components <NUM> of the machine <NUM>. The fluid sample may include an oil sample, a coolant sample, a fuel sample, and the like. Further, a fluid test of various fluids associated with the components <NUM> of the machine <NUM> provide relevant information related to a performance of the corresponding components <NUM>. The fluid test may be used to determine a quality of various fluids associated with the machine <NUM>. For example, the fluid test may be used to predict component failures before a potential failure event. The fluid test may be carried out every <NUM> to <NUM> days. The fluid test provides the fluid test results of various fluids used in the machine <NUM> such as fuel, engine oil, coolants for different components <NUM> of the machine <NUM>, power steering fluid, brake fluid, transmission fluid, various lubricants, and the like, without any limitations.

The fluid test is carried out based on collection of the fluid samples from the machine <NUM> onsite. The fluid samples may be analyzed in a laboratory to determine a condition/quality of the fluid. The fluid samples may include contaminants, such as debris, that may negatively affect the performance of the machine <NUM>. In some examples, the fluid test result may measure contents of various substances present in the fluids. For example, the fluid test result may provide an indication of an amount of iron content in the fluid samples. The fluid test may include an oil sampling test, a coolant sampling test, a fuel sampling test, and the like.

The oil sampling test includes analysis of engine oil. Further, the oil sampling test may include analysis of the components <NUM> that require lubrication such as engines, transmission, hydraulics, final drive, differential gears, gear boxes, compressor, and the like. In an example, the oil sampling test provides early signs of wear and identifies contaminants in the engine oil such as water, fuel, glycol, dirt, and the like, that may degrade the performance of the machine <NUM>. The condition of the engine oil is also determined in the oil sampling test for overall particle analysis.

Further, for the coolant sample test, a coolant sample is collected from the machine <NUM>. The coolant sampling test determines a chemical balance of the coolant for thermal protection and better cooling efficiency. The coolant sampling test provides information pertaining to correct usage of the coolant, condition of the coolant, adequate freeze and boil protection of the coolant, contaminants in the coolant, and the like. Moreover, the fuel sampling test is performed on the fuel to determine fuel quality, A low-quality fuel can negatively affect the performance of the machine <NUM>. Further, the low-quality fuel may lead to abnormal wear of components <NUM> such as valves, valve guides, piston ring, and the like. The fuel sampling test determines if the fuel quality is acceptable, determines microbial growth in the fuel, contaminants in the fuel, and the like.

In an example, the fluid test result may be stored in a database of the laboratory which can be retrieved by the controller <NUM> using the cloud computing system, the mobile application, the wireless transmission system, and the like. Alternatively, the fluid test results may be fed into the system <NUM> by a personnel in charge of fluid testing. The controller <NUM> compares the fluid test result and a predetermined threshold associated with the fluid samples for generation of the service report. The predetermined threshold associated with the fluid samples may be stored in the database <NUM> of the system <NUM>. The predetermined threshold may include standard or optimal values for various parameters associated with the fluids.

Further, the inspection data may be generated based on the inspection of the machine <NUM>. The inspection of the machine <NUM> may combine data collection and analysis with hands-on testing and examination for a thorough look at the condition of the machine <NUM>. The inspection of the machine <NUM> may be performed by personnel who are skilled and trained to determine faults in the components <NUM> of the machine <NUM> that may impact machine performance. For example, the personnel may check various sensors, gauges, engine components, steering components, brake systems, exhaust system, cooling system, fan belts, engine support, radiator guards, transmission function, oil levels, hydraulic system, and the like. The inspection data of the various components <NUM> for the machine <NUM> is collected to verify a condition of the respective components <NUM>. The inspection data may be stored in the ECM <NUM> and may be retrieved by the controller <NUM> or the inspection data may be transmitted directly to the database <NUM>.

Further, the controller <NUM> correlates the fault diagnosis data with the fault code, the fluid test result, and/or the inspection data. In some examples, the fault diagnosis data is compared with the fault code, the fluid test result, and/or the inspection data to verify if the fault diagnosis data corresponds to the fault code, the fluid test result, and/or the inspection data.

The controller <NUM> assigns a priority for the servicing schedule based on the correlation between the fault diagnosis data and the fault code, the fluid test result, and/or the inspection data. More particularly, the controller <NUM> assigns a high priority for the servicing schedule if the fault diagnosis data matches with the fault code, the fluid test result, and/or the inspection data. In some examples, if the fault diagnosis data matches with even one of the fault code, the fluid test result, and/or the inspection data, the controller <NUM> may assign a high priority to such a servicing schedule. Further, if the fault diagnosis data matches with each one of the fault code, the fluid test result, and the inspection data, the controller <NUM> may assign a high priority to the servicing schedule and may also provide a notification to draw the service personnel's attention towards such an alarming situation.

In other example, the fault diagnosis data may not match with the fault code, the fluid test result, and/or the inspection data. In such an example, the controller <NUM> may assign a low priority for such a servicing schedule to indicate conflicts between the fault diagnosis data and the fault code, the fluid test result, and/or the inspection data.

In some examples, the controller <NUM> may also use the historical failure data and the historical repair data to generate an association model that indicates which components <NUM> of the machine <NUM> may be impacted based on certain real time machine events. In such an example, a pattern and occurrences of the historical failure data and the historical repair data may be used to map the historical failure data with the historical repair data. Such a mapping may assist in relating a particular fault code with the component <NUM> of the machine <NUM> that may be potentially impacted by the fault code.

<FIG> is a flowchart of a process <NUM> to assign the priority for the servicing schedule. The process <NUM> may be executed by the controller <NUM>. At a block <NUM>, details related to the machine <NUM> such as a dealer of the machine <NUM>, a location at which the machine <NUM> operates, a machine serial number, warranty data, service engineer details, Customer Value Agreement (CVA), and the like, are received by the controller <NUM>. The controller <NUM> may receive the details from the ECM <NUM> of the machine <NUM> or the database <NUM> of the system <NUM>. Further, from the block <NUM>, the details are transmitted to a block <NUM>. At blocks <NUM> and <NUM>, the controller <NUM> receives the details representing the historical failure data and the historical repair data associated with the machine <NUM>. Data from the blocks <NUM>, <NUM> are sent to a block <NUM> where the association model based on mapping of either the historical failure data to the historical repair data or for various historical repair data associated with a particular component <NUM> is generated. It should be noted that the association model for the historical failure data and the historical repair data is generated based on recentness of the historical failure data and the historical repair data, frequency of occurrences of failures/repairs, monetary value associated with the failures/repairs, and the like. The association models are then received by the controller <NUM> at the block <NUM>. Further, from a block <NUM>, the inspection data is received by the controller <NUM>. At a block <NUM>, the fluid test result is received by the controller <NUM>. At a block <NUM>, data related to the fault code is received by the controller <NUM>. At a block <NUM>, information related to the aftermarket servicing lead is received by the controller <NUM> or the aftermarket servicing lead may be generated by the controller <NUM>.

From the blocks <NUM>, <NUM>, <NUM>, <NUM>, <NUM>, <NUM>, the process <NUM> moves to the block <NUM>. At the block <NUM>, the controller <NUM> assigns the priority for the servicing schedule. For this purpose, the controller <NUM> generates a confidence score based on correlation between the input signal from the block <NUM> and the input signals from the blocks <NUM>, <NUM>, <NUM>, <NUM>, <NUM>. Specifically, at the block <NUM>, a high confidence score is generated if the input signal from the block <NUM> matches with the input signals from the blocks <NUM>, <NUM>, <NUM>, <NUM>, <NUM>. Further, the controller <NUM> generates a low confidence score if the input signal from the block <NUM> does not match with the input signals from the blocks <NUM>, <NUM>, <NUM>, <NUM>, <NUM>. Moreover, the high priority of the servicing schedule is assigned to the servicing schedule having the high confidence score and the low priority of the servicing schedule is assigned to the servicing schedule having the low confidence score. The high or low priority can be assigned at a component level, a subcomponent level, a model level, and the like. Further, the high priority of the servicing schedule generates an aftermarket part sale lead. From the block <NUM>, the process <NUM> moves to a block <NUM>. At the block <NUM>, the user interface <NUM> presents the service report including the prognosis data to the servicing personnel.

Referring now to <FIG>, the service report containing the servicing information is presented on the user interface <NUM>. The service report includes the prognosis data based on the analysis of the input signal. The prognosis data may include actionable events or remedies that can be applied for servicing or maintenance of the components <NUM> of the machine <NUM> that are not operating in an intended manner. For instance, the user interface <NUM> may display the fault in the machine components <NUM> and actions that can be taken by the servicing personnel to solve the related faults. Moreover, the prognosis data includes a first prognosis data for the aftermarket servicing lead and a second prognosis data for the fault code, the fluid test result, and/or the inspection data.

Further, in the service report, the first prognosis data is generated based on the fault diagnosis data. The first prognosis data may include actionable events that may be performed for addressing the faults presented in the machine <NUM> based on the fault diagnosis data. Moreover, in the service report, the second prognosis data is generated based on the fault code, the fluid test result, and/or the inspection data. The second prognosis data may include actionable events that may be performed for addressing the faults presented in the machine <NUM> based on the data from the fault code, the fluid test result, and/or the inspection data.

The prognosis data shows whether the aftermarket servicing lead and the fault code, the fluid test result, and/or the inspection data are related to similar or dissimilar faults which may in turn affect an acceptance level for the servicing schedule. For example, the service report may disclose if the first prognosis data matches with the second prognosis data or if the first prognosis data does not match with the second prognosis data. In some examples, if the first prognosis data matches with the second prognosis data, a probability of the acceptance level of the servicing schedule may increase. In other examples, if the first prognosis data does not match with the second prognosis data, a probability of the acceptance level of the servicing schedule may decrease.

<FIG> illustrates an exemplary dashboard <NUM> that may be displayed on the user interface <NUM>. The dashboard <NUM> includes a first tab <NUM> for a fault code summary, a second tab <NUM> for a fluid test result summary, and a third tab <NUM> for an inspection data summary. Each of the first, second, and third tabs <NUM>, <NUM>, <NUM> may allow a user of the system <NUM> to obtain information related to the fault code, the fluid test result, and the inspection data, respectively. More specifically, when accessed, the first, second, and third tabs <NUM>, <NUM>, <NUM> may allow the user to view details related to a number of the fault codes, the fluid test results, and the inspection data, respectively, for a particular machine or for a group of machines. The machine may be similar to the machine <NUM> (see <FIG>). For explanatory purposes, the dashboard <NUM> that will be displayed based on accessing the first tab <NUM> will now be explained in detail. However, it should be understood that the information provided below is equally applicable to the second and third tabs <NUM>, <NUM>.

As illustrated herein, the dashboard <NUM> includes a first dropdown <NUM> for serial numbers associated with different machines, a second dropdown <NUM> for location at which the machines are operating, a third dropdown <NUM> for city in which the machines are operating, a fourth dropdown <NUM> for component category, a fifth dropdown <NUM> for severity level, a sixth dropdown <NUM> for the aftermarket servicing lead, and a seventh dropdown <NUM> for date. The dropdowns <NUM>, <NUM>, <NUM>, <NUM>, <NUM>, <NUM>, <NUM> may be used to filter data that will be displayed on the dashboard <NUM> based on user preferences. For example, the system <NUM> may store information related to a variety of machines having serial number <NUM>, serial number <NUM>, serial number <NUM>, and the like. The user can use the first dropdown <NUM> for accessing information related to a particular serial number amongst the serial numbers <NUM>, <NUM>, <NUM>. Further, the second and third dropdowns <NUM>, <NUM> may be used to filter and look for information based on the location, such as a country or a state where the machines are operating, or the city where the machines are operating. The fourth dropdown <NUM> may be used to filter information related to different component categories of a single machine or multiples machines. Moreover, the fifth dropdown <NUM> may be used to filter information based on severity level associated with the fault codes.

The sixth dropdown <NUM> may be used to access data of the serial numbers <NUM>, <NUM>, <NUM> that have an associated aftermarket servicing lead. For example, the sixth dropdown <NUM> may provide an option of "YES" or "NO" for the user. When the user chooses the option "NO", the system <NUM> does not map the fault code data with the fault code diagnosis data associated with the aftermarket servicing lead and presents data related only to the fault codes. Whereas, when the user chooses the option "YES", the system <NUM> maps the fault code data with the fault code diagnosis data associated with the aftermarket servicing lead. In an example, the severity level may be divided into four levels, i.e., a first level, a second level, a third level, and a fourth level such that the first level denotes high severity, and the fourth level denotes low severity.

Further, the dashboard <NUM> includes a serial number summary <NUM> containing the serial numbers <NUM>, <NUM>, <NUM>. In the illustrated example, a number of fault codes "X1", "X2", "X3" generated for a particular serial number <NUM>, <NUM>, <NUM> is displayed adjacent to the serial number <NUM>, <NUM>, <NUM>. As an example, a machine with the serial number <NUM> transmitted "X1" numbers of fault codes in a period of one month, a machine with the serial number <NUM> transmitted "X2" numbers of fault codes in a period of one month, and a machine with the serial number <NUM> transmitted "X3" numbers of fault codes in a period of one month. Further, the tabs for "X1", "X2", and "X3" may include indicators to imply the severity level associated with the fault codes. Such indicators may include for example, a color coding, a hatching, and the like.

Moreover, the dashboard <NUM> includes a fault code and description summary <NUM> containing various fault codes and description related to such fault codes. As illustrated, the fault code and description summary <NUM> may display a first fault code and a total number of first occurrences "Y1" for the first fault code, a second fault code and a total number of second occurrences "Y2" for the second fault code, a third fault code and a total number of third occurrences "Y3" for the third fault code, a fourth fault code and a total number of fourth occurrences "Y4" for the fourth fault code, and so on. In this example, the total number of occurrences "Y1", "Y2", "Y3", "Y4" associated with different fault codes for all the serial numbers <NUM>, <NUM>, <NUM> is illustrated. Alternatively, the user may use the first dropdown <NUM> to view occurrences for different fault codes associated with one of the serial numbers <NUM>, <NUM>, <NUM>. Further, the tabs for the occurrences "Y1", "Y2", "Y3", "Y4" may include indicators to indicate the severity level associated with the fault codes. Such indicators may include for example, a color coding, a hatching, and the like.

Further, the dashboard <NUM> includes an occurrence timeline summary <NUM>. The occurrence timeline summary <NUM> may include various plots "Z1", "Z2", "Z3", "Z4" generated based on plotting of occurrences of different fault codes in a particular time period. Each plot "Z1", "Z2", "Z3", "Z4" may also signify a severity level associated with the fault codes. The plots may include different color coding based on the severity levels. It should be noted that the plots "Z1", "Z2", "Z3", "Z4" may be generated for the fault codes associated with a particular serial number <NUM>, <NUM>, or <NUM> or the plots "Z1", "Z2", "Z3", "Z4" may be generated for the fault codes associated with all the serial numbers <NUM>, <NUM>, <NUM>. Further, the dashboard <NUM> includes an occurrence location summary <NUM>. The occurrence location summary <NUM> may display details of locations, such as states or countries, at which the serial numbers <NUM>, <NUM>, <NUM> with the fault codes are present.

Referring now to <FIG>, the dashboard <NUM> illustrates information that will be displayed if the option "YES" is selected using the sixth dropdown <NUM>. A mapping of the fault code data with the aftermarket servicing lead changes the total number of the occurrences "Y1", "Y2", "Y3", "Y4" for the corresponding fault codes. In an example, the total number of occurrences "Y1", "Y2", "Y3", "Y4" may reduce to only display data that is derived based on mapping of the fault code data and the fault diagnosis data. More particularly, the total number of the occurrences "Y1", "Y2", "Y3", "Y4" in a particular serial number <NUM>, <NUM>, <NUM> or associated components may be determined based on matching of the fault code data and the fault diagnosis data associated with the aftermarket servicing lead.

<FIG> shows a schematic diagram <NUM> illustrating impact of the fault code, the fluid test result, and/or the inspection data on an acceptance level of a total number of first servicing schedules for the machine <NUM>. In a first cycle "C1", the first servicing schedules are generated at a block <NUM> based on the aftermarket servicing lead. The first servicing schedules are presented to the customer for review. Further, at a block <NUM>, data corresponding to a number of acceptances and a number of rejections for the first servicing schedules is generated based on the customer review. It has been observed that the acceptance level of the various first servicing schedules is generally low in the first cycle "C1" as only data from the aftermarket servicing lead is used for generating the first servicing schedules.

In a second cycle "C2", a number of second servicing schedules are generated at a block <NUM> based on the fault code, the fluid test result, and/or the inspection data. The second servicing schedules are presented to the customer for review. Further, at a block <NUM>, data corresponding to a number of acceptances and a number of rejections for the second servicing schedules is generated based on the customer review. It has been observed that the acceptance level of the various second servicing schedules is generally high in the second cycle "C2" as data from the aftermarket servicing lead as well as data associated with the fault code, the fluid test result, and/or the inspection data is used for generating the second servicing schedules. Specifically, in the second cycle, if the first prognosis data matches with the second prognosis data, the confidence level of the customer increases which in turn increases the acceptance level of the servicing schedule.

In one example, the servicing schedule for the machine <NUM> includes the first prognosis data for rebuilding the engine of the machine <NUM>. Further, the fault code for this example may include the second prognosis data that indicates fault in a sensor associated with the engine. Thus, the second prognosis data relates to replacement of the sensor rather than rebuilding the engine, which may be cost effective. An upfront provision of details corresponding to a real time machine event based on the fault code data allows precise identification of the issue with the machine <NUM>. Moreover, the servicing schedule without the fault code may be rejected by the customer while a lead generated based on the fault code may be pursued for generating the servicing/maintenance of the machine <NUM> due to the upfront provision of the fault code.

<FIG> illustrates a flowchart of a process <NUM> (or an algorithm) for generating the servicing schedule for the machine <NUM>. Referring to FIGS. <NUM> to <NUM>, the process <NUM> may be executed by the controller <NUM>. The process <NUM> may be stored within the database <NUM> of the system <NUM> and may be retrieved for execution by the controller <NUM>. At a block <NUM>, the process <NUM> starts or begins operation. At a block <NUM>, the controller <NUM> receives the aftermarket servicing lead and the fault diagnosis data from the database <NUM> of the system <NUM> or the ECM <NUM> of the machine <NUM>. In another example, the aftermarket servicing lead and the fault diagnosis data is generated by the controller <NUM> itself based on various inputs from the ECM <NUM> of the machine <NUM>, the database <NUM>, or any other external sources. The fault diagnosis data may be associated with the components <NUM> of the machine <NUM> such as the engine, the transmission, the hydraulics, and the like.

The process <NUM> then moves to a block <NUM>. At the block <NUM>, the controller <NUM> receives the fault code, the fluid test result, and/or the inspection data. Further, the fault code is received by the controller <NUM> from the ECM <NUM> of the machine <NUM>. The fluid test result may be fed to the controller <NUM> by the servicing personnel, a third-party application, or it may be present in the database <NUM>. Moreover, the inspection data is fed to the controller <NUM> by the servicing personnel, a third-party application, or it may be present in the database <NUM>. In some examples, the fluid test result and the inspection data may be received from the ECM <NUM> of the machine <NUM>.

The process <NUM> then moves to a block <NUM>. At the block <NUM>, the controller <NUM> analyze the fault diagnosis data as well as the fault code, the fluid test result, and/or the inspection data. For example, the controller <NUM> may determine if the fluid test result lie within the predetermined threshold or beyond the predetermined threshold or if the aftermarket servicing lead should be scheduled. The process <NUM> then moves to a block <NUM>. At the block <NUM>, the controller <NUM> determines if the fault diagnosis data matches with the fault code, the fluid test result, and/or the inspection data. Specifically, the controller <NUM> compares if the fault diagnosis data corresponds to the fault code, the fluid test result, and/or the inspection data based on correlating the fault diagnosis data with the fault code, the fluid test result, and/or the inspection data. If the fault diagnosis data matches with the fault code, the fluid test result, and/or the inspection data, the process <NUM> moves to a block <NUM>. At the block <NUM>, the controller <NUM> assigns the high priority for the servicing schedule. The process <NUM> then moves to a block <NUM>. At the block <NUM>, the controller <NUM> generates the service report for the machine <NUM>. The service report may include the fault diagnosis data, data related to the fault code, the fluid test result, and/or the inspection data, the first prognosis data, the second prognosis data, and the like. The service report is then utilized to generate the servicing schedule of the machine <NUM>.

However, at the block <NUM>, if the fault diagnosis data does not match with the fault code, the fluid test result, and/or the inspection data, the process <NUM> moves to a block <NUM>. At the block <NUM>, the controller <NUM> assigns the low priority for the servicing schedule. The process <NUM> then moves to the block <NUM>. At the block <NUM>, the controller <NUM> generates the service report for the machine <NUM>. From the block <NUM>, the process <NUM> moves to a block <NUM> where the process <NUM> terminates or ends operation.

The present disclosure relates to the system <NUM> for generating the servicing schedule for the machine <NUM>. The system <NUM> generates the servicing schedule based on the aftermarket servicing lead as well as the data associated with the fault code, the fluid test result, and/or the inspection data. An upfront integration and presentation of the servicing information offers real-time insights on the condition of the machine <NUM> for performing servicing/maintenance of the machine <NUM>. Further, the correlation between the fault diagnosis data and the fault code, the fluid test result, and/or the inspection data and the upfront presentation of the real-time machine condition increases the confidence level of the customer which ultimately increases the acceptance level of the servicing schedule. Moreover, the presentation of the servicing schedule on the user interface <NUM> provides improved clarity to the customers of the machine <NUM> which reduces a data processing time associated with the servicing schedules.

The system <NUM> also increases an accuracy and a precision of the servicing schedule, which eliminates any unplanned or unnecessary repair downtime of the machine <NUM>. Further, the fault code, the fluid test result, and the inspection data provide the servicing information on a real-time basis which improves accuracy and precision as compared to the data or prognosis presented by just the aftermarket servicing lead. In some cases, the data associated with the fault code, the fluid test result, and/or the inspection data may provide a more detailed and reliable insight of the condition of the components <NUM> of the machine <NUM>, which in turn eliminates excessive cost of replacement or repair of the machine components <NUM> having a higher value, improves resale value of the machine <NUM>, and the like.

The system <NUM> also reduces cost of repair or replacement by giving prior intimation of the servicing schedule before failure of the machine components <NUM>. The prior intimation and corresponding initiation of the servicing may prevent failure of the components <NUM> and eliminate unnecessary servicing/repair of the machine components <NUM>. Further, a successful servicing schedule may extend the lifespan of the machine <NUM> and minimize equipment breakdown.

<FIG> illustrates a flowchart of a method <NUM> for generating the servicing schedule for the machine <NUM>. At step <NUM>, the controller <NUM> receives the input signal pertaining to the servicing information for the machine <NUM>. The servicing information includes the aftermarket servicing lead, the fault code from the machine <NUM>, the fluid test result for the machine <NUM>, and/or the inspection data for the machine <NUM>. The controller <NUM> generates the aftermarket servicing lead based on the operating hours of the machine <NUM>, the historical repair data of the components <NUM> of the machine <NUM>, the predicted lifespan of the components <NUM> of the machine <NUM>, and/or the manufacturing date of the machine <NUM>. The controller <NUM> also receives the fault diagnosis data associated with the aftermarket servicing lead.

Further, the controller <NUM> receives the fault code from the machine <NUM>. The fault code is representative of the faulty operation of the components <NUM> of the machine <NUM>. Moreover, the fluid test result is generated based on analysis of the fluid samples associated with the components <NUM> of the machine <NUM>. Further, the service report is generated based on comparison between the fluid test result and the predetermined threshold associated with the fluid samples for generation of the service report.

At step <NUM>, the controller <NUM> analyzes the input signal for generating the service report that contains the servicing information. The controller <NUM> correlates the fault diagnosis data with the fault code, the fluid test result, and/or the inspection data. The controller <NUM> assigns the priority for the servicing schedule based on the correlation between the fault diagnosis data and the fault code, the fluid test result, and/or the inspection data. The controller <NUM> also assigns the high priority for the servicing schedule if the fault diagnosis data matches with the fault code, the fluid test result, and/or the inspection data.

At step <NUM>, the user interface <NUM> receives the service report from the controller <NUM>. The user interface <NUM> presents the service report thereon. Further, the service report includes the prognosis data based on the analysis of the input signal. The service report also includes the first prognosis data for the aftermarket servicing lead and the second prognosis data for the fault code, the fluid test result, and/or the inspection data. The service report is used for generating the servicing schedule for the machine <NUM>.

Claim 1:
A system (<NUM>) for generating a servicing schedule for a construction machine (<NUM>), the system (<NUM>) comprising:
a controller (<NUM>) configured to:
receive an input signal pertaining to a servicing information for the construction machine (<NUM>), wherein the servicing information includes an aftermarket servicing lead, and one or more of a fault code from the construction machine (<NUM>), a fluid test result for the construction machine (<NUM>), and an inspection data for the construction machine (<NUM>); and
analyze the input signal for generating a service report that contains the servicing information, wherein the service report is used for generating the servicing schedule for the construction machine (<NUM>); and
a user interface (<NUM>) for receiving the service report from the controller (<NUM>), wherein the user interface (<NUM>) presents the service report thereon.