openpdc Wiki & Documentation Rss Feed

New Comment on "Documentation"

gianghtdbk — Tue, 28 May 2013 06:38:47 GMT

Dear Sir/Madam, I am Giang from Vietnam. I am learn about the software OpenPDC. I am currently involve in the project "Building a Lab Synchrophasor Model for an University in Vietnam". According to my plan, the Lab Synchrophasor Model will includes the components below: - The software OpenPDC administered by the Grid Protection Alliance (GPA) - Five PMUs (using the set of SEL- 571A) - One GPS clock (using the set of SEL 2407) - Two Test Sets However, currently, I have some problems for this modle, my problems are: - I don't know all components above are enough to run the Synchrophasor model? - How I can connect the software OpenPDC to PMUs? - How I can send Synchrophasor data from PMUs to OpenPDC? Could you please give me some guides for the problems above? Looking for your helps!

Updated Wiki: Documentation

ritchiecarroll — Tue, 23 Apr 2013 13:52:59 GMT

Note: you can get a quick optimization of the openPDC run-time assemblies by using the .NET native image cache NGen. To apply these optimizations after the openPDC has been installed, run the following commands from an administrative console:

CD "C:\Program Files\openPDC\"
C:\Windows\Microsoft.NET\Framework\v4.0.30319\ngen install openPDC.exe
C:\Windows\Microsoft.NET\Framework\v4.0.30319\ngen install TVA.PhasorProtocols.dll
C:\Windows\Microsoft.NET\Framework\v4.0.30319\ngen install HistorianAdapters.dll
C:\Windows\Microsoft.NET\Framework\v4.0.30319\ngen install PowerCalculations.dll
C:\Windows\Microsoft.NET\Framework\v4.0.30319\ngen install ICCPExport.dll

The most recent system API help and documentation can be downloaded from the Nightly Builds - it's included with the binaries. This help can be used as standalone, compiled help files (.chm) or can be directly integrated within Visual Studio. We have also made our help system available online: Synchrophasor Protocol Classes Documentation

Updated Wiki: openPDC OSI-PI Adapters

swilliam26 — Tue, 23 Apr 2013 12:41:43 GMT

Minimum Requirements

PI SDK v1.4.0 or greater (use 32-bit or 64-bit to match openPDC) must be installed on the openPDC server
Desired PI server connection must be added to the SDK
Access to PI system using PI trust (preferred) or explicit login
1. Connection must have access to read/write any points mapped to openPDC.
2. If the metadata synchronization is enabled, connection must also have read/write access to the pipoint database.

Output Configuration on an Existing openPDC Installation

Open the openPDC manager and navigate to Outputs > Historians.
Click the Clear button to create a new historian.
Type name is PIAdapters.PIOutputAdapter. Assembly name is PIAdapters.dll.
Connection string should be the following: server=<servername>;
1. For explicit logins, add the following:
  username=<pi username>;password=<pi password>;
2. To have openPDC create new PI tags for all archived measurements if they don’t already exist, add the following: runMetadataSync=True;
Save the adapter configuration.
Navigate to Manage > Measurements.
Choose each measurement that should be archived to PI, and change its historian to the PI historian that was set up on the Historians page.

Output Configuration on a new openPDC Installation

In the configuration setup utility, make sure to check the “Setup / change the primary historian” checkbox on the “Apply configuration changes” screen.
On the next screen, which is the “Set up primary historian” screen, select “PI : Archives measurements to a PI server using PI SDK”
On the “Set up historian connection string” screen, set the servername property to the name of your PI server from the PI SDK.
1. For explicit logins, set the values of the username and password properties.
2. To have openPDC create new PI tags for all archived measurements if they don’t already exist, set the RunMetadataSync Property to True. Otherwise, set it to false.
Continue with the setup utility. This will make all your measurements archive to PI by default.

Real-time Input Adapter Configuration

The real-time PI input adapter connects to PI using event pipes, which is the same mechanism process book uses to retrieve real-time data. The adapter also uses the connect on demand feature in openPDC, which allows it to only query PI for data being used an action adapter or output adapter.

