DESC: FORM 2

THE PATENTS ACT, 1970
(39 of 1970)
&
THE PATENT RULES, 2003

COMPLETE SPECIFICATION
(See Section 10 and Rule 13)

Title of invention:
METHOD AND SYSTEM FOR PREDICTING FAILURES IN SOFTWARE PROCESSES

Applicant:
Tata Consultancy Services Limited
A company Incorporated in India under the Companies Act, 1956
Having address:
Nirmal Building, 9th Floor,
Nariman Point, Mumbai 400021,
Maharashtra, India

The following specification particularly describes the invention and the manner in which it is to be performed.
CROSS-REFERENCE TO RELATED APPLICATIONS AND PRIORITY
[001] The present application claims priority from Indian provisional patent application no. 201821049453, filed on December 27, 2018. The entire contents of the aforementioned application are incorporated herein by reference.
TECHNICAL FIELD
[002] The disclosure herein generally relates to predicting failures, and, more particularly, to method and system for predicting failures in software processes.
BACKGROUND
[003] Robotic process automation revolution transforms enterprise by automating autonomous agents with the goal of reducing manual effort and time taken for resolving occurred faults. Enterprise services use multiple services and applications for handling a single transaction. These applications may be distributed over several machines, making the topology of the machines that provides service more difficult to track and monitor. Human agents spend significant time interacting with multiple domain services for predicting and troubleshooting the problem which practically does not scale. However, a scalable conversational framework enables automating the process of detecting, predicting and troubleshooting the problem by coordinating with multiple domain experts as combinational bots that proactively utilize domain knowledge and represent the occurred faults in a best suitable approach.
[004] In conventional methods, predicting faults or failures in any software processes is based on robotic agents for detecting possible failures, deficiencies and breakdowns from transactional history. In another method, robotic agents detect fault events and pushing these fault events to operational system for diagnosis and then for recovery of the software process. However, these conventional methods limit in providing a scalable framework model for processing various transactional applications dynamically which thereby improves operational stability. Further, these conventional methods also limit in predicting faults to be occurred in any critical entity, which requires proactive monitoring of violated real time metrics for predicting the occurrence of time dependent system failures.
SUMMARY
[005] Embodiments of the present disclosure present technological improvements as solutions to one or more of the above-mentioned technical problems recognized by the inventors in conventional systems. For example, in one embodiment, a system for is provided. The system includes a processor, an Input/output (I/O) interface and a memory coupled to the processor is capable of executing programmed instructions stored in the processor in the memory to fetch, using a scan bot, an input data from a data source, wherein the data source receives the input data from a centralized data lake configured to a plurality of software applications for monitoring failures. Further, the input data is parsed from the data source into a log parser. Further, a reference database comprising a reference data for the input data is accessed, wherein the reference database comprises previously detected failure related events. Further, a correlation factor corresponding to the input data indicating a failure alert is determined using natural language processing (NLP) by creating a correlation schema for the input data using a correlation technique. Further, dynamic weights for the input data are calculated using the correlation schema and the reference database, wherein the reference database is utilized as ground truth for the input data. Further, using an influencer data analyzer (ID) module, a correlation factor for the input data is calculated using a mean time between failures (MTBF). Furthermore, using a predictor model, a failure prediction metrics corresponding to the input data is predicted based on a fault threshold range, the correlation factor and the reference database.
[006] In another aspect, provides a method that includes a processor, an Input/output (I/O) interface and a memory coupled to the processor is capable of executing programmed instructions stored in the processor in the memory to fetch, using a scan bot, an input data from a data source, wherein the data source receives the input data from a centralized data lake configured to a plurality of software applications for monitoring failures. Further, the input data is parsed from the data source into a log parser. Further, a reference database comprising a reference data for the input data is accessed, wherein the reference database comprises previously detected failure related events. Further, a correlation factor corresponding to the input data indicating a failure alert is determined using natural language processing (NLP) by creating a correlation schema for the input data using a correlation technique. Further, dynamic weights for the input data are calculated using the correlation schema and the reference database, wherein the reference database is utilized as ground truth for the input data. Further, using an influencer data analyzer (ID) module, a correlation factor for the input data is calculated using a mean time between failures (MTBF). Furthermore, using a predictor model, a failure prediction metrics corresponding to the input data is predicted based on a fault threshold range, the correlation factor and the reference database.
BRIEF DESCRIPTION OF THE DRAWINGS
[007] The accompanying drawings, which are incorporated in and constitute a part of this disclosure, illustrate exemplary embodiments and, together with the description, serve to explain the disclosed principles:
[008] FIG.1 illustrates an exemplary block of a system, alternatively referred as failure prediction system, for predicting failures in software processes, in accordance with some embodiments of the present disclosure.
[009] FIG. 2 is a flow diagram illustrating a method for predicting failures in the software processes of the system of FIG. 1, in accordance with some embodiments of the present disclosure.
[010] FIG.3 illustrates a high-level architecture of the system of FIG 1, in accordance with some embodiments of the present disclosure.
[011] FIG.4A and FIG.4B illustrates a functional flow diagram for predicting failures of the system of FIG. 1 depicted in the architecture of FIG. 3, in accordance with some embodiments of the present disclosure.
[012] FIG.5A illustrates a cognitive bot depicted in the architecture of the FIG. 3 for processing the input data for predicting failures occurred in software processes using the system of FIG.1, in accordance with some embodiments of the present disclosure.
[013] FIG.5B illustrates a model evaluator for normalizing the input data using the system of FIG.1, in accordance with some embodiments of the present disclosure.
[014] FIG.5C illustrates a correlation schema for the input data using the system of FIG.1, in accordance with some embodiments of the present disclosure.
[015] FIG.6A depicts graph of correlation factor for the input data using the system of FIG.1, for the input data, in accordance with some embodiments of the present disclosure.
[016] FIG.6B depicts experimental data of failure prediction metrics for the input data using the system of FIG.1, in accordance with some embodiments of the present disclosure.
DETAILED DESCRIPTION OF EMBODIMENTS
[017] Exemplary embodiments are described with reference to the accompanying drawings. In the figures, the left-most digit(s) of a reference number identifies the figure in which the reference number first appears. Wherever convenient, the same reference numbers are used throughout the drawings to refer to the same or like parts. While examples and features of disclosed principles are described herein, modifications, adaptations, and other implementations are possible without departing from the scope of the disclosed embodiments. It is intended that the following detailed description be considered as exemplary only, with the true scope being indicated by the following claims.
[018] The embodiments herein provide a method and a system, for predicting failures in software processes using autonomous agents. The disclosed method is a low-cost efficient system for predicting failures from any software processes or application. The system receives input data from the data source configured to a centralized data lake, wherein the centralized data lake is connected to a plurality of software applications. The input data received from the plurality of software applications are processed by the system for predicting anomalies occurred in future. The disclosed method eliminates manual intervention reducing human errors and induced effort. The faults are predicted before the occurrence which reduces breakdown time of the system thereby essentially increases efficiency. The proposed system is a machine determined architecture for predicting occurrence of faults thereby detecting the failures and troubleshooting the cause for any critical events increasing the performance. An example of the said system for predicting failures is described with the disclosed method in conjunction with FIG. 1 to 6B below.
[019] Referring now to the drawings, and more particularly to FIG. 1 through FIG.6B, where similar reference characters denote corresponding features consistently throughout the figures, there are shown preferred embodiments and these embodiments are described in the context of the following exemplary system and/or method.
[020] FIG.1 illustrates an exemplary block of a system, alternatively referred as failure prediction system, in accordance with some embodiments of the present disclosure. In an embodiment, the system 100 includes processor (s) 104, communication interface device(s), alternatively referred as or input/output (I/O) interface(s) 106, and one or more data storage devices or memory 102 operatively coupled to the processor (s) 104. The processor (s) 104 may be alternatively referred as one or more hardware processors. In an embodiment, the hardware processors can be implemented as one or more microprocessors, microcomputers, microcontrollers, digital signal processors, central processing units, state machines, logic circuitries, and/or any devices that manipulate signals based on operational instructions. Among other capabilities, the processor(s) 104 is configured to fetch and execute computer-readable instructions stored in the memory. In an embodiment, the system 100 can be implemented in a variety of computing systems, such as laptop computers, notebooks, hand-held devices, workstations, mainframe computers, servers, a network cloud and the like.
[021] The I/O interface(s) 106 can include a variety of software and hardware interfaces, for example, a web interface, a graphical user interface, and the like and can facilitate multiple communications within a wide variety of networks N/W and protocol types, including wired networks, for example, LAN, cable, etc., and wireless networks, such as WLAN, cellular, or satellite. In an embodiment, the I/O interface device(s) can include one or more ports for connecting a number of devices to one another or to another server or a centralized data lake used as source of input data by the system 100.
[022] The memory 102 may include any computer-readable medium known in the art including, for example, volatile memory, such as static random access memory (SRAM) and dynamic random access memory (DRAM), and/or non-volatile memory, such as read only memory (ROM), erasable programmable ROM, flash memories, hard disks, optical disks, and magnetic tapes. The memory 102 further may include modules 108. In an embodiment, the modules 108 includes a failure prediction module 110, for implementing functions of the system 100. In an embodiment, the modules 108 can be an Integrated Circuit (IC) (not shown), external to the memory 102, implemented using a Field-Programmable Gate Array (FPGA) or an Application-Specific Integrated Circuit (ASIC). The names (or expressions or terms) of the modules of functional block within the modules 108 referred herein, are used for explanation and are not construed to be limitation(s). Further, the memory 102 can also include the repository 112. In an embodiment, the repository 112 includes a data source, which may be external or internal to the system 100. The data source may store the input data, which is received from the centralized data lake configured to a plurality of applications for monitoring failures. The memory 102 may further comprise information pertaining to input(s)/output(s) of each step performed by the system 100 and methods of the present disclosure. The system processes the received input data and predicts failures using the disclosed method that will be explained with reference to the accompanying diagrams in FIG.3 and FIG.4. The system 100 is further explained in detail in conjunction with FIG.2 through FIG.6B.
[023] FIG. 2 is a flow diagram illustrating a method for predicting failures in the software processes of the system of FIG. 1, in accordance with some embodiments of the present disclosure. The steps of the method 200 of the flow diagram will now be explained with reference to the components or blocks of the system 100 in conjunction with the example architecture of the system as depicted in FIG.3 through FIG.6B. In an embodiment, the system 100 comprises one or more data storage devices or the memory 102 operatively coupled to the one or more processors 104 and is configured to store instructions for execution of steps of the method 200 by the one or more processors 104. In an embodiment, the failure prediction module 110 in the memory 102 store instructions for execution of steps of the method 200 by the one or more processors 104, for predicting the failures from software processes. Although process steps, method steps, techniques or the like may be described in a sequential order, such processes, methods and techniques may be configured to work in alternate orders. In other words, any sequence or order of steps that may be described does not necessarily indicate a requirement that the steps be performed in that order. The steps of processes described herein may be performed in any order practical. Further, some steps may be performed simultaneously.
[024] At step 202 of the method 200, the processor 104 is configured to fetch, using a scan bot, an input data from the data source, wherein the data source receives the input data from the centralized data lake, configured with the plurality of software applications for monitoring failures. Referring now to FIG.3, which illustrates a high-level architecture of failure prediction system, in accordance with some embodiments of the present disclosure. Here, the system 100 receives the input data which is an failure event detected from the plurality of software processes and these failure events are stored in the data source The data source is configured to the centralized data lake which is a configured to the plurality of software applications. Example the plurality of software application include, but are not limited to, a volume of end points such as inbound agents, monitoring agents, an application server or an database, an infrastructure or an network, an e-commerce web service applications, a social media, a search engines or an data agency, an ticketing tools and an log server. The repository 112 alternatively referred as data source stores the input data received from any of the plurality of software applications. The centralized data lake is a heterogeneous framework that stores voluminous data representing an actual data landing and processes the stored input data.
[025] At step 204 of the method 200, the processor 104 is configured to parse, the input data from the data source into a log parser. Referring now to FIG.4A, the scan bot scarps the input data from the data source configured to the centralized data lake which is an end point for any critical software applications or processes. These critical software processes or applications requires constant monitoring, for any failure metric violations to avoid system failures which is of time dependent. FIG.5B illustrates a model evaluator for normalizing the input data using the system of FIG.1, in accordance with some embodiments of the present disclosure. The input data parsed into the log parser normalizes the input data into various dimensions of derived data into a common format with specific titles and spaces using predefined normalized data format.
[026] At step 206 of the method 200, the processor 104 is configured to access, a reference database comprising a reference data for the input data, wherein the reference data comprises previously detected fault or failure related events. The reference database may be a relational database for storing reference data relating to previously detected failures and maintenance related events. The method accesses reference database for the input data of relevant context data for servicing the respective occurred failures are additionally stored in the database. The database may be a centralized database that is in data exchange with all autonomous agents. The reference database is configured to be responsible for failure prediction and serves the respective clients or agents or any software processes applications.
[027] At step 208 of the method 200, the processor 104 is configured to determine, a correlation factor corresponding to the input data indicating a failure alert using natural language processing (NLP). Referring now to FIG.4A and FIG.5C, the model evaluator chooses a best-fit model for the reference database by applying various known in the art machine learning algorithms. Further, a correlation schema is created for the input data using a correlation technique. The correlation technique is a metrics correlation matrix builder which builds a schema of correlation or interdependency within the metrics or the order. Further, dynamic weights for the input data is calculated using the correlation schema and the reference database. Here, the reference database is utilized as ground truth for the input data. The weights of these metrics are calculated dynamically based on how closely they are coupled. The associated weights are availed based on the reference data obtained from the reference data base and an impact is created for the metrics for identifying system-failure. The closely coupled weights are identified based on multi variate positioning of failure alerts at different points in time. Further, an influencer data analyzer (ID) module calculates a correlation factor for the input data using a mean time between failures (MTBF) as represented below in equation 1,
MTBF = Total Operational Time
Total No. of Failures
---------------- equation 1
The mean time between failures is the ratio of total operational time with the total number of failures. The influencer data analyzer (ID) module calculates a correlation factor as mentioned below in the table 1,
Table 1 – Correlation factor calculation

