UNIVERSIDAD DE LOS ANDES

Design and implementation of an AMI

Data Concentrator Unit (DCU) in a

simulated distribution system

by

Jesus Gabriel Angel Imitola

A thesis submitted in partial fulfillment for the

degree of Electronics Engineer

School of Engineering

Department of Electrical and Electronics Engineering

December 2017

Declaration of Authorship

1. I am aware that any fraud in this thesis is considered a serious offense in college.

By signing, deliver and present this proposal Thesis or Graduation Project, I ex-

press testimony that this proposal was developed in accordance with standards

established by the University. Similarly, assure you that I did not participate in

any kind of fraud and at work concepts or ideas that are taken from other sources

are properly expressed.

2. I am aware that the work that I perform include ideas and concepts of the author

and the Advisor and may include course materials or previous work in the Uni-

versity and therefore, give proper credit and I will use this material in accordance

with human rights standards copyright. Likewise, I will not publications, reports,

articles and presentations at conferences, seminars or conferences without review

or authorization of the Counsel who represent in this case the University.

Signed:

Name: Jesus Gabriel Angel

University ID: 201413561

C.C.: 1045745219

Date: December 2017

i

UNIVERSIDAD DE LOS ANDES

Abstract

School of Engineering

Department of Electrical and Electronics Engineering

by Jesus Gabriel Angel Imitola

This project develops an AMI communication framework for GridTeractions, a simula-

tion tool for controlling distribution power systems. There is a current interest worldwide

in developing Smart Grids, but they require an AMI backbone which this project tries

to recreate within a simulation environment. Smart Meter to Data Concentrator Unit

(DCU) communication was implemented using DLMS/COSEM as application layer, as

well as DCU module was created and some adjustments to the tool were done in order to

reproduce the behaviour of AMI in a real scenario. Smart Meter module already defined

was modified to enhance its capability for AMI applications and to simulate behaviour

of a real Smart Meter in order to allow Hardware In the Loop simulations concerning

AMI in GridTeractions.

Acknowledgements

I must first thank to my parents Luis Eduardo Angel and Diana Luz Imitola for giving

me the great opportunity to study at Universidad de los Andes, and for giving me their

full support to continue my studies at any circumstances and difficulties. Thanks for

your trust in me, I am sure this goal encourages you both to keep giving to me and my

brothers your support for achieving our goals.

I also want to express my complete gratitude to every single professor that helped and

instructed me during my formation process as an Electronics Engineer at Uniandes.

They gave me both professional and personal formation so I could become an integral

Engineer prepared for today’s challenges.

I want to thank my project advisor Gustavo Ramos Lopez as well as David Celeita and

Miguel Hernandez for guiding me at every step done to complete this project. Without

their help and guidance this project might have become been much harder. The tips

and suggestions they gave me at every meeting helped me to solve the problems I found

during the development of this project.

Thanks to all my friends, the ones I met during my formation here at Uniandes, as well

as all my friends who are still there supporting me even if I am far away from them.

Thanks to all of you, everyone helped me to finish this project successfully.

iii

Contents

Declaration of Authorship i

Abstract ii

Acknowledgements iii

List of Figures v

Abbreviations vi

1 Introduction 1

2 Objectives 3

2.1 General Objective . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3

2.2 Specific Objectives . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3

3 Foundations 5

3.1 GridTeractions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5

3.2 Current Standards . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8

3.3 Libraries/APIs for Communication . . . . . . . . . . . . . . . . . . . . . . 11

3.4 jDLMS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13

4 Work Done and Results 14

4.1 Inserting jDLMS in GridTeractions . . . . . . . . . . . . . . . . . . . . . . 14

4.2 DCU implementation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16

4.3 Transferring of Smart Meters . . . . . . . . . . . . . . . . . . . . . . . . . 18

5 Discussion and Conclusions 22

Bibliography 24

iv

List of Figures

1.1 AMI possible typical configurations. Taken from [1] . . . . . . . . . . . . . 2

3.1 GridTeractions main architecture. Taken from [2] . . . . . . . . . . . . . . 6

3.2 GridTeractions main window interface . . . . . . . . . . . . . . . . . . . . 6

