Bachelorthesis

Björn Kiencke Conception and Implementation of a Software Distribution to Facilitate the Usage of an Energy Data Monitoring

Fakultät Technik und Informatik Faculty of Engineering and Computer Science Department Informations- und Department of Information and Elektrotechnik Electrical Engineering

Björn Kiencke Conception and Implementation of a Software Distribution to Facilitate the Usage of an Energy Data Monitoring System

Bachelorthesis eingereicht im Rahmen der Bachelorprüfung im Studiengang Informations- und Elektrotechnik am Department Informations- und Elektrotechnik der Fakultät Technik und Informatik der Hochschule für Angewandte Wissenschaften Hamburg

Betreuender Prüfer : Prof. Dr. Thomas Klinker Zweitgutachter : Prof. Dr. Franz Schubert

Abgegeben am 20. Februar 2013

Björn Kiencke

Thema der Bachelorthesis Entwurf und Implementierung einer Softwarezusammenstellung mit Energie- datenmonitoring-Funktionalität

Stichworte Direktstartbetriebssystem, Energiedatenmonitoring, Remastering, Java, JEVis, Ubuntu, Kernel

Kurzzusammenfassung Diese Arbeit umfasst den Entstehungsprozess einer Lösung, die Energieda- tenmonitoring für Test- und Schulungszwecke zur Verfügung stellt. Program- me zum Monitoring von Energiedaten werden eingesetzt, um die Energieeffi- zienz von Unternehmen zu erhöhen und somit den Anforderungen von Ener- giemanagementsystemen, wie sie beispielsweise die ISO 50001 vorschreibt, gerecht zu werden. Das genutzte Monitoring Programm setzt mehrere Kom- ponenten, u. a. eine Datenbanksoftware, voraus und benötigt daher erhebli- chen Konfigurationsaufwand. In der vorliegenden Arbeit wird der Ansatz eines Direktstartbetriebssystems mit Energiedatenmonitoring-Funktionalität umge- setzt. Zur Vereinfachung des Remastering-Prozesses wird ein Programm ent- worfen.

Björn Kiencke

Title of the paper Conception and Implementation of a Software Distribution to Facilitate the Us- age of an Energy Data Monitoring System

Keywords Live System, Energy Data Monitoring, Remastering, Java, JEVis, Ubuntu, Kernel

Abstract This report comprises the development process of a solution which offers energy data monitoring for testing and training. This kind of program is used to increase the energy efficiency of industrial companies and hence to implement the requirements of energy management systems according to standards like ISO 50001.The JEVis Data Monitoring System depends on several components, e.g. a database server. Therefore a huge overhead on configuration is demanded. In the thesis presented the approach of a live system to facilitate using an energy data monitoring system is taken. Furthermore, a program to simplify the remastering-process is designed. Contents

1 Introduction 1

2 Background 3 2.1 Motivation ...... 3 2.2 Envidatec GmbH ...... 4 2.3 Data Monitoring Software ...... 6 2.3.1 JEVis ...... 6 2.4 Open Source ...... 9 2.4.1 General Principles ...... 9 2.4.2 Beneﬁts for Business ...... 10 2.5 Open JEVis ...... 11 2.5.1 Analyzing the Open Source Community Structure ...... 11 2.5.2 Improvement suggestions ...... 13 2.6 Live Operating Systems ...... 14 2.6.1 Basics ...... 14 2.6.2 Operating Systems and Kernels ...... 15

3 Conception and Design 17 3.1 Use Cases ...... 17 3.1.1 Energy Data Monitoring System ...... 18 3.1.2 Creating a JEVis Monitoring Test System ...... 20 3.2 Requirements ...... 21 3.2.1 Data Monitoring Test System ...... 22 3.2.2 Distribution ...... 22 3.2.3 Solution to Create Test Systems ...... 23 3.3 Design ...... 23 3.3.1 Approach of a Live System ...... 23 3.3.2 Approach of a Remastering Program ...... 24

D 4 Implementation 25 4.1 Remastering ...... 25 4.2 Remastering in Detail ...... 27 4.3 Customization ...... 34 4.3.1 Look and Feel ...... 34 4.3.2 JEVis ...... 35 4.3.3 Presentation ...... 35 4.4 Distribution ...... 38 4.4.1 Presentation ...... 38 4.5 JEVis Live Creator ...... 38 4.5.1 Programming Techniques ...... 39 4.5.2 Execute Scripts within JAVA Programs ...... 40 4.5.3 Script Parser ...... 42 4.5.4 Presentation ...... 46 4.6 Packages ...... 47 4.6.1 Repository ...... 49 4.6.2 Presentation ...... 51

5 Conclusion and Outlook 52 5.1 Conclusion ...... 52 5.2 Outlook ...... 54 5.2.1 Integration of Datasources ...... 54 5.2.2 Further Projects ...... 56

Glossary I

List of Figures V

List of Tables VI

List of Listungs VII

Bibliography VIII 1 Introduction

Since the age of industrialization world’s economy is reliant on resources of any kind, enabling humanity to run all kinds of power taking devices, may they deliver mobility, comfort, productivity or medical capability. However, during the recent decades especially non-renewable resources are running short and although renewable energy sources are on the rise, new technology can not close the gap as quickly. Moreover, political decisions contribute to this problem significantly which has lead to a dramatic increase of energy prices since the turn of the millennium. The price of oil can be taken as a good example for this and it is commonly accepted that the peak was already reached during the last years (cf. Kausch et al. 2011, p. 11). For industry, mother earth’s signs of exhaustion and the above mentioned lack of alternatives means facing the costly effects of this development. Therefore, energy efficiency has become the key word for companies CEO’s to get control over this problem. In addition, costumers get increasingly conscious about ecological sustainability during the method of production of a product. A promising way to realize a resource-optimized method of production of such a kind is the implementation of an energy management system basically enabling the company to monitor the energy the process needs in every production step over time.

To implement a suitable energy management system companies are commonly advised by service providers. One of these is the Envidatec GmbH where this thesis was performed. For the purpose of analysis, control and surveillance energy data monitoring programs are used. In line with this thesis a modular software solution is dealt with. This implies a pedestrian and complex installation which is not appropriate for an - concerning this project - unskilled person. Within this thesis multiple concepts where established to create an easy way of testing allowing users to let the program run out of the box and by that enabling a broad audience to work with this software.

Therefore, the aim of this thesis is the establishment of an energy data monitoring live system. For this a Linux distribution was remastered. This means, that the energy data monitoring application was integrated in the OS and further minor and major modiﬁcations were performed.

1 1 Introduction

As an example of a minor modiﬁcation the adaption in design and the addition of icons for easy handling of the system can be mentioned. Furthermore, major modiﬁcations enable the user to install the OS together with the ready to run monitoring software on a local drive. With respect to the hardware available this leads to a faster system and can be used for test and research purposes. Last but not least a continuously advancing development of this software shall be facilitated since this is an open source project. For this the remastering process is implemented in a self-programmed application to provide developers an easy and time-saving way of creating a new version.

To relieve reading this thesis here is an overview of the contained sections. The second chapter gives detailed information about the motivation of implementing energy management systems. Furthermore it deals with background facts on the company, their monitoring software, issues of founding an open source community and subjects of live systems. The third and fourth chapter document the process of conception. This includes the procedure given by modern software engineering: generating use-cases, extracting requirements and specifying the design. Subsequently the next chapter is about the implementation containing explanations of the used programming techniques and examples of implementation in source code. Furthermore the results of the development are presented. The last chapter reviews the implemented solution and sketches out its advantages and disadvantages. Finally, the outlook section gives information about further steps, which are already planned.

2 2 Background

2.1 Motivation

During the last years energy economic issues have become increasingly important for companies. Limited resources available and the growing demand for energy are leading to higher prices. In addition, political decisions have impact on the price of energy. Especially in Germany, companies are encouraged to optimize their energy consumption. The feed-in tariﬀs for renewable energies whose additional costs are known as EEG surcharge raise by 2013 up to almost 5.3 ct/kWh. The contribution of the industry to achieve the planned aims implies exploiting energy saving potentials. The Policy Report by the Fraunhofer Institute by order of the Federal Ministry for the Environment Nature Conservation and Nuclear Safety sees a reduction potential of 52 percent on ﬁnal energy demand compared to the baseline. The major amount of 75 percent savings can be exploit by making use of cross-cutting technologies1 (cf. Boßmann, Eichhammer, and Elsland 2012, p. 18).

An indicator for the success of the eﬀorts is the energy productivity. It is deﬁned by the consumption of primary energy on products and services in comparison to the gross domestic product.

The reference for the derived statistic is set to 100 percent on the data of 1990. The German government is aiming to double the energy productivity until 2020 compared to 1990. As shown in figure 2.1 the value already improved by almost 50 percent. Considering the aims increased efforts are necessary. In particular the industry has to take activity for optimization. A common way to improve the energy efficiency is given by the specification ISO 50001. The process of implementing an energy management system (EnMS) according to this standard provides the tasks of monitoring, measurement, and analysis. There are certain good reasons using energy data monitoring software to implement this. The most important are the quantity of data samples

1Eﬃcient steam and hot water generation as well as optimization of entire systems relying on electric drives.

3 2 Background

Energy productivity (1990=100)

140

120

100

0 1990 1991 1992 1993 1994 1995 1996 1997 1998 1999 2000 2001 2002 2003 2004 2005 2006 2007 2008 2009 2010 2011 Year

Figure 2.1: Germany’s energy productivity (Data: DESTATIS)

delivered by energy meters and clustering of distributed data devices. That gives the opportunity to store data of various measurement points centralized to visualize, combine, and compare them. In this way data monitoring systems contribute to save energy. Therefore, a wide distribution of them is desirable. In particular the availability for university education, partners, and interested persons establishes the idea of monitoring energy data. Furthermore these interested parties participate with ideas, feedback, and work on development to improve the solution. The work done as part of the thesis aims to facilitate the distribution to encourage these processes.

The German company Envidatec GmbH, where the author was working on this thesis, oﬀers services in the ﬁeld of energy management. Company’s philosophy encloses the ideas of innovating energy data monitoring in the sketched way. The following section gives basic information about the Envidatec GmbH and its business area.

2.2 Envidatec GmbH