In the openPDC manager, go to Adapters > Input Adapters.
Enter a name for the PI input adapter.
For the type of adapter, choose “PI : Reads real-time measurements from a PI server using PI SDK.”
Set the ServerName property to the name of the PI server from the PI SDK
If you wish to connect to the PI server using explicit logins, set the UserName and Password properties too.
Add an additional property to the connection string: “ConnectOnDemand=True;”
Next, go to the Manage > Measurements screen.
You will need to manually add measurements that you wish to make available in openPDC. Either the point tag or the alternate tag must match the point’s tag in PI. It is recommended to create a separate historian (probably virtual output historian) to archive all measurements and set the PI adapter’s output measurement keys to everything on the historian with a FILTER expression.

Updated Wiki: Documentation

swilliam26 — Tue, 23 Apr 2013 12:36:21 GMT

CD "C:\Program Files\openPDC\"
C:\Windows\Microsoft.NET\Framework\v4.0.30319\ngen install openPDC.exe
C:\Windows\Microsoft.NET\Framework\v4.0.30319\ngen install TVA.PhasorProtocols.dll
C:\Windows\Microsoft.NET\Framework\v4.0.30319\ngen install HistorianAdapters.dll
C:\Windows\Microsoft.NET\Framework\v4.0.30319\ngen install PowerCalculations.dll
C:\Windows\Microsoft.NET\Framework\v4.0.30319\ngen install ICCPExport.dll

Updated Wiki: Documentation

swilliam26 — Tue, 23 Apr 2013 12:34:19 GMT

CD "C:\Program Files\openPDC\"
C:\Windows\Microsoft.NET\Framework\v4.0.30319\ngen install openPDC.exe
C:\Windows\Microsoft.NET\Framework\v4.0.30319\ngen install TVA.PhasorProtocols.dll
C:\Windows\Microsoft.NET\Framework\v4.0.30319\ngen install HistorianAdapters.dll
C:\Windows\Microsoft.NET\Framework\v4.0.30319\ngen install PowerCalculations.dll
C:\Windows\Microsoft.NET\Framework\v4.0.30319\ngen install ICCPExport.dll

Updated Wiki: Documentation

swilliam26 — Tue, 23 Apr 2013 12:32:39 GMT

CD "C:\Program Files\openPDC\"
C:\Windows\Microsoft.NET\Framework\v4.0.30319\ngen install openPDC.exe
C:\Windows\Microsoft.NET\Framework\v4.0.30319\ngen install TVA.PhasorProtocols.dll
C:\Windows\Microsoft.NET\Framework\v4.0.30319\ngen install HistorianAdapters.dll
C:\Windows\Microsoft.NET\Framework\v4.0.30319\ngen install PowerCalculations.dll
C:\Windows\Microsoft.NET\Framework\v4.0.30319\ngen install ICCPExport.dll

Updated Wiki: openPDC OSI-PI Adapters

swilliam26 — Tue, 23 Apr 2013 12:30:44 GMT

Minimum Requirements
1. PI SDK v1.4.0 or greater (use 32-bit or 64-bit to match openPDC) must be installed on the openPDC server
2. Desired PI server connection must be added to the SDK
3. Access to PI system using PI trust (preferred) or explicit login
a. Connection must have access to read/write any points mapped to openPDC.
b. If the metadata synchronization is enabled, connection must also have read/write access to the pipoint database.
Output Configuration on an Existing openPDC Installation
1. Open the openPDC manager and navigate to Outputs > Historians.
2. Click the Clear button to create a new historian.
3. Type name is PIAdapters.PIOutputAdapter. Assembly name is PIAdapters.dll.
4. Connection string should be the following: server=<servername>;
a. For explicit logins, add the following:
username=<pi username>;password=<pi password>;
b. To have openPDC create new PI tags for all archived measurements if they don’t already exist, add the following: runMetadataSync=True;
5. Save the adapter configuration.
6. Navigate to Manage > Measurements.
7. Choose each measurement that should be archived to PI, and change its historian to the PI historian that was set up on the Historians page.
Output Configuration on a new openPDC Installation
1. In the configuration setup utility, make sure to check the “Setup / change the primary historian” checkbox on the “Apply configuration changes” screen.
2. On the next screen, which is the “Set up primary historian” screen, select “PI : Archives measurements to a PI server using PI SDK”
3. On the “Set up historian connection string” screen, set the servername property to the name of your PI server from the PI SDK.
a. For explicit logins, set the values of the username and password properties.
b. To have openPDC create new PI tags for all archived measurements if they don’t already exist, set the RunMetadataSync Property to True. Otherwise, set it to false.
4. Continue with the setup utility. This will make all your measurements archive to PI by default.

