AVEVA™ PI System™ 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, 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 and comments are visible to all other users.


This page is for feedback specifically for AVEVA PI System. For links to our other feedback portals, please see the tab RESOURCES below.

Add a new idea Subscribe
Status Declined
Product AVEVA™ PI Server
Categories Analytics & Calculations
Created by Guest
Created on Aug 20, 2022

RELATED IDEAS

Relative time in PI AF being DST-Aware

When utilizing the output timestamp relative to trigger time functionality within PI AF 2018, customer has experienced an issue where values written 12 hours before (*-12h) (ideally at 12PM/12AM, thanks to a 12 hour period) the output time will write at an undesired time (11PM or 1AM) during the DST transition. Customer's desired improvement would be that either relative time (d,h,m,s, etc.) be made DST aware, or for there to be an additional setting configurable to allow DST awareness for relative time units.
  • ADMIN RESPONSE
    Aug 20, 2022
    Current capabilities satisfy this request.
  • Attach files
  • Guest
    Reply
    |     Aug 20, 2022
    For additional background, this issue affects whenever we calculate production shift performance (in our case, shifts are 12 hours). We have periodic analyses which trigger at midnight and noon. We want to write the shift performance to the start time of the shift, so we use an output timestamp override of *-12h. At DST changes, our analysis output gets written to 11 pm or 1 am, as opposed to 12 am as would be expected.
  • Guest
    Reply
    |     Aug 20, 2022
    The 'day' offset will always be the same time of the day (which is what you desire) where the 'hour' offset will be the specified number of hours. The problem is you want a fraction of a day which is not supported because the length of a day is not constant. But I think you could use '-1d+12h' to produce your desired result for the 12AM time and '+1d-12h' for the 12PM time.
  • Guest
    Reply
    |     Aug 20, 2022
    Please the BOD() and NOON() builtin functions for this particular use case. Bod('*') will give you beginning of day, which would be 12AM. Similarly Noon('*') will give you noon of the current day. As an example, for 2018, the DST transition was on 3/11/2018 in the US. As such, if you use a 12h offset, the DST will affect the output. However, using Bod('3/11/2018') and Noon('3/11/2018') would return the desired results.
  • Guest
    Reply
    |     Aug 20, 2022
    Hi David and Steve, thank you for your input. The current functionality, as described, works fine for keeping daily outputs at a fixed output time (adjusted for DST). However, if you wish to have an analysis output every shift (commonly every 8 or 12 hours), there is no simple way to accomplish this, other than (a) using two or three separate analyses, with the appropriate Bod or Noon functions, or (b) having a set of analyses that correctly outputs the shift start and end times, adjusted for DST, which you can use as variables in your analyses. Please refer to Tech Support Case #911100 for a demonstration of how the expected behavior David mentions (-1d-12h) does not return noon/midnight on DST changes. Please feel free to contact me to discuss further, since I strongly believe there is a disconnect between the intended behavior and actual behavior.
  • Guest
    Reply
    |     Aug 20, 2022
    Hi, sorry for the delayed response. I want to re-emphasize that the PI System uses UTC as the basis for time. This of course helps us minimize issues related to DST and as a result the relative time expression for the PI System is very specific in that it's referenced to UTC and not "wall clock" time. As an example, if you were to assume "*" equates now, then "*-8h" means starting from now, count 8 hours backwards in time based on UTC and not "wall clock". What you're describing is counting hours (or more generally counting time) based on the "wall clock". (BTW, in the PI System, "*" actually does not mean NOW, but rather it means the snapshot value.)