Envidatec GmbH was founded in 2001. The company with headquarter in Hamburg oﬀers energy services for industrial customers. Since 2008, new tasks arising from new laws and standards concerning energy management systems, e.g. the international standard ISO 50001, have been evolved for the company.

4 2 Background

Figure 2.2: Energy management system model (Source: International Organization for Standard- ization 2011, p. 8)

The model shown in ﬁgure 2.2 describes the approach of the energy management system model according to ISO 50001. It is implemented as a plan do check act circle that is often used in business economics.

Plan: conduct the energy review and establish the baseline, energy performance indi- cators, objectives, targets and action plans necessary to deliver results in accor- dance with opportunities to improve energy performance and the organization’s energy policy.

Do: implement the energy management action plans.

Check: monitor and measure processes and the key characteristics of its operations that determine energy performance against the energy policy and objectives and report the results.

Act: take actions to continually improve energy performance and the EnMS.

(see International Organization for Standardization 2011, p. 7)

5 2 Background

Appropriate to services like energy eﬃciency analyzes or creating guidelines for energy management Envidatec provides its own energy data monitoring software:

Additionally, the Envidatec GmbH provides a software for automated logging, analyzing and visualization of energy and operating data, the JEVis system. This monitoring solution has been distributed meanwhile as open source license. It will not only be used by commercial companies but also from many universities world- wide. For this reason the Envidatec GmbH has built up an international university network for research and development topics based on the JEVis system.

(see Envidatec GmbH 2013, p. 2)

As a part of the already mentioned research and development program the author handled a project at the Envidatec GmbH, which is the topic of this thesis. The structure of Envidatec’s data monitoring software is brieﬂy described in the following section to phase in technical background of the work.

2.3 Data Monitoring Software

The role of data monitoring software in the process of implementing an energy management (according to ISO 50001) is enabling identiﬁcation of weaknesses, measurement of improvements, and a possibility to protocol eﬀorts.

2.3.1 JEVis

The JEVis Energy Data Monitoring solution appears to the end user in form of a portal page that contains links to two java programs. To launch these programs Java Web Start technique is used. To launch a program according to this technique a Java Network Launching Protocol (JNLP) ﬁle is deposited on a server. It contains information about the path to the program, the name of the main class and additional parameters for the program (cf. Marinilli 2002, p. 272). Since the path can be a network resource the user has the beneﬁt of getting an always up to date software.

After logging in to the JEGraph program the user can load previously saved analyses. The user is able to add data rows to plugins, set threshold limits, zoom into graphs and link plugins.

6 2 Background

Figure 2.3: JEVis data monitoring software

Taking a closer look on the third plugin displaied in figure 2.3 a vibration of the machine can be seen. Knowledge of consumption helps to scale machines correctly to exploit their best efficientcy point. Advanced tasks can be done in the second program JEConfig, which offers alarming, set up of devices, user management and Octave (MATLab syntax) calculations.

Structure of the JEVis System

Like quite a number of other complex software the JEVis data monitoring system contains multiple modules and various participants. The server is the most complex component in the system. Its sub-modules provide diﬀerent functionality. For example this contains the task of controlling necessary operations like requesting data from measurement points will be done by the server. The second type of component are data-sources in the measurement infrastructure. Typically these are devices like common industrial energy-meters. The task of visualization is implemented in software on client machines. The technical structure of the JEVis Energy Data Monitoring solution is shown in the following ﬁgure.

7 2 Background

Server

Database

Servlet Container

JDBC

JEWebService

axis 2

JECAPI

Client Measurement

JEGraph JEConﬁg Device

Figure 2.4: JEVis System Setup

The activities of the JEVis System components shown in ﬁgure 2.4 can be brieﬂy described as follows:

Server

The server assumes the role of data storage. It is the interface between the data producers that are summarized as measurement infrastructure and client devices that display charts and analyses.

Measurement Infrastructure

JEVis supports connecting diﬀerent types of engergy meters. Connections are realized via the JEADFWeb tool, that supports various web protocols. It includes functionality for HTTP, FTP, SOAP, and SQL web protocols. The data can have CSV or XML format. At the moment a second but already deprecated option exists, that implements a direct connection to the JEWebService. The principle is explained in detail within the section about including data sources 5.2.1.

8 2 Background

The JEADFWeb can read out data from any device, that is reachable via that protocols and which’s data is stored in one of that formats. If a device needs a protocol or format that has not been added yet, the tool is easily extendable: When creating a data structure in the JEVis System, every device gets its driver. You can add the driver parts oﬀered by the system, or add you own one.

(see OpenJEVis.org 2013[a], p. 2)

Clients

Every PC with Java environment can be a JEVis client if the server is reachable inside client’s network. The client software programs JEGraph and JEConﬁg oﬀer a login dialog on start-up. Therefore, users can log in to the monitoring system using their accounts on any machine.

Remarkable on the JEVis Energy Data Monitoring Solution is the fact it is an open source software. Thus, the next section gives an insight into topics around open source.

2.4 Open Source

The success of a software essentially depends on users acceptance. Therefore software developers rely on feedback from them. Particularly in the case of software with limited distribution and any budget for usability testing the contact to the customer is crucial. This way of software development is a remarkable feature about open source and speciﬁcally about OpenJEVis. With other general characteristics deals the following chapter, while section 2.4.2 outlines the beneﬁts of open source.

2.4.1 General Principles

The open source initiative was founded in 1998 by Eric Raymond and Bruce Perens. It is the committed aim to encourage the idea of open source. Therefore they are distributing an overview about existing open source licenses (see Bandel 2010, p. 8). There is a list of ten points available on the oﬃcial Open Source website that enumerates the general principles of this kind of software. They are meant to be essential preconditions for successful and eﬀective software engineering:

1. Free redistribution

9 2 Background

2. Source code

3. Derived works

4. Integrity of the author’s source code

5. No discrimination against persons or groups

6. No discrimination against ﬁelds of endeavor

7. Distribution of license

8. License must not be speciﬁc in a product

9. License must not restrict other software

10. License must be technology-neutral

(cf. Open Source Initiative 2012)

Without getting too much into detail the most important points shall be explained: One of the main aspects about open source besides its free distribution (no. 1) is that modification and copying of a source has to be permitted (no. 4). This concept is realized with a specified license model (no. 7 to 10). To be more concrete, both use and release must be allowed as an executable file (no. 2). Furthermore, it is to stress that there do not exist any restrictions against certain groups of users and fields of activity what can be seen as a great enrichment of open source (no. 5 and 6). (see Envidatec GmbH 2012).

2.4.2 Beneﬁts for Business

What is the motivation for businesses to support open source projects? Which specific benefits can be advertised? These questions will be answered in this section. In the concept of open source proprietors, a management or employees do not exist. Therefore anybody has the right to profit from the usage, development or change of the software (see Nüttgens and Tesei 2000, p. 10). As explained in the section below, the concept of open source is network based meaning that many participants are developing a product. Also commercial businesses are getting more and more interested in open source – in other words: They pursuit being part of that network. In general, a successful process results in a collective increase of efficiency, which in turn has positive effects on the competitive position of a single company (see ibid., p. 13). Getting more into detail, new business models which belong to the new strategy of involving open source software can result

10 2 Background in proﬁt (see Bandel 2010, p. 5). An abstract of business models that are already implemented in companies business strategies are listed below:

• Companies distribute open source software to generate potential customers for additional, compatible software products that are chargeable.

• Companies like RedHat oﬀer chargeable support and service contracts binded to the open source software they distribute.

• Companies like Apple oﬀer chargeable hardware, e.g. a mobile phone, in combination with software applications that base on open source software (see ibid., pp. 53-54).

To summarize the increase of the consumer surplus is the main motivation of enclosing open source software in a business strategy. Businesses are highly interested in the know-how, skills, and creativity of the open source community to have advantages in the competition. Furthermore, they have low hardware costs and beneﬁt from the free testing within the community (see ibid., p. 54). All in all the coexistence of open source software and proprietary software products inspirit the market.

2.5 Open JEVis

Envidatec points out to oﬀer the monitoring software as open source. As its basic strategy for further charged services this is an unique selling point of the company. The realization of the development as open source keeps several advantages. This business model enables external partners to participate on increasing the function range of JEVis. Hardware manufactures and universities are typical partners.

2.5.1 Analyzing the Open Source Community Structure

The approach of an open source project needs some special infrastructure. One basic thought is to make hurdles to entry as low as possible. The mindmap show in ﬁgure 2.5 deals with the important aspects when getting in touch with JEVis.

11 2 Background

Attention

Community Information

Get started Testserver Account Documen- Testing tation Virtual Machine Installation Live System

Installer Package Manual Concept

Figure 2.5: Get in touch with JEVis

The mindmap displays the process of getting in touch with Jevis resp. the OpenJEVis Commu- nity from the viewpoint of a person which is interested in an energy data monitoring solution. Starting from this the aspects are visualized in ﬁgure 2.5 and annotated in the following. Thus, the ﬁgure contains the analysis of the existing structure and ideas for improvements which are formatted underlined and italic.

Attention

The first hurdle for a software is to be noticed by potential users. In addition to the traditional distribution channels and online presence there are some special ideas fitting well to the open source philosophy. Workshops about energy efficiency and online events like the OpenJEVis Days are already practiced by the company.

12 2 Background

Information

In the following the user’s impression depends on quality of the information and communication. The most important platform for sharing information is the community website.

Testing

In the case of the information have convinced the user, he will make concrete efforts to check whether the software fits to his requirements. While working on the thesis the common option to test the software was to create a guest account. New ideas are addressed to advanced users who want to have their own system. Both concepts base on an operating system with an “out the box” running monitoring system. Benefits of using a separate system are undisturbed trying without registration and full control of own data.

Installation

For productive usage of the system a customized installation is necessary. A comfortable technology to install and update software known as “package managers" exists for linux systems. This tool may be interesting for simple JEVis installations.

Community and Documentation

All other nodes deal with structural organization. As usual for open source projects documentation and communication issues are placed on the community website.

2.5.2 Improvement suggestions

The structure of an open source project has to be considered to assess weaknesses correctly. Aspects like transparency, quality of communication, and documentation contribute a lot to the success of a project. Detecting the most critical aspects was done before start working on this thesis and are identified within the offers of testing and installation: The option of a guest account requires the user’s action on registration. An incentive for users that do not want to register is a live system which offers easier testing and the possibility to apply own changes without any risk. The work on this live system with energy data monitoring functionality is the central purpose

