• No results found

An Android application for Meter Terminal Management using Bluetooth Serial Port Profile

N/A
N/A
Protected

Academic year: 2021

Share "An Android application for Meter Terminal Management using Bluetooth Serial Port Profile"

Copied!
41
0
0

Loading.... (view fulltext now)

Full text

(1)

Institutionen för datavetenskap

Department of Computer and Information Science

Final thesis

An Android application for Meter Terminal

Management through Bluetooth Serial Port Profile

by

Andreas Karlsson

Henrik Nelson

LIU-IDA/LITH-EX-G—13/001--SE

2013-02-11

Linköpings universitet

SE-581 83 Linköping, Sweden

Linköpings universitet

581 83 Linköping

(2)
(3)

Linköpings universitet

Institutionen för datavetenskap

Final Thesis

An Android application for Meter Terminal

Management through Bluetooth Serial Port

profile

by

Andreas Karlsson / Henrik Nelson

LIU-IDA/LITH-EX-G--13/001--SE

2013-02-11

Supervisor:

Tommy Blohm

Software Engineering, Metrima AB

Supervisor:

Massimiliano Raciti

Dept. of Computer and Information Science, Linköpings universitet

Examiner:

Simin Nadjm-Tehrani

(4)
(5)

Abstract

When maintaining and configuring systems for Automatic Meter Reading (AMR) it is important to have access to powerful tools for on-site management of the connected metering devices. These tools includes mobile phone applications which allow system operators to directly manage the devices through the phys-ical interfaces they expose. This thesis report explores and describes the im-plementation of an application, the problems and choices which arose while developing it, like choice of platform and communication protocols. The result is an Android application that is capable of setting up communication variables on the metering devices and reprogram them with new firmware, amongst many other features.

(6)
(7)

Acknowledgements

We would like to thank the people at Metrima AB for their unconditional sup-port throughout our thesis project.

From Link¨opings University, we would like to thank Anders Haraldsson and Per-Magnus Olsson as a source of inspiraton during our early days, and Massi-miliano Raciti for his valuable work guiding us and supervising us throughout our project.

At last, we would like to thank our friends and family.

(8)

Contents

1 Introduction 1 1.1 Problem formulation . . . 1 1.2 Solution approach . . . 2 1.3 Thesis outline . . . 2 2 Background 3 2.1 System Overview (MActor System) . . . 3

2.2 MActor software . . . 4

2.3 Infrastructure . . . 4

2.4 Terminal . . . 4

2.5 Meter . . . 5

2.6 Optical interface / probe . . . 6

2.7 Old PDA Software/MAst . . . 6

3 Requirements 8 3.1 Functionality . . . 8

3.1.1 Primary functionality . . . 8

3.1.2 Secondary functionality . . . 9

3.1.3 Additional/New functionality (not prioritized) . . . 9

3.2 Choice of platform . . . 10 4 Application Development 11 4.1 Application layers . . . 11 4.1.1 Presentation layer . . . 12 4.1.2 Middleware . . . 14 4.1.3 Data layer . . . 15

4.2 Implementation of required functionality . . . 18

4.2.1 Primary functionality . . . 18

4.2.2 Secondary functionality . . . 20

4.2.3 Additional/New functionality (not prioritized) . . . 23

5 Discussion 26 5.1 Outcome . . . 26 5.2 Platform . . . 27 5.3 Security . . . 27 5.4 Possible Improvements . . . 27 6 Conclusions 29 iii

(9)

CONTENTS iv

(10)

Chapter 1

Introduction

Automatic meter reading (AMR) is the technology of automatically and re-motely collecting meter value data from utility metering devices (electricity, heat, wam water, gas etc.) and transferring that data to a central database for control and presentation. The main advantage of this is the reduced cost for the utility providers as they do not need to visit each metering point physically. It also increases the possibility to analyze the periodic usage of utilities. When maintaining such systems there is need for an easy and flexible way of configur-ing and integratconfigur-ing new and existent meterconfigur-ing devices to it. Earlier solutions to this problem included mobile handsets and platforms with proprietary software applications suited for communicating with these devices. The automatic meter reading (AMR) system we are integrating with is a network where a central software management system called MActor controls and receives data from multiple nodes in the network. The nodes consists of utility metering devices which report their reading through different communication channels that in-clude powerline communication (PLC), radio and TCP/IP. When building a network of metering devices, they must be parameterized and configured to be able to initiate a connection to the network. If the specific measuring point has multiple meter types connected, the metering device must be configured on-site for this.

1.1

Problem formulation

The current mobile configuration tool in this system is a Windows Mobile 6.1 ap-plication called MAst which communicates with the meter nodes through blue-tooth serial port profile (SPP). These nodes themselves do not have blueblue-tooth support but utilizes an optical serial interface for communication. A portable bluetooth to serial data adapter is therefore used with MAst to allow access to the nodes. MAst is outdated, running on an unsupported legacy platform with an inflexible code base and lacking many features that would be needed to manage the meter devices currently used.

(11)

Introduction 2

1.2

Solution approach

This thesis describes the development process of a new application, and inves-tigates the advantages this new solution brings over the older and outdated one. The platform used will be thoroughly investigated to ensure it satisfies our needs (such as expected better longevity) and will be redesigned from scratch. A requirement specification will be written to formalize the goals of the project. After that, the implementation, coding and design of the new application will start, with the expected result that the new application will bring many ad-vantages compared to MAst, such as automatic updates, easier bluetooth man-agement and overall more stable performance. This new application is then evaluated and presented to the reader retrospectively.

1.3

Thesis outline

The report starts of with a background that introduces the concepts and system that we are integrating with. This includes the AMR system MActor, the under-lying infrastructure and the specifics of the meter devices. The old application is also described to provide the reader with an understanding of the needs and current feature set of the legacy mobile solution. The physical interface between the mobile phone and the metering device is also described.

The second part of the report describes our process of writing a requirement specification for the application, and the contents of this specification. We mo-tivate the usage of Android as the target platform and we describe the different functionality that is to be implemented and why they should be included on the new platform. We also dicuss the features that are currently implemented in MAst and which of these features that should be transferred into the new application.

The next part of the report is concerned with the implementation of the ap-plication. It provides the reader with an understanding of how the application architecture is designed and how the applications core components are working and integrating with each other to satisfy the required functionality and improve on the older solutions design choices.

Finally, the report discusses the resulting application and what conclusions that can be drawn from this project.

(12)

Chapter 2

Background

