Problem with alarms comming from IEC61850 OPC server (CET) not latched in alarm list
We have a project where we are communicating via IEC61850. The IEC61850 communicaiton is communicated to 800xa through IEC60850 OPC server (Communication Engineering Tool). All signals are communicated from Schneider P139 relays to 800xa without problems.
Though we have some problems with the alarms generated in CET and shown in the 800xa process alarm list. Normally these alarms needs to be acknowledged and be in the RTN state before they disapears from this alarm list, but for all the IEC61850 alarms, they disappears as soon as they enter a RTN state, even when they are not acknowledged.
It is the first project where we are using 800xa version 6.x, and on all other projects where we have used 800xa version 5.x, we have not experienced this kind of problems.
Have anyone experienced this problem before, and/or have a solution to fix this problem?
Thanks in advance.
This issue is appeared in 800xA6.0 version only. We are also facing same problem in 2-3 projects. If customer agrees just keep Inactive acknowledge required as "True" in CET AE properties.
This will give keep Inactive state of alarm in Alarm list but acknowledge will be required from operator to remove it from the list.
Please raise the case to supportline for further assistance and let us also know if any solution is there.
Actually, the behaviour you described is now correctly following the "Incative Acknowledge Required" property of the indication event in CET. Such correction can already be seen in 800xA 5.1 FP4 RevE.
In your case this property seems to be set to "False" as it disappears from AE list when reaching the inactive state.
For protection/trip signals that act as a pulse (duration of milliseconds), you won't see the active state 1 in AE list, but only the inactive status. The operator will then recognize the inactive state of the trip. For that, change the property to "True".
On the other hand, signals that remain in a state for a period (e.g. CBR Discharged Spring) allow the operator's recognition before deactivitation. So, the "Incative Acknowledge Required" property shall be set to "False" if you do not want operator to recognize the signal again after normalization. In my opinion, keeping the property in "True" to recognize the signal "twice" would make sense since you are forcing operator to confirm that he is aware of both the 'problem occurrence/existence' and the 'problem solving' afterwards.