DeltaV Zone Servers

Hi, Does anyone have any experience with DeltaV Zone Servers? We have 3 DeltaV Systems connected together via zone servers but we are currently unable to pull process history data or alarms and events data from the zones. The Emersons product data sheets for Zone Servers state you can 'View continuous historian data in other zones' and 'View event data gathered from plant areas in multiple zones' but we are unable to implement this functionality.

3 Replies

  • Any time I see these types of question, I have to first start by recommending you speak with your local Emerson service provider as there are many facets to this type of question, and a forum like this invites many well meaning contributors that collectively can get you into trouble. Having someone own this problem to bring focus will get you to a solution much faster.

    Being one of those well meaning contributors :-), I will add this. Pulling history data from other Zones is done on a separate network than the Zone Network. The Zone Servers provide runtime data connectivity between the Zones, allowing displays and controllers in one zone to read or write to data in modules located in an other zone.

    The PHV client application allows you to specify Continuous History and Event Journal hosts by name. The Continuous History server can even be a PI Enterprise server. To connect to a server in another zone, the Operator Station needs to be able to communicate with the Historian over a separate network that connects it to the server.

    There are two challenges to overcome.

    First, you must configure the Chart using the history tag used in the server, without the Zone prefix. You cannot browse as the PHV client will only browse the local DeltaV system. If you create a chart from the other zone and save it, you can copy that chart to other zones and when these are connected to the right historian, they will show the data. So the work around is to configure charts for data in their host zone, and copy these to the Pro Plus of other zones, and then download them to the operator stations.

    For launching PHV from the Faceplate window in Operate, the Zone% prefix allows the CHART to display the runtime data in the trend, but the CHART does not know where to find the history data for this module, and so you do not get history for module based preconfigured CHARTS. If you were to pass the module name with out the prefix, and point the PHV CHART to the right Historian, you would be able to see the history, but without the zone prefix, the CHART would not be able to update runtime. By refreshing the remote history chart manually, you would have a usable workaround. Or you could provide the operator with a choice to show runtime or history.

    The second challenge, and I don't know how this would be solved, is that the PHV client needs to have Windows security access to the history server. I'm not sure how the connection is done for data retrieval, so if some one can speak to that, it would be appreciated. Since each DeltaV Zone is a separate domain, or a workgroup, users in one domain accessing a server in another domain may have to setup trusts or user accounts. If the Zones were installed in a forest under a parent domain, setting up the trusts would be relatively easy, versus having workgroups and copying user accounts and passwords. Assuming the security aspect of the connection is solved, then in PHV you add the remote zone history servers to the list, allowing Charts to connect.

    So integrating the PHV Charts with DeltaV Operate for remote history servers is doable, but it is not out of the box and there are some compromises to make along the way. Good luck.

    Andre Dicaire

  • In reply to Andre Dicaire:

    Stuart,

    Not much action on this question. We have a customer with a similar requirement so we did some testing.

    Some good news. PHV is aware that a Zone%Module path does not work for the history call and strips the Zone prefix when it makes the history call. So in PHV, you will see the runtime data as the Operator station sees is, and it can retrieve the history data from the remote server.

    The PHV command line interface allows you to set the History node server and the Event server when calling up a chart from Operator. When you call up a faceplate for a module from another zone, the zone name can be used to determine what history server you need to use. You will have to create this information either in a look up table or something. I'm thinking that a set of global variables could be set up, one for each zone history server, and your faceplate PHV button would look up the history server name in order to point the chart appropriately.

    We also found that there is a hotfix required on the Workstations to address an issue with the Server command line switch. I think it is WS09 hotfix in v12. Check with Guardian for that.

    Now for the challenge. From what we have been able to determine, the Operator stations need to have interactive user access on the history servers in order for the history data to be populated. We were not sure if this was being accomplished with the DeltaVAdmin user or the interactive user. We set up two systems in Workgroups and had the same administrator accound and DeltaVAdmin account with matching passwords. Everything workded. We first set it up manually in PHV, then using DOS commands for the command line and finally set this on the Faceplate button via the FRSRunTask.

    THen we changed the DeltaVAdmin password on the workstation using ServPWD. After rebooting the operator station, we were still able to see the history, logged on as the Administrator. So we added a user in one system not in the other. THis user is unable to see the history.

    We are still investigating, but it seems at this point that in order to have history servers share the data to other zones, the Zones should be setup in an Active directory forest so that the history servers trust the users from the other zones. Exaclty how this should be set up will need so additional investigation to determine the minimum security settings for these users.

    There are two options here: Set up a separate domain to which all the DeltaV zones will be child domains. THis allows you to administer global users for all the systems in one place and local users in each domain that belong only in that domian. In each Domain you must add the parent domain groups to the appropriate local groups to grant those users their required access.

    THe other option is to make one of the DeltaV admin domains the parent domain to the other zones. THis works will if the additional zones are indeed subordinate to this master zone. There must be a common network that connects all the zones together, and also the workstations and history servers. This network will use DNS to resolve names, but you can also use IP addresses to set the location of the servers when calling up PHV. The downside to this is PHV shows the IP address for the history server so the operator must know the IP addresses to know what server he is connected to. HOwever, the Zone name is in the tag name so this is not a big deal.

    If you chose to use an Enterperise server for cross zone history access, you would not need to derive the location of the history data, since it would all be in this central server, but you would need to setup security to access the server, and this would require that all the workstations have access to this server, bringing us back to needing a forest with trusts to allow operators to view the history.

    Another option is to use a common windows user for all operator stations and to have this user account as a local user on every history server. By using all local windows accounts, authentication of this user might be sufficient to get the data while the DeltaV users are explicitly logged on using their domain accounts. In this way, DeltaV Privilege is specific to users at the DeltaV level, but windows access is common, but restricted to view access and the DeltaV group.

    I'll try to get more details as we work this through with our customer. If you find anything in this regard, please let us know.

    Andre Dicaire

  • Thank you so much for taking the time to reply. My local Emerson office are quoting to resolve the issue as they have resolved the same issue for another customer, so it will be interesting to compare solutions

    Sent from my iPhone