Downtime prediction for management of machines in manufacturing network

Abstract

A method of managing a manufacturing network includes obtaining historical alarm data indicative of alarm state information for each of a plurality of alarms during a historical time period. At least one alarm of the plurality of alarms is associated with a target machine in the manufacturing network and at least one other alarm of the plurality of alarms is associated with at least one other machine upstream or downstream of the target machine in the manufacturing network. The method also includes executing a trained machine learning model using the historical alarm data to generate a downtime prediction for the target machine during a future time interval. The trained machine learning model takes the historical alarm data during the historical time period as an input to generate the downtime prediction. The downtime prediction is provided to facilitate management of the manufacturing network.

Description

DOWNTIME PREDICTION FOR MANAGEMENT OF MACHINES IN MANUFACTURING NETWORKFIELD OF THE INVENTION

[0001] The present disclosure relates generally to monitoring and maintenance of interconnected machines, such as in manufacturing networks. More specifically, the present disclosure relates to downtime prediction for the management of machines in a manufacturing network.BACKGROUND OF THE INVENTION

[0002] Machines used in certain scenarios and applications interact with other machines. In a manufacturing network, for example, different machines may perform different functions at different stages of the manufacturing process. A given machine in the manufacturing network may receive products and / or signals from one or more other machines and / or supply products and / or signals to one or more other machines. The machines may be outfitted with a variety of sensors that can detect various issues (e.g., a filling line is clogged, gripper did not close). Each sensor may trigger an alarm associated with a detected condition. Based on the number of sensors and machines involved in a given scenario, the alarm data generated (e.g., during manufacturing of a batch of a product) can be substantial. For example, a single assembly line may include over 3000 unique types of alarms, and over 13 million alarm records may be generated during a manufacturing interval.SUMMARY OF THE INVENTION

[0003] According to an exemplary embodiment, a method of managing a manufacturing network includes obtaining historical alarm data indicative of alarm state information for each of a plurality of alarms during a historical time period. At least one alarm of the plurality of alarms is associated with a target machine in the manufacturing network and at least one other alarm of the plurality of alarms is associated with at least one other machine upstream or downstream of the target machine in the manufacturing network. The method also includes executing a trained machine learning model using the historical alarm data to generate a downtime prediction for the target machine during a future time interval. The trained machinelearning model takes the historical alarm data during the historical time period as an input to generate the downtime prediction. The downtime prediction is provided to facilitate management of the manufacturing network.

[0004] According to another exemplary embodiment, a method of managing a manufacturing network includes obtaining historical alarm data indicative of alarm state information for each of a plurality of alarms at each of a plurality of time intervals within a historical time period. At least one alarm of the plurality of alarms is associated with a target machine in the manufacturing network and at least one other alarm of the plurality of alarms is associated with at least one other machine upstream or downstream of the target machine in the manufacturing network. The method also includes selecting a target alarm among the plurality of alarms, identifying one or more correlated alarms among the plurality of alarms that are correlated with the target alarm, and creating hypothetical alarm data indicative of the alarm state information of the plurality of alarms during the historical time period with modifications to the alarm state information of the target alarm and one or more of the one or more correlated alarms for one or more of the plurality of time intervals. A trained machine learning model is implemented to predict hypothetical downtime of the target machine of the manufacturing network based on the hypothetical alarm data to facilitate management of the manufacturing network.

[0005] It is noted that techniques for implementing downtime prediction for management of machines in a manufacturing network having various different features are disclosed herein and these features may be combined in various different configurations, including configurations not specifically illustrated or discussed. Although several different combinations of such features are described herein, a person having ordinary skill in the art will realize that further such combinations not explicitly described herein are also possible and enabled by the present disclosure and are within the scope of the present application. Additionally, although various techniques are disclosed herein for attaining the disclosed features, a person having ordinary skill in the art will realize that some modifications to the disclosed techniques may be possible and within the scope of the disclosed techniques. It is also to be understood that the phraseology and terminology employed herein are for the purpose of description and should not be regarded as limiting.BRIEF DESCRIPTION OF THE DRAWINGS

[0006] Various aspects, techniques, and embodiments of the present technology disclosed herein are described below with reference to the accompanying drawings. It should be appreciated that the figures are not necessarily drawn to scale. Items appearing in multiple figures may be indicated by the same reference numeral. For purposes of clarity, not every component may be labeled in every figure. Features of the present technology will become more apparent, and techniques for how to attain the features of the present technology, will be better understood by reference to the following detailed description considered in conjunction with the accompanying drawings, wherein:

[0007] FIG. 1 is a block diagram of aspects of an exemplary manufacturing network according to one or more embodiments.

[0008] FIG. 2 is a process flow of an exemplary method of managing a manufacturing network using downtime prediction according to one or more embodiments.

[0009] FIG. 3 details aspects of the method shown in FIG. 2 pertaining to obtaining predicted downtime.

[0010] FIG. 4 details aspects of the method shown in FIG. 2 pertaining to identifying correlated alarms.

[0011] FIG. 5 details aspects of the method shown in FIG. 2 pertaining to pruning alarms to generate hypothetical data.

[0012] FIG. 6 is a block diagram detailing aspects of the controller that performs alarm pruning and downtime prediction according to exemplary one or more embodiments.DETAILED DESCRIPTION OF THE INVENTION

[0013] Provided herein are exemplary implementations of obtaining downtime predictions for machines within a manufacturing network. The downtime predictions can be obtained using recorded data of alarm activations, as well as modified versions of the recorded data that reflect hypothetical resolution of certain issues. The techniques can be used, for example, to determine the impact of addressing those certain issues on the predicted downtime of a machine and may help to prioritize maintenance and repair activities in the manufacturing network.

[0014] As noted, sensors may be positioned at different places within and / or around machines of a manufacturing network. The sensor outputs may activate corresponding alarms based on detected activity (e.g., clog in a filling line, failure of grabbing or gripping device to open or close, lack of needed input to a machine). Over a period of operation, a large number of alarm records may be generated for each of the machines of the manufacturing network based on the various sensors. Analyzing and addressing every alarm activation recorded in the alarm records may be time and resource-prohibitive.

[0015] The inventors have recognized and appreciated the need to identify alarms that, when addressed, have an impact on improving (i.e., reducing) downtime of a given machine. The inventors have developed techniques to predict downtime based on historical records of alarm activations.

