The present invention belongs to the field of monitoring alerts to be classified according to their severity. In particular, the invention describes a method and a system that monitor a large amount of alerts automatically to prioritize those with severe character. Such alerts are generated by measuring instruments or devices—as sensors or detectors—or are generated by third party tools.
The emission of alerts could be performed in many contexts nowadays. The aim of such emission is to report an abnormal behavior of a system, e.g. an overheating of a machine in an industrial plant, or to inform about a certain event is taken place, e.g. a stock market crash or a market abuse.
The severity or urgency of each alert is really variable, being mandatory to analyze the alerts one by one to establish a prioritization of the most severe alerts. In this way, alerts reporting serious problems could require the intervention of professionals, for example for repairing a broken machine, or a certain type of actuation, for example the automatic triggering of a fire hydrant, whereas alerts that do not report important issues can even be discarded.
An alert management method starts after the generation of a huge number of alerts which need to be monitored. The objective of such monitoring is to identify the severe cases that should be prioritized. In this way, it is essential to analyze alerts quickly so that such prioritization is properly performed. The negative effects of failing in the prioritization of alerts are diverse, from stopping a production process of an industrial plant to receiving substantial fines. For example, the interruption of the production process could be the consequence of not repairing a certain machine when a malfunctioning alert is issued or the substantial fines could be the consequence of not attending legal, compliance and control surveillance alerts (such as trade surveillance or anti-money laundering or fraud surveillance) in order to prevent illegal behavior, such as market abuse, money laundering or terrorism financing.
Traditionally, the alerts are monitored and analyzed manually by a group of experts. Thus, as the volume of alerts received grows, such volume could become unmanageable by said experts leading to a lack of adequate prioritization of the alerts. In this way, a proper alert monitoring procedure would require a great consumption of time and extra resources that, many times, are completely unaffordable.
Some solutions that simulate the decisions that the group of experts would make when analyzing the alerts are based on machine learning techniques. The main problem of these solutions is that there are not enough hits (positive alerts) to train the algorithms and they offer theoretical solutions which have not been tested against practical examples. Besides, these solutions are focused on analyzing background alerts, but they disregard other aspects that must be taken into account during the classification of the alerts; for example, the accuracy and the reliability of the element that issued the alert.
The following invention proposes a solution to the problems described above by means of an efficient and robust method for monitoring high volumes of alerts so that the severe alerts identified are properly prioritized.
The present invention provides an alternative solution for the aforementioned problems, by a computer implemented-method for monitoring large amounts of alerts according to claim 1, a processing system according to claim 13, a computer program product according to claim 14 and a computer-readable medium according to claim 15. In dependent claims, preferred embodiments of the invention are defined.
In a first inventive aspect, the invention provides a computer implemented-method for monitoring large amounts of alerts to classify them according to their severity, the method comprising the following steps:
Throughout all this document, “large amount of alerts” will be understood as a number of alerts that is unmanageable by a group of experts when they analyze the alerts manually. This amount of alerts would lead to an improper prioritization thereof. Throughout all this document, “element” will be understood as the sensor, detector, device, third party or third party tool that issues an alert. As “third party” will be understood as a third person, organization or company not directly involved in the method for monitoring alerts. The term “severity” will be understood as the degree or the level of urgency of an alert. Hence, when an alert has the highest possible degree of severity, it should be handled with priority in relation to the rest of alerts. On contrary, a disposable alert has the lowest possible degree of severity. The method classifies the alerts according to their severity in a category of prioritization, being the number of categories at least two.
The consequences of not attending a severe or priority alert would depend on the context of the alert issuing, for example:
The method of the invention for monitoring alerts to be classified begins with the reception of a plurality of alerts, preferably a large amount of alerts. In a preferred manner, those alerts are received by a computer—or a microcontroller—with processing capabilities and memory means. In general, each alert has just partial information about the event being reported so a set of alerts is needed to count on the whole information of such event. As “event being reported” should be understood the event that has caused the issuing of alerts; for example, the detection of a machine failure in an industrial plant; the detection of a fire in a forest or the detection of an illegal behavior.
Hence, the method continues classifying the alerts in at least one alert case according to a classifying criterion previously predetermined. An “alert case” should be understood as a group of alerts that have at least one feature in common or a group of alerts that share the same aim so that the information obtained from the alert case allows having complete information about the event being reported.
In a preferred embodiment, the number of alert cases is greater than one so, for simplicity, throughout the document we will refer to this term in plural without prejudice that just one alert case could be generated.
As it was previously mentioned, the alert cases are generated according to a predetermined classifying criterion. Such criterion varies with the context of alert issuing. For example, in the context of an industrial plant, the classifying criterion could be the selection of alerts coming from the same plant that were issued in a determined period. In another example, the criterion could be the selection of alerts coming from a certain territory. In another example, when alerts are issued in the context of legal, compliance and control surveillance, the criterion could be the selection of alerts of the same account (natural or legal person that ordinates an operation or an investment), and/or with the same asset (where the operation or investment is taken place, for example, the stocks of a public company in an exchange or a fixed income bond) and/or alerts issued during the same trading session.
Once the alerts have been classified in cases, the method continues calculating the odds each alert case corresponds to a hit using background cases.
Throughout all this document, “odds” should be understood as a metric for each alert case that is assessed to allow the classification and prioritization of the alert cases. As a preferred embodiment the metric is a probability. Throughout all this document odds or probabilities will be used indistinctly.
Throughout all this document, a “hit” should be understood as an event that actually took place or is taking place; that is, the method calculates the probability that a group of alerts is truly reporting an event. For example, if several alerts from the same territory were received reporting the existence of a traffic accident, the method of the invention merges all the alerts in the same case and calculates the odds of a traffic accident is truly occurring or has truly occurred. Throughout all this document, a “miss” should be understood as a false positive in reporting an event.
Throughout all this document, “background cases” should be understood as groups of alerts that took place in the past and that provide truthful and complete information about the event that was reported. For example, if a fire was actually produced in an industrial plant and several alerts were issued reporting the presence of such fire—by means of, for example, the detection of an increment in the temperature and a decrement of humidity—the alert case resulting from the join of such alerts must be part of the background cases. The alert cases that did not report a real incident (miss) are also part of the background cases.
According to the odds calculated before, the method continues with a classification of the alert cases in a category of severity, being the number of categories at least two. As “categories of severity” should be understood the categories where the alert cases are classified to obtain a level of prioritization. For example, in the simplest situation, the alert cases with odds that overcomes a certain predetermined threshold are classified as priority alerts and the rest of the alert cases are classified as non-priority alerts. In this example, the priority alerts are analyzed by a group of experts that decides if the alert case requires the intervention of professionals or a certain type of actuation and the non-priority alerts are automatically discarded.
Finally, the alerts must be joined to the background cases together with the result of the classification and other relevant information. “Relevant information of an alert” will be understood as information related to each alert that could be of interest in subsequent executions of the method; for example, the alert case to which the alert belongs, the element that issued the alert or the odds to be a hit calculated for its alert case. These are mere examples without prejudice that other type of relevant information could be kept.
The method of the invention, advantageously, allows managing huge amounts of alerts without requiring additional time or cost resources in relation to the traditional methods. Besides, the accuracy of the method increases with the number of executions; that is, as the alerts classified and analyzed at the end of the method start forming part of the background cases, the information in which the calculation of the odds is based is more complete, being such calculation more accurate execution after execution.
It must be noted that the method is also applicable when the number of alerts could not be considered as large (a number that is manageable by the group of experts). In these cases, the method has also good results in the prioritization of alerts but the advantages in respect to the traditional methods are not so evident.
The step of the method of calculating the odds each alert case corresponds to a hit comprises the following sub-steps:
P(H|Ci)=P(H|CBi)
P(Hcase)=max{P(H|C1), . . . ,P(H|CZ)}
The calculation of the odds each alert case corresponds to a real incident using background cases, in this particular embodiment, comprises several sub-steps.
Firstly, the method estimates all the possible combinations of behavior properties for each background case. Throughout all this document, “behavior property” will be understood as a kind of alert, a kind of measurement of an alert or a kind of element that issues an alert so that each background or alert case comprises a certain number of different behavior properties. For example, in the context of alerts of an industrial plant, a behavior property can be a power surge detection, a temperature measurement or a pressure gauge measurement. Another example in the context of alerts for legal, compliance and control surveillance, some behavior properties can be a firm introducing orders unusually large or doing self-trading (firm crossing its own buy and sells orders each other).
Next, the method calculates, for each background case, the odds of each of the previous combinations of behavior properties to be a hit by means of the Bayes theorem. In order to apply such theorem, it is necessary a previous calculation of P(CBi|H) and P(H) using the information of the background cases.
This way of calculating the odds is really efficient as it takes into account that a hit does not have to involve all the behavior properties of a background case; that is, the method considers that there could be behavior properties that are irrelevant for the event reported that should be deemed as noise.
At this point, a list with the odds for all the possible combinations of behavior properties of each background case to be a hit is available.
Later, for each of the alert cases generated before, the method calculates all the available combinations of behavior properties—having account only the behavior properties contained in the alert case—and assigns them a probability of being a hit. This assignation is performed according to the list of odds of being a hit calculated for the combination of behavior properties of the background cases (inferring that the probabilities of current cases would be similar than the probabilities obtained for the cases analyzed in the past)
Finally, the method estimates the probability for each alert case to be a hit as the maximum of the probabilities of being a hit of all its available combinations of behavior properties.
The method calculates the probabilities an alert case to be a hit based on the background of previously monitored cases. As it was previously mentioned, it requires a background of analyzed cases is available and, advantageously, as larger the background is as more accurate the odds will be.
In a particular embodiment, the sub-steps for calculating the probabilities of each combination of behavior properties of the background cases to be a hit is performed periodically, being the period a predefined value of time.
Considering that the background cases grows as the alerts are analyzed and classified, the odds to be a hit of the combination of behavior properties of the background cases could be updated periodically to include the new information with a certain frequency. Advantageously, the accuracy of the method is increased as the number of background cases raises.
In a preferred example, the updating period is once a day. In other examples, the updating period could be once a week, once each 15 days or once a month.
In a particular embodiment, the classifying criterion is one of the following:
As it was previously mentioned, during the execution of the method the alerts are classified in cases. Such cases will depend on a specific classifying criterion.
There are some specific classifying criteria that could be adopted in different alert context:
Other classifying criteria just apply for a specific alert context, being the classifying criteria really variated:
The classifying criteria previously described are just representative examples without prejudice that other criteria could exists.
In a preferred example, the classifying criterion comprises alerts issued in a predefined period of time and, optionally, at least one of the rest of classifying criteria described above.
In a particular embodiment, the method further comprises a step of calculating a metric, the Case Relevant Indicator (CRI), for each alert case taking into account the real performance of the elements that issued the alerts; and the step of classifying the at least one alert case in a category of severity is additionally based in the Case Relevant Indicators (CRI).
Throughout this document, as “Case Relevant Indicator (CRI)” will be understood as a further metric for each case being assessed, which is calculated during the execution of the method of the invention, whose purpose is working in a complementary way with the calculation of odds as previously explained to allow the classification and prioritization of the alert cases.
Traditionally, the alerts are monitored and analyzed manually by a group of experts so, when the amount of alerts is unmanageable by this group of experts, requires another techniques for handling the alerts.
In the state of the art, solutions based on Machine Learning techniques can be found. These type of techniques present two main problems:
In this embodiment, the method incorporates this type of information related to the environment of alert issuing. Firstly, the method comprises a step of calculating the CRI and this information is later used during the classification and prioritization of the alert cases (together with the information of the calculation of odds, as previously mentioned). Advantageously, the accuracy of the alert cases classification is incremented so that the prioritization of alerts is more precise.
The relevant information is related to the knowledge an expert has about the performance of the element that issued the alert. In the context of the invention, “real performance” should be understood as how an element actually operates, which can be different to the ideal performance of the element due to tolerances in their behavior property, manufacturing inaccuracies, malicious operation or changes in regulations, among others.
In the case of sensors, detectors or devices are involved in the alert issuing, the relevant information used is the knowledge an expert has about their type of technology, their calibration and the accuracy of their measurement, if any. In case of third party tools are involved in the alert issuing, the relevant information used is the knowledge an expert has about the reliability of the third party or the reliability of the tool. For example, if the alerts are issued via mobile phone by a group of users, it should be taken into account the reliability of the phones as well as the reliability of the particular user that issued the alert.
In a particular embodiment, the method further comprises a previous step of calculating a weight for each element configured to issue an alert taking into account the real performance of such element.
In this embodiment, it is described a step that could be performed previously to the first execution of the method; that is, an estimation of a weight for each of the available elements issuing alerts could be done once and, afterwards, several executions of the method could be performed. The weight of each element takes values between 0 and 1.
The step of calculating the CRI could require such weights. Then, the calculation of these weights aims to take into account the real performance of the elements that issue the alerts.
It is important to stand out that, in case a change in the elements that issue the alerts is produced, the estimation of weights could be repeated. In this way, subsequent execution of the method would use the new values of weights calculated.
In a particular embodiment, the calculation of the Case Relevant Indicator (CRI) is performed according to the following sub-steps:
The Case Relevant Indicator (CRI), in this embodiment, is calculated by applying a Correction Coefficient (CC) to an Initial estimation of such Case Relevant Indicator (ICRI), according to the following formula: CRI=ICRI*CC
Firstly, a weight for each behavior property of each alert case is selected. Then, the ICRI is calculated according to the number of alerts generated per behavior property and the weights selected for each behavior property.
Most of combination of behavior properties happen with the same pattern over and over again so, in order to prevent the method to prioritize the same kind of alerts every time, the ICRI should decrease if other similar patterns have been analyzed and discarded recently. To achieve that, the method of the invention calculates and applies a Corrector Coefficient (CC) to the ICRI depending on similar behavior properties analyzed recently and its relevance.
In a particular embodiment, the background cases used for determining the CRI are those happened during a predetermined period of time P.
In this embodiment, to calculate the CRI a set of background cases that occurred during a predetermined period of time are selected. According to a preferred embodiment, the predetermined period of time rules out the oldest background cases while keeping the alert cases happened recently.
According to a specific embodiment, the background cases used for determining the CRI are selected among those matching a predetermined selection-criterion.
In a particular embodiment, the Correction Coefficient (CC) is a decreasing function.
In this embodiment, a decreasing function is used to decrease de Case Relevant Indicator (CRI) in order to give more relevance to the alert cases happened recently over the past alert cases and in order to prevent the method to prioritize similar patterns that have been analyzed and discarded recently.
In a particular embodiment, wherein the sub-step of the method for calculating the Case Relevant Indicator (CRI) by applying a Correction Coefficient (CC) to the Initial Case Relevant Indicator (ICRI) is performed according to the following sub-steps:
CCj=k
Firstly, a weight for each behavior property of each background case is selected. Then, an Amended Case Relevant Indicator (ACRI) vector is calculated using such weights and the number of alerts generated for the behavior property of each background case
Hereafter, a Correction Coefficient (CC) is calculated for each background case according to the Amended Case Relevant Indicator (ACRI) vector. There are two different ways of calculating the Correction Coefficient (CC) that depends on if the background case under study is a miss or a hit. In the first case, —the background case is a miss—the Correction Coefficient is calculated using the value of the Amended Case Relevant Indicator (ACRI) vector that corresponds to the background case under study and two parameters B and D, which adjust the level of correction of interest, selected at the beginning of the execution of the method. In the second case, —the background case is a hit—the Correction Coefficient is calculated using a predefined multiplication coefficient k.
In a preferred embodiment, the value of the parameter B is lower than one and the value of the parameter k is greater than one.
The parameters B, D and k are adjusted statistically by the skilled person to reduce the CRI of the cases whose combinations of behavior properties have repetitive patterns. The values selected for such parameters are related to the range of weight values (W) selected, to the background period P selected and to the background cases of such period from which the CC is calculated. The value of the parameter k, additionally, is related to the probability of a case to be a hit and the correlation that exists between the pattern repetition and the probability of the new case to be a hit. The higher the value of k, the greater the relevance of a hit is weighted over a miss.
In the end, the final Case Relevant Indicator (CRI) is calculated by applying the Correction Coefficients (CC) of all the background cases to the initial case relevant indicator (ICRI).
In a particular embodiment, wherein the sub-step of the method for calculating the Case Relevant Indicator (CRI) by applying a Correction Coefficient (CC) to the Initial Case Relevant Indicator (ICRI) further comprises the following sub-step:
In this embodiment, in order to calculate the Case Relevant Indicator (CRI) by calculating and applying a Correction Coefficient (CC) to the Initial Case Relevant Indicator (ICRI), firstly a selection of the background cases is performed.
This selection takes into account the background cases that happened during a certain period of time predetermined, those that happened recently. Besides, the previous selection can also be refined with other selection criterion; for example, by selecting the alert cases of a certain industrial plant or the alert cases of a certain account and/or asset in the context of trade surveillance. Note that this selection criterion could be the same as any of the classifying criteria previously described.
Next, for each of the background cases selected, the method calculates a Correction Time α using a displaced sigmoid function. As “sigmoid function” will be understood a mathematical function with a characteristic “S”-shaped curve or sigmoid curve. The value of the Correction Time depends on the specific background case, the time occurred since the background case happened, for instance measured in number of days, and the parameters defining the displacement and the slope of the sigmoid function.
The sigmoid function gives more relevance to the alert cases happened recently and less relevance to the alert cases happened a long time ago.
The parameters that define the displacement and the slope of the sigmoid function are established at the beginning of the execution of the method, depending on the context of alert issuing. They should be established according to the interval of time according to which the alerts were classified; that is, if the classifying criterion was to merge alerts issued during a period of a day, the parameters defining the displacement and slope of the sigmoid function should be established to cover several days. In cases where the classifying criterion was to merge alerts issued during a period of one minute, the parameters defining the displacement and slope of the sigmoid function should be established to cover a few hours. In this way, such parameters are established taken into account the time interval of the classifying criterion with a security margin.
Then, an Amended Case Relevant Indicator (ACRI) vector is calculated using such weights, the number of alerts generated for the behavior property of each background case and a matrix related to the Correction Times. This matrix is a diagonal matrix with the Correction Times calculated before for each background case.
In a particular embodiment, the weights for the behavior properties of both alert and background cases are based on the following performance criteria:
The real performance of the elements that issued the alerts is taken into account to select a weight for each behavior property of each alert case and background case. This is the way in which the method considers relevant information of the elements that issue the alerts, being such information related to the knowledge an expert has about the particular element that issues the alert.
As it was previously mentioned, the type of relevant information will depend on the context of the alert issuing. For example, in the case of sensors, detectors or devices are involved in the alert issuing, the relevant information used is the knowledge an expert has about their type of technology, their calibration and the accuracy of their measurement, if any. In another example, when third party tools are involved in the alert issuing, the relevant information used is the knowledge an expert has about the reliability of the tool and the reliability of the third party.
In this way, the method defines different performance criteria to select the weights for the behavior properties in an objective manner. The most representative criteria are the following ones, being combinable among them, without prejudice that other criteria could exist.
In a particular embodiment, the categories of severity where the at least one alert case is classified are:
In this embodiment, it is described a preferred classification without prejudice that the number and type of categories could change.
In this preferred embodiment, there are three different categories for the monitored alert cases according to their severity.
Advantageously, counting on a category to discard cases automatically saves much time and resources that, besides, can be used on other more relevant cases.
In a particular embodiment, the three categories of severity are defined by four thresholds:
The different categories of severity are defined according to different predetermined criteria. Preferably, such criteria comprises predetermined thresholds of the odds obtained for the alert cases to be hits and predetermined thresholds for the Case Relevant Indicators calculated.
In a particular embodiment, the method further comprises:
It is a good practice to review the alert cases that were discarded in order to identify possible errors made during the classification. If any, the thresholds defining the categories of severity and/or the predefined parameters of the method could be reviewed.
The categories of severity should not be statics but they could be re-determined periodically according to the odds and Case Relevant Indicators calculated in subsequent executions of the method.
Finally, all the parameters that are predefined could also be updated periodically in order to refine the accuracy of the method.
In a second inventive aspect, the invention provides a processing system comprising means configured to perform the steps of the method according to the first inventive aspect.
In a third inventive aspect, the invention provides a computer program product comprising instructions which, when the program is executed by a computer, cause the computer to carry out the steps of the method according to the first inventive aspect.
In a forth inventive aspect, the invention provides a computer-readable medium comprising instructions which, when executed by a computer, cause the computer to carry out the steps of the method according to the first inventive aspect.
All the features described in this specification (including the claims, description and drawings) and/or all the steps of the described method can be combined in any combination, with the exception of combinations of such mutually exclusive features and/or steps.
These and other characteristics and advantages of the invention will become clearly understood in view of the detailed description of the invention which becomes apparent from a preferred embodiment of the invention, given just as an example and not being limited thereto, with reference to the drawings.
The method (100) begins with the generation of a plurality of alerts (1) issued by a variety of elements (5). In this particular example, the elements (5) are two sensors that measure temperature and humidity and a smoke detector. For simplicity, in the scheme just three alerts (1) represented with circles are shown, each of them being issued by a different element (5) in the time slot 10:00-12:00 pm. However, notice that other alerts (1) (not shown) were issued in other time slots.
When the alerts (1) have been generated, they are received (110) by a computer or a microcontroller where the method (100) is being executed. Then, the method (100) continues by classifying (120) the alerts (1) in at least one alert case (2) according to a predetermined classifying criterion (6). For simplicity, this step of the method (100) is shown in
In this particular example, the classifying criterion (6) consist of joining alerts (1) issued by the elements (5) of a particular industrial factory during the last two hours. Considering that the moment when the alerts (1) were received (110) shown in
In other particular examples, the classifying criterion (6) could be limited to a specific plant of the industrial factory or even a specific area of a plant of the industrial factory. In other example, the classifying criterion (6) could be wider involving alerts (1) issued in the context of a specific type of industrial sector; for instance, a healthcare alert related to food industry or a drug alert related to pharma industry. In other example, the classifying criterion (6) is the join of alerts issued by the same third party, for example, alerts issued by a certain company whatever their professional activity is or alerts issued by a group of anonymous users reporting an accident to the medical services. In other example, the classifying criterion (6) consists on classifying (120) the alerts issued in a predetermined territory; for instance, alerts issued in a radius of five kilometers. In other example, the classifying criterion (6) is limited to the course of a specific event; for instance, the terrorism alerts issued during a concert. In other particular example, in the context of trade surveillance, the classifying criterion (6) could be more specific as alerts issued by a specific account, a specific asset or during the same trading session. All these types of classifying criteria (6) are combinable among them with the exception of combinations of such mutually exclusive.
Once the alerts (1) have been classified (120) in an alert case (2), the method (100) continues calculating (130) the odds each alert case (2) corresponds to a hit. For this step of the method (100) shown in the example of
The probabilities (P1, P2, P3) indicates the odds an alert case (2) corresponds to a hit; that is, the probability that the alert case (2) corresponds to a real incident. The odds calculated (130) in this example are P1=5.1%, P2=0.13%, P3=0.86%. In particular, in
After calculating (130) the odds for each alert case (2), the method (100) continues classifying (140) each alert case (2) in a category of severity (4). In this particular example, there are three different categories of severity (4) defined by two thresholds of probabilities (1% and 5%):
In the example of
In another particular example, the odd of being a hit of other different alert case (2) issued in the time slot 12:00 pm-2:00 am was 3.5%. In such case, the alert case (2) is then classified (140) in the “medium severity” category (4) so that such alert case (2) is stored temporally to be analyzed with no urgency.
Finally, the method (100) continues storing (150) all the alerts (1) as part of the background cases (3) to be used in subsequent executions of the method (100). Together with the alerts (1), it is required to store (150) another relevant information as the result of the classification, the alert case (2) to which the alert (1) belongs, the element (5) that issued the alert (1) and the odds to be a hit calculated (130) for its alert case (2).
Each productive chain is being monitored by 10 different sensors or detectors. Each of these elements (5), which are configured to issue alerts (1), corresponds to a different behavior property (B1, B2 . . . B10) as shown in
There is also available a set of background cases (3) stored in a data base with all the alerts (1) issued throughout the year that were classified (140) as hits (real incidents) or miss (false positive). Together with this alerts (1), relevant information is also stored (150) in the database as part of the background cases (3) as the productive chain to which the alert (1) belongs, the time interval when the alert (1) was produced and the behavior property (B) of the alert (1).
The alert cases (2) and the background cases (3) in this particular example are/were generated according to two classifying criterion (6): alerts (1) issued for the same productive chain (PC) and alerts (1) issued during the same time interval (I). For the whole example, the notation of a case (2, 3) is: “INint PCNpc”, where Nint is the number of time interval and Npc is the number of the productive chain. For instance, “I457 PC13” corresponds to the background case (3) with alerts (1) issued for the productive chain number 13 during the time interval 457.
The productive chains operates during time intervals of 3 hours (I1, I2 . . . ) and, between intervals, a time gap of 20 minutes is produced for maintenance tasks. The total time intervals of 3 hours during the day are three. Then, taking into account that the number of working days is 220 and there are 3 time intervals per day, the total number of intervals of the background is 660.
Previously to executing the method (100) for the first time, a calculation of a weight (W) for each of the elements (5) configured to issue alerts (1) could be performed.
In
Such weights (W) aims to evaluate the real performance of the elements (5) by means of a certain performance criteria; in this particular example, three different criteria are used:
In
After the execution of the method (100), in case a change is produced in at least one of the elements (5) that issue alerts (1), this adjustment of weights (W) could be repeated for subsequent executions of the method (100).
For the execution of the method (100), the parameters θ, σ, B, D and k should be predetermined.
The determination of the parameters requires information about the background cases (3), in particular their ICRIs, which are calculated taking into account the number of alerts (1) per behavior property (B) and the weights (W) of the behavior property (B) for each background case (3).
For instance, for the background cases (3) “I1 PC11” and “I559 PC12” shown in
After analyzing all the cases, the minimum ICRI calculated is equal to 1 and the maximum ICRI calculated is equal to 541.
1 shows several displaced sigmoid functions for different combinations of parameters θ and σ. Depending on the time corrector adjustment needed in each alert context, a certain combination should be chosen. The set of sigmoid functions has been obtained empirically.
The sigmoid function gives more relevance to the alert cases happened recently and less relevance to the alert cases happened a long time ago. The sigmoid function is 1 for the alert cases that happened today and tends to zero for the background cases happened a long time ago.
1 shows in axis x the time interval, being 0 today and 90 the maximum time interval whose background cases are considered. That is, oldest background cases are located at the right side of the time axis.
In this particular example, during the execution of the method (100), a selection of background cases (3) is needed to calculate the Case Relevant Indicator (CRI) of each alert case (2). Such selection will consider just the background cases (3) of the last 60 time intervals. It must be noted that the parameters of the sigmoid functions are covering a period of 90 time intervals, as it is required to count on a security margin.
In this example, it is required to reduce the time corrector adjustment by half after 10 days (3 time intervals/day*10 days=30 time intervals). Taking into account that θ represents the number of intervals in which the background case ICRI is reduced by half and that σ represents the abruptness of the curve drop, the parameters selected could be θ=30 and σ=0.1
According to the ICRIs calculated for the background cases (3) and according to this embodiment, a selection of the parameters B, D and k should be performed in order to define a Correction Coefficient CC. CC is determined as follows:
wherein CC=k if the alert case is a hit and CC=
2 shows several functions (
In this particular example, as the ICRIs of the background cases (3) varies from 1 to 541 so the selected values are B=0.9, D=50 and k=3.
In this example:
The execution of the method (100) begins with the reception (110) of a plurality of alerts (1) issued by the plurality sensors and detectors (5). Such alerts (1) are classified (120) into different alert cases (2) and then, the method (100) calculates (130) the odds each alert case (2) corresponds to a hit using background cases (3).
Firstly, all the combination of behavior properties (B) of each background case (3) is obtained. Then, the Bayes theorem is applied to calculate (130) the odds of each combination of behavior property (B) to be a hit. In
In the first column, it is shown a combination of ten behavior properties sorted as in table 2c (B) where the number “1” indicates that this particular behavior property (B) is present in the combination and “0” indicates that said behavior property is absent. The second and third columns show the number of hits and miss for this particular combination of behavior property (B) in the background cases and, in the last column, the probability of being a hit of the combination of behavior properties (B) is presented. For instance, the combination of behavior properties B2+B3+B7 has a probability of 2.2556% of being a hit according to the background cases (3).
This list of probabilities is done for all the possible combination of behavior properties (B) of the background cases (3) and could be periodically updated. In this particular example, the updating is performed once a day.
Hereafter, for each alert case (2), the method (100) identifies all its possible combination of behavior properties (B) and assigns to each combination a probability to be a hit according to the list of odds calculated (130) before.
In
Then, the method (100) assigns a probability for each of the previously mentioned combinations of behavior properties (B) according to the list of odds of the background cases (3):
Finally, the method (100) calculates (130) the probability for the alert case (2) to be a hit as the maximum of the probabilities of being a hit of all its available combinations of behavior properties (B):
P(HI661PC2)=3.3256%
The classification (140) in a particular category of severity (4) of each alert case (2) takes into account these probabilities.
The method (100) of the invention, additionally, comprises a step of calculating a further metric, the Case Relevant Indicator (CRI), for each alert case (2) taking into account the real performance of the elements (5) that issued the alerts (1). Such CRI, together with the probability of each alert case (2) to be a hit, is later used during the classification (140) of the alert cases (2).
The use of this metric, advantageously, increments the accuracy of the alert cases (2) classification (140) so that the prioritization of alerts (1) is more precise.
The CRI estimation requires the weights (W) for the elements (5) that issue the alerts (1) estimated previously to the execution of the method (100). Thus, a selection of such weights (W) is needed according to the specific behavior properties (B) that are present in each alert case (2). In this particular example, for the alert case (2) I661PC2, the weights (W) selected are the ones shown in
Next, an Initial Case Relevant Indicator (ICRI) is calculated for each alert case (2). This indicator considers the weights (W) previously mentioned and the number of alerts (1) per behavior property (B) of each particular alert case (2).
According to
Most of combination of behavior properties (B) happen with the same pattern over and over again so, in order to prevent the method (100) to prioritize the same kind of alerts (1) every time, the ICRI should decrease if other similar patterns have been analyzed and discarded recently. To achieve that, the method (100) of the invention calculates and applies a Corrector Coefficient (CC) to the ICRI depending on similar behavior properties (B) analyzed recently and its relevance.
Firstly, the method (100) selects the background cases (3) of the same productive chain as the alert case (2) that were analyzed in the last 60 time intervals, as it was previously mentioned; that is, a selection of the background cases (3) whose time interval is among the time interval 601 and the time interval 660 (with the productive chain PC2).
Then, a Correction Time (a) is calculated for each background case (3) selected according to the parameters θ and σ predetermined when configuring the method (100).
Next, an Amended Case Relevant Indicator (ACRI) vector is calculated using the Correction Times (αi), the number of alerts (1) per behavior property (B) and the weights (W) of the behavior properties (B) of each background case (3) selected.
Hereafter, a Correction Coefficient (CC) is calculated for each background case (3) selected according to the ACRI vector and the parameters B, D and k predetermined when configuring the method (100). Besides, the method (100) takes into account if a specific background case (3) was a Hit or a Miss.
Finally, the Case Relevant Indicator (CRI) is obtained for each alert case (2) by applying the Correction Coefficients to the ICRI initially calculated as CRI=ICRI*CC for each alert case (2). For the case being analyzed in this example (“I661 PC2”)), the CRI is calculated multiplying its ICRI by all the CCs of the selected background cases (3) (being the value 0.0403) as follows:
CRII661PC2=ICRI*CC=22*0.0403=0.88
To classify (140) the alert case (2) “I661 PC2” both the odds to be a hit (3.3256%) and the CRI (0.88) should be considered.
This alert case (2) is not a high severity case since its odds is lower than the threshold of 4% and its CRI value is lower than the threshold of 30. It is not a low severity case either because, although the CRI value is lower than the threshold of 5, the odds exceed the threshold of 0.5%.
Then, the alert case (2) is a medium severity case, what implies that the case is not going to be discarded but stocked temporally so that it can be later analyzed with no urgency.
Finally, the alerts (1) of the alert case (2) “I661 PC2” start to form part of the background together with its relevant information: the alert case (2) to which they belong and its ICRI, the result of the classification (MISS), the behavior property (B) involved in each alert (1) and its weight (W); by storing such information in the background data base.
In a preferred illustrative embodiment as “embodiment 1”, it is presented a computer implemented-method (100) for monitoring large amounts of alerts (1) to classify them according to their severity, the method (100) comprising the following steps:
“Embodiment 2”. The computer implemented-method (100) according to the “embodiment 1”, wherein the step of the method (100) of calculating (130) the odds each alert case (2) corresponds to a hit comprises the following sub-steps:
P(H|Ci)=P(H|CBi)
P(Hcase)=max{P(H|C1), . . . ,P(H|CZ)}
“Embodiment 3”. The computer-implemented method (100) according to the “embodiment 2”, wherein the sub-steps for calculating the probabilities of each combination of behavior properties (B) of the background cases (3) to be a hit is performed periodically, being the period a predefined value of time.
“Embodiment 4”. The computer-implemented method (100) according to any of the preceding “embodiments”, wherein the classifying criterion (6) is one of the following:
“Embodiment 5”. The computer-implemented method (100) according to any of the preceding “embodiments”, wherein
“Embodiment 6”. The computer-implemented method (100) according to the “embodiment 5”, wherein the method (100) further comprises a previous step of calculating a weight (W) for each element (5) configured to issue an alert (1) taking into account the real performance of such element (5).
“Embodiment 7”. The computer-implemented method (100) according to the “embodiment 6”, wherein the calculation of the Case Relevant Indicator (CRI) is performed according to the following sub-steps:
Coefficient (CC) to the Initial Case Relevant Indicator (ICRI), wherein the Correction Coefficient (CC) decreases the Case Relevant Indicator (CRI) if the behavior properties (B) of the alert case (2) are similar to behavior properties (B) of other alert case (2) analyzed and discarded in previous executions of the method (100).
“Embodiment 8”. The computer-implemented method (100) according to the “embodiment 7”, wherein the background cases (3) used for determining the CRI are those happened during a predetermined period of time P.
“Embodiment 9”. The computer-implemented method (100) according to the “embodiment 7” or the “embodiment 8”, wherein the Correction Coefficient (CC) is a decreasing function.
“Embodiment 10”. The computer-implemented method (100) according to any of the “embodiments 7 to 9”, wherein the sub-step of the method (100) for calculating the Case Relevant Indicator (CRI) by applying a Correction Coefficient (CC) to the Initial Case Relevant Indicator (ICRI) is performed according to the following sub-steps:
CCj=k
“Embodiment 11”. The computer-implemented method (100) according to the “embodiment 10” and any of the “embodiments 1 to 9”, wherein the sub-step of the method (100) for calculating the Case Relevant Indicator (CRI) by applying a Correction Coefficient (CC) to the Initial Case Relevant Indicator (ICRI) further comprises the following sub-step:
“Embodiment 12”. The computer-implemented method (100) according to the “embodiments 6 or 7” and any of previous “embodiments”, wherein the weights (W) for the behavior properties (B) of both alert and background cases (2, 3) are based on the following performance criteria:
“Embodiment 13”. The computer-implemented method (100) according to any of the previous “embodiments”, wherein the categories of severity (4) where the at least one alert case (2) is classified (140) are:
“Embodiment 14”. The computer-implemented method (100) according to the “embodiment 13”, wherein the three categories of severity are defined by four thresholds:
“Embodiment 15”. The computer-implemented method (100) according to the “embodiment 14”, wherein the method (100) further comprises:
“Embodiment 16”. A processing system comprising means configured to perform the steps of the method (100) according to any of the previous “embodiments”.
“Embodiment 17”. A computer program product comprising instructions which, when the program is executed by a computer, cause the computer to carry out the steps of the method (100) according to any of the “embodiments 1 to 15”.
“Embodiment 18”. A computer-readable medium comprising instructions which, when the program is executed by a computer, cause the computer to carry out the steps of the method (100) according to any of the “embodiments 1 to 15”.
Number | Date | Country | Kind |
---|---|---|---|
20382090.7 | Feb 2020 | EP | regional |
Filing Document | Filing Date | Country | Kind |
---|---|---|---|
PCT/EP2021/053066 | 2/9/2021 | WO |