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.

Add a new idea Subscribe
Status Shipped
Portfolio area Enterprise SCADA Server
Products Krunch and Data Manipulation Realtime API/SDK Telemetry
Created by Guest
Created on Feb 5, 2022

RELATED IDEAS

VDB Override Future?

Our projects make use of the VDB Override feature quite a bit in our project apps, especially now that we no longer have access to the baseline source code to modify. I'm told that the VDB Override feature will be deprecated, possibly in 2022, and I'm wondering if we could get more information about that? Is it no longer supported at all in 2022? Or will it be in 2023?

Work in
OASYS-E-10 Krunch Pipeline
Work status
Release
Enterprise SCADA 2023
Release date
Jan 31, 2023
  • Attach files
  • Admin
    Jake Hawkes
    Reply
    |     Feb 5, 2022

    The VDB layer will remain in the product for the foreseeable future, as it is still how the realtime database essentially works at the lower levels.

    The problem is that some kinds of VDB overrides require access to source.

    I've attached a PPT to the related idea OASYS-I-33 ("Request for a new telemetered point type/table"), which described the different scenarios of a VDB override. But I will try to summarise:

    • augment - this is where the custom functionality can occur entirely before or after the main baseline krunch routine (e.g. genana()). This doesn't require source, as the integrator can wrap the baseline module with their own, and call the baseline module either before or after their custom code

    • replace - this is where the custom functionality is required in the middle of the baseline module, or needs to replace certain aspects of the baseline module. This scenario requires source, as the integrator must replace the entire baseline module with their own, and re-implement those parts of the baseline module than they do not want to replace.

    I'm not sure what the current rules are for our SI partners, and so I think the next step is for your upline to bring this up with the SI manager so that we can decide on how to handle your needs in the timelines that you are working in.