[0016] In some embodiments, the inventors have appreciated that the downtime of a target machine during a time interval may be affected and / or predicted using recently observed alarm data associated not only with the target machine, but also associated with other machines within the manufacturing network, such as machines upstream or downstream from the target machine. This is because the target machine’s downtime, as well as the state of one or more alarms associated with the target machine, are correlated with alarms at other machines. For example, a given alarm indicating lack of needed input at the target machine may be related to one or more alarms at an upstream machine that supplies the target machine. This may be because the lack of supply to the target machine (indicated by the given alarm) may result from the other upstream machine experiencing an actuator failure (as indicated by the other alarm), for example. In another example, a given alarm indicating an inability to offload output components at the target machine (e.g., because a conveyer belt responsible for offloading output is at capacity) may also be correlated with one or more alarms at a downstream machine indicating the downstream machine is unable to process further components. This is because the downstream machine’s inability to process components is directly causing, and therefore is correlated with, the target machine’s inability to offload output components. As such, the inventors have appreciated that the pattern of alarm activations at the target machine as well as in one or more other machines within the manufacturing network during a historical time period (e.g., 10 minutes) could be used to predict the target machine’s downtime for a future time interval following the historical time period (e.g., the 10 seconds immediately following the 10 minute historical time period).

[0017] The inventors have further appreciated that a machine learning model may be trained to generate such predictions accurately. For instance, a machine learning model may be trained based on historical data comprising (i) alarm state information for multiple historical periods (e.g., each 10 minutes in duration) for alarms both at the target machine and at one or more other machines within the manufacturing network, and (ii) ground truth information regarding the historically observed downtime that was experienced at the target machine in a time interval (e.g., 10 seconds) immediately following the historical period. The trained machine learning model may then be used to use similar alarm state information for a historical period to predict a downtime that would result from the historical period. For instance, the machine learning model may output a proportion of a future time interval (e.g., 10 seconds following the historical time period) in which the target machine is expected to be in a nonrunning state. Such a trained model may be useful for forecasting downtime at the target machine given observed alarm activations data at the target machine as well as at one or more other machines in the manufacturing network. Such a trained model may also be used to generate multiple forecasted downtimes (e.g., based on multiple sets of historical data), and the multiple forecasted downtimes may be aggregated to form an aggregate estimate of downtime over a longer prediction time period (e.g., one day). Such an aggregated estimate of downtime may also be useful for generating a baseline for downtime to be compared against a hypothetical prediction of downtime based on modified historical data.

[0018] In some embodiments, the historical alarm data records may be modified to create a hypothetical record based on the assumption that a given issue associated with a given alarm is addressed. That is, the given alarm may be pruned from the historical record to create the hypothetical record. The hypothetical record may then be used to determine a hypothetical predicted downtime for a given machine associated with the given (pruned) alarm. By comparing predicted downtime with hypothetical predicted downtime resulting from pruning different alarms associated with a given machine, the comparison may facilitate identifying which alarm(s), if addressed (i.e., pruned), have the highest impact on predicted downtime (i.e., reduce downtime the most). This may, in turn, facilitate establishing a priority in addressing alarms in the future.

[0019] In some embodiments, obtaining a hypothetical prediction of downtime at the given machine based on pruning the given alarm may benefit from identifying and additionally pruning other correlated alarm(s). The pruning of correlated alarms may take into account atime lag at which the target alarm and correlated alarm are correlated. For example, if the target alarm is associated with an issue that will subsequently cause an issue in another (downstream) machine, the correlated alarm at the other machine is likely to be activated at some time lag after activation of the target alarm (i.e., after a time it takes for the issue at the target machine to reach the other machine). Additionally, pruning the other alarm to create the hypothetical record may be performed to maintain a ratio at which the given alarm and the other alarm are activated in the historical records.

[0020] In this way, identifying and pruning correlated alarms when a target alarm is pruned in the hypothetical record, and then using the hypothetical record to generate a hypothetical predicted downtime, may help improve the accuracy of the hypothetical predicted downtime. Improving the accuracy of the hypothetical predicted downtime allows manufacturing network operators to more accurately predict the impact on downtime that is likely to result from decreasing the incidence of a specific target alarm. In this way, manufacturing network operators are better able to determine which alarms out of the plurality of alarms to prioritize for investigation, maintenance, repair, or optimization.

[0021] Following below are more detailed descriptions of various concepts related to, and embodiments of, techniques described above. It should be appreciated that various aspects described herein may be implemented in any of numerous ways. Examples of specific implementations are provided herein for illustrative purposes only. In addition, the various aspects described in the embodiments below may be used alone or in any combination and are not limited to the combinations explicitly described herein. In particular, although examples of the downtime prediction and alarm pruning are described herein in connection with a manufacturing network, the techniques are not limited to machines in a manufacturing network. For example, the alarm pruning and downtime prediction analysis techniques described herein may also be used in connection with a network for inspecting, processing, sorting, or packaging items. Generally, the correlation determination that may be part of the alarm pruning process detailed herein can be used to facilitate a determination of a correlation between any two alarms.

[0022] FIG. 1 is a block diagram of a manufacturing system 100 according to one or more embodiments. The manufacturing system 100 includes a manufacturing network 105. The exemplary manufacturing network 105 shown in FIG. 1 includes machines 110-1 through 110-8 (generally referred to as machine (s)l 10) interconnected by conveyer belts 120a through120g (generally referred to as conveyer belt(s) 120). For example, machines 110-1 and 110-2 are connected by conveyer belt 120a, and machines 110-7 and 110-8 are connected by conveyer belt 120g. The relative differences in length among the conveyer belts 120 are intended to convey that different conveyer belts 120 connecting different pairs of machines 100 may be of different lengths and / or may operate at different speeds.

[0023] The exemplary illustration in FIG. 1 is not intended to limit the numbers or arrangements of machines 110 that make up a manufacturing network 105. For example, machines 110-3, 110-5, 110-6, 110-8 are shown obtaining inputs of raw materials or components from outside the manufacturing network 105, while a product is shown output from machine 110-1. In alternate arrangements, other machines 110 in the manufacturing network 105 (e.g., machine 110-1, 110-2, 110-4, and / or 110-7) may also obtain input from outside the manufacturing network 105. In addition, while the flow of components to produce a product at machine 110-1 is indicated, an opposite flow, returning empty pucks that held those components in place, may also be part of the manufacturing network 105. The specific configuration of the manufacturing network 105 is not relevant to the embodiments detailing aspects of performing downtime prediction and alarm pruning, in consideration of correlated alarms, to predict hypothetical improvement in downtime.

[0024] Exemplary sensors 125 are indicated in FIG. 1. Sensors 125 are shown at an interface between a machine 110 and conveyor belt 120 and within some machines 110. Each sensor 125 may be associated with one or more alarms 126. For example, sensors 125 may be positioned to monitor operation of actuators and pushers within the manufacturing network 105. Sensors 125 may be positioned at different areas, referred to as stations, for example, within machines 110. Some sensors 125 may activate an alarm if expected components are not at the station to facilitate further production. For example, a sensor 125 may indicate that a linear tracker at a given station within a given machine 110 is starved for components. It should be appreciated that these examples are only illustrative and not indicative of the numerous sensors 125 and associated alarms 126 that may be distributed throughout a given manufacturing network 105.

