Accurate Allocation of energy in production processes - the importance of using metamodels

Condugo
Accurate allocation of
energy in production
processes
The importance of using
metamodels

Condugo
Accurate allocation of energy in
production processes
The importance of using metamodels
Copyright © 2017 by Condugo
All rights reserved. No part of this publication text may be uploaded or posted
online without the prior written permission of the publisher.
For permission requests, write to the publisher, addressed “Attention:
Permissions Request,” to info@condugo.com
2

Many companies struggle with correctly monitoring, allocating and distributing
direct and indirect energy consumption over all internal and external customers,
users or products. In this age of rising commodity costs and additional
attention to sustainability, the advantages of adequately allocating energy are
nonetheless substantial:
1. Real-time mapping of energy throughout process flows makes it easier
to detect deviations in energy conversions during production processes,
find the root causes and reduce losses.
2. Using exact and objective keys for allocating energy consumption
speeds up periodic P&L and CSR reporting and makes for more accurate
reports.
3. Continuous, real-time distribution of energy cost among users increases
transparency and raises awareness with them.
Although most companies already struggle with integrating correct data from
metered equipment, this is only the first - albeit important - step. The crux is
fully understanding the nature and efficiency of energy conversions processes;
energy inflows and outflows to different customers; fixed and variable costs
and corporate structures. By using metamodels - designed for and maintained
by energy managers - all this information is added to the initial metered data
and processed in such a way that any change from an energy point of view
instantly leads to adjustments in the energy allocation.
This white paper reviews emerging trends and challenges in energy allocation
and examines the working and benefits of using specific metamodels at the
level of energy management software.
3

Index
Market drivers impacting energy management and energy allocation 5
The challenge of energy allocation mismanagement 5
A brief history of energy management tools 7
The solution: the metamodel as the core of energy management 8
What exactly are metamodels? 9
The core elements of metamodels 9
The benefits of graph-based versioned models 12
Hierarchical vs. graph-based metamodels 13
A detailed graph-based versioned metamodel 17
A model for accurate distribution keys 18
Application: conversion efficiencies 19
Application: cost allocation 19
How to choose energy management software 24
Do I need a graph-based metamodel in my energy management software? 25
Do I need a versioned metamodel in my energy management software? 25
Condugo’s energy allocation module 26
Co-creating the next generation of energy management software 28
4

Market drivers impacting energy management
and energy allocation
We analysed 156 energy management applications for energy bookkeeping.
We found that the majority of them do an excellent job in collecting, validating
and reporting straightforward metering data (mainly for electricity and gas),
but that they fail to provide meaningful insights as soon as energy conversions
and changing company structures enter into play.
This is a cause for concern, as the general trend with industrial companies is to
monitor all process flows - including conversions - and the associated energy
costs in real time and with increasing detail.
In addition ‘energy’ is gaining importance as a strategic issue in such companies
and is no longer only of concern to the energy manager. Not only do several
people throughout the organisation bear responsibility for a share of energy
consumption/costs, but the requirements on external reporting on energy and
sustainability have gone up as well.
The challenge of energy allocation
mismanagement
The core challenge at the heart of energy allocation is to relate recorded energy
data to the specificities of the process flow and the organisation structure.
Although this is a point of attention in any organisation, it is especially complex
in industrial processes. This can be explained by three factors: data issues,
conversion of energy flows and corporate restructuring.
Data issues
The logical approach to allocating energy, is to use a distribution key based
on a combination of main meter readings with submeter readings for each
customer. This requires the integration of data from many meters, turning them
into a consistent and permanent data stream of high quality to work with.
Getting those data in, validating them and correcting any errors, is the first
major challenge.
5

