DeltaV Live introduced Faceplate Trends, where an Operator is presented with added insight to a control loop without having to open a PHV Trend.  The Module GEMs also have a Drag Interaction for creating Watchlist trends, These items call for the configuration of the HIstory server, which is by default defined using the S_HistoryServerPreference Standard.  Simply by defining this Standard to contain the name of the History server, the trends all connect and show you history.

But what happens if you have two History servers with one part of the plant collecting data for a number of Plant Areas, and the rest of the Plant areas assigned to another Historian.  The OOB Faceplates and GEMs only allow for one history server to be defined.  Without doing something, half the tags will not show any history on faceplates and Drag to Watchlist.  

Another aspect of this is that we don't know at runtime which historian a module is being collected on.  

So the first part of this problem is how do we determine which historian a module is collecting data.  DeltaV Live was supposed to have a mechanism to automatically find where a tag is historized.  However that does not appear to be the case.  I've tried leaving the HIstory server property blank in a trend, which seems to let the trend look at the local node.  At least that is what I observed since running Live on the Pro Plus where a historian was configured resulted in history but all the workstations showed no history.  I had to define a History server to get history on the workstation faceplates.

IF this was Operate, I could look up the Plant Area of the module in the MODT.SCR file and find which Historian has this area assigned to it in PHSL.SCR, But need to resolve the Area index first from ANT.SCR.  A shortcut to this would be to populate an array in Live on startup that identifies the Historian to use for each area, then you only have to find the Module's area to know the Historian to use.  HOwever, in Live we don't have access to read the SCR files.  One solution would be to put the SCR files into a SQL database so these types of searches can be done via SQL queries.  Having knowledge of the runtime database available to Live could open alternative ways to do what we used to do in Operate reading the .SCR files directly.  Hmmm.

The brute method would be to add a string parameter in every module where you call out the History server to use with this module.  That would require a download to every module, which is rather intrusive and might not be feasible for many plants, even when upgrading.  

I'm thinking a SQL database and including the tag data of each historian, so the faceplate could search for the module name and return a history server name.  It doesn't matter if there are multiple locations as the history data will be the same.  

Now that we have a History server name, how do I get a trend to look at it?  Well the Trends are hard coded to a server.  My solution here is to configure two or more Trend objects in the faceplate, each one pointing to a different historian, and visibility set based on the module's historian from the look up.  This allows you to develop one Faceplate for all the PID loops, and show data from the correct historian of any PID loop in the system.  Maybe the SQL table uses the Area of the module to find the historian the Area is assigned to.  Point is, once I know the history server to use, I can show the trend with history.

What about the Drag Interaction?  I think here we have to do the same thing by configuring multiple Drag Interactions and setting the Active property to evaluate the modules Historian.  Only that Interaction will be active and the Watchlist trend will be pointed to that historian as defined in the interaction.  

In my system, I created a Trend Pop up that is called from a Faceplate to show history and Events, similar to a PHV combo E_CHART.  I would have to add a second and third CHART preconfigured to different historians and show only the one the module has been assigned to.  

Show should this work?  Personally, I think the History server property on trends and in the Drag interaction should support an animation.  This would allow a chart or a pen to be targeted to the appropriate historian at runtime.  This would avoid needing to create parallel objects with a visibility animation.   The Embedded Trend allows each pen to come from any server, which is good and bad.  In the case of a faceplate or Module chart, all values come from the same server.  If left blank on the individual pen, the pen should use a Chart level history server.  These parameters should support animation to support a library function or a variable reference that can be manipulated online.  Or some way to programmatically set the history property in the On Open script and such.  

The second requirement is to allow Live to read the History server of a Module.  DLSYS["MYMODULE" + "/History"].  While we are at it, how about DLSYS{"MyModule" + "/Area"] to retrieve the area of the module. That would negate the need for that SQL Database. 

Another approach might be to set a history server parameter per workstation, with the pretext that each workstation will be assigned to the same areas as the Historian serving those plant areas.  That would work if the DeltaV system has been deployed with dedicated control rooms and workstations for areas of the plant.  But the Pro Plus and other system wide stations would have issues.  I don't think this has the coverage needed.

Or this capability already exists, and I can't find it in the documentation.  That's been known to happen.  Does the S_HistoryServerPreference standard support a delimited list of history servers that enables Live to look in each server for the tag in the pen? 

Anyway, this problem existed before Live, but it is a bit more of an issue since Live places trends in the faceplates and has the Watchlist drag interaction that put this problem out in the open.  I suppose one could delete the history from the faceplate and not use Watch lists.  I'm thinking a DeltaV enhancement is required but before I submit one, I thought I'd ask what the community thinks and what direction an enhancement request should go in.

Andre Dicaire