3.3 GridTeractions: Smart Meters window interface . . . . . . . . . . . . . . . 7

3.4 Various implementations of C12.22 Devices. Taken from [3] . . . . . . . . 9

3.5 Object Model for COSEM server. Taken from [4] . . . . . . . . . . . . . . 11

3.6 Some Interface Classes for COSEM object model. Taken from [4] . . . . . 12

4.1 IEEE 13 Nodes Test Feeder, distribution system used for validation . . . . 15

4.2 DLMS/COSEM addition for smart meters at GT Server . . . . . . . . . . 16

4.3 Validation for jDLMS use in GridTeractions . . . . . . . . . . . . . . . . . 16

4.4 DCU Implementation validation . . . . . . . . . . . . . . . . . . . . . . . 17

4.5 Meter GUI shown in GT Client . . . . . . . . . . . . . . . . . . . . . . . . 19

4.6 Test of meter implemented at GT client from GT Server . . . . . . . . . . 20

4.7 Configuration window for DCUs for meters at GT clients . . . . . . . . . 21

4.8 DCU manager . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21

v

Abbreviations

AMI Advanced Metering Infrastructure

COSEM COmpanion Specification for Energy Metering

DCU Data Concentrator Unit

DLMS Device Language Message Specification

EPRI Electric Power Research Institute

EMS Energy Management System

GIS Geographic Information System

GUI Graphical User Interface

GT GridTeractions

IP Internet Protocol

OBIS OBject Identification System

SCADA Supervisory Control And Data Acquisition

SG Smart Grid

TCP Transport Control Protocol

vi

Chapter 1

Introduction

Electric grids have evolved throughout last decades in order to improve performance,

control and automation of the networks. In the last two decades, there has been much

research about the transition of conventional distribution power systems into smarter

systems thanks to the fast development in communication infrastructure and control

techniques. These smarter distribution networks are the more commonly known as

Smart Grids (SG). However, these SG as stated before, need an advanced communication

infrastructure for the fast and reliable transfer of electrical data and robust control

techniques for the secure operation of the networks.

According to Electric Power Research Institute (EPRI), Advanced Metering Infrastruc-

ture (AMI) is a term born in the last decade, mostly developed by utility industries,

in which a new measurement scheme is integrated into the distribution systems thanks

to fast development of smart meters, which are replacing traditional ones. Neverthe-

less, this new integrated system brings new challenges about optimization of resources,

improvement of power quality and efficiency of the grid. One of the most important

challenges is to setup a reliable and correct communication of every element within AMI

system, since if it does not work correctly, AMI applications may become not feasible.

Figure 1.1 shows different ways of interconnecting AMI elements using different medium

and protocols.

Since AMI is currently in its development phase, we need tools for testing and simulating

its functionality before being installed in real life. However, because AMI architecture is

recently born, work in these areas is scarce and is not fully developed. This project tries

1

Introduction 2

Figure 1.1: AMI possible typical configurations. Taken from [1]

to develop a framework for managing communication between different AMI elements

(e.g. data concentrator units -DCUs- and smart meters) in GridTeractions (GT), a

Java-written simulation tool for controlling and monitoring DSSSim-PC distribution

system simulations. DSSim-PC is a software developed by Power and Energy Group at

Universidad de los Andes that provides a fast design of distribution systems and easy to

use user interface to the simulation distribution systems software OpenDSS. This will

be discussed later for further information.

This project’s main goal is to develop the communication system required for AMI

architecture in Smart Grids. It is desirable to use the developed standards in order to

reach compatibility with real hardware, so Hardware in the Loop (HIL) simulations with

AMI physical elements could be done within GridTeractions. This is helpful because

this AMI interface developed in GridTeractions can be used to test AMI functionality

and more importantly, to test AMI physical devices such as actual smart meters.

Chapter 2

Objectives

2.1 General Objective

Implement AMI communication scheme within the power distribution systems simula-

tion and control software Gridteractions

2.2 Specific Objectives

• Design and implement communication between distributed AMI smart meters with

a Data Concentrator Unit (DCU)

– Protocol selection (IEC 62056, ANSI C12.22)

– Implementation of protocol in AMI GridTeractions Smart Meters

