MA14-39 - Erstellung einer Kommunikationsinfrastruktur für ... · [8] und Google mit „Weave“...

MASTERARBEIT

Erstellung einer Kommunikationsinfrastruktur für verteilte Smart

Home Anwendungen

durchgeführt am

Studiengang Informationstechnik und System-Management

an der

Fachhochschule Salzburg

vorgelegt von:

Manuel Parfant, BSc

Studiengangsleiter: FH-Prof. DI Dr. Gerhard Jöchtl

Betreuer: DI Armin Veichtlbauer

Salzburg, September 2015

Eidesstattliche Erklärung

Hiermit versichere ich, Manuel Parfant, geboren am 10. Februar 1986 in Braunau am Inn,

dass die vorliegende Masterarbeit von mir selbstständig verfasst wurde. Zur Erstellung wur-

den von mir keine anderen als die angegebenen Quellen und Hilfsmittel verwendet.

Braunau am Inn, am 01.09.2015

1310581045

Manuel Parfant Matrikelnummer

Allgemeine Informationen

Vor- und Zuname: Manuel Parfant

Institution: Fachhochschule Salzburg GmbH

Studiengang: Informationstechnik & System-Management

Titel der Masterarbeit: Erstellung einer Kommunikationsinfrastruktur für

verteilte Smart Home Anwendungen

Schlagwörter: XMPP, IEC 61499, 4DIAC, Smart Home,

Kommunikationsinfrastruktur, verteilte Anwendung

Betreuer an der FH: DI Armin Veichtlbauer

Abstract

Home automation in private living space is becoming more and more important. The break-

through in the market of so called “Smart Homes” has not been achieved yet due to the lack

of programming and communication standards. In the first part of this master thesis an ex-

planation of Smart Homes will be given followed by a detailed analysis of common use cases

and the definition of requirements for the programming system and communication protocol.

In the next step common programming standards and communication protocols will be dis-

cussed. In the practical part two use cases will be implemented with the most suitable pro-

gramming standard and communication protocol and evaluated against the previously de-

fined requirements. A summary with optimization possibilities together with future pro-

spects concludes this thesis.

Danksagung

An dieser Stelle möchte ich mich bei allen Personen bedanken, die mich beim Schreiben

dieser Masterarbeit unterstützt und motiviert haben.

Ein spezieller Dank gilt meinem Betreuer Herrn DI Armin Veichtlbauer für die freundliche

und engagierte Betreuung und die vielen hilfreichen Gespräche und Anregungen.

Ganz besonders möchte ich meiner Familie und meinen Freunden danken, die mir während

des Studiums immer mit Rat und Tat zur Seite standen und immer ein aufmunterndes Wort

parat hatten.

Nicht zuletzt danke ich meinen Studienkollegen für die vergangene, gemeinsame Studien-

zeit, die von außerordentlicher Gemeinschaft, Humor und gegenseitiger Wertschätzung ge-

prägt war.

i

Inhaltsverzeichnis

1 Einleitung ...................................................................................................................... 1

1.1 Motivation ............................................................................................................. 2

1.2 Zielsetzung ............................................................................................................ 3

1.3 Innovationspotenzial .............................................................................................. 4

2 Anforderungsanalyse ..................................................................................................... 6

2.1 Use Cases ............................................................................................................... 6

2.2 Anforderungen ..................................................................................................... 12

2.3 Test Cases ............................................................................................................ 15

3 Normen für speicherprogrammierbare Steuerungen ................................................... 18

3.1 IEC 61131 ............................................................................................................ 18

3.2 IEC 61499 ............................................................................................................ 26

4 Kommunikationsprotokolle ......................................................................................... 37

4.1 SOAP ................................................................................................................... 37

4.2 REST ................................................................................................................... 41

4.3 WebSocket ........................................................................................................... 44

4.4 XMPP .................................................................................................................. 48

5 Kodierungsverfahren ................................................................................................... 55

5.1 ASN.1 .................................................................................................................. 55

5.2 Base64 ................................................................................................................. 61

6 Bewertung .................................................................................................................... 63

6.1 Programmiersystem ............................................................................................. 63

6.2 Kommunikationsprotokoll ................................................................................... 65

6.3 Kodierungsverfahren ........................................................................................... 68

7 Architektur ................................................................................................................... 70

ii

7.1 System-Komponenten ......................................................................................... 71

7.2 Software-Komponenten ....................................................................................... 74

8 Definition der Testumgebung ...................................................................................... 78

8.1 Hardware und Betriebssystem ............................................................................. 78

8.2 IEC 61499 Entwicklungs- und Laufzeitumgebung ............................................. 79

8.3 XMPP Bibliothek ................................................................................................ 80

8.4 XMPP Server ....................................................................................................... 82

9 Implementierung .......................................................................................................... 84

9.1 XMPP-Kommunikation ....................................................................................... 84

9.2 Anwendungslogik ................................................................................................ 93

10 Validierung .................................................................................................................. 94

10.1 TC1 - Demand-Side-Management mittels Stromspeicher................................... 94

10.2 TC2 – Erinnerungsfunktion ................................................................................. 98

11 Evaluierung ................................................................................................................ 101

11.1 Reaktionszeit Publish-Subscribe ....................................................................... 101

11.2 Nachrichtengröße............................................................................................... 102

11.3 Systemauslastung .............................................................................................. 103

12 Fazit und Ausblick ..................................................................................................... 106

Literaturverzeichnis ........................................................................................................... 110

Anhang .............................................................................................................................. 117

A.1 Abbildungen ...................................................................................................... 117

A.2 Listings .............................................................................................................. 120

A.3 Tabellen ............................................................................................................. 121

iii

Abkürzungsverzeichnis

AAL Ambient Assisted Living

AS Ablaufsprache

ASCII American Standard Code for Information Interchange

ASN.1 Abstract Syntax Notation One

AWL Anweisungsliste

BER Basic Encoding Rules

CBA Component Based Automation

CCITT International Telegraph and Telephone Consultative Committee

CEM Customer Energy Management

CER Canonical Encoding Rules

DER Distinguished Encoding Rules

DHCP Dynamic Host Configuration Protocol

DIN Deutsches Institut für Normung

DNS Domain Name System

DOS Denial of Service

DPWS Devices Profile for Web Services

ECN Encoding Control Notation

FB Funktionsbaustein

FBD Funktionsbausteindiagramm

FBN Funktionsbausteinnetzwerk

FBS Funktionsbausteinsprache

FTP File Transfer Protocol

GOOSE Generic Object Oriented Substation Events

GUID Globally Unique Identifier

iv

HATEOAS Hypermedia as the Engine of Application State

HTTP Hypertext Transfer Protocol

HTTPS Hypertext Transfer Protocol Secure

IANA Internet Assigned Numbers Authority

IEC International Electrotechnical Commission

IETF Internet Engineering Task Force

IMPP Instant Messaging and Presence Protocol

IoT Internet of Things

IP Internet Protocol

IRI Internationalized Resource Identifier

ISO International Organization for Standardization

ITU-T International Telecommunication Union - Telecommunication

Standardization Sector

JID JabberID

JSON JavaScript Object Notation

KOP Kontaktplan

LDAP Lightweight Directory Access Protocol

MD5 Message Digest 5

MIME Multipurpose Internet Mail Extensions

MMS Manufacturing Messaging Specification

OER Octet Encoding Rules

OSI Open Systems Interconnection

PER Packed Encoding Rules

PGP Pretty Good Privacy

Profinet Process Field Network

PwC PricewaterhouseCoopers

v

REST Representational State Transfer

RFC Request for Comments

RFID Radio-frequency Identification

ROA Resource Oriented Architecture

RPC Remote Procedure Call

SASL Simple Authentication and Security Layer

SHA Secure Hash Algorithm

SIFB Service Interface Function Block

SIP Session Initiation Protocol

SMTP Simple Mail Transfer Protocol

SNMP Simple Network Management Protocol

SOA Service Oriented Architecture

SPS Speicherprogrammierbare Steuerung

ST Strukturierter Text

SVM Support Vector Machine

TCP Transmission Control Protocol

TLS Transport Layer Security

URI Uniform Resource Identifier

URN Uniform Resource Name

V2I Vehicle-to-Infrastructure

V2V Vehicle-to-Vehicle

V2X Vehicle-to-X

VDE Verband der Elektrotechnik, Elektronik und Informationstechnik

VM Virtuelle Maschine

VPS Verbindungsprogrammierte Steuerung

W3C World Wide Web Consortium

vi

XER XML Encoding Rules

XML Extensible Markup Language

XMPP Extensible Messaging and Presence Protocol

XSD XML Schema Definition

XSF XMPP Standards Foundation

XSS Cross-Site Scripting

vii

Abbildungsverzeichnis

Abbildung 1: IEC 61131-3 Software-Modell ...................................................................... 20

Abbildung 2: AS-Beispiel, nach [25] .................................................................................. 23

Abbildung 3: FBS-Beispiel, nach [25] ................................................................................ 23

Abbildung 4: KOP-Beispiel, nach [25] ............................................................................... 24

Abbildung 5: IEC 61131-5 Send FB, nach [26] .................................................................. 25

Abbildung 6: IEC 61499 – Referenzmodell, nach [22] ....................................................... 27

Abbildung 7: IEC 61499 FB ................................................................................................ 30

Abbildung 8: IEC 61499 FB Schnittstelle, nach [22] .......................................................... 31

Abbildung 9: IEC 61499 FB-Ausführungsmodell, nach [22] ............................................. 32

Abbildung 10: Ausführungssteuerung des Random-FBs aus 4DIAC ................................. 33

Abbildung 11: IEC 61499 Adapter FB, nach [22] .............................................................. 34

Abbildung 12: Aufbau einer Web-Socket Nachricht [50] ................................................... 46

Abbildung 13: XMPP-Architektur und Adressformat ........................................................ 50

Abbildung 14: ASN.1 BER-Kodierung (BOOLEAN Datentyp mit dem Wert TRUE) ...... 58

Abbildung 15: Komponenten-Diagramm ............................................................................ 70

Abbildung 16: Netzwerk-Topologie .................................................................................... 71

Abbildung 17: Testplatine Netzbetreiber ............................................................................ 72

Abbildung 18: Testplatine CEM ......................................................................................... 73

Abbildung 19: Testplatine Display ...................................................................................... 74

Abbildung 20: FBD Demand-Side-Management mittels Stromspeicher ............................ 76

Abbildung 21: FBD Erinnerungsfunktion ........................................................................... 77

Abbildung 22: Publish FB aus 4DIAC ................................................................................ 85

Abbildung 23: 4DIAC Kommunikations-Architektur, nach [94] ....................................... 87

Abbildung 24: Klassendiagramm XMPP Implementierung ................................................ 88

viii

Abbildung 25: Verteilte Anwendungslogik ......................................................................... 93

Abbildung 26: Testaufbau ................................................................................................. 117

Abbildung 27: Zeitverzögerung Publish-Subscribe mit XMPP verschlüsselt .................. 118

Abbildung 28: Zeitverzögerung Publish-Subscribe mit XMPP unverschlüsselt .............. 118

Abbildung 29: Zeitverzögerung Publish-Subscribe mit UDP ........................................... 119

Abbildung 30: Publish-Subscribe mit XMPP verschlüsselt .............................................. 119

Abbildung 31: Publish-Subscribe mit XMPP unverschlüsselt .......................................... 119

Abbildung 32: Publish-Subscribe mit UDP ...................................................................... 119

Abbildung 33: Client-Server mit XMPP verschlüsselt ..................................................... 119

Abbildung 34: Client-Server mit XMPP unverschlüsselt ................................................. 119

Abbildung 35: Client-Server mit TCP ............................................................................... 120

ix

Tabellenverzeichnis

Tabelle 1: TC1 - Demand-Side-Management mittels Stromspeicher ................................. 16

Tabelle 2: TC2 – Erinnerungsfunktion ................................................................................ 17

Tabelle 3: Fazit Programmiersysteme ................................................................................. 65

Tabelle 4: Fazit Kommunikationsprotokolle ....................................................................... 67

Tabelle 5: Abkürzungen der Taster und LEDs im FBD ...................................................... 75

Tabelle 6: IEC 61499 Software-Tools ................................................................................. 80

Tabelle 7: XMPP Bibliotheken ........................................................................................... 81

Tabelle 8: XMPP Server ...................................................................................................... 82

Tabelle 9: Validierung TC1 - Demand-Side-Management mittels Stromspeicher ............. 95

Tabelle 10: Fazit TC1 - Demand-Side-Management mittels Stromspeicher ...................... 97

Tabelle 11: Validierung TC2 - Erinnerungsfunktion .......................................................... 99

Tabelle 12: Fazit TC2 – Erinnerungsfunktion ................................................................... 100

Tabelle 13: Zeitverzögerung Publish-Subscribe................................................................ 102

Tabelle 14: Nachrichtengröße Publish-Subscribe ............................................................. 103

Tabelle 15: Nachrichtengröße Client-Server ..................................................................... 103

Tabelle 16: Systemauslastung XMPP mit Verschlüsselung nach einem Tag Laufzeit ..... 104

Tabelle 17: Systemauslastung XMPP ohne Verschlüsselung nach einem Tag Laufzeit .. 104

Tabelle 18: Systemauslastung TCP bzw. UDP nach einem Tag Laufzeit ........................ 104

Tabelle 19: Systemauslastung XMPP mit Verschlüsselung nach drei Tagen Laufzeit ..... 105

Tabelle 20: IEC 61131-3 Datentypen, nach [25] ............................................................... 122

Tabelle 21: ASN.1 Variablen-Typen, nach [68]................................................................ 124

Tabelle 22: Base64 Alphabet, nach [83] ........................................................................... 125

x

Listingverzeichnis

Listing 1: AWL-Beispiel, nach [25] .................................................................................... 22

Listing 2: ST-Beispiel, nach [25] ........................................................................................ 22

Listing 3: Beispiel einer SOAP-Nachricht .......................................................................... 39

Listing 4: WebSocket URI-Schema [50] ............................................................................. 44

Listing 5: Websocket Verbindungsaufbau - Request Header [50] ...................................... 45

Listing 6: Websocket Verbindungsaufbau - Response Header [50].................................... 45

Listing 7: Client-Stream-Header, nach [57] ........................................................................ 51

Listing 8: Server-Stream-Header, nach [57]........................................................................ 51

Listing 9: Stream-Features, nach [57] ................................................................................. 52

Listing 10: Beispiel einer XML-Stanza ............................................................................... 52

Listing 11: Beispiel ASN.1-Syntax, nach [68] .................................................................... 57

Listing 12: XMPP-Presence-Stanza mit XML-Namensraum forte ..................................... 92

Listing 13: REST über URI und HTTP – Beispiel Onlineshop, nach [41] ....................... 121

Einleitung 1

1 Einleitung

Der Begriff „Smart Home“ bezeichnet einen Wohnraum, der sich mit Hilfe von technischen

Systemen an die Bedürfnisse der Bewohner anpasst. Hauptziele sind die Erhöhung des Kom-

forts, der Lebensqualität, der Sicherheit und der Energieeffizienz. Grundlage eines Smart

Homes ist die Vernetzung von Haustechnik (z.B. Heizungssteuerung, Lichtschalter), Sicher-

heitstechnik (z.B. Alarmanlage, Zutrittskontrolle), Haushalts- und Unterhaltungselektronik

(z.B. Kühlschrank, Waschmaschine, Fernseher) und die zentrale Steuerung über das Internet

oder per App [1].

Die Anwendungsgebiete können in die drei Bereiche Ambient Assisted Living (AAL),

Heimautomatisierung (engl. Home-Automation) und Energie-Management unterteilt wer-

den.

Unter den Begriff AAL fallen Systeme, die den Gesundheitszustand eines Menschen über-

wachen und den Komfort und die Sicherheit erhöhen. Diese Systeme richten sich hauptsäch-

lich an pflegebedürftige, gesundheitlich beeinträchtigte und ältere Personen. Ziel ist es, den

Lebenskomfort zu steigern, den Pflegebedarf durch Angehörige oder externe Personen zu

senken und den Wechsel in eine stationäre Pflegeeinrichtung hinauszuzögern bzw. zu ver-

meiden. Beispiele für AAL-Systeme sind die Überwachung der Vitalfunktionen (z.B. Blut-

zucker, Herzfrequenz), die Erinnerung an die Medikamenteneinnahme oder das Abschalten

von elektrischen Verbrauchern (z.B. Herd) beim Verlassen der Wohnung, siehe auch Ab-

schnitt 2.1.1 [1], [2].

Heimautomatisierung ist ein Sammelbegriff für Systeme zur Steigerung des Wohnkomforts

und der Sicherheit. Unter diesen Begriff fallen unzählige Anwendungsbeispiele. Dies kön-

nen Haustechnikgeräte, wie z.B. Heizungs-, Lüftungs-, Licht- und Rollladensteuerung,

smarte Geräte, wie z.B. ein Kühlschrank oder eine Hausapotheke, die den Bestand und das

Verfallsdatum kontrollieren und bei Bedarf Produkte automatisch nachbestellen, oder Si-

cherheitssysteme, wie z.B. eine Alarmanlage, eine Urlaubsschaltung, ein Zutrittssystem via

Fingerabdruck oder Rauchmelder, sein. Weitere Anwendungsgebiete sind in Abschnitt 2.1.2

zu finden [1], [3].

Unter Energie-Management fallen Anwendungen der Tarifs- und Verbrauchsinformation

und das Management von elektrischen Netzen. Unter die erste Kategorie fallen z.B. die An-

zeige des dynamischen Energiepreises oder des aktuellen Energieverbrauchs und unter die

Einleitung 2

zweite Kategorie z.B. Last- und Transport-Management oder Spannungsregelung. Nähere

Details sind in Abschnitt 2.1.3 zu finden [1], [4].

1.1 Motivation

Der Markt für intelligente Gebäudeautomatisierungslösungen hat in den letzten Jahren

enorm an Dynamik gewonnen, ein Durchbruch konnte aber noch nicht erzielt werden. Die

Zuwächse konnten größtenteils durch die starke Verbreitung von Smartphones und Tablets

und durch die neuen Anwendungsmöglichkeiten, die durch die Ausrollung der Smart Meter

möglich sind, erzielt werden [5]. Unternehmen aus den unterschiedlichsten Bereichen brin-

gen Smart Home Lösungen auf den Markt. Dazu zählen unter anderem Telefonanbieter (z.B.

die deutsche Telekom), Stromanbieter (z.B. RWE) und Gerätehersteller (z.B. AVM, Belkin).

Die derzeit verfügbaren Lösungen verwenden eine Vielzahl von unterschiedlichen, meist

proprietären Übertragungsprotokollen und sind in den meisten Fällen nicht zueinander kom-

patibel [6]. Die meist verbreitetsten Funkstandards im Smart Home Bereich sind Zigbee, Z-

Wave und Bluetooth Low Energy [7]. Derzeit drängen Apple mit dem Produkt „Homekit“

[8] und Google mit „Weave“ [9] auf den Markt. Beides sind proprietäre Plattformen für die

Kommunikation mit Smart Home Komponenten. Google stellt gleichzeitig mit dem Projekt

„Brillo“ eine abgespeckte Variante des Android Betriebssystems für Smart Home Kompo-

nenten bereit.

Durch das Fehlen eines Kommunikationsstandards sind derzeit meist nur Einzellösungen

erhältlich. Dies führt meistens dazu, dass sich die Kunden beim Kauf an einen Hersteller

binden und mehrere Systeme parallel eingesetzt werden müssen. Jedes dieser Systeme ist

anders zu konfigurieren und für jedes System ist eine eigene App für die Bedienung erfor-

derlich. Ein weiteres Problem ist die unterschiedliche Erfüllung von Sicherheitsaspekten in

den einzelnen Protokollen. In [10] werden die Schwachstellen der einzelnen Protokolle ana-

lysiert. Eine einheitliche Norm könnte alle aktuellen Sicherheitsaspekte abdecken und die

Sicherheit in einem Smart Home erhöhen. Der zweite Vorteil wäre die Interoperabilität zwi-

schen verschiedenen Herstellern. Damit wäre es für die Endkunden möglich, ein für ihre

Bedürfnisse angepasstes Smart Home System im Baukastenprinzip zusammenzustellen.

Eine Erweiterung eines bestehenden Systems wäre jederzeit durch Komponenten eines be-

liebigen Herstellers möglich. Der Großteil der derzeit verfügbaren Systeme sieht keine An-

bindung von externen Datenquellen, wie z.B. vom Netzbetreiber, vor. Dies gestaltet sich

auch schwierig, da viele der Kommunikationsprotokolle nicht für die Kommunikation nach

Einleitung 3

außen gedacht sind und die Datenquelle verschiedene Protokolle unterstützen müsste. Der

Bericht [11] kommt zum Schluss, dass sich nicht das weit verbreitetste Smart Home System

durchsetzen wird, sondern das System, das die größtmögliche Vernetzbarkeit mit anderen

Herstellern ermöglicht [1].

1.2 Zielsetzung

Die Ziele dieser Arbeit sind es, vorhandene Programmiersysteme und Kommunikationspro-

tokolle auf die Anforderungen eines Smart Homes zu testen und das geeignetste Program-

miersystem und Kommunikationsprotokoll zu definieren. Dazu erfolgt in Kapitel 2 eine An-

forderungsanalyse. Es werden typische Anwendungsfälle in den Bereichen AAL, Home-

Automation und Energie-Management definiert und von diesen die funktionalen und nicht-

funktionalen Anforderungen an das Programmiersystem und an das Kommunikationsproto-

koll abgeleitet. Zusätzlich werden Testfälle definiert, mit denen die Programmiersysteme

und Kommunikationsprotokolle auf die Erfüllung der Anforderung getestet werden können.

In Kapitel 3 erfolgt eine Beschreibung der Normen für speicherprogrammierbare Steuerun-

gen. Analysiert werden zwei Normen der International Electrotechnical Commission (IEC),

die IEC 61131 und die IEC 61499. Das Kapitel 4 widmet sich den Kommunikationsproto-

kollen SOAP, Representational State Transfer (REST), WebSocket und Extensible Messaging

and Presence Protocol (XMPP). In Kapitel 5 werden Kodierungsverfahren beschrieben, die

häufig bei Web Services eingesetzt werden. Die Bewertung der Programmiersysteme und

Kommunikationsprotokolle, die Auswahl des am besten geeignetsten Programmiersystems

und Kommunikationsprotokolls und die für die Übertragung notwendigen Kodierungsver-

fahren erfolgen in Kapitel 6.

In Kapitel 7 erfolgt die Definition der System- und Software-Architektur zur Ausführung

der in Abschnitt 2.3 definierten Testfälle. Danach erfolgt in Kapitel 8 die Auswahl der Hard-

und Software-Komponenten für die praktische Umsetzung der Testanwendungen. Das Ka-

pitel 9 beschreibt die Implementierung des Kommunikationssystems und der Anwendungs-

logik. Die Testfälle werden in Kapitel 10 ausgeführt und die Ergebnisse dokumentiert. Dabei

erfolgt auch die Bewertung, ob das ausgewählte Programmiersystem und Kommunikations-

protokoll die definierten Anforderungen erfüllen. In Kapitel 11 erfolgt die Evaluierung des

Einleitung 4

Testaufbaus hinsichtlich Reaktionsgeschwindigkeit, Nachrichtengröße und Systemauslas-

tung. Die Arbeit wird in Kapitel 12 zusammengefasst, Optimierungsmöglichkeiten definiert

und mit einem Ausblick abgerundet.

1.3 Innovationspotenzial

Der Markt für Smart Home Komponenten ist seit Jahren kräftig am Wachsen. Ein Durch-

bruch konnte aber bis jetzt noch nicht erzielt werden. Einer der Hauptgründe ist, wie bereits

im vorherigen Abschnitt erwähnt, das Fehlen von Programmier- und Kommunikationsstan-

dards. Durch die großflächige Einführung der Smart Meter in der Europäischen Union wird

der Bedarf an Smart Home Komponenten in den nächsten Jahren weiter ansteigen und der

Markt kräftig wachsen. Der Verband der Elektrotechnik, Elektronik und Informationstech-

nik (VDE) sieht ein hohes Wachstumspotenzial und rechnet damit, dass ein Smart Home im

Jahr 2025 Standard ist. Studien rechnen mit einem Umsatz im deutschen Markt von 19 Mrd.

€ im Jahr 2025 [12]. Eine PricewaterhouseCoopers (PwC)-Studie [13] vom April 2015 rech-

net mit einem Durchbruch und einer Verzehnfachung des deutschen Marktes im Jahr 2030.

Bis zum Jahr 2030 wird jedes dritte neu errichtete oder renovierte Haus ein Smart Home

sein. Derzeit liegt die Marktdurchdringung bei 3 %, diese dürfte bis 2017 auf 10 % und bis

2030 auf 30 % steigen [1].

Der Markteinstieg für neue Unternehmen gestaltet sich derzeit schwierig. Die Entwicklungs-

abteilung des Unternehmens muss sich zwischen der Entwicklung eines eigenen, proprietä-

ren oder für die Verwendung eines der zahlreich vorhandenen Kommunikationsprotokolle

entscheiden. Die Entwicklung eines eigenen Protokolls ist sehr zeit- und kostenintensiv, da-

für kann es an das Anwendungsszenario angepasst werden. Bei Verwendung eines vorhan-

denen Protokolls fließt die Zeit in die Analyse und Auswahl des für die Anwendung geeig-

netsten Protokolls, verbunden mit dem Risiko, dass ein Protokoll gewählt wird, das sich am

Markt unter Umständen nicht durchsetzen wird. Bei einem standardisierten Protokoll würde

dieser erste Entwicklungsschritt entfallen, da auf vorhandene Bibliotheken zurückgegriffen

werden kann. Dadurch würden sich die Entwicklungszeit und die Time-to-Market wesent-

lich verkürzen.

Für Dienstleister, die Daten für das Smart Home zur Verfügung stellen wollen, wie z.B.

Netzbetreiber oder Wetterstationen, gestaltet sich der Markteinstieg ebenfalls schwierig. Bei

Einleitung 5

vielen Smart Home Lösungen ist eine Kommunikation mit externen Stellen nicht vorgese-

hen. Bei den wenigen Lösungen, bei denen die Einbindung von externen Dienstleistern vor-

gesehen ist, muss vom Dienstleister für jede Smart Home Lösung eine eigene Schnittstelle

entwickelt werden. Dies ist sehr zeit- und kostenintensiv. Bei einem standardisierten Kom-

munikationsprotokoll und Programmiersystem kann der Dienstleister ein Modul in Form

von einer Bibliothek oder eines Funktionsbausteins (FBs) erstellen und diesen über einen

App Store vertreiben. Die Endkunden hätten dadurch den Vorteil, dass für die Gestaltung

ihres individuellen Smart Homes eine große Auswahl an Apps zur Verfügung stehen wür-

den.

Die Endkunden können derzeit, wie bereits im vorherigen Abschnitt erwähnt, nur auf her-

stellerspezifische Systeme zurückgreifen, die in den meisten Fällen nicht zueinander kom-

patibel sind. In vielen Fällen sind für ein Smart Home System mehrere parallele Systeme,

wie z.B. Heizungssteuerung und Rollladensteuerung, notwendig. Für jedes System wird eine

eigene App benötigt und jedes System ist anders zu konfigurieren. Mit einem Kommunika-

tions- und Programmierstandard könnten die Endkunden ihre individuelle Smart Home Lö-

sung nach dem Baukastenprinzip aus den unterschiedlichsten Komponenten verschiedener

Hersteller zusammenstellen. Dieses System könnte von einer zentralen Stelle aus konfigu-

riert und über eine einzige App bedient werden. Bei Bedarf könnte ein bestehendes System

jederzeit mit neuen Komponenten beliebig erweitert werden.

Anforderungsanalyse 6

2 Anforderungsanalyse

In diesem Kapitel erfolgt die Anforderungsanalyse für ein Programmiersystem und ein

Kommunikationsprotokoll für ein Smart Home. Im ersten Abschnitt werden typische An-

wendungsfälle in den Bereichen AAL, Home-Automation und Energie-Management defi-

niert und die wichtigsten zusammengefasst. In Abschnitt 2.2 werden aus den zuvor definier-

ten Anwendungsfällen Anforderungen für das Programmiersystem und das Kommunikati-

onsprotokoll abgeleitet. Im letzten Abschnitt werden Testfälle definiert, mit denen die Pro-

grammiersysteme und Kommunikationsprotokolle auf die Erfüllung der Anforderungen ge-

testet werden können.

2.1 Use Cases

Die Anwendungsfälle (engl. Use Cases) unterteilen sich in die Bereiche AAL, Home Auto-

mation und Energie-Management. Diese drei Bereiche überschneiden sich leicht, daher

kommen einige Use Cases mehrfach vor. In weiterer Folge werden von diesen Use Cases

die Anforderungen an das Programmier- und Kommunikationssystem abgeleitet.

2.1.1 AAL

In diesem Abschnitt werden die Anwendungsfälle für ein AAL-System ermittelt. Dabei wer-

den die Einsatzbereiche und Themenschwerpunkte eines AAL-Systems erörtert.

Für ein AAL-System gibt es zahlreiche Einsatzbereiche. Grob können diese in drei Bereiche

unterteilt werden [1], [2], [14], [15]:

Gesundheit

o Überwachung der Vitalfunktionen (z.B. Blutdruck, Blutzucker)

o Überwachung von technischen Geräten (z.B. Herzschrittmacher)

o Erkennung von Sturz und Notsituationen und darauffolgende Alarmierung

o Notrufarmbänder

o Erinnerung an Medikamenteneinnahme oder Bewegungsprogramme

Komfort

o Steuerung von Licht und Rollläden

o Elektronisches Zutrittssystem

o Telefonieren über Bildaufruf


o Kommunikationsnetzwerke zu Familienmitgliedern, Freunden und Bekann-

ten

o Organisation von Freizeitaktivitäten

Sicherheit

o Automatische Abschaltung elektronischer Verbraucher

o Warnmeldung beim Verlassen des Hauses bei geöffneten Fenstern oder bei

eingeschalteten Elektrogeräten

o Alarmfunktionen (Feuer, Wasser, Gas)

o Tür- und Fensterüberwachung

o Erkennung von Aktivitäten über Bewegungsmelder, Wasser- und Stromver-

brauch

o Kamera

2.1.2 Home-Automation

In diesem Abschnitt folgen die Anwendungsfälle für den Bereich Home-Automation.

Die Home-Automation umfasst ein großes Gebiet von Anwendungen. Diese können in fol-

gende vier Bereiche eingeteilt werden [1], [3]:

Moderne Haushaltsführung

o Abdunkelung

Jalousien, Markisen und Rollläden werden mit Hilfe einer Zeitsteuerung,

Helligkeits-, Wind- und Regensensoren automatisch geöffnet oder geschlos-

sen.

o Beleuchtung

Für jeden Raum individuell konfigurierbar, Reaktion auf Ereignisse (z.B.

Verlassen der Wohnung).

o Heizung

Regelung von extern (z.B. Smartphone), automatisches Absenken beim Ver-

lassen des Raums bzw. der Wohnung oder beim Öffnen eines Fensters.

o Lüftung

Bei schlechter Luftqualität wird die Lüftung eingeschaltet oder die Fenster

geöffnet.


o Klima

Heizung, Lüftung, Jalousien sind miteinander vernetzt und regeln das Raum-

klima energieeffizient.

o Gartenpflege

Der Garten wird in Abhängigkeit des Wetters und der Wettervorhersagen be-

wässert und der Rasen automatisch gemäht und gedüngt.

Entertainment & Lifestyle

o Multi-Device-Konsum

Die Unterhaltungselektronik tauscht Daten drahtlos oder über eine Kabelver-

bindung aus. Dadurch wird z.B. die Wiedergabe von Fotos über den Fernse-

her oder der Zugriff auf die eigene Musiksammlung vom Radio oder Fernse-

her aus ermöglicht.

o Vernetzung

Die Unterhaltungselektronik ist mit dem Internet verbunden. Damit wird z.B.

das Surfen im Internet über den Fernseher, das Herunterladen von Spielfil-

men oder das Programmieren des DVD-Recorders über das Smartphone er-

möglicht.

o Personalisierung

Filme, Musik und Spiele werden aufgrund des Nutzerverhaltens und persön-

licher Interessen vorgeschlagen.

o Interaktivität

Die Anwender können sich an einem TV Programm aktiv beteiligen. Es kann

z.B. an Spielen, Wettbewerben, Wetten oder Abstimmungen teilgenommen

werden.

Gesundheitspflege und Ernährung

o Küchen-Assistent

Koordination von Küchengeräten zur Zubereitung von Nahrung und Kom-

munikation mit anderen Bewohnern.

o Smarter Kühlschrank

Überprüft die Haltbarkeit von Lebensmittel und bestellt automatisch nach.

o Heimapotheke

Überprüft Bestand und Verfallsdatum von Medikamenten und bestellt auto-

matisch nach.


o Wellnessbereich

Im Wellnessbereich (z.B. Sauna, Whirlpool) werden Licht, Temperatur,

Musik und Düfte automatisch geregelt.

Gebäudesicherheit