[0025] The manufacturing system 100 also includes a controller 130 that may perform the alarm pruning and prediction of hypothetical machine downtime to facilitate prioritizing alarms for resolution. The controller 130 is further discussed with reference to FIG. 6. The controller 130 may obtain historical records indicating which alarms were activated during aperiod of time. Ultimately, pruning alarms from the historical records, pruning an appropriate number of correlated alarms, and obtaining hypothetical downtime predictions may facilitate triage of the various alarms 126 of the manufacturing network 105 to determine which alarm(s) 126 to investigate for possible action to improve operation of the manufacturing network 105.

[0026] FIG. 2 is a process flow of an exemplary method 200 of managing a manufacturing network 105 using downtime prediction according to one or more embodiments. For explanatory purposes, target machine 110 is used to refer to a machine 110 of interest and target alarm 126 is used to refer to an alarm 126 of interest.

[0027] At 210, obtaining historical data 310 (FIG. 3) of alarm records for a target machine 110 and other machines 110 refers to obtaining data that indicates times of activation of alarms 126 associated with the target machine 110 and the other machines 110. An exemplary representation of historical data 310 is shown in FIG. 3. Other machines 110 of interest at 210 may be, for example, neighboring machines 110 of the target machine 110 whose activities may affect or be affected by activities at the target machine 110 and, thus, whose alarms 126 may be correlated with a target alarm 126 associated with the target machine 110. For example, in the exemplary manufacturing network 105 shown in FIG. 1, if machine 110-2 is the target machine 110, then neighboring machines 110-1, 110-3, and 110-4 may be the other machines 110 whose alarm activation information is also obtained.

[0028] At 220, obtaining predicted downtime for the target machine 110 using the historical data 310 (obtained at 210) is detailed with reference to FIG. 3. The predicted downtime may be a value between 0 and 1 that indicates a proportion (e.g., a percentage) of a subsequent time interval (beyond the time intervals in the historical data 310) during which the target machine 110 is predicted to be in a waiting state, in which it is not executing its normal operations.

[0029] As discussed with reference to FIG. 3, predictions may be obtained for multiple intervals and aggregated to obtain an aggregated downtime prediction for the target machine 110. For example, the processes discussed with reference to FIG. 3 may be performed using a first set of historical data 310 representing 10 minutes separated into 10 second intervals. The prediction of downtime may be obtained for a subsequent 10 second interval following the historical time period represented by the historical data 310. The processes of FIG. 3 may then be repeated for one or more different sets of historical data 310 that may or may not partially overlap with the first and other sets of historical data 310. For example, the first set of historicaldata 310 may be a subset of 10 minutes from a total record of hours or days of alarm data. Thus, additional subsets of that record may form one or more additional sets of historical data 310.

[0030] Repeating the processes of FIG. 3 for each set of historical data 310 results in obtaining additional predictions for different time intervals. The first prediction and one or more additional predictions may then be aggregated to obtain an aggregate downtime prediction for all the predicted time intervals. For example, the first prediction and one or more additional predictions (each of which predict downtime over a 10 second interval in the exemplary case) may be aggregated to obtain an aggregate downtime estimate for an entire day.

[0031] FIG. 3 details aspects of the method 200 shown in FIG. 2 pertaining to obtaining predicted downtime (at 220). An exemplary representation of historical data 310 (obtained at 210) is shown as a two-dimensional (2D) array. Obtaining the historical data 310 may refer to the controller 130 accessing the historical data 310 from memory based on previously recording the alarm activations. During operation of the manufacturing network 105, a separate time series may be stored for each alarm 126 indicating activation times for the alarm 126.

[0032] The historical data 310 may result from processing and combining time series information for some or all of the alarms 126 associated with one or more machines 110. The historical data 310 may include stored information for all alarms 126 of the target machine 110, as well as for other machines 110 (e.g., neighboring machines) of interest. The other machines 110 may be upstream or downstream of the target machine 110. In some embodiments, a subset of all the alarms 126 may be part of the historical data 310.

[0033] In the 2D array, alarms 126 are shown along one of the two dimensions (e.g., each column pertains to a different alarm 126 according to the example in FIG. 3) and are indexed by i. Time intervals (e.g., 10 seconds) are shown along the other of the two dimensions (e.g., each row pertains to a time interval according to the example in FIG. 3) and are indexed by j. The time intervals together may represent a duration of manufacture (e.g., 10 second intervals within 10 minutes of manufacturing).

[0034] A given cellij of the 2D array of historical data 310 indicates a value between 0 and 1 that indicates a proportion (percentage) of the time interval j that the alarm 126 i is active (i.e., on) , for example. Thus, cell2,5 = 0 indicates that alarm 126 2 was not active for any duration (e.g., any of the 10 seconds) during time interval 5. As another example, cell3,4= 0.6 indicates that alarm 126 3 was active for 60 percent of the duration (e.g., 6 of the 10 seconds) during time interval 4. The information encoded in a column of the 2D array may also be depicted in a graphical timeline format as shown in FIG. 3. Each time index on the timeline may represent a time interval j. As explained above, the timeline may fluctuate between the values of 0 and 1, where the value of the timeline at any given time index j indicates the proportion (percentage) of the time interval j that the alarm was active (i.e., on).

[0035] Obtaining predicted downtime (at 220) may involve the controller 130 implementing machine learning. For example, a general-purpose machine learning model such as XGBoost may be implemented according to some embodiments. In some other embodiments, a particular type of machine learning model such as a recurrent neural network (RNN) and, more specifically, a long-short term memory (LSTM) RNN may be implemented. An RNN can look at historical data 310 and learn the probability distribution of the next sequence of the historical data 310.

[0036] The machine learning model may be trained with historical data or simulated data. For example, thousands of sets of historical data 310, each including alarm activation information for 10 second intervals over a 10-minute period, may be obtained to perform training. The training data may also include ground truth data that indicates observed downtime of a target machine for the 10-second interval immediately following each of the sets of historical data 310. It should be clear that the exemplary 10-second interval and 10- minute data set are only discussed for explanatory purposes. The processes discussed herein may be applied to historical data 310 of any duration and including time intervals of any duration. Also, according to additional embodiments, parameters of the machine learning model may be continuously updated as historical data is obtained in a continuous learning scheme.

[0037] Returning now to the discussion of FIG. 2, at 230, selecting a target alarm 126 refers to selecting one of the alarms 126 associated with the target machine 110. Additionally at 230, finding correlated alarms 126 refers to identifying alarms 126 at the target machine 110 or at other (e.g., neighboring) machines 110 that are correlated with the target alarm 126. In general, an alarm may be considered “correlated” to a target alarm 126 if the alarm tends to be activated (e.g., with probability X) within a certain time t before or a short time after an activation of the target alarm. The value for the time t may vary based on the type of machines and / or manufacturing network. For instance, in some embodiments, t may be as short as a fewmicroseconds or a few seconds, while in other embodiments, t may be as long as multiple minutes, hours, or even days. The time t may be selected based on the frequency of alarms within the manufacturing network, and the likely time delays between propagation of alarms throughout the network, which is in turn affected by the length and speed of conveyer belts that transfer components between machines and the speed at which machines process components. The value for probability X may also be varied depending on the type of machines and / or manufacturing network. Setting the value for X at a high level (e.g., 95% or 99%) may lead to fewer alarms being designated as “correlated”, while setting the value for X at a low level (e.g., 10% or 20%) may lead to more alarms being designated as correlated. The choice for the value X for any particular embodiment, therefore, may depend on computational, time, and / or memory limitations.

