Recent Control & Safety Systems Discussions
Similar Posts
Write array data to deltav tag
DeltaV on Windows 7 Enterprise
Setting up DeltaV systems as part of an Enterprise domain.
Accessing DeltaV Live shows blank white screen with RDP to Windows 10 Enterprise LTSB PC
Different Approaches for Managing DCSs and Enterprise Systems
Share

Enterprise PI Data to DeltaV Tag

Hi DeltaV Gurus,

We have an Enterprise PI system with a PI-PI link to our DeltaV advanced continuous historian. I would like to send down a hand full of data points from the Enterprise PI down to DeltaV so I can use them in a control scheme. Can anyone describe how this can be configured? I have an idea how you could configure data from the Enterprise PI to the advanced Historian but how to get the data from the Advanced Historian to a DeltaV Tag?

Thanks in advance.

DVUser007
  • Colin Welsh
    1 thing to be wary of; if you send data from your PI historian to the DeltaV, what happens if you lose the PI link?? Will this impact your control scheme?? If someone was to "hack" the link could it potentially cause an issue on your control system?? At my plant we do not allow any PI data to be used in any control scheme, just in case the value gets corrupted and leads to a plant upset/incident. What network control schemes (firewalls, etc) do you have in place between the enterprise server and the DeltaV historian?? We have just been cyber attacked and by luck the control system was not affected but the PI server was declared unusable. Since the attack we have installed 2 pairs of firewalls with a DMZ network layer in between, and very tight firewall rules.

    In terms of PI data back to DeltaV, I have no idea how to link the Deltav historian to a DeltaV tag, but would suggest using an OPC interface to write data direct from the PI server to the DeltaV system (we do this, but purely for display on DeltaV graphics - no control scheme links at all).

    I would also suggest moving from the PI to PI interface to an OPC interface for your data collection in to PI. I know that DeltaV did have a PI server as its historian package at one time, but I think that is no longer the case. We use OPC interfaces for all our "control" systems and its fairly easy to setup and maintain.

    Hope this helps a little.
  • SandraVann
    We have a plant that is writing from an Aspen historian to a DeltaV module. There is a dual firewall DMZ set up. Aspen CIMIO is used to communicate through the first firewall to an interface server on the DMZ. Matrikon software is used to go from the DMZ server through the Emerson firewall to the DeltaV tag.
  • MPHymel
    Imagine the following: PI TagA exists on your business LAN PI server, PI TagA also exists on your control PI LAN server (these are synced by PI Auto Point Sync), PI Tag B exists on your control LAN PI server.


    PI TagB is special, in that its PI Source Tag field will point to PI TagA, and its Instrument Tag field will point to your DeltaV module/parameter.CV.

    At your lowest level PI server, create a PI tag. The PI Instrument Tag field will contain the DCS module and parameter you wish to write to ie "<module_name>/<parameter>.CV ".
    Set your PI location parameters as necessary.
    For this same PI tag, set your PI Source Tag field to the business LAN PI tag you want to get data from.
    Make sure this same tag is set up on both your PI servers and the PI APS utility has been run in the proper direction to establish the tag creation on the appropriate server.
    I suspect that this will require you to sync the business LAN tag from your business LAN PI server to your control LAN PI server in the reverse direction than you would normally use when trying to create a PI tag to historize a DCS tag.
  • Bob McIntyre
    Greetings. Sorry up front for the length of this, but I thought I would lay it all out for you, then you can pick what best fits your environment.

    Here is what I know about PI, DeltaV and bi-directional communications. You mention that you are using the DeltaV Advanced Continuous Historian. This means that it is a branded PI server, as opposed to the Continuous Historian or Legacy Historian which are not PI based. PI-to-PI is a good way to get data from Advanced Continuous Historian to Enterprise PI, but it has the drawback of running the two historians in SERIES. In my configurations, I set up PI-OPC-DA Interfaces on the App Station and run the two in PARALLEL. This way changes on one will not impact changes on the other, and you do not have to double-buy tag licensing just to get a value into Enterprise PI. I have the standard PI firewall exception in place in my firewalls (allow TCP 5450, one way from the interface computer to the PI server) and it works very well and is very secure.

    Aside: For anyone using the Legacy Historian or Continuous Historian (not Adv), your best option to transfer data to Enterprise PI is PI-OPC-DA Interface. Some might mention a "PI-Protocol-Converter" and "PI-to-PI Interface", but trust me: don't do it! I had two of these and switched them to PI-OPC-DA Interfaces. 80% CPU load on App Station and tags regularly not updating properly went to SIX % CPU load and perfect updates when I switched one system over.

    Now back to the bi-directional stuff. There are a few ways to get data from Enterprise PI back into your control system. These are the main ones:
    1. PI-to-PI Interface can be bi-directional, IF you buy the second PI-to-PI license to send data back the other way. When buying PI-to-PI, you buy 1 if you only want to send data one way, you buy 2 if you want to send data both ways. You would have to check with who you bought from to see if you got one-way or two-way. Then you can look at the manuals in each to see how to do it. Of course you need to keep in mind the layers. If you go PI-to-PI back to your Advanced Continuous Historian, you will still then need to also do another write back from Adv Cont Hist to DeltaV. See option 2 for that part.
    2. PI-OPC-DA Interface "can be" bi-directional if you use the right one. When downloading the installer, the latest version comes in two flavors. "Read-Only" does not allow write backs. "Read-Write" can. Older versions of the interface that do not explicitly say so are "Read-Write" by default. If you switched to, or put in a PI-OPC-DA Interface, you could go direct from Enterprise PI to DeltaV in one step.
    3. PI does have an OPC-DA Server and OPC-HDA Server on it as well. I believe you need some additional OSIsoft licensing to use it (I think it is called PSA). Check with your OSIsoft rep to see if you already have this. With this you could then use OPC technology to connect the PI-OPC Server to the DeltaV OPC Server. Matrikon Data Manager or Kepware LinkMaster are two that I have used successfully. The big drawback on this one is the firewall hits you hard here. My rule is NEVER try and do OPC across a firewall. Opens things up way too much. There are technologies like Matrikon Tunneller and the like that can help here, but it is still not very firewall friendly.

    You will also need to look at your interface from DeltaV to Advanced Continuous Historian to see what type it is. If it is really a PI-OPC-DA Interface, then just make sure it is not one of the "Read-Only" ones and away you go. Alternatively if it is one of the newer "PI Connectors", a quick check with your Emerson LBP and OSIsoft Tech Support would tell you the bi-directional capabilities and settings here as well. If you set up PI-OPC-DA in PARALLEL direct to Enterprise PI, you won't need to worry about your Advanced Continuous Historian connection at all.

    The other comments here about cyber security and potential impact on the control system are very valid. You will need to pay close attention to how you use and handle any data coming back from PI into DeltaV.
    The first two options above are covered by the standard PI firewall exception (TCP 5450 one way). The OPC option is NOT.
    For the extra security conscious out there, instead of a firewall, you could put in a data diode interface. There are a couple of these that are PI-Interface friendly and work very well. These guarantee that nothing can ever come back the other way, but then this also prevents any type tag data being sent back to DeltaV.

    If I were picking, I would go for option 2 so you go direct instead of multi-hop. If you pick option 1, you would still need to do option 2 as well. But your actual choice depends more on your particular environment and needs.

    I don't work for any of the companies I mention here. I am an end user like yourself but have been working with all of these technologies for many years.
    Sorry again for the long-winded reply.
    Hope this helps.

    Bob

  • Ravi Medandravu
    The PI OPC DA Interface can let you to allow output tags which you can use to write values from PI into an OPC server. I had used this successfully to allow write a value to DeltaV tag and we do this all the time to take a tag value from one OPC server to write to a tag in DeltaV
    Also to consider that OSIsoft has an OPC DA/HDA Server for PI which is essentially exposes PI as an OPC DA/HDA Server, which you could then use OPC bridges or connectors ( various available to build connecting two tags). You can essentially use OPC Mirror if you are familiar to map the PI tag in OPC server to tag in DeltaV.OPC.1 perhaps this should integrate and solve your use case.
  • Matthew Arthur

    In reply to Bob McIntyre:

    Bob, what do you know about OPC UA in ver 14.3? I would like to replace my PI to PI with OPC UA interface. DeltaV Advanced Continuous Historian to site OSI PI server. Any thoughts?
  • Andre Dicaire

    In reply to Matthew Arthur:

    Matthew, OPC UA addresses the Firewall concerns that OPC DA create. It also provides levels of encryption and eliminates the need for 3rd party products to "tunnel" the OPC DA data through a Firewall.

    In addition to Matricon and Kepware, Emerson has an alliance with IntegrationObjects, who have a full suite of OPC tools, including wrappers to work with OPC DA clients and servers. This allows you to use OPC UA with what is commonly now called OPC Classic. But unlike Coke Classic, no one is going to be wanting them to bring OPC Classic back...

    A small correction. DeltaV's Legacy Historian is also a PI historian. Users who purchased DeltaV before version 7.3 would have installed the PI historian that was part of DeltaV, and when DeltaV released its own Continuous Historian, customers with this PI server were allowed to continue using it. It was supported in the Application station as the Legacy Historian.

    In addition, DeltaV supports the use of an Enterprise PI historian installed on the Application station. The difference between this and the Advanced Historian is in the licensing. The Advanced Historian is licensed as part of the DeltaV system, but is also limited to serving the host DeltaV system. There are some limitations that are part of the license agreement, but not enforced by OSI PI software. One is that you cannot populate the Advanced Historian with data from other sources. You should verify if PI to PI is permitted to bring tags from the Enterprise historian to the Advanced Historian. This may not be supported under the license agreement for Advanced Historian.

    I agree with Bob that using the OPC "Data Access" (or OPC UA) connection gives you flexibility to serve different data to the Enterprise PI server than what you collect in the local Historian. This may be desirable in both what is collected and the sample rate. You can focus the local historian to serve the needs of the control Room operators, while the Enterprise PI server can be configured to pull whatever tags are needed at that level, and at the sample rates desired. If you use the PI OPC DA collector, you do have to license the OPC server for the requisite number of data values. If you use PI to PI to bring up data of interest that is already in the Advanced Historian, you can save on the number of OPC licenses for these tags. Maybe 80% of your history needs are met with PI to PI, and you only need to license 20% via OPC Server. You will have to purchase the PI OPC collector separately.

    Normally, the collector is installed on the DeltaV Application Station, and the PI API calls via TCP 5450 pass securely through the firewall. If the PI server is in the L3 layer, and there is one firewall between it and DeltaV, you can install the collector on the App Station. One advantage of this is that the collector can buffer data if there is a loss of connection between the DeltaV App Station and the Enterprise PI server. But if The PI server is installed at L4, you will need a computer at L3 to connect to L2. The PI Collector can be used at the L3 layer, serving data to L4 PI Server, reading from L2 Application station. In this scenario, if the data is in the Historian, you are protected from data loss in case of network disruption between L2 and L3. If you use OPC DA collector at L3, you are subject to data loss if network connection is lost between L2 and L3.

    Adding an OPC UA wrapper to the PI OPC DA collector would allow the use of OPC UA down to the OPC UA server in v14.3. That would give you secure, firewall friendly connection. I'm not aware that OSI has released an OPC UA collector yet. I would discuss with OSI, and if an OPC UA wrapper is needed, which one they would recommend/support, if they recommend one at all.

    Andre Dicaire

  • Bob McIntyre

    In reply to Matthew Arthur:

    Greetings. The PI to PI interface only goes from OSIsoft PI Server to another OSIsoft PI Server. ACH is a branded PI server. If you want to send data back the other way, then you need another PI to PI Interface to handle the other direction. As for connecting from OPC to any PI Server, there are two flavors: OPC-DA is called a PI INTERFACE. OPC-UA is called a PI CONNECTOR. Connectors are more expensive (2x) the price of Interfaces. When switching from PI to PI to Interface or Connector, you are now decoupling the two historians and going directly to the source. The two historians now run in parallel instead of the series connection of PI to PI. The PI OPC-DA Interface CAN be run bi-directional, or can be read-only. Don't have enough time on the Connector to know how that works yet - they are too new.
    Hope this helps.
    Bob

    Bob

  • DVUser007

    In reply to Bob McIntyre:

    Hi Guru's,

    Thanks for your input to this. I did solve this in the end by using an additional PI-PI interface to write data from the Enterprise PI back to the ACH. Then I configured output tags in the ACH to use the DeltaV OPC interface to write to the DeltaV Modules. This was all working great in V12.3, we recently upgraded to V14.3.1, it would appear the configuration for an output tag in the ACH has changed as that method no longer works. Does anyone have any experience or have an example of how to configure an output tag in ACH?

    Thanks!

This is the official online community site of the Emerson Global Users Exchange, a forum for the free exchange of non-proprietary information among the global user community of all Emerson Automation Solution's products and services. Our goal is to improve the efficiency and use of automation systems and solutions employed at members’ facilities by sharing our knowledge, experiences, and application information.

User Groups | World Areas | Community Guidelines | Legal Information | Privacy Policy | Contact Community Manager

Website translation provided by Website Translator

© 2015-2022 Emerson Global Users Exchange. All rights reserved.