o Notfallsystem

Z.B. Sprinkleranlage gegen Feuer, Abschalten von Wasser bei einem Rohr-

bruch, Abschalten des Stroms bei einem Brand.

o Schadensmeldung und Vorkehrung

Einbruch, Wasser, Feuer werden automatisch erkannt und gemeldet, Anwe-

senheitssimulation (z.B. Lichter, Rollläden, Jalousien), Videoüberwachung,

Notruftaster.

o Schlüsselsteuerung

Abschalten von Elektrogeräten und Aktivierung der Alarmanlage beim Ver-

lassen des Gebäudes.

o Tür- und Fensterüberwachung

Meldung offenstehender Türen und Fenster beim Verlassen des Gebäudes.

o Urlaubssteuerung

Zeitabhängige Anwesenheitssimulation mit Hilfe der Lichter, Rollläden, Ja-

lousien, etc.

o Zutrittskontrolle

Zutrittssystem durch biometrische Merkmale (z.B. Fingerabdruck, Iris).

2.1.3 Energie-Management

Der letzte Teil der Use Cases behandelt den Bereich Energie-Management.

Die Anwendungsfälle können in zwei Gruppen eingeordnet werden [4], [16], [17], [18]:

Tarif- und Verbrauchsinformationen

o Anzeige des dynamischen Energiepreises

o Tarifvergleich

o Anzeige von Verbrauchsdaten (z.B. Tagesverbrauch, aktueller Verbrauch

von einzelnen Geräten)

Netzmanagement

o Lastmanagement in Abhängigkeit des Energiepreises


o Lastmanagement zur Einhaltung von vertraglich definierten Leistungsgren-

zen

o Lastmanagement in Abhängigkeit von Netzkenndaten zur Vermeidung von

Verbrauchsspitzen

o Spannungsregelung, Wirk- und Blindleistungsregelung eines Erzeugers (z.B.

Photovoltaik-Anlage)

o Automatisches Laden bzw. Entladen von Speichersystemen (z.B. Batterie, E-

Car)

o Transportmanagement (Vermeidung von Übertragungsverlusten durch lokale

Erzeugung und lokalen Verbrauch)

2.1.4 Zusammenfassung

Wie bereits am Anfang des Abschnitts erwähnt, gibt es bei den Use Cases der drei Bereiche

AAL, Home-Automation und Energie-Management Überschneidungen. Daher können viele

Anwendungsfälle zusammengefasst werden.

Nachfolgende Aufzählung enthält eine Zusammenfassung der Anwendungsfälle, die speziell

für Smart Homes von Bedeutung sind. Anwendungsfälle aus den Bereichen Wellness und

Unterhaltungselektronik wurden nicht weiter betrachtet.

UC01: Notsituationserkennung

Erkennung von Notfällen durch mobile Messgeräte, Sensoren, Energie- und

Wasserverbrauch, Bewegungsmelder und Absetzen eines Notrufs.

UC02: Sturzerkennung

Zur Vermeidung einer Unterkühlung werden bei einem Sturz die Fenster ge-

schlossen und die Raumtemperatur erhöht.

UC03: Gesundheitsdatenübermittlung

Mobile Messgeräte übermitteln Gesundheitsdaten (z.B. Blutdruck, Zucker) auto-

matisch an den Arzt.

UC04: Fernöffnung

Die Wohnungstür kann bei einem Notfall durch eine Sicherheitsfirma geöffnet

werden.

UC05: Alarmmeldung

Benachrichtigung bei Feuer, Wasser- oder Gasaustritt an Besitzer, Feuerwehr

oder Verwandte.


UC06: Automatische Abschaltung

Abschalten von Geräten bei längerer Inaktivität (Bügeleisen, Herd, etc.), z.B.

durch Bewegungssensor im Bügeleisen, Bewegungsmelder beim Herd.

UC07: Flexible Konfigurierbarkeit

Da sich der Betreuungsbedarf einer 60-jährigen Person stark vom Betreuungsbe-

darf einer 90-jährigen Person unterscheidet, muss das System flexibel konfigu-

rierbar sein.

UC08: Heizungssteuerung

Ein- bzw. Ausschalten und Konfiguration über Handy App oder Browser. Auto-

matisches Ausschalten der Heizung beim Öffnen eines Fensters.

UC09: Einbruchsbenachrichtigung

Wird nach dem Verlassen des Hauses eine Tür bzw. ein Fenster geöffnet oder

eine Bewegung in der Wohnung festgestellt, wird der Besitzer per Handy ver-

ständigt.

UC10: Erinnerungsfunktion

Erinnerung beim Verlassen des Hauses an eingeschaltete Verbraucher, offene

Fenster und Türen.

UC11: Anwesenheitssimulation

Konfiguration per App oder Browser. Lichter (Helligkeit, Farbe) und Rollläden

werden automatisch gesteuert.

UC12: Automatische Gartenpflege

Bewässern, Düngen, Mähen wird vollautomatisch und in Abhängigkeit vom

Wetter und der Wetterprognose durchgeführt.

UC13: Rollladensteuerung

Die Rollläden schließen sich bei Sonnenschein und ausreichender Raumtempe-

ratur automatisch.

UC14: Unwetterschutz

Öffnen der Rollläden, Schließen der Fenster bei einer Unwetterwarnung. Unwet-

terdaten werden vom Wetterdienst empfangen.

UC15: Smarter Kühlschrank

Beim Sinken des Bestandes im Kühlschrank wird automatisch eine Bestellung

beim Lieferservice durchgeführt.


UC16: Anzeige des Energiepreises

Der aktuelle Energiepreis, der Energiepreis der letzten Stunden und der Trend der

nächsten Stunden werden auf einem Display angezeigt.

UC17: Anzeige der Verbrauchsdaten

Der aktuelle Stromverbrauch und der historische Verbrauch können auf einem

Display angezeigt werden.

UC18: Steuerung von Verbrauchern in Abhängigkeit vom Energiepreis

Verbraucher (z.B. Geschirrspüler, Waschmaschine) können so konfiguriert wer-

den, dass sie innerhalb eines gewählten Zeitraums beim günstigsten Energiepreis

eingeschaltet werden.

UC19: Lastmanagement anhand von Netzkenndaten

Der Netzbetreiber kann bei großen Verbrauchern (z.B. Waschmaschine, Warm-

wasser-Boiler) um eine Verschiebung der Last (z.B. um eine Stunde) anfragen.

UC20: Lademanagement von Stromspeichern

Der Netzbetreiber kann Stromspeicher in Abhängigkeit von Netzkenndaten laden

oder entladen.

2.2 Anforderungen

Im vorherigen Abschnitt wurden Anwendungsfälle für ein Smart Home in den Bereichen

AAL, Home-Automation und Energie-Management ermittelt. Von diesen und aus den tech-

nischen Berichten [19] und [20] werden nun die Anforderungen an das Programmiersystem

und an das Kommunikationsprotokoll abgeleitet.

2.2.1 Programmiersystem

Aus den Anwendungsfällen in Abschnitt 2.1.4 ist zu entnehmen, dass ein Smart Home aus

einer Vielzahl von Komponenten (Aktoren und Sensoren) besteht. Zur Vermeidung von In-

sellösungen und für den besseren Überblick ist es notwendig, dass das Smart Home von

einer zentralen Stelle aus programmiert und die Anwendung auf mehrere Komponenten ver-

teilt werden kann.

Außerdem ist aus den Anwendungsfällen zu erkennen, dass unter dem Begriff Smart Home

kein standardisiertes System zu verstehen ist, sondern ein Smart Home für jedes Objekt

(Haus, Wohnung) individuell gestaltet wird. Die Entwicklung und Modifizierung der An-

wendung muss durch den Benutzer in einer sehr einfachen Art und Weise erfolgen können.


Smart Homes bestehen typischerweise aus sehr unterschiedlichen, heterogenen Systemen.

Daher muss die Programmierung unabhängig vom eingesetzten System erfolgen.

In den Anwendungsfällen sind auch einige sehr zeitkritische Anwendungen (z.B. UC01 –

Notsituationserkennung, UC02 – Sturzerkennung, UC19 – Lastmanagement, UC20 - Lade-

management) enthalten. Aus diesem Grund muss die Laufzeitumgebung performant genug

sein, um diese Anwendungsfälle in einer minimalen Zeitspanne ausführen zu können.

Zusammengefasst ergeben sich folgende Anforderungen an das Programmiersystem [19],

[20]:

REQ01: Das Programmiersystem muss die Entwicklung von verteilten Anwendungen

unterstützen.

REQ02: Die Entwicklung von Anwendungen muss auf eine sehr einfache Art und Weise

möglich sein.

REQ03: Die Performance der Laufzeitumgebung muss für die Ausführung der Anwen-

dungsfälle ausreichend sein.

REQ04: Die Anbindung von Legacy-Systemen muss möglich sein.

REQ05: Die Unterstützung von Standard-Schnittstellen (z.B. Transmission Control Pro-

tocol / Internet Protocol (TCP/IP), XMPP) muss gegeben sein.

REQ06: Das Programmiersystem muss eine systemunabhängige Programmierung er-

möglichen.

2.2.2 Kommunikationsprotokoll

Für die individuelle Gestaltung eines Smart Homes ist es notwendig, dass Komponenten so

einfach wie möglich, am besten durch „Plug & Play“, ausgetauscht und hinzugefügt werden

können.

In einem Smart Home gibt es unzählige unterschiedliche Anwendungsszenarien, die den

Austausch von unterschiedlichsten Nutzdaten erfordern. Daher darf es durch das Protokoll

in keinster Weise zu Einschränkungen in der Gestaltung von Nutzdaten kommen. Smart Ho-

mes bestehen typischerweise aus sehr unterschiedlichen, heterogenen Systemen. Daher muss

der Datenaustausch zwischen heterogenen Systemen möglich sein.

Zum Start der Abarbeitung eines Anwendungsfalles sind in vielen Fällen Ereignisse notwen-

dig (z.B. UC01 - Notsituationserkennung). Um diese Ereignisse möglichst zeitnah und per-

formant melden zu können, muss das Protokoll asynchrone Kommunikation (z.B. Push oder


Publish-Subscribe) unterstützen.

Bei vielen Daten (z.B. aktueller Zählerstand) ist eine sofortige Benachrichtigung per Event

nicht notwendig. Hier ist es ausreichend, die Daten bei Bedarf abzufragen. Daher muss das

Protokoll eine synchrone Kommunikation (Request-Response) unterstützen.

Bei einigen Anwendungsfällen werden sensible, personenbezogene Daten (z.B. Gesund-

heitsdaten bei UC03) an externe Stellen übertragen. Aus diesem Grund ist es unbedingt not-

wendig, dass die Kommunikation zu externen Stellen verschlüsselt erfolgt.

Einige Anwendungsfälle erfordern den Fernzugriff auf das Smart Home (z.B. UC04 – Fern-

öffnung oder UC08 – Heizungssteuerung). Das Protokoll muss also auch im Internet ver-

wendet werden können, also routbar sein. Zum Schutz vor unautorisierten Zugriffen ist eine

Authentifizierungsfunktion unbedingt erforderlich.

Für die Ausführung von zeitkritischen Anwendungsfällen (z.B. UC01 – Notsituationserken-

nung, UC02 – Sturzerkennung, UC19 – Lastmanagement, UC20 - Lademanagement) muss

das Protokoll eine entsprechend große Performance bieten.

Zusammengefasst ergeben sich folgende Anforderungen an das Kommunikationsprotokoll

[19], [20]:

REQ11: Das Hinzufügen von neuen Knoten muss sehr einfach erfolgen, am besten durch

„Plug & Play“.

REQ12: Das Protokoll darf die Variabilität der Nutzdaten nicht einschränken.

REQ13: Das Protokoll muss asynchrone Kommunikation (Push oder Publish-Subscribe)

unterstützen.

REQ14: Das Protokoll muss eine synchrone Kommunikation (Client-Server bzw. Requ-

est-Response) unterstützen.

REQ15: Das Protokoll muss eine zeitgemäße Verschlüsselung unterstützen.

REQ16: Das Protokoll muss die Möglichkeit einer Authentifizierung bereitstellen.

REQ17: Das Protokoll muss lokale und entfernte Ziele (Internet) erreichen können (rout-

bares Protokoll).

REQ18: Die Performance des Protokolls muss für die Ausführung der Anwendungsfälle

ausreichend sein.

REQ19: Das Protokoll muss den Austausch von Daten zwischen heterogenen Systemen

unterstützen.


2.3 Test Cases

In diesem Abschnitt werden Test Cases definiert, um das Programmiersystem und das Kom-

munikationsprotokoll auf die Erfüllung der in Abschnitt 2.2 definierten Anforderungen zu

testen.

Folgende Test Cases wurden definiert:

TC1: Demand-Side-Management mittels Stromspeicher

TC2: Erinnerungsfunktion

Diese zwei Test Cases decken den Großteil der zuvor definierten Anforderungen ab. Mit

dem TC1 wird eine asynchrone Kommunikation zwischen Netzbetreiber und Smart Home

getestet, wobei der Schwerpunkt vor allem auf der Sicherheit und der Performance der Kom-

munikation liegt. Mit dem TC2 wird eine synchrone Kommunikation innerhalb des Smart

Homes getestet. Die Detailbeschreibungen der Test Cases erfolgt in den nachfolgenden Ab-

schnitten.

2.3.1 TC1 - Demand-Side-Management mittels Stromspeicher

In Tabelle 1 ist die Detailbeschreibung von Test Case 1 (TC1) zu finden.

ID TC1

Name Demand-Side-Management mittels Stromspeicher

Kurzbeschreibung Laden und Entladen einer Pufferbatterie in Abhängigkeit von

Netzkenndaten.

Trigger Stromüberschuss oder –mangel

Akteure Netzbetreiber, Stromspeicher

Vorbedingungen Die Pufferbatterie meldet sich beim Netzbetreiber mittels Be-

nutzername und Kennwort über eine verschlüsselte Verbin-

dung an.

Essentielle Schritte 1) Der Netzbetreiber stellt einen Stromüberschuss oder -mangel

fest.


a) Der Netzbetreiber sendet der Pufferbatterie ein Event zum

Laden oder Entladen der Batterie.

2) Der Netzbetreiber stellt fest, dass die Netzstabilität wieder ge-

geben ist.

a) Der Netzbetreiber sendet der Pufferbatterie ein Event zum

Beenden des Lade- oder Entladevorgangs der Batterie.

Mögliche Erweite-

rungen

3) Der Stromspeicher stellt fest, dass der Akku vollständig gela-

den oder entladen ist.

a) Der Stromspeicher beendet den Lade- oder Entladevor-

gang.

Zugeordnete

Anforderungen

REQ01

REQ02

REQ03

REQ05

REQ06

REQ11

REQ12

REQ13

REQ15

REQ16

REQ17

REQ18

Tabelle 1: TC1 - Demand-Side-Management mittels Stromspeicher

2.3.2 TC2 - Erinnerungsfunktion

In Tabelle 2 ist die Detailbeschreibung von Test Case 2 (TC2) zu finden.

ID TC2

Name Erinnerungsfunktion


Kurzbeschreibung Die Bewohner werden mittels einer Anzeige an eingeschaltete

elektrische Verbraucher erinnert.

Trigger Statusänderung des Verbrauchers

Akteure Verbraucher, Display

Vorbedingungen Das Display meldet sich beim Verbraucher an

Das Display prüft in einem fixen Intervall den Status des Ver-

brauchers.

Essentielle Schritte 1) Der Verbraucher wird eingeschaltet.

a) Das Display empfängt bei der nächsten Abfrage den Status

„Eingeschaltet“ und zeigt diesen an der Anzeige an.

2) Der Verbraucher wird ausgeschaltet.

a) Das Display empfängt bei der nächsten Abfrage den Status

„Ausgeschaltet“ und zeigt diesen an der Anzeige an.

Mögliche Erweite-

rungen

3) Beim Öffnen der Wohnungstüre ertönt bei einem eingeschal-

teten Verbraucher ein Warnsignal.

Zugeordnete

Anforderungen

REQ01

REQ02

REQ05

REQ06

REQ12

REQ14

Tabelle 2: TC2 – Erinnerungsfunktion

Nachdem in diesem Kapitel die Use Cases ermittelt, von diesen die Anforderungen abgelei-

tet und Test Cases definiert wurden, erfolgt in den nächsten drei Kapiteln die Beschreibung

von Normen für speicherprogrammierbare Steuerungen, Kommunikationsprotokollen und

Kodierungsverfahren.

Normen für speicherprogrammierbare Steuerungen 18

3 Normen für speicherprogrammierbare Steuerungen

Die ersten speicherprogrammierbaren Steuerungen (SPS) wurden Ende der sechziger Jahre

in der Fahrzeugindustrie der vereinigten Staaten (USA) eingesetzt. Eine SPS hat gegenüber

einer verbindungsprogrammierten Steuerung (VPS) den Vorteil, dass komplexe Steuerungs-

funktionen mit weniger Platzbedarf und Zeitaufwand realisiert und Änderungen einfacher

durchgeführt werden können. Zusätzlich ermöglicht eine SPS die Dokumentation der Steu-

erungsfunktion direkt im Quellcode und die Fernwartung und Ferndiagnose. Die Verdrän-

gung der VPS erfolgte wegen der höheren Kosten und fehlender Standards erst Anfang der

achtziger Jahre [21].

Mit den beiden Normen des Deutschen Institut für Normung (DIN), der DIN 40719 (IEC

848) im Jahr 1977 und der DIN 19239 im Jahr 1983, wurden die ersten Normen für SPS-

Systeme definiert. Wegen der fehlenden Akzeptanz dieser Standards, entwickelten die Her-

steller zueinander inkompatible Steuerungen und Programmiersprachen. Erst Anfang der

neunziger Jahre wurde mit der DIN EN 61131 (IEC 1131, heute IEC 61131) ein Standard

mit ausreichender Akzeptanz geschaffen [21]. Basierend auf der IEC 61131 wurde im Jahr

2005 der IEC 61499 Standard entwickelt. Diese neue Norm definiert ein generisches Modell

für verteilte Steuerungen [22].

In den nächsten Abschnitten werden die Normen IEC 61131 und IEC 61499 näher beschrie-

ben. In Abschnitt 6.1 werden die beiden Normen hinsichtlich der in Abschnitt 2.2.1 definier-

ten Anforderungen bewertet und die geeignetste Norm für die Programmierung von Smart

Homes ausgewählt.

3.1 IEC 61131

Der IEC 61131 Standard wurde im Jahr 1992 erstmals veröffentlicht. Dieser umfasst den

gesamten Software-Design-Prozess für SPS-Systeme, einschließlich Programmiersprachen,

Implementierung, Kommunikation und technische Dokumentation. Der Standard besteht ak-

tuell aus neun Teilen [23], [24]:

IEC 61131-1 ed2.0 (2003-05) - General information

Im ersten Teil werden sämtliche Begriffe definiert und das vom Standard abgedeckte

technische Umfeld beschrieben.


IEC 61131-2 ed3.0 (2007-07) - Equipment requirements and tests

Dieser Teil beschreibt mechanische und elektronische Anforderungen an SPS-Sys-

teme einschließlich der zur Verifizierung notwendigen Testmethoden.

IEC 61131-3 ed3.0 (2013-02) - Programming languages

In diesem Teil werden ein Softwaremodell inklusive Programmiersprachen definiert

und Anwendungsfälle beschrieben.

IEC 61131-4 ed2.0 (2004-07) - User guidelines

Dieser Teil des Standards beschäftigt sich mit den Themen Systemauswahl, Inbe-

triebnahme, Wartung und Anwendungsrichtlinien.

IEC 61131-5 ed1.0 (2000-11) – Communications

In diesem Teil wird die Kommunikation zwischen SPS-Systemen und mit Legacy-

Systemen beschrieben.

IEC 61131-6 ed1.0 (2012-10) - Functional safety

Dieser Teil definiert Anforderungen an Sicherheits-SPS-Systeme.

IEC 61131-7 ed1.0 (2000-08) - Fuzzy-control programming

In diesem Teil des Standards wird die Programmiersprache, inklusive FBe, für

Fuzzy-Regelungen definiert.

IEC 61131-8 ed2.0 (2003-09) - Guidelines for the application and implementation of

programming languages for programmable controllers

Dieser Teil enthält Richtlinien für die Implementierung und Anwendung der im drit-

ten Teil des Standards definierten Programmiersprachen.

IEC 61131-9 ed1.0 (2013-09) - Single-drop digital communication interface for

small sensors and actuators (SDCI)

Im letzten Teil wird ein Kommunikationssystem zur Anbindung von intelligenten

Sensoren und Aktoren definiert.

In den nächsten Abschnitten erfolgt eine Beschreibung der wichtigsten Punkte des IEC

61131 Standards.

3.1.1 Software-Modell

Das IEC 61131-3 Software-Modell ist in Abbildung 1 dargestellt und enthält die Sprach-

Grundelemente und deren Beziehungen zueinander. Das Modell besteht aus mehreren


Konfiguration

Ressource

Task

Programm

FB FB

Task

Programm

Ressource

Task

Programm

FB FB

Task

Programm

Globale und lokale Variablen

Zugriffspfad

Kommunikationsfunktionen

FB

VariablerZugriffs-pfad

Funktions-baustein

Variable Ausführungs-pfad

Abbildung 1: IEC 61131-3 Software-Modell

Schichten, wobei jede Schicht ihre eigenen Elemente abstrahiert. Die Elemente können in

Programm- (z.B. Programm, FBe) und Konfigurations-Elemente (z.B. Konfiguration, Res-

sourcen, Tasks, globale Variablen, Zugriffspfad) unterteilt werden [25].

Das Software-Modell enthält folgende Grundelemente [25]:

Konfiguration

Die Konfiguration ist die oberste Schicht des Software-Modells und entspricht der

SPS.

Ressource

Jede Konfiguration enthält mindestens eine Ressource, welche alle zur Pro-

grammausführung notwendigen Elemente (Programm, Task) enthält.

Programm

Ein Programm enthält Software-Elemente, die in den verschiedenen Programmier-

sprachen (siehe Abschnitt 3.1.2) geschrieben werden können, und/oder FBe. Pro-

gramme können Ein- und Ausgabevariablen lesen bzw. schreiben und mit anderen

Programmen kommunizieren.


Task

Ein Task kontrolliert die Ausführung von einem oder mehreren Programmen oder

einzelnen FBen. Die Ausführung kann periodisch oder ereignisgesteuert erfolgen.

Funktionsbaustein

Der FB ist eines der wichtigsten Elemente der IEC 61131-3. Dieser kann in den ver-

schiedenen Programmiersprachen der Norm programmiert werden oder aus anderen

FBen, einem sogenannten Funktionsbausteinnetzwerk (FBN), bestehen. Ein FB be-

steht aus Daten (Ein- und Ausgänge) und einem Algorithmus, der bei der Ausführung

des FBs abgearbeitet wird. FBe reduzieren die Komplexität, da sie ihren Algorithmus

verbergen und dienen zur Strukturierung des Programms. Darüber hinaus sind FBe

die Basis der IEC 61499, siehe Abschnitt 3.1.4.

Funktionen

Funktionen sind Software-Elemente, die basierend auf den Eingabeparametern ein

Resultat liefern.

Globale und lokale Variablen

Der Standard erlaubt die Deklaration von globalen und lokalen Variablen. Auf glo-

bale Variablen kann aus allen Software-Elementen zugegriffen werden, auf lokale

Variablen nur aus dem Software-Element, in dem sie deklariert wurden.

Geräte-Variablen

Geräte-Variablen erlauben das Schreiben und Lesen von bestimmten Speicherberei-

chen bzw. Ein- und Ausgängen der SPS.

Zugriffspfad

Der Zugriffspfad bietet Funktionen für den Datenaustausch zwischen verschiedenen

Konfigurationen an.

3.1.2 Datentypen

Der Standard enthält eine Reihe von elementaren Datentypen, diese sind im Anhang in Ta-

belle 20 zu finden. Aus diesen können abgeleitete Datentypen, wie Felder und Datenstruk-

turen, definiert werden [25].

3.1.3 Programmiersprachen

Im dritten Teil des Standards werden textbasierte und grafische Programmiersprachen für

SPS-Systeme definiert [25]:


Textbasierte Sprachen

o Ablaufsprache (AS) / Sequential Function Chart (SFC)

o Anweisungsliste (AWL) / Instruction List (IL)

o Strukturierter Text (ST) / Structured Text (ST)

Grafische Sprachen

o Ablaufsprache (AS) / Sequential Function Chart (SFC)

o Funktionsbausteinsprache (FBS) bzw. Funktionsbausteindiagramm (FBD) /

Function Block Diagram (FBD)

o Kontaktplan (KOP) / Ladder Diagram (LD)

Anweisungsliste:

Die AWL ist eine hardwarenahe Programmiersprache, die der Assemblersprache sehr ähn-

lich ist. Die Befehle werden zeilenweise abgearbeitet, daher ist kein Strichpunkt (;) oder

ähnliches am Zeilenende notwendig. Ein Befehl besteht aus einem Operator bzw. einer

Funktion und einem oder mehreren Operanden. Optional kann vor einem Befehl eine

Sprungmarke, gefolgt von einem Doppelpunkt (:) stehen. Ein Beispiel ist in Listing 1 darge-

stellt [25].

START: LD %IX1 (* TASTE *)

ANDN %MX5 (* NICHT GESPERRT*)

ST %QX2 (* LÜFTER EIN *)

Listing 1: AWL-Beispiel, nach [25]

Strukturierter Text:

ST ist im Gegensatz zur AWL eine höhere Programmiersprache und ist der Programmier-

sprache C oder Pascal sehr ähnlich. Die Befehle werden nicht zeilenweise abgearbeitet, son-

dern sind durch einen Strichpunkt (;) getrennt. Ein Beispiel ist in Listing 2 dargestellt [25].

SUM := 0 ;

FOR I := 1 TO 3 DO

FOR J := 1 TO 2 DO

IF FLAG THEN EXIT ; END_IF

SUM := SUM + J ;

END_FOR ;

SUM := SUM + I ;

END_FOR ;

Listing 2: ST-Beispiel, nach [25]


Ablaufsprache:

Die AS wurde entwickelt um komplexe Aufgaben in Teilaufgaben aufzuteilen. Die Teilauf-

gaben selbst können in anderen Sprachen oder in der AS programmiert werden. Die AS

ähnelt Petri-Netzen und kann sowohl textuell als auch grafisch programmiert werden. Ein

Beispiel ist in Abbildung 2 dargestellt [25].

|Ventil_1_Bereit|

Ventil_1_Öffnen

Tank_1_Leer

Ventil_1_Schließen Ventil_1_RückwärtsN

Ventil_1_VorwärtsN

Schritt1

Schritt2

Schritt3

Schritt4

Abbildung 2: AS-Beispiel, nach [25]

Funktionsbaustein-Sprache:

Die FBS, auch Funktionsplan genannt, ist eine grafische Programmiersprache, die aus einem

Netzwerk von logischen Einheiten, den sogenannten FBen, besteht. Die FBe sind durch Li-

nien, den sogenannten Konnektoren, miteinander verbunden. Ein Beispiel ist in Abbildung

3 dargestellt [25].

>=1

&

Start1

Start2

Enable

Run

Abbildung 3: FBS-Beispiel, nach [25]


Kontaktplan:

Der KOP ist eine grafische Programmiersprache, die aus einem Netzwerk von Kontakten

und Spulen besteht. Die Netzwerke befinden sich zwischen Stromschienen und die Abarbei-

tung wird durch den Stromfluss beschrieben. Ein Beispiel ist in Abbildung 4 dargestellt [25].

RunStart1 Enable

Start2

Abbildung 4: KOP-Beispiel, nach [25]

3.1.4 Kommunikation

Der fünfte Teil des Standards beschreibt die Kommunikation zwischen SPS-Systemen und

von SPS-Systemen mit Legacy-Geräten, die nach dem IEC 61131-3 Standard programmiert

wurden und den IEC 61131-5 Standard für die Kommunikation nutzen [26].

Der Standard definiert kein Kommunikationsprotokoll, sondern generische Kommunikati-

onsservices auf FB-Basis, die für alle implementierten Kommunikationsprotokolle verwen-

det werden können. Diese FBe ermöglichen 1-zu-1 (Unicast), 1-zu-n (Multicast) und 1-zu-

alle (Broadcast) Verbindungen. Dadurch ist sowohl ein Client-Server, als auch ein Publish-

Subscribe Modell möglich. Verbindungen sind innerhalb des Systems (z.B. SPS mit mehre-

ren CPUs), zwischen Tasks, Applikationen und Systemen möglich [26].

Für die Anwender stehen eine Vielzahl von FBen bzw. FB-Paaren für die verschiedenen

Verbindungsarten zur Verfügung. Eine detaillierte Liste ist in [26] enthalten. Bei allen Kom-

munikations-FBen wird das Kommunikationsprotokoll bzw. der -kanal über den Ein-

gangsparameter „ID“ des FBs definiert [26].

Ein Beispiel ist in Abbildung 5 dargestellt. Der SEND FB sendet die Daten FCT1 und DAT1

an den RCV FB mit der ID ‚ORD1‘ über den Kommunikationskanal TO_PC2 und wartet

auf die Empfangsdaten RDAT1 vom Empfänger [26].


SEND

SREQ

T1.Q

TO_PC2

'ORD1'

FCT1

DAT1

REQ

R

ID

R_ID

SD_1

SD_2

NDR

ERROR

STATUS

RD_1 RDAT1

Abbildung 5: IEC 61131-5 Send FB, nach [26]

3.1.5 Aktueller Stand

Die IEC 61131 ist eine der wichtigsten Normen in der Automatisierungstechnik [27]. Der

Großteil der derzeit verfügbaren SPS-Systeme und Entwicklungs-Tools sind vollständig

oder zumindest teilweise kompatibel zu dieser Norm. Dennoch sind die Produkte der einzel-

nen Hersteller in den meisten Fällen nicht vollständig zueinander kompatibel. Dies liegt da-

ran, dass die Norm einige Punkte offen lässt oder nur sehr vage beschreibt bzw. die Hersteller

die Norm teilweise nicht vollständig erfüllen [28], [29].

Die bereits vor 20 Jahren definierte Norm wurde mehrmals überarbeitet und aktualisiert.

Dennoch lassen sich die aktuellen Trends der Softwareentwicklung meist nur über Umwege

realisieren. [30] kommt zum Ergebnis, dass die Konzepte der IEC 61131 nicht mehr Stand

der Technik in der modernen Softwareentwicklung sind. Der Trend in der Industrie geht

derzeit in Richtung Objektorientierung, Modularität, Wiederverwendbarkeit, Online-Rekon-

figuration und dezentralisierte Systeme. Diese Punkte waren zum Zeitpunkt der Entwicklung

der Norm noch überhaupt kein Thema und daher ist die Norm auch nicht explizit für diese

Themen ausgelegt [27], [28], [29].

Ein weiterer aktueller Trend ist Modell-Driven-Development (MDD). Dabei wird eine Soft-

ware über ein, meist grafisches, Modell definiert und automatisch übersetzt. Die IEC 61131

bietet mit dem FBN zwar ein grafisches Modell an, dieses stößt aber bei größeren Projekten

mit hoher Komplexität schnell an seine Grenzen und bietet nur eine einzige Ansicht (engl.

View) an. Es gibt aber Ansätze, wie z.B. SysML, mit denen eine rein grafische Programmie-

rung möglich ist und das fertige Modell in die IEC 61131 übersetzt wird [29].


Um diesen Problemen entgegenzuwirken, wurde im Jahr 2005 der IEC 61499 Standard ent-

wickelt. Da sich dieser neue Standard aus diversen Gründen in der Industrie nicht durchge-

setzt hat, siehe auch Abschnitt 3.2.3, wurde im Jahr 2013 der IEC 61131-3 Standard um

Objektorientierung erweitert [27].

3.2 IEC 61499

Der IEC 61499 Standard wurde im Jahr 2005 erstmals veröffentlicht. Das Hauptziel des

Standards ist es, ein FB-orientiertes Programmiermodell für verteilte SPS-Anwendungen zu

definieren. Der IEC 61499 Standard basiert auf den Programmiersprachen und Modellen des

IEC 61131-3 Standards und erweitert diesen für verteilte Anwendungen. Des Weiteren ver-

wendet der Standard ein ereignisbasiertes Ausführungsmodell und bietet Basisdienste für

die Online-Rekonfiguration an [22], [23].

Der Standard besteht aktuell aus drei Teilen. Ein weiterer Teil (IEC 61499-3) wurde im Jahr

2008 wieder zurückgezogen und wird nur der Vollständigkeit halber angeführt [22], [23].

IEC 61499-1 ed2.0 (2012-11) – Architecture

Dieser Teil beschreibt die Architektur und die Modelle und definiert Regeln für die

Verwendung von FBen.

IEC 61499-2 ed2.0 (2012-11) - Software tool requirements

Der zweite Teil enthält Regeln für die Entwicklung von Software-Werkzeugen für

die IEC 61499.

IEC 61499-3 ed1.0 (2004-06) - Tutorial information (zurückgezogen)

