How can we improve PI Connectors?

PI Connector for RDBMS

The PI Interface for RDBMS is one of the most used PI Interfaces. Unfortunately, the fact that it is a PI Interface makes it unnecessarily difficult to use, and turning it into a PI Connector can help alleviate this. No more Location codes, squishy PI ICU, distributor tags, SQL file in the InstrumentTag, strange notations in the ExDesc, etc.

51 votes
Sign in Sign in with OSIsoft
Signed in as (Sign out)

We’ll send you updates on this idea

Kenneth Barber shared this idea  ·   ·  Flag idea as inappropriate…  ·  Admin →

From this item description it looks like the major pain point with existing RDBMS interface is providing configuration information (to the tags and interface). I would like to understand more if the request behind the connector is to solely minimize providing configuration information to the existing interface and tags?


Sign in Sign in with OSIsoft
Signed in as (Sign out)
  • Kenneth Barber commented  ·   ·  Flag as inappropriate

    In response to Abbas, the request is not solely for the purpose of minimizing the entry of configuration information. OSIsoft is moving away from PI Interfaces and towards PI Connectors, so it would make sense to make a PI Connector based on one of the most used PI Interfaces. As I demonstrated in my original post, this is also OSIsoft's chance to redesign and improve how RDBMS data gets into PI.

    A PI Connector for RDBMS would give us the usual benefits of PI Connectors: remote configuration, configuration in a resizable window, self-buffering, higher performance, and increased security.

    A PI Connector for RDBMS would also help quicken the deaths of the PI Buffer Subsystem, PI ICU, and the PI Module Database, which is still used to store the PI ICU information of PI Interfaces. Those are 3 less things for PI administrators to worry about.

  • kdarl commented  ·   ·  Flag as inappropriate

    Our biggest issue with the current RDBMStoPI interface is, you hit a limit of 10,000 tags per interface, and we have a need to bring much more data across the interface than that.

  • lafound commented  ·   ·  Flag as inappropriate

    I agree with this strategy as well. It would alleviate the need to reprocess a concatenated string to make use of the data.

  • gusg21 commented  ·   ·  Flag as inappropriate

    We use EMDVB for deltav and have the exact problem you see. The way we did it was to pull data out of different column into different tags so in effect we are parsing through the interface and then the attributes tied to these tags can be used in the EF generated by our analytic. You can also use analytics to parse but this can be expensive from a performance perspective. I agree a connector would be better.

  • Nate Anderson commented  ·   ·  Flag as inappropriate

    Many of our pharma customrs use the RDBMS interface to bring in alarms and events into the PI system, but with the RDBMS interface the workflow is clunky since there's no AF or EF capability in the interface... first the data must come into a tag then it must be transformed into an event frame to give the alarm the actual information needed. a connector could supply all of the required capability to greatly reduce the complexity of this workflow.

Feedback and Knowledge Base

Posted ideas will have one of the following statuses.
Full definition of these statuses can be found on the Home Page.
No status