# Future Smart Metering Runs on Open Source –Challenges and the GuruxAMI Project

Mikko Kurunsaari

► To cite this version:

Mikko Kurunsaari. Future Smart Metering Runs on Open Source –Challenges and the GuruxAMI Project. 8th International Conference on Open Source Systems (OSS), Sep 2012, Hammamet, Tunisia. pp.389-394, 10.1007/978-3-642-33442-9_40. hal-01519068

HAL Id: hal-01519068

https://inria.hal.science/hal-01519068

Submitted on 5 May 2017

HAL is a multi-disciplinary open access
archive for the deposit and dissemination of sci-
entific research documents, whether they are pub-
lished or not. The documents may come from
teaching and research institutions in France or
abroad, or from public or private research centers.

L'archive ouverte pluridisciplinaire HAL, est
destinée au dépôt et à la diffusion de documents
scientifiques de niveau recherche, publiés ou non,
émanant des établissements d'enseignement et de
recherche français ou étrangers, des laboratoires
publics ou privés.

<figure><img src="image_1.png" /></figure>

Distributed under a Creative Commons Attribution 4.0 International License
Future Smart Metering Runs on Open
Source –
Challenges and the GuruxAMI Project

Mikko Kurunsaari

Gurux Ltd, Hermiankatu 6-8 H 33720 Tampere, Finland WWW home page:
http://www.gurux.org/

**Abstract.** More and more devices are coming to Internet and organizations are using more devices to measure things. Challenges include a huge amount of different protocols and a risk of technological lock-in. Because of new innovations and demands new protocols are coming out all the time. Increasing amount of protocols makes it harder to collect data from different data sources and save it to one place. If we want to make tailored reports it is important that we can save all collected data to the one place. This paper presents an overview of how the industrial research project GuruxAMI (Gurux Advanced Metering Infrastructure) tries to solve this problem. An overarching goal of the project is to make an open platform that can be used to collect data from different data sources using different protocols and save collected data to the one place. This will be done by developing Open Source platform that can handle different protocols.

# 1 Introduction

Protocols are like languages. There are lots of different protocols and if you speak one protocol other devices that speak other protocols do not understand you. It would be easy to say that we will build one universal protocol and everyone should use it but it is not possible. Demands that are expected from the protocol are changing a lot depending where protocol is used. A sensor has different needs than a paper mill for example. Sensor can measure only one variable and only purpose of it is measure it. From sensors point of view protocol must be very light and simple whereas paper mill can consist of lots of different variables and its protocol can be much bigger and more comprehensive.

The paper presents an overview of the ongoing GuruxAMI (Gurux Advanced Metering Infrastructure) project [1] and summarizes our open source experiences related to the project.
## 2 GuruxAMI Project Details

The goal of GuruxAMI is to offer an open platform that can be used to collect data from various data sources. The basic idea is that multiple protocols can be used simultaneously and more can be added on the fly. Thanks to this idea data can be collected from various data sources and save to one place and make tailored reports etc.

### GuruxAMI

The Purpose of GuruxAMI is to collect data from different data sources and make tailored reports so people can save energy. Basic idea is that if you want to save energy you must know where it is used or otherwise you are saving in wrong place.

Basic idea of GuruxAMI is that we can collect data from the meters using different kind of protocols. GuruxAMI can be used to collect data from other data sources than electricity meters but for the sake of clarity we are talking only them. So there is no need to have multiple concentrators for different meters/manufacturers: DLMS/COSEM, MBus, Modbus, etc. This saves time and money.

Basic difference between “Automatic Meter Reading” and “Advanced Metering Infra-structure” Systems is that AMR reads meters AMI can control them as well. In this moment biggest problems for meter reading are: different protocols and static IP addresses. GuruxAMI can handle both problems. Figure 1 shows the main parts of GuruxAMI.

<figure><img src="image_2.png" /><figcaption>Figure 1. GuruxAMI platform components</figcaption></figure>

### Database server(s)

There is a uniform database where collected data is saved. From collected data is generated all kind of reports. Sometimes collected data is inserted directly to the SAP system.
**Device server(s)**

Device servers collect data from meters. Device servers are also known as data collectors. In this moment they are polling data from the meters. Polling is problem when using GPRS/CDMA connection because concentrators' needs static IP address and this is expensive because mobile phone operators are charging quite a lot from static IP address. Additional some mobile operators do not give static IP addresses for smaller companies.

**Concentrator(s)**

The purpose of concentrator is connecting local meters to the data collecting system. Concentrators can be “dummy” when they only transport data between device server and meters. Problem is if there are lots of different meters. This is usually not a problem in energy utilizations but factories want to use different kind of meters from different manufacturers.

Because there are lots of concentrators without intelligence, data collecting systems must poll meters. This is a big problem is you have lots of meters. First if meters be-hind concentrators are using ex. Power Line Communication (PLC) it is really slow and causes that you must have lots of data collector devices. Second they must use Static IP addresses and this is very expensive.

