IEC 61850 alarm time

[KIM_JINGEUN]

I am importing data through IEC 61850. In IEC61850, when data changes, a timestamp is uploaded. When an alarm occurs by setting an alarm for one data, I want to record the alarm time using the timestamp received from IEC61850, not the server time. What should I do?

[Nikzitronik1]

Hello,

Did you find a solution to your problem? I am designing a system with the same requirment.

[tevis]

You can set the Alarm Timestamp source, and ensure that you are also subscribed to the relevent _t tag.

eg: subscribe to the following:

• {BUFFERED REPORT PATH}.PRO_BK1XCBR1.Pos.stVal
• {BUFFERED REPORT PATH}.PRO_BK1XCBR1.Pos.t

IEC61850 Alarm Time Delay

Hi there, I have configured IEC61850 based alarms for CB position feedback. I am also receiving the timestamp from the IED. These are both part of a IEC61850 Buffered Report. My issue is that the status tag updates slightly before the timestamp, (1-2s when viewing in designer). This results in my alarms having the timestamp of the previous change of state. Adding a time delay to the alarm does not seem to rectify this. I have included screenshot showing ignition alarm status table, and the …

[Kevin.Herron]

The timestamp that is associated with the stVal value in the data change notification should be the one from the report, and the same one (eventually) as the t Node. You probably don’t need to subscribe to t at all.

[tevis]

thanks Kevin that makes sense, I was wondering how this might affect my issue I have raised in the above hyperlink? Am I setting the timestamp source correctly?

[Kevin.Herron]

I’m not sure about the alarming stuff, somebody else might have to answer that (or a support ticket).

It might be useful to set the logger found searching “ReportAddressSpace” to TRACE level and then look at the trace log messages that get emitted when a report is received to make sure the value and source timestamp are as expected to begin with.

[tevis]

Thanks Kevin, there is an intermediate RTU in-between Ignition and the IED which might be confusing things. I was hoping to ignore it and simply read the update times for individual tags which are passed through.

Even if I set the Alarm timestamp as:

{[.]CB_STATE_T.value}

and configure 10s Active Delay, i’m still getting incorrect timestamps. Ill check in with support.

[Kevin.Herron]

Can you verify the date and time on both the Ignition server and your RTU (both the intermediate and downstream) are correct?

I noticed in the log screenshot you sent support that the SourceTimestamps are a full day ahead of the other timestamps for some reason:

[tevis]

Hi Kevin, I've realised that ignition uses the report timestamp as the Alarm timestamp source.

As I have:

IED >> RTU >> Ignition

The report timestamp is not actually generated in the IED. Once I have all devices synced to PTP clock source it will be more accurate, but I'm hoping to generate an alarm based on the .stVal and .t returned from the IED (via the RTU).

I am hoping to just build a custom alarm based on .stVal and .t with a time delay as mentioned here:

Timestamp source alarming

Ignition won’t do this an any automated way, but it is possible with some PLC code. Basically, you have to capture the input card’s timestamp in the PLC and place it in a register available to Ignition. Or in a queue of custom event structures. In a Logix processor, you would add the CST-Localtime adjustment offset to get a 64-bit Unix-style timestamp with microsecond precision. If you want accuracy too, not just precision, the HiProm GPS module is a good (if expensive) choice. It offers GP…

support ticket (#156868)

[Kevin.Herron]

I think it may be difficult, as you noticed initially, data change notifications for stVal and t arrive independently and without any guarantee of order.

This is true for all values from all OPC UA servers - the only way to guarantee independent values arrive together in a data change notification is for a server to expose them in a structured value and for the client to subscribe to the structured value. And this assumes the underlying data source can update atomically.

When the 61850 driver receives a report for stVal (and any other point where this is appropriate) it takes care to use the associated quality and timestamp when it constructs the OPC UA DataValue. After that any special relationship between stVal and t is lost - it only exists in 61850, not in OPC UA, and not in Ignition.

Hopefully somebody here or in support has some tricky alarm solution for you.

[tevis]

Do you know if this is the implementation of the TMW driver? This menu item does look like there was some intent there at some point:

IED/s will commonly will set buffer time of 1ish seconds, the server accumulates all data changes occurring during that time and generates a report at the end of the buffer time reporting all changes. This prevents multiple reports executing from single “event”. - lots of things happening in a few hundredths of a second.

In a situation where a breaker is closed, trip occurs, bus fault, breaker fault etc. Ignition implementation would result in all of these events having the exact same timestamp - missing out on one of the awesome functions of Reports.

[Kevin.Herron]

Unless you enable that setting, all the events will have their own individual timestamps, from the corresponding t node if available. That setting was added by request and the default behavior remains unless you enable it. edit: it may have been a request, but it's been an option since the driver was released.

From the posts you've made I would think you do not want to enable that.