13 2 Background of this thesis. Another suggestion in the scope of installation is the package concept which is used on Linux operating systems to organize installations and updates. Intending to fulﬁll as many improvement suggestions as possible chapter 3 speciﬁes usage scenarios and the resulting requirements on the software distribution.

2.6 Live Operating Systems

Thus, the solution of a live system seems adequate the following section overviews its history and its actual importance.

2.6.1 Basics

One of the most important milestones in the young history of live systems was Knoppix Linux. It was developed by the German engineer Klaus Knopper, who published the ﬁrst version of his live system in the year 2000. In the preface of “Knoppix Hack”, he said his idea was driven by giveaways. At that time, Linux based rescue discs were given away at computer expos and Knopper started his work on a “personal rescue CD” (cf. Jones 2008, pp. 11-12).

That way, it would be possible to use software that I needed from a CD, rather than carry around an expensive and fragile laptop. Computers are available everywhere anyway, so why not just have the software in your pocket instead.

(see Knopper and Rankin 2007, foreword)

The sparsely standardized hardware for computers is reasoning the central problem of a live system: the hardware support. Because the approach of minimal hardware requirements is not suitable for most of the software the live system, first of all, has to provide automatic configuration of PC hardware. The second important technology is the compression of containing software that makes it possible to provide a whole working system on a single CD. The question that arises is why open source operating systems could occupy the field of live systems without appreciable competitive. R. Hattenhauer instances economic interest of the big software manufacturers to sell as much as possible full versions (cf. Hattenhauer 2005, p. 16). Since that time, more and more projects of live operating systems with highly diverse functional range have been started. Nowadays, the majority of Linux distributions are shipped with the functionality of a live system. There are almost hundred active Linux distributions that provide a live medium

14 2 Background listed at www.distrowatch.com, a website that provides overview on Linux distributions. In fact, the popularity of diﬀerent distributions varies quickly but there are some base frames that are steadily gaining popularity. The family of Debian based distributions is the biggest of the base frames. The most famous member is Ubuntu and its fork Mint. The second big player is Fedora that is supported by the company RedHat. The next section deals with basics on operating system and the diﬀerences between the underlying concepts.

2.6.2 Operating Systems and Kernels

To facilitate the comprehension of the work, this section gives overview on the underlying concepts of operating systems. Most operating systems are using kernels and the basic idea is for all of them the same: provide the interface between hardware and software.

Applications

Kernel

Hardware

Figure 2.6: Layers on a PC system

As shown in ﬁgure 2.6 the kernel can be regarded as the connecting part between application and hardware layer. It provides the lowest level abstraction layer for resources (as devices, CPU and memory) that usually uses system calls and inter-process communication. 2

There are two classical designs of kernels with diﬀerent advantages. One concept known as monolithic kernels uses address space to execute all operating system code. The other concept is the family of micro kernels that are using the user space to run most parts of the operating system. The beneﬁt is a modular implementation with better maintainability. On the other hand using servers in user space generates much more communication overhead compared with direct function calls used in monolithic kernels. That promises better performance of systems with monolithic kernels.

2For more detailed information about functionality of Unix based operating systems the lecture script of "Echtzeitbetriebssysteme" by Prof. Dr. Schneider (HAW) is highly recommended.

15 2 Background

The evolution of operating systems led to new kernel concepts with the intention of combining advantages of both kernel implementations. The approach of hybrid kernels makes use of both concepts in the way of running some important services (e.g. network stack) in kernel space to reduce performance overhead. Speciﬁc codes like drivers are still running as servers in user space. Modern generations of Microsoft Windows and Apple Mac OS X belong to this group. Linux belongs to the family of Unix-like operating systems that use monolithic kernels. However the monolithic concept is enhanced of the functionality to provide loading of modules at running time. These modular kernels are able to load binaries to kernel space on demand. Once the background of live operating systems is considered, the next chapter focuses on the origin problem again.

16 3 Conception and Design

3.1 Use Cases

Before start thinking on concrete implementation some basic work on the deﬁnition of scenarios and the resulting requirements has to be done. The idea of textual, structural and visual modeling techniques for specifying use cases were formulated by Ivar Jacobson in 1986. Nevertheless, these techniques are part of modern software engineering approaches like eXtreme Programming. The template style used here is the casual use case structure deﬁned by Alistair Cockburn (cf. Cockburn 2001, p. 236). This use case template consists of title (goal), primary actor, scope, level and the story. The story is the body of the use case and contains a short text that describes informally what happens. The description of possible scenarios is split up in two general points of view. On the one hand scenarios of end users like customers and potential new community members are shown. On the other hand there are the necessities of the company have to be taken into consideration.

17 3 Conception and Design

3.1.1 Energy Data Monitoring System

The following use case include the scenarios that belong to the features of the live energy data monitoring system. They are formulated as generic as possible to enable diﬀerent approaches. The idea is to document the interests in a short and clear way.

Use Case 1 Test JEVis Energy Data Monitoring System

Primary Actor: End-User

Stakeholders and • Customer: Get an impression of the software. Interests: • Training: Provide a training system for each participant.

• Marketing: Showcase JEVis even if network is not available. Get in contact with interested parties.

• Developer: Test developed software in a sandbox environment.

Scope: JEVis Energy Monitoring System

Level: User-goal

Main Scenario:

1. The actor is interested in testing the monitoring solution. He can get the software online or on a memory medium. With the help of the enclosed documentation the user can start the monitoring software and try it out by means of sample data.

18 3 Conception and Design

Extensions: 1.a Communication:

1. The actor is informed about news concerning the monitoring software.

2. Extentions are oﬀered to the actor after registration on website.

1.b Sandbox system:

1. The actor can save changes.

2. The actor can restore test system to original state.

1.c The actor can install the monitoring system.

To visualize the interests listed above a use case specialized UML diagram can be used. Figure 3.1 shows use case 1.

JEVis System JEVis System

Training

Customer Envidatec

Testing Service Interested Person

Research Associate

Figure 3.1: UML use case diagram of use case 1

The use case package “JEVis System” includes the use cases training and testing. The actors are associated to the use cases with lines. The actor “Interested Person” inherits the “Research Associate” actor. Figure 3.1 simpliﬁes the tabular use case.

19 3 Conception and Design

3.1.2 Creating a JEVis Monitoring Test System

The continuous development of Linux and the monitoring software leads to the use case of managing to create new versions of the live system. The stakeholder is in this case the company.

Use Case 2 Create JEVis Monitoring Test System

Primary Actor: IT specialist of the company

Stakeholder and Interest: Company: Oﬀer easily up to date versions

Scope: JEVis Energy Monitoring System

Level: Company-goal

Main Scenario:

1. The actor can create a test system according to use case 1.

2. The actor can update the test system when a new version of JEVis data- monitoring solution is released.

Extensions: 2.a Customization:

1. The actor can customize the test system.

2. The actor can distribute the test system.

2.b Distribution:

1. The actor can choose between diﬀerent distribution media.

On basis of the use cases the requirements on the solution are determined in chapter 3.2.

20 3 Conception and Design

3.2 Requirements

As done before in the use cases chapter, the requirements on the test system and the creation process will be discussed separately. For professional development a standard of IEEE on software requirements specification exists. Although a specification of requirements according to the aforementioned IEEE 830 goes beyond the scope of this thesis, a minimal discourse follows. Requirements specify what features are expected. In the context of software engineering this means the expectation of a stakeholder on a software system. The term stakeholder generalizes all parties involved in system’s requirements (cf. Balzert 2009, pp. 455-456). Requirements are classified in functional and non-functional ones. The functional group defines functions provided by the software system. Non-functional requirements by contrast define the way of doing. Requirements should fulfill the following characteristics: unitary, complete, consistent, atomic, traceable, current, unambiguous and verifiable (cf. IEEE Computer Society 1998, p. 4).

The ﬁgure 3.2 of the process splits the problem into three diﬀerent aspects.

Figure 3.2: The aspects of scope

The ﬁrst aspect represents the requirements that result from use case 2. The second box deals with the options of distribution. The last and most important aspect contains the requirements on the implementation of the solution to provide the data monitoring system.

21 3 Conception and Design

3.2.1 Data Monitoring Test System

The table below lists the direct (1) and indirect (2) requirements that result of requirement no. 1.4.

No. Description 1 Test data monitoring system 1.1 Can run on PCs 1.2 Can run without network connection 1.3 Can display news 1.4 Gets along with any installation 1.5 Offers a complete JEVis system 1.6 Offers an installation routine for JEVis system 2 Environment 2.1 Installed Java JDK runtime environment 2.2 Installed and configurated Tomcat Java Servlet and server 2.2.1 Axis2 Web Services Engine 2.3 Installed and configurated database

Table 2.1: Requirements on the test system

3.2.2 Distribution

No. Description 3 Distribution 3.1 Provide creation of copys 3.2 Supports various distribution channels

Table 2.2: Requirements on distribution

22 3 Conception and Design

3.2.3 Solution to Create Test Systems

No. Description 4 Creation 4.1 Process is reproducible 4.2 Can be done within appropriate time

Table 2.3: Requirements on the solution to create test systems

Once the requirements are deﬁned the concept for further development can be ﬂeshed out in the following.

3.3 Design

This section is about the design decisions. In the first step the requirements that call for decisions will be identified and the questions on design will be formulated. In the second step approaches to solve tasks begged by the questions are discussed and finally design specifications are generated.

3.3.1 Approach of a Live System

The requirements on the environment for the data monitoring test system (prefix 2) are leading to a central problem. As the section 2.3.1 about the structure of JEVis points out the requirements no. 2.1 to 2.4 are the basis for running JEVis. The JEVis Installation Manual (see OpenJEVis.org 2013[b]) shows on nine pages how to install and configurate Java JDK runtime environment, Tomcat Java Servlet Server, Axis2 Web Services Engine, MySQL Database and finally JEVis. This overhead for a simple installation contradicts to requirement no. 1.4 that implies no installation is necessary for testing the energy monitoring solution. Consistently the test solution needs to contain the environmental requirements. The options to afford this facility are the approaches of both portable applications and live systems. A Portable Application is a standalone program that runs on compatible operating systems without being installed. Al- though there exist portable applications that have managed the implementation of a needed environment1 managing the major difficulty to accomplish the requirements on the environment.