[0038] In some embodiments, correlated alarms 126 may be identified based on an operator’s input or judgment, which in turn may be influenced by the topology of the manufacturing network as well as the tasks being performed by the machines therein. For instance, since the operator knows or appreciates that machine 110-1 is immediately downstream of machine 110-2, the operator may identify alarms at machines 110-1 and 110-2 to be correlated, because if machine 110-2 stops, machine 110-1 will be starved for components and will also be forced to stop (and conversely, if machine 110-1 stops, machine 110-2 will also be forced to stop because it can no longer offload components).

[0039] In some embodiments, such an identification of correlated alarms may be done through application of pre-specified rules. For instance, once an operator selects a target machine, all alarms associated with machines within Y machines upstream or downstream of the target machine may be automatically designated as correlated alarms (where Y is an operator-configurable number).

[0040] Another exemplary method for identifying correlated alarms 126 is detailed with reference to FIG. 4. FIG. 4 details aspects of the processes shown in FIG. 2 pertaining to identifying correlated alarms 126 (at 230) to the target alarm 126. For a given target alarm 126, a correlated alarm 126 may be associated with the same (target) machine 110 or one or more other machines 110.

[0041] In some embodiments, for efficiency, the other machines 110 may be limited to being neighboring machines 110, for example. That is, according to the arrangement shown in FIG. 1, an issue at machine 110-7 may indirectly affect machine 110-2, as well as directlyaffect machine 110-4. In this case, an alarm 126 at machine 110-7 corresponding to the issue may have a correlated alarm 126 at machine 110-2.

[0042] To implement the processes of the method 200 efficiently, such a correlation may be found via the intervening machine 110-4 rather than by considering all machines 110 of the manufacturing network 105 in the historical data 310 with the target machine 110. Thus, an alarm 126 at machine 110-7 may be found to be correlated with an alarm 126 at machine 110-4, when machine 110-7 is considered as a target machine 110. Then, the same alarm 126 of machine 110-4 may be found to be correlated with an alarm 126 at machine 110-2, when machine 110-4 is considered as a target machine 110 in a subsequent implementation of the processes of the method 200.

[0043] In other embodiments, for a given target alarm 126, all other alarms 126 in the historical data 310 (including but not limited to alarms associated machines that neighbor the target machine) may be processed, in turn, as shown in FIG. 4, to determine whether the target alarm 126 and the other alarm 126 are correlated. In some embodiments, to save on computational effort, some alarms 126 in the historical data 310 may be eliminated as potentially correlated alarms 126 and the processes shown in FIG. 4 may only be implemented for the remaining alarms. The identification of potentially correlated alarms 126 or elimination of some alarms 126 from consideration may be based on prior knowledge of the manufacturing network 105 or the particular target machine 110, for example.

[0044] For the target alarm 126 and a given other alarm 126, the correlation process at FIG. 4 begins by obtaining the array 410 associated with the target alarm 126 and the array 420 associated with the given other alarm 126. According to the exemplary historical data 310 shown in FIG. 3, each of the arrays 410, 420 is, respectively, the column of the historical data 310 that pertains to the target alarm 126 and the column that pertains to the given other alarm 126. Each of those columns is a one-dimensional array with N elements, which are time intervals indexed by j .

[0045] A series of multiplication results 430 are obtained, as shown, for different offsets between the target alarm array 410 and the other alarm array 420. Specifically, as shown, the offsets are from -n to n. As used herein, an “offset” refers to an offset in time. Thus, for example, alarm array 420 being “offset” from target alarm array 410 by a certain offset value t means that alarm array 420 has been shifted in time by a number of time intervals equal to the value t, wherein t may be a positive or a negative value. At each offset, the alignedelements of the arrays 410, 420 are multiplied and added together to obtain a result 430 associated with the particular offset. In some embodiments, only N-n aligned elements of the arrays 410, 420 are multiplied and added together to obtain result 430 associated with the particular offset, such that the same number of aligned elements are multiplied and summed regardless of the offset. In other embodiments where N is much greater than n, all or most of the aligned elements of the arrays 410, 420 may be multiplied. This is because when N » n, the impact of having different numbers of aligned elements multiplied and summed together at different offsets may be negligible. Exemplary offsets shown in FIG. 4 are -n, 0, and n. Thus, results 430[-n], 430[0], and 430[n] are obtained for the exemplary positions of the arrays 410, 420 shown in FIG. 4 and results 430 are also obtained for all other offsets of the array 420 between -n and n. The results 430 are plotted and a threshold value 440 is applied.

[0046] A peak value of the results 430 that exceeds the threshold value 440 indicates correlation between the target alarm 126 and the other alarm 126. In addition, the particular offset associated with the peak value of the results 430 that exceeds the threshold value 440 indicates the time lag 450 at which the target alarm 126 and other alarm 126 are correlated. For example, if the time lag 450 for correlation is -1, then the target alarm 126 at a given time interval j is correlated with the other alarm at time interval j-1. That is, the correlation result indicates that the other alarm 126 precedes the target alarm 126 by one time interval. Alternately, a time lag 450 of +2 indicates that the target alarm 126 is correlated with and precedes the other alarm 126 by two time intervals.

[0047] While the correlation result indicates whether a correlated alarm 126 precedes or follows the target alarm 126, the correlation result is not an indication of causality. For example, if a correlated alarm 126 precedes the target alarm 126, the condition causing the correlated alarm 126 is not necessarily the cause of the target alarm 126. Instead, another alarm 126 upstream of the correlated alarm 126 may be associated with the cause.

[0048] Returning again to the discussion of FIG. 2, at 240, generating hypothetical data 510 by pruning the target alarm 126 and correlated alarms 126 in the historical data 310 (obtained at 210) is further discussed with reference to FIG. 5. Pruning refers to eliminating target alarm 126 activations recorded in the historical data 310. Pruning correlated alarms 126 may include pruning activations of each given correlated alarm 126 at a time lag (ahead of or behind) relative to a pruned target alarm 126. The time lag may be the time lag at which the target alarm 126 and the given correlated alarm 126 are correlated. Additionally, whether ornot a given correlated alarm 126 is pruned may be based on maintaining the ratio of activations of the target alarm 126 and the correlated alarm 126 in the historical data 310.

