2009/7/15, Wolfgang Laun <wolfgang.l...@gmail.com>: > 2009/7/15 Edson Tirelli <tire...@post.com>: >> >> Aldian, >> >> Yes, this is the way to go: >> >> rule "detect and set routers different from root for alarm 45" >> When >> * All routers which index is different from 0 are raising the alarm 45 >> * There is an alarm $a of numero 45 raised by an equipement $e >> different from the root >> Then >> * execute some specific code on ($a,$e) >> end >> >> It would be like this: >> >> when >> forall( $e1 : Equipment( index != 0 ) >> Alarm( origin == $e1.name, probablecause == 45 ) ) >> $e2 : Equipment( index != 0 ) >> $a2 : Alarm( origin == $e2.name, probablecause == 45 ) >> then >> // do something with $e2 and $a2 >> end >> > > What happens if the RHS contains a retract( $a2 ), which (I think) is > one of the things Aldian intends to do? > > Also, there is the requirement of inserting a summary alarm > replacing all the 45ers on non-root equipments. You may not > want to do this on the RHS, unless you rely on the engine > discarding fact duplicates. >
Thank you for your answers. I am currently examining how to use the accumulate keyword. As for the alarms that have been correlated in only one, I don't know how they are dealt with commonly, but here are the problems we have seen: 1) In the hypothesis where a same single alarm could be correlated with different pairs to create correlated alarms in different cases, it would be careless to retract it after having been correlated one time, because it would block all further correlation 2) In the hypothesis where a correlated alarm sum of a lot of single one has been created and where an event is raised to tell that one of these alarms has fallen: Two possibilities: Introducing the notion of "correlated alarm partially cleared" or removing the correlated alarm and reintroducing its remaining components. If the correlation has been well done, it doesn't make sense to use the first possibility, because once the condition are no longer validated, there is no reason to display the correlated alarm any further. Here is the way we will deal with this: Currently there are two list of alarms in main class: a) the list of alarms that has been inserted to drools (including single and correlated ones) but not cleared yet b) the list of alarms that should be displayed to the operator. So basically, when we decide that a group of alarms should be correlated in only one, we remove them from the list (b) and we add to (a) and (b) a correlated one that contains all the group. When an event rise to signal that one alarm is no longer raised, all correlated alarms it is part of are destroyed and removed from both lists and all their components except the fallen one are re-added to list b. The mechanisms allowing this are based on the alarm keys that are unique and on some mappings. So as you see there is a distinction between what is in drools, and what is visible by the operator. All non cleared alarms (single and correlated) are permanently in drools until it is destroyed because it has been cleared. The only inconvenient is then to avoid the rules to fire indefinitely, since they are permanently susceptible to be validated. To avoid this all rules are of type "If some alarms respect the folowing conditions and at least one of them is not part of a correlated alarm built for this rule, then...". There are probably smarter ways to do, but this is my point of view for the moment. Cheers Aldian _______________________________________________ rules-users mailing list rules-users@lists.jboss.org https://lists.jboss.org/mailman/listinfo/rules-users
