Accumulator points that reset at the start of the Month / Year

[BevanWeiss]

Hi all,

I'm surprised that I've only encountered this problem recently in my ClearSCADA / GeoSCADA life... but I'm trying to use Delta Accumulators to perform totalisation for Runtime / Starts / Flows / Cats etc...

I have a daily totaliser within the RTU (plus for consistency checks a Yesterday total also).  My plan was to use Delta Accumulators to keep things like Weekly Totals, Monthly Totals, Yearly Totals, All Time totals.

I really wanted to keep these away from being actual Points, however whilst the weekly Delta Accumulator seems straight forward, there doesn't seem to be a way to have a Monthly or Yearly Accumulator (Delta or otherwise).  Since the Interval setting must be an OPC Time Interval, and that doesn't support changing values like Month / Years.

At the moment my 'solution' would be to have a little piece of logic that is alongside the accumulators and runs at the start of every day (Local Time with DST compensation) and if the month has rolled over reset the Monthly accumulators, and if the Year has rolled over to reset the Yearly accumulators.  But I'm surprised that this isn't just 'out of the box' functionality.

I'm also not that fond of pushing out this many ST Logic routine that would all need to execute at pretty much the same time (i.e. 00:00 each day), regardless of how little maths they needed to do (compare month to retained month.. if different reset Monthly and update retained month, compare year to retained year.. if different reset yearly and update retained year...).

I could do one ST SQL query (so that there's not lots of ST routines floating around with the same execution time), but I'm sure the performance impact of the ST SQL query and filters would outweigh the multiple smaller ST programs.

I'm open to ideas 🙂  [unless it involves calling an external command line utility with the SYSTEM() command Adam 😉 ]

[AdamWoodland · Accepted solution]

The issue with accumulators is that by default they expect ad-hoc reporting, i.e. periodic dial in from PSTN, backfill with DNP3, etc, so they handle reset based on receiving data after the reset period ends. Couple that with MO being a dynamic period (28, 29, 30, 31 days as necessary) it doesn't like that.

A few ways I can think of, each has their own advantage and disadvantage:

1. You do the accumulator daily and then at the end of each month do the maths. This doesn't work too well on things like mean, but min and max should be fine

2. Run some logic on the 1st (not necessarily at midnight to allow data collection?) to query the historic the past month and do the maths. Not very scaleable and depending on how much data you're storing may impact performance.

3. Enable the continuous box and this enables the Reset method. Then on a schedule (or any other preferred way) call that method at midnight on the reset. You lose any data being considered in the calc that comes in after the reset for the previous period (so not an issue with modbus... most other protocols will likely have a timing issue even if its just a couple of seconds)

4. Can also use third party programs like Crystal Reports to do the maths?

5. Run a SYSTEM() command to do something (I mean technically you could call some app that does the calcs, but not sure its the best way 🙂 )

[BevanWeiss]

@AdamWoodland I would have thought that backfilling aspect wouldn't really be any trickier than backfilling stuff from yesterday in a daily totaliser... and there's no issue with that.

I don't want to use continuous, as it will be coupled to DNP3 points, so having it point update based seems like the nicest fit.

And the ad-hoc viewing is precisely why I wanted to use the accumulator object rather than just a report type of analysis...

I absolutely forgot that reset isn't available if continuous isn't set... that will be quite the problem for my monthly/yearly reset logic.

The RTU generated Daily Starts / Runtime is what I intended on using as the source for the accumulator.  I'm not sure how these resetting each midnight will impact on things like Crystal Reports.  Certainly a delta across a month would not be valid, nor would a max, nor an integration.

I really did like the idea of the accumulator tracking the reported changes to the Daily Runtime / Starts.  i.e. each time a Daily Start occurs, then the Monthly Starts accumulator should have incremented also (ditto for the Yearly).

Is there really any 'funky' logic in the accumulator that it couldn't just have a trigger to say 'Start new period'?

(i.e. all timestamp deltas before this new period timestamp, all the new ones go into the new period... and I'm thinking that it would just be a Method that could be called via a Schedule object.. that way all the monthly / yearly / weekly / every second Saturday requirements would be met).