This part of the report describes the context in which this project has been undertaken. It provides the reader with an understanding of how the AMR system we are integrating with, MActor, is structurally composed and what its components are. It also gives the reader an overview of the old software we are aiming at replacing.

2.1

System Overview (MActor System)

Figure 2.1: MActor System

MActor System is described by Metrima, the company responsible for the system, as a ”flexible two-way communication system for the gathering of me-ter data”. The system is partly composed of a central control software and database solution (Component 1 in Fig 2.1), also called MActor Software, that can fetch and store meter data and communicate with metering devices that have been connected through the system infrastructure (Component 2 in Fig 2.1). The communication network is composed of proprietary routers/repeaters that can communicate with each other, creating an infrastructure for commu-nications between the MActor sofware and the single-purpose computers, ter-minals (Component 3 in Fig 2.1), that control end node metering devices, or meters (Component 4 in Fig 2.1). These terminals have one or more meters attached to them, and will read and cache meter data regularly to be able to provide the MActor software with this information at request. When installing

(13)

Background 4 and configuring new terminals/meters in the network an operator sometimes need to have physical access to the device being installed to be able to configure it. That is why every meter is equipped with a serial optical data port that can be used to communicate on-site with both the meter and the terminal. This is currently being used by MAst, which needs a bluetooth-to-optical probe at-tached to the optical data port when the device is to be configured (Component 5,6 in Fig 2.1). For example, if the first adjacent infrastructure node to the metering device is a radio station, the operator needs to send certain radio pa-rameters to it to enable its communication with the network. Another use case is if a customer to a utility company has not payed their bills, they might have to be turned off from the utility. Modern meters features a ”breaker” (circuit breaker) which can be manipulated remotely.

2.2

MActor software

The MActor software suite is a set of software, hardware and database servers and applications for use with the MActor automatic utility reading system. Its primary use is as a framework that can be used to regurarly fetch meter values from all the system networks attached terminals/meters and persist and present them in an easy accessible manner for the utility company using the system.

2.3

Infrastructure

The network of the MActor System is composed of multiple proprietary nodes (routers and repeaters) connected with each other either wirelessly through ra-dio or through power line communication, providing a flexible infrastructure for MActor even when setup in remote areas. There are several different commu-nication protocols supported by the infrastructure:

• TCP/IP is a well known established standard being used primarily in the central parts of the system.

• LonWorks is an open standard which provides software- and hardwareR

producers with free networking capabilities.

• IEC62056-21 is a global standard for reading electric power meters. • MBus is an established standard for connecting different type of meters

such as district heating-, water- and gas meters to a central system or a terminal.

The communication between the MActor Software and the first adjacent network node is always based on TCP/IP.

2.4

Terminal

The terminal is the device that links together the communication infrastructure with the meter(s), and is primarily responsible for fetching and caching meter values from any of its attached meters, and sending those values to the central system when asked to do so, via the infrastructure. There are two main types of

(14)

Background 5 terminals, differentiated by the manner in which they communicate ”up-streams” to the first adjacent node in the network;

• ”PLC” (Power Line Communication) terminals, where the communication is carried out on a conductor normally used for electric power transmission, using a proprietary protocol.

• ”Cellradio” terminals, where the communication is carried out wirelessly over radio using a proprietary protocol.

The terminal supports numerous other operations depending on terminal type, some of the most important abilities being to logically connect/disconnect a terminal with remote meters, manage a meters circuit breaker or read status information from a meter. It is possible to communicate with a terminal in two different manners, either through MActor or through an internal service port on the meter it is attached to. To communicate with a terminal, a proprietary protocol called TerminalProtocol is used, holding a payload of arbitrary size built up by another protocol. The payload protocol used within the scope of this project is called TMp2 and can be used to build up messages that can be sent to and from a terminal, instructing it to perform specific operations or give out certain data. Before a message is sent to a terminal, special care needs to be taken to ensure that the data being sent is valid, which is why a message length needs to be included in the terminal protocol header together with an arithmetic checksum that has been calculated to ensure the integrity of the message data. In our situation, the message will be relayed through multiple intermediate steps before it reaches the terminal. Since some data has meaning to these intermediate stations, they might interfer with and stop message data from reaching the terminal if certain bytes have not been properly escaped beforehand. Likewise, the receiver of any communication from the terminal must make sure to unescape the response data before using it. For the purpose of identification, both terminal types might be sent certain messages to have them reveal their unique identification numbers, albeit in slightly different ways. The communication speed when communicating with a terminal needs to be at a specific baud rate. For this specific project, support needed to be built for the ME320 terminal series, which is of communication type PLC.

2.5

Meter

The meter is responsible for the actual measuring of electric consumption and other data that might be of interest to the electric utility. Metrima doesn’t manufacture any meters themselves, instead choosing to build their terminals and systems around meters from industry leading producers such as Landis Gyr and Kamstrup, who provide their meters with communication interfaces for terminal manufacturers to use. The meters supported within the scope of this project all have an optical service port interface (TOSLINK) for communication, which can be used to send and receive data to and from the meter. In order for a meter to be able to pass data through to a terminal and not intercept it, a meter-specific message needs to be sent to it to make it relay all further communication down to the terminal. The process of sending such a message is called ”signing on” and a meter which relays communication through its service

(15)

Background 6 port down to its terminal is said to be in a ”signed on” state. A meter will automatically ”sign off” from the terminal after 30 seconds of communication inactivity, disabling all further communication with it until it is put into a ”signed on” state again. When in ”signed on” state, the terminal is unable to perform any communication with the meter. This is also true in the opposite situation when the terminal is actively communicating with the meter, which means that it is not possible to sign on when the terminal is working with the meter. One example is when a terminal fetches all meter values from the meter. Depending on the meter and terminal type this operation can take several tens of seconds, in which case multiple sign on attempts might be needed. As stated earlier, some meters have a breaker which enables an operator to remotely disable the power throughput through the meter. To enforce that such a disabled state is not tampered with, the terminal can be set to block the meters breaker, where an operator communicating with the terminal in a secure and password protected manner is the only way to enable power throughput again. There are LED indicators on the meters reflecting the inner state of the breaker; whether it is on or off and blocked or not. For the purpose of identification, a specific message might be sent to a meter to have it reveal its name.

2.6

Optical interface / probe