Conversion of energy flows
It becomes even more complicated when energy flows are being converted onsite,
as is the case in many industrial companies. A common example is the one
of CHPs. They take in gas and convert it into heat and electricity, which could be
used for producing hot water or powering equipment. The consumption of an
internal customer therefore consists of what they consume directly plus their
share of whatever went into the conversions into other energy types which
they consumed as well. Full understanding of the nature and efficiency of such
conversion processes, energy inflows, outflows to other customers, fixed and
variable costs involved, is crucial information that should be structured, added
to the metering data and processed.
This is not a trivial task and most companies stop short of this or rely on proxy
measures to assign a share of energy used in conversions, to its users. Apart
from being a source of internal discussions on P&L responsibilities, it frustrates
any attempt to report on and track energy usage at the level of individual
production batches.
Correctly incorporating on-site energy conversions therefore is the second
major challenge.
Corporate restructuring
The third challenge is the consistency of the distribution key and overall energy
monitoring when conditions change.
Corporate restructuring changes the entire fabric of departments and
responsibilities. From an energy point of view this implies unbundling flows
and reassigning them to different entities.
Physical changes can be even more tricky: upgrading production installations,
adding or removing buildings, reconverting entire sites - those are all reasons
for adding, removing or reconfiguring individual energy meters.
When such changes occur - which is more or less continuously in any larger
organisation -, the new configuration of meters, processes and departments
needs to be linked to the previous one to make reporting consistent and to
continue providing meaning to the data.
6

A brief history of energy management tools
Crafting appropriate distribution keys is often a tedious task that is undertaken
once a year - with meticulous attention to details and hard work. Without the
appropriate software tools, it is almost impossible to monitor their evolution
permanently.
Over the last ten years, the market for dedicated energy bookkeeping software
has grown and there are now a number of applications for collecting, validating
and reporting metering data. Most of the 156 energy management packages
referred to above, indeed provide real-time monitoring.
When it comes to providing insights and linking metering data to the
organisation structure, however, only a very small number of those packages
provide the option to do so. Dealing with changing structures proved even
more problematic, as none of those applications provided an option to take
into account changing structures without heavy custom development.
Taking into account energy conversions and allocation energy throughout such
processes, turned out to be an even greater challenge that none of them could
address.
The fundamental reason for these shortcomings, is the lack of an adequate
metamodel at the core of the current generation of energy management
software. Such a metamodel provides all contextual information that is needed
to interpret raw metering data. It describes the structure of energy flows
(inflows, conversion, outflows); the structure of the company (the organisation
chart); and the position of key people (those with responsibilities, as they will
need dedicated periodic reports) within it.
The metamodels in the software - which were present in only a fraction of
the packages to begin with - are hierarchical and static. A hierarchical model
would give each asset a fixed position within a set structure, where it belongs
to one and only one higher category (e.g. a meter belongs to a building, which
in turn could be part of a site). Energy conversions, however, break this mould
as several commodities - and thus their meter readings - are combined and
recombined in different configurations. As the models are also static they are
not aware of any changes that may have occurred, impairing the ability to draw
conclusions.
All this points at the dawn of a new generation of energy management software,
built around appropriate metamodels and able to allocate energy in changing,
process-based settings.
7

The solution: the
metamodel as the core of
energy management
8

What exactly are metamodels?
‘To measure is to know’, is the adagio at the heart of energy management.
Systematically collecting the readings from a network of (sub)meters is indeed
the starting point. The boom in submetering of the last decade brought with
it a proliferation of software packages focused on collecting, validating and
visualising information. At the time of writing this document, Capterra lists
156 applications under the heading ‘energy management’. If we add generic
enterprise data management software being used for storing metered data the
tally goes up even more.
Data management is important, but only a first step. Data needs to be interpreted
within the specific structure of the company to really build understanding of
the energy situation. Identifying the real cost drivers or the most attractive
improvement projects, following up on performance - or assigning energy to
internal users - can only be done when there is more info on the context. For
each measured value, there needs to be information on where and when it was
recorded, what kind of process/building the meter is associated with, what
kind of energy flow is being measured and how it is related to other meters
and flows. Such ‘data on the data’ are what is called metadata. A structured
overview of all relevant metadata and the relationships between them, is what
is called a meta-model.
Most energy management software is not built around metamodels and
is therefore limited to recording and visualising metered values, leaving
interpretation entirely to the user/energy manager. A limited number of
programs -as mentioned before - do incorporate some kind of model and
allow for energy reports that are organisation-specific and infused with
meaning. Typical examples include the monitoring of the consumption of an
entire building based on the readings of several submeters or the reporting on
(variable) energy costs of an entire department.
The core elements of metamodels
Complete metamodels for energy management contain three basic categories
of information.
Structure of energy flows
Every production process consists of a number of conversions, which together
transform flows of raw material into a (semi-)finished product. This is reflected
energetically as well. A number of energy flows are acquired or produced
9