Der dritte Teil enthält Hintergrundinformationen, Anwendungsbeispiele und Ant-

worten auf häufig gestellte Fragen. Dieser Teil wurde im Jahr 2008 wieder zurück-

gezogen, da ausreichend Literatur vorhanden ist. Es ist aber wahrscheinlich, dass in

Zukunft eine überarbeitete Version veröffentlicht wird.

IEC 61499-4 ed2.0 (2013-01) - Rules for compliance profiles

Die IEC 61499 beschreibt einige Punkte sehr vage und lässt Spielraum für Interpre-

tation (z.B. Interoperabilität und Konfigurierbarkeit von Geräten unterschiedlicher

Hersteller bzw. Portabilität von Software zwischen unterschiedlichen Entwicklungs-

umgebungen). Die Implementierung dieser Punkte soll in sogenannten Complience-

Profilen beschrieben werden. Deren Struktur wird im letzten Teil der Norm definiert.


In den nächsten Abschnitten erfolgt eine Beschreibung der wichtigsten Punkte des IEC

61499 Standards.

3.2.1 Referenzmodelle

Der IEC61499-1 Standard definiert folgende acht Referenzmodelle, die ersten vier sind in

Abbildung 6 dargestellt [22]:

a. Systemmodell (System Model)

b. Gerätemodell (Device Model)

c. Ressourcenmodell (Resource Model)

d. Anwendungsmodell (Application Model)

e. Funktionsbausteinmodell (Function Block Model)

f. Verteilungsmodell (Distribution Model)

g. Managementmodell (Management Model)

h. Betriebszustandsmodelle (Operational State Models)

Gerät 1 Gerät 3 Gerät 4

Anwendung 3

Kommunikationsnetzwerk

Gesteuerter Prozess

Gerät

Prozessschnittstelle(n)

Geräte-Management

Ressource A

Gerät 2

Anwendung 1

Anwendung 2

Anwendung 2

Ressource

Prozessschnittstelle(n)

Kommunikationsschnittstelle(n)

Ausführungsplanfunktion

Kommunikationsschnittstelle(n)

Ressource B

Anwendung 1

a. Systemmodell

b. Gerätemodell c. Ressourcenmodell

d. Anwendungsmodell

Abbildung 6: IEC 61499 – Referenzmodell, nach [22]


Der FB wird als Basis dieser Modelle verwendet. Dadurch wird eine rein grafische Entwick-

lung einer verteilten Anwendung ermöglicht. Applikationen werden im Anwendungsmodell

ohne Berücksichtigung einer Verteilung oder des Kommunikationsnetzwerkes entwickelt.

Die Verteilung der Anwendung auf die einzelnen Geräte bzw. Ressourcen und die Konfigu-

ration der Kommunikationsinfrastruktur erfolgen danach im Systemmodell [22].

Systemmodell:

Ein IEC 61499 System besteht aus mehreren Geräten, die über ein Kommunikationsnetz-

werk miteinander verbunden sind und darüber kommunizieren. Gerätefunktionen werden als

Anwendungen modelliert, welche entweder auf einem einzelnen Gerät ausgeführt werden

(z.B. Anwendung 2 in Abbildung 6) oder über mehrere Geräte verteilt sind (z.B. Anwendung

1 oder Anwendung 3 in Abbildung 6) [22].

Gerätemodell:

Ein Gerät besitzt mindestens eine Schnittstelle (Kommunikations- oder Prozessschnittstelle)

und keine, eine oder mehrere Ressourcen [22].

Die Prozessschnittstelle dient zur Kommunikation zwischen der Ressource und dem physi-

kalischen Gerät (z.B. Sensor). Die Kommunikation erfolgt über Daten und/oder Ereignisse

[22].

Die Kommunikationsschnittstelle dient zur Kommunikation zwischen der Ressource und

dem Kommunikationsnetzwerk. Die Kommunikation erfolgt ebenfalls über Daten und/oder

Ereignisse. Zusätzlich stellt die Schnittstelle Dienste für die Programmierung, Konfiguration

und Diagnose zur Verfügung [22].

Ressourcenmodell:

Eine IEC 61499 Ressource ist eine unabhängige Funktionseinheit in einem Gerät. Diese

kann ohne Beeinflussung der anderen Ressourcen erstellt, gelöscht, konfiguriert oder gestar-

tet werden [22].

Die Aufgaben einer Ressource sind das Entgegennehmen von Daten und/oder Ereignissen

von der Prozess- und/oder Kommunikationsschnittstelle, das Verarbeiten der Daten

und/oder Ereignisse und das Zurückgeben der verarbeiteten Daten und/oder Ereignisse an


die Prozess- und/oder Kommunikationsschnittstelle. Die Kommunikation zwischen der Res-

source und den Schnittstellen erfolgt über spezielle Dienstschnittstellen-FBe (Service Inter-

face Function Blocks -SIFBs) [22].

Die Ausführungsplanfunktion ist für die Ausführung der FBe und dem Datenaustausch zwi-

schen diesen in Abhängigkeit der Zeit- und Ablaufanforderungen zuständig [22].

Anwendungsmodell:

Eine IEC 61499 Anwendung besteht aus einem FBN, dessen Knoten FBe oder Unteranwen-

dungen mit deren Parametern sind und dessen Kanten aus Daten- und Ereignisverbindungen

bestehen [22].

Eine Anwendung kann auf einer Ressource ausgeführt oder über mehrere Ressourcen auf

demselben oder auf anderen Geräten verteilt werden [22].

Funktionsbausteinmodell:

Eine FB-Instanz, siehe Abbildung 7, ist eine funktionale Software-Einheit mit einem eigenen

Namen und eigenen Instanzvariablen.

Diese weist folgende Merkmale auf [22]:

Typenbezeichnung und Instanzname

Ereigniseingänge, die Ereignisse entgegennehmen und verknüpfte Algorithmen aus-

führen

Ereignisausgänge, über die Algorithmen oder Ressourcenfunktionen Ereignisse aus-

geben können

Dateneingänge, die auf Eingangsvariablen abgebildet werden

Datenausgänge, die auf Ausgangsvariablen abgebildet werden

Interne Daten, die auf interne Variablen abgebildet werden

Funktionale Eigenschaften, die durch Algorithmen oder Ressourcenfunktionen in

Abhängigkeit von internen Daten und/oder Statusinformationen definiert werden.

Die funktionalen Eigenschaften werden in der FB-Typendefinition festgelegt.

Die im FB enthaltenen Algorithmen, die Ausführungssteuerung und die internen Daten sind

von außen nicht sichtbar oder veränderbar. Details zum FB folgen in Abschnitt 3.2.2 [22].


Ereignisfluss Ereignisfluss

Datenfluss Datenfluss

Ereigniseingänge Ereignisausgänge

Dateneingänge Datenausgänge

Instanzname

Typenbezeichnung

Algorithmen

Interne Daten

Ausführungs-steuerung

Ressourcenfunktionen

Abbildung 7: IEC 61499 FB

Verteilungsmodell:

Eine Anwendung oder Unteranwendung kann durch die Zuordnung ihrer FB-Instanzen auf

mehrere Ressourcen auf einem oder mehreren Geräten verteilt werden. Da ein FB eine ato-

mare Einheit bildet und die internen Details von außen nicht sichtbar sind, kann eine FB-

Instanz nicht auf mehreren Ressourcen verteilt werden [22].

Die funktionalen Beziehungen zwischen den FBen wird durch eine Verteilung nicht beein-

flusst. Das Zeitverhalten und die Zuverlässigkeit des Kommunikationssystems wirkt sich

jedoch auf das Zeitverhalten und die Zuverlässigkeit der verteilten Anwendung aus [22].

Managementmodell:

Das Managementmodell ist für die Kommunikation mit der Entwicklungsumgebung, Ver-

waltung der FBe inkl. deren Verbindungen (z.B. FB starten, Verbindung löschen, Rekonfi-

guration) und für das Anwendungs-Lifecycle-Management verantwortlich. Die Manage-

ment-Dienste eines Gerätes können entweder als eigene Management-Ressource abgebildet

oder über alle Ressourcen verteilt werden [22].


Betriebszustandsmodelle:

Jedes System muss entworfen, in Betrieb genommen, betrieben und gewartet werden. Diese

Funktionalitäten werden durch das System-Lebenszyklus-Modell ermöglicht. Da jedes Sys-

tem in mehrere Funktionseinheiten (z.B. Gerät, Ressource, Anwendung) unterteilt ist, hat

jede Funktionseinheit ihren eigenen Lebenszyklus [22].

Ein Lebenszyklus besteht aus Zuständen (z.B. IDLE, RUNNING, STOPPED) mit zugehö-

rigen Berechtigungen. Ist z.B. eine Funktionseinheit im RUNNING Zustand, kann kein Ap-

plikations-Download durchgeführt werden [22].

3.2.2 Funktionsbaustein

Ein FB, siehe Abbildung 8, ist eine Softwarekomponente, mit einer Logik und einer Schnitt-

stelle, von der Instanzen erzeugt werden können (vergleichbar mit einer OOP-Klasse). Der

IEC 61499 FB entspricht dem IEC 61131 FB mit einer zusätzlichen Ereignisschnittstelle.

Die Schnittstelle besteht also aus Ereignis Ein- und Ausgängen und Daten Ein- und Ausgän-

gen. Einem Ereignis Ein- bzw. Ausgang können ein oder mehrere Daten Ein- oder Ausgänge

zugewiesen werden. Ein Ein- bzw. Ausgang besteht aus einem Namen und einem Daten-

bzw. Event-Typ [22].

INIT_EVENT

TIMEREAL

BOOL

INIT_EVENTEVENTEVENT

TIMEREALREAL

EI1EIn

IN1IN2INn

OUT1OUT2OUTn

EO2EO1

FB Typ

Abbildung 8: IEC 61499 FB Schnittstelle, nach [22]

Das Ausführungsmodell eines Basis FB ist in Abbildung 9 dargestellt. Zum Zeitpunkt t1

werden die für das Ereignis notwendigen Daten angelegt und zum Zeitpunkt t2 das Ereignis

selbst. Zum Zeitpunkt t3 informiert die Ausführungssteuerung die Ausführungsplanfunktion,

dass ein Algorithmus zur Ausführung bereitsteht. Die Ausführung des Algorithmus beginnt

zum Zeitpunkt t4. Zum Zeitpunkt t5 stehen die Ausgabedaten zur Verfügung und zum


Algorithmus

Ausführungs-steuerung

t1

t2

Ausführungsplanfunktion

t3 t4 t6 t7

t5

t8

Abbildung 9: IEC 61499 FB-Ausführungsmodell, nach [22]

Zeitpunkt t6 informiert der Algorithmus die Ausführungsplanfunktion über das Ende der

Ausführung. Zum Zeitpunkt t7 wird die Ausführungssteuerung ausgeführt und das Aus-

gangsereignis wird zum Zeitpunkt t8 ausgeführt [22].

Die IEC 61499 definiert fünf verschiedene FB-Basistypen [22]:

Basis FB (Basic Function Block)

Zusammengesetzter FB (Composite Function Block)

Dienstschnittstellen FB (Service Interface Function Block)

Adapterschnittstellen (Adapter Interfaces)

Unteranwendungen (Subapplications)

Basis FB:

Das Grundelement eines Basis FBs ist die Ausführungssteuerung (Execution Control Chart

– ECC). Diese basiert auf der AS der IEC 61131-3 und definiert den auszuführenden Algo-

rithmus bei einem auftretenden Ereignis. Die Ablaufsteuerung besteht aus Zuständen mit

zugehörigen Aktionen und Zustandsübergängen [22].

In Abbildung 10 ist die Ausführungssteuerung des Random-FBs dargestellt. Ausgehend vom

Ausgangszustand „START“ sind die Zustandsübergänge für die Eingangs-Ereignisse

„INIT“ und „REQ“ verknüpft. Tritt das Ereignis „INIT“ auf, wird in den Zustand „State“

gewechselt, der Algorithmus „INIT“ ausgeführt, das Ausgangs-Ereignis „INITO“ ausgelöst


Abbildung 10: Ausführungssteuerung des Random-FBs aus 4DIAC

und wieder auf den Ausgangszustand „START“ gewechselt. Analog dazu ist der Ablauf

beim Auftreten des „REQ“ Ereignisses.

Der Algorithmus kann in einer beliebigen IEC 61131-3 Programmiersprache implementiert

werden, der Zugriff ist aber auf die Daten Ein- und Ausgänge und auf die internen Variablen

beschränkt. Im Gegensatz zur IEC 61131 gibt es bei der IEC 61499 keine globalen Variablen

[22].

Zusammengesetzter FB:

Ein zusammengesetzter FB ist ein Container für FBe (FBN). Die Ein- und Ausgänge des

FBs sind mit den Ein- und Ausgängen des internen FBN verbunden [22].

Dienstschnittstellen FB:

Der Dienstschnittstellen FB wird für Funktionen verwendet, die über den Rahmen der IEC

61499 hinausgehen. Typische Anwendungen sind Hardware-Zugriffe, wie z.B. Ein- und

Ausgänge oder die Kommunikationsschnittstelle, oder Zugriffe auf Betriebssystem-Funkti-

onen, wie z.B. einem Zeitgeber [22].

Der Standard unterscheidet zwischen zwei Grundtypen des Dienstschnittstellen FBs: Dem

Requester- und dem Responder-FB. Der Requester-FB wird von der Applikation getriggert

und führt den zugehörigen Dienst aus. Der Responder-FB wird vom zugehörigen Dienst,

z.B. durch einen Hardware-Interrupt oder durch das Betriebssystem, getriggert. Für Spezi-

alfälle sind auch Mischformen der beiden Grundtypen möglich [22].

Die Anwendung sendet z.B. dem Requester-FB ein Ereignis, dass Daten über das Netzwerk

übertragen werden sollen. Die Daten werden vom Requester-FB versendet und von der Ziel-

hardware empfangen. Diese aktiviert den Responder-FB durch einen Interrupt und dieser

sendet ein Ereignis aus, dass Daten zum Abholen bereitstehen.


Adapterschnittstellen:

Adapterschnittstellen werden verwendet, um Daten- und Ereignisverbindungen zu bündeln.

Dabei wird ein Satz von Daten- und Ereignisverbindungen als eine einzige Adapterverbin-

dung dargestellt.

Abbildung 11 zeigt eine schematische Adapterverbindung. Beim Provider-FB werden die

Daten- und Ereignisverbindungen durch den Plug-Adapter gebündelt und beim Acceptor-

FB durch den Socket-Adapter wieder in Daten- und Ereignisverbindungen aufgeteilt [22].

Provider Acceptor

Adapter FB Adapter FB

Plug Socket

Abbildung 11: IEC 61499 Adapter FB, nach [22]

Unteranwendungen:

Eine Unteranwendung unterscheidet sich zu einem zusammengesetzten FB kaum. Eine Un-

teranwendung ist kein atomarer FB, daher kann diese auf verschiedenen Ressourcen verteilt

werden. Jedoch wird eine Unteranwendung in der Regel nur auf der Anwendungsebene de-

finiert und ist daher in anderen Anwendungen nicht wiederverwendbar [22].


Der IEC 61499 Standard sollte der Nachfolger des vor über 20 Jahren erschienenen IEC

61131 Standards werden und diesen um die neuen Anforderungen komplexer Anlagen, wie

z.B. Portabilität, Interoperabilität, Wiederverwendbarkeit und Verteilung, erweitern. Der

Standard konnte sich in der Industrie, bis auf ein paar Ausnahmen, bis heute nicht durchset-

zen. Angewendet wird die IEC 61499 hauptsächlich in Forschungseinrichtungen und an

Hochschulen. Verantwortlich für die mangelnde Akzeptanz der neuen Norm ist die Umset-


zung der am Anfang des Abschnitts genannten neuen Anforderungen. Diese werden im Stan-

dard teilweise unvollständig definiert oder lassen einen großen Interpretationsspielraum of-

fen. In [31] wird die Umsetzung der neuen Anforderungen detailliert analysiert. Der Bericht

kommt zum Schluss, dass die neuen Anforderungen größtenteils auch mit der neuesten Aus-

gabe der etablierten IEC 61131-3 (mit Objektorientierung) umgesetzt werden können und

wegen der ungenauen Definitionen mehr neue Probleme geschaffen, als bestehende gelöst

werden. Eine weitere große Hürde für den Anwender ist der Umstieg von der prozeduralen,

gerätezentrierten Entwicklung, zur verteilten, objektorientierten, applikationszentrierten

Entwicklung und der damit verbundene Schulungsaufwand. In [32] wird bemängelt, dass im

neuen Standard die Themen Anforderungsanalyse und Architekturentwurf nicht enthalten

sind [27], [30], [33].

Ein weiteres Problem ist die Verfügbarkeit von Entwicklungs- und Laufzeitumgebungen. Es

stehen derzeit zwei kommerzielle Tools (ISaGRAF und NxtStudio) und zwei Open Source

Projekte (4DIAC und FBDK) zur Verfügung, siehe auch Abschnitt 8.2. Die Gründe dafür

sind einerseits, dass nur geringer Bedarf von Seiten der Industrie besteht und andererseits

der Standard einige Punkte offen lässt, z.B. die Ausführung des FBN, oder zu ungenau de-

finiert. Diese Punkte sind auch eine der Hauptursachen, wieso die derzeit verfügbaren Tools

größtenteils zueinander inkompatibel sind [30], [31], [33], [34].

Zusammenfassend kann gesagt werden, dass Anwender am Anfang eines Projekts vor der

Entscheidung stehen, die bereits etablierte IEC 61131 oder die neue IEC 61499 zu verwen-

den. Bei der IEC 61131 besteht der Nachteil, dass die neuen Anforderungen kompliziert

umzusetzen sind, dafür ist die Norm weit verbreitet und es ist kein Umdenken in der Ent-

wicklung notwendig. Die IEC 61499 bringt den Vorteil, dass diese speziell auf die neuen

Anforderungen eingeht. Jedoch stehen dafür derzeit nur wenige ausgereifte Entwicklungs-

tools zur Verfügung und es ist ein Umdenken im Entwicklungsprozess und ein damit ver-

bundener Lernaufwand notwendig [30], [32], [33].

In der Industrie sind nur wenige auf der IEC 61499 basierende Projekte vorhanden. Bei den

meisten Projekten handelt es sich um Demo-Anlagen oder Forschungsprojekte von Hoch-

schulen [32]. Zum Beispiel wird die IEC 61499 als Basis von Process Field Network Com-

ponent Based Automation (Profinet CBA) [35] verwendet und das Austrian Institute of

Technology (AIT) setzt IEC 61499 in Kombination mit Powerlink für das SmartEST Labor


[36] ein. Weitere Bespiele sind in der Gebäudeautomatisierung, Fertigungssteuerung, Le-

bensmittelverarbeitung, Montage und im Materialtransport zu finden [33].

Kommunikationsprotokolle 37

4 Kommunikationsprotokolle

Wie bereits im ersten Kapitel beschrieben, besteht ein Smart Home aus sehr heterogenen

Systemen. Um diese Komponenten miteinander zu verbinden werden häufig Web Services

als Service Oriented Architecture (SOA) oder als Resource Oriented Architecture (ROA)

verwendet. Die derzeit populärsten und verbreitetsten Webservices sind SOAP und REST.

Diese werden in den ersten zwei Abschnitten beschrieben. Im dritten Abschnitt wird die

noch relativ junge Technologie WebSocket vorgestellt. Als letzte Technologie folgt in Ab-

schnitt 4 das Messaging-Protokoll XMPP. Dieses gewann in letzter Zeit vor allem für Web

Services immer mehr an Bedeutung [37].

In Abschnitt 6.2 werden die Kommunikationsprotokolle hinsichtlich der in Abschnitt 2.2.2

definierten Anforderungen bewertet und das geeignetste Protokoll für die Kommunikation

von Smart Home Komponenten ausgewählt.

4.1 SOAP

Die erste Version der SOAP (ursprünglich: Simple Object Access Protocol) Spezifikation

wurde im Jahr 2003 vom World Wide Web Consortium (W3C) veröffentlicht. Seit Version

1.2 wird die Abkürzung SOAP nicht mehr als Akronym verwendet, da die Bezeichnung

nicht treffend war [38].

SOAP ist ein Kommunikationsprotokoll zum Austausch von Nachrichten über ein Netzwerk

oder zum Aufruf entfernter Methoden (Remote Procedure Call - RPC). Eine SOAP-Nach-

richt besteht aus einem gewöhnlichen Extensible Markup Language (XML)-Dokument. Da

die Spezifikation keine Vorschriften für das darunterliegende Transportprotokoll (z.B. Hy-

pertext Transfer Protocol - HTTP, File Transfer Protocol - FTP, Simple Network Manage-

ment Protocol - SNMP) und das Format der Nutzdaten macht kann das Protokoll sehr flexi-

bel eingesetzt werden [38].

Die Spezifikation besteht aktuell aus vier Teilen [38].

SOAP Version 1.2 Part0: Primer (2007-04-27)

Dieser Teil beschreibt die Grundlagen, die Nachrichtenstruktur und die Formen des

Nachrichtenaustauschs.

SOAP Version 1.2 Part1: Messaging Framework (2007-04-27)

Der zweite Teil beschreibt den Aufbau einer Nachricht und die Protokoll-Bindung.


SOAP Version 1.2 Part2: Adjuncts (2007-04-27)

In diesem Teil werden ein Datenmodell, ein Kodierungsschema für Datentypen und

eine praktische Realisierung der Protokoll-Bindung über HTTP definiert.

SOAP Version 1.2 Specification Assertions and Test Collection (2007-04-27)

Im letzten Teil werden die wichtigsten Aspekte der Norm zusammengefasst und

Testszenarien definiert, um eine konkrete SOAP-Implementierung hinsichtlich der

Erfüllung der Norm zu testen.

In den nächsten Abschnitten erfolgt eine Beschreibung der wichtigsten Punkte von SOAP.

4.1.1 Nachrichtenformat

Ein Beispiel einer SOAP-Nachricht ist in Listing 3 dargestellt. Eine SOAP-Nachricht besteht

aus folgenden vier XML-Elementen, wovon zwei optional sind [38], [39].

Envelope-Element:

Das Envelope-Element bildet das Root-Element einer SOAP-Nachricht. Es muss den XML-

Namensraum http://www.w3.org/2001/12/soap-envelope enthalten. Ein XML-Namensraum

definiert eindeutige Element- und Attributnamen für ein XML-Dokument [40]. Der Soap-

Envelope Namensraum definiert, dass es sich um ein SOAP-Envelope-Element handelt. Op-

tional kann ein EncodingStyle angegeben werden. Dieser definiert wie das Envelope-

Element und alle Unterelemente zu interpretieren sind [38], [39].

Header-Element:

Das optionale Header-Element enthält anwendungsspezifische Informationen der SOAP-

Nachricht, wie z.B. Authentifizierung oder Verschlüsselung. Alle enthaltenen Unterele-

mente, die sogenannten Header-Blöcke, müssen durch einen Namensraum definiert werden.

Die Header-Blöcke können die SOAP-spezifischen Attribute encodingStyle,

mustUnderstand, role und relay enthalten. Detaillierte Informationen zu den Attri-

buten sind in [39] zu finden [38].

Body-Element:

Das Body-Element enthält Informationen, z.B. Daten oder Anweisungen, für den Empfänger

der SOAP-Nachricht. Alle enthaltenen Unterelemente müssen durch einen Namensraum de-

finiert sein [38], [39].


<?xml version="1.0"?>

<soap:Envelope

xmlns:soap="http://www.w3.org/2003/05/soap-envelope"

soap:encodingStyle="http://www.w3.org/2003/05/soap-encoding">

<soap:Header>

<t:Trans xmlns:t=http://www.example.com/transaction/

soap:mustUnderstand="true">123</t:Trans>

</soap:Header>

<soap:Body>

<m:GetValue xmlns:m="http://www.example.com/values">

<m:Item>Value3</m:Item>

</m:GetValue>

<soap:Fault>

<soap:Code>

<soap:Value>soap:MustUnderstand</soap:Value>

</soap:Code>

<soap:Reason>

<soap:Text xml:lang="en-US">

Header not understood

</soap:Text>

</soap:Reason>

</soap:Fault>

</soap:Body>

</soap:Envelope>

Listing 3: Beispiel einer SOAP-Nachricht

Fault-Element:

Das optionale Fault-Element enthält Fehler- und Status-Informationen und ist ein Unterele-

ment des Body-Elements. Das Fault-Element muss die Unterelemente Code und Reason

enthalten und kann optional die Unterelemente Node, Role und Detail enthalten. De-

taillierte Informationen zu den Unterelementen sind in [39] zu finden [38].

4.1.2 Nachrichtenübertragung

Die SOAP-Spezifikation beinhaltet in [39] formale Regeln für die Übertragung von SOAP-

Nachrichten, der sogenannten SOAP-Bindung. Das Übertragungsprotokoll kann, sofern es

diesen Regeln entspricht, frei gewählt werden. In [41] sind mehrere Muster zur Nachrich-

tenübertragung und eine Bindung an das HTTP-Protokoll spezifiziert. Zusätzlich gibt es in

[42] eine Notiz zur Protokollbindung an eine E-Mail [38].


SOAP-Nachrichten können entweder direkt vom Sender- zum Empfänger-Knoten oder über

Zwischenstationen übertragen werden. Zwischenstationen können z.B. Nachrichten ver-

schlüsseln oder zusätzliche Informationen einfügen oder entfernen. Geregelt wird diese

Übertragungsart über die Header-Block-Attribute role, mustUnderstand und relay.

Details zu den Übertragungsarten und Attributen sind in [39] zu finden [38].


In den letzten Jahren haben Web Services immer mehr an Bedeutung gewonnen. Cloud-

Anwendungen, Smartphones und Tablets treiben die Entwicklung voran. Mit Web Services

wird die Kommunikation zwischen heterogenen Systemen (Betriebssystem, Hardware, Ent-

wicklungsplattform) ermöglicht. SOAP entwickelte sich, mit der Ausnahme von mobilen

Plattformen, zum derzeit dominierenden Protokoll für Web Services. Durch den vermehrten

Einsatz von mobilen Geräten geht der Trend derzeit eher zu RESTful Web Services, da diese

einen geringeren Overhead haben [43], [44].

Am häufigsten wird HTTP als Transportprotokoll für SOAP verwendet. Es werden aber auch

andere Protokolle wie z.B. das Simple Mail Transfer Protocol (SMTP) eingesetzt. SOAP

wird hauptsächlich für „Desktop-Anwendungen“ verwendet, bei denen Sicherheit im Vor-

dergrund steht, Nachrichten über Zwischenstationen versendet werden und die Kapazität der

Netzwerkverbindung ausreichend groß ist. Verglichen mit REST über HTTP hat SOAP im

schlechtesten Fall eine bis zu zehnmal höhere Netzwerk-Payload. Mit SOAP Version 1.2

nähert sich SOAP ein wenig an REST an, indem über HTTP-GET eine direkte Adressierung

der Ressource über den HTTP-Header ermöglicht wird. Mit den vorherigen Versionen war

nur eine indirekte Adressierung über das Body-Element der SOAP-Nachricht via HTTP-

Post möglich. Für die gängigsten Programmiersprachen, wie z.B. Java oder C#, stehen

SOAP-Frameworks zur Anwendungsentwicklung zur Verfügung [37], [38], [44].

Das „Devices Profile for Web Services“ (DPWS) verwendet SOAP als Nachrichtenproto-

koll. DPWS ist eine SOA basierend auf Web Services. Diese unterstützt das Suchen von

Services, eventbasierten Nachrichtenaustausch (Publish-Subscribe) und Austausch der Ser-

vice-Metadaten [45]. In [19] wird eine Smart Home Architektur basierend auf DPWS ent-

wickelt. Der Report [46] befasst sich mit der Reduzierung der DPWS-Nachrichtenlänge

durch Komprimierung der SOAP-Nachrichten.


4.2 REST

Bei REST handelt es sich nicht um ein Protokoll oder eine Methodik, sondern um einen

Architektur-Stil. REST wurde im Jahr 2000 von Roy Thomas Fielding in seiner Dissertation

„Architectural Styles and the Design of Network-based Software Architectures“ entworfen.

REST orientiert sich an der Struktur und dem Verhalten des Internets [47].

4.2.1 Architektur

Damit eine REST-Architektur als „RESTful“ bezeichnet werden darf, muss sie die folgen-

den sechs Design-Regeln erfüllen [47].

Client-Server:

Bei REST handelt es sich um eine Client-Server Architektur. Durch die Trennung von Client

und Server, kann die Client- und die Server-Applikation unabhängig voneinander entwickelt

werden. Der Server bietet eine oder mehrere Schnittstellen an und empfängt bzw. beantwor-

tet über diese Client-Anfragen [47].

Stateless:

Die Kommunikation zwischen Client und Server muss zustandslos erfolgen. Sitzungsinfor-

mationen müssen am Client gespeichert und bei jeder Anfrage an den Server mitgeschickt

werden bzw. bei jeder Server-Antwort enthalten sein. Somit enthält jede Anfrage alle Infor-

mationen, die für die Bearbeitung notwendig sind und jede Anfrage ist in sich geschlossen

[47].

Cache:

Um die Latenzzeit und das aufkommende Datenvolumen zu senken und gleichzeitig die Sta-

bilität zu erhöhen, wird Caching verwendet. Dazu ist es notwendig, dass die Server-Antwor-

ten als cachebar oder nicht cachebar markiert sind. Eine cachebare Server-Antwort wird zu-

sätzlich im Client-Cache gespeichert und zukünftige, äquivalente Anfragen werden nicht

mehr an den Server, sondern an den Client-Cache gesendet [47].

Uniform Interface:

Einer der zentralen Punkte der REST-Architektur ist eine einheitliche Schnittstelle (Uniform

Interface) zwischen Client und Server. Die Schnittstelle soll schlank und unabhängig von


der Business-Logik sein. Dieses Design-Prinzip vermindert das Risiko, dass eine Schnitt-

stelle im Nachhinein angepasst werden muss und fördert die Wiederverwendbarkeit [47].

Layered System:

In einer REST-Architektur ist es möglich, ein System in mehrere Schichten aufzuteilen. Als

Beispiel kann ein Server aus Performance- oder Architekturgründen in mehrere Komponen-

ten aufgeteilt werden. Diese Aufteilung ist von außen nicht sichtbar. Ein Client kommuni-

ziert weiterhin mit einem Server und dieser leitet die Anfragen an die entsprechende Schicht

weiter. So können Schichten jederzeit und ohne Auswirkungen auf das Gesamtsystem hin-

zugefügt, entfernt, geändert oder anders angeordnet werden [47].

Code-On-Demand:

Bei Code-On-Demand handelt es sich um eine optionale Regel. Diese Regel besagt, dass

Server-Code (z.B. Applets, Skripts) auch auf Clients ausgeführt werden kann. Als Beispiel

kann JavaScript genannt werden, wobei JavaScript-Code vom Server heruntergeladen und

im Browser des Clients ausgeführt wird [47].

4.2.2 REST über URI und HTTP

Die REST-Architektur kann grundsätzlich auf jedes Protokoll angewendet werden. Im Pra-

xisteil von [47] wird beschrieben, wie REST mit den Webtechnologien Uniform Resource

Identifiers (URI) und HTTP verwendet werden kann [47].

Eine zentrale Forderung von REST ist „Hypermedia as the Engine of Application State“

(HATEOAS). Diese Navigationsart ähnelt der Navigation auf einer Internetseite. Der Server

soll nur einige wenige Eintrittspunkte zur Verfügung stellen. Bei den Eintrittspunkten han-

delt es sich um Ressourcen, die mit einer URI adressiert werden können. Der Client sendet

an einen dieser Eintrittspunkte eine Anfrage und erhält eine Antwort. Diese besteht aus der

eigentlichen Nachricht und einem oder mehreren dynamischen und selbsterklärenden Links

(URIs) zu weiteren Funktionen. Der Client soll ohne Vorkenntnisse und ausschließlich mit

Hilfe der Links durch die Programmfunktionen navigieren können [43], [47].

Eine weitere zentrale Forderung an eine REST-Architektur ist eine einfache und universelle

Schnittstelle. Bei der Verwendung des HTTP-Protokolls besteht die Schnittstelle aus den

vier HTTP-Methoden GET, POST, PUT und DELETE. Mit GET können Repräsentationen


abgerufen, mit POST neue Ressourcen erstellt, mit PUT geändert und mit DELETE gelöscht

werden [43], [47].

Im Anhang in Listing 13 ist ein einfaches Onlineshop-Beispiel für REST über URI und

HTTP dargestellt. Im ersten Schritt wird mittels HTTP-POST ein Warenkorb angelegt. In

der Antwort sind ein Status-Code und Links zu Artikeln sowie zum Warenkorb enthalten.

Anhand des Status-Codes (201 – Created) kann erkannt werden, ob die Operation erfolgreich

war. Mit den zwei darauffolgenden HTTP-GET-Anfragen wird durch die Artikel navigiert

und mit der dritten HTTP-GET-Anfrage wird ein Artikel ausgewählt. Diese Art der Naviga-