[0049] FIG. 5 details aspects of the method shown in FIG. 2 pertaining to pruning alarms 126 to generate hypothetical data 510 (at 240). Hypothetical data 510 is shown in FIG.5. As previously noted, the hypothetical data 510 is based on historical data 310 with some of the elements of the 2D array modified. Specifically, the target alarm 126 is pruned. That is, in some percentage of the cells of the 2D array representing the historical data 310 pertaining to the target alarm 126 T, the value is set to 0 (i.e., proportion at which the target alarm 126 T is activated in one or more of the time intervals) for the target alarm 126 i=T is set to 0). The number of time intervals j (e.g., percentage of total intervals in the historical data 310) for which cells pertaining to the target alarm 126 T are set to a value of 0 may be predetermined, iteratively changed, or selected (e.g., based on knowledge of current conditions of the manufacturing network 105).

[0050] For each time interval j for which the historical data of the target alarm 126 T is modified, other alarms 126 found to be correlated with the target alarm 126 (at 230) may also be modified. This may result in hypothetical data 510 that is more representative of the way the manufacturing network 105 functions. The correlated alarms 126 may or may not be pruned, as detailed, and, when pruned, may be pruned at a different time interval than the target alarm 126.

[0051] For explanatory purposes, two correlated alarms 126 X and Y are indicated in FIG. 5. In the exemplary case, alarm 126 X is correlated with the target alarm 126 T at a time lag 450 of +2, and alarm 126 Y is correlated with the target alarm 126 T at a time lag 450 of - 1. One cell of the historical data 310 pertaining to the target alarm 126 T is set to a value of 0 (i.e., pruned). That cell is at time interval j’ and is indicated as T(j’) in FIG. 5. Thus, the pruned time interval j ’ of the target alarm 126 T corresponds with alarm 126 X at time interval j ’+2 and with alarm 126 Y at time interval j ’-1. Those cells are indicated as X(j ’+2) and Y(j 1), respectively.

[0052] As previously noted, when a target alarm 126 is pruned, a correlated alarm 126 may or may not be pruned. The probability that a given correlated alarm 126 will be pruned may be the same as the probability that the given correlated alarm 126 will be activated at any given time interval j . Thus, for example, the probability that the value of cellX,(j ’+2) = 0 may be the same as the probability that alarm 126 X is activated at any given time interval j, whichmay be determined from the historical data 310. Similarly, the probability that the value of cellY,(j’-l) = 0 may be the same as the probability that alarm 126 Y is activated at any given time interval j, which may also be determined from the historical data 310. Pruning a given correlated alarm 126 according to the probability that the given correlated alarm 126 will be activated at any given time interval j helps preserve the ratio of activations between the target alarm 126 and the given correlated alarm 126. This allows the hypothetical data 510 to more accurately simulate the effects of pruning the target alarm 126, which in turn helps generate more accurate hypothetical predicted downtime at step 250.

[0053] Returning to the discussion of FIG. 2, at 250, obtaining a hypothetical predicted downtime for the target machine 110 using the hypothetical data 510 may involve implementing the processes at 220, including the aggregation of hypothetical predictions, over multiple intervals. That is, as discussed with reference to FIG. 3 for predicted downtime obtained using the historical data 310, hypothetical predicted downtime (e.g., for a 10 second interval following the last time interval in the hypothetical data 510) may be obtained for a number of sets of hypothetical data 510. The hypothetical predicted downtime obtained from each set may then be aggregated to obtain an aggregatehypothetical downtime prediction (e.g., over the course of a day). Additionally at 250, the predicted downtime or predicted aggregate downtime (from 220) may be compared with the hypothetical predicted downtime or predicted hypothetical aggregate downtime to determine a change (e.g., percentage decrease in downtime) based on the hypothetical data 510 which equates to addressing the issue associated with activation of the target alarm 126. For instance, by comparing the predicted aggregate downtime with the predicted hypothetical aggregate downtime, an operator may quantify an expected effect on aggregate downtime from pruning the target alarm and correlated alarms (as discussed previously).

[0054] As indicated in FIG. 2, the processes at 230-250 may be repeated. That is, for each of a number of alarms 126 of the target machine 110 (selected, in turn, as the target alarm 126 at 230), the improvement in predicted downtime resulting from addressing the issue associated with the alarm 126 may be estimated (at 250). At 260, managing the manufacturing network 105 based on the results of the comparisons (at 250) may include determining which alarm 126, when selected as the target alarm 126 (at 230), results in the highest decrease in predicted downtime of the target machine 110 (at 250). For example, the alarm 126 that, when eliminated by addressing the issue that activates the alarm 126, results in the largest decreasein predicted downtime of the target machine 110 may be the alarm 126 that is addressed first when it activates, along with other alarms 126 of the target machine 110, in the future.

[0055] FIG. 6 is a block diagram detailing aspects of the controller 130 that performs alarm pruning and downtime prediction according to exemplary one or more embodiments. The controller 130 may include one or more processors 610 that implement the processes shown in FIG. 2, for example. Instructions processed by the one or more processors 610 to implement the method 200 may be stored in non-transitory computer-readable media such as non-volatile storage 620, for example. Any one or more processors 610 may be referred to as “a processor,” and subsequent reference to “the processor” should be interpreted to refer to any one or more of the processors 610. That is, different ones of the processors 610 may implement different aspects of the method 200 and other processes discussed herein. Memory 630 may store historical data 310 and other data. A display 640 may indicate which alarms 126 may be higher priority alarms 126 to address based on the results of implementing the method 200 shown in FIG. 2.

[0056] Techniques operating according to the principles described herein may be implemented in any suitable manner. The processing and decision blocks of the flow charts above represent steps and acts that may be included in algorithms that carry out these various processes. Algorithms derived from these processes may be implemented as software integrated with and directing the operation of one or more single- or multi-purpose processors, may be implemented as functionally-equivalent circuits such as a Digital Signal Processing (DSP) circuit or an Application-Specific Integrated Circuit (ASIC), or may be implemented in any other suitable manner. It should be appreciated that the flow charts included herein do not depict the syntax or operation of any particular circuit or of any particular programming language or type of programming language. Rather, the flow charts illustrate the functional information one skilled in the art may use to fabricate circuits or to implement computer software algorithms to perform the processing of a particular apparatus carrying out the types of techniques described herein. It should also be appreciated that, unless otherwise indicated herein, the particular sequence of steps and / or acts described in each flow chart is merely illustrative of the algorithms that may be implemented and can be varied in implementations and embodiments of the principles described herein.

[0057] Accordingly, in some embodiments, the techniques described herein may be embodied in computer-executable instructions implemented as software, including asapplication software, system software, firmware, middleware, embedded code, or any other suitable type of computer code. Such computer-executable instructions may be written using any of a number of suitable programming languages and / or programming or scripting tools, and also may be compiled as executable machine language code or intermediate code that is executed on a framework or virtual machine.

