RTAC-hosted OPC-UA and IEC-61850 data structures

Ignition
1

Here's a 61850 question that's probably not related to the new 61850 driver...

I'm sure many of us in power systems are familiar with those blue boxes from Pullman, WA that fill the bulk of our installs, including their RTAC platform. RTACs use IEC 61850-7-3 data types, such as Measured Value MV commonly used for analogs.

OPC-UA server was recently released as an option for RTACs, and we are optimistic about using this as our link to Ignition rather than DNP3. I can either address the specific tag name, in which case Ignition will return a JSON string that is not a tree in the tag browser. Or I can specifically target an attribute such as .instMag or .Status to pull the actual tag value I want.

But I'd rather have Ignition parse the metadata coming over on this structure, including timestamp and quality.

Is there a way I can handle how Ignition parses data structures from an OPC-UA server? Thanks!

An example JSON coming from a point on an RTAC (in this case .instMag is the actual tag value):

{
  "instMag": 0.0,
  "mag": 0.0,
  "range": 0,
  "q": {
    "validity": 1,
    "detailQual": {
      "overflow": false,
      "outOfRange": false,
      "badReference": false,
      "oscillatory": false,
      "failure": false,
      "oldData": false,
      "inconsistent": false,
      "inaccurate": false
    },
    "source": 0,
    "test": false,
    "operatorBlocked": false
  },
  "t": {
    "value": {
      "dateTime": 133239072380000000,
      "uSec": 563724
    },
    "quality": {
      "leapSecondsKnown": false,
      "clockFailure": false,
      "clockNotSynchronized": true,
      "accuracy": 31
    },
    "daylight_savings_time": {
      "enabled": true,
      "activated": true,
      "offset": 60
    },
    "UTC_Offset": 0,
    "source": {
      "value": 4,
      "priority": 0
    }
  },
  "db": 100.0,
  "zeroDb": 2.0,
  "rangeC": {
    "hhLim": 1.0E+36,
    "hLim": 1.0E+35,
    "lLim": -1.0E+35,
    "llLim": -1.0E+36,
    "minVal": -1.0E+37,
    "maxVal": 1.0E+37
  }
}
2

You'll have to make expression or derived tags that pull out, and manipulate if necessary, the information you're interested in.

3

https://docs.inductiveautomation.com/display/DOC81/jsonGet

4

I guess I could set up UDTs for these 61850-7-3 data types and then nest them within my existing UDTs to parse the various values and metadata, but that would make life messy with tag paths everywhere else such as [provider]path/to/tagName/instMag instead of [provider]path/to/tagName. But that seems to run counter to a logical and semantic deployment of tag structures. I guess it's a trade off to determine if I want/need that metadata or if I want to simply map the root tag path to the value itself.

5

Do you know if they apply the quality and timestamp metadata to the instMag (lossily mapping from 61850 to OPC UA) or not?

6

I'm working on some lab testing to compare that behavior to our previous DNP3 implementation, and may test out Ignition's new 61850 MMS driver as an alt as well.

7

When we forced invalid data or a different timestamp, these did not show up in the primary tag's .Quality or .Timestamp properties. I can map to these properties with separate attributes in the 61850-7-3 datatype by addressing .q.validity or .t.value.dateTime but that still doesn't solve my problem since everything in Ignition is built around the tag's own properties for things like quality overlays, historization timestamps, etc.

I imagine this has been a difficulty for anyone connecting to a OPC-UA server that outputs 61850-7-3 data structures like SEL RTACs. Any suggestions on how to handle this? I don't want to go back to DNP3 for this.

How are Ignition's .Timestamp and .Quality tag attributes populated and is there a way to map in certain sources for this? Thanks

8

for OPC tags they are derived from the StatusCode and timestamp given to us by the server.

No.

This seems like a new product, or at least the first time I've heard of anyone using it. The way they chose to model it retains all 61850 quality and timestamp information but makes it difficult for clients to consume. I don't really have any clever ideas right now.

It would be nice if they at least mapped the severity of the 61850 quality to an equivalent severity in the OPC UA StatusCode, and the timestamp to the OPC UA SourceTime component in the DataValue, then used those derived values when accessing the primary value attribute for a given struct (our driver takes this approach).

9

Yes, they just released OPC-UA server as an add-on in RTAC R150 a few months ago. We are (were?) very excited to use it for projects. I'm reaching out to Schweitzer support to see if there's any way to update StatusCode and SourceTime on the server side.

10

Hmm... we have an SEL-3505... I wonder if we can get the same add-on.

11

Ah, looks like R150 is the firmware version. I'll have to look into this. If nothing else it's good to have more embedded OPC UA servers to test with.

12

OPC UA is only supported on SEL-3350, 3555, and 3560.

Our go-to is the SEL-3555 (We also run Ignition on SEL-3355s - the same substation-grade hardware but with Windows Server). The older RTAC models are based on a PowerPC architecture and are not getting certain new features.

SEL via their local distributors are usually great about lab/loaner units if you're interested in testing.

13

Darn. We have an SEL-3555 too but I'm pretty sure it's just on loan to us.

14

@msteele, If you guys need another heavy user of "Blue Boxes" to hit up their sales and support team on the same issue, please let me know :slight_smile:

15

@FrankP we had a meeting with some of their product team on this recently. SEL is aware and working on a change to their OPC-UA implementation. It is dependent on a change to an upstream library for their OPC-UA implementation, but they're pushing on that as well. I don't want to get into more detail or specifics on their behalf, but our course of action is to keep using DNP3 for our active 2023 projects with a goal of using OPC-UA for future projects.

3 Likes
16

Hey there,

Did you end up getting any more intel out of SEL and have begun using OPCUA?

I'm in the same predicament, though mine is datatypes. It seems there's an issue with how the RTAC presents "DATE_AND_TIME" over OPC, defaulting to FILETIME which is a 64 bit (vs 32 bit) var, which causes things to break on the client end.

17

Nope, still using DNP3 for RTAC to Ignition data flows. Last we heard, they would need changes to a Codesys library.

We're meeting with some RTAC product managers later today about another topic, so I'll see if I can sneak in a request for an update on this topic.

18

Thanks mate,

Have you just been using the native Ignition driver (we have lots of issues with it), the new one, or the 3rd party?