We are using Ignition solely for alarm notification on our site. We generate alarms in our PCS system and in Ignition we subscribe to the OPC path for the PCS alarm. We use an expression in the Is Active value of the alarm to evaluate if that value is not equal to 0. Anything not equal to 0 and the alarm is enabled.
This works pretty well but it has some limitations in the current setup & I'm just hoping for some general ideas about how to make it a bit more robust.
Within our PCS system, the value that we read in Ignition will show that the alarm is active even when the alarm is shelved or when it is acknowledged (I would need to confirm the acknowledged state to be certain). I'd like to leverage the PCS status (acknowledged/shelved) to update the status in Ignition.
I think I could simply enough subscribe to those acknowledged & shelved states over OPC & use that to update the applicable state in Ignition, but I'm not sure if that is the best approach. As I understand it, additional subscriptions place additional load on the OPC server & on top of that, we are license restricted (on our PCS system which host the OPC server - Ignition is acting as the client) & I'd need to get more licenses to subscribe to all of these additional points.
Any thoughts or general pointers on how you might approach this? Thanks in advance!
First off, you're not license restricted with Ignition, so that shouldn't be an issue unless it's a restriction on something else (are you using a different OPC server besides Ignition?)
For the acknowledgement, you should be able to monitor a tag that when it goes true, you simply script the system.alarm.acknowledge() function to acknowledge the alarm.
Shelving might get a little trickier as there's a time component associated with it. You can script shelving also using system.alarm.shelve() and system.alarm.unshelve() but if you don't specify a time, it will default to 15 minutes.
I edited above to reflect accordingly, but the license restriction comes into play from our PCS system which is our OPC server. Ignition is serving as a client in this case.
I think in an ideal scenario for us, a changed state of the alarm value would trigger an OPC read of the associated shelving and acknowledged states of that alarm in our PCS system. Not sure how plausible that is.
I could be overthinking the impact of this, but the concern is that we have 3-5 alarms which are, within Ignition, dynamically enabled or disabled via a OPC point from our PCS. It's just going to be a lot of points to subscribe to & these points will only update whenever the alarm value changes. To be honest, I really only care about them when the tag goes into an alarm state.
For clarity, if we ever ran into a scenario where the alarm was shelved in PCS but did not actually escalate into an alarm condition in PCS, I don't necessarily care that Ignition knows about it. Since we really just use Ignition for alarm escalation, my main concern is that we prevent alarm escalation.
I think I may have devised a solution on my end that'll meet my needs but hopefully someone can chime in if this seems to be a suitable approach. I just want to make sure that I'm not going to cause unforeseen issues by taking this approach.
Thought here is to create a memory tag for each alarm type in the UDT. The OPC tag which reads the alarm status from PCS would use a 'Value Changed' script to set the memory tag to an arbitrary value of 0 for not enabled and 1 for enabled.
The memory tag would also have a 'Value Changed' script. This script would loop on a TBD interval and would perform polling of applicable OPC points. If the script found that the tag remains in alarm, and that it was not marked out of service, acknowledged or shelved in PCS, then it would set the value of the memory tag to a new value of let's say 5.
The alarm itself, tied to the PV, would then evaluate to true in a case where the memory tag is equal to 5. Any other value and the alarm would evaluate to false & no alarm escalation would occur.
Main concern I have is if there is potentially an issue w/ looping this value changed script for an indefinite amount of time... if it has possible implications if we were to say encounter multiple alarms & that kind of thing. We have a working system at the moment & don't have a test system so I'm a bit hesitant to test extensively without a bit of insight.
Yeah, no, not safe. Tag events need to execute to completion in single digit milliseconds or less, or you risk stalling your entire gateway. No sleeping, no condition-checking loops.
Other events, like tag change events in a project, have a little more freedom to do time-consuming things, but not indefinite looping either.
I'm not entirely clear on the architectural limitations of your situation, but this isn't a workable answer.
Kind of had a feeling that might be the case but thanks for the confirmation.
Main limitations on our system is that I'm license restricted from PCS. Without looping off the event script, I'm not sure there's another way other than subscribing to those OPC points then that I can think of.
Just ends up being a lot of points & I didn't want to add more strain to the system (the OPC server on PCS) than needed... especially since those points really only become relevant when a point goes into an alarm state.
You're overthinking this, but an easy solution to me to avoid the constant subscription "overhead" would be, for each alarm I guess, put these peripheral tags into a separate Tag Group that is configured as driven, based on whatever the main alarm condition is. You could even make the group OPC Data Mode Polled instead of Subscribed and it will just read those points while active, instead of create a subscription.
Process Control System - that's what I've always heard DeltaV referred to.
So in our case, we are probably a bit outside the 'normal' configuration. We have a qualified system in DeltaV where we generate alarms initially. Ignition is used in a diminished capacity to just send out alarms & that's really it.
I think that might work. I need to do a bit of testing to see if I can do that within the confines of our licensing restrictions or not (from DeltaV - not Ignition).
Do you happen to know if the polling on that group is sequential? As I understand it, I'm going to tie up a license allocation when I open a connection to these points & then I'll free up that same allocation as soon as I finish the request / polling of that point.
I can give this a test though if not. Not any real risk in this case.
Sounds good. I'll give that a shot & see what it does to the licensing. I think it might tie up all the remaining slots we have but I think there could be some restructuring of other points that might free up enough licenses. Worst case we might need some more licensing & that's not a huge deal.
Thanks!
Edit: Just realized you said it'd keep polling till the driving condition went false. I take that to mean it'll just keep polling till it gets signals back on all of them. My guess is that'll just eat the remaining licensing up, get some of the points, poll again, get more points, etc, until completion. Time to do some testing. Thanks again to everyone for the help!