locally and then used throughout the production process. In many cases there
will be conversions in between.
Each submeter captures a part of this whole - and its place in it should be
documented. This involves both a specification of the type of energy/commodity
it measures (electricity, gas, heat, compressed air,...) and the relationship to the
other meters. This way flows can be decomposed in their constituent parts and
any losses/inefficiencies detected.
Example graph based model with single conversion
Source node Distribution node Conversion node Distributionnode
Natural gas grid
Natural gas Hot water boilers Hot water
connection
Sink node
Building product
line 1
Sink node
Building product
line 2
Figure 1: Graph-based model example illustrating node types.
Company structure
Every meter ought to get a place in the overall company structure. They belong
to departments, sites or buildings. Groups of meters may together capture the
energy situation of a part that is deemed relevant.
Mapping the network of meters to the company structure is the bedrock for
assigning energy usage to cost centers throughout the company. Depending on
the energy intensity of the organisation, the impact on P&L can be considerable.
A good metamodel captures this in a fine grained fashion, allowing each
individual meter to be clustered in several ways at the same time so as to
reflect the complexity - and the peculiarities - of the company.
Hierarchical model
Company HQ
Site Brussels
Building 1
Line product A
Building 2
Line product B
Line product C
Site Antwerp
Building 1
Line product D
Line product E
Building 2
Line product F
Site Ghent
Building 1
Line product G
Line product H
Building 2
Line product I
Building 3
Line product J
Line pruduct K
Figure 2: Hierarchical metamodel example for physical company structure
10

Position of key people and responsibilities
There are typically a number of people who bear some kind of responsibility
for the energy flows and costs of the company. Each of them requires specific
information and reporting, focused on their area of authority and tailored to
their needs. The production manager will be more focused on permanent
updates on the energy use and losses throughout the process; the purchasing
department’s first interest is getting all information to periodically (re)
negotiate the best contract price; accounting will be looking at ways to verify
whether monthly invoices match actual consumption; and the energy manager
is on the lookout for new opportunities to reduce overall consumption. In
organisations where energy has already become a strategic issue, the CEO will
require periodic overviews of the evolution in total consumption, cost and CO2
emissions - which will eventually show up in the annual reports.
The people involved and their precise positions in the company hierarchy,
differ wildly. There is a clear trend, though, to have an increasing number of
employees needing to pay some kind of attention to energy consumption and
costs; and to assign specific responsibility for energy improvement to a single
person - who may or may not be taking it up as a full-time job.
A good metamodel integrates the information on those people. (Groups of)
meters can be linked to one or more positions; access rights to each individual
data point can be defined for each profile; and the level of aggregation of the
information is included.
11

The benefits of graphbased
versioned models
12

Hierarchical vs. graph-based metamodels
The metamodels found in energy bookkeeping packages are mostly hierarchical.
This means they categorize every data point - typically an energy meter reading,
but it could also be an invoice or a contract - as belonging to a single group or
entity. This in turn is part of another group or entity.
The hierarchical metamodel is in very many ways a direct reflection of the
formal company structure. This is not unlogical:
• Many packages are focused on buildings and sometimes individual
installations. Energy consumption is therefore broken down to that level.
They are in one place and belong to one entity.
• By reflecting the formal hierarchy, the formal chain of reporting is
mirrored and data are likely to be available at the point where they are
needed. A department manager will need information on the overall
energy consumption and contracts for their P&L; plus more fine grained
output from underlying submeters to pinpoint the main drivers of costs.
The limitations of hierarchical models start showing up when the focus shifts to
the (production) processes rather than the buildings or installations.
Processes imply a sequence of inputs being combined, converted and
recombined. All of those occur with a given efficiency, which can vary over
time. The energy content or cost of a single unit produced therefore is the
sum of (fractions of) the energies that went into each of the preceding steps.
This can no longer be determined by simply looking at a single meter output
or a single invoice; nor is it sufficient to aggregate a few meters. Depending
on the process and the products involved, datapoints will need to be grouped
in specific ways and become part of more complex calculations. A single
datapoint - again, most likely to be a meter - could therefore figure in different
configurations, belonging to multiple processes at once or being used several
times over in a single calculation.
The solution is to move up one step in complexity to the incorporation of
graph-based models. They are far better in reflecting the logic of processes:
every entity is connected to a number of preceding entities and a number of
entities succeeding it. This is shown in figure 3 .
13