1To name an example XAMPP is working as an completely portable webserver.

23 3 Conception and Design

Moreover requirement no. 1.6 that implies oﬀering an installation possibility is hard to realize.

The second approach of a Live System contains many capabilities. As already mentioned in section 2.6.1 several derivatives of live systems with highly diverse scopes already exsist. Almost all JEVis system installations up to now are running on Linux servers. While only a marginal group of desktop computers uses Linux, the number of servers running Linux keeps growing (cf. Vaughan-Nichols 2013). Even today working with Linux on servers is not unusual. Pondering the pros and cons of the possible solutions leads to the design decision to use a Linux Live System to manage the tasks.

3.3.2 Approach of a Remastering Program

In due consideration of requirements no. 4.1 and 4.2 it is incidental to automate the process of creating new versions of a live system. The program shall be able to guide the remastering process without resticting the options on customization. Furthermore, the program has to oﬀer a possibility to copy the remastered live system onto media. Because of the necessary shell commands the program is only runnable on Linux operating systems. Many design decissions on the program design depend on the further work on the live system and can not be formulated at this stage. The next chapter starts with the implementation of remastering.

24 4 Implementation

This chapter is structured as follows: Each scope of implementation is justified, exemplary car- ried out and finally presented. Structuring the tasks like previously done in the requirements chapter lead to the topics remastering, distribution and live system as shown in figure 4.1.

Figure 4.1: Aspects of scope

The result of an energy data monitoring live system requires a distribution and the process of remastering. The term remastering is taken from the audio production process and describes the process of customizing an operating system or software. Taking account of the structure of operating systems which was topic of section 2.6.1 remastering of an operating system requires many steps to customize the diﬀerent parts of it.

4.1 Remastering

Before the decision to implement remastering with low level commands was taken, existing tools were tested for their suitabiliy for the task of creating a data monitoring live system. Systems that are qualiﬁed to be base frame are Knoppix, Ubuntu and Fedora. Taking into account the wide distribution, dynamics of development, and good community structure Ubuntu is favored.

25 4 Implementation

For Ubuntu exists the customization tool “Ubuntu Customization Kit”. The user can enter a path to an up to date Ubuntu image. With UCK it is possible to chose the display manager, set names, and add software. The tool oﬀers to create a set of languages that will be available on live system.

UCK is a tool that helps you customizing oﬃcial Ubuntu Live CDs (including Kubun- tu/Xubuntu and Edubuntu) to your needs. You can add any package to the live system like, for example, language packs, applications, etc.

Features: Create bootable LiveCD with predeﬁned languages based upon an original Ubuntu/Kubuntu live CD using graphical wizard. Build live CD with special features using scripts. It is possible to customize the root ﬁlesystem (for example install/remove packages), ISO contents (add/remove docs, change names) and initrd (add modules to boot, change boot sequence).

(see Balliano and Lichota 2013)

An other approach is implemented via the Remastersys tool. This program oﬀers the option to create a backup or a live system from the running operating system. Many customizations like default live session user, choice of plymouth boot theme or GRUB background image can be applied. This program appeals to be most matured of all tested alternatives. Certainly the options for customizing other modules of the live system are not given and on testing occurred problems.

Remastersys is a tool that can be used to do 2 things with an existing Debian, Ubuntu or derivative installation.

It can make a full system backup including personal data to a live cd or dvd that you can use anywhere and install. It can make a distributable copy you can share with friends. This will not have any of your personal user data in it. The resulting iso ﬁle can be used on any other PC that still meets the original minimum requirements of Ubuntu or Debian. Things like the graphics card and other hardware will be conﬁgured and setup automatically and you do not have to use identical hardware. Ubuntu’s live boot tool, casper, currently blacklists Nvidia and AMD proprietary drivers so they will not be available on the live system and will need to be reinstalled after installation of your custom system.

26 4 Implementation

(see Remastersys.com 2013)

The main disadvantage of the tested tools is the missing possibility to run the database server during the remastering process. For the installation of JEVis a database is required. Taking into account the previously listed problems the way of manual remastering which means doing it without existing programs with graphical user interface is chosen.

4.2 Remastering in Detail

To understand the functionality of live systems and spot the steps of remastering the parts of a live system are shown in 4.2 and are discussed in the following.

Figure 4.2: Components of a live system

Usual mediums to distribute operating systems are compact discs (CD), digital versatile disc (DVD) and newly USB flash drives or flash media cards. The crucial difference between disks and flash drives is the option of savings on the medium at runtime. Furthermore the time needed for loading the system depends on used medium. The medium contains a bootable partition, bootsectors and is marked as bootable. This enables the start of bootmanager when BIOS calls system start on the device. The bootmanager organizes start of basic operating system with optionally state of arguements. As explained in 2.6.1 linux basic systems are made up of kernel and kernel modules. For live systems this includes a lot of drivers in basic configuration. To complete the setup basic programs like a window manager are provieded. The possibility of persistent storage can be realized by adding a partition or a persistent file.

27 4 Implementation

Prepare System

Extract Image

Extract Live-System

Edit Live-System

Pack Live-System

Create USB-Stick

Figure 4.3: Sequence of remastering process

The remastering steps shown in figure 4.3 result from the knowledge of the components of live system media. The different images are extracted into folders on the host system. Once the data is copied changes can be applied and finally the new system can be packed again. The following paragraphs are dealing with more detailed information about the steps in the remaster process.

Prepare Creating System

Starting point for the system to create a new version of live system is Ubuntu 12.04 LTS installation with default software selection. In expectation of using a 32 bit architecture image it is a good idea to use a creating system with same architecture. Some additional tools are needed during remastering process.

1 sudo apt−get install squashfs −t o o l s

Listing 4.1: Prepare

28 4 Implementation

To install the needed programs the command line tool apt-get is used. Squashfs-tools are needed to extract and compress ﬁle system images in squashfs ﬁle system format. In the following many commands need higher rights. These rights can be granted with the sudo command.

of lines

Extract Image

1 # Make Work Folder and Enter

2 mkdir JEVisLive_v${VERSION}

3 cd JEVisLive_v${VERSION}/

5 # Mount Image and Copy

6 mkdir i s o

7 sudo mount −o l o o p ${SRCIMAGE} . / i s o /

8 mkdir c p i s o

9 sudo r s y n c −a ./iso/ ./cpiso/

10 sudo umount ./iso

11 r m d i r . / i s o

Listing 4.2: Extract Image

By using the mount and the rsync commands (line 7-10) a copy the content of an Ubuntu hybrid image1 is saved to the remaster directory. Many tries of remastering failed because of using the rm command. It seems like some files or links are not copied correctly with it. The workaround on this problem is using rsync for exactly copying files. Related to figure 4.2 the components are now located in the directory as listed in table 2.1.

1Images that can be used to create CDs and USB media

29 4 Implementation

Part Location Bootloader configuration boot/grub/grub.cfg Kernel casper/vmlinuz Kernel modules (RAM filesystem) casper/initrd.lz System data (SquashFS filesystem) casper/filesystem.squashfs Persistent memory Second partition labeled as casper-rw

Table 2.1: Location of system contents

Extract Live-System

The compressed image that contains the system data of the live system gets unpacked in a separate directory.

1 sudo mount −t s q u a s h f s −o loop ./cpiso/casper/filesystem.squashfs ./casper/

2 mkdir cpcasper

3 sudo r s y n c −a ./casper/ ./cpcasper/

4 sudo umount ./casper

5 rmdir ./casper

Listing 4.3: Extract Live-System

When the copy with rsync was successful the mount-folder can be deleted. The copy is now the starting point for editing the live system.

Edit Live-System

To customize the operating system the extracted live system can be entered with the chroot command. With this command it is possible to change the root directory on terminal. Several tasks have to be done to customize the system. Many of them can be realized by using the Debian Package concept which is topic of section 4.6.

1 # Prepare Chroot

2 sudo cp /etc/resolv.conf /etc/hosts ./cpcasper/etc

3 mkdir ./resources

30 4 Implementation

4 sudo mount −o bind ${RESOURCES} ./ cpcasper/mnt

6 # Enter Chroot Install Software and Create Default User

7 sudo chroot ./cpcasper/

8 mount −t proc none /proc

9 mount −t sysfs none /sys

11 # Add Repositorys

12 sudo add−apt−r e p o s i t o r y −−y e s "deb http://archive.ubuntu.com/ubuntu $(lsb_release -sc) universe"

13 sudo add−apt−r e p o s i t o r y −−yes ppa:webupd8team/java

14 sudo add−apt−r e p o s i t o r y −−yes ppa:gwendal−l e b i h a n −dev/cinnamon−s t a b l e

16 sudo apt−g e t update

17 # sudo apt−g e t upgrade

19 # Install Java

20 sudo apt−get install oracle −java6 − i n s t a l l e r

21 echo "JAVA_HOME=/usr/lib/jvm/java-6-oracle/" | tee /etc/environment

23 # Remove Software

24 sudo apt−get purge openjdk −∗

25 sudo apt−get purge gnome−games−data

26 sudo apt−get purge unity −l e n s −s h o p p i n g

27 sudo apt−get purge rhythmbox

29 sudo dpkg −− install /mnt/plymouth−theme−openjevis .deb

30 sudo update−alternatives −−config default.plymouth

31 sudo apt−g e t i n s t a l l −−yes cinnamon

33 # JEVis Installation Dependencies

34 sudo apt−g e t i n s t a l l −−yes tomcat6 libtcnative −1 mysql−server openssl unzip octave

35 echo "JAVA_HOME=/usr/lib/jvm/java-6-oracle/" | tee /etc/default/tomcat6

37 # Add Default User

38 adduser jevis

39 # passwd −d jevis# Remove Password

40 usermod −aG sudo jevis

41 e x i t

43 # Enter Chroot with Default User

44 sudo chroot ./cpcasper/

45 su j e v i s

46 # JEVis Installation

47 sudo mkdir /opt/jevis

48 sudo chown jevis:jevis /opt/jevis

49 sudo usermod −a −G tomcat6 jevis

31 4 Implementation

50 e x i t

51 su j e v i s

52 unzip /mnt/JEVis_2_2_0_20121026. zip −d ~/

53 cd ~/JEVis_2_2_0_20121026/

54 j a v a −jar ./JEInstaller.jar

55 mv /var/ lib /tomcat6/webapps/ROOT /var/ lib /tomcat6/webapps/OLDROOT