– Validation

• Implement an AMI DCU device compatible with communication protocol selected

– Protocol implementation in the DCU device

– Establish and implement new functions and features into AMI elements (Smart

Meters and DCUs)

– Validation

• Organize AMI GridTeractions elements to fit AMI architecture

– Move Smart Meters module from GT Server to Client

3

Objectives 4

– Set new GridTeractions communication messages to provide binding between

AMI elements in the server and clients

Chapter 3

Foundations

3.1 GridTeractions

Getting started with the GridTeractions software tool was the first step done in this

project. This section is an overview about what is GridTeractions, how it works, and

specially, work done concerning smart meters.

Before discussing about GridTeractions, it is necessary to introduce the DSSim-PC and

OpenDSS software. OpenDSS is a simulation tool developed by EPRI, for analyses

on distribution power systems. It is a powerful simulator, but it lacks Graphical User

Interface (GUI) [5]. DSSim-PC solves this problem by providing a nice user interface

in which the user can create or modify models of the system very easily, compared to

writing long commands in the way it is done in OpenDSS. It uses OpenDSS COM server

interface to run generated DSS models for its operation.

GridTeractions is a Java-written application capable of controlling DSSim-PC simula-

tion variables in real time, such as time step, switches status and load profiles by using a

manager TCP connection with DSSim-PC. In Figure 3.1 it is shown the main architec-

ture of the software and its feature of parallelization of different modules. Each module

usually represents a single power system element or a group of them.

As can be seen in Figure3.1, GridTeractions consists of two different sections: The

main server (GT Server) and some clients (GT Clients) associated with the server. The

server runs a DSSim-PC simulation using the TCP connection mentioned before, which

5

Foundations 6

describes all the distribution system modules. On the other hand, clients can be asso-

ciated with one or more power system elements, such as loads, capacitors and switches

and control variables of their associated elements. However, it has little development on

controlling auxiliary elements such as smart meters.

In Figure 3.2, there is shown the main window for the GUI of GridTeractions Server,

together with all the functions available before the project was started.

Figure 3.1: GridTeractions main architecture. Taken from [2]

Figure 3.2: GridTeractions main window interface

Foundations 7

Smart Meter Module

Smart Meters modules were recently added to GridTeractions. Smart Meters had their

own GUI in GridTeractions, just as shown in Figure 3.3. They had some basic functions,

which were:

• Voltage Monitoring

• Current Monitoring

• Active Power Monitoring

• Energy Register

• Cost Calculator

• Plot of the evolution of the variables throughout time

• Connection/Disconnection temporarily of meters

Figure 3.3: GridTeractions: Smart Meters window interface

Even though smart meters had the main functions for the end user or customer, they

were standalone elements which did not provide any functionality to the power system

Foundations 8

operator. That was why it was needed to design the AMI architecture and develop AMI

functions for the smart meters. As shown in Figure 1.1, there are 3 possible typical

configurations for AMI topology, 2 of which use DCUs as standalone elements indepen-

dent to MDMS. Our goal here is to integrate the Smart Meters-DCU communication

interface into GridTeractions for the Smart Meter Modules already implemented.

3.2 Current Standards

There are two main standards currently in development and use, which are the ANSI

C12 Suite and DLMS/COSEM. Both will be discussed in the following sections

ANSI C12 Suite

This is the American Standard made by ANSI/IEEE for configuration of communication

of Smart Meters.

ANSI C12 Suite is made up by the following standards:

• ANSI C12.18: is the first protocol for communication in utility metering. It gives

specification for communication through optical port.

• ANSI C12.19: is the standard specification for utility tables. These tables are the

common data structures that meters should have when communicating with this

protocol suite.

• ANSI C12.21: offers C12.18 devices communication through telephone modem

instead of direct optical port. Although this offers to C12.19 a wider variation of

the lower layers protocols than C12.18, it is still limited to telephone networks.

• ANSI C12.22: is a standard that provides communication for AMI devices over any

communication network. It uses ANSI C12.19 for specification of data structures

as well, and is the closest approach to AMI architecture of this suite.

ANSI C12.18, C12.21 and C12.22 devices, all provide basic services for the C12.19 tables