Example graph based model with CHP and hot water conversions
Source node
Electricity grid
connection
Distribution node
Electricity
Sink node
Building product
line 1
Source node
Wind turbine
Conversion node
Combined heat
power
Sink node
Building product
line 2
Source node
Natural gas grid
connection
Distribution node
Natural gas
Conversion node
Hot water boilers
Conversion node
Hot water
Source node
Water grid
connection
Distribution node
Water
Sink node
Building product
line 3
Figure 3: Graph-based model example.
As is immediately clear from the picture above, a graph-based model is not
restricted to the one-on-one relationships between a datapoint and the entity
it belongs to. Interpreting total energy consumption that went into a batch on
product line three, for example, is now possible as the model can trace back
meter data on how much electricity (and from which sources) was used, which
fraction of natural gas was used - both for heating water and for generating
electricity - and how much water went in. The efficiency of the hot water
distribution and the combined heat-and-power (CHP) plant is readily available
from the meter readings and can be taken into account as well.
Do note that hierarchical models can be seen as a less complex instance of
graph-based ones. In a process where no energy sources are combined or
converted, every step gets only one input from its predecessor. There would
be only one arrow arriving at each node - which is the conceptual equivalent of
the datapoint/node belonging to a single category.
Static vs. versioned models
A second perspective is to distinguish between static models on the one hand
and versioned models on the other.
The few software packages we found to have been built around metamodels in
the first place, were all based on static ones. The word ‘static’, however, does
not necessarily mean the metamodel cannot change - indeed, one or two of the
packages did offer (limited) options to adjust the configuration of datapoints/
meters that are fed into the program. They are still ‘static’ in our vocabulary,
however, as they lack the essential feature: they do not track the changes that
were at the basis of the change in the model. There is no way to uncover the
alterations to the structure of the energy flows, to the company structure or
to the positions of key people. There are, in other words, no pathways that
14

logically link the old and the new model to each other.
The lack of pathways is a major impediment for energy reporting in complex
and changing organisations.
• Trend data are no longer meaningful after a change. The information
being reported - and the conclusions based on it - may or not be about
the same entities or processes as before. The model itself will only
allow for interpretation based on the configuration based on the new
situation, even when the bulk of the trendline is based on data being
collected in the old situation. The issue is further compounded when
several, consecutive changes occur - each time wiping out the meaning
that could have been given to older data readings.
• The allocation of consumption or costs to entities, loses its value as
a management tool. Whether the goal is to track performance, draft
department P&Ls, do accurate cost accounting or inform CSR policy,
the information gained from a changed metamodel can no longer be
put to use the same way as it may no longer cover the same underlying
elements.
Versioned models offer a solution. They are essentially a series of timestamped
metamodels, each of which has been valid for a given period of time.
Whenever a change occurs, the old version gets archived with the appropriate
time stamp and the new one is generated. In addition, the links between the
previous and the new model are made explicit. This means each new, changed
or altered datapoint must be highlighted as such; get its place in the overall
structure and have its relationships with other datapoints defined. Examples
include fitting an extra meter in a given process or adding a new building to an
existing department.
Do note that a versioned model is a generalisation of a static one much the
same way a graph-based model is a generalisation of a hierarchical one. As
long as there are no changes to the underlying energy or company structure,
the versioning does not come into play and the model is identical to a static
one.
15

The table below summarizes the main distinctions between metamodels
Hierarchical
One category per
datapoint
Graph-based
Multiple precursors per
datapoint
Static
No awareness of
changes
• Buildings and stable
tertiary sector
environments
• High-level insight in
trends as long as no
changes
• Available in some
software
• Stable industrial
environments
• Insight in trends lost
as soon as changes
• Only indirectly
available in a few
applications
Versioned
Changes in model are
tracked
• Buildings and
changing tertiary
sector environments
• High-level insight in
trends
• Only available
through heavy
customization
• Changing industrial
environments
• Full insight in trends
• Not available in
current energy
management apps
16

A detailed graph-based
versioned metamodel
17