Real-time Input Adapter Configuration
The real-time PI input adapter connects to PI using event pipes, which is the same mechanism process book uses to retrieve real-time data. The adapter also uses the connect on demand feature in openPDC, which allows it to only query PI for data being used an action adapter or output adapter.
1. In the openPDC manager, go to Adapters > Input Adapters.
2. Enter a name for the PI input adapter.
3. For the type of adapter, choose “PI : Reads real-time measurements from a PI server using PI SDK.”
4. Set the ServerName property to the name of the PI server from the PI SDK
5. If you wish to connect to the PI server using explicit logins, set the UserName and Password properties too.
6. Add an additional property to the connection string: “ConnectOnDemand=True;”
7. Next, go to the Manage > Measurements screen.
8. You will need to manually add measurements that you wish to make available in openPDC. Either the point tag or the alternate tag must match the point’s tag in PI. It is recommended to create a separate historian (probably virtual output historian) to archive all measurements and set the PI adapter’s output measurement keys to everything on the historian with a FILTER expression.

Updated Wiki: Documentation

staphen — Mon, 22 Apr 2013 15:30:46 GMT

CD "C:\Program Files\openPDC\"
C:\Windows\Microsoft.NET\Framework\v4.0.30319\ngen install openPDC.exe
C:\Windows\Microsoft.NET\Framework\v4.0.30319\ngen install TVA.PhasorProtocols.dll
C:\Windows\Microsoft.NET\Framework\v4.0.30319\ngen install HistorianAdapters.dll
C:\Windows\Microsoft.NET\Framework\v4.0.30319\ngen install PowerCalculations.dll
C:\Windows\Microsoft.NET\Framework\v4.0.30319\ngen install ICCPExport.dll

Updated Wiki: Controlling UDP Data Loss

staphen — Mon, 22 Apr 2013 15:30:20 GMT

Regarding the issues that some openPDC users have reported about UDP data loss on 120 fps streams, a new parameter has been introduced to the connection string for input devices called bufferSize. This property controls the size of the kernel buffer used to receive data from the device so that packets will not be dropped during garbage collection. If you are experiencing UDP data loss, try increasing the buffer size by setting this property via the connection string used to connect to your device.

Example connection string (2 MB buffer):
localport=4712; transportprotocol=udp; interface=0.0.0.0; bufferSize=2097152

If modifying this property does not solve the UDP data loss, you may also try reading the information below.

Some openPDC users have reported UDP data loss on 120 fps streams and/or systems that were heavily loaded. That is even though Wireshark reported all the data arriving on the system, the openPDC wasn't receiving all the data. The issue here is the .NET Garbage Collector that blocks threads during a blocking/forced unused memory collection every 10-15 seconds - the more memory that is in use amplifies the time required to collect. More specifically, if you do not retrieve data from the Windows UDP socket buffer queue fast enough it will replace the existing buffer with new data. When the garbage collector starts taking more time there is more opportunity for loss (data replacement with new data) on the UDP socket. During garbage collection data loss can simply be caused by amplification in memory usage (which causes GC to take longer) or heavily loaded system (meaning the GC is competing for CPU and therefore taking longer). The issue can occur simply by increasing samples per second and/or using large lag times, like 30 seconds.

The solution is to force garbage collection more often. All recent versions of the openPDC include a setting in the configuration file to do a generation zero garbage collection on a specified interval - increasing the frequency of garbage collection for generation zero objects on the 4.0 framework will resolve data loss when lag times (i.e., basic memory utilization) are reasonable (e.g., 3-5 seconds of lag time) even when receiving data at 120 samples per second.

On .NET 4.0 builds the issue can return once lag times are increased (e.g., to 30 seconds) thereby increasing memory pressure and the need to collect large volumes of data - this is because with a large lag time the allocated memory will be promoted to generation 2 and 3 and a generation zero collection will be ineffective. Increasing the garbage collection to generation to 2 or 3 on an interval may increase CPU loading to a point where data can again occur.