[0058] When techniques described herein are embodied as computer-executable instructions, these computer-executable instructions may be implemented in any suitable manner, including as a number of functional facilities, each providing one or more operations to complete execution of algorithms operating according to these techniques. A “functional facility,” however instantiated, is a structural component of a computer system that, when integrated with and executed by one or more computers, causes the one or more computers to perform a specific operational role. A functional facility may be a portion of or an entire software element. For example, a functional facility may be implemented as a function of a process, or as a discrete process, or as any other suitable unit of processing. If techniques described herein are implemented as multiple functional facilities, each functional facility may be implemented in its own way; all need not be implemented the same way. Additionally, these functional facilities may be executed in parallel and / or serially, as appropriate, and may pass information between one another using a shared memory on the computer(s) on which they are executing, using a message passing protocol, or in any other suitable way.

[0059] Generally, functional facilities include routines, programs, objects, components, data structures, etc. that perform particular tasks or implement particular abstract data types. Typically, the functionality of the functional facilities may be combined or distributed as desired in the systems in which they operate. In some implementations, one or more functional facilities carrying out techniques herein may together form a complete software package. These functional facilities may, in alternative embodiments, be adapted to interact with other, unrelated functional facilities and / or processes, to implement a software program application.

[0060] Some exemplary functional facilities have been described herein for carrying out one or more tasks. It should be appreciated, though, that the functional facilities and division of tasks described is merely illustrative of the type of functional facilities that may implement the exemplary techniques described herein, and that embodiments are not limited to being implemented in any specific number, division, or type of functional facilities. In someimplementations, all functionality may be implemented in a single functional facility. It should also be appreciated that, in some implementations, some of the functional facilities described herein may be implemented together with or separately from others (i.e., as a single unit or separate units), or some of these functional facilities may not be implemented.

[0061] Computer-executable instructions implementing the techniques described herein (when implemented as one or more functional facilities or in any other manner) may, in some embodiments, be encoded on one or more computer-readable media to provide functionality to the media. Computer-readable media include magnetic media such as a hard disk drive, optical media such as a Compact Disk (CD) or a Digital Versatile Disk (DVD), a persistent or non-persistent solid-state memory (e.g., Flash memory, Magnetic RAM, etc.), or any other suitable storage media. Such a computer-readable medium may be implemented in any suitable manner. As used herein, “computer-readable media” (also called “computer- readable storage media”) refers to tangible storage media. Tangible storage media are non- transitory and have at least one physical, structural component. In a “computer-readable medium,” as used herein, at least one physical, structural component has at least one physical property that may be altered in some way during a process of creating the medium with embedded information, a process of recording information thereon, or any other process of encoding the medium with information. For example, a magnetization state of a portion of a physical structure of a computer-readable medium may be altered during a recording process.

[0062] Further, some techniques described above comprise acts of storing information (e.g., data and / or instructions) in certain ways for use by these techniques. In some implementations of these techniques — such as implementations where the techniques are implemented as computer-executable instructions — the information may be encoded on a computer-readable storage media. Where specific structures are described herein as advantageous formats in which to store this information, these structures may be used to impart a physical organization of the information when encoded on the storage medium. These advantageous structures may then provide functionality to the storage medium by affecting operations of one or more processors interacting with the information; for example, by increasing the efficiency of computer operations performed by the processor(s).

[0063] In some, but not all, implementations in which the techniques may be embodied as computer-executable instructions, these instructions may be executed on one or more suitable computing device(s) operating in any suitable computer system, or one or morecomputing devices (or one or more processors of one or more computing devices) may be programmed to execute the computer-executable instructions. A computing device or processor may be programmed to execute instructions when the instructions are stored in a manner accessible to the computing device or processor, such as in a data store (e.g., an on- chip cache or instruction register, a computer-readable storage medium accessible via a bus, a computer-readable storage medium accessible via one or more networks and accessible by the device / processor, etc.). Functional facilities comprising these computer-executable instructions may be integrated with and direct the operation of a single multi-purpose programmable digital computing device, a coordinated system of two or more multi-purpose computing device sharing processing power and jointly carrying out the techniques described herein, a single computing device or coordinated system of computing device (co-located or geographically distributed) dedicated to executing the techniques described herein, one or more Field- Programmable Gate Arrays (FPGAs) for carrying out the techniques described herein, or any other suitable system.

[0064] A computing device may comprise at least one processor, a network adapter, and computer-readable storage media. A computing device may be, for example, a desktop or laptop personal computer, a personal digital assistant (PDA), a smart mobile phone, a server, or any other suitable computing device. A network adapter may be any suitable hardware and / or software to enable the computing device to communicate wired and / or wirelessly with any other suitable computing device over any suitable computing network. The computing network may include wireless access points, switches, routers, gateways, and / or other networking equipment as well as any suitable wired and / or wireless communication medium or media for exchanging data between two or more computers, including the Internet. Computer-readable media may be adapted to store data to be processed and / or instructions to be executed by processor. The processor enables processing of data and execution of instructions. The data and instructions may be stored on the computer-readable storage media.

[0065] A computing device may additionally have one or more components and peripherals, including input and output devices. These devices can be used, among other things, to present a user interface. Examples of output devices that can be used to provide a user interface include printers or display screens for visual presentation of output and speakers or other sound generating devices for audible presentation of output. Examples of input devices that can be used for a user interface include keyboards, and pointing devices, such as mice,touch pads, and digitizing tablets. As another example, a computing device may receive input information through speech recognition or in other audible format.

[0066] Embodiments have been described where the techniques are implemented in circuitry and / or computer-executable instructions. It should be appreciated that some embodiments may be in the form of a method, of which at least one example has been provided. The acts performed as part of the method may be ordered in any suitable way. Accordingly, embodiments may be constructed in which acts are performed in an order different than illustrated, which may include performing some acts simultaneously, even though shown as sequential acts in illustrative embodiments.

[0067] Various aspects of the embodiments described above may be used alone, in combination, or in a variety of arrangements not specifically discussed in the embodiments described in the foregoing and is therefore not limited in its application to the details and arrangement of components set forth in the foregoing description or illustrated in the drawings. For example, aspects described in one embodiment may be combined in any manner with aspects described in other embodiments.

[0068] Use of ordinal terms such as “first,” “second,” “third,” etc., in the claims to modify a claim element does not by itself connote any priority, precedence, or order of one claim element over another or the temporal order in which acts of a method are performed, but are used merely as labels to distinguish one claim element having a certain name from another element having a same name (but for use of the ordinal term) to distinguish the claim elements.

[0069] Also, the phraseology and terminology used herein is for the purpose of description and should not be regarded as limiting. The use of “including,” “comprising,” “having,” “containing,” “involving,” and variations thereof herein, is meant to encompass the items listed thereafter and equivalents thereof as well as additional items.

[0070] The word “exemplary” is used herein to mean serving as an example, instance, or illustration. Any embodiment, implementation, process, feature, etc. described herein as exemplary should therefore be understood to be an illustrative example and should not be understood to be a preferred or advantageous example unless otherwise indicated.

