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
In the we talked a little about Bi-Directional energy measurements in for electricity in PAM. Marty also put up a post showing the New Standard Measurements supporting Electricity Generation . I think it's time, however, to bring this all together into a larger discussion.
As on-site generation becomes more common, we have a greater need to show and analyze the generation, its impact on the site's grid-based consumption, and to allow calculation of KPIs on the whole complex situation.
For example, a building with solar panels on the roof will generate electricity (on a clear sunny day) in a roughly parabolic pattern that loosely aligns with a normal load profile. It may partially or fully offset the building's energy consumption during parts of the day, potentially sending energy back to the grid. In this situation, you want to track 3 distinct things:
Prior to November 2017 we only offered one "flavour" of electricity - we just called it "Energy" and didn't say anything about it being about consumption or generation or net. There were, of course, the apparent and reactive aspects as well as the demand-based measurements as well. If you wanted to keep track of energy generated specifically, you needed to create a new node in the hierarchy, and then just adopt a convention that the "Energy" measurement for that node was generation. We see lots of systems deployed in the past using this method:
In this example, the Energy measurement means different things on these nodes. At the "01 Base Building" node, it refers to net energy. When the generation exceeds the load, it becomes negative. At the "01 Base Building Load" node, it refers to the consumption on site, ignoring generation. Finally, the "02 Total Solar Generation" node holds generation, ignoring site load.
We strongly encourage you to try to set up systems where you map your various data streams into the measurements that we designed for them. In ION meter terms:
|ION Measurement||PAM Measurement|
|Energy Delivered||Energy Gross|
|Energy Delivered minus Received||Energy Net|
If you do this, you can create a nice clean top node for each site or building where you have the ability to turn on all 3 data streams and get accurate information about: energy used (aka Energy Gross), energy balance (aka Energy Net) and energy generated.
When you set up systems like that, make sure to teach your users how to select measurements in PAM! Also, feel free to offer feedback that comes your way. Maybe systems with generation should have Energy, Energy Net and Energy Generated as "on" by default?
This isn't perfect yet, and there are things that we're watching out for. The main one is:
Im still not 100% clear on the gross v net demarcation & also the handling on nodes below the site level.
I am having difficult with the question whether Energy Generated would be our full PV generation, or whether its the amount exported from the site?
In the intro above, you say it is 'generated within the facility', whereas the table mapping against the ION meter measurements would suggest its the 'export' or 'received'. I think we just need to clarify this point and then it become a little easier.
So do we want 'Generated' to be that 'exported' from the node, or the total 'generation' for the site?
My interpretation was that its the 'export' and not generation. This is on the basis that we want it to be consistent across multiple nodes. For example, if we have bi-directional sub-meters in the hierarchy for a cogen system, or sub-meters that have the PV system attached to them.
If we want to allow for all of these points to be available on a single node, then I see 5 measurements, meaning we need to add one more:
|Energy exported (generated out from the node)||?|
|Energy import - export||Energy Net|
|Energy generated (in total, not from the node)||?|
|Energy import - export + generated||Energy Gross|
The other issue, which I have come across with the client Verdia, is that when you look at the actual generation source node in the hierarchy (eg the PV system), the 'correct' setup for bidirectional energy to have it as energy generated is actually counter intuitive.
With Verdia, I have had to remind them several times that to view the generation when they click on the PV node, they need to turn on the energy generation measurement. From that I make the following notes about human interface:
1) Intuitively, when looking at generation nodes, we expect them to be flipped from consumption nodes in terms of viewing the data
2) This is reinforced with 'energy' being the default measurement turned on in the PAM hierarchy
In the end, import/export all depends on what side you are looking from! For example, the utility data we get from retailer here are always from the networks perspective. So a site generating into the grid has data that is 'importing'.
I dont think this is an easy one to answer and in reality, I am probably a bigger fan of us creating hierarchies that make the most sense for our clients on an individual level.
That said, how does taggregation work with bi-directional energy? Certainly, we want at least a consistent structure in place such that we don't have to do a huge number of calculated measurements to make our clients hierarchies work for them.
Oh this takes me back to my thermodynamics lectures.
Gross and net can get misleading. For example I wouldn't agree with either definitions of gross energy above. I think this is heavily dependent on the definition of the system.
If the consuming assets of a site are classed as the system then my view is below:
I have two thoughts on all of this:
1) Having different meter / node types
Do we need to / or can we currently define nodes as being different types or is a node a node? When selecting a node can we define it as a generation / consumption / delivery / export / storage?
A potential benefit of this would be if you could set up some defaults in the system e.g. don't combine generation and consumption nodes in a stacked bar chart. Always overlay generation. Don't aggregate consumption and generation automatically. It could then do Kim's point as well for total generation where it would know to aggregate all generation nodes that sit below it in the hierarchy.
2) Adding new reports / areas of RA
The UX has been brought up and the difficulties some users are having. Currently we have one place where we expect all users to go in and play. This can be your basic user or your super advanced user. Do we need to think about creating new reports / analysis areas that are specific to certain types of analysis. E.g. A consumption area would be completely focused on those just looking at consumption (what we have today). A net energy balance (whatever you want to call it) area would be targeted towards analyzing impact / benefit of on-site generation.
In my view we are putting more and more great stuff in a very small space, which means we are being forced to hide it away in places. This is not helpful to the user. You could say that is what dashboards are for, but it is not in my view. Dashboards still don't offer enough functionality for analysis to serve this purpose.
Here is an overview of how Dexma approaches it:
In the example you will see they ask for the meters to be defined to my Point 1 above. To Point 2 all of this sites in what they call and App (SolarView). This is where you get multiple reporting and analysis options focused only on Solar generation.
If the consuming assets of a site are classed as the system then my view is below
The "system" is not defined in any meaningful sense here. The "system" is contextual: whatever you have selected in the hierarchy (plus its children) is "the system". Therefore, it's not just consuming assets: it can be a mix of consuming and producing assets. This is part of what makes this challenging.
The terminology is certainly debatable too. I'd agree that at the top site level, "energy gross" equating to "energy delivered" is not ideal. However, at almost any other point in the hierarchy it's usually correct. The energy flowing to a chiller is counted as "energy delivered" regardless of whether it came from the grid or from on-site generation.
To your point about "node types", we are effectively trying to solve that with "measurement types". They amount to roughly the same thing: don't aggregate generation and consumption. Allow reporting on total generation within the site. etc. We are trying to improve the experience of using these things of course, and marking nodes with types is an option. We can invent any tags we like, and we can make some tags "system defaults" that exist on all clients if we want as well.
Finally, new PAM cards would be a great way to handle this. When Qlik is integrated with interval data, we can also do better guided reporting of these things. Unfortunately, none of these things is at the top of any revenue leaders' current list of priorities!
So I've been at a Qlik Conference all week this week and I am amped up at some of the possibilities and use cases around this type of "On-Site Generation Analysis Card" concept.
As Mike stated, this doesn't show up on the revenue leaders list of top priorities...but it might be moving up my personal list of fun extra-cirricular use cases of Qlik to test Agile development of analysis to deploy against interval data within RA.
I'm not promising anything.
Brian, I would be more than happy to contribute to this "side project" If you need someone to bounce ideas off, feel free to reach out to me
Energy Generated would be relative to whatever node it's on. So "Energy Generated" at the site level is the total production of energy within the site. This is not the same as "energy exported" though: for that, you'd look at the Site's "Energy Net" value. If that is negative, then you're exporting to the grid. If it's positive, you're still importing from the grid.
Lower down the hierarchy, "Energy Generated" on a node called "Solar Array" would be the energy generated on that array. If each panel in the array is metered, then it would be the sum of the "Energy Generated" on each panel. The "Energy Net" value on the solar array would (probably) be the inverse of "Energy Generated", since one assumes there's no consumption within the array.
Thanks Michael Schmitz, the reason I feel another measure is needed, is that we often will get data for a point purely on the export (ie utility grid data, or even a bidirectional meter), so to load that in to be able to create the 'net' meter. At the moment, and following your guidance, the generated is the total generation (not export), then we have no base measurement to put this value in to create the virtual of the net meter. Below is a visual representation of the 5 measurements we need to cover (imo), using your terminology of generation being for the total generation. For most AU sites we will have the black '?', the dotted green 'energy' and the 'generation'.
On taggregation, lets use a case where you have 2 main switchboards, one of which has generation and exports, the other that uses it. Aggregating for the site node means that everything needs to be setup just right - and where I agree with you, the need for the right measurements to be used is critical to ensure the site level measurements are correct.
I feel we still have a intuition issue around the generation though. Is there a way that, for sites with generation, it is selected as a default measurement along with energy?
Martin Mokry Kim's case above is pretty interesting. It's probably worth revisiting this as we launch the Data Lobby and think about what we might do here. As Kim has described, the black line and dotted green line don't have natural places to live in PAM. If you subtract the black line from the dotted green you get Energy Net as we've defined it. Should we discuss creating two new standard measurements to support this? Alternatively we could create custom measurements where needed and then calculate Energy Net from them at the site level.
Food for thought.
A few more thoughts:
Import/export: this is specifically why we didn't use those terms. They are subjective based on who's talking. Energy Generted is pretty clear. Energy Net is harder, hence my comment that its positive under normal consumption scenarios, and negative when energy is flowing "backwards".
Taggregation: this is one reason we want to be careful to use measurements and not just specially named nodes. Say you have two brands of solar panels, A and B. If you want "Energy generated by A" and "Energy generated by B" at the Site level, then you tag the panels and do an AggregateChildren expression on the "Energy Generated" measurement using the tags to create these two new measurements. If instead you are running diesel generators to load shed on your production lines, you could do taggregation of any of the "net energy", the "gross energy" or the "energy generated" on lines A, B and C. The lines in this case would be whole systems including load- and generation-nodes. Taggregation would allow you to elevate these line-specific totals to the Site level, if that mattered to you. Maybe for aggregation above the site into groups or divisions?
Do you have specific taggregation cases you want to run past us?
Alisdair Mc Dougall I had the same thought as you - at what point does it make sense to add a new card specific to this? Or even a new module specific to renewable energy where we can tie in the environmental trading module? It sounds like we are trying a bit to put a square peg in a round hole by relying on training of users to do certain things for net/generated energy vs. consumed.
The problem with new cards is cost. I agree it would be great to do a card for energy generation, or a Qlik report (once PAM data can be queried). For now, we're trying to figure out how to build useful outputs using the tools we already have, as effectively as possible.
I think I have to go with Kims expression here as it would seem RA is not following the `markets` use of data but creating its own more complex vision.
Virtual meters or net off can occur in all directions ....... so positive and negatives needed. I am unclear why you are creating new measurement groups when a `virtual` should simply plot `number` .
Else does the virtual Site or virtual measure need separation in the portfolio tree to avoid avoid data being counted or aggregated elsewhere using other standard visuals ? .. .....
In simple terms there are 4 points to meter and the effectiveness across these points could be positive or negative depending on whether you are buying or selling energy . For example .. think line losses / distribution losses ~ we have metered a turbine house ... a point of insertion 300m across a water meadow plus the Grid Incomer and Export data sets to manage
Meter A = `point of generation` [ export] Meter B = `point of on Site use/distribution` [ import]
Meter X Standard grid Incomer for `consumption` [import] Meter Z to grid [export] when Site generates excess
1st point of management is to see all 4 measurements `kWh` on same graph/same table of numbers be it generated or consumed ... no negatives are involved in this view they are just energy numbers .. if you have precipitation/ wind and/or irradiance all the better.
The User needs to visualise the 4 aspects before determining next item to review
The secondary and tertiary are to create `virtual meters` where you net off as described by Mike but why no negatives ?
The User will want to see both positive and negative impacts of the process and all the data they need for each market.
However .... this becomes more complex when the Site has Meter B2 or B3 .. ie a Tenant on their Site who takes part of the generated load [ this model exists now .. usually termed boundary meters ...] . and in a few odd sites we also have Meter Z2 ... where Meter B2 only takes On site generation but can themselves export their excess to grid under their own Capacity Market contract.
Hope this helps ....it may be that UK is further ahead in trading these things but as a rule expectation is that `calculation` should be possible to create number results as positive or negative ..... Individual meter results are needed for specific market reporting/buying/selling regards Peter