On .NET 4.5 the garbage collector has been vastly improved - the improvements include an "optimized" collect as well the ability to perform a non-blocking collect. On the .NET 4.5 build of the openPDC, code has been modified such that the interval garbage collection method can be performed against generation 1 through 3 objects using optimized, non-blocking garbage collection running every 5 milliseconds without a significant impact on CPU loading*. With this in place testing showed no data loss even with significant memory usage at 120 samples per second.

Bottom line:

If you are experiencing UDP data loss on GPA products where you can confirm that data is being received (e.g., with Wireshark), simply enabling the interval garbage collection method may help (i.e., change the systemSettings/GCGenZeroInterval to 50 milliseconds); continuing to increase frequency (i.e., lower interval) could make a difference. Upgrading the system to the .NET 4.5 version of the openPDC (version 2.0) will resolve the issue entirely.

* Note that on .NET 4.5 deployments, garbage collection performance can be affected by the runtime settings in the config file (e.g., openPDC.exe.config). If these settings are defined in config file (see example below), please remove them so that the default settings will be used:

  <runtime>
    <gcConcurrent enabled="false" />
    <gcServer enabled="true" />
  </runtime>

Updated Wiki: Documentation

ritchiecarroll — Mon, 22 Apr 2013 14:19:12 GMT

CD "C:\Program Files\openPDC\"
C:\Windows\Microsoft.NET\Framework\v4.0.30319\ngen install openPDC.exe
C:\Windows\Microsoft.NET\Framework\v4.0.30319\ngen install TVA.PhasorProtocols.dll
C:\Windows\Microsoft.NET\Framework\v4.0.30319\ngen install HistorianAdapters.dll
C:\Windows\Microsoft.NET\Framework\v4.0.30319\ngen install PowerCalculations.dll
C:\Windows\Microsoft.NET\Framework\v4.0.30319\ngen install ICCPExport.dll

Updated Wiki: Documentation

ritchiecarroll — Mon, 22 Apr 2013 13:41:40 GMT

CD "C:\Program Files\openPDC\"
C:\Windows\Microsoft.NET\Framework\v4.0.30319\ngen install openPDC.exe
C:\Windows\Microsoft.NET\Framework\v4.0.30319\ngen install TVA.PhasorProtocols.dll
C:\Windows\Microsoft.NET\Framework\v4.0.30319\ngen install HistorianAdapters.dll
C:\Windows\Microsoft.NET\Framework\v4.0.30319\ngen install PowerCalculations.dll
C:\Windows\Microsoft.NET\Framework\v4.0.30319\ngen install ICCPExport.dll

Updated Wiki: Documentation

staphen — Mon, 22 Apr 2013 13:21:41 GMT

CD "C:\Program Files\openPDC\"
C:\Windows\Microsoft.NET\Framework\v4.0.30319\ngen install openPDC.exe
C:\Windows\Microsoft.NET\Framework\v4.0.30319\ngen install TVA.PhasorProtocols.dll
C:\Windows\Microsoft.NET\Framework\v4.0.30319\ngen install HistorianAdapters.dll
C:\Windows\Microsoft.NET\Framework\v4.0.30319\ngen install PowerCalculations.dll
C:\Windows\Microsoft.NET\Framework\v4.0.30319\ngen install ICCPExport.dll

Updated Wiki: OSI-PI Adapters

staphen — Mon, 22 Apr 2013 13:20:37 GMT

openPDC OSI-PI Adapters

Minimum Requirements

PI SDK v1.4.0 or greater (use 32-bit or 64-bit to match openPDC) must be installed on the openPDC server
Desired PI server connection must be added to the SDK
Access to PI system using PI trust (preferred) or explicit login
1. Connection must have access to read/write any points mapped to openPDC.
2. If the metadata synchronization is enabled, connection must also have read/write access to the pipoint database.

Output Configuration on an Existing openPDC Installation

Open the openPDC manager and navigate to Outputs > Historians.
Click the Clear button to create a new historian.
Type name is PIAdapters.PIOutputAdapter. Assembly name is PIAdapters.dll.
Connection string should be the following: server=<servername>;
1. For explicit logins, add the following: username=<pi username>;password=<pi password>;
2. To have openPDC create new PI tags for all archived measurements if they don't already exist, add the following: runMetadataSync=True;
Save the adapter configuration.
Navigate to Manage > Measurements.
Choose each measurement that should be archived to PI, and change its historian to the PI historian that was set up on the Historians page.