This section presents a concrete metamodel and uses it to illustrate how
metamodels work, what intelligence they embody and how much complexity
they capture.
A model for accurate distribution keys
The goal of this model is to provide an accurate distribution key for all
commodity types present on the site of a company, especially when on-site
conversions come into play.
We will refer to the example given below of the CHP and hot water conversions
to explain the model (See figure 4).
Example graph based model with CHP and hot water conversions
Source node
Electricity grid
connection
Distribution node
Electricity
Sink node
Building product
line 1
Source node
Wind turbine
Conversion node
Combined heat
power
Sink node
Building product
line 2
Source node
Natural gas grid
connection
Distribution node
Natural gas
Conversion node
Hot water boilers
Conversion node
Hot water
Source node
Water grid
connection
Distribution node
Water
Sink node
Building product
line 3
Figure 4: Graph-based model example.
The model requires three steps to achieve correct distribution of the commodities
(the source nodes) to the customers (the sink nodes).
1. Partitioning source node flows over distribution nodes
The first step distribute the consumption of each commodity
(represented by the source nodes) over its direct customers
(represented by the distribution nodes). This initial partition is
based on submeter readings for all customers of the particular
commodity type (represented by the sink and conversion nodes).
In the graph model above the total commodity consumption
equals the sum of all the input flows of a distribution node.
Total water consumption (a distribution node), for example, is
what is provided through the water network (a source node).
18

2. Allocating shares to sinks and conversion nodes.
As the goal is to get to the distribution over the final customers (the sink
nodes), the next step is to further distribute the share of consumption
allocated to the distribution and conversion nodes. This describes the
actual physical flow of the commodity types from the distribution node
into the other nodes (sink and conversion nodes) . It is used to spread
the total amount of commodity used over all the physical users of the
commodity type.
3. Allocating indirect consumption from conversion nodes to sinks
The final step redistributes the flows that have gone into conversion
nodes. All users of the converted commodity, in other words, will get
their share of the primary commodity they indirectly consume. This
partition is crucial for transferring all costs - both direct and indirect -
for all commodity types to the internal end customers of the company.
The description above illustrates the power of graph models. The logic of
partitioning is already built in, so to speak. It defines the energy type sources,
conversions and sinks for all the energy types provided by the company. Meters
can be mapped to the flows of the graph model for all the periods relevant for
the company - whether it is weeks or months - and their totals calculated over
those periods.
Application: conversion efficiencies
The first application is straightforward. For each conversion node, the efficiency
of the conversion is easily calculated using the input and output flows. Every
input-output combination gives rise to a particular efficiency.
For example, a combined heat power converter has a single natural gas flow
input and two output flows, heat and electrical power.
Application: cost allocation
All costs for the acquired commodity types like, gas, water & electricity need to
be allocated to the internal customers who use them. In addition the costs for
converting acquired commodity types to derived commodity types (e.g. hot
water, resulting from the combination of water and gas) need to be allocated
to the internal customers that use these derived commodity types.
Direct costs are fairly easy to allocate, as they can be linked to the meters which
record the commodity type usage. The challenge is to correctly assign indirect
19

commodity costs, like depreciation costs, operational costs and maintenance,
to the internal customers. A graph-based model which includes commodity
conversions will be very helpful in implementing this application.
All in all, three steps are needed to correctly allocate commodity costs to a
company’s internal customers.
Assigning cost centers
The first step in building a cost allocation application model is to assign cost
centers to all nodes in the graph based model. Four types of nodes exist in
the graph model: source nodes, conversion nodes, distribution nodes and sink
nodes.
Source nodes apply to acquired commodities on the one hand and locally
generated ones on the other (e.g. electricity from wind turbines or solar plants).
For acquired commodity types the monthly invoices will be assigned to their
cost centers. For locally generated commodity types, the depreciation costs,
operational costs and maintenance costs will be assigned.
Conversion nodes are used for industrial installations which convert one or more
commodity types into others. A typical example would be the conversion of
natural gas into heat, which is distributed across the site via a pipeline network
of superheated pressurized water. The costs for the conversion installation like
depreciation costs, operating costs and maintenance costs are assigned to
their cost center.
Distribution nodes are used to bundle all the sources of a single commodity
type and distribute the commodity among the other conversion, sink or
distribution nodes of the same type. Even when distribution nodes for the
same commodity type form a hierarchy, cost allocation is no problem as long
as all the distribution nodes of the same type have the same cost center.
Depreciation costs and maintenance costs for the distribution network on the site
can be assignedtotheircostcenter. Typicallythedistributionnodewillalsodealwith
lossesin the distribution network which represent a cost. These losses will be
distributed to the sink nodes according to their usage, ensuring these loss costs
will be assigned to the internal customers automatically.
For example a site converts natural gas and water into steam. This steam is
distributed over the site via a pipeline network. This pipeline network represents
an investment which is depreciated on a regular interval and will also require
maintenance. Pipes corrode and need replacing or valves break down and need
replacement as well. Tiny leaks in the pipeline network cause pressure drops
and represent losses. All these costs are addressed by the distribution node.
20

