Support Forums
Is it possible to have each server of the same instance have their own Alarm and Event DBs?

Hi,

Is it possible for each server/station of the same VTScada application to have their own Alarm DB and Event DB?

Or is there any way so that alarms would need to be acknowledged independently on each server/station? So if an alarm is acknowledged on one server, it still shows up as unacknowledged on the other.

Thanks
Victor

Hi, Is it possible for each server/station of the same VTScada application to have their own Alarm DB and Event DB? Or is there any way so that alarms would need to be acknowledged independently on each server/station? So if an alarm is acknowledged on one server, it still shows up as unacknowledged on the other. Thanks Victor

An alarm can only have one state. The purpose of an alarm is to transition between states when certain conditions are met.

You could do workarounds (multiple alarms), but these are generally poor designs:

  • Decreases usefulness of audit trail
  • Decreases operational ability to respond to the alarm, as the alarm state can not be unambiguously determined. (the event that caused the alarm could already have been acknowledged and cleared)
  • Becomes difficult to determine between a chattering or fleeting alarm

ISA 18.2 is a well-defined standard and mandated in many control system fields. Your first point of thought should be alarm rationalization (what causes this event in the first place), and then to when and how should the SCADA system notify operators.

How the designated responding operators respond to an abnormal condition is an operational consideration.

An alarm can only have one state. The purpose of an alarm is to transition between states when certain conditions are met. You could do workarounds (multiple alarms), but these are generally poor designs: * Decreases usefulness of audit trail * Decreases operational ability to respond to the alarm, as the alarm state can not be unambiguously determined. (the event that caused the alarm could already have been acknowledged and cleared) * Becomes difficult to determine between a chattering or fleeting alarm ISA 18.2 is a well-defined standard and mandated in many control system fields. Your first point of thought should be alarm rationalization (what causes this event in the first place), and then to when and how should the SCADA system notify operators. How the designated responding operators respond to an abnormal condition is an operational consideration.
edited Mar 13 '18 at 3:37 pm

If I understand your question correctly, you can use Realm/Tag Area Filtering separate databases, users, tags, etc. between servers. You can start learning about that here: https://www.trihedral.com/help/Content/D_Tags/Dev_FilteringOverview.htm

If I understand your question correctly, you can use Realm/Tag Area Filtering separate databases, users, tags, etc. between servers. You can start learning about that here: https://www.trihedral.com/help/Content/D_Tags/Dev_FilteringOverview.htm

Trihedral Engineering Ltd.

Micheal, so I guess it doesn't matter which Alarm DB it is, the state of an alarm is stored on the tag itself. So having multiple Alarm DBs doesn't really work in this case then.

Dave, each stations would need access to the same tags so I don't think Realm/Tag Area is the right direction.

Basically, the customer wants to have all stations to acknowledge the same alarm independently.

And right now, the only way that I can think of is just having completely independent VTScada application on each station, but that would increase the number of read to the field devices.

Micheal, so I guess it doesn't matter which Alarm DB it is, the state of an alarm is stored on the tag itself. So having multiple Alarm DBs doesn't really work in this case then. Dave, each stations would need access to the same tags so I don't think Realm/Tag Area is the right direction. Basically, the customer wants to have all stations to acknowledge the same alarm independently. And right now, the only way that I can think of is just having completely independent VTScada application on each station, but that would increase the number of read to the field devices.

If I understand your problem correctly you want a tag to cause its alarm to appear on all workstations together, but each workstation should be required to acknowledge the alarm for itself. I believe that you can achieve this by declaring each workstation to be its own alarm server. This way the tags could get data from a common driver server, the alarms would be treated and stored quite independantly - worth looking in to I suggest?

If I understand your problem correctly you want a tag to cause its alarm to appear on all workstations together, but each workstation should be required to acknowledge the alarm for itself. I believe that you can achieve this by declaring each workstation to be its own alarm server. This way the tags could get data from a common driver server, the alarms would be treated and stored quite independantly - worth looking in to I suggest?

That's it, Andyn. Thank you so much. That's exactly what I need.

That's it, Andyn. Thank you so much. That's exactly what I need.
144
5
4
live preview
enter atleast 10 characters
WARNING: You mentioned %MENTIONS%, but they cannot see this message and will not be notified
Saving...
Saved
With selected deselect posts show selected posts
All posts under this topic will be deleted ?
Pending draft ... Click to resume editing
Discard draft