56 l n −s /var/lib/tomcat6/webapps/jevis /var/lib/tomcat6/webapps/ROOT

57 sudo service mysql restart

58 sudo service tomcat6 restart

59 e x i t

60 e x i t

Listing 4.4: Edit Live-System

The preparation of the chroot environment is done in lines 1-4 and includes overwriting the network configuration with the files of the host system. This is necessary to etablish a connection within the chroot environment. Additionally a shared folder is linked to the environment. Up next one of the most important steps for remastering is taken: The chroot command allows to change the root directory within the terminal window. Furthermore the current user of the terminal changes to root user. This implies the possibility to apply changes to the content of the directory in the way it can be done usually only within a running system. The proc and sys folders contain system information which is necessary for execution of programs. The mount commands (lines 7-10) provide the integration of this file system contents. At this point the requirements to install and uninstall software are fulfilled. Lines 11 to 35 illustrate the removal and the adding of software packages and repositories exemplarily. The following lines perform the installation and configuration of the data monitoring system. The biggest problems while the installation of JEVis as illustrated are caused by system services: the Tomcat server and the MySQL database service have undocumented requirements on the chroot environment. For example the installation fails when a MySQL service is already running on the host system. Furthermore the re-logins done are required to apply the set user-rights.

Pack Live-System

When the customization of the live system is finished the directory containing the edited files has to be packed again. Furthermore a list of installed packages is needed. The filesystem.manifest file lists packages used on the live system. The filesystem.manifest-desktop contains a list that is needed for a system installation of the distribution.

32 4 Implementation

1 sudo su

2 # Generate Package−L i s t s

3 chroot ./cpcasper dpkg−query −W −−showformat=’${Package} ${Version}\n’ > ./cpiso/casper /filesystem .manifest

4 cp ./cpiso/casper/filesystem.manifest ./cpiso/casper/filesystem.manifest −d e s k t o p

6 # Compress Live −System

7 rm ./cpiso/casper/filesystem.squashfs

8 mksquashfs ./cpcasper/ ./cpiso/casper/filesystem .squashfs

10 # Override Initrd.lz

11 cp ./cpcasper/boot/initrd .img∗ ./cpiso/casper/initrd .lz

12 e x i t

Listing 4.5: Pack Live-System

Create USB-Stick

Finally the USB ﬂash device has to be prepared for the generation of live system device. In order to this old partitions are removed, new partitions are created, formatted, and the edited system is copied to the device.

1 DEV=/dev / sdc

3 # Create Partions

4 sudo umount ${DEV}∗

5 sudo p a r t e d −s ${DEV} rm 1

6 sudo p a r t e d −s ${DEV} rm 2

7 sudo p a r t e d −s ${DEV} rm 3

8 sudo p a r t e d −s ${DEV} mklabel msdos

9 sudo p a r t e d −s ${DEV} mkpart primary fat32 5 30%

10 sudo p a r t e d −s ${DEV} mkpart primary ext2 30% 60%

11 sudo p a r t e d −s ${DEV} mkpart primary fat32 60% 100%

12 sudo p a r t e d −s ${DEV} set 1 boot on

13 sudo mkfs.vfat −n JEVisLive ${DEV}1

14 sudo mkfs.ext2 −L c a s p e r −rw ${DEV}2

15 sudo mkfs.vfat −n Resource ${DEV}3

17 sudo umount ${DEV}1

19 # Copy

20 sudo mkdir ./par1

33 4 Implementation

21 sudo umount ${DEV}1

22 sudo mount ${DEV}1 ./par1

23 sudo r s y n c −a ./cpiso/ ./par1

25 # Install Bootloader

26 sudo grub− i n s t a l l −−boot−directory=./par1/boot −−no−floppy ${DEV} −−f o r c e

27 sudo cp ./resources/grub.cfg ./par1/boot/grub/grub.cfg

Listing 4.6: Create USB-Stick

To copy the live system onto a USB flash device the media first has to be partitioned and formatted. This tasks are done with lines 4 to 17. After the preparation of the media is complete the system is copied to the device (line 23). Finally the boot manager has to be installed onto the media und the configuration of it gets overwritten (lines 26 and 27).

4.3 Customization

There are certain parts of a live system that can be customized to match the style guidelines of the community. In addition the data included in delivery has to be deﬁned.

4.3.1 Look and Feel

The desired aim of an uniform appearance of products, projects and documentation implies customizing parts of the live system. Some components are editable with appropriate effort. Regarding a live system from users point of view the boot routine is the first seen component which is editable. The boot manager offers two operating modes: The default mode starts the system with the opportunity of savings while the save mode does not permit storage of data. Once the user has chosen an option the boot routine continues. It encloses loading of kernel, kernel-modules and systems data while displaying a boot animation. The live system uses a customized boot screen which is implemented on a system named Plymouth. There exist examples of creating own boot animations. When booting is finished an automatic log in with the default JEVis user is performed. Now the display manager is already started and the user is able to handle the system. Assuming that most of the users are familiar with Microsoft Windows the Cinnamon Display Manager that is similar to it is installed.

34 4 Implementation

4.3.2 JEVis

To test the monitoring system feasible data to analyze are necessary. A set of suitable data for testing exists on the OpenJEVis Alpha Test Server. Data can be copied with the mysqldump command. During the remastering process the exported ﬁle has to be imported to the live system’s database. No longer used data have to be deleted and additionally a clean up of the database has to be performed.

4.3.3 Presentation

Figure 4.4: Customized boot screen

Figure 4.4 shows the animation that is displayed while starting the system. The logo is a transparent png image and the animation scripts enables glowing of the images contours.

35 4 Implementation

Figure 4.5: Desktop environment

Figure 4.5 shows the desktop provided by the Cinnamon display manager. The customizations aims to create a intuitive for most users with similar desktop concepts to Microsoft Windows.

Figure 4.6: Test the Monitoring Solution

The JEVis Live System contains a customized portal page. This page is able to detect an internet connection and can display content loaded from the update.openjevis.org server. If no connection is available the portal page displays the default content.

36 4 Implementation

Figure 4.7: Test the Monitoring Solution

The already included example data enables the possibility to test the functions of the JEVis programs. For the most users JEGraph is the starting point like shown in 4.7 For advanced users jobs like MATLab calculations can be conﬁgured with JEConﬁg and the menu items provide the possibility to start the calculation, which is on a normal system started periodically.

Figure 4.8: Installation Routine

For users that decides to work with JEVis the installation routine of the live system is useful. The

37 4 Implementation dialog captured in ﬁgure 4.8 guides the installation and oﬀers many options for the installation.

4.4 Distribution

The options on distribution of the presented live systems are DVD’s, offering download and USB flash devices. The option of using DVDs as media is impracticable because savings are not possible. Envidatec’s management decided to use the option of USB flash devices. The reasons are the usability of them in connection with events like workshops and trainings.

4.4.1 Presentation

Figure 4.9: JEVis USB ﬂash device

The chosen USB flash devices have a size of 8 GB and are labeled with the JEVis logo. The speed of the live system depends highly on the used flash media. While a high performance USB flash device boots the live system within 50 seconds 2 ordinary flash devices needs approximability two and a half minute.

4.5 JEVis Live Creator

The approach a of remastering tool previously discussed in section 3.3.2 aims to facilitate more comfortable editing of the live systems. That includes on the one hand the possibility to do settings on the customization and on the other hand to provide the procedure to copy it on

2tested with a Kingston DataTraveler Ultimate G2 3.0 on a USB 3.0 supporting PC.

38 4 Implementation

flash devices. In consideration of the possibilities for program’s design the questions arises which programming language is to use. Of course C has to be debated because it offers good access to command line functions. Even today many programs especially on Linux are written in C and indeed there are also libraries available to create graphical user interfaces. For example the GTK+ (Gimp Tool Kit) contains a lot of GUI components. Nevertheless an object orientated programming language establishes more comfortable development and usage of design patterns. Within the scope of the study of electrical engineering the opportunity of learning fundamentals on object orientated programming with Java exists. That encloses first steps with the Java Swing library. However the task of combining shell commands and a Java user interface begs problems. This will be discussed in section 4.5.2. Previously some general program design decisions have to be ruled.

4.5.1 Programming Techniques

The implementation makes use of the JavaFX library to create the graphical user interface. The program is realized with programming patterns. The following paragraphs describe the Singleton and the Model View Control (MVC) Pattern.

Singleton

The Singleton Pattern ensures that only one instance of a class is created. Listing 4.7 shows an example of a Singleton implementation in Java.

1 p u b l i c final class Singleton {

2 p r i v a t e static Singleton theInstance = null;

3 p r i v a t e Singleton() {};

4 p u b l i c static Singleton getInstance() {

5 i f (theInstance == null)

6 theInstance = new Singleton();

7 r e t u r n theInstance;

8 }

9 }

Listing 4.7: Singleton Pattern

The chosen implementation does not provide thread safety because the program does not make use of multithreading (cf. Eilebrecht and Starke 2010, p. 35).

39 4 Implementation

Model View Control Pattern

The MVC Pattern splits the tasks within a program into three diﬀerent parts shown in 4.10.

Figure 4.10: Model View Control Design Pattern (cf. Heinisch, Goll, and Müller-Hofmann 2007, p. 822)

The view is used for outputting representation. It requests information from the model that the view needs to generate output. The user sees the data shown by the view and uses the controller for commanding the program. The controller implements the event handling. It is able to send commands to its associated view and model to update them. Methods that touches data of the model belong to the model itself. The update of the view is bind to the state of the model which notiﬁes its associated views and controllers when there has been a change in its state. This notiﬁcation allows the view to produce updated output, and the controller to change the available set of commands (see Eckstein 2008). Other programming techniques used are explained in the following documentation of concrete implementations.

4.5.2 Execute Scripts within JAVA Programs

In exception of the tasks the program has to oﬀer a solution to run scripts. This enables executing scripts generated by the script parser that is topic of section 4.5.3.

Executing scripts usually causes output that is written to the terminal window the script is launched. By launching the scripts within the program the output has to be redirected:

40 4 Implementation

