My goal is to have the Core Historian process an SOE of DNP3 Events which are pushed via unsolicited messages from an Outstation. Specifically, that when a DNP3 message containing multiple events for a single object, that the Historian would process each event - adding a row with timestamp sourced from event (i.e. the DNP3 Outstation) and not only the most recent value.
I am not seeing this behavior currently.
Below details my test setup, includes a sample COM capture, and Power Chart plot of the results.
DNP3 Server is configured to provide Unsolicited Messages if
Event Queue > 81 events
OR
Max Event Age in Queue > 5s
DNP3 Client is configured to provide Integrity Polls at 10-sec for testing (300-sec for production)
Now we can look and see how the Ignition Core Historian is currently processing the telemetry.
I have tested with 3 Ignition side configurations of the Tag and plotted the results in a Power Chart (the red pen)
As a reference, I have a second Ignition DNP3 client configured the same as above, but with Class 1 Polling at 1s, History is “On Change” with Min Time 1ms and Max Time 10 Minutes (the blue pen)
Ideally, you create a dedicated Tag Group for the OPC tags coming from DNP3 devices where you want to preserve the events, then configure the Tag Group like this: DNP3 Driver | Ignition User Manual
I have configured a “DNP3 Tags” Tag Group and configured the OPC UA and History settings with some confidence but still do not see the “expected behavior” from the Tag Historian of processing the SOE from the DNP3 unsolicited messages.
Have you tried setting Tag Config -> History -> Sample Mode to On Change ? I think you mentioned you had that set for the other DNP3 client, so maybe you've already tried that
(As an aside, I will be investigating the apparent drift in time syncing once the SOE parsing is done. Typically we rely on GPS clocks & IRIG-B for time sourcing at the originating device, but here I have configured DNP3 time sync via IIN1.4 “Need Time” … so I would expect the two sources to be aligned.)
Hi Rob! I am actually working on a project right now using DNP3 and ignition and had my fair share of problems setting it up until I got the data backfill working.
I am going to share the configuration I am currently using for the tags that works (at least for me). Main difference I’m seeing is the history configuration. Sample mode should be set to “On change” I think.
Also, can you enable this field in the DNP3 connection settings and check the logs to verify that you are receiving the data with the correct timestamps? It should indicate “with time” in the logs. I doubt this is the problem since your script correctly reflects the timestamps, but it is best to check.
Can't help specifically with unsolicited messaging but since you have class 1 polling working the first thing I'd suggest if you haven't already is keep your Outstation generating Class 1 events at 1 second intervals but change Ignition to poll every 10 seconds. Then watch on your real-time trend you should see a chunk of data appear every 10 seconds with the correct backfilling of values. If that works then I'd look more specifically at the unsolicited messaging part of things; if its not working then I'd check your connection setup or your Outstation maybe isn't generating events correctly.
I can confirm that things work as expected when using Class Polling to pull in telemetry. Specifically When I slow the Class 1 Polling of the “baseline” DNP3 Server from 1000ms to 10000ms, all event telemetry successfully lands in the Core Historian.
I do not yet see this behavior with unsolicited messages. Currently working with Inductive Automation to troubleshoot further. Tag Changes are seen by the Gateway (verified above with logging).
The Green Trace shows an event in telemetry every second (as expected) with poll rate of 10s.
Then next step would be to setup wireshark and do some captures to look at the DNP3 response coming as unsolicited messaging to see if it's actually including the missing data. It could still be that your outstation isn't including multiple events when it sends the messages while it does include multiple events when its a class 1.
I think that's the best bet for narrowing this down
This step was done as part of my initial post (see above for the PCAP if you are interested).
We have confirmed both with Wireshark and then further with additional logging that the Outstation (server) is providing the telemetry in unsolicited messages. Those unsolicited messages are parsed at the Gateway but do not appear to land in the Core Historian.
Once root cause is determined, I will post back here with detail.
