Portable and Flexible Communication Protocol Stacks for Smart Metering Projects

Axel Sikora

1.Introduction

Efficient,low-cost,secure,and reliable communication solutions are a major stepping stone for smart metering and smart grid applications[1].This especially holds true for the so called primary communication or local metrological network(LMN)between a local meter or actuator and a data collector or gateway[2].The automatic meter reading(AMR)has the potential to become the first machine-tomachine-(M2M)application with really large-scale multivendor installations[3],[4].

Wireless M-Bus according to EN-13757-4[5]is a major contender for LMNs in smart metering and smart grid applications,as it holds the promise of flexible and optimized solutions.It enjoys wide popularity in continental Europe,but increasingly in many other regions of the world.However,Wireless M-Bus is characterized by a wide variety of different operation modes(C-,D,F-,N-,P-,Q-,S-,and T-modes),which work in different frequency bands(i.e.868 MHz,433 MHz,and 169 MHz).Its application layer can be enhanced by extensions,being defined from vendor alliances,like the Open Metering System(OMS)Group,or from national bodies[6]–[8].

This paper is structured as follows:Section 2 gives an overview on the different modes and flavors of the Wireless M-Bus standard.Section 3 describes the state-of-the-art of the research and development activities around Wireless MBus.Section 4 briefly elaborates on the major projects that the author’s teams are involved in and which are the background of the ongoing activities.Section 5 describes the required elements for an efficient implementation of a Wireless M-Bus protocol stack,including test,verification,and simulation.The most important tools for commissioning and monitoring of the developed solutions are presented in Section 6.Finally,an outlook on the next steps is given.

2.Wireless M-Bus and Its Derivatives

2.1 Background

The Meter Bus(M-Bus)is a specialized field bus for transmission of metering data from gas,heat,water or other meters.Several meter devices send their data to a data collector,which saves and forwards data to a local display or to a backend system of an energy utility.The data collector may be installed at a fixed location.It may also be used as mobile reading out unit.So an employee of the energy utility may walk or drive through the streets and collect the current energy data from each household for billing.

2.2 M-Bus Layer Stack

The different versions of M-Bus are specified by the European Standard EN-13757,which is worked out by TC294 at CEN/CENELEC.The EN-13757 is divided into the six parts(see Table 1).The M-Bus standard describes physical and data link layers as well as the application layer to enable vendor-independent interoperability.

EN-13757 describes different communication schemes(the so-called modes)for unidirectional and bidirectional data flow.Table 2 shows the dazzling variety of options.Anyhow,the different modes allow an optimized fit to the different requirements of different markets,regions,and topologies.However,the variety also calls for a wellstructured and modular software architecture(Section 5).

2.3 Derivatives

As the early versions of the Wireless M-Bus protocol had only insufficient support for commissioning and full application interoperability,space was left for extensions on the application layer.Dutch Smart Meter Requirements(DSMR)and the OMS are the most prominent examples for these extensions,which fit into the general stack according to Fig.1.Especially,the OMS Group is developing a quite complete ecosystem,which includes testing and certification support.However,it also leaves some space for neighbouring activities.

Table 1.EN-13757―Communication systems for meters and remote reading of meters[5]

Fig.1.Stack overview of Wireless M-Bus

Table 2:Operating modes of Wireless M-Bus

3.State-of-the-Art

3.1 M-Bus Layer Stack

A good number of implementations exist for the Wireless M-Bus protocol stack.Many of them,coming directly from module manufacturers,are closely linked to the specific hardware,and therefore do not need this high degree of modularity and portability.In contrast to those solutions,the teams of the author want to provide a portable and flexible solution,which potentially can be directly integrated into a single chip system solution together with customer specific functionality.

In comparison with its brother ZigBee,which has found broad reception also in the research community,Wireless M-Bus has not succeeded in receiving this attention from scientific world,yet.Consequently,most of the developments are directly product related,use neither new design approaches nor new paradigms,and are neither experimental nor future-oriented.