All meters of our concern have an optical serial port for communication with it, and in extension the terminal managing it. Metrima has made a business deci-sion of using a certain optical probe that enables data transfer between smart-phones equipped with a Bluetooth interface and consumption meters equipped with an optical interface for on-site configurations. The hardware in question is manufactured by the German company P+E and is named ”Optical Probe K01-BLUE”[1]. The probe can be configured to use a variety of settings, for example speed, measured in characters per second or baud rate, the parity of each byte and whether a stop bit should be used or not. Several versions of this probe has been released onto the market, which has caused some compatibility problems, unfortunately different versions might be needed for different terminals. As is the case with meters, certain byte sequences have special meaning to this probe, which is why it might stop message data containing them unless they have been properly escaped beforehand.

2.7

Old PDA Software/MAst

The old PDA configuration software MAst does not have support for the new terminal series which is the main reason why this project was undertaken. The new application will base its set of core functionality off of MAst, and in order to minimize the level of confusion for operators using the new application we will maintain much of its core design concepts. MAst has been designed in multiple iterations over several years, with new functionality being added continuously. The current version number is 12.1.0 (Build 920), and this is also the version used during our investigation into it. The application is built around a main screen that provides the user with functionalities for common scenarios. From this screen, the user can enter a new one which lists all the secondary

(16)

function-Background 7 ality. As Windows Mobile 6 do not provide a way of establishing a bluetooth connection to another device from inside an application, bluetooth connectivity and configuration needs to be done at the operating system level and a user must explicitly create virtual COM-ports for a bluetooth connection to be able to take place, a time consuming and error-prone task. MAst does not keep track of whether a meter is in a signed on state or not, instead a sign on and sign off operation is performed for every single other supported operation, something potentially time consuming. It has support for many Metrima terminals and is quite feature rich. It features the ability to configure radio settings in a terminal. It also contains the possibility to connect multiple meters (wired or wirelessly connected to the terminal) to it and maintain them in its software. Terminal state information can be presented in an informative matter and maintenance issues can be easily solved by pinging and reading certain parameters from it.

(17)

Chapter 3

Requirements

Since the new application will implement the bulk of MAst’s core functionality, some time was initially spent trying to reverse engineer it, which combined with new requirements rendered this specification for the new application. All functionality requirements are derived from the old software, unless explicitly stated otherwise.

3.1

Functionality

A scheme where the functionality were labeled after importance (e.g. ”primary” or ”secondary” functionality) was also devised after consideration of normal use cases.

3.1.1

Primary functionality

The primary functionality is the functionality which was considered to be the most important to implement, this includes core functionalities and features that have been deemed the most valueable to users.

• Installation: a newly mounted terminal that communicates with its first adjacent network node through radio must somehow signal its existence to the world. This requires an operator to configure certain radio parameters after mounting, enabling the meter to broadcast its existence to its first neighbouring node.

• Parameter reading: every terminal and meter can be asked to provide information about its internal state (its internal clock, which meters it is connected to, hardware information and other state data which might be of interest to a user).

• Remote meter management: a terminal can connect to a number of remote meters, usually through the wired or wireless MBus protocols. When such a link has been established, the terminal can fetch its meter data. In MAst, certain functionality allows the user to view a list of the remote meters a terminal can communicate with at any given time. From this interface, the user is able to connect with any meter within its range, and also set an encryption key for encrypted communication with

(18)

Requirements 9 it. In cases where there are many meters nearby, a mechanism to poll the terminal for heard meters matching a ”priority” pattern is possible. The list showing all the meters should be sortable.

• Breaker management: each meter has a ”breaker” which enables an op-erator to disable the power throughput through the meter. To ensure that unauthorized users do not tamper with such a disabled state, the meter can also be set in a so called ”breaker blocked” mode, where an operator communicating with the meter in a secure manner is the only procedure that can be followed to enable power throughput again. Management of these two intertwined states is possible in MAst.

3.1.2

Secondary functionality

The secondary functionality is functionality which was considered to be less important to implement than the functionality deemed as ”primary”.

• Firmware installation: the original software provides an ability for users to reinstall/upgrade the internal software(”firmware”) for most types of terminals. This procedure might differ quite a lot depending on the ter-minal type to operate on.

• Service commands: in MAst, the user was able to enter specific ser-vice commands to the terminal and/or meter and receive their responses. This made MAst a useful troubleshooting tool for malfunctioning me-ters/terminals. One such important service command is one to reformat the terminals internal flash memory.

• Factory reset: an operator should be able to restore the terminal to its initial state. This includes stored meter value data and communication parameters.

• Meter list deletion: as a terminal keeps a list of all meters within its range, it sometimes might be useful to remove all entries from this internal list.

• Meter search: this functionality listens and queries for all available me-ters and re-populates the terminals internal meme-ters list.

• WMBus settings: this functionality provides the user with the ability to provide settings for the terminals internal WMBus-card.

• Restart: provides the user with the ability to restart the meter.

3.1.3

Additional/New functionality (not prioritized)

• Easy change of terminal: an operator should be able to seamlessly attach their bluetooth dongle to a new terminal and connect to this one, all through the same bluetooth connection. In the old MAst software, an intricate and complex protocol had to be followed each time an operator wanted to communicate with another terminal. This is something that will be addressed in this new software.

(19)

Requirements 10 • Self update: the new application should have a self updating mechanism enabling it to look for newer versions of itself and to download any new versions from the internet if needed. This simplifies a lot for Metrima´s support department, as the users will be persuaded to use the latest version of the new software, minimizing problems that might arise from the use of different application versions.

• Service menu: the new application should have a service menu where logged data is accessible for troubleshooting.

• Terminal type awareness: the new application should be able to auto-matically identify the type of terminal it is connected to, enabling/disabling specific in-application functionality accordingly. This is because not all terminal types supports all the functionality of our application.

• Settings menu: a settings menu should always be available to enable the user to have control over some things, such as the communication baud rate.

3.2

Choice of platform

Since the new application must have support for bluetooth connections, one of the main design choices is the selection of a platform where this is supported. Other factors are taken into account, such as prognosis of platform longevity. At the time in which this work was done, the three modern mobile operating systems with the largest market shares are Microsoft’s Windows Phone 7.5, Google’s Android and Apple’s iOS. As market shares can be seen as a good indicator of expected platform longevity, we conclude that any of these three could be targeted. A basic requirement is that the platform should expose good communication capabilities over a bluetooth connection, which is why our in-vestigation starts with that in mind. The iOS platform currently provides no way for developers to establish a general data connection (RFCOMM / SPP[2]) over bluetooth. This was true for the next assessed platform as well, Windows Phone 7.5. Android has had support for the serial port profile (SPP) over blue-tooth since version 2.0[3] (launched on the 26th of October 2009) - this version or later is currently available on more or less all android devices manufactured lately. Android is therefore the platform that is selected by exclusion. Other properties makes Android a greater choice in contrast to the other platforms are its relative openness and the large community-driven support base for de-velopers. One remark regarding this selection is that the personnel at Metrima is not currently acquainted with the platform, but we believe that this will be a minor issue in the future.