tion entspricht dem HATEOAS-Prinzip. Anschließend werden mit HTTP-PUT zwei Artikel

in den Warenkorb gelegt und zum Schluss wird mit HTTP-DELETE der zweite Artikel wie-

der aus dem Warenkorb gelöscht [43].


REST kommt vorwiegend bei mobilen Anwendungen zum Einsatz, da diese Technologie

verglichen mit SOAP weniger Bandbreite benötigt. Dies liegt vorwiegend am geringeren

Protokoll-Payload und der Caching Funktion. Referenzwerte sind in [44] zu finden. Als

Kommunikationsprotokoll wird auch hier größtenteils HTTP mit den Methoden GET,

POST, PUT und DELETE verwendet. Bei der Implementierung der Anwendung muss da-

rauf geachtet werden, dass REST zustandslos ist, der Server also keine Client-Informationen

speichert, nur Punkt-zu-Punkt Verbindungen, also ohne Zwischenstationen, möglich sind

und REST nur auf die Verschlüsselung des Protokolls, z.B. Hypertext Transfer Protocol

Secure (HTTPS), zurückgreifen kann. Da REST der ROA zuzuordnen ist kann die Funktio-

nalität des Servers jederzeit erweitert werden ohne, dass die Schnittstelle erweitert oder der

Client angepasst werden muss. Die Auswahl an Frameworks für die Anwendungsentwick-

lung ist im Vergleich zu SOAP begrenzt. Ein Framework ist aber aufgrund der Einfachheit

der Schnittstelle nicht unbedingt notwendig bzw. oftmals gar nicht erwünscht. Des Weiteren

ist zu beachten, dass viele Web Services als RESTful bezeichnet werden, aber oft einige

wesentliche Eigenschaften verletzt werden [37], [43], [44].

In [20] wird eine Smart Home Implementierung als RESTful Web Service beschrieben. Da-

bei wird auch auf die bei REST problematische ereignisbasierte Benachrichtigung eingegan-

gen. Diese wird über Web Hooks gelöst. Der Subscriber sendet einen Request an den Publi-

sher, in dem eine Callback URI enthalten ist. Beim Auftreten eines Ereignisses sendet der

Publisher an die Callback URI des Subscribers einen HTTP-Request. Die Nachteile von Web


Hooks sind, dass diese noch nicht standardisiert sind und eingehende Verbindungen oft

durch eine Firewall blockiert sind. Im Report sind auch Performancemessungen der RESTful

Architektur enthalten, die als „für ein Smart Home ausreichend“ bewertet werden [48].

In Report [49] werden die Dienste im Internet of Things (IoT) in fünf Klassen eingeteilt und

auch die Problematik von ereignisgesteuerten Diensten und Diensten mit langer Antwortzeit

beschrieben. Als Lösungsansätze werden Web Hooks und eine Verarbeitung durch Tasks

diskutiert. Ein Task wird mit einem HTTP-POST am Server angelegt, der Status bzw. das

Ergebnis kann von einer für den Task erzeugten Ressource über HTTP-GET abgerufen wer-

den.

RESTful Web Services werden von allen größeren Internet-Dienstleistern, wie z.B. Amazon,

Doodle, Dropbox, Flickr, Google und Yahoo, angeboten. Eine Liste von RESTful Web Ser-

vices ist auf der Internetseite von ProgrammableWeb1 zu finden.

4.3 WebSocket

Die erste Version des WebSocket-Protokolls wurde im Dezember 2001 von der Internet En-

gineering Task Force (IETF) als Request for Comments (RFC) 6455 veröffentlicht. Das Pro-

tokoll ermöglicht eine bidirektionale TCP-Verbindung zwischen einem Client und einem

Server [50].

Im RFC 6455 und in den nächsten Abschnitten wird eine WebSocket Nachricht als Frame

bezeichnet. Ein Frame entspricht dabei nicht einer Nachricht der Open Systems Interconnec-

tion (OSI)-Schicht 2, sondern einer WebSocket Nachricht der OSI-Schicht 7.

4.3.1 Verbindungsaufbau und –abbau

Der WebSocket-Server wird über eines der in Listing 4 dargestellten URI-Schemas adres-

siert. Das ws-URI-Schema verwendet zum Verbindungsaufbau das HTTP-Protokoll, das

wss-URI-Schema das HTTPS-Protokoll.

ws-URI = "ws:" "//" host [ ":" port ] path [ "?" query ]

wss-URI = "wss:" "//" host [ ":" port ] path [ "?" query ]

Listing 4: WebSocket URI-Schema [50]

1 http://www.programmableweb.com/category/all/apis?data_format=21190

http://www.programmableweb.com/category/all/apis?data_format=21190


Der Verbindungsaufbau wird mit einem Opening-Handshake zwischen Client und Server

durchgeführt. Dazu wird vom Client ein HTTP-GET-Request, siehe Listing 5, versendet.

1 GET /chat HTTP/1.1

2 Host: server.example.com

3 Upgrade: websocket

4 Connection: Upgrade

5 Sec-WebSocket-Key: dGhlIHNhbXBsZSBub25jZQ==

6 Origin: http://example.com

7 Sec-WebSocket-Protocol: chat, superchat

8 Sec-WebSocket-Version: 13

Listing 5: Websocket Verbindungsaufbau - Request Header [50]

In Zeile 1 und 2 wird die Ressource „/char“ auf dem Host „server.example.com“ adressiert.

Mit Zeile 3 und 4 wird der Host aufgefordert, vom HTTP- auf das WebSocket-Protokoll zu

wechseln. In Zeile 5 wird eine base64-kodierte Zufallszahl mit einer Länge von 16 Byte

mitgeschickt. Das Origin-Feld in Zeile 6 wird vom Browser generiert und zum Schutz vor

Cross-Domain Anfragen verwendet. In Zeile 7 werden vom Client unterstützte WebSocket

Unterprotokolle angegeben. Eine Liste der derzeit verfügbaren Unterprotokolle ist bei der

Internet Assigned Numbers Authority (IANA)2 abrufbar. Mit Hilfe des Unterprotokolls kön-

nen z.B. SOAP, REST oder XMPP über WebSocket verwendet werden. XMPP über Web-

Socket wird z.B. dann verwendet, wenn eine Kommunikation über die XMPP Ports aufgrund

der Netzwerkinfrastruktur oder durch Einschränkungen des Browsers nicht möglich ist [51].

In der letzten Zeile wird die unterstützte WebSocket Version des Clients definiert [50].

Der Server beantwortet die Anfrage mit einem HTTP-Response, siehe Listing 6.

1 HTTP/1.1 101 Switching Protocols

2 Upgrade: websocket

3 Connection: Upgrade

4 Sec-WebSocket-Accept: s3pPLMBiTxaQ9kYGzzhZRbK+xOo=

5 Sec-WebSocket-Protocol: chat

Listing 6: Websocket Verbindungsaufbau - Response Header [50]

Mit dem Statuscode in Zeile 1 teilt der Server mit, dass er das WebSocket-Protokoll versteht.

Mit Zeile 2 und 3 bestätigt der Server das Upgrade auf das WebSocket-Protokoll. In Zeile 4

wird der Accept-Wert definiert. Generiert wird dieser, indem an den WebSocket-Key des

Requests der Globally Unique Identifier (GUID) „258EAFA5-E914-47DA-

2 http://www.iana.org/assignments/websocket/websocket.xhtml

http://www.iana.org/assignments/websocket/websocket.xhtml


95CAC5AB0DC85B11“ angehängt wird. Von diesem Wert wird der Secure Hash Algo-

rithm 1 (SHA1)-Hash berechnet und das Ergebnis base64-kodiert. Mit dem Accept-Wert

kann der Client sicherstellen, dass der Server die Anfrage gelesen und verstanden hat. Mit

der letzten Zeile wird dem Client mitgeteilt welches der vorgeschlagenen Unterprotokolle

für die weitere Kommunikation verwendet wird [50].

Das Schließen der Verbindung wird durch einen Closing-Handshake durchgeführt. Dazu

wird von der Seite, die die Verbindung schließen möchte, ein Frame mit dem Code „0x8“

(Close-Frame) gesendet. Optional kann dieser Frame noch einen Statuscode und eine Nach-

richt mit dem Grund enthalten. Die andere Seite muss nach dem Empfang des Frames eben-

falls einen Close-Frame senden. Nachdem eine Seite einen Close-Frame sowohl gesendet

als auch empfangen hat, schließt diese die TCP-Verbindung [50].


Nach einem erfolgreichen Opening-Handshake können Daten bidirektional ausgetauscht

werden. Eine Nachricht kann aus einem oder aus mehreren Frames bestehen. Zum Schutz

vor „Cache Poisoning“ müssen Nachrichten vom Client zum Server maskiert werden. Bei

„Cache Poisoning“ wird der Web- oder Proxycache für eine oder mehrere URLs durch einen

Angreifer manipuliert. Beim nächsten Aufruf einer dieser URLs wird den Anwendern nicht

der tatsächliche, sondern der manipulierte Inhalt aus dem Cache zurückgeliefert. Details zur

WebSocket-Maskierung sind in [50] zu finden.

Abbildung 12: Aufbau einer Web-Socket Nachricht [50]


Der Hauptvorteil beim WebSocket-Protokoll liegt am geringen Overhead. In Abbildung 12

ist der Aufbau des WebSocket-Frames dargestellt. Ein Frame startet mit einem „FIN“-Bit.

Dieses gibt an, ob es sich um den letzten Frame der Nachricht handelt. Die nächsten 3 Bits

sind für zukünftige Funktionen reserviert. Danach folgen 4 Bits „Opcode“. Dieser gibt an,

um welchen Frame-Typ es sich handelt. Das neunte Bit gibt an, ob der Frame maskiert ist.

Danach folgen je nach Nachrichteninhalt 7, 23 oder 71 Bits für die Länge des Nachrichten-

inhaltes. Wenn die Nachricht maskiert ist, folgen als nächstes die 32 Bits des Maskierungs-

schlüssels. Die weiteren Bits werden für den Nachrichteninhalt verwendet. Der Overhead

beträgt also im besten Fall 2 und im schlechtesten Fall 14 Byte [50].

Folgende Frame-Typen werden derzeit unterstützt [50]:

Text (0x1): Nachricht mit UTF8-codiertem Text

Binary (0x2): Nachricht mit binären Daten

Close (0x8): Anfrage zum Schließen der Verbindung

Ping (0x9): Ping-Nachricht

Pong (0xA): Pong-Antwort auf eine Ping-Nachricht

Die bislang undefinierten Bereiche (0x3-0x7 und 0xB-0xF) sind für zukünftige Frame-Ty-

pen reserviert [50].


Das WebSocket-Protokoll wird für Anwendungen eingesetzt, bei denen eine Echtzeitüber-

tragung mit geringer Verzögerung und geringem Overhead notwendig ist. Beispiele sind

Visualisierung von Sensordaten, Übertragung von Multimedia (Streaming) oder Chats. Das

Protokoll wird ohne zusätzliche Plug-Ins von den gängigsten Browsern unterstützt. Mit

WebSocket ist eine Verbindung zwischen heterogenen Systemen, wie z.B. Wireless Sensor

Networks (WSN) mit ZigBee- und 6LoWPAN-Protokoll möglich. Da es sich bei WebSocket

um eine bidirektionale Verbindung handelt, ist auch eine eventbasierte Kommunikation

möglich [52], [53], [54].

In [52] werden HTTP-Polling, Socket in ActiveX, FlashSocket und WebSocket für die Re-

mote-Abfrage von Sensordaten eines Smart Homes verglichen. Das WebSocket-Protokoll

schneidet bei der Reaktionszeit und bei der CPU-Auslastung der Clients in fast allen Fällen

am besten ab. In [53] wird ebenfalls der Overhead und die Reaktionszeit bei der Übertragung


von 1 GB Multimedia-Daten bei Verwendung von WebSocket und HTTP-Polling vergli-

chen. Auch hier schneidet WebSocket wesentlich besser ab.

In [54] wird WebSocket für die Visualisierung von Messdaten auf Embedded Devices ver-

wendet. Dabei wird die Visualisierung bereits vom Server generiert und als JPEG-Bilddatei

zum Client übertragen.

In [55] wird die Sicherheit vom WebSocket-Protokoll analysiert. Der Report kommt zum

Schluss, dass das Protokoll nicht unsicherer als andere im Web verwendete Protokolle ist,

aber mit WebSocket nun ein weiteres Protokoll existiert, das gegen bestimmte Angriffe, wie

z.B. Denial of Service (DOS), Cross-Site Scripting (XSS) oder Port Scanning, anfällig ist.

Im Report werden außerdem Richtlinien, wie z.B. Transport Layer Security (TLS)-Ver-

schlüsselung, Authentifizierung oder Sitzungsverwaltung, für die Entwicklung von sicheren

WebSocket-Anwendungen genannt.

4.4 XMPP

XMPP wurde von der IETF erstmals im Oktober 2004 als RFC 3920 und RFC 3921 veröf-

fentlicht. Ursprünglich wurde das Protokoll im Jahr 1999 von Jeremie Miller als Kommuni-

kationsprotokoll für den Messenger Jabber unter dem Namen Instant Messaging and

Presence Protocol (IMPP) entwickelt [56], [57].

XMPP ist ein Protokoll für den Austausch von strukturierten Daten zwischen zwei oder

mehreren Clients. Dieser geschieht beinahe in Echtzeit und als Austauschformat wird XML

verwendet. Da XML beliebig erweiterbar ist, kann XMPP in zahlreichen Anwendungsdo-

mänen eingesetzt werden. Die Kommunikation erfolgt via TCP über Client-Server-Verbin-

dungen. In der Norm sind auch Verschlüsselungs- und Authentifizierungsfunktionen defi-

niert [57].

XMPP ist aktuell in sieben RFCs definiert [56]:

RFC 6120 – XMPP CORE (März 2011)

Definiert die XMPP-Grundfunktion wie z.B. XML-Streams, Simple Authentication

and Security Layer (SASL) und TLS. Ersetzt den RFC 3920.

RFC 6121 – XMPP IM (März 2011)

Erweitert die XMPP-Grundfunktionen um die Instant Messaging (IM) und Presence

Funktionalität. Ersetzt den RFC 3921.


RFC 6122 – XMPP ADDR (März 2011)

Definiert das XMPP-Adressformat.

RFC 3923 – XMPP E2E (Oktober 2004)

Definiert Methoden zur End-to-End-Signierung und Verschlüsselung.

RFC 4854 – XMPP URN (April 2007)

Definiert einen Uniform Resource Name (URN) Namensraum für XMPP-Erweite-

rungen.

RFC 4979 – XMPP ENUM (August 2007)

IANA Registrierung für den Enum-Service „XMPP“.

RFC 5122 – XMPP URI (Februar 2008)

Definiert die Verwendung von Internationalized Resource Identifiers (IRIs) und

URIs für XMPP-Entitäten.

Zusätzlich sind noch 357 Erweiterungen (Stand 28.Mai 2015) bei der XMPP Standards

Foundation (XSF)3 abrufbar [56].

In den nächsten Abschnitten erfolgt eine Beschreibung der wichtigsten Aspekte von XMPP.

4.4.1 Architektur

XMPP verwendet eine dezentralisierte Client-Server-Architektur, siehe Abbildung 13. Das

bedeutet, dass jeder XMPP-Client mit einem XMPP-Server verbunden ist. Beim Nachrich-

tenaustausch sendet der Client die Nachricht an seinen Server, dieser leitet die Nachricht an

den Server des Empfängers weiter und dieser wiederum an den Client. Sendet z.B. der Client

1 eine Nachricht an Client 3, so wird diese Nachricht vom Client 1 an Server 1, von Server

1 zu Server 2 und von Server 2 zu Client 3 weitergeleitet. Ein Nachrichtenaustausch zwi-

schen Servern ist ebenfalls möglich [57].

Die Adressierung von XMPP-Knoten erfolgt über das Domain Name System (DNS).

XMPP-Server werden mit einem Domainnamen, wie z.B. example.com, adressiert.

XMPP-Clients verwenden zur Adressierung eine so genannte JabberID (JID). Die JID ähnelt

einer E-Mail-Adresse, z.B. [email protected], kann aber nicht nur American

Standard Code for Information Interchange (ASCII)- sondern auch Unicode-Zeichen

3 http://xmpp.org/xmpp-protocols/xmpp-extensions/

http://xmpp.org/xmpp-protocols/xmpp-extensions/


Server 1example.com

Server 2example.net

Client [email protected]/pc

Client [email protected]/work

Client [email protected]/notebook

Client [email protected]/home

Abbildung 13: XMPP-Architektur und Adressformat

enthalten. Dieses Adressformat wird als „bare JID“ bezeichnet. Um XMPP-Clients, die die-

selbe JID verwenden, eindeutig adressieren zu können, wird der JID noch eine Ressource

angehängt, z.B. [email protected]/home. Dieses Adressformat wird als „full

JID“ bezeichnet. Somit ist es möglich, dass mehrere Clients, wie z.B. Notebook und PC, mit

derselben JID gleichzeitig online sind und die Nachrichten an den einzelnen Client adressiert

werden können, siehe z.B. „Client 3“ und „Client 4“ in Abbildung 13 [58].

4.4.2 Verbindungsaufbau

Eine XMPP-Verbindung basiert auf einer langlebigen TCP-Verbindung, über die ein XML-

Datenstrom (XML-Stream) übertragen wird. Eine XMPP-Sitzung (engl. XMPP-Session) be-

ginnt, wenn der XML-Datenstrom aufgebaut wurde und endet, wenn dieser (vom Server

oder Client) geschlossen wird [57].

Für den Auf- und Abbau einer XMPP-Verbindung sind folgende Schritte notwendig [57]:

Aufbau einer TCP-Verbindung zum XMPP-Server (Port 5222 für Client-Server-,

Port 5269 für Server-Server-Verbindung)

Öffnen eines XML-Datenstroms

Aushandeln verschiedener Funktionen (Stream-Features), wie z.B. Verschlüsselung

Authentifizierung beim Server

Definition der Ressource (entfällt bei einer Server-zu-Server-Verbindung)

Austausch von XML-Nachrichten, sogenannten XML-Stanzas

Schließen des XML-Datenstroms

Schließen der TCP-Verbindung


Bei der nachfolgenden Beschreibung des Verbindungsaufbaus wird von einer Client-Server

Verbindung ausgegangen. Eine Server-zu-Server Verbindung verhält sich identisch [57].

Nach dem Aufbau der TCP-Verbindung wird vom Client der XML-Datenstrom geöffnet.

Dies geschieht mit dem Senden des Stream-Headers, siehe Listing 7 [57].

<?xml version='1.0'?>

<stream:stream

from='[email protected]'

to='im.example.com'

version='1.0'

xml:lang='en'

xmlns='jabber:client'

xmlns:stream='http://etherx.jabber.org/streams'>

Listing 7: Client-Stream-Header, nach [57]

Der Server öffnet als Antwort einen eigenen XML-Datenstrom und sendet ebenfalls einen

Stream-Header, siehe Listing 8. Es existiert also für jede Richtung ein eigener XML-Daten-

strom. Der Server-Stream-Header enthält zusätzlich eine eindeutige Datenstrom-ID [57].

<?xml version='1.0'?>

<stream:stream

from='im.example.com'

id='++TR84Sm6A3hnt3Q065SnAbbk3Y='

to='[email protected]'

version='1.0'

xml:lang='en'

xmlns='jabber:client'

xmlns:stream='http://etherx.jabber.org/streams'>

Listing 8: Server-Stream-Header, nach [57]

Nach dem Aufbau der beiden Datenströme sendet der Server dem Client seine unterstützten

Stream-Features. Im Beispiel in Listing 9 bietet der Server Verschlüsselung über TLS (op-

tional) und Authentifizierung über SASL (verpflichtend) an. Der Client kann nun optional

eine TLS-Verschlüsselung aufbauen und sich via SASL authentifizieren [57].

Viele Stream-Features, z.B. SASL, erfordern nach einer erfolgreichen Verhandlung einen

Neuaufbau des XML-Datenstroms. Dazu sendet der Client einen neuen Stream-Header. Der

Server generiert eine neue Stream-ID und sendet ebenfalls einen Stream-Header und eine

neue Stream-Feature Liste. Diese enthält z.B. nach erfolgter SASL-Verhandlung kein


<stream:features>

<starttls xmlns="urn:ietf:params:xml:ns:xmpp-tls">

<optional/>

</starttls>

<mechanisms xmlns="urn:ietf:params:xml:ns:xmpp-sasl">

<mechanism>PLAIN</mechanism>

<mechanism>DIGEST-MD5</mechanism>

<required/>

</mechanisms>

</stream:features>

Listing 9: Stream-Features, nach [57]

SASL-Feature mehr, dafür z.B. das Binding-Feature um eine Ressource zu binden. Die Ver-

handlungen sind beendet, wenn die vom Server versendete Feature-Liste leer ist oder nur

noch optionale Features enthält. Ab diesem Zeitpunkt kann der Client XML-Nachrichten

versenden. Details zu den einzelnen Nachrichten-Typen sind im nächsten Abschnitt be-

schrieben. Eine Sitzung kann zu jedem Zeitpunkt vom Server oder Client mit einem Closing-

Tag </stream:stream> geschlossen werden. Die TCP-Verbindung wird erst beendet,

wenn die Gegenseite den zweiten XML-Datenstrom ebenfalls mit einem Closing-Tag ge-

schlossen hat [57].


XMPP-Nachrichten, sogenannte XML-Stanzas, werden über einen XML-Datenstrom über-

tragen. In Listing 10 ist ein einfacher XML-Datenstrom dargestellt, der ein XML-Stanza

vom Typ „message“ überträgt [57].

<stream:stream>

<message from="[email protected]/pc"

to="[email protected]"

type="chat">

<subject>Initial message</subject>

<body>Hello world</body>

</message>

</stream:stream>

Listing 10: Beispiel einer XML-Stanza


Die Norm definiert drei Typen von XML-Stanzas [57]:

Message

Dieser Typ entspricht dem „Push-Muster“. Damit können z.B. Informationen oder

Messwerte versendet werden. Der Empfänger muss auf eine „Message“ nicht ant-

worten.

Presence

Dieser Typ entspricht dem „Publish-Subscribe-Muster“. Damit kann den Subscri-

bern ein Status oder eine Wertänderung mitgeteilt werden. Auch „Presence“-Nach-

richten müssen nicht beantwortet werden.

Info/Query(IQ)

Dieser Typ entspricht dem „Request/Response-Muster“. Damit können z.B. Befehle

gesendet oder Daten abgerufen werden. Im Vergleich zum „Message“- und

„Presence“-Typ muss eine IQ-Nachricht vom Empfänger beantwortet werden.

Mit einem XML-Stanza können beliebige Kindelemente versendet werden. Diese müssen

lediglich mit einem Namensraum klassifiziert werden. Häufig verwendete Namensräume,

z.B. SOAP über XMPP, sind bei der XSF4 zu finden [57].

Die XMPP-Kommunikation erfolgt völlig asynchron. Dies bedeutet, dass ein Client mehrere

Anfragen gleichzeitig versenden kann, ohne die Antwort der vorherigen Anfrage abwarten

zu müssen. Die einzelnen Antworten können beim Empfang über die ID des XML-Stanzas

(XML-Attribut „id“) unterschieden werden [57].


Das XMPP-Protokoll wurde ursprünglich für Messaging-Dienste entwickelt. Auf Grund der

unterstützten Features, wie z.B. Verschlüsselung, Authentifizierung, synchrone und asyn-

chrone Nachrichten, erweiterbares Nachrichtenformat, gewinnt es für Anwendungen im IoT

und in Smart Homes immer mehr an Bedeutung. Protokoll-Stacks stehen für alle gängigen

Programmiersprachen und Plattformen zur Verfügung. Für embedded Plattformen wurden

ressourcenschonende Stacks, wie z.B. uXMPP und mbed XMPP Client, entwickelt [59],

[60], [61].

4 http://xmpp.org/xmpp-protocols/protocol-namespaces/

http://xmpp.org/xmpp-protocols/protocol-namespaces/


In [59] wird die Verzögerungszeit anhand eines E-Mobility-Szenarios mit einem Erzeuger

und 20 Konsumenten getestet. Als Übertragungsart kommt Publish-Subscribe zum Einsatz.

Die einzelnen XMPP-Komponenten sind über verschiedene Netzwerke, wie z.B. WLAN,

DSL und Ethernet, miteinander verbunden. Es ergibt sich eine durchschnittliche Verzöge-

rungszeit zwischen Datengenerierung und Datenempfang von 108 ms. Auch der Report [60]

befasst sich mit dem Thema XMPP für IoT. Hier wird eine Methode zur Reduktion des

Datentransfers von Presence-Stanzas erläutert und die Bootzeit und die Anzahl an TCP-Pa-

keten analysiert. In [62] wird XMPP über UDP für ein Funk-Sensornetz getestet. UDP wird

verwendet um die Ressourcen-Anforderungen für die Sensor-Clients so gering wie möglich

zu halten. In [63] wird ein Inventur-Management-System mittels Radio-frequency Identifi-

cation (RFID) über XMPP realisiert.

In [64] wird XMPP für Demand-Side-Management verwendet. Der Report beschäftigt sich

mit den verschiedenen Anwendungsfällen. Dabei wird analysiert, wie viele XMPP-Server

notwendig sind, wer für die Verwaltung der einzelnen Server zuständig ist und welcher Ser-

ver von welchem XMPP-Client genutzt wird. Auch die im April 2015 erschienene IEC

62476 [17] sieht XMPP als Übertragungsprotokoll zwischen Customer Energy Management

(CEM) System und Netzbetreiber vor.

In [65] wird ein Notrufsystem basierend auf XMPP spezifiziert. Der Report geht auf die

Interoperabilität mit dem bestehenden, auf Session Initiation Protocol (SIP) basierenden,

Notrufsystem ein und definiert die notwendigen Funktionen.

In [61] wird ein Cloud-Service-Host mit Standard XMPP-Funktionen implementiert. Im

Zuge der Evaluierung wurden auch die Reaktionszeiten gemessen und festgestellt, dass diese

annähernd so gut wie bei einer zentralen Lösung sind.

Es gibt noch zahlreiche weitere Beispiele, wie das XMPP-Protokoll eingesetzt werden kann.

Der Großteil der Anwendungen fällt in die Bereiche IoT, Energie-Management, Cloud-

Computing, Notruf- und Notfallsysteme und Informationssysteme.

In [66] wird analysiert, wie mit dem XMPP-Protokoll versteckte Daten übertragen werden

können. Dazu werden hauptsächlich Protokoll-Attribute, wie z.B. der Message-Type, die

Message-ID oder die Message-Sprache verwendet, die vom XMPP-Server nicht ausgewertet

werden.

Kodierungsverfahren 55

5 Kodierungsverfahren

In diesem Kapitel werden die Kodierungsstandards ASN.1 und Base64 erläutert. Der erste

Standard dient zur Übertragung von Datenstrukturen zwischen heterogenen Systemen und

der zweite zur Konvertierung zwischen Bitströmen und ASCII-Zeichen. Diese Standards

werden häufig für die Übertragung von Daten bei Verwendung von Web Services eingesetzt.

5.1 ASN.1

Die Abstract Syntax Notation One (ASN.1) wurde erstmals im Jahr 1984 von der CCITT

(International Telegraph and Telephone Consultative Committee, heute ITU-T – „Internati-

onal Telecommunication Union - Telecommunication Standardization Sector“) normiert.

Seit 1985 wird die Norm gemeinsam mit der International Organization for Standardization

(ISO) bzw. dem IEC publiziert [67].

ASN.1 ist eine Beschreibungssprache zur Definition von Datenstrukturen ohne Berücksich-

tigung der Rechner-Architektur (z.B. Little-Endian vs. Big-Endian) und der Programmier-

sprache (z.B. C/C++, Java). Zusätzlich enthält der Standard Kodierungsregeln, mit denen

die ASN.1-Datenwerte bei der Übertragung (z.B. über Ethernet) kodiert und beim Empfang

dekodiert werden. Zusammenfassend kann gesagt werden, dass mit Hilfe der ASN.1-Syntax

und den Kodierungsregeln ein Austausch von Daten zwischen heterogenen Systemen er-

möglicht wird [68].

Die ASN.1 besteht aktuell aus vier Teilen Syntax und sieben Teilen Kodierungsregeln

[68]:

ISO/IEC 8824-1:2008 | ITU-T X.680 (2008): Specification of basic notation

ISO/IEC 8824-2:2008 | ITU-T X.681 (2008): Information object specification

ISO/IEC 8824-3:2008 | ITU-T X.682 (2008): Constraint specification

ISO/IEC 8824-4:2008 | ITU-T X.683 (2008): Parameterization of ASN.1 specifica-

tions

ISO/IEC 8825-1:2008 | ITU-T X.690 (2008): Specification of Basic Encoding Rules

(BER), Canonical Encoding Rules (CER) and Distinguished Encoding Rules (DER)

ISO/IEC 8825-2:2008 | ITU-T X.691 (2008): Specification of Packed Encoding

Rules (PER)


ISO/IEC 8825-3:2008 | ITU-T X.692 (2008): ASN.1 encoding rules: Specification

of Encoding Control Notation (ECN)

ISO/IEC 8825-4:2008 | ITU-T X.693 (2008): ASN.1 encoding rules: XML Encoding

Rules (XER)

ISO/IEC 8825-5:2008 | ITU-T X.694 (2008): ASN.1 encoding rules: Mapping W3C

XML schema definitions into ASN.1

ISO/IEC 8825-6:2008 | ITU-T X.695 (2008): ASN.1 encoding rules: Registration

and application of PER encoding instructions

ISO/IEC 8825-7:2014 | ITU-T X.696 (2014): ASN.1 encoding rules: Specification

of Octet Encoding Rules (OER)

In den nächsten Abschnitten erfolgt eine Beschreibung der wichtigsten Punkte von ASN.1.

5.1.1 ASN.1-Syntax

Mit der ASN.1-Syntax lassen sich Datenstrukturen unabhängig von der Hardware-Plattform

und der Programmiersprache definieren. Datenstrukturen werden z.B. als SET oder SE-

QUENCE von elementaren Typen wie z.B. INTEGER, VisibleString oder BOOLEAN

definiert. Eine Übersicht der ASN.1 Variablen-Typen ist im Anhang in Tabelle 21 zu finden.

Die Notation schreibt vor, dass Variablen-Typen mit einem Großbuchstaben und Variablen

mit einem Kleinbuchstaben beginnen [68].

In Listing 11 ist ein einfaches Beispiel einer Personen-Struktur dargestellt. Diese beinhaltet

Name, Titel, Personalnummer, Einstelldatum, Name des Ehepartners und eine Liste der Kin-

der.

Die in der ASN.1-Syntax definierten Datenstrukturen werden mit einem ASN.1-Compiler

in die Zielprogrammiersprache, wie z.B. C, C++ oder Java, konvertiert. Als Ergebnis liefert

der Compiler die Datenstrukturen und Kodierungs- und Dekodierungsfunktionen. Mit die-

sen Funktionen können Datenstrukturen für die Übertragung kodiert oder empfangene Da-

tenstrukturen dekodiert werden. Details zu den verschiedenen Kodierungsarten folgen im

nächsten Abschnitt [68].


PersonnelRecord ::= SET

{ name Name,

title VisibleString,

number EmployeeNumber,

dateOfHire Date,

nameOfSpouse Name,

children SEQUENCE OF ChildInformation DEFAULT {}

}

ChildInformation ::= SET

{ name Name,

dateOfBirth Date

}

Name ::= SEQUENCE

{ givenName VisibleString,

initial VisibleString,

familyName VisibleString

}

EmployeeNumber ::= INTEGER

Date ::= VisibleString -- YYYY MMDD

Listing 11: Beispiel ASN.1-Syntax, nach [68]

5.1.2 Kodierungsarten

Der ASN.1 Standard enthält verschiedene Kodierungsarten, mit denen ASN.1-Datenwerte

für die Übertragung zwischen heterogenen Systemen kodiert bzw. dekodiert werden können

[67], [68]. Die ECN erlaubt die Definition von eigenen bzw. eine Abänderung der bestehen-

den Kodierungsverfahren [69]. Im Anschluss werden die in der Norm definierten Kodie-

rungsverfahren kurz beschrieben.

Basic Encoding Rules:

Ein BER-Datenpaket besteht aus mindestens drei Byte-Blöcken (Octets). Diese setzen sich

aus folgenden vier Komponenten zusammen [70]:

Kennung (Identifier)

Gibt den ASN.1-Datentyp der Daten-Komponente an.

Länge (Length)

Die Länge der Daten-Komponente kann definiert oder undefiniert angegeben wer-

den. Bei der definierten Form wird die Länge (z.B. 2 Byte) angegeben, bei der unde-


finierten Form wird die Daten-Komponente mit der Datenende-Komponente abge-

schlossen. Die zweite Form wird bei langen Datenstrukturen, die paketweise über-

tragen werden, verwendet.

Daten (Contents)

Besteht aus den kodierten Datenwerten.

Datenende (End-Of-Contents)

Die Datenende-Komponente wird nur bei der undefinierten Form mitgeschickt, bei

