Skip to content
  • There are no suggestions because the search field is empty.

Historians: Read Asset Metadata

This article provides starter solutions for obtaining asset metadata from supported historians.

What this article covers

Many Intelligence Hub data pipelines focus on high‑frequency value changes for large numbers of points/tags, written to a narrow table for throughput and low latency. Those pipelines typically do not process metadata. A complementary metadata pipeline can provide downstream systems with asset information such as asset name, description, hierarchy path, and more. This article outlines starter patterns for that purpose, with notes for specific historians.

 

Intelligence Hub design considerations for obtaining tag metadata  

These considerations pertain to obtaining tag metadata.

  • Define scope: Identify the assets that are in scope for the given solution.
  • Plan how you will query: Decide how assets (and their attributes/tags) will be queried (e.g., naming conventions, templates, filters).
  • Start small, measure, then scale: Begin by querying for metadata for 10s or 100s of assets and scale from there to determine query duration.  
    • Optimally, the duration of the query should be approximately a few seconds.
  • Scale resources/queries as needed: Determine if resources need to be scaled because it might not be possible to obtain all desired points or tags with one query.
  • Assess connection impact: Understand how the new Connection Input impacts other Inputs sharing the same Connection.
  • Account for change cadence: Determine how often asset metadata changes and configure an appropriate Cache Interval so updates are reflected efficiently.
  • Choose a pattern: Run on a schedule, poll at a frequence, or invoke the pipelike externally.  Asset metadata typically changes infrequently, so processing can be less frequent than value stream.
  • Changes to asset metadata: This may update existing records in the destination system rather than creating new records.
  • Select outputs: Write the payload to a MQTT broker, database, data lake, or data warehouse, or make available by the Intelligence Hub REST Data Server.
  • Model the shape: This solution type is conducive to a wide table format with columns per metadata value. 
    • Use an Intelligence Hub Model to define column names and data types. 

 

AVEVA PI System Asset Framework (AF) : asset metadata 

These considerations pertain to obtaining metadata for assets and attributes from PI System Asset Framework.

  • Assume that the metadata and the values will be linked via an identifier.  
    • In the starter solution, the unique keys are the attribute ID and asset ID.
  • It is typically best to use the Intelligence Hub PI Connection Asset Metadata Input that returns attribute configuration per asset.  
  • The Asset Metadata Connection Input queries the PI Asset Framework's database and can be a long-duration query if there are many assets returned by the query.  It may be necessary to index through an asset list to avoid long-duration queries.
  • The starter solution obtained asset attribute metadata from the PI System Asset Framework.  The attribute metadata includes the static value for asset attributes that are not associated with PI Points.  In the starter solution, the values are written to the table for attribute metadata.  
    • Alternatively, these values could be written to a different table with a wide or narrow format.
  • A project file may be downloaded [here].

 


 

Summary

Use these considerations to implement asset‑metadata pipelines alongside value‑change pipelines in Intelligence Hub. Align scope, query strategy, cadence, modeling, and destination behavior with downstream requirements.

 

Additional Resources