(20)

Chapter 4

Application Development

This chapter describes the implementation phase of our project, including the way we have structured the source code components and how these different components can communicate with each other. The most important compo-nents are described together with general design choices and design patterns. Screenshots are provided for some of the functionality.

4.1

Application layers

The software architecture in the new application constists of three separate logical layers (Fig. 4.1), each providing its own level of abstraction.

• The presentation layer is the part of the application which is concerned with user interaction. In this layer we manage GUI components of the An-droid framework. These components can communicate with and present data from a data layer.

• The data layer performs low level communication with the terminals. • The middleware layer The communication in between the presentation

layer and the data layer are facilitated by a group of components. The middleware layer handles tasks like thread communication and synchro-nization, terminal state management and error handling.

(21)

Application Development 12

Figure 4.1: The layered architecture of the new application, with important components showing

4.1.1

Presentation layer

The presentation layer is composed of the graphical user interface with its com-ponents and semantics. Our intention was to design the applications user inter-face with a uniform and themed look and feel, while maintaining design choices made for the old application as not to confuse users. For instance; we decided to continue presenting the user with the most used and common operations on a main screen, while showing operations perceived to be of lesser importance in a different, secondary view. Both of us were heavily influenced by the look of Windows Phone 7.5 while designing the application. We also use the same color theme as in Metrima’s logotype - black, white and green.

In Android, applications consists of one or more different Activities, an abstrac-tion providing a developer with a window-like surface where GUI components can be shown and user input can be handled. Since this often forced the user to toggle between different activities when accessing different functionality, the user experience could feel sluggish. In Android 3.0 a new graphical component was introduced in the SDK to counter this problem; Fragments[4]. A Fragment represents a behaviour or a portion of user interface in an Activity. You can combine multiple fragments in a single activity to build a multi-pane UI and reuse a fragment in multiple activities. We decided to build our application using a single activity while using fragments to display different functionality. Another graphical component provided by the Android platform that we have used throughout the application to implement functionality is a Dialog[5]. A

(22)

Application Development 13 dialog is usually a small window that appears in front of the current Activity. The underlying Activity loses focus and the dialog accepts all user interaction. Dialogs are normally used for notifications that should interrupt the user and to perform short tasks that directly relate to the application in progress (such as a progress bar or a login prompt).

Our application is centered around two main parts; the header section and the content section (Fig. 4.2).

Figure 4.2: The GUI layout of the application

The header section is always visible to the user and provides her with con-nectivity status, application state information and other useful feedback. Apart from information, the header section also provides the user with a button to ac-cess the connection manager, a fragment (Fig. 4.3) that helps the user connect to a bluetooth device. The content section is a view placeholder for different fragments, each providing different functionality. We designed the application work flow so that a user cannot show any other fragments than this until they have successfully established a connection with another bluetooth enabled de-vice, thus being the fragment shown at application startup. When a successful bluetooth connection has been established, the main fragment (Fig. 4.4) will automatically be shown, with all alternatives disabled except for the option to try and sign on to a terminal. If the sign on process is successful, the user will be presented with all the supported functionality for the attached terminal type, as the application is now reflecting the terminals signed on state (Fig. 4.5).

(23)

Application Development 14

Figure 4.3: Connection Fragment

Figure 4.4: Main Frag-ment

Figure 4.5: Terminal at-tached

Whenever communication with a terminal is interrupted for any reason, the application will adjust its state accordingly, once again presenting the user with the connection manager fragment as the only possible alternative.

We decided to keep functionality that does not require terminal communication accessible in a global manner by presenting them in a menu bar that is displayed whenever a user presses a hardware button on her handset(Fig. 4.6). The menu bar presents three buttons that open dialogs with different functionalities:

• About dialog (Fig. 4.7); A dialog that shows the user the current version number

• Sign off; Provides the user with the ability to explicitly sign off from a terminal

• Settings (Fig. 4.8); Provides the user with a fragment to manipulate global settings.

The data presented to the user is fetched from the terminal and data layer through a set of components specifically designed to bind together terminal specific code with generic UI code, the middleware layer.

4.1.2

Middleware

Whenever the presentation layer wants to access the data layer, a certain set of components might be used to help the presentation layer communicate with the data layers interfaces and provide utility tools that can be used throughout these layers. This set of components constitute the middleware.

The two most important middleware components are:

• TerminalConnection - Provides API entries for the different terminal com-munication requests that can be issued to the data layer. This ensures,

(24)

Application Development 15

Figure 4.6: Menu bar Figure 4.7: About Figure 4.8: Settings amongst others, that requests/messages are sent in a separate background thread as opposed to the main thread. It also provides means to return errors and return values from the background thread to the main thread. This is implemented by utilizing the AsyncTask class in the Android frame-work and pre-defined interfaces to deliver errors and data. Other tasks that this class manages are to keep track of the currently attached ter-minal, signal when this connectivity state changes and to supply default parameters for a lot of requests.

• TerminalConnectionManager - A class implementing the Singleton design pattern that keeps track of a connection to a bluetooth device. This globally accessible object is the owner of TerminalConnection instances and takes responsibility for them. Apart from keeping track of the active bluetooth connection, it reports changes to bluetooth connectivity states and allows global access to the active TerminalConnection instance.

4.1.3

Data layer

The data layer is the part of our application that is responsible for communi-cating with terminals. Apart from sending and receiving data, the data layer also is in charge of serializing and wrapping parameters in protocol headers, deserializing responses and validating that the responses received are valid. The data layer provides a well defined interface for the different functions and hides as much implementation details as possible.

One important part of the data layers are different components called ”mes-sages”. The messages have one thing in common: they take parameters, build complex data types and send them over a stream. They then deserialize the response and return the appropriate data to the caller. All messages implement the interface TerminalMessage<E>, which is a very simple interface that ex-poses two public methods: send - which sends the messages and returns the

(25)

Application Development 16 response from the terminal and getMessageType that returns a unique identifier for any message. The send method is also allowed to throw an exception of type TerminalException, to signal that the message encountered a serious problem while performing its task. Messages are often reusable but since they are often very small they are almost always created on the fly and discarded when their content has been sent.