to allow proper communication between devices or elements. These services include the

Foundations 9

READ and WRITE services as minimum requirement for using C12.19 specification.

These services allow elements to send or retrieve data between two of them. In order

to allow scalability in these AMI systems, specially in C12.22 networks (communication

networks for C12.22 devices), backward compatibility is necessary. That is why C12.22

offers wide solutions for communicating C12.18 devices with the C12.22 network and

devices, as shown in Figure 3.4. In [6] there are more specifications about ANSI C12.22,

its use in AMI architecture and C12.22 device implementations. RFC 6142 discusses

a specific implementation of C12.22 over an IP network, by using either TCP or UDP

transport protocol on port 1153, assigned by IANA in order to make easier compatibility

between C12.22 devices.

Figure 3.4: Various implementations of C12.22 Devices. Taken from [3]

IEC 62056

Also known as DLMS/COSEM, this standard is the most used worldwide for its ease

of use and because research and development on smart meters and AMI architecture

started using this standard. It is a growing standard. DLMS stands for Device Lan-

guage Message Specification, while COSEM means COmpanion Specification for Energy

Metering

DLMS/COSEM is completely specified in color books, as follows:

• Blue Book describes the COSEM meter object model and the object identification

system

• Green book describes the architecture and protocols to transport the model

• Yellow book describes the conformance testing process

Foundations 10

• White book holds the Glossary of DLMS/COSEM terms [7]

As will be mentioned later, library chosen for implementing AMI communication link

between smart meters and DCUs within GridTeractions uses this standard, specifically

the Blue Book. That is why it is relevant to briefly introduce to this part of the DLM-

S/COSEM standard.

DLMS/COSEM Blue Book

The Blue Book is equivalent to IEC 62056-1 and IEC 62056-2 together. One of the parts

of the Blue Book[4] deals with the COSEM OBject Identification System(OBIS). This

section of the book it is specified the OBIS code associated with each object. An OBIS

code is a 6-byte identification for objects and it is usually expressed by separating points

in decimal notation: A.B.C.D.E.F. Hence, to allow compatibility between devices, this

part of the Blue Book indicates where each variable in meter should point, independently

from the manufacturer or meter model. For example, according to the Blue Book a

logical device name is stored in a Data object with OBIS code or address 0.0.42.0.0.255.

A full official and updated specification for OBIS code can be found in [8].

In Figure 3.5 it is shown the main configuration of objects within a smart meter (physical

device). From the Figure, OBIS model is specified as follows: each physical device may

have many logical devices, each associated with some dependency or area measured. A

logical device holds objects for every OBIS referenced item of the standard, even if they

are not being used or have no meaning in that particular logical device. So in order to

reference some object of a Smart Meter, one must first establish a physical connection

with the meter, then associate with the logical device which one wants to connect and

finally reference the object using their associated OBIS code according to the Blue Book.

The second main objective of the Blue Book is to specify the Interface Classes (an

Interface Class defines data structures and methods) and data formats that can be

associated with each element within the smart meter. There are many Interface Classes

defined in the standard as well as some data formats, such as Date and Time formats. In

Figure 3.6 there are shown some of the Interface Classes defined in the Blue Book. Each

Interface Class has Object instances, which are for example: Instantaneous Voltage,

Average Power, Max Frequency, Min Current and so on. Each of these instances has

Foundations 11

Figure 3.5: Object Model for COSEM server. Taken from [4]

its own OBIS Code for referencing it. However, due to the scope of this project, only

Register and Extended Register Interface Classes were instantiated for data storage and

some other Interfaces Classes that were already in use in the library selected.

3.3 Libraries/APIs for Communication

Due to the complexity of the standards, it was necessary to search for an open-source

library that implements of the two main standards for AMI architecture mentioned in

last section, ANSI C12.22 and DLMS/COSEM (IEC 62056) in Java, C, C++, Python

or another programming language. There were found the following APIs for AMI com-

munication between smart meters and DCUs.

ANSI C12.22

For implementations of ANSI C12.22 there was found the jc12 library for Java[9], but

repository was out of date and no library could be retrieved. No further libraries were

found for C12.22. Two ANSI C12.18 libraries were found in Python: optiguard[10] and

