UNIVERSITEIT•STELLENBOSCH•UNIVERSITY
jou kennisvennoot
•
your knowledge partner
Long Range (LoRa) Based Modem for Remote
Low-Voltage Energy Meter Access
by
Jason Waugh
20000871
Project E448
Report submitted in partial fulfilment of the requirements of
the module Project (E) 448 for the degree Baccalaureus in
Engineering in the Department of Electrical and Electronic
Engineering at the University of Stellenbosch
Study leader:
Mr Christo Nicholls
November 2019
i
Acknowledgements
I would like to acknowledge the following individuals whom have had an extremely positive impact on me during my academic career;
My Father, John Waugh, whom has shown nothing but endless love and support towards my goals in the academic field.
My Sisters, Samantha and Danielle Waugh, for always being by my side with unmatched
wisdom and calming advice.
My Mother, Sharon Hann, even though being away always managing to provide love
and mental stability.
I would further like to extend my appreciation to the following individuals who have
been a part of this project
Mr Christo Nicholls, for providing unparalleled insight into the field of research and providing motivation through passion for problem solving in South Africa.
Mr Jacques Paulse, for taking part in this research project and providing specialist insight
and much needed support.
Abstract
English
Efficient use of Electrical energy is of high concern today in South Africa as extreme
demand over strains outdated infrastructure within the energy distribution grid. While
replacing infrastructure is not an option, replacing low-voltage components such as prepaid meters is very expensive.
This applied research project aims to develop a possible solution architecture to upgrade
legacy pre-paid meters for enhanced and smart functionality by enabling bi-directional
communications between distribution components with new communication technologies.
This document will review trends and regulations in advanced metering infrastructure
in South Africa and describe the software and hardware development stages of an end
node device, a gateway data router and a back end server host.
It was found that the solution architecture of an IoT based communications system was
capable of wirelessly connecting users to low-voltage pre-paid meters and cost effectively
upgrade legacy meters to smart meter status.
Afrikaans
Doeltreffende gebruik van elektriese energie is vandag in Suid-Afrika baie kommerwekkend,
want ’n uiterste vraag ooreis verouderde infrastruktuur in die energiedistribusienet. Die
vervanging van infrastruktuur is nie ’n opsie nie, maar dit is baie duur om lae-spanningskomponente
soos voorafbetaalde meters te vervang.
Hierdie toegepaste navorsingsprojek is daarop gemik om ’n moontlike oplossing vir argitektuur te ontwikkel wat vooruitbetaalde meters sal opragradeer vir verbeterde en slim
funksionaliteit, deur dit moontlik te maak om rigtinggewende kommunikasie te gebruik
tussen verspreidingskomponente met nuwe kommunikasietegnologiee.
Hierdie dokument sal die neigings en regulasies in gevorderde meetinfrastruktuur in SuidAfrika bespreek en die sagteware en hardeware-ontwikkelingsfases van ’n eindknoopapparaat, ’n gateway-data-router en ’n back-end server host beskryf.
Daar was gevind dat die oplossingsargitektuur van ’n IoT-gebaseerde kommunikasiestelsel in staat is om gebruikers met lae-spanning voorafbetaalde meters te koppel, en om
ouditmeters na slim meter status op te grader in ân koste-effektiewe manier.
ii
Contents
Abstract
ii
Contents
iii
List of Figures
v
List of Tables
vii
Nomenclature
viii
1 Introduction
1.1 Project Objectives . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
1
2
2 Literature Study
2.1 Pre-payment Metering . . . . . . . . . . . . . . .
2.1.1 Meter Communications . . . . . . . . . . .
2.2 Demand response Strategies . . . . . . . . . . . .
2.3 Advanced metering infrastructure . . . . . . . . .
2.3.1 AMI in South Africa . . . . . . . . . . . .
2.3.2 Eskom AMI pilot . . . . . . . . . . . . . .
2.3.3 City Power: Smart Metering Project . . .
2.3.4 Soweto Split Metering Project . . . . . . .
2.4 Communication technologies . . . . . . . . . . . .
2.4.1 Narrow Band Internet of Things (NBIoT)
2.4.2 Low-Power Wide-Area networks (LPWAN)
2.4.3 SigFox . . . . . . . . . . . . . . . . . . . .
2.4.4 LoRa and LoRaWAN . . . . . . . . . . . .
2.4.5 Comparison . . . . . . . . . . . . . . . . .
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
3
3
3
7
8
8
9
10
10
10
10
12
13
13
15
3 System Design
3.1 System Overview . . .
3.2 End Node Device . . .
3.3 Network Gateway . . .
3.4 Back-End Server Host
3.5 Conclusion . . . . . . .
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
16
16
17
17
18
18
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
4 Methodology
19
4.1 Validation Methodology . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19
4.2 Development Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19
4.3 End Node Device . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19
iii
iv
CONTENTS
4.4
4.5
4.6
4.3.1 Meter Interfacing . .
4.3.2 Network Interfacing .
4.3.3 Device Power Supply
4.3.4 Remarks . . . . . . .
Gateway . . . . . . . . . . .
4.4.1 Remarks . . . . . . .
Application Host . . . . . .
Conclusion of Methodology .
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
20
24
25
26
26
27
27
28
5 System Integration
5.1 Testing . . . . . .
5.2 End to End . . .
5.3 Range . . . . . .
5.4 Load Profiling . .
5.5 Power Limiting .
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
29
29
29
29
31
31
6 Conclusion
6.1 Project Summary
6.2 Appraisal . . . .
6.3 Lessons Learnt .
6.4 Recommendations
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
32
32
32
33
33
Appendix A: Project planning Schedule
34
Appendix B: ECSA Level Outcomes
35
Appendix C: Letter of Appraisal
37
Appendix D: XML Templates
38
Appendix E: Software Scripts
41
List of References
46
List of Figures
2.1.1
2.1.2
2.1.3
2.2.1
2.3.1
2.4.1
2.4.2
2.4.3
2.4.4
2.4.5
HDLC frame format [1] . . . . . . . . . . . . . . . . . . . . . . . . . . .
OSI Layers Imposed on Pre-Paid Energy Meters . . . . . . . . . . . . .
Full DLMS Synchronization and Association Between Client and Server
Demand Response Motives [2] . . . . . . . . . . . . . . . . . . . . . . .
Propsed AMI Network Structure by NRS-049 [3] . . . . . . . . . . . . .
3GPP release notes [4] . . . . . . . . . . . . . . . . . . . . . . . . . . .
LPWAN performance comparison [5] . . . . . . . . . . . . . . . . . . .
Star Network Topology . . . . . . . . . . . . . . . . . . . . . . . . . . .
LoRa chirp for spreading factors 7-9 . . . . . . . . . . . . . . . . . . . .
LoRa preamble up chirps with following data symbols: 7,0,16,112 . . .
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
5
6
6
7
8
11
12
12
14
15
3.1.1 High Level System Diagram . . . . . . . . . . . . . . . . . . . . . . . . . . . 16
3.3.1 Raspberry Pi 3 Model B+ . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18
4.3.1
4.3.2
4.3.3
4.3.4
4.3.5
4.3.6
4.3.7
4.3.8
4.4.1
4.4.2
4.4.3
Developed Arduino Infrared TX/RX Extension Circuit Diagram . . . .
HXE34-KP 3 Phase Energy Meter Communication port diagram . . . .
Communication Port Protocol Profiles . . . . . . . . . . . . . . . . . .
Negotiation Request and Response Log . . . . . . . . . . . . . . . . . .
Example XML Data for Low-Level Security Application Access Request
Implemented Meter Interfacing Software Flow Diagram . . . . . . . . .
Implemented Network Interfacing Software Flow Diagram . . . . . . . .
Arduino Power Supply Regulator Circuit . . . . . . . . . . . . . . . . .
Implemented Gateway BASH script Flow Diagram . . . . . . . . . . .
Gateway Debug View for Database Push . . . . . . . . . . . . . . . . .
Simulated Data on Hosted Database . . . . . . . . . . . . . . . . . . .
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
20
21
21
21
23
23
24
25
26
27
27
5.2.1
5.2.2
5.2.3
5.4.1
Debug Log for Credits Request . . . .
Gateway Debug Log for Data Received
Updated Database with New Data . .
Webview of credit data with user usage
.
.
.
.
.
.
.
.
.
.
.
.
30
30
30
31
.0.1
Letter of Appraisal: Jacques Paulse (Snr Engineer at Eskom Group Technology) 37
.0.2
.0.3
.0.4
.0.5
.0.6
AARQ
AARQ
AARQ
AARQ
AARQ
.0.7
Arduino Sketch: Setup . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 41
XML
XML
XML
XML
XML
for
for
for
for
for
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
No Security Authorization . . . . .
Low Level Security Authorization .
High Level Security Authorization
Normal Request of Time data . . .
Normal Set Request . . . . . . . .
v
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
38
39
39
40
40
vi
LIST OF FIGURES
.0.8
.0.9
.0.10
.0.11
.0.12
.0.13
Arduino Sketch: Main Loop . . . . . . . . . . . . . . . . . . . . . . . . . .
Arduino Sketch: Time synchronization and Client initialization request functions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Arduino sketch: Clear buffer and data transmit functions . . . . . . . . .
Arduino sketch: Client data request . . . . . . . . . . . . . . . . . . . . . .
Gateway BASH script for data routing to database . . . . . . . . . . . . .
Embedded website Javascript for database data accessing . . . . . . . . . .
. 41
.
.
.
.
.
42
42
43
44
45
List of Tables
2.1.1 Initial Client Server Message Formats . . . . . . . . . . . . . . . . . . . . . . 4
2.4.1 Configurable LoRa Parameters . . . . . . . . . . . . . . . . . . . . . . . . . . 14
3.2.1 Arduino MKR WAN 1300 Relevant Features . . . . . . . . . . . . . . . . . . 17
4.3.1
4.3.2
4.3.3
4.3.4
4.3.5
Initial Request Serial Configuration [6] . . . . .
Negotiable Baud Rates [6] [7] . . . . . . . . . .
Implemented OBIS codes And descriptions . . .
Maximum Full LoRa Airborn Packet: Spreading
LoRa Packet Format . . . . . . . . . . . . . . .
.0.1
Project Schedule . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 34
vii
. . . . .
. . . . .
. . . . .
factor 9
. . . . .
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
22
22
22
25
25
Nomenclature
Abbreviations —————————————————————————
ST S Secure Token Service
IoT Internet of Things
DLM S Device Language Messaging Specification
COSEM Companion specification for Energy Meters
AM I Advanced Metering Infrastructure
SAN S South African National Standard
OSI Open Systems Interconnection
OBIS Object Identifications System
IEC Independent Electoral Commission
HDLC High Level Data Link Control
M AC Media Access Control
HCS Header Check Sequence
F CS Frame Check Sequence
SN RM Set Normal Response Mode
P DU Program Data Unit
AARQ Application association Request
DR Demand Response
DM S Data Management Systems
CIU Customer Interface Unit
LoRa Long Range
IDE Independent Development Environment
U SB Universal Serial Bus
T X Transmit
RX Receive
T T L Transistor to Transistor Logic
LLC Logical Link Controll
LLS Low Level Security
SP I Serial Peripheral Interface
RT C Real Time Clock
CRC Cyclic Redundancy Check
SSH Secure Shell
CSS Cascaded Style Sheet
viii
NOMENCLATURE
HT M L Hyper Text Markup Language
XM L Extensible Markup Language
ID
Identity
AARQ Application Association Request
OBIS Object Identfication System
DSM Demand Side management
T oU Time of Use
GSM Global System for Mobile Communications
U M T S Universal Mobile Telecommunications system
LT E Long Term Evolution
3GP P third Generation Partnership Project
EC − GSM Extended coverage GSM
ISM Industrial Scientific Medical
BP SK Binary Phase Shift Keying
GP SK Gaussian Phase Shift Keying
EU Europen Union
W AN Wide Area Network
Hz
Hertz
RT C Real Time Clock
P LC Power Line Communications
GP RS General Packet Radio Service
HT T P Hyper Text Transfer Protocol
AP I Application Program Interface
ix
Chapter 1
Introduction
Energy plays one of the crucial roles in economic growth and societal lifestyles. The need
for the distribution to be efficient and reliable is of major concern. Well established energy
supply chains, internationally, are under immense pressure to align electrical energy demand with supply and to continuously do so in an energy efficient manner. This is driving
utilities to upgrade inefficient, unreliable legacy systems and infrastructure to make use
of more advanced information and communication technologies available.
In South Africa, low-voltage electrical grid infrastructure that is in place was implemented
during the electrification program of 1988. Prior to this program, only less than a third
of South Africans had direct access to electricity. [8]Though South Africa possessed a
world class energy supply chain, Eskom, electrifying the country proved challenging and
highlighted problems in distribution methods. While the program was aimed at supplying energy directly to larger customer bases and promoting economic growth, challenges
including customer connection management and billing processes due to the rural nature
of customers shifted focus to pre-paid metering systems implementation. [9] [10]
The underdeveloped and unreformed infrastructure in place within the supply network
renders Eskom unable to meet high demand periods or react to physical faults, ghost
vending and tampering, directly effecting profit margins. With the growing financial
strain, Eskom is forced to focus their efforts in low-cost and short term solutions including energy conservation and demand response programs to alleviate grid strain on
outdated infrastructure, rather than replace grid components. [11] [12]These programs
highlight a significant problem within the low-voltage distribution network, the lack of
affordable communications infrastructure between low-voltage components and Eskom.
The implementation of such real time communications systems within the distribution
network will provide distributors with greater vision into low voltage networks, allowing
efficient utilization of distributor resources and enable the participation of customers in
operations in an innovative, Smart Grid system. This will give Eskom real time access to
low-voltage network data and provide a base for development of re-configurable control
schemes of low voltage components. [3]
While the concept of smart metering is already well sought after and development well
underway in many countries, Eskom is unable to invest in such large-scale projects to
replace all distribution networked meters with available high operational cost communication solution technologies. Therefore a low cost, adaptable communications system
1
CHAPTER 1. INTRODUCTION
2
layer solution is required to rather enable meters with smart functionality and utilize
readily available functionality and data of Legacy meters in South Africa to their full
potential.
1.1
Project Objectives
This document investigates and reviews the development process and implementation of a
LoRa based communications layer for remote access to pre-paid meter data. This project
aims to introduce a means to break to the link between Pre-paid meters and Eskom
using the LoRa protocol and thus the objectives are to develop a full system architecture
through hardware and software integration, capable of:
• Secure Access to low-voltage Pre-paid meter data.
• Transmitting Meter data via the LoRa protocol to a LoRa network.
• Securely hosting meter data for cloud accessing
Chapter 2
Literature Study
Within this review of literature, we will explore; a brief history of pre-payment metering in
South Africa and regulated functionality of metering devices; applicable demand response
strategies within a South African context, Advanced metering infrastructure development
in south Africa and current implementations thereof and investigate practical communication technologies available for AMI network implementation. This chapter aims highlight
current trends and research on the topic of AMI in South Africa and identify challenges,
relevant technologies, practical considerations and industry norms.
2.1
Pre-payment Metering
After 1988, Eskoms strategy of selective energy supply (supplying only to registered and
billable customers) was redefined to promote an "Electricity for All" vision and to drive
economic growth in Southern Africa. [10] This approach presented many issues when confronted with aspects such as; billing of rural area customers with no registered addresses,
lack of grid infrastructure to supply rural areas with power and the adoption of fixed
tariffs among the rural customer base. [9] This drove rise to the pre-payment metering
system. The first request for pre-paid meterring systems and devices within Eskom was
made in 1989 and thus the first short hand specification standard was released, which
has thus been revised in years 1993, 1994, 1995, 2005 and 2008 [6] The SANS 1524-1 lays
out minimum specifications and requirements for the pre-payment devices in an attempt
to ensure devices fulfill Eskoms specific needs when in use. A some what under-specified
aspect of the pre-payment meters is that of the interfacing protocol, defining the OSI
layers of the device.
2.1.1
Meter Communications
Pre-paid meters are experiencing a rise in a secure and reliable communications protocol, Device Language Messaging Service (DLMS) and Companion specification for Energy
Meters (COSEM) for physical, data link and application layer interfacing. Implementation of communication technologies normally needs to follow sets of guidelines when being
developed. Data being transported via these technologies, being energy load profiles, instantaneous voltage or data and time values must all be supported by the technology and
fulfill the requirements for data integrity. This is all important in the context of Demand
response strategy implementations and possible extensions to functionality of the technologies, improving cost effectiveness of implementation.[13]
3
4
CHAPTER 2. LITERATURE STUDY
Data sets needed for collection by supply chains for billing processes and estimations are
relatively large and require a versatile protocol for various data formats. The DLMS/COSEM
define the interfacing protocol based on commonly used object modelling techniques,
defining object interfacing classes and attribute sets within classes, all accessible through
the Object Identification system (OBIS) codes.[14] This protocol is specified in the series
of standardised IEC-62056 documents for electricity metering data exchange. The structure of the interface model is based on the client-server model. In this model the client,
in this context a device attempting to access the meter, initiates communications with
requests and relative data is replied by the server (our Meter).[15] The IEC series covers
Physical, data link, transport and application layers and is such accommodated in South
Africa as the SANS 62056-21 series. Implementation of this protocol model guarantees
integrity between meters and devices from multiple manufactures used within the energy
distribution chain.
• SANS 62056-21 : Data exchange for meter reading, tariff and load control
• SANS 62056-5-3 : The DLMS/COSEM suit: DLMS/COSEM application layer
• SANS 62056-6-1 : The DLMS/COSEM suit: Object Identification system (OBIS)
• SANS 62056-6-2 : The DLMS/COSEM suit: COSEM Interface classes
• SANS 62056-7-6 : The DLMS/COSEM suit: The 3 layer, connection orientated
HDLC based Communications profile
Messaging Formats
Messaging formats for the Data Link Layer vary across different interfacing mediums
in the case of needed synchronizations and negotiations of device/meter capabilities.[16]
Synchronization protocol is specified in the SANS 1524-1 and can be seen below in table
2.1.1
Table 2.1.1: Initial Client Server Message Formats
Identification request Message
Identification Response Message
Acknowledge Message
/ ? <device address> ! <CR> <LF>
/X X X Z W <identification> <CR> <LF>
<ACK> V Z Y <CR> <LF>
• Identification request Message
– requesting server identification and preferred communication parameters
• Identification Response Message
– Servers response to ID request
∗ X - reserved for Meter Short ID code
∗ Z - preferred Baud rate
CHAPTER 2. LITERATURE STUDY
5
∗ W - Communication Mode
• Acknowledge message
– Acknowledge sent by client before switching baud rates and moving to specific
communications profile
An initial client request is sent at 300 baud, which includes optional physical address of
the client. The server will respond with its identification and preferred baud rate and
communications profile. A baud rate switch over must be made and an Acknowledge sent
to the server. one synced, the DLMS/COSEM media access control follows the High-Level
Data link Control frame format with some exceptions dependent on the preferred mode
of the meter.[16] The HDLC frames used in the MAC is based on the IEC 13239 and
includes enhancements in addressing, error control and segmentation of data.
Figure 2.1.1: HDLC frame format [1]
Protocol specifications for the MAC layer interactions follow HDLC frame type 3[14]
with Program data units within the information field. Type 3 frames include the enhancements mentioned and thus require a segmentation field in the the form of a header
check sequence HCS.
Flag fields are 1 byte in length and have the value 0x7E and are used to flag the beginning and end of a transmission frame, unless multiple frames are transmitted, thus a
single instance of the flag is used to separate frames. The Frame format field is 2 bytes
long and contains the frame type - for frame type 3 0xA0 is used - the remaining 8 bits
is reserved for the frame size in octets, excluding the flag bytes.
Addressing fields are for the client and server addresses and are 1 byte each. Control
fields indicate frame type, either I, RR or RNR. the first error check sequence is embedded in the HCS field which is 2 bytes long. this check field is only applied to the header
section, excluding the flag byte, the calculation of the HCS is the same as the FCS using
Cyclic redundancy check of 16 bits. The FCS is calculated over the entire message, excluding the flag.
The information field contains all program data units for processing by the server. The
final error check sequence is the frame check sequence that is calculated over the entire
frame, excluding the flag byte.
To create the client server communication instance, the client needs to establish an application association before any data transfers and application protocols can begin. This
is done after the initial handshake done in the data link layer in order to move into the
application layer. The association process begins after the protocol has moved to the
HDLC profile and begins with Setting of the normal response mode, know as an SNRM
request. this request defines HDLC parameters such as; addresses and Maximum PDU
CHAPTER 2. LITERATURE STUDY
6
Figure 2.1.2: OSI Layers Imposed on Pre-Paid Energy Meters
Figure 2.1.3: Full DLMS Synchronization and Association Between Client and Server
sizes. These parameter fields can be left empty to engage in default parameters.[15]
The application layer provides services to the client for application layer interactions.
These services are; association control(ACSE), extended DLMS application (xDLMS
ASE) and the control function(CF). Once the parameters are set, an Application Association Request(AARQ) is sent by the client to establish the association for access to
CHAPTER 2. LITERATURE STUDY
7
the application layer which is handled by the ACSE service. The association defines requested procedures from the ASE and context parameters for xDLMS.
once association is established, information requests all follow the COSEM model and
are identified using OBIS codes. these codes are referenced using their logical names, 16
bits each, which refer to the first attribute of the object. The DLMS/COSEM standard
is undoubtedly a very well suited protocol for the Energy chain structure. The structure of DLMS/COSEM is compatible with all types of energy interfaces and supports the
ability for future extensions to the object lists and models without disruption of already
implemented models. this makes it perfect for rushed deployment.
2.2
Demand response Strategies
Demand Response is defined as; the reduction in the consumption of electrical energy
by customers from their expected consumption in response to an increase in the price
of electrical energy or to an incentive payment. [2] Customers are aware of the lack of
generation and supply capabilities within South Africa and are expected to participate in
efforts of energy conservation and load elevation. However, there is no tangible incentive
for customers in South Africa and therefor rolling black outs still plague high load periods.
Both applicable options for a demand response strategy rely heavily on consumers will
to participate in the response. Customers will either need to lower their consumption
based on pricing signals or participate in an incentive program and react to high load
periods. Each use case of these options is dependent on the desired outcome from the
energy supplier as can be seen below, possible goals related to each option of response
can be seen in figure 2.2.1 [2]
Figure 2.2.1: Demand Response Motives [2]
While customer participation is crucial in effective demand response, two significant
problems make implementation of DR much more complex. The issue of flattening the
demand curve for electrical energy due to the lack of well-designed policies around Time of
Use tariffs make shifting the usage very difficult. [experience Europe] However, without an
efficient and highly reliable metering infrastructure, none of these options are financially
CHAPTER 2. LITERATURE STUDY
8
or practically viable for South Africa. Advanced infrastructure is yet to be fully implemented and regulated in South Africa, this infrastructure includes the data collection from
customer metering systems, reliable transmission of data to data management systems as
the demand response management sector to assess data and make policy decisions.
2.3
Advanced metering infrastructure
Advanced metering infrastructure (AMI) is a subset of the overall smart grid program
that places focus on the bi-directional communications link between customer meters and
the utility itself. [3] Therefor AMI is the crucial link between metering data and the data
managing systems in place to utilize the data for demand response programs or other
applications.
While AMI is relatively fresh for South Africa, regulation standards for implementation
Figure 2.3.1: Propsed AMI Network Structure by NRS-049 [3]
have been released in 2008 in NRS 049 document [3] offering options for South African
utilities to implement and utilizes AMI communications networks. Proposed Architecture
from NRS 049 can be seen in figure 2.3.1. AMI consists of; a smart meter, data collection
networks, AMI host systems and data management systems (DMS). These Wide area
Networks used for bi-directional data transmission can be wired, wireless or a combination
of both.
2.3.1
AMI in South Africa
Eskom has been mandated by the national Energy regulator of South Africa (NERSA) to
implement a comprehensive DSM strategy to reduce peak electricity demand and enhance
energy efficiency. [11] To achieve effective DSM, a collaboration between energy utilities
and customers to achieve predictable and sustainable changes in energy demand, two main
approaches can be used that are derived from figure 2.2.1
• Through direct load control
• Time-based rates
CHAPTER 2. LITERATURE STUDY
9
– TOU
– Critical peak pricing
– Real time pricing
By 2006, Eskom deployed a proof of concept project for ToU tariffs with a project
called HomeFlex. Residential meters were manually read, about 450 customers, by specially trained field staff on a monthly basis. [17] This project revealed 2 main observations
to be noted; the ToU tariff had little noticeable effect on customers consumption pattern
however increased incentive for customers to not bypass or tamper meters, Direct control
over high load devices on ToU meters resulted in an average of 0.7 kWh per customer
in peak times. This translated to 84MW of peak time load reduction at the time of the
project. [11] [17]
HomeFlex was not an effective demonstration of the concept but revealed that in order to have a large effect on customer consumption patterns, ToU tariffs need to be used
in conjunction with near real-time feedback systems to monitor consumption or customers
are unable to participate in the demand response strategy.
2.3.2
Eskom AMI pilot
During the year of 2008, Eskom experienced severe strain on their network causing memorable national blackouts and load shedding. Since then, Eskom passed a regulation, regulation 773, mandating all energy customers in consuming more than 1000kWh a month
to be using smart meter systems and ToU tariff schemes by 2012. [18] This prompted the
pilot project from Eskom to implement their unique regulation compliant AMI solution.
As per the regulating NRS049 Document, a regulation compliant AMI energy metering
system will Have; [12]
• Two-way communications from central servers to meters and other connected devices
• Automated meter reading functionality
• ToU metering functionality
• Non-Technical Loss detection
• Load Limiting and Appliance control
• Portable customer interface units for meter readings and utility information
• Two controllable relays for load control
• Remote load disconnection capabilities
Eskomâs solution architecture for the AMI implementation, as seen above, consists of;
a smart meter, customer interface unit, Appliance control device for scheduled high load
appliance control, AMI communications network including concentrators/gateways and
meter data management systems for data collection and processing. Also including in the
specifications of Eskoms tender for the AMI solution was for a Multi-Vendor integration
layer for integration of the billing systems and AMI master stations. [12]
CHAPTER 2. LITERATURE STUDY
2.3.3
10
City Power: Smart Metering Project
City Power, an independent municipal entity owned by the city of Johannesburg in Gauteng, took it upon themselves to deploy smart meter systems to high consumption and
domestic customers with focus on minimizing billing issues, improve overall revenue collection, and reduce non-technical losses [12] . While this project focused on improving
issues of legacy systems it also piloted the use of Inclined Block Tariffs and ToU tariffs for
residential and commercial customers. [12] [19] City Power installed over 65 000 meters
in their residential sector by the year 2015 and reported great success in their billing
accuracy and meter data. Estimation on load saving on the 335 000 units in the year
2017 was at 775MW, the project is still well underway with lots of momentum.
2.3.4
Soweto Split Metering Project
Eskoms split meter solution consists of the AMI status meter and the Customers interface
unit (CIU) that communicates bi-directionally with the meter. The CIU is installed in
the home, while the rest of the device is installed within a tamper proof box [20] Eskom
embarked on this project with similar aims to reduce growing debt margin, overloading of
transformers and address the unplanned blackouts through directly addressing the tampering of meters. [19] As the low voltage network is unable to be consistently monitored,
tampering of meters is a large portion of overall losses for Eskom. Sowetoâs customer base
consists of 181 000 customers, where 65 percent of whom were still on conventional billed
meter systems and the remainder on pre-paid. Eskom was able to install over 55 000 split
meter systems and convert more than 30 000 conventional meters to pre-paid systems by
March 2017. [19] The result of this project saw monthly revenues increase by 450 percent
within three years of the project life-cycle [19]The the ability to improve meter reading
accuracy, eliminate excess costs linked to customer billing processes and reduced call-out
costs linked to meter tampering, could all be addressed with AMI implementation in areas
such as Soweto.
2.4
Communication technologies
Wireless integration technologies connect electronic devices in a paradigm of complete
integration of all services offered. It allows remote interactions with smart devices for mobile and flexible access for homeowners, utility providers and third party service providers.
Communication network design considerations need to satisfy a variety of complex requirements to ensure secure transmission of sensitive data, while the data itself holds its
integrity through transmission. The technology to be chosen should be cost effective, secure, efficient in bandwidth, low power and provide good link budget. While considering
these specifications, a large weighting will be put on cost of deployment and operational
cost of the network and thus a wireless IoT network scheme will be explored as a solution.
2.4.1
Narrow Band Internet of Things (NBIoT)
For majority of the wireless age, cellular-communication protocols have supported humanorientated voice services and mobile-broad band services [21] [22]. In 2005, third generation partnership project (3GPP) started research and development in cellular network
CHAPTER 2. LITERATURE STUDY
11
bands such as GSM, UMTS and LTE for Machine to Machine communication. The solution was proposed to support IoT within the mobile cellular networks and to regulate and
standardize IoT protocols. This highlighted many issues with existing protocols, this includes congestion and overload within signal planes with the large number of devices that
shall be connected in the near future. They have thus refined and rectified these issues
with enhancements of the GSM access network with the redesign of requirements for security and overall network access architecture. This introduced 3 new kinds of narrow-band
air interfaces including; GSM-compatible EC-GSM-IoT, LTE-compatible eMTC and the
emerging Narrow-Band IoT (NBIoT). [21]
Figure 2.4.1: 3GPP release notes [4]
Observed in the figure 2.4.5 , NB-IoT development is highly dependent on existing
LTE carrier planes. The changes and development of NB-IoT systems and features are
made on relevant existing LTE technologies.[21]
NB-IoT’s notable achievement was the integration of the licensed spectrum, ensuring high
service quality and support from existing mobile equipment and manufacturers. Features
CHAPTER 2. LITERATURE STUDY
12
such as strong authentication, resulting in little additional infrastructure needed to deploy
large scale projects, and low overall power usage. Addressing the congestion factors by
using only 180 KHz of the LTE band for the entire network.
2.4.2
Low-Power Wide-Area networks (LPWAN)
IoT devices and application cases require very efficient specifications such as; low power
consumption for battery powered devices, low-data rates, long range and low cost. Solutions such as Zigbee, WiFi or Bluetooth are not effective radio frequency systems in long
range transmission or power efficiency. Cellular communication solutions such as; 2G, 3G
or 4G can provide the range in transmission but consume large amounts of device energy
and are thus not suitable for most IoT applications [11]
Figure 2.4.2: LPWAN performance comparison [5]
These requirements for IoT applications have driven a new wireless communication
technology to the surface in the form of Low-Power Wide-Area Networks (LPWAN).
LPWAN is characterized as a low power, wide area coverage network working in the sub
GHz industrial scientific medical (ISM) band. The LPWAN topology, unlike that of the
short-range multi-hop meshes of WiFi or Bluetooth, allows each node to communicate
directly to the base station in a star network topology. This network topology is highly
suited for low traffic and high density device to gateway use cases, such as that of a smart
meter integration.
Figure 2.4.3: Star Network Topology
CHAPTER 2. LITERATURE STUDY
2.4.3
13
SigFox
Sigfox is the first of the large scale IoT LPWAN ventures in Europe, showing great progress
and stability, even reaching support in Spain, France and Portugal. Sigfox was designed
for a device scheme that does not need a lot of frequent data transmission with initially
only supporting uplink but later including downlink capabilities.[5]
Operating within the unlicensed ISM bands and using BPSK in an ultra-low (100Hz)
band carrier. Sigfox uses the frequency bandwidth extremely efficiently resulting in low
noise, high receiver sensitivity and low power consumption at the expense of minimal
throughput, about 100bps. [23]
Favorable features of Sigfox include the ease of device activation’s. there is no need
for network configurations when new devices or gateways come online, as gateways are
capable of handling multiple devices across multiple channels. this makes it extremely
scalable. Although the network is conveniently in place and device configuration is relatively simplistic, all aspects of network debugging will be out of house.
Device uplinks are limited to 12 bytes per message and 140 messages per day, leaving
only 6.8MB of available transmission in a day.
2.4.4
LoRa and LoRaWAN
Long Range (LoRa) is a solution based on a spread spectrum modulation technique developed by Cycleo of Grenoble in France, later acquired by Semtech in 2012. This solution
consists of a physical layer LoRa chip and the LoRaWAN networking protocol. [24]
The LoRaWAN network structure is that of the describe star topology and consists of
four main components; End node devices, gateways or concentrators, network server filters and application servers. End node devices (Sensors or smart appliances) freely send
LoRa packets, gateways within range of devices will receive payloads and forward them
to the relative network servers for processing. Transmission protocols between gateways
and network servers can be of any type, allowing for user specification. Network servers
do relative security checks on payloads and acknowledge payloads, if needed payloads are
then forwarded the their respective application servers. Application servers are hosted
either on public or private clouds and run the necessary software applications to handle
payloads from the devices. The MAC is of an Aloha type, a send and hope to be received,
thus gateways/concentrators need to be visible at time of transmission for success full
transmits as no acknowledge system is present for end node devices.[25]
The physical layer uses a chirp spread spectrum technique (CSS) utilizing 6 spreading
factors, Factor7 to Factor12, while also making use of Gaussian Frequency Shift Keying
(GFSK) modulation as an added measure for out-band power and interference. Payloads
are encrypted within a series of up chirps within the specified frequency , as the technology supports the selection of different frequency channels and data rates. Possible data
rates are between 300bps and 50Kpbs and maximum payload length is 243 bytes. LoRa
technology is able to operate in the entire 868 MHz EU ISM band. Below in figure 2.4.4
is a visualization of the effect of the spreading factor on the modulated signal. Data rate
selection is at the expense of transmission range and overall message duration. [25] [26]
14
CHAPTER 2. LITERATURE STUDY
Figure 2.4.4: LoRa chirp for spreading factors 7-9
DataRate = SF ∗
Variable
CR
BW
SF
4
4+CR
2SF
BW
∗ 1000.
(2.4.1)
Description
Coding Rate
Bandwidth
Spreading factor
Table 2.4.1: Configurable LoRa Parameters
It can be seen in 2.4.5 Spreading factor selection also has an expense factor in the form
of the data rate.
LoRa end node devices are categorized into 3 different classes, highlighting power consumption characteristics for specific application needs. Listed from Most power efficient
to least.
• Class A - bidirectional end devices. Devices transmit up link beacons when ready
to receive for only 2 short down link windows. This class is the most power efficient
in operation but at the expense of heavy delays on down links to the device.
• Class B - bidirectional end devices with scheduled receive slots. This class implements the same protocol as class A, with the exception of another single scheduled
receive window, triggered by another up link beacon.
• Class C - Always Available to receive, except when transmitting. This class devices
is always listening and therefor highly inefficient in power consumption
CHAPTER 2. LITERATURE STUDY
15
Figure 2.4.5: LoRa preamble up chirps with following data symbols: 7,0,16,112
2.4.5
Comparison
Between LoRaWAN, Sigfox and NB-IoT, only NB-IoT does not operate within an unlicensed band and requires collaboration with cellular networks. Although NB-IoT is a
3GPP standard and holds high quality assurance and well supported network structure,
LoRa was chosen for this project due to the Independence aspect of the protocol. Implementing loRa enabled all network configuration, setup and debugging to be done in house
and keep the specified projection development location in Stellenbosch.
Chapter 3
System Design
This chapter aims to narrate a high-level description of the overall proposed solution
architecture together with rationale of system design choices made and specific hardware
component choices made for the development base. After the system architecture is
characterized, each section will comprise of individual key components within the system
to be developed and relative functionality to be validated in this project.
3.1
System Overview
The chosen system architecture will be based off of existing advanced metering infrastructure solution reviewed in 2. The system will validate smart metering device scheme
implementable within South Africa on Legacy Pre-paid metering systems, thus the design will be aimed at complying with South African standards and regulations for energy
devices.
Shown in figure 3.1.1 is all components and relative interaction paths representing the
designed infrastructure. Three key components within the system need to be developed
for this project, namely;
• An end node device for meter and network interfacing.
• A network gateway device for data routing.
• A back-end server system for application hosting and data management.
Figure 3.1.1: High Level System Diagram
16
17
CHAPTER 3. SYSTEM DESIGN
To achieve the proposed system architecture, new physical layer technologies are necessary for the end node device and the network gateway device.
3.2
End Node Device
Critical functionality within the system is the end node devices ability to interface with
the low-voltage meter and gain secure access to data stored within via the DLMS/COSEM
meter interfacing method specified in 2.1.1. The medium for interfacing chosen was the
serial infrared optic port. This medium was chosen to simplify the choice in hardware for
development as implementation of such an interface requires only a direct serial peripheral
on the chosen hardware.
The end node device will also be required to interface with the LoRa network. The
chosen method will be via a point to point implementation of the LoRa protocol, this
was chosen above the LoRaWAN protocol to simplify the implementation and hardware
choice related to the gateway device.
Chosen hardware for base development was the Arduino MKR WAN 1300. The board
supports a SPI and has an embedded USB hosting service for possible expansion on existing infrared optic USB devices.This development board also implements an embedded
LoRa radio module - the CMWX1ZZABZ chip - with well supported and versatile software libraries for a range of configurations for network interfacing. Relevant features of
the development board can be seen below.
Antenna Power
Flash Memory
SRAM
Clock Speed
2dB
256 KB
32KB
32.768 kHz (RTC), 48 MHz Normal
Table 3.2.1: Arduino MKR WAN 1300 Relevant Features
3.3
Network Gateway
The LoRa protocol is not supported on average hardware and therefor to bridge the
network gap, the proposed system requires a routing device. This device will receive
LoRa data packets and rout data via an internet protocol, making data widely available.
LoRaWAN network architecture consists of multiple gateway devices in a star-topology
running LoRaWAN software to manage multiple channels for mulitple connected devices.
For this project a simplified implementation will be developed using a single gateway with
a single channel, solely for the purpose of achieving remote access via the LoRa protocol
rather than designing a complex LoRaWAN infrastructure.
The gateway will need to implement the LoRa protocol and further support Ethernet
or WiFi for data routing to a back end system. The chosen hardware device was the
CHAPTER 3. SYSTEM DESIGN
18
Raspberry Pi 3 Model B+ along with an added Dragino LoRa Shield for interfacing with
the LoRa chip. This device runs an embedded Linux distribution based on Debian, Raspbian, enabling a variety of configuration choices and widely supported software packages
for ease of development and possible expansions of the project.
Figure 3.3.1: Raspberry Pi 3 Model B+
The Dragino LoRa shield, implementing the SX1276 radio Module, was chosen to enable LoRa Protocol on the Raspberry Pi which is interfaced via the embedded SPI. The
supported internet protocol interfaces will be leveraged to interface the gateway with the
Back end system.
3.4
Back-End Server Host
The back-end server component of the system will provide a graphical user interface to
the system and host a storage platform for data received from Gateway devices. For this
project it was chosen to use an existing server host service for simplicity of development.
The chosen service was Googles Firebase. The Firebase Host service offers an extremely
versatile development platform and a variety of well supported services to be implemented
on their servers for no cost,inclduing; A website hosting service, Web Application hosting
service and a real time database hosting service.
All three services will need to be implemented to achieve the functional back end system for the project objectives.
3.5
Conclusion
This chapter reviewed the proposed solution architecture for the problem investigated
introduced in chapter 1. three key components were discussed; The end node device,
gateway device and Back end system. Choices made for the development base of the key
components and relative functionality to be developed were described. This section set
the base for the project development which will be described in detail in chapter 4.
Chapter 4
Methodology
This chapter will describe the applied methods for development of the key system components and relative functionality together with relative validation methodologies adopted
for this project. Each section will expand on the key components stages of; development,
testing and result analysis. Each key components development will be described on a
low-level and results of isolated testing reviewed.
4.1
Validation Methodology
The research methods adopted for this project were based on a qualitative approach,
whereas the proposed solution architecture for the introduction of a LoRa based communications layer will be developed and reviewed. Further industry use cases are simulated
on the system and results reviewed. This enabled the project to validate the viability and
practicality of the proposed architecture and mediums.
4.2
Development Overview
The solution architecture described in Chapter 3.1 consists of complex component interfaces and thus each component was developed separately. Individual interactions between
components will be simulated according to criteria stipulated in 1.1, to Validate each components development success.
4.3
End Node Device
Development stages of the end node device can be split into two separate categories,
namely; Energy Meter interfacing and Network interfacing. Both categories consists of
mainly software development for data flow control and processing. This section will describe the development and testing processes of the end node device functionality.
Functionality to be developed on the end node device is, but is not limited to; LoRa
communications protocol implementation of a class B loRa device and DLMS/COSEM
energy meter interfacing protocol.
19
CHAPTER 4. METHODOLOGY
4.3.1
20
Meter Interfacing
With Slight variations in encryption, all pre-paid metering devices within South Africa are
regulated by Eskom in an attempt to standardize minimum meter functionalities and is
stipulated within their DISSCAAA9 document which thoroughly regulates the minimum
required interfacing parameters and protocol stacks. Unfortunately, even within the regulation documentation, there is still room for manufacturer specific interfacing protocols
and data encryption. Thus without accessibility to all manufacturer specific interfacing
parameters and encryption keys, a specific meter manufacturer was chosen to validate
meter interface development. The Chosen device was Hexing Co. HXE34-KP 3 Phase
low-voltage meter.
The Arduino development board used is programmed via the Arduino IDE, based off
a variation of the C++ language. All Arduino development and testing of the meter communication protocol was done using the Arduino IDE and accredited open source DLMS
Client simulation software GURUXDirector . Arduinos IDE embedded Serial port monitor feature was used for results analysis which will be presented and reviewed.
As reviewed in 2.1.1, the energy meter follows a strict protocol before allowing access
to the wanted application layer which holds all application objects and attributes we wish
to manipulate and collect. While the chosen development board does implement a USB
host service, to simplify development a simple yet effective Infrared optic attachment was
developed for the Arduino board to interface with the meters built in Infrared optic port
via the Arduinos Serial communication lines.
This port on the meter was chosen due to its basic Serial interface, thus no physical
Figure 4.3.1: Developed Arduino Infrared TX/RX Extension Circuit Diagram
layer protocols or drivers were needed to create a direct data stream with the meter. A
manufacturer specific meter diagram, 4.3.2, shows the possible interface ports available.
Provided by Hexing Co,4.3.3, shows the access layers for the optic port used as referenced
CHAPTER 4. METHODOLOGY
21
during development.
Figure 4.3.2: HXE34-KP 3 Phase Energy Meter Communication port diagram
Figure 4.3.3: Communication Port Protocol Profiles
It can be seen above in 4.3.3 the optic port follows the DLMS Mode E profile which
implements a negotiation stage for payload formats before the data stream begins. An
executed example can be seen in 4.3.4. It should be noted the 5th element of the response
depicts the selected baud rate as shown in 4.3.2
Figure 4.3.4: Negotiation Request and Response Log
The Arduino Serial library, Serial.h, was used to implement the communications link
with the added infrared optic attachment using standard TTL over Infrared. The Arduino Serial library allows for configuration of of the serial data format needed for the
DLMS protocol aspects such as baud rate switching and parity bit configurations.
22
CHAPTER 4. METHODOLOGY
Initial Baud Rate
300 b/s
Initial Serial Configuration
7E1
Table 4.3.1: Initial Request Serial Configuration [6]
Option
0
1
2
3
4
5
Baud Rate (b/s)
300
600
1200
2400
4800
9600
Table 4.3.2: Negotiable Baud Rates [6] [7]
The end node device was developed to implement the COSEM application layer association. This allowed the device to create an association and request or set available data
objects within the meter. Specific OBIS codes implemented for this project were stored
on the device memory for use and can be seen in table 4.3.3
OBIS Code
0-0:1-0:0.255
1-0:1.6.1.255
Description
Time
Available Credits
Return Format
hh.mm.ss
XXXX.XX
Data Type
double long unsigned
double long unsigned
Table 4.3.3: Implemented OBIS codes And descriptions
These Codes are inserted in the application requests and request access to the objects;
Available Objects and relative attributes within the application layer to be accessed, the
date and time objects of the meter and the power limiting factor for the load switch relay.
For this project, all association requests were constructed using the Extensible Markup
Language(XML) and converted to Hexadecimal Program Data Units (PDU) before implementing them as constants in the Arduino software script. Software used for the
conversions was an open source XML translator. This is a common practice in DLMS
implementation which allows for human readable configuration of requests. An example
can be seen below in 4.3.5
Developed functionality on the Arduino for the metering interface include; A cyclic redundancy checker and an HDLC frame decrypter for serial packet response processing
CHAPTER 4. METHODOLOGY
23
Figure 4.3.5: Example XML Data for Low-Level Security Application Access Request
Figure 4.3.6: Implemented Meter Interfacing Software Flow Diagram
during meter interfacing. The Cyclic redundancy implemented is a 16 bit check sum.
These check bytes are issued after the header as the header check sequence and before the
final flag as a frame check sequence in the HDLC responses from the meter.
The cyclic redundancy checker checks incoming data for any errors while the decrypter
pulls wanted data out of the received HDLC frames and stores them for transmission on
the network.
CHAPTER 4. METHODOLOGY
4.3.2
24
Network Interfacing
The Arduino board implements an Arduino hosted LoRa library, LoRa.h, and a serial
peripheral interfacing library for interfacing with the LoRa module, SPI.h. Both these
libraries were used in implementing the transmission protocol and to configure the LoRa
modules attributes such as spreading factor, data rates, and operating frequency band to
achieve the device functionality needed.
The chosen Implementation of the LoRa network interfacing for the end node device
is that of a class B LoRa device. The device is only available for data transmission in
specified slots and thus implements a sleep Synchronization function on start up to synchronize sleep cycles with specified down-link slots from gateways. The device function
requests a time and date value from the gateway and updates its on-board RTC. This
highlighted the need for a data type byte to be added into LoRa packets for the gateways
identification of the synchronization request, thus a data type byte was included as either
0 or 1. This class was chosen to ensure an overall low-power consumption with the possibility of adaptable down-link slots for future expansions on the project. The configured
time slots were for 4 times a day, thus 6 hours apart.
All data transmission to and from gateways from devices and vice versa are implemented
Figure 4.3.7: Implemented Network Interfacing Software Flow Diagram
as an adapted Slotted ALOHA protocol. Since for this project only a single channel
gateway was developed, multiple device up-links and message collision scenarios were not
considered in the design scope. Therefor devices sleep cycles were synced with gateways
and transmission slots were constant, avoiding the need for complex successful message
parameters for transmission acknowledges.
With Payload sizes not exceeding 100 Bytes a data-rate of level 3, 1760b/s, and a spreading factor of 9 in the 125KHz band was chosen for the LoRa protocol thus allowing a 123
25
CHAPTER 4. METHODOLOGY
bytes of data per transmission packet.
Airborn Packet Item
Pre-amble
CRC
Data Type
Data
Device ID
Size (Bits)
72
16
8
18
8
Table 4.3.4: Maximum Full LoRa Airborn Packet: Spreading factor 9
This is a comfortable amount for the implemented requestable data from the meter to be
transferred over the network to the gateway, though configuration of parameters is fast
and simple for any further adaption or implementation. The CRC and pre-amble form
part of the LoRa protocol stack and are already incorporated into the maximum packet
size, thus the packet format is as seen in 4.3.5
Device ID
Data Type
Data
Table 4.3.5: LoRa Packet Format
4.3.3
Device Power Supply
The chosen end node device hardware supports a 5V input voltage for external powering.
The HXE34-KP meter implements a PLC/GPRS communication module interface, seen
in 4.3.2. The port hosts a 6V supply and was leveraged for powering the Arduino. A
linear voltage regulation system was designed for stepping the 6V supply to 5V input for
the Arduino.
Figure 4.3.8: Arduino Power Supply Regulator Circuit
CHAPTER 4. METHODOLOGY
4.3.4
26
Remarks
This section reviewed the development process of the meter and network interfacing for
the end node device. To conclude, the end node device was capable of accessing the meter
data over DLMS/COSEM and send data via the LoRa protocol as seen in 4.3.4.
4.4
Gateway
As stated in 3.3, the gateway device chosen runs an embedded linux distribution and thus
configuration script was developed using BASH, a UNIX command shell language. This
implementation of the gateway is structured as a single channel packet router from the
LoRa network via Internet protocol to the real time database hosting service deployed on
googles Firebase. Development and testing was done using Windows UBUNTU distribution and Windows Software ATOM, an SSH client software for dynamic file access on the
Raspberry Pi.
This configuration was chosen to purely bridge the gap between end node devices and
potential users via the LoRa protocol and not to create a LoRaWAN infrastructure.
The developed functionality for the gateway; synchronization with end node devices transmission cycles when new devices come online, pushing data received from end node devices
to the back end hosted database via an internet protocol for user viewing.
Figure 4.4.1: Implemented Gateway BASH script Flow Diagram
Configuration of the LoRa Shield was implemented using an open-source LoRa and SPI
package installed on the Pi and correlates with the configurations of the End node device.
The Raspberry pi hardware does not implement an RTC, thus an HTTP request package,
Urllib, was installed allowing the gateway to to request time data from an online API to
sync with the Arduino.
Firebase host a command line interface with their system, Firebase tools, which was
CHAPTER 4. METHODOLOGY
27
installed onto the raspberry pi for interaction with the firebase API. These command line
functions were used to push data securely onto the hosted real time database.
Figure 4.4.2: Gateway Debug View for Database Push
Figure 4.4.3: Simulated Data on Hosted Database
4.4.1
Remarks
The gateway device developed provides an access point for LoRa transmitted data to be
routed to a cloud data hosting service. This is validated in ?? and further validates the
systems ability to transfer data from meters via LoRa to a cloud accessible data host.
4.5
Application Host
Googles Firebase provides versatile and efficient hosting abilities for a full range of testing
and implementation for this project and hosts the project server side features. Developed
Back-end services are the user web interface, the application service for server reaction to
the gateway and a database service to store data received by gateways to preview to users.
This was developed to create a user friendly interface to view the received data and
simulate the hosting of meter data and access on secure back end server architecture.
This also allows room for further implementable application functions for commands to
be sent to the devices via the interface or for fully automated server to end node device
communications.
CHAPTER 4. METHODOLOGY
28
The hosted user interface and embedded application software was developed in HTML,
CSS and javascript. the html script forms the back bone of the web-page structure
while being aesthetically molded by the css code for a user friendly look. The implemented Javascript code enables dynamic responses to data access of the hosted database
by pulling data from the database and displaying it on the web page for viewing,
4.6
Conclusion of Methodology
In this chapter each key components means for development and development process
was explored on a low-level. Key design choices were described and validation of isolated
functionality tested. System components were proven functional in an isolated simulation
scenario to complete the Pre-system integration phase.
Chapter 5
System Integration
Once each key component was developed and tested in isolated scenarios, system components were able to be integrated in compliance with .0.13 and tested. Testing scenarios
were based on the project objectives and findings of chapter 2 to simulate the possibility
of such applications in industry and assess the impact of the prposed architecture.
5.1
Testing
The fully integrated system tests first invoke simplified scenarios to validate component
interactions. Once all component interactions are tested, full functionality of the system will commence. Testing scenarios listed in 5.1 were chosen to validate the project
objectives and further test possible use cases of the proposed architecture, this includes
dispatching of Power Limit Tokens and User load profiling.
• End node device to web interface End to End test
• End node transmission Range test
• Down Stream Power Limit Token
• Load Profiling
5.2
End to End
To test the data flow from the end node device through to the server hosted website,
the end node device needs to send data via the LoRa protocol to the gateway device
which will push the received data via internet protocol onto the Google firebase real time
database. This will validate the system is able to fetch data from the meter and host it
on an accessible database via our LoRa network structure. Results can be seen in figures
5.2.1 , 5.2.2 , 5.2.3
5.3
Range
The transmission range tests were conducted by isolating the end node device and streaming data to the gateway device until transmissions were no longer received. Maximum
29
CHAPTER 5. SYSTEM INTEGRATION
30
Figure 5.2.1: Debug Log for Credits Request
Figure 5.2.2: Gateway Debug Log for Data Received
Figure 5.2.3: Updated Database with New Data
range for direct line of sight was averaged at 1.2 Km, while obscured sight at 800m. This
provides insight into the scalability of such a network structure. Though the project only
developed a single channel gateway device, implementing a multi-channel gateway will
thus only invoke the need for a single access point per 800m radius.
CHAPTER 5. SYSTEM INTEGRATION
5.4
31
Load Profiling
With the ability to request time stamped meter credit data, stored data can be used to
create a consumer usage profile. While the developed system is restricted to 4 requests a
day, alteration of data collection times can be easily changed to create a more accurate
profile.
Figure 5.4.1: Webview of credit data with user usage
5.5
Power Limiting
A significant application case for testing is that of meter power limiting. Pre-paid meters
have the ability to alter maximum power tolerances connected to the output relay.[6] The
ability to send power limiting tokens downstream to end node devices, to limit areas of
high load during high demand periods, enables Eskom to free up load in a virtual grid
system. This could potentially curtail the need for load-shedding.
The testing environment can not fully simulate the use case as only a single end node device was developed along with a single channel gateway device. Thus, the systems ability
to alter the power limiting factor from a command sent downstream was tested.
Small software alterations were added to the end node device enabling the device to
receive a power token and further use its AARQ functionality to Set the meter parameter. Unfortunately, to create Set associations with the Hexing Co. meter, high level
security access is required within the AARQ. specific to hexing Co., high level access
implements AES encryption with a manufacturer specific 128 bit key. An Authorization
request follows the AARQ with a random encrypted number received in the Association
response, enabling set functionality. During the project duration the key was unavailable,
thus power limiting values were not able to be changed.
Although, downstream tokens were able to be pushed via the database and received
by the end node device. With access to encryption keys, high level security association is
possible and further changing of the power limiting values can be changed.
Chapter 6
Conclusion
This chapter will review the project achievements and conclude all results gained through
development. A summary of outcomes achieved, lessons learnt and further recommendations for future development will be presented.
6.1
Project Summary
Reviewed in chapter 1, the issue of affordable remote access architecture to low voltage
electrical energy network components in South Africa was investigated and the impact
of this in demand response programs and dynamic grid functionality highlighted. Thus,
stated in chapter 1, this project aimed at investigating and reviewing the implementation
of a LoRa based communications system for legacy Pre-paid meters in South Africa.
Within the review of literature in chapter 2, it was found that pre-paid meters in South
Africa implement a complex communications protocol DLMS/COSEM which needed to
be developed for the end node device to gain secure data access. It was also found that
the IoT protocol LoRa was indeed best suited for a low cost, low power communications
protocol, thus a point to point LoRa network structure was developed for wireless data
transfer. Further a back end server system for cloud data management was developed to
validate data accessibility within the proposed communications structure.
6.2
Appraisal
The development of DLMS/COSEM protocol on the end node device was successful and
enabled the device secure access to the Pre-paid meter data, namely the available credits,
time data of the meter and the maximum power limit. Though the development was
forced to focus on a manufacturer specific meter due to a lack of resources related to
manufacturer specific interfacing protocols, validation of the communications structure
via LoRa was still satisfied.
The communications network implemented a gateway device for data routing from the
LoRa protocol to an internet protocol to host data received from meters on an accessible
service, the chosen service being Googles Firebase cloud servers. This enabled versatile
data access and validated the remote access to data from the meter via LoRa.
32
CHAPTER 6. CONCLUSION
33
Though the system was biased towards Hexing Co. Pre-paid meters, the developed system was able to validate the abilities of a LoRa based network and provides a base for
much needed future development of a versatile LoRa communications layer in conjunction
with all energy meter manufacturers.
Through review of results gained in 5.3 and 5.4, it is clear that implementation of this
network structure is capable of scaling down high operational costs involved with GSM or
GPRS based communication systems dramatically and provides insight to practical uses
with readily available data.
The project provides valuable insight to the need for future development within the IoT
based AMI solutions.
6.3
Lessons Learnt
Despite having an immense interest and passion for software development, the project
highlighted numerous weak points in my understanding of hardware implementation of
software protocols and thus increased my knowledge in the area. Deeper knowledge was
gained of the OSI stacks and industry implementation of data security. Further skills
were developed in shell scripting, Arduino, Javascript, database management and wireless
systems implementation.
6.4
Recommendations
Considering the time frame of development there are aspects of the projects hardware
architecture that if changed, would produce a more effective system. If more time were
dedicated to the project, a dedicated single board computer system should be used in place
of an a micro-controller unit for the end node device to enable more versatile functionality.
This would ease the development process while adding room for far more functionality
and eliminate the need for development of hardware interfaces.
Appendix A: Project planning Schedule
Project Task
Review Literature and Investigate
Formulate Problem Statement
Formulate Proposed Solution
Define Acceptance Criteria of Solution
Design Proposed System Architecture
Formulate Project Methodology and validation Process
Analyse Results
Conclude project
Table .0.1: Project Schedule
34
Start Date
08/07/2019
29/07/2019
12/08/2019
26/08/2019
09/09/2019
30/09/2019
21/10/2019
28/10/2019
Finish Date
29/07/2019
12/08/2019
26/08/2019
09/09/2019
30/09/2019
21/10/2019
28/10/2019
04/11/2019
Appendix B: ECSA Level Outcomes
ELO 1: Problem Solving - Identify, formulate, analyse and solve complex
engineering problems creatively and innovatively
• Formulate a factual problem statement based on factual industry cases, chapter 1
• Formulate a creative and innovative solution based on specified problem and define
a clear acceptance criteria, chapter 1 and 1.1
ELO 2: application of scientific and engineering knowledge - Apply knowledge
of mathematics, natural sciences, engineering fundamentals and an engineering speciality to solve complex engineering problems.
• Formulation of solution architecture based on industry use cases, chapter 1.1 and
chapter3.1
• Actual industry collaboration to formulate practical and useful solutions based on
complex industry problems, please refer to 6.4.
ELO 3: engineering design - Perform creative, procedural and nonâprocedural
design and synthesis of components, systems, engineering works, products or
processes
• Design of proposed solution architecture based on formulated problem statement,
chapter 3.1.
• Development of solution architecture components and isolated simulation, chapter
4.
ELO 4: investigations, experiments and data analysis - Demonstrate competence to design and conduct investigations and experiments.
• Analysis of isolated component development and simulations, chapter 4.
• Simulation of solution use cases and analysis of results, chapter 5.1.
ELO 5: engineering methods, skills and tools - Demonstrate competence to
use appropriate engineering methods, skills and tools, including those based
on information technology
• Complex software development on multiple environments in multiple languages,
including: LINUX bash scripting, Arduino Sketching, HTML and CSS, Python and
the use of GURUXDirector. chapter 4.
• Hardware development based on system needs, chapter 4.3.3 and 4.3.1.
35
APPENDIX B: ECSA LEVEL OUTCOMES
36
ELO 6: Professional and technical communication - Demonstrate competence
to communicate effectively, both orally and in writing, with engineering audiences and the community at large
• This document attempts to professionally communicate complex problems and relative complex solutions.
• This document also attempts to professionally communicate the complex methodology of validating the complex solution.
• This research was shared with Senior engineer at Eskom technology group Jacques
Paulse, in attempt to professionally communicate the research, refer to 6.4.
ELO 9: Independent Learning Ability - Demonstrate competence to engage
in independent learning through well developed learning skills.
• This project required independent research and learning in the following fields;
– DLMS/COSEM Energy Metering interface protocols
– Wireless communication methods and implementation
– Electrical energy demand response methods
– LINUX systems development
– Advanced metering infrastructure implementation
Appendix C: Letter of Appraisal
Figure .0.1: Letter of Appraisal: Jacques Paulse (Snr Engineer at Eskom Group Technology)
37
Appendix D: XML Templates
Figure .0.2: AARQ XML for No Security Authorization
38
APPENDIX D: XML TEMPLATES
Figure .0.3: AARQ XML for Low Level Security Authorization
Figure .0.4: AARQ XML for High Level Security Authorization
39
APPENDIX D: XML TEMPLATES
Figure .0.5: AARQ XML for Normal Request of Time data
Figure .0.6: AARQ XML for Normal Set Request
40
Appendix E: Software Scripts
Figure .0.7: Arduino Sketch: Setup
Figure .0.8: Arduino Sketch: Main Loop
41
APPENDIX E: SOFTWARE SCRIPTS
42
Figure .0.9: Arduino Sketch: Time synchronization and Client initialization request functions
Figure .0.10: Arduino sketch: Clear buffer and data transmit functions
APPENDIX E: SOFTWARE SCRIPTS
Figure .0.11: Arduino sketch: Client data request
43
APPENDIX E: SOFTWARE SCRIPTS
Figure .0.12: Gateway BASH script for data routing to database
44
APPENDIX E: SOFTWARE SCRIPTS
Figure .0.13: Embedded website Javascript for database data accessing
45
List of References
[1]
Dlms, T.: SANS 62056-6-2 : 2014 SOUTH AFRICAN NATIONAL STANDARD Electricity
metering data exchange â The DLMS / COSEM suite Part 6-2 : COSEM interface classes.
014. 2014. ISBN 9780626303686.
[2]
Xia, X., Setlhaolo, D. and Zhang, J.: Residential demand response strategies for South
Africa. IEEE Power and Energy Society Conference and Exposition in Africa: Intelligent
Grid Integration of Renewable Energy Resources, PowerAfrica 2012, , no. July, pp. 1–6,
2012.
[3]
Monontsi Nthontho, S.P. Chowdhury, S.W.: INVESTIGATING IMPLEMENTATION OF
COMMUNICATION NETWORKS FOR ADVANCED METERING INFRASTRUCTURE
IN SOUTH AFRICA Monontši Nthontho * | SP Chowdhury * | Simon Winberg * * Department of Electrical Engineering , University of Cape Town , South Africa. Proceedings of
ITU Kaleidoscope 2011: The Fully Networked Human? - Innovations for Future Networks
and Services (K-2011) (2011), pp. 1–8, 2011.
[4]
Economy, C. and Asia, N.: Construction of a Harmonious Northeast Asia and the Dilemma
of Japan’s Diplomacy SHEN Hai-tao. pp. 1–8, 2006. ISSN 01636804. 1606.04171.
[5]
Zuniga, J.C. and Ponsard, B.: Sigfox System Description. Ietf 97, p. 9, 2016.
Available at: https://www.ietf.org/proceedings/97/slides/slides-97-lpwan-25-sigfox-system-de
[6]
Meters, P.: Title : Particular Requirements for Prepayment Meters Reference Revision Date
:. 2008.
[7]
Dlms, T.: SANS 62056-9-7 : 2014 IEC 62056-9-7 : 2013 SOUTH AFRICAN NATIONAL
STANDARD Electricity metering data exchange â The DLMS / COSEM suite Part 9-7 :
Communication profile for TCP-UDP / IP networks. 014. 2014. ISBN 9780626303679.
[8]
Bekker, B., Eberhard, A., Gaunt, T. and Marquard, A.: South Africa’s rapid electrification
programme: Policy, institutional, planning, financing and technical innovations. Energy
Policy, vol. 36, no. 8, pp. 3115–3127, 2008. ISSN 03014215.
[9]
Makonese, T., Kimemia, D. and Annegarn, H.: Assessment of free basic electricity and use
of pre-paid meters in South Africa. Proceedings of the 20th Conference on the Domestic Use
of Energy, DUE 2012, 2012.
[10] Tewari, D.D. and Shah, T.: An assessment of South African prepaid electricity experiment,
lessons learned, and their policy implications for developing countries. Energy Policy, vol. 31,
no. 9, pp. 911–927, 2003. ISSN 03014215.
[11] Madhoo, H.: Investigating the value proposition of advanced metering infrastructure in
developed and emerging economies with a focus on South Africa. Core.Ac.Uk, 2015.
Available at: http://wiredspace.wits.ac.za/handle/10539/17716%5Cnhttps://core.ac.uk/download
46
LIST OF REFERENCES
47
[12] SEA: Smart Metering : Overview and Considerations for South African Municipalities. ,
no. July, p. 27, 2015.
[13] S. Feuerhahn, M. Zillgith, C.W. and Wietfeld, C.: Comparison of the Communication Protocols DLMS / COSEM , SML and IEC 61850 for Smart Metering Applications. 2011.
[14] Specification, C.: for Energy Metering Green Book Edition 8 . 3 DLMS / COSEM Architecture and Protocols DLMS User Association. 2018.
Available at: https://www.dlms.com/
[15] DLMS User Association: DLMS / COSEM Architecture and Protocols. pp. 1–101, 2014.
[16] Dlms, T.: SANS 62056-5-3 : 2014 SOUTH AFRICAN NATIONAL STANDARD Electricity metering data exchange â The DLMS / COSEM suite Part 5-3 : DLMS / COSEM
application layer. 014. 2014. ISBN 9780626294175.
[17] August, E.M.: Eskom Experience on AMI Implementation. , no. August, 2011.
[18] Van den Berg, K.N.: The Impact of Advanced Metering Infrastructure (AMI) on African
Electricity Utilities. PIESA Workshop, 2011.
Available at: http://piesa.publishpath.com/Websites/piesa/files/Content/6285146/The_Impact_o
[19] MS Windows NT installation and conversion of split meters in soweto progressing well.
http://www.eskom.co.za/news/Pages/Mayy30B.aspx. Accessed: 2019-08-20.
[20] PamphSandtonMidrand.pdf.
[21] Chen, M., Miao, Y., Hao, Y. and Hwang, K.: Narrow Band Internet of Things. IEEE
Access, vol. 5, no. September 2017, pp. 20557–20577, 2017.
[22] Zayas, A.D. and Merino, P.: The 3GPP NB-IoT system architecture for the Internet of
Things. 2017 IEEE International Conference on Communications Workshops, ICC Workshops 2017, pp. 277–282, 2017.
[23] Mekki, K., Bajic, E., Chaxel, F. and Meyer, F.: A comparative study of LPWAN technologies for large-scale IoT deployment. ICT Express, vol. 5, no. 1, pp. 1–7, 2019.
Available at: https://doi.org/10.1016/j.icte.2017.12.005
[24] Lauridsen, M., Nguyen, H., Vejlgaard, B., Kovacs, I.Z., Mogensen, P. and Sorensen, M.:
Coverage Comparison of GPRS, NB-IoT, LoRa, and SigFox in a 7800 km Area. IEEE
Vehicular Technology Conference, vol. 2017-June, 2017.
[25] Asbery, C.W.: Smart grid communications. p. 64, 2012.
Available at: http://uknowledge.uky.edu/cgi/viewcontent.cgi?article=1009&context=ece_etds
[26] Fialho, V. and Azevedo, F.: Wireless Communication Based on Chirp Signals for LoRa IoT
Devices. i-ETC : ISEL Academic Journal of Electronics Telecommunications and Computers, vol. 4, no. 1, pp. ID–6, 2018. ISSN 2182-4010.