This relates to another question I posted recently, but is still quite a separate topic.
Essentially I have a decoder which can have 1 or two TS inputs, and has a parameter table to keep the state and information of those inputs.
What I'd like to achieve (in addition to extra complexity from my other question, which I'll leave out of this question) is if one input is showing as 'unlocked' then that is a critical alarm, but if both are showing unlocked then that's a critical alarm, but as these the same parameter but different rows I think this has to be done with quite a few lines in the alarm template based on conditions from the other input.
Is that the only way to achieve this, or is there a better way?
There is on the Ateme Decoder protocol a 'Decoder Probe' set of param tables - if these table rows are not populated (i.e. no rows in the table) then that could be what I set as a critical alarm - because it means neither TS input is locked, and I think I would prefer that, so that the ts input lock will always just be major, not critical, but I'm pretty sure I can't alarm on the lack of a table row, so what's the best advice to achieve what I want here please?
Thanks, James.
Hi James,
I see that this question has been inactive for some time. Do you still need help with this? If not, could you select the most relevant answer to indicate that the question is resolved?
As this question has now been inactive for a long time, I will close it. If you still want more information, could you post a new question?
Hi James,
For the first use case, a possible option is to use a correlated alarm. You could try creating a correlation rule based on the conditions that you describe in your question. For this case, you will need to enable monitoring on these column so it can be used in the alarm filter.
For he second use case, I believe it will make sense to update the connector and add a single parameter that counts the number of rows for the TS Inputs table.
Hope it helps.
If you can add a "Service" layer, my preferred approach would be to define some kind of "redundancy group" across the two TS inputs: do you have the state of the selected input as a parameter? If so, you could include just the latter as a Service Critical severity and leave the others as major.
One of the biggest advantages of DM (in my view) is the possibility to define a Service layer, so that operators have a service overview, rather than just a collection of alarms to react to: it requires practice, but in the long run has always paid the effort.
If I understand correctly, you have the following:
TS1 unlocked --> Critical* alarm
TS2 unlocked --> Critical* alarm
TS1 & TS2 unlocked --> 2 critical* alarms
In such a case, if only one TS is "unlocked" would it work to have the "single TS input failure" as major and elevate to critical (e.g. with a correlation as suggested above by Miguel) only when both TS inputs are down for the same decoder?
Within a Service, as long as at least one input is working, I wouldn't use "critical" for a single TS input down if there's other TS that can be used without outage: it's just a modelling choice of your severity, but indeed *there is nothing higher (or lower) in severity than "critical" - I guess operators would prefer to know which event is actually representing lack of service.
Thanks for your response, let me try to write the logic I’m trying to achieve another way:
If decoder config != redundant TS:
—if TS 1 unlocked then critical alarm
—if TS 2 unlocked then NO alarm (this is normal in this case)
else if decoder config == redundant TS:
—if TS 1 unlocked & TS 2 unlocked then critical alarm
—if TS 1 unlocked or TS 2 unlocked then major alarm
I’ve tried and failed to implement this in a protocol alarm template, I am created a service from the majority of these decoders, but it seems sensible to me to apply this at a device level as that’s the most root level you can make it, but I’ll do whatever makes the most sense in DM.
My understanding of services is, in this case, at minimum an encoder and a decoder, and I am working on making such a service, and could look to wrap this into a service alarm but again not sure on the best practice really.
If you prefer staying within the device layer, you may be able to achieve this with a monitoring “condition” in the alarm template & a correlation.
There’s a column you can use to define which condition will disable the monitoring when true.
HTH
Hi James,
Would it be a possibility to add a “Service” layer over your device monitoring done with alarm templates?