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
Anforderungsanalyse 7
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.
Anforderungsanalyse 8
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.
Anforderungsanalyse 9
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
Anforderungsanalyse 10
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.
Anforderungsanalyse 11
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.
Anforderungsanalyse 12
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.
Anforderungsanalyse 13
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
Anforderungsanalyse 14
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.
Anforderungsanalyse 15
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.
Anforderungsanalyse 16
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
Anforderungsanalyse 17
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.
Normen für speicherprogrammierbare Steuerungen 19
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
Normen für speicherprogrammierbare Steuerungen 20
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.
Normen für speicherprogrammierbare Steuerungen 21
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]:
Normen für speicherprogrammierbare Steuerungen 22
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]
Normen für speicherprogrammierbare Steuerungen 23
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]
Normen für speicherprogrammierbare Steuerungen 24
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].
Normen für speicherprogrammierbare Steuerungen 25
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].
Normen für speicherprogrammierbare Steuerungen 26
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.
Normen für speicherprogrammierbare Steuerungen 27
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]
Normen für speicherprogrammierbare Steuerungen 28
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
Normen für speicherprogrammierbare Steuerungen 29
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].
Normen für speicherprogrammierbare Steuerungen 30
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].
Normen für speicherprogrammierbare Steuerungen 31
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
Normen für speicherprogrammierbare Steuerungen 32
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
Normen für speicherprogrammierbare Steuerungen 33
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.
Normen für speicherprogrammierbare Steuerungen 34
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].
3.2.3 Aktueller Stand
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-
Normen für speicherprogrammierbare Steuerungen 35
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
Normen für speicherprogrammierbare Steuerungen 36
[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.
Kommunikationsprotokolle 38
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].
Kommunikationsprotokolle 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].
Kommunikationsprotokolle 40
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].
4.1.3 Aktueller Stand
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.
Kommunikationsprotokolle 41
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
Kommunikationsprotokolle 42
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
Kommunikationsprotokolle 43
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].
4.2.3 Aktueller Stand
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
Kommunikationsprotokolle 44
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
Kommunikationsprotokolle 45
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
Kommunikationsprotokolle 46
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].
4.3.2 Nachrichtenübertragung
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]
Kommunikationsprotokolle 47
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].
4.3.3 Aktueller Stand
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
Kommunikationsprotokolle 48
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.
Kommunikationsprotokolle 49
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/
Kommunikationsprotokolle 50
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
Kommunikationsprotokolle 51
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
Kommunikationsprotokolle 52
<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].
4.4.3 Nachrichtenübertragung
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
Kommunikationsprotokolle 53
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].
4.4.4 Aktueller Stand
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/
Kommunikationsprotokolle 54
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)
Kodierungsverfahren 56
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].
Kodierungsverfahren 57
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-
Kodierungsverfahren 58
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].
Kodierungsverfahren 59
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].
Kodierungsverfahren 60
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].
5.1.3 Aktueller Stand
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].
Kodierungsverfahren 61
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].
5.2.1 Aktueller Stand
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:
Kodierungsverfahren 62
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
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 <. 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
Definition der Testumgebung 79
ü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/
Definition der Testumgebung 80
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.
Definition der Testumgebung 81
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/
Definition der Testumgebung 82
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/
Definition der Testumgebung 83
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.
REQ05 - Die Unterstützung von Standard-Schnittstellen (z.B. XMPP) muss gegeben
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.
REQ12 - Das Protokoll darf die Variabilität der Nutzdaten nicht einschränken.
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.
Eine Zusammenfassung der Ergebnisse ist in Tabelle 10 zu finden.
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.
Siehe Abschnitt 10.1.
REQ05 - Die Unterstützung von Standard-Schnittstellen (z.B. XMPP) muss gegeben
sein.
Siehe Abschnitt 10.1.
REQ12 - Das Protokoll darf die Variabilität der Nutzdaten nicht einschränken.
Siehe Abschnitt 10.1.
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.
Eine Zusammenfassung der Ergebnisse ist in Tabelle 12 zu finden.
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]
XMPP verschlüsselt 346
XMPP unverschlüsselt 741
Evaluierung 103
Protokoll Paketgröße [Byte]
UDP 45
Tabelle 14: Nachrichtengröße Publish-Subscribe
Protokoll Paketgröße [Byte]
XMPP verschlüsselt 378
XMPP unverschlüsselt 535
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
Fazit und Ausblick 107
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-
Fazit und Ausblick 108
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.
Fazit und Ausblick 109
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.
Literaturverzeichnis 111
[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.
Literaturverzeichnis 112
[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
Literaturverzeichnis 113
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.
Literaturverzeichnis 114
[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.
Literaturverzeichnis 115
[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).
Literaturverzeichnis 116
[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]