der definierten Form entfällt diese.

In Abbildung 14 ist als Beispiel die Daten-Komponente des Datentyps BOOLEAN mit dem

Wert TRUE dargestellt.

0x01 0x01 0xFFKennung Länge Daten

Abbildung 14: ASN.1 BER-Kodierung (BOOLEAN Datentyp mit dem Wert TRUE)

Ein BER-Datenpaket ist auf Bit-Ebene nicht völlig eindeutig. Z.B. spezifiziert die Norm

einen BOOLEAN-Datentyp mit dem Wert TRUE als einen Wert ungleich Null, also 0x01 bis

0xFF.

Canonical Encoding Rules:

Die CER-Kodierung basiert auf der BER-Kodierung, ist aber auf Bit-Ebene völlig eindeutig,

z.B. ist ein BOOLEAN-Datentyp mit dem Wert TRUE als kodierter-Wert 0xFF definiert.

Diese Kodierung wird in Umgebungen verwendet, in denen eine Signierung des Datenpa-

ketes notwendig ist und die Übertragung über eine Zwischenstation erfolgt. Dabei wird vom

Sender der zu übertragende Wert CER-kodiert, vom kodierten Wert eine Signatur generiert

und der kodierte Wert gemeinsam mit der Signatur an die Zwischenstation gesendet. Diese

dekodiert den empfangenen Wert und führt erneut eine CER-Kodierung durch. Der kodierte

Wert wird mit der ursprünglichen Signatur an den Empfänger weitergeleitet. Dieser generiert

vom empfangenen Wert eine Signatur und vergleicht diese mit der empfangenen Signatur.

Wäre das CER-Kodierungsverfahren nicht völlig eindeutig würden die beiden Signaturen

nicht übereinstimmen [70].


Die CER-Kodierung verwendet für Datenblöcke mit einer Länge von über 1000 Bytes und

bei konstruierten Datentypen die undefinierte Form für die Länge-Komponente. Das Kodie-

rungsverfahren eignet sich für große Datenstrukturen oder bei Systemen, bei denen wenig

Speicher zur Verfügung steht [70].

Distinguished Encoding Rules:

Die DER-Kodierung ist zur CER-Kodierung fast identisch. Im Gegensatz dazu verwendet

diese für die Länge-Komponente ausschließlich die definierte Form. Die DER-Kodierung

eignet sich für kleine Datenstrukturen oder bei Systemen, bei denen ausreichend Speicher

zur Verfügung steht [70].

Packed Encoding Rules:

Der Nachteil der BER-Kodierung sowie der darauf basierenden Kodierungen ist der relativ

hohe Overhead durch die byteweise Verarbeitung. Die PER-Kodierung hat, durch eine bit-

weise Verarbeitung und dem Wegfall von unwesentlichen Informationen, einen deutlich ge-

ringeren Overhead. Es gibt eine BASIC-PER- und eine CANONICAL-PER-Variante die

entweder Aligned oder Unaligned sein kann. Der Vorteil der CANONICAL-PER-Variante

liegt an der Eindeutigkeit auf Bit-Ebene (vergleichbar mit BER und CER/DER). Bei der

Aligned Variante werden beim Datenpaket 0-Bits aufgefüllt, bis das Byte-Alignment erfüllt

ist. In [71] ist die Anwendung von optionalen Kodierungsanweisungen spezifiziert. Die

PER-Kodierung wird verwendet, wenn hohe Datenübertragungsraten erforderlich sind (z.B.

Videotelefonie) oder die Bandbreite begrenzt ist (z.B. Mobilfunk) [72].

Octet Encoding Rules:

Die OER-Kodierung vereint die Vorteile der BER- und PER-Kodierung. Die Verarbeitung

erfolgt wie bei der BER-Kodierung byteweise, es werden aber alle unwesentlichen Informa-

tionen weggelassen. Der Overhead liegt dadurch zwischen der BER- und der PER-Kodie-

rung. Der Vorteil gegenüber der PER-Kodierung liegt in der wesentlich geringeren Rechen-

zeit für die Dekodierung bzw. Kodierung. Im Wesentlichen werden nur die Variablenwerte

übertragen und Präfixes nur wenn notwendig (z.B. Länge bei variabler Länge, Presence-

Bitmap bei einer SEQUENCE mit optionalen Elementen oder Identifier bei einem

CHOICE). Auch bei dieser Kodierung gibt es wieder eine BASIC-OER- und eine CANO-

NICAL-OER-Variante [73].


XML Encoding Rules:

Die XER-Kodierung verwendet XML als Übertragungsformat. Die Norm definiert drei ver-

schiedene Varianten von XER-Kodierungen: BASIC-XER, CANONICAL-XER (CXER)

und EXTENDED-XER. Der Vorteil der CXER-Variante liegt an der Eindeutigkeit des er-

zeugten XML-Dokuments. Mit der EXTENDED-XER-Variante lässt sich die BASIC-XER-

Variante modifizieren und erweitern [74].

Zusätzlich existiert noch eine Norm, die die Konvertierung einer XML Schema Definition

(XSD) in ein ASN.1-Schema beschreibt [75].

Encoding Control Notation:

Die ECN definiert eine Syntax, mit der vorhandene Kodierungsverfahren modifiziert oder

neue erstellt werden können. Die ECN-Elemente sind mit den ASN.1-Elementen identisch,

es wird lediglich ein #-Zeichen am Anfang des Elementnamens angehängt (z.B.

#INTEGER, #SEQUENCE) [69].


Die ASN.1 wird überwiegend für die Beschreibung der Datenstrukturen von Kommunikati-

onsprotokollen verwendet.

Folgende Protokolle werden z.B. mit ASN.1 definiert:

Cooperative Awareness Message (CAM)

Wird bei der Vehicle-to-Vehicle (V2V)-, Vehicle-to-X (V2X)- und Vehicle-to-Inf-

rastructure (V2I)-Kommunikation verwendet [76].

IEC 61850 - Manufacturing Messaging Specification (MMS), Generic Object Ori-

ented Substation Events (GOOSE)

Diese Norm definiert die Kommunikation und Steuerung in elektrischen Schaltanla-

gen. ASN.1 wird hier in modifizierter Form verwendet [77].

Simple Network Management Protocol (SNMP)

SNMP ist ein Protokoll für die Überwachung und Steuerung von Netzwerkkompo-

nenten, wie z.B. Router, Switches und Servern [78].

Lightweight Directory Access Protocol (LDAP)

LDAP ist ein Verzeichniszugriffsprotokoll, das z.B. zur Verwaltung von E-Mail Ad-

ressbüchern verwendet wird [79].


In [80] wird eine dezentrale, generische Middleware für ein heterogenes Sensoren-/Aktoren-

Netzwerk entwickelt. Diese bietet die Möglichkeit, dass Geräte die Funktionen eines ande-

ren Geräts abfragen und dadurch ihre Kommunikationspartner selbstständig finden können.

Für die Datenkodierung wird ASN.1 mit PER-Kodierung verwendet.

In [81] und [82] wird die Performance zwischen ASN.1 und XML verglichen. Die Reports

kommen zum Ergebnis, dass der Overhead bei XML generell höher ist als bei ASN.1 und

die Verarbeitungszeit bei kleinen Datenstrukturen bei XML etwas besser ist als bei ASN.1,

aber mit zunehmender Komplexität der Datenstrukturen ASN.1 um bis zu 1.000 % perfor-

manter ist als XML.

5.2 Base64

Die Base64-Kodierung wurde von der IETF im Juli 2003 als RFC 3548 erstmals veröffent-

licht. Im Oktober 2006 wurde die RFC 3548 durch die RFC 4648 ersetzt. Die Base Kodie-

rung wird zur Konvertierung von beliebigen Binärdaten in ASCII-Zeichen verwendet. Im

RFC sind außerdem die Base16- und die Base32-Kodierung beschrieben. Die Base-Kodie-

rungsverfahren unterscheiden sich anhand der Größe des Zeichensatzes, z.B. 16 Zeichen bei

der Base16-Kodierung [83].

Bei der Base64-Kodierung wird ein Zeichensatz bestehend aus 64 US-ASCII-Zeichen und

einem Füllzeichen verwendet, siehe Tabelle 22 im Anhang. Beim Kodierungsvorgang wer-

den jeweils 3 Byte Binärdaten in 4 ASCII-Zeichen konvertiert. Dabei entsprechen 6 Bit Bi-

närdaten einem ASCII-Zeichen. Stehen weniger als 3 Byte Binärdaten zur Verfügung, wer-

den unvollständige 6 Bit-Gruppen mit 0-Bits aufgefüllt und fehlende 6 Bit-Gruppen mit dem

Füllzeichen ‚=‘ ergänzt. Als Beispiel wird der Wert 0x12345 in „EjRQ“ und der Wert

0x1234 in „EjQ=“ konvertiert [83].

Um die Base64-Kodierung auch für URLs und Dateinamen verwenden zu können, wurde

die Base64-URL-Kodierung definiert. Dabei wurden das 63. (‚+‘ durch ‚-‘) und 64. Zeichen

(‚/‘ durch ‚_‘) ersetzt [83].


Die Base64-Kodierung wird derzeit hauptsächlich für die Übertragung von Binärdaten in

zeichenbasierten Protokollen, zum Speichern von Binärdaten in XML und zum Verschlüs-

seln von Daten verwendet. Beispiele sind unter anderem:


Open Pretty Good Privacy (OpenPGP)

OpenPGP ist ein Standard zum Verschlüsseln und Signieren von Daten und wird

häufig für die Verschlüsselung von E-Mails verwendet. Die Base64-Kodierung wird

bei diesem Standard um eine Prüfsumme erweitert und als Radix-64 bezeichnet [84].

SMTP

SMTP ist ein reines ASCII-Protokoll und ermöglicht daher keine Übertragung von

Binärdaten, wie z.B. Anhänge. Erst durch die Multipurpose Internet Mail Extensions

(MIME), in der die Base64-Kodierung der Binärdateien in ASCII definiert ist, wurde

die Möglichkeit von E-Mail-Anhängen geschaffen [85].

In [86] wird die Verwendung von Base64 in Kombination mit Message Digest 5 (MD5) zur

Verschlüsselung und zum Schutz vor Veränderungen von Texten verwendet.

In [87] wird ein hybrider Verschlüsselungsalgorithmus unter der Verwendung von einem

initialen Stringmanipulations-Algorithmus, sowie dem Vigenere- und dem Base64-Algo-

rithmus beschrieben.

In [88] wird eine Methode zur sicheren Übertragung von Passwörtern über eine unverschlüs-

selte Verbindung vorgestellt. Dabei wird das Passwort verschlüsselt und in einem Bild ver-

steckt. Das Bild wird Base64-kodiert und in einem HTTP-Request versteckt.

Im Report [89] wird eine sichere Kommunikation zwischen Smartphones beschrieben. Die

verschlüsselte Information wird auf einen Text und ein Bild aufgeteilt und beim Empfänger

wieder zusammengesetzt. Im Verschlüsselungsalgorithmus wird die Base64-Kodierung

mehrfach angewendet.

In [90] wird eine Methode zur Image-Spam-Erkennung vorgestellt. Dabei werden die Binär-

daten des Bildes Base64-kodiert, die Features mit der N-Gramm-Methode extrahiert und

durch eine Support Vector Machine (SVM) gegebenenfalls als Spam klassifiziert.

Bewertung 63

6 Bewertung

In diesem Kapitel erfolgt die Auswahl des geeignetsten Programmiersystems und Kommu-

nikationsprotokolls für Smart Homes und der für die Übertragung notwendigen Kodierungs-

verfahren.

Das ausgewählte Programmiersystem und Kommunikationsprotokoll wird anschließend, in

Kombination mit den ausgewählten Kodierungsverfahren, für die Umsetzung des prakti-

schen Teils dieser Arbeit verwendet.

6.1 Programmiersystem

In diesem Abschnitt erfolgt die Bewertung der in Kapitel 3 vorgestellten Normen für spei-

cherprogrammierbare Steuerungen hinsichtlich der in Abschnitt 2.2.1 definierten Anforde-

rungen. Nachfolgend werden die Ergebnisse der einzelnen Anforderungen begründet und in

einem Gesamtfazit die geeignetste Norm ausgewählt.

REQ01 - Das Programmiersystem muss die Entwicklung von verteilten Anwendun-

gen unterstützen.

Verteilte Anwendungen können mit Hilfe der Kommunikations-FBe mit beiden Nor-

men erstellt werden. Die IEC 61499 bietet dabei den Vorteil, dass diese Norm spe-

ziell für verteilte Anwendungen entwickelt wurde. Applikationen werden im Anwen-

dungsmodell ohne Berücksichtigung einer Verteilung entwickelt. Die Verteilung der

Anwendung erfolgt anschließend im Systemmodell.

REQ02 - Die Entwicklung von Anwendungen muss auf eine sehr einfache Art und

Weise möglich sein.

Die Anwendungsentwicklung ist in der IEC 61131 in drei graphischen und drei tex-

tuellen Programmiersprachen, siehe Abschnitt 3.1.3, und in der IEC 61499 nur als

FBN möglich. Die IEC 61131 bietet den Vorteil, dass aus mehreren Programmier-

sprachen die für den Anwender einfachste ausgewählt werden kann. Dies wiederrum

bringt auch den Nachteil zur IEC 61499, dass es keine einheitliche Programmierspra-

che gibt und es daher von Vorteil wäre, eine Programmiersprache als Standard für

Smart Homes zu definieren.

Bewertung 64

REQ03 - Die Performance der Laufzeitumgebung muss für die Ausführung der An-

wendungsfälle ausreichend sein.

Anwendungsfälle der beiden Normen zeigen, dass weit komplexere Projekte als die

zwei definierten Test Cases realisiert werden können. Es ist aber sicher die Kombi-

nation aus verwendeter Systemhardware und Laufzeitumgebung für die Perfor-

mance-Bewertung ausschlaggebend.

REQ04 - Die Anbindung von Legacy-Systemen muss möglich sein.

Die Anbindung von Legacy-Systemen ist grundsätzlich mit Hilfe der Kommunikati-

ons-FBe möglich. Zur Inkompatibilität kann es durch verschiedene Implementierun-

gen des Kommunikationsprotokolls und durch die Datendarstellung kommen. Hier

können Anpassungen an den Kommunikations-FBen oder Adapter-FBen notwendig

sein.

REQ05 - Die Unterstützung von Standard-Schnittstellen (z.B. XMPP) muss gegeben

sein.

Die Kommunikations-FBe werden in beiden Normen über den ID-Eingang konfigu-

riert. Mit dieser ID werden das Kommunikationsprotokoll und die notwendigen Ein-

stellungsparameter konfiguriert. Durch dieses Konzept ist die Implementierung von

beliebigen Kommunikationsprotokollen möglich. Es kann aber bei den einzelnen

Entwicklungs- und Laufzeitumgebungen Einschränkungen geben.

RE06 - Das Programmiersystem muss eine systemunabhängige Programmierung er-

möglichen.

Die Programmierung erfolgt bei beiden Normen in systemunabhängigen Program-

miersprachen. Die Größe der verschiedenen Datentypen wird durch die Norm vor-

gegeben. Beim Datenaustausch zwischen heterogenen Systemen muss beachtet wer-

den, dass das Kommunikationsprotokoll eine generische Datendarstellung (Little- vs.

Big-Endian) unterstützt.

Eine Zusammenfassung der Ergebnisse ist in Tabelle 3 zu finden.

Anforderung IEC 61131 IEC 61499

REQ01 √ √

REQ02 √ √

REQ03 √ √

Bewertung 65

Anforderung IEC 61131 IEC 61499

REQ04 √ √

REQ05 √ √

REQ06 √ √

Tabelle 3: Fazit Programmiersysteme

Beide Normen erfüllen grundsätzlich alle definierten Anforderungen an das Programmier-

system. Die IEC 61499 bietet aber den Vorteil, dass diese speziell für verteilte Anwendun-

gen entwickelt wurde und in Zukunft wohl vermehrt zum Einsatz kommen wird. Aus diesen

Gründen wird die IEC 61499 als Programmiersystem für Smart Homes ausgewählt.

6.2 Kommunikationsprotokoll

In diesem Abschnitt erfolgt die Bewertung der in Kapitel 4 vorgestellten Kommunikations-

protokolle hinsichtlich der in Abschnitt 2.2.2 definierten Anforderungen. Nachfolgend wer-

den die Ergebnisse der einzelnen Anforderungen begründet und in einem Gesamtfazit das

geeignetste Kommunikationsprotokoll ausgewählt.

REQ11 - Das Hinzufügen von neuen Knoten muss sehr einfach erfolgen, am besten

durch „Plug & Play“.

Keines der Protokolle unterstützt das Hinzufügen von neuen Knoten per „Plug &

Play“. Es gibt aber für alle Protokolle Frameworks oder Erweiterungen, um diese

Funktion zu realisieren. Bei XMPP kann dies durch die Erweiterung „XEP-0030:

Service Discovery“5 und bei SOAP durch die Verwendung von DPWS, siehe Ab-

schnitt 4.1.3, realisiert werden. Das Integrieren von neuen Knoten erfolgt auch ohne

Protokollerweiterungen auf eine einfache Art. Dem neuen Knoten muss die IP-Ad-

resse, ID, JID oder URL der Gegenstelle bekannt sein.

REQ12 - Das Protokoll darf die Variabilität der Nutzdaten nicht einschränken.

Der Nachrichtenaustausch erfolgt bei SOAP und XMPP über XML, bei REST übli-

cherweise über XML oder JavaScript Object Notation (JSON) und bei WebSocket

als Text oder binär. Da der Datenaustausch bei allen Protokollen über XML erfolgen

5 http://xmpp.org/extensions/xep-0030.html

http://xmpp.org/extensions/xep-0030.html

Bewertung 66

kann und sich XML beliebig erweitern lässt, können beliebige Daten übertragen wer-

den. Es ist jedoch zu beachten, dass binäre Daten vorher als Text (ASCII, Unicode)

kodiert werden müssen. Dies kann z.B. mit Base64, siehe Abschnitt 5.2, erfolgen.

REQ13 - Das Protokoll muss asynchrone Kommunikation (Push oder Publish-Sub-

scribe) unterstützen.

Eventbasierte Nachrichten werden vom WebSocket- und XMPP-Protokoll unter-

stützt. Bei SOAP lässt sich diese Funktion mit der Verwendung von DPWS oder bei

Verwendung von SMTP als Transportprotokoll und bei REST über Web Hooks,

siehe Abschnitt 4.2.3, realisieren.

REQ14 - Das Protokoll muss eine synchrone Kommunikation unterstützen.

Eine Client-Server bzw. Request-Response Kommunikation wird von allen Proto-

kollen unterstützt.

REQ15 - Das Protokoll muss eine zeitgemäße Verschlüsselung unterstützen.

Eine Verschlüsselung auf Protokollebene bieten SOAP, XMPP und WebSocket an.

REST kann nur auf Transportprotokollebene, z.B. durch Verwendung von HTTPS,

verschlüsselt werden. Bei SOAP Nachrichten ist bei Verwendung von HTTPS eine

zusätzlich Verschlüsselung auf Transportprotokollebene möglich.

REQ16 - Das Protokoll muss die Möglichkeit zur Authentifizierung bereitstellen.

Authentifizierung auf Protokollebene bieten SOAP und XMPP an. Bei WebSocket

können HTTP-Client-Authentifizierungsverfahren, z.B. Cookies, HTTP- oder TLS-

Authentifizierung, oder eigene Verfahren, z.B. Ticket, verwendet werden. Bei REST

können, bei Verwendung des HTTP-Protokolls, dieselben Verfahren angewendet

werden.

REQ17 - Das Protokoll muss lokale und entfernte Ziele (Internet) erreichen können

(routbares Protokoll).

Entfernte Ziele können bei WebSocket durch die Verwendung von URLs und bei

XMPP durch Verwendung von JIDs erreicht werden. SOAP hat auf Protokollebene

Routing-Mechanismen. Für entfernte Ziele ist, wie auch bei REST, das verwendete

Transportprotokoll, z.B. HTTP, ausschlaggebend.

REQ18 - Die Performance des Protokolls muss für die Ausführung der Anwendungs-

fälle ausreichend sein.

Der „aktuelle Stand“ der einzelnen Protokolle zeigt, dass durch die Verwendung von

XML (mit Ausnahme von WebSocket) ein sehr großer Overhead entsteht, aber alle

Bewertung 67

Protokolle auf Performance optimiert werden können. Dies kann beispielsweise

durch Binary XML oder Komprimierung realisiert werden. Ohne Optimierung wei-

sen REST und WebSocket die besseren Performance-Werte auf.

REQ19 - Das Protokoll muss den Austausch von Daten zwischen heterogenen Sys-

temen unterstützen.

Da der Datenaustausch bei allen Protokollen über XML erfolgen kann, können die

XML-Elemente problemlos zwischen heterogenen Systemen ausgetauscht werden.

Ein Austausch von Binärdaten über XML ist nur mit vorheriger Konvertierung in

Text möglich. Bei der Auswahl des Kodierungsverfahrens ist darauf zu achten, dass

dieses heterogene Systeme (Little- bzw. Big-Endian) unterstützt. Bei der Übertra-

gung von Binärdaten mit WebSocket muss darauf geachtet werden, dass die Über-

tragung in der „Network-Byte-Order“ (Big-Endian) erfolgt.

In Tabelle 4 wurden die Ergebnisse zusammengefasst und die einzelnen Protokolle mit

Punkten bewertet. Ein ‚-‘ ergibt einen Punkt Abzug, ein ‚o‘ wird neutral gewertet und ein

‚√‘ ergibt einen zusätzlichen Punkt.

Anforderung SOAP REST WebSocket XMPP

REQ11 o/√1 o/√1 o/√1 o/√1

REQ12 √ √ √ √

REQ13 -/√1, 2 -/√1 √ √

REQ14 √ √ √ √

REQ15 √ -/√2 √ √

REQ16 √ -/√1, 2 -/√1 √

REQ17 -/√2 -/√2 √ √

REQ18 o/√1 √ √ o/√1

REQ19 √ √ √ √

Bewertung 3 0 6 7

1 mit Erweiterung

2 abhängig vom Transportprotokoll

Tabelle 4: Fazit Kommunikationsprotokolle

Bewertung 68

Unter Verwendung des Punktesystems schneidet XMPP knapp besser als WebSocket ab.

XMPP erfüllt ohne zusätzliche Erweiterungen alle Anforderungen. Der Overhead kann

durch Optimierungen verbessert werden und eine „Plug and Play“-Funktion kann durch eine

Erweiterung integriert werden. Aus diesen Gründen wird das XMPP-Protokoll als Kommu-

nikationsprotokoll für Smart Homes ausgewählt.

6.3 Kodierungsverfahren

In den vorherigen zwei Abschnitten wurde die IEC 61499 als Programmiersystem und

XMPP als Kommunikationsprotokoll für Smart Home Anwendungen ausgewählt. Für die

Übertragung von IEC 61499 Datentypen über das XMPP Protokoll sind Kodierungsverfah-

ren notwendig.

Für die Übertragung einer IEC 61499 Variable ist es nicht ausreichend nur den Variablen-

Wert zu übertragen, da der empfangene Wert einem Datentyp zuordenbar sein muss. Wird

z.B. der Wert 12 übertragen, könnte es sich um einen Ganzzahltyp, z.B. INT, oder um eine

Zeichenfolge, z.B. STRING, handeln. Der einfachste Lösungsansatz wäre, den Datentyp und

den Wert, z.B. über XML <value type=“INT“>12</value>, zu übertragen. Sobald

es sich bei den Daten nicht mehr um Basisdatentypen, sondern um (mehrfach) verschachtelte

Strukturen handelt, stößt dieser einfache Lösungsansatz an seine Grenzen. Ein zusätzliches

Problem stellen die verschiedenen Rechner-Architekturen (z.B. Little-Endian vs. Big-En-

dian oder Variablengröße) in einem Smart Home dar. Daher ist es sinnvoller, einen bewähr-

ten Kodierungsstandard zu verwenden, der auch die Kodierung von komplexen Datenstruk-

turen und deren Austausch in einer heterogenen Systemlandschaft unterstützt. Um auch für

zukünftige, komplexere Anwendungsfälle gerüstet zu sein, wird für die Kodierung der IEC

61499 Variablen der Kodierungsstandard ASN.1, siehe Abschnitt 5.1, verwendet.

Bei der ASN.1 Kodierung stehen mehrere Kodierungsarten, siehe Abschnitt 5.1.2, zur Ver-

fügung. Alle unterstützten Kodierungsarten, mit Ausnahme von XER, kodieren die Daten-

strukturen als Bit- oder Bytefolge. Bei Verwendung der XER-Kodierung können die erzeug-

ten XML-Elemente ohne eine zusätzliche Kodierung mit dem XMPP-Protokoll übertragen

werden. Bei allen anderen Kodierungsarten ist es notwendig die Bit- oder Bytefolge in eine

Zeichenfolge umzuwandeln, da das XMPP Protokoll nur XML-Elemente übertragen kann.

Die einfachste Möglichkeit wäre es, die Bitfolge als ASCII-Zeichen 0 bzw. 1 zu übertragen.

Dies führt aber zu einem sehr großen Overhead (1 Bit wird zu 7 Bits). Ein performanterer

Bewertung 69

Ansatz wäre es die einzelnen Bytes in UTF-8- Zeichen zu konvertieren. Bei dieser Lösung

entsteht zwar kein zusätzlicher Overhead, dafür sind im UTF-8-Zeichensatz Zeichen enthal-

ten, z.B. <, > oder &, die für XML-Elemente reserviert sind und daher nochmals speziell

konvertiert werden müssten, z.B. < wird zu &lt. Da es für genau diese Problemstellung

mehrere bewährte Kodierungsverfahren gibt ist es auch sinnvoll auf diese zurückzugreifen.

Daher wird für die Kodierung von Bit- bzw. Bytefolgen in eine Zeichenfolge die Base64-

Kodierung, siehe Abschnitt 5.2, verwendet.

Zusammenfassend kann festgehalten werden, dass für die Übertragung einer IEC 61499 Va-

riable eine ASN.1 Kodierung notwendig ist. Wird eine ASN.1 Kodierungsart verwendet, die

als Ergebnis eine Bit- oder Bytefolge liefert, wird diese zusätzlich mit der Base64-Kodierung

in ASCII-Zeichen konvertiert, da mit dem XMPP-Protokoll nur XML-Elemente übertragen

werden können.

Architektur 70

7 Architektur

In diesem Kapitel wird die Architektur des Testaufbaus definiert. Nachfolgend werden die

Architektur und die beteiligten Komponenten beschrieben. Im ersten Abschnitt erfolgt die

Beschreibung der System-Komponenten und im zweiten Abschnitt die der Software-Kom-

ponenten.

Für die Ausführung der in Abschnitt 2.3 definierten Test Cases werden drei Akteure (Sys-

tem-Komponenten) benötigt: Netzbetreiber, CEM und Display. Diese sind in Abbildung 15

als Komponentendiagramm dargestellt und werden in Abschnitt 7.1 detailliert beschrieben.

Der Test Case 1 (TC1) „Demand-Side-Management mittels Stromspeicher“ wird auf der

Netzbetreiber- und Stromspeicher-Komponente ausgeführt, der Test Case 2 (TC2) „Erinne-

rungsfunktion“ auf der Verbraucher- und Display-Komponente.

Netzbetreiber

CEM

Stromspeicher

Status

Verbraucher Display

Netz-Daten

Abbildung 15: Komponenten-Diagramm

In Abbildung 16 ist die Netzwerk-Topologie dargestellt. Jeder der zuvor definierten Akteure

wird als eigenes System modelliert. Da beim XMPP-Protokoll die Kommunikation zwischen

den Clients über einen XMPP-Server erfolgt, ist noch ein viertes System mit einem XMPP-

Server notwendig. Details über die XMPP-Kommunikation sind in Abschnitt 9.1 zu finden.

Die Kommunikation zwischen den einzelnen Systemen erfolgt über Ethernet und TCP/IP.

Jedes System besitzt eine statische IP Adresse und eine oder mehrere JIDs. Auf ein DNS

und einen Dynamic Host Configuration Protocol (DHCP)-Server wurde bewusst verzichtet,

um die Komplexität und die Hardwareanforderungen gering zu halten.

Die Testanwendung für die Ausführung des TC1 ist auf den Systemen Netzbetreiber und

CEM verteilt und die des TC2 auf den Systemen CEM und Display.

Architektur 71

XMPP-Server192.168.1.210

localhost

Netzbetreiber192.168.1.200

netop@localhost/res

CEM192.168.1.201

cemdsm@localhost/rescemlm@localhost/res

Display192.168.1.202

display@localhost/res

Abbildung 16: Netzwerk-Topologie

7.1 System-Komponenten

In diesem Abschnitt werden die Aufgaben und die Bedienung der vier System-Komponenten

- Netzbetreiber, CEM, Display und XMPP-Server - detailliert beschrieben. Um die Imple-

mentierung einfach zu halten werden Stromnetz, Stromspeicher, Verbraucher und Display

über Testplatinen simuliert.

7.1.1 Netzbetreiber

Die Aufgabe des Netzbetreibers ist es die Netzkenndaten (Überspannung, Normalspannung,

Unterspannung) zu ermitteln und diese über eine Schnittstelle anzubieten.

Die Netzkenndaten werden über die in Abbildung 17 dargestellte Testplatine simuliert.

Diese besteht aus drei LEDs mit zugehörigen Tastern. Mit den Tastern kann zwischen den

drei Netzzuständen gewechselt werden.

Rote LED - Überspannung

Grüne LED – Normalspannung

Gelbe LED – Unterspannung

Die Netzkenndaten werden vom Netzbetreiber an interessierte Empfänger über eine Publish-

Subscribe Verbindung übertragen. Der Netzbetreiber übernimmt dabei die Rolle des Publi-

shers. Die Nachrichtenübertragung erfolgt über XMPP-Presence-Stanzas.

Architektur 72

Abbildung 17: Testplatine Netzbetreiber

7.1.2 CEM

Das CEM-System besteht aus einem Stromspeicher und einem Verbraucher. Der Stromspei-

cher empfängt Netzkenndaten und startet in Abhängigkeit dieser den Lade- bzw. Entlade-

vorgang. Der Verbraucher bietet seinen Status (Ein, Aus) über eine Schnittstelle an.

Der Stromspeicher und der Verbraucher werden über die in Abbildung 18 dargestellte Test-

platine simuliert. Diese besteht aus 3 LEDs und einem Taster:

Rote LED – Stromspeicher wird geladen

Grüne LED – Stromspeicher wird entladen

Gelbe LED – Verbraucher ist eingeschaltet

Taster – Verbraucher ein- bzw. ausschalten

Die Netzkenndaten werden über eine Publish-Subscribe Verbindung empfangen. Das CEM

übernimmt dabei die Rolle eines Subscribers. Die Nachrichtenübertragung erfolgt über

XMPP-Presence-Stanzas.

Der Verbraucherstatus kann über eine Client-Server Verbindung abgerufen werden. Das

CEM übernimmt dabei die Rolle des Servers. Die Nachrichtenübertragung erfolgt über

XMPP-IQ-Stanzas.

Architektur 73

Abbildung 18: Testplatine CEM

7.1.3 Display

Die Aufgabe des Displays ist es den Status des Verbrauchers in einem definierten Intervall

abzufragen und diesen anzuzeigen.

Das Display wird über die in Abbildung 19 dargestellte Testplatine simuliert. Diese besteht

aus einer LED, die anzeigt, ob der Verbraucher ein- oder ausgeschaltet ist.

Der Verbraucherstatus wird über eine Client-Server Verbindung abgerufen. Das Display

übernimmt dabei die Rolle des Clients. Die Nachrichtenübertragung erfolgt über XMPP-IQ-

Stanzas.

7.1.4 XMPP-Server

Der XMPP-Server wird für die Kommunikation zwischen den XMPP-Clients benötigt. Die-

ser verwaltet die Regeln für den Verbindungsaufbau und die XMPP-Benutzer und routet die

eingehenden Nachrichten an die Empfänger weiter.

Für den Verbindungsaufbau ist die Authentifizierung über das SASL Protokoll notwendig

und die Verbindungsverschlüsselung über TLS optional. Für die Test Cases wäre es sinnvoll,

wenn die TLS-Verschlüsselung verpflichtend wäre. Für die weiteren Evaluierungstests,

siehe Kapitel 11, ist eine optionale Abschaltung der Verschlüsselung zwingend erforderlich.

Architektur 74

Abbildung 19: Testplatine Display

Für die zuvor erläuternden Systeme sind folgende vier XMPP-Benutzer notwendig:

netop@localhost - Publisher Netzkenndaten (Netzbetreiber)

cemdsm@localhost – Subscriber Netzkenndaten (CEM)

cemlm@localhost – Server Verbraucher (CEM)

display@localhost – Client Verbraucher (Display)

7.2 Software-Komponenten

Für die Ausführung der Test Cases werden zwei Testanwendungen benötigt. Deren Ablauf

wird mittels IEC 61499 FBD beschrieben. Um die Übersichtlichkeit der Diagramme zu er-