Def IDAnalyzer(jobID1, jobID2, CF_old, n, W_old):
CF = eigenFactor(mtbf , jobID1, jobID2)
If (CF == CF_old):
W = W_old
Break
Else:
W = CF*n
W_old = W
Break
Return (W_old, W, CF, CF_old)

The correlation factor is calculated by applying eigen factor for the input data using the mean time between failures and the failure alerts and thereby determining the change in the weights based on the time drift of the correlation factor.
[028] Referring now to FIG.5A illustrates a cognitive bot processing the input data for predicting failures occurred in software processes using the system of FIG.1, in accordance with some embodiments of the present disclosure. The feature store module of the cognitive bot processes the data lake to load various metric features and their max-min range of permissible magnitude in the form of casual impact propagation order based on the determined historical references. The bot memory loads the metric key values by obtaining the inputs from the multi model executor, auto model evaluator, metrics correlation matrix builder and influencer data analyzer to determine failure predicted metrics with the fault threshold range along with the order of propagation. The failure predicted metrics of the cognitive bot predicts outcome of the model based on the adjusted range and weights wherein inputting the feature store and bot memory data into the system. The failure prediction metrics of the cognitive bot processes the scan bot information to determine the decision maker that validates the predicted metrics and the correlation factor to identify any violation in the range. The predicted real time metrics is in compliant with the failure predicted metrics results no failures to be identified. If the above failure predicted metrics are not compatible and not in range, then the recovery action bot is enabled to provide the logs that auto hard closes ticket using the ticketing tool that records the information instantly.
[029] At step 210, of the method 200, the processor 104 is configured to predict, using a predictor model, a failure prediction metrics corresponding to the input data based on a fault threshold range, the correlation factor and the reference database. Referring now to FIG.4B and FIG.6A, the threshold adjustor module dynamically determines the fault threshold range corresponding to the input data. In one embodiment the threshold adjustor module of the cognitive bot automates to adjust the threshold by performing various trial and error method based on the predicted failure. Based on the fault threshold range, the input data is loaded into a feature store and a bot memory. Here, a boolean function acts as a switch that chooses to load the failure prediction metrics into the feature store and the bot memory based on the input data and the fault threshold range. Referring now to FIG.6B, the fault threshold range is a minimum range value and a maximum range value determined dynamically for the input data based on the reference database in accordance with time drift. The fault threshold range identifies the failure alerts for by eliminating noise. The feature store contains various failure prediction metric features and their maximum and minimum range of permissible magnitude in the form of impact propagation order based on the reference database. Further an anomaly from the input data is determined by comparing a correlation factor with the fault threshold range to determine whether the correlation factor differs from the fault threshold range.
[030] The written description describes the subject matter herein to enable any person skilled in the art to make and use the embodiments. The scope of the subject matter embodiments is defined herein and may include other modifications that occur to those skilled in the art. Such other modifications are intended to be within the scope of the present disclosure if they have similar elements that do not differ from the literal language of the embodiments or if they include equivalent elements with insubstantial differences from the literal language of the embodiments described herein.
[031] The embodiments of the present disclosure herein addresses unresolved problem of detection, monitoring and prediction of faults in software processes. Moreover, the embodiments herein further predicts software processes failures thereby increasing the scalability, reducing cost. The system is capable of eliminating manual intervention reducing human errors and induced effort. The faults predicted before the occurrence of fault reduces breakdown time of the system essentially with increased efficiency. The present disclosure is a machine determined architecture for predicting occurrence of faults unseen thereby detecting the issue, troubleshooting and determining the cause and then synchronization of data is both reactive and involves significant effort thereby increasing performance efficiency.
[032] In one embodiment, the cognitive bot receives the input from the data source, wherein the source includes a volume of end points collected from servers, external websites through web crawling, various monitoring tools, ticketing tools, logs, file systems. However, the end points may be a critical entity, wherein the critical entity requires proactive monitoring in real time for metric violation to predict the occurrence of system failures which is time dependent. The predictor module of the cognitive bot processes the received input using the scan bot module of the cognitive bot to generate a data lake. The centralized data lake module representing actual data landing and storage processes the data lake associated with the scan bot to generate normalized or segmented data. The model evaluator of the cognitive bot selects the best fit model for training the data based on prediction score obtained using the auto model evaluator. The training model comprises a plurality of algorithms which are known in the art to be applied on the normalized data for determining predictive results based on the historical trained data using the multi model executor. The threshold adjustor module of the cognitive bot automates the range adjustor to derive a min to max of the predicted score at any instance based on the historical trained data. This module obtains input from the multi model executor and auto model evaluator of the model evaluator module switches between each of the metric to load or not to load the metric into feature store and bot memory. Further, a metrics correlation matrix builder (MCM) is generated for creating a schema of correlation within metrics and their order. Further, calculates the weights of theses metrics based on closely coupled weights based on historical data generated by the metric during the system failure. Further, influencer data analyzer (ID) module of the cognitive bot calculates the mean time between failures (MTBF) for the predicted fault based on cause versus effect analysis based on the correlation metrics with their associated weights generated by MCM builder. This further estimates the actual time left to recover from the point of failure and to eliminate the impact of the system where the application is set to be enabled.
[033] It is to be understood that the scope of the protection is extended to such a program and in addition to a computer-readable means having a message therein; such computer-readable storage means contain program-code means for implementation of one or more steps of the method, when the program runs on a server or mobile device or any suitable programmable device. The hardware device can be any kind of device which can be programmed including e.g. any kind of computer like a server or a personal computer, or the like, or any combination thereof. The device may also include means which could be e.g. hardware means like e.g. an application-specific integrated circuit (ASIC), a field-programmable gate array (FPGA), or a combination of hardware and software means, e.g. an ASIC and an FPGA, or at least one microprocessor and at least one memory with software processing components located therein. Thus, the means can include both hardware means, and software means. The method embodiments described herein could be implemented in hardware and software. The device may also include software means. Alternatively, the embodiments may be implemented on different hardware devices, e.g. using a plurality of CPUs.
[034] The embodiments herein can comprise hardware and software elements. The embodiments that are implemented in software include but are not limited to, firmware, resident software, microcode, etc. The functions performed by various components described herein may be implemented in other components or combinations of other components. For the purposes of this description, a computer-usable or computer readable medium can be any apparatus that can comprise, store, communicate, propagate, or transport the program for use by or in connection with the instruction execution system, apparatus, or device.
[035] The illustrated steps are set out to explain the exemplary embodiments shown, and it should be anticipated that ongoing technological development will change the manner in which particular functions are performed. These examples are presented herein for purposes of illustration, and not limitation. Further, the boundaries of the functional building blocks have been arbitrarily defined herein for the convenience of the description. Alternative boundaries can be defined so long as the specified functions and relationships thereof are appropriately performed. Alternatives (including equivalents, extensions, variations, deviations, etc., of those described herein) will be apparent to persons skilled in the relevant art(s) based on the teachings contained herein. Such alternatives fall within the scope of the disclosed embodiments. Also, the words “comprising,” “having,” “containing,” and “including,” and other similar forms are intended to be equivalent in meaning and be open ended in that an item or items following any one of these words is not meant to be an exhaustive listing of such item or items, or meant to be limited to only the listed item or items. It must also be noted that as used herein and in the appended claims, the singular forms “a,” “an,” and “the” include plural references unless the context clearly dictates otherwise.
[036] Furthermore, one or more computer-readable storage media may be utilized in implementing embodiments consistent with the present disclosure. A computer-readable storage medium refers to any type of physical memory on which information or data readable by a processor may be stored. Thus, a computer-readable storage medium may store instructions for execution by one or more processors, including instructions for causing the processor(s) to perform steps or stages consistent with the embodiments described herein. The term “computer-readable medium” should be understood to include tangible items and exclude carrier waves and transient signals, i.e., be non-transitory. Examples include random access memory (RAM), read-only memory (ROM), volatile memory, nonvolatile memory, hard drives, CD ROMs, DVDs, flash drives, disks, and any other known physical storage media.
[037] It is intended that the disclosure and examples be considered as exemplary only, with a true scope of disclosed embodiments being indicated by the following claims.
,CLAIMS:
1. A processor implemented method for predicting failures in software processes, the method comprises:
fetching (202), using a scan bot implemented by one or more hardware processors, an input data from a data source, wherein the data source receives the input data from a centralized data lake configured with a plurality of software applications for monitoring failures, wherein the input data is the fault event obtained from the plurality of software applications;
parsing (204), via the one or more hardware processors (104), the input data from the data source into a log parser;
accessing (206), via the one or more hardware processors (104), an reference database (112) comprising a reference data for the input data, wherein the reference database (112) comprises previously detected fault related events;
determining (208), via the one or more hardware processors (104), a correlation factor corresponding to the input data which indicates a failure alert using natural language processing (NLP) by:
creating, using a correlation technique, a correlation schema for the input data;
calculating, dynamic weights for the input data using the correlation schema and the reference database, wherein the reference database is utilized as ground truth for the input data;
calculating, using an influencer data analyzer (ID) module, a correlation factor for the input data using a mean time between failures (MTBF); and
predicting (210), via the one or more hardware processors (104), using a predictor model (110), a failure prediction metrics corresponding to the input data based on a fault threshold range, the correlation factor and the reference database (112).
2. The method as claimed in claim 1, wherein predicting the failure prediction metrics using the predictor model (110) comprises:
dynamically determining, using a threshold range adjustor, the fault threshold range corresponding to the input data;
loading, based on the fault threshold range, the input data into a feature store and a bot memory; and
determining, an anomaly from the input data by comparing the correlation factor with respect to the fault threshold range.
3. The method as claimed in claim 2, wherein the fault threshold range is the dynamically determined variation between a minimum range value and a maximum range value for the input data based on the reference database in accordance with time drift.
4. The method as claimed in claim 2, wherein the fault threshold range identifies the failure alerts for the input data by eliminating noise.
5. The method as claimed in claim 1, wherein the dynamic weights for the input data are calculated based on a closely coupled weight and the reference database, wherein the closely coupled weight are identified based on multi variate positioning of failure alerts at different points in time.
6. The method as claimed in claim 1, wherein the correlation factor for the input data is calculated by,
applying, eigen factor using the mean time between failures and the failure alerts, wherein the mean time between failures is the ratio of total operational time with the total number of failures; and
determining, the change in the weights based on the time drift of the correlation factor.
7. A system (100) for predicting failures in software processes, the system (100) comprising:
a memory (102) storing instructions;
one or more Input / Output (I/O) interfaces (106);
and one or more hardware processors (104) coupled to the memory (102) via the one or more I/O interfaces (106), wherein the one or more hardware processors (104) are configured by the instructions to:
fetch, using a scan bot, an input data from a data source, wherein the data source receives the input data from a centralized data lake configured to a plurality of software applications for monitoring failures, wherein the input data is a fault event obtained from the plurality of software applications;
parse, the input data from the data source into a log parser;
access, a reference database comprising a reference data for the input data, wherein the reference database comprises previously detected failure related events;
determine, a correlation factor corresponding to the input data which indicates a failure alert using natural language processing (NLP) by,
creating, using a correlation technique, a correlation schema for the input data;
calculating, dynamic weights for the input data using the correlation schema and the reference database, wherein the reference database is utilized as ground truth for the input data;
calculating, using an influencer data analyzer (ID) module, a correlation factor for the input data using a mean time between failures (MTBF); and
predict, using a predictor model, a failure prediction metrics corresponding to the input data based on a fault threshold range, the correlation factor and the reference database.
8. The system (100) as claimed in claim 7, wherein predicting the failure prediction metrics using the predictor model (110) comprises:
dynamically determining, using a threshold range adjustor, the fault threshold range corresponding to the input data;
loading, based on the fault threshold range, the input data into a feature store and a bot memory; and
determining, an anomaly from the input data by comparing the correlation factor with respect to the fault threshold range.
9. The system (100) as claimed in claim 8, wherein the fault threshold range is the dynamically determined variation between a minimum range value and a maximum range value for the input data based on the reference database in accordance with time drift.
10. The system (100) as claimed in claim 8, wherein the fault threshold range identifies the failure alerts for the input data by eliminating noise.
11. The system (100) as claimed in claim 7, wherein the dynamic weights for the input data are calculated based on a closely coupled weight and the reference database, wherein the closely coupled weight are identified based on multi variate positioning of failure alerts at different points in time.
12. The system (100) as claimed in claim 7, wherein the correlation factor for the input data is calculated by,
applying, eigen factor using the mean time between failures and the failure alerts, wherein the mean time between failures is the ratio of total operational time with the total number of failures; and
determining, the change in the weights based on the time drift of the correlation factor.