Output Configuration on a new openPDC Installation

In the configuration setup utility, make sure to check the "Setup / change the primary historian" checkbox on the "Apply configuration changes" screen.
On the next screen, which is the "Set up primary historian" screen, select "PI: Archives measurements to a PI server using PI SDK"
On the "Set up historian connection string" screen, set the servername property to the name of your PI server from the PI SDK.
1. For explicit logins, set the values of the username and password properties.
2. To have openPDC create new PI tags for all archived measurements if they don't already exist, set the RunMetadataSync Property to True. Otherwise, set it to false.
Continue with the setup utility. This will make all your measurements archive to PI by default.

Real-time Input Adapter Configuration

In the openPDC manager, go to Adapters > Input Adapters.
Enter a name for the PI input adapter.
For the type of adapter, choose "PI: Reads real-time measurements from a PI server using PI SDK."
Set the ServerName property to the name of the PI server from the PI SDK
If you wish to connect to the PI server using explicit logins, set the UserName and Password properties too.
Add an additional property to the connection string: "ConnectOnDemand=True;"
Next, go to the Manage > Measurements screen.
You will need to manually add measurements that you wish to make available in openPDC. Either the point tag or the alternate tag must match the point's tag in PI. It is recommended to create a separate historian (probably a virtual output historian) to archive all measurements and set the PI adapter's output measurement key to everything on the historian with a FILTER expression.

Updated Wiki: Adapter Synchronization (Developers)

staphen — Wed, 17 Apr 2013 20:06:52 GMT

To address limitations in the wait handle pattern for adapter synchronization, as of version 1.5.192 of the openPDC and to be included in the final release of v1.5 SP1, wait handle synchronization has been replaced by the "Queue and Notify" pattern.

Note: Introduction of the queue and notify pattern has replaced the wait handle pattern, in that the wait handle pattern no longer exists. Any systems using the old pattern will need to migrate their connection strings and adapter code to the queue and notify pattern.

Usage is similar to the wait handle pattern. The following connection string parameters can now be specified on the dependent adapter.

dependencies - Comma separated list of adapter acronyms
dependencyTimeout - Maximum wait time, in seconds, before proceeding

These connection string parameters instruct the openPDC measurement routing system to wait for an adapter's dependencies to finish processing measurements before providing those measurements to the dependent adapter. Those measurements will instead be queued until either the dependency adapters notify the routing system or the timeout expires.

Any adapter which is acting as a dependency will now be expected to call one of the OnNotify() overloads to indicate that it has finished processing its measurements.

    protected override void PublishFrame(IFrame frame, int index)
    {
        // Set flags for flat-line values
        SetStateFlagsForFlatLineValues(frame.Measurements.Values);

        // Release adapters waiting on flat-line state
        OnNotify(frame.Measurements.Values);
    }

Note: If dependency relationships are updated due to a configuration change, it will be necessary to notify the measurement routing system by sending the 'RefreshRoutes' command via the openPDC Console.

Advanced information

Intelligent queuing

The measurement routing system attempts to determine which measurements need to be queued based on the routes that the measurement is taking through the system. For example, in the following diagram, the measurement routing system has received three measurements (m1, m2, and m3) which are to be routed to at least one of two adapters (Dependency Adapter and Dependent Adapter). Dependent Adapter has listed Dependency Adapter among its dependencies in its connection string.

Measurements m1 and m3 are each being sent to only one of the adapters, so they will be provided immediately to Dependency Adapter and Dependent Adapter respectively. However, m2 is being provided to both adapters. In this case, the measurement routing system recognizes that there is a dependency between the two adapters receiving the measurement and will therefore only provide m2 to Dependency Adapter. It will also hold onto m2 until Dependency Adapter has sent a notification to indicate that it has finished processing. When the routing system receives the notification, that is when it sends m2 to Dependent Adapter.

The key point here is that although m3 is being sent to Dependent Adapter, the routing system recognizes that it is not also being sent to Dependency Adapter. The measurement will not be held pending notification.

Signal separation

