1 general introduction 2 energy use related to ... - UCC, IT in AEC

1 GENERAL INTRODUCTION................................................................................... 5
1.1 ENERGY CONSUMPTION.............................................................................5
1.2 BUILDING ENERGY AUDITING..................................................................8
1.3 WHOLE BUILDING ENERGY ANALYSIS..................................................9
1.4 BUILDING ENERGY MANAGEMENT SYSTEMS ..................................10
1.5 THE IT NETWORK AND THE BEMS.........................................................11
1.6 THE FUTURE OF BUILDING ENERGY CONTROL.................................11
1.7 THESIS STRUCTURE SCHEMATIC...........................................................13
1.8 LAYOUT OF THESIS....................................................................................14
2 ENERGY USE RELATED TO CLIMATE CHANGE......................... 15
2.1 WORLDWIDE LEGISLATION WITH REGARD CO 2 EMMISIONS .......16
2.2 KYOTO PROTOCOL AND THE EU............................................................16
2.3 ENERGY RELATED CO 2 EMISSIONS - THE UNIVERSAL
PERSPECTIVE...........................................................................................................17
2.4 SUMMARY....................................................................................................22
3 BUILDING ENERGY USE ........................................................................................ 23
3.1 ENERGY ANALYSIS IN THE DESIGN STAGE ........................................24
3.2 CRITERIA USED TO MONITOR BUILDING OPERATIONAL
PERFORMANCE .......................................................................................................26
3.3 DECISION MAKING SUPPORT FOR STAKEHOLDERS.........................29
3.4 BUILDING ENERGY MANAGEMENT SYSTEMS ...................................31
3.5 SUMMARY....................................................................................................32
4 WHOLE BUILDING ENERGY USE................................................................... 34
4.1 INTRODUCTION ..........................................................................................35
4.2 DISAGGREGATION OF ENERGY USE .....................................................35
4.3 CALCULATING ENERGY USE BY COMPONENT..................................38
4.4 USING WHOLE BUILDING ENERGY ANALYSIS TO ANALYSE REAL
DATA..........................................................................................................................40
1

4.5 AHU 1 – THE POOL AREA AHU ................................................................41
4.6 CONCLUSIONS.............................................................................................44
4.7 SUMMARY....................................................................................................45
5 INFORMATION/ DATA MODELLING ......................................................... 46
5.1 STEP COMPLIANCE .....................................................................................48
5.2 XML.................................................................................................................49
5.3 STEP AND XML...........................................................................................52
5.4 DOCUMENT TYPE DEFINITIOIN (DTD) .................................................52
5.5 GbXML............................................................................................................53
5.6 MYSQL............................................................................................................54
5.7 OPEN SOURCE SOFTWARE........................................................................55
5.8 DATABASE DEVELOPMENT......................................................................56
5.9 SUMMARY....................................................................................................58
6 THE MARDYKE ARENA ...........................................Error! Bookmark not defined.
6.1 INTRODUCTION TO THE MARDYKE ARENA ......Error! Bookmark not
defined.
6.2 BUILDING USAGE PROFILE...................... Error! Bookmark not defined.
6.3 BUILDING ENERGY USE............................ Error! Bookmark not defined.
6.4 BUILDING HVAC DESIGN ......................... Error! Bookmark not defined.
6.5 CONCLUSIONS............................................. Error! Bookmark not defined.
6.6 SUMMARY.................................................... Error! Bookmark not defined.
7 SPECIFICATIONS OF REQUIREMENTS .................................................. 60
7.1 PRESENT SITUATION AND PROPOSED NEW DIRECTION ..................61
7.2 ARCHIVING ..................................................................................................63
7.3 DATA TRANSFER AND INTEROPERABILITY .......................................65
7.4 USER INTERACTION ANALYSIS AND DESIGN ....................................69
2

7.5 LINKING THE TECHNOLOGIES TOGETHER..........................................76
7.6 SUMMARY.....................................................................................................78
8 DESIGN..................................................................................................................................... 80
8.1 INTRODUCTION ..........................................................................................80
8.2 VIEW LAYER - GUI DESIGN......................................................................88
8.3 MODEL LAYER - DATABASE DESIGN....................................................93
8.4 CONTROL LAYER – PHP ............................................................................95
8.5 SECURITY - USER AUTHENTICATION .................................................101
8.6 SUMMARY..................................................................................................105
9 IMPLEMENTATION................................................................................................... 106
9.1 BACKGROUND ..........................................................................................106
9.2 MARDYKE ARENA HARDWARE SITUATION .....................................106
9.3 UNIVERSITY SERVER ..............................................................................110
9.4 WORKING APPLICATION ........................................................................113
9.5 GUI DEVELOPMENT WITH IMPLEMENTED CONTROL STRUCTURE
139
9.5 SUMMARY.................................................................................................145
10 TESTING: PROTOTYPE SITE – THE MARDYKE ARENA..... 147
10.1 SOFTWARE TESTING ................................................................................148
10.2 REVIEW OF HARDWARE SITUATION IN THE MARDYKE ARENA.150
10.3 PROBLEMS ENCOUNTERED AND SOLUTIONS FOUND ...................151
10.4 NETWORK CONNECTION DIFFICULTIES ............................................154
10.5 FILE PERMISSION PROBLEMS USING IIS ............................................155
10.6 UPLOAD PROBLEMS ................................................................................156
10.7 QUANTIFYING DATA STORAGE CAPACITY.......................................158
10.8 A CASE STUDY – THE MARDYKE ARENA ..........................................160
10.9 RESULTS AND CONCLUSIONS................................................................167
3

10.10 SUMMARY..............................................................................................170
11 FUTURE WORK......................................................................................................... 171
11.1 METERING OF FACILITIES......................................................................171
11.2 TECHNOLOGY REQUIRED TO ENSURE OPTIMUM INFORMATION
RETREIVAL FROM A FACILITY .........................................................................172
11.3 XML INTEGRATION WITH OFF THE SHELF APPLICATIONS .........174
11.4 USING GD-LIBRARY TO GRAPHICALLY INTERTPRET RETURNED
RESULTS .................................................................................................................175
11.5 WHOLE BUILDING ENERGY ANALYSIS OF THE MARDYKE ARENA
...................................................................................................................................177
11.6 CREATION OF AN EXECUTABLE FILE TO AUTOMATICALLY
UPLOAD DATA TO MySQL DATABASE............................................................178
11.7 SESSION CONTROL IMPLEMENTATION.............................................179
11.8 REMOTE UPLOAD OF DATA WITH SSL INTEGRATION ..................179
11.9 DEVELOPMENT OF A MORE PROFESSIONAL GUI ...........................181
11.10 FUTURE BUSINESS PLAN......................................................................182
11.11 SUMMARY.................................................................................................184
12 REFERENCES.............................................................................................................. 185
13 APPENDICES ................................................................................................................ 197
A - HOVAL HEAT EXCHANGER CATALOGUE................................................197
B – EU DIRECTIVE ON THE ENERGY PERFORMANCE OF BUILDINGS.....201
C – EPA MISSION STATEMENT REGARDING EMISSIONS TRADING
SCHEME ..................................................................................................................208
D – CYLON Ltd. UNITRON CONTROL SYSTEM MANUAL ............................210
4

CHAPTER 1
GENERAL INTRODUCTION
GENERAL INTRODUCTION
1.1 ENERGY CONSUMPTION
The latest report from the Intergovernmental Panel on Climate Change [IPCC, 2001]
refers directly to the emissions of gases such as CO 2 as the main reason for global
warming [Rolfsman, 2002], and with their emission being a direct result from the
energy generation process, the need for the reduction of worldwide energy use is
highlighted. The major contributors of CO 2 emissions are the developed and
industrialised countries notably in Europe and North America. The whole of Asia
contributes about 36.4% of which China and Japan contribute about 14% and 15%
respectively [Priambodo, Kumar, 2001]. The projected rise in greenhouse gas emissions
in Ireland from 1990 to 2010 is 25% compared to the limit of 13% under the EU
burden-sharing agreement.
Reports by the Intergovernmental Panel on Climate Change (IPCC) and the US
Department of Energy note that buildings account for 25-30% of total energy-related
carbon dioxide (CO 2 ) emissions [Wiel et al, 1998]. The overall building stock in the U.S
accounted for 40% of the total energy consumption of the entire country [Filippin,
2000]. Energy consumption for buildings-related services accounts for approximately
one third of total EU energy consumption [EU, 2002]. Energy consumption in buildings
accounts for approximately 30% of greenhouse gas emissions in Ireland with buildings
accounting for approximately 40% of total energy consumed, meaning that this is an
area of much significance if energy conservation and sustainability is to be achieved in
this country.
1.1.2 A global breakdown of energy use in buildings
Since 1950 global CO 2 emissions from energy-related activities have grown 3.2%
annually to an estimated 6188 million tonnes (Mt) of carbon in 1991. North America
accounts for nearly a fourth of world emissions, followed by Eastern Europe and the
former Soviet Union (19%), Western Europe (15%) and Centrally Planned Asia (12%)
[Wiel et al, 1998]. The fastest growth in emissions has taken place in the Middle East
and Centrally Planned Asia (both about three times the world average), followed by
countries in the Far East [Marland et al., 1994]. Buildings-related emissions account for
approximately 30% of total global CO 2 emissions from energy use (19% from the
5

CHAPTER 1
GENERAL INTRODUCTION
residential sector and 10% from the commercial sector) [Levine et al., 1996a]. Even in
climatically favourable Australia, energy consumption in buildings accounts for 25% of
total energy consumption [Filippin, 2000]. The IPCC report further notes that the rate of
growth in emissions from developing countries was over four times the average world
rate between 1973 and 1990 (4.4%), and that their share of world building emissions
has grown from an estimated 11% of the world total in 1973 to 19% in 1990 [Wiel et al,
1998]. The global breakdown of CO 2 emissions from buildings can be seen in Figure
1.1.
Figure 1.1: CO 2 emissions from building energy use by region [Wiel et al., 1998]
1.1.2.1 United States
Reports by the Intergovernmental Panel on Climate Change (IPCC) and the US
Department of Energy note that buildings account for 25-30% of total energy-related
carbon dioxide (CO 2 ) emissions [Wiel et al, 1998], [DOE, 2002]. In 1992, 27 % of the
4.8 million commercial buildings in the United States were mercantile buildings used
primarily for sale and/or distribution of goods and services. These buildings had 18 %
of the 67.9 billion square feet of commercial floorspace and used 15 % of the 5.8
quadrillion Btu (1BtU = 1.055 kJ) of site commercial energy to provide energy services.
Office buildings accounted for only 16 % of all buildings and floorspace, but
commanded 22 % of all the commercial site energy used in 1992. The overall building
stock in the U.S accounted for 40% of the total energy consumption of the entire
country [Filippin, 2000]. In 1989 the largest proportion of the energy used for energy
6