1 s t a t i c class StreamHandler extends Thread {

2 InputStream is;

4 S t r i n g type;

6 StreamHandler(InputStream is , String type) {

7 t h i s.is = is;

8 t h i s.type = type;

9 }

11 p u b l i c void run() {

12 t r y{

13 InputStreamReader isr = new InputStreamReader(is);

14 BufferedReader br = new BufferedReader(isr);

15 S t r i n g line = null;

16 w h i l e ((line = br.readLine()) != null)

17 System.out. println(type + " " + l i n e ) ;

18 } catch (IOException ioe) {

19 ioe.printStackTrace();

20 }

21 }

22 }

Listing 4.8: Stream

Java oﬀers a runtime class to execute external programs. The path to bash which is the programm that executes shell scripts and the path to the script are combined to the command.

1 // Executes the script

2 p u b l i c static void execute(String script) {

3 i f (script.length()<1) {

4 System.out. println( "USAGE: java ShellScriptExecutor script" );

5 System. exit(1);

6 }

8 t r y{

9 S t r i n g osName = System.getProperty( "os.name" );

10 S t r i n g[] cmd = new String[2];

11 cmd [ 0 ] = "/bin/sh" ;// Path to shell

12 cmd[1] = script;

14 Runtime rt = Runtime.getRuntime();

15 System.out. println( "Run " + cmd [ 0 ] + " " + cmd [ 1 ] ) ;

16 Process proc = rt.exec(cmd);

41 4 Implementation

17 // Error messages

18 StreamHandler errorStreamHandler = new StreamHandler(

19 proc.getErrorStream() , "ERR" );

21 // Output messages

22 StreamHandler outputStreamHandler = new StreamHandler(

23 proc.getInputStream() , "OUT" );

25 // Start handlers

26 errorStreamHandler. start();

27 outputStreamHandler. start ();

29 // Error messages of process

30 i n t exitVal = proc.waitFor();

31 System.out. println( "ExitValue: " + e x i t V a l ) ;

32 } catch (Throwable t) {

33 t.printStackTrace();

34 }

35 }

Listing 4.9: Module to run scripts

4.5.3 Script Parser

At this point the program is able to execute scripts. The next task is to find a way to combine the users choice in the graphical interface with the remastering scripts of chapter 4.2. This can be done according to figure 4.11 by reading a template script and replacing previous set wild-cards. This procedure offers the possibility to show the user the generated script before it gets executed.

Figure 4.11: Principle of generating scripts

The interface shown in listing 4.10 speciﬁes the necessary methods when programming a class that implements the interface.

42 4 Implementation

1 package org.openjevis.jevislivecreator.model;

3 import java.util.Map;

5 p u b l i c interface Scriptable{

6 /∗∗

7 ∗ I n i t i a l i z e script. Template needs to be set

8 ∗/

9 v o i d initialize();

11 /∗∗

12 ∗ @ r e t u r n Map var

13 ∗ s e t pairs to be replaced

14 ∗/

15 Map defVariables();

17 /∗∗

18 ∗ @ r e t u r n boolean status

19 ∗ s t a r t replace

20 ∗/

21 Boolean replace();

23 v o i d setScript(String script);

24 S t r i n g getScript();

25 v o i d setTemplate(String template);

26 S t r i n g getTemplate();

27 v o i d setVars(Map vars);

28 Map getVars();

29 v o i d generateScript(String script);

30 }

Listing 4.10: Interface of script creation

The abstract class provides shared used methods.

1 package org.openjevis.jevislivecreator.model;

3 import java.io.BufferedReader;

4 import java.io.BufferedWriter;

5 import java.io.File;

6 import java.io.FileReader;

7 import java.io.FileWriter;

8 import java.io.IOException;

9 import java.util.Map;

43 4 Implementation

11 p u b l i c abstract class Script implements Scriptable{

12 p r i v a t e String template;

13 p r i v a t e String script;

14 p r i v a t e Map vars;

16 p u b l i c void setScript(String script){

17 t h i s.script=script;

18 }

19 p u b l i c String getScript(){

20 r e t u r n script;

21 }

22 p u b l i c void setTemplate(String template){

23 t h i s .template=template;

24 }

25 p u b l i c String getTemplate(){

26 r e t u r n template;

27 }

28 p u b l i c void setVars(Map vars){

29 t h i s .vars=vars;

30 }

31 p u b l i c Map getVars(){

32 r e t u r n this.vars;

33 }

34 p u b l i c void generateScript(String script){

35 setScript(script);

36 r e p l a c e ( ) ;

37 }

38 p u b l i c Boolean replace(){

39 t r y{

40 // Open Files

41 File infile=new File(getTemplate());

42 i f(!infile.exists()){

43 System.out. println( "Template not exists" );

44 r e t u r n false;

45 }

47 File outfile=new File(getScript());

48 i f(!outfile.exists()){

49 i f (! outfile .createNewFile()){

50 System.out. println( "Script can not be created" );

51 r e t u r n false;

52 }

53 }

55 BufferedReader in = new BufferedReader(new FileReader(infile));

56 BufferedWriter out = new BufferedWriter(new FileWriter(outfile));

44 4 Implementation

58 // Create map of variables

59 setVars(defVariables());

61 S t r i n g line;

62 // Read template file by line

63 w h i l e((line = in.readLine()) != null){

64 // For each key−v a l u e −p a i r

65 f o r (Map.Entry e : vars.entrySet()){

66 // Replace key with value

67 line=line .replace(e.getKey() , e.getValue());

68 }

69 // Write to script file

70 out.write(line);

71 }

72 // Close files

73 in.close();

74 out.close();

75 }

76 c a t c h( IOException e ){

77 e.printStackTrace();

78 }

79 r e t u r n true;

80 }

81 }

Listing 4.11: Abstract methods for script creation

To give an example of the functionality the implementation of the script that copies the system to an USB device is shown below.

1 package org.openjevis.jevislivecreator.model;

3 import java. util .HashMap;

4 import java.util.Map;

6 p u b l i c class ScriptCreate extends Script{

8 @Override

9 p u b l i c Map defVariables() {

10 Map vars = new HashMap();

12 // Model

13 ModCreate modCreate=new ModCreate();

15 // Add variables

45 4 Implementation

16 v a r s . put ( "$WORKDIR" , model.getWorkDir() );

17 v a r s . put ( "$DEV" , modCreate.getDevice() );

18 v a r s . put ( "$MOUNT_USB" , modCreate.getUSBMount() );

19 v a r s . put ( "$SIZE_LIVE" , modCreate.getSizeParLive() );

20 v a r s . put ( "SIZE_PERS" , modCreate.getSizeParPers() );

21 v a r s . put ( "$NO_PERS" , modCreate.getPers() );

22 v a r s . put ( "$useDef" , modCreate.useDefaultIso.getValue().toString());

23 r e t u r n vars;

24 }

26 @Override

27 p u b l i c void initialize() {

28 setTemplate(model.getScriptTemplateUsb() );

29 }

30 }

Listing 4.12: Example for script implementation

4.5.4 Presentation

Figure 4.12: Copy live system to media

Figure ?? shows the dialog to copy the JEVis Live System to a ﬂash device.

46 4 Implementation

4.6 Packages

Distributing software centralized offers benefits like predefined paths, enhanced configuration, version control, satisfy of dependencies, and update mechanisms. New versions of popular OS are mostly shipped with a build-in solution of software centers. While this feature on MS Windows has been implemented in 2012 (Windows 8) for the first time onto Linux systems concepts of an unified way to install software has been established for a long time. However there exist different implementations inside the distribution groups. One of the leading concepts is the RPM Package Manager 3, which has been developed since the 1990ies and has been specified in the Linux Standard Base. The RPM is for instance used by Fedora and Suse Linux. This packages are managed on client’s side with the yum tool. The second important implementation is provided on Debian based distributions and are called Debian packages (.deb). They are managed with the dpkg, aptitude or usually apt-get tool.

Because Ubuntu Linux which belongs to the Debian based Linux derivatives is used for the realization Debian Packages are created. The procedure of making a package is exemplary shown in the following.

The ﬁle name of a Debian Package shall be built up containing the program’s name, its version information and the architecture of target system.

programs-name_version.sub_version_debian_revision_version_architecture.deb

Debian packages have a default structure of folders and configuration files as shown in figure 4.13, that contains the default configuration for a local running JEVis system. The creation of the packages can be automated by the following script:

1 echo "=== Make Package ==="

2 SRC=./jevis −l i v e −j e v i s −

3 DEB=./ jevis −l i v e −j e v i s . deb

5 r e a d −p "Path to package sources: " −i $SRC −e SRC

6 r e a d −p "Target file: " −i $DEB −e DEB

8 echo "Change permissions"

9 f i n d $SRC −t y p e f −print0 | xargs −0 sudo chmod 644# set files to 644

10 f i n d $SRC −t y p e d −print0 | xargs −0 sudo chmod 755# set folders to 755

11 f i n d . / −t y p e f −name "*.sh" −print0 | xargs −0 sudo chmod +x# make scripts executable

3primary meaning RedHat Package Manager

47 4 Implementation

12 #find./ −t y p ef −name" ∗ .jar" −p r i n t 0| xargs −0 sudo chmod+x# make scripts executable

14 chmod 0755 −R $SRC/DEBIAN/postinst# rwx, rx, rx to scripts

15 chmod 0755 −R $SRC/DEBIAN/prerm# rwx, rx, rx to scripts

17 echo "Clean sources"

18 f i n d $SRC −t y p e f −name "*~" −exec rm −f {} \ ;# delete gedit auto −s a v e

19 rm − rf ‘find $SRC −t y p e d −name . svn ‘# delete svn info

21 echo "Make deb package"

22 fakeroot dpkg −b ${SRC} ${DEB}

23 lintian ${DEB}

Listing 4.13: Create a Package

To build packages of good quality the file permissions have to be set correctly. Furthermore, not needed files are deleted and the package is created under usage of a fakeroot environment. The program lintian offers a check of the built package.

jevis-live-jevis DEBIAN changelog control copyright preinst postinst opt jevis etc jevis.cnf jevis-live

Figure 4.13: Folder structure of an example package

The DEBIAN folder contains conﬁguration ﬁles. They are used to provide information about license, platform, depencies and more. Analog to the procedure sketched ahead within the work on the live system the packages listed in table 6.1 are created. These packages take part during the remastering process.

48 4 Implementation

