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

Concentrator Output Streams

Oct 5, 2010 at 4:21 PM

Good day, My name is Samuel Sanchez and I work at the Colombian ISO with Ramon Leon’s group implementing the WAMS system using OpenPDC.

We are using OpenPDC for supplying PMU data for the Osisoft PI system. For that, we use the output stream functionality. However, we found that the OpenPDC automatically assigns the ID for each output PMU. We need that the PMU IDs be maintained the same at the input and the output levels in order to manage the appropriate measurement historic information in all our systems.

 Is there a way to change the ID for the PMUs at the output adapter?


Oct 5, 2010 at 8:06 PM

We have added a task for this:

Ideally it would better to create a direct output adapter for OSI PI using standard PI API's - this would be the most efficient way to send data to the historan instead of proxying data through IEEE C37.118. Pushing data through an output stream means slow devices can be left out of the data stream when the lag time is low (by design) - this means slow data may not make into the historian. By having a direct openPDC Output Adapter that sends data directly to OSI PI all data would get into the historian regardless of latency *and* would directly tie Measurements defined in the openPDC to those defined in OSI PI - these points could then be linked by more direct means (i.e., tags / ID's).

I cannot open source a direct link into OSI PI - as a customer, you can using the OSI PI SDK - writing an output adapter is a pretty trival task and you can use one of the existing adapters as a template (see the CSV or MySQL output adapters in the source code for examples).

I have discussed with OSIsoft the possiblity of creating a direct link into OSI-PI from the openPDC so they aware of how to accomplish this.

In the meantime the task I referenced will allow customized device output ID's - you can "vote it up" to help make sure it gets more priority and thefrore resolved quicker.


Oct 6, 2010 at 3:14 PM

Thanks Ritchie!