Hi Dojo,
We're across a use-case where we're evaluating if it can actually help to have conditional monitoring,
based on element names, e.g. something like...
Let's say that in a hypothetic scenario, a police officer needs to monitor the average speed of vehicles registered on speed-cameras for a given road (the element): the officer need an alarm if the speed average exceeds a given threshold; different roads will naturally have different speed-limits, hence the current implementation with 2 different templates,
template A for urban roads, and a template B for highways.
I might be biased, but I've always thought of "alarm conditions" as something
to perform checks on other values retrieved by the protocol:
e.g. if X == TRUE & ... OR ... --> disable this line in the alarm template.
In this scenario, I'm a bit reluctant to the idea of applying conditions based on element names: as an admin, I prefer to have a clear indication of the underlying infrastructure at "Template" level, via the protocol & Templates screen in CUBE, rather than having to dig down at alarm conditions level to gain the same level of visibility (this can easily hinder when it comes to planning works both in & out of DataMiner). As a driver, instead, it's good to know on which kind of road I'm travelling... as I don't want to be fined for speeding (^_^)'.
However, I don't want to leave any stone unturned, and I've realized that "[Element ID]" is built-in for conditions, so here I am, asking for some more insight from the community.
Is it possible to use Element ID or an expression to check the name and achieve the same result of the current implementation, based on 2 different templates?
Alternatively, would this be a good use-case for an Alarm Template Group?
Thanks
Hi Alberto,
Isn't possible to use normalization? Then you basically defined the allowed deviation from the normal, expected value (=speed) in your alarm template. Either you specify this deviation in an absolute value, so the allowed extra speed (m/s), or you specify the deviation in a relative number, the allowed % more than the normal/expected value.
Then you can define one alarm template, which defines how much faster you are allowed to drive, and you define for each element (=road) what it the normal/expected/allowed speed in the baseline editor.
More info: Configuring dynamic alarm thresholds | DataMiner Docs
Bert
It’s not necessary to trend the parameter. You can always define the ‘baseline’ manually yourself. It’s only if you automatically want to populate the baseline with the average of e.g. the last 7 average that you need to activate trending.
An alternative approach would be to run an automation script e.g. each hour or so, and check if the correct alarm template is assigned based on the name of the elements. It would have a delay of one hour, but I guess it doesn’t change that often.
PS: It’s Bert here, not Ben 😉
Apologies, Bert ^^
Unforgivable, as you were my DM-Instructor too, back in the days.
And I know there’s Bert, Ben & Frederik!
It’s just my “Monday-Morning-Typing” that needs some more coffee! (;
So that I pay attention to name & pic too, instead of just the surname! (^_^)’
Marking this as solved!
Thank you for your help
No problem at all 😉
Thanks for the prompt feedback, Ben – much appreciated.
I agree that baselines would make it all much more practical than a condition on the element name – in this specific “speed camera” example, we had originally used two different alarm templates since the thresholds (“speed limits”) would be static & deterministic – am I correct that for baseline I’d need to trend the parameter?
Let’s drive safely ^_^