Name description jevis-live-bin-links Places run scripts in bin. jevis-live-casper Place settings for casper environment. jevis-live-cinnamon Overrides default session-setting. jevis-live-defaultconf Default pre-configuraton for JEVis-installation. jevis-live-desktop-icon-jecalc Shows JECalc button on desktop. jevis-live-desktop-icon-jeconfig Shows JEConfig button on desktop. jevis-live-desktop-icon-jegraph Shows JEGraph button on desktop. jevis-live-desktop-icon-portal Shows JEPortal butoon on desktop. jevis-live-desktop-icon-readme Shows readme-icon on desktop. jevis-live-documentation Local documentation of JEVis. jevis-live-exampledata Copy example data to JEVis system. jevis-live-fix-apport Suppress crash reports of apport. jevis-live-icons Icons for JEVis. jevis-live-jeconfig JEConfig - set up the monitoring system configuration. jevis-live-jevis Copy and run JEInstaller. jevis-live-languages Install language packages (DE,RU,EN,UK)

Table 6.1: Created packages

4.6.1 Repository

To create an repository the command line program reprepro is used.

“Creating an APT repository involves creating a set of directories to hold the packages and using a tool to create the supporting ﬁles for the APT tools to use to access the repositories.”

(Sally 2009)

In the ﬁrst step packages that are added to the repository have to be signed with with a GPG key.

1 # install tool to sign packages

2 sudo apt−get install dpkg−s i g n

49 4 Implementation

3 # export key

4 gpg −−armor −−output ./repository/publickey.gpg −−e x p o r t [email protected]

5 # signa package

6 dpkg−s i g −−sign builder ./packages/jevis −l i v e −i c o n s . deb −k 47E56ABD

Listing 4.14: Sign packages

Next steps are creating a folder named conf and a configuration file named distributions in it. The repository needs the configuration to organize clients access to the repository. Clients need to know what types of packages they can expect to find.

1 Origin: openjevis.org

2 Codename: experimental

3 Architectures: i386 amd64

4 Components: main

5 Description: Debian−Packages of OpenJEVis.org

6 SignWith : 47E56ABD

8 Origin: openjevis.org

9 Codename: quantal

10 Architectures: i386 amd64

11 Components: main

12 Description: Debian−Package of OpenJEVis.org

13 SignWith : 47E56ABD

Listing 4.15: Distributions conﬁguration ﬁle

After the repository is set up package ﬁles can be added to the repository with this command:

1 # install needed tool

2 sudo apt−get install reprepro

4 # set repository base dir

5 e x p o r t REPREPRO_BASE_DIR=’/repository’

7 # add packages with reprero

8 reprepro includeb experimental jevis −l i v e −i c o n s . deb

10 # To remove a package from

11 reprepro remove experimental jevis −l i v e −i c o n s

Listing 4.16: Add and remove packages

50 4 Implementation

Subsequently the content of the repository folder has to be uploaded except of db and conf which are only needed locally for conﬁguration.

4.6.2 Presentation

Once the repository is available clients can adapt it to their package sources. The procedure is described brieﬂy at http://update.openjevis.org.

Figure 4.14: Ubuntu software center

Figure 4.14 shows how packages are presented on the software center. If new versions of the packages are uploaded to the repository clients are notiﬁed about the update. The short presen- tations of the results are associated within the last chapter and the impact on the initial situation is revealed.

51 5 Conclusion and Outlook

5.1 Conclusion

To estimate the impact of the implemented improvements on usability of OpenJEVis, and espe- cialy the necessary efforts to test and install JEVis, subsequently the initial and actual situation have to be compared. The fields of initial usability and distribution infrastructure became the main topics of this thesis. To remind the reason for starting research on distribution alternatives figure 5.1 shows the weaknesses again.

Testserver Account

Package Concept

Virtual Testing Installation Machine

Installer Manual

Live System

Figure 5.1: Fields of work

The ﬁgure displays the existing and the within the project planned (underlined italic) options of testing and installing. The initial situation required the registration on the website and requesting of a guest account to try out JEVis without complex installation. The only way to install JEVis was given by the JEInstaller and a nine page long installation manual.

The main eﬀorts were taken on the development of the JEVis Live System. The ﬁnal result of the

52 5 Conclusion and Outlook research on it is a solution that eliminates many weak points. By taking a closer look on inten- tions and actual results the live system approach provides a crucial easier way for testing. The live system is able to save data, do calculations, display news, perform installation and contains example data. Up to this point about 100 JEVis Live USB ﬂash devices have been produced. Particularly new possibilities to perform installations were created which are discussed later on. For time reasons the planned feature of integrating a data source was not implemented.

Aiming at creating a sustainable solution becomes apparent on the developed program. The JEVis Live System Creator oﬀers creating new versions of the Live System and the reproduction of Live System USB ﬂash devices. A graphical user interface based on JavaFX and the realization of remastering tasks which go back to terminal scripts are chosen in this implementation. The adaption of scripts bases on templates and a parsing algorithm of the program. Adapted scripts can be executed with the implemented shell script launcher.

New options besides the live system are offered by the concept of Debian Packages. The used synergies flow into alternative installation options. Within the scope of this thesis the presentation of possibilities are published on an own domain1 which is integrated on the OpenJEVis.org community. Approaching to distribute the software via repository would offer a technical solution to perform updates more comfortable. Thus, this topic is examined in the following outlook section.

1The results are available on http://update.openjevis.org/

53 5 Conclusion and Outlook

5.2 Outlook

5.2.1 Integration of Datasources

The initial purpose includes the integration of datasources. As already mentiond in the previous section the current version of the JEVis Live System does not implement an own active datasource. The reﬂections done on this topic during working on this thesis are used to outline possibilities of datasource integration in the following.

Normally the live system is only running for limited periods. That causes undynamic data for long sequences. Interrupted data recording has impact on the group of matching sources because hardly any of them can provide definite data rows. Some sources provide data that changes only while the system is running. As a consequence values for undetermined data sequences can be reconstructed. Examples for this kind of data are disk space or network traffic that do not change when the system is turned off.

Other data values change while the system is not running. In times the recording service does not capture data the values are undetermined. This thought can be proved taking CPU temperatures: Sensors can only deliver temperatures in uptime but the value will change after turning oﬀ the system.

Data Sources

There are diﬀerent possibilities to realize the transmission of data to the JEVis software. The concepts diﬀer in level of abstraction and deepness of access to the monitoring software.

Taking into account the limitation that the data source is only used on local system a service program is a solution to connect data sources to the monitoring system. Within the JEVis architecture the JECAPI contains the functionality of basic input- and output-operations.

Former devices often use the way of a direct connection to the energy monitoring system as shown in the figure above. Direct binding leads to the benefit of less overhead and thus a good performance. The following described approach enables a more flexible and easier possibility to realize binding energy meters.

54 5 Conclusion and Outlook

JEVis Live System

Database

Servlet Container

JDBC

JEWebService Service Program axis 2 Datasource JECAPI

Figure 5.2: JECAPI direct binding

JEADFWeb Concept

JEVis Live System

Database

Servlet Container

JDBC

JEWebService

axis 2

JECAPI

HTTP or FTP Server

Datasource

Figure 5.3: JEADFWeb concept

The JEADFWeb concept sketched in ﬁgure 5.3 is the common used solution to connect energy meters. As denoted within the 2.3.1 section it supports various protocols. The better choice to demonstrate function principle, advantages and conception of JEVis is therfore the JEADFWeb

55 5 Conclusion and Outlook concept.

5.2.2 Further Projects

As mentioned before Envidatec GmbH cooperates with diﬀerent universities in various countries to expedite research and development and education, too. A concept of laboratory experiment at Perm National Research Politechnic University in Russia contains the installation of measurement hardware. The laboratory places shall be equipped with computers running JEVis energy data monitoring software. For this concept the JEVis Live System can be considered as a valuable innovation especially for pre- and postprocessing experiments.

Another point deals with the delivery of drivers and custom written software to customers. The idea of Envidatec’s management is to send them a portfolio including the manual and an USB ﬂash device containing the ordered software and additionaly the JEVis Live System. Boxing software, even if a physical media is not mandatory, is not unusual, e.g. mass market software like oﬃce products.

All in all these examples prove that the project contributes to future development both in the company and for interested open source users.

56 Glossary

C programming language is a general-purpose programming language initially developed by Dennis Ritchie between 1969 and 1973 at AT&T Bell Labs.

Canonical Ltd.) is a UK-based privately held computer software company founded (and funded) by South African entrepreneur Mark Shuttleworth to market commercial support and related services for Ubuntu and related projects.

Chief Executive Oﬃcer is the highest-ranking corporate oﬃcer (executive) or administrator in charge of total management of an organization.

Cinnamon (user interface) is a user interface. It is a fork of GNOME Shell, initially developed by (and for) Linux Mint.

Debian is a computer operating system composed of software packages released as free and open source software.

Energy Management System is a system of computer-aided tools used by operators of electric utility grids to monitor, control, and optimize the performance of the generation and/or transmission system.

German Renewable Energy Act (in German: Erneuerbare-Energien-Gesetz, EEG) was designed to encourage cost reductions based on improved energy eﬃciency from economies of scale over time.

GNU Privacy Guard is a GPL Licensed alternative to the PGP suite of cryptographic software.

Graphical User Interface is a type of user interface that allows users to interact with electronic devices using images rather than text commands.

Institute of Electrical and Electronics Engineers is a professional association headquartered in New York City that is dedicated to advancing technological innovation and excellence.

International Organization for Standardization is an international standard-setting body composed of representatives from various national standards organizations.

I Glossary

ISO 50001 is a speciﬁcation created by the International Organization for Standardization (ISO) for an energy management system.

Java programming language is a general-purpose, concurrent, class-based, object-oriented computer programming language that is speciﬁcally designed to have as few implementation dependencies as possible.

JavaFX software platform is a software platform for creating and delivering rich internet applications (RIAs) that can run across a wide variety of devices.

JEConﬁg is a program to conﬁgure the JEVis software.

JEGraph is a program used to visualize energy data; it is a part of the JEVis software.

JEVis is a energy data monitoring software developed by Envidatec GmbH.

Linux is a generic term referring to the family of Unix-like computer operating systems that use the Linux kernel.

Model–View–Controller is a software architecture pattern which separates the representation of information from the user’s interaction with it.

My Structured Query Language is an open source relational database management system.

Plymouth is a bootsplash for Linux. It supports animations. It makes use of Direct Rendering Manager (DRM) and kernel-based mode-setting (KMS). It gets packed into the initrd.