höhen, werden die Ereignisverbindungen nicht dargestellt und für die Taster und LEDs Ab-

kürzungen verwendet, siehe Tabelle 5. Zur besseren Unterscheidung beginnt die Abkürzung

eines Tasters (Eingang) mit dem Buchstaben ‚I‘, die einer LED (Ausgang) mit ‚Q‘.

Abkürzung System Beschreibung

I_OV Netzbetreiber Taster zum Einstellen der Überspannung

I_NV Netzbetreiber Taster zum Einstellen der Normalspannung

I_UV Netzbetreiber Taster zum Einstellen der Unterspannung

Architektur 75

Abkürzung System Beschreibung

I_LO CEM Taster zum Ein- und Ausschalten des Verbrauchers

Q_OV Netzbetreiber LED zur Anzeige der Überspannung

Q_NV Netzbetreiber LED zur Anzeige der Normalspannung

Q_UV Netzbetreiber LED zur Anzeige der Unterspannung

Q_C CEM LED zur Anzeige des Ladevorgangs des Stromspeichers

Q_D CEM LED zur Anzeige des Entladevorgangs des Stromspei-

chers

Q_LO CEM LED zur Anzeige des Verbraucher-Status

Q_LOD Display LED zur Anzeige des Verbraucher-Status

Tabelle 5: Abkürzungen der Taster und LEDs im FBD

7.2.1 Demand-Side-Management mittels Stromspeicher

In Abbildung 20 ist das FBD der Testanwendung des TC1 dargestellt. Der linke Teil der

Anwendung wird am Netzbetreiber ausgeführt, der rechte Teil am CEM. Das Einlesen der

Taster, das Setzen der LEDs und die Übertragung der Daten zwischen Netzbetreiber und

CEM wurden aus Gründen der Übersichtlichkeit nicht dargestellt.

Der linke Anwendungsteil liest über die drei Eingänge (I_OV, I_NV, I_UV) den Netzzu-

stand ein. Dieser wird intern über drei RS-Flipflops gespeichert. Gesetzt werden diese beim

Drücken des dazugehörigen Netzzustandstasters (z.B. I_NV) und zurückgesetzt beim Drü-

cken eines der beiden anderen Netzzustandstaster (z.B. I_OV, I_UV). Die beiden Netzzu-

standstaster für das Rücksetzen sind über ein OR-Glied mit dem Reset-Eingang des RS-

Flipflops verbunden. Die Ausgänge der Flipflops sind mit den dazugehörenden LEDs und

dem rechten Anwendungsteil verbunden.

Beim rechten Anwendungsteil wird der Lade- und Entladevorgang des Stromspeichers wie-

derum über RS-Flipflops realisiert. Gesetzt wird das Flipflop des Ladevorgangs bei Über-

spannung, das des Entladevorgangs bei Unterspannung. Zurückgesetzt werden beide bei

Normalspannung oder beim Auftreten des jeweils anderen Netzzustandes (z.B. Überspan-

nung beim Entladevorgang). Das Rücksetzen der Flipflops wurde ebenfalls über OR-Glieder

Architektur 76

Abbildung 20: FBD Demand-Side-Management mittels Stromspeicher

realisiert. Die Ausgänge der Flipflops sind mit den dazugehörigen LEDs für den Lade-

(Q_C) bzw. Entladevorgang (Q_D) verbunden.

Das Einlesen der drei Taster erfolgt in einem Intervall von 500 ms. Das Ein- und Ausschalten

der LEDs erfolgt nach dem Setzen des dazugehörigen Flipflops ohne Verzögerung. Die

Übertragung der drei Netzzustände vom Netzbetreiber zum CEM erfolgt über eine Publish-

Subscribe Verbindung mit XMPP-Presence-Stanzas. Der Netzbetreiber ist dabei der Publis-

her und das CEM der Subscriber.

7.2.2 Erinnerungsfunktion

In Abbildung 21 ist das FBD der Testanwendung des TC2 dargestellt. Der linke Teil der

Anwendung wird am CEM ausgeführt, der rechte Teil am Display. Das Einlesen des Tasters,

das Setzen der LED und die Übertragung der Daten zwischen CEM und Display wurden aus

Gründen der Übersichtlichkeit nicht dargestellt.

Der linke Anwendungsteil liest über den Eingang I_LO den Status des Verbrauchers ein.

Dieser wird intern über ein RS-Flipflop gespeichert. Gesetzt und rückgesetzt wird dieses

beim Drücken des Tasters. Das Rücksetzen wurde über ein AND-Glied realisiert. Dieses

Architektur 77

Abbildung 21: FBD Erinnerungsfunktion

verknüpft den Taster und den Ausgang des Flipflops. Wenn das Flipflop gesetzt ist und der

Taster gedrückt wird, wird das Flipflop zurückgesetzt. Der Ausgang des Flipflops ist mit der

Status-LED des Verbrauchers und dem rechten Anwendungsteil verbunden.

Beim rechten Anwendungsteil wird der Status des Verbrauchers am LED Q_LOD ausgege-

ben.

Das Einlesen des Tasters erfolgt in einem Intervall von 500 ms. Das Ein- und Ausschalten

der LEDs erfolgt nach dem Setzen des Flipflops bzw. nach der Übertragung des Status ohne

Verzögerung. Die Übertragung des Verbraucherstatus vom CEM zum Display erfolgt über

eine Client-Server Verbindung mit XMPP-IQ-Stanzas in einem Intervall von einer Sekunde.

Das Display ist dabei der Client und das CEM der Server.

Definition der Testumgebung 78

8 Definition der Testumgebung

In diesem Kapitel erfolgt die Auswahl der Hardware und des Betriebssystems, der IEC

61499 Entwicklungs- und Laufzeitumgebung, der XMPP-Bibliothek und die des XMPP-

Servers für die Umsetzung des Testaufbaus.

8.1 Hardware und Betriebssystem

Die Anforderungen an die System-Hardware sind sehr unterschiedlich. Bei der Hardware

des Netzbetreibers wird es sich höchstwahrscheinlich um eine Server-Farm und beim Dis-

play um ein eingebettetes Gerät (engl. Embedded-Device) handeln. Um einheitliche Systeme

verwenden zu können wird das kleinstmögliche System, das alle Anforderungen erfüllen kann,

verwendet. Im konkreten Fall wird das System des Displays, ein Embedded-Device, für den

Testaufbau eingesetzt. Dies bringt zusätzlich den Vorteil, dass sich die Testumgebung kos-

tengünstig und transportabel realisieren lässt.

Die Anforderung an die System-Hardware kann auf folgende Punkte zusammengefasst wer-

den:

Embedded-Device

Kleiner Formfaktor

Kostengünstig

Geringer Stromverbrauch

Passive Kühlung

Ausreichende Performance für die Ausführung der Testanwendungen

Ethernet Schnittstelle

GPIO Pins (für die Ansteuerung der in Abschnitt 7.1 definierten Testplatinen)

Offenes Betriebssystem (nicht proprietär), Open Source

Diese Anforderungen werden von sogenannten Einzelplatinencomputern, wie z.B. Arduino,

Banana Pi, BeagleBoard, Cubieboard, PandaBoard oder Raspberry Pi am besten erfüllt.

Diese Systeme unterscheiden sich anhand der Leistungsfähigkeit des Prozessors, der Größe

des Arbeitsspeichers, der Anzahl der GPIO Pins, der verfügbaren Schnittstellen und des

Preises.

Da die Performance- und Schnittstellen-Anforderungen gering sind und es sich auch um das

günstigste System handelt, fällt die Auswahl auf den Raspberry Pi Modell B. Dieser verfügt


über einen ARMv6 Prozessor mit einem Kern und 700 MHz Taktfrequenz, 512 MB RAM,

eine 100 MBit Ethernet Schnittstelle, zwei USB 2.0 Schnittstellen, 17 GPIO Pins und kostet

25 USD (Listenpreis). Weitere technische Details sind auf der Raspberry Pi Internetseite6 zu

finden [91].

Für den Raspberry Pi stehen als Betriebssystem mehrere Linux Distributionen und eine

RISC OS Version zur Verfügung. Diese können von der Internetseite des Hertellers7 als

Image heruntergeladen werden. Das weitverbreitetste und empfohlene Betriebssystem ist

das auf Debian 7 basierende Raspbian. Dieses erfüllt die vorher definierten Anforderungen

(offenes Betriebssystem, Open Source) und kann daher als Betriebssystem für den Testauf-

bau verwendet werden [91].

Im nächsten Abschnitt erfolgt die Auswahl der IEC 61499 Enwicklungs- und Laufzeitum-

gebung.

8.2 IEC 61499 Entwicklungs- und Laufzeitumgebung

Seit der Veröffentlichung der IEC 61499 wurden einige Software-Tools für den wissen-

schaftlichen und kommerziellen Bereich entwickelt. Einige dieser Tools wurden in der Zwi-

schenzeit eingestellt bzw. nicht mehr weiterentwickelt. In Tabelle 6 sind die derzeit erhält-

lichen und in Weiterentwicklung befindlichen Software-Tools aufgelistet. Dabei handelt es

sich um ein Closed Source, ein Open Source und zwei kommerzielle Produkte. Bei der Por-

tabilität setzen zwei Produkte auf eine Virtuelle Maschine (VM) und zwei Produkte auf eine

native Ausführung [33], [35], [92], [93].

Für den Testaufbau wird 4DIAC aus mehreren Gründen bevorzugt. Die Entwicklungsumge-

bung und die Laufzeitumgebung sind kostenlos und stehen als Open Source zur Verfügung.

4DIAC ist die einzige IEC 61499 Open Source Implementierung, die annähernd den Funk-

tionsumfang der kommerziellen Produkte abdeckt, aktiv weiterentwickelt wird und von der

zweimal jährlich neue Versionen erscheinen. Im Lieferumfang sind bereits FBe für die GPIO

Pins des Raspberry Pi enthalten. Ein weiterer Vorteil ist die Implementierung der Kommu-

nikations-Architektur als Schichtenmodell. Bei dieser können die einzelnen Kommunikati-

onsprotokolle beliebig kombiniert werden, z.B. ASN.1 und TCP/IP [92], [93], [94].

6 https://www.raspberrypi.org/documentation/hardware/raspberrypi 7 https://www.raspberrypi.org/downloads/

https://www.raspberrypi.org/documentation/hardware/raspberrypi

https://www.raspberrypi.org/downloads/


Entwicklungs-

umgebung

Laufzeit-

umgebung

Typ Programmier-

sprache

Plattform

FBDK FBRT Closed Source Java Java VM

4DIAC-IDE FORTE Open Source C++ nativ

ISaGRAF

Workbench

ISaGRAF

Runtime

Kommerziell ST VM

nxtStudio nxtRT61499F Kommerziell C++ nativ

Tabelle 6: IEC 61499 Software-Tools

Die nächsten beiden Abschnitte befassen sich mit der Auswahl der XMPP Bibliothek und

des XMPP Servers.

8.3 XMPP Bibliothek

Zur Reduktion der Implementierungsdauer und zur Steigerung der Softwarequalität wurde

der XMPP-Stack für die Kommunikation zwischen den Smart Home Komponenten nicht

selbst entwickelt, sondern auf eine etablierte XMPP Bibliothek (engl. Library) zurückgegrif-

fen.

Der erste Implementierungsansatz für die XMPP-Kommunikation war eine Server-zu-Ser-

ver-Verbindung. Diese hätte im Vergleich zur Client-zu-Server-Verbindung den Vorteil,

dass kein zusätzlicher XMPP-Server notwendig wäre und die Rechteverwaltung beim Ak-

teur selbst erfolgen könnte. Dieser Ansatz wurde jedoch wieder verworfen, da eine zentrale

Rechteverwaltung der Praxis entspricht und gleichzeitig die Sicherheit erhöht. Ein weiterer

Grund ist, dass der Standardanwendungsfall die Entwicklung einer XMPP-Clientanwendung

ist und daher so gut wie keine XMPP-Server-Bibliotheken zur Verfügung stehen. Ein wei-

terer Ansatz wäre eine Client-zu-Client Verbindung (XEP-0174: Serverless Messaging).

Dieser Ansatz wurde ebenfalls verworfen, weil nur wenige XMPP Bibliotheken diese

XMPP-Erweiterung unterstützen, die Rechteverwaltung lokal erfolgen müsste und die Ein-

bindung von Legacy-XMPP-Knoten nur bedingt möglich wäre. Aus diesen Gründen fiel die

Entscheidung auf die Client-zu-Server-Verbindung.


Auf der Internetseite der XSF8 ist eine Liste von verfügbaren XMPP-Client-Bibliotheken zu

finden. Da die Bibliothek in die IEC 61499 Laufzeitumgebung FORTE eingebunden wird,

muss die Bibliothek ebenfalls in C oder C++ entwickelt worden sein und wenn möglich für

mehrere Plattformen (z.B. Linux, Windows) verfügbar sein. In Tabelle 7 sind alle Bibliothe-

ken aufgelistet, die diese Anforderungen erfüllen. Die Spalte „Letzte Veröffentlichung“ be-

inhaltet das Datum, an dem die aktuelle Version erschienen ist. Kein Eintrag bedeutet, dass

entweder das Datum unbekannt oder noch keine stabile Version verfügbar ist.

XMPP Bibliothek Programmier-

sprache

Letzte

Veröffentlichung

Delta XMPP Project QT, QCA -

DXMPP BOOST -

gloox ANSI C++ 31.01.2015

iksemel C 07.2009

libstrophe C 31.10.2014

Jreen library QT 28.10.2014

qxmpp QT 13.03.2015

Swiften QT -

Txmpp C++ 02.07.2010

Tabelle 7: XMPP Bibliotheken

Im nächsten Schritt wurden alle Bibliotheken, bei denen seit einem Jahr (Juni 2014) keine

neue Version erschienen ist, aussortiert. Somit blieben vier Kandidaten (in Tabelle 7 fett

markiert) über. Diese wurden anhand des Funktionsumfangs, der Dokumentation, der ver-

fügbaren Beispiele und deren Abhängigkeiten zu anderen Bibliotheken bewertet. Letztlich

fiel die Wahl auf die gloox-Library, da diese den größten Funktionsumfang bietet, für sehr

viele Plattformen verfügbar ist und nur eine notwendige und zwei optionale Abhängigkeiten

zu anderen Bibliotheken besitzt.

Im nächsten Abschnitt erfolgt die Auswahl das XMPP Servers.

8 https://xmpp.org/xmpp-software/libraries/

https://xmpp.org/xmpp-software/libraries/


8.4 XMPP Server

Im vorherigen Abschnitt wurde als XMPP-Verbindungsart eine Client-zu-Server-Verbin-

dung festgelegt. Aus diesem Grund ist ein XMPP Server notwendig. Wie in Abbildung 16

ersichtlich, wird der XMPP Server auf einem eigenen System installiert.

Auf der Internetseite der XSF9 ist eine Liste von verfügbaren XMPP Servern zu finden. Da

der XMPP Server auf einem Raspberry Pi mit Raspbian installiert wird, muss dieser für

Linux verfügbar sein. In Tabelle 8 sind die Server zusammengefasst, die diese Anforderun-

gen erfüllen.

XMPP Server Programmier-

sprache

Letze

Veröffentlichung

Apache Vysper Java 23.02.2011

djabberd Perl 13.06.2011

ejabberd Erlang 23.04.2015

in.jabberd C 04.09.2014

jabberd14 C++ 28.06.2012

Jabberd2 C 13.04.2015

Metronome IM Lua 27.03.2015

MongooseIM Erlang 02.04.2015

Openfire Java 21.04.2015

Prosody IM Lua 26.03.2015

psyced Python 21.08.2012

Tigase XMPP Server Java 15.05.2015

Vines XMPP Server Ruby 13.09.2014

Wokkel Python 12.01.2013

Tabelle 8: XMPP Server

9 http://xmpp.org/xmpp-software/servers/

http://xmpp.org/xmpp-software/servers/


Im nächsten Schritt wurden alle XMPP-Server, bei denen seit einem Jahr (Juni 2014) keine

neue Version erschienen ist, aussortiert. Somit blieben neun Kandidaten (in Tabelle 8 fett

markiert) über. Für Raspbian stehen ejabberd und Prosody IM als Paket zur Verfügung. Da

dies die Installation wesentlich beschleunigt und erleichtert wurden nur noch diese zwei

XMPP Server genauer bewertet. Schlussendlich fiel die Entscheidung auf ejabberd, da sich

dieser sehr komfortabel und einfach per Webinterface konfigurieren lässt und von diesem

schon seit vielen Jahren eine stabile Version verfügbar ist.

Implementierung 84

9 Implementierung

Dieses Kapitel widmet sich der Implementierung der XMPP-Kommunikation und der An-

wendungslogik der beiden Testanwendungen.

Für die Implementierung wurde Raspbian in der Version 2015-02-16, 4DIAC in der Version

1.7.1, gloox in der Version 1.0.13 und ejabberd in der Version 2.1.10 verwendet.

Im nächsten Abschnitt werden die in 4DIAC vorhandenen Kommunikationsarten und die

Kommunikations-Architektur beschrieben und die Implementierung der XMPP-Kommuni-

kation erläutert.

9.1 XMPP-Kommunikation

Die Implementierung der XMPP-Kommunikation in der Laufzeitumgebung FORTE kann

über zwei Wege erfolgen: Es können eigene Dienstschnittstellen FBe (engl. SIFBs) entwi-

ckelt oder die bestehenden NET-FBe verwendet werden. Die Entwicklung eigener SIFBs

hat den Vorteil, dass die Schnittstelle frei definiert werden kann und dass die Entwicklung

keinen Einschränkungen durch die interne Kommunikations-Architektur unterliegt. Bei Ver-

wendung der bestehenden NET-FBe können die Anwender das Protokoll durch Verändern

des ID-Parameters, siehe Abbildung 22, festlegen. Zum Ändern des Protokolls muss also

kein FB ausgetauscht, sondern lediglich der Parameter verändert werden. Ein weiterer Vor-

teil ist, dass die Anwender mit dem Umgang der NET-FBe bereits vertraut sind und im Ver-

gleich zu den XMPP-SIFBe kein zusätzlicher Lernaufwand besteht. Durch die Verwendung

der internen Kommunikations-Architektur der NET-FBe können Protokolle beliebig kom-

biniert werden. So ist es z.B. möglich die bereits existierende ASN.1 Kodierung für die

XMPP-Kommunikation zu verwenden. Für die Entwicklung fällt zwar Einarbeitungszeit für

die interne Kommunikations-Architektur an, dafür kann diese erprobte Architektur verwen-

det werden und es muss keine Zeit in die Entwicklung einer eigenen investiert werden. Da

die Vorteile bei der Verwendung der bestehenden NET-FBe überwiegen, wird diese Vari-

ante für die Entwicklung der XMPP-Kommunikation verwendet.

Im nächsten Abschnitt wird die Kommunikation mit den NET-FBe kurz beschrieben.

Implementierung 85

Abbildung 22: Publish FB aus 4DIAC

9.1.1 NET FB

In 4DIAC stehen zwei Kommunikationsarten zur Verfügung: Publish-Subscribe und Client-

Server. Die nachfolgende Beschreibung bezieht sich auf die Verwendung der IP-Kommuni-

kation. Diese verwendet TCP/IP für Publish-Subscribe und UDP/IP für Client-Server. Bei

Verwendung anderer Kommunikationsprotokollen, wie z.B. Modbus oder Powerlink, kann

die Beschreibung leicht abweichen [94].

Publish-Subscribe:

Für diese Kommunikationsart stehen PUBLISH_X und SUCSCRIBE_X FBe zur Verfü-

gung. Das X steht für die Anzahl der Daten, die übertragen werden. Es stehen FBe für 0 bis

6 Dateneingänge bzw. -ausgänge zur Verfügung. Die Anzahl der Dateneingänge eines Sub-

scribe FBs muss immer der Anzahl der Datenausgänge des Publish FBs entsprechen. Bei

dieser Kommunikationsart wird eine Nachricht vom Publisher versendet und von einem oder

mehreren Subscribern empfangen [94].

Client-Server:

Für die zweite Kommunikationsart stehen SERVER_X_Y und CLIENT_Y_X FBe zur Ver-

fügung. Das X steht für die Anzahl der Datenausgänge des Client bzw. Dateneingänge des

Server FBs und das Y für die Dateneingänge des Clients bzw. Datenausgänge des Server

FBs. Es stehen FBe für diverse Ein- und Ausgangskombinationen zur Verfügung. Die An-

zahl der Datenausgänge bzw. -eingänge eines Client FBs muss immer der Anzahl der Da-

teneingänge bzw. -ausgänge des Server FBs entsprechen. Bei dieser Kommunikationsart

wird eine Anfrage vom Client an den Server geschickt und der Server sendet die Antwort an

den Client zurück. Anders als bei Publish-Subscribe funktioniert diese Kommunikationsart

nur zwischen einem Server und einem Client. Es können sich nicht gleichzeitig mehrere

Clients an einem Server anmelden und ein Client kann sich auch nicht gleichzeitig an meh-

reren Servern anmelden. Ein Verbindungsaufbau vom Client zum Server ist nur möglich,

wenn der Server vor dem Client initialisiert wurde [94].

Implementierung 86

Wie am Anfang des Kapitels bereits erwähnt werden die zu verwendenden Kommunikati-

onsprotokolle über den ID Eingang, siehe Abbildung 22, des NET-FBs festgelegt und kon-

figuriert. Diese ID setzt sich aus „Protokoll[Parameter].Protokoll[Parameter]“ zusammen,

wobei die Anzahl der Protokolle nicht begrenzt ist.

Eine Beispiel ID könnte z.B. so aussehen:

fbdk[].ip[192.168.20.1:61499]

Das erste Protokoll hat den Namen fbdk und keine Parameter, das zweite den Namen ip

und als Parameter 192.168.20.1:61499. Bei fbdk handelt es sich um die ASN.1 Ko-

dierung, bei ip um die IP-Kommunikation mit TCP/IP bzw. UDP/IP [94].

Im nächsten Abschnitt wird auf die 4DIAC Kommunikations-Architektur genauer eingegan-

gen.

9.1.2 Kommunikations-Architektur

Die Kommunikations-Architektur ist als Schichtenmodell, siehe Abbildung 23, ähnlich dem

OSI-Schichtenmodell aufgebaut. Wie bereits am Ende des letzten Abschnitts erwähnt, kön-

nen mit dem ID-Parameter eines NET-FBs mehrere Protokolle angegeben werden. Mit Hilfe

dieses Parameters wird das Schichtenmodell aufgebaut. Dieses besteht aus einer oberen, ei-

ner oder mehreren mittleren und einer unteren Schicht. Die obere Schicht hat direkten Zu-

griff auf den FB und dessen Ein- und Ausgänge. Die Aufgabe der oberen Schicht ist es, die

Daten vom FB zu lesen bzw. die empfangenen Daten zurückzuschreiben. Die mittlere

Schicht bereitet die Daten für die Übertragung vor bzw. bereitet die empfangenen Daten für

die obere Schicht auf. Typische Anwendungen sind Kodierungsverfahren, wie z.B. ASN.1

oder Base64, oder Komprimierungsverfahren. Die untere Schicht hat direkten Zugriff auf

die Netzwerkschnittstelle. Diese überträgt die Daten an die Netzwerkschnittstelle bzw. emp-

fängt neue Daten asynchron über eine Interrupt-Funktion [94].

Realisiert wird die Kommunikations-Architektur über ein C++ Klassenmodell. Jede Netz-

werk-Schicht entspricht einer C++ Klasse, die von der Klasse CComLayer abgeleitet wird.

Implementierung 87

NET FB(CCommFB)

Obere Netzwerk-Schicht

Mittlere Netzwerk-Schicht

Untere Netzwerk-Schicht

Netzwerk

IEC 61499Events

Abbildung 23: 4DIAC Kommunikations-Architektur, nach [94]

Die Schnittstelle besteht aus folgenden Methoden [94]:

EComResponse openConnection(char *pa_acConnectionParams,

char *pa_acRemainingConnectionID)

Diese Funktion wird beim INIT+ Event des FBs aufgerufen. Sie konfiguriert die

Schicht und erstellt die darunterliegende Schicht, falls vorhanden. Der Übergabepa-

rameter *pa_acConnectionParams enthält die Konfigurationsparameter des

aktuellen Protokolls aus dem ID Feld des FBs.

virtual void closeConnection() = 0

Diese Funktion wird beim INIT- Event des FBs aufgerufen. Sie führt alle Aktionen,

die zum Beenden der Schicht notwendig sind aus und ruft die closeConnec-

tion()-Methode der darunterliegenden Schicht, falls vorhanden, auf.

virtual EComResponse sendData(void *pa_pvData, unsigned

int pa_unSize) = 0

Diese Funktion wird beim REQ Event des FBs aufgerufen. Sie führt alle notwendi-

gen Aktionen zum Versenden der Daten, wie z.B. Kodierung, Komprimierung oder

den Sendevorgang selbst, aus.

Implementierung 88

virtual EComResponse recvData(const void *pa_pvData, un-

signed int pa_unSize) = 0

Diese Funktion wird von der darunterliegenden Schicht beim Empfang von Daten

aufgerufen. Sie führt alle notwendigen Aktionen zum Empfangen der Daten, wie z.B.

Dekodierung oder Übergabe an den FB, durch.

virtual EComResponse processInterrupt()

Diese Funktion wird vom Interrupt aufgerufen und zum Abschluss des Empfangs-

vorgangs der Daten genutzt. Normalerweise wird diese Funktion nur in der untersten

Schicht implementiert.

Der nächste Abschnitt widmet sich der Implementierung der XMPP-Kommunikation.

9.1.3 XMPP Implementierung

Die Implementierung der XMPP-Kommunikation ist als Klassendiagramm in Abbildung 24

dargestellt.

Abbildung 24: Klassendiagramm XMPP Implementierung

Implementierung 89

Die notwendigen Funktionen wurden in vier Klassen aufgeteilt:

CXmppComLayer

Diese Klasse implementiert die XMPP-Netzwerk-Schicht, wie am Ende des vorhe-

rigen Abschnitts beschrieben. Es wird lediglich die vorgegebene Schnittstelle imple-

mentiert und Anfragen an die CXmppConnection-Klasse weitergeleitet.

CXmppConnection

Diese Klasse beinhaltet die eigentliche XMPP-Verbindung. Sie verwaltet die Ver-

bindung und die Kontaktliste (Rooster) und empfängt bzw. versendet XMPP-Stan-

zas. Alle XMPP-Funktionen werden mit Hilfe der gloox-Bibliothek ausgeführt.

CXmppExtension

In dieser Klasse ist ein eigener XML-Namensraum „forte“ für die XMPP-Stanzas

definiert. Eine genauere Beschreibung erfolgt am Ende dieses Abschnitts.

CXmppHandler

In dieser Klasse ist die Interrupt-Logik implementiert. Nach dem Empfang einer

XMPP-Stanza oder bei Verbindungsverlust, wird in dieser Klasse ein Interrupt aus-

gelöst. Der executeComCallback()-Interrupt-Handler sendet ein Event zum

FB. Dieser ruft die processInterrupt()-Methode der untersten Netzwerk-

Schicht, in diesem Fall die XMPP-Netzwerk-Schicht, auf.

Der Verbindungsaufbau kann mit oder ohne TLS-Verschlüsselung erfolgen. Diese kann über

den ersten Parameter der ID des NT-FBs eingestellt werden. Die genaue Beschreibung der

ID erfolgt etwas später. Der Wert 0 bedeutet „keine Verschlüsselung“ und der Wert 1 „TLS-

Verschlüsselung“. Wird bei aktivierter TLS-Verschlüsselung diese vom XMPP-Server nicht

angeboten oder schlägt die Zertifikatsprüfung fehl, wird der Verbindungsaufbau abgebro-

chen und ein Fehler zurückgegeben. Erfolgt nach erfolgtem Verbindungsaufbau ein Verlust

der Verbindung, z.B. durch eine Störung im Kommunikationsnetzwerk oder Ausfall des

XMPP-Servers, wird ein Interrupt in der CXmppHandler-Klasse ausgelöst und ein Fehler

zurückgegeben. Die Verbindung wird von der Netzwerk-Schicht nicht automatisch wieder-

hergestellt, sondern muss in der Anwendungslogik erfolgen. Die Implementierung der

XMPP-Schicht wurde kompatibel zur IP-Schicht gehalten. Dies betrifft unter anderem die

Implementierung des Verbindungsverlusts, das Verhalten der Client-Server Verbindung,

Implementierung 90

wenn der Server offline ist, und die Fehlerbehandlung beim Senden und Empfangen von

Nachrichten.

Als Kommunikationsarten werden Publish-Subscribe und Client-Server unterstützt.

Publish-Subscribe:

Diese Kommunikationsart wird mit XMPP-Stanzas vom Typ Presence realisiert. Die Stan-

zas werden vom Publisher an seine Subscriber gesendet.

Beim Verbindungsaufbau des Subscribers, sendet dieser eine Subscribtion-Anfrage an den

Publisher. Der Publisher akzeptiert diese und beide XMPP-Knoten fügen den Partner zu

ihrer Kontaktliste (Rooster) hinzu. Die Subscription wird vom Publisher zum Subscriber

abgeschlossen. Um das Versenden von XMPP-Stanzas an veraltete Subscriber zu verhin-

dern, werden beim Verbindungsaufbau des Publishers und der Subscriber alle Kontakte in

ihrem Rooster gelöscht. Um zu verhindern, dass bei einem Neustart des Publishers auch

aktive Subscriber gelöscht werden bekommen diese eine Unsubscribe Information übermit-

telt. Die Subscriber senden in diesem Fall eine neue Subscribtion-Anfrage. Für den Fall, dass

der Subscriber vor dem Publisher die Verbindung herstellt, werden die Subscription-Anfra-

gen vom XMPP-Server gespeichert und nach Verbindungsaufbau des Publishers übermittelt.

Die ID zur Konfiguration des PUBLISH_X FBs wird im folgenden Format angegeben:

xmpp[Verschlüsselung:Publisher-Full-JID:Passwort:XMPP-Server-

IP-Adresse]

Beispiel: xmpp[1:netop@localhost/res:its:192.168.1.210]

Die ID zur Konfiguration des SUBSCRIBE_X FBs wird im folgenden Format angegeben:

xmpp[Verschlüsselung:Subscriber-Full-JID:Passwort:XMPP-

Server-IP-Adresse, Publisher-Full-JID]

Beispiel: xmpp[1:cemdsm@localhost/res:its:192.168.1.210:

netop@localhost/res]

Client-Server:

Diese Kommunikationsart kann mit XMPP-Stanzas vom Typ Message und IQ realisiert wer-

den. Der Message-Typ bietet den Vorteil, dass diese am Server gespeichert werden, falls der

Empfänger offline ist. Dies birgt aber auch die Gefahr, dass der Empfangsknoten eine nicht

mehr aktuelle Nachricht empfängt. Ein Nachteil vom Message-Typ ist, dass Nachrichten

Implementierung 91

nicht beantwortet werden müssen. Eine Beantwortung einer Anfrage ist aber bei der Client-

Server Verbindung zwingend erforderlich. IQ bietet den Vorteil, dass dieser Stanza-Typ be-

antwortet werden muss. IQ-Stanzas werden, wenn der Empfänger offline ist, nicht am Server

gespeichert, sondern vom Server mit einem Fehler retourniert. Da der IQ-Typ den Anforde-

rungen der Client-Server-Verbindung am besten entspricht wurde dieser Stanza-Typ für die

Implementierung ausgewählt. Für diese Kommunikationsform ist das Hinzufügen des Kom-

munikationspartners zum Rooster nicht notwendig, da ein Nachrichtenaustausch auch ohne

gültiger Subscription möglich ist. Der Client kann mit dem Server nur Nachrichten austau-

schen, wenn dieser online ist. Ist der Server offline, wird die Client-Verbindung getrennt und

ein Fehler ausgegeben.

Die ID zur Konfiguration des SERVER_X_Y FBs wird im folgenden Format angegeben:

xmpp[Verschlüsselung:Server-Full-JID:Passwort:XMPP-Server-IP-

Adresse: Client-Full-JID]

Beispiel: xmpp[1:cemlm@localhost/res:its:192.168.1.210:

display@localhost/res]

Die Angabe der Client-JID wäre nicht zwingend erforderlich, da diese in der eingehenden

XMPP-Stanza enthalten ist. Um zu verhindern, dass ein nicht berechtigter Client mit dem

Server kommuniziert, werden nur XMPP-Stanzas verarbeitet, die von der angegebenen Cli-

ent-JID stammen, alle anderen Stanzas werden mit einer Fehlermeldung retourniert. Dazu

ist es erforderlich, dass die Integrität der XMPP-Nachricht vom XMPP-Server sichergestellt

wird.

Die ID zur Konfiguration des CLIENT_Y_X FBs wird im folgenden Format angegeben:

xmpp[Verschlüsselung:Client-Full-JID:Passwort:XMPP-Server-IP-

Adresse: Server-Full-JID]

Beispiel: xmpp[1:display@localhost/res:its:192.168.1.210:

cemlm@localhost/res]