CHAPTER 1
GENERAL INTRODUCTION
services in commercial buildings was for space heating (35 %) followed by lighting (18
%), water heating (9 %), office equipment (7 %), space cooling (5 %), ventilation (5 %),
cooking (3 %) and refrigeration (5%)[EIA, 1992]. Some building activities use more of
a particular energy service than other building activities; for example, office buildings
used only 30 % of the total site energy for space heating, but educational buildings used
54 % of total site energy for space heating.
1.1.2.2 European Union (EU)
Energy consumption for buildings-related services accounts for approximately one third
of total EU energy consumption [EU, 2002]. The EU Commission considers that, with
initiatives in this area, significant energy savings can be achieved, thus helping to attain
objectives on climate change as set out by the Kyoto protocol and security of supply.
Office equipment (personal computers, monitors, fax machines, scanners, copiers,
printers, etc.) accounts for a large proportion of electricity consumption in the tertiary
sector. In the context of the Community's international commitments, particularly in the
area of climate change (notably the KYOTO PROTOCOL), and given its objectives in
such areas as sustainable development, the energy-efficiency initiatives take on special
significance. The implementation of a coordinated labelling programme (known as
ENERGY STAR [EnergyStar, 2003] will enable consumers to identify energy-efficient
appliances and should therefore result in electricity savings that will help not only to
protect the environment but also to ensure the security of energy supply. The
programme may also help to encourage the manufacture and sale of energy-efficient
products.
1.1.2.3 Ireland
Energy consumption in buildings accounts for approximately 30% of greenhouse gas
emissions in Ireland and accounts for 40% of the total energy consumption. The total
Irish housing stock is about 1.1 million units, a significant proportion of which has no
existing insulation, with building completions estimated at 20,000 – 30,000 a year,
making Ireland unique in the EU in relative growth terms [TFI, 2002]. There is vast
potential to reduce energy consumption and improve comfort levels in both new and
existing buildings through an integrated range of measures designed to support energy
conservation and improved efficiency, and increased use of renewable energies in
7

CHAPTER 1
GENERAL INTRODUCTION
buildings; especially passive solar heating, daylighting, natural cooling and active solar
systems, where appropriate.
Even after taking account of the expected increase in building stock by 2015, it should
still be possible to reduce the total energy consumption and carbon dioxide emissions of
the buildings sector significantly.
A number of ways currently exist to first of all quantify the energy used in a facility and
secondly identify areas where the performance could be improved with a view to
reducing the energy consumption and hence CO 2 emissions.
1.2 BUILDING ENERGY AUDITING
1.2.1 Energy auditing as a support tool
With performance and economic viability taking such a prime position in any decision
that the stakeholders in any project make, it is essential to have a tool that combines
both in order to get to a best practice solution. An energy audit would be one such tool.
Energy audits and surveys are investigations conducted on a site with a view to
identifying cost saving measures, reducing the energy used, as well as the detrimental
environmental impact of the energy use of that site. Their results should be
comprehensive and useful to different groups of users [Bennett, Newborough, 2001],
i.e., both the skilled engineer and the facility manager. They are an essential part of the
control of energy costs and should be carried out every 3 – 5 years. Audits along with
routine monitoring of a facility ensure that energy is utilized cost effectively. Through
their use, future consumption could be predicted and strategies could be devised to
reduce it [Bennett, Newborough 2001], this being of interest when the EU directives
targets for Ireland are taken into account.
The energy audit can take a number of forms from an overall energy audit to a more
specific lighting audit which would highlight deficiencies specifically in the area of
lighting.
1.2.2 Building Benchmarking
By quantifying a buildings energy usage over a predetermined amount of time, its actual
performance can be compared with representative figures for that particular buildings
usage sector (benchmarks), e.g. Leisure facilities [DETR ECON 19, 2002]. The EU
benchmark used is energy used per metre of floor area (kWh/m 2 ) in the building. If a
building is assessed and its energy usage is above the benchmark for its usage sector,
8

CHAPTER 1
GENERAL INTRODUCTION
remedial action can take place to bring the energy usage down to the recommended and
more cost effective level. The benchmarks are derived from surveys of large amounts of
occupied buildings so as to determine an average value, known as the “typical” value,
and also a value which would represent that sector that has significantly lower energy
consumption, and employs energy management features in its usage, this building to be
known as a “good practice” building.
However these techniques even though very effective in an overall energy conservation
fashion, do not specifically identify where excess energy usage is taking place, which
would lead to a more accurate solution. Section 1.3 introduces the concept of Whole
Building Energy analysis, which is the analysis of a building by its constituent energy
utilising parts, leading to a more effective and exact solution.
1.3 WHOLE BUILDING ENERGY ANALYSIS
1.3.1 Components of energy use in buildings
By splitting a buildings energy use into its individual constituents, the energy use can be
tracked more closely with a view to identifying areas where optimal performance is not
being achieved, thus allowing the contracted engineer to make changes to the system to
improve performance.
1.3.2 Disaggregation of energy use
The energy use in the building is disaggregated using the monthly utility bills into the
components of [Vital Signs, 2003]:
:
• Energy and costs for fan motor operation;
• Energy and costs for lighting;
• Energy and costs for receptacles (e.g. computers, office equipment and small
appliances);
• Energy and costs for water heating;
• Energy and costs for space cooling;
• Energy and costs for space heating.
9

CHAPTER 1
GENERAL INTRODUCTION
Once disaggregated, the energy can be more easily accounted for with any shortfalls in
performance easily identified. This method ensures that all systems are accountable for
their energy use, so ensuring efficient system performance.
The effective utilisation of this analysis technique does however require the data that a
Building Energy Management System can record, and this in turn is the next area to be
discussed.
1.4 BUILDING ENERGY MANAGEMENT SYSTEMS
Building Energy Management Systems (BEMSs) can significantly improve the overall
energy management and performance of buildings. BEMS’s have become a significant
part of the modern building, adding saving potential as well as increasing functionality
[Wang, Zheng 2001]. The operational feedback obtained from the BEMS can cut energy
costs by by 10 – 20% compared with individual control operation for each facet of the
system [CIBSE, 2002a]. However, for a BEMS to operate effectively it needs to be well
specified and managed correctly by trained staff. An easily understandable graphical
user interface (GUI) design is also an essential part of any BEMS to ensure good
operation.
The monitoring facilities of a BEMS allows plant status, environmental conditions and
energy use to be monitored allowing the user to have a real time understanding of the
operation of the building. This often leads to the user identifying areas that the building
is not performing well, e.g. a period of high energy usage with no mitigating
circumstances. Energy consumption is at a minimum when the source (electrical
energy) tracks the load perfectly, which will be discussed in Chapter 9 on the
implementation of this project with respect to the control of HVAC equipment. When a
mismatch occurs, energy losses are high [Bhatt, 2000]. Thus through the use of the
BEMS, the buildings energy use can be tailored to meet its load pattern and to achieve
the highest possible states of comfort at least cost. BEMSs can therefore improve
building management by trend logging performance, benefiting forward planning and
costing, and when coupled with whole building analysis, serve as a very effective
energy conservation system for buildings.
The BEMS system can also serve as an early warning system so that if set
environmental conditions are exceeded, or plant shutdown has occurred outside
operating procedure, an alarm can be set to go off. This would make the user aware that
10

CHAPTER 1
GENERAL INTRODUCTION
a problem may exist. BEMSs that integrate security, access control and lighting are now
available, which where appropriate can further reduce running costs.
A new advance in the BEMS field is the use of the IT network as the communications
medium for the system, and this is to be the next area of interest in this project.
1.5 THE IT NETWORK AND THE BEMS
IT networks are a standard part of most non-domestic buildings and their use as the
communications system for BEMSs has emerged as the next step in developing
intelligent building control [CIBSE, 2002]. The vast majority of these systems are based
on the Ethernet and most employ Transmission Control Protocol/Internet Protocol
(TCP/IP) as the communications procedure for data transport. The falling cost and the
newly found ease of installation mean that this technology is now at the forefront in
BEMS system communication technology.
The Local Area Networks (LANs) linked to the controllers are then connected to the
Ethernet which in turn is presided over by a supervisory Windows based PC which
governs the whole system. This enables the BEMS to take advantage of the IT networks
high speed and flexibility [CIBSE, 2002]. The next generation of supervisors will also
be able to serve up HTML, the language of the World Wide Web, to display data in a
common web browser. This coupled with the fact that XML could be then generated
enabling a data transfer solution ensures that the future use of the IT network in building
monitoring and control has only reached the tip of the iceberg.
1.6 THE FUTURE OF BUILDING ENERGY CONTROL – PROJECT
OBJECTIVES
The impact of the current energy conservation policy and the associated environmental
initiatives with this mean that the associated costs of running a building now take equal
if not greater importance than the actual capital costs of its construction [CIBSE,
2002b]. Building control and monitoring as well as the ability to label a buildings
energy use are now the areas that most research is addressing. The use of Internet
Protocol (IP), which enables the control layer data to be transferred to the computer
screen at a fast rate and high quantity, will also be utilised.
In the UK and Ireland, the Building Energy Management System (BEMS) is expected
to play an important role in building energy management and security over the coming
years [CIBSE, 2002c]. With the introduction of the Ethernet as the communications
11

CHAPTER 1
GENERAL INTRODUCTION
backbone for the BEMS, it now has the added flexibility and speed of the IT system.
Over the Ethernet, the download of a 100-point data log for example would take just a
fraction of a second [CIBSE, 2002]. Devices have been developed which allow a much
more plug and play approach to connecting a control device to the Ethernet, which will
have a huge impact on data sharing between systems in a building. This would allow a
much more integrated solution with for example the HVAC and fire alarms systems
being displayed on the same Graphical User Interface (GUI) [CIBSE, 2002c].
The building data will also be archived using a relational database management system.
This archiving of building data will allow its performance to be monitored on an
ongoing basis, so making it as efficient as possible in its everyday use.
The GUI is the next area to be taken to the next level with the advent of the Ethernet
and IP as the communications network for the BEMS. Some of the latest BEMSs are
able to display data in HTML (hypertext mark-up language), which is the language of
the World Wide Web on a simple web browser. This facilitates a much more flexible
data analysis platform as the extensibility of the Ethernet and the usability of the web
browser mean off site analysis is now possible via the IP network. This will mean that
many more people will not only have access to the data but will understand it.
The use of a language called XML (extensible mark-up language) is the next step in this
process. This language is the evolution of HTML, and is used to structure data on the
web. Many control manufacturers are now developing controllers that have the ability to
transfer data in XML across the Ethernet. This allows the formatting of their data, as
well as the ability to combine data from different controllers in one XML document for
analysis, so emphasising the combined system approach that the BEMS is now taking
[CIBSE, 2002d]. XML files could also be created from the sensor data obtained via the
web browser enabling data to be transferred to third party packages that have the ability
to read XML for analysis such as Energyplus and DOE 2. A building sector specific
version of the XML language called gbXML will be used to facilitate the transfer of
building specific data for use with these applications. This will make it much more time
and cost effective to analyse building data with a view to reducing the associated energy
costs.
This ability to display multiple building systems on a web browser, along with the
ability to transfer data in a structured, generic form across the Ethernet for analysis
means the possibilities for improvements in the way buildings are monitored is endless.
If this is added to the fact that users can access information from any convenient
12

CHAPTER 1
GENERAL INTRODUCTION
location using web browsers, personal organisers, or even mobile phones, this point is
emphasised. With the introduction of whole building energy analysis into this problemsolving
loop, the energy saving potential is enormous.
1.7 THESIS STRUCTURE SCHEMATIC
The Thesis Structure schematic shown in Figure 1.2 illustrates the different areas that
this thesis examines in the development of this software tool. The colour coding at the
beginning of each section signifies the beginning of a new topic of examination.
Monitoring
Energy use
ENERGYEYE
Energy Archiving and
Analysis Tool
Kyoto Protocol
PHP
MySQL
Unitron & BACnet
Environmental
Requirements
Whole Building
Energy Analysis
gbXML
Technology
Methodology
Real Case Study
THE MARDYKE ARENA
Figure 1.2: Thesis structure schematic
13

CHAPTER 1
GENERAL INTRODUCTION
1.8 LAYOUT OF THESIS
Chapter 2 examines the current legislation with regard to energy related CO 2 emissions
in both a National and International perspective and examines how buildings contribute
a high percentage of this energy. Chapter 3 addresses the energy use in buildings at the
three stages of building development and focuses more closely on the operational phase
of energy use. BEMSs are introduced and the individual ways in which building energy
use can be evaluated is also examined. Chapter 4 introduces the concept of whole
building energy use and analysis as a means to more closely monitor building energy
performance. Chapter 5 looks at making the BEMS more extensible through the use of
the gbXML building data exchange format, as well as introducing the idea of the
database management system to take advantage of the BEMS systems ability to log
building energy use data. This will allow data to be archived with a view to future
analysis. Chapter 6 introduces the Mardyke Arena sports complex as the facility to be
used as a prototype for this project. It also describes the building services in existence in
the Arena with a view to choosing a specific area to be analysed using the whole
building analysis framework. Chapter 7 returns to the core objectives of this project that
being to create an extensible user friendly building energy archiving and analysis
software package and goes on to examine software that could be used to achieve these
goals. Chapter 8 looks at the design process now that the software has been hosen, and
uses the Object Oriented approach to design the Graphical User Interface (GUI).
Chapter 9 describes the actual process used to implement the software environment
using the prototype facility and its inherent building services to develop a prototype
package. It begins by examining the hardware interface, and then using performance
metric analysis derives the relevant formulae to quantify the energy use in the facility at
component level. It then implements the package starting with the GUI until desired
functionality is achieved. Chapter 10 outlines the testing process used in this project
along with examining some of the problems encountered in its implementation. Chapter
11 concludes the research and describes a future development process for the software
environment.
14

CHAPTER 2
ENERGY USE RELATED TO CLIMATE CHANGE
ENERGY USE RELATED TO CLIMATE CHANGE
As Figure 2.1 illustrates, this section examines the environmental requirements that are
related to the consumption of energy, and introduces the idea of energy related CO 2
emissions.
Monitoring
Energy use
ENERGYEYE
Energy Archiving and
Analysis Tool
Kyoto Protocol
PHP
MySQL
Unitron & BACnet
Environmental
Requirements
Whole Building
Energy Analysis
gbXML
Technology
Methodology
Real Case Study
THE MARDYKE ARENA
Figure 2.1: General thesis Structure schematic with emphasis on Environmental
Requirements of Energy use
15

CHAPTER 2
ENERGY USE RELATED TO CLIMATE CHANGE
2.1 WORLDWIDE LEGISLATION WITH REGARD CO2 EMMISIONS
One of the major greenhouse gases is Carbon Dioxide (CO 2 ). The latest report from the
Intergovernmental Panel on Climate Change [IPCC, 2001] refers directly to the
emissions of gases such as CO 2 as the main reason for global warming [Rolfsman,
2002]. The relationship between the emissions of such gases and the detrimental effects
on the environment that resulted has long been known. Because of this knowledge, in
1992, the United Nations Framework Convention on Climate Change (UNFCCC) was
agreed at the Earth Summit. The UNFCCC would like to limit the amount of
greenhouse gases emitted to the atmosphere so as to curtail the damage being done.
Developed countries committed themselves to adopt policies with the aim of returning
individually or jointly to their 1990 levels of emissions of CO 2 and other greenhouse
gases.
2.2 KYOTO PROTOCOL AND THE EU
In 1997, the Kyoto Protocol of the UNFCCC was agreed and set legally binding targets
for developed countries for the period 2008-2012. Under the Kyoto Protocol, the EU
has agreed to reduce emissions of the six greenhouse gases, carbon dioxide, methane,
nitrous oxide, hydrofluorocarbons, perfluorocarbons, and sulphur hexafluoride, by 8%
below 1990 levels by the period 2008-2012. Under the provisions of this agreement and
as part of the EU burden sharing agreement, Ireland has agreed to limit the increase in
emissions of the six greenhouse gases to 13% above 1990 levels by the same period
[DPE, 2002].
The protocol looks to the domestic governments themselves to initiate mechanisms
whereby the criteria will be met, but also establishes a series of flexible mechanisms,
which may be used to supplement domestic action through international offsets. These
"Kyoto mechanisms" include:
1.”Tradable permits (Article 17) - a provision, which allow Annex 1 Parties to trade
emissions”;
2.”Joint Implementation (JI) (Article 6) - providing that emissions credits generated
through project activities may be traded among Annex I Parties”;
16

CHAPTER 2
ENERGY USE RELATED TO CLIMATE CHANGE
3.”Clean Development Mechanism (CDM) (Article 12) - through which project based
reduction credits acquired from activities in non-Annex I countries may be used to
offset Annex I country commitments”.
The mechanisms were created to reduce the costs of compliance, but the time required
for their full elaboration only left approximately 10 years for their use to meet the Kyoto
objectives as they were fully outlined in 2000. Emissions trading which is the most
important of the flexibility mechanisms from Ireland's viewpoint will not start until
2008, though the EU may commence emissions trading in some form prior to 2008.
Two aspects are also worth noting:
1.”Penalties for non-compliance with the Protocol will have to be agreed by the
Conference to the Parties as required under Article 18. In any event Ireland must be
seen to comply with the Protocol in keeping with its commitments to the international
community”;
2.”Reliable and pro-active monitoring and verification systems are essential for the
assessment of progress and therefore form an important part of adequate preparations
for the implementation of the Protocol”.
The official term used in relation to emissions reduction in the Kyoto Protocol is
“quantified emissions limitations and commitments” (QELRCs) [Halsnaes, 2001], and it
is only through meeting these commitments that the levels of CO 2 in the atmosphere
will be controlled.
2.3 ENERGY RELATED CO 2 EMISSIONS - THE UNIVERSAL
PERSPECTIVE
In 1990, the global industrial sector consumed about 91EJ (1 exajoule (EJ) = 1.0 x 10 18
J) of end use energy, which resulted in emissions of an estimated 1.8GtC (1.8 x 10 9
tonnes of Carbon). The major contributors of CO 2 emissions are the developed and
industrialised countries notably in Europe and North America. The whole of Asia
contributes about 36.4% of which China and Japan contribute about 14% and 15%
respectively [Priambodo, Kumar, 2001]. The breakdown of CO 2 emissions universally
can be examined more closely from Figure 2.2.
17

CHAPTER 2
ENERGY USE RELATED TO CLIMATE CHANGE
Figure 2.2 Total carbon emissions by country [Wiel et al., 1994]
2.3.1 EU
With 1990 baseline levels of greenhouse gases taking a pivotal role in the Kyoto
protocols reforming policy, the fact that taking the EU as a whole, energy use and
production is by far the most important source of Greenhouse gas emissions,
representing 80% of 1990 emissions [KYOTO Strategy, 1998], means that this is going
to be the key area of change if the protocols are to be met. Since the aggregate energy
demand in the EU is expected to rise by over 60% by 2010 [Sun, 2001], and the fact
that climate change can be directly attributed in a large part to the use of energy means
that a fresh look is now required at the current energy policy in place. There is also a
new importance on the research and development side of energy use and production as
it is strived to reverse or at the least curb this worrying trend of climate change.
18

CHAPTER 2
ENERGY USE RELATED TO CLIMATE CHANGE
2.3.2 Ireland
Within the EU burden sharing agreement in order to meet its obligation under the Kyoto
Protocol, Ireland must stabilise its Greenhouse gas emissions at 13% above 1990 levels
within the period 2008 to 2012 [EEC, 1998]. For the three new gases (HFCs, PFCs and
SF6,), the reference year is 1995.
Table 2.1 Ireland's Greenhouse Gas Emissions 1990 – 2010 [DPE, 2002]
Source: Historical CO 2 data based on DPE Energy Balances 1980-1998. CO 2 projections based on ESRI
and DPE data. Provisional data for non-energy related CO 2 and other gases and sinks DELG. Methane
figures represent emissions from the Agriculture sector
Table 2.1 shows Ireland's greenhouse gas emissions for the period 1990 - 2010 1 . By
2010, on a business as usual basis, it is projected that the limit will be exceeded by the
equivalent of 6.8 million tonnes CO 2 . The projected rise in greenhouse gas emissions
from 1990 to 2010 is 25% compared to the limit of 13% under the EU burden-sharing
agreement.
Energy related CO 2 emissions account for most of the growth. It is projected that there
will be 18.2 million tonnes more of CO 2 emitted due to the production, transmission,
supply and end use of energy in 2010 compared to 1990. As a proportion of greenhouse
gas emissions overall, energy related CO 2 emissions accounted for 51% in 1990
compared to a projected 66% in 2010, with energy use in buildings being at present
30% of this total.
To examine where this growth occurs, Table 2.2 shows the increase in energy related
CO 2 emissions by sector after energy used in transformation is apportioned to sectors.
1 Note that CO 2 emissions from aviation kerosene for international use are excluded under the
Kyoto Protocol
19

CHAPTER 2
ENERGY USE RELATED TO CLIMATE CHANGE
The increases in energy demand in transport that is projected in the coming years are
reflected here by the 157% increase in transport related CO 2 emissions in 2010
compared to 1990. The second largest growth sector in CO 2 with an increase of 76% is
the tertiary sector, with industry being the third largest increase. With both the tertiary
sector and the industrial sector being building dependant to a large extent, the need for
energy consumption to be reduced in these areas again highlights the need for more
efficient building energy management.
Table 2.2: Ireland's Energy Related CO 2 Emissions 1990 - 2010 2 (Million Tonnes)
[DPE, 2002]
Figure 2.3 graphs the aforementioned projected growth levels by sector relative to 1990
and Table 2.3 shows CO 2 emissions by source to further clarify the worrying trends of
increases in all sectors.
Source: DPE, 1999
Figure 2.3: Projected growth of energy related CO 2 emissions to 2010 [DPE, 2002]
2 Energy related CO 2 emissions in transformation have been allocated to sectors.
20

CHAPTER 2
ENERGY USE RELATED TO CLIMATE CHANGE
2.3.3 General Conclusions
Due to sustained economic growth, Ireland's primary energy consumption has increased
by 58% since 1980, and is projected to increase in line with economic growth by a
further 37% by 2010 in a business as usual scenario. As a result, the target set for
greenhouse gas emissions for the period 2008 - 2012 will be reached far earlier than the
target year of 2010 as set by the Kyoto protocol. In the business as usual case, Ireland
will exceed its target limit by 6.8 million tonnes of CO 2 equivalent in 2010. The
projected growth in energy related CO 2 emissions are 63% above 1990 levels. In
meeting Irelands’ commitments arising from the Kyoto Protocol, it will be necessary to
separate energy growth from economic growth as the associated proportional increase in
CO 2 emissions is too high a price to pay in environmental terms. In order to reverse this
worrying trend of increasing emissions, people’s behavioural patterns must firstly
change both in their lifestyles and in their energy consumption practices. The more
widespread use of energy efficient production, processing and distribution techniques
will also serve to reverse this trend [Filippin, 2000]. Figure 2.4 summarises the
projected growth in the economy, energy consumption, energy related CO 2 emissions
and greenhouse gas emissions all of which are projected to rise by worrying levels. This
means that energy management and conservation is now a more important subject at
both economic and environmental levels than ever, with solutions being sought
immediately to reverse these trends.
Figure 2.4: Projected growths of economy, energy consumption and Energy
related CO 2 emissions to 2010 [DPE, 2002]
21

CHAPTER 2
ENERGY USE RELATED TO CLIMATE CHANGE
2.4 SUMMARY
Ireland has committed to a 13% reduction of GHG emissions by 2010 but if current
energy use trends continue will exceed 1990 levels by 25% by this time. This means
that urgent attention is required to curb this trend if commitments are to be upheld.
Building energy use accounts for 40% of Irelands present energy use figures and hence
is an important area to be refined if targets are to be met. Chapter 3 focuses on building
energy use and the associated monitoring and analysis techniques in current use to
legislate this sector. This chapter continues on the energy related environmental
requirements section of this thesis.
Chapter 4 examines the whole building energy analysis technique whereby a building is
analysed down to its constituent energy utilising parts. At the beginning of this section
the thesis structure schematic will again appear as it does in Figure 2.1, but this time
with the next section highlighted to signify the beginning of a new topic of examination.
The individual software technologies used to achieve this software tools’ goals and their
implementation will be discussed in a later section, beginning with Chapter 7 again with
the new area of the schematic highlighted.
22

CHAPTER 3
BUILDING ENERGY USE
BUILDING ENERGY USE
With the application of the Kyoto protocol on an international level the EU directive on
climate change was put in place stating that building’s will be issued with energy
utilisation certificates based on their consumption at all three stages of the building
lifecycle as displayed in Figure 3.1. This will ensure that the minimum energy
efficiency requirements demanded are met [EU Directive, 2002]. This legislation is
driving the energy efficiency market to new levels of productivity. With the
introduction of this legislation, end users of the energy will be made accountable for the
amount that they use, and will be made to pay financially for any waste on their part.
As mentioned in Chapter 2, energy use in buildings accounts for 40% of the energy
used in Ireland and as such demands serious consideration in any national energy
management strategy. Energy use in buildings is metered by the supply company and is
measured in kWh’s. This kWh quantity is also applicable when CO 2 emissions are
considered because depending on the source generation process (the fuel used to
generate the energy), the exact amount of CO 2 emitted to the atmosphere can be
calculated as it is directly proportional to the amount of kWh’s of energy that is utilised.
A number of strategies are currently used to calculate this kWh quantity with energy
auditing, a process similar to the more well known practice of financial auditing being
one of the more prominent. These are undertaken in order to quantify the energy utilised
at all three stages of the building lifecycle as in Figure 3.1. With the improvements in
technology over the years, simulation and analysis packages have also been developed
which allow a buildings energy use to be inspected in the design, construction and
operation processes, all leading ideally to an energy efficient building. This process is
explained more clearly in Figure 3.1. The following sections outline the tools use to
appraise building energy use at each of the aforementioned stages in the building life
cycle.
23

CHAPTER 3
BUILDING ENERGY USE
Building Life Cycle
DESIGN
CONSTRUCTION
OPERATION
Simulation packages:
Energyplus
DOE 2
Commissioning
and
Mechanical checks
Energy Auditing
and
Benchmarking
Figure 3.1: Building Lifecycle
3.1 ENERGY ANALYSIS IN THE DESIGN STAGE
At this stage of the development of a building as displayed in Figure 3.1, it is important
to take into consideration the energy that the building is projected to use and building it
in such a way as to minimise the energy utilised in the future. This process is aided by
the use of energy simulation packages, which have been developed just for this purpose.
For two decades the US government supported the development of two hourly building
energy simulation programs, BLAST and DOE 2, but in 1996, a US federal agency
began work on a new tool which built on the developments made by the previous two,
called Energyplus [Crawley et al, 2001].
3.1.1 DOE 2
The DOE-2 program for building energy use analysis provides the building construction
and research communities with an up-to-date, unbiased, well-documented computer
program for building energy analysis [DOE SIM, 2002]. DOE-2 is a portable
FORTRAN program that can be used on a large variety of computers, including PC's.
Using DOE-2, designers can quickly determine the choice of building parameters,
24

CHAPTER 3
BUILDING ENERGY USE
which improve energy efficiency while maintaining thermal comfort. A user can
provide a simple or increasingly detailed description of a building design or alternative
design options and obtain an accurate estimate of the proposed building's energy
consumption, interior environmental conditions and energy operation cost.
DOE-2 is an up-to-date, unbiased computer program that predicts the hourly energy use
and energy cost of a building given hourly weather information and a description of the
building and its HVAC equipment and utility rate structure. [Dhakel et al, 2003]. DOE-
2 uses five modules to accomplish this:
• LOADS module, which calculates the hourly heating and cooling loads in the
structure;
• SYSTEMS module, which simulates performance of the HVAC equipment
employed;
• PLANT module, which calculates the performance of the energy conversion
equipment;
• ECONOMICS module, which utilises utility pricing information to come up
with a costing analysis of the energy used;
• WEATHER PROCESSOR module, which prepares the weather data for use in
the package.
Using DOE-2, designers can determine the choice of building parameters that improve
energy efficiency while maintaining thermal comfort and cost-effectiveness. DOE 2 is
heavy to use but very effective in its results [Ndoye, Sorr, 2003].
3.1.2 BLAST
The BLAST (Building Loads Analysis and System Thermodynamics) [BLAST, 2002]
system is a set of computer programs for predicting heating and cooling energy
consumption in buildings, and analysing energy costs, based on a heat balance approach
[Crawley et al, 2001]. This means that equations are written for each facet of the
building environment, walls, floors etc., then solved simultaneously leading to an
“exact” solution [Al-Rabghi, Hittle, 2001].
BLAST was originally developed on mainframe computers, and a portable/workstation
version is actively supported. For Windows users, an important feature is the graphical
25

CHAPTER 3
BUILDING ENERGY USE
user interface, HBLC. This interface allows users to access all the important features of
BLAST and its auxiliary programs in a convenient and easily understandable format.
Furthermore, it significantly speeds the process of entering building data compared to
the input processors previously available for BLAST.
3.1.3 ENERGYPLUS
EnergyPlus [Energyplus, 2002] is a new Department of Energy-supported project that
merges two major building energy simulation programs, DOE-2 and Building Loads
Analysis and System Thermodynamics (BLAST). The goal of EnergyPlus is to take the
best features of DOE-2 and BLAST and unite them in a single program [Crawley et al,
2001]. The program greatly improves the simulation of whole-building approaches in
design, planning and construction [DOE SIM, 2002]. It allows users to calculate the
impacts of different heating, cooling and ventilating equipment and various types of
lighting and windows to maximize building energy use and occupant comfort. Users can
simulate the effect of window blinds, elector chromic window glazing, and complex day
lighting systems, features not available in earlier DOE software.
3.2 CRITERIA USED TO MONITOR BUILDING OPERATIONAL
PERFORMANCE
It is important to regularly measure and monitor building performance after buildings
are built in order to optimize their performance and learn ways to improve future
buildings [MP, 2002]. This section is again highlighted in Figure 3.1 and is the next
stage of the building life cycle.
3.2.1 Energy Auditing
Energy audits and surveys are investigations conducted on a site with a view to
identifying cost saving measures, reducing the energy used, as well as the detrimental
environmental impact of that site. Their results should be comprehensive and useful to
different groups of users [Bennett, Newborough, 2001], i.e., both the skilled engineer
and the facility manager. They are an essential part of the control of energy costs and
should be carried out every 3 – 5 years. Audits along with routine monitoring of a
facility ensure that energy is utilised cost effectively and through their use, future
consumption could be predicted and strategies could be devised for its reduction
[Bennett, Newborough, 2001].
26

CHAPTER 3
BUILDING ENERGY USE
They involve the collection of utility bills over a predetermined period usually one year,
which are analysed with a view to determining the total energy use for this period. The
individual energy users in the facility would also be examined with a view to
identifying areas where the systems are underperforming. The overall goal is to reduce
the total energy used. By comparing the actual performance of the prime energy users in
a facility with published benchmarks, which will be discussed in the subsequent section,
for similar facilities, areas with potential for energy and hence cost savings can be
identified.
3.2.2 Benchmarking
Benchmarking is the comparison of a business's current level of performance against a
pre-defined point of reference (or benchmark) in order to evaluate performance. This
benchmark may be an industry standard or established, commonly accepted norm. For
example, DETR's Energy Efficiency Best Practice Programme (EEBPP) suggests no
more than 48 kWh/m 2 /yr of energy should be used in heating small offices.
Alternatively, companies may set internal benchmarks to compare performance over
time, or between different sites or operational units. Whether internal or external
benchmarking is used, if the level of energy consumption exceeds the benchmark this
provides an indication that performance can probably be improved, savings made and
environmental impacts reduced. However, climatic conditions need to be taken into
account when comparing benchmarks for facilities to ensure they are applicable in
different regions [Filippin, 2000].
Energy consumption benchmarks for a range of buildings are readily available from
EEBPP. These figures are derived from heating and lighting requirements and do not
incorporate other forms of consumption such as the operation of machinery.
Benchmarks are typically expressed as annual energy consumption divided by floor area
, kWh/ m 2 /yr. The following steps would need to be completed to evaluate how a
particular building is performing:
1. Select buildings (or whole site) to be evaluated for performance against industry
norms;
2. Assemble electricity invoices and add together total electricity consumption for the
whole year (kWh/yr);
27

CHAPTER 3
BUILDING ENERGY USE
3. Calculate the treated floor area of the selected building (m 2 ). Treated floor area refers
only to that area that you heat and light;
4. Divide annual electricity consumption by treated floor area to calculate a
Performance Index in kWh/m 2 per year;
5. Compare the buildings Performance Index, i.e. its particular energy use per square
meter, against industry norms for that building sector;
6. Investigate the cause of each buildings performance. Could performance be improved
or do factors other than heating and lighting account for the difference? If the latter
is true, then the consumption attributable to heating and lighting may be isolated
from other forms by using a technique called degree-day analysis;
7. Repeat steps 1 - 6 to identify heat consumption due to fossil fuels (gas etc.) [EABEC,
2002].
3.2.3 CO 2 Emissions Audit
Each kWh of energy delivered to a building causes atmospheric emissions of the major
greenhouse gas CO 2 from the extraction, processing and delivery of the fuel to its
eventual consumption on site [DETR, 2002]. The more energy used on site by a
facility, the more CO 2 is emitted to the atmosphere and hence the more damage is done
to the environment.
As was explained in more detail in Chapter 2, penalties will be imposed on facility
owners in proportion to the emission of CO 2 by their facility to the atmosphere when
compared to its baseline levels. A facility performing badly in energy terms will face
heavy financial penalties when the KYOTO protocol comes into effect at the beginning
of 2005 [EPA, 2003].
To obtain the figures of CO 2 emitted by a facility, the DETR econ guide 78 provides
conversion from the fuel type used on site to kg of CO 2 emitted and is shown in Table
3.1. Hence by calculating the amount of CO 2 emitted by a facility, it can be determined
if it is performing well, and hence if the penalties imposed will be at a minimum if at
all.
28

CHAPTER 3
BUILDING ENERGY USE
Table 3.1: Conversion to CO 2 emissions from different fuel types [DETR ECON
19, 2002]
3.3 DECISION MAKING SUPPORT FOR STAKEHOLDERS
In order to make the correct decision regarding energy management in the future of any
project; a full analysis of the project is required. This analysis would take various forms,
the first being a performance assessment where key questions are answered: is the
primary objective of the project being met? Are the secondary objectives suffering in
order to meet the primary one?
The second and usually most important form of assessment in any project whether new
or existing is the economic assessment. It is on this single aspect of performance that
most decisions are usually made. In a new project, the capital costs are usually the
driving force, whereas in an existing project the running or lifecycle costs are of main
concern.
It is a combination of this performance and economic data that the “stakeholders” in any
project base their decisions on. A balance must be found between performance and cost
for any project to be successful as well as economically viable.
3.3.1 Decision making criteria on an economic level
When determining the economic viability of a new project or a change to an existing
one, a number of decision-making criteria exist to aid a decision. By far the most
popular criteria for analysing the cost effectiveness of any project is the payback period.
Simply put, this is the time taken for the initial investment to be recouped, with the new
investment properties in place. An example of this would be when energy saving
measures are put in place by a company for say 1000 Euro, saving the company 200
Euro each year. The payback period for these savings would be 5 years. In a survey of
29

CHAPTER 3
BUILDING ENERGY USE
over 100 firms in Australia between 1991 and 1997, the Enterprise Energy Audit
Programme (EEAP) found that 80% of the firms used the payback period as their
primary decision making tool for establishing whether an investment was cost effective
or not. The time that these firms were prepared to wait to recoup their initial investment
varied but the average expected was 42 months [Harris et al, 2000].
Two other criteria used to analyse a prospective investments’ potential are the benefit to
cost ratio and the rate of return on the initial investment. The first relates the benefits of
the investment to the cost of it as a means of comparing one potential investment
opportunity to another. The second looks to establish a figure for the amount of the
initial investment that can be expected by the firm to recoup. In the EEAP survey
mentioned earlier, 53% of companies sited the rate of return on investments as one of
the main ways that they would establish an investments viability, with a 26% rate of
return being the average return sought on the initial investment [Harris et al, 2000].
3.3.2 Energy auditing as a support tool
With performance and economic viability taking such a prime position in any decision
that the stakeholders in any project make, it is essential to have a tool that combines
both in order to get to a best practice solution. An energy audit would be one such tool.
The energy audit would be typically carried out every 3 – 5 years and its results would
typically indicate how well a project is operating, thus giving a performance indication,
as well as an overall economic cost. With this information a correct decision can be
made so as to determine whether the project is viable or not in its current situation or
whether changes are required in order to ensure economic stability.
30

CHAPTER 3
BUILDING ENERGY USE
3.4 BUILDING ENERGY MANAGEMENT SYSTEMS
Building Energy Management Systems (BEMSs) can significantly improve the overall
energy management and performance of buildings. BEMS’s have become a significant
part of the modern building, adding saving potential as well as increasing functionality
[Wang, Zheng 2001]. The operational feedback obtained from the BEMS can cut energy
costs by 10 – 20% compared with individual control operation for each facet of the
system [CIBSE, 2002]. However, for a BEMS to operate effectively it needs to be well
specified and managed correctly by trained staff. An easily understandable Graphical
User Interface (GUI) design is also an essential part of any BEMS to ensure efficient
operation. Recent advances in information technology (IT) have led to developments in
BEMSs [Clarke et al, 2002]. Significant developments have also been made in the
standardisation of communication protocols as well as in the use of web controllers
(Clarke et al, 2002). However in recent years it has become clear that although BEMSs
are being utilised effectively in their primary position of plant control systems, their
strategic functions such as energy monitoring and targeting are being ignored. This in
turn affects the efficiency and the cost of managing the facility [Lowery, 2002].
The monitoring facilities of a BEMS allows plant status, environmental conditions and
energy use to be monitored allowing the user to have a real time understanding of the
operation of the building. This often leads to the user identifying areas of poor
performance, e.g. a period of high-energy usage with no mitigating circumstances.
Energy consumption is at a minimum when the source (electrical energy) tracks the load
perfectly. When a mismatch occurs, energy losses are high [Bhatt, 2000]. Thus through
the use of the BEMS, the buildings energy use can be tailored to meet its load pattern. It
will also achieve the highest possible states of comfort at least cost. In order to achieve
this goal however, the BEMS system must be utilised fully, with the addition of energy
meters, which would provide real time energy consumption patterns of the prime energy
movers of the building. Then through the use of the data logging tools of the system,
these results could be compared for different periods of use, leading to a greater
understanding of the buildings performance. BEMSs can therefore improve building
management by trend logging performance, benefiting forward planning and costing. At
the moment however, problems in User Interface design coupled with the lack of
knowledge on the users part of the system, mean that the BEMS is not being used to its
full potential [Lowery, 2002].
31

CHAPTER 3
BUILDING ENERGY USE
As well as this data analysis, the BEMS system can also serve as an early warning
system so that if set environmental conditions are exceeded, or plant shutdown has
occurred outside operating procedure, an alarm can be set to go off thus making the user
aware that a problem may exist. BEMSs that integrate security, access control and
lighting are now available, which where appropriate can further reduce running costs.
3.4.1 BEMS implementation issues
When a BEMS is to be utilized to improve building performance a number of issues
must first be discussed to ensure its efficient use. The staff designated as the BEMS
users must be trained in its efficient use and must be present when all set points are
chosen as well as being made aware why these set points are chosen. Emulators, which
simulate the heating, ventilation and air conditioning (HVAC) systems response to
BEMS commands, are now being used in the training of their operators [Clarke et al,
2002]. Without this understanding of the system and the events, inefficient use of the
system will result leading to a reduction in any savings that will result from its use. A
significant level of support should be obtained from the BEMS supplier to ensure
smooth operation of the system. User documentation should also be freely available to
those with access to the system.
The other facility that can promote efficient use of a BEMS system is a user-friendly
GUI. With a good graphical, well-displayed GUI, a user can more easily navigate a
BEMS system. Unfortunately, over elaborate GUI design is commonplace in the
industry at this time, leading to inefficient use of the system [Lowery, 2002]. The level
of understanding of the systems use can be greatly improved by allowing the user to see
colour-coded graphs of system operation, thus reducing the specialised training required
to efficiently utilise the system.
A full life cycle costing analysis should take place before any BEMS is installed to
ensure that it is warranted. This should include payback period as a result of energy
consumption savings, and improved maintenance procedures.
3.5 SUMMARY
Building energy use accounts for 40% of Irelands current energy use figures. The
introduction of environmental legislation with regard to CO 2 emissions and the advent
of the EU directive on energy use demands that this area is now being examined with a
view to reducing energy use. This is being achieved by focusing on the three phases of
32

CHAPTER 3
BUILDING ENERGY USE
the building cycle. In each phase, the opportunity exists to minimise the energy used by
the building, from simulation packages being used in the design phase to energy audits
being undertaken in the operational phase. Looking more closely at the operational
phase of the building, the BEMS could be used more effectively to reduce building
energy use. With the correct tools at the disposal of the facility manager, informed
decisions can be made on the running of the facility with the result being a more energy
efficient building.
With Energy efficiency now a key factor in a buildings lifecycle, Chapter 4 examines
the theory behind the whole building energy analysis process. It develops the idea of
examining a building at component level with a view to recognising shortfalls in its
performance at source. This method of building energy analysis could be intrinsic to the
development of a truly energy efficient solution for buildings and to the development of
this software framework.
33

CHAPTER 4
WHOLE BUILDING ENERGY USE
4 WHOLE BUILDING ENERGY USE
This section introduces the idea of whole building energy analysis. It establishes how
building energy use can be more effectively quantified when the constituent
components of the building are looked at individually. It then looks at the various data
transfer methods available to free up this data once it has been collected
ENERGYEYE
Energy Archiving and
Analysis Tool
Monitoring
Energy use
Kyoto Protocol
PHP
MySQL
Environmental
Requirements
Whole Building
Energy Analysis
gbXML
Technology
Unitron & BACnet
Methodology
Real Case Study
THE MARDYKE ARENA
Figure 4.1: Thesis structure schematic focusing on whole building analysis and
data transfer
34

CHAPTER 4
WHOLE BUILDING ENERGY USE
4.1 INTRODUCTION
There are several methods available to identify a buildings’ actual energy consumption,
but one of the most effective is achieved by using the principle of Whole Building
Energy analysis [Vital Signs, 2003]. This involves using the monthly utility records
obtained from the utility company used to supply the building, and disaggregating them
into the components of heating, cooling, fan motor, lighting, equipment, and water
heating energy [Vital Signs, 2003]. By splitting the buildings energy use into its
individual constituents like this, the energy use can be tracked more closely with a view
to identifying areas where optimal performance is not being achieved. This then allows
the contracted engineer to make changes to the system to improve performance.
4.2 DISAGGREGATION OF ENERGY USE
The energy use in the building is disaggregated using the monthly utility bills into the
components of;
• Energy and costs for fan motor operation;
• Energy and costs for lighting;
• Energy and costs for receptacles (e.g. computers, office equipment and small
appliances);
• Energy and costs for water heating;
• Energy and costs for space cooling;
• Energy and costs for space heating.
This data is then displayed for ease of access in pie charts as in Figure 4.2 [CIBSE CDa,
2003] to emphasise which areas are energy intensive, or are displayed in bar charts
versus the benchmarks for the associated building use as in Figure 4.3, Figure 4.4, and
Figure 4.5 [TM 22, 2003] to show whether the building is performing well or not.
35

CHAPTER 4
WHOLE BUILDING ENERGY USE
Figure 4.2: Pie Charts showing the breakdown of energy use in a swimming pool
centre [DETR GPG 219, 2002]
Figure 4.3: Pie Charts showing the breakdown of energy use in a facility by fuel
type [DETR Fuel 1, 2002]
36

CHAPTER 4
WHOLE BUILDING ENERGY USE
Figure 4.4: Bar Chart of Cost of Type of energy used versus Established
Benchmarks [TM 22, 2003]
Figure 4.5: Bar Chart of Energy Use by sector versus Established Benchmarks
[TM 22, 2003]
37

CHAPTER 4
WHOLE BUILDING ENERGY USE
The engineer can now focus more closely on matching the total input energy to the
building (obtained from the utility bills) with the sum of the actual energy used by the
individual constituents of the building. The optimum solution is then that of energy
input to the building equalling energy used (sum of constituent components) in the
building.
CALCULATING ENERGY USE BY COMPONENT
4.3.1 Energy use calculations for fan motors, lighting and receptacles
In order to quantify the amount of energy used by any piece of equipment, it must firstly
be known how often that piece of equipment is used. The building manager must be
interviewed and the operating schedule for that particular piece of equipment studied in
order to determine the answer to this question. It is possible that a fan unit would never
be turned off, but it is more likely that a prescribed schedule exists that utilises it only
when the building is occupied. This information is then recorded for each piece of
equipment.
The next step in the process is to record data from each piece of equipments’ individual
electrical nameplate. Again using the fan unit as an example, the nameplate would yield
the power of the unit at full capacity in kW. Depending on the type of fan used (variable
speed etc), an average value for kW can be obtained and when multiplied by the
aforementioned total hours in operation would yield the total kWh of electricity that the
fan utilises in the period in question (usually 1 year). Then a simple calculation using
the cost of electricity per kWh would allow the engineer to calculate exactly how much
of the associated input energy bill can be attributed to running the fan.
This pattern of load calculation is very similar for the lighting and the receptacles in the
building with the time each piece of equipment is in use firstly being quantified by
interviewing the building manager or from schedule information. The kW rating of each
unit is then obtained and once multiplied by the time in operation would yield the total
load, once the total number of the equipment is summed.
38

CHAPTER 4
WHOLE BUILDING ENERGY USE
4.3.2 Water heating, space heating and cooling energy calculation
The water-heating situation is a little more difficult to quantify. Firstly the occupancy
must be known so that an average amount of hot water utilised by each person can be
calculated. Then the average hot water energy use is calculated from the equation in
Equation 4.1.
Equation 4.1: Calculation necessary to find the energy used in the water heating
process [Vital Signs, 2003]
( OCCxLPDx4.54x(60
− TG)
xODPY)
kWh = 3412*
EFF
Where
OCC = Number of Building occupants (CONSTANT)
LPD = Litres per day per person of hot water use (CONSTANT)
60 = Hot water supply temp (C)
TG
= Ground temp (C)
ODPY = Occupied days of year
EFF
= Efficiency of water heater (usually 0.75 for gas)
If the building is gas heated, then all the electric energy not used by the previously
calculated end users is assumed to be used by the space cooling system. Otherwise a
monthly analysis of outside temperature is required to give the energy used. Since the
fan energy use will have already been calculated by this time, the cooling energy is
defined as the compressor energy and the chilled water and condenser water pumps
energy.
A similar system is used to define the space heating load, as if it is gas heated building
then the total gas input minus that used for water heating will determine the result.
Otherwise the electric load can again be found using the monthly temperature analysis.
After this calculation process has been completed, a clear picture of where the input
energy is being used should exist with any shortfalls in performance being apparent
from higher than expected energy usage in a particular area.
39

CHAPTER 4
WHOLE BUILDING ENERGY USE
4.4 USING WHOLE BUILDING ENERGY ANALYSIS TO ANALYSE REAL
DATA
Whole building energy analysis using utility bills is a very good way to identify the
areas where building energy is being consumed. It does however centre on a lot of
assumed, and unverified quantities such as in the case of the interview with the building
manager for example which is dependant upon the level of knowledge and the energy
management ability of that person [Waltz, 1999]. From this interview, the engineer
takes the time that the end users such as the lights and other HVAC machinery are in
action, and uses these quantities in the calculations used to obtain the kWh’s used by
each component.
If however a situation existed where the data recorded by the sensors in the building at
any time was recorded in a relevant database table, and this table could be accessed with
the data being then inserted into the relevant formulae to determine exactly how much
energy each component was using at any time, a far more accurate picture of whole
building energy use could be obtained.
These sensors would already exist as they would be required by the Building Energy
Management System (BEMS). By accessing the temperature sensors before and after a
heating coil, knowing the mass flow rate of air through the duct that services this coil,
the exact energy that the coil uses can be calculated. If this practice was repeated for
every energy user in the facility as described in the previous section, and using real data
recorded and stored via the various sensors in the facility, the exact whole building
energy use could be determined then compared to the input energy to the facility. This
would allow any utilised energy to be accounted for, hence finding exactly where the
energy is consumed.
It was decided to focus on the HVAC equipment in the facility, as this was a main
energy user in it. And since the correct implementation of this procedure on one
particular area of this equipment could be imitated for each area of it, it was decided to
focus on the AHU in the pool area of the facility, as this had components common to all
AHU’s onsite such as a heating coil for example. If this area of the HVAC system could
be analysed correctly then the whole HVAC system could be analysed in the same way,
and hence the whole building energy use calculated from real data. The pumps and fans
in this unit were not analysed in this project due to time constraints, as they were by far
the lesser energy users when compared to the other components of energy use in the
AHU.
40

CHAPTER 4
WHOLE BUILDING ENERGY USE
4.5 AHU 1 – THE POOL AREA AHU
In looking to establish the energy load of the AHU in the pool area of the Mardyke
Arena, it was first necessary to establish the main users of energy in it. As illustrated in
Figure 4.6, these are the heat exchanger and the afterheater, with their uses now being
explained.
Heat Exchanger
Afterheater
Figure 4.6: AHU 1, The Pool AHU [WN 3000, 2003]
4.5.1 The heat exchanger
As can be clearly seen from Figure 4.6, the heat exchanger is the first piece of apparatus
to impart energy to the incoming fresh air. It does this in a very economical way with
the incoming air receiving its energy from the return airflow from the space to be
maintained, which in this case in the pool area.
In this plate heat exchanger [Hoval, 2003] the warm return air and the cool fresh air are
separated by thin plates and pass each other in cross-flow. No mixing of the two air
streams takes place in order to avoid cross contamination. Heat is transmitted from the
return air to the fresh air by conduction and convection as a result of the temperature
difference between the two air streams. This exchange of energy means that the amount
of work to be done by the afterheater directly after this piece of apparatus is greatly
reduced, so saving energy in the process. This piece of apparatus is shown in Figure 4.7.
41

CHAPTER 4
WHOLE BUILDING ENERGY USE
Figure 4.7: Plate Heat Exchanger [Hoval, 2003]
The load on the Heat Exchanger would be calculated by looking at the temperature of
air before and after it, as well as the mass flow rate of the air flowing through it, and of
course the specific heat capacity of the air, which is a measure of how much energy it
takes to raise the temperature of the air by one degree. The equation, which combines
all of these factors to return a load for the apparatus, is shown in Equation 4.2.
42

CHAPTER 4
WHOLE BUILDING ENERGY USE
Equation 4.2
Q
HE
.
= m a*
C
pma
*( T
OFF
− T
OUT
)
Where
Q
HE
=Load on the heat exchanger (kW)
ṁ a
C pma
=Mass flow rate of air across the unit (kg/s)
=specific heat capacity of the air (kJ/kgK)
T
OFF
=Temperature of the air after the unit (C)
T
OUT
=Temperature of the air before the heat exchanger, i.e. the outside air temperature (C)
4.5.2 The afterheater
Figure 4.8 shows a diagram obtained from the WN3000 BMS software tool, which
shows the common situation in an Air Handling Unit (AHU), of a afterheater being used
to heat the incoming fresh air for use in the conditioned space to provide comfortable
conditions for its occupants, showing that its use was common to other AHU’s.
Afterheater
Figure 4.8: Afterheater as part of an AHU in the Mardyke Arena [WN 3000, 2003]
43

CHAPTER 4
WHOLE BUILDING ENERGY USE
In AHU 1, the pool AHU, the air once it has received energy and had its temperature
increased by the heat exchanger moves through the afterheater to receive its final energy
pickup to reach its required supply temperature.
The load on the afterheater can be calculated by analysing the temperature of air that
entered it, i.e. the air coming from the heat exchanger, and the temperature of air that
left it, i.e. the supply temperature, along with the mass flow rate of air that passed
through it, as long as the properties of the air are known. The equation used to calculate
the load on the afterheater is shown in Equation 4.3.
Equation 4.3: Equation used to calculate the Load on an Afterheater
Q
ah
.
= m a*
C
pma
*( T
off
− T
on
)
Where
Q
ah
=Load on the unit (kW)
ṁ a =Mass flow rate of air across the unit (kg/s)
C pma =specific heat capacity of the air (kJ/kgK)
T
off
=Temperature of the air after the unit (C)
T
on
=Temperature of the air before the unit (C)
4.6 CONCLUSIONS
This software framework would be beneficial if a situation existed where the real data
from the sensors could be obtained and inserted into Equations 4.2 and 4.3, then the
exact loads on the heat exchanger and the afterheater could be obtained for any duration
of time. The data would firstly be obtained from the facility and archived for a one-year
period, then inserted into Equations 4.2 and 4.3 in time-steps, summing each obtained
step to get the annual load. The objective of this project would then be achieved, that
being to quantify the exact annual load on one particular area of a facility in order to
facilitate a whole building energy analysis of the same building in future.
44

CHAPTER 4
WHOLE BUILDING ENERGY USE
4.7 SUMMARY
Whole Building Energy analysis is the disaggregation of energy use into its component
parts allowing for the more accurate evaluation of performance by component. If the
energy use of each component can be looked at individually, shortfalls in performance
become evident far more easily and remedial actions become much easier to undertake,
as the exact cause of the energy inefficiency is known.
In real terms, if a facility is broken down into its individual energy use sectors, HVAC,
lighting etc., and these sectors are broken down into their individual components, then
the energy use can be tracked from source to end use effectively.
Chapter 5 examines ways to develop the extensibility of the BEMS by making the
recorded data interoperable and hence useful to third party analysis applications with a
view to monitoring and reducing building energy use.
45

CHAPTER 5
INFORMATION/DATA MODELLING
INFORMATION/ DATA MODELLING
Chapters 2 and 3 describe the emerging international environmental policy and
associated legislation with regard to the energy performance and certification of
buildings. This places the demand that any effective solution must be an integrated one
that is underpinned by both the building product model (The building product model
contains geometry, dimensions, and technical data and allows for sharing of information
between different disciplines within the AEC) philosophy and whole building energy
use methodology. STEP, the ISO standard for the exchange of product model data,
provides the basis for such an integrated solution [STEPTOOLS, 2002]. Specifically,
STEP Part-28 allows for XML representations of the EXPRESS schemas that comprise
STEP. GbXML is a specific implementation of STEP Part-28 that contains all of the
STEP entities (written in XML) relevant to the design [ISO, 2003], construction and
operation of Green Buildings. Figure 5.1 illustrates the links between the various data
standards and protocols.
STEP Standard
ISO 10303
Part 21 - Relates to
CAD application support
Part 28- Relates to
XML application support
SGML
ISO 8879
XML
gbXML
Building Specific
Version of XML
Figure 5.1: Relationship between STEP, SGML, XML and gbXML
46

CHAPTER 5
INFORMATION/DATA MODELLING
In examining this area the flow of discussion will start by focusing on the front-end of
the solution as illustrated in Figure 5.2, with the technology used shown in Table 5.1
and denoted by the FE (Frontend). This discussion begins by examining the STEP data
standard and continues as follows:
• STEP;
• XML;
• STEP and XML;
• XML DTD;
• GbXML.
Then the focus turns to the backend (BE) of the solution where the raw data is archived
before it is manipulated into gbXML. This is illustrated once again in Figure 5.2 and in
Table 5.1 with the flow being;
• MySQL;
• Opensource Software;
• Database Development.
BACKEND
FRONTEND
MYSQL database
populated by PHP
with sensor data from BMS
GUI
loaded with data from database
gbXML report
generated by PHP
Figure 5.2: Front-end and Backend of Software solution
47

CHAPTER 5
INFORMATION/DATA MODELLING
Table 5.1: Outline of methods and software used in the development of this project
METHOD LANGUAGE TOOL
REPORT GBXML WEB BROWSER
CONTROL PHP EDITPLUS
GUI HTML DREAMWEAVER
F
E
CONTROL PHP EDITPLUS
DATA RELATIONAL MYSQL
CONTROL PHP EDITPLUS
DATA CSV BEMS
B
E
5.1 STEP COMPLIANCE
5.1.1 Introduction to STEP
STEP, the Standard for the Exchange of Product Model Data, is a comprehensive ISO
standard (ISO 10303)[ISO, 2003] that describes how to represent and exchange digital
product information [STEPTOOLS, 2002]. It was first issued in 1994 [Pratt, Anderson,
2001] and has been constructed as a multi-part ISO standard. ISO 10303, which is the
area which refers to the STEP process, focuses on the neutral file approach, where the
files are translated from their natural format into a neutral ISO file format, then
translated from there to the native format of the receiving system [Pratt, Anderson,
2001].
Digital product data must contain enough information to cover a product's entire life
cycle, from design to analysis, manufacture, quality control testing, inspection and
product support functions. In order to do this, STEP must cover geometry, topology,
tolerances, relationships, attributes, assemblies, configuration and more.
To accomplish this ambitious goal, STEP has been constructed as a multi-part ISO
standard. The basic parts are complete and published, while more are under
development. These parts cover general areas, such as testing procedures, file formats
and programming interfaces, as well as industry-specific information. The most
important aspect of STEP is extensibility. STEP is built on the Express language that
48

CHAPTER 5
INFORMATION/DATA MODELLING
can formally describe the structure and correctness conditions of any engineering
information that needs to be exchanged.
5.1.2 The future of STEP
STEP was developed by an international community for all engineering data. And
because it is open and extensible, it can be sure that it will meet design and
manufacturing needs well into the next century. The benefits of STEP are faster design
times and better communication. Concurrent engineering can be achieved by managing
data more efficiently. Product data can be communicated to customers and suppliers
worldwide and data can be archived in a format that will be supported by CAD systems,
as defined in part 21 of the standard, for many years into the future.
STEP is being written into a growing number of contracts worldwide because of the
scope, flexibility, and quality of its product representation capabilities. STEP is
international, and was developed by users, not vendors. User-driven standards are
results-oriented, while vendor-driven standards are technology-oriented. STEP has, and
will continue to, survive changes in technology and can be used for long-term archiving
of product data. STEP is increasingly being recognised by the construction industry as
an effective means of exchanging product related data between CAD systems and
applications [Pratt, Anderson, 2001], and it should enable them to do this with more
success than was previously possible [Ma et al, 2001].
5.2 XML
5.2.1 Background
XML [XML, 2002] is the Extensible Mark-up Language. It is designed to improve the
functionality of the Web by providing more flexible and adaptable information
identification. It is called extensible because it is not a fixed format like HTML (a
single, predefined mark-up language). Instead, XML is actually a `metalanguage' , a
language for describing other languages, which lets the user define their own
customized mark-up languages for limitless different types of documents. XML is
simple, recognisable [Aloisio et al, 1999], and describes a documents structure and
meaning [Badard, Richard 2001]. XML can do this because it's written in SGML as
49

CHAPTER 5
INFORMATION/DATA MODELLING
illustrated in Figure 5.1, the international standard metalanguage for text mark-up
systems (ISO 8879) [XML, 2002].
ISO standards like SGML are governed by the International Organization for
Standardization (ISO) in Geneva, Switzerland, and voted into or out of existence by
representatives from every country's national standards body. HTML is the HyperText
Mark-up Language, a small application of SGML, which is used on the Web. It defines
a very simple class of report-style documents, with section headings, paragraphs, lists,
tables, and illustrations, with a few informational and presentational items, and some
hypertext and multimedia.
XML is intended to make it easy and straightforward to use SGML on the Web as well
as make it easy to define document types and share them across the Web. It defines an
extremely simple dialect of SGML, which is completely described in the XML
Specification. The goal is to enable generic SGML to be served, received, and processed
on the Web in the way that is now possible with HTML. For this reason, XML has been
designed for ease of implementation, and for interoperability with both SGML and
HTML, and it is through its strong links to these languages that it has gained user
acceptance worldwide [Aloisio et al, 1999]. SGML is very large, powerful, and
complex. It has been in heavy industrial and commercial use for over a decade, and
there is a significant body of expertise and software to go with it. XML is a lightweight
cut-down version of SGML, which keeps enough of its functionality to make it useful,
but removes all the optional features, which make SGML too complex to program for in
a Web environment.
5.2.2 XML for data transfer
XML is gaining acceptance today because many problems require its flexibility and
simplicity [Devarticles, 2003]. XML is designed to organise information which makes it
perfect for the data exchange purposes [Badard, Richard, 2001]. It enables the user to
create structured and semi-structured documents that can be transferred and read by
people and programs in multiple formats (for example, pages that can be read on the
web, handheld devices and print). This "multi-use" of content is the driving force
behind the adoption of XML technology.
XML lets business users create structured documents that can be leveraged for multiple
purposes in-house and exchanged to people and businesses around the world.
Information on a network, which connects many different types of computer, has to be
50

CHAPTER 5
INFORMATION/DATA MODELLING
usable on all of them. Public information cannot afford to be restricted to one make or
model or manufacturer, or to concede control of its data format to private hands. It is
also helpful for such information to be in a form that can be reused in many different
ways, as this can minimize wasted time and effort. Proprietary data formats, no matter
how well documented or publicised, are simply not an option as their control still
resides in private hands and they can be changed or withdrawn arbitrarily without
notice. SGML is the international standard for defining this kind of application, with
XML, its cut down version, being the obvious choice to facilitate international user
acceptance.
5.2.3 The Future of XML
XML is user driven with such uses being developed as CAD-CAM, UML (software
design and modeling), and other graphically oriented content. Widespread adoption of
XML technology depends on the DTD, which is explained in a subsequent section, and
schema designs that provide a structure convenient for humans. In other words, people
will use XML only if it is easy and solves a problem.
XML may solve database problems by providing a common format to exchange data.
But databases have been around for a long time, and most database problems have been
solved. XML will be the next generation of Business to Business (B2B) data transfer
language [Yen et al, 2002]. XML is at the moment being used in the transfer of
information between databases and simulation tools and packages, where the data is
stored in a relational database, translated to XML form then fed to the XML compliant
simulation tool [Kokkonen et al, 2003]. This is made possible because parsers that
interpret XML can be built into a wide variety of tools at low cost and in any number of
programming languages, thus aiding interoperability and user acceptance on a global
scale [Kim, 2001].
The use of XML for the purpose of this project is highly recommended because of its
use in association with the ISO STEP standard to represent product data in a generic
format for data transfer as well as its easy to use and structured format allowing it to be
easily displayed over the World Wide Web, which is derived form its predecessor, the
ISO standard SGML as is illustrated in Figure 5.3. However in order to be of most use
in the building field, a specific version of the XML language needed to be developed
which defined the tags and attributes individual to this particular industry, those being
sensors and environmental conditions to name but two. This specific type of XML
51

CHAPTER 5
INFORMATION/DATA MODELLING
(gbXML) would require the construction of its own DTD, which would outline these
new tags and attributes for use within the document.
STEP - ISO Standard
10303-28
SGML - ISO Standard
8879
XML
Figure 5.3: XML derived from two ISO standards for use in this project
5.3 STEP AND XML
The step standard has taken into account the advantages of using XML for business-tobusiness
data transfer in the construction industry and has developed a section
pertaining to the language itself. ISO 10303-28 is a standard for Industrial and
automation systems and their integration and it allows for product data to be represented
and exchanged. Part 28: Implementation methods, more specifically allows for XML
representations of EXPRESS schemas and data to facilitate business-to-business
exchange of data [ISO, 2003] as shown in Figure 5.1 and Figure 5.3. XML can be used
to encode any product information, in this case construction, and make it widely
accessible via the web, and this standard ensures that the data is in standard form so it
can be recognised by all systems using it.
5.4 DOCUMENT TYPE DEFINITIOIN (DTD)
This Document Type Defintion (DTD) is the key to the extensibility of XML and in this
case gbXML. The DTD defines the meaning of the specific tags that are valid in a
gbXML document. For example in the case of gbXML, the sensor tag would be allowed
whereas a MathML function tag would not.
52

CHAPTER 5
INFORMATION/DATA MODELLING
With gbXML a building’s sensor information can be embedded in the associated tags as
defined in the DTD as commissioned by gbXML.org. A DTD is used to define the
structure of an XML document. It lists the set of legal element names, specifies the
hierarchy and gives a listing of the allowable attribute names that are agreed upon by
the different parties involved in creating the particular application of the XML
language. A validating parser can then verify that the received XML document
conforms with the structure as defined by the DTD, thus giving a valid document
[Kokkonen et al, 2003]. It is in this document that the meaning of each of the tags is
described, and a simple verification by the DTD on the gbXML report that is generated,
defines each of the tags, and hence gives meaning to the data enclosed in each tag.
Using this process, independent groups of people can agree to use a common DTD for
interchanging data [W3SCHOOLS, 2003].
When a new use of the XML language is identified, a new DTD is required so that the
tags have meaning. The DTD allows self-describing data exchanges and allows
developers to use their own sector specific syntax [Badard, Richard, 2001]. To use a
metaphor, the tags are like hangers from which the data is hung with each hanger having
a different title. And in the DTD, the title for each hanger is defined, so that in turn what
hangs from them has meaning. Verification by the gbXML DTD defines the tags in a
gbXML document, and verification by an aecXML DTD defines the tags for an
aecXML document.
5.5 GbXML
5.5.1 Background
The Green Building XML schema, gbXML, was developed to facilitate the transfer of
building information essential to designing resource efficient buildings [gbXML, 2002].
This approach allows building designers to focus on what they want to i.e. designing
energy efficient buildings that will meet their owner's needs with minimal cost and
environmental impact. gbXML also allows solutions for the operation, maintenance,
and recycling of buildings [gbXML, 2002]. The explosive growth of XML-based
proposals such as CML [CML, 2003], and MathML [MathML, 2003] show the
progressive nature as well as the strength of the XML language in freeing data for use
by other applications [Kim, 2001].
53

CHAPTER 5
INFORMATION/DATA MODELLING
Now that a means exists to exchange the data in a generic format specific to the
construction industry, the raw data needed to be accessed and stored somewhere before
it was translated into gbXML. This would be achieved using the storage capacity and
flexibility of a database management system called MySQL.
5.6 MYSQL
In order to generate gbXML output from a GUI, this being the front-end of the solution,
it was necessary to manipulate the raw sensor data as recorded by the BEMS and store it
in a database, this being the backend of the solution. This structure is clearly shown in
Figure 5.2. Later in this thesis, the means of interaction between the backend and the
front-end, a server side scripting language called PHP which was developed using the
object oriented software engineering framework will be examined, but for now the
process is introduced.
5.6.1 Background
MySQL [MySQL, 2002] pronounced “my ess que el” is an open source, enterprise
level, multi thread, Relational Database Management System (RDBMS). A consulting
firm in Sweden called TcX, when they realised that the fast and flexible database they
required for their business needs, did not exist developed it. Universities, Internet
service providers and non-profit organisations are the main users of MYSQL, mainly
because its open source, which basically means its widely available and free to use. It
has however managed to permeate the business world because of its fast and reliable
makeup.
5.6.2 Understanding MySQL
MySQL is often confused with SQL, the structured query language developed by IBM.
It is not a form of the language but is in fact a database system that uses the language to
create, manipulate, and show data. MySQL is a program that manages databases, much
like Microsoft EXCEL manages spreadsheets. It controls who can use them and how
they are manipulated. It logs actions and runs continuously in the background. Database
management systems (DBMS) can contain many databases. Users connect to the
database server and issue requests. The database server queries the database and returns
54

CHAPTER 5
INFORMATION/DATA MODELLING
the results to the issuer. Databases such as Microsoft Access are not DBMS’s and would
be a step down from this type of system [SAMSa, 2001].
[SAMSb, 2001] MySQL is a full-featured relational database management system. It is
very stable and has proven itself since its first creation in 1979. It has been publicly
available since 1996. MySQL is a multi-thread server, meaning that every time
someone establishes a connection with the server, the server program creates a thread or
process to handle that client’s requests. This makes for an extremely fast server, as in
effect every client who connects to the MySQL server gets his or her own thread.
As MySQL was an open source resource, this software development and sharing
resource is now examined.
5.7 OPEN SOURCE SOFTWARE
5.7.1 Background
The basic idea behind open source is very simple: When programmers can read,
redistribute, and modify the source code for a piece of software, the software evolves.
Open Source software is made freely available to anyone who wants it as long as they
agree to the licensing terms [Krogh, von Hippel, 2003]. When developers are given
access to the source code used to create a software application, they can use their
knowledge to make changes to it with the end goal being the improvement of the overall
package [Lakhani, van Hippel, 2003]. This can happen at a speed that, if one is used to
the slow pace of conventional software development, seems astonishing
[OPENSOURCE, 2002]. Open source software came about as a result of many software
companies providing not only a product but also the source code as well, so that
consumers could see how the program worked and modify it to meet their own
particular needs. Other motivations for the open source movement include the
intellectual gratification that the developers get when they make a particular
advancement [Bonalcorsi, Rossi, 2003], and the fact that a good contribution can result
in an enhanced reputation for the developer [Lakhani, van Hippel, 2003].
Open Source development originated from university and research environments, where
the recognition from peers was the prime motivational factor behind its emergence, and
at present there is an estimated 120,000 developers actively involved in the movement
[Bonalcorsi, Rossi, 2003]. Today, there is an increased interest in Open Source
development because of the success of its products [Fugetta, 2003].
55

CHAPTER 5
INFORMATION/DATA MODELLING
5.8 DATABASE DEVELOPMENT
5.8.1 Previously encountered problems in data storage - flat file storage
The first real type of computer data storage mechanism was achieved using flat files as
a storage media. However a number of problems were encountered using this such as
the slow down experienced in operational efficiency when the file became very large.
Another problem encountered was the lack of searchabilty in the flat file system, as the
data was not ordered by nature. Even if the data were written to the file in ordered form,
each entry would have to be read in and checked individually, in order to find patterns
of information. Also concurrent access to the file was not permitted, so the queue for
people to access the data could become impractical in real situations where a number of
people could require access to the data at the same time.
Random data access was also a problem. If it was required to add or delete entries to the
file, the whole file would have had to be read in to memory, changed and then rewritten,
and with a large data file this becomes somewhat of a chore. Also the issue of security
causes problems as beyond file permissions there was no way of granting user
privileges based on an administrator user type situation where users are given limited
access with only the administrator having full read/write capabilities.
5.8.2 Relational databases
Relational databases were the solution to all of the aforementioned problems of flat file
storage [SAMSb, 2001], as they offered faster access, were searchable, offered
concurrent and random access, and most importantly offered a built in privilege system.
5.8.2.1 Relational database concepts
Relational databases are by far the most commonly used type of database. They are
made up of relations, more commonly known as tables, each table being filled with
data. Each table is made up of columns and rows, with the values in the rows
corresponding to the data type specified by the column it also occupies. The relational
database usually consists of multiple tables and uses a key to relate one table to another,
a key being an assigned value given to each row of data.
56

CHAPTER 5
INFORMATION/DATA MODELLING
5.8.3 Data normalisation
The normalisation process of database design is essentially a simplification process
whereby the database tables are stripped to their basest and most efficient levels. It's the
art of organizing your database in such a way that your tables are related where
appropriate and flexible for future growth [Informit, 2003]. The sets of rules used in
normalization are called normal forms. If your database design follows the first set of
rules, it's considered in the first normal form. If the first three sets of rules of
normalization are followed, your database is said to be in the third normal form.
If we take the example of a flat table with many columns in it, we can see how
normalisation works. In a flat table there is no relationship between multiple tables and
all the data we could possibly want is at our disposal. However, this is not necessarily
efficient, as some data is repeated and could be housed in a much more user friendly
and usable manner. Here is where data normalisation comes in.
Normalisation is based on the principle of minimising redundancy of information
[Elmasri and Navathe, 2000], so to start with the data is taken to first normal form. The
rules for the first normal form include:
• Eliminate repeating information;
• Create separate tables for related data.
So by eliminating any white space or information that occurs more than once, the table
is made more efficient. Also the fact that more than one table exists means that a one-tomany
relationship of one topic to many others also exists, so again making the
information more easily accessible. The next step is to put the tables into the second
normal form. The rule for the second normal form is:
• No non-key attributes depend on a portion of the primary key.
In plain English, this means that if fields in the table are not entirely related to a primary
key, more work must be done. The final step is the third normal form and the rule for
this is;
• No attributes depend on other non-key attributes.
57

CHAPTER 5
INFORMATION/DATA MODELLING
This rule simply means that the tables must be examined to see if more fields exist that
can be broken down further and are also not dependent on a key. Think about removing
repeated data and the answer is clear. Third normal form is usually adequate for
removing redundancy and allowing for flexibility and growth.
Now that the database layout has been discussed with a view to minimising repetition of
data and hence minimising the space required to store the data, the code used to access
and manipulate the data, PHP code, is examined with a view to firstly minimising it,
and secondly making it as readable, usable and simple to operate as possible. This was
achieved using the object-oriented approach to programming.
5.9 SUMMARY
Table 5.1: Outline of methods and software used in the development of this project
METHOD LANGUAGE TOOL
REPORT GBXML WEB BROWSER
CONTROL PHP EDITPLUS
GUI HTML DREAMWEAVER
F
E
CONTROL PHP EDITPLUS
DATA RELATIONAL MYSQL
CONTROL PHP EDITPLUS
DATA CSV BEMS
B
E
In examining the three phases of the building life cycle, the operational phase and its
associated data returned via the BEMS could be an answer to the energy efficiency
problem if it could be freed up. The STEP standard is a standard for the exchange of
data within the construction industry. A relationship existed between STEP and another
data transfer language called XML, which itself had a building specific sibling in
gbXML. This language allowed building specific data to be enclosed in gbXML tags for
exchange purposes at the front end of the solution as shown in Figure 5.4 with the tools
used shown in Table 5.1 denoted by the F.E.
58

CHAPTER 5
INFORMATION/DATA MODELLING
The database at the backend of the solution as described in Figure 5.4 and with the tools
used in Table 5.1 denoted by the B.E., which would be the starting point for the
archived data to be enclosed in these building specific tags, is commonly used today in
data driven projects. MySQL, a database management system, with its fast, flexible and
open source, meaning that it was free to use, nature, was the clear front runner.
Database design now becomes the next dilemma with data normalisation being the key
to the early stage of the design process for the software tool to be designed in this thesis.
With the technologies now introduced which will achieve this extensible energy
analysis mechanism, Chapter 6 expands on the whole building energy analysis theme by
examining the individual components of the HVAC system in a prototype facility, the
Mardyke Arena, by zone with the end result being a clearer understanding of where
exactly the energy is used in the system.
59

CHAPTER 7
SPECIFICATION OF REQUIREMENTS
SPECIFICATIONS OF REQUIREMENTS
The thesis structure schematic in Figure 7.1 illustrates the focus shifting to the software
side of the development process, with the various technologies available being
scrutinised to find the most suitable. Once obtained, the suitable software will be
implemented to facilitate the end goal of a working prototype software tool.
ENERGYEYE
Energy Archiving and
Analysis Tool
Monitoring
Energy use
Kyoto Protocol
PHP
MySQL
Environmental
Requirements
Whole Building
Energy Analysis
gbXML
Technology
Unitron & BACnet
Methodology
Real Case Study
THE MARDYKE ARENA
Figure 7.1: Thesis Structure schematic with the focus now on the software aspects
of the thesis
60

CHAPTER 7
SPECIFICATION OF REQUIREMENTS
7.1 PRESENT SITUATION AND PROPOSED NEW DIRECTION
7.1.1 Data storage
A BEMS is a microprocessor-based system, which provides the facility to control any
building service [Action Energy, 2003]. The current Building Energy Management
Systems (BEMS’s) in operation today do not as a rule archive the building data that
they monitor. Instead they periodically dump this data, outputting it in the form of a
non-searchable, not automatically manipulatable printout, to be looked over by the
contracted engineer on a bi-monthly (or some similar timeframe) basis. This data once
in hard copy form is now much more difficult to work with as any calculations must
now be done by hand rather than by the much faster and more efficient means of a
computer processor.
As well as losing the flexibility of this data, the ability to track trends that might have
shown themselves had this data been analysed over a larger period of time is also lost.
By tracking trends in building performance with a view to reducing higher usage
periods, the performance and hence the cost of running a building, can be greatly
improved. As soon as this data is discarded from the BEMS and taken out of electronic
format, this trend logging becomes much more difficult, if not impossible.
7.1.2 Interoperability
Another problem of the current building performance analysis situation is that since so
many different manufacturers develop the different devices that monitor, manage and
analyse building performance, no common data transfer protocol exits between them.
By this it is also meant that the output from each data analysis tool, or data-monitoring
tool may be completely different and hence not compatible with the other. At present
much of the data exchange takes place in paper form owing to a lack of integration
between tools [Sun, Lockly, 1997]. This in turn means that any further analysis of the
results that each piece of equipment obtains now becomes much more difficult to work
with, with much of the time being exhausted in translating the data from each device or
tool to a common form for further analysis. If an exchange standard was to be used, an
open architecture for exchanging data between software packages or simulation tools
could be designed [Kim, 2001].
61

CHAPTER 7
SPECIFICATION OF REQUIREMENTS
7.1.3 More accessible BEMS
One of the main issues that most building managers encounter on a daily basis is the
fact that users need to be skilled in the operation of a BEMS in order for it to function
efficiently, and any data that it collects needs to be analysed by the contracted engineer
in order to make any changes to the system to improve performance. It is partly due to
these facts that it is widely reported that BEMS users are not making full use of their
systems, so ensuring that the building they control is not being most efficient in its
energy use [Lowry, 2002]. Many advances have been made in making the BEMS more
accessible from off site, with these advances closely following those made in the
Information Technology (IT) sector [Clarke et al, 2002], but as yet no means really
exists that couples the remote flexibility with an easy to operate system. This is where
the Internet and its flexibility come in.
One in six people use the Internet in North America and Europe [Internet Indicators,
2003]. These figures support the idea that the Internet is easily accessible and familiar to
a large portion of the population. Any solution using this media would instantly be
accessible to most because of the existing knowledge of the media that already exists. If
the flexibility that the Etherent/Interent offers, allowing users to access the same
information from anywhere in the network/world, is coupled with its familiarity to
users, its full power can begin to be seen.
IT networks are a standard part of most non-domestic buildings and their use as the
communications system for BEMSs has emerged as the next step in developing
intelligent building control. The vast majority of these systems are based on the
Ethernet and most employ Transmission Control Protocol/Internet Protocol (TCP/IP) as
the communications procedure for data transport. The Local Area Networks (LANs)
that the controllers are linked to are then linked to the Ethernet which in turn is presided
over by a supervisory Windows based PC which governs the whole system, thus
enabling the BEMS to take advantage of the IT networks high speed and flexibility
[CIBSE, 2002].
To emphasise this point, a situation where a facility manager for a large organisation
with many buildings under his/her responsibility is taken as an example, say at a
university campus. The BEMS is accessed over the university network, and
immediately the data accessed in a user-friendly format, which allows him/her to make
decisions on the efficient running of each building. If trend logging and a method to
transfer data to off the shelf building analysis tools is also included, the amazing
62

CHAPTER 7
SPECIFICATION OF REQUIREMENTS
potential that such a solution would offer to not only reduce building energy cost and
management, but also to enable the archived data to be utilised for future analysis and
transmission begins to become apparent.
7.2 ARCHIVING
The BEMS is primarily a monitoring and control tool used by a building’s manager to
keep energy usage as economical as possible while maintaining the required
atmospheric conditions so as not to exceed the comfort levels of the buildings patrons. It
could however do so much more.
In order to monitor and control a buildings performance, the BEMS calls data from the
controllers, which in turn call data from the actual sensors fitted in the building. This
data is then displayed on the BEMS, and compared with the relative set points to ensure
that the required level of control is being obtained. The data is not as a rule archived by
the BEMS, and as mentioned earlier in Section 7.1.1, is more often than not, stored as
print outs, or even discarded altogether. It is this data, which would be archived with a
view to analysing it, in order to determine if the building is performing well. Then if it
is not, it would be possible to determine which areas of it, and at which times it is not
doing so, with the end result being a more energy efficient building that is cheaper to
run.
7.2.2 Database options
Now that the reasons why the data was archived from the controllers via the BEMS had
been identified and expanded on, the database system to be used to archive the data had
to be researched in order to find the most suitable. A number of choices were available.
7.2.2.1 Microsoft Access
The first system examined was the Microsoft offering called ACCESS. This was
appealing due to its simplicity and the fact that it was a Microsoft development and
hence was widely available. Microsoft Access was first released in 1992, and because of
the fact that it cost just $99, it managed to claim a large chunk of the database industry
[Getz, Litwin, Gilbert 1999]. Microsoft has released 4 major upgrades since then
culminating in Access 2000. Access does not however support the ANSI SQL standards
in their entirety with it instead using a sort of hybrid version called Access SQL that
performs most of the same commands. But actions such as granting users different
63

CHAPTER 7
SPECIFICATION OF REQUIREMENTS
levels of permissions for example are not available using Access SQL, but can be
obtained using the Jet 4 SQL 92 extensions, which add to the usability of the Access
SQL if taking somewhat from the simplicity of use of the system. Some sub-queries or
more complex queries that ANSI SQL outlines are also not supported by Access or the
Jet 4 SQL 92 extensions [Getz, Litwin, Gilbert, 1999].
As soon as it was realised that SQL coupled with XML support seemed to be the keys to
achieving the required solution in this project, i.e. perform calculations on retrieved data
with the end result being usable, informative data, SQL Server 2000, another Microsoft
offering, was the next logical choice of database system to be researched.
7.2.2.2 SQL Server 2000
SQL Server 2000 is the latest and most powerful version of Microsoft’s data
warehousing and relational database management system, and offers a newly developed
support system for XML. This facility allows SQL query result-sets to be returned
directly in XML format, so meaning that no secondary translation is needed on the
client side in order to view the returned data on a web browser. SQL Server 2000 uses
Transact SQL to execute statements. This is a dialect of SQL and is ANSI SQL 92
compliant [Vieira, 2000]. This lead to the conclusion that a database system, which is
based on SQL and is capable of outputting XML; the two most important functions of
the software tool, was now available. However the high cost of SQL Server 2000
[Microsoft, 2003] was a cause for concern so the search for an efficient, cost effective
solution continued.
7.2.2.3 MySQL
A far easier and much more cost-effective alternative to SQL Server 2000 was MySQL.
This was an open-source offering, which meant it was free to use for everyone who
wished to use it. It was also fast and highly flexible. It was developed by a consulting
firm in Sweden called TcX, when they realised that the fast and flexible database they
required for their business needs, did not exist [SAMSb, 2001]. MYSQL is a program
that manages databases, much like Microsoft EXCEL manages spreadsheets. It controls
who can use them and how they are manipulated. The MySQL database management
system contains an enormous amount of functionality and power. Using a simple set of
commands for inserting, retrieving, deleting and updating data, a complex set of databases
64

CHAPTER 7
SPECIFICATION OF REQUIREMENTS
and tables could be developed. There are several reasons why MySQL was chosen. Here are
some of them [Devarticles, 2003]:
• MySQL can be accessed and manipulated from a huge number of popular
programming languages. A complete set of API’s is provided for MySQL in C,
C++, Eiffel, Java, Perl, PHP, Python, and Tcl;
• MySQL was written in C and C++, and is completely optimized for both the
Unix and Win32 platforms. It uses in-memory hash tables, thread-based memory
allocation, kernel threads that are capable of utilizing multiple processors, and
highly optimized individual pre-compiled class libraries;
• MySQL contains built-in support for every common field type, including
FLOAT, DOUBLE, CHAR, VARCHAR, TEXT, BLOB, DATE, SET and
ENUM;
• MySQL supports a subset of advanced querying and grouping functions,
including GROUP BY and ORDER BY, COUNT(), AVG(), STD(), SUM()
MAX() and MIN();
• MySQL allows per-server password allocation. Also, any passwords that are
passed to the MySQL engine for authentication are fully encrypted;
• MySQL supports a variety of connection methods including TCP/IP sockets,
Unix Sockets, and named pipes for Windows NT/2000;
• MySQL is a free download, and comes complete with all of the tools needed to
begin its use. The Win32 version includes a GUI based management and
configuration tool named winmysql.exe.
MySQL is also one of the most stable database systems available. Due to this and the
fact that it was PHP compliant allowing XML output and allowed user authentication
which will all be utilised in this project later as well as the fact that it was open source
and so free to use, it was chosen as the database system for our project.
7.3 DATA TRANSFER AND INTEROPERABILITY
As mentioned in Section 7.1.2, the output from different manufacturers products more
often that not are in different formats, leads to increased analysis times, and costs. It
also adds to the possibility of mistakes in analysis being made due to the need for
translation to a common format. If one format could be chosen that each device outputs
to, one can only imagine the time and money that would be saved. No more would the
65

CHAPTER 7
SPECIFICATION OF REQUIREMENTS
CAD developer have to spend countless man hours changing the 2-d drawing
dimensions to the 3-d format that he/she requires, or the building simulation analyst
have to input every data point individually. The information could now be received in
the standard form and the program run to simulate the data, so enabling the user to
concentrate on the end goal with more time to spend analysing the results and hence
obtaining a cheaper and ideally better solution.
7.3.1 Choice of directions
This however is not a new topic of conversation and has been attempted before.
However, no true universally acceptable data exchange format for the construction
industry currently exists. So in order to continue this work, the next generation of data
transfer protocol that could overcome the problems that prevented the previous attempts
to facilitate this end goal had to be chosen. Efforts in data interoperability include the
STEP standard and the IFC standards developed by the international alliance for
interoperability (IAI) [IAI, 2002, Hassanain et al, 2001], so this is where research
began.
7.3.1.1 Industry Foundation Classes (IFC’s)
The Industry Foundation Classes (IFC’s) [IFC, 2002] were the first topic to be looked at
with a view to using them as the method of data exchange. The IFC’S were developed
by the IAI (International Alliance for Interoperability). The IAI is a division of the ISO
(International Standards Organization), the body that controls the IGES
[IGES, 2003] and STEP data standards and was established in 1996 with a view to
founding interoperability in the industrial process in all construction orientated fields,
allowing computers used by the participants of this industry to exchange product
information [Hassanain et al, 2001]. The IFC system is a data representation standard
and file format for defining architectural and constructional CAD graphic data as 3D
real-world objects. This was mainly so that architectural CAD users could transfer
design data to and from rival products with no compromises [Cad Info, 2003]. The
IAI’s IFC system comprises a set of definitions of all the objects encountered in the
building industry, and a text based structure for storing those definitions in a data file.
When using the IFC standard, the time taken to manually input data is cut because the
data can be input directly from the IFC file created by the IFC compliant tool or
package [Karola et al, 2002]. As the development work on the basic IFC set for graphic
66

CHAPTER 7
SPECIFICATION OF REQUIREMENTS
representation slowly moves toward completion, there have been moves to extend its
scope to supporting data associated with estimating and project management and similar
non-graphic data, although the IFC system is essentially a graphic representation or
object modelling system and essentially aids interoperability for design tools [Karola et
al, 2002]. For these reasons the next option for data exchange was now examined, this
being the STEP standard mentioned in relation to the IFC’s.
7.3.1.2 STEP Standard
STEP [STEP, 2002], the Standard for the Exchange of Product Model Data, is a
comprehensive ISO standard (ISO 10303) that describes how to represent and exchange
digital product information. It was first issued in 1994 [Pratt, Anderson, 2001] and has
been constructed as a multi-part ISO standard. ISO 10303 focuses on the neutral file
approach, where the files are translated from their natural format into a neutral ISO file
format, then translated from here to the native format of the receiving system [Pratt,
Anderson, 2001].
The basic parts are complete and published, while more are under development. These
parts cover general areas, such as testing procedures, file formats and programming
interfaces, as well as industry-specific information. The most important aspect of STEP
is extensibility. STEP is built on a language that can formally describe the structure and
correctness conditions of any engineering information that needs to be exchanged.
Industry experts use this language, called EXPRESS, to detail the information required
to describe products of that industry. These "Application Protocols" form the bulk of the
standard, and are the basis for STEP product data exchange [STEPTOOLS Library,
2003]. STEP is increasingly being recognised by the construction industry as an
effective means of exchanging product related data between CAD systems and
applications [Pratt and Anderson, 2001], and it should enable them to do this with more
success than was previously possible [Ma et al, 2001]. From this research it became
clear that the STEP standard was more related to product information than recorded
data, which would not have been the main area of interest in this project, however it was
while researching the STEP standard that part 28 of it was uncovered, which detailed
how to represent data in XML form. This was now to become the next area to be
researched.
67

CHAPTER 7
SPECIFICATION OF REQUIREMENTS
7.3.1.3 XML
XML [XML, 2002] is the Extensible Mark-up Language. It is designed to improve the
functionality of the Web by providing more flexible and adaptable information
identification. It is a powerful mechanism for humans and computers to exchange data
[Aloisio et al, 1999], as the data even though functional in it’s formatting, is also
readable. It is called extensible because it is not a fixed format like HTML (a single,
predefined mark-up language) [XML, 2002]. Instead, XML is actually a
`metalanguage', a language for describing other languages, which lets its user design
their own customized mark-up languages for limitless different types of documents.
However, since XML is very similar to HTML in its make-up, universal acceptance of
the language is guaranteed [Aloisio et al, 1999]. XML enables its user to create structured
and semi-structured documents that can be transferred and read by people and programs in
multiple formats (for example, pages that can be read on the web, handheld devices and
print). XML lets business users create structured documents that can be leveraged for
multiple purposes in-house and exchanged to people and businesses around the world.
Since E-commerce is made up of two types of data transfer, business to business (B to B),
and business to customer (B to C), it is essential that a transfer norm exists for transferring
this data. XML will be this next generation B to B data transfer language as it allows each
developer to develop their own data exchange format [Yen, 02]. This flexibility of design that
developers now have has contributed to the explosive growth of XML based proposals, such
as the Chemical mark-up language (CML)[CML, 2003], and the Mathematical mark-up
language (MathML) [MathML, 2003], showing its strength in a growing market [Kim,
2001].
7.3.1.4 GBXML
The Green Building XML schema, gbXML, was developed to facilitate the transfer of
building information essential to designing resource efficient buildings [gbXML, 2002].
With gbXML a building’s sensor information can be embedded in the associated tags as
defined in the Document Type Definition (DTD) as commissioned by gbXML.org
[GbXML Schema, 2002]. This DTD is the key to the extensibility of XML and in this
case gbXML. This DTD enables self-describing data exchange and allows developers to
define their own syntax [Badard, Richard, 2001]. It is in this document that the meaning
of each of the tags is described, and a simple call against the DTD by the gbXML report
that is generated via a parser, defines each of the tags, and hence gives meaning to the
data enclosed in each tag. This area now became the core of this project with an end
result of a gbXML report of the building data being the main objective.
68

CHAPTER 7
SPECIFICATION OF REQUIREMENTS
7.4 USER INTERACTION ANALYSIS AND DESIGN
The present situation of building control centres on the facility manager and more
importantly the contracted building services engineer. Because of the complex nature of
the BEMS, the facility manager becomes responsible for the everyday running of the
system, with any encountered problems being referred to the contracted engineer. This
leads to a situation where any reported problem with the system requires a site visit
more often than not by the engineer in order to rectify it. There are two problems with
this situation:
1) The engineer is required to visit the site no matter how small the problem;
2) The facility manager is cut from the problem-solving loop because of the
complex nature of the BEMS.
Although work has been undertaken to make BEMS’s more accessible over the World
Wide Web, on the whole wireless technology and easily accessible user interfaces have
not been embraced in the building control situation. It is in these areas that the need for
improvements can be clearly seen.
Firstly, the ability to generate reports from the data that the BEMS collects in the form
of gbXML documents would be required, thus enabling them to be forwarded to the
building services engineer, allowing him/her to carry out analysis on them from their
working environment without the need for costly and unnecessary site visits. The
engineer could then put the recommendations found into practice either via the facility
manager or via the Web by using their own browser as the interface to the BEMS on
site.
Secondly, a more easily understandable user interface would be created, focusing on the
areas that make most sense to the facility manager, i.e. energy consumption, and
monetary cost. By providing read outs in this format, much like an energy audit, the
manager can see very quickly if the building is performing well, and if it is not, in
which areas it is not doing so, in turn allowing him/her to provide accurate information
to the engineer so he/she can more quickly analyse why the shortfall in performance is
occurring.
69

