Embed Size (px)
Citation preview
Tutor: Mr Didier Marty-Dessus Supervisor: Mr Wassim Derguech
Evaluating the Energy Consumption
of Business Processes
Student: Mr Alexandre Teyar
Master 1 Internship - ERASMUS Program
Academic year: 2013-2014
1
Eva
lua
tin
g t
he
En
erg
y C
on
su
mp
tio
n o
f B
usin
ess P
roce
sse
s |
A
ca
de
mic
ye
ar:
20
13
-20
14
Acknowledgment:
On the very outset of this report, I would like to express my special gratitude and
thanks to Mr. Wassim Derguech who gave me the great opportunity to come to Ireland and
pursue my internship within the Grenn and Sustainable IT Unit in the Insight Centre for Data
Analytics, and for his guidance and constant supervision during the whole period of the
internship, also for his support in completing the project.
I express my profound and sincere thanks to Mr. Didier Marty-Dessus for his support.
I also extend my special thanks and gratitude to Mrs. Jackie Leroux for her
involvement in all my administrative issues.
I also acknowledge with deep sense of reverence, my gratitude towards my parents
and member of my family, who has always supported me.
At last but not least, my thanks and appreciations go to all the Insight@NUIG working
staff, who made me feel comfortable among them during my stay in the company.
Thanking You
2
Eva
lua
tin
g t
he
En
erg
y C
on
su
mp
tio
n o
f B
usin
ess P
roce
sse
s |
A
ca
de
mic
ye
ar:
20
13
-20
14
Abstract:
The consideration of ecological objectives has been identified as one of the major
topics for IS (Information Systems) research and Business Process Management (BPM). An
essential precondition for advancing the emerging discipline of Green BPM still is the
availability of methods and tools for detecting and matching the resource usage of a business
process to its individual steps.
In this report, we describe the design and implementation of a set of tools that will
allow the energy annotation and cost evaluation of business processes models. In this work,
we define our own vocabulary for the energy consumption description and we link our
software to this ontology in order to provide a powerful and standardised tool using the
semantic web technologies.
Furthermore, this prototype can be used to develop and validate effective methods for
creating energy-efficient business processes; indeed, increase the transparency of the energy
consumption (energy awareness) of business processes allows users to save energy.
Résumé:
La prise en compte des enjeux écologiques a été identifiée comme l'un des principaux
sujets de la recherche en SI (Système d’Informations) et Business Process Management
(BPM). ). Une précondition essentielle pour l’avancement de la discipline émergente qui est le
BPM « vert » est la disponibilité des méthodes et des outils pour détecter et faire correspondre
l'utilisation des ressources d'un business process à ses différentes étapes.
Dans ce rapport, nous décrivons la conception et la mise en œuvre d'un ensemble
d'outils qui permettra l'annotation énergétique et de l'évaluation des coûts des business
processes models. Dans ce travail, nous définissons notre propre vocabulaire pour la
description de la consommation énergétique et nous lions notre logiciel à cette ontologie afin
de fournir un outil puissant et standardisé utilisant les technologies du Web sémantique.
En outre, ce prototype peut être utilisé pour développer et valider des méthodes
efficaces pour créer des business processes économes en énergie, en effet, accroître la
transparence de la consommation d'énergie (sensibilisation à l'énergie) des business processes
permet aux utilisateurs d'économiser de l'énergie.
3
Eva
lua
tin
g t
he
En
erg
y C
on
su
mp
tio
n o
f B
usin
ess P
roce
sse
s |
A
ca
de
mic
ye
ar:
20
13
-20
14
Evaluating the Energy Consumption of Business Processes
SUMMARY
ACKNOWLEDGMENT ......................................................................................................... 1
ABSTRACT: ..................................................................................................................... 2
RESUME: ........................................................................................................................ 2
LIST OF FIGURES ............................................................................................................... 5
LIST OF TABLES ................................................................................................................ 6
1. INTRODUCTION ....................................................................................................... 7
1.1. MISSION AND HOSTING INSTITUTE ....................................................................... 7
1.2. CONTEXT, MOTIVATION AND REQUIREMENTS ........................................................ 8
1.2.1 WORKING CONTEXT .................................................................................. 8
1.2.2 MOTIVATION ............................................................................................ 9
1.2.3 PROBLEM STATEMENT................................................................................ 9
1.2.4 PROPOSED SOLUTION ............................................................................... 10
1.2.5 REQUIREMENTS ...................................................................................... 10
1.3. STRUCTURE OF THE REPORT ............................................................................. 11
2 BACKGROUND ...................................................................................................... 12
2.1 BUSINESS PROCESSES [5] ................................................................................. 12
2.2.1 BUSINESS PROCESS MODELLING LANGUAGES .............................................. 14
2.2.2 EVENT-DRIVEN PROCESS CHAINS ............................................................... 15
2.2 RESOURCE DESCRIPTION FRAMEWORK (RDF) [12] .............................................. 16
2.3 CONCLUSION ................................................................................................. 19
3. CONCEPTUALISATION ............................................................................................ 20
3.1 USE CASE DIAGRAM ........................................................................................ 20
3.2 ONTOLOGY FOR DESCRIBING AN ENERGY CONSUMPTION [18] ................................ 21
3.3 EPCTOOLS CLASS DIAGRAM ................................................................................. 24
3.4 MODIFIED EPCTOOLS CLASS DIAGRAM .................................................................... 25
4. DEVELOPMENT ..................................................................................................... 26
4.1 TECHNOLOGY CHOICES ................................................................................... 26
4.1.1 SWT LIBRARY ........................................................................................ 26
4.1.2 JENA LIBRARY ....................................................................................... 26
4.1.3 EPML ................................................................................................... 27
4.1.4 ECLIPSE ................................................................................................. 28
4.1.5 RESOURCE DESCRIPTION FRAMEWORK (RDF) – NOTATION 3 (N3) .................. 28
4.2 CHANGES TO EPCTOOLS ................................................................................. 29
4.2.1 ANNOTATION COMPONENT ....................................................................... 29
4.2.2 COST EVALUATION COMPONENT ................................................................ 31
4.3 CONCLUSION ................................................................................................. 32
5. TEST AND VALIDATION .......................................................................................... 33
5.1 CONTROLLED ANNOTATIONS (REQUIREMENT 1 AND 2) ......................................... 33
5.2 EASE OF THE USER INTERFACE (REQUIREMENT 3) ................................................ 34
4
Eva
lua
tin
g t
he
En
erg
y C
on
su
mp
tio
n o
f B
usin
ess P
roce
sse
s |
A
ca
de
mic
ye
ar:
20
13
-20
14
5.3 MULTI-LEVEL ENERGY COST EVALUATION (REQUIREMENT 4) ................................ 34
5.4 MULTI-INDICATOR ENERGY COST EVALUATION (REQUIREMENT 5) ......................... 34
5.5 CONCLUSION ................................................................................................. 35
6. CONCLUSION ....................................................................................................... 36
APPENDIX A: SAVING ENERGY CONSUMPTION IN EPML ........................................................... 38
APPENDIX B: USER GUIDE ............................................................................................... 40
1. INSTALL OF THE EPCTOOLS PLUG-IN .................................................................... 40
2. GEF INSTALLATION ........................................................................................... 40
3. INSTALLATION OF THE EPCTOOLS PLUG-IN ........................................................... 40
4. IMPORT AND COMPILE THE EPCTOOLS PROJECT (SOURCE PACKAGE) .......................... 40
5. TEST THE SELF-COMPILED PLUG-IN ....................................................................... 41
6. RUN THE EPCTOOLS EDITOR ............................................................................... 41
7. ENERGY ANNOTATION OF A BUSINESS PROCESS ...................................................... 43
8. SINGLE FUNCTION NODE COST EVALUATION .......................................................... 47
9. SUBPROCCES AND ENTIRE PROCESS BUSINESS PROCESS COST EVALUATION ................. 48
APPENDIX C: WORKING PLAN .......................................................................................... 51
BIBLIOGRAPHY............................................................................................................ 52
5
Eva
lua
tin
g t
he
En
erg
y C
on
su
mp
tio
n o
f B
usin
ess P
roce
sse
s |
A
ca
de
mic
ye
ar:
20
13
-20
14
List of Figures
Figure 1: Example of a Business Process Model for organising a trip ............................................. 8
Figure 2: Business Process Management lifecycle .................................................................... 13
Figure 3: EPC diagram Shapes .............................................................................................. 15
Figure 4 RDF Description .................................................................................................... 17
Figure 5 An RDF Graph Describing Eric Miller ....................................................................... 19
Figure 6: UML Use Cases Diagram ....................................................................................... 20
Figure 7 Diagram Class of the ontology .................................................................................. 24
Figure 8 EPCTools ............................................................................................................. 24
Figure 9 Modified EPCTools class diagram ............................................................................ 25
Figure 10 EPML file example ............................................................................................... 27
Figure 11 Structure of a RDF statement .................................................................................. 28
Figure 12 RDF N3 Vocabulary ............................................................................................. 34
Figure 13 EPML file ........................................................................................................... 38
Figure 14 Create a new EPC file............................................................................................ 41
Figure 15 A new empty EPC file ........................................................................................... 42
Figure 16 Resize, rename and delete an EPC component ........................................................... 43
Figure 17 Contextual menu showing "Energy Consumption" for annotating a function ................... 43
Figure 18 Empty Energy Consumption window ....................................................................... 44
Figure 19 Filled Energy Consumption window ........................................................................ 44
Figure 20 Domain Ontology File selection .............................................................................. 45
Figure 21 Wrong N3 syntax.................................................................................................. 45
Figure 22 Annotation form error............................................................................................ 46
Figure 23 Wrong ontology file path ....................................................................................... 47
Figure 24 Energy cost evaluation ........................................................................................... 48
Figure 25 Propagation GUI .................................................................................................. 48
Figure 26 Energy cost NULL ................................................................................................ 49
Figure 27 Business Process evaluation by Propagation .............................................................. 50
6
Eva
lua
tin
g t
he
En
erg
y C
on
su
mp
tio
n o
f B
usin
ess P
roce
sse
s |
A
ca
de
mic
ye
ar:
20
13
-20
14
List of Tables
Table 1: RDF classes for the Energy Vocabulary ............................................................................. 23
Table 2: RDF Properties for the Energy Vocabualry ........................................................................ 23
7
Eva
lua
tin
g t
he
En
erg
y C
on
su
mp
tio
n o
f B
usin
ess P
roce
sse
s |
A
ca
de
mic
ye
ar:
20
13
-20
14
1. Introduction
1.1. Mission and hosting institute
This internship takes place in Galway – Ireland at the Insight@NUIG institute
(previously known as DERI – Digital Enterprise Research Institute) which is among the
largest research organisations working in Semantic Web technologies.
My mission as an intern consists of designing and developing a tool for evaluating the
Energy Requirements and Impact of business processes using the semantic web technologies.
This tool should be integrated to a pre-existing open-source software called EPCTools that
will be introduced in details later in this report.
Insight@ NUI Galway [1]
The Insight Centre for Data Analytics was created to realise this vision. Insight is a
joint initiative between University College Dublin, the National University of Ireland at
Galway, University College Cork, and Dublin City University. Insight was established in
2013 by Science Foundation Ireland with funding of €75m.
At Insight we combine the skills of leading researchers with cutting-edge technologies
from diverse research areas. We work closely with industry partners to develop next-
generation data acquisition and analytics solutions for important and diverse application areas.
Insight brings together leading Irish academics from 5 of Ireland'�™s leading
research centres (DERI, CLARITY, CLIQUE, 4C, TRIL), previously established by Science
Foundation Ireland (SFI) and the Irish Industrial Development Authority (IDA), in key areas
of priority research including:
1. The Semantic Web,
2. Sensors and the Sensor Web,
3. Social network analysis,
4. Decision Support and Optimization, and
5. Connected Health.
8
Eva
lua
tin
g t
he
En
erg
y C
on
su
mp
tio
n o
f B
usin
ess P
roce
sse
s |
A
ca
de
mic
ye
ar:
20
13
-20
14
Collectively these centres represent an investment in excess of €150m over the past 10
years, hosting more than 300 researchers, and collaborating with more than 150 industry
partners. In bringing together these Centres, through the SFI funded Research Centres
call, Insight will become a single brand and single entity with the critical mass of research
competence that will serve as an international beacon for the science and application of Big
Data Analytics. The Insight Centre is designed to provide a national ICT research platform for
Ireland based on world-class targeted research programmes.
1.2. Context, motivation and requirements
1.2.1 Working Context
A business process is a set of ordered activities coordinated by either people or
machines intended to reach a business goal [2] in order to provide a service or a product for
the client’s needs. Business Process Management (BPM) is the approach to manage the
business process life cycle from a business expert’s point of view rather than from a technical
perspective.
A business process model based on EPCTools is designed this way, the lozenges
represent the events, the rectangles represent the functions and the rounds represent the
rooting nodes (“AND”, “XOR” and “OR”) this report will provide further details about the
EPCTools model schema on the section 2.1.1.
The example depicted in Figure 1 shows a, EPC business process model for organising
a trip: the user first has to select a destination and then to book a flight “AND” a hotel.
FIGURE 1: EXAMPLE OF A BUSINESS PROCESS MODEL FOR ORGANISING A TRIP
9
Eva
lua
tin
g t
he
En
erg
y C
on
su
mp
tio
n o
f B
usin
ess P
roce
sse
s |
A
ca
de
mic
ye
ar:
20
13
-20
14
1.2.2 Motivation
Increasing energy costs and the trend towards green energy has given rise to a
renewed focus on energy management.
Energy consumption is set to become one of the most significant cost factors for many
data centers in the near future. In 2010, Google estimated that the operation of its data centers
used around 2.26 billion kilowatt hours of electricity [3]. According to a study by the Global
e-Sustainability Initiative (GeSI), however, Information and communications technology
(ICT) solutions can help other industries to dramatically reduce their CO2 emissions by 2020
[3].
Various solutions can be adapted for reducing energy consumption of current business
processes. As example, video conferencing can drastically reduce energy costs compared to
physical conference attendance. Indeed, Cloud computing, low-energy hardware or
substituting time and cost-intensive business trips with video conferencing can substantially
reduce energy consumption. Cloud computing based on virtualization technologies and high-
level standardization reduce data centers’ electricity consumption by up to 80 percent. Using
thin clients consumes only around 0.08 kWh per day per computer, slashing CO2 emissions
by 54 percent. And video conferences reduce travel-related CO2 output by 10 percent [3].
According to the Global Sustainability Initiative’s Smart 2020 report [3], ICT
solutions that boost energy efficiency have the potential to deliver savings of some 600 billion
euros. Energy-intensive industries have the most to gain, because their electricity bills can be
as much as six percent of gross production value.
A major step towards reducing energy consumption in business domains consists
of understanding how much energy does the current processes require for achieving a
particular business goal.
1.2.3 Problem statement
The problem that we are dealing with in this context is twofold:
First, current ICT solutions for the monitoring of the energy consumption of the
business processes lack of data to exactly describe what energy is made of and how to
represent energy sources and consumption. Indeed, there is no standard conceptual model for
describing various aspects of the energy sources and consumptions and linking it to business
processes.
Second, most of the business processes modelling languages focus more on describing
the functional aspect [4] of tasks rather than energy consumption.
10
Eva
lua
tin
g t
he
En
erg
y C
on
su
mp
tio
n o
f B
usin
ess P
roce
sse
s |
A
ca
de
mic
ye
ar:
20
13
-20
14
In such context, there is a need to define a complete conceptual model for
describing energy consumptions and design a tool for integrating such annotation in
business process models.
1.2.4 Proposed solution
This work presents our solution towards an efficient use of energy within business
processes by increasing energy awareness. Energy-awareness is given by an enrichment of a
typical Business Process conceptual model with annotations able to support the assessment of
the energy consumption of the involved business tasks.
We propose in this work to design a vocabulary for describing energy consumptions
as well as the required tool support for annotating business processes with their energy
consumption.
In our proposed solution, we are mainly interested in the energy annotation of the
functions occurring during a business process life cycle, these annotations will be made using
a semantic web language – Resource Description Framework (RDF) in order to obtain a
unified global language for the representation of the energy consumption data that can be used
and modified without any attached explanation of our energy consumption modelling (further
information is given in section 2).
Moreover, in addition of the calculation of the carbon footprint (CO2 emission) the
energy consumption will be given with the cost equivalent in currency, the water consumption
and the landfill wastes because we want to provide a simple and complete tool which can be
used by professionals as well as particulars to make them aware of the environmental impact
of business processes.
1.2.5 Requirements
Annotation Requirements:
1. Controlled annotation: [Requirement 1]
The business process annotation must be controlled to avoid incomplete or
incorrect annotation (e.g. insertion of a wrong type of value or forgetting the
unit of measurement selection). The control settings are defined in domain
ontology.
2. Predefined units of measurement: [Requirement 2]
The units of measurement associated to an energy source are defined in the
domain ontology to avoid misunderstanding and cover multiple units.
3. Easy to use Interface: [Requirement 3]
11
Eva
lua
tin
g t
he
En
erg
y C
on
su
mp
tio
n o
f B
usin
ess P
roce
sse
s |
A
ca
de
mic
ye
ar:
20
13
-20
14
The Graphic User Interface (GUI) must be clear, simple and ergonomic; a label
must be associated to every field to facilitate the understanding of the GUI.
Cost of energy Requirements:
1. Multi-level energy cost evaluation: [Requirement 4]
The evaluation of the energy cost can operate at different levels. That can be an
energy cost evaluation for a single business process task, for a sub process or
for an entire business process.
2. Multi-indicator energy cost evaluation: [Requirement 5]
The evaluation process of energy consumption provides multiple indicators
such as the cost in currency, the CO2 emission, the water consumption and the
landfill waste resulting from the energy used.
1.3. Structure of the report
The rest of the report is organized as follows:
Background (Section 2) - builds the background knowledge required for the
Conceptualisation and Development.
Conceptualisation (Section 3) - constitutes the design of our prototype for the energy
annotation of business process. It presents the data format of our conceptual model and our
RDF vocabulary.
Development (Section 4) - provides technology choices and some useful details about
the extended EPCTools prototype.
Test and Validation (Section 5) – evaluates the developed prototype with respect to the
functional requirements provided at the beginning.
Conclusion (Section 6) - conclude the report; general conclusions are drawn and some
perspectives are defined as future cornerstones to enrich this work.
The report also includes 3 Appendixes:
Appendix A: Saving Energy Consumption in EPMLDescribes the epml data
format used in this work.
Appendix B: User GuideConstitutes a user guide for the developed prototype.
Appendix C: Working PlanReports on our working plan for achieving this
internship.
12
Eva
lua
tin
g t
he
En
erg
y C
on
su
mp
tio
n o
f B
usin
ess P
roce
sse
s |
A
ca
de
mic
ye
ar:
20
13
-20
14
2 Background
This background section reviews the main concepts related to the design and
development phases. We start by an overview of the business processes. Then, we define
some business process modelling languages that we used in our work: with a focus on Event-
driven Process Chains (EPC). Finally, we take a look on RDF.
2.1 Business processes [5]
A business process is a series of activities occurring within a company that lead to a
specific end. Most often, it focuses on meeting the needs of the customer and delivering a
good or service that will fulfil that need. This process is actually often a collection of
interrelated processes that function in a logical sequence to achieve the ultimate goal [5].
Defining the exact steps of a business process will vary somewhat from one corporate
structure to another, but there are some elements or sub-processes that can be found in most.
This is actually done during the modelling phase of the BPM lifecycle. Indeed, BPM defines a
four phase’s lifecycle for managing business processes [2] as depicted in Figure 2:
Modelling: During the modelling phase, the business expert models a business
process from a business perspective using a business process modelling language.
The business process model represents an important knowledge artefact in the
enterprise life cycle as it captures best practices of how to achieve the business
functionality of an enterprise.
Implementation: During the implementation phase, the business process is getting
prepared for execution; the business-view model is mapped to the IT model which
will be ready for deployment and execution.
Execution: During the execution phase, the business process is deployed and
executed.
Analysis: During the analysis phase, the executed business processes are analysed
for their continuous improvement.
This work mainly focuses on the first phase of a BPM (modelling).
13
Eva
lua
tin
g t
he
En
erg
y C
on
su
mp
tio
n o
f B
usin
ess P
roce
sse
s |
A
ca
de
mic
ye
ar:
20
13
-20
14
FIGURE 2: BUSINESS PROCESS MANAGEMENT LIFECYCLE
In the following, we describe a manufacturing business process split into 5 steps [5]:
The first step normally has to do with the acquisition of raw materials for the business
operation. In order to maximize the benefit from them, efforts are made to secure materials of
the highest quality at the most cost efficient price. Doing so increases the chance of achieving
a higher amount of profit for each unit produced and sold.
Following the acquisition step, the process will move on to the structure and efficiency
of the production structure. Here, the organization of the plant facility in order to allow raw
materials to be processed with the greatest degree of efficiency becomes paramount. This is
coupled with attention to such factors as employee training, setting reasonable production
goals, and establishing a workable maintenance program for the production machinery.
The next step focuses on the sales and marketing effort. While it is established early
on that the final product will be of value to consumers, it is often necessary to develop and
implement creative strategies for making buyers aware of the product. As part of this effort,
public relations, advertising efforts, and the establishment of a simple means of placing orders
will often help to secure customers who are ready and willing to buy the produced products.
Once the goods are produced and sold, the final step of the business process has to do
with delivery to the client. This portion of the process includes such elements as processing
orders in a timely manner, advising the client of the scheduled delivery date, and making sure
that date is met. On the back end, the delivery process also has to do with obtaining feedback
from the customer regarding their level of satisfaction with the product and the efficiency of
the physical delivery.
14
Eva
lua
tin
g t
he
En
erg
y C
on
su
mp
tio
n o
f B
usin
ess P
roce
sse
s |
A
ca
de
mic
ye
ar:
20
13
-20
14
Depending on the nature of the industry involved, orders from clients may be secured
before the actual process of production begins. Many companies operate with a business
process that allows for the production of goods in anticipation of sales to consumers,
however.
The important required element for describing these steps is the business process
modelling language. The literature proposed various languages either from industry or
academia; the following section describes some them.
2.2.1 Business Process Modelling Languages
Over the last decade more and more companies began the optimization of their
business processes in order to achieve its business objectives. They implement business
process models to determine which activities have to be executed in which order under which
conditions by whom and by using which resources. In order to achieve this purpose several
approaches to business process modelling have been developed, which led to the apparition of
many different Business Process Modelling Languages [6].
The goal of developing Business process languages was to enable practitioners to
describe the flow of business process in a consistent manner. In combination with a toolset,
they provide a way for easily drawing process models [7]. Usually, the toolsets allow
annotating the process models with additional details like resources or data requirements, as
well as they provide some basic methods for analysing the models. There are several kinds of
notations such as:
• Business process Modelling Notation (BPMN) that was developed with the goal to
form a common standard notation for business process modelling. BPMN was designed with
the specific aim to enable in one hand business users, in the other hand technical developers to
model easily comprehensible graphical representations of business processes. In this way,
BPMN reuses typical elements of flowcharting techniques, e.g. rounded rectangles and
diamonds, which are familiar to most modellers [8].
• Another example of process modelling language is UML Activity Diagrams (UML
ADs), which is part of the Unified Modelling Language (UML). UML is a visual, object-
oriented and multipurpose modelling language which offers a variety of notations to capture
different aspects of software structure and behaviour [8]. The Object Management Group
(OMG) consortium standardized UML.
• In our work we will focus on the Event-driven Process chains notation (EPCs).
These last were developed in an academic environment, nowadays they are supported by
15
Eva
lua
tin
g t
he
En
erg
y C
on
su
mp
tio
n o
f B
usin
ess P
roce
sse
s |
A
ca
de
mic
ye
ar:
20
13
-20
14
various popular tools as Microsoft Visio or ARIS from IDS Scheer. In the following we
will give more details about EPCs.
2.2.2 Event-driven Process Chains
An Event-driven Process Chain (EPC) is a type of flowchart used for business process
modelling. Event-driven Process Chains can be used for configuring an enterprise resource
planning (ERP) implementation, [9] and for business process improvement.
The Event-driven Process Chain method was developed within the framework of
Architecture of Integrated Information Systems (ARIS) by August-Wilhelm Scheer at the
Institut für Wirtschaftsinformatik at the Universität des Saarlandes in the early 1990s [10].
FIGURE 3: EPC DIAGRAM SHAPES
Businesses use Event-driven Process Chain diagrams to lay out business process work
flows, originally in conjunction with SAP R/3 modelling, but now more widely. It is used by
many companies for modelling, analysing, and redesigning business processes. EPC forms the
core technique for modelling in ARIS, which serves to link the different views in the so-called
control view. To quote from a 2006 publication on Event-driven Process Chains: [11]
16
Eva
lua
tin
g t
he
En
erg
y C
on
su
mp
tio
n o
f B
usin
ess P
roce
sse
s |
A
ca
de
mic
ye
ar:
20
13
-20
14
“An Event-driven Process Chain (EPC) is an ordered graph of events and functions. It
provides various connectors that allow alternative and parallel execution of
processes. Furthermore it is specified by the usages of logical operators, such as OR,
AND, and XOR. A major strength of EPC is claimed to be its simplicity and easy-to-
understand notation. This makes EPC a widely acceptable technique to denote
business processes.” [11].
Figure 1 shows an example of EPC, in here the activities are represented as rectangles
and event as lozenges and gateways as circles, the rest of shapes required for modelling an
entire business process in EPC is shown in Figure 3.
2.2 Resource Description Framework (RDF) [12]
The Resource Description Framework (RDF), developed under the auspices of the
World Wide Web Consortium (W3C) [13]http://www.dlib.org/dlib/may98/miller/05miller.html -
W3C, is an infrastructure that enables the encoding, exchange, and reuse of structured
metadata. This infrastructure enables metadata interoperability through the design of
mechanisms that support common conventions of semantics, syntax, and structure. RDF does
not stipulate semantics for each resource description community, but rather provides the
ability for these communities to define metadata elements as needed. RDF uses XML
(eXtensible Markup Language) as a common syntax for the exchange and processing of
metadata. RDF supports the use of conventions that will facilitate modular interoperability
among separate metadata element sets. These conventions include standard mechanisms for
representing semantics that are grounded in a simple, yet powerful, data model discussed
below. RDF additionally provides a means for publishing both human-readable and machine-
processable vocabularies. Vocabularies are the set of properties, or metadata elements,
defined by resource description communities.
The ability to standardize the declaration of vocabularies is anticipated to encourage
the reuse and extension of semantics among disparate information communities. For example,
the Dublin Core Initiative [14], an international resource description community focusing on
simple resource description for discovery, has adopted RDF [15]. Educom's IMS Instructional
Metadata System [16], designed to provide access to educational materials, has adopted the
Dublin Core and corresponding architecture and extended it with domain-specific semantics.
RDF is designed to support this type of semantic modularity by creating an infrastructure that
supports the combination of distributed attribute registries. Thus, a central registry is not
17
Eva
lua
tin
g t
he
En
erg
y C
on
su
mp
tio
n o
f B
usin
ess P
roce
sse
s |
A
ca
de
mic
ye
ar:
20
13
-20
14
required. This permits communities to declare vocabularies which may be reused, extended
and/or refined to address application or domain specific descriptive requirements.
2.2.1 The RDF Data Model [12]
RDF provides a model for describing resources. Resources have properties (attributes
or characteristics). RDF defines a resource as any object that is uniquely identifiable by a
Uniform Resource Identifier (URI). The properties associated with resources are identified by
property-types, and property-types have corresponding values. Property-types express the
relationships of values associated with resources. In RDF, values may be atomic in nature
(text strings, numbers, etc.) or other resources, which in turn may have their own properties.
A collection of these properties that refers to the same resource is called a description. At the
core of RDF is a syntax-independent model for representing resources and their
corresponding descriptions. Figure 4 illustrates a generic RDF description.
FIGURE 4 RDF DESCRIPTION
The RDF data model operates at the lowest level which is the conceptualisation phase,
then on a higher level this data must be serialized, formatted, in the following we will see the
main serialization formats in use.
2.2.2 The RDF Syntax [17]
Several common serialization formats are in use, including:
Turtle, a compact, human-friendly format.
N-Triples, a very simple, easy-to-parse, line-based format that is not as compact as
Turtle.
N-Quads, a superset of N-Triples, for serializing multiple RDF graphs.
JSON-LD, a JSON-based serialization.
N3 or Notation 3, a non-standard serialization that is very similar to Turtle, but has
some additional features, such as the ability to define inference rules.
RDF/XML, an XML-based syntax that was the first standard format for serializing
RDF.
18
Eva
lua
tin
g t
he
En
erg
y C
on
su
mp
tio
n o
f B
usin
ess P
roce
sse
s |
A
ca
de
mic
ye
ar:
20
13
-20
14
Each of these formats follows its own rules and standards.
RDF/XML is sometimes misleadingly called simply RDF because it was introduced
among the other W3C specifications defining RDF and it was historically the first W3C
standard RDF serialization format. However, it is important to distinguish the RDF/XML
format from the abstract RDF model itself. Although the RDF/XML format is still in use,
other RDF serializations are now preferred by many RDF users, both because they are more
human-friendly, and because some RDF graphs are not representable in RDF/XML due to
restrictions on the syntax of XML QNames.
2.2.3 RDF Example
The following example in Figure 5 is taken from the W3C website [13] describing a
resource with statements "there is a Person identified by
http://www.w3.org/People/EM/contact#me, whose name is Eric Miller, whose email address
is [email protected], and whose title is Dr.
The resource "http://www.w3.org/People/EM/contact#me" is the subject.
The objects are:
"Eric Miller" (with a predicate "whose name is"),
mailto:[email protected] (with a predicate "whose email address is"), and
"Dr." (with a predicate "whose title is").
The subject is a URI.
The predicates also have URIs. For example, the URI for each predicate:
"whose name is" is http://www.w3.org/2000/10/swap/pim/contact#fullName,
"whose email address is" is
http://www.w3.org/2000/10/swap/pim/contact#mailbox,
"whose title is" is http://www.w3.org/2000/10/swap/pim/contact#personalTitle.
In addition, the subject has a type (with URI http://www.w3.org/1999/02/22-rdf-
syntax-ns#type), which is person (with URI
http://www.w3.org/2000/10/swap/pim/contact#Person).
Therefore, the following "subject, predicate, object" RDF triples can be expressed:
http://www.w3.org/People/EM/contact#me,
http://www.w3.org/2000/10/swap/pim/contact#fullName, "Eric Miller"
http://www.w3.org/People/EM/contact#me,
http://www.w3.org/2000/10/swap/pim/contact#mailbox, mailto:[email protected]
http://www.w3.org/People/EM/contact#me,
http://www.w3.org/2000/10/swap/pim/contact#personalTitle, "Dr."
19
Eva
lua
tin
g t
he
En
erg
y C
on
su
mp
tio
n o
f B
usin
ess P
roce
sse
s |
A
ca
de
mic
ye
ar:
20
13
-20
14
http://www.w3.org/People/EM/contact#me, http://www.w3.org/1999/02/22-
rdf-syntax-ns#type, http://www.w3.org/2000/10/swap/pim/contact#Person
FIGURE 5 AN RDF GRAPH DESCRIBING ERIC MILLER
2.3 Conclusion
Recall, our objective is to annotate business process models with their energy
consumptions. To do so we will focus our work on EPC based models, however the actual
state of EPC Markup Language (EPML further details page 38) and EPC does not allow us to
annotate the energy consumption moreover there is a real need in a vocabulary to describe the
business processes energy consumption; we will use RDF to create this new vocabulary;
finally, we will provide the necessary tool to annotate business process models in a user
friendly way (i.e., no need to understand or create RDF data).
20
Eva
lua
tin
g t
he
En
erg
y C
on
su
mp
tio
n o
f B
usin
ess P
roce
sse
s |
A
ca
de
mic
ye
ar:
20
13
-20
14
3. Conceptualisation
3.1 Use case diagram
FIGURE 6: UML USE CASES DIAGRAM
Annotate energy consumption: A user can define the energy sources that a task
needs (e.g., paper, electricity, etc.) as well as their respective values (including units of
measurement).
o Import domain ontology:
The system can import a defined ontology to set the energy sources, values and
unit of measurements of a task.
o Define energy source and value:
The user can annotate a task with different energy sources, values and units of
measurement.
21
Eva
lua
tin
g t
he
En
erg
y C
on
su
mp
tio
n o
f B
usin
ess P
roce
sse
s |
A
ca
de
mic
ye
ar:
20
13
-20
14
o Save annotation:
The user can save the annotated task with its corresponding energy sources,
values and units of measurement in a proper format (to be defined later in
Section 2.2).
o Load existing annotation:
The system load a previously annotated task with its corresponding energy
sources, values and units of measurement.
o Remove annotation:
The user can delete an existing task’s annotation.
Evaluate energy cost: A user can evaluate the energy consumption of a task, sub
process or entire process.
o Evaluate energy cost of a task:
A user can evaluate the cost, CO2 emission, water consumption and landfill
waste of a task.
o Evaluate energy cost of a sub process:
A user can evaluate the cost, CO2 emission, water consumption and landfill
waste of a sub process.
o Evaluate energy cost of an entire process:
A user can evaluate the cost, CO2 emission, water consumption and landfill
waste of an entire process.
3.2 Ontology for describing an energy consumption [18]
In this part of the report we will focus on how to build an ontology for an energy
consumption. Our starting point in doing so is to think about the concepts and relationships
which are the most relevant to describe the energy consumption of business process.
Domain ontologies have large number of domain specific concepts and rich
relationships between these concepts. Various approaches of ontology design have been
proposed by researchers. We follow the methodology proposed by Uschold and Gruninger to
define ontology. Their methodology is consists of following three phases.
A. Brainstorming: Have brainstorming session to identify all potential concepts and
phrases in the domain of interest.
B. Grouping: Structure the terms into provisional categories.
C. Refine the grouping and identify the semantic cross-reference between areas.
22
Eva
lua
tin
g t
he
En
erg
y C
on
su
mp
tio
n o
f B
usin
ess P
roce
sse
s |
A
ca
de
mic
ye
ar:
20
13
-20
14
To our knowledge there is no effort exists in literature to implement the energy
consumption of business process.
The ontology encodes an energy consumption (EnergyConsumption) with its source
(EnergySource), amount (ConsumptionAmount), price (ConsumedEnergyPrice) (with its
corresponding currency) and CO2 emission (CO2Emission).
This modelling is not the only one possibility. In our conception of what is a business
process, a task can be either an AtomicTask (single task) or a ProcessModel (combination of
several task), in any case each task has its own Capability (refer to the work accomplished by
Arslane Chaouche the last year) and its own EnergyConsumption.
Ontological modellers in different domains may represent same concepts and entities
in real world using different terminologies which are not supposed to occur, but this kind of
modelling flexibility results in limited or no interoperability of vocabularies. In order to
address the challenges of interoperability a domain independent ontology that acts an abstract
layer on top of domains ontologies is needed which ties together individual domain
ontologies. PEN is domain independent ontology that addresses the challenge of knowledge
sharing between various information or knowledge based systems.
The aim of complying our proposed ontology with PEN is to allow knowledge sharing
and information retrieval by making use of generic structure and concepts provided by PEN.
PEN is upper level, domain-independent ontology which provides a framework by which
disparate systems can utilize a common knowledge base and from which more domain-
specific ontologies can be derived. PEN supports metadata interoperability that allows the
knowledge sharing of the proposed ontology with other PEN compliant ontologies.
The modelling example context is the organisation of a travel.
The PEN ontology:
http://vocab.deri.ie/pen#
The PEN ontology was created by merging publicly available ontological contents
into a single, comprehensive structure.
http://www.w3.org/1999/02/22-rdf-syntax-ns#
http://www.w3.org/2000/01/rdf-schema#
http://purl.oclc.org/NET/muo/muo#
http://www.w3.org/2001/XMLSchema#
http://vocab.deri.ie/bp#
23
Eva
lua
tin
g t
he
En
erg
y C
on
su
mp
tio
n o
f B
usin
ess P
roce
sse
s |
A
ca
de
mic
ye
ar:
20
13
-20
14
TABLE 1: RDF CLASSES FOR THE ENERGY VOCABULARY
Classes Description
ENERGYCONSUMPTION: The energy consumed.
ENERGYSOURCE: The energy's source.
CONSUMPTIONAMOUNT: The energy's consumption amount.
CONSUMEDENERGYPRICE: The energy's price equivalent.
CURRENCY: The price's currency
CO2EMISSION: The CO2’s emission.
TABLE 2: RDF PROPERTIES FOR THE ENERGY VOCABUALRY
RELATIONS Sub
Relations
PARENTS CHILD
CONSUMES BP:TASK ENERGYCONSUMPTION
HASSOURCE ENERGYCONSUMPTION ENERGYSOURCE
HASAMOUNT ENERGYCONSUMPTION ENERGYSOURCE
HASVALUE CONSUMPTIONAMOUNT XSD:DOUBLE
HASUNIT
CONSUMPTIONAMOUNT MUO:UNITOFMEASUREMENT
HASPRICE ENERGYCONSUMPTION CONSUMEDENERGYPRICE
HASVALUE CONSUMPTIONAMOUNT XSD:DOUBLE
HASUNIT CONSUMPTIONAMOUNT CURRENCY
HASCO2EMISSION ENERGYCONSUMPTION CO2EMISSION
HASVALUE CO2EMISSION XSD:DOUBLE
HASUNIT CO2EMISSION XSD:STRING
24
Eva
lua
tin
g t
he
En
erg
y C
on
su
mp
tio
n o
f B
usin
ess P
roce
sse
s |
A
ca
de
mic
ye
ar:
20
13
-20
14
Figure 7 shows another view of our ontology architecture.
FIGURE 7 DIAGRAM CLASS OF THE ONTOLOGY
3.3 EPCTools class diagram
The original UML class diagram of EPCTools is illustrated in Figure 8. It represents
the main components of EPC: node, FunctionItem, EventItem, etc… The changes required to
do on this model consist of adding the energy description option to the FunctionITem that will
be described in the following section.
FIGURE 8 EPCTOOLS
25
Eva
lua
tin
g t
he
En
erg
y C
on
su
mp
tio
n o
f B
usin
ess P
roce
sse
s |
A
ca
de
mic
ye
ar:
20
13
-20
14
3.4 Modified EPCTools class diagram
After the introducing of the original EPCTools UML class diagram, here we present its
extended version. This version permits to conceptually representing the required classes and
modifications to support the use cases given as functional requirements. This version allows
the conceptualisation of an energy consumption by attributing to each function a composition
of energy.
The adjustment that we did in the diagram helps implementing for each function its
energy consumption. Changes are made on the FunctionItem class by adding an attribute that
will help to interoperate with the RDF energy description that the users will have to set
through the software.
The modified UML class diagram is depicted in Figure 9.
FIGURE 9 MODIFIED EPCTOOLS CLASS DIAGRAM
26
Eva
lua
tin
g t
he
En
erg
y C
on
su
mp
tio
n o
f B
usin
ess P
roce
sse
s |
A
ca
de
mic
ye
ar:
20
13
-20
14
4. Development
4.1 Technology choices
We used the following technologies, the choices was highly led by the fact that we are
working on EPCTools which is an eclipse plugin:
4.1.1 SWT library
The Standard Widget Toolkit (SWT) is a graphical widget toolkit for use with the Java
platform. It was originally developed by Stephen Northover at IBM and is now maintained by
the Eclipse Foundation in tandem with the Eclipse IDE. It is an alternative to the Abstract
Window Toolkit (AWT) and Swing Java GUI toolkits provided by Sun Microsystems as part
of the Java Platform, Standard Edition.
To display GUI elements, the SWT implementation accesses the native GUI libraries
of the operating system using JNI (Java Native Interface) in a manner that is similar to those
programs written using operating system-specific APIs. Programs that call SWT are portable,
but the implementation of the toolkit, despite part of it being written in Java, is unique for
each platform.
The toolkit is licensed under the Eclipse Public License, an open source license
approved by the Open Source Initiative.http://en.wikipedia.org/wiki/Standard_Widget_Toolkit -
cite_note-1
We used the SWT library to implement the Graphic User Interface (GUI) of our
software.
4.1.2 JENA library
27
Eva
lua
tin
g t
he
En
erg
y C
on
su
mp
tio
n o
f B
usin
ess P
roce
sse
s |
A
ca
de
mic
ye
ar:
20
13
-20
14
Jena is an open source Semantic Web framework for Java. It provides an API to
extract data from and write to RDF graphs. The graphs are represented as an abstract "model".
A model can be sourced with data from files, databases, URLs or a combination of these. A
Model can also be queried through SPARQL and updated through SPARUL.
Jena is similar to Sesame; though, unlike Sesame, Jena provides support for OWL
(Web Ontology Language). The framework has various internal reasoners and the Pellet
reasoner (an open source Java OWL-DL reasoner) can be set up to work in Jena.
Jena supports serialisation of RDF graphs to:
o a relational database
o RDF/XML
o Turtle
o Notation 3
We used the Jena library to facilitate the programming work because the Jena library
provides Java functions to interact with RDF models and statements.
4.1.3 EPML
EPC Markup Language (EPML) is motivated by the goal of supporting data and
model interchange in the face of heterogeneous Business Process Modelling tools. The chief
design principles in EPC Markup Language are readability, extensibility, tool orientation, and
syntactic correctness. Our EPC models are write in EPML language, this language is defines
an XML schema for representing EPC models. Figure 10 illustrates an example of EPML file.
FIGURE 10 EPML FILE EXAMPLE
28
Eva
lua
tin
g t
he
En
erg
y C
on
su
mp
tio
n o
f B
usin
ess P
roce
sse
s |
A
ca
de
mic
ye
ar:
20
13
-20
14
4.1.4 Eclipse
Eclipse is an integrated development environment (IDE). It contains a base workspace
and an extensible plug-in system for customizing the environment. Written mostly in Java,
Eclipse can be used to develop applications.
Released under the terms of the Eclipse Public License, Eclipse SDK is free and open
source software (although it is incompatible with the GNU General Public License). It was
one of the first IDEs to run under GNU Classpath and it runs without problems under
IcedTea.
We decided to work with Eclipse as an IDE because EPCTools is an Eclipse’s plugin.
4.1.5 Resource Description Framework (RDF) – Notation 3
(N3)
The Resource Description Framework (RDF) provides a uniform data model and
syntax to represent structured data. RDF allows asserting statements about resources
identified via URIs. The RDF model encodes data in the form of subject, predicate, object
triples. The predicate, represented by a URI, specifies how the subject and object are related.
A predicate can relate a resource to a literal specifying an attribute in terms of Object-
Oriented Programming or it can relate two resources specifying a relation between them.
FIGURE 11 STRUCTURE OF A RDF STATEMENT
29
Eva
lua
tin
g t
he
En
erg
y C
on
su
mp
tio
n o
f B
usin
ess P
roce
sse
s |
A
ca
de
mic
ye
ar:
20
13
-20
14
For example, an RDF triple can state that person A, identified by a URI, and has the
literal “Richard” as his name. Similarly person A may relate to a city D, also identified by a
URI, by the fact that A lives in D (see Figure 11). In our work we used RDF for representing
energies consumption and their related vocabularies.
The vocabularies that we used were previously defined within the Service Oriented.
Notation3, or N3 as it is more commonly known, is a shorthand non-XML
serialization of Resource Description Framework models, designed with human-readability in
mind: N3 is much more compact and readable than XML RDF notation. The format is being
developed by Tim Berners-Lee and others from the Semantic Web community. A
formalization of the logic underlying N3 was published by Berners-Lee and others in 2008.
N3 has several features that go beyond a serialization for RDF models, such as support
for RDF-based rules. Turtle is a simplified, RDF-only subset of N3.
Architecture in DERI:
o A capability Meta model available at: http://vocab.deri.ie/cap
o An Action Verb schema available at: http://vocab.deri.ie/av
o Import processes Actions ontology available at:
http://vocab.deri.ie/imp
o Import capabilities domain ontology available at:
http://vocab.deri.ie/impc
4.2 Changes to EPCTools
This section reports on the changes that we made to EPCTools for covering the
functional requirements introduced in section 1.2.5 and discussed in section 3.1.
4.2.1 Annotation component
In order to add the energy annotation feature to EPCTools; we have implemented our
own java classes as well as added/changed the pre-existing EPCTools java classes/functions.
We can consider the development of the energy annotation functionality of EPCTools
in three mains steps:
First, we have created two new classes:
30
Eva
lua
tin
g t
he
En
erg
y C
on
su
mp
tio
n o
f B
usin
ess P
roce
sse
s |
A
ca
de
mic
ye
ar:
20
13
-20
14
o The Energy class which actually contains the exact description of energy
according to our RDF model (see Section 3.2 for further details).
o The PEn class which is a helper class to automate the RDF N3 models
creation (we use these RDF models to save the energy consumption of
each function in an .epml file (refer to Appendix A: Saving Energy
Consumption in EPML for further information)).
Second, we bounded the energy annotation Graphic User Interface to the save file
(.epml file), that leads to two possible cases:
o If the selected function has not been annotated before; the annotation
window will be filled only with the extracted information from the loaded
ontology file (see Section 7 of Appendix B: User Guide).
o Else, the information used to fill the energy annotation GUI is extracted
from the EPML file (this file contains instances of energy consumption as
described in our vocabulary using RDF N3 syntax and (see Section 3.2).
To manage these two cases we created some new classes as the EnergyGUI class
located in the file EPCToolsEditor.java to be able to create new dedicated interfaces for the
energy annotations and to interact with the ontology file or the EPML file to extract all the
required information to fill our GUI with the pre-existing annotations or to start a new
annotation from scratch.
Third, to save the user annotation of a function we generate an RDF N3 model
using the Pen class (to generate an instance of an energy consumption) and the Foo
helper class (to convert the information from the GUI to concrete information that
can be used in the Energy class (for instance to convert a label in an integer)). The
Foo helper class was added in the EPCToolsEditor.java file.
The generated N3 description of the energy consumption of the function is then stored
in the EPML file associated to his functions thanks to a unique identifier for the function. We
also made changes to the EPCToolsXML.java file, more precisely to the saving function
which generates the .epml saving file to add the energy consumption of the function between
the tags <energyConsumption> and </energyConsumption> (see Appendix A: Saving Energy
Consumption in EPML).
31
Eva
lua
tin
g t
he
En
erg
y C
on
su
mp
tio
n o
f B
usin
ess P
roce
sse
s |
A
ca
de
mic
ye
ar:
20
13
-20
14
4.2.2 Cost evaluation component
The development of the cost evaluation feature of EPCTools required a lot of work
because of the inherit behaviour of business processes especially the possible use of different
connector nodes (AND, OR and XOR) within business processes that lead us to make a
specific algorithm for the energetic propagation of attributes describing energy consumption.
We can divide the development phase of the cost evaluation in two main parts:
In a first time, we focused our work on a single business process task. Thus,
we proceed this way:
o We have extracted all the required information that we need to compute
the energy consumption as the source type, the quantity and the unit of
each energy from function node. To do so, we have modified the
structure of the FunctionItem java class in EPCTools. The main
modification consisted in the association of an ArrayList <Energy>
with a FunctionItem. From there, we knew for each business process
function what energy sources were associated to them and we used this
information together with real time web services and open data sources
to implement our own java functions in the EPCToolsEditor.java file
and Propagation.java file to get all the indicators of an energy
consumption as the price, CO2 emission, water consumption and
landfill waste for each energy source that composed function node (see
Section 5.4).
For a sub/entire business process cost evaluation we have mostly reused the
same java functions than the ones we have used for a single business process
task cost evaluation: However, the main noticeable difference resides in the
fact that for a sub/entire business process cost evaluation we have in first
instance to find the highest cost path. The common indicator for the path
comparison is the price because whatever the energy source is it will always
have a price and most of time the price is the easiest indicator to get in
comparison with the landfill waste or CO2 emission for instance.
To propagate the energy cost throw a whole business process, we have created
the java class Propagation in the Propagation.java file. In this class we have
32
Eva
lua
tin
g t
he
En
erg
y C
on
su
mp
tio
n o
f B
usin
ess P
roce
sse
s |
A
ca
de
mic
ye
ar:
20
13
-20
14
implemented the algorithm that manages the propagation by finding the
highest cost path throw the business process.
Basically the algorithm operates as follows:
o From an start node to an end node (both are event nodes) all the
consumption of the function nodes are added together and in the case
there is AND or an OR connector node the consumption of all the
functions between the two branches are added to the rest, in the case
there is a XOR connector node we compute the highest branch between
the start XOR connector node and the end XOR connector node and we
add it to the rest.
In both cases, for a single or an entire/sub business process function task, we also print
the total energetic consumption of the function or the sub/entire business process.
4.3 Conclusion
The changes that we made to EPCTools are covering the functional requirements
introduced previously. Most of these changes are shown in more details in Appendix B:
User Guide, where we present a detailed user guide showing the functionalities that we
added to EPCTools. These changes are:
Energy annotation of a business process detailed in Section 7 of Appendix B.
Single function node cost evaluation detailed in Section 8 of Appendix B.
Subprocces and entire process business process cost evaluation detailed in Section 9 of
Appendix B.
33
Eva
lua
tin
g t
he
En
erg
y C
on
su
mp
tio
n o
f B
usin
ess P
roce
sse
s |
A
ca
de
mic
ye
ar:
20
13
-20
14
5. Test and Validation
In this part of the report, we evaluate the developed tool with respect to the initial
requirements discussed in Section 1.2.5.
1For an optimal execution of the tool, there are few assumptions that can be classified
as follows:
o User:
Familiar with business processes models: Users should be familiar with
the modelling language, i.e., how to represent business processes using
EPC.
Basic literacy and computer usage skills: Users should be at least able
to read and write in English (as our tool is developed in English). Users
also should be able to use basic computer skills for using our tool.
Interest in energy consumption: Users should be interested in
evaluating their business processes energy consumption and aware of
the used units of measurements for giving accurate annotations.
o Business Processes Models:
Models are well structured: All models that we consider are well
structure, i.e., respect the EPC standard notation restrictions.
Models are well annotated: We assume that the models are annotated
with their energy consumption in order to evaluate the energy
consumption of a sub-process/entire process model.
Models do not have loops: Loops should be treated as a special case in
the model structure and especially when computing the cost in energy
usage. To avoid this issue, we assume that the models used here do not
have any loops.
5.1 Controlled annotations (Requirement 1 and 2)
The vocabulary used plays a major role in the control of the annotations and the
predefined units of measurements. Indeed, our java code is designed in a way that the user has
to respect the conditions set by the vocabulary.
The extraction of all the energy sources and associated units of measurements for the
annotation is made from the vocabulary to the java annotation window (Figure 19).
In addition of the “hasSource” property, according to our conceptual model (Section
3.2) an energy consumption has also an amount “hasAmount”, a price “hasPrice” and a CO2
34
Eva
lua
tin
g t
he
En
erg
y C
on
su
mp
tio
n o
f B
usin
ess P
roce
sse
s |
A
ca
de
mic
ye
ar:
20
13
-20
14
emission “hasCO2Emission”, our tool extract all the information we need from the
vocabulary to set in the annotation java window the units and quantity types.
There are java controls on the user choices, if the user wants to add another energy
source or unit of measurement, he has to add it to the vocabulary.
FIGURE 12 RDF N3 VOCABULARY
In Figure 12, we have “power” which is an “EnergySource” associated to an instance
of “kWh” which is a “muo:UnitOfMeasurement”, that means that if we use this vocabulary in
our tool we will be able to annotate a task with a “power” source that will be expressed in
“kWh”.
5.2 Ease of the user interface (Requirement 3)
The user interface does not require any programming skill, everything is transparent
for an end user, the interactions between the vocabulary and the java code are hidden and we
tried to make it as instinctive and easy as possible. For further details about how to use the
user interface, we refer to the User Guide on page 40.
5.3 Multi-level energy cost evaluation (Requirement 4)
We can do an energy cost evaluation on different levels; the basic one is an energy
evaluation for a single business task (see Section 8). For an evaluation of a sub process or
entire business process, we used an algorithm to propagate the energy consumption from a
start node to an end node (see Section 9). As previously mentioned, we assume that the model
is well structured, without loops and tasks are well annotated.
5.4 Multi-indicator energy cost evaluation (Requirement 5 )
The tool provides many energy cost indicators. It is always better to have more than
one indicator to rely on because sometimes just a CO2 emission means nothing for an end
user whereas a concrete price in Euro or something else has more meaning and enhances the
energy usage evaluation of a business process.
35
Eva
lua
tin
g t
he
En
erg
y C
on
su
mp
tio
n o
f B
usin
ess P
roce
sse
s |
A
ca
de
mic
ye
ar:
20
13
-20
14
To use multiple indicators, we used open data sources that indicate the conversion
rates of energy (kWh) to carbon emission (gCO2) as well as the required sources for creating
papers. The sources that we used are as follows:
We use Eirgrid1 for getting a real time CO2 intensity of the energy produced in Ireland
for converting energy in kWh to gCO2.
We use epayplus2 for evaluating the required CO2 emission for a printed document
using the following indicators:
o A4 0.34Kg A3 0.68€ A2 1.36€
o A1 2.72€ A0 5.44€
We use Donegal Stationery Co. Ltd.3 as a reference for evaluating the cost of papers in
Euro. The prices used are as follows:
o A4 0.21€ A3 0.25€ A2 10€
o A1 15€ A0 25€
We use epayplus2 as reference for evaluating the required amount of water for creating
papers using the following conversion rates:
o A4 6L A3 12L A2 24L
o A1 48L A0 96L
We use epayplus2 as a reference for evaluating the resulting landfill waste when using
papers with the following indicators:
o A4 2.4g A3 4.8g A2 9.6g
o A1 19.2g A0 38.4g
5.5 Conclusion
As discussed in this section, we have covered all the predefined requirements by using
an RDF vocabulary for controlling major annotations (Requirement 1). We also include in our
code multiple controls for avoiding wrong annotations (Requirement 2). We provided a
simple user interface that has also been validated by some end users (Requirement 3). We
implemented a method for evaluating the cost of energy of either a simple task or entire
business process (Requirement 4). Finally, we used online available open data sources for
evaluating the energy costs using multiple indicators (Requirement 5).
1 http://www.eirgrid.com/ 2 https://secure.actewagl.com.au/epayplus/ 3 http://www.stationeryshop.ie/index.htm
36
Eva
lua
tin
g t
he
En
erg
y C
on
su
mp
tio
n o
f B
usin
ess P
roce
sse
s |
A
ca
de
mic
ye
ar:
20
13
-20
14
6. Conclusion
This report details the project I worked on during my four months internship at
Insight@NUIG. As an intern in the Green and Sustainable IT unit, my work consisted of the
design and implementation of a solution for the energy consumption annotation and
evaluation of business processes.
Indeed, as we saw in Section 1.2.3 there is a serious need for a solution to efficiently
manage the use of energy within business processes considering the important amount of
energy wastage inside the energy-intensive industries. By increasing their energy awareness,
they can expect to save a relevant amount of money and to significantly reduce theirs
greenhouse gas emission (our work focuses on the CO2 emission). However, considering the
fact that the available solutions do not use a common standardised describing language to
describe energy consumption, we designed a tool using semantic web technologies.
Considering that we chose to use semantic web technologies to provide a standardised
application, the main issues we encountered were due to the lack of a vocabulary to describe
an energy consumption. Consequently, we created our own model that is why our application
is designed to work together with vocabularies that respect our schema.
To conclude the three mains contributions of this work were: first, we propose a
vocabulary to describe energy consumption (see Section 3.2), this vocabulary can be shared
and re-use by the professional of the business process managers. Second, we added to
EPCTools an energy consumption annotation feature (see Section 4.2). And finally, we
developed the required methods to evaluate the cost of consumed energy of a simple task as
well as an entire business process (see Section 4.2).
This work can be further extended by refining its current features as well as adding
new ones including:
Improve the cost evaluation of energy usage using dynamic open data.
Currently we are using static values taken from online resources. A possible
improvement includes using methods similar to the evaluation of the CO2
emission.
Evaluate the correctness of data sources: We currently use only Eirgrid (see
Section 5.4) for evaluating CO2 emission which from time to time is not
responsive and gives wrong values. This can be improved either by using a
second source of data that can be queried in such cases or by keeping historical
data that can be used for future calculations.
37
Eva
lua
tin
g t
he
En
erg
y C
on
su
mp
tio
n o
f B
usin
ess P
roce
sse
s |
A
ca
de
mic
ye
ar:
20
13
-20
14
Add real-time evaluation of energy of business processes: this can be done
through getting sensor readings that are related to some tasks and link their
current values to the business process.
38
Eva
lua
tin
g t
he
En
erg
y C
on
su
mp
tio
n o
f B
usin
ess P
roce
sse
s |
A
ca
de
mic
ye
ar:
20
13
-20
14
Appendix A: Saving Energy Consumption in EPML
FIGURE 13 EPML FILE
An .epml file is a text file used to save and load the EPCTools models and theirs
annotation, as we can see in Figure 13 it’s like a tree.
A function has a graphic part (<graphics>) which takes care of the position and scale
of the rectangle…, a name (<name> explicit name to make easier the manipulation of big
.epml files), an energy consumption (<EnergyConsumption>) which describe everything
related to the energy uses of the function, amount, unit, value… (According to our conceptual
model) and a capability part (<capability>).
Into the energy consumption tag, we describe the consumption using the RDF N3
language. The skeleton of the content is the following one:
Each line represent a statement, a statement is composed by 3 elements a subject a
predicate and a object, let’s see the first row.
http://example.com/instances#a3e3fc7d-0786-41b3-9244-ecf6q18bq943 (subject) is an
URI (unique id to identify a RDF resource), in this case it’s the ConsumptionAmount of a
paper.
http://vocab.deri.ie/pen#hasUnit (predicate) is our relation define in our conceptual
model.
“A4” is the object (value).
“<”, “&#xsd” and “>” are added by EPCTools to escape special characters.
39
Eva
lua
tin
g t
he
En
erg
y C
on
su
mp
tio
n o
f B
usin
ess P
roce
sse
s |
A
ca
de
mic
ye
ar:
20
13
-20
14
Basically this statement means that our resource
http://example.com/instances#a3e3fc7d-0786-41b3-9244-ecf6q18bq943 has as a unit A4.
All the information are saved according to this schema in an .epml file bounded to a
specific model.
When a user launch EPCTools, the program will first load all the data from the
corresponding .epml file to the graphic interface of EPCTools in order to draw the model with
its corresponding annotations, this is how the loading process works.
40
Eva
lua
tin
g t
he
En
erg
y C
on
su
mp
tio
n o
f B
usin
ess P
roce
sse
s |
A
ca
de
mic
ye
ar:
20
13
-20
14
Appendix B: User Guide
1. Install of the EPCTools plug-in
Please note that EPC Tools is an open source initiative towards a tool for Event
Driven Process Chains (EPCs) that supports the tool independent EPC interchange format
EPML9. EPCTools runs as an Eclipse10 plug-in, consequently this section supposes that
Eclipse is installed and running already in the machine. The installation of the binary version
of the EPCTools plug-in consists of the following steps11:
2. GEF Installation
If you have not installed the GEF plug-in before, then you should download it (from
http://www.eclipse.org/projects/gef/), decompress the downloaded archive and copy the
content of the "plugins" and "features" folders to the corresponding folders in your eclipse
installation folder (e.g."/usr/local/eclipse/plugins" and "/usr/local/eclipse/features" or in
windows "C:\ProgramFiles\Eclipse\plugins" and "C:\Program Files\Eclipse\features").
Note: The GEF plug-in provides some library functions used by the EPC editor
contained in the EPCTools package. For Eclipse 3.1 and higher, it is recommended to use the
built-in update functions for installing GEF (Help->Software Updated->Find and Install).
3. Installation of the EPCTools plug-in
The EPCTools plug-in can be installed in the same way as the GEF plug-in. Extract
the files from the archive's folder "plugins" and copy these files to the corresponding
"plugins" folder in your eclipse installation location.
The next time you start eclipse, the new plug-ins (GEF and EPCTools) will be loaded
automatically.
4. Import and compile the EPCTools project (source package)
The EPCTools project archive contains the complete source code needed to compile
the EPCTools plug-in. Before you can import and compile this package, you will need the
GEF SDK plug-in. Please install the GEF SDK as described in 5.2.1).
Now decompress the archive and use the eclipse import function to create the
EPCTools project within eclipse: Menu: File->Import...->"Existing Project into Workspace"
To compile the project, use Menu: Project->"Build Project"
41
Eva
lua
tin
g t
he
En
erg
y C
on
su
mp
tio
n o
f B
usin
ess P
roce
sse
s |
A
ca
de
mic
ye
ar:
20
13
-20
14
5. Test the self -compiled plug-in
You can export a self-compiled plug-in using the Eclipse export function:
Menu: File->Export...->"Deployable plug-ins and fragments"
Then you can install and run this plug-in as described in Section 3.
Alternatively, it is possible to temporarily load the new plug-in in a run-time
workspace. This starts a new Eclipse program instance with the plug-in enabled:
Menu: Run->"Run As"->"Run-time Workbench"
Note that here the EPCTools project must have been cleanly compiled, and the project
must be selected in the (Java or Plug-in Development) Platform's Package Explorer.
In order to change to the Plug-in Development Perspective, do the following:
Menu: Window->"Open Perspective"->"Other..."->"Plug-in Development"
You can use the EPCTools editor as it will be described in the following.
6. Run the EPCTools editor
To run the EPCTools editor, you can simply double-click an epml file in the
"Navigator" (Resource Perspective) or in the "Package Explorer" of one of the programming
Perspectives.
To create a new epml file, use the following menu command:
Menu: File->New->Other...->"EPC diagram"->"Empty EPC" (see Figure 14)
FIGURE 14 CREATE A NEW EPC FILE
42
Eva
lua
tin
g t
he
En
erg
y C
on
su
mp
tio
n o
f B
usin
ess P
roce
sse
s |
A
ca
de
mic
ye
ar:
20
13
-20
14
The container path requested in this dialog must be an existing project name in the
current Eclipse environment. If you want to create a simple new project containing some epml
files, you can do this with:
Menu: File->New->Project...->Simple->Project
Once the editor is open the user will find the editing environment as shown in Figure
26. The menu in the upper left corner (see 1 in the Figure 15Figure 14) can be used for selecting
different editing tools.
The select tool can be used for selecting single or multiple EPC objects (including
arcs).
FIGURE 15 A NEW EMPTY EPC FILE
Once an object is selected, it can be moved, resized or deleted (see Figure 16). For
moving a node, click into it with the left mouse button and move the mouse, while the left
mouse button is pressed. For resizing a node click on one of the handles with the left mouse
button and move it while the mouse button is pressed. For renaming a node, click into the
43
Eva
lua
tin
g t
he
En
erg
y C
on
su
mp
tio
n o
f B
usin
ess P
roce
sse
s |
A
ca
de
mic
ye
ar:
20
13
-20
14
middle of the node; then a small editor window will open in which the label can be edited.
FIGURE 16 RESIZE, RENAME AND DELETE AN EPC COMPONENT
7. Energy annotation of a business process
The main feature that we added to EPCTools consists of the energy annotation of a
business process model. By annotating we mean associating an energy consumption to each
function node. To annotate a business process model the user has first to launch EPCTools
(refer to section 6), then to right click on the desired function node and to select “Energy
Consumption” (Figure 17).
FIGURE 17 CONTEXTUAL MENU SHOWING "ENERGY CONSUMPTION" FOR ANNOTATING A FUNCTION
44
Eva
lua
tin
g t
he
En
erg
y C
on
su
mp
tio
n o
f B
usin
ess P
roce
sse
s |
A
ca
de
mic
ye
ar:
20
13
-20
14
Clicking on “Energy Consumption” opens a new window dialog. Figure 18 and Figure
19Figure 1 show the “Energy Consumption” annotation windows.
FIGURE 18 EMPTY ENERGY CONSUMPTION WINDOW
FIGURE 19 FILLED ENERGY CONSUMPTION WINDOW
The user has first to select a domain ontology (a filter is set on the file selection
window to shows only the file with a .n3 extension as shown in Figure 20Figure 20) to fill the
window with the domain ontology contents (sources, units and units of measurements
respectively 1, 2 and 3 of Figure 19), in case it is the first time that the user annotates this
function otherwise the previous annotation will be loaded and the user still has the possibility
to change the domain ontology to modify the previous annotations.
45
Eva
lua
tin
g t
he
En
erg
y C
on
su
mp
tio
n o
f B
usin
ess P
roce
sse
s |
A
ca
de
mic
ye
ar:
20
13
-20
14
FIGURE 20 DOMAIN ONTOLOGY FILE SELECTION
A control is set on the selected domain ontology, to check the syntax of the .N3 file in
case the syntax is does not respect the N3 standards the Figure 21 error message is displayed
(the control is made only on the syntax not the content of the file).
FIGURE 21 WRONG N3 SYNTAX
Finally, the user can annotate the function node with the selected energies associated
to a value and a unit of measurement, if the user needs to duplicate an entry (source, value and
unit of measurements, he can click on the plus sign – see 4 in Figure 19), to direct the user
few controls are set on the annotation form to check if for each selected entry there is no:
Empty value AND unit corresponding to one of the selected entries
Empty value OR unit corresponding to one of the selected entries
String in the quantity field instead of an integer
46
Eva
lua
tin
g t
he
En
erg
y C
on
su
mp
tio
n o
f B
usin
ess P
roce
sse
s |
A
ca
de
mic
ye
ar:
20
13
-20
14
If one of the above condition is true the Figure 22 error message is displayed when the
user try to validate the annotation with a click on the “Ok” button.
FIGURE 22 ANNOTATION FORM ERROR
The user also has the possibility to cancel every change he made by escaping the
window with a click on the “Cancel” button. A click on the “Clear” button will have as effect
to clear the window content and to clear the domain ontology file path. To save every change
the user may have done, he has to click on the “Ok” button which will have as effect to save
the function annotation and to exit the window.
The user can also change the annotations at any time, but in case the source ontology
file path has changed when the user will try to re-annotate or to check the energy consumption
of a function an error message will be displayed as shown in Figure 23 Wrong ontology file
path.
47
Eva
lua
tin
g t
he
En
erg
y C
on
su
mp
tio
n o
f B
usin
ess P
roce
sse
s |
A
ca
de
mic
ye
ar:
20
13
-20
14
FIGURE 23 WRONG ONTOLOGY FILE PATH
8. Single function node cost evaluation
When a function is annotated with its energy consumption we can get the energy cost
evaluation of this function by clicking on the “Cost” button (refer Figure 19).
Clicking on “Cost” opens a new window dialog with various indicators. This window
is composed of two main views; the first view (1 in Figure 24) shows the energy consumption
of all the function’s selected energies, these indicators are:
the “Source”
the “Unit”
the “Quantity”
the “Cost(€)” in euro
the “CO2(Kg/CO2)” emission
the “Water(L)” consumption
the produced “Landfill Waste(g)” in grams
The second view shows the total consumption of the function.
48
Eva
lua
tin
g t
he
En
erg
y C
on
su
mp
tio
n o
f B
usin
ess P
roce
sse
s |
A
ca
de
mic
ye
ar:
20
13
-20
14
If there is N/A instead of a value for a field (exemple in Figure 24 for the CO2 emission
of our power entry) that means that the software cannot access the value that can be due to a
down server or a missed algorithm to evaluate the value.
FIGURE 24 ENERGY COST EVALUATION
9. Subprocces and entire process business process cost evaluation
In addition of the cost evaluation of a single business process task (function node), the
user can get the evaluation of a business sub process as well as the evaluation of an entire
business process throw the button 2 in Figure 15.
Indeed, a click on this button opens the graphic user interface (Figure 25) for the sub
process/entire process cost evaluation.
First the user has to select the evaluation range from an event start node (1 in Figure
25) to an event end node (2 in Figure 25). At the event start node selection the software will
compute all the possible end event nodes from the selected start node.
FIGURE 25 PROPAGATION GUI
49
Eva
lua
tin
g t
he
En
erg
y C
on
su
mp
tio
n o
f B
usin
ess P
roce
sse
s |
A
ca
de
mic
ye
ar:
20
13
-20
14
When the user made his choices, he can either cancel everything by clicking on the
“Cancel” button (Figure 25) or he confirm his choices and getting the evaluation of the
business process/sub process he selected.
If there is no energy cost for the selected user path, an empty window will be returned
like in Figure 26.
FIGURE 26 ENERGY COST NULL
Indeed, in this example we want to evaluate the energy cost of all the functions
between the start event node: cash and the end event node: Payment done. In other words, we
want to evaluate the energy cost of the business task (function): Get cash payment. This
function does not require any energy so the energy consumption is null that is why we get the
Figure 26 window.
However, most of the time a user will evaluate an annotated business process. The
resulting evaluation window is shown in Figure 27.
50
Eva
lua
tin
g t
he
En
erg
y C
on
su
mp
tio
n o
f B
usin
ess P
roce
sse
s |
A
ca
de
mic
ye
ar:
20
13
-20
14
FIGURE 27 BUSINESS PROCESS EVALUATION BY PROPAGATION
Figure 27 window is structured as following:
o The name of each function (1 in Figure 27) associated to its own energy
consumption (“Cost” in euro, “CO2(Kg/CO2)” emission in kilogram,
“Water(L)” consumption in litre and “Landfill Waste(g)” in gram).
o And the total consumption of the process/sub process 3 in Figure 27.
o After an evaluation if the user wants to do anothesr evaluation with different
start and end event node he has to click on the “Cancel” button (Figure 27) and
to launch another instance of the model evaluation tool with a click on the
“Model’s consumption” button (2 in Figure 15).
Appendix C: Working Plan
Month April 2014 May 2014 June 2014 July 2014
Period from 01/04/2014
to 11/04/2014
from 14/04/2014
to 25/04/2014
from 28/04/2014
to 09/05/2014
from 12/05/2014
to 23/05/2014
from 26/05/2014
to 06/06/2014
from 09/06/2014
to 20/06/2014
from 23/06/2014
to 04/07/2014
from 07/07/2014
to 31/07/2014
Tasks
Learning of RDF
Learning of Jena
library
Using Jena to create
examples of RDF
data
Learning EPC
Using EPCTools
Do first changes in
EPCTools
Design of the RDF
ontology to
describe energy
consumption.
Learning of SWT
library and creation
of the first interface
for the task
annotation
Annotation of a
task
Controls and
improvement for
the annotation
Saving and loading
with the .epml file
Cost of a task
Creation of the cost
evaluation graphic
interface
Research of the
open data and web
service to evaluate
energy
consumption
Cost of a business
process
Creation of the
global cost
evaluation graphic
interface
Bug fixing and
improvement of the
cost evaluation
graphic interface
Propagation
algorithm
Last bug fixing on
the business
process cost
evaluation
Internship report
redaction
PowerPoint
presentation
Deliverables
Example of RDF
data
Java code using
Jena library
Install and run of
EPCTools
Minor changes in
EPCTools
RDF ontology
First interface for
the task annotation
Updated version of
the annotation
interface
RDF N3
description of a
business task
Cost evaluation of
a single business
task
First version of the
global cost
evaluation window
Cost of a business
process
Internship report
PowerPoint
presentation
Bibliography
[1] Insight Centre for Data Analytics, “Insight Centre Mission,” 2014. [Online]. Available: https://www.insight-
centre.org/about/mission. [Accessed 14 July 2014].
[2] P. H. Feiler and W. S. Humphrey, “Software Process Development and Enactment: Concepts and
Definitions,” in ICSP, 1993.
[3] T-Systems, “Green Business Processes,” 2014. [Online]. Available: http://www.t-systems.com/about-t-
systems/green-business-processes/763090. [Accessed 21 July 2014].
[4] S. Bhiri, W. Derguech and M. Zaremba, “Modelling Capabilities as Attribute-Featured Entities,” in WEBIST,
Porto, Portugal, 2012.
[5] “What is a Business Process?,” [Online]. Available: http://www.wisegeek.org/what-is-a-business-
process.htm. [Accessed 23 July 2014].
[6] B. Korherr, “Business Process Modelling - Languages, Goals, and Variabilities,” [Online]. Available:
https://www.big.tuwien.ac.at/teaching/theses/81. [Accessed 24 July 2014].
[7] F. Gottschalk, “Configurable Process Models,” Technical University of Eindhoven, Eindhoven, 2009.
[8] M. La Rosa, “Managing variability in process-aware information systems,” Queensland University of
Technology, Brisbane, 2009.
[9] L. J. Hommes, The Evaluation of Business Process Modeling Techniques, TU Delft, 2004.
[10] W. S. August, Vom Geschäftsprozess zum Anwendungssystem, Springer, 2002.
[11] A. Tsai, “EPC Workflow Model to WIFA Model Conversion,” in IEEE International Conference on Systems, Man,
and Cybernetics, Taipei, 2006.
[12] “An Introduction to the Resource Description Framework,” [Online]. Available:
http://www.dlib.org/dlib/may98/miller/05miller.html. [Accessed 22 July 2014].
[13] “W3C,” [Online]. Available: http://www.w3.org/. [Accessed 25 July 2014].
[14] “Dublin Core,” [Online]. Available: http://dublincore.org/. [Accessed 25 July 2014].
[15] “DCRDF,” [Online]. Available: http://dublincore.org/documents/dcmes-xml/. [Accessed 25 July 2014].
[16] “IMS,” [Online]. Available: http://www.imsproject.org/. [Accessed 25 July 2014].
[17] “Resource Description Framework,” [Online]. Available:
http://en.wikipedia.org/wiki/Resource_Description_Framework. [Accessed 22 July 2014].
[18] N. Shah and K.-M. Chao, “Ontology for Home Energy Management Domain,” Faculty of Engineering and
Computing Coventry University, Coventry , 2011.
[19] ARIS Community, “Event-driven process chain (EPC),” [Online]. Available:
http://www.ariscommunity.com/event-driven-process-chain. [Accessed 22 July 2014].
[20] E. Kindler , “On the Semantics of EPCs: A Framework for Resolving the Vicious Circle,” University of
Paderborn, 2006.
