Can any one please advise on connectivity from Kelton FM2P system to PI Data archive server, we need to read and write the data from PI to FM2P and FM2P to PI.
According to their documentation, it uses a MSSQL backend. You could use the PI Interface for RDBMS (via ODBC) to both read and write to the MSSQL database.
I would suggest getting in touch with them to see their recommended approach on exporting data out. Generally querying the backend database is not the best approach as it can change during upgrades and can be a potential security risk.
Thanks , Gabriel.
Is their any POC conducted by OSIsoft on this .
Actually, looking at old communications we have had with them, they recommend using OPC to read from PI to FM2P.
That means, that you would need:
I am not sure if they also expose their data as OPC, but if so, you could forego using RDBMS interface and instead use:
in our interaction with Kelton they are also proposing the same thing of PI OPC, which they made successful connections to PI earlier too, but still the connectivity is not yet finalized.
Also we are proposing for an PI OLEDB connectivity to get the data from PI to their SQL server and to receive the data from SQL Server to PI.
By avoiding to connectives in PI RDBMS.
Any other suggestion on this.
PI Interface for OPC DA also support outputs from the PI Data Archive and hence may serve you for the read and for the write operations.
Hi Gabriel Michaud-Verreault Gregor Beck,
Thanks for your help and insight on this. Let me ask this with more detail on this with few more background of this request - We have our PI system connectivity with Offshore DCS system and getting values for process parameters inside PI (Temp, Press, Flow etc.). Now Kelton wants to read these process parameters and also wanted to write back again cleansed values into another PI tags. In that condition we will have 2 OPC servers (PI side and Kelton side). On this situation we have below queries -
1. Is it still possible to have single instance OPC DA Read/Write interface for reading and writing from PI ?
2. If above statement is true in that condition for DCS tags which we already have Instrument tag in attribute will remain same OPC ID for Kelton to browse ?
3. This connection will go via Firewall only so is there any recommendation on tunneller or DCOM setup ?
4. In this condition which one is better option RDBMS/OLEBD or OPC ?
Thanks in advance for your help.
lalit Pokharana wrote: Now Kelton wants to read these process parameters and also wanted to write back again cleansed values into another PI tags. In that condition we will have 2 OPC servers (PI side and Kelton side).
lalit Pokharana wrote:
Now Kelton wants to read these process parameters and also wanted to write back again cleansed values into another PI tags. In that condition we will have 2 OPC servers (PI side and Kelton side).
This statement changes the picture of what we've been discussing so far. Previously you were asking for connectivity (OPC read/write) against Kelton FM2P. Now you ask for (OPC read/write) connectivity from Kelton to the PI System. This changes my recommendation from using PI Interface for OPC DA to using PI OPC DA Server.
1. Yes. OPC connectivity from a 3rd party system to the PI System is independent from interfacing a 3rd party system using the PI Interface for OPC DA.
2. Again, both can be used independently. Unless you change configuration, you don't need to change configuration. This sounds confusing but means installing an additional optional piece must not break an existing PI Interface connection unless you apply changes which break the established connection e.g. changes to DCOM security.
3. I admit that configuring DCOM can be challenging due to the many options Microsoft has built into the standard. Using a tunneller usually is easy but likely not the best choice from the security perspective. Firewall and DCOM are to secure communication. Tunnellers are just installed and function but who knows what security mechanisms are bypassed? Tunneller vendors may document how their product tunnels DCOM but you cannot avoid dealing with the security aspect to be able to assess security. I definitely favor proper DCOM configuration.
4. I thought PI Interface for RDBMS and PI OLEDB Provider had already been ruled out, also because Kelton recommends OPC connectivity. With your change in scope, quoted above, RDBMSPI Interface is ruled out. PI OLEDB Provider might still be an option but will likely require developing a piece of software which connects against FM2P and to the PI Data Archive through PI OLEDB Provider. I don't know what's needed on the Kelton side to read from and write to an OPC DA Server but to my understanding the decision between PI OPC DA Server and PI OLEDB Provider (I consider those the remaining options based on what's said so far) depends on what you consider being more effort or which technology the individual(s) who do the work feel more familiar with.
Retrieving data ...