Primary energy is an energy form found in nature that has not been subjected to any conversion or transformation process.

Structured Query Language is a special-purpose programming language designed for managing data held in a relational database management systems.

Ubuntu is a computer operating system based on the Debian Linux distribution and distributed as free and open source software.

II Glossary

Overview of Commands

This contains an overview of commands used in the thesis with a short description. add-apt-repository Adds a repository into the /etc/apt/sources.list or /etc/apt/sources.list.d or removes an existing one adduser create a new user or update default new user information apt-get is the command-line tool for handling packages, and may be considered the user’s “back- end” to other tools using the APT library. Several “front-end” interfaces exist, such as synaptic and aptitude.

update Used to re-synchronize the package index ﬁles from their sources. The indexes of available packages are fetched from the location(s) speciﬁed in /etc/apt/sources.list(5). An update should always be performed before an upgrade or dist-upgrade.

upgrade Used to install the newest versions of all packages currently installed on the system from the sources enumerated in /etc/apt/sources.list(5). Packages currently installed with new versions available are retrieved and upgraded; under no circumstances are currently installed packages removed, nor are packages that are not already installed retrieved and installed. New versions of currently installed packages that cannot be upgraded without changing the install status of another package will be left at their current version. An update must be performed ﬁrst so that apt-get knows that new versions of packages are available.

install this option is followed by one or more packages desired for installation cd change directory cp copy files and directories chown change file owner and group chroot run command or interactive shell with special root directory exit cause normal process termination grub-install install GRUB to a device ln make links between files

III Glossary mkdir make directories mkfs build a Linux filesystem mksquashfs tool to create and append to squashfs filesystems mount mount a filesystem mv move (rename) files nano small editor parted a partition manipulation program rsync a fast, versatile, remote (and local) file-copying tool service run a System V init script su run a shell with substitute user and group IDs sudo execute a command as another user umount unmount file systems unzip list, test and extract compressed files in a ZIP archive usermod modify a user account

IV List of Figures

2.1 Germanys Energy Productivity ...... 4 2.2 Energy management system model ...... 5 2.3 JEVis data monitoring software ...... 7 2.4 JEVis System Setup ...... 8 2.5 Get in touch with JEVis ...... 12 2.6 Layers on a PC system ...... 15

3.1 UML use case diagram of use case 1 ...... 19 3.2 The aspects of scope ...... 21

4.1 Aspects of scope ...... 25 4.2 Components of a live system ...... 27 4.3 Sequence of remastering process ...... 28 4.4 Customized boot screen ...... 35 4.5 Desktop environment ...... 36 4.6 Test the Monitoring Solution ...... 36 4.7 Test the Monitoring Solution ...... 37 4.8 Installation Routine ...... 37 4.9 JEVis USB ﬂash device ...... 38 4.10 Model View Control Design Pattern ...... 40 4.11 Principle of generating scripts ...... 42 4.12 Copy live system to media ...... 46 4.13 Folder structure of an example package ...... 48 4.14 Ubuntu software center ...... 51

5.1 Fields of work ...... 52 5.2 JECAPI direct binding ...... 55 5.3 JEADFWeb concept ...... 55

V List of Tables

2.1 Requirements on the test system ...... 22 2.2 Requirements on distribution ...... 22 2.3 Requirements on the solution to create test systems ...... 23

2.1 Location of system contents ...... 30 6.1 Created packages ...... 49

VI List of Listungs

4.1 Prepare ...... 28 4.2 Extract Image ...... 29 4.3 Extract Live-System ...... 30 4.4 Edit Live-System ...... 30 4.5 Pack Live-System ...... 33 4.6 Create USB-Stick ...... 33 4.7 Singleton Pattern ...... 39 4.8 Stream ...... 40 4.9 Module to run scripts ...... 41 4.10 Interface of script creation ...... 43 4.11 Abstract methods for script creation ...... 43 4.12 Example for script implementation ...... 45 4.13 Create a Package ...... 47 4.14 Sign packages ...... 49 4.15 Distributions conﬁguration ﬁle ...... 50 4.16 Add and remove packages ...... 50

VII Bibliography

Balliano, Fabrizio and Krzysztof Lichota (January/2013). Ubuntu Customization Kit. Available online, visited on February 20. 2013. url: {http://sourceforge.net/projects/ uck/} (cit. on p. 26).

Balzert, H. (2009). Lehrbuch Der Softwaretechnik: Basiskonzepte Und Requirements Engineer- ing. Lehrbücher der Informatik. Spektrum Akademischer Verlag GmbH. url: {http: //books.google.de/books?id=vmfIb9R2QikC} (cit. on p. 21).

Bandel, G. (2010). Open Source Software: Fördert Oder Hemmt Diese Art Der Softwareentwick- lung Den Wettbewerb? Diplomica Verlag Gmbh. url: {http://books.google.de/ books?id=1498NifAmlEC} (cit. on pp. 9, 11).

Boßmann, Tobias, Wolfgang Eichhammer, and Rainer Elsland (2012). Policy Report Contribution of Energy Eﬃciency Measures to Climate Protection within the European Union until 2050. Fraunhofer ISI for the Federal Ministry for the Environment, Nature Conservation and Nuclear Safety (BMU) of Germany. url: {http://www.isi.fraunhofer.de/isi- media/docs/e/de/publikationen/BMU_Policy_Paper_20121022.pdf} (cit. on p. 3).

Cockburn, A. (2001). Writing eﬀective use cases. Agile software development series. Addison- Wesley. url: {http://books.google.de/books?id=VKJQAAAAMAAJ} (cit. on p. 17).

Eckstein, Robert (2008). Java SE Application Design With MVC. url: {https://blogs. oracle . com / JavaFundamentals / entry / java _ se _ application _ design _ with} (cit. on p. 40).

Eilebrecht, Karl and Gernot Starke (1/2010). Patterns kompakt: Entwurfsmuster für eﬀektive Software-Entwicklung. 3. Auﬂ. 2010. Spektrum Akademischer Verlag. url: {http:// amazon.de/o/ASIN/3827425255/} (cit. on p. 39).

VIII Bibliography

Envidatec GmbH (2012). JEVis Energy and Operating Data System. Internal presentation (cit. on p. 10).

— (Februrary/2013). Company Proﬁle. An Overview of the Company Envidatec GmbH, Ref- erence Projects and Expertise. Internal document (cit. on p. 6).

Hattenhauer, Rainer (4/2005). Linux-Livesysteme: Knoppix, Ubuntu, Morphix, Kanotix, Mepis, Quantian & Co. (Galileo Computing). 1. Negernbötel: Galileo Computing. url: {http: //amazon.de/o/ASIN/3898426319/} (cit. on p. 14).

Heinisch, C., J. Goll, and F. Müller-Hofmann (2007). Java als erste Programmiersprache. Teub- ner. url: {http : / / books . google . de / books ? id = Q8 \ _zG0muPiEC} (cit. on p. 40).

IEEE Computer Society, Software Engineering Standards Committee (1998). IEEE recommended practice for software requirements speciﬁcations. IEEE (std.) Institute of Electrical and Electronics Engineers. url: {http : / / books . google . com . ec / books ? id = MYBGAAAAYAAJ} (cit. on p. 21).

International Organization for Standardization (2011). Win the energy challenge with ISO 50001. url: {http://www.iso.org/iso/iso_50001_energy.pdf} (cit. on p. 5).

Jones, P. (2008). Knowing Knoppix: The Beginner’s Guide to Linux That Runs from Cd. Cre- ateSpace. url: {http://books.google.de/books?id=KW-6TU19THkC} (cit. on p. 14).

Kausch, P., J. Gutzmer, M. Bertau, and J. Matschullat (2011). Energie Und Rohstoﬀe: Gestaltung Unserer Nachhaltigen Zukunft. Spektrum Akademischer Verlag GmbH. url: {http:// books.google.de/books?id=ixajES\_KlfsC} (cit. on p. 1).

Knopper, Klaus and Kyle Rankin (2007). Knoppix hacks - tips and tools for using the Linux live CD to hack, repair, and enjoy our PC: includes Knoppix on DVD (2. ed.). O’Reilly, pp. I–XXV, 1–391 (cit. on p. 14).

Marinilli, M. (2002). Java Deployment with JNLP and WebStart. Kaleidoscope Series. Sams. url: {http://books.google.de/books?id=lbvUD6LUyV8C} (cit. on p. 6).

IX Bibliography

Nüttgens, M. and E. Tesei (2000). Open source - Marktmodelle und Netzwerke. Veröﬀentlichungen des Instituts für Wirtschaftsinformatik. Iwi. url: {http://books.google.de/books? id=bBMPPwAACAAJ} (cit. on p. 10).

OpenJEVis.org (2013[a]). JEADFWeb. JEVis Automatic Data Fetch via Webprotocol. url: {http://openjevis.org/projects/jeadfweb} (cit. on p. 9).

— (February/2013[b]). JEVis Installation Manual. Available online. visited on March 1. 2013. url: {http://www.openjevis.org/documents/12} (cit. on p. 23).

Open Source Initiative (2012). The Open Source Deﬁnition. Available online. url: {http: //opensource.org/osd} (cit. on p. 10).

Remastersys.com (January/2013). Remastersys. A Unique Linux Backup to Live Media Tool for Debian and Ubuntu. Available online, visited on February 18. 2013 (cit. on p. 27).

Sally, G. (2009). Pro Linux Embedded Systems. The Expert’s Voice in Linux. Apress. url: {http://books.google.de/books?id=3pBP5Y\_fLDkC} (cit. on p. 49).

Vaughan-Nichols, Steven J. (2013). Linux servers keep growing, Windows and Unix keep shrinking. url: {http://www.zdnet.com/blog/open-source/linux-servers-keep- growing-windows-and-unix-keep-shrinking/10616} (cit. on p. 24).

X Bibliography

Versicherung über die Selbstständigkeit

Hiermit versichere ich, dass ich die vorliegende Arbeit im Sinne der Prüfungsordnung nach §16(5) APSO-TI-BM ohne fremde Hilfe selbstständig verfasst und nur die angegebenen Hilfsmittel be- nutzt habe. Wörtlich oder dem Sinn nach aus anderen Werken entnommene Stellen habe ich unter Angabe der Quellen kenntlich gemacht.

Ort, Datum Unterschrift