termineter[11], but they had no support for C12.22, which is desirable for GridTerac-

tions, since no physical optical port is available during simulation.

Foundations 12

Figure 3.6: Some Interface Classes for COSEM object model. Taken from [4]

DLMS/COSEM

For DLMS/COSEM standard, there were found two main open-source libraries: jDLMS[12]

for Java and GuruxDLMS[13] which has multiple language and platform support. jDLMS

was chosen over GuruxDLMS after testing both libraries due to its ease of use and com-

patibility with Java used in GridTeractions.

Foundations 13

3.4 jDLMS

jDLMS is a well-documented library for Java. In [12] there is a complete user guide

for the basics of using the library and DLMS/COSEM specification. The library mainly

implements functions of the Blue Book for DLMS over a TCP/IP connection. It means it

provides some specifications about the data structures in meter and several OBIS codes

referencing to their objects. jDLMS has support for the minimum required Interface

Classes for defining a DLMS device, so user-defined classes need to be created for specific

applications(RegisterClass and ExtendedRegisterClass were defined in this project). In

the library there are only a few well-known OBIS codes with their respective objects

associated, so to pursue the project objectives, new OBIS codes had to be defined for

the electricity meter, in order to set the corresponding references to measurements for

electricity variables according to the OBIS codes established by the Blue Book, such as

voltages, powers and currents.

Chapter 4

Work Done and Results

This chapter discusses the various steps that have been followed by the current project.

It includes: Merging GridTeractions with the selected library jDLMS, DCU module

implementation compatible with jDLMS, implementation of new AMI functions, trans-

ferring smart meter module from GT Server to GT Client, and finally introducing some

new messages into GridTeractions internal communication protocol to enhance support

of AMI. It is important to claim that familiarization with GridTeractions, search for

current available standards for communication, search and selection of libraries or APIs

implementing communication between AMI elements, and further use of the jDLMS li-

brary were tasks done during this project, but they were mentioned in the Foundations

chapter, so it is not relevant to recall them again.

All validations done for each step in this methodology were done by using the IEEE

13 Nodes Test Feeder that is available in DSSim-PC and OpenDSS software. The one

line diagram for this power distribution system is shown in Figure 4.1. For further

information about this test distribution power system, see [14]

4.1 Inserting jDLMS in GridTeractions

Implementation

The jDLMS incorporation into GridTeractions was done by using the sample client and

server code given in the library and adapting it to append them into existing Smart

14

Work Done and Results 15

Figure 4.1: IEEE 13 Nodes Test Feeder, distribution system used for validation

Meter modules. This step done is shown in the highlighted part of Figure 4.2 which

was added by this project in order to validate results. A user can request an OBIS

code referenced object specified by the DLMS/COSEM standard and the Java console

outputs the requested value. For every meter, a jDLMS server was set, connected via

TCP/IP, with associated port range from 27400 to 27600, allowing 200 smart meters

to be defined with their corresponding jDLMS server. However, at this point meters

were in the GT Server, and it does not represent a realistic scenario to insert DCUs for

collecting data when data comes from GT Server and is sent to GT Server.

Validation

In Figure 4.3 there is a validation of the functionality of the DLMS/COSEM incor-

poration for Smart Meters. An Instantaneous Voltage for Phase A (1.0.32.7.0.255) is

requested to the ’Load2’ meter. The command line shows the requested value and it

equals the shown in the plot of voltage.

Note that even though jDLMS supports security for communications, no security was

used in order to make an easier implementation of the communication.

Work Done and Results 16

Figure 4.2: DLMS/COSEM addition for smart meters at GT Server

Figure 4.3: Validation for jDLMS use in GridTeractions

4.2 DCU implementation

So once jDLMS was merged with GT, the next goal was to implement a DCU which uses

the already established DLMS/COSEM communication interface for retrieving data at

meters. It was done by establishing a TCP connection with each one of the jDLMS

Work Done and Results 17

servers associated with the related meters, and its validation is shown in Figure 4.4. As

can be seen, DCUs are defined within GT as an object which gets data from some meters

and get some measurements by using their corresponding Obis codes. The tests done

