Skip to Main Content
AVEVA™ Products Feedback Portal

Welcome to our new feedback site!


We created this site to hear your enhancement ideas, suggestions and feedback about AVEVA products and services. All of the feedback you share here is monitored and reviewed by the AVEVA product managers.

To start, select the product of your interest in the left column. Then take a look at the ideas in the list below and VOTE for your favorite ideas submitted by other users. POST your own idea if it hasn’t been suggested yet. Include COMMENTS and share relevant business case details that will help our product team get more information on the suggestion. Please note that your ideas will first be moderated before they are made visible to other users of this portal.

This page is for feedback for specific AVEVA solutions, excluding PI Systems and Data Hub. For links to these other feedback portals, please see the tab RESOURCES below.

Status Unlikely to implement
Portfolio area Plant SCADA
Products Alarms
Created by Guest
Created on Jul 2, 2020

Create new Trend Type that hooks into Variable Tag Subscriptions

Traditional periodic Trend type makes the end user set a very small sample time such that no sample is missed. This is a complete mis-match between what is happening at the tag level.

I propose a new Trend type that hooks into the Tag Subscription. It would be a "event" trend but wouldn't require the end I/O Device to be DRI enabled. E.g. it could just be basic Modbus driver. The Trend tag would only recieve a sample when the value changes on the Variable tag.

Idea business value

Better performance from the Trend System.

Easier configuration.

No loss of data from Variable tag to Trend Tag.

The possibility for more compression of historic data (if tag value changes slowly).

Idea priority 4 – Important to my company
  • Attach files
  • John Worley
    Reply
    |
    Nov 13, 2024

    sorry missed the abbreviation DRI??
    Modnet, BACnet = DRI?

  • Admin
    Nathan Slider
    Reply
    |
    Aug 19, 2024

    It is easier to change the Driver to become a DRI based driver versus a new alarm type. The purpose of DRI based drivers are to take advantage to the Time-Based events (Alarms & Trends (Event Trends) as it uses the timestamp from the field and injects this upon value change into the underlying subsystem. All DRI based drivers support this today. The request should be for a specific driver to become DRI based and then this occurs as designed.

  • John Worley
    Reply
    |
    Aug 17, 2024

    COV Trend. Asked for this YEARS ago.

    PLEASE PLEASE PLEASE add this.

  • +1