Historians: Read Time Span Values

What Does This Article Cover?

General Intelligence Hub design considerations for obtaining values for a time span 

• The overall data pipeline solution might involve polling at a frequency or calling a pipeline externally.
• The resulting data payload might be written to an MQTT broker, database, data lake, data warehouse, or made available by the Intelligence Hub REST Data Server.
• When creating a solution, start with a small number of points or tags and a short time span.  Avoid long queries.  Attempt to use a query that executes in a few seconds.
• The time span might be a relative time span or a dynamic time span with datetimes from an external source or perhaps calculated in an Intelligence Hub Pipeline.  
  • Consider logic to avoid long time spans being sent to the Connection Input.
• It might not be possible to return all data for the desired time span in one query execution.
• Consider aggregations that might be performed on the data and intervals for sampling the data rather than queries to obtain all value changes.
• Consider the datetime format used by the historian and conversions that might need to be applied.
• Avoid Pipeline Debug mode and Enabling Tracking Activity if the Intelligence Hub Pipeline is processing more than dozens of value changes.  
• Obtaining late-arriving data is beyond the scope of this article.

AVEVA PI System Data Archive design considerations for obtaining values for a time span 

These considerations pertain to obtaining value changes for a time span from the PI Data Archive. 

• This solution type is conducive to a narrow table format with value columns (perhaps numeric and non-numeric) and no or minimal additional context.
• PI Point context, including the PI data type, might be obtained infrequently and stored in a different table in the destination system.
• In this scenario, times are relative to the time that the respective value was written to the historian.
• The Intelligence Hub AVEVA PI System Connection Point Type Input is typically used to obtain data for a time span.  A Reference list of PI Points may be used, or specific named PI Points.
• Consider the selection for Get and whether Raw Values will be obtained, or an aggregation will be applied.
• The Index option may be used if the value changes for the time span cannot be returned efficiently by one query execution.  
  • Intelligence Hub will index through the overall time span for an explicitly defined start and end time.
• Consider normalizing data types in a narrow table and the respective logic.  It might be practical to have a column for numeric values and a separate column for non-numeric values.
• The starter solution calculates a rolling time span in a Pipeline Transform Stage.  The end time is stored as a state variable and is used for the next start time.  The end time is saved in the last stage of the Pipeline.  Logic is included and correlated with the Pipeline’s polling rate to prevent a large time span from being sent to the Connection input.
• A project file may be downloaded [here].

AVEVA PI System Asset Framework design considerations for obtaining values for a time span 

These considerations pertain to obtaining value changes for a time span for PI Asset Framework Attributes. 

• This solution type is conducive to a wide table format with a column for each attribute.
• The Intelligence Hub AVEVA PI System Connection Asset Type Input is typically used to obtain data for a time span.
• Consider the selection for Get and whether Raw Values will be obtained, or an aggregation will be applied.  In either case, an interval must be specified.
• The starter solution computes a rolling time span within a Pipeline Transform Stage. The end time is maintained as a state variable and serves as the next start time in each cycle. This end time is updated in the final stage of the Pipeline, and the logic is aligned with the Pipeline’s polling rate to prevent excessive time spans from being sent to the Connection input.
• The _path attribute returned by the Intelligence Hub Input can be converted to an MQTT slash “/” topic path.
• A project file may be downloaded [here].

Canary Historian design considerations for obtaining values for a time span

• This solution type is conducive to a narrow table format with value columns (perhaps numeric and non-numeric) and no or minimal additional context.
• Tag context, including the data type, might be obtained infrequently and stored in a different table in the destination system.
• In this scenario, times are relative to the time that the respective value was written to the historian.
• The Canary Views Service API's getTagData method can be used to obtain data for a time span.  A list of tags can be provided, or search criteria can be used.
• Consider whether an aggregation will be applied to the values.
• Consider normalizing data types in a narrow table and the respective logic.  It might be practical to have a column for numeric values and a separate column for non-numeric values.
• The Canary date format will require date conversions.
• The starter solution calculates a rolling time span in a Pipeline Transform Stage.  The end time is stored as a state variable and is used for the next start time.  The end time is saved in the last stage of the Pipeline.  Logic is included and correlated with the Pipeline’s polling rate to prevent a large time span from being sent to the Connection input.
• A project file may be downloaded [here].

Aspen InfoPlus.21 design considerations for obtaining values for a time span

These considerations pertain to obtaining value changes for a time span from IP.21. 

• This solution type is conducive to a narrow table format with value columns (perhaps numeric and non-numeric) and no or minimal additional context.
• Tag context, including the IP.21 data type might be obtained infrequently and stored in a different table in the destination system.
• In this scenario, times are relative to the time that the respective value was written to the historian.
• Consider whether an aggregation will be applied to the values.  
• Consider normalizing data types in a narrow table and the respective logic.  It might be practical to have a column for numeric values and a separate column for non-numeric values.  
• The IP.21 date format will require date conversions.
• The starter solution determines a rolling time span within a Pipeline Transform Stage, storing the end time as a state variable for use as the next cycle’s start time.
  • This end time is updated in the final stage of the Pipeline, with logic designed to align with the Pipeline’s polling rate and prevent excessive time spans from reaching the Connection input.
• A project file may be downloaded [here].

Additional Resources

• AVEVA PI System query syntax 
• Canary Views Service API