Discuss and solve problems in energy management and automation. Join conversations and share insights on products and solutions. Co-innovate and collaborate with a global network of peers.Register Now
The Trend card in PAM lets you choose the time granularity for your chart with the 'Time Interval' setting: hour, day, week, month or year. Data are time aggregated to the requested period using the aggregation method for each measurement: sum, min, max, avg, or "prevent aggregation".
This process is usually invisible and trouble free, but calculated measurements receive some special handling. If you are using a calculated measurement to find something like an energy intensity ratio in manufacturing (energy consumed per manufactured item), and have entered an expression like
[Electricity:Energy] / [Other:Production output]
special care is taken to get you the correct answer when that value is rolled-up to longer time intervals.
When the Trend card sees a calculated measurement as one of its data series, it invisibly wraps an aggregation function around it with the right time interval, like AGGREGATE PER DAY(<your expression>). You don't see this, but it happens to every calculated measurement.
Suppose the energy and production streams were both hourly data and you wanted to see a daily intensity. Instead of taking the hourly ratios and averaging them, the calculation feature can break into the expression you made and rearrange it so the time aggregation is done before the division to make the final ratio. Effectively,
AGGREGATE PER DAY([Electricity:Energy] / [Other:Production output])
Is transformed behind the scenes into:
AGGREGATE PER DAY([Electricity:Energy]) / AGGREGATE PER DAY([Other:Production output])
To do the time aggregation before the division. Now compare that to the way a cost is calculated from a price and consumption. The interval cost of electricity would be:
[Electricity:Energy] * [Other:Electricity Realtime Price]
and the daily total cost would be the sum of these hourly costs:
AGGREGATE PER DAY([Electricity:Energy] * [Other:Electricity Realtime Price])
In this case, aggregating the operands first would give the wrong answer. The average price times the total consumption isn't the total cost.
Certain operations in calculated expressions are marked as "Aggregate Before Calculate". When an expression is aggregated to the Time Interval selected in the Trend card, the expression is searched for any of these operations and the aggregation command is inserted before their operands. That includes:
In the simple example of the intensity ratio above, the aggregation operation is inserted before each of the operands. But what if the expression is more complex? The process continues through the whole expression, looking for one of the three operations above and inserting the aggregation wherever it's needed.
For example an expression to calculate Power Factor from Reactive and Real energy would be written as:
[Electricity:Energy] / SQRT([Electricity:Energy]^2 + [Electricity:Reactive_Energy]^2)
Which for readability's sake I'll shorten to:
A / SQRT(A^2 + B^2)
To show this in a daily trend card, the system first wraps it in AGGREGATE PER DAY behnd the scenes, like
AGGREGATE PER DAY(A / SQRT(A^2 + B^2))
And then following the rule above, this is transformed into:
AGGREGATE PER DAY(A) / AGGREGATE PER DAY(SQRT(AGGREGATE PER DAY(A)^2 + AGGREGATE PER DAY(B)^2))
Which gives the true average power factor in a day. Notice that an aggregation operation has been inserted before the operands to each of division, square root and exponentiation.
So far, this rewriting of expressions is limited to only those that have their aggregation method set to 'Auto' in the basic measurement properties:
Starting in June 2018 though, you can ask for this treatment for calculated measurements with other aggregation methods by adding a directive in front of the calculated measurement's expression. If you add [[AggregationTrigger:Always]], then when it's being rolled-up to a longer time interval in a Trend card it will be searched for division, square root and exponentiation and aggregate the operands to those operations first. If none of those things exist in your expression, nothing will change and it will work as before.
Normally there isn't much need to do this because we already advise people to use the 'Auto' setting for ratio type expressions in the help window in the Edit Measurement form:
Hi Andy .... It may be this was just an example so apologies .... but as a Trend a little confused as to why reference this for Power Factor as a daily aggregated result when for the energy manager it is essential to be chasing the `time of event` and a Trend by daily aggregation I cant see of any value ... method would overstate the performance and miss the power/equipment issues involved. If report was just `Day by Average Min and Max and Min and Max shown with time stamp that would be okay.
This may already be hidden but on `interval length` UK most of Europe and I believe Aus are using half hourly metered data UK since c1988 ... can system manage this or is system already aggregating HH to hourly and reducing visibility?
On tariffs our application enables User to create by interval by day type and designate what months/years this applies to ... in this way User can report cost of any measurement energy/production etc at interval day week month ...custom periods etc where customer may cross changing tariff rates such as STOD `seasonal time of day` which varies by time period system uses right rates against right numbers. Again as with PF is your Trend method reducing accuracy in `aggregation` ... eg if you take an `average tariff ` imagine 3time periods night 8 HH periods 6p day 24 HH periods 12.5p evening 16 HH periods 8p ... average = 8.83p av or three rates or 9.91p av of 48 HH periods? Neither gives accurate result ... as you don't know when energy was used .... what you need is the individual period calculations `summed`
Sorry if this rambles ... but trust its a useful comment or already resolved ... If you want examples I can run some stuff to help visualise
Power Factor (calculated from energy) was just used as an example of a more complex expression using division that should be aggregated before the expression is evaluated in order to get the expected result. While this may not be relevant to the PF analysis and billing determinants that you are looking at (which I think from the other post is PF at time of peak demand), we've had a number of requests from clients in areas where customers are billed on "average" power factor (calculated from total monthly kWh and total monthly kVARh) to be able to chart this in Trend Analysis. Tony's example used SUM PER DAY, but it would be the same idea, just using SUM PER MONTH, when viewing monthly average power factor in Trend.
The ability to view Power Factor in Trend is new. We didn't initially expose it because of precisely what you have raised here- there are different expectations of how rolling-up power factor to monthly (daily, weekly,yearly) intervals should be handled. We implemented the "average" power factor method as described above, but don't currently have an easy "out of the box" setting to tell the system to show PF at time of peak kW (or peak kVA) when rolling up the data. Some of the scenarios that you can set up fairly easily are:
The aggregation method (average, min, or max) is set for a measurement group, and you can define multiple measurement groups with the different methods if you want to compare the various values on a chart.
If you want a report on your monthly PF at time of peak demand over the last year, you could set up a more complex expression to calculate this. There's an example here if you are interested: Using an expression to find PF at time of peak demand (and other coincident values)
PAM supports interval data in all different lengths below hourly. I believe the most common we see is 15-minute, but we have half hourly, 5-minute, 10-minute, etc. If you want to see the lower level interval metered data, you can do this in Load Profile. In addition, the statistics in Load Profile offer some of the Power Factor data that I think you are looking for (min, max, average, PF at time of peak demand).
Trend Analysis does aggregate the data to hourly as the lowest interval length supported, and also rolls up to daily, weekly, monthly, yearly. It aggregates using the measurement group's aggregation method, so energy streams will add up the half hourly data, Demand streams will take the maximum half-hourly value, temperature will take the average of all the intervals, etc. These aggregation methods are set for each measurement group.
You can break the data into time of day periods (in PAM these are Site Schedules) and show these in Trend, or use them in calculated expressions. I'm not exactly clear on the question in your example, but I think you are asking if PAM aggregates all of the energy (or cost or other data) for a day and then somehow averages that back into each time period. If that is the concern, the answer is no, PAM doesn't aggregate/average when using the site schedule feature. PAM actually works at the lowest level in almost all cases. The feature to roll-up the data first before calculating the expression was specifically added (with a special directive to do so) to handle the average power factor scenario because most of the time PAM does operate on the lowest level before rolling things up.
For example, in Trend analysis when breaking down the data by Site Schedule, each interval data point is allocated to a TOU bucket before those buckets are rolled up individually. Each interval data point in the shaded area (here on Load Profile, 9am-5pm weekdays) is included when adding up to get the daily (or monthly or yearly) total.
The max demand for each time period is only from the intervals that fall into the time period definition.
Same thing if you are calculating cost from energy * price. As Tony mentioned above, multiplication will always operate at the lowest level and then aggregate after. So if you want to aggregate your cost per TOU period on an expression which is Energy * Price, it will calculate the cost at each lowest-level interval (e.g. 30-minutes), and then add those up for each TOU period for your selected time range (e.g. per week or per month). There are some complexities in setting this up (using Site Schedules in expressions if you want TOU-specific pricing), but it will work as you want it to.
There are a couple of other shortcomings that I know we have related to what you mentioned. The first is seasonal TOD definitions. Right now you can define TOU periods on different days of the week, include special days (e.g. holidays), but there is no support for seasonality or annual effective dates. The second you can see in the screen capture above: we don't actually show the timestamp of the min/max demand in the statistics window of the Trend Analysis. You have to click on the day to see the hour, or jump over to Load Profile to see the exact timestamp.
I hope this answers the gist of all of the questions, but let me know if not! I'm happy to follow up with some time on the phone if it would be helpful.
Thanks Cynthia ...
Many thanks looks like it has the core to what we do and is being pulled together.