Sink nodes represent the internal customers in the company. These nodes have
cost centers assigned to them. The costs assigned to these cost centers will
- obviously - be the distributed costs from the other nodes based on the sink
node’s commodity consumption.
Selection of the reporting period
The second step is choosing a reporting period. It is typically based on the firm’s
overall financial reporting schedule and not determined by the requirements
of energy management. Monthly or quarterly reporting periods are therefore
common.
The result would look like the picture below. All costs and losses for the selected
period of time have been assigned to the nodes. They can now be used to
allocate all direct and indirect costs to the sink nodes.
Example graph based model with CHP and hot water conversions
Source node
Electricity grid
connection
Usage: 100
Gross
prod: 150
Loss: 0
Distribution node
Electricity
Usage: 90
Usage: 80
Sink node
Building product
line 1
Source node
Wind turbine
Usage: 140
Gross
prod: 50
Conversion node
Combined heat
power
Gross prod: 100
Usage: 80
Usage: 130
Sink node
Building product
line 2
Source node
Natural gas grid
connection
Usage: 300
Distribution node
Natural gas
Usage: 150
Conversion node
Hot water boilers
Conversion node
Hot water
Loss: 10
Usage: 100
Gross prod: 150
Loss: 10
Usage: 80
Source node
Water grid
connection
Usage: 200
Distribution node
Water
Loss: 50
Usage: 80
Sink node
Building product
line 3
Loss: 40
Loss: 10
Figure 5: Graph-based model example with usages and gross productions..
Distribution of commodity costs to internal
customers
For each reporting period the following steps will be taken:
1. Distribution of acquired commodity costs to internal customers,
2. Distribution of generated commodity costs to internal customers,
3. Distribution of converted commodity costs to internal customers,
4. Translation of converted commodity usages to primary commodity
usages,
5. Distribution of commodity usages to internal customers,
6. Total cost calculation per internal customer.
21

Step 1: Distribution of acquired commodity costs to internal customers
The acquired commodities like water, electricity and natural gas will have
contracts and monthly invoices which specify both the costs as well as the
usage for each billing period. By dividing the costs on the invoice by the usage
for each commodity a commodity unit cost is calculated for each invoice period.
For all commodity usages of acquired commodities the cost per period is
calculated by multiplying the usage by the unit cost.
Step 2: Distribution of generated commodity costs to internal customers
The generated commodities like electricity via wind or solar, will have similar
cost structures as the acquired commodity types. Depreciation costs, operating
costs and maintenance costs which fall within the current period are summed
and divided by the gross production within the same period. This yields an unit
cost for the generated commodity types.
For all commodity usages of generated commodities the cost per period is
calculated by multiplying the gross production by the unit cost.
Step 3: Distribution of converted commodity costs to internal customers
For the converted commodities, the cost structure is the same as for generated
commodities: depreciation costs, operating costs and maintenance costs. The
gross production is measured so the unit cost is as follows:
For all commodity usages of converted commodities the cost per period is
calculated by multiplying the gross production by the unit cost.
In addition to these costs, the input commodities for the conversion also bring
a cost. These will be calculated in the next step.
Step 4: Translation of converted commodity usages to primary commodity
usages
Due to the importance of monitoring the commodity conversion efficiencies,
the input commodity usages are measured directly and thus available for
calculations.
The costs associated with the input commodity flows of the conversion nodes
consist of the usage multiplied by the unit cost of the commodity.
Depending on the source of the input commodity flow, the unit cost is
22

