This project has moved and is read-only. For the latest updates, please go here.

New Fields on Device Page in openPDC Manager

Nov 9, 2010 at 5:25 PM


The documentation for the openPDC manager seems to be a little out of date as there are new fields which are not listed on the documentation. I have some questions about the fields in the device pages, namely FramesPerSecond, Data Loss Interval, Allowed Parsing Exceptions, Parsing Exception Window, and Delayed Connection Interval.

FramesPerSecond -- this doesn't appear to be a required field and it seems like it should be, how is it used by openPDC?  In the case of IEEE C37.118 connections how is the DATA_RATE field of the config frame used? Does it replace the value entered in the FramesPerSecond field?

Data Loss Interval -- a time delay on how long the openPDC attempts to reconnect after a connection has been lost.  What determines loss of connection? is it the termination of the TCP/UDP connection or a series of invalid frames or both?

Allowed Parsing Exceptions & Parsing Exception Window  -- As I understand it these are used to determine when a connection has been corrupted.  For example if Allowed Parsing Exceptions = 10 and Parsing Exception Window = 5  if 10 invalid frames are encountered in 5 seconds the connection is deemed invalid and the connection is reset. Is this correct?

Delayed Connection Interval  -- another time delay on the device connections, this is imposed on all connection and reconnection attempts.  How does this work with Data Loss Interval? which take precedence in the case of a lost connection or do they add together?

My system currently has 5 devices communicating to an openPDC server acting as a concentrator which puts them into one output stream which connects to another server runing openPDC which acts as the historain and provides data to our internal network through the the xml interfaces.  The 5 devices communicate using C37.118-2005 over a cellular connection and transmit data at 1 frame per second.  For the most part the system works fine but every once in a while a unit will lose connection to the concentrator due to the cell network reliability and the openPDC can't seem to reconnect to the devices properly, I believe it is trying to reconnect before the cell modem in the device has identified a loss of connection.  I have tried adjusting the fields above and it has helped somewhat but now all of the data coming through the xml interface is being flagged as "SuspectData" the value tags are still correct however.  How do the above fields relate to the quality tags in the xml interface of the historian? I have tried updating all of the appropiate config frames but the data is still being flagged as suspect.

Thank You,

Jason Bank

Nov 10, 2010 at 2:38 AM
Edited Nov 10, 2010 at 2:48 AM

The frames per second field isn't required since it will default to 30 if not specified. This frame rate defines the maximum publication rate of an outgoing data stream as well as defining the DATA_RATE field in config frame as you mention. This is not as important for incoming connections - you can have various input frame rates all going into one output stream with a fixed maximum frame rate.

The data loss interval is for connections that are still active from a socket perspective but stop receiving data. A connection loss will result in restarting the connection cycle anyway.

On the parsing exception parameters, this related to parsing "errors" (CRC failures, malformed data packets, etc.) - this is not related to the status bits being reported as invalid.

The delayed connection interval defines the minimum interval by which the system wait between failed connection attempts. Some devices need a little more time between connection attempts in order to respond properly to connection attempts.

In your cellular connection case I would definitely increase the delayed connection interval to several seconds - perhaps as many as 15 to 30 seconds depending on the severity of the network delay.

Suspect data is based on the bits in the reporting device; these are abstracted by the openPDC since it can make connections to devices with different protocols (see for more information). The quality flags for the historian are based on the following expression:

measurement.IsDiscarded ? Quality.DeletedFromProcessing : (measurement.ValueQualityIsGood ? (measurement.TimestampQualityIsGood ? Quality.Good : Quality.Old) : Quality.SuspectData))

So the suspect data flag is only set when the value quality of the associated measurement is *not* good. Channel value measurements from phasor protocols are mapped directly to the DataIsValid bit of the associated PMU. Your aforementioned settings shouldn't have an affect on this quality for "input" devices, however, in your concentrated output stream - the concentrator will set the DataIsValid bit to False if all the expected source measurements did not arrive before publication. In this case you try adjusting the lead/lag time parameters of the output stream to accommodate for network delays -or- simply disable the processing of the data valid flag (i.e., set processDataValidFlag  to False in the connection string).

Hope that helps!

Nov 10, 2010 at 3:03 PM

Thanks for the quick reply.

That cleared up most of the questions I had.  The problem with the SuspectData flag seems to be originating with the concentrator.  It has a historian for the devices but it is always disabled, the other server is archiving all of the data.  When a new device is added to the concentrator or the parameters of an existing one are changed all the data is being flagged as suspect until its historian is enabled, all new parameters/measurements added to it then disabled again.  I have run into similar data handling and addressing errors before, all of them relating to not having an active historian.  It seems like the data stream parameters do not update properly without a historian.

Jason Bank