ENERSCOPE: REAL-TIME ENERGY MANAGEMENT
AND DEMAND RESPONSE SYSTEM
A THESIS SUBMITTED
FOR THE DEGREE OF BACHELOR OF ENGINEERING
ENGINEERING SCIENCE PROGRAMME
NATIONAL UNIVERSITY OF SINGAPORE
Typeset with LATEX
c Haﬁiz Osman, June 2010. All rights reserved.
An energy management system uses a combination of advanced metering hardware and software to
monitor a facility’s electricity usage, identify inefﬁciencies and pinpoint potential threats to reliability.
This type of system can provide facility managers with the information to make informed decisions, from
both a functional perspective and a ﬁnancial one. Regardless of the type of facility monitored, the tools
used to effectively manage and control electrical energy usage on a full-time basis usually consist of three
main components: meters, software and communications.
The EnerScope energy management system is a demonstration project to showcase the integration
of various hardware and communication interfaces through a common platform. Most manufacturer of
metering hardware and data acquisition equipment provide proprietary software that work only with their
respective devices. The EnerScope system aims to bring compatible devices to work under one platform
and simplify hardware integration through clever implementation of interconnection technologies.
To demonstrate the EnerScope system’s support for various communication methods, the system will
acquire data both wired and wirelessly. Wired technologies include serial communication for localized
data acquisition, and LAN for remote metering. DAQ equipments used to demonstrate serial, Wiﬁ and
LAN communication are ADAM-4017+, ADAM-6017 and INTEGRA-1630 respectively. These equip-
ment’s support for Modbus protocol enable data acquisition using Modbus library and drivers in Lab-
VIEW, a programming environment chosen to write the EnerScope software. The integration of MICAz
motes into the system will demonstrate EnerScope’s support for IEEE 802.15.4 and WSN technology.
First of all, I would like to thank Mr. Inam Nutkani, for initiating this project and inviting my partic-
ipation, through which I have gained valuable knowledge and skills that are too many to mention. As a
supervisor, Inam taught me what i do not know, or forgot about power systems; and guiding me again with
constructive criticisms during the process of developing the software.
This dissertation could not have been written without Assistant Professor Karl Erik Birgersson, who
not only served as my supervisor but also encouraged and challenged me throughout my academic pro-
gram. I thank him for his reception to ideas, and entrusting me with responsibility to work independently
under remote supervision.
I express my gratitude to Dr. Daniel Yap and Professor Ho Hiang Kwee for taking me in as an intern at
the Experimental Power Grid Centre. Without this internship, I would not have known about Microgrids
and Smart Grids.
Last but not least, I would like to thank all the researchers and staff at EPGC for their help and support
during the course of the project; and especially to Mr. Alex Chong, Dr. Zhong Wen, Ms. Sharon Savitri,
and Ms. Jenny Tan for making my time at EPGC a pleasant one.
LIST OF FIGURES
2.1 Hardware components and communication interfaces of the EnerScope system. . . . . . . 4
2.2 Inter-connectivity and modularity of devices in the EnerScope system. . . . . . . . . . . . 7
2.3 Sensor position in DB-L1, DB-P1, DB-MISC and DB-CNC . . . . . . . . . . . . . . . . 8
2.4 Sensor position in DB-SH . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8
2.5 Topology of source-end devices for DAQ-assisted metering. . . . . . . . . . . . . . . . . 10
2.6 Topology of source-end devices for metering using intelligent meter. . . . . . . . . . . . . 10
2.7 (a) Current transformer and (b) current transducer (CR Magnetics). . . . . . . . . . . . . 13
2.8 Schematic representation of WSN deployment in EnerScope. . . . . . . . . . . . . . . . . 15
2.9 Wireless Sensor Network topologies . . . . . . . . . . . . . . . . . . . . . . . . . . . 16
2.10 Position of enclosures relative to DBs. . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16
2.11 Relative locations of DBs and data acquisition equipments deployed . . . . . . . . . . . . 17
3.1 Relative topologies of RS-232, RS-422 and RS-485 communication network. . . . . . . . 20
3.2 Daisy-chaining, Stub, and Star conﬁgurations for RS-485. . . . . . . . . . . . . . . . . . 22
3.3 Cabling between serial DAQ modules in an RS-485 network and NI 9871 serial commu-
nication module on a cRIO-9074. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 23
3.4 Wireless data acquisition using ADAM-6017, router and access point. . . . . . . . . . . . 24
4.1 Integra-1630 register decode algorithm. . . . . . . . . . . . . . . . . . . . . . . . . . . . 32
4.2 Decode VI for Integra-1630 registers. . . . . . . . . . . . . . . . . . . . . . . . . . . . . 33
4.3 Signal conversions from analog source to digital output. . . . . . . . . . . . . . . . . . . . 34
4.4 VI for voltage to current conversion from ADAM input. . . . . . . . . . . . . . . . . . . . 35
4.5 VI that reads and interprets ADAM-4017 registers in proper units. . . . . . . . . . . . . . 35
4.6 Creating shared variables from manipulation of shared variables. . . . . . . . . . . . . . 38
4.7 Polling and display of shared variables. . . . . . . . . . . . . . . . . . . . . . . . . . . . 38
4.8 Inserting data row-by-row into an Access database. . . . . . . . . . . . . . . . . . . . . . 39
4.9 Front panel and block diagram showing the query of an Access database. . . . . . . . . . . 40
5.1 Relevant hardware and software for headless portion of real-time system. . . . . . . . . . 42
5.2 Application and device interfacing through device driver. . . . . . . . . . . . . . . . . . . 44
5.3 Application and device interfacing through Modbus. . . . . . . . . . . . . . . . . . . . . . 45
5.4 Rows and columns in a database table. . . . . . . . . . . . . . . . . . . . . . . . . . . . . 47
5.5 Connection diagram for total load metering using Integra-1630. . . . . . . . . . . . . . . . 47
5.6 Connection diagram for individual circuit metering using ADAM module. . . . . . . . . . 49
6.1 Schematic representation of data ﬂow in current version of EnerScope. . . . . . . . . . . . 53
6.2 Schematic representation of data ﬂow in future version of EnerScope. . . . . . . . . . . . 53
6.3 (a) LabVIEW Project window and (b) Source Menu window. . . . . . . . . . . . . . . . . 54
6.4 Screenshot of Main window. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 55
6.5 Screenshot of Trend Monitor window. . . . . . . . . . . . . . . . . . . . . . . . . . . . . 56
6.6 Screenshot of Datalogger window. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 57
6.7 Screenshot of Source Data window. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 58
6.8 Screenshot of Line Diagram window. . . . . . . . . . . . . . . . . . . . . . . . . . . . . 58
7.1 Duplication of data from source to destination. . . . . . . . . . . . . . . . . . . . . . . . . 60
7.2 Block diagram of Trend Monitor showing event structure. . . . . . . . . . . . . . . . . . . 60
7.3 Main window graphing function block diagram. . . . . . . . . . . . . . . . . . . . . . . . 61
A.1 Line diagram for DB-L1 and DB-P1; unlabeled circuits are not relevant. . . . . . . . . . . 64
A.2 Line diagram for DB-MISC and DB-CNC; unlabeled circuits are not relevant. . . . . . . . 65
B.1 Equipment layout in enclosure E-1. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 66
B.2 Equipment layout in enclosure E-2. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 66
LIST OF ABBREVIATIONS
AC Alternating current
BCA Building and Construction Authority
C&C Command and Control
DAQ Data acquisition
DB Distribution box
DBMS Data Base Management System
DC Direct current
DTE Data Terminal Equipment
EPGC Experimental Power Grid Centre
FPGA Field Programmable Gate Array
GtC Giga-tons CO2
HMI Human Machine interface
HVAC Heating, Ventilating and Air-conditioning
IPCC Intergovernmental Panel on Climate Change
NI National Instruments
PSU Power Supply Unit
SQL Structured Query Language
UI User interface
USB Universal serial bus
WSN Wireless Sensor Networks
ZEG Zero emission growth
1.1 Motivation for energy management
1.1.1 Reducing carbon footprint
Over the past century, technology has advanced so rapidly that it is almost impossible to disassociate man
from man-made energy consuming machines. Human development can be associated, in large part, to
these machines that even as prices for energy soar, the global demand for it is not likely to plateau. IPCC
reported that electricity generation from fuel combustion alone contributed more than six billion tons of
CO2 (GtC) emission in year 2000 . A business-as-usual attitude is predicted to bring carbon levels in
the atmosphere to 14 GtC by 2055, implicating serious consequences of global warming. Being a key
greenhouse gas, CO2 is warming our planet at such an alarming rate that world leaders have manifested
their cooperation to stabilize atmospheric CO2 concentration. In view of this, IPCC has recommended
that atmospheric CO2 concentration be limited to 500 ppm to avert the onslaught of climate change. This
require a reduction of 80% in carbon emission over the next 50 years to limit temperature increase of earth
within a 2 ◦
Individuals can play a part to reduce carbon footprint by minimizing phantom energy consumption as
much as possible; this can be as simple as switching off an appliance when not in use as opposed to stand-
by mode. However, individuals usually lack tangible knowledge with regards to their energy consumption
to be able to act proactively. This is where the energy management system come in. An effective energy
management system must be user-friendly, informative and must incorporate very intuitive UI that allows
user interaction with the system. This system must be competitively priced or subsidized, such that it can
eventually be part of every household. A more advanced system can be designed for industrial use. With
a nation-wide drive on energy efﬁciency and worldwide effort to reduce carbon emissions, there will be
demand for energy management services.
1.1.2 Energy management at macro level
At a macro-level, the energy management system will require a large hardware infrastructure with a so-
phisticated base station that is capable of managing enormous amount of data from numerous sources. The
following paragraphs describes two types of macro-level system that heavily relies on energy management
Intelligent power distribution
With increasing energy consumption in the industries, schools, and homes, current power generation and
distribution systems are becoming increasingly overloaded, exposing numerous vulnerabilities. United
States and Canada experienced major power outages, that resulted in billions of dollars in damages due to
this vulnerabiliy. Investigations later revealed that grid imbalances due to overloading is a major cause of
the outage .
Current monitoring system only possesses the capability to match generation with demand but not
vice-versa. This means that in the event generation capacity cannot match demand, the latter is not able
to dynamically adjust itself to match a lower generating capacity. The lack of a two-way communication
between the supply and demand compromises the reliability of the power supply chain. Using advanced
sensors and IT technology, the power grid can be made smarter, thereby improving its reliability.
Rising peak demand and fundamental imbalance looms between supply and demand straining the
electricity system and threatening the reliability of the power grid. Demand response integration with an
energy management system can help save infrastructure cost by reducing peak demand. With appropriate
pricing signals (e.g. Time of Use), automated demand response can provide additional reliability to the
utility grid; or monetary incentives to end use customers by helping to motivate changes in electric use by
such customers. This is achieved by varying the energy demand to changes in the price of electricity over
time, or when grid reliability is jeopardized.
Distributed Energy Resources
In microgrids, distributed energy resources (DERs) such as solar photovoltaics, wind turbine, diesel gen-
erator and micro-turbine technologies form the power generating components in a miniature power dis-
tribution system. In conventional grids, several centralized power plants supply electricity to large areas
whereas a microgrid supplies only to a small cluster of consumers. The advantage of deploying many mi-
crogrids in place of one large power grid is improved efﬁciency and better energy security. Bringing DERs
together into a microgrid system require an intelligent system that controls unpredictable energy sources to
produce reliable supply of electricity. This is only possible with an advanced energy management system
that utilizes advanced sensors and communication technologies.
This project aims to develop an energy management system that will,
1. monitor the energy consumption of selected sites (local and remote loads) in real-time;
2. implement demand response on selected loads based on real-time data;
3. study the impact of the implemented demand response system towards energy and cost savings.
Energy monitoring system
Implementation of real-time energy monitoring involves the integration of several hardware such as data
acquisition modules, sensors, wireless devices in which each may have different protocols and interfaces.
The base platform (hardware and software) will be capable of handling different interfaces and protocols
for greater ﬂexibility and modularity, enabling this system to expand, if needed, to include more DERs and
loads. The software will be developed using LabVIEW Development system due to its extensive support
and market presence in the area of instrumentation equipments. Real-time raw data from I/O devices will
be channeled to LabVIEW, wired and wirelessly, and processed into meaningful parameters that will be
communicated to the user in the form of charts and graphs through an intuitive UI.
Demand response management
The energy monitoring system presented above will also have the capability for automated demand re-
sponse, with the following implementation:
1. Automation of Standby HVAC units in the EPGC Command and Control (C&C) Facility;
2. Development of a demand response device,
With appropriate pricing signals (e.g. Time of Use), automated demand response can provide additional
reliability to the utility grid, or monetary incentives to end use customers by helping to motivate changes
in electric use by such customers. This is achieved by varying the energy demand to changes in the price
of electricity over time, or when grid reliability is jeopardized.
ARCHITECTURE AND DEVICES
2.1 An overview of EnerScope system architecture
Figure 2.1 illustrates the system’s hardware components and communication interface and how each
equipment is connected or related to one another. In this ﬁgure, each component type is enclosed in a
box, and arranged such that boxes that share an edge are physically connected to each other. The arrows
represent the different communication interfaces supported by the EnerScope system. Each component
will be described in greater detail in subsequent sections.
Sensors and Actuators
Sensors sense voltage, current, temperature, humidity and luminance.
Actuators perform control activities like switching.
Measure voltage and current.
Computes electricity parameters.
Measure voltage and current,
temperature, humidity and luminance.
Receive field data and transmit
control instructions wirelessly.
Primarily functions as a security enhancement.
Allows modular system expansion.
Programmed to perform energy monitoring and
management, automation of connected equipments
and appliances, and datalogging activities.
Figure 2.1: Hardware components and communication interfaces of the EnerScope system.
2.1.1 Hardware overview
EnerScope consist of several hardware components that are integrated to form a complete energy manage-
ment system. This system is designed to be highly modular, enabling electrical systems to be added with
minimal disruption to ongoing operations. This feature is highly advantageous if the energy management
software were to serve facilities, group of buildings, or even a micro-grid system that serve an entire dis-
trict. Support for Modbus devices, and mutiple communication protocols and interfaces further expand
EnerScope’s pool of compatible OTS products.
Sensors and actuators
For monitoring energy consumption of an electrical system, only sensors that sense current and voltage
are needed. There are many kinds of voltage and current sensors available in the market and they must
be carefully chosen to match both the metering equipment and the load-end. Temperature and humidity
sensors are used to monitor the ambient conditions where critical equipments are housed, such as in data
centre and server rooms. HVAC equipments keep servers cool to prevent excessive heating which can
result in costly server downtime. Monitoring temperature and humidity of these critical devices facilitate
damage control measures in the event of equipment failure.
An energy management system typically consist of a network of intelligent meters that have the capability
to measure and record data at speciﬁed intervals, and communicate the data to a remote, centrally lo-
cated server running the energy management software. The type and location of each metering equipment
depends on the targeted electrical system. For example, utility-grade meter can be installed at the main
substation to verify the quantity and quality of power delivered to the site; whereas simpler sub-metering
devices can be installed at key points around facilities or buildings to monitor individual buildings or
processes. The distributed meters typically communicate with the central software across the facility’s ex-
isting ethernet-based LAN. Communication over the internet is also possible for geographically dispersed
DAQ modules can only measure basic parameters like voltage and current from which parameters like
power and energy are derived. Using DAQ modules for the purpose of metering, will therefore require
more development time than when an energy meter is used. This is because an energy meter is already
programmed to perform all the necessary calculations within its chassis. Nevertheless, DAQ devices are
generally cheaper than most energy meters, and is best deployed when there is a need to measure electricity
from multiple circuits — it certainly is unwise to use energy meters for individual household appliance,
Integrated real-time controller
The NI real-time controller is an integrated system with computing power similar to a PC but has to be pro-
grammed to perform very speciﬁc tasks. This system combines a real-time processor and a reconﬁgurable
FPGA within the same chassis for embedded machine control and monitoring applications. Programming
the controller is made simple with LabVIEW Real-Time module and FPGA module. Real-time software
is developed using LabVIEW Development system on a workstation, and then ported over to the headless
controller . In effect, the real-time controller performs the bulk of the system processes and free up PC
processes for tasks requiring the Windows environment.
Base router and wireless nodes
The base router and wireless nodes enable wireless communication between remote ﬁeld devices and the
base station. Wireless nodes can be wireless DAQ, wireless digital output module or wireless access points
that connect multiple ﬁeld devices wirelessly to the base station. Current wireless technologies enable
clean and speedy installation and is desired when wiring involve costly installations. A base router’s
capability to support many wireless nodes facilitates system expansion. Many wireless technologies are
available in the market but not one is ’perfect’ for all situations. The choice of wireless technology to
implement depends on factors such as distance, cost, security and other constraints. However, this project
focuses on Wi-Fi and ZigBee.
The EnerScope system is essentially made up of a network of ﬁeld devices connected to the base station
through a variety of communication interface. The LAN switch provide ﬁrst-line defense against exter-
nal attacks by keeping out unauthorized users from entering the network. Security services provided by
LAN switches include Network Admission Control; Man-in-the-Middle attack mitigation; and integrated
security service modules that provide virtual private networks, ﬁrewalls, intrusion prevention, intrusion
detection, and many more. All system components connect to the switch as shown in Figure 2.1.
The workstation serve as a data consumer, continuously polling data from the real-time controller which
functions as a data producer. The ability to display data through various visualization tools, and the
availability of physical controls such as the mouse and keyboard facilitate user interaction with the system.
For example, the user may give control instructions such as increasing thermostat level; or set the time for
equipments to begin operation as part of demand-side management strategy. Because the bulk of processes
take place in the real-time controller, processing requirements of the workstation is low. The PC also
provide storage media for EnerScope’s database. In summary, the workstation provide the link between
machine environment of the real-time controller and the familiar full-feature Windows environment.
2.1.2 System modularity
The EnerScope system is highly modular and is designed to be implemented in many settings. Figure
2.2 illustrates the actual conﬁguration of the EnerScope system in this demonstration project. Real-life
implementation of the EnerScope system can vary accordingly to ﬁt the requirements of speciﬁc applica-
tion scenarios. In Figure 2.2, dotted boxes indicate the expansion points of the system. The NI real-time
controller supports up to 8 slots for various NI modules. For instance, if we were insert into one of the the
slots a 4-port RS-485 communication module, that single slot can now support up to 128 (4 x 32) serial
devices. Using all 8 slots for serial communication means a maximum of 1024 (8 x 128) serial devices
can be supported. Expanding the number of wiﬁ-enabled ethernet DAQ is also possible by linking several
access points to the wiﬁ router. Theoretically, a wiﬁ router can support up to 254 wireless/wired machines.
Unfortunately, supporting too many devices through the wiﬁ router will give rise to bandwidth issues. The
network switch provide the last expansion point for the energy managment system. Depending on the
number of ports per switch, and the number of switches used, there is virtually no limit to the size of the
overall system. As can be seen in Figure 2.2, the PC, controller, router and variable number of ethernet
meters are connected to switch. The system can be expanded further by adding more routers, controllers
and ethernet meters to the switch.
Serial DAQ Intelligent Meter Ethernet DAQ
Figure 2.2: Inter-connectivity and modularity of devices in the EnerScope system.
2.2 Load speciﬁcation
The choice of meter, DAQ module and sensor for metering largely depends on the targeted electrical
system; proximity of that system to the base station; and cost considerations. Understanding the electrical
system of interest by gathering all available data regarding that system is necessary to determine the kind
of equipments to procure. In this demonstration project, three locations are targeted — EPGC Ofﬁce,
Command & Control Facility, and StarHOME.
2.2.1 Experimental Power Grid Centre
The Experimental Power Grid Centre (EPGC) is a research facility dedicated to the development of sus-
tainable energy technologies related to intelligent grids, microgrids and distributed energy resources.
EPGC consist of a remote Command and Control (C&C) Centre, located at Fusionopolis; and a Microgrid
and Distributed Energy Test Facility, located at Jurong Island. EPGC’s facility at Fusionopolis consist of
the C&C Centre, where EnerScope’s Base Station is housed; and an administrative area, which we will
refer to as EPGC Ofﬁce.
Power for EPGC Ofﬁce come from three distribution boxes (DBs), DB-P1, DB-L1 and DB-MISC,
which are located around 50 meters from Base Station (names of DBs do not reﬂect their actual names for
security reasons). DB-P1, DB-L1 and DB-MISC contain circuit breakers for EPGC Ofﬁce loads and non-
EPGC loads for that level. Hence, circuits that lead to the ofﬁce are identiﬁed and individually metered
by afﬁxing a current sensor to each. Circuit breakers for loads in C&C Facility is housed in DB-CNC, in
close proximity to the Base Station. All circuits in DB-CNC are exclusive to C&C Facility.
In Figure 2.3 current sensors (red rings) are ﬁxed to the subsidiary circuits that lead to EPGC Ofﬁce
and C&C Centre. Voltage sensors (blue dots) are ﬁxed to the 3-phase feed — 1R, 1Y and 1B. Subsidiary
circuits in DB-L1 are rated 10 A while those in DB-P1 and DB-CNC are rated 20 A (refer to Appendix
A). For convenience we shall assume a higher rating of 20 A for subsidiary circuits in all three DBs.
1R 1Y 1B
Figure 2.3: Sensor position in DB-L1, DB-P1, DB-MISC and DB-CNC
1R 1Y 1B
Figure 2.4: Sensor position in DB-SH
StarHOME is a fully furnished and functional model home with extensive infrastructure to showcase
innovative and integrated smart home technologies . Because StarHOME is located several levels above
EPGC, serial or wiﬁ communication with the Base Station is not feasible. Using serial metering device
for StarHOME will require very long cables passing through several levels, resulting in costly installation.
Wi-Fi data transfer is also not suitable because of its limited indoor range. When LAN infrastructure is
available, data transfer through LAN offers the best solution in such situation. Fortunately, Fusionopolis
is built with an extensive LAN infrastructure.
Circuit breakers for all StarHOME loads are housed in DB-SH. Since the 3-phase power feed in DB-
SH is dedicated for StarHOME’s power needs, we can simply meter StarHOME from this feed. In contrast
to the number of sensors needed for EPGC Ofﬁce and C&C Facility, only three current sensors and one
3-phase voltage sensors are needed for metering. Figure 2.4 shows that each phase of the feed line, 1R, 1Y
and 1B, are ﬁxed with one current sensor (red ring) and one voltage sensor (blue dot) each. Feed current
is rated 63 A per phase.
Table 2.1: DB-L1, DB-P1, DB-MISC, DB-CNC and DB-SH
Description DB-L1, DB-P1,
Current sensing point subsidiary feed, subsidiary feed
Voltage sensing point feed feed feed
Rated current 10, 20 A 63 A 63 A
Rated voltage 230 V 230 V 230 V
Number of CTs 18 12 3
Number of VTs 1 (3-ph) 1 (3-ph) 0
Distance from Base Station 50 m 5 m 5 ﬂoors
Preferred communication Wi-Fi Serial LAN
2.3 Devices for electricity measurement
Devices that do not constitute the Base Station are considered ’source-end’ devices. This include all de-
vices that play a role in data acquisition, but excludes communication equipments. This section discusses
speciﬁcations and the role of such devices.
2.3.1 DAQ-assisted metering
A data acquisition (DAQ) device is used to measure real-world parameters by converting continuous phys-
ical signals, such as voltage and current, into discrete digital values that can be understood by computers
for further manipulation. The choice of DAQ device must take into consideration the nature of its appli-
cation and the environment in which it will be implemented. Figure 2.5a and 2.5b illustrate the devices
deployed for current and voltage measurements using ADAM-4017+ and ADAM-6017 modules.
2. 1.5 kΩ Resistor
(a) Current measurement
(b) Voltage measurement
Figure 2.5: Topology of source-end devices for DAQ-assisted metering.
2.3.2 Utilizing intelligent meters
Integra-1630 meter offers a complete electrical measurement of more than 60 parameters. These pa-
rameters are displayed in a three-tier LED display panel but can also be viewed on a computer when
connected by an ethernet cable. The values of these parameters are stored in Modbus registers that can
be programatically retrieved using any programming language that provide drivers, or classes for Modbus
communication. With ethernet communication capability, this meter can be deployed to monitor energy
usage and other electrical parameters of remote location through LAN, Wi-Fi or even the internet. Because
of its remote metering capability, the Integra-1630 is deployed at StarHOME.
1. TA 30R
Figure 2.6: Topology of source-end devices for metering using intelligent meter.
2.4 Device speciﬁcation
2.4.1 ADAM modules
Selecting a suitable DAQ module is a challenging process due to varied nature of such devices. After
studying several models from different manufacturers, we decided on Advantech because of its comfort-
able pricing point and excellent technical support. Table 2.2 lists some of the speciﬁcations of our ADAM
Table 2.2: Selected speciﬁcations of ADAM-6017 and ADAM-4017+ remote I/O modules .
Speciﬁcations ADAM-6017 ADAM-4017+
Analog input channels 8 differential 8 differential
±150 mV, ±500 mV, ±1 V, ± 5 V,
±10 V, 0-20 mA, 4-20 mA
Resolution 16-bit 16-bit
Sampling rate 10 samples/s 10 samples/s
Accuracy ±0.1% voltage mode, ±0.2% current mode
Digital output channels 2 None
Communication LAN RS-485
Connector RJ-45 Terminal block
Protocol Modbus/TCP Modbus /RTU
Resolution refers to smallest value increment that can be detected by a data acquisition system and is
usually expressed in bits. For example, a data acquisition system that has a resolution of n-bit, can detect
a physical analog signal up to an accuracy equal to (measurement span)/2n
. Using speciﬁcations from
Table 2.2 and assuming an input range of ±5 V , we get a resolution of (5 − (−5))/216
= 0.000152 V.
Sample rate is the speed at which a data acquisition system collects data and is normally expressed in
samples per second. For multi-channel DAQ devices, the sample rate is typically the speed of the analog-
to-digital (A/D) converter. Individual channel sample rate can be obtained by dividing the speed of the
A/D by the number of channels being sampled. Nyquist theorem states that the sample rate must be at least
twice the highest frequency component contained within the input signal. To sample a 50 Hz sine wave,
the sample rate should be at least 100 Hz. ADAM modules can only sampling at 1.25 Hz per channel if all
eight channels are used. Therefore, an AC signal must ﬁrst be converted to its DC equivalent ﬁrst. This
can be implmented by interfacing ADAM with an RMS output device.
Integra-1630 conﬁgured for 3-phase, 4-wire metering require only three external CTs. No VTs are re-
quired since the meter is designed with an integrated tranducer. Therefore, voltage signals can be wired
directly to appropriate terminals for voltage measurements. Maximum current input to the device’s cur-
rent input terminals is 5 A. Hence, only CTs that has secondary output rating of 5 A can be used with
Integra-1630. Refer to Table 2.3 for selected speciﬁcations of Integra-1630.
Table 2.3: Selected INTEGRA-1630 speciﬁcations .
Programmable VT and CT ratio Accuracy up to 0.2%
Direct connection up to 480 VAC True RMS measurement
5 A CT input Nominal voltage burden: < 0.2 VA
16-bit resolution RJ-45 communication port
Sampling at 10 samples/s Supports Modbus TCP, TCP/IP
2.4.3 Voltage sensor
Voltage transducer (VT) takes in analog voltage signal from the feed line and outputs a signal according to
the design of the transducer. Theses VTs also serve as RMS converters for our ADAM modules whereby
a 50 Hz input voltage signal is converted to equivalent RMS (DC) signal between 0-5 V. The VT in the
ﬁrst row of Table 2.4 converts high frequency current output from a CT (CR3110) to a DC voltage signal.
The other VT in the same table converts high frequency voltage signals from the mains circuit to DC
voltage signals. Voltage at the input of the transducer can be calculated by multiplying the measured
output voltage by a scaling factor, where
Scaling factor =
Max. rated input
Max. rated output
Input votage = Scaling factor × Output voltage (2.2)
2.4.4 Current sensor
There are two types of current sensors — the ﬁrst is a transformer, the other a transducer. The complexity
of a current transducer’s internal circuitry is similar to that of a voltage transducer. Such circuitry give
these devices the ability to perform relatively advanced computations such RMS calculations. A trans-
ducer can be considered a power electronics device, in the same category as power supply adapters and
Table 2.4: CE-VJ03-34MS2 and CE-VJ41-34MSK speciﬁcations .
Case Model Input Output
CE-VJ03-34MS2 0-10 VAC 0-5 VDC
CE-VJ41-34MSK 0-250 VAC 0-5 VDC
In contrast, a current transformer is a much simpler device. It typically consists of a transformer core,
a primary winding, and a secondary winding encapsulated in a non-conducting casing. Current transform-
ers, or CTs, are therefore very inexpensive and compact device. Thus, CTs are preferred when deployment
in highly constrained space of DBs are required. In reference to Table 2.1, ﬁtting 19 CR4210S transducers
will certainly be much more problematic than ﬁtting the same number of CR3110 transformers.
(a) CR3110 (b) CR4210s
Figure 2.7: (a) Current transformer and (b) current transducer (CR Magnetics).
In metering application, the primary winding is the circuit to be measured from, while the secondary
winding forms part of the transformer body. Current in the primary winding, Ip can be calculated from
Ip = Is ×
where Ns — the secondary winding turns ratio — can be found from product speciﬁcation sheet; Np = 1
if primary winding is not looped, and Is is current output of the CT.
CR3110 gives a tracking output current that is equal to the source current scaled down by a factor of
3100 . Tracking output means that the output waveform follows the waveform at the input. In other
words, when used to measure current of power circuits, CR3110 outputs a highly attenuated 50 Hz signal.
Table 2.5: Comparison of CR3110-3000 and CR4210S (www.crmagnetics.com).
Description CR3110-3000 CR4210S
Input signal AC AC
Input range 0-75 A 0-100 A
Output signal AC DC
Output range 0-10 V (resistor) 0-5 V
Mounting Free hanging DIN-rail
Dimension (L × W × H mm) 27 × 27 × 40 83 × 36 × 100
Price (approximate) SG$19 SG$180
Because ADAM-4017+ and ADAM-6017 sample at a rate much lower than the frequency at the output of
the CT, connecting CR3110 directly to these DAQ modules will result in a highly inaccurate measurement
due to aliasing. In our application, we pair each CR3110 CT with CE-VJ03 as illustrated in Figure 2.5a.
2.5 WSNs for environmental monitoring
Two reason for incorporating WSNs in the EnerScope system: To demonstrate the integration of wireless
sensor network technology; and to enable programmatic control of stand-by HVAC units.
The C&C Facility houses very sensitive equipments that must be kept in a low temperature and hu-
midity environment. The facility is kept cool by the central HVAC system during ofﬁce hours, and ﬁve
stand-by A/C units after the central system shuts down. Activation and shutting down of the A/C units
are controlled by in-built timers only. In the event of central HVAC downtime, the A/C units must be
manually activated to maintain temperature and humidity of the facility at appropriate levels, to prevent
damage to equipments.
With environmental sensing, the EnerScope system has the added capability of monitoring temperature
and humidity of the facility. The system can then be programmed to activate the stand-by A/C units when
temperature and humidity rises a certain threshold level.
2.5.1 MICAz mote
A mote is a sensor node in a WSN that is capable of performing some processing, gathering sensory
information and communicating with other connected nodes in the network . Five MICAz motes were
deployed for this project. A MICAz mote consist of a processor and radio platform, and several varieties
of sensor boards. The sensor board interfaces with the processor and radio platform through a 51-pin
expansion connector. Depending on the application of the mote, different sensor boards may be selected.
Each MICAz mote has routing capability and communicates through IEEE 802.15.4 radio standard. .
In this project, we used an MTS400 environmental sensor board for measuring temperature, humidity and
Figure 2.8: Schematic representation of WSN deployment in EnerScope.
2.5.2 MIB520 Gateway
The MIB520 Gateway provides connectivity with the MICAz motes for communication and in-system
programming . The gateway behave as a router capable of managing communications with the motes
and the PC. Using the MoteView software, MICAz family of motes can be programmed remotely through
the gateway. Gateway connects directly to the workstation as shown in Figure 2.8.
2.5.3 Wireless Sensor Network
A wireless sensor network (WSN) generally consists of a ’gateway’ that communicates with a number of
wireless sensors via a radio link. A wireless sensor node collects, compresses, and transmits data to the
gateway directly, or through other nodes. The transmitted data is then presented to the system from the
gateway . Figure 2.9 illustrates several WSN topologies.
Star network topology
In this topology, each node to communicates directly with the gateway and communication between nodes
are not permitted. This keeps power consumption of remote nodes to the minimum, but is only suitable
when the base station is within radio transmission range of all the nodes.
Mesh network topology
Mesh networking allows for continuos connections and reconﬁgurations around broken nodes that are
blocked, by hopping from node to node until the destination is reached. Nodes that are too far to commu-
nicate with the gateway directly can still get their messages across by hopping.
Star-Mesh hybrid network topology
This topology involve several base station and numerous nodes spread over a large area. The mesh topol-
ogy allows gathering of data over large area, similar to the mesh network topology. In addition, the use of
(a) Star (b) Mesh
(c) Star-mesh hybrid
Figure 2.9: Wireless Sensor Network topologies .
several gateways reduce energy from ’hopping’; it also ensures that the whole network remain in operation
when nodes or gateways fail.
2.6 Installation of equipments
Source-end equipments must be housed in enclosures, close to existing DBs from which current and
voltage signals are tapped. Two enclosures, E-1 and E-2 were installed near DB-L1 and DB-CNC respec-
tively. Figure 2.10 illustrates the relative position of E-1 and E-2 with respect to their respective source
DBs. Internal layout of E-1 and E-2 can be found in Appendix B
Figure 2.10: Position of enclosures relative to DBs.
Figure 2.11: Relative locations of DBs and data acquisition equipments deployed
Figure 2.11 and the following bullets summarizes our discussion in this chapter:
1. Communication technologies supported:
(d) IEEE 802.15.4
2. Data acquisition and energy meter deployed:
(a) ADAM-4017+ meters from DB-CNC;
(b) ADAM-6017 meters from DB-P1, DB-L1 and DB-MISC;
(c) INTEGRA-1630 meters from DB-SH in STARHome;
(d) Five MICAz motes scattered in C&C Facility to monitor temperature and humidity;
3. Sensors deployed:
(a) CR-3110 for current sensing;
(b) CE-VJ03 to convert output of CR3110 to VDC;
(c) CE-VJ41 for voltage sensing from 3-phase circuit;
(d) TA 30R CT used with Intergra-1630;
4. Enclosures installed:
(a) E-1 houses,
i. 03× ADAM-6017,
ii. 18× CE-VJ03 VT,
iii. 01× CE-VJ41 VT,
iv. 03× Resistors board,
v. 03× Fuse holder,
vi. 02× WAP3205 access point,
vii. 02× Power supply adapter,
(b) E-2 houses,
i. 02× ADAM-4017+,
ii. 12× CE-VJ03 VT,
iii. 01× CE-VJ41 VT,
iv. 02× Resistors board,
v. 03× Fuse holder,
vi. 01× Power supply adapter,
5. Base station in C&C Facility consists of:
(a) Windows Workstation as an UI and database;
(b) NI cRio Real-Time controller to process all instructions and data;
(c) Netgear switch to manage communication with all hardware components;
(d) WRT610N Wi-Fi router retrieve data from ADAM-6017 modules wirelessly;
3.1 Serial data acquisition
Serial communication interfaces are still widely used despite the introduction of several other communi-
cation technologies. The popularity of serial communications can be attributed to its reliability in data
handling. It has also become a standard practice for many equipment manufacturers to incorporate the
serial interface in data terminal equipments (DTE). Due to the availability of serial DAQ devices in he
market, it makes sense for the EnerScope system to support serial communications. This section will
describe how serial communication is implemented in the EnerScope system.
3.1.1 An overview of serial standards
Most computers provide at least one serial connection port in the form of a 9-pin female connector. This
connector is commonly known as the serial COM port on personal computers and is an actual RS-232
interface. Through this communication port, one serial DAQ device supporting the RS-232 standard can
interface directly with the PC. However, serial DAQ devices are not limited to the RS-232 standard. Newer
serial standard like RS-485, are increasingly popular in the data acquisition market due to its ﬂexibility
and robustness. Fortunately, RS-485 devices can still communicate with the DTE’s serial port (supporting
the incumbent RS-232 standard) by ﬁrst interfacing with an RS-485/RS-232 converter.
Table 3.1: Key characteristics of RS-232, RS-422 and RS-485 standards.
Description RS-232 RS-422 RS-485
Mode of operation single-ended differential differential
No. of drivers in one line 1 1 32
No. of receivers in one line 1 10 32
Max. cable length 15 m 1200 m 1200 m
Max. data rate at max. length 20,000 baud 100,000 baud 100,000 baud
RS-485 offers several advantages over RS-232 in that the former allows multi-drop communications
over a single network bus and high speed data transmission rates over a maximum distance of 1200 m. On
the other hand, RS-232 can only support one device per port and is limited to a maximum distance of 15 m
(Figure 3.1a). Using a RS-485/RS-232 converter, an RS-232 port can be converted to an RS-485 terminal,
which will then allow up to 32 receivers and 32 drivers to communicate on a single bus (Figure 3.1c).
The other serial standard that often comes into the picture when discussing between RS-232 and RS-
485 is RS-422. Like RS-232, RS-422 supports 4-wire, full-duplex communication but has the added
advantage of multi-drop communication and long transmission distance like RS-485. However, RS-422
only allow one driver in the data bus. Implementation of RS-422 is rare compared to the other two
standards but is usually used to extend the transmission distance of an RS-232 device through a RS-
422/RS-232 converter. When RS-422 or RS-422 is implemented, each receiver must be assigned a unique
ID (slave identity) for the driver to correctly identify and assign instructions to the intended receivers.
Table 3.1 summarizes the key differences among the three serial standards that we have introduced in this
Figure 3.1: Relative topologies of RS-232, RS-422 and RS-485 communication network.
3.1.2 Network wiring of ADAM-4017+ modules
DATA+ and DATA- terminals on ADAM-4017+ provide the 2-wire interface for RS-485 communication.
Standard pin-out for 9 wire serial cable with a DB-9 connector inherits from RS-232 speciﬁcations, al-
though RS-485 communication may also be carried out through the same cable and connector. Since
ﬂow-control and modem-control do not require additional signal wires in RS-485, only RXD+, RXD- and
GND (corresponding to pins 4,5 and 1 on a DB-9 connector) will be used. Other wires in the standard
null-modem cable are not utilized, hence not connected (NC). In Table 3.2, the ’Signal’ column represents
the signal conventionally carried by a serial cable. As shown in the table, a 2-wire RS-485 device only
require three signal wires corresponding to pins 1, 4 and 5 of a DB-9 connector. Table 3.3 shows the
corresponding pin assignment on the RJ50 side of the the 10P10C-DE9M cable provided by NI.
Table 3.2: Pin assignment for RS-485 DB-9 connector.
Connector Pin Signal 2-wire
1 GND GND
2 CTS+ NC
3 RTS+ NC
4 RXD+ DATA+
5 RXD- DATA-
6 CTS- NC
7 RTS- NC
8 TXD+ NC
9 TXD- NC
Table 3.3: Pin assignment for RS-485 RJ-50 connector.
Connector Pin Signal
Once physical wiring between the driver (cRIO-9074) and a receiver (ADAM-4017+) is completed, an
RS-485 bus is thus established. Henceforth, more receivers can be added to the bus (up to 32) by daisy-
chaining as shown in Figure 3.2a and Figure 3.3. Note that ’star’ and ’tree’ or ’stubbing’ conﬁgurations in
an RS-485 network are not recommended since they result in complicated transmission line which lead to
hence unreliable data communication .
(b) Stub conﬁguration
(c) Star conﬁguration
Figure 3.2: Daisy-chaining, Stub, and Star conﬁgurations for RS-485.
Assigning slave ID’s to devices in the network
This project utilizes two ADAM-4017+ modules daisy-chained to a single RS-485 bus that connects to
the real-time system (cRIO-9074). The presence of more than one slave device (receiver) on the network
necessitates the assignment of a unique slave ID on each device. Slave ID’s must be assigned on each
device separately by connecting the DATA+ and DATA- terminals on the device to similar terminals on a
RS-485/RS-232 converter. The converter allows RS-485 devices to interface with serial port of the com-
puter. After connection with the PC is established, a arbitrary and unique slave ID can be assigned using
the utility software provided by the manufacturer. When a unique ID has been assigned on each device,
the computer or driver will then identify the devices on the RS-485 network by its ID. Other settings such
as input channel conﬁguration and baud rate can be conﬁgured at anytime during the deployment.
3.1.3 Serial communication with NI real-time system
ADAM-4017+ serial DAQ modules connect to a real-time system (NI cRIO-9074) via NI 9871, a serial
communication module that ﬁt exactly into one of the slots on cRIO-9074. The NI 9871 therefore behave
as an interface that connects any RS-485 (and RS-422) compliant devices, with the cRIO-9074 real-time
system. An RS-485/RS-232 converter is not required in this case.
The NI 9871 provides four RJ-50 ports for RS-485 communication with our ADAM-4017+ devices.
Connection to these ports require the 10P10C-DE9M cable — a 10-wire, shielded cable with an RJ-50
connector (Table 3.3) on one end, and a male DB-9 connector (Table 3.2) on the other — that can be
extended by connecting to a null-modem serial cable of appropriate length. This extension cable should
have a female DB-9 connector on one end, and open on the other, such that pins 1, 4 and 5 wires can be
wired directly to the GND, DATA+ and DATA- terminals on the ADAM-4017+. Figure 3.3 illustrates the
connection between the real-time system and ADAM-4017+ network.
Figure 3.3: Cabling between serial DAQ modules in an RS-485 network and NI 9871 serial com-
munication module on a cRIO-9074.
3.2 Wi-Fi data acquisition
Wireless data acquisition systems can eliminate costly and time consuming ﬁeld wiring. These systems
consist of one or more wireless transmitters sending data back to a wireless receiver. In the case of the
EnerScope system, this receiver form part of the base station’s communication interface. All wireless
technologies have very limited range in an indoor environment. And even more so when the transmission
path between transmitter and receiver encounter several layers of signal attenuating obstructions such
as walls, panels and glass doors, features common in an ofﬁce building. Therefore, when selecting a
particular Wi-Fi device, be sure to ﬁeld test the range of the signal prior to deployment. At the time of
writing, Wireless-N (802.11n) has the best range and speed over earlier editions.
3.2.1 Using ethernet DAQ devices for Wi-Fi acquisition
Three ADAM-6017 modules will tap signals from various lighting and power circuits leading to the EPGC
ofﬁce from a circuit breaker box located approximately 50 m from the base station. These modules are
ethernet-based devices and ideal for remote data acquisition through the existing LAN network. Since
there no LAN network point exist in close proximity to the devices’ deployment site, we decided to set-up
a Wi-Fi network instead. Because ADAM-6017 complies with TCP/IP, we further enhanced the device by
attaching a wireless access-point to it to give the modules Wi-Fi capability. This is illustrated in Figure
3.4. Note that the number of access points required depends entirely on the number of ADAM modules
deployed and the number of ports available on each access point. The switch is part of the EnerScope’s
base station and its role is described in Chapter 2.
Figure 3.4: Wireless data acquisition using ADAM-6017, router and access point.
Steps for wireless data acquisition
1. Connect module to PC’s ethernet port using ethernet cable (CAT-5e patch cable).
2. Launch ADAM utility program (provided by manufacturer) and assign a unique IP address.
3. Upon successful assignment, repeat steps 1 and 2 to assign unique IP addresses to other modules.
4. Disconnect module from PC and connect access point.
5. Access the wireless device’s conﬁguration page from a browser by entering device’s IP address
(usually 192.168.1.1 by factory default).
6. Conﬁgure access points to enable forwarding to base router (refer to manual).
7. Once forwarding is enabled, disconnect access point from PC.
8. Connect the ADAM modules to the access point as shown in Figure 3.4.
9. Connect the router to the PC (directly or through switch).
10. Acquire data wirelessly.
The access points act as virtual wires connecting the ADAM-6017 devices to the base router. Once the
network is set-up, data from the ethernet DAQ modules can be accessed by either establishing a physical
connection with the router, or by connecting wirelessly to Wi-Fi network in question. Because the wireless
network is available in the airwave, anyone with appropriate knowledge can access the wireless network.
Hence, the wireless network just established present as a possible entry point for malicious activity. To
maintain the integrity of the system, the network should be encrypted and hidden from public view. To
enhance network security further, the router can be conﬁgured to allow access only from certain IP or
Testing the communication
One way to ascertain the communication between the remote modules and the base station is by using the
ADAM utility software. Assuming the the router is connected to workstation (either directly or through a
network switch), one can use the utility software to search for ADAM modules on the wireless network.
Upon successful communication, information of each device will be displayed, and remote conﬁguration
of each device, such as setting input channel voltage range, will then be possible.
3.3 Data acquisition through the LAN
In today’s highly connected world, most buildings are built with an underlying extensive communication
network. The existing LAN infrastructure in a building is ideal for remote monitoring applications and
minimizes the need for further wiring with the addition of new devices to the network. In this section, we
describe how we acquire data from a remotely placed energy meter using the building’s data bus.
3.3.1 Using ethernet-enabled energy meter for remote acquisition
Integra-1630 is a compact energy meter that is capable of measuring numerous energy parameters (refer
to Table 4.3). StarHOME overall load will be measured from this device and the data generated will be
tunneled to the Real-Time Energy Management System’s base station located in the CC Centre at EPGC.
StarHOME and EPGC are housed in the same building but are separated by ﬁve levels of concrete ﬂoor-
ing. Hence, data transfer using serial cables or Wi-Fi is not feasible since cabling will require expensive
installations and wiﬁ communications over ﬁve levels is not a practical due to the limitations of the signal
range. Nevertheless, this level separation do not pose a real communication problem as the Integra-1630
also support ethernet communication. Using a standard ethernet cable (CAT-5 or CAT-6), this ethernet-
enabled energy meter can transmits its data to the base station through the existing LAN infrastructure of
3.3.2 Getting help from the network administrator
The communication network is not by any means trivial — the whole building network is a network of
networks, with ﬁrewalls, switches and hubs at various points. To get data from a remote location within
the building to the base station, there must be a link between these two points. Most probably, only
the network administrator has the authority to establish the link required. Therefore, consultation with
network administrator is necessary in most new deployment.
Integra-1630 can be conﬁgured from the front panel. When the module is ﬁrst installed, there is a need to
conﬁgure the modules so that energy parameters calculated by the device accurately reﬂects actual values.
Communication parameters must also be conﬁgured accordingly.
Modbus address: 001 Baud rate: 38400 Baud Parity: no parity, 1 stop bit
IP address assignement
Communication through the LAN require the address of Integra-1630 in the network to be speciﬁed. IP
address of the Integra can be conﬁgured using Ruinet[int1630], a simple command-based utility that allow
users to set a unique IP address of supported equipments. Essesntially, the Ruinet utility software works
by ﬁrst detecting any ﬁeld servers on the same network as the host computer. When the ﬁeld servers are
detected, their IP addresses and register activities will be reﬂected in the Ruinet terminal window. Ruinet
also allows the IP addresses of detected ﬁeld servers to be conﬁgured remotely from the host PC. For
sucessful detection of ﬁeld servers in the network, the user must ﬁrst ensure that the host PC and the ﬁeld
servers are within the same subnet.
Once set, data can be retrieved in a master-slave queries and response scheme. LabVIEW provides the
necessary VIs to initiate TCP communication in the Communications library.
RETRIEVING AND PROCESSING DATA
4.1 Protocols and Data Formats
In Chapter 2 we discussed how ethernet-enabled DAQ devices can reduce cabling costs by communicating
wirelessly, or by taking advantage of the extensive LAN infrastructure in the building. Making sense of
the data. however, will involve several layers of processing before data in familiar units, such as volts
and amperes, are ﬁnally exposed. In Modbus TCP communication, initialization of TCP communication
using the IP address and port number of the remote device is required. IP addresses can usually be assigned
manually prior to deployment while port number is 502 for ALL modbus communications.
Once TCP link is established, master-slave communication in the modbus network can then be carried
out. Analogous to the client-server relationship in networking, the modbus master initiate communication
by sending a query to a modbus slave which listens to queries addressed to it, and responds accordingly.
In this case, the master is the base station’s automated query powered by LabVIEW while the various data
acquisition devices in the network are its slaves. At this stage, it is important to understand the modbus
protocol in sufﬁcient detail to facilitate master and slave communication.
Data received will likely be in a form not understood by most users. Decoding will reveal the actual
raw data and will require the understanding of the device coding format as speciﬁed by the manufacturer.
This section will show how ’peeling’ layer after layer of the coded data is carried out.
4.1.1 Modbus protocol
The Modbus protocol follows a client/server (master/slave) architecture where a client will request data
from the server. The client can also ask the server to perform some action. The client initiates a process
by sending a function code that represents the type of transaction to perform. The transaction performed
by the MODBUS protocol deﬁnes the process a controller uses to request access to another device, how
it will respond to requests from other devices, and how errors will be detected and reported. Modbus
protocol establishes a common format for the layout and contents of message ﬁelds.
4.1.2 IEEE ﬂoating point format
The IEEE 754 ﬂoating point format is the most widely used standard for ﬂoating point computations. It
speciﬁes four formats for representing ﬂoating point values — single precision (32-bit), double precision
(64-bit), single-extended precision (≥ 43-bit) and double-extended precision (≥ 79-bit) (Note that a byte
is equivalent to 8 bits) . In this report, we will only discuss single precision format since we will not
be needing the others. Table 4.1 shows the structure of IEEE 754 single precision ﬂoat.
Table 4.1: IEEE 754 ﬂoating-point format for single precision.
Hi Register Hi Register Lo Register Lo Register
Hi Byte Lo Byte Hi Byte Lo Byte
SEEE EEEE EMMM MMMM MMMM MMMM MMMM MMMM
S - sign bit where 1 is negative and 0 is positive;
E - 8-bit exponent with an offset of 127;
M - 23-bit mantissa. The 24th bit is always 1.
4.2 Data acquisition from Integra-1630
4.2.1 Integra-1630 Modbus data format
Table 4.2: Integra-1630 modbus data format for each byte in RTU mode
Coding system 8-bit per byte
4 bytes (2 registers) per parameter
Floating point format (IEEE 754)
Most signiﬁcant register ﬁrst (Default)
Error check ﬁeld 2 byte cyclical redundancy check (CRC)
1 start bit
8 data bits, least signiﬁcant bit sent ﬁrst
1 bit for even/odd parity (or no parity)
1 stop bit if parity is used; 1 or 2 bits if no parity
4.2.2 Register addresses and parameter mapping
Present values of measured and calculated electrical parameters are stored in the device’s input registers.
Integra-1630 allocates each parameter in two consecutive 16-bits registers beginning from the starting
address. Table 4.3 provide an exhaustive list of input register parameters provided by the energy meter
set-up for 3-phase-4-wire conﬁguration.
Table 4.3: Integra-1630 parameters and modbus addresses (3-phase-4-wire). .
Register Parameter Start Address (Hex)
30001 Volts L1-N 0000
30003 Volts L2-N 0002
30005 Volts L3-N 0004
30007 Current 1 0006
30009 Current 2 0008
30011 Current 3 000A
30013 Watt Phase 1 000C
30015 Watt Phase 2 000E
30017 Watt Phase 3 0010
30019 VA Phase 1 0012
30021 VA Phase 2 0014
30023 VA Phase 3 0016
30025 VAr Phase 1 0018
30027 VAr Phase 2 001A
30029 VAr Phase 3 001C
30031 Power Factor Phase 1 001E
30033 Power Factor Phase 2 0020
30035 Power Factor Phase 3 0022
30037 Phase Angle Phase 1 0024
30039 Phase Angle Phase 2 0026
30041 Phase Angle Phase 3 0028
30043 Volts Average 002A
30047 Current Average 002E
30049 Current Sum 0030
30053 Watts Sum 0034
30057 VA Sum 0038
30061 VAr Sum 003C
30063 Power Factor Average 003E
30067 Phase Angle Average 0042
30071 Frequency 0046
30073 Wh Import 0048
30075 Wh Export 004A
30077 VArh Import 004C
30079 VArh Export 004E
30081 VAh 0050
Continued on Next Page...
Table 4.3 – Continued
Register Parameter Start Address (Hex)
30085 W Demand Import 0054
30087 W Max. Demand Import 0056
30101 VA Demand 0064
30103 VA Max. Demand 0066
30105 A Demand 0068
30107 A Max Demand 006A
30201 Volts L1-L2 00C8
30203 Volts L2-L3 00CA
30205 Volts L3-L1 00CC
30207 Volts L-L Average 00CE
30225 Current Neutral 00E0
30235 THD Volts L1-N 00EA
30237 THD Volts L2-N 00EC
30239 THD Volts L3-N 00EE
30241 THD Current 1 00F0
30243 THD Current 2 00F2
30245 THD Current 3 00F4
30249 THD Volts Mean 00F8
30251 THD Current Mean 00FA
30253 Hours Run 00FC
30255 Power Factor (+Ind/-Cap) 00FE
30259 Current 1 Demand 0102
30261 Current 2 Demand 0104
30263 Current 3 Demand 0106
30265 Current 1 Max. Demand 0102
30267 Current 2 Max. Demand 0104
30269 Current 3 Max. Demand 0106
4.2.3 Decoding register values
Modbus registers holding energy parameters in Integra-1630 are in engineering units and require no scal-
ing. All data in the Integra-1630 are stored as 32-bit IEEE 754 ﬂoating point numbers in two modbus
registers. Current parameter values in modbus registers can be decoded by converting the ﬂoating point
numbers from their hexadecimal form to decimal from. Note that each parameter is stored in two consec-
utive registers beginning from the start address (Table 4.3, column 3).
As an example, lets assume we want to read the current total power of the electrical system. From
Table 4.3, this parameter is assigned the modbus address of 30053 with starting address at 0034 (hex).
Since parameter values are stored in two registers, the value for total power must be read from both 0034
and 0035 register addresses. Successful reading of register addresses will return the parameter value in
hexadecimal. To illustrate the decoding process, we assume querying addresses 0034 and 0035 returns
hexadecimal values 4560 and 8800 respectively. The two 4-digit hexadecimal numbers are then separated
into four 2-digit hexadecimal numbers. At this stage, we must ensure that the numbers are in the proper
order — Hi Register Hi Byte followed by Hi Register Lo byte followed by Lo Register Hi Byte followed
by Lo Register Lo byte.
Hi Register Hi Register Lo Register Lo Register
Hi Byte Lo Byte Hi Byte Lo Byte
45 60 88 00
Next, we convert each 2-digit hexadecimal numbers into 8-bit binary numbers using Hex-to Binary
conversion widget that is freely available on the internet. In LabVIEW, this can be implemented by
specifying the data type of the numeric control. After conversion, we get:
Hi Register Hi Register Lo Register Lo Register
Hi Byte Lo Byte Hi Byte Lo Byte
01000101 01100000 10001000 00000000
Under the speciﬁcations of IEEE 754 ﬂoating-point format, the 32-bit binary number can be con-
structed by concatenating the four 8-bit binary numbers we just obtained. Cross-referencing the above
binary representation with Table 4.1, we produce the following binary numbers:
S - 0;
E - 10001010;
M - 11000001000100000000000.
To ﬁnd the exponent value, we ﬁrst convert 10001010 to decimal, giving 138. Because the exponent
is offset by 127, we need to subtract the offset from the 138. Thus, the actual exponent is 11.
The mantissa is a 24-bit number but 1 bit is always not stored in the binary representation since it
always have the value 1(note that the mantissa we obtained consist of only 23 bits). Therefore we add 1
followed by a period, to the beginning of the mantissa resulting in 1.11000001000100000000000. We then
move the period in the mantissa by an amount equal to the exponent. Since our exponent is 11, the period
moves to the right by 11 places. Our ﬁnal binary ﬂoating-point number is: 111000001000.100000000000.
To convert the binary ﬂoating-point number to its decimal form, we execute the ﬂoating-point arith-
metic which speciﬁes that binary bits to the left of the period represent a power of 2 with respect to their
position, and binary bits to the right of the period represent a negative power with respect to their positions.
The ﬁnal decimal number is then the sum of these two numbers obtained separately, and positive (since S
111000001000 (binary number to the left of period) represents:
(1 × 211
) + (1 × 210
) + (1 × 29
) + (1 × 23
) = 3592
100000000000 (binary number to the right of period) represents:
(1 × 2−1
) + (0 × 2−2
) + (0 × 2−2
) + ... = 0.5
Addition of these two values gives, 3592 + 0.5 = 3592.5
Therefore the total power of the electrical system at the time of query is +3592.5 W
The process involved to decode the register values of Integra-1630 can be summarized in the following
Move ‘.’ to right
If Sign ==1
Figure 4.1: Integra-1630 register decode algorithm.
Exponent in decimal is offset by 127
Sign bit; 0 is positive
Sign bit; 0 is positive
If sign bit is equal to 1, then negate.
Figure 4.2: Decode VI for Integra-1630 registers.
Like ADAM-6017, Integra-1630 uses the Modbus protocol of data transfer. Hence, read and write
programs written for ADAM-6017 can also be used to read and write registers from the Integra-1630 after
minor code modiﬁcations. A clear advantage of utilizing an intelligent meter is that all parameters are
computed within a relatively compact device and no further data processing is required from the user,
reducing development time.
4.3 Data acquisition from ADAM modules
In Chapter 2, we introduced the equipments required to measure voltage and current signals from various
circuits in the DB. Unlike the Integra-1630, ADAM-6017 and 4017+ modules can only measure voltage
and current signals. Even so, the values held in ADAM registers are raw values that cannot be directly
utilized in a meaningful way. Therefore, substantial development is required to not only process these
raw values into real-time voltage and current readings; but also to further manipulate of these readings
into other parameters like power and energy. The following subsections will describe the steps required to
acquire and accurately interpret the data from ADAM modules.
4.3.1 Interpreting register values
In Chapter 2, the equipments required for data acquisition from EPGC Ofﬁce and the Command Control
was shown. In this section, we will use some speciﬁcations of each component in the data acquisition chain
to convert raw values output from the ADAM modules into correct voltage and current readings.
Current signals from source circuits go through several equipments starting from a current transformer,
then moving on to voltage transducer, and ﬁnally the input of our ADAM module where digitization take
place. At each interface, the original signal is modiﬁed as it goes through complicated electronic system
of each device. Figure 4.3 illustrates the transition of current signal from source to ADAM output.
Figure 4.3: Signal conversions from analog source to digital output.
The CT scales down input current I by a factor N where N is the turns ratio. The output current i is,
Looking into terminal ab, the ouput of the CT sees an input impedence Zab, which is total impedence of
the resistor, VT and the ADAM module in parallel. Then,
R × Zvt × Zdaq
R + Zvt + Zdaq
where R is resistor value, Zvt is impedence of VT, and Zdaq is impedence of the DAQ device. Current i
will produce voltage across cd as,
Vcd = i × Zab (4.3)
The VT calculates the RMS value of the sinusoidal input voltage signal and outputs an RMS value that is
half of the value at the input. Voltage between ef is,
R and VT output rating is chosen such that voltage at the input channel of ADAM do not exceed 5V . V
represents that voltage value that is read by the user and reﬂects the actual value at the input terminal of
the DAQ device. Hence,
V = Vef (4.5)
Substituting (5.1), (5.3) and (5.4) into (5.5), we get
I × Zab
Since the original intention is to measure current I ﬂowing through the source circuit, through some
arrangement we get
The bracketed term in (5.7) is a constant, where N = 3100 and Zab is measured to be 1285 Ω.
Voltage measurement is much more straight forward. The VT we used for voltage measurement has
an input rating of 250V and output rating of 5V and essentially functions as an RMS converter and down-
scaler. Voltage value given by ADAM must therefore be re-scaled by multiplying by 50 (250/5). The VI
in Figure 4.4 implements this conversion. Figure 4.5 shows the block diagram of a VI that reads every
register of an ADAM-4017 module and processes it to correct units through scaling and conversion. The
same VI may apply to ADAM-6017+ with modiﬁcation to the relevant connection parameters.
C:Documents and SettingshafizosmanDesktopFYP LabVIEW DataenerScope visenerScope v2a.1_RTVolt-
Last modified on 2/24/2010 at 12:51 PM
Printed on 2/24/2010 at 12:51 PM
CT turns ratio
Reff (ohm), looking in
from the CT output.
CR3110 Split-core CT (scale down sensed current by a factor of 3100) -
Volts produced across Reff (consist of resistors and device impedences) -
CE-VJ03 VT (Rated input 10V, Rated output 5V. Volts scaled down by factor 2 -
ADAM 6017/4017 (configured for voltage inputs between 0-5V)
Figure 4.4: VI for voltage to current conversion from ADAM input.ReadScale_Adam4017P.vi
C:Documents and SettingshafizosmanDesktopFYP LabVIEW DataenerScope visforReport
Last modified on 2/28/2010 at 3:15 AM
Printed on 4/12/2010 at 2:12 PM
Read Holding Registers
VISA resource name
Min EU -5
Voltage to Current
Figure 4.5: VI that reads and interprets ADAM-4017 registers in proper units.
4.3.2 Input channel assignments
Correct assignment of input channels for any DAQ device is the most critical step in data acquisition be-
cause any mismatch will certainly result in unreliable source data, rendering all derived values corrupt.
A scenario illustrating this, is that of a user assuming an input of a DAQ device to measure a certain pa-
rameter from a certain circuit; when in actual fact, that particular input measures a different circuit and/or
parameter. Therefore, there is a need to make recordings of circuit-to-input assignments as equipment
installation is being carried out.
Table 4.4 and Table 4.5 maps each channel of the DAQ modules to their respective circuit location.
For example, the ﬁrst row of Table 4.4, indicates that Channel 0 of A4017-01 measures current (since a CT
is used as a sensor) from the Red phase of the Main circuit (labeled M-R), located in the distribution box
labeled as DB-CNC. Likewise, the last row of Table 4.5 indicates that Channel 7 of ADAM-03 measures
voltage (since a VT is used as a sensor) from the Blue phase bus. To visualize the locations of the circuits
in their respective DB’s, refer to Appendix A.
Table 4.4: Channel assignments for ADAM-4017+ modules.
Module Channel Location Circuit Sensor Load
A4017-01 0 DB-CNC M-R CT Main
A4017-01 1 DB-CNC M-Y CT Main
A4017-01 2 DB-CNC M-B CT Main
A4017-01 3 DB-CNC P-R CT Outlet
A4017-01 4 DB-CNC P-Y CT Outlet
A4017-01 5 DB-CNC P-B CT Outlet
A4017-01 6 DB-CNC L-R CT Lighting
A4017-01 7 DB-CNC L-Y CT Lighting
A4017-02 0 DB-CNC L-B CT Lighting
A4017-02 1 DB-CNC AC-R CT A/C
A4017-02 2 DB-CNC AC-Y CT A/C
A4017-02 3 DB-CNC AC-B CT A/C
A4017-02 4 Bus NC NA NA
A4017-02 5 Bus VR VT Main
A4017-02 6 Bus VY VT Main
A4017-02 7 Bus VB VT Main
Table 4.5: Channel assignments for ADAM-6017 modules.
Module Channel Location Circuit Sensor Load
A6017-01 0 DB-L1-8C R-1 CT Lighting
A6017-01 1 DB-L1-8C R-2 CT Lighting
A6017-01 2 DB-L1-8C R-3 CT Lighting
A6017-01 3 DB-L1-8C R-4 CT Lighting
A6017-01 4 DB-L1-8C B-1 CT Lighting
A6017-01 5 DB-L1-8C B-2 CT Lighting
A6017-01 6 DB-P1-8C R-1 CT Outlet
A6017-01 7 DB-P1-8C R-2 CT Outlet
A6017-02 0 DB-P1-8C Y-1 CT Outlet
A6017-02 1 DB-P1-8C Y-2 CT Outlet
A6017-02 2 DB-P1-8C B-1 CT Outlet
A6017-02 3 DB-P1-8C B-2 CT Spare
A6017-02 4 DB-MISC-8C R-2 CT Outlet
A6017-02 5 DB-MISC-8C R-6 CT Lighting
A6017-02 6 DB-MISC-8C Y-2 CT Outlet
A6017-02 7 DB-MISC-8C Y-4 CT Outlet
A6017-03 0 DB-MISC-8C B-1 CT Outlet
A6017-03 1 DB-MISC-8C B-2 CT Outlet
A6017-03 2 NA NA NA NA
A6017-03 3 NA NA NA NA
A6017-03 4 Bus VN VT Main
A6017-03 5 Bus VR VT Main
A6017-03 6 Bus VY VT Main
A6017-03 7 Bus VB VT Main
4.3.3 Data manipulation
So far, all we have done is read register values and perform conversion techniques to either voltage and
current values. Go go further by grouping circuit currents into phases (red, yellow and blue) and load type
(lighting, power outlet, A/C or main). We also use these data to compute power and energy consumption
of the circuit groups. We therefore end up with more parameters than what the ADAM modules provide
after some manipulations. Figure 4.6 gives an example how variables can be manipulated to create more
variables. In this block diagram excerpt, the left-most column of variables are original voltage and current;
the middle and right-most columns are power variables derived from the variable in the left-most column.
C:Documents and SettingshafizosmanDesktopFYP LabVIEW DataenerScope visforReportADAM Power.vi
Last modified on 4/12/2010 at 6:21 PM
Printed on 4/12/2010 at 6:21 PM
6017_03  V_B
6017_03  V_Y
6017_03  V_R
4017_01  Main_R
4017_01  Main_Y
4017_01  Main_B
4017_01  EqmtAC_R
4017_01  EqmtAC_Y
4017_01  EqmtAC_B
4017_01  Light_R
4017_01  Light_Y
4017_02  Light_B
4017_02  AC_R
4017_02  AC_Y
4017_02  AC_B
4017_02  V_R
Figure 4.6: Creating shared variables from manipulation of shared variables.
C:Documents and SettingshafizosmanDesktopFYP LabVIEW DataenerScope visforReportMain_cnc.vi
Last modified on 3/15/2010 at 5:25 PM
Printed on 4/12/2010 at 5:59 PM
Lighting Circuits 6
Lighting Circuits 4
Lighting Circuits 7
Lighting Circuits 5
Power Sockets 2
Lighting Circuits 2
Lighting Circuits 3
CNC Light Sum
CNC Light B
CNC Light Y
4017_01  Light_Y
4017_02  Light_B
CNC Light R
4017_01  Light_R
EPGC (From ADAM 6017)
Figure 4.7: Polling and display of shared variables.
These variables are produced by the real-time controller and made available to systems in its network
as Shared Variables. Since the workstation lies within the same network as the real-time controller, the data
display panel of the energy management system can be easily conﬁgured to display the shared variable
data stream. Figure 4.7 illustrates the polling and display of shared variables using a while loop and
4.4 Database connectivity in LabVIEW
The integrated real-time controller has in-built memory to store instructions and for datalogging purposes,
but this memory will not be used for the following reasons — the integrated memory is limited and is ideal
only when logging frequency is low, such as when only alarm or trigger events are logged; secondly, full-
feature databases like Microsoft Access or SQL servers are more versatile and can interface with numerous
Windows software for useful functions. For instance, an Access database ﬁle can be easily imported into
Excel if say, we need to use Excel’s graphing features for report generation. Using a dedicated RDMS
also has the advantage of storing enormous amount of data in a highly organized manner, with high data
reliability. LabVIEW provide database drivers through its Database Connectivity Toolset to allow users to
quickly connect with databases with minimal programming. Alternatively, open-source database toolset
can also be downloaded freely from the internet.
Figure 4.8 shows the actual datalogging tha was implemented. The while loop is controlled by the
timer VI wired to the Log Frequency case structure. In this case, the while loop is set to execute its
contents at 5 minutes interval. What this code does is, it inserts a new ’Power’ value (refer to Table ??,
look for 0034 in the third column and verify the corresponding parameter) into ’StarHome’ table in the
database speciﬁed by the .udl path, every 5 minutes. To log more parameters, simply wire the appropriate
variable into the the input terminals of the ’Insert Data Row’ SubVI. ’EPGC’ and ’CNC’ table can be
logged in the same manner
C:Documents and SettingshafizosmanDesktopFYP LabVIEW DataenerScope visforReportDataLOGG
Last modified on 3/16/2010 at 10:17 AM
Printed on 4/15/2010 at 10:20 PM
Log Data to Access .mdb
5 minutes, D
Universal Data Link *.udl
5 minutes, D
Figure 4.8: Inserting data row-by-row into an Access database.
4.4.2 Querying a database
Both datalogging and query activites were implemeted using the free ADO toolkit that can be downloaded
from www.ib-berger.com. This VIs provided in this toolkit allow us to query the Access database us-
ing common SQL commands and syntax. The block diagram in Figure 4.9b is a code excerpt from the
graphing portion of the Main window. This block diagram opens the connection to the Access database
using ADOTool OpenDB.vi and then selects the required data using ADOTool SelectData.vi. Figure 4.9a
shows the SQL statement entered, and the corresponding data generated from the query.
C:Documents and SettingshafizosmanDesktopFYP LabVIEW DataenerScope visforReportQueryDB.vi
Last modified on 3/30/2010 at 11:33 AM
Printed on 4/14/2010 at 5:07 PM
error out 2
C:Documents and Settingshafizosman
error out 2
Database Variant To Data
Change data from a variant table
to a string table
error out 2
C:Documents and Settingshafizosman
error out 2
Database Variant To Data
Change data from a variant table
to a string table
error out 2
Figure 4.9: Front panel and block diagram showing the query of an Access database.
SYSTEM EVALUATION: MERITS, LIMITATIONS AND COST
5.1 Application development in LabVIEW
LabVIEW is a graphical programming environment in which the user selects suitable functions from
LabVIEW’s library of virtual instruments (VIs) and connects them with ’wires’ to build new VIs that are
capable of performing speciﬁc user-deﬁned tasks. A VI is essentially a function that retrieves values from
its input nodes and churns out other values at its output nodes, a concept that is very similar to text-based
programming environment such as C. For example, in C, applications are built based on text instructions
that will involve the calling of functions, then passing of parameters into functions, computations and
returning of a certain parameter to the caller. Likewise, LabVIEW uses icons with input and output nodes
to represent a function (or VI) and the interconnection of these VIs represents the ﬂow of data which
determines the program execution.
LabVIEW was originally designed to create GUI front ends for test and measurement systems, hence
its heavy emphasis on the many different I/O buses used in that industry. Over time, however, it has
evolved into more of a general-purpose language. However, LabVIEW is not the only general purpose
language in the market that can be used for SCADA applications like our EnerScope system. In fact, there
exist several languages that are suitable for industrial automation and instrumentation purposes. In this
section we will address the strengths and limitations of LabVIEW as a platform for the development of
our energy management system.
Apart from the relatively speedy development time that LabVIEW offers as a result of the highly
intuitive graphical environment, the platform also provide very specialised packages for different purpose.
For example, the Datalogging Supervisory Control module is specially designed for real-time data-
acquisition, datalogging and equipment control. LabVIEW is chosen as the development environment
for the EnerScope energy management system because LabVIEW has very extensive support and market
presence in the area of instrumentation hardware, apart from the simplicity that graphical programming
has to offer. The actual energy management program will run in NI integrated real-time controller.
5.1.1 Strength of LabVIEW
LabVIEW is especially designed to interact with measurement instruments and tools giving its users the
capability to set up the measurement applications rapidly using in-built wizards or device drivers. Lab-
VIEW enables a user who has limited knowledge of programming to produce a working measurement
application with elegant user-interface in a relatively short-time. The built-in user interface components
such as buttons and graphs require virtually no programming. Parallel execution of multiple tasks is
handled automatically by placing independent loops on the block diagram, often a requirement in data
acquisition and control applications.
5.1.2 Cost of developing in LabVIEW
Although there are many open source projects written using LabVIEW, the development environment
itself is expensive — the student edition is apprximately SG$120 while the professional version with
many advanced function will set back more than SG$7,000. While LabVIEW has decent support for non-
NI devices, NI devices still enjoy seamless integration with the LabVIEW platform. An NI device can be
set-up almost immediately using the DAQMax wizard whereas non-NI devices rely heavily on drivers to
get it running on LabVIEW.
When developing a real-time system in LabVIEW, a developer not only has to rely on expensive NI
hardware but also has to purchase additional modules to interface with the relevant hardware. In the
EnerScope project, our need for a headless real-time system led to the purchase of cRIO-9074. Because
the cRIO is essentially a modular system, additional capabilities have to be purchase separately. cRIO
has no in-built support for serial communication with serial devices and require the NI-9871 for this
additional capability that our system require. Unfortunately, these hardware components ill not work with
our existing LabVIEW platform without ﬁrst installing the Real-Time module and the FPGA module,
thereby adding cost to the system. The closed-source, vendor monopoly of NI software and hardware is
probably the greatest barrier to developing a low cost system.
Professional Development system
Figure 5.1: Relevant hardware and software for headless portion of real-time system.
The dependence of NI hardware on LabVIEW is schematically shown in Figure 5.1. LabVIEW Profes-
sional Development platform is used to develop test and measurement applications by interfacing directly
(or through device drivers) with non-NI equipments. The addition of the cRIO real time system require
the installation of LabVIEW Real-time module as indicated by the solid arrow in Figure 5.1. To enable
the real-time hardware to communicate with external serial devices, an additional hardware (NI-9871) has
to be installed on the cRIO, which in turn, require another additional software module (FPGA module)
to interface with the existing LabVIEW platform. The headless real-time system cost more SG$22,000
(refer to Table 5.1) with the software component alone costing around SG$17,000.
Table 5.1: Approximate cost of relevant hardware and software for a headless real-time system.
Component Cost (SG$)
LabVIEW Developer suite 7,340
LabVIEW Real-time module 4,807
LabVIEW FPGA module 4,807
5.1.3 Portability of software written in LabVIEW
Portability of a developed software is another important consideration when choosing a development plat-
form. A software that is highly portable will not only have the potential to reach a greater audience, it also
allows the software to enjoy a proper software development life-cycle — a lacking feature when written
on a platform that is highly restrictive. A development platform that is costly will naturally cater to a
smaller pool of users than a freely available one. Where LabVIEW is concerned, a collaborative effort
in application development will require separate installation and license of the LabVIEW software. Due
to the high cost of the platform, a collaborative effort may increase the cost of development. Cost aside,
collaborative effort is also challenging due to the nature of a graphical programming. Being a graphical
language, LabVIEW relies heavily on icons and connecting wires. As the program grow bigger, it is easy
to get lost in the mess of icons and wires in the block diagram. Therefore, a lot more effort is needed for
documentation if collaborative development is needed.
Portability issues do not end at the development stage. A complete software must eventually reach the
end-user. With regards to the EnerScope system, the end-users can be home owners, facilities, institutions
of higher learning and even a whole power generation and supply system. Due to the possibility of a di-
verse customer base, a LabVIEW developed software must be able to run in stand-alone mode. It certainly
does not make economic sense for customers to purchase and install a LabVIEW suite just to run several
VI’s on their system. Fortunately, LabVIEW is able to compile projects into stand-alone applications that
can run on Windows, Mac and Linux environments using the Application Builder module.
The Application Builder module is included in the Professional Development system but must be pur-
chased separately if using the Base Package or Full Development System. Although, the Application