3.2 Silicon Support

The different Wireless M-Bus modes mainly use FSK(frequency shift keying)modulation.Its characteristics are within the specifications of many proprietary RF-transceiver ICs from various silicon manufacturers.Whereas a broad multitude of devices is able to support the 868 MHz specifications,only recent product launches meet the specifications for 169 MHz N-mode.

The control of the various RF-transceivers mainly poses the following challenges,which are reflected in the solutions from Subsection 5.4.

· The interfaces to the transceiver ICs from different vendors and different generations may have many variations.

· Some of the coding schemes of the different Wireless M-Bus modes(e.g.,the 3-out-of-6- and the Manchestercodes)are not supported by all transceiver ICs,and then have to be emulated on the microcontroller.

· Some of the preamble schemes of the different Wireless M-Bus modes(e.g.,18 bit synchronization word)are not supported by all transceiver ICs,and then have to be emulated on the microcontroller.

· Partial AES(advanced encryption standard)encryption gets no hardware support by many transceiver ICs and has also to be executed on the microcontroller.

· Earlier Wireless M-Bus versions allow very large frequency tolerances,which are significantly beyond the specifications of many transceiver ICs.Consequently,software or hardware based workaround must be provided.

Fig.2.Wireless M-Bus compatible RF-modules.

4.Projects Background

4.1 General Overview

The teams of the authors are active in a broad variety of projects on both the research and development level.We have developed an own Wireless M-Bus stack with the advantages of modern design and software engineering techniques.Our stack has been licensed and applied in a variety of projects together with meter manufacturers and silicon providers.In addition,publicly funded academic projects help to investigate in future solutions.

4.2 DEMAX

The research project DEMAX(decentralized energy and network management using flexible energy prices)was partially supported from the German Federal Ministry of Economics and Technology(BMWi).Its target is the distributed measurement and control of energy consumption at the individual household level.For this,legacy tertiary communication techniques are used for the data exchange between premises and energy providers.For the in-house primary communication,the basic Wireless M-Bus protocol stack was developed to read out data from various metering devices like water,gas,heat,electricity and alike.In addition,the first field-proven tooling was developed.

4.3 ME3GAS

ME3GAS is the acronym for the full project title “smart gas meters & middleware for energy efficient embedded services”.The objective of the ME3GAS project is to put consumers in control of their energy efficiency and appliances at home.This goal follows the European Directives,which emphasize to share metering information so that customers have full visibility on the consumptions and their energy-saving usage without compromising comfort or convenience.

In this context,the ME3GAS project addresses the development of a new generation of smart gas meters,based on embedded electronics,communications and the remote management of a shut-off valve,which shall offer a whole range of added values:management of multiple tariffs and payment modalities,remote gas cut off,security alarms,absolute index,temperature correction,and alike.Specification,implementation,and dissemination of an open architecture for wireless communication are also addressed.

In order to hide the complexity of the underlying device and communications technologies for application developers and to raise the level of programming abstraction to a web services layer,the ME3GAS platform provides the necessary functionality and tools to add energy efficiency features to device networks.ME3GAS will only have commercial and residential relevance if it is successful in saving energy and cost in real-world applications.

ME3GAS uses real-time energy information as energy-awareness services for all residents and combines household specific services with a community portal.This will enable collective/community activities to motivate positive competition in saving energy,complemented by courses on towards the education on energy efficiency,sustainability,and clarification of complicated legislation aspects.

It has to be remarked that ME3GAS shall also contribute to the standardization work being carried out currently in Europe in the smart metering field,mainly under the M/441 mandate of the EC.

More details on the ME3GAS project can be found at http://www.me3gas.eu.

4.4 WiMBex