associated with an acquired commodity, a generated commodity or a converted
commodity.
Step 5: Distribution of commodity usages to internal customers
Using the physical partitioning of the distribution nodes, both the usage and
cost are
distributed over the internal customers.
Step 6: Total cost calculation per internal customer
Internal customers, which are represented by sink nodes in the graph model,
use one or more commodities. The total cost for an internal customer is thus
found by the some of the cost of individual commodity types.
23

How to choose energy
management software
24

Not all companies have the same needs in terms energy management software.
The key question is how complex the relationship between measured energy
data, the process flow and the company structure, really is. This will determine
how difficult it is to map process flows, detect deviations or allocate energy
consumption to specific users, products or batches.
The guidelines below will help you select the right kind of software.
Do I need a graph-based metamodel in my
energy management software?
When your company is only acquiring commodities like natural gas, water and
electricity and it is not converting those into other commodities locally, a graphbased
model is not strictly necessary. Software using traditional hierarchical
metamodels can suffice. However, if you want to do cost allocation with the
energy management software a graph based model can ease the setup of such
an application.
For example in the model in figure 3, there are two conversion nodes: one CHP
and one hot water. This company would definitely profit from a graph based
metamodel in their energy software.
Do I need a versioned metamodel in my
energy management software?
Depending on the dynamics of your company, you may or may not need a
versioned metamodel. Suppose the largest time frame on which you report is
one year and the company structure - including sites, buildings and product
lines - is stable within the year, then no versioned model is needed.
If your company, however, launches two new products and builds two new
product lines during the year, then a versioned model with three versions may
be needed to report accurately over the year. The first version describes the
start of year situation. The second version the new situation after the opening
of the first new product line. Finally, the third version is needed after the
opening of the second new product line. The year reporting period will need to
be partitioned into three partitions where each version is valid. After reporting
on each partition, the final report will present the aggregation of the three
partitions. When only the latest version is available in the software in case of a
non-versioned metamodel, then no accurate report can be generated over the
year.
25

Condugo’s energy
allocation module
26

Condugo is a young company - founded in 2015 - offering comprehensive
energy management to industrial companies. At its core lies the modular
Energy Hub platform, with tools and dashboards for monitoring, analysing and
interpreting energy data.
The platform’s Energy Allocation module has been designed around two specific
models. The first one provides an accurate distribution key for all commodity
types present on the site of a company, especially when on-site conversions
come into play. The second one allocates full energy costs down to the level of
individual production batches.
Those models enable three types of analysis needed for advanced energy
management.
• Conversion efficiencies and deviation analysis
• Cost allocation from user down to batch level
• Energy allocation in constantly changing environments
The Energy Allocation module turns the power of those models and analyses
into a unique set of features :
• Each metamodel has been designed for and can be maintained by
energy managers. Any change from an energy point of view within the
organisation, is easily fed back into the model and instantly leads to
adjustments in the energy allocation.
• The module deals with any type of complexity. Smoothly handle any
change related to (metering) data, history, conversion of energy flows,
upgrading production installations, reconverting sites or corporate
restructuring.
• Built-in intelligence. A single datapoint can figure in different
configurations, belong to multiple processes or link to several key people
at once. This guarantees the right people get the right information and
reporting at the right time.
27

Co-creating the next
generation of energy
management software
28

Metamodels are starting to show up in energy management software, but only
reluctantly. The need for packages built around more advanced (graph-based,
versioned) models, however, is growing quickly. They are urgently needed as
indispensable tools for professional and comprehensive energy management
in complex industrial settings, whether the goal is steering consumption,
reducing costs or limiting emissions.
Condugo is building its Energy Hub platform to be this tool.
After 1,5 years of intensive development, grounded in cases of large and
extremely complex production sites with extensive needs for reporting and
cost allocation, the backbone of the software is operational. In addition, first
versions of its Monitoring and Reporting modules have successfully been
deployed with customers.
The next step is to implement the Energy Allocation module on the platform,
incorporating the models described in this white paper.
As we strongly believe in co-creation, we have done extensive work with one of
our customers to define and design the module. We are now moving towards
implementation and want to extend this co-creation effort to other industrial
companies as well.
That is why we call on other industrial companies to join us in this endeavour.
Do not hesitate to get in touch to discuss the options and build the next
generation of energy management software, together.
29

info@condugo.com
www.condugo.com