Our idea is that we replace Concentrators with embedded Linux device where is GuruxAMI inside. In this way there is no need for static IP addresses (or concentrators) because device servers do the collecting work and after data is send they will send data to the database servers.

We are collecting data "on the field" and then we send collected data to the database server. It is faster and cheaper because we can use dynamic IP addresses. Data collector does not make connection to the concentrator and device server. Device server connects to the Database Servers and this makes possible to use dynamic IP addresses. Additionally we can build intelligence to the collector so concentrator does not need send data so often. Basic idea is not to invent concentrator again but to expand it. There are just some cases where plain concentrator is not enough. This is illustrated in Figure 2.

<figure><img src="image_3.png" /><figcaption>**Figure 2.** Data collection using GuruxAMI</figcaption></figure>
## 3 GuruxAMI Project Working

GuruxAMI lies on the Gurux Communication structure. We have developed it more than ten years now. Basic idea is that there is a thin layer where changes are made when protocol changes. All other parts are remaining same. Because of this developing and testing is faster because there is much less work to be done. The structure of GuruxAMI layers is depicted in Figure 3.

<figure><img src="image_4.png" /><figcaption>**Figure 3.** Structure of GuruxAMI layers</figcaption></figure>

### Physical Layer

The physical Layer represents physical device.

### Media Layer

Media layer presents different communication channels, ex. TCP/IP, serial port, USB, etc. Basic idea is that media layer must implement IGXMedia interface. When media implements this interface Media can be changed to the other and there is no need to make any changes. Basic idea of media layer is offer transforming channel that is used to send and receive byte stream.

### Communication layer

Purpose of communication layer is to take care that data is sent and received correctly. Communication layer takes care of resending if packet is lost and it also parses packets from the data stream using Begin and End of Packet markers and checksum.

### Protocol Layer

Purpose of protocol layer is to transform data to the byte stream and vice versa. Protocol layer is the layer that is changed when the protocol is changed. Idea of Protocol Layer is to isolate changes so that there is only a small part of the code that needs to be tested when the protocol is changed.

### Device layer

Purpose of Device layer is to represent all properties that device supports. All properties of device are saved to the xml file, so it can be easily modified for users
needs. Because device's properties are saved to the xml-file it can be used to easily create user depend devices. Example: a developer needs to read much more data from the meter than an ordinary user. Thanks device Layer we can have two different xml-files. One for the developer and one for other users. There is no need to make changes for the actual source code only changing the xml-file will do the trick.

## Application Layer

Application layer is usually User Interface. Basic idea is that if UI is changed rest of the application remains the same. Because of this developing is much faster and it is much faster to implement custom UIs. Gurux's products: GXDeviceEditor, GXDirector and GuruxAMI are relaying this idea. User uses GXDeviceEditor to tell what data is collected from the device. After that user uses GXDirector or GuruxAMI to collect data and visualize it.

We are collecting more and more data from various data sources. Companies are putting lots of money to collect data, but is it worth the cost? Is data used enough? Very easily costs are much higher than the benefits.

<figure><img src="image_5.png" /><figcaption>Figure 3. Data collection and associated costs</figcaption></figure>

The current situation is that costs and efforts on data collecting are high without Value of the data (Figure 3-a). The optimal situation would be that there are no more data collecting investments, but rather the focus should be on data utilization and value (Figure 3-b).

## 3 Why Open Source?

We are receiving lots of questions why we are Open Source Company. Reason for this is quite simple. We believe that we have made something great and if we succeeded GuruxAMI system can be a success story. Our problem was advertising. How a small company from Finland can be known around the world? Problem for software companies in Finland is that we have only 5 Million people and it is very
hard or almost impossible to make software only for local markets. So if Finnish
software companies want to live they must find bigger markets.

We considered this problem for over a year. What to do? How we could let people
to know what we have done? After considering various options, we decided that the
source code is not our most valuable asset.

We have learned a lot from Open Source during these years. One important thing
what we have learned is that in Open Source world there usually is only one king at
the time. We want to be that king of AMI systems.

4 Discussion

We have been Open Source Company over three years now and we are still
learning. I believe that most important thing is publicity. It is very important for
Open Source projects. I believe that biggest problem in Open Source projects is how
people can find you. In internet there are lots of projects and big challenge is how
you get visibility for your project. In picture below is visualized growth of users in
our community. It took very long time from us to start grows, over a year. After we
grow over critical point we started grow faster. I believe that reason for this is people
talk and when they talk it increased people's awareness from us.

<figure><img src="image_6.png" /><figcaption>Figure 4. GuruxAMI community growth</figcaption></figure>

References

1. GuruxAMI. Available at http://www.gurux.fi/index.php?q=AMIIntroduction. Last accessed May 2012.