Measurements are queued by signal for each dependent adapter. This means that a set of queues is created for each dependent adapter, and the number of queues matches the number of signals being received by that dependent adapter and its dependencies. The following diagram shows a system with three dependent adapters and three signals, where each adapter is receiving a different set of signals.

In this scenario, if m1.1 arrives before m2.1, but the dependency adapters finish processing m2.1 before m1.1, then m2.1 can still be dequeued and provided to the adapters without having to wait on m1.1. On the other hand, if a dependency adapter fails to process m1.1 but succeeds in processing m1.2, the routing system must provide these measurements to the dependent adapter in order. The routing system will automatically time out m1.1 so that both measurements can be provided to the dependent adapters immediately.

Multiple dependencies

In the case of multiple dependencies, where A3 depends on both A1 and A2, this situation is handled in much the same way as the first example under intelligent queuing. For each measurement that goes through the measurement routing system, the system determines whether any measurements are going to A1 and A3, A2 and A3, or all three of them. Then, for each measurement added to the queue, it stores two sets: a set of the dependencies which also received the measurement and a set of the adapters that have notified. When the set of dependencies matches the set of notifications, the measurement is provided to A3. This way, notifications can come from A1 and A2 at any time and in either order. The measurement will not be provided to A3 until all of its dependencies which also received the measurement have notified.

New with any adapter in v1.4 SP2 of the openPDC there are now two new connection string parameters:

waitHandleNames - Comma separated list of wait handle names
waitHandleTimeout - Maximum wait time, in milliseconds, before proceeding

These two parameters allow any adapter in the system to temporarily postpone processing until all the named wait handles have fired and/or the wait times-out. Waiting is built-in and automated for action and output adapters simply by specifying the wait handle names. This includes remote data subscribers - the subscription methods include these two items as optional parameters.

The wait handle timeout is an optional parameter. The default value for the wait handle timeout on action adapters is based on the frame rate, for example, if the frame rate is 30 samples per second, the default wait handle timeout will be 33 milliseconds. For non-action adapters, the value will default to 33 milliseconds unless otherwise specified.

The multiple wait handle names allows adapters to wait for multiple events (e.g., measurement validation and chained calculation results).

The only code change that will be needed is to "release" the waiting adapters when your custom event or action has completed, for example, in the following code the external event wait handle named "FlatLineState" gets released once the flat-line set has been completed and the state flags have been assigned:

        protected override void PublishFrame(IFrame frame, int index)
        {
            // Set flags for flat-line values
            SetStateFlagsForFlatLineValues(frame.Measurements.Values);

            // Release adapters waiting on flat-line state
            GetExternalEventHandle("FlatLineState").Set();
        }

For the adapter that needs to wait for the state to be set before processing, you would only need to add "; waitHandleNames=FlatLineState" to your connection string.

That should be it - so now any adapter can "wait" on another for input and/or flags to be assigned before processing the measurements.

Thanks!
Ritchie

Updated Wiki: About the Signal Reference

ritchiecarroll — Fri, 12 Apr 2013 17:55:03 GMT

Signal Reference Notes:

For synchrophasor measurements the signal reference field is critical - it is used to map device elements in a protocol frame (e.g., IEEE C37.118) to and from measurements. The format of this field is very regular:

The text based signal reference field must contain the Acroynm of the associated Device, followed by a dash (‘-‘), followed by the two character SignalType Suffix then optionally followed by an index. Note that the mapping is by order, not by index or name. Thus, it is critical that the indexed measurements be modeled in the order that they are returned from the source device. For example SHELBY-PM4 represents the fourth phasor magnitude for the SHELBY Device and SHELBY-SF represents its status flags.

The information below describes the original specification:

In order to rebroadcast data from the sub-second sources, a field is required to be able to associate each point with its associated "field" in a synchrophasor protocol data frame. This document defines these relations.

This field is normally for internal use only and is stored in a field associated with each defined measurement point:

Type of Point	Abbreviation	Indexed?
Phasor Magnitude i.e., Voltage (Volts) or Current (Amps)	PM	Yes
Phasor Angle i.e., Angle (Degrees)	PA	Yes
Frequency i.e., Frequency (Hz)	FQ	No
dF/dt i.e., Frequency rate of change	DF	No
Digital Value	DV	Yes
Analog Value	AV	Yes
Status Flags	SF	No