CHAPTER 7
SPECIFICATION OF REQUIREMENTS
7.4.1 XML Report generation
Generic data transfer has for a long time been the goal of the software engineer, and this
is no different in the engineering environment. In the building services environment, the
data displayed on the BEMS systems is obtained from sensors via controllers, which
may be from different manufacturers and hence use different data interoperability
protocols. So the problem in this project was finding a common language that the data
could be translated into in order to facilitate generic data transfer.
As previously examined in Section 7.3, the IFC protocol, the STEP standard, and
various other options for data transfer were examined and analysed. However XML was
the clear leader because of its extensibility and flexibility. Also the fact that a schema
had been developed specifically for the building services environment (gbXML),
coupled with the fact that the development of the Ethernet as the communications
backbone to current BEMSs means that XML will be available as a front end tool for
data exchange [CIBSE, 2002], meant that it was the preferred option.
On deciding to use PHP as the intermediary language in this project, the ability with
PHP’s built in functions, to output archived data directly to gbXML which cut
development time significantly, and added to the usability of this package was now
available.
The User Interface was now examined, as this was the next step in the creation of the
software environment.
7.4.2 User interface design
Having identified the problems with the current BEMS User Interfaces in operation,
attention now focused on the creation of a more easily accessible, more informative
solution for the non-specialist. The goal was to use the accessibility of the Internet and
the already well-defined knowledge of user preference in display and navigation of web
GUI’s, to deliver a more usable building services GUI to the facility manager. It was
also necessary to couple this Internet design process with the equally well researched
area of everyday GUI design, so essentially offering the user the best of both worlds.
7.4.2.1 Web design
Introduction
70