The aim of the WiMBex project(remote wireless water meter reading solution based on the EN-13757 standard,providing high autonomy,interoperability and range,http://www.wimbex.com)is to add a powerful new set of new features to the Wireless M-Bus platforms developed by the SME(small & medium size enterprises)consortium,to enable them to keep pace,and even to surpass the needs of the emergent automatic water meter reading(AWMR)market in Europe.

WiMBex shall exploit the powerful new features of the P- and Q-mode of the Wireless M-Bus standard,and in this manner,extend the use and impact of the European standard.By introducing the new network Q-mode protocol,which enables precise network time synchronization,the high-power requirements typically associated with multi-hop wireless networks can be significantly reduced by a TDMA(time division multiple access)MAC(media access control)protocol and an efficient energy-aware routing protocol.Energy aware routing protocols have been developed by the research community over the past decade,and have proven to be effective in large-scale network deployments.The metrics for the proposed energy-aware routing protocol are based not only on the legacy parameters like link quality and hop count,but take into account also energy-related parameters of the intermediate nodes.The specification includes at least three parameters,i.e.,node residual energy,energy replenishment rate,and activity rate.Thus,fairness in the way that energy is consumed across the network is introduced when determining optimal routing schedules.

Some more details of the WiMBex project are described in [7],[8]and at http://www.wimbex.com.

5.Elements of the Embedded Software Engineering

5.1 Introduction

This section describes some of the key elements of the software engineering process applied for the design of the embedded software.Many of these technologies and approaches are widely used in standard software engineering,but up to now have found only limited applications in embedded software design.This is all the more valid in those cases where software of very cost- efficient implementation with regard to memory footprint,processing performance,and energy efficiency shall be implemented.However,the experience from the above projects shows that these objectives can be reached,while still supporting the high efficiency of a modern design flow.

5.2 Requirements Analysis

The design flow starts with a detailed requirement analysis,where all aspects of the standard and customer specific requirements are explicitly listed.Table 3 shows an example for this translation,which has been performed for the P-mode of Wireless M-Bus.

5.3 Model Driven Design

Based on the overall text-driven requirements specification,a full model driven design flow is executed,where models exclusively are described by using UML2.4.1 and start with sequence diagrams(Fig.3).From there,a finite-state machine driven design is pursued,which leads to the design of the corresponding state machines(Fig.4).These state machines are not restricted to the mere functionality,but also include a systematic set of error handling,time-outs,and alike.As nearly always,the largest portion of complexity does not come from the pure functionality,but from all these different measures to support stability.

5.4 Platform Selection

The platform selection includes the elements exemp- lified in Fig.3 for the projects mentioned in Section 4:

· The basic OS-(operating system)vs.non-OS- decision was answered with either native C,with a software architecture in Fig.5 or with TinyOS as an event-driven OS-platform.In the latter case,coding is done in NesC.

· The microcontroller selection shows a broad range from energy-efficient 16- and 32-Bit platforms.

· The transceivers can be selected from a variety of standard products,as discussed in Section 3.2.

· One special case is the usage of single-chip solutions,which integrate MCU and transceiver into one system-on-chip(SOC)device,like the CC430.

· Another very specific case comes from the consistent usage of the developed firmware not only for the real hardware implementation,but also for the simulation environments from Subsection 5.6.

Table 3.Sample requirement specification of data link layer of Wireless M-Bus P-mode,as performed for the WiMBex project(cf.Subsection 4.4); references in the table are related to the full requirements document,M stands for mandatory

Fig.3.Platform selection for Wireless M-Bus projects.

Fig.4.UML sequence diagram for direct and routed communication flow of the P-mode of Wireless M-Bus.

Fig.5.UML state diagram for receive process of the P-mode of Wireless M-Bus.

The software architecture has to cover the multitude of operation modes from Table 2 and the multitude of the platforms from Fig.3.It therefore supports a very modular approach,shown in Fig.6 and Fig.7.

5.5 Test and Verification

Four elements support a well-defined and comfortable automatic test environment,which efficiently also support regression testing throughout the complete software engineering process.

· Unit test provides the lowest level and guarantees the functioning of the individual modules.

· The second level is provided by a PC-based software,which verifies the correct and stable functionality of each communication node.

Fig.6.Software architecture for flexible platform selection for Wireless M-Bus projects.

Fig.7.Functional split for flexible platform selection for Wireless M-Bus projects.

· A network emulator provides the third level of the test environment.This emulator was originally proposed by Ringwald et al.[9],but significantly enhanced with regard to automatic and web-based control.It is shown in Fig.8 and interconnects the nodes with RF-wave guides,splitter-combiner,and attenuation elements.These elements are remotely controlled by microcontrollers,so that arbitrary network topologies and coexistence scenarios can be generated and reproduced,and full network tests can be performed.

· The final step is the interoperability test against the third party devices.The OMS Group[8]has recently launched the first element of a standardized interoperability test-suite.Before,each provider ran his own test-suite.

5.6 Simulation

The use of network simulations offers several benefits for the development,the prediction of the suitability and the parameterization of a network.The main objectives of simulations are as follows.

· To provide an early and comfortable development environment that behaves close to the later target system.Since the development and production of target hardware may be time consuming and costly,a simulation environment with abstracted hardware opens the possibility to start an early implementation and verification of concepts.

· A better observability of the internal behavior,since processes are reproducible and can be analyzed in detail.This also helps to get to know the system.Especially in cases of errors or incorrect behavior,this offers a practical starting point for debugging and problem solving.

· A better controllability and reproducibility of processes.

· Evaluation and prediction of the behavior of large network topologies at low efforts.The results of a simulation might help to indicate eventual bottlenecks or risks of the system and to improve its performance.

In simulations,a variety of scenarios can easily be executed.Therefore,an automated simulation environment was developed to support the selection the scenarios as well as the easy parameterization of the participating models via a user interface.A further benefit of the environment is the filtering and preparation of the simulation output for a presentation according to the chosen output parameters.

The simulation environment was created with a set of Matlab functions and scripts.For the simulation,engine OPNET modeler is used.

It has to be highlighted that the identical code can be used for the embedded firmware and the simulation models.Only the hardware abstraction layer(HAL)and the RF drivers need to be adapted for the integration into the OPNET simulation engine.The core stack implementation remains completely unchanged,since it does not contain any platform-dependent directives.For convenience,an API(application program interface)selection layer was added to automatically select scenarios and protocols from the simulation environment.

Fig.9 shows the node architecture of a Wireless M-Bus stack with the required adaptations for the use in a network simulator.More details on the simulation setup and some results can be found in [10].For the TinyOS based implementation,the firmware functionality can be simulated in the open-source OMNET++ using NesCT.

Fig.8.Physical test bed for automated verification of routing mechanisms.

Fig.9.Node architecture of a Wireless M-Bus stack adapted for the use in a network simulator.

Fig.10.Wireless M-Bus suite for commissioning,parameterization,and testing purposes.

6.Tools

6.1 Commissioning

A Java-based fat-client was developed for the parameterization of the nodes,for the commissioning of network,and also for the execution of the functional tests(cf.Subsection 5.5).A screenshot of this tool is shown in Fig.10.

6.2 Monitoring

For the monitoring of the spatially distributed networks,a gateway and sniffer platform was developed to provide a direct and bidirectional access to the wireless nodes.This web server based platform supports long-term monitoring with or without online connectivity.Remote access is provided via wide-area networks(WAN),i.e.GPRS,WLAN or Ethernet.A client computer accesses the input from the management nodes.As management traffic is pure HTTP and XML,there is only a single requirement to the client computer:It shall be capable to run a JavaScript enabled web client.Tests were performed with PC platforms,but also with portable communication devices,i.e.smart phones.

A dedicated hardware platform was developed,as shown in Fig.11.Interfaces to wireless modules allow the access to the wireless network.

The software architecture illustrated in Fig.12 is described as follows.

· The heart is an embedded web server from the author’s team.

Fig.11.PCB for gateway platform.

Fig.12.Embedded web2.0 web server in radio networks.

· A serial handler reads and writes the data to the wireless modules.

· The web server software gains the access to these telegrams via an exposed API,which allows for retrieval of specific telegrams as well as initialization of the buffers and deletion of the content.

· The data is retrieved from a web-client via HTTP,whereas the whole web page including the Java Script Libs has to be downloaded at the first run,after that it is only the XML-Feeds that follow.Thus,the communication channel can be kept very lean.It should be highlighted that all functionality is performed on the client,i.e.display,sorting,filtering,and storing.

It is also well possible to access the data within an M2M-architecture.Then,an automated HTTP-client retrieves the data from the distributed web servers and stores it in a backend database.

7.Outlook

Further activities of the authors’ team are mainly directed towards the following topics:

· Integration of security solutions,as they are anticipated by BSI(Federal Office of Security in Information Technology),into the Wireless M-Bus stack and the gateway solution,in order to secure a very vulnerable part of the infrastructure against cyberattacks[9];

· Involvement of harmonization between currently heterogeneous solutions on application level and management level;

· Support of middleware solutions for efficient operation of heterogeneous and horizontally integrated networks.

[1]R.Abe,H.Taoka,and D.McQuilkin,“Digital grid:communicative electrical grids of the future,” IEEE Trans.on Smart Grid,vol.2,no.2,pp.399–410,2011.

[2]R.Padil,“A best fit for ‘short haul communication protocol’in smart metering,” presented at Embedded World Conf.,Nuremberg,2012.

[3]G.Wu,S.Talwar,K.Johnsson,N.Himayat,and K.D.Johnson,“M2M:from mobile to embedded internet,” IEEE Communications Magazine,vol.49,no.4,pp.36–43,2011.

[4]Internet of Things in 2020,Commission of the European communities,EpoSS,Brussels,2008.

[5]Communication systems for meters and remote reading of meters,Part 1:Data exchange,EN 13757-1,2002; Part 2:Physical and link layer,EN 13757-2,2004; Part 3:Dedicated application layer,EN 13757-3,2004; Part 4:Wireless meter readout(Radio meter reading for operation in the 868 MHz to 870 MHz SRD band),EN 13757-4,2005 Part 5:Wireless Relaying,EN 13757-5,2009; Part 6:Local Bus,EN 13757-6,2009.

[6]A.Sikora and K.Landwehr,“Communication solutions for smart gas meters and energy efficient embedded services,”presented at Embedded World Conf.,Nuremberg,2012.

[7]A.Sikora,P.Villalonga,and K.Landwehr,“Extensions to wireless m-bus protocol for smart metering and smart grid application,” in Proc.of Int.Conf.on Advances in Computing,Communications,and Informatics,Chennai,2012,pp.399–404.

[8]A.Sikora,P.Digeser,M.Klemm,M.Tubolino,and R.Werner,“Model based development of a TinyOS-based Wireless M-Bus implementation,” in Proc.of 1st IEEE Int.Symposium on Wireless Systems within the Conf.on Intelligent Data Acquisition and Advanced Computing Systems,Offenburg,2012,pp.91–94.

[9]M.Ringwald and K.R?mer,“Deployment of sensor networks:problems and passive inspection,” in Proc.of the Fifth Workshop on Intelligent Solutions in Embedded Systems,Madrid,2007,pp.179–192.

[10]A.Sikora and M.Schappacher,“Network simulation of wireless metering networks,” presented at Embedded World Conf.,Nuremberg,2012.

[9]A.Hahn and M.Govindarasu,“Cyber attack exposure evaluation framework for the smart grid,” IEEE Trans.on Smart Grid,vol.2,no.4,pp.835–843,2011.