Project

General

Profile

Feature #18743

Limitations of Alarm Mapping for multi-area Front-ends

Added by Dennis Nicklaus over 1 year ago. Updated over 1 year ago.

Status:
Closed
Priority:
Normal
Assignee:
-
Category:
-
Target version:
-
Start date:
01/16/2018
Due date:
% Done:

0%

Estimated time:
Duration:

Description

Wally Kissel called to note that a device's alarm was not noticed because the device is in clx40e which is mapped to the accelerator projects page on the alarms screen.
The missed alarm was for swyd or some other place. Clx40e covers multiple locations because it generally hosts PLC devices. There are several other erlang front-ends which similarly cover many locations.

I don't know the best way to handle this with our current features. Ideally (IMHO) finer grained mapping? Can you map a node to multiple alarm places? (But then you get the other alarms from other areas that aren't of interest.) Re-allocate devices to change erlang front-ends from a functional (e.g. PLC) focus to location focus? Use "virtual nodes" sort of like we did on clx58 where cmlrfa,b,c,d all point to the same clx58e erlang FE? That isn't without its problems either, mostly in difficulty of startup downloads.

History

#1 Updated by Dennis Nicklaus over 1 year ago

  • Status changed from Under Discussion to Closed

Brian tells me (and he had already told Wally) that we can already do all this with Alarm Lists. See D59.
So, this becomes more of a process management thing. When you create alarmed devices on these frontends which cover multiple areas, you should enter the devices into an appropriate Alarm List. For existing devices/front-ends, you can use an ACL command like this:

ACL> list oid=187/node=clx40e "%nm %has_analog_alarm %has_digital_alarm"

to find all the alarmed devices with a particular erlang or MOOC OID (in this example, with OID 187 on the clx40e node).
In the clx40 startup script, there is an OID defined:

,{187,plcdirect_driver,
[{name, "mc1-lcw-plc"},

So the above ACL command lists all the devices with that OID (derived from that PLC) and tells you whether they have an alarm.
So now just take those device and add them to an appropriate (Muon Campus, in this example) alarm list, and everybody is happy.

I'm closing this Issue because there's nothing in the infrastructure that needs to change. We just need to manage our alarm devices properly on multi-area frontends.



Also available in: Atom PDF