Examples below follow the prescribed format of: the PMU/device acronym, a dash and one of the above abbreviations. Also, if the type of point is indexed, adding the associated entry index, for example:

SHELBY-PM1 ß Magnitude associated with Phasor1 entry

SHELBY-PA1 ß Angle associated with Phasor1 entry

SHELBY-PM2 ß Magnitude associated with Phasor2 entry

SHELBY-PA2 ß Angle associated with Phasor2 entry

SHELBY-PM3 ß Magnitude associated with Phasor3 entry

SHELBY-PA3 ß Angle associated with Phasor3 entry

SHELBY-PM4 ß Magnitude associated with Phasor4 entry

SHELBY-PA4 ß Angle associated with Phasor4 entry

SHELBY-PM5 ß Magnitude associated with Phasor5 entry

SHELBY-PA5 ß Angle associated with Phasor5 entry

SHELBY-FQ ß Frequency value associated with Frequency entry

SHELBY-DF ß Rate of frequency change associated with Frequency entry

SHELBY-DV1 ß Digital Value 1

SHELBY-DV2 ß Digital Value 2

SHELBY-SF ß Status Flags

Using this information you can map individual measurements to and from most any synchrophasor protocol data frame.

Updated Wiki: About the Signal Reference

ritchiecarroll — Fri, 12 Apr 2013 17:54:35 GMT

Signal Reference Notes:

The information below describes the original specification:

This field is normally for internal use only and is stored in a field associated with each defined measurement point:

Type of Point	Abbreviation	Indexed?
Phasor Magnitude i.e., Voltage (Volts) or Current (Amps)	PM	Yes
Phasor Angle i.e., Angle (Degrees)	PA	Yes
Frequency i.e., Frequency (Hz)	FQ	No
dF/dt i.e., Frequency rate of change	DF	No
Digital Value	DV	Yes
Analog Value	AV	Yes
Status Flags	SF	No

SHELBY-PM1 ß Magnitude associated with Phasor1 entry

SHELBY-PA1 ß Angle associated with Phasor1 entry

SHELBY-PM2 ß Magnitude associated with Phasor2 entry

SHELBY-PA2 ß Angle associated with Phasor2 entry

SHELBY-PM3 ß Magnitude associated with Phasor3 entry

SHELBY-PA3 ß Angle associated with Phasor3 entry

SHELBY-PM4 ß Magnitude associated with Phasor4 entry

SHELBY-PA4 ß Angle associated with Phasor4 entry

SHELBY-PM5 ß Magnitude associated with Phasor5 entry

SHELBY-PA5 ß Angle associated with Phasor5 entry

SHELBY-FQ ß Frequency value associated with Frequency entry

SHELBY-DF ß Rate of frequency change associated with Frequency entry

SHELBY-DV1 ß Digital Value 1

SHELBY-DV2 ß Digital Value 2

SHELBY-SF ß Status Flags

Using this information you can map individual measurements to and from most any synchrophasor protocol data frame.

Updated Wiki: Adapter Synchronization (Developers)

staphen — Wed, 27 Feb 2013 15:29:17 GMT

Usage is similar to the wait handle pattern. The following connection string parameters can now be specified on the dependent adapter.

dependencies - Comma separated list of adapter acronyms
dependencyTimeout - Maximum wait time, in milliseconds, before proceeding

Any adapter which is acting as a dependency will now be expected to call one of the OnNotify() overloads to indicate that it has finished processing its measurements.

    protected override void PublishFrame(IFrame frame, int index)
    {
        // Set flags for flat-line values
        SetStateFlagsForFlatLineValues(frame.Measurements.Values);

        // Release adapters waiting on flat-line state
        OnNotify(frame.Measurements.Values);
    }

Advanced information

Intelligent queuing

Signal separation

Multiple dependencies

New with any adapter in v1.4 SP2 of the openPDC there are now two new connection string parameters:

waitHandleNames - Comma separated list of wait handle names
waitHandleTimeout - Maximum wait time, in milliseconds, before proceeding

The multiple wait handle names allows adapters to wait for multiple events (e.g., measurement validation and chained calculation results).

For the adapter that needs to wait for the state to be set before processing, you would only need to add "; waitHandleNames=FlatLineState" to your connection string.

That should be it - so now any adapter can "wait" on another for input and/or flags to be assigned before processing the measurements.

