Tag descriptions to Historian

Tag descriptions are sent to the Historian during object startup (before going on scan?). Many of our customers end up with tag descriptions that are built dynamically as a combination of the object description + attribute description. These descriptions never make it to the Historian.

One workaround would be to use "Preserve Runtime Changes" and redeploy the object. This way the object will have it's dynamic description when it starts up, and this is transmitted to the Historian. This will lead to additional reconfigurations on the Historian and needless entries in the TagHistory table, so I don't think it is a good solution.

Are there any solutions or plans for this functionality? I am almost certain I have read about this somewhere, but I can't remember when or where...

Suggestion: System Platform always sends updates to the Historian when certain attributes are updated (TrendHigh, TrendLow, Description, EngUnits)

Example:

Object A is a pump with three attributes, temperature, vibration and current that are historized. Object A has the description "Feedwater pump A". We build the descriptions dynamically when the object goes on scan:

Temperature.Description = me.ShortDesc + ", Temperature";

Vibration.Description = me.ShortDesc + ", Vibration";

Current.Description = me.ShortDesc + ", Current";

Parents
  • I had to do some more tests.

    Setting the description in a startup script will actually work for this problem. OnScan and Execute scripts will not get the description field ready in time before it is sent to the Historian, but Startup script works.

    Shouldn't be a big issue either, it is a local string operaton on the object. Nothing that could cause issues.

  • Hi! please be aware of that in older versions, (pre 2023) all changes to tags (such as the description) are stored in the TagHistory table in the Runtime database as you noted.

    If this is updated on a regular basis it could impact performance.

    For this reason the description field was removed from this TagHistory mechanism in the latest version, other settings still create a new versions of the tag.

    Just mentioning this if others start exploring the possibility to add dynamic data to the Attribute History primitives.

    This will require you to consolidate the TagHistory table at some point to ensure retrieval performance.

    In my cases all these modifications are in execute scripts, and seems to work.

  • Can you please list all settings that will update the taghistory table ? I suppose with 2023, if we have a large amount of tag versions in this table we can still have issues or Aveva worked on this as well ?

  • This was discussed in another forum topic, If you do have this issue I would advise you to consult with techsupport so you get correct (and updated) information depending on the version you are using.

    Also, be aware of that the tags in the TagHistory table are there for a reason and manually removing data here can result in loss of data.

    As mentioned there is a tool to consolidate the data, this requires Historian to be stopped during the consolidation. 


    If you today have to many rows of data you would experience performance issues retrieving data.

    But a couple of thousands of rows here should not be an issue, in the scenario where I was involved and we have performance issues, we had 600k rows... = bad time..

    I do not believe that the new versions of System Platform triggers the consolidation, the different tag versions are there for a reason, so this is something that has to be done manually, if needed.

    What I was informed was that 2023 stopped creating new versions based on the comment attribute, since this was a parameter that normally change over time and does not really adds any value to the 'version history'

     RE: Corrupt Tag in Historian. 

  • Hi Richard,


    Thank you for your answer. I was aware of the query which will clear the tagversions but apparently there is a utility for that. I'm gonna ask our local distributor.

    I know it has been an issue since years and that would be great if something can change or run in the background and allow SI to change metadatas dynamycally as we have ofen case were the process needs it. 

    Regards,

  • The important thing to know is that the Utility will modify the TagId in the existing History blocks, to ensure data availability after consolidation.

    If you remove a TagID from the table manually using a query, then you will loose that that corresponding datablock.

    (Example of Datablock content, TagID is used to provide data to Retrieval service)

    Also you need to have all datablocks in Historian when performing this cosolidation, so if you have backup data (let say data older than xy years) it has to be moved to historian before running the tool.

    Otherwise the tool will not be able to update TagID and the data will not be available if you move it 'back'

    Example of query to find Occurences in TagHistory.

    select count(*) as TotalCount from taghistory
    select TagName, COUNT(*) as OccurenceCount from TagHistory
    GROUP BY Tagname having COUNT(*) > 1
    order by COUNT(*) desc

Reply
  • The important thing to know is that the Utility will modify the TagId in the existing History blocks, to ensure data availability after consolidation.

    If you remove a TagID from the table manually using a query, then you will loose that that corresponding datablock.

    (Example of Datablock content, TagID is used to provide data to Retrieval service)

    Also you need to have all datablocks in Historian when performing this cosolidation, so if you have backup data (let say data older than xy years) it has to be moved to historian before running the tool.

    Otherwise the tool will not be able to update TagID and the data will not be available if you move it 'back'

    Example of query to find Occurences in TagHistory.

    select count(*) as TotalCount from taghistory
    select TagName, COUNT(*) as OccurenceCount from TagHistory
    GROUP BY Tagname having COUNT(*) > 1
    order by COUNT(*) desc

Children
No Data