CHAPTER 7
SPECIFICATION OF REQUIREMENTS
Users of Web documents do not just look at information but instead they also interact
with it [Web Style Guide, 2002]. The Graphical User Interface (GUI) of a computer
screen comprises the interaction metaphors, images and concepts used to convey
function and meaning on it. However most of the guidance needed to design, create and
assemble a web page does not differ greatly from the current methods used in print
media. GUI are designed to give people control over what they are viewing onscreen. It
is important to put a great emphasis on the target audience, and to design for both the
experienced and uninitiated user.
Design and layout
Graphic Design creates a visual logic and allows a balance to be found between
delivering information and aesthetic pleasure. Without the visual impact of shape and
colour, pages appear uninteresting and will not appeal to the viewer so any information
locked in them will also be lost to the viewer as happens in the first page in Figure 7.2.
The primary task of graphic design is to create a strong, consistent visual hierarchy
where important elements are emphasised and content is organised logically as well as
predictably ensuring viewer interest and confidence. Graphic design is the management
of visual information using page layout and graphics to lead the reader’s eye to the
points and information of interest to them as occurs in the second page in Figure 7.2
where a menu to the left of the screen is highlighted allowing the reader to easily locate
it. Also the individual points in the content are separated by paragraphs to aid
readability and understanding. A balance must be obtained between visual appeal and
information organisation in order to ensure the optimal usage of the GUI.
71

CHAPTER 7
SPECIFICATION OF REQUIREMENTS
Figure 7.2: Examples of page designs [Web Style Guide, 2002].
The most effective designs for general viewing use a careful balance of text and links
with small images ensuring pages are loaded quickly into the browsers even when using
a slow modem for connection.
The design grids that underlie most well designed paper publications are equally
necessary when designing electronic documents. HTML can be used to create complex
and highly functional information systems. Haphazardly mixing graphics and texts
detracts from the usability of the GUI, so a balanced and consistent design scheme again
serves to reinforce user confidence.
Figure 7.3: Examples of page layouts [Web Style Guide, 2002].
72

CHAPTER 7
SPECIFICATION OF REQUIREMENTS
Navigation
Most user interactions in web pages are done through hypertext links to various
documents. The main problem in this area is to establish a sense of knowledge of where
one is in relation to the entire site. In order to overcome this problem, graphic identity
schemes or text navigation bars are used to give the user a confidence that they can find
what they are looking for without wasting time. Users should also be always able to
return to the first introductory page or, “home” page as it is otherwise known, of the
GUI and to other major navigation points in it with these links being located in
consistent locations on every page.
Repetition is not boring but instead gives the GUI a consistent identity as well as
reinforcing a confidence in the user that they can navigate freely. A consistent approach
to navigation and layout allows users to adapt quickly to the design as well as to
confidently predict the location of the information that they are looking for.
Page headers and footers
In order to create a unique visual identity for the site, careful graphic design is needed.
A “signature” graphic and page layout will allow the user to grasp almost immediately
the function of the document in relation to the overall GUI. The header element should
contain a prominent title so again reinforcing the users sense of “place”. Well-designed
page footers offer the user a set of links to other pages and also some essential
information about the site such as copyright information or contact details. Both the
header and footer should be located on every page in the site to reinforce confidence in
navigation but to also identify each page of the site as being a part oft the overall GUI.
Conclusions
Consistency of design and navigation and the use of the correct layout tools are the two
most important areas in GUI design. If these are addressed properly a user-friendly
atmosphere is created where information is easy to find and once found is pleasurable to
view.
73

CHAPTER 7
SPECIFICATION OF REQUIREMENTS
7.4.2.2 Principles of GUI design
A well designed Graphical User Interface establishes consistent and predictable
behaviour on the part of the user, and pulls them into a situation where they suspend
disbelief and treat the objects they encounter onscreen as real, such as buttons, tools etc.
[Shneiderman, 1992]. Shneidermann identified 8 areas where care should be taken in
developing a well-commissioned user interface, these “8 Golden Rules” as he called
them are:
1) Strive for consistency – the most frequently violated principle. Relies on
consistent sequences of actions being incorporated in similar situations so
reinforcing the users sense of confidence in their surroundings. Identical
terminology should be used in prompts, menus and help screens again to build
user confidence;
2) Enable frequent users to use shortcuts – as the frequency of use increases so too
does the desire to cut the amount of time taken and the interaction needed to
reach ones end goal. Frequent knowledge users appreciate abbreviations and
hidden commands to ease the burden of use;
3) Offer informative feedback – for every operator action there should be some
form of system feedback;
4) Design dialogs to yield closure – sequences of actions should have a clear
beginning, middle and end. The informative feedback at the completion of a
group of actions gives the user a sense of accomplishment;
5) Offer simple error handling – in so far as is reasonably possible, design the
system so that the user cannot make a fatal, irreversible error. If an error is
detected, the system should yield some kind of helpful advice for the user to
negate their actions;
6) Permit easy reversal of actions – in so far as is possible, actions should always
be reversible, relieving any anxiety that the user might feel towards moving
forward through the system;
74

CHAPTER 7
SPECIFICATION OF REQUIREMENTS
7) Support internal locus of control – experienced users strongly desire to feel in
control of the system, so difficulty in obtaining information or slow practice of
actions leads to dissatisfaction on their part;
8) Reduce short-term memory load – displays should be kept as simple as possible,
so to be the least strain possible on the short-term memory banks of the user.
These principles if followed and utilised correctly in the user interface design process
will ensure that the user feels comfortable in the environment created for them which in
turn means that the information that the interface is home to will be much freer to
access.
7.4.3 Choice of web server
Now that the design for usability issue has been discussed in relation to the design of
the GUI to be implemented to ensure universal acceptance of this software environment,
the next step was to look at the means through which the GUI would be displayed over
the Internet. This was to be achieved through the use of Web Server software which is a
continuously looping server that waits for requests from the client for documents over
the network [Web Servers, 2003]. Once it receives these requests, it takes the
corresponding actions in order to execute the script or return the required document as
the client wished.
In order to choose web server software for this project, the two most widely used were
compared with the more efficient and suited to this project being the one chosen
[Network Computing, 2003].
7.4.3.1 Microsoft Internet Information Server (IIS)
The first Web Server software to be examined with the view of using it in this project
was the Microsoft Internet Information Services (IIS) version 5.0 server. This is the
latest version of Microsoft's IIS and comes as part of the NT Option Pack.
IIS has superior performance across the board than most of its competitors and can
serve up pages for viewing at a faster rate, however it does have some notable
drawbacks in the form of its frequent need to reboot, its lack of support for non
windows platforms and the security issues that accompany it. IIS is managed with a
75

CHAPTER 7
SPECIFICATION OF REQUIREMENTS
Microsoft Management Console (MMC) plug-in, which is both efficient and easy to
use, this being one of its major advantages over its competitors, most of which use
command line, text based management, making them sometimes difficult to manage.
In comparison with its competitors, IIS outperformed Apache on Linux, for the serverside
include (SSI) testing. However, IIS proved to be on par only with the Perl-based
CGI tests with the Apache Server.
7.4.3.2 APACHE Web server
Apache Server quietly and reliably serves up content for most Web sites in existence,
according to NetCraft's Web Server survey [Netcraft, 2003]. Apache is freely available
on the Internet and has earned the reputation for being the most reliable Web server
available. Unfortunately, reliability does exact a small price as Apache Server's
management isn't much more than text editing and a few useful server-status Web pages
that are difficult to manage when compared to IIS’s management system.
Apache Server's greatest strengths are its huge amount of end-user support, nearly
universal platform support, and rapid bug fixes and product cycles. It is however not as
robust and feature-rich as Microsoft's IIS. Apache Server's performance was generally
marginally inferior to that of Microsoft's IIS, particularly on the SSI tests.
Configuring and managing the Apache Server is done almost entirely from the
command line or text editor proving again to be a bit more difficult especially for
novice users.
7.4.3.3 Conclusion
Microsoft’s IIS is the chosen option for Web Server technology in this project due to its
strengths in management and configuration, with an easy to use management console,
when compared to Apache’s text editor command line control. It was also available to
this project for no extra cost as the option pack that came with the computer system
purchased for this project contained it.
7.5 LINKING THE TECHNOLOGIES TOGETHER
Now that the technologies were decided upon, it was time to decide how to link them
together to achieve a solution. The backend MySQL database where the raw data
would reside would need to be accessed. This data would then need to be operated on to
get the correct figures for analysis. Once operated on this data would then need to be
76

CHAPTER 7
SPECIFICATION OF REQUIREMENTS
displayed on the World Wide Web via a user-friendly user interface (UI) on a web
browser. Once here the user would not only need to be able to navigate through it, but
also download it in a generic, interoperable form, i.e. gbXML. The key to achieving all
this data and linking the aforementioned technologies together turned out to be a server
side scripting language called PHP.
7.5.1 PHP
PHP (Hypertext Preprocessor) [PHP, 2002] is a widely used Open Source general
purpose scripting language that is especially suited for Web development and can be
embedded into HTML [PHP MANUAL, 2003]. PHP has many functions and interfaces
and is used on many Web based interactive server systems [Inoue et al, 2002]. PHP
code is executed on the server, which means that the client would receive the results of
running the script, with no way of determining what the underlying code may be. This is
especially useful when considering the security issues of this software environment and
the sensitive data that it handles. PHP can be used on all major operating systems,
including Linux, many Unix variants (including HP-UX, Solaris and OpenBSD),
Microsoft Windows, Mac OS X, RISC OS, and probably others. PHP has also support
for most of the web servers today. This includes Apache, Microsoft Internet Information
Server, Personal Web Server, Netscape and iPlanet servers, Oreilly Website Pro server,
Caudium, Xitami, OmniHTTP, and many others. With PHP one is not limited to
outputting HTML. PHP's abilities includes outputting images, PDF files and even Flash
movies, but where it is most interesting and useful in this project is its ability to output
any text, such as XHTML and any other XML file [PHP MANUAL 2, 2003]. PHP can
auto generate these files, and save them in the file system, instead of printing it out, thus
allowing the user to easily set up a method for data transfer using XML as the transfer
media. PHP also has a better relationship with database management systems such as
MySQL than ASP or JAVA [Inoue et al, 2002], so making it the perfect choice for this
project.
7.5.2 Proposed process using PHP
Since MySQL was PHP compliant, SQL could be embedded in PHP tags and used to
access the database. The predefined MySQL access functions of the PHP language
allowed access to the database, the ability to perform an SQL query on the data, then
using loops, and various other operations, the ability to operate mathematical
77

CHAPTER 7
SPECIFICATION OF REQUIREMENTS
procedures on the raw data in order to output the results required to variables. Once in
these variables, the embedded HTML could be used to display them on the World Wide
Web via a browser. This in essence was the solution. The user could now navigate the
data obtained directly from the database like a web page, something that most people
are very familiar with due to the popularity and extensive usage of the World Wide
Web.
The final part of the solution was the output of the data in a gbXML report. This again
was achieved using PHP, as the data once in variables, was inserted between the
relevant gbXML tags, as defined by the schema [GbXML Schema, 2002], and written
to a new file for download, or just for viewing. This allowed the user to view the data in
gbXML form, and hence freed up the data for use with any XML compliant software
tool once it was downloaded. Each individual part of this process will be discussed in
the next chapter with examples of the code used in each situation also expanded on.
7.6 SUMMARY
The three key objectives of this project are to archive the building data with a view to
analysing it, to make the recorded data generic so that it can be exchanged between third
party analysis tools and finally to develop a user friendly GUI. A number of software
options were available in each area, such as SQL server and ACCESS at the database
side of development, but these were both passed over in favour of MySQL, a database
management system that was both fast and flexible but also free to use.
A number of options also existed in the data interoperability field with the IFC’s, STEP
standard being just two, which apply to the construction industry. A language called
XML, and its sibling gbXML, which is more specific to the building services industry
was however more suited to this project.
The final area to be examined in respect of the software to be used was the GUI. A
number of web servers, which are display mechanisms for World Wide Web
applications, are in existence, with the Apache system firstly being examined. This
however was passed over in favour of IIS as it was freely available to the project and
had a more accessible user interface so speeding up the development process.
Once these technologies had been chosen, a means to interact between them to arrive at
the final solution was required. A server side scripting language called PHP was chosen,
which could interact with the MySQL database and output gbXML through IIS to the
World Wide Web, so finalising the technologies to be used in this project.
78

CHAPTER 7
SPECIFICATION OF REQUIREMENTS
With the technologies chosen, the design process needed to be examined. This will be
done in Chapter 8 with the View/Control/Model design process based on development
centering on the GUI being used as the foundation for this process.
79

CHAPTER 8
DESIGN
DESIGN
8.1 INTRODUCTION
Chapter 5 and Chapter 7 described the software architecture from the front end (FE) and
backend (BE) of the GUI scenarios. The following chapter describes in more detail the
specifications as outlined in these previous Chapters. These will link together as shown
in Figure 8.2 in order to generate a self-updating Graphical User Interface (GUI) with
real time BEMS data. As Chapter 5 discussed, the Backend, database, portion of the
package and the Front-end, report generation from the GUI, of the package will be
examined in greater detail. The model, control view software design process will be
adhered to, with the GUI being the driving force behind the development of the
software environment. It will be designed firstly using the concept of data stubs, and
then gradually stage by stage be incorporated with real data from the model layer by
means of the control layer. Figure 8.1 shows the flow of data from the backend to the
front-end of the package with Table 8.1 showing the tools used to achieve this flow in
more detail.
BACKEND
FRONTEND
MYSQL database
populated by PHP
with sensor data from BMS
GUI
loaded with data from database
gbXML report
generated by PHP
Figure 8.1: Flow of data from the backend to the front-end of the package
80

CHAPTER 8
DESIGN
Sensor 1 Sensor 2
Sensor 3 Sensor 4
UC16
UC16
UCC 4
UDS 10
Data transferred over college network using TCP/IP
PC with WN3000
BMS software logs data using ccReport
CSV file
MS Scheduler runs PHP script which
uploads data from CSV file to MySQL Database using embedded SQL
BACKEND
MYSQL
DATABASE
FRONTEND
Generation of gbXML Reports
GUI
Figure 8.2: Data flow in order to arrive at GUI
The method used to design this software tool is based on the model, view, control,
software engineering method as Figure 8.3 depicts, where the Graphical User interface
is the driving force behind the development process [Liant, 1992]. It is essentially the
end result that dictates the data that is required and the way in which this data is
manipulated from the raw recorded data. So in this case, the values and graphs that will
be displayed onscreen in the GUI (VIEW layer) are chosen, the data that is required to
obtain these values is obtained (Model data layer), and finally the manipulation of this
81

CHAPTER 8
DESIGN
data (Control layer) is achieved to obtain the necessary end result, this being a two way
process as data is constantly being called from the GUI and obtained from the Model
layer by means of the Control mechanism.
VIEW Layer - (GUI)
CONTROL Layer - (PHP)
MODEL Layer - (DATA)
Figure 8.3: Principles of software design process used in the development of this
package
The software and programming techniques used in this process are outlined in Table
8.1, with two data model layers, one the original CSV files obtained from the BEMS
using ccReport and the other the MySQL database that houses the data when archived.
82

CHAPTER 8
DESIGN
Table 8.1: Software flow details
METHOD LANGUAGE TOOL
REPORT GBXML WEB BROWSER
CONTROL PHP EDITPLUS
GUI HTML DREAMWEAVER
F
E
CONTROL PHP EDITPLUS
DATA RELATIONAL MYSQL
CONTROL PHP EDITPLUS
DATA CSV BEMS
B
E
Initially, the design process was centred as discussed on the GUI, as this would be the
area that the third party user would be interacting with, and the correct detailing of it
was a necessity. Once the correct format of data had been arrived at by contacting the
Environmental Protection Agency (EPA) [EPA, 2003], and the Department for the
Environment, Food and Rural Affairs (DEFRA) [DEFRA, 2003] in the UK, as will be
discussed in Section 10.8.3, the next step was to look at the raw data that would be
coming from the sensors on site and look to manipulate them in order to arrive at the
necessary values for display.
This was achieved by focusing attention on one area of the GUI and using as close an
approximation of real data as was possible to obtain, as if the scale of the process could
be kept to a minimum then it was easier to develop and could be later expanded to the
rest of the GUI. An approximation was initially used, as the actual data was not
available at this early stage. This approximated, static data used in the development of
the GUI is known as a data “stub”, with the each data “stub” being replaced by real data
one by one as the development process successfully progresses [Liant, 1992] and is
shown in Figure 8.4.
83

CHAPTER 8
DESIGN
GUI
Analysis Section
Graphical Section
STUB
STUB
STUB
Figure 8.4: Data Stubs used in development process as applied to the analysis
section only
In order to illustrate this development process an example is offered. One of the first
and most important areas to be developed in the GUI was the energy analysis portion of
it. It needed to show the monthly energy use for each component in AHU 1 in kWh,
kWh/m 2 , and cost, all of which would serve to help the third party analyst in their
inspection of the facility’s energy use. In order to do this, the data would need to be
eventually extracted from the CSV file and inserted into the relevant tables in the
MySQL database. Then once there, it would need to be accessed and the calculations as
outlined in Section 9.4.1.2 performed on it, in order to have the correct figures available
for display by the PHP code in HTML in the web browser.
In order to effectively design the GUI for this area of the project, the data stubs were
used to bypass this complicated procedure, as shown in Stage 1 of Figure 8.7,
illustrating once again how the GUI drives the development, with the GUI being
illustrated in Figure 8.5. Once the look and functionality of the GUI were fine tuned, the
stubs could begin to be replaced one by one with real data obtained from the BEMS.
84

CHAPTER 8
DESIGN
Figure 8.5: Final GUI design with data from stubs
In order to be able to replace the data stubs with real data from the BEMS, the real data
needed to be accessible to the GUI as shown in Stage 2 of Figure 8.7. By this it is meant
that the data needed to be manipulated into such a format that it could be uploaded to
the MySQL database and then called on demand by the GUI from there, this being the
control layer of the design process. PHP was used to access the database from the GUI
end of the process using SQL queries embedded in the code to choose the relevant data
and manipulate it for display. It also turned out to be the answer to the file manipulation
situation, as it was used to access the flat CSV file and manipulate the data for upload to
the database as well as take care of the upload process while it was doing so. This entire
process and its intricacies will be expanded on in the following sections.
The final step to removing the static stubs was to be able to access the data in the
MySQL database on demand from the GUI with no data stubs remaining in this section
of the GUI as is shown in Stage 3 of the process illustrated in Figure 8.7. Links were
added to the GUI as shown in Figure 8.6, which launched PHP script to obtain the
relevant data then perform calculations on it. Once the correct values as defined by the
initial GUI design process using the Data Stubs had been arrived at in this way, the real
85

CHAPTER 8
DESIGN
data was displayed in the web browser replacing the stubs that had previously been
there. This left one fully functional area of the software package, with data stubs still
present in the other areas waiting for the development process to extend to their section.
Figure 8.6: Screenshot of first area of package to be developed using the data stub
process
86

CHAPTER 8
DESIGN
VIEW Layer - GUI
ANALYSIS Section
STAGE 1
STUBS
VIEW Layer - GUI
ANALYSIS Section
STAGE 2
STUBS
MODEL LAYER accessed via the CONTROL method
VIEW Layer - GUI
ANALYSIS Section
STAGE 3
MODEL LAYER
via CONTROL method
Figure 8.7: Model/View/Control design methodology
87

CHAPTER 8
DESIGN
This process is now explained in more detail in the next sections, with the programming
code used in each situation being illustrated to further clarify the process. Since the GUI
was the driving force behind the development process, it is here that the explanation
begins.
8.2 VIEW LAYER - GUI DESIGN
At present, the user interface of a BEMS, even though highly graphical in most cases, is
still not easily understandable and usable by the people that operate the facility on a
daily basis, the facility managers. It is because of this lack of knowledge that the
problems in the GUI persist [Lowry, 2002]. It is here that the introduction of a web
frontend can add to the functionality of the BEMS.
Because of the fact that one in six people use the Internet on a daily basis [Internet
Indicators, 2003], it became apparent that this media was the best option available to
maximise the usability of the GUI.
IT networks are a standard part of most non-domestic buildings and their use as the
communications system for BEMSs has emerged as the next step in developing
intelligent building control. The vast majority of these systems are based on the
Ethernet and most employ Transmission Control Protocol/Internet Protocol (TCP/IP) as
the communications procedure for data transport. The Local Area Networks (LANs)
that the controllers are linked to are then linked to the Ethernet which in turn is presided
over by a supervisory Windows based PC where the GUI will reside [CIBSE, 2002].
It was required to keep the layout simple and easily navigatable with easy to follow
links leading the user to the information that they required. In order to do this Hypertext
Mark-up Language (HTML), as explained in Section 5.2.1 was utilised, which is the
language most commonly used on the Internet in site design. It was decided to use a
concept known as version control to keep development as efficient and reversible as
possible.
8.2.1 Versioning of software
Version control [SAMSb, 2001] is the management of change as applied to software
engineering. Version control acts as a kind of archive situation where any code used can
be stored and shared. Imagine a situation where the programmer tries to improve the
code but instead accidentally stops or diminishes its functionality, or another situation,
where the client or programmer decides that an earlier version of the site was better.
88

CHAPTER 8
DESIGN
Without version control, the earlier, functionally superior version of the site would be
lost.
Version control is the tracking of code. It means that when a site is considered
functional, the code used is locked and stored in this format so that any changes made to
it are tracked and can be regressed should the need arise. When the code has moved on
to the next level of functionality, this versioning takes place once again with the newly
created code once again being locked and stored. This would be version two of the site
and would now be used as the base level of code, should it be considered that it was
superior to the first version of the site. However if this was to be found to be untrue with
later testing, the first version of the site would still be locked and stored and could once
again be used. Three versions of the GUI design in this project were used before the
final design was decided upon.
8.2.1.1 Version 1 - Frames
The first GUI layout that was used was based on HTML frames, which split the browser
window into parts defined by the programmer. By using these frames an easy to use
navigation bar was made available to the user at all times, with the content requested
being loaded into the main segment of the browser window as shown in Figure 8.8.
Although HTML frames allowed the GUI to be divided accordingly onscreen for easy
viewing, it was not the most efficient method as some of the content might not fit in the
window so scroll bars would be needed to view all. This although not a fatal flaw did
take from the usability, and coupled with the fact that HTML frames were also not that
efficient in terms of their usability, with some browsers not having the ability to display
them, the decision was taken to keep the version of the site but move on and try
different approaches to layout.
89

CHAPTER 8
DESIGN
Figure 8.8: Screenshot of Version 1 of Energyeye Software tool, which used HTML
frame
8.2.1.2 Version 2 – HTML “INCLUDES”
The next design method examined was HTML “includes”. This meant that instead of
loading content into a frame as in the previous version, the file was included in a parent
file in the program itself. By doing this, the file was loaded directly into the browser
window and appeared as the frames would have but without the associated browser
support problems. The design is shown, as it would appear in the browser window in
Figure 8.9. This method of screen display was perfectly usable and effective but did
lack a little professionalism in its look so again the decision was taken to name it as
Version 2 for data retrieval purposes and move on in the hope of finding an even better
solution.
90

CHAPTER 8
DESIGN
Figure 8.9: Screenshot of Version 2 of Energyeye Software tool, which used HTML
“includes”
8.2.1.3 Version 3 – Macromedia STUDIO MX Site
On doing some research into web design and the techniques used to design a
professional looking and functional web site, it was decided to invest in some software
to help in the design process. A package called Macromedia Studio MX [Macromedia,
2003] was purchased which allowed the web designer to create very professional web
sites while minimising the code required as templates and other devices were available
in the software. One of the tools that came with it the StudioMX package was called
Dreamweaver MX, which did a lot of the hard coding for the developer, allowing
him/her to concentrate more on the actual layout and design of the site. Using
Dreamweaver MX a much more usable GUI was created which was able to link to the
database using hand coded HTML and PHP. This form of prototyping was necessary in
the design process to ensure that the GUI was designed effectively. In Dreamweaver
MX HTML tables were used to organise the look and feel of the site. These were a lot
like frames and includes as they too split the browser window into areas that
information could be displayed. They however were much more flexible than either of
the previous methods and allowed a navigation panel and logo header to be added to the
91

CHAPTER 8
DESIGN
GUI that remained on each page of the site to serve as a tool to aid navigation around it.
Screenshots of the final design are shown in Figure 8.10 and Figure 8.11.
Figure 8.10: Screenshot of Final Site designed using Macromedia Studio MX
Figure 8.11: Screenshot of Energyeye Site designed using Macromedia Studio MX
92

CHAPTER 8
DESIGN
Now that the design of the GUI had been decided upon and fed with data stubs in order
to finalise the layout, the model layer was examined in order to continue the
development process towards using real data.
8.3 MODEL LAYER - DATABASE DESIGN
On examining the BEMS in the prototype situation in the Mardyke Arena on campus, it
was noticed that the data obtained from the sensors via the controllers could be output in
a Comma Separated Value (CSV) file. Note was also taken of the format of the output
file, as this would shape the eventual form of the database tables that the data would
reside in on upload to the MySQL database. This data would also need to be
manipulated so that only the required data was uploaded to the database. Through the
use of data normalisation as explained in more detail in Section 5.8.3, the final form of
the database tables was decided upon, with each sensor essentially having its own
database table, where just the raw recorded sensor data i.e. temperatures or relative
humidity’s, were recorded. This data was however date stamped and set with an ID so
as to label each data point individually.
Table 8.2 shows the data obtained directly from the WN3000 ccReport tool .The first
draft of the database table “pool area temperature” was designed to coincide with the
headings in the CSV file obtained from the pool area sensor directly. But as only the
actual temperatures were required, only this data was uploaded to the table, with the rest
being disregarded. By doing this, the data would go straight into the relevant table
column on upload. Properties were also applied to the database columns based on the
type of data that they would contain. The column where the sensor data itself would
reside was given a “float” which is a “real” number, property. This was a number with a
defined amount of decimal places. By doing this the size of the number recorded for
both visual and storage capacity purposes was defined. The ID column, which would be
used to give each row of data a unique identifier so that later when SQL queries called
the data, each row would be unique due to this column, allowing the SQL to more easily
pick certain rows for analysis, was included in each table in the database, so that data
obtained at the same time would have the same ID identifying it.
93

CHAPTER 8
DESIGN
Main Controller
loaded with
Strategies
Pool Controller linked
to main Controller
Seconds
between
readings i.e. 15
minutes
Table 8.2: CSV file Output from BEMS [WN3000, 2003]
UC24 - 004 - AHU
UCC4 - 001 01 Pool AHU Pool Area Temperature 900 °C
32976.9792 192 28.63 28.58 28.49
Assuming that for each sensor, a CSV file could be logged and retrieved as described
earlier, a table was created in the MySQL database, named according to the area
monitored, i.e. a table called “supply temp” would archive data from the supply
temperature sensor. Since creating tables and various other operations carried out in
MySQL are now being discussed, the method used will briefly be discussed, that being
the DOS prompt dialog box. It was here that the command to be carried out was
inserted, with MySQL initiating it. For example the code necessary to show existing
databases stored in the MySQL database is listed in Figure 8.12 and takes the form of
the MySQL interface language SQL. Later more of this process would be automated
using HTML links in the GUI linked to server side PHP which would have the SQL
queries embedded in it. For now this basic method would suffice. But in order to arrive
at this more efficient solution the control layer was now looked at with a view to finding
an effective solution to the data manipulation and retrieval problems.
Figure 8.12: Dos Prompt Dialog box used to access MYSQL database
94

CHAPTER 8
DESIGN
8.4 CONTROL LAYER – PHP
The GUI had been designed and was ready to receive data and the database was up and
running in an efficient, if manual form. An automatic method of accessing the data, and
manipulating it into the format desired was examined. This was achieved using the
flexibility and language integration of PHP.
8.4.1 Previous approach
Normally, as mentioned in Section 8.2, the MySQL database was accessed using DOS
and SQL queries. However once the result was obtained, it was not usable in any other
programs but was just available to view. A way to access the data and output it to a web
front-end, so that the user could examine it anywhere on demand, was however the
desired result. More complex operations on the data would also need to be performed so
that the output was more streamlined to what the user needed. PHP was able to do just
this.
8.4.2 PHP and MySQL
PHP has built in functions for accessing a MySQL database. These functions allowed
the user to input a username and password, so PHP and MySQL could determine if the
user had the required user privileges to carry out the command required, access the
database to retrieve data from it, and retrieve the information itself from the individual
tables by means of SQL queries embedded in the script as in Table 8.3. This code
snippet is in fact a function call to a “classes” file, which is the Object Oriented
approach to programming. The actual PHP function that connects to the database is the
“mysql_connect” function, which is shown in Table 8.4 in the way it appears in the
“classes” file. It is these native PHP functions that allow a connection to the database to
be easily made.
95