[0071] To clarify the use of and to hereby provide notice to the public, the phrases “at least one of , , . . . and <N>” or “at least one of , , . . . <N>, or combinations thereof’ or “, , . . . and / or <N>” are defined by the Applicant in the broadest sense, superseding any other implied definitions hereinbefore or hereinafter unless expressly assertedby the Applicant to the contrary, to mean one or more elements selected from the group comprising A, B, . . . and N. In other words, the phrases mean any combination of one or more of the elements A, B, . . . or N including any one element alone or the one element in combination with one or more of the other elements which may also include, in combination, additional elements not listed.

[0072] While various embodiments have been described, it will be apparent to those of ordinary skill in the art that many more embodiments and implementations are possible. Accordingly, the embodiments described herein are examples, not the only possible embodiments and implementations. Furthermore, the advantages described above are not necessarily the only advantages, and it is not necessarily expected that all of the described advantages will be achieved with every embodiment.

[0073] Various aspects are described in this disclosure, which include, but are not limited to, the following aspects:

[0074] 1. A method of managing a manufacturing network, the method comprising: obtaining historical alarm data indicative of alarm state information for each of a plurality of alarms during a historical time period, wherein at least one alarm of the plurality of alarms is associated with a target machine in the manufacturing network and at least one other alarm of the plurality of alarms is associated with at least one other machine upstream or downstream of the target machine in the manufacturing network; executing a trained machine learning model using the historical alarm data to generate a downtime prediction for the target machine during a future time interval, wherein: the trained machine learning model takes the historical alarm data during the historical time period as an input to generate the downtime prediction; and providing the downtime prediction to facilitate management of the manufacturing network.

[0075] 2. The method according to aspect 1, wherein: the downtime prediction indicates a proportion of the future time interval during which the target machine is predicted to be in a non-running state; the historical data includes alarm state information for a series of time intervals within the historical time period; and for each time interval of the series of time intervals, the historical data indicates a proportion of time that an alarm among the plurality of alarms is on during the time interval.

[0076] 3. The method according to any one of aspects 1-2, further comprising: executing the trained machine learning model to obtain the downtime prediction for the targetmachine for one or more additional time intervals; and aggregating the downtime predictions for the target machine obtained at the future time interval and the one or more additional time intervals to obtain an aggregated downtime prediction for the target machine for a prediction time period that includes the future time interval and the one or more additional time intervals.

[0077] 4. The method according to aspect 3, further comprising creating hypothetical alarm data for the target machine and the second machine, wherein the hypothetical alarm data is indicative of the alarm state information of the plurality of alarms during the historical time period with a modification to the alarm state information of at least one alarm among the plurality of alarms.

[0078] 5. The method according to aspect 4, further comprising selecting one alarm associated with the target machine among the plurality of alarms as a target alarm, wherein the hypothetical alarm data includes a modification to the alarm state information of the target alarm.

[0079] 6. The method according to aspect 5, further comprising calculating a cross-correlation result between a time series of the alarm state information of the target alarm over the historical time period and a time series of the alarm state information of one or more other alarms of the plurality of alarms over the historical time period; and identifying correlated alarms among the one or more other alarms that are correlated to the target alarm based on the cross-correlation results.

[0080] 7. The method according to aspect 6, wherein the calculating the crosscorrelation result between the time series of the alarm state information of the target alarm, T(t), and the time series of the alarm state information of a specific alarm, M(t), among the one or more other alarms includes calculating a sum of multiplication results obtained by multiplying aligned values of T(t) and M(t) at a plurality of offsets of M(t).

[0081] 8. The method according to aspect 7, wherein the identifying correlated alarms includes identifying the specific alarm as one of the correlated alarms based on determining that the cross-correlation result for at least one of the plurality of offsets of M(t) exceeds a predefined threshold value; and the method further comprises identifying a crosscorrelation offset as the offset of M(t) at which the cross-correlation result is highest.

[0082] 9. The method according to aspect 8, wherein the hypothetical alarm data includes a modification to the alarm state information of the specific alarm.

[0083] 10. The method according to aspect 9, further comprising, modifying the alarm state information of the target alarm at a modified time interval, and modifying the alarm state information of the specific alarm at a time interval that is offset from the modified time interval by the cross correlation offset.

[0084] 11. The method according to any one of aspects 4-10, further comprising executing the trained machine learning model using the hypothetical alarm data to generate a hypothetical downtime prediction for the target machine for multiple time intervals; and aggregating the hypothetical downtime predictions for the target machine obtained at the multiple time intervals to obtain an aggregated hypothetical downtime prediction for the target machine.

[0085] 12. A method of managing a manufacturing network, the method comprising: obtaining historical alarm data indicative of alarm state information for each of a plurality of alarms at each of a plurality of time intervals within a historical time period, wherein at least one alarm of the plurality of alarms is associated with a target machine in the manufacturing network and at least one other alarm of the plurality of alarms is associated with at least one other machine upstream or downstream of the target machine in the manufacturing network; selecting a target alarm among the plurality of alarms, wherein the target alarm is associated with the target machine; identifying one or more correlated alarms among the plurality of alarms that are correlated with the target alarm; creating hypothetical alarm data indicative of the alarm state information of the plurality of alarms during the historical time period with modifications to the alarm state information of the target alarm and one or more of the one or more correlated alarms for one or more of the plurality of time intervals; and implementing a trained machine learning model to predict hypothetical downtime of the target machine of the manufacturing network based on the hypothetical alarm data to facilitate management of the manufacturing network.

[0086] 13. The method according to aspect 12, wherein identifying the one or more correlated alarms comprises calculating a cross-correlation result between a time series of the alarm state information of the target alarm over the historical time period and a time series of the alarm state information of one or more other alarms of the plurality of alarms over the historical time period, and identifying correlated alarms among the one or more other alarms that are correlated to the target alarm based on the cross-correlation results.

[0087] 14. The method according to aspect 13, wherein calculating the crosscorrelation result between the time series of the alarm state information of the target alarm, T(t), and the time series of the alarm state information of a specific alarm, M(t), among the one or more other alarms includes calculating a sum of multiplication results obtained by multiplying aligned values of T(t) and M(t) at a plurality of offsets of M(t).

[0088] 15. The method according to aspect 14, wherein identifying correlated alarms includes identifying the specific alarm as one of the correlated alarms based on determining that the correlation result for at least one of the plurality of offsets of M(t) exceeds a predefined threshold value; and the method further comprises identifying a cross-correlation offset as the offset of M(t) at which the multiplication result is highest.

[0089] 16. The method according to aspect 15, wherein the hypothetical alarm data includes a modification to the alarm state information of the specific alarm.

[0090] 17. The method according to aspect 16, further comprising, modifying the alarm state information of the target alarm at a modified time interval, and modifying the alarm state information of the specific alarm at a time interval that is offset from the modified time interval by the cross correlation offset.

[0091] 18. The method according to aspect 12, further comprising implementing the trained machine learning model to predict downtime of the target machine based on the historical alarm data.