retrieve all data queried by testing them one by one, as shown in the console of Figure

4.4. However, the same problem of the first step stills: it was taking data from smart

meters at GT Server for retrieving it to a DCU implemented in the same GT Server,

which is a not real scenario of an AMI architecture.

Figure 4.4: DCU Implementation validation

With DCU already implemented, it was more clear which extra functions the meters

should have. One of them was the storage of Geographic Information System (GIS)

data within the meter. The most basic GIS data was added for the meter, which is

geolocation given by latitude and longitude, as well as setting DLMS/COSEM to let this

data be retrieved from other COSEM devices. Since there is currently no information

about this the storage of this type of GIS data in the standard, a manufacturer specific

OBIS code was picken for referencing the corresponding object.

Another function that could be helpful when using AMI architecture would be us-

ing time stamps for measurements, since many algorithms and processes done by the

SCADA/EMS require this information in order to operate correctly. For this reason,

this information was added into smart meters and a transition from COSEM Register

objects to Extended Registers objects was done to allow DCUs retrieve this data from

smart meters.

Work Done and Results 18

4.3 Transferring of Smart Meters

Smart meters transfer from GT Server to GT Client

As previously mentioned, in order to keep more realistic scenarios, a transfer from GT

Server to Client was necessary to be done for the Smart Meters module, so this was the

next step done to achieve the AMI architecture insertion into GT. By doing this change,

some new tasks were needed in order to keep AMI capabilities able to use within GT.

One extra benefit of transferring smart meters to GT clients was to allow support for

more than 200 smart meters constrained by the port range used by jDLMS servers, since

jDLMS servers are now distributed in the GT Clients with the smart meters.

Smart meters must now be defined only when associating a load to a client (see [2]).

Since GT Clients are intended to be run from Raspberry Pi’s due to their cost and

performance relation [2], GUI associated with smart meters should be modified in order

to fit into 7 inch, 800x480 resolution screen equipped with the Raspberry Pi’s. For this

reason, the final GUI for smart meters implemented in GT clients was changed and it

is shown in Figure 4.5.

So the final GUI shows voltage, power and energy plots like the original one, port

associated to the jDLMS server used by meter, cost of energy at current time, time and

geolocation data, used by GIS. It also allows the user to connect or disconnect meter

from the client, change time step of plots, change the cost profile (for economic analyses)

and change data for latitude and longitude.

Test of GT Clients’ smart meters

With smart meters now being in GT clients, the GT Server has little knowledge about

the meters, even information about whether they are active or not. That is why testing

DLMS/COSEM was a little harder than before. In Figure 4.6 there is shown the GUI

for testing the meters implemented at GT clients next to a test case. The test case tries

to retrieve instantaneous current for phase 1 from meter, with its corresponding time

stamp. As it can be seen, it gets both attributes, but the time stamp is unreadable, since

it must be sent as an octet string when using DLMS/COSEM. That is why a COSEM

Work Done and Results 19

Figure 4.5: Meter GUI shown in GT Client

Date-Time interpreter is needed at every DCU in order to get meaningful time stamps

information.

DCU for GT Clients’ smart meters

Now it is necessary to implement DCUs for the new scheme of smart meters when they

were transferred to GT Clients. Since the GT Server should have the Metering Data

Management System (MDMS) but does not have knowledge from smart meters at GT

Client as mentioned before, there are two possible approaches for setting up a DCU at

server. First one is to associate meters in the same way tests were done. However, this

process is exhausting for simulation users even for a simple simulation containing AMI

elements, specially if the AMI network is quite large, since users has to type in every

IP address and ports for each meter connection. For this reason, GT messaging system

for GT Clients and server was modified in order to allow exchange of AMI configuration

information between GT Clients and GT Server, for example, send data to GT Server

about meters connected at each GT Client.

DCUs can be configured in the GT server, using a GUI interface similar to the one used

when meters were at server, as shown in Figure 4.7. By using the modified GT messaging

system for exchanging AMI configuration data, all meters available at GT Clients are

automatically displayed at this window, rather than configuring them manually. Since

Work Done and Results 20

Figure 4.6: Test of meter implemented at GT client from GT Server

