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.

Collect doesn't collect current real-time value at top of hour

Customer Requirement

Our customers require the ability to maintain complete Timeseries historical trends (collect samples), including timestamped samples polled after a PLC communication loss (outage could be for several hours/days). The customer is using DNP PLCs which can store up to 100,000 timestamped events. If communications to the PLC are lost, the PLC continues to buffer the change events (timestamped value changes). We need to be able to collect all the buffered events when communications are restored to the PLC, and view in a Timeseries trend.

Problem Descriptions

Some of our customers have unreliable communication paths to the PLCs in field. The communication paths can be over the customer WAN, master radios, terminal servers, direct ethernet, or some combination. As a result, they like to use PLCs that can buffer events while communications are out to the main SCADA system.

Problem #1: It is not possible to collect samples older than the latest sample in collect table, and the system automatically inserts a Top of Hour sample regardless of the remote's state.

Problem #2: Collectxfer does not keep up, RealTime collect buffer overflows

Work in
OASYS-655 Collect doesn't collect current real-time value at top of hour
Work status
  • Attach files
      Drop here to upload
    • Admin
      Jake Hawkes
      Jan 6, 2023

      With regards to the second problem, "Collectxfer does not keep up, RealTime collect buffer overflows", can you provide some numbers around the throughput of historical data? Like, number of points on collect, and their breakdown from sample to exception, or even better, the number of collectxfr records/min that causes the buffer to overflow. Also would help to know some details on the hardware used.

    • Admin
      Jake Hawkes
      Feb 14, 2022

      For problem #1, confirming that the existing baseline method for configuring Field Device Trend History is not sufficient. This would require that all trend history always come directly from the field, and cannot support some data also coming from collect. Bear in mind that enhancements to collect are coming such that a point's entire meta-state will be historised with every row. This includes multiple DQ flags and other state information (i.e. test-mode, etc)


      From the Doc: Realtime Admin Vol 2 -> Additional Protocol Functionality -> Field Device Trend History

      Field Device Trend History

      When Historical point data is stored in a Remote Terminal Unit (RTU) data logger, this application enables you to configure the system such that it sends the data to the Historical database.

      When analog collect records are configured with the collect type "device based history", Omnicomm sends the Historical data collected from the RTU to a spooler, which in turn calls a stored procedure in the Historical database that adds data to the TimeSeries database. This provides Controllers with immediate access to the data for the purposes of trending. The flow of data is illustrated below.


      Configuring the Host to send Device-based History directly to Historical Collect

      Follow this procedure when Historical point data is stored in a Remote Terminal Unit (RTU) data logger and sent to the AVEVA Enterprise SCADA host, as opposed to collected on the AVEVA Enterprise SCADA host.

    1 MERGED

    Support for TimeSeries Historical Uploads

    The current versions of OASyS / Enterprise SCADA have some inherent issues with Historical uploads that populate TimeSeries. These issues and some of our group’s past workarounds are described in the attached file HistoricalUploadDescriptionV3.pdf...
    Guest over 3 years ago in Enterprise SCADA Server / Historical 3 Waiting for information