[0092] 19. The method according to aspect 18, further comprising generating an indication of a predicted impact of the modifications in the hypothetical alarm data on downtime of the target machine based on a comparison of the predicted downtime and the predicted hypothetical downtime.

[0093] 20. The method according to aspect 19, further comprising prioritizing maintenance or repair activities of the manufacturing network based on the generated indication.

[0094] 21. Non-transitory computer-readable media storing instructions that, when executed by one or more processors, are operable to cause the one or more processors to implement the methods of any one of aspects 1-20.

[0095] 22. A system comprising: memory storing instructions; and one or more processors operable to execute the instructions to implement the methods of any one of aspects 1-20.

Claims

CLAIMSWe claim:

1. A system for manufacturing products or components of products, the system comprising: a plurality of machines in a manufacturing network for manufacturing products or components of products, wherein each machine is configured with one or more sensors, each sensor being configured to activate an alarm of a plurality of alarms if said sensor detects a corresponding alarm condition, and wherein the plurality of machines includes a target machine and at least one other machine upstream or downstream of the target machine in the manufacturing network; and a processor configured to: obtain from said sensors historical alarm data indicative of alarm state information for each of the plurality of alarms during a historical time period; execute a trained machine learning model using the historical alarm data to generate a downtime prediction for the target machine during a future time interval, wherein the trained machine learning model takes the historical alarm data during the historical time period as an input to generate the downtime prediction; and provide the downtime prediction to facilitate management of the manufacturing network.

2. The system of claim 1, wherein the downtime prediction indicates a proportion of the future time interval during which the target machine is predicted to be in a non-running state; the historical data includes alarm state information for a series of time intervals within the historical time period; and for each time interval of the series of time intervals, the historical data indicates a proportion of time that an alarm among the plurality of alarms is on during the time interval.

3. The system of any one of claims 1-2, wherein the processor is further configured to: execute the trained machine learning model to obtain the downtime prediction for the target machine for one or more additional time intervals; and aggregate the downtime predictions for the target machine obtained at the future time interval and the one or more additional time intervals to obtain an aggregated downtimeprediction for the target machine for a prediction time period that includes the future time interval and the one or more additional time intervals.

4. The system of claim 3, wherein the processor is further configured to create hypothetical alarm data for the target machine and the second machine, wherein the hypothetical alarm data is indicative of the alarm state information of the plurality of alarms during the historical time period with a modification to the alarm state information of at least one alarm among the plurality of alarms.

5. The system of claim 4, wherein the processor is further configured to select one alarm associated with the target machine among the plurality of alarms as a target alarm, wherein the hypothetical alarm data includes a modification to the alarm state information of the target alarm.

6. The system of claim 5, wherein the processor is further configured to: calculate a cross-correlation result between a time series of the alarm state information of the target alarm over the historical time period and a time series of the alarm state information of one or more other alarms of the plurality of alarms over the historical time period; and identify correlated alarms among the one or more other alarms that are correlated to the target alarm based on the cross-correlation results.

7. The system of claim 6, wherein calculating the cross-correlation result between the time series of the alarm state information of the target alarm, T(t), and the time series of the alarm state information of a specific alarm, M(t), among the one or more other alarms includes calculating a sum of multiplication results obtained by multiplying aligned values of T(t) and M(t) at a plurality of offsets of M(t).

8. The system of claim 7, wherein identifying correlated alarms includes identifying the specific alarm as one of the correlated alarms based on determining that the crosscorrelation result for at least one of the plurality of offsets of M(t) exceeds a predefinedthreshold value; and the processor is further configured to identify a cross-correlation offset as the offset of M(t) at which the cross-correlation result is highest.

9. The system of claim 8, wherein the hypothetical alarm data includes a modification to the alarm state information of the specific alarm.

10. The system of claim 9, wherein the processor is further configured to: modify the alarm state information of the target alarm at a modified time interval; and modify the alarm state information of the specific alarm at a time interval that is offset from the modified time interval by the cross correlation offset.

11. The system of any one of claims 4-10, wherein the processor is further configured to: execute the trained machine learning model using the hypothetical alarm data to generate a hypothetical downtime prediction for the target machine for multiple time intervals; and aggregate the hypothetical downtime predictions for the target machine obtained at the multiple time intervals to obtain an aggregated hypothetical downtime prediction for the target machine.

12. A system for manufacturing products or components of products, the system comprising: a plurality of machines in a manufacturing network for manufacturing products or components of products, wherein each machine is configured with one or more sensors, each sensor being configured to activate an alarm of a plurality of alarms if said sensor detects a corresponding alarm condition, and wherein the plurality of machines includes a target machine and at least one other machine upstream or downstream of the target machine in the manufacturing network; and a processor configured to: obtain from said sensors historical alarm data indicative of alarm state information for each of the plurality of alarms during a historical time period; select a target alarm among the plurality of alarms, wherein the target alarm is associated with the target machine;identify one or more correlated alarms among the plurality of alarms that are correlated with the target alarm; create hypothetical alarm data indicative of the alarm state information of the plurality of alarms during the historical time period with modifications to the alarm state information of the target alarm and one or more of the one or more correlated alarms for one or more of the plurality of time intervals; and implement a trained machine learning model to predict hypothetical downtime of the target machine of the manufacturing network based on the hypothetical alarm data to facilitate management of the manufacturing network.

13. The system of claim 12, wherein identifying the one or more correlated alarms comprises calculating a cross-correlation result between a time series of the alarm state information of the target alarm over the historical time period and a time series of the alarm state information of one or more other alarms of the plurality of alarms over the historical time period, and identifying correlated alarms among the one or more other alarms that are correlated to the target alarm based on the cross-correlation results.

14. The system of claim 13, wherein calculating the cross-correlation result between the time series of the alarm state information of the target alarm, T(t), and the time series of the alarm state information of a specific alarm, M(t), among the one or more other alarms includes calculating a sum of multiplication results obtained by multiplying aligned values of T(t) and M(t) at a plurality of offsets of M(t).

15. The system of claim 14, wherein identifying correlated alarms includes identifying the specific alarm as one of the correlated alarms based on determining that the correlation result for at least one of the plurality of offsets of M(t) exceeds a predefined threshold value; and the processor is further configured to identify a cross-correlation offset as the offset of M(t) at which the multiplication result is highest.

16. The system of claim 15, wherein the hypothetical alarm data includes a modification to the alarm state information of the specific alarm.

17. The system of claim 16, wherein the processor is further configured to: modify the alarm state information of the target alarm at a modified time interval; and modify the alarm state information of the specific alarm at a time interval that is offset from the modified time interval by the cross correlation offset.

18. The system of claim 12, wherein the processor is further configured to implement the trained machine learning model to predict downtime of the target machine based on the historical alarm data.

19. The system of claim 18, wherein the processor is further configured to generate an indication of a predicted impact of the modifications in the hypothetical alarm data on downtime of the target machine based on a comparison of the predicted downtime and the predicted hypothetical downtime.

Images