Thanks!
Ritchie

Updated Wiki: Adapter Synchronization (Developers)

staphen — Wed, 27 Feb 2013 14:37:08 GMT

Usage is similar to the wait handle pattern. The following connection string parameters can now be specified on the dependent adapter.

dependencies - Comma separated list of adapter acronyms
dependencyTimeout - Maximum wait time, in milliseconds, before proceeding

Any adapter which is acting as a dependency will now be expected to call one of the OnNotify() overloads to indicate that it has finished processing its measurements.

    protected override void PublishFrame(IFrame frame, int index)
    {
        // Set flags for flat-line values
        SetStateFlagsForFlatLineValues(frame.Measurements.Values);

        // Release adapters waiting on flat-line state
        OnNotify(frame.Measurements.ToArray());
    }

Advanced information

Intelligent queuing

Signal separation

Multiple dependencies

New with any adapter in v1.4 SP2 of the openPDC there are now two new connection string parameters:

waitHandleNames - Comma separated list of wait handle names
waitHandleTimeout - Maximum wait time, in milliseconds, before proceeding

The multiple wait handle names allows adapters to wait for multiple events (e.g., measurement validation and chained calculation results).

For the adapter that needs to wait for the state to be set before processing, you would only need to add "; waitHandleNames=FlatLineState" to your connection string.

That should be it - so now any adapter can "wait" on another for input and/or flags to be assigned before processing the measurements.

Thanks!
Ritchie

Updated Wiki: Adapter Synchronization (Developers)

staphen — Wed, 27 Feb 2013 14:36:56 GMT

Usage is similar to the wait handle pattern. The following connection string parameters can now be specified on the dependent adapter.

dependencies - Comma separated list of adapter acronyms
dependencyTimeout - Maximum wait time, in milliseconds, before proceeding

Any adapter which is acting as a dependency will now be expected to call one of the OnNotify() overloads to indicate that it has finished processing its measurements.

    protected override void PublishFrame(IFrame frame, int index)
    {
        // Set flags for flat-line values
        SetStateFlagsForFlatLineValues(frame.Measurements.Values);

        // Release adapters waiting on flat-line state
        OnNotify(frame.Measurements.ToArray());
    }

Advanced information

Intelligent queuing

Signal separation

Multiple dependencies

New with any adapter in v1.4 SP2 of the openPDC there are now two new connection string parameters:

waitHandleNames - Comma separated list of wait handle names
waitHandleTimeout - Maximum wait time, in milliseconds, before proceeding

The multiple wait handle names allows adapters to wait for multiple events (e.g., measurement validation and chained calculation results).

For the adapter that needs to wait for the state to be set before processing, you would only need to add "; waitHandleNames=FlatLineState" to your connection string.

That should be it - so now any adapter can "wait" on another for input and/or flags to be assigned before processing the measurements.

Thanks!
Ritchie

Updated Wiki: Adapter Synchronization (Developers)

staphen — Tue, 26 Feb 2013 21:38:52 GMT

Usage is similar to the wait handle pattern. The following connection string parameters can now be specified on the dependent adapter.

dependencies - Comma separated list of adapter acronyms
dependencyTimeout - Maximum wait time, in milliseconds, before proceeding

Any adapter which is acting as a dependency will now be expected to call one of the OnNotify() overloads to indicate that it has finished processing its measurements.

    protected override void PublishFrame(IFrame frame, int index)
    {
        // Set flags for flat-line values
        SetStateFlagsForFlatLineValues(frame.Measurements.Values);

        // Release adapters waiting on flat-line state
        OnNotify(frame.Measurements.ToArray());
    }

Advanced information

Intelligent queuing

Signal separation

Multiple dependencies

New with any adapter in v1.4 SP2 of the openPDC there are now two new connection string parameters:

waitHandleNames - Comma separated list of wait handle names
waitHandleTimeout - Maximum wait time, in milliseconds, before proceeding

The multiple wait handle names allows adapters to wait for multiple events (e.g., measurement validation and chained calculation results).

For the adapter that needs to wait for the state to be set before processing, you would only need to add "; waitHandleNames=FlatLineState" to your connection string.

That should be it - so now any adapter can "wait" on another for input and/or flags to be assigned before processing the measurements.

Thanks!
Ritchie