Messages can be divided into two larger categories, atomic messages and com-posite messages. Atomic messages are the smallest single communication entity of the application. They usually represents a single terminal request/operation and have little or no logic apart from the building of protocol headers and pars-ing the response. Example of messages that are of atomic type are messages that fetch the terminal identification number , set encryption key of remote me-ters or change the communication settings of the bluetooth probe.

Composite messages on the other hand are often composed of several other messages (atomic and/or composite). They might implement their own logic to perform tasks and handle errors. Examples of compound messages in our ap-plication is GetAllFoundMetersMessage which repeatedly sends an atomic Get-FoundMetersMessage to gather all meters connected to a terminal. A simple atomic message is DetectProductMessage (Fig. 4.9) which queries the terminal for its identification code and returns it to the caller.

(26)

Application Development 17

Figure 4.9: A typical atomic message. The constructor is concerned with setting message specific parameters, in this case ’109’ which to the TerminalProtocol means ”Detect product ID”. getMessageType returns a unique identifier for a message, and the getResponse function initiates the communication with a terminal, fetching its response in the process.

To be able to build, send and parse these messages the data layer also con-sists of several components that takes care of this. The two most important are TerminalProtocolHolder and TerminalStream. TerminalProtocolHolder is a class that is intended to be used as a base class. It is basically a wrapper around a java byte array which is capable of holding the entire terminal message struc-ture. Almost all messages that are sent and received from the terminal uses this structure so it’s fundamental to our messaging system. It exposes methods to extenders of this class to manipulate the underlying byte array. Apart from methods that sets and/or gets data fields of the protocol it also provides meth-ods that calculates and validates checksum fields in the message. Another vital functionality that this class takes care of is the escaping of data, to stop data intended for the terminal being intercepted before it reaches its destination TerminalStream is the class that handles of all the sending and receiving in-volving the bluetooth connection. Most of the time TerminalStream is just a wrapper around the native Java streams, InputStream and OutputStream, with one very important exception: reading data. It is not always possible to know how many bytes you are expecting from the terminal and sometimes there are

(27)

Application Development 18 bugs in the terminal firmware. In some cases, this means that we might expect to receive more data from the terminal but from its perspective it has sent its en-tire response. That would create situations where the application would block indefinitely. To solve this peculiar problem we decided to use a background thread that always reads as much data as possible from the stream, leaving it in a thread safe shared byte buffer. This means that the background thread will be blocked most of the time but this does not matter since the thread that fetches the data can get it from the background thread without fear of an infinite wait scenario.

4.2

Implementation of required functionality

This part of the report covers our implementation of the required functionality described in Chapter 3; Requirement Specification. Each functionality is imple-mented by using different components from each and every one of our abstract application layers. The sections describe a specific functionality and the design choices we made when implementing it. We will explain the problems we have had to deal with and our solutions to those problems.

4.2.1

Primary functionality

• Parameter Reading - (Fig. 4.10) A terminal and meter can be asked to provide a multitude of hardware and software information, therefore a certain subset of these parameters has been selected for this functionality. These specific categories of information can be shown by our application: – General Parameters - General information about the terminal such as model name, current date and time and its unique identification number, or TerminalID.

– System Parameters - Hardware and software information regarding the system such as memory size information, firmware version and hardware board revision number.

– Meter List - Shows a list of all meters that have been logically con-nected to the terminal and the protocol being used when communi-cating with it.

• Remote Meter Management - (Fig. 4.11) The old software has a fea-ture where it can provide the user with a list of remote meters that the terminal can connect to. The list is populated with rows of meters where each row consists of three columns showing the meters unique serial num-ber, its signal strength and the date and time of latest communication with it. There is also an indication of whether or not the individual meter is currently logically connected to the terminal or not. A requirement for the new application was that the user should be able to query the ter-minal for a similar list, and be able to sort the list by column in both ascending and descending order. Since the Android framework does not provide a graphic list view that could be customized to our taste, we had to design our own composite view object capable of tracking the lists sort state. In the original application, the user could logically connect the ter-minal to a meter by selecting the meter and pressing a button. In the

(28)

Application Development 19 new application, a design choice was made in accordance with standard android design guidelines to present the user with meter specific alterna-tives when pressing the meter in the list. The meter specific alternaalterna-tives available are either ”Connect” for non-connected meters and ”Disconnect” and ”Encrypt” for connected ones. The encryption feature enables the user to encrypt communication with a meter by entering an encryption key. Since this operation was deemed by us to be a small one with only a single atomic message, we decided to present the user with the function-ality by using a dialog instead of a fragment. A design choice was made to query the terminal for the meter list automatically upon viewing the fragment and also to provide the user with an explicit possibility to fetch the meter list and re-populate the list view by a button. In a case where many meters might be in the terminals range the user might want to tell the terminal to only look for meters with a serial number matching a spe-cific string pattern. This operation was also deemed a minor one, with the functionality to give the pattern string to the terminal being implemented with a single message and a dialog.

• Breaker Management - (Fig. 4.12) Some meters have a hardware breaker that, when pressed, enables or disables power throughput through it. The breaker can also be blocked, disabling its ability to toggle power through-put. In order for an electric utility operator to manage the breaker state (via the central system or the optical interface), the terminal has been equipped with support for it. Specific operations related to the breaker cannot be sent to a terminal before it has entered an armed state - a ter-minal in an armed state can only process breaker operations within the next 30 seconds before the state is removed and the terminal has to be armed again to facilitate any new breaker operations. The message telling a terminal to go to an armed state contains a CRC32-checksum calculation on a security code which has to be provided by the user, effectively hin-dering anyone without the code to tamper with the breaker state. The old software provides the user with no security code option, instead defaulting the security code to a byte array of size 8 filled with 0x00 values. It does however require the user to enter something called Installation-ID, which is the unique terminal identification number for cellradio terminals (the PLC terminal equivalent is called Neuron-ID). The required functionality for the new application was the ability to either block the breaker, turn the breaker off or turn the breaker on. It was decided that the operations to turn the breaker on or off automatically should disable any breaker block silently. We discovered that both Cellradio and PLC terminals could be polled for their Neuron-ID, which is why we do not have to query the user for it in the new application, instead polling the terminals for this infor-mation. We had to implement different messages for each terminal type, since PLC terminals and cellradio terminals have to be queried for this information in slightly different ways. In order to maintain extensibility and a high level of abstraction, we decided to use the template method pattern[6] and implement the terminal id polling messages by using an ab-stract base class to control the generic algorithm, which is similar for all terminal types, while letting methods in sub classes provide terminal type-specific parts of the algorithm. We also implemented a factory method in