Der Nachrichteninhalt, also die zu übertragenden Werte, werden innerhalb eines eigenen

XML Namensraums übertragen. Dies hat den Vorteil, dass der Aufbau der XML-Elemente

fix definiert ist und somit der Versender die Nachricht eindeutig erstellen und der Empfänger

diese wieder eindeutig interpretieren kann. Der Namensraum und auch der einleitende XML-

Tag lauten forte. Der Nachrichteninhalt wird im Unterelement value als Zeichenkette

eingefügt. Der Namensraum wird durch die Klasse CXmppExtension implementiert und

Implementierung 92

für Presence- und IQ-Stanzas verwendet. Ein Beispiel einer Presence-Stanza ist in Listing

12 dargestellt.

<presence from='netop@localhost/res' xmlns='jabber:client'>

<priority>0</priority>

<forte xmlns='forte'>

<Value>QEBA</Value>

</forte>

<c xmlns='http://jabber.org/protocol/caps' hash='sha-1'

node='http://camaya.net/gloox'

ver='1LpOuB49QCQE6BcZoAF5tBoALdg='/>

</presence>

Listing 12: XMPP-Presence-Stanza mit XML-Namensraum forte

Die XMPP-Kommunikation wurde so implementiert, dass diese die zu übertragenden nicht

direkt vom FB lesen bzw. empfangenen Werte nicht direkt zum FB schreiben kann. Es wird

eine darüber liegende Schicht benötigt, die die Daten vom FB liest und in einem allgemeinen

Austauschformat zur Verfügung stellt bzw. die empfangenen Daten dekodiert und zum FB

schreibt. Als Austauschformat würden sich XML oder Binärdaten eignen. Da die bereits in

4DIAC vorhandene ASN.1 Kodierung Binärdaten als Austauschformat verwendet, wird die-

ses Austauschformat auch für die XMPP-Implementierung verwendet.

Die von der darüber liegenden Schicht empfangenen Binärdaten können nicht direkt als

XMPP-Stanza versendet werden. Ein XMPP-Stanza entspricht einem XML-Dokument, wel-

ches nur Zeichen beinhalten kann. Daher werden die empfangenen Binärdaten Base64-ko-

diert. Für die Kodierung werden die Base64-Funktionen der gloox-Bibliothek verwendet.

Beim Empfang einer XMPP-Nachricht muss der Wert, vor der Übergabe an die darüber lie-

gende Schicht, wieder Base64-dekodiert werden. Die Base64 Kodierung hätte auch als ei-

gene Schicht implementiert werden können. Da diese Funktionalität bereits von der gloox-

Bibliothek zur Verfügung gestellt wird und es sich nur um einen Methodenaufruf handelt,

wurde bewusst darauf verzichtet.

In den vorherigen Abschnitten wurden die Implementierung der XMPP-Schicht und der in-

terne Aufbau der Kommunikations-Architektur beschrieben. Im nächsten Abschnitt wird die

XMPP-Kommunikation für die Implementierung der zwei Test Cases verwendet.

Implementierung 93

9.2 Anwendungslogik

Die Anwendungslogik wurde in zwei unabhängige Programme aufgeteilt und auf drei Sys-

teme verteilt, siehe Abbildung 25.

Netzbetreiber DisplayCEM

Demand Side Management

Demand Side Management

Load Display Load Display

Demand Side Management Display

Abbildung 25: Verteilte Anwendungslogik

Die Testanwendung „Demand Side Management“ dient zur Ausführung des TC1 „Demand-

Side-Management mittels Stromspeicher“, siehe Abschnitt 7.2.1. Die Testanwendung „Dis-

play“ dient zur Ausführung des TC2 „Erinnerungsfunktion“, siehe Abschnitt 7.2.2. Die An-

wendungen werden völlig unabhängig voneinander in verschiedenen Geräte-Ressourcen

ausgeführt. Das bietet den Vorteil, dass die Anwendungen unabhängig voneinander auf das

Gerät geladen, gestartet, gestoppt oder modifiziert werden können ohne dass andere Anwen-

dungen davon beeinflusst werden. Die in Abschnitt 7.1 beschriebenen Testplatinen für die

Simulation von Stromnetz, Stromspeicher und Verbraucher werden über die GPIO Pins mit

den Raspberry Pis verbunden, siehe Abbildung 26 im Anhang.

Der Netzbetreiber besitzt eine Ressource mit dem Namen „Demand Side Management“

und in dieser wird ein Teil der Anwendung „Demand Side Management“ ausgeführt, siehe

auch linker Teil der Abbildung 20.

Das CEM besitzt zwei Ressourcen. Die erste trägt den Namen „Demand Side Management“

und in dieser wird der zweite Teil der Anwendung „Demand Side Management“ ausgeführt,

siehe auch rechter Teil der Abbildung 20. Die zweite Ressource trägt den Namen „Load

Display“ und in dieser wird ein Teil der Anwendung „Display“ ausgeführt, siehe auch linker

Teil der Abbildung 21.

Das Display besitzt eine Ressource mit dem Namen „Load Display“ und in dieser wird der

zweite Teil der Anwendung „Display“ ausgeführt, siehe auch rechter Teil der Abbildung 21.

Validierung 94

10 Validierung

Nachdem im letzten Kapitel die Implementierung der XMPP-Kommunikation und der Tes-

tanwendungen beschrieben wurde, werden in diesem Kapitel die Test Cases ausgeführt und

die Implementierung auf die Erfüllung der Anforderungen getestet. Die Test Cases können

mithilfe der Taster und LEDs auf den Testplatinen, siehe Abschnitt 7.1, ausgeführt werden.

10.1 TC1 - Demand-Side-Management mittels Stromspeicher

TC1 kann über die Taster und LEDs auf der Testplatine des Netzbetreibers und die LEDs

auf der Testplatine des CEMs getestet werden. Die durchgeführten Schritte zur Ausführung

des Test Cases sind in Tabelle 9 zu finden.

Vorbedingungen Der Netzstatus wird durch Betätigung des mittleren Tasters auf

der Testplatine des Netzbetreibers auf Normalspannung einge-

stellt.

Die grüne LED auf der Testplatine des Netzbetreibers leuchtet

und signalisiert Normalspannung.

Die grüne und die rote LED auf der Testplatine des CEMs

leuchten nicht, da bei Normalspannung kein Lade- bzw. Ent-

ladevorgang aktiv ist.

Die gelbe LED auf der Testplatine des CEMs wird für TC2 ver-

wendet und hat auf diesen TC keinen Einfluss.

Essentielle Schritte Der Netzstatus wird durch Betätigung des oberen Tasters auf

der Testplatine des Netzbetreibers auf Überspannung einge-

stellt.

Die grüne LED auf der Testplatine des Netzbetreibers erlischt

und die rote LED leuchtet auf. Dies signalisiert Überspannung.

Auf der Testplatine des CEMs leuchtet die rote LED und signa-

lisiert, dass der Stromspeicher geladen wird.

Der Netzstatus wird durch Betätigung des unteren Tasters auf

der Testplatine des Netzbetreibers auf Unterspannung einge-

stellt.

Validierung 95

Die rote LED auf der Testplatine des Netzbetreibers erlischt und

die gelbe LED leuchtet auf. Dies signalisiert Unterspannung.

Auf der Testplatine des CEMs erlischt die rote LED und die

grüne LED leuchtet auf. Dies signalisiert, dass der Stromspei-

cher entladen wird.

Der Netzstatus wird durch Betätigung des mittleren Tasters auf

der Testplatine des Netzbetreibers auf Normalspannung einge-

stellt.

Die gelbe LED auf der Testplatine des Netzbetreibers erlischt

und die grüne LED leuchtet auf. Dies signalisiert Normalspan-

nung.

Auf der Testplatine des CEMs erlischt die grüne LED. Dies sig-

nalisiert, dass der Stromspeicher weder geladen, noch entladen

wird.

Nachbedingungen Die grüne LED auf der Testplatine des Netzbetreibers leuchtet

und signalisiert Normalspannung.

Die grüne und die rote LED auf der Testplatine des CEMs

leuchten nicht, da bei Normalspannung kein Lade- bzw. Ent-

ladevorgang aktiv ist.

Tabelle 9: Validierung TC1 - Demand-Side-Management mittels Stromspeicher

Mit der Ausführung des Test Cases wird die Implementierung auf die Erfüllung der Anfor-

derungen an das Programmiersystem und Kommunikationsprotokoll getestet. Nachfolgend

werden die Ergebnisse der einzelnen Anforderungen begründet und in einem Gesamtfazit

zusammengefasst:

REQ01 - Das Programmiersystem muss die Entwicklung von verteilten Anwendungen

unterstützen.

Die Anwendungsentwicklung erfolgt in der IEC 61499 bzw. 4DIAC im ersten Schritt

komplett systemunabhängig. Die einzelnen FBe der fertigen Anwendung werden im

zweiten Schritt auf die einzelnen Systeme verteilt.

REQ02 - Die Entwicklung von Anwendungen muss auf eine sehr einfache Art und Weise

möglich sein.

Validierung 96

Anwendungen werden in 4DIAC mit FBNen, siehe Abschnitte 3.1.3 und 3.2.2, imple-

mentiert. Der Anwender benötigt dazu keine Kenntnisse einer höheren Programmier-

sprache. Die Programmierung erfolgt durch das Kombinieren und Verbinden der einzel-

nen FBe zu FBNen.

REQ03 - Die Performance der Laufzeitumgebung muss für die Ausführung der Anwen-

dungsfälle ausreichend sein.

Die Ausführung war prinzipiell möglich, eine genauere Performancemessung erfolgt in

Abschnitt 11.3.


sein.

Die modulare Kommunikationsarchitektur von 4DIAC lässt sich jederzeit um neue

Schichten erweitern bzw. lassen sich die Netzwerk-Schichten beliebig kombinieren.

REQ11 - Das Hinzufügen von neuen Knoten muss sehr einfach erfolgen, am besten

durch „Plug & Play“.

Neue Knoten, in diesem Test Case CEM-Systeme als Subscriber, lassen sich jederzeit

hinzufügen und registrieren sich, nach erfolgter Konfiguration der ID des NET-FBs,

selbstständig beim Publisher.


Die XMPP-Schicht wurde so implementiert, dass jeder beliebige Binär-Datenstrom

übertragen werden kann, Details siehe Abschnitt 9.1.3. Die vorgelagerte Schicht zum

Kodieren der Daten in einen Binär-Datenstrom (z.B. ASN.1) kann frei gewählt werden.

REQ13 - Das Protokoll muss asynchrone Kommunikation (Push oder Publish-Sub-

scribe) unterstützen.

Die Kommunikation bei diesem Test Case erfolgt über die Kommunikationsart Publish-

Subscribe über XMPP-Presence-Stanzas. Die XMPP-Stanzas werden vom Publisher bei

Bedarf versendet. Der Subscriber muss sich einmalig beim Publisher für den Empfang

registrieren.

REQ15 - Das Protokoll muss eine zeitgemäße Verschlüsselung unterstützen.

Die XMPP-Schicht wurde so implementiert, dass die von XMPP angebotene TLS-Ver-

schlüsselung über die ID des NET-FBs aktiviert werden kann.

REQ16 - Das Protokoll muss die Möglichkeit zur Authentifizierung bereitstellen.

Validierung 97

Ein XMPP-Client kann erst nach erfolgter Authentifizierung beim XMPP-Server Nach-

richten versenden. Die Authentifizierung des XMPP-Clients erfolgt durch seine JID und

seinem Passwort beim XMPP-Server.

REQ17 - Das Protokoll muss lokale und entfernte Ziele (Internet) erreichen können (rou-

tbares Protokoll).

XMPP nutzt als Transportprotokoll TCP/IP und ist daher prinzipiell routbar. Da die der-

zeitige Implementierung auf ein DNS verzichtet und als Host den localhost verwendet,

ist diese nicht routbar und nur im lokalen Netzwerk verwendbar. Die Implementierung

kann aber jederzeit um ein DNS erweitert werden.

REQ18 - Die Performance des Protokolls muss für die Ausführung der Anwendungsfälle

ausreichend sein.

Die Ausführung war prinzipiell möglich, eine genauere Performancemessung erfolgt in

Abschnitt 11.1.


Anforderung Ergebnis

REQ01 √

REQ02 √

REQ03 o1

REQ05 √

REQ11 √

REQ12 √

REQ13 √

REQ15 √

REQ16 √

REQ17 √

REQ18 o1

1 Ausführlicher Test erfolgt in Kapitel 11

Tabelle 10: Fazit TC1 - Demand-Side-Management mittels Stromspeicher

Validierung 98

Mit diesem Test Case wurden vier Anforderungen an das Programmiersystem und sieben

Anforderungen an das Kommunikationsprotokoll getestet. Neun der Anforderungen werden

erfüllt und bei zwei Anforderungen sind noch weitere Tests notwendig, um eine fundierte

Bewertung durchführen zu können. Diese beiden Anforderungen werden in Kapitel 11 noch

detaillierter analysiert.

10.2 TC2 – Erinnerungsfunktion

TC2 kann über den Taster und der LED auf der Testplatine des CEMs und der LED auf der

Testplatine des Displays getestet werden. Die durchgeführten Schritte zur Ausführung des

Test Cases sind in Tabelle 11 zu finden.

Vorbedingungen Die gelbe LED auf der Testplatine des CEMs leuchtet nicht und

signalisiert, dass der Verbraucher ausgeschaltet ist.

Die rote und die grüne LED auf der Testplatine des CEMs wer-

den für TC1 verwendet und haben auf diesen TC keinen Ein-

fluss.

Die gelbe LED auf der Testplatine des Displays leuchtet nicht

und signalisiert, dass der Verbraucher ausgeschaltet ist.

Essentielle Schritte Der Verbraucher wird durch Betätigung des Tasters auf der

Testplatine des CEMs eingeschaltet.

Die gelbe LED auf der Testplatine des CEMs leuchtet und sig-

nalisiert, dass der Verbraucher eingeschaltet ist.

Auf der Testplatine des Displays leuchtet nach einer maximalen

Verzögerung von einer Sekunde die gelbe LED und signalisiert,

dass der Verbraucher eingeschaltet ist.

Der Verbraucher wird durch Betätigung des Tasters auf der

Testplatine des CEMs ausgeschaltet.

Die gelbe LED auf der Testplatine des CEMs erlischt und sig-

nalisiert, dass der Verbraucher ausgeschaltet ist.

Validierung 99

Auf der Testplatine des Displays erlischt nach einer maximalen

Verzögerung von einer Sekunde die gelbe LED und signalisiert,

dass der Verbraucher ausgeschaltet ist.

Nachbedingungen Die gelbe LED auf der Testplatine des CEMs leuchtet nicht und

signalisiert, dass der Verbraucher ausgeschaltet ist.

Die gelbe LED auf der Testplatine des Displays leuchtet nicht

und signalisiert, dass der Verbraucher ausgeschaltet ist.

Tabelle 11: Validierung TC2 - Erinnerungsfunktion

Mit der Ausführung des Test Cases wird die Implementierung auf die Erfüllung der Anfor-

derungen an das Programmiersystem und Kommunikationsprotokoll getestet. Nachfolgend

werden die Ergebnisse der einzelnen Anforderungen begründet und in einem Gesamtfazit

zusammengefasst:

REQ01 - Das Programmiersystem muss die Entwicklung von verteilten Anwendungen

unterstützen.

Siehe Abschnitt 10.1.

REQ02 - Die Entwicklung von Anwendungen muss auf eine sehr einfache Art und Weise

möglich sein.



sein.




REQ14 - Das Protokoll muss eine synchrone Kommunikation unterstützen.

Die Kommunikation bei diesem Test Case erfolgt über die Kommunikationsart Client-

Server über XMPP-IQ-Stanzas. Der Client, in diesem Fall das Display, sendet in regel-

mäßigen Abständen (1 Sekunde) eine Anfrage an den Server. Der Server antwortet mit

dem aktuellen Status.


Validierung 100

Anforderung Ergebnis

REQ01 √

REQ02 √

REQ05 √

REQ11 √

REQ12 √

REQ14 √

Tabelle 12: Fazit TC2 – Erinnerungsfunktion

Mit diesem Test Case wurden drei Anforderungen an das Programmiersystem und drei An-

forderungen an das Kommunikationsprotokoll getestet. Alle Anforderungen werden erfüllt.

Evaluierung 101

11 Evaluierung

In diesem Kapitel werden verschiedene Evaluierungstests an der Implementierung durchge-

führt. Im ersten Abschnitt wird die Reaktionszeit bei der Kommunikationsart Publish-Sub-

scribe, im zweiten Abschnitt die Nachrichtengröße bei Publish-Subscribe und Client-Server

und im dritten Abschnitt die Systemauslastung der einzelnen Systeme ermittelt.

Bei der Ausführung der Evaluierungstests ist es zu mehrfachen Abstürzen von FORTE am

CEM mit folgender Fehlermeldung gekommen:

terminate called after throwing an instance of

'std::length_error'

what(): basic_string::_S_create

Der Zeitpunkt des Auftretens der Fehlermeldung war sehr unterschiedlich. Der Fehler kann

bereits nach wenigen Minuten oder auch erst nach einigen Tagen auftreten. Aus den Debug-

Meldungen war außerdem zu erkennen, dass das Fehlverhalten beim Empfang von Daten

des Server-FBs (Client-Server Verbindung zwischen Display und CEM) aufgetreten ist. Da-

her kann ziemlich sicher ausgeschlossen werden, dass dieser Fehler mit dem in Abschnitt

11.3 festgestellten Speicherzuwachs bei einer Publish-Subscribe-Verbindung zusammen-

hängen könnte. Außerdem konnte festgestellt werden, dass die ASN.1 Schicht einen „Data-

type error“ meldet. Von daher ist eher davon auszugehen, dass ein unvollständiges oder feh-

lerhaftes Datenpaket empfangen wurde und dieser Fehlerfall in der Empfangsroutine nicht

ausreichend berücksichtigt wurde.

11.1 Reaktionszeit Publish-Subscribe

Die Kommunikationsart Publish-Subscribe wird beim Testaufbau für Demand-Side-Ma-

nagement verwendet. Daher muss die Benachrichtigung der Subscriber ohne einer großen

Zeitverzögerung erfolgen. Die Messung wurde mit einem digitalen Oszilloskop für die Über-

tragungsarten XMPP verschlüsselt (TLS), XMPP unverschlüsselt und UDP (FORTE Stan-

dardprotokoll) durchgeführt, siehe Tabelle 13. Dazu wurde mit dem ersten Kanal die Span-

nung des Überspannungs-LEDs am Netzbetreiber und mit dem zweiten Kanal die Spannung

des Lade-LEDs des Stromspeichers am CEM gemessen. Es wurden jeweils mehrere Mes-

sungen durchgeführt und der Mittelwert verwendet. Die Oszilloskop-Bilder sind im Anhang

in Abbildung 27 bis Abbildung 29 zu finden.

Evaluierung 102

Protokoll Verzögerungszeit [ms]

XMPP verschlüsselt 25

XMPP unverschlüsselt 21

UDP 3

Tabelle 13: Zeitverzögerung Publish-Subscribe

An den Messergebnissen ist zu erkennen, dass die TLS-Verschlüsselung die Übertragung

um 4 ms verzögert. Dies ist auf die zusätzliche Rechenzeit für die Ver- und Entschlüsselung

und die Komprimierung, siehe nächster Abschnitt, der Nachricht zurückzuführen. Eine un-

verschlüsselte UDP-Verbindung ist im Vergleich zur unverschlüsselten XMPP-Verbindung

um 18 ms schneller. Dies lässt sich durch den Protokoll-Overhead von TCP und XMPP er-

klären. Bei den Messergebnissen muss berücksichtigt werden, dass diese unter Laborbedin-

gungen ermittelt wurden. Die Systeme waren über einen Switch mit einem jeweils ein Meter

langen Netzwerkkabel miteinander verbunden. Zur Verbesserung der Reaktionszeit für De-

mand-Side-Management wäre es sinnvoll, eine Validierung von XMPP über UDP durchzu-

führen.

11.2 Nachrichtengröße

In diesem Abschnitt wird die Nachrichtengröße für die Kommunikationsarten Publish-Sub-

scribe, siehe Tabelle 14, und Client-Server, siehe Tabelle 15, ermittelt. Bei beiden Kommu-

nikationsarten wurden die Protokolle XMPP verschlüsselt (TLS), XMPP unverschlüsselt

und UDP bzw. TCP analysiert. Als Paketgröße wird die Summe aller Nachrichten, die für

den Austausch eines Variablenwertes notwendig sind, bezeichnet. Bei der Client-Server-

Verbindung entspricht die Paketgröße dem Senden der Anfrage an den Server, der Antwort

des Servers und der Empfangsbestätigung (Acknowledge) des Clients an den Server. Die

Pakete, die zum Aufbau der XMPP-Verbindung notwendig sind, wurden nicht berücksich-

tigt. Die Messungen wurden mit dem Netzwerk-Sniffer Wireshark durchgeführt. Die Auf-

zeichnungen sind im Anhang in Abbildung 30 bis Abbildung 35 zu finden.

Protokoll Paketgröße [Byte]



Evaluierung 103


UDP 45

Tabelle 14: Nachrichtengröße Publish-Subscribe




TCP 202

Tabelle 15: Nachrichtengröße Client-Server

An den Paketgrößen ist zu erkennen, dass diese bei einer verschlüsselten XMPP-Verbindung

wesentlich kleiner sind als bei einer unverschlüsselten. Dies liegt daran, dass die gloox-

Library bei einer TLS-Verbindung automatisch die zlib-Komprimierung von OpenSSL ak-

tiviert (zu finden in Zeile 54 von tlsopensslbase.cpp). Ohne Komprimierung würde eine ver-

schlüsselte XMPP-Nachricht, im Vergleich zu einer unverschlüsselten, einen größeren

Overhead haben. Daher ist der Vergleich der unverschlüsselten XMPP-Nachricht mit UDP

bzw. TCP aussagekräftiger. Bei Publish-Subscribe ist die XMPP-Nachricht ca. 16,5-mal

größer als die UDP-Nachricht, bei Client-Server ist die XMPP-Nachricht ca. 2,7-mal größer

als die TCP-Nachricht. Durch Verwendung der zlib-Komprimierung ist eine verschlüsselte

XMPP Nachricht ca. 7,7-mal größer als UDP und ca. 1,9-mal größer als TCP. Daher wäre

es sinnvoll, wie auch bereits im vorherigen Abschnitt erwähnt, eine Validierung von XMPP

über UDP durchzuführen und die XMPP-Nachricht zu komprimieren. Die Komprimierung

kann z.B. über die OpenSSL Komprimierung oder durch Verwendung von Binary XML

erfolgen. Dabei ist aber zu beachten, dass die zusätzliche CPU-Zeit, die für die Komprimie-

rung benötigt wird, die Verzögerungszeit bei Publish-Subscribe verschlechtern kann.

11.3 Systemauslastung

Da es sich bei der verwendeten Hardware um Einzelplatinencomputer mit wenigen Ressour-

cen handelt, ist die Auslastung von Prozessor und Speicher von besonderer Bedeutung. Aus-

gewertet wurde die Laufzeitumgebung FORTE bei Verwendung von XMPP verschlüsselt

(TLS), XMPP unverschlüsselt und TCP bzw. UDP. Für die Auswertung wurde das Linux

Evaluierung 104

Programm ps verwendet. Die Ergebnisse nach einem Tag Laufzeit wurden in Tabelle 16 bis

Tabelle 18 zusammengefasst.

System Prozessor

[%]

Prozessorzeit

[mm:ss]

Speicher

[%]

Physikalischer

Speicher [KB]

Virtueller

Speicher [KB]

Netzbetreiber 6,0 86:17 10,9 48.872 92.624

CEM 7,9 112:46 11,1 49.780 110.584

Display 4,0 56:52 1,5 6.912 50.040

Tabelle 16: Systemauslastung XMPP mit Verschlüsselung nach einem Tag Laufzeit

System Prozessor

[%]

Prozessorzeit

[mm:ss]

Speicher

[%]

Physikalischer

Speicher [KB]

Virtueller

Speicher [KB]

Netzbetreiber 5,7 82:25 10,5 46.992 91.488

CEM 8,3 119:26 10,5 47.128 108.792

Display 4,6 65:43 1,1 4.980 49.292

Tabelle 17: Systemauslastung XMPP ohne Verschlüsselung nach einem Tag Laufzeit

System Prozessor

[%]

Prozessorzeit

[mm:ss]

Speicher

[%]

Physikalischer

Speicher [KB]

Virtueller

Speicher [KB]

Netzbetreiber 4,8 70:22 0,9 4.084 40.784

CEM 6,8 97:58 0,9 4.328 48.944

Display 4,0 59:36 0,9 4.072 40.704

Tabelle 18: Systemauslastung TCP bzw. UDP nach einem Tag Laufzeit

Die Prozessorauslastung des Netzbetreibers und des CEMs sind bei Verwendung von XMPP

um ca. 1 % höher als bei TCP bzw. UDP. Beim Display ist diese ungefähr gleich. Interessant

ist auch die Tatsache, dass die Prozessorauslastung scheinbar nur bei Publish-Subscribe

(Netzbetreiber – CEM) höher ist und bei Client-Server (Display, CEM) nur ein geringer

Unterschied feststellbar ist.

Der Speicherverbrauch des Netzbetreibers und des CEMs sind bei Verwendung von XMPP

um ca. 10-mal höher als bei TCP bzw. UDP. Beim Display ist dieser bis zur Hälfte höher.

Um feststellen zu können, ob sich der Speicherverbrauch konstant verhält oder ob dieser

Evaluierung 105

noch weiter anwächst, wurde für XMPP verschlüsselt eine weitere Messung über einen Zeit-

raum von drei Tagen durchgeführt. An den Ergebnissen in Tabelle 19 ist zu erkennen, dass

der Speicherverbrauch beim Netzbetreiber und beim CEM um ca. 10 % pro Tag ansteigt.

Beim Display ist keine große Änderung feststellbar. Scheinbar tritt der Speicherverbrauchs-

zuwachs nur bei der Übertragungsart Publish-Subscribe auf. Da der Programmcode bei bei-

den Verbindungsarten fast identisch ist, ist dieses Fehlverhalten mit größerer Wahrschein-

lichkeit in der gloox-Library zu finden. Dies müsste aber erst durch eine genauere Analyse

belegt werden. Es kann davon ausgegangen werden, dass das System, bei einer Laufzeit von

über 10 Tagen oder bei einer größeren Anwendung, durch die Auslagerung in den virtuellen

Speicher immer langsamer werden und schlussendlich ausfallen wird.

System Prozessor

[%]

Prozessorzeit

[mm:ss]

Speicher

[%]

Physikalischer

Speicher [KB]

Virtueller

Speicher [KB]

Netzbetreiber 5,8 243:30 30,8 137.588 180.816

CEM 6,4 270:52 30,9 138.008 198.176

Display 4,8 202:35 1,6 7.520 50.720

Tabelle 19: Systemauslastung XMPP mit Verschlüsselung nach drei Tagen Laufzeit

Fazit und Ausblick 106

12 Fazit und Ausblick

Für einen hohen Verbreitungsgrad von Smart Home Komponenten am Massenmarkt ist eine

Trendumkehr von proprietären Einzellösungen zu einfach und zentral konfigurierbaren, mo-

dularen Lösungen notwendig. Die größte Hemmschwelle ist das Fehlen von einheitlichen

Programmier- und Kommunikations-Standards für Smart Homes.

Ziel dieser Arbeit war es, vorhandene Programmiernormen und Kommunikationsprotokolle

für den Einsatz in Smart Homes zu validieren. Der erste Schritt war eine Anforderungsana-

lyse in Kapitel 2. In diesem Kapitel wurden typische Anwendungsfälle von Smart Home

Lösungen analysiert und davon die Anforderungen an das Programmiersystem und das

Kommunikationsprotokoll abgeleitet. Zusätzlich wurden Testszenarien entwickelt, um die

Programmiernormen und Kommunikationsprotokolle auf die Erfüllung der Anforderungen

testen zu können.

Im dritten Kapitel wurden vorhandene Normen für speicherprogrammierbare Steuerungen

beschrieben. Analysiert wurden die in der Industrie etablierte IEC 61131 und deren Nach-

folger, die IEC 61499. In Abschnitt 6.1 wurden die beiden Normen hinsichtlich der Erfüllung

der in Abschnitt 2.2.1 definierten Anforderungen bewertet. Grundsätzlich erfüllen beide

Normen die Anforderungen, die IEC 61499 bietet aber den Vorteil, dass diese speziell für

die Erstellung von verteilten Anwendungen konzipiert wurde. Daher wurde diese Norm als

Programmiersystem für den Testaufbau ausgewählt.

In Kapitel 4 erfolgte die Beschreibung von Kommunikationsprotokollen. Hier wurde auf

webbasierte Protokolle zurückgegriffen, da sich diese für die Kommunikation zwischen he-

terogenen Systemen bewährt und etabliert haben. Analysiert wurden SOAP, REST, WebSo-

cket und XMPP. In Abschnitt 6.2 erfolgte wiederrum eine Bewertung hinsichtlich der Erfül-

lung der in Abschnitt 2.2.2 definierten Anforderungen. Diese werden von XMPP am besten

abgedeckt, da dieses Protokoll viele Funktionen, wie z.B. Verschlüsselung und Authentifi-

zierung, ohne eine Erweiterung oder ein zusätzliches Protokoll unterstützt und einfach er-

weitert werden kann. Daher wurde dieses Protokoll als Kommunikationsprotokoll für den

Testaufbau ausgewählt.

Im fünften Kapitel wurden Kodierungsverfahren vorgestellt, die bei Web Services häufig

verwendet werden. Zum einen ist dies ASN.1, ein Kodierungsverfahren für die Übertragung


von Datenstrukturen zwischen heterogenen Systemen, zum anderen Base64, ein Kodie-

rungsverfahren zur Konvertierung von Binärdaten in ASCII-Zeichen. In Abschnitt 6.3 er-

folgte eine Begründung, wieso und unter welchen Bedingungen diese beiden Kodierungs-

verfahren bei der Verwendung von IEC 61499 in Kombination mit XMPP verwendet wer-

den.

In den nächsten Kapiteln erfolgte die Beschreibung des Testaufbaus. In Kapitel 7 wurde die

System-Architektur des Testaufbaus und die Software-Architektur der Testanwendungen

beschrieben. Im darauffolgenden Kapitel erfolgte die Auswahl der Hard- und Softwarekom-

ponenten. Für den Testaufbau wurden Raspberry Pis und als Entwicklungsumgebung

4DIAC ausgewählt. Für die XMPP-Kommunikation wurden die gloox-Library und der ejab-

berd XMPP-Server eingesetzt. Eine detaillierte Beschreibung der Implementierung der

XMPP-Kommunikation in der IEC 61499 Laufzeitumgebung FORTE und der Anwendungs-

logik für die Testfälle erfolgte in Kapitel 9.

Kapitel 10 widmet sich der Validierung des Testaufbaus und der Ausführung beider Test

Cases. Die Ausführung der Test Cases wurde detailliert dokumentiert und die einzelnen An-

forderungen, die mit den Testfällen getestet wurden, Punkt für Punkt bewertet. Alle Anfor-

derungen, die an das Programmiersystem und Kommunikationsprotokoll gestellt wurden,

konnten erfüllt werden. Die Performanceanforderungen konnten mit dem Ausführen der

Testfälle nicht tiefgründig genug bewertet werden. Diese Bewertung erfolgte bei der Evalu-

ierung des Testaufbaus in Kapitel 11. In diesem Kapitel wurden die Reaktionszeit bei Pub-

lish-Subscribe, die Nachrichtengröße bei den verschiedenen Kommunikationsarten und die

Systemauslastung analysiert. Die Evaluierung zeigte durchaus sehr positive Ergebnisse, aber

auch Spielraum für Erweiterungen und Optimierungen.

Für einen produktiven Einsatz des Testaufbaus ist es unbedingt notwendig, die in Kapitel 11

festgestellten Abstürze von FORTE am CEM und den in Abschnitt 11.3 festgestellten Spei-

cherzuwachs bei Publish-Subscribe näher zu untersuchen.

Bei der Architektur des Testaufbaus wäre es von großem Vorteil, ein DNS einzusetzen. Da-

mit wären die XMPP-Clients auch aus dem Internet erreichbar und statt den Testplatinen

könnten reelle Werte, z.B. Netzzustandsdaten vom Netzbetreiber, verwendet werden. Dafür

wäre auch ein einheitliches Datenaustauschformat sinnvoll. Bevor der Testaufbau von außen

erreichbar gemacht wird, sollte dieser noch einer Sicherheitsüberprüfung unterzogen wer-


den. Es wird derzeit zwar eine TLS-Verschlüsselung verwendet, diese basiert aber auf Test-

zertifikaten, welche durch echte Zertifikate ersetzt werden müssten. Auch die Zertifikatsprü-

fung bei den Clients müsste erst implementiert werden. Derzeit werden nur die Zertifikats-

details im Debugmodus auf der Konsole ausgegeben und jedes Zertifikat akzeptiert.