CHAPTER 8
DESIGN
Table 8.3: Code snippet of a PHP connection to a MYSQL database
require("classes..php");
This is an Object Oriented Programme so this file is
where the query is outlined and the connection to the
database made
//initiate connection
$conn = new Connection;
$conn->connect("mardyke_arena", "user", "pass");
Defines the database to be connected
along with a username and password
//call the function from classes_new.php to display the monthly kwhr loads onscreen
$display = new Display;
$display->display_monthly_cool_load_data();
This function outlines the display
parameters that the result array will
undergo
Table 8.4: Actual PHP to connect to database
class Connection
{
function Connection()
{
return true;
}
function connect($dbname, $user, $password)
{
mysql_connect("localhost", $user, $password) or die(mysql_error());
}
}
mysql_select_db($dbname) or die(mysql_error());
Once obtained, this data could then be stored in variables, to be output to the GUI in a
browser window using loops and other operations embedded in HTML in order to
display the results as required. An example of the code used to do just this is given in
Table 8.5.
96

CHAPTER 8
DESIGN
Table 8.5: Code snippet of the output process using embedded HTML
$iTotal = 0;
while( $line = mysql_fetch_array($result, MYSQL_NUM))
{
$iTotal +=$line[0];
$Total_CO2=$iTotal*0.5;
$Total_cost=$Total_CO2*100;
Result array, which is now manipulated to get
required fields
}
echo "\n";
echo "\n MONTH\n";
echo "\n".$iTotal."\n";
echo "\n".$Total_CO2."\n";
echo "\n".$Total_cost."\n";
echo "\n";
Embedded HTML, which is output using PHP.
Variables store the final figures, which are
displayed using the HTML tags, here a table
$start=$start+$i;
$i+=$i;
}
A loop is used to do calculations on each set of
results and then display them in turn
echo"\n";
The beauty of using PHP with embedded SQL queries to access the MySQL database
was the fact that all the complicated mathematical operations to be done on the raw
archived data could now take place in the server side code. This lead to a situation
where the user could access the database, pick the data wanted, multiply/divide or
perform a complex mathematical operation on the data using the SQL query, then store
the result in a variable for output to the GUI. All the hard work is done behind the
scenes (server side), with the results alone displayed to the user.
It was now required to do analysis on the archived data in order to track energy
consumption and greenhouse gas emissions using this process. Complex SQL queries
were used in order to both call the data, and perform mathematical operations on it. For
example, to quantify the load on an afterheater over a predefined period, the post-unit
temperature, pre-unit temperature, as well as the mass flow rate of air travelling across
the unit would have been needed from the database. This data would then be used to
calculate the required loads using the mathematical equation shown in Equation 8.1, to
achieve the load on the unit. The results of this operation would again be stored in an
array, which would then be displayed by the browser the same way as before using
embedded HTML with a complex SQL query like that in Table 8.6.
97

CHAPTER 8
DESIGN
Equation 8.1: After heater Load Calculation
Qhc
.
= ma*
C *( T
pma s
− T )
p
Q
hc
= Afterheater Load (kW)
m
a
= Mass Flow Rate of Air passing through the apparatus (kg/s)
C
pma
= Specific Heat Capacity of Air (kJ/kgK)
T s
T p
= Supply Temperature (C)
= Pre-afterheater Temperature (C)
Table 8.6: Complex SQL used to calculate the load on the afterheater from
Equation 8.1
function calc_cool_load()
{
$query = "select (Mass_flow_rate*1.02*(post-unit_temp – pre_unit_temp)) from Massflowratetable, posttemptable and
preunittempteable";
$result = mysql_query($query) or die(mysql_error());
}
8.4.3 gbXML Report generation
The last and most important area that required the functionality of PHP to operate was
the output of gbXML reports. This language would in the future be the data transfer
language used to exchange building specific data once the building industry
incorporates it into existing and developing software tools. To do this the filesystem
functionality of PHP was again used. A blank file was created and opened each time a
report was to be generated. The “tags”, which are the method of data identification used
in gbXML, were then written into this file in gbXML form by PHP using the “fwrite”
file function. The tags were assigned to the data based on what they were describing in
agreement with the schema for gbXML as defined at gbXML.org. [gbXML Schema,
2002]. For example, the results of a query to the database that returned supply
98

CHAPTER 8
DESIGN
temperatures would have been placed between tags that identified the figures as the
same. This can be seen more clearly in the code snippet in Table 8.7.
Table 8.7: Code snippet of the process required to output gbXML using PHP
filesystem functions
$conn = new Connection;
$conn->connect("mardyke_arena", "ken", "hatrick");
$sql = "SELECT * FROM real_supply_temp where id

CHAPTER 8
DESIGN
Table 8.8: gbXML file as created using PHP and real BMS data obtained from
WN3000
91.70032
0.330121152
0.000330121152
7.3360256
Specific gbXML tags
and attributes, which
define the building
specific data
Actual value
enclosed between
gbXML tags, which
give it meaning
8.4.3.1 Displaying XML reports - XML and XSL
Once these reports have been transferred to the next user for examination, they could
either directly use the XML protocol in applications containing an XML import
function, or examine the results in their basic XML form using another language, one
specifically designed to display XML documents called the Extensible Stylesheet
Language (XSL). XSL allows developers to format XML documents for World Wide
Web viewing [Kim, 2001] and is a standard recommended by the World Wide Web
Consortium. The first two parts of the language (XSLT and XPath) became a W3C
Recommendation in November 1999 [W3SCHOOLS, 2003b,]. The full XSL
Recommendation including XSL formatting became a W3C Recommendation in
October 2001 [W3SCHOOLS, 2003b,]. XSLT is the most important part of the XSL
Standard. It is the part of XSL that is used to transform an XML document into another
XML document, or another type of document that is recognized by a browser. A
common way to describe the transformation process is to say that XSL uses XSLT to
transform an XML source tree into an XML result tree with the parts of the source
document that do not match a template will end up unmodified in the result document
[W3SCHOOLS, 2003b].
100

CHAPTER 8
DESIGN
The use of XSL to transform the gbXML report generated in this package for use by the
third party analyst will be returned to in Section 10.8.4 of this thesis, with a prototype
application described.
Now that a way existed to free up the archived data for transfer over the World Wide
Web, the next important issue that needed to be addressed was the security issue as the
data was of a sensitive nature.
8.5 SECURITY - USER AUTHENTICATION
Because of the nature of the archived data, some system of user authentication needed
to be put in place in order to filter the personnel that could view the information. This
was especially important when the security issues that using the World Wide Web as a
transmission media are considered. Http is a stateless protocol, meaning that it has no
way of maintaining state between two transactions. When a user requests one page then
moves on to another, HTTP does not have a way of tracking whether both requests
came from the same user [SSL, 2003]. This becomes a problem when users of sensitive
information need to be tracked, maybe only allowing certain authorised people to view
the data over a number of pages. Because HTTP is stateless, users cannot be tracked
from page to page, so data in turn cannot be kept secure. A number of options were
available in this area, and a brief description of each as well as the reasons that they
were passed over or finally chosen follows.
8.5.1 Session control
The idea of session control [SAMSb, 2001] is the ability to track a user’s movements in
a web site over a single visit or session to the site. If this could be done a situation could
easily be set up where a user is logged in and allowed access to secure data based on
his/her authorisation privileges. Sessions in PHP are driven using a unique session ID,
a cryptographically random number. This session ID is generated by PHP and stored on
the clients side for the duration of their session in either a cookie, which is a small piece
of information that scripts store on the user’s machine or it is passed along through
URL’s, the address bar of the site itself. Once the session ID is stored and the sessions
variables registered, the user has access to the secure information.
These cookies have some associated problems however. Some browsers do not allow
cookies and some users may have disabled cookies as they do involve having foreign,
uncontrollable information stored on their machine. PHP uses cookies by default then
101

CHAPTER 8
DESIGN
sends the session ID through the URL should cookies fail. It is for this reason and the
fact that sessions are new to PHP and so have associated bugs that session control was
passed over in favour of another approach.
8.5.2 Secure Sockets Layer (SSL)
The SSL suite was first developed by Netscape to facilitate secure communication
between web servers and web browsers. It has since been adopted as the standard way
for browsers and servers to transfer sensitive information.
Digital certificates encrypt data using Secure Sockets Layer (SSL) technology, the
industry-standard method for protecting web communications developed by Netscape
Communications Corporation [Netscape SSL, 2003]. The SSL security protocol
provides data encryption, server authentication, message integrity, and optional client
authentication for a TCP/IP connection. When a digital certificate is installed, the
security is simply turned on by the browser or web server as they are pre-installed.
SSL comes in two strengths, 40-bit and 128-bit, which refer to the length of the "session
key" generated by every encrypted transaction. The longer the key, the more difficult it
is to break the encryption code. Most browsers support 40-bit SSL sessions, and the
latest browsers, including Netscape Communicator 4.0, enable users to encrypt
transactions in 128-bit sessions which is far more secure than the 40 bit system.
Server certificates are designed to protect the site and visitors to it by installing a digital
certificate, which lets the user:
• Authenticate the site - A digital certificate on the server automatically
communicates the site's authenticity to the users web browser, confirming that
the user is actually communicating with the site, and not with a fraudulent site
stealing credit card numbers or personal information;
• Keep private communications private - Digital certificates encrypt the data
visitors that exchange with the site to keep it safe from interception or tampering
using SSL technology.
SSL would be something to examine in future, but for the present purposes of the
package, it was too expensive and over secure in relation to the data archived. It would
however be the next logical step should the package grow in stature.
102

CHAPTER 8
DESIGN
8.5.3 Password protection
Password protection is the simplest form of user authentication available to the
administrator of any database/website. It involves the registration of authorised users
and the storage of passwords individual to each user in a database table. A login page is
then utilised by the administrator to allow the client to input their name and password,
which in turn is checked against the stored authorised usernames and passwords in the
database table. If an exact match occurs then the client is allowed access to the secure
pages.
This format is not however 100% secure and could not be utilised on its own in order to
achieve a secure package. Because the Internet address bar is clearly visible to all in the
browser window, the “secure” pages could just be accessed by inputting the individual
page addresses, thus bypassing the login page. This is where the previously mentioned
idea of session control would have come in, tracking the user from page to page so
making sure that a valid password/username combination had been entered at the
beginning of the users session.
8.5.4 Chosen option
The option finally decided upon to ensure the security of the archived data, was a
combination of an initial username/password form as in Figure 8.7, with encryption
enabled leading, once verification is obtained, to a javascript pop up window. This pop
up window was chosen because of the security issues that using the get/post method of
password control allowing users to view log in information in the address bar and also
allowing users to return to logged in pages by directly inputting the address of the
“secure” page. By using the pop up window, the user is allowed to view the archived
data only in the window itself which has no address bar, so not allowing a return visit to
the secure area without first being verified as a registered user via the
username/password form. This is shown in Figure 8.13 and Figure 8.14. Once the user
has finished viewing the secure data, they can log out of this area and return to the nonsecure
area to continue using the software environment.
103

CHAPTER 8
DESIGN
Figure 8.13: Screenshot of login page
Figure 8.14: Screenshot of secure archive – notice the lack of address bar
104

CHAPTER 8
DESIGN
8.6 SUMMARY
The model, view, control method of software development is a method whereby the
GUI is the driving force behind the development process. It is here that the process
begins with static, prototype data being employed to allow the GUI to be designed
initially. These portions of static data otherwise known as data stubs are removed
progressively as the functionality of the tool develops, and interaction with the model
layer via the control layer is facilitated and replaced with real data from the model layer.
This process was used to initially design the GUI for this software environment, as user
interaction was a prime concern in this project. Data stubs were used and the design
finalised using Macromedia Studio MX software. This prototyping was necessary to
ensure optimal design at this stage. The model layer was then developed so that the data
was in the correct format to be accessed and manipulated using the control layer. This
was continued until the data stubs had been fully replaced with real data for one section
of the GUI, leaving one fully functional area of the software environment. Security was
the next issue to be examined, with a number of options available. Due to a number of
reasons, including time constraints, the chosen option was of a low level but was
functional for present purposes.
With the design process now complete, the implementation phase of the project will be
discussed in Chapter 9, with the specific code and techniques outlined in this chapter
being put into practice explained in more detail.
105

CHAPTER 9
IMPLEMENTATION
IMPLEMENTATION
9.1 BACKGROUND
In order to fully understand the problems facing the development of this software
environment and hence the solutions required, it was decided to use the Mardyke
Arena [Mardyke, 2003] off campus leisure facility as described in Chapter 6 as a
prototype site. This newly constructed leisure facility, ten minutes walk from the
main campus was chosen, as it had the required sensor technology present and was
already on the college computer network, so lessening any financial overheads. Full
access was also available as it was still a college facility even though; an outside
company managed it. A review of the sensor technology and control mechanisms in
place in the Arena is now undertaken as a starting point in the implementation
process.
9.2 MARDYKE ARENA HARDWARE SITUATION
The Mardyke Arena has a complicated array of sensor and control technology in
order for it to maintain the correct environmental conditions throughout. Sensors are
located at key areas of the facility in order to monitor conditions with controllers
uploaded with control strategies ensuring that the design conditions are maintained.
Temperature and humidity sensors are used and the information they collect is
relayed back to a controller so that it can be compared against set points, so that
action can be taken if they are outside the allowable ranges, with valves and
dampers being under their supervision. All of these sensors are linked on a
communications network by means of the Unitron system as in Figure 9.4
[Appendix D].
9.2.1 The Unitron system
The Mardyke Arena is controlled via the Unitron network of communications and
universal controllers [UNITRON, 2003]. Measurements from sensors and switches are
processed through these intelligent controllers, which then control output devices such
as valves and dampers. The system is viewed through a “supervisor” or PC running the
appropriate building management software, which in the case of the Mardyke Arena is
the WN3000 package. This software is used to adjust control parameter.
In order for the controllers to be able to share information about different locations
in the Arena, they are networked together as in Figure 9.4. A UCC4
communications controller is used to do this and the supervisory PC then monitors
this network.
106

CHAPTER 9
IMPLEMENTATION
9.2.2 The Universal Communications Controller (UCC4)
The UCC4 is so called because of its 4 different modes of communication as will be
explained in Section 9.2.4. The UCC4 allows for communication between up to 63
universal controllers on its own sub network. It takes data received from the universal
controllers and transmits it to other universal controllers over the RS485 sub network. It
also performs alarms functions for all the controllers on its sub network as well as
providing a real time clock for the sub network. It can also communicate with other
UCC4’s via ARCnet, which allows for very rapid transmitting of data. However this is
not needed in the Mardyke Arena as only one UCC4 is required to control the entire
building as less than 63 universal controllers are utilised. The universal controllers used
on the UCC4 sub network are UC16’s. They are so called because of the number of
input and output points on them. These points can be defined as either digital or
analogue. The Engineering tool in the WN3000 software suite allows for the assignment
of these input/output parameters.
9.2.3 WN3000 Software suite
WN3000 is a windows based software suite used to commission, monitor and supervise
the Unitron system of controllers. Alarms, datalogging and reports programs allow for
the monitoring of the system, and engineering tools and time schedules allow the
programming of it. The Alarm program is used to alert the user of the system to any
difficulties within the plant, while the Datalog Manager is designed to allow the user to
analyse data obtained from the controllers. The Engineering Tool application is used to
program the Unitron controllers and therefore is the key application of the WN3000
software suite. Strategies are created graphically as illustrated in Figure 9.1 to
implement the control decisions made by the contracted engineer. These strategies when
created are downloaded to the controller, so that they can take any control decision.
107

CHAPTER 9
IMPLEMENTATION
Figure 9.1: Screenshot of WN3000 showing Control Strategies Set-up [WN3000,
9.2.4 Controller networks
2003]
The Unitron system has four main controller network types; Standalone,
Subnetwork, ARCnet, and Ethernet. The Standalone system comprises of just one
controller, which can be accessed via a keypad or via a modem and a remote PC
with WN3000 software. It would typically be used for boiler or AHU control in a
small office or school.
ARCnet is used for communication between UCC4’s, which are installed with an
ARCnet card, and then three different media exist to connect to them; Coax, Twisted
pair, and Fiber, with different configuration required by the UCC4 for each media.
In the Mardyke Arena the other two network types were of much more importance.
Firstly the Subnetwork, which meant that one UCC4 could have 63 universal controllers
under its supervision and more importantly again the Ethernet connection, which
allowed the Unitron system to be accessed via a TCP/IP network by using a Terminal
server. This Terminal Server had the ability to convert a serial signal to TCP/IP,
allowing access to the data collected by the controllers via the Ethernet based University
network already in place. The Lantronix UDS10 terminal server was purchased as the
terminal server to be used in this project as shown in Figure 9.2 (LANTRONIX, 2003),
108

CHAPTER 9
IMPLEMENTATION
which connected directly to the UCC4. This allowed remote access to any data collected
by the controllers in the Arena through a PC located on campus installed with the
WN3000 software suite.
A new communications protocol has recently been developed which would serve to
improve functionality in the coming years even further, that being the BACnet
communication protocol [BACnet, 2003].
Figure 9.2: Lantronix UDS 10 Terminal Server [LANTRONIX, 2003]
Figure 9.3: Lantonix UDS 10 as connected to Controller in Mardyke Arena
109

CHAPTER 9
IMPLEMENTATION
9.2.5 BACnet
Over the last five years the competitors in the building control protocol field have been
narrowed down to two; BACnet and LonWorks. LonWorks works on the principal of
the output from one device being the input to the next, whereas BACnet is based on a
number of software objects simulating real world items like boilers and fans. BACnet is
a data communication protocol for Building Automation and Control Networks
developed by the American Society of Heating, Refrigerating and Air-Conditioning
Engineers (ASHRAE) [BACnet, 2003]. BACnet is a non-proprietary, open protocol
communication American national standard, European pre-standard, and an ISO global
standard with the integratability of the TCP/IP network [BACnet, 2003]. BACnet/IP is
now the most common combination of technologies found in the building control sector
[CIBSE, 2003b], and through the use of the TCP/IP network in this project, it is a
feasible option in the future of this project to add even more to the interoperability of
the software package.
The next step in the implementation of this project was to look at the other end of the
communication setup, that being the university end where the data was to be housed on
a new supervisory PC with the WN3000 software suite installed on it.
9.3 UNIVERSITY SERVER
In order to view the data translated by the Lantronix UDS 10, as shown in Figure 9.2
and in use in the Mardyke Arena in Figure 9.3, the BMS software used in the Mardyke
Arena needed to be installed on the IRUSE University server. This WN3000 software
was owned and created by CYLON Controls ltd. (CYLON CONTROLS Ltd, 2003),
one of the University’s research project affiliates. It was obtained and with the help of
their technical support team installed. The first step was now to initiate a connection
with the terminal server in the Mardyke Arena.
9.3.1 Initiating a connection
In order to communicate with the controllers in the Mardyke Arena, a live data point
was needed for the UDS 10 to connect to, to allow communication with it. A data point
was located in the vicinity of the UCC4 and UDS 10, and on making it live was
connected to the hardware using an RJ 45 Ethernet cable. The UDS 10 had three ports
as can been seen in Figure 9.2. One connected to the data point via the RJ 45 Ethernet
cable as just mentioned, one connected to the UCC4 via an RS 232 cable with the last
110

CHAPTER 9
IMPLEMENTATION
being a power connection. This now meant that the controller was fully accessible from
the PC on campus via the college network, and hence the Ethernet, with the overall
hardware situation in the Mardyke Arena being shown in Figure 9.4.
Once everything was in place on the server, BEMS software was accessed, where the
data received could now be viewed. With the WN3000 software package, came a
number of different tools for altering control strategies and downloading them to the
controllers as well as viewing the collected data. However the tool that was most
interesting and beneficial for this project was called ccReport, which will be described
in more detail in a subsequent section.
111

CHAPTER 9
IMPLEMENTATION
Sensor 1 Sensor 2
Sensor 3 Sensor 4
UC16
UC16
UCC 4
UDS 10
Data transferred over college network using TCP/IP
PC with WN3000
BMS software logs data using ccReport
CSV file
MS Scheduler runs PHP script which
uploads data from CSV file to MySQL Database using embedded SQL
MYSQL
DATABASE
PHP used with embedded complex SQL queries to fetch data from MySQL database
and return it to a web rowser for viewing
Figure 9.4: Mardyke Arena Hardware Flow Diagram
9.3.2 Proposed data flow situation
ccReport was a data logging tool, that had the facility to log data obtained from any
sensor via its controller, the set up of which can be seen in Figure 9.5. ccReport allowed
its user to pick which data points were to be logged. This data would then be
downloaded from the controller on a schedule set by the user, and saved in CSV format
onto the hard drive of their server. A different CSV file would be created for each data
point logged by ccReport. With this facility in place the process could now be
112

CHAPTER 9
IMPLEMENTATION
automated, with a view to then taking it to the next step, and most important for this
project, the archiving process using MS Schedular in conjunction with a PHP script
using SQL commands. This process is covered in more detail in the next section, which
outlines the software tool in use and the techniques used in each process.
Figure 9.5: Screenshot of ccReport sensor choice screen
9.4 WORKING APPLICATION
Once the BMS software had been installed on the server, the sensor data in the Mardyke
Arena could now be accessed. This meant the schematics of the AHU’s that were in the
Arena along with the relevant data obtained from each, could now be viewed. The
control strategies, i.e. the control methods used to control the environmental conditions,
in use in the Arena could also be viewed and used in order to better understand the
running of the facility. They were also studied in order to better assess which areas
needed to be focused on in this project. A situation now existed where a remote BEMS
could be used, if the user so wished, to alter any control strategies in the Arena by
downloading new ones to the controller via the network through the UDS-10. This was
113

CHAPTER 9
IMPLEMENTATION
not however within the scope of this project Attention now switched to one subprogram
in the WN3000 software suite, that being ccReport.
9.4.1 Introducing ccreport
ccReport was a program that allowed the user of the BEMS to view every point on the
control network that could be data-logged. It was based on a tree structure whereby on
accessing a UCC4, each UC16 under its supervision could be viewed along with each
associated sensor controlled. Next to each sensor displayed by ccReport there was a
checkbox that once checked meant that, that particular sensor would now be data logged
over a 48 hour period (as in Figure 9.5) that was determined by the user to start at any
time of their convenience. This 48-hour period, being the maximum logging capacity of
the UCC4’s memory.
9.4.1.1 Datalogging process
In order to determine which data points were needed in order to calculate the load on
any piece of equipment a performance metric analysis needed to be undertaken in
which, it was required to understand the process performed by that that piece of
equipment. It was decided to concentrate on one AHU, the pool AHU, in the Mardyke
Arena, as it was the most energy intensive. Figure 9.6 illustrates AHU 1 in the Arena as
shown by WN3000.
Figure 9.6: Screenshot of AHU 1 as shown by WN3000
114

CHAPTER 9
IMPLEMENTATION
As can be seen from Figure 9.6 and more basically with annotations in Figure 9.7, the
outside air is passed through a heat exchanger and then an after heater in order for its
temperature to be raised to the required supply temperature. In the plate heat exchanger
the warm return air from the pool area and the cool outside air are separated by thin
plates and pass each other in cross-flow, thereby allowing energy to be transferred to the
outside air from the warm return air by way of conduction and convection [Hoval,
2003]. On exit from the heat exchanger the supply air receives its final energy boost
from the afterheater supplied by two boilers controlled by a 3-way mixing valve. If the
condition of the air, as well as its mass flow rate could be determined before and after
the apparatus, the energy supplied by the individual pieces of apparatus could be
determined using an energy balance as outlined in Equation 9.1 for the afterheater, and
in Equation 9.2 for the heat exchanger.
Outside Air
(To)
Return Air (Tr)
HEAT
EXCHANGER
AFTER
HEATER
Exhaust Air
(Te)
Pre
Afterheater
Air (Tp)
Supply Air
(Ts)
Conditioned Space
(Tspace)
Figure 9.7: Flow of air through AHU 1
Equation 9.1: After heater Load Calculation
Q ah
.
= ma*
C *( T
pma s
− T )
p
Q
ah
= Afterheater Load (kW)
ṁ a
= Mass Flow Rate of Air passing through the apparatus (kg/s)
C
pma
= Specific Heat Capacity of Air (kJ/kgK)
T s
T p
= Supply Temperature (C)
= Pre-afterheater Temperature (C)
115

CHAPTER 9
IMPLEMENTATION
Equation 9.2: Heat Exchanger Load Calculation
Q
He
.
= ma*
C *( T
pma p
− T )
o
Q
He
= Heat Exchanger Load (kW)
.
ma
= Mass Flow Rate of Air passing through the apparatus (kg/s)
C
pma
= Specific Heat Capacity of Air (kJ/kg.K)
T
o
T
p
= Outside Temperature (C)
= Pre afterheater Temperature (C)
9.4.1.2 Actual load calculation procedure
Afterheater load calculation
However, on further inspection of the system, it became evident that the pre-after heater
temperature was not monitored by a sensor, so could not be obtained by using the
ccReport tool. This meant that Equations 9.1 and 9.2 could not be used to determine the
loads on the individual pieces of apparatus unless this value could be obtained. The post
after-heater temperature in the form of the supply temperature was however monitored
along with the mass flow rate of air passing through the unit, meaning that the preafterheater
temperature alone was missing from Equation 9.1.
The pre afterheater temperature could however be obtained by undertaking the
following steps:
1) Obtaining the design load on the afterheater from the manufacturers, which
resulted in 197 kW [Masterair, 2003];
2) Using ccReport to obtain the outside temperature at any 15 minute instant;
3) Using the fact that the ratio of the design temperature differences to the part load
temperature differences, which is where the derivation of Equation 9.3 begins, it
was possible to find the load on the unit at any 15 minute interval. The equation
used to do just this is shown in Equation 9.3.
116

CHAPTER 9
IMPLEMENTATION
Q
design
Q
PL
= UA(
T
design − space
− T
)
design − outside
= UA(
T
T
)
PL − space − PL − outside
Re-arranging:
Equation 9.3
Q
PL
T − T
PL − space PL − outside
=
T
− T
design − space design − outside
*197
Where
Q = Design fabric losses from the space (kW) = 197kW
design
Q PL
= Part Load fabric losses from the space (kW)
UA
T
design −
space
= Fabric characteristics
= Temperature maintained in the space at design conditions(C)
T
PL −
T
PL
T
design
space
− outside
− outside
= Temperature maintained in the space at part load conditions(C)
= Temperature outside part load conditions (C)
= Design outside Temperature (C)
197 = The Maximum load that the after heater was sized for at design conditions (kW)
Heat exchanger load calculation
Now that the load on the after heater had been established, the earlier problem in finding
the pre-after heater temperature was turned to in order to quantify the actual load on the
heat exchanger.
Again, using the first law of thermodynamics, the after heater was further inspected in
terms of energy inputs and outputs to and from it, this implying an energy balance, with
117

CHAPTER 9
IMPLEMENTATION
the aim being the determination of the pre-unit temperature. The inputs to the unit were
the air that passed over it via the ducts and the water that serviced it via the boiler loop,
with the outputs being their respective end points of the same systems. Equation 9.4
illustrates this balance:
∑
∑
Energy _ inputs = Energy _ ouputs
.
∑ miC
piTi
= ∑ m o C
poTo
.
where
.
mi
= Mass Flow rates input to the afterheater (kg/s)
C = Specific heat capacities input to the afterheater ((C)
pi
T = Temperatures input to the afterheater (C)
i
.
mo
= Mass Flow rates output to the afterheater (kg/s)
C = Specific heat capacities output to the afterheater ((C)
po
T = Temperatures output to the afterheater (C)
o
Expanding gives:
.
m
C T
a pa p
.
+ m
C T
w pa f
.
= m
Equation 9.4
C T
a pa s
.
+ m
C T
w pw r
.
ma
= The Mass Flow rate of the air passing through the unit (kg/s)
C = The Specific Heat Capacity of the air passing through the unit (kJ/C) = 1.2kJ/kgK
pa
.
mw
= The Mass Flow rate of the water servicing the unit via the boilers (kg/s)
C = The Specific Heat Capacity of the water servicing the unit (kJ/kgK) = 4.2 kJ/C
pw
118

CHAPTER 9
IMPLEMENTATION
T = The Temperature of the Air pre-afterheater (C)
P
T = The Flow Temperature of the water from the boiler (C)
f
T = The Temperature of the Air pre-afterheater (C)
s
T = The Flow Temperature of the water from the boiler (C)
r
Rearranging this equation as in Equation 9.5 yields a result for the pre-after-heater
temperature as long as the temperature differential between the boiler flow and return
temperatures can be obtained as these were not monitored for this apparatus individually
as can be seen in Figure 9.8 which is a screenshot from the WN3000 Software suite.
This meant that it had to be done using the fact that the load on the after-heater could be
determined by allowing the use of the water side of the system to calculate a load and
hence through re-arranging to calculate the temperature differential if the load was
already known, as is illustrated in Equations 9.6 and 9.7:
Boiler Return water
joins together from all
apparatus so is mot
uniquely measurable
Figure 9.8: Boiler Flow and Return Situation in Mardyke Arena [WN3000, 2003]
119

CHAPTER 9
IMPLEMENTATION
Equation 9.5
mw C
pw
= T −
⎛
⎜T
s
⎝ f
ma C
pa
T p .
.
− T
r
⎞
⎟
⎠
Equation 9.6
Q
hc
.
=
⎛
mw C ⎜T
pw⎝
f
− T
r
⎞
⎟
⎠
Re-arranging;
Equation 9.7
T
f
− T
r
= Q hc
.
mw C
pw
Where
Q hc = Load on the After Heater (kW)
.
mw = The Mass Flow rate of the water servicing the afterheater via the boilers (kg/s)
C = The Specific Heat Capacity of the water servicing the afterheater (kJ/kgK)
pw
T
f
T
s
= The Flow Temperature of the water from the boiler (C)
= The Temperature of the Air pre-afterheater (C)
Once Equations 9.3, 9.7, and 9.5 have been used to calculate the pre-afterheater
temperature, this value is then substituted into Equation 9.2 to calculate the load on the
heat exchanger.
120

CHAPTER 9
IMPLEMENTATION
However on inspection of the returned results for the pre afterheater temperature (Tp),
they did not match those expected using Equation 9.14, leading to the assumption that
the maximum load that the afterheater was capable of imparting on the air in the system
was actually greater that the specifications had outlined [Masterair, 2003b].
It was decided to perform the following analysis to determine a realistic value for the
max load on the afterheater using the values obtained from the ccReport tool:
1) A Microsoft Excel spreadsheet was filled with real data obtained from the
WN3000 ccReport tool, as Table 9.1 shows;
2) This real time data was then used to calculate the percentage error in the pre
afterheater temperature (Tp in Table 9.1) when it was calculated using the
afterheater max load (Q AH in Table 9.1) versus that expected from Equation
9.14 (Tp2 in Table 9.1). The maximum load on the afterheater was varied to
obtain the result which yielded the lowest percentage errors (% Error in Table
9.1) over the dataset which was between the values of –1 and 11 degrees outside
temperature (Tout in Table 9.1).
This lead to the conclusion that the actual afterheater in place in the Mardyke had the
capability of imparting approximately 270 kW of energy to the incoming air as this
yielded six percentage errors less than 25 percent, which was the best over the range of
values examined (as shown in Table 9.1). The three highest pre coil temperatures also
had percentage errors of less than 70 percent, these being so high due to the extreme
nature of both the outside temperatures and the supply temperatures and the fact that the
step control in the facility as will be discussed later in this section, was not reactive
enough and so yielded inaccurate results at the extreme end of the supply temperature
scale. This new maximum load of 270W would then be used in Equation 9.3 and hence
in the calculation equations for both the actual loads on the afterheater and the heat
exchanger at any moment in time.
However the percentage errors that this inspection of the system yielded were not
satisfactory as they were too high in general as they were greater than the allowable
error factor of 5% with this being + or – 0.8 C on the pre afterheater value obtained with
respect to that arrived at from Equation 9.14. The reason for such a high error
percentage was that the control situation in existence in the Mardyke Arena was of an
121

CHAPTER 9
IMPLEMENTATION
ON/OFF nature, where the system reacted to a drop below the set point by increasing
the work done by it (ON) by 100 percent until the set point is returned to the required
level, then doing the opposite and imparting the lower end point of work done (OFF),
that being 0 percent, i.e. the bypass situation in the 3-way mixing valve. This situation
meant that a pattern existed in the supply temperatures to the space, with these ranging
from 29 to 41 degrees on an ongoing basis increasing in steps of 4 or 5 degrees to max
then returning to minimum, and continuing in this range as the day progressed. This
control strategy is known as step control with this situation illustrated from real data
obtained from the facility over a ten-day (192 values in two day period per series)
period in September 2003 in Figure 9.9. The conclusion was that the control was not
reactive and reversible enough with respect to the outside temperature to yield an
accurate result for the supply temperature needed to maintain the space’s set conditions,
and lacked the sensitivity to react effectively to changes in conditions. This meant that
the percentage errors shown in Table 9.1 resulted. This correction factor situation could
have been avoided if a sensor had been available before the afterheater in order to log
data on either side of it, thus allowing for the accurate determination of the load on it at
any given time, with this point being expanded on in the future work Chapter 11 of this
thesis.
122

CHAPTER 9
IMPLEMENTATION
123