(29)

Application Development 20 the base class which provides the correct derived message from a given terminal type, making it easy to add support for new terminal types in the future. A specific problem with the implementation of this function-ality was to read out the responses from the different breaker operations, since the terminals communication with the meter disrupts communication through the optical interface. Special composite messages implementing logic to sign off and on to the terminal again after every breaker operation was designed in order for the application to be able to keep its signed on state after managing the breaker.

• Installation - During the development phase, it was decided to leave this functionality for the future.

Figure 4.10: Parameters fetching

Figure 4.11: Remote me-ters

Figure 4.12: Breaker management

4.2.2

Secondary functionality

Secondary functionality is implemented by using a fragment, accessible from the main fragment. It is a gathering of less used operations which might still be of interest to a field operator. We decided to differentiate the look of the alternatives in this menu from those in the main fragment, as a means to not confuse the user. As is the case with the main fragment, functionality might be enabled or disabled according to the connected terminal type.

(30)

Application Development 21

Figure 4.13: Less used functionality

• Firmware installation - (Fig. 4.14) The ability to update or reinstall terminal firmware required an easy way for the application to access and read binary files containing firmware data. It was decided that the ap-plication would look for firmware files in a specific folder on the handsets memory card. Installing a new firmware is a complicated procedure where a lot of composite messages need to be sent to the terminal in certain chronological order with certain time delays in between. As with breaker management, a security code has to be provided in order for the terminal to perform this operation. The firmware binary data is sent to the termi-nal in sections of 64 bytes each, encapsulated in a regular single message. When all data has been sent to the terminal, a checksum is calculated on the terminal to verify the integrity of it. This checksum is compared with an earlier and locally calculated checksum for validation. A success-ful comparison initiates the installation sequence on the terminal where it will restart itself and boot the new firmware image. Since the terminal will reboot itself a new sign on message needs to be sent to the terminal after a full firmware installation to restore the applications communication ability with it. The overall firmware installation procedure for cellradio terminals and PLC terminals are very similar, there are however some small differ-ences. As with the breaker management, it was decided to implement this functionality by using the template method pattern[6].

• Service commands - During the development phase, it was decided to leave this functionality for the future.

• Factory reset - (Fig. 4.15) In order for the terminal to perform a fac-tory reset operation, it needs to be sent a specific single purpose message containing a security code. The dialog provides the user with easy way of entering the security code. It was also decided that it should give the user a tip of how one could override the security code lock by physically pressing a service button on the meter. After the terminal has performed this operation, it enters production test mode, where a number of system tests can be performed, e.g. flashing LEDs or testing registers. To leave

(31)

Application Development 22 this mode, the terminal must either be idle for 60 seconds or process a specific message. Unfortunately, the firmware version we were working on had the optical interface disabled in production test mode, so we solved this in our application by having the user wait for a whole minute. This was due to a bug in the firmware which has now been solved, but due to the firmware already being out in production it was decided to keep this approach to provide backward compatibility.

• Meter list deletion - Does not provide the user with any graphical views other than the results of the operation, implemented in a single atomic message. It effectively removes all meters from the terminals internal meter list.

• Meter search - Does not provide the user with any graphical views other than the results of the operation, implemented in several atomic messages. Since the meter is in a signed on state, it can not be found by the meter search. We decided to explicitly send sign off and sign on messages to the terminal after performing the search operation to make the terminal able to find the meter and the application to maintain its communicative state. For certain types of MBus meters, the search process might take up to 30 minutes. Since this is a very long time, we decided to give control to the user in the beginning of this operation and let her manually check for its completion later.

• WMBus settings - (Fig. 4.16) Provides the user with an option to set a predefined protocol for a wmbus hardware card, available when connected to a terminal with such a card installed. Since there are several card interfaces on a terminal, the user needs to provide one as well. This functionality has been implemented by using a single atomic message and is no different from the corresponding functionality in the old application. • Restart This functionality was not implemented, due to the fact that

(32)

Application Development 23

Figure 4.14: Firmware update

Figure 4.15: Factory re-set

Figure 4.16: WMBus set-tings

4.2.3

Additional/New functionality (not prioritized)

• Easy change of terminal - To make it easy for operators to quickly change terminals and perform task on multiple terminals in a short time, we decided to keep an option on the startup page of the application to allow an operator to virtually anytime quickly attach to a new terminal. Combined with the Terminal Awareness functionality described later this provides a powerful and agile way to work with terminals of different make. • Self update - A problem that Metrima has earlier encountered during the lifetime of their products is difficulty with customers having to update software to the latest version. This difficulty arises from the fact that binary executable files have been sent through email and other node-to-node communication media with poor or no version control system. This has led to customers experiencing problems with bugs that have already been fixed and confusion in which version should be used. To counter these difficulties we determined that it would be useful to incorporate an update mechanism into the application. This would solve any problems with old versions still in use as the support personnel could just prompt any user to first check the updating mechanism for the latest version before performing any troubleshooting. We initially looked at Google Play (former Android Market) as the distributing platform for the application. We quickly had to abandon Google Play though, since it does not support the concept of ”private app” where an application is only available to someone who has a direct link to the application. Instead we found a 3rd party distributing platform named ”Push Link”[7]. This solution consists of a java library (in the form of a jar file) and a homepage. Push Link supports all the functionality we needed and was free of charge so we decided to go with it. Incorporating the push link library into the application turned out to be a simple task and it was a mere initialization call that was needed to the push link library. The result is an application that checks for a

(33)

Application Development 24 new version of the software multiple times during runtime. When a new version is found a notification is posted to the user prompting the user to download and install the latest version. If an exception is caught within our application, Push Link will send us an email with the details, providing a nice automatic error reporting mechanism.

• Service menu - As work progressed we came to the conclusion that we needed the possibility to log execution progress. We developed a system where the application could log diagnostic messages and all data sent and received through the bluetooth interface. Since the logs resides on the SD-card of the handset the log is readily available and easy maintainable. Due to this fact we decided that a specific menu in the application where this log could be displayed was not needed and in situations where the log would be needed it could easily be accessed by looking at the log file on the SD-card.