Eine weitere Optimierungsmöglichkeit stellt die Übermittelung der XMPP-Passwörter der

Clients dar. Diese stehen unverschlüsselt in den ID-Werten der NET-FBen. Diese ID wird

unverschlüsselt von der Entwicklungsumgebung zur Laufzeitumgebung übertragen bzw. un-

verschlüsselt in den FORTE-Bootfiles gespeichert. Hier wäre eine verschlüsselte Definition

des XMPP-Passwortes in der ID sinnvoll.

Weitere Optimierungsmöglichkeiten bestehen bei der Performance der Datenübertragung.

Zur Verbesserung der Reaktionszeit und zur Verminderung des Overheads wäre eine Vali-

dierung von XMPP über UDP sehr interessant. Zusätzlich wäre eine Prüfung von Kompri-

mierungsverfahren wie z.B. Binary XML oder SSL-Komprimierungsverfahren empfehlens-

wert. Hier ist jedoch zu beachten, dass Komprimierungsverfahren, durch die zusätzlich be-

nötigte CPU-Zeit, die Übertragung auch verzögern könnten. Bei der Publish-Subscribe Ver-

bindung zwischen Netzbetreiber und CEM werden derzeit in jedem Abfragezyklus der Tas-

ter die Netzstatus-Werte an die Subscriber übertragen. Hier wäre eine Erweiterung, damit

die Daten nur bei einer Veränderung gesendet werden, sehr sinnvoll.

Eine weitere Erweiterungsmöglichkeit steckt in der Client-Server Verbindung. Derzeit wer-

den nur 1:1 Verbindungen unterstützt. Mit XMPP als Kommunikationsprotokoll wäre auch

eine n:1 Verbindung realisierbar. Um die Einbindung von neuen Smart Home Komponenten

zu vereinfachen, wäre auch die Implementierung der XMPP-Erweiterung „XEP-0030: Ser-

vice Discovery“ zu empfehlen. Damit wäre eine Einbindung von neuen Komponenten per

„Plug & Play“ möglich. Durch den Austausch von Features könnten die Clients ihre Kom-

munikationspartner selbst finden. Somit könnte die manuelle Initialkonfiguration entfallen.

Im Zuge dieser Arbeit wurde vom Display bei der Eingangstür als performanceschwächste

Komponente ausgegangen. In einem Smart Home gibt es noch weit kleinere Geräte, wie z.B.

Lichtschalter, die den benötigten Strom nur durch das Drücken des Tasters erzeugen. In die-

sem Bereich wäre eine Analyse interessant, ob dieser kurze Stromimpuls zum Aufbau einer

XMPP-Verbindung und zum Versenden der Daten ausreichend ist bzw. ob diese Geräte als

Legacy Geräte angebunden werden müssten oder ob eine Programmierung über IEC 61499

möglich wäre.


Die Validierung von Programmiernormen und Kommunikationsprotokollen hat gezeigt,

dass mehrere Normen und Protokolle die definierten Anforderungen ganz oder zum größten

Teil erfüllen. Die IEC 61499 erfüllt alle definierten Anforderungen an das Programmiersys-

tem vollständig. Das XMPP-Protokoll erfüllt den Großteil der definierten Anforderungen an

das Kommunikationsprotokoll vollständig und zwei Anforderungen teilweise. Mit Erweite-

rungen und Optimierungen könnten alle Anforderungen vollständig erfüllt werden.

Durch die Definition und Implementierung eines Programmier- und Kommunikationsstan-

dards für Smart Homes, könnten die derzeit verfügbaren Insellösungen zu einer auf die per-

sönlichen Bedürfnisse des Anwenders zugeschnittenen Gesamtlösung zusammengefügt

werden. Die Anwender könnten ihre persönliche Smart Home Lösung im Baukastenprinzip

aus Modulen verschiedener Hersteller zusammenbauen. Werden z.B. Netzkenndaten benö-

tigt, müsste der Netzbetreiber lediglich einen FB zur Verfügung stellen, welcher z.B. über

einen App-Store vertrieben werden könnte. Der FB müsste in der Smart Home Applikation

eingefügt und, wenn notwendig, über Eingangsparameter konfiguriert werden. Dasselbe

Prinzip könnte auch bei der Einbindung von neuen Smart Home Komponenten angewendet

werden.

Der Komponenten-Hersteller könnte bei der Entwicklung von neuen Produkten auf ein ein-

heitliches Programmiersystem und Kommunikationsprotokoll zurückgreifen. Dadurch

könnte sich dieser auf seine Kernkompetenz konzentrieren, z.B. Rollladensteuerung, und für

die restlichen Anwendungsfälle auf Produkte eines anderen Herstellers, z.B. Heizungsrege-

lung, zurückgreifen. Durch die Interoperabilität zwischen den verschiedenen Herstellern

würde für die Endanwender in kürzester Zeit ein breites Angebot an Smart Home Kompo-

nenten verfügbar sein. Bereits existierende Smart Home Komponenten könnten eventuell

mit Hilfe von Adapterkomponenten um die Kommunikation über das XMPP-Protokoll er-

weitert und als Legacy-Gerät in das Programmiersystem eingebunden werden. Somit stehen

den Endkunden alle Möglichkeiten offen, um aus vorhandenen und neuen Smart Home

Komponenten ihre individuelle Gesamtlösung zusammenzustellen.

Literaturverzeichnis 110

Literaturverzeichnis

[1] H. Strese, U. Seidel, T. Knape und A. Botthof, “Smart Home in Deutschland,” Insti-

tution für Innovation und Technik (iit) in der VDI/VDE-IT, Berlin, Deutschland,

Mai. 2010.

[2] P. Georgieff, “Ambient Assisted Living: Marktpotenziale IT-unterstützter Pflege für

ein selbstbestimmtes Altern,” MFG Stiftung Baden-Württemberg, Okt. 2008.

[3] R. Glasberg und N. Feldner, “Studienreihe zur Heimvernetzung: Konsumentennutzen

und persönlicher Komfort,” Technische Universität Berlin, Berlin, Deutschland, Okt.

2008.

[4] “Use Cases and Architecture for a Home Energy Management Service,” Home Gate-

way Initiative (HGI), Aug. 2011.

[5] L. Hellmann, Intelligente Vernetzung: Smart-Home-Markt wächst. Verfügbar unter:

http://www.faz.net/asv/smart-home/intelligente-vernetzung-smart-home-markt-

waechst-13182265.html (02.08.2015).

[6] D. Wyllie, Die besten Smart-Home-Lösungen für Einsteiger. Verfügbar unter:

http://www.computerwoche.de/a/die-besten-smart-home-loesungen-fuer-einstei-

ger,2550730 (26.08.2015).

[7] A. Sebayang, So funkt's im Smarthome: Zigbee und Z-Wave. Verfügbar unter:

http://www.golem.de/news/zigbee-und-z-wave-so-funkts-im-smarthome-1502-

111858.html (26.08.2015).

[8] J. Villeneuve, “The Internet of Things,” University of North Texas, Denton, Texas,

Dez. 2014.

[9] Spier Alexander, Google Brillo und Weave: Ein Android fürs Internet der Dinge.

Verfügbar unter: http://www.heise.de/newsticker/meldung/Google-Brillo-und-

Weave-Ein-Android-fuers-Internet-der-Dinge-2670592.html (02.08.2015).

[10] J. Thoma, Smarthomes, offen wie Scheunentore. Verfügbar unter: http://www.go-

lem.de/news/security-smarthomes-offen-wie-scheunentore-1412-111173.html

(02.08.2015).

[11] G. Wagner, Smart-Home-Markt braucht einheitliche Standards. Verfügbar unter:

http://www.faz.net/asv/smart-home/schnittstellenfaehige-systeme-smart-home-

markt-braucht-einheitliche-standards-13322425.html (02.08.2015).

[12] M. Unseld, “Das Smart Home wird 2025 Standard,” Verband der Elektrotechnik,

Elektronik und Informationstechnik (VDE), Mrz. 2013.

[13] S. Zuberer, “Große Wachstumschancen für Smart Home,” PricewaterhouseCoopers

(PwC), Apr. 2015.

[14] M. Hansen und S. Meissner, Hg., Verkettung digitaler Identitäten. Kiel, Deutschland:

Unabhängiges Landeszentrum für Datenschutz Schleswig-Holstein (ULD), 2007.

[15] VDE, “Intelligente Assistenz-Systeme im Dienst für eine reife Gesellschaft,” VDE-

Positionspapier, Verband der Elektrotechnik Elektronik Informationstechnik, Frank-

furt, 2008.


[16] CEN-CENELEC-ETSI Smart Grid Coordination Group, “Smart Grid Reference Ar-

chitecture,” Nov. 2012.

[17] IEC, “Systems interface between customer energy management system and the

power management system - Part 2: Use cases and requirements (IEC 62476-2),” In-

ternational Electrotechnical Commission, Apr. 2015.

[18] Smart Grid Taks Force, “Regulatory Recommendations for the Deployment of Flexi-

bility: EG3 Report,” Jan. 2015.

[19] J. Parra, M. A. Hossain, A. Uribarren, E. Jacob und A. El-Saddik, “Flexible Smart

Home Architecture using Device Profile for Web Services: a Peer-to-Peer Ap-

proach,” in International Journal of Smart Home, Vol. 3, Apr. 2009, S. 39–55.

[20] A. Kamilaris, V. Trifa und A. Pitsillides, “The Smart Home meets the Web of

Things,” in International Journal of Ad Hoc and Ubiquitous Computing archive,

7(3), 2011, S. 145–154.

[21] R. Pickhardt und O. Mildenberger, Grundlagen und Anwendung der Steuerungstech-

nik: Petri-Netze, SPS, Planung. Braunschweig, Deutschland: Vieweg, 2000.

[22] IEC, “Function blocks - Part 1: Architecture (IEC 61499-1),” International Electro-

technical Commission, Nov. 2012.

[23] International Electrotechnical Commission (IEC). Verfügbar unter:

http://www.iec.ch/ (15.04.2015).

[24] IEC, “Programmable controllers – Part 1: General information (IEC 61131-1),” In-

ternational Electrotechnical Commission, Mai. 2003.

[25] IEC, “Programmable controllers – Part 3: Programming languages (IEC 61131-3),”

International Electrotechnical Commission, Feb. 2013.

[26] IEC, “Programmable controllers - Part 5: Communications (IEC 61131-5),” Interna-

tional Electrotechnical Commission, Nov. 2000.

[27] K. Thramboulidis, “Towards an Object-Oriented Extension for IEC 61131,” in 17th

IEEE Conference on Emerging Technologies & Factory Automation (ETFA 2012),

Krakau, Polen, Sep. 2012, S. 1–8.

[28] William Wenbin Dai und Valeriy Vyatkin, “A Case Study on Migration from IEC

61131 PLC to IEC 61499 Function Block Control,” in 7th IEEE International Con-

ference on Industrial Informatics (INDIN 2009), Cardiff, Großbritannien, Jun. 2009,

S. 79–84.

[29] K. Thramboulidis und G. Frey, “Towards a Model-Driven IEC 61131-Based Devel-

opment Process in Industrial Automation,” in Journal of Software Engineering and

Applications, 4(04), 2011, S. 217–226.

[30] A. Zoitl und V. Vyatkin, “IEC 61499 Architecture for Distributed Automation: the

'Glass Half Full' View,” in Industrial Electronics Magazine, 3(4): IEEE, 2009, S. 7–

23.

[31] K. Thramboulidis, “IEC 61499 vs. 61131: A Comparison Based on Misperceptions,”

in Journal of Software Engineering and Applications, 6(08), 2013, S. 405–415.

[32] K. Thramboulidis, “IEC61499 Function Block Model: Facts and Fallacies,” in Indus-

trial Electronics Magazine, 3(4): IEEE, 2009, S. 7–26.


[33] V. Vyatkin, “IEC 61499 as Enabler of Distributed and Intelligent Automation: State-

of-the-Art Review,” in IEEE Transactions on Industrial Informatics, 7(4), 2011, S.

768–781.

[34] K. Thramboulidis und G. Doukas, “IEC61499 Execution Model Semantics,” in Inno-

vative algorithms and techniques in automation, industrial electronics and telecom-

munications, T. Sobh, K. Elleithy, A. Mahmood, and M. Karim, Eds., Dordrecht,

Niederlande: Springer, 2007, S. 223–228.

[35] A. Zoitl, T. Strasser, K. Hall, R. Staron, Sünder Christoph und B. Favre-Bulle, “The

Past, Present, and Future of IEC 61499,” in Third International Conference on In-

dustrial Applications of Holonic and Multi-Agent Systems (HoloMAS 2007), Regens-

burg, Deutschland, Sep. 2007, S. 1–14.

[36] F. Andrén und T. Strasser, “Challenges and Experiences using 4DIAC for Smart

Grid Laboratory Automation: Successful Usage of the 4DIAC Environment,” in 18th

IEEE International Conference on Emerging Technologies and Factory Automation

(ETFA 2013), Cagliari, Italien, Sep. 2013.

[37] K. Wagh und R. Thool, “A Comparative Study of SOAP Vs REST Web Services

Provisioning Techniques for Mobile Host,” in Journal of Information Engineering

and Applications, 2(5), 2012, S. 12–16.

[38] N. Mitra und Y. Lafon, “SOAP Version 1.2 Part 0: Primer (Second Edition) (W3C

Recommendation),” World Wide Web Consortium, Apr. 2007.

[39] M. Gudgin, M. Hadley, N. Mendelsohn, J. J. Moreau, H. F. Nielsen, A. Karmarkar

und Y. Lafon, “SOAP Version 1.2 Part 1: Messaging Framework (Second Edition)

(W3C Recommendation),” World Wide Web Consortium, Apr. 2007.

[40] T. Bray, D. Hollander, A. Layman, R. Tobin und H. S. Thompson, “Namespaces in

XML 1.0 (Third Edition) (W3C Recommendation),” World Wide Web Consortium,

Dez. 2009.

[41] M. Gudgin, M. Hadley, N. Mendelsohn, J. J. Moreau, H. F. Nielsen, A. Karmarkar

und Y. Lafon, “SOAP Version 1.2 Part 2: Adjuncts (Second Edition) (W3C Recom-

mendation),” World Wide Web Consortium, Apr. 2007.

[42] N. Mendelsohn, H. M. Mountain, J. Kopecky, S. Wiliams und G. Daniels, “SOAP

Version 1.2 Email Binding (W3C Note),” World Wide Web Consortium, Jul. 2002.

[43] M. Dazer, “RESTful APIs - Eine Übersicht,” Technical University Berlin, Berlin,

Deutschland, Mrz. 2012.

[44] K. M. Waqas und E. Abbasi, “Differentiating Parameters for Selecting Simple Object

Access Protocol (SOAP) vs. Representational State Transfer (REST) Based Archi-

tecture,” in Journal of Advances in Computer Networks, 3(1), 2015, S. 63–66.

[45] F. Jammes, A. Mensch und H. Smit, “Service-Oriented Device Communications Us-

ing the Devices Profile for Web Services,” in 21st International Conference on Ad-

vanced Information Networking and Applications Workshops/Symposia, Niagara

Falls, Kanada, Mai. 2007, S. 947–955.

[46] G. Moritz, D. Timmermann, R. Stoll und F. Golatowski, “encDPWS - Message En-

coding of SOAP Web Services: Compression and Encoding for Devices Profile for

Web Services,” in 8th IEEE International Conference on Pervasive Computing and


Communications (PERCOM Workshops), Mannheim, Deutschland, März-Apr. 2010,

S. 784–787.

[47] R. T. Fielding, “Architectural styles and the design of network-based software archi-

tectures,” Dissertation, University of California, Irvine, 2000.

[48] G. Moritz, E. Zeeb, S. Prüter, F. Golatowski, D. Timmermann und R. Stoll, “Devices

Profile for Web Services and the REST,” in 8th IEEE International Conference on

Industrial Informatics (INDIN), Osaka, Japan, Jul. 2010, S. 584–591.

[49] A. Ruppen, J. Pasquier und T. Hürlimann, “A RESTful architecture for integrating

decomposable delayed services within the Web of Things,” in 17th IEEE Interna-

tional Conference on Parallel and Distributed Systems (ICPADS 2011), Tainan, Tai-

wan, Dez. 2011, S. 860–865.

[50] I. Fette und A. Melnikov, “The WebSocket Protocol (IETF RFC 6455),” Dez. 2011.

[51] L. Stout, J. Moffitt und E. Cestari, “An Extensible Messaging and Presence Protocol

(XMPP) Subprotocol for WebSocket (IETF RFC 7395),” Okt. 2014.

[52] K. Ma und R. Sun, “Introducing WebSocket-Based Real-Time Monitoring System

for Remote Intelligent Buildings,” in International Journal of Distributed Sensor

Networks Volume 2013, 2013.

[53] J.-t. Park, H.-s. Hwang, J.-s. Yun und I.-y. Moon, “Research and Performance Analy-

sis of HTML5 WebSocket for a Real-time Multimedia Data Communication Envi-

ronment,” in Advanced Science and Technology Letters (ASTL 46): Convergence Re-

search Trend I, Jeju Island, Korea, Apr. 2014, S. 307–312.

[54] A. Wessels, M. Purvis, J. Jackson und S. S. Rahman, “Remote Data Visualization

through WebSockets,” in Eighth International Conference on Information Technol-

ogy: New Generations (ITNG 2011), Las Vegas, Nevada, Apr. 2011, S. 1050–1051.

[55] J.-P. Erkkilä, “WebSocket Security Analysis,” Aalto University School of Science,

Espoo, Finnland, 2012.

[56] XMPP Standards Foundation (XSF). Verfügbar unter: http://xmpp.org (28.05.2015).

[57] P. Saint-André, “Extensible Messaging and Presence Protocol (XMPP): Core

(IETF RFC 6120),” Mrz. 2011.

[58] P. Saint-Andre, “Extensible Messaging and Presence Protocol (XMPP): Address For-

mat (IETF RFC 6122),” Mrz. 2011.

[59] S. Bendel, T. Springer, D. Schuster, A. Schill, R. Ackermann und M. Ameling, “A

Service Infrastructure for the Internet of Things based on XMPP,” in IEEE Interna-

tional Conference on Pervasive Computing and Communications Workshops

(PERCOM Workshops), San Diego, Kalifornien, Mrz. 2013, S. 385–388.

[60] R. Klauck und M. Kirsche, “Chatty Things - Making the Internet of Things Readily

Usable for the Masses with XMPP,” in 8th International Conference on Collabora-

tive Computing: Networking, Applications and Worksharing (CollaborateCom

2012), Pittsburgh, Pennsylvania, Okt. 2012, S. 60–69.

[61] P. Grubitzsch und D. Schuster, “Hosting and Discovery of Distributed Mobile Ser-

vices in an XMPP Cloud,” in Third IEEE International Conference on Mobile Ser-

vices (MS 2014), Anchorage, Alaska, Jun. 2014, S. 47–54.


[62] P. Wang, H. Wang und W. Wu, “Design and Implementation of XMPP for Wireless

Sensor Networks Based on IPv6,” in International Conference on Logistics Engi-

neering, Management and Computer Science (LEMCS 2014), Shenyang, China, Mai.

2014, S. 852–855.

[63] S. Mathaba, N. Dlodlo, A. Smith, I. Makitla, G. Sibiya und Adigun Matthew, “Inter-

facing internet of things technologies of RFID, XMPP and Twitter to reduce inaccu-

racies in inventory management,” in IST-Africa 2012 Conference & Exhibition, Dar

es Salaam, Tansania, Mai. 2012.

[64] M. Pichler, “Communication Patterns for Demand Side Flexibility,” in Tagungsband

ComForEn 2014: 5. Symposium Communications for Energy Systems, Wien, Öster-

reich, Sep. 2014, S. 19–28.

[65] H. Tschofenig, “Emergency Services Functionality with the Extensible Messaging

and Presence Protocol (XMPP) (IETF Internet-Draft <draft-tschofenig-ecrit-xmpp-

es-00.txt>),” Mrz. 2012.

[66] R. Patuck und J. Hernandez-Castro, “Steganography using the Extensible Messaging

and Presence Protocol (XMPP),” University of Kent, Canterbury, Großbritannien,

Sep. 2013.

[67] ITU-T, ASN.1 Project. Verfügbar unter: http://www.itu.int/en/ITU-T/asn1/Pa-

ges/asn1_project.aspx (25.05.2015).

[68] ITU, “Abstract Syntax Notation One (ASN.1): Specification of basic notation (ITU-

T Recommendation X.680),” International Telecommunication Union, Nov. 2008.

[69] ITU, “ASN.1 encoding rules: Specification of Encoding Control Notation (ECN)

(ITU-T Recommendation X.692),” International Telecommunication Union, Nov.

2008.

[70] ITU, “ASN.1 encoding rules: Specification of Basic Encoding Rules (BER), Canoni-

cal Encoding Rules (CER) and Distinguished Encoding Rules (DER) (ITU-T Rec-

ommendation X.690),” International Telecommunication Union, Nov. 2008.

[71] ITU, “ASN.1 encoding rules: Registration and application of PER encoding instruc-

tions (ITU-T Recommendation X.695),” International Telecommunication Union,

Nov. 2008.

[72] ITU, “ASN.1 encoding rules: Specification of Packed Encoding Rules (PER) (ITU-T

Recommendation X.691),” International Telecommunication Union, Nov. 2008.

[73] ITU, “ASN.1 encoding rules: Specification of Octet Encoding Rules (OER) (ITU-T

Recommendation X.696),” International Telecommunication Union, Aug. 2014.

[74] ITU, “ASN.1 encoding rules: XML Encoding Rules (XER) (ITU-T Recommendation

X.693),” International Telecommunication Union, Nov. 2008.

[75] ITU, “ASN.1 encoding rules: Mapping W3C XML schema definitions into ASN.1

(ITU-T Recommendation X.694),” International Telecommunication Union, Nov.

2008.

[76] S. Diewald, T. Leinmüller, B. Atanassow, L.-P. Breyer und M. Kranz, “Mobile De-

vice Integration with V2X Communication,” in 19th World Congress on Intelligent

Transport Systems (ITS), Wien, Österreich, Okt. 2012.


[77] C. Kriger, S. Behardien und J.-C. Retonda-Modiya, “A Detailed Analysis of the Ge-

neric Object-Oriented Substation Event Message Structure in an IEC 61850 Stand-

ard-Based Substation Automation System,” in International Journal of Computers

Communications & Control, 8(5), 2013, S. 708–721.

[78] J. Case, M. Fedor, M. Schoffstall und J. Davin, “A Simple Network Management

Protocol (SNMP) (IETF RFC 1157),” Mai. 1990.

[79] J. Sermersheim, “Lightweight Directory Access Protocol (LDAP): The Protocol

(IETF RFC 4511),” The Internet Society, Jun. 2006.

[80] A. Herzog und A. Buchmann, “A3ME – Generic Middleware for Information Ex-

change in Heterogeneous Environments,” in Ninth International Conference on Net-

worked Sensing Systems (INSS 2012), Antwerpen, Belgien, Jun. 2012, S. 1–4.

[81] D. P. Mundy, D. Chadwick und A. Smith, “Comparing the Performane of Abstract

Syntax Notation One (ASN.1) vs eXtensible Markup Language (XML),” in TERENA

Networking Conference, Zagreb, Kroatien, Mai. 2003.

[82] D. Mundy und D. W. Chadwick, “An XML Alternative for Performance and Secu-

rity: ASN.1,” in IT Professional, 6(1), 2012, S. 30–36.

[83] S. Josefsson, “The Base16, Base32, and Base64 Data Encodings (IETF RFC 4648),”

The Internet Society, Okt. 2006.

[84] J. Callas, L. Donnerhacke, H. Finney, D. Shaw und R. Thayer, “OpenPGP Message

Format (IETF RFC 4880),” Nov. 2007.

[85] N. Freed und N. Borenstein, “Multipurpose Internet Mail Extensions (MIME) Part

One: Format of Internet Message Bodies (IETF RFC 2045),” Nov. 1996.

[86] M. A. Ahmad, I. F. Al-Shaikhli und H. M. Ahmad, “Protection of the Texts Using

Base64 and MD5,” in Journal of Advanced Computer Science and Technology Re-

search, 2(1), 2012, S. 22–34.

[87] L. Yu, Z. Wang und W. Wang, “The Application of Hybrid Encryption Algorithm in

Software Security,” in Fourth International Conference on Computational Intelli-

gence and Communication Networks (CICN 2012), Mathura, Indien, Nov. 2012, S.

762–765.

[88] M. Hussain, Wahab, Ainuddin Wahid Abdul, I. Batool und M. Arif, “Secure Pass-

word Transmission for Web Applications over Internet using Cryptography and Im-

age Steganography,” in International Journal of Security and Its Application, 9(2),

2015, S. 179–188.

[89] M. Mukherjee, S. Adya und M. Sarkar, “Message Secured Module using Image

Cryptography,” in Advances in Modern Computing and Application Trends: Third

National Conference on Advances in Modern Computing and Application Trends

(TECHMAN-14), Bangalore, Indien, Dez. 2014, S. 30–33.

[90] C. Xu, Y. Chen und K. Chiew, “An Approach to Image Spam Filtering Based on

Base64 Encoding and N-Gram Feature Extraction,” in 22nd International Confer-

ence on Tools with Artificial Intelligence (ICTAI 2010), Arras, Frankreich, Okt.

2010, S. 171–177.

[91] Raspberry Pi Foundation, Raspberry Pi. Verfügbar unter: https://www.raspber-

rypi.org/ (05.07.2015).


[92] J. H. Christensen, T. Strasser, A. Valentini, V. Vyatkin und A. Zoitl, “The IEC

61499 Function Block Standard: Software Tools and Runtime Platforms,” in ISA Au-

tomation Week 2012, Orlando, Florida, Sep. 2012, S. 1–12.

[93] C. Pang, S. Patil, C.-W. Yang, V. Vyatkin und A. Shalyto, “A Portability Study of

IEC 61499: Semantics and Tools,” in 12th IEEE International Conference on Indus-

trial Informatics (INDIN 2014), Porto Alegre, Brasilien, Jul. 2014, S. 440–445.

[94] PROFACTOR GmbH, 4DIAC Help. Verfügbar unter: http://fordiac.source-

forge.net/ehelp/ (07.07.2015).

Anhang 117

Anhang

Im Anhang sind Abbildungen vom Testaufbau, von den Messungen mit dem Oszilloskop,

von den Wireshark-Aufzeichnungen, ein Listing mit einem Onlineshop-Beispiel über REST

und Tabellen mit den von der IEC 61131 und von ASN.1 unterstützten Datentypen und dem

Base64 Alphabet enthalten.

A.1 Abbildungen

In Abbildung 26 ist der Testaufbau mit den Systemen und Testplatinen des Netzbetreibers,

CEMs und Displays und dem XMPP Server dargestellt.

Abbildung 26: Testaufbau

Anhang 118

In Abbildung 27 bis Abbildung 29 sind die Oszilloskop-Bilder der Reaktionszeitmessungen,

siehe auch Abschnitt 11.1, dargestellt.

Abbildung 27: Zeitverzögerung Publish-Subscribe mit XMPP verschlüsselt

Abbildung 28: Zeitverzögerung Publish-Subscribe mit XMPP unverschlüsselt

Anhang 119

Abbildung 29: Zeitverzögerung Publish-Subscribe mit UDP

In Abbildung 30 bis Abbildung 35 sind die Wireshark-Aufzeichnungen der verschiedenen

Kommunikationsarten, siehe auch Abschnitt 11.2, dargestellt.

Abbildung 30: Publish-Subscribe mit XMPP verschlüsselt

Abbildung 31: Publish-Subscribe mit XMPP unverschlüsselt

Abbildung 32: Publish-Subscribe mit UDP

Abbildung 33: Client-Server mit XMPP verschlüsselt

Abbildung 34: Client-Server mit XMPP unverschlüsselt

Anhang 120

Abbildung 35: Client-Server mit TCP

A.2 Listings

In Listing 13 ist ein Beispiel für REST über URI und HTTP, siehe auch Abschnitt 4.2.2,

dargestellt.

POST www.autoteile.de/shop/warenkoerbe <Benutzerdaten>

==> HTTP/1.1 201, Created

==> www.autoteile.de/shop/warenkoerbe/1234

==> www.autoteile.de/shop/teile/

==> www.autoteile.de/shop/teile/kategorien/

GET www.autoteile.de/shop/teile/kategorien

==> HTTP/1.1 200, OK

==> . . .

==> www.autoteile.de/shop/teile/kategorien/reifen

==> www.autoteile.de/shop/teile/kategorien/bremsen

==> . . .

GET www.autoteile.de/shop/teile/kategorien/bremsen

==> HTTP/1.1 200, OK

==> . . .

==> www.autoteile.de/shop/teile/kategorien/bremsen/4678

==> www.autoteile.de/shop/teile/kategorien/bremsen/4679

==> . . .

GET www.autoteile.de/shop/teile/kategorien/bremsen/4678

==> HTTP/1.1 202, Accepted

==>

<Artikel>

<Name>Anker 2.0</Name>

<Beschreibung>

Ab jetzt nur noch Vollbremsungen...

</Beschreibung>

<Anmerkung>Beläge für je einen Sattel</Anmerkung>

<Preis>32.80</Preis >

<Verwandte Artikel>

<Artikel xlink:href=www.autoteile.de/shop/teile/bremsen/4679>

<Beschreibung>

Anhang 121

Halten ein Autoleben lang...

</Beschreibung>

</Artikel>

</Verwandte Artikel>

</Artikel>

PUT www.autoteile.de/shop/warenkoerbe/1234 <4678, 4679>

==> HTTP/1.1 202, Accepted

DELETE www.autoteile.de/shop/warenkoerbe/1234/teile/4679

==> HTTP/1.1 204, No Content

Listing 13: REST über URI und HTTP – Beispiel Onlineshop, nach [41]

A.3 Tabellen

In Tabelle 20 sind die von der IEC 61131-3 definierten Datentypen inkl. ihrer Größe aufge-

listet, siehe auch Abschnitt 3.1.2.

Bezeichnung Größe [bit]

Binär / Bitfolge

BOOL 1

BYTE 8

WORD 16

DWORD 32

LWORD 64

Ganzzahl

INT 16

SINT 8

DINT 32

LINT 64

Ganzzahl ohne Vorzeichen

UINT 16

USINT 8

Anhang 122

Bezeichnung Größe [bit]

UDINT 32

ULINT 64

Gleitkomma Zahlen

REAL 32

LREAL 64

Zeitpunkt, Zeitdauer, Datum

TIME -

DATE -

TIME_OF_DAY -

DATE_AND_TIME -

Zeichenfolge

STRING 8

WSTRING 16

Tabelle 20: IEC 61131-3 Datentypen, nach [25]

In Tabelle 21 sind die von ASN.1 definierten Datentypen inkl. ihrer Tag-ID aufgelistet, siehe

auch Abschnitt 5.1.1.

Bezeichnung Tag

Elementare Typen

BOOLEAN 1

INTEGER 2

BIT STRING 3

OCTET STRING 4

NULL 5

OBJECT IDENTIFIER 6

Anhang 123

Bezeichnung Tag

EXTERNAL 8

REAL 9

ENUMERATED 10

EMBEDDED PDV 11

UTF8String 12

RELATIVE-OID 13

TIME 14

NumericString 18

PrintableString 19

TeletexString

(T61String)

20

VideotexString 21

IA5String 22

GraphicString 25

VisibleString 26

GeneralString 27

UniversalString 28

CHARACTER

STRING

29

BMPString 30

OID-IRI 35

RELATIVE-OID-IRI 36

Zusammengesetzte Typen

SEQUENCE 16

Anhang 124

Bezeichnung Tag

SEQUENCE OF 16

SET 17

SET OF 17

CHOICE -

SELECTION -

Tabelle 21: ASN.1 Variablen-Typen, nach [68]

In Tabelle 22 ist das Base64 Alphabet dargestellt, siehe auch Kapitel 5.2.

Wert Zeichen Wert Zeichen Wert Zeichen Wert Zeichen

0 A 17 R 34 i 51 z

1 B 18 S 35 j 52 0

2 C 19 T 36 k 53 1

3 D 20 U 37 l 54 2

4 E 21 V 38 m 55 3

5 F 22 W 39 n 56 4

6 G 23 X 40 o 57 5

7 H 24 Y 41 p 58 6

8 I 25 Z 42 q 59 7

9 J 26 a 43 r 60 8

10 K 27 b 44 s 61 9

11 L 28 c 45 t 62 +, -1

12 M 29 d 46 u 63 /, _1

13 N 30 e 47 v

14 O 31 f 48 w (Füll-Z.) =

15 P 32 g 49 x

Anhang 125

Wert Zeichen Wert Zeichen Wert Zeichen Wert Zeichen

16 Q 33 h 50 y

1 Bei Base64-URI-Kodierung

Tabelle 22: Base64 Alphabet, nach [83]

MA14-39 - Erstellung einer Kommunikationsinfrastruktur für ... · [8] und Google mit „Weave“...

Documents

Transcript of MA14-39 - Erstellung einer Kommunikationsinfrastruktur für ... · [8] und Google mit „Weave“...