there are typically several DCUs per system, a DCU manager for modifying and visualize

DCUs is available at GT server, as shown in Figure 4.8

Work Done and Results 21

Figure 4.7: Configuration window for DCUs for meters at GT clients

Figure 4.8: DCU manager

Chapter 5

Discussion and Conclusions

In this project AMI architecture was implemented inside the distribution systems sim-

ulation tool GridTeractions. This covered all concerning communication between AMI

elements, specially meters and DCUs. The IEC 62056 or DLMS/COSEM was selected

as the standard for defining the communication framework used by the AMI network.

A full implementation of the DLMS/COSEM within GridTeractions was done thanks to

the use of the jDLMS library.

Note that according to Figure 1.1, there are three ways of connecting smart meters to

MDMS. In this project only the third way of connection was implemented, where DCUs

are inside the MDMS, due to the scope of the project. However, basic architecture is

provided and only a DCU transfer from server to client is needed to enhance support to

all three main ways of connecting smart meters according to [1].

Although the jDLMS offers the capability to use a secure DLMS/COSEM connection,

for simulation purposes it is not strictly necessary. However if the impact of a secure

DLMS/COSEM network needs to be evaluated, it is still needed to add security features

to the protocol, which are available already in the library.

For further projects concerning AMI, here are some work that can be done after this

project was finished:

• Enable HIL simulations using real smart meters. Validate DLMS/COSEM com-

munication interface.

22

Discussion and Conclusions 23

• Transfer DCUs from GT Server to GT Clients, allowing different communication

schemes to be available.

• If HIL simulations are available, add security to DLMS/COSEM communication.

• Create a model for MDMS which collects the data from DCUs. If it is desired to

keep AMI model as real as possible, implement communication according to [1]

• Create GUI for visualizing results obtained by MDMS or DCUs

• Any AMI application

Even though the list of work stated before is long, there are even more work that can

be done with AMI communication framework available at GridTeractions. Remember

that since AMI is currently in development, some new applications and research can be

done in this area.

Bibliography

[1] G. Lopez, et al., Paving the road toward Smart Grids through large-scale advanced

metering infrastructures, Electr. Power Syst. Res. (2014), http://dx.doi.org/10.

1016/j.epsr.2014.05.006.

[2] C. A. Trujillo, C. C. Zambrano, G. A. Ramos, and F. E. Segura. Gridteractions :

simulation platform to interact with distribution systems, 2016.

[3] IEEE. IEEE Standard for Local Area Network/Wide Area Network (LAN/WAN)

Node Communication Protocol to Complement the Utility Industry End Device

Data Tables. IEEE Std 1703-2012, pages 1–239, June 2012. doi: 10.1109/IEEESTD.

2012.6226334.

[4] DLMS UA 1000-1 Ed. 12.2 2017-01-19, COSEM Interface Classes and OBIS Object

Identification System ”Blue Book”.

[5] Electric Power Research Institute EPRI. Smart Grid Resource Center: OpenDSS.

http://smartgrid.epri.com/SimulationTool.aspx.

[6] EPRI. A Review of ANSI C12.22. December 2008.

[7] DLMS User Association. OVERVIEW / EXCERPTS OF THE

DLMS UA COLOURED BOOKS. http://dlms.com/documentation/

overviewexcerptsofthedlmsuacolouredbooks/index.html, .

[8] DLMS User Association. LIST OF STANDARD OBIS CODES

AND COSEM OBJECTS. http://www.dlms.com/documentation/

listofstandardobiscodesandmaintenanceproces/index.html, .

[9] OpenHub. Java ANSI C12 library. https://www.openhub.net/p/jc12.

24

Bibliography 25

[10] InGuardians. Optiguard. https://github.com/inguardians/optiguard/tree/

master/docs.

[11] S. McIntyre. Termineter. https://github.com/securestate/termineter.

[12] OpenMUC. jDLMS User Guide. https://www.openmuc.org/dlms-cosem/

user-guide/.

[13] Gurux. GuruxDLMS. http://www.gurux.fi/Gurux.DLMS.

[14] IEEE PES. Distribution Test Feeders. http://www.ewh.ieee.org/soc/pes/

dsacom/testfeeders/index.html.