• Terminal type awareness - In MAst, the user was queried for some information regarding the terminal that the software was currently con-nected to. This lead to situation where the software could perform oper-ations on a terminal that did not support them. We decided to address this problem by querying the terminal for several pieces of information to determine what kind of terminal it is. The primary identification pro-vided is the product id. This is a simple 32 bit unsigned number which corresponds to a specific terminal model; e.g. when looking at terminals of the 320 series, the product id of the cellradio variant is ’319’ while the PLC variant is ’320’. This convention where the cellradio variant is the product number minus one and the PCL variant corresponds directly to the product number is used in all the different terminals manufactured by Metrima thus making our implementation future proof.

This is however not all the information needed when identifying the ter-minal type. Apart from the model (i.e 320) and communication type (i.e PLC) there are one more thing needed for a correct identification: whether it is of WMBus or MBus type or if it is neither. This information can only be identified by querying for different types of I/O-cards attached to the terminal. Technically the terminal can have both an MBus-card and a WMbus-card, however in production this never happens, thus it’s safe to assume a terminal is of a given type if it has the card associated with that type attached as an I/O-card. The identification process is initiated every time a successful sign on message is sent to a terminal, where a positive identification adjusts the applications state according to terminal type, enabling or disabling functionality. In order for us to be able to stati-cally store terminal specific data within our application with information regarding I/O cards, product id and supported functionality, a decision to use XML serializing was made. This enabled us to sum up all relevant information regarding all supported terminal models in a single XML doc-ument while easily being able to create objects representing the different terminals for use throughout the application. XML serializing was made possible by using a third party library, SimpleXML.

(34)

Application Development 25 we decided to expose some extra alternatives to the user. The central idea is that these alternatives can be used when troubleshooting, optimizing performance and/or managing incompatibilities with hardware/software configurations. The alternatives we decided to include were a setting of baud rate and meter type. Having baud rate as an option is very useful since terminals and meters usually work well with the default 4800 bits per second communication speed, but in some case the optical link may be volatile or the meter may be unstable. In these cases it is vital to be able to lower the baud rate setting to establish successful communication with a terminal. It’s also very useful in troubleshooting as one might rule out optical probe problems with this setting. We also decided to include the ability to choose which meter the terminal is connected to. In the default setting, the application will query the meter for identification and proceed from there. This mechanism however is somewhat error prone and might fail in certain situations so we added the ability to completely skip the identification process by letting the user explicitly state what kind of meter she is connected to. To implement this settings menu we decided to not go with a dialog but rather a fragment that doesn’t look the same way as the other fragments in the application, denoting the special significance of this one.

(35)

Chapter 5

Discussion

In this part of our report we discuss the outcome of our work, what the future possibilities might be for the application, and some of the possible improvements planned for it.

5.1

Outcome

During the 10 weeks we have been working on this thesis project, we have had to use knowledge and tools accumulated by us during our three years as com-puter science students. We have been involved in every step in the creation process, designing the graphical user interface, modelling API´s and selecting appropriate design patterns for specific problems. Special care has been taken to use a uniform code standard and to select appropriate data structures. We have received basic knowledge of certain types of project methodologies such as SCRUM that we have been heavily influenced by during the development phase, starting each work day with an assessment of the current project status and iter-atively keeping a constant discussion regarding requirements with Metrima. All important design choices have been made after deliberations with our employ-ers and with each other. In respect to the project’s requirements, our task has been fulfilled. All the required functionality has been implemented accordingly, the application has built in error reporting and a self updating functionality, with a easy to use, uniform and comprehensible graphical user interface. The application is easily extendable to accommodate new terminal types and oper-ations. The field operators has not reported any serious problems and the new application is a substantial improvement over the old one; especially the fact that the user does not have to explicitly manage a bluetooth connection. In retrospect, one drawback to this project was that the requirement to mimic as much as possible of the old application sometimes required us to use compo-nents, frameworks and/or tools in ways they were not meant. For example, in the old application the user had the possibility to show all meters connected to a terminal in a multi-column list view, sortable on the columns. This behaviour was replicated in the new application even though this is non-intuitive behaviour

(36)

Discussion 27 to an android user, and required much development time to implement. The different terminal types that we have implemented support for are supposed to behave in a similar manner, which we have found out is not the case under some circumstances. This has sometimes required us to write less generic code and adhere to undocumented behavior in our supported terminals.

5.2

Platform

The selection of Android as a target platform proved to be a good one. All of our initial requirements were possible to implement on the platform, and at the time of this work the popularity of it is increasing. The tight connection to a specific platform poses an inherent problem with platform longevity which in the future might be countered by implementing the functionality in a web based application running in browsers capable of communicating with bluetooth hardware.

5.3

Security

One significant trend in the industry is the focus and interest in security. This is due to an increased public interest in personal integrity and new laws being pro-posed in both Sweden and the European Union. One example of this is wireless mbus-meters. The advent of wireless technlogy in the meter business has led to several security concerns with sensitive data being broadcasted into possible adversaries which could use this information to for example determine when it’s safe to break into a house or to change it. To combat these issues several manufacturers of wireless meter has begun to use encryption on their meters. This means that the terminals needs to be configured to use the corresponding encryption key, a functionality that has been included in our application. Other possible security concerns are the terminals themselves. Several commands ex-posed through the optical interface could be exploited to change the stored meter values, disturb the meter reading or simply make the terminal malfunctioning. To address these concerns several commands exposed are protected with a se-curity code. Such commands include firmware installation, factory reset and breaker management. The terminals also have mechanisms that detect possible tampering attempts and reports them to the central system.

5.4

Possible Improvements

With software development, there is always a possibility for further improve-ments. In fact, we knew from earlier projects that it might sometimes be hard to keep up with a planned time schedule when new things to implement con-stantly keeps showing up. With this in mind we decided to gather and document all the non-essential improvements we could think of during the development phase, for potential implementation in the future. A major drawback of our current design is the way the data layer currently treats all terminals equally, exposing the same API irregardless of attached terminal type. This creates problems when a terminal can be sent messages telling it to perform operations

(37)

Discussion 28 it does not support. The re-modelling of this is scheduled to be an important improvement that needs to be implemented in the future.

Since handheld tablet PCs running Android are getting more and more com-mon, a special version of MAField for tablets might be ported from the cellular phone version, perhaps letting the application make use of the larger screen. As new legislation for utility measurements constantly changes, the demand for new features in meter terminals are high. To be able to reflect such changes it is important that new messages and operations can be easily added to the appli-cation source code. Our logical division of code and separation of presentation layer and data later has been designed with this in mind, making additions to the applications feature set easy. One major reason for this project was that support for a new terminal series needed to be added to the old software, which was deemed outdated. Since new terminal series are planned for the future, the new application must be updated to be able to reflect and support these models as well. This was something we were aware of while developing, which is why we have created easy ways of extending our application with new terminal types and API methods, like serializing XML describing a specific terminal, making it very easy to add new terminal types to the application.