CHAPTER 9
IMPLEMENTATION
Table 9.1: Excel spreadsheet used to calculate the actual max load on the
afterheater
Tspace Tout TDesignOut Q AH Qact Tsupply Tp
0 -3 -3 270 270 0 0
0 -2 -3 180 0 0
35.69 -1 -3 256 46.14 19.96
26.38 0 -3 242 45.49 20.70
27.07 1 -3 234 45.47 21.54
27.92 2 -3 226 46.79 23.65
29.21 3 -3 220 34.96 12.50
28.83 4 -3 211 31.97 10.43
28.81 5 -3 202 40.37 19.71
29.21 6 -3 195 39.95 20.06
28.82 7 -3 185 30 11.07
29.17 8 -3 178 32.5 14.33
29.6 9 -3 171 30.34 12.89
29.41 10 -3 162 29.79 13.26
30.54 11 -3 157 34.15 18.07
Tp2 Error %Error
0 0 0
0 0 0
16.345 -3.61 -22.1153
12.19 -8.51 -69.8247
13.035 -8.50 -65.2094
13.96 -9.69 -69.3908
15.105 2.61 17.27726
15.415 4.98 32.31267
15.905 -3.80 -23.8963
16.605 -3.45 -20.7864
16.91 5.84 34.54322
17.585 3.25 18.49577
18.3 5.41 29.5363
18.705 5.45 29.12992
19.77 1.70 8.617686
Percentage errors too
high so correction factor
was necessary in order
to calculate the loads on
the apparatus effectively
Because of the control shortfall in performance it was decided to use a correction factor
based on the fact that the part load situations should vary proportionally. The correction
factor was obtained by calibrating the expected pre afterheater temperature as
determined from Equation 9.14 with the space temperature (Tspace), the supply
temperature(Ts) and the outside temperature(To) at design and part load situations. This
yielded an equation in terms of the measured supply temperature for the correction
factor as derived into Equation 9.8 which was then curve fitted for this data using the
fact that a trend line could be best fitted to the data leading to a function (Equation 9.9)
for the correction factor as obtained by graphing the supply temperatures against the
124

CHAPTER 9
IMPLEMENTATION
calculated correction factor in Microsoft Excel as through examination of the data, the
greatest connection resulted from varying the Supply Temperature with respect to the
correction factor, as illustrated in the graph in Figure 9.10. This correction factor would
in real terms be the adjusted flow rate of air passing through the apparatus at part load
conditions.
Deriving:
Design − Inputs − to − space = Design − Outputs − from − space
Part − Load − Inputs − to − space = Part − Load − Outputs − from − space
.
mD C ( T
pD s
.
mPL C ( T
pPL s
− T ) = UA(
T − T )
p D space o D
− T ) = UA(
T − T )
p PL space o PL
Cancelling and re-arranging:
.
mD
.
mPL
=
( T − T )
space outside D
( T − T )
s p D
( T − T )
s p PL
*
( T − T )
space o PL
With design condition known, this Equation becomes:
Equation 9.8
CF
=
1
0.645
( T − T )
s p PL
( T − T )
space o PL
Where:
CF
T space
T o
T s
T p
m
PL
= Correction Factor (CONSTANT)
= Space Temperature (C)
= Outside temperature(C)
= SupplyTemperature (C)
= Pre afterheater temperature (C)
= Mass flow rate of air
= Part load conditions
125

CHAPTER 9
IMPLEMENTATION
D = Design conditions
Equation 9.9
CF
= 0.0547(
T ) − 0.7126
s
Where:
T s
CF
= Supply Temperature (C)
= Correction Factor (CONSTANT)
126

CHAPTER 9
IMPLEMENTATION
127

CHAPTER 9
IMPLEMENTATION
As can be seen clearly from Figure 9.10, the trend line is a very accurate fit for the
lower bound values of the supply temperature, these being the operational range of the
facility for the most part. The fact that the trend line is as good a fit for the upper bound
figures can be attributed to the fact that the efficiency of the heat exchanger varies for
both sets of data leading to the conclusion that two trend lines would result in a more
accurate final result. This is illustrated for the lower bound in Figure 9.11 and for the
upper bound in Figure 9.12.
1.4
1.2
1
y = 0.0562x - 0.7734
0.8
0.6
Series1
Linear (Series1)
0.4
0.2
0
29 30 31 32 33 34 35 36
Figure 9.11: Trend line for the lower bound of the supply temperatures
2.5
2
y = 0.0636x - 0.9726
1.5
Series1
Linear (Series1)
1
0.5
0
39 40 41 42 43 44 45 46 47 48
Figure 9.12: Trend line for the upper bound of the supply temperatures
128

CHAPTER 9
IMPLEMENTATION
This trend line analysis was validated using three months of real data from October to
December 2003 and the graphs obtained are shown in Figures 9.13 and 9.14.
Minimum Daily Values
1.5
1
0.5
Md/Mpl
Minimum
Linear (Minimum)
0
0 5 10 15 20 25 30 35
-0.5
-1
Tsupply
Figure 9.13: Validation of trend line analysis and correction factor derivation
using large amount of real data points at the lower bound of supply temperatures
129

CHAPTER 9
IMPLEMENTATION
Maximum Daily Values
3.5
3
2.5
2
Md/Mpl
1.5
1
Maximum
Linear (Maximum)
0.5
-0.5
0
0 10 20 30 40 50 60 70
-1
Tsupply
Figure 9.14: Validation of trend line analysis and correction factor derivation
using large amount of real data points at the upper bound of supply temperatures
This lead to two correction factor (CF) calculation Equations as shown in Equation 9.10
and 9.11, whose respective results would in turn be substituted into Equation 9.12 to
calculate the required pre afterheater temperature for each, hence allowing the
calculation of the loads on both pieces of apparatus from Equations 9.1 and 9.2.
Equation 9.10: Lower bound values supply temperature Equation
CF
= 0.0562(
T ) − 0.7734
s
Where:
T s
CF
= Supply Temperature (C)
= Correction Factor (CONSTANT)
130

CHAPTER 9
IMPLEMENTATION
Equation 9.11: Upper bound values supply temperature Equation
CF
= 0.0636(
T ) − 0.9726
s
Where:
T s
CF
= Supply Temperature (C)
= Correction Factor (CONSTANT)
Once this correction factor had been determined for any value of supply temperature it
could be used to calculate the actual loads on the afterheater and heat exchanger by:
1) Taking any supply temperature from the ccReport tool and finding the
associated CF from the relevant graph, either that in Figure 9.10 or 9.11
depending on the supply temperature;
2) Using Equation 9.12 to calculate the corrected pre afterheater temperature;
3) Inserting this new pre afterheater temperature to calculate the loads on the
afterheater and heat exchanger respectively from Equation 9.1 and 9.2.
Re-arranging Equation 9.9 yields:
Equation 9.12
Tp = Ts − CF * 0.645*( Tspace − To)
Where
CF
T space
Ts
T o
= Correction Factor (CONSTANT)
= Space Temperature (C)
= Supply Temperature (C)
= OutsideTemperature (C)
131

CHAPTER 9
IMPLEMENTATION
Verifying procedure using manufacturers specifications
In order to verify the thought process that was used to establish the Equations described
in the previous section, which yielded a plausible result for both the afterheater and heat
exchanger loads, the manufacturers specifications were consulted.
Masterair (Masterair, 2003) were contacted and the specifications for the heat exchanger
unit were obtained, and once studied, yielded an equation for the load on the unit as is
shown in Equation 9.13.
Equation 9.13
.
Q = ma*
C * Eff *( T − T )
he pma r o
Where
Q
hc
= Load on the Heat Exchanger (kW)
m a
C pma
Eff
T
r
T
o
= Mass Flow Rate of the air in the system (kg/s)
= Specific Heat Capacity of Air (kJ/KgK)
= Efficiency of the Heat Exchanger (CONSTANT)
= Room Temperature (C)
= Outside Temperature (C)
This Equation once worked through with real values obtained from the ccReport tool
yielded a result, which was within the allowable error parameters to that obtained by
means of the previous Equation 9.2 for the load on the heat exchanger with the
discrepancies being due in part to the lack of an efficiency factor in Equation 9.2. The
load calculated (Q) in just below the load as expected (Q SPEC), which was obtained
from the specification Equation 9.13. This proved that the thought process behind the
evolution of these equations was indeed true and meant that they could be used in the
further determination of loads in the software package itself.
132

CHAPTER 9
IMPLEMENTATION
Table 9.2: Comparison of the calculated load on the Heat Exchanger for the lower
bound values of the supply temp using Equation 9.2 and that obtained from the
manufacturers specifications using Equation 9.13
cf corr Ts tp corr Q Q SPEC Tspace To
1.191352 34.96 14.81966 115.5963 134.7243 29.21 3
1.023314 31.97 15.58127 113.2648 127.0448 28.83 4
0.9126 30 17.15616 99.32723 110.2947 28.82 7
1.0531 32.5 18.12029 98.97642 106.6776 29.17 8
0.931708 30.34 17.9604 87.63267 103.5057 29.6 9
0.900798 29.79 18.5125 83.25229 96.88352 29.41 10
1.14583 34.15 19.70876 85.17168 97.60694 30.54 11
Table 9.3: Comparison of the calculated load on the Heat Exchanger for the upper
bound values of the supply temp using Equation 9.2 and that obtained from the
manufacturers specifications using Equation 9.13
cf corr Ts high tp Corr Q Q SPEC Tspace To
1.920564 45.49 12.81141 125.2956 135.6703 26.38 0
1.919292 45.47 13.19682 119.2849 133.9452 27.07 1
2.003244 46.79 13.29897 110.5039 133.1105 27.92 2
1.594932 40.37 15.87591 106.3664 121.3687 28.81 5
1.56822 39.95 16.47304 102.4263 118.0298 29.21 6
Verification of procedure and results by site and apparatus inspection and
experimentation
Since it was impossible to obtain a sensed result for the pre-afterheater temperature in
AHU 1 in the Mardyke Arena, the result of Equation 9.12 could not be validated against
real values.
It was decided that since the pre afterheater temperature was the critical value in all the
load calculations that Equation 9.12 needed to be validated against real returned values
for the pre-afterheater temperature. On inspection of AHU 1 in the Arena, it became
apparent that the manual measurement of this value was impossible as no access could
be obtained to this area of the AHU meaning the hand placing of a sensor such as the
Hanna HI92000 (Hanna, 2003) could not be facilitated. An alternative approach needed
to be found.
The approach decided upon was to manually isolate the afterheater directly after the
heat exchanger meaning that the sensed supply temperature in the AHU would now
actually be the pre afterheater temperature. This was required in the validation process
133

CHAPTER 9
IMPLEMENTATION
of the equations used in this package to determine the loads on the individual pieces of
apparatus in AHU 1, minus a 1.5 o to 2 degrees picked up over the fans in the system
used to deliver the air to the space. This process however had to be undertaken after the
facility had closed for the night, as it would significantly affect the space conditions.
At 10:30 at night, after the facility had closed for the night, the isolating valve
delivering the boiler water to the afterheater in AHU 1 was manually switched off. After
a 45-minute period, which allowed the existing water in the unit to become redundant
for heating purposes, a colleague monitoring the remote BMS on campus recorded the
value for the supply temperature every minute. This would later allow the comparison
of actual values for the pre afterheater temperature with those obtained from Equation
9.14, which gives an approximation for the pre afterheater temperature based on the
possible heat transfer of the heat exchanger, allowing first of all, the validation of the
recorded dataset ensuring the correct operation of the system and secondly the
validation of the values obtained from Equation 9.12.
Equation 9.14
T
P
T
=
r
+ T
2
o
T
P
T
T
r
o
= Temperature of the Air before the afterheater (C)
= Temperature of the Air returning from the conditioned space (C)
= Outside Temperature of the Air (C)
On comparing the recorded values for the pre afterheater temperature obtained on this
night with those obtained using Equation 9.14, it was decided that the calculated results
were within the allowable error parameters to fully validate the process used meaning:
1) The equipment was functioning satisfactorily as the expected value obtained
from Equation 9.14 for the pre afterheater temperature was being obtained
(Supply Air Temp in Table 9.4 as afterheater redundant). The only worry was
that the actual specification of the afterheater itself which was listed at 197 KW
in the specifications but which now looking at the recorded results in Table 9.5
must be capable of much more. This meant that a larger afterheater must be
134

CHAPTER 9
IMPLEMENTATION
present in the AHU, and hence a larger rating must be used for the peak load
used in Equation 9.3. This also verified the earlier spreadsheet analysis in Table
9.1 that the unit was in fact a higher capacity unit, in the region of a 270 kW
unit, again verified by the findings in Table 9.5;
2) The subsequent load calculation procedure described in Section 9.4.1.2 did
indeed return the true loads on the individual pieces of apparatus in AHU 1. This
meant that they could indeed be used in this software packages load calculation
procedure.
Table 9.4: Line of data confirming the correct operation of the Heat Exchanger
Supply Return
Outdoor
Air Air
Time Dry Bulb
Temp Temp
C
(C) (C)
Pool VSD
Pool Area
Damper
Area Speed
Temperature Postion
humidity Signal
(C)
%
(%) (%)
Mixing
Heat
Valve
Exchnager
Open
Load
(%)
23:47 10.13 20 21.9 25.8 82 100 100 100 76.9686
Time
Table 9.5:Line of data confirming that a larger afterheater was present in
Mardyke Arena AHU 1
Outdoor
Dry Bulb
C
Supply
Air
Temp
(C)
Return
Pool VSD
Pool Area
Damper
Air
Area Speed
Temperature Postion
Temp
humidity Signal
(C)
%
(C)
(%) (%)
Mixing
Valve
Open
(%)
Afterheater
Load
00:03 10.28 47.6 27.8 29.2 64.9 100 100 100 269.928
9.4.1.3 ccReport output
Once which points to log had been chosen, some way of scheduling when exactly they
would be logged needed to be found. In ccReport two ways existed to do just this;
manual or automatic. In the case of this software tool, automatic was the obvious
choice, as so many points needed to be taken that human error would have been a
problem. The time decided on to data-log was midnight as this would give two calendar
days of data, and names for each sensor were set so that differentiation between logged
files could be made. The manual logging process was however used along with the error
logging mechanism of ccReport to check that all was operational before setting the
automatic process in running.
135

CHAPTER 9
IMPLEMENTATION
Once logged the data was stored in a CSV file in a specially created archive folder. The
format of each CSV file followed the same pattern with the sensor ID, number of values
etc. as displayed in Table 9.6, being listed followed by the values themselves obtained
from the sensor in question. There were 192 values obtained from each sensor, this
being the maximum capacity of stored data that the UCC4 could hold before discarding
data. It translated to 48 hours of data; with one data point being taken every 15 minutes,
this being perfectly adequate for this packages purposes.
Table 9.6: CSV File of output from ccReport tool of BMS
Controller
accessed
No. of values
logged
Data Set
obtained
Time in seconds between
logged values
UC24 - 004 - AHU
UCC4 - 001 01 Pool AHU Pool Area Temperature 900 °C
32976.9792 192 28.63 28.58 28.49
9.4.2 CSV File format manipulation
The next obstacle in the path of this package was the format of the CSV files saved to
the archive folder. The data to be archived in the database from these files was the raw
sensor data, as the remainder would just repeat itself over each log. In order to separate
this data from the rest, the file-system functions on offer from PHP needed to be fully
understood and utilised. This was done using the PHP manual (PHP MANUAL, 2003)
and various books (SAMSa, 2001, SAMSb, 2001).
9.4.2.1 PHP Filesystem functions
Firstly the file from the archive folder needed to be accessed using the “fopen” function.
The data in it then needed to be read through until the pointer was at the beginning of
the data required in the file, this being the 192 values obtained initially from the sensor.
At this point this data would then be written to a new file vertically and once again in
CSV form. This was achieved using a combination of functions, but most importantly
136

CHAPTER 9
IMPLEMENTATION
using the “fgetcsv” function, which allowed the user to parse the data read for fields in
CSV format returning them to an array [PHP MANUAL 3, 2003] which was then
output vertically to a new blank file. The data was required to be vertical in the new file
as in this form it could most easily be uploaded to the MySQL database. When this was
done, the original file was emptied of all contents, so that it was ready to be rewritten at
the next data-log time. The file-system code used to do exactly this can be seen in its
entirety in Table 9.7.
Table 9.7: Code used to manipulate CSV files obtained from ccReport
function revamp_csv($uploadfilename)
{
$fp = fopen ($uploadfilename, "r+") or die ("could not open file");
//i want to read to line 2 where the data begins then dump to a new file eventually
$nav = fgets($fp, 100);
for ($i=1; $i

CHAPTER 9
IMPLEMENTATION
database connection in the file-system code, but after the data manipulation had taken
place. Then once connected the data was uploaded from its new location to the database
using an SQL upload command, as illustrated in Table 9.8.
Table 9.8: Code used to upload manipulated data to the relevant database table
function load_temps()
{
$query = "load data local infile \"C:/Inetpub/wwwroot/ver6/output22.csv\" into table temps";
$result = mysql_query($query) or die(mysql_error());
}
9.4.2.3 Automation of upload process
Next the automation process needed to be addressed. The first idea was to use
ccReport’s ability to launch another program once logging had been completed. This
would have enabled the PHP upload script to be automatically run on completion of the
logging process. However, due to bugs in this new area of the ccReport tool which
meant that it was not fully operational and hence was unreliable, it was decided to use a
desktop tool offered by Microsoft called MS Schedular to automatically run the script
on demand. This program allowed the user to set a time when a program would
automatically be set to start-up. This then allowed the user to set ccReport to log data at
a particular time, then set MS Schedular to launch the upload script at a time after
ccReport had finished as shown in Figure 9.15, so meaning that the data would now be
logged, manipulated and uploaded automatically.
However this process though meeting the needs of the project for automation of the
upload procedure, did not fully solve the problem as some manual maintenance was still
necessary due to the fact that an executable file could not be created, thus meaning that
the script to upload data needed to be launched in internet explorer, which could not be
shut down automatically, hence requiring human intervention to close the program,
leaving the server ready to upload the next set of values to the database.
138

CHAPTER 9
IMPLEMENTATION
Figure 9.15: Ms Scheduler set-up box
9.5 GUI DEVELOPMENT WITH IMPLEMENTED CONTROL
STRUCTURE
Now that the data was being collected, manipulated and uploaded to the database
automatically, attention turned to implementing a data retrieval process, whereby the
data would have calculations done on it so rendering more useful information and
would allow for the replacement of the data stubs used in the development of the initial
GUI design. A graphical element would also be included in the GUI, letting users see
the relevant load information in bar graphs, so leading to more easily understandable
information display.
9.5.1 Database information retrieval
The process for data retrieval from the MySQL database using PHP was explained
earlier in Section 8.4.2, but a number of new problems arose as the implementation of
the package continued. The one main problem that was encountered was the fact that
the pre-afterheater temperature in AHU 1 was not monitored and so could not be logged
by ccReport meaning that the assumption made in Section 8.4.2 that the load could be
calculated from the equation in Equation 8.1 of the same section was now in error. A
new idea for the calculation of this load using the a correction factor was decided upon,
and was outlined in Section 9.4.1.2. These equations now needed to be translated into
complex SQL queries so that they could be embedded in PHP script and used to access
and manipulate the MySQL database data, so allowing the calculation of the loads on
the apparatus in AHU 1 at any given time according to the archived data.
139

CHAPTER 9
IMPLEMENTATION
9.5.1.1 Performing load calculations using SQL
The first obstacle met in translating the equations into SQL was the fact that multiple
tables needed to be accessed in the database in order to perform calculations. This
meant using table joins, which is a method whereby multiple tables are accessed by
using a naming convention where not only the table name is needed but also the column
name. The same row of data also needed to be accessed from each table for each
calculation to be correct. This was achieved by relating the tables to each other using a
common column. This “ID” column contained a primary key, which meant that each
row was completely individual and so could be called on as such in each table. An
example of the table set up is shown in Figure 9.16, as obtained from mySQL’s own
management system called winMySql.
Figure 9.16: Screenshot of WinMysql showing database and table characteristics
The next encountered problem in translating the mathematical equations into their SQL
counterparts was choosing the correct sequence for the mathematical operations to be
executed. Much like a normal complex mathematical equation, the same set rules are
followed, i.e. that portion of the equation in brackets being calculated firstly, then the
remainder etc. However in SQL syntax, not only do the brackets need to be in the
correct place, but the order of the data retrieved matters as it is obtained from the
database tables in the same order. So the equations were pieced together bit by bit
140

CHAPTER 9
IMPLEMENTATION
ensuring that the correct result was being returned for one line of data before moving on
to the next problem, that being creating a while loop to execute the overall query until
the required number of results had been obtained.
9.5.1.2 Implementing a control structure
For the final Equations, Equations 9.1 & 2, to return the correct load value for the
afterheater and heat exchanger, the previous three Equations 9.10, 9.11 and 9.12 firstly
needed to access the database, perform their calculations, and then store the results in
variables for use in Equations 9.1 & 2. This would not have been much of a problem if
just one line of data needed to be accessed, however, many lines of data had to be
accessed, returning a value for the equations after each line. This was where a
programming control structure needed to be implemented.
9.5.1.3 Control structures
Control structures are the structures within a programming language that allow the
programmer to control the flow of execution through a program or script (SAMSb,
2001). In this case the control structure that suited these circumstances best was the
“for” loop. It is the simplest kind of loop in PHP and it operates by executing a piece of
code as long as a certain condition, set by the programmer, is true. It was perfect for this
situation as the most common use of a for loop is when one doesn’t know how many
iterations are required in order to make the condition true, as was the case in the results
returned from the database in this situation. The loop was set to begin at the first
iteration corresponding to the ID column in the database, continuing until and not
beyond the last relevant iteration corresponding to the last ID concerned with here. A
portion of the code used in the application is shown in Table 9.9.
141

CHAPTER 9
IMPLEMENTATION
Table 9.9: Code used to calculate the load on the afterheater in AHU 1
$sumTotal = 0;
for ($i=1; $i

CHAPTER 9
IMPLEMENTATION
9.5.2 Graphical interpretation
Once the loads on the apparatus in AHU 1 were being returned, the task of displaying
them in such a format that they were as accessible as possible to the untrained eye could
be examined. Firstly the results were displayed in table format, and due to the work
done in the PHP script as shown in Table 9.7, the load in GJ/m 2 and more importantly
for the facility manager, in monetary cost could be output, these being much more
understandable quantities to the everyday user.
Taking the display to the next step was now the goal, so it was decided to implement
some kind of graphical output which would allow the user to see the output in bar graph
format, again making it easier to identify where shortfalls in the system were occurring.
In order to do this a number of options were considered.
The first option considered was using a graphical library called GD library (GDLib,
2003), which was an up-loadable library of PHP functions that allowed the programmer
to set parameters for the construction of a graph, either a pie chart or bar graph, and
even line graphs, based on returned values from a database. GDLibrary was available to
freely download from the GDLibrary homesite [GDLib, 2003]. However on download,
a complex installation procedure had to be adhered to in order for the library to be
installed correctly. The configuration process was also difficult and little supported text
existed to aid this process. The gd 2.0.15, which is the latest version of the library,
requires that the libpng, zlib and jpeg-6b libraries also be installed, in order to produce
the related image formats. This process proved very difficult and because of this was
abandoned in favour of a more time efficient solution, that being the use of HTML
tables as a formatting tool.
9.5.2.1 HTML Tables used to graphically display data
The option decided upon to create a graphical interpretation of the returned data turned
out to be a much simpler option, if not as functional as the GD library. It was decided to
use PHP’s ability to output a table to the web browser. But whereas the normal HTML
table generated was used for positioning text or to display figures, instead the possibility
of using the table as a horizontal bar graph was now considered.
To achieve this the returned results of a calculation query to the database were taken
and stored in variables. These variables were then used as attributes in the table make up
parameter. More specifically they were used as the table row width attribute, so
meaning that the table row width would now equal to the value of the returned querys.
143

CHAPTER 9
IMPLEMENTATION
By doing this it meant that each table row now corresponded to the result of a returned
query from the database, hence achieving the aim of creating a simple bar graph to
illustrate the result of each query. The code used is displayed in Table 9.10 with the
graph of monthly loads as displayed by the GUI illustrated in Figure 9.17.
Table 9.10: Code used to output a graph of retuned query
while( $line = mysql_fetch_array($result, MYSQL_NUM))
{
$Total +=$line[0];
}
Assigning result of
query to $month_bar
variable
//the commented out section directly underneath is the changes necessary to display a gj graph
$month_bar = $Total/*_Gj*110*//2;
echo"\n";
echo"\n";
Using the $month_bar
variable to set the table
row width
echo"$month$Total\n";
echo"\n";
echo"\n"
}
Figure 9.17:Screenshot of bar graph displaying monthly loads
144

CHAPTER 9
IMPLEMENTATION
As can be seen the $month_bar variable is the result of the returned query and is used to
set the width of each table row.
Now a situation existed where the backend database is being automatically uploaded
with the relevant data directly from the sensors on site via the BEMS on the server.
Using the PHP scripts previously explained in Section 8.4.2, access to this data is
obtained, calculations performed on it, then the final output being displayed in the
browser. And finally, and most importantly, the ability to generate gbXML reports as
required by the user at the click of a mouse is the end result.
9.5 SUMMARY
The Mardyke Arena is controlled via the Unitron network of communications and
universal controllers. The system is viewed through a “supervisor” or PC running
the appropriate building management software, which in the case of the Mardyke
Arena is the WN3000 package. In order for the controllers to be able to share
information about different locations in the Arena, they are networked together. A
UCC4 communications controller is used to do this and the supervisory PC then
monitors this network. The Unitron system can be accessed via a TCP/IP network
by using a Terminal server called the Lantronix UDS 10. The BEMS software used
in the Mardyke Arena was installed on the Informatics Research Unit for
Sustainable Energy (IRUSE) University server so that the data could be viewed and
stored there.
ccReport was a program in the WN3000 software suite, that allowed the user of the
BEMS to view every point on the control network that could be data-logged. This
allowed the sensor data to be output in the form of CSV files. Once these files were
accessed, attention turned to the fact that the pre afterheater temperature needed to
quantify the loads on the afterheater and heat exchanger in AHU 1 was not available
to log, so an alternative approach was required.
After much research and investigation, it was finally decided to use a correction
factor (CF), which was determined to be a function of the supply temperature based
on curve fits depending on the value of the supply temperature to the space to find
this pre afterheater temperature. Once this value was obtained, the loads on the
individual pieces of apparatus could be determined using Equations 9.1 and 9.2.
This process was verified using the specifications for the heat exchanger and
through a site investigation, both of which yielded positive results.
The next obstacle in the path of this software environment was the format of the
CSV files that were logged. A solution was achieved using the file-system functions
of PHP. This system of data manipulation needed to be automated, and coupled with
an upload procedure that would fill the relevant tables of the relevant database with
the correct data. This was achieved to a good degree using the MS task manager
program, which came with the windows operating system.
Now that the data was being collected, manipulated and uploaded to the database
automatically, attention turned to implementing a data retrieval process, whereby
calculations are done on the data so rendering more useful information. Again this
145

CHAPTER 9
IMPLEMENTATION
was achieved using the functionality of the PHP programming language with
embedded complex SQL queries.
The implementation phase of development proved difficult and would need to be
tested in order to ensure it was successful. Chapter 10 does just this, with the testing
procedure firstly outlined, then adhered to as the parts that made up the software
tool were tested individually and in unison to ensure the effective operation of the
tool.
146

CHAPTER 10
ARENA
TESTING: PROTOTYPE SITE – THE MARDYKE
TESTING: PROTOTYPE SITE – THE MARDYKE ARENA
In order to ensure the smooth running of the software tool as developed in Chapter 9, an
extensive testing process is undertaken to ensure that any flaws in the design could be
fixed, and improvements in user interaction achieved. Firstly the process is examined.
Monitoring
Energy use
ENERGYEYE
Energy Archiving and
Analysis Tool
Kyoto Protocol
PHP
MySQL
Unitron & BACnet
Environmental
Requirements
Whole Building
Energy Analysis
gbXML
Technology
Methodology
Real Case Study
THE MARDYKE ARENA
Figure 10.1: Thesis Schematic illustrating the beginning of the software testing
section
147

CHAPTER 10
ARENA
TESTING: PROTOTYPE SITE – THE MARDYKE
10.1 SOFTWARE TESTING
10.1.1 Principles of software testing
It is important to approach the testing process with the attitude of executing a program
with the intent of finding errors, since testing can only show the presence of errors in a
program and never their absence. There are two fundamental approaches to program
testing [Marcotty, 1991]:
• Black Box Testing – data driven testing to illustrate compliance. The program is
viewed as a black box whose internal aspects are not visible, with the method
being to search for circumstances where the program or software does not
behave according to the way it was developed;
• White Box Testing – logic-driven testing, where the internal aspects are known
to the tester, with the method being to execute every single path in the program
or software with a view to finding errors.
By using these techniques with test cases, the programmer can test the software that
they themselves have written. This is known as benevolent testing.
10.1.2 Debugging
This is the part of the testing process that programmers traditionally like the least
because it means admitting that the program is flawed in some way. The ease with
which a bug in the program can be tracked down depends on three things:
• Software Design – the formatting of each part of each script that encompasses
the entire package controls how easy or hard it is to locate bugs. A welldesigned,
well-annotated program will aid this process no end;
• Plan for Debugging – if the programmer built some debugging applications to
solve problems as they occurred, then this again will speed up the debugging
process;
• Mental attitude of the Debugger – if the process is looked at as more of a
challenge than a burden then most if not all of the problems will be solved.
148

CHAPTER 10
ARENA
TESTING: PROTOTYPE SITE – THE MARDYKE
10.1.2.1 First actions in debugging process
First, it must be possible to repeat the error reliably. This might sound strange as why
would the user want an error to happen every time; but it is logical, as if it does happen
each time a certain action takes place, then the chances of finding the reason for it
occurring are increased exponentially. This put more logically is that when the same
starting conditions are met with the same input data on a number of occasions, the
output must be the same each time. Different output with constant data input implies
that the starting conditions are changing, so leading the programmer to change the
starting conditions until the problem occurs every time, so leading to a more clear
understanding of why the failure is occurring, and hence to achieving a solution to it.
10.1.2.2 Finding the route of the problem
Often when an error occurs, the nature of it will point to a certain area of the program
that may be responsible for the error. However this is not always the case. To alleviate
this ambiguity, error messages can be inserted into the program at different points so
clarifying the reason for the error. Then after these have been inserted in most places, if
no message appears onscreen, the search for the reason for the error becomes easier as
fewer options remain without associated error messages. This process is continued until
the reason for failure of the program is resolved.
10.1.2.3 Fixing the problems
It is imperative that once the reason for the error is located that it is fixed correctly and
not that it is bypassed in some way. The quick fix may be an attractive option, but the
error may just be bypassed for that particular section of the package and may rear its
ugly head in some other part, maybe even in a much more difficult place to find. Any
correction must also preserve the structure of the code used as this may otherwise lead
to confusion later on.
The methods to test the software tool had now been identified and understood. They
were now used to test the tool in its current format using the Mardyke Arena as the
prototype facility.
149

CHAPTER 10
ARENA
TESTING: PROTOTYPE SITE – THE MARDYKE
10.2 REVIEW OF HARDWARE SITUATION IN THE MARDYKE ARENA
The Mardyke Arena is controlled via the Unitron [UNITRON, 2003] network of
communications and universal controllers. Measurements from sensors and switches are
processed through these intelligent controllers, which then control output devices such
as valves and dampers. The system is viewed through a “supervisor” or PC running the
appropriate building management software, which in the case of the Mardyke Arena
was the WN3000 package developed by CYLON Controls Ltd. [Cylon Controls Ltd.,
2003]. This software is used to adjust control parameters as well as to perform other
maintenance and analysis functions.
In order for the controllers to be able to share information about different locations in
the Arena, they are networked together. A UCC4 communications controller is used to
do this and the supervisory PC then monitors this network.
WN3000 is a windows based software suite used to commission, monitor or supervise
the Unitron system of controllers. Alarms, data logging and reports programs allow for
the monitoring of the system, and engineering tools and time schedules allow the
programming of it. The Alarm program is used to alert the user to any difficulties within
the plant, while the Datalog Manager is designed to allow the user to analyse data
obtained from the controllers.
The Ethernet connection in the Mardyke Arena allowed the Unitron system to be
accessed via a TCP/IP network by using the Lantronix UDS 10 Terminal server. This
UDS 10 had the ability to convert a serial signal to TCP/IP, allowing access to the data
collected by the controllers via the University network already in place, and was
connected directly to the UCC4. This allowed access to any data collected by the
controllers in the Arena through a PC located on campus installed with the WN3000
software suite.
The problems encountered during the testing process on this software tool are now
examined in more detail, with any solutions being outlined.
150

CHAPTER 10
ARENA
TESTING: PROTOTYPE SITE – THE MARDYKE
10.3 PROBLEMS ENCOUNTERED AND SOLUTIONS FOUND
Once the hardware situation in the Mardyke Arena was fully understood and connected
via the UDS 10 to the PC on campus through the Ethernet connection between the
Arena and the main campus, data from the sensors could be viewed onscreen using the
WN3000 software suite installed on the PC as in Figure 10.2.
Figure 10.2: Screenshot of AHU 1 Displaying Information retrieved via the sensors
in the Mardyke Arena [WN3000, 2003]
However, as everything seemed to be set for the logging process to begin using this
system, the data flow from the Arena ceased. There were a few possible explanations
for this:
1) The network connection of the PC had failed or was faulty;
2) The data point that the UDS 10 was connected to in the Mardyke Arena, or the
one that the PC on campus was connected to, was faulty;
151

CHAPTER 10
ARENA
TESTING: PROTOTYPE SITE – THE MARDYKE
3) The RS232 cable that connected the UDS 10 to the UCC4 or the RJ 45 Ethernet
cable that connected it to the data point in the Mardyke Arena was faulty;
4) The UDS 10 must be reconfigured to communicate with the WN3000 software
suite over the TCP/IP network.
10.3.1 Fault detection analysis
10.3.1.1 Network connection check
A network connection failure may be due to a number of different factors; the computer
that a connection is being sought with may be offline, the application server may be
down, there might be a fault in the communications link somewhere, or one of any
number of other factors may have occurred.
If a command prompt dialog box is opened on the computer and the “ping” command
used, it can be determined if the problem is that communication cannot be facilitated
with the other machine or whether the problem is with the application that resides on the
remote computer that is being accessed.
The command is typed in followed by the IP address of the terminal server that is being
checked. For example if the connection to an imaginary terminal server that had an IP
address of 200.80.128.7 needed to be checked, the text in Table 10.1 would be typed in.
Table 10.1: Ping command to test network connection
ping 200.80.128.7
The response that should be obtained if the terminal server was answering would be
something like that obtained in Table 10.2.
Table 10.2: Result form a Ping command showing a valid network connection
Pinging 200.80.128.7 with 32 bytes of data:
Reply from 200.80.128.7: bytes=32 time

CHAPTER 10
ARENA
TESTING: PROTOTYPE SITE – THE MARDYKE
Table 10.3: Result from a Ping command showing a failed network connection
Pinging 200.80.128.7 with 32 bytes of data:
Request times out.
Request times out.
Request times out.
Request times out.
This process was carried out using the IP address assigned to the UDS 10 in the
Mardyke Arena from the supervisory PC on campus, with no reply being obtained,
meaning that either the network connection was not working or that the UDS 10 itself
was not functioning correctly
10.3.1.2 Data point checks
The data points both in the Mardyke Arena and on campus were checked to see if they
were operational. This was achieved by testing to see if they could be accessed by
another machine on the university network when a terminal server made a connection to
them.
A DOS prompt dialog box was used with the DOS “ping” command being utilised to
test if a reply could be obtained from the IP number assigned to the PC in sequence,
with this situation being similar to that shown in Table 10.2. If no reply was obtained
from them using this approach, then the data points were not operational and the
problem was solved. However both data points returned replies from an independent
machine on the network thus verifying that both were actually operational meaning that
the other possible problems needed to be explored.
10.3.1.3 Cable checks
The cable connecting the server to the data point, the RJ 45 Ethernet cable, was tested
by connecting it to a different machine and data point pair, to see if a network
connection could be obtained elsewhere thus proving that the cable was not at fault in
the original situation. This was indeed the case as a connection was established on a
different machine using the original cable proving it to be operational.
A similar process was adhered to in the Mardyke Arena where the cross cable and
RS232 cable were checked and proven to be functional.
153

CHAPTER 10
ARENA
TESTING: PROTOTYPE SITE – THE MARDYKE
10.3.1.4 Reconfiguration of UDS 10
The settings in the UDS 10, the terminal server, must be configured using a terminal
program within Windows such as Hyperterminal or TerminaLexe. Hyperterminal was
used, as this was included in the Windows software suite on the supervisory PC on
campus. The UDS 10 was connected to the PC via an Ethernet connection, with the IP
address of it being firstly set in hyperterm in the TCP/IP (Winsock) connection option
dialog box. The COM 1 properties are set according to the CYLON controls ltd. manual
(Appendix 1), as well as the terminal server properties and ASCII settings with the
successful connection being finally saved.
Once the UDS 10 is connected to the same Ethernet network as the supervisory PC on
campus, the PC can connect to it and configure it accordingly using the Lantronix
software, available from the Lantronix website (LANTRONIX, 2003). The APS
Configuration Utility is installed on the PC. Using Telnet, the UDS 10 can be logged on
to, but only after an IP address is assigned to it.
The APS configuration utility is started from the programs menu of the PC, and the
Assign IP link followed from the tools menu, with the relevant IP address being filled
into the dialog box, which is displayed. Once the IP address is assigned to the unit, it is
connected to via Telnet, another Windows utility, with a client program opening on the
PC. Once this screen is displayed, by pressing enter the setup area is entered and the
final configuration of the UDS 10 can be completed, again according to the CYLON
manual [Appendix D].
10.4 NETWORK CONNECTION DIFFICULTIES
Since the network connection test yielded a negative result, it needed to be fixed or an
alternative solution found before the archiving process could begin.
10.4.1 Purchase of a dedicated PC for this project
It transpired on future inspection that the network card on the PC used as the
supervisory PC on campus was in fact not fully operational. Returning the machine to
the manufacturer for the fault to be repaired could have solved this problem, however,
the decision was taken to purchase a new, dedicated PC for the purpose of this project
alone.
This was done because it had become apparent that human intervention could have
become a problem, as the old machine was a multi purpose one. So in order to have the
154

CHAPTER 10
ARENA
TESTING: PROTOTYPE SITE – THE MARDYKE
least possible chance of errors in the logging process occurring, a dedicated machine
needed to be obtained. This meant that this machine now just ran the MS scheduler tool,
which in turn launched the PHP upload script. This populated the relevant database
tables with the information obtained form the WN 3000 software suite, which initially
logged the data using the ccReport tool. The dedicated machine also ensured that
substantial memory was now available for the archiving process, so that many years
worth of data could now be stored and analysed in the future of this project. Once the
software had been installed on the dedicated machine, the software tool needed to
access the logged data that had been stored in CSV format.
10.5 FILE PERMISSION PROBLEMS USING IIS
In order to upload data to the MySQL database using the PHP filesystem commands
outlined in Section 9.4.2.1 access needed be granted to the files so that the “fopen”
function could access them. The files in question, the CSV files logged by the ccReport
tool in the WN3000 software suite on the campus server, were freed up so that they
could be accessed by the filesystem functions by allowing read/write access, hence
allowing the manipulation of data in them for upload to the database.
However even though access was allowed to these files, a file access problem still
persisted, meaning that the files could not be accessed and hence could not be uploaded.
The cause of this problem was the setting relating to files in IIS.
10.5.1 Altering IIS properties to allow file access
On opening the IIS system and accessing the properties tab of the default web site a
number of options are given in order to alter various parts of the running of the site.
This situation can be seen in Figure 10.3.
155

CHAPTER 10
ARENA
TESTING: PROTOTYPE SITE – THE MARDYKE
Figure 10.3: Screenshot of default Web Site options in IIS
In order to allow access to certain file extensions through IIS, it is first necessary to
make their use known to the IIS server by including the file extensions to be accessed in
the default list associated with IIS. This is done in the Server Extensions and Home site
Configuration tabs of the Server, thus meaning that IIS will recognise these file types in
future thus allowing their access and use within the server, and hence solving the file
access problems in this project. Once the data could be accessed it needed to be
archived in the MySQL database.
10.6 UPLOAD PROBLEMS
10.6.1 Automation of file upload procedure concerns
MS Scheduler was used in conjunction with Internet Explorer to run the PHP script that
uploads the MySQL database tables relating to each sensor logged. This process though
meeting the needs of the project for automation of the upload procedure, did not fully
solve the problem as some manual maintenance was still necessary due to the fact that
an executable file could not be created, thus meaning that the script to upload data
needed to be launched using Internet Explorer, which could not be shut down
automatically, hence requiring human intervention to close the program, leaving the
server ready to upload the next sets of values to the database. This human intervention
would be required once a week, so it was not a critical flaw so could be come back to at
a later date for improvements to be made.
156

CHAPTER 10
ARENA
TESTING: PROTOTYPE SITE – THE MARDYKE
During the testing process, it became apparent however that this level of manual
maintenance was not acceptable as a long-term solution to the upload process as it left
open the door for human error leading to shortfalls in the archived data. A number of
other possibilities to negate this problem will be considered in Chapter 11 of this thesis
dealing with future work to be carried out on this project with a view to improving it at
a later date.
10.6.2 Database upload problem
When the data is written to the CSV files, to be stored in the archive folder on the hard
drive of the server by the ccReport tool in the WN3000 software suite, it is written one
line at a time with one line corresponding to a 48 hour period of logged data, this being
192 values. However, if this file was to be written to with each set of new values it
would quickly become unmanageable due to its size. It would also take up unnecessary
space on the hard drive of the server as well as also confusing the upload process, as the
file pointer would need to be repositioned in the file after each new line had been added
to ensure that the correct line of data was uploaded to the database.
Table 10.4: CSV file as archived by the ccReport tool prior to upload to the
database
UC24 - 004 - AHU
UCC4 - 001 01 Pool AHU Pool Area Temperature 900 °C
32976.9792 192 28.63 28.58 28.49
It was therefore decided to empty this file of all its contents after each upload had taken
place, so rendering it blank, ready for the next set of data to be written to it. This
ensured that only one set of data resided in this file at any one time, minimising the
memory used by it, and also ensuring that the file pointer would start from the same
position in the file each time it was to begin upload of data to the database. The CSV
file for the Pool Area temperature, as written to by ccReport is shown in Table 10.4. As
can be seen, only one line of actual sensor data is written to it, with the rest being
repetitive data relating to which sensor is being dealt with.
157

CHAPTER 10
ARENA
TESTING: PROTOTYPE SITE – THE MARDYKE
In order to ensure the smooth running of the software tool, the exact file sizes needed to
be known to ensure that sufficient memory was available to the tool.
10.7 QUANTIFYING DATA STORAGE CAPACITY
Once the data was being uploaded to the MySQL database successfully on an ongoing
basis, it was time to focus on the actual size of the MySQL files created by populating
the database tables.
10.7.1 The MYSQL data file
MySQL stores the procedures necessary to repopulate a blank database with the same
attributes and values as set by the administrator in the original database, in the “data”
folder in the “MySQL” folder on the hard drive of the archiving PC. This folder
contains all the databases associated with the MySQL database along with the contents
of their associated tables. Each table consists of three files, which are necessary in order
to store the data, and use it if needed to repopulate a blank table. The first is the file,
which sets the attributes of the table, remains the same size in kB’s no matter how big
the file gets due to new uploads to it. For the tables in question in this project this file
was 9kB in size.
The other two contain the actual data, which resides in the table and change in size as a
direct result of new data being input. In the case of this project for each upload of 192
data values to the table, these two files increased in size by a total of 3kB meaning that
to store two days of data from one sensor, just 3kB of memory is required.
This however must be taken in context as many sensors would be required to monitor an
entire facility, and the timeframe that they would be archived for would typically be one
year before the data is backed up in an alternative way.
10.7.2 Memory required to store one-years data for one component
For this project, the swimming pool AHU was analysed with sensor data being stored to
calculate the energy load on its individual constituents. Five sensors and their associated
monitored data were required in order to quantify the load on this AHU. Hence, for two
days of archived data, 5 times the 3kB of memory is required, this being equal to 15kB
of memory. Then for one year of archived data, 183 times this 15kB would be required
this being equal to 2.745MB of data. Finally to conclude the calculation, the format files
158

CHAPTER 10
ARENA
TESTING: PROTOTYPE SITE – THE MARDYKE
for each table must be factored in, this being 9kB for each table. So the final memory
capacity used to store the sensor data required to calculate the energy load on one
component of energy use in the Mardyke Arena is 2.79 MB, about half the size of one
“mp3” file, which is tiny when it is considered that the average hard drive capacity of a
PC is 30GB.
Since any errors that had been identified had had solutions found, it was now time to
analyse the data that the software tool was generating, with a view to refining it to the
needs of the user, as well as making sure that it was in fact accurate.
159

CHAPTER 10
ARENA
TESTING: PROTOTYPE SITE – THE MARDYKE
10.8 A CASE STUDY – THE MARDYKE ARENA
10.8.1 Verification of calculation process used in the Energyeye software suite
The software environment was now in place and data could be uploaded to the MySQL
database via the BEMS onsite in the Mardyke Arena using the PC set up on campus
with the associated WN3000 software suite. It was now time to analyse the actual data
that was being delivered onscreen having been operated on to get the associated loads to
make sure that it made sense, and was accurate in the results it obtained.
The data displayed onscreen was defined by what the EPA and DEFRA had advised
regarding the emissions trading scheme, as this would be one area where this data
would be deemed very useful. The calculations were done in the software suite as
explained previously in Section 9.4.1.2 in order to obtain the required quantities, these
being primarily kWh’s and kgCO 2 .
In order to verify the calculation procedure as set out by this software environment, it
was necessary to analyse the results that it returned compared to the actual loads that the
components of energy use in AHU 1 imparted. This was done by returning to the
analysis procedure as outlined previously in Section 9.4.1.2, where the expected results
for the load on the heat exchanger (Q SPEC in Tables 10.1 and Table 10.2) unit were
compared to those returned by the software package (Q in Tables 10.1 and 10.2). The
calculated load (Q) did return just less than those expected (Q SPEC) but this could be
attributed to the fact that efficiencies were not factored in by the software tools
calculation process. These results can be seen in Table 10.1 and 10.2, and lead to the
conclusion that the results returned by the software environment were correct for the
loads on the heat exchanger and the afterheater in AHU 1.
160

CHAPTER 10
ARENA
TESTING: PROTOTYPE SITE – THE MARDYKE
Table 10.1: Comparison of the calculated load on the Heat Exchanger for the
lower bound values of the supply temp using Equation 9.2 and that obtained from
the manufacturers specifications using Equation 9.13
cf corr Ts tp corr Q Q SPEC Tspace To
1.191352 34.96 14.81966 115.5963 134.7243 29.21 3
1.023314 31.97 15.58127 113.2648 127.0448 28.83 4
0.9126 30 17.15616 99.32723 110.2947 28.82 7
1.0531 32.5 18.12029 98.97642 106.6776 29.17 8
0.931708 30.34 17.9604 87.63267 103.5057 29.6 9
0.900798 29.79 18.5125 83.25229 96.88352 29.41 10
1.14583 34.15 19.70876 85.17168 97.60694 30.54 11
Table 10.2: Comparison of the calculated load on the Heat Exchanger for the
upper bound values of the supply temp using Equation 9.2 and that obtained from
the manufacturers specifications using Equation 9.13
cf corr Ts high tp Corr Q Q SPEC Tspace To
1.920564 45.49 12.81141 125.2956 135.6703 26.38 0
1.919292 45.47 13.19682 119.2849 133.9452 27.07 1
2.003244 46.79 13.29897 110.5039 133.1105 27.92 2
1.594932 40.37 15.87591 106.3664 121.3687 28.81 5
1.56822 39.95 16.47304 102.4263 118.0298 29.21 6
10.8.2 Analysis of visual display of results obtained from the Energyeye software
suite
Once the actual data and the associated calculations had been checked for accuracy, the
next logical step was to look at the graphical interpretation of these results to see if they
allowed the user the ability to analyse data visually in an instant as this was the goal of
the graphs used.
161

CHAPTER 10
ARENA
TESTING: PROTOTYPE SITE – THE MARDYKE
Figure 10.4: Screenshot of graphs used to display energy utilised in the Mardyke
Arena
It was important to integrate a monthly breakdown of results into the display
mechanism to highlight the seasonal variations that implicitly occur in a facility such as
this. This was achieved by assigning one table row of the graph per monthly energy use
total as calculated by the Energyeye software environment. By doing this an unjustified
period of high-energy use could easily be identified.
The graphs used in this project even though crude in their make up at the present time
do indeed serve to illustrate adequately the areas of interest to a facility manager. They
allow the user to view the building energy use and CO 2 emissions levels for a defined
period allowing them to make decisions easily based on their results.
10.8.3 Format of reports generated
In order to make a final decision on the exact format of the reports generated by the
Energyeye software environment, the Environmental Protection Agency (EPA) [EPA,
2003] were contacted in order to establish what criteria they would be basing future
162

CHAPTER 10
ARENA
TESTING: PROTOTYPE SITE – THE MARDYKE
emissions trading on, and to find out exactly what energy use quantities it would be
necessary to obtain from a buildings energy use to establish them.
On contacting the EPA, it became evident that the emissions trading scheme was at a
very early stage in its establishment in this country and as such the exact quantities
needed could not be finalised by the authority at this time. However they recommended
contacting DEFRA, the Department for the Environment, Food and Rural Affairs
[DEFRA, 2003] in the UK, who had initiated the scheme in the UK in 2002, a scheme
that the EPA said would be followed closely by this country.
On contacting DEFRA, it was established that the overall building energy in kWh’s
would need to be established for a twelve month period as well as the associated CO 2
emissions that resulted. This meant that in order for the report generated by this
software environment to be useful to the emissions trading scheme in this country,
which would follow the DEFRA version closely, it would need to include both of the
aforementioned quantities.
The report generation procedure as outlined in Section 8.4.3 was now examined with a
view to implementing the required structure so as to deliver the relevant information to
the authorities in future. A calculation function was written in the classes PHP file
where much of the functionality of the package resided. This function calculated the
required energy use for the necessary period as well as the CO 2 emissions associated
with it, when called upon by the associated PHP file. This information was then written
to a specially created blank .xml file when the correct HTML links were followed,
saving the file to the hard drive of the users computer in the process. The gbXML file
created as well as a snippet of the code used is shown in Figure 10.5 and Table 10.7
respectively.
163

CHAPTER 10
ARENA
TESTING: PROTOTYPE SITE – THE MARDYKE
Figure 10.5: gbXML report generated
Table 10.7: Code snippet of PHP required to output the gbXML report
function calc_real_monthly_heat_load_data()
{
.
.
.$sumTotal += $iTotal;
$Total_Gj=$sumTotal*0.0036;
$Total_Gj_m=$Total_Gj*0.001;
$Total_cost=$sumTotal*0.08;
}
$handle = fopen("report.xml","w");
$tofile = "\n";
$tofile .= "\n";
$tofile .= "\n";
$tofile .= "\n";
$tofile .= "\t\t" . $sumTotal . "\n";
$tofile .= "\n";
.
}
164

CHAPTER 10
ARENA
TESTING: PROTOTYPE SITE – THE MARDYKE
10.8.4 gbXML Integration with third party tools
The next step on generating a gbXML report was to show it in use at the next phase,
that being for example by the engineer on its receipt. It is hoped that because an XML
based language was used as the transfer language that integration with third party
energy analysis packages will eventually result as more and more packages become
XML compliant, as explained in Section 5.2.3. However for now the use of the
Extensible Stylesheet Language (XSL) to display the gbXML report is illustrated
showing how the eventual recipient of the gbXML report will be able to view the report
in a user friendly, functional manner.
XSL [XSL, 2003] is a standard recommended by the World Wide Web Consortium,
which allows developers to format XML documents for World Wide Web viewing
[Kim, 2001] as explained in more detail in Section 8.4. With the inclusion of an XSL
stylesheet reference in the XML document to be transformed using the XSL file as
shown in Table 10.8, the XML document is manipulated for display according to the
rules as set out in the XSL file.
Table 10.8: XML link to XSL Stylesheet
Once this link is initialised the XML source document is transformed into XHTML, a
hybrid version of HTML, which can be viewed in a web browser much like HTML.
This gives XSL the ability to convert large chunks of visually unpleasing data into a
much more aesthetically pleasing format.
In the case of the gbXML report generated by the ENERGYEYE software environment
relating to building specific archived data, the XSL “matches” the data in the XML file
with formatting objects, allowing the data to be displayed in a more visually pleasing
manner, yet not changing the actual content of the file. A code snippet of both the
gbXML report generated and the XSL file used to display it is shown in Tables 10.9 and
10.10 respectively, and the way it will appear in the browser window is shown in the
screenshot in Figure 10.6.
165

CHAPTER 10
ARENA
TESTING: PROTOTYPE SITE – THE MARDYKE
Table 10.9: Generated gbXML report
32.790
29.190

CHAPTER 10
ARENA
TESTING: PROTOTYPE SITE – THE MARDYKE
Figure 10.6: Screenshot of Display result of XSL transformation of gbXML report
In order for the recipient of the gbXML report to view it in the browser window using
the associated XSL stylesheet, they simply place the gbMXL report in the same folder
as the stylesheet, and then open it using their usual web browser, thus again illustrating
the extensibility of the XML programming language.
10.9 RESULTS AND CONCLUSIONS
10.9.1 Using APACHE web server in place of IIS
Because of the problems encountered with file access using Microsoft’s IIS, and the fact
that it had some security issues, as well as its temperamental installation procedures, an
alternative may be looked at in the web server area, that being the Apache Web Server
[Eweek, 2003]. After three years of development, Apache 2.0 has been released with the
biggest impact being on Windows servers, where Apache can now perform as a
production-level Web server. Unlike previous Windows versions of it, which were built
from ported Unix code, the new version is written as a native Windows application and
is recommended by the Apache Software Foundation for production use.
The performance of Apache 2.0 and Microsoft Corporations Internet Information
Services 5.0 when compared, both running on Windows 2000 Advanced Server, yielded
167

CHAPTER 10
ARENA
TESTING: PROTOTYPE SITE – THE MARDYKE
a positive result for Apache with little or no performance dips associated with a switch
from IIS 5.o to Apache 2.0.
The biggest advantage is only seen when security is discussed. Apache's security track
record is excellent, while IIS is not so secure. Microsoft has announced that 10 new
security flaws have been discovered in IIS, on top of the ones that already exist.
One potential setback that would seem obvious when moving to Apache from IIS is the
open-source server's unfriendly administration interface with all configuration and
administration done by editing “.conf” files. This however could prove to be an
advantage as many experts now advise disabling administration interfaces, especially
Web-based ones, because they are a potential attack point for hackers.
As well as these improvements in security, Apache also has fewer bugs in its operation,
which could mean the alleviation of the file access problems experienced in this project,
which caused substantial problems in the implementation phase of this software tool.
With apache, as soon as the installation has been achieved successfully, which is now a
little easier with the new release, with a bit of research, the server’s seemingly
unfriendly configuration and administration could be overcome. The result would be a
more secure, much more smoothly run web server, so alleviating the problems
encountered in the duration of this project with IIS 5.0.
10.9.2 Creation of an executable file to automatically upload data to database
Due to the problems encountered in this project with automatically uploading the
MySQL database on a daily basis with data obtained via the ccReport tool in the
WN3000 software suite, more research will need to be done to determine if there is a
way in PHP or some other programming language to create an executable file that could
be scheduled to run daily. This program would when launched connect to the database,
do the necessary file manipulation, then upload the data to the relevant tables in the
database before automatically finishing in wait of its next execution the following day.
A number of languages could theoretically do just this such as ASP or C++, with C++
definitely having the ability to have executable files created. ASP on the other hand
would need to be researched to see whether it was possible, the only advantage in this
being its similarity to PHP, so lessening research time.
Another possibility would be to use a .bat system file, which would have the path to the
necessary PHP file included in it. This .bat file could then be launched using the MS
168

CHAPTER 10
ARENA
TESTING: PROTOTYPE SITE – THE MARDYKE
scheduler tool every two days in order to upload the 192 values logged by ccReport for
this period.
10.9.3 Development of a more functional XSL stylesheet to display gbXML
reports in a graphical form to a third party
In Section 10.8.4 an XSL stylesheet is used to display a gbXML report as generated by
the ENERGYEYE software environment in order to enable a third party to view the
report on an independent machine.
Even though this method is functional and does serve to enable access to the report by
third parties, it is somewhat crude in its make up. The next step in the development
process of this area of the package could be to include a graphical element to the report
viewing procedure, so allowing the generated data to be displayed in bar graphs or pie
charts allowing the third party to view and hence analyse the data that much easier.
Another area that the XSL stylesheet could improve in the display of archived data
would be to highlight sensor data that was above the set points as set by the control
strategies, allowing the third party to once again identify areas where problems may be
present that much faster and more efficiently.
These areas will be returned to in the next chapter on future work.
10.9.4 Deliverables
The first objective of this project was to archive the data logged by the BEMS. This was
achieved using the MySQL database management system. Once in this database the
data was then free to be manipulated into the building specific gbXML data exchange
language. This was again achieved with the result being that the data logged by the
BEMS system was now interoperable in a gbXML file. This file could now be
exchanged with gbXML compliant analysis applications for further analysis.
The GUI was also developed using the language of the World Wide Web, HTML. This
meant that it could be uploaded to the Internet for remote access. It also meant that it
was easy to use and navigate for the unskilled user, which was another objective of this
project. With each of the initial objectives of this project met, it was now time to begin
to look to its future, and any improvement to it that could be made.
169

CHAPTER 10
ARENA
TESTING: PROTOTYPE SITE – THE MARDYKE
10.10 SUMMARY
In order to ensure the smooth running of the software environment as developed in
Chapter 9, an extensive testing process was undertaken to ensure that any flaws in the
design could be fixed, and improvements in user interaction achieved. It is important to
approach the testing process with the attitude of executing a program with the intent of
finding errors, since testing can only show the presence of errors in a program and never
their absence.
The network connection to the Mardyke Arena was determined to be faulty and needed
to be repaired so that the logging process would be uninterrupted. A number of areas
where this error was originating were examined. It transpired on future inspection that
the network card on the PC used as the supervisory PC on campus was in fact not fully
operational. Returning the machine to the manufacturer for the fault to be repaired could
have solved this problem, however, the decision was taken to purchase a new, dedicated
PC for the purpose of this project alone.
There were also a number of problems with file access, which on inspection were due to
errors in the IIS configuration. This was examined and solved.
The core of the package was in place and data could be uploaded to the MySQL
database via the BEMS onsite in the Mardyke Arena using the PC set up on campus and
the associated WN3000 software suite. It was time to analyse the actual data that was
being delivered onscreen having been operated on to get the associated loads to make
sure that it made sense, and was accurate in the results it obtained. The load calculated
by the software tool did return just less than those expected as calculated from equations
present in the specifications for the heat exchanger but this could be attributed to the
fact that efficiency’s were not factored in by the software environments calculation
process. These results lead to the conclusion that the results returned by the software
environment were correct for the loads on the heat exchanger and the afterheater in
AHU 1.
The visual display portion of the software environment, as well as the report generation
format were also examined with a view to refining them. With each of the initial
objectives of the project met, it was now time to move on to examining its future.
Chapter 11 will take this analysis to the next level by examining areas where
improvements could be made to the software tool in its future.
170

CHAPTER 11
FUTURE WORK
FUTURE WORK
If this software environment is to be a fully effective in displaying, analysing and
generically reporting real building data, it must be developed further than has been
achieved in the timeframe of this thesis. A number of possible areas have been noted
with a view to making improvements to the environment, with these now being
examined in more detail.
11.1 METERING OF FACILITIES
11.1.1 Introduction - present metering trends
A feature of energy usage is that its consumption can be accurately measured [DETR
Fuel, 2002]. The electricity supply board supplies a meter, with the same company
reading it in order to charge the consumer for the energy utilised over a certain period,
usually bi-monthly. The positions of these meters are not normally a concern of the
customer, and are normally placed where it is most convenient and/or cheapest for the
installer. The bill is then sent to the consumer in question, and is usually not questioned.
By this, it is meant that, the maximum demand loading is not questioned and the
quantity of energy used is blindly paid for. Unfortunately there are a number of
problems with this system.
11.1.2 Sub-metering
When analysing a medium to large-scale industrial building, it becomes apparent that
the energy metering in use in most cases, is not sophisticated enough to measure each
constituent part of the buildings energy usage. To achieve the best energy monitoring
and load matching results, each prime energy user of a building must be metered
separately so that their usage can be analysed individually, with a view to tailoring their
energy usage to match the load put on them on an individual basis. Energy consumption
is at a minimum when the source (electrical energy) tracks the load perfectly. When a
mismatch occurs, energy losses are high [Bhatt, 2000]
If a situation is imagined where the lighting and air-conditioning equipments’ energy
usage is recorded by the same meter, it would take a qualified engineer to look more
closely at the situation in order to differentiate how much energy the air conditioning
171

CHAPTER 11
FUTURE WORK
plant was using, taking out the energy usage of the lights, and whether this was good
practice or not, if a problem arose with it. This would however be a much easier
problem if the air conditioning system and the lighting were individually metered as the
energy usage could be read directly from the meter and compared with benchmarks to
see if a good practice situation existed. This second individually metered set-up is
known as sub-metering and is essential in all medium to large-scale industries if their
energy usage is to be monitored and tailored to efficiently meet their needs at least cost.
11.1.3 Sub-metering and this package
This package uses the philosophy of Whole Building Energy analysis as examined in
Chapter 4 to break down the energy usage for an entire facility into its constituent parts.
This is undertaken so that the usage can be first of all measured and accounted for, and
secondly analysed with a view to reducing consumption at those areas where energy is
being wasted.
Through the use of sub-metering in the Mardyke Arena, the prototype site used in this
project, the energy use could have been more closely tracked, making it easier and much
more accurate to compare any results obtained through the analysis done in this package
against real values obtained from the individual meters.
So looking to the future, if sub-metering were in place in any facility that this package
were to be integrated with, the baseline level of energy use obtained from meters could
more easily be calibrated against ensuring that any figures obtained in future were
absolutely correct and accurate. This would mean that any improvements recommended
as a result of the analysis done by this package would indeed be warranted, and would
also ensure the accuracy of the reports generated by it to be integrated into third party
off the shelf energy analysis packages.
11.2 TECHNOLOGY REQUIRED TO ENSURE OPTIMUM INFORMATION
RETRIEVAL FROM A FACILITY
In analysing a building and its energy use, it is essential that the correct technology,
whether that is sensor or flow technology, be in place so that all the data needed to
accurately quantify the energy load on the entire building can be gathered.
172

CHAPTER 11
FUTURE WORK
11.2.1 Positioning of sensors in a facility
In using the whole building energy analysis philosophy to analyse building energy use,
it is essential that each component of energy use be equipped with sensors effectively
allowing the necessary information to calculate the load on each to be logged by the
BEMS. This can be more easily understood when the extensive procedure used in this
project to calculate the load on the components in AHU 1 in the swimming pool area of
the Mardyke Arena is considered, as is explained in Section 9.4.1.2. In this section, due
to a lack of a sensor directly before the afterheater, complex equations had to be
developed, using a correction factor, to establish the condition of the air before the unit
and hence determine the load on the afterheater and the heat exchanger unit. This
scenario meant that a lot more work than would have been necessary had a sensor been
in place monitoring the pre-afterheater temperature, had to be done.
In future building energy projects, this research would point very strongly towards
having each component of energy use sensored separately, so that their individual loads
could be calculated independently. This would allow the overall energy use to be
compared against the sum of the constituent energy users in the building to see if a
shortfall occurs, and if so would identify the problem with the system right down to its
individual components, so allowing a more accurate problem solving loop to exist in the
system.
To put this into practice would require the sensor technology to be included in the initial
design phase of the building process of a new facility, with each AHU being controlled
by a separate controller, which is linked to the individual sensors monitoring each
component. By doing this in the design phase, the need to install sensor technology at a
later date at much greater cost and with implications for the control set up in the facility
causing further trouble and expense is avoided, so ensuring a least cost solution to
supplying the most energy efficient facility.
This individual component monitoring would also allow the entire lifecycle of
performance of each component to be monitored, so illustrating the optimum timescale
for equipment replacement and other necessary maintenance work.
11.2.2 Integration of flow meter sensors
This much like the temperature sensor technology would allow the load on each
component to be monitored more accurately, as at present, the commissioned flow rates
are used in the calculation process to obtain the loads on the constituent parts of the
173

CHAPTER 11
FUTURE WORK
AHU system. If the flow rates were to be monitored by sensors at different points along
the ducts, this coupled with the other sensors in the system would allow the exact load
at any time to be calculated, based on time specific flow rate data, so taking out any
possibility of errors due to the use of incorrect averaged data.
11.3 XML INTEGRATION WITH OFF THE SHELF APPLICATIONS
At present the XML output generated by this software tool is not directly usable by
packages such as DOE and ENERGYPLUS as they do not support XML. By this it is
meant that the information is there to be uploaded by hand by the packages’ operator
from the easily understandable gbXML document but is not automatically up-loadable
to the package itself.
However, with XML being a data format that can be read by any IT application,
allowing controller logged data to be transferred over an Ethernet into say a spreadsheet
or a billing package for further analytical purposes [CIBSE, 2002], it is almost certain
that these engineering software packages will integrate XML in the not too distant
future. In fact ENERGYPLUS has already implemented support for XML in the form of
IFX, which means that it will write an XML version of the IFCs to the output file. However, at
present there is a means to translate XML data into a more easily understandable format to facilitate third
party analysis, this being through the use of XSL.
11.3.1 Using XSL for display of gbXML reports to facilitate third party analysis
In Section 10.8.4, XSL was used to display the archived data returned from the MySQL
database in an easy to read, aesthetically pleasing table. This file would reside on the PC
of the third party analyst and would be linked to the gbXML report generated by the
Energyeye package on its receipt by a call embedded in the report itself.
However, even though this facility would enable the third party analyst to have access
to the report in an easily understandable format, it could do so much more with a little
research and development.
A bar graph could be implemented in order to highlight the kWh usage per month in
much the same way as was achieved using the HTML tables in this package. This
would however require some research into the XSL language but once implemented,
would add extra functionality.
Also, by doing a quick comparison check on returned kWh or kgCO 2 results against for
example the maximum levels allowed before carbon taxation would result, the figures
174

CHAPTER 11
FUTURE WORK
above these levels could be highlighted in an alarm colour to draw the analysts attention
to the guilty time periods, so that remedial action could be set in motion.
This would be just one small and limited use of the gbXML report but it does serve to
show the attractiveness of having a generic data exchange format, which could be
integrated with third party analysis tools, thus freeing up the data for analysis off-site at
least cost and maximum efficiency.
11.4 USING GD-LIBRARY TO GRAPHICALLY INTERTPRET RETURNED
RESULTS
The display portion of this project was a very important aspect of it in order to allow the
software environment to be as accessible as possible to as many people as possible. It
was hoped that by displaying the information in graphical format that it would be more
easily understandable to the untrained eye, and hence be open to a larger share of the
market. It was also hoped that this graphical display would allow for the easy
identification of any existing problems in plant operation, so leading to a solution being
sought that much faster.
Because of the limited time and funding available to complete this project it was not
possible to fully explore what would have been a better solution to the graphical display
portion of this project as explained in Section 9.5.2, that being the GD-Library of
display functions. Instead tables were used to display bar graphs onscreen allowing the
user to identify fluctuations in load visually in a more crude, yet still effective manner.
The GD-Library however, would have facilitated the use of pie charts (Figure 11.1) as
well as comparative line graphs (Figure 11.2) to examine archived data, so allowing a
more visually attractive and possibly more effective solution to be arrived at.
175

CHAPTER 11
FUTURE WORK
Figure 11.1: Pie Chart created using GD Library in association with PHP [ZEND,
2003]
Figure 11.2: Comparative Line Chart created using GD Library in association
with PHP [ZEND, 2003]
11.4.1 Introduction to GDlibrary
The GD graphics library is an open source library, which allows programmers to easily
generate PNG, JPEG, and WBMP images from many different programming languages
[GD Lib, 2003]. It is an up-loadable library of PHP functions that allows the
programmer to set parameters for the construction of a graph, either a pie chart or bar
graph, and even line graphs, based on returned values from a database.
11.4.2 GDlibrary as a future graphical tool
The use of the GD graphics library in the future of this project would enhance the
display portion of it. It would allow the returned results from the MySQL database to be
displayed in comparative line charts as in Figure 11.2, which would be very helpful in
the analysis of the archived sensor data to see when any set points had been surpassed.
176

CHAPTER 11
FUTURE WORK
The use of pie charts as in Figure 11.1, would allow the monthly load breakdown in
kWh’s as well as the kgCO 2 emitted each month to be much more closely scrutinised at
a single glance as the main energy using and CO 2 emitting months would be
immediately apparent from first glance at the pie chart.
Numerous other types of graphs could also be implemented to further add to the
functionality and broad scale appeal of the returned data allowing easy access to and
analysis of the archived data.
11.5 WHOLE BUILDING ENERGY ANALYSIS OF THE MARDYKE ARENA
The Mardyke Arena as examined in Chapter 6, was a facility controlled by four AHUs
as well as with a combination of extract/supply fans and separate all in one Mitsubishi
air conditioning units in order to maintain comfort levels. The decision was taken at an
early stage to focus on one AHU in order to simplify the calculation process, as well as
make sure the software tool was working correctly. The code used and the scope of the
project were also kept to a minimum using just one AHU. This simplification was
necessary due to the time and funding constraints that this project had. It would simply
not have been possible to examine each part of the mechanical system in existence in
the Arena, and implement it into the software environments analysis procedure, in the
time available, and with the funding available.
However, with one AHU being used as a prototype for the packages development, and
the procedure for analysis as well as the code used to achieve this analysis being fine
tuned, the next step, that being to take on the analysis of the whole facility, would now
be made a lot easier with the same steps being followed. This would however require
substantial time, as the individual AHUs operation would need to be firstly understood,
then broken down into their individual parts in order to identify the energy consumed by
each different components. Then the relevant sensors would need to be logged by the
ccReoprt tool in the WN3000 software suite on the server in order for the data to be
eventually uploaded to the MySQL database table created specifically for that
component of energy use. However this process could be made more difficult if the
particular area was not available to log in ccReport as was the case in the pre-afterheater
temperature in AHU 1 as explained in Section 9.4.1.2.
Once any problems in this area had been solved, the next step in the development
process would be the SQL calls and the calculations necessary in order to quantify the
energy used by that piece of apparatus. This should again now be much easier with the
177

CHAPTER 11
FUTURE WORK
successful completion of the calculations to quantify the load on the prototype AHU,
with similar calculations being required by each component of energy use thereafter.
Then once the correct results are being returned by the SQL queries via the PHP used to
connect to the database, the GUI would need to be updated to include links and display
mechanisms for each new portion operated on. This process would again be time
consuming if repetitive in nature, as the code needed to create the different portions of
the GUI would need to be developed then linked to the existed pages. The navigation
would also have to be improved as the front-end portion of the software tool expanded
in order to keep the usability, which is one of the most important aspects of the software
tools’ operational goals.
11.6 CREATION OF AN EXECUTABLE FILE TO AUTOMATICALLY
UPLOAD DATA TO THE MySQL DATABASE
At present the automatic upload procedure used to populate the Mysql database with the
information logged by the ccReport tool is flawed in the fact that it requires human
intervention on a weekly basis in order for it to function sufficiently. The MS Scheduler
program launches a PHP script via an Internet Explorer browser window, and the
database is populated by the actions that take place in the PHP script. However since
PHP has no way of creating a standalone executable file which could be launched
independently of the browser window, an alternative programming language needs to be
identified which could house the PHP script in an executable file which in turn could be
launched by the MS Scheduler tool hence requiring no human intervention to shut it
down when its job is complete as is presently the case.
The most likely option for the smooth automation of this upload procedure would seem
to be through the creation of a .bat system file which would run the PHP script in the
associated upload file. This .bat file would link to the PHP file by having the associated
file path included in it.
Once the .bat file was created and seen to be operational by testing it using the DOS
command prompt dialog box it could be automatically launched by the MS scheduler
tool every two days. This would correspond to 192 data points, which is the maximum
logging capacity of the controllers in place in the Mardyke Arena. No human interaction
would then be required to facilitate a successful data upload. It would also run in the
background so not interrupting any other processes being carried out on the system.
178

CHAPTER 11
FUTURE WORK
11.6.1 Implementing this solution
In order to accomplish this task, the .bat file creation and running system would need to
be researched and understood. As this problem would only be a simple implementation
of this system, it would not be seen as a major undertaking and would definitely be the
most likely and efficient solution.
11.7 SESSION CONTROL IMPLEMENTATION
The data dealt with in this project was of a sensitive nature and so needed to be treated
very carefully in order to ensure its secure nature. In looking at this aspect of the
development process, various means of securing any data collected and archived so that
only the authorised personnel could access it were identified.
Again the time constraints on this project proved the deciding factor in this area, as
password protection leading to a javascript pop up window was utilised. This low level
security ensured that the everyday web surfer could not access the data, but did leave it
open to the more experienced hacker. With more time and resources to develop this
project, session control would be the chosen option as discussed in Section 8.5.1 as this
would allow the software environment to more closely track the users logged on and
ensure that they remain the same from secure page to secure page.
Session control would require some in depth research as in PHP it is a developing area
that has just been implemented in the last update of the language, so some bugs would
have been inevitable. However with the time to fully understand the process used
alleviating any bugs along the way, it could be successfully implemented in this project.
11.8 REMOTE UPLOAD OF DATA WITH SSL INTEGRATION
In order to take this project to the next level of operation, a remote upload procedure
would need to be developed. This itself would require minimal coding on the
programmers part as the procedure would remain the same from company to company if
the correct technology was installed onsite, i.e. the WN3000 software suite, and the
ccReport tool that comes with it, but again the sensitive nature of the data uploaded
would mean that security issues would need to be addressed in the form of the SSL
security certificate as discussed in Section 8.5.2.
179

CHAPTER 11
FUTURE WORK
11.8.1 Procedure outlined
A number of possibilities for this process are currently used everyday in the E-
commerce business world.
11.8.1.1 Upload of data online
The first and most widely used method would be through the use of an upload screen
which would allow the facility manager to browse through the archive on the
supervisory PC in his/her facility until the file for upload is found, then hitting an
upload tab onscreen so setting in motion the upload process. This method is used in a
cruder manner on guestbook’s or areas of sites that request user feedback. The user
types their information or request into a dialog box and on hitting an upload button the
data is transferred to the webmaster, or owner of the sites designated folder for their
inspection at their convenience.
This method would serve this purpose very well, but some concerns would exist with its
utilisation. The fact that a lot of responsibility resides with the facility manager for the
upload of the correct file could lead to user errors occurring and the wrong data being
uploaded. Some knowledge of the Internet and its use is also required for this method to
run smoothly and this in turn could lead to problems with the procedure if the facility
manager is unfamiliar with the process. Finally the security issue would again be a
cause for concern as the data being transferred over the internet means that it would be
free to be attacked by hackers should they wish to do so, unless a secure transaction
were to take place which could alleviate this problem.
None of these problems are fatal however and this solution would be looked at further
before discounting it totally
11.8.1.2 The MySQL data file
Another option in receiving data from remote sites would be to use the MySQL data
file. In this file as explained in Section 10.7.1, the entire contents of the MySQL tables
is stored and can be used to repopulate a new remote MySQL database identical to the
one that is maintained on the supervisory PC of the facility where the information was
gathered.
This file could be emailed on a periodic basis automatically to the staff at
ENERGYEYE, and then uploaded to the administration database where calculations
180

CHAPTER 11
FUTURE WORK
would take place so leading to output being generated for the GUI where the facility
manager would log into to view energy use data.
This method would require no actions to be taken by the facility manager so meaning
that the chance of human error would be significantly reduced in this process. However,
this scenario would require human intervention at the other end of the system with an
employee of ENERYEYE being required to upload the data to the relevant database,
this being however a relatively simple operation and also one being done by a trained
individual used to the process.
Further development of this process would need to be undertaken including the
automation of the email process, but it would seem to be a viable solution to this
problem, and could serve to be the best practice option.
11.9 DEVELOPMENT OF A MORE PROFESSIONAL GUI
At the completion of this project, the GUI was functional and aesthetically pleasing, as
well as easy to navigate. It also displayed the returned data in a format that was
accessible to even the most untrained eye that being in easy to understand graphs.
However, it did not have a very professional look or feel to it. It was still somewhat
crude in its make-up, with no branding or logo to define its market.
The Macromedia Studio MX software package purchased during the course of the
project has the facility to change all of this. With this package, the user interface could
be totally revamped. The Fireworks MX portion of the Studio MX package could be
used to design a logo along with any navigation buttons or artwork necessary to create a
custom made brand to go along with the software tool. This would then be easily
identifiable when put into action on the Internet. This branding would not only serve to
add to the functionality and feel of the package but would also serve to identify the
software environment in its individual market.
The Dreamweaver and Flash MX development section of the Studio MX package could
then be used to integrate these Fireworks created icons and buttons into the GUI. This
coupled with Dreamweaver’s ability to define the look and layout of the GUI, and
Flash’s ability to add to the dynamic nature of the site using animations and other
dynamic elements to bring the GUI to life, would serve to upgrade the accessibility and
navigating elements of the GUI to integrate it into the business world more effectively.
181

CHAPTER 11
FUTURE WORK
11.10 FUTURE BUSINESS PLAN
In looking to take this software environment to the next level in terms of finding a
genuine place for it in the energy management market, a business model will need to be
developed. This model will need to look at the market that the package will best suit as
well as the way that it will generate revenue from this market.
11.10.1 E-Commerce business models
As the delivery tool used to facilitate this software tool is the Internet, the E-Commerce
business models in existence were examined with a view to identifying a suitable one to
use.
11.10.1.1 Introduction to business models on the web
Business Models are one of the most discussed yet also the most misunderstood aspects
of the Internet. A Business Model is a method of doing business that allows a company
to sustain itself by creating revenue to meet its production costs [Rappa, 2000]. It does
this by specifying a company’s place in the value chain so identifying where it can
make money.
Some models are quite simple, whereby a company produces a good service or product
and sells it to its customers, with all going well the revenue generated by sales of the
product or service exceeding the running costs of operation of the company hence
meaning that it has made a profit. It is a way of describing the logic of a business
system for creating value behind the actual processes involved in the production of this
service [Osterwalder, 2003].
On the other hand, some Business models are more complicated such as in the
broadcasting sector, where programmes are broadcasted for free with any revenue
generated being a product of a complex network of advertisers and content creators,
with the bottom line depending on all of these competing factors.
11.10.1.1 CATAGORIES OF BUSINESS MODELS
There are nine main E-commerce Business Models that company’s use when
developing an Internet business strategy. Companies may even combine several
different models as part of their overall strategies. The nine Business Models are:
182

CHAPTER 11
FUTURE WORK
1) Brokerage – Brokers are market makers who bring buyers and sellers together to
facilitate transactions, charging a fee or commission for the service that they
provide;
2) Advertising – The web-advertising model is an extension of the traditional
media broadcast model, with the web site providing content to attract viewers to
the advertising that they are home to;
3) Infomediary – some firms act as infomediaries assisting buyers and/or sellers
understand a given market;
4) Merchant – Wholesalers and retailers of goods and services with sales being
based on list prices or through auctions;
5) Manufacturer – A model based on the power of the web to allow a manufacturer
to reach buyers directly thereby compressing the distribution channel;
6) Affiliate – Instead of trying to drive a high volume of traffic to one site, the
affiliate model provides purchasing opportunities wherever people may be
surfing. It does this by providing financial incentives to affiliated partner sites
with purchase opportunities being available through a click through system;
7) Community – This model is based on user loyalty, with users having a high
investment in both time and emotion in the site and may even be content
providers;
8) Subscription – Users are charged a periodic fee to subscribe to a service, with
some sites providing free content with premium, subscription material;
9) Utility – This “on-demand” model charges people for the frequency of their use
of the site and is a type of metering approach .
183

CHAPTER 11
FUTURE WORK
11.10.1.2 Business model suited to this software environment
Having researched the Business Models in existence for businesses on the Internet, the
Subscription model would be the one of most interest in conjunction with the
development of this package for use on the Web.
Companies would subscribe to the service and hence be set up on site with the required
software to facilitate the logging of their sensor data in the same way as is described in
this thesis. This data would then be uploaded to the remote database server on a periodic
basis, with the company having access to the results using a username and password
individual to them, while being protected by an SSL certificate.
The Subscription method seems perfect for this scenario as no limit to the amount of
viewings of the data would exist, and companies would only see the benefit of the
logging process the longer they were signed up to the service so ensuring continuous
revenue is generated.
11.11 SUMMARY
If this software environment is to be a fully effective in displaying, analysing and
generically reporting real building data, it must develop further than has been achieved
in the timeframe of this thesis. A number of areas where improvements could be made
to this software environment have been identified, with sub metering of the facility and
the use of flow and temperature sensors for every component of energy use being two of
the main ones.
Changes to the display portion of the GUI would also serve to add to its functionality
along with a more secure means of transferring information. A subscription based
business plan has also been identified to fully exploit the future of this software
environment.
With the necessary time and financial backing this software environment could monitor
and archive building energy use remotely, this being a developing area of the building
services field. Due to the EU directive on building energy use this area of the market
will be of great importance in the coming years, with this software environment being
the perfect solution.
184

CHAPTER 12
REFERENCES
12 REFERENCES
Aloisio et al, 1999, An XML Architecture for High Performance Web-Based Analysis
of Remote Sensing Archives, Future Generation computer Systems 91 – 100
Al-Rabghi, Hittle, 2001, Energy simulation in buildings: overview and BLAST
example, energy Conversion and management 42, 1623 – 1635
Assessment Method, Cibse Members CD
Badard, Richard, 2001, Using XML for the Exchange of Updating Information between
Geographical Information Systems, Computers, Environment and Urban Systems 17 –
31
Bennett, Newborough, 2001, Auditing Energy Use in Cities, Energy Policy 125 – 134
Bhatt, 2000, Energy Audit Case Studies II – Air Conditioning (cooling) Systems,
Applied thermal Engineering 20 (2000) 297 – 307
Bonaccorsi, Rossi, 2003, Why open source software can succeed, Research Policy,
article in press
Carbon dioxide, Environmental Science & Policy 1 (1998) 27±38
CIBSE CDa, 2003, Facilities Energy Management, 1997, Members CD
CIBSE CDb. 2003, Energy Efficiency in Buildings Guide F, 1998, Members CD
CIBSE, 2002, The IT Factor, Building Services Journal, June 2002
CIBSE, 2002a, Building Control Document, Chapter 5, published by CIBSE
CIBSE, 2002b, Building of the Future, Building Services Journal, June 2002
185

CHAPTER 12
REFERENCES
CIBSE, 2002c, Market Watch, BMS, Building Services Journal, June 2002
CIBSE, 2002d, Technological Winds of Change, Building Services Journal, June 2002
CIBSE, 2002e, Building Energy Auditing, Chapter 18A, published by CIBSE
CIBSE, 2003b, Are We Connecting Yet?, Building Services Journal, July, 2003.
Clarke et al, 2002, Simulation assisted Control in Building Energy Management
Systems, Energy and Buildings 933- 940
Clarke et al, Assisted Control in Building Energy Management Systems, Energy and
2002, Simulation Buildings 1449, (2002) 1 – 8
Crawley et al, 2001, Energyplus: creating a new generation of building energy
simulation program, energy and Building 33, 319 – 331
DETR ECON 19, 2002, ECON 19, Energy Consumption Guide published by the
Department of the Environment, Transport and Regions (DETR) in the UK
DETR Energy, 2002, DETR energy monitoring and targeting guide 125
DETR Fuel, 2002, Efficiency booklet 9, Economic Use of Electricity in Industry
DETR Fuel 1, 2002, Efficiency booklet 1, Energy Audits for Buildings
DETR 2002, Department of the Environment, Trade and Regions, UK, Energy
Consumption Guide 78
DETR GPG 219, 2002, Good Practice Guide 219, Energy Efficiency in Swimming
Pools
186

CHAPTER 12
REFERENCES
Dhakal et al, 2003, Estimation of heat discharges by residential buildings in Tokyo,
energy conversion and management 44, 1487 – 1499
DPE, 1999, Paper on Sustainable Energy
DPE, 2002, Green Paper on Sustainable Energy
EEBPP, 2002, General Information leaflet 65, Metering Energy Use in New/non
Domestic Buildings
EEC, 1998, European Environment Council meeting 16-17 June 1998 –
Luxembourg
EIA, 1992, EIA's Commercial Buildings Energy Consumption and Expenditures 1992
DOE/EIA-0318 (92)
Elmasri and Navathe, 2000, Fundamentals of Database Systems
EU Directive, 2002, Directive 2002/91/Ecof the European Parliament and of the council
of 16 December 2002 on the Energy Performance of Buildings, Article 1 parts c and d.
Filippin, 2000, Benchmarking the Energy Efficiency and Greenhouse Gases Emissions
of School Buildings in Central Argentina, Buildings and Environment 35 407 – 414
Fuggetta, 2003, Open source software – an evaluation, the journals of systems and
software – article in press
Getz, Litwin, Gilbert 1999, Access 2000 Developers Handbook
Halsnaes, 2001, Market potential for Kyoto Mechanisms – Estimation of Global Market
Potential for Co-operative greenhouse gas Emission Reduction Policies, Energy Policy
30 (2002) 13 – 32
187

CHAPTER 12
REFERENCES
Harris et al, 2000, Investment in Energy Efficiency: a Survey of Australian Firms,
Energy Policy 28 (2000) 867 – 876
Hassanin et al, 2001, Development of a Maintenance Management Model based on IAI
standards, Artificial Intelligence in Engineering 15 177 – 193
Henryson et al, 2000, Energy Efficiency in Buildings through Information – Swedish
Perspective, energy Policy 169 – 180
Holtsmark, 2002, Emission Trading under the Kyoto Protocol – Effects on Fossil Fuel
Markets under Alternative Regimes, Energy Policy 30 (2002) 207 – 218
Inoue et al, 2002, Automated graphic Image generation System for Effective
Representation of infectious disease surveillance data, Computer Methods and
Programs in Biomedicine 00 1 – 6
Karola et al, 2002, BSPro COM-Server – Interoperability between software tools using
Industrial Foundation Classes, Energy and Building 34 901 – 907
Kim, 2001, An XML based Modelling Language for the Open Interchange of Decision
Models, Decision Support Systems 439 – 441
Kokkonen et al, 2003, Interfacing Environmental Simulation Models and Databases
using XML, Environmental Modelling and Software 463 – 471
Krogh, von Hippel, 2003, Special Issue on open source software development, Research
Policy, article in press
Kunz, 1998, An object oriented approach to multibody systems analysis, Computers and
Structures 69 209 – 217
KYOTO STRATEGY, 1998, Climate Change - Towards a Post - Kyoto
Strategy. Commission of the European Communities
188

CHAPTER 12
REFERENCES
Lakhani, von Hippel, 2003, How open source software works: “free” user to user
assistance, Research Policy 32 923 – 943
Levine et al., 1996, Mitigation options for Carbon Dioxide emissions from buildings,
Energy Policy 24 937 – 949
Linat, 1992, Liant Software Corporation, C++/VIEWS Version 2 Users Guide, 1992
Liaskas et al, 2000, Decomposition of Industrial CO2 Emission: the Case of European
Union, Energy Economics 22 (2000) 383 – 394
Lowry, 2002, Modelling User Acceptance of Building Management Systems,
Automation and Construction 695 – 705
Ma et al, 2001, Methodology for the Implementation of a STEP standard: a Java
Prototype, Advances in Engineering Software 32 15 – 19
Marcotty, 1991, Software Implementation, Prentice Hall international UK ltd, 1991
Masterair, 2003b, Specifications for the Heat Exchanger Unit in the Mardyke Arena as
in Appendix B
Ndoye, Sorr, 2003, Influence of Domestic Hot Water Parameters on the energy
consumption of large buildings in Senegal, energy Conservation and management 44,
2635 – 2649
Osterwalder, 2003, An onthology for developing E-Business models, Ecole des HEC,
Switzerland.
Pratt, Anderson, 2001, A shape Modelling Applications Programming Interface for the
STEP standard, Computer Aided Design 33 531 – 543
189

CHAPTER 12
REFERENCES
Priambodo, Kumar, 2001, Energy Use and Carbon Dioxide Emission of Indonesian
small and Medium Scale Industries, Energy Conservation and Management 42 (2001)
1335 – 1348
Rolfsman, 2002, CO 2 Emission Consequences of Energy Measures in Buildings,
Buildings and Environment 37 (2002) 1421 – 1430
SAMSa, 2001, Teach Yourself MYSQL
SAMSb, 2001, PHP and MYSQL Web Development by Welling and Thompson
Shneiderman, B., 1992, Designing the User-Interface: Effective Strategies for Effective
Human-Computer Interaction, Second Edition, Addison-Wesley Publishing Company.
Sun, 2001, Energy Demand in the Fifteen European Union Countries by 2010 – A
Forecasting model based on the Decomposition approach, Energy 26 (2001) 549 – 560
Sun, Lockly, 1997, Data exchange system for an integrated building design system,
Automation in Construction 6, 1997, 147 – 155
TM 22, 2003, Energy Assessment and Reporting Methodology – Office Assessment
Method
Vieira, 2000, SQL Server 2000 Programming
Vital Signs, 2003, Whole Building Energy Performance, Berkeley Institute U.S.
Waltz, 1999, Computerized Building Energy Simulation Handbook, published by the
Fairmont press
Wang, Zheng, 2001, Dynamic and Real-time simulation of BMS and Air-conditioning
system as a “living” environment for learning/training, Automation and Construction 10
487 – 505
190

CHAPTER 12
REFERENCES
Web Style Guide, 2002, by Patrick J. Lynch, Sarah Horton
Welling and Thompson, 2001, PHP and MYSQL Web Development
Wiel et al, 1998, The role of building energy efficiency in managing atmospheric
carbon dioxide
WN 3000, 2003, Cylon building management software, Mardyke Arena
Yen et al, 2002, The Impact and Implementation of XML on Business to Business
Commerce, Computer Standards and Interfaces 347 – 362
Web References
Action Energy, 2003, Energy Efficiency Documents and guidelines for the UK
http://www.actionenergy.org.uk/downloads/GPCS390.pdf
BACnet, 2003, BACnet official website, http://www.bacnet.org/
BLAST, 2002, http://www.bso.uiuc.edu/BLAST/index.html
Cadinfo, 2003, Cad information and discussion,
http://www.cadinfo.net/editorial/aecxml.htm
CML, 2003, The Chemical Mark-up Language http://www.venus.co.uk/omf/cml/
CYLON CONTROLS Ltd, 2003, Developers of building HVAC control solutions,
http://www.lantronix.com/products/ds/uds10iap/index.html
DEFRA, 2003, Department for the Environment, Food and Rural Affairs (UK),
http://www.defra.gov.uk/environment/
191

CHAPTER 12
REFERENCES
Devarticles, 2003, Articles and Tutorials for computer programmer’s,
http://www.devarticles.com
DOE SIM, 2002, Arkansas Department of Economic Development,
http://www.aedc.state.ar.us/energy/Commercial_Industrial/DOE_simulation.htm
DOE, 2002, Energy Statistics from the US Government,
http://tonto.eia.doe.gov/ftproot/consumption/0555952.pdf
EABEC, 2002, East Anglian Business Environment Club, Factsheet of Benchmarking
and Energy Consumption,
http://www.uea.ac.uk/env/all/eabec/factsheet_benchmarking_energy_consumption.pdf
EIA, 1994, Energy information Administration, http://www.eia.doe.gov
Energyplus, 2002, http://gundog.lbl.gov/EP/ep_main.html
EnergyStar, 2003, http://www.energystar.gov/
EPA, 2003, EPA takes on role of National Allocation Authority in Carbon Trading
Scheme, Appendix C & http://www.epa.ie
EU, 2002, ACTIVITIES OF THE EU, http://europa.eu.int/
EU Directive, 2002, Directive 2002/91/Ecof the European Parliament and of the council
of 16 December 2002 on the Energy Performance of Buildings, Article 1 parts c and d.
Eweek, 2003, Articles relating to E-commerce,
http://www.eweek.com/article2/0,3959,3763,00.asp
Fuel Efficiency booklet 9, 2003, http://www.energy-efficiency.gov.uk
GbXML Schema, 2002, Official Schema for gbXML,
http://www.gbxml.org/schema.htm
192

CHAPTER 12
REFERENCES
gbXML, 2002, Official site for gXML protocol, http://www.gbxml.org
GDLib, 2003, GDLibrary Main Download site, http://www.boutell.com/gd
Green Paper, 2002, Green Paper on Sustainability, 2002, http://www.irlgov.ie
Hanna, 2003, Hanna Instruments Ltd., Developers of sensor technology,
http://www.hannainst.com
http://europa.eu.int/scadplus/leg/en/lvb/l27042.htm
Hoval, 2003, Specifications for Hoval Heat Recovery Units, Appendix A &
http://www.hoval.com/english/defaults/produkte/waerme/waerme_d.html
IAI, 2002, International Alliance for Interoperability, http://www.iai-na.org
IFC, 2002, Industry Foundation Classes, http://eetd.lbl.gov/btp/iai/copyright_ifc2x.html
IGES, 2002, http://www.nist.gov/iges/
Informit, 2003, Tutorials and Books relating to computer programming,
http://www.informit.com
Internet Indicators, 2003, http://www.internetindicators.com/factfigure.html
IPCC, 2001, Report on Climate Change, Climate Change 2001,
http://www.ipcc.ch/pub/un/syreng/spm.pdf
ISO, 2003, International Standards Organisation, http://www.iso.ch
LANTRONIX, 2003, Website for the UDS 10 Terminal server purchased for this
project, http://www.lantronix.com/products/ds/uds10iap/index.html
193

CHAPTER 12
REFERENCES
Macromedia, 2002, Macromedia Official Website,
http://www.macromedia.com/software/studio/
Mardyke, 2003, Mardyke Arena Official Website, http://www.mardykearena.com
MARDYKEARENA, 2003, http://www.mardykearena.com
Marland et al., 1994, Global, Regional, and National Fossil Fuel CO 2 Emissions,
http://cdiac.ornl.gov/trends/emis/meth_reg.htm
Masterair, 2003, Manufacturers of HVAC systems, http://www.masterair.ie
MathML, 2003, The Mathematical Mark-up Language, http://www.w3.org/TR/WDmath
Microsoft IIS, 2002, Internet Information Services,
http://www.microsoft.com/WindowsServer2003/iis/default.mspx
Microsoft, 2003, http://www.microsoft.com/sql/howtobuy/production.asp
MP, 2002, Minnesota Planning Authority, Return on Investment of High Performance
Buildings, http://www.mnplan.state.mn.us/pdf/2002/BuildingsReport.pdf
MYSQL MANUAL, 2003, http://www.mysql.com/doc/en/index.html
MySQL, 2002, Relational Database Management System Download site,
http://www.mysql.com
Netcraft, 2003, http://www.netcraft.com/survey/
Netscape SSL, Article on SSL, http://wp.netscape.com/security/techbriefs/ssl.html
Network Computing, 2003, http://www.nwc.com/1020/1020f1.html
194

CHAPTER 12
REFERENCES
OIKOS, 2002, Understanding the Impacts of Changing Energy Source in Buildings on
Energy Utility Efficiency and the Global Environment, http://www.oikosstiftung.unisg.ch/academy2002/Paper_An.pdf
OPENSOURCE, 2002, http://www.opensource.org
PHP MANUAL 2, 2003, http://www.php.net/manual/en/intro-whatcando.php
PHP MANUAL 3, 2003, http://ch.php.net/manual/en/function.fgetcsv.php
PHP MANUAL, 2003, Manual for PHP Developers,
http://www.php.net/manual/en/introduction.php
PHP, 2002, http://www.php.net/
PHP, 2003, http://www.php.net
PHPBUILDER, 2002, Forum for PHP Developers, http://www.phpbuilder.com
Rappa, 2000, Managing the digital enterprise – Business models on the Web, 2000,
http://ecommerce.ncsu.edu/business_models.html
RISO, 2002, Environmental Damages caused by Energy Production,
http://www.risoe.dk/sys/esy/emiss_e/extern_1.htm
SSL, 2003, Secure Sockets Layer, http://wp.netscape.com/security/techbriefs/ssl.html
STEP, 2002, http://www.steptools.com/library/standard/
Steptools Library, 2003.
http://www.steptools.com/library/standard/introduction_to_step.html
STEPTOOLS, 2002, STEP information and accompanying software,
http://wwwisteptools.com
195

CHAPTER 12
REFERENCES
TFI, 2002, TECHNOLOGY FORESIGHT IRELAND,
http://www.forfas.ie/icsti/statements/tforesight/energy/key.htm
UNITRON, 2003, http://www.cyloncontrols.com/news/Press%20Releases/BSNews092000.htm
W3SCHOOLS, 2002, http://www.w3schools.com/dtd/dtd_intro.asp
W3SCHOOLS, 2003b, http://www.w3schools.com/xsl/xsl_languages.asp
Web Server, 2003, http://www.openloop.com/internet_training/WebServer
XML, 2002, The Extensible Markup language official site, http://www.xml.com
XSL, 2003, The Extensible Stylesheet language – A Web Tutorial,
http://www.w3schools.com/xsl/xsl_intro.asp
ZEND, 2003, Dynamic Image Generation with PHP,
http://www.zend.com/zend/tut/dynamic.php
196

CHAPTER 13
APPENDICES
13 APPENDICES
A - HOVAL HEAT EXCHANGER CATALOGUE
197

CHAPTER 13
APPENDICES
198

CHAPTER 13
APPENDICES
199

CHAPTER 13
APPENDICES
200

CHAPTER 13
APPENDICES
B – EU DIRECTIVE ON THE ENERGY PERFORMANCE OF BUILDINGS
201

CHAPTER 13
APPENDICES
202

CHAPTER 13
APPENDICES
203

CHAPTER 13
APPENDICES
204

CHAPTER 13
APPENDICES
205

CHAPTER 13
APPENDICES
206

CHAPTER 13
APPENDICES
207

CHAPTER 13
APPENDICES
C – EPA MISSION STATEMENT REGARDING EMISSIONS TRADING
SCHEME
EPA takes on role of National Allocation Authority
in Carbon Trading Scheme
4 th July 2003
The Director General of the Environmental Protection Agency, Dr Mary Kelly, today
welcomed the announcement by Martin Cullen, TD, Minister for the Environment,
Heritage and Local Government, that the Government has given the EPA responsibility
for implementing the Emissions Trading Directive in Ireland. The Directive establishes
an allowance-trading scheme for emissions to promote reductions of greenhouse gases,
in particular carbon dioxide.
Dr Kelly said that the EPA was aware that there would be potentially significant
economic consequences for companies affected by the Directive. “Allocation of
emission allowances to those companies that are involved will be a difficult job,” said
Dr Kelly, “and will present complex and difficult challenges for the Agency”.
The EPA will immediately set up a National Allocation Unit for Emissions Trading as
required by the Directive. Its first task will be to produce a National Allocation Plan
and a National Allocation Advisory Group will be established by Government to assist
in this task. The EPA will work with the Advisory Group to deliver an equitable plan
for distributing the allowances. The timetable fixed by the Directive is tight with the
allocation plan to be submitted to the European Commission by March 31 st , 2004.
“It is highly unlikely that companies will receive the amount of allowances they will
need to cover current levels of emissions,” said Dr Kelly, “as Ireland has already
exceeded its emissions limits agreed under the Kyoto Protocol. Therefore companies
will have to buy emissions on the international market to cover the deficit or reduce
208

CHAPTER 13
APPENDICES
their emissions to the allowed amounts. Allocation of allowances in this climate will
not be easy.”
The EPA will instigate a greenhouse gas emissions permit scheme once the allocation
plan is finalised. A pilot phase will run from 1 st January 2005 for three years.
Operators of emissions covered by the Directive must hold a permit to emit greenhouse
gases. The permit will require installations to be capable of monitoring their emissions
and to submit a yearly report to the EPA. Each installation will surrender their
emissions allowance at year end for each tonne of CO2 emitted. Although this is a pilot
phase, real financial penalties will attach to companies who do not hold enough permits
through allocation or trade. The EPA will set up a public registry to track the transfer of
allowances.
Industries that will be required to participate in the scheme include combustion, cement,
lime, glass and ceramics plants, oil refineries and paper mills, many of which already
hold IPC licences from the EPA.
209

CHAPTER 13
APPENDICES
D – CYLON Ltd. UNITRON CONTROL SYSTEM MANUAL
210