(38)

Chapter 6

Conclusions

In this report we have described a process where a new application for remote management of electricity meter terminals has been developed, and the presen-tation of this application. A number of conclusions can be drawn from this ex-perience, in regards to the projects stated purpose. This chapter contains these conclusions, as well as a discussion on the shortcomings of the thesis project. We have developed a new application for a modern mobile platform, where as much as possible of the old applications functionality has been preserved while at the same utilizing as much as possible of the benefits of the new platform. Our main conclusion is that this has been achieved to a high degree, with mod-ern high-level Android concepts such as Fragments being used, together with a re-designed communication model, achieving a higher reliability in communica-tions with a terminal when the approach to keep connection state proved to be effective. A number of functionalites not present in the old application has been well received by users, and the automated error reporting has made support and troubleshooting easier than before.

(39)

Bibliography

[1] http://www.aquametro.com/english/auslesekopf_e.html. (11/02/2013). [2] http://en.wikipedia.org/wiki/Bluetooth_profile. (11/02/2013). [3] http://developer.android.com/sdk/android-2.0.html. (11/02/2013). [4] http://developer.android.com/guide/topics/fundamentals/ fragments.html. (11/02/2013). [5] http://developer.android.com/guide/topics/ui/dialogs.html. (11/02/2013).

[6] Erich Gamma, Richard Helm, Ralph Johnson, and John Vlissides. De-sign patterns: elements of reusable object-oriented software. Addison-Wesley Longman Publishing Co., Inc., Boston, MA, USA, 1995.

[7] https://www.push-link.com. (11/02/2013).

(40)

Avdelning, Institution Division, Department Datum Date Spr˚ak Language 2 Svenska/Swedish 4 Engelska/English 2 Rapporttyp Report category 2 Licentiatavhandling 4 Examensarbete 2 C-uppsats 2 D-uppsats 2 ¨Ovrig rapport 2

URL f¨or elektronisk version

ISBN

ISRN

Serietitel och serienummer Title of series, numbering

ISSN Titel Title F¨orfattare Author Sammanfattning Abstract Nyckelord Keywords

When maintaining and configuring systems for Automatic Meter Read-ing (AMR) it is important to have access to powerful tools for on-site management of the connected metering devices. These tools includes mobile phone applications which allow system operators to directly manage the devices through the physical interfaces they expose. This thesis report explores and describes the implementation of an appli-cation, the problems and choices which arose while developing it, like choice of platform and communication protocols. The result is an An-droid application that is capable of setting up communication vari-ables on the metering devices and reprogram them with new firmware, amongst many other features.

IDA,

Dept. of Computer and Information Science

581 83 LINK ¨OPING 2013-02-11 — LIU-IDA/LITH-EX-G–13/001--SE — http://www.ep.liu.se/exjobb/ida/2013/dd-d/ 001/ 2013-02-11

An Android Application for Meter Terminal Management through Bluetooth Serial Port Profile

TITEL

Andreas Karlsson,Henrik Nelson

(41)

Copyright

Svenska

Detta dokument h˚alls tillg¨angligt p˚a Internet - eller dess framtida ers¨attare - under 25 ˚ar fr˚an publiceringsdatum under f¨oruts¨attning att inga extraordin¨ara omst¨andigheter uppst˚ar.

Tillg˚ang till dokumentet inneb¨ar tillst˚and f¨or var och en att l¨asa, ladda ner, skriva ut enstaka kopior f¨or enskilt bruk och att anv¨anda det of¨or¨andrat f¨or ickekommersiell forskning och f¨or under-visning. ¨Overf¨oring av upphovsr¨atten vid en senare tidpunkt kan inte upph¨ava detta tillst˚and. All annan anv¨andning av dokumentet kr¨aver upphovsmannens medgivande. F¨or att garantera ¨aktheten, s¨akerheten och tillg¨angligheten finns det l¨osningar av teknisk och administrativ art.

Upphovsmannens ideella r¨att innefattar r¨att att bli n¨amnd som upphovsman i den omfattning som god sed kr¨aver vid anv¨andning av dokumentet p˚a ovan beskrivna s¨att samt skydd mot att dokumentet ¨andras eller presenteras i s˚adan form eller i s˚adant sammanhang som ¨ar kr¨ankande f¨or upphovsmannens litter¨ara eller konstn¨arliga anseende eller egenart.

F¨or ytterligare information om Link¨oping University Electronic Press se f¨orlagets hemsida http://www.ep.liu.se/

English

The publishers will keep this document online on the Internet - or its possible replacement - for a period of 25 years from the date of publication barring exceptional circumstances.

The online availability of the document implies a permanent permission for anyone to read, to download, to print out single copies for your own use and to use it unchanged for any non-commercial research and educational purpose. Subsequent transfers of copyright cannot revoke this permission. All other uses of the document are conditional on the consent of the copyright owner. The publisher has taken technical and administrative measures to assure authenticity, security and accessibility.

According to intellectual property law the author has the right to be mentioned when his/her work is accessed as described above and to be protected against infringement.

For additional information about the Link¨oping University Electronic Press and its procedures for publication and for assurance of document integrity, please refer to its WWW home page: http://www.ep.liu.se/

c

Andreas Karlsson,Henrik Nelson Link¨oping, February 12, 2013

References

Related documents

Object A is an example of how designing for effort in everyday products can create space to design for an stimulating environment, both in action and understanding, in an engaging and

• User is out in the city and wants to show pictures stored in a home device • Using a mobile phone, user accesses the home device with the photos • The mobile phone can also be used

pedagogue should therefore not be seen as a representative for their native tongue, but just as any other pedagogue but with a special competence. The advantage that these two bi-

46 Konkreta exempel skulle kunna vara främjandeinsatser för affärsänglar/affärsängelnätverk, skapa arenor där aktörer från utbuds- och efterfrågesidan kan mötas eller

The AbstractFactory declares an interface for operations that create abstract product objects. The ConcreteFactory classes implement the operations defined by the interface

While getting a users credentials could be done by installing a keylogger on the attacker computer or by logging the requests made using Burp Suite, the method described above does

It provides an introduction to the Internet-of-Things, pervasive and ubiquitous comput- ing, context information, peer-to-peer computing, group management, the

These flow pattern data are used as inlet data to a flow simulation program in order to obtain a detailed flow pattern picture inside the flow meter under consideration.. The