Definition einer Internet-der-Dinge

Transcrição

Definition einer
Internet-der-Dinge-Plattform und
deren Referenzimplementierung
sowie einer exemplarischen
Anbindung an Formale Methoden.
Bachelorarbeit
von
Sascha Wolter
eingereicht bei
Institut für Informatik
Softwaretechnik und Programmiersprachen
Prof. Dr. Michael Leuschel
Universitätsstr. 1, D–40225 Düsseldorf
November 2015
Gutachter:
Prof. Dr. Michael Leuschel
Jun.-Prof. Dr.-Ing. Kálmán Graffi
Betreuer:
David Schneider
Erklärung
Hiermit versichere ich, die vorliegende Bachelorarbeit selbstständig verfasst und keine
anderen als die angegebenen Quellen und Hilfsmittel benutzt zu haben. Alle Stellen, die
aus den Quellen entnommen wurden, sind als solche kenntlich gemacht worden. Diese
Arbeit hat in gleicher oder ähnlicher Form noch keiner Prüfungsbehörde vorgelegen.
Düsseldorf, den 6. November 2015
Sascha Wolter
Zusammenfassung
Diese Bachelorarbeit beschäftigt sich mit der Beschreibung einer typischen Internet-derDinge-Plattform und stellt eine Referenzimplementierung vor, die sich für die Verwendung mit Formalen Methoden wie ProB eignet. Die umgesetzte Plattform nutzt gängige
und offene Standards: Als Nachrichtenbus kommt MQTT zum Einsatz – inklusive eines
exemplarischen Clients auf Basis eines Arduino bzw. Genuino; die Anwendungslogik
und das Gateway basieren auf Node.js und Node-RED.
Das Internet der Dinge umfasst eine Vielzahl realer Objekte, die mit Hilfe von Sensoren und
Aktuatoren um digitale Funktionen erweitert und direkt oder indirekt über Internet-basierte Technologien vernetzt sind. Diese Systeme aus Systemen durchdringen immer mehr Lebensbereiche und beeinflussen aktiv den Alltag. Die daraus resultierende Komplexität birgt
zahlreiche Risiken. Als Grundlage für deren Bewältigung dient ein Durchstich, der die
Internet-der-Dinge-Plattform über den Nachrichtenbus mit Formalen Methoden kombiniert und dafür auf die ProB Java API zurückgreift. Denn der Einsatz Formaler Methoden
hilft bereits während der Spezifikation bei der Fehlervermeidung und macht die Korrektheit eines Systems berechenbar.
Doch nicht nur das Internet der Dinge profitiert von Formalen Methoden: Die hier vorgestellte Internet-der-Dinge-Plattform ist auch zum Nutzen von Formalen Methoden. Denn
bei der Modellierung zustandsbasierter Systeme und der Animation von Zustandsübergängen hilft es, die zugrundeliegende Hardware zu berücksichtigen. Das reale Verhalten
lässt sich auf diese Weise durch Sensoren und Aktuatoren abbilden und interaktiv verfügbar machen. Dies trägt nicht nur zum Verständnis bei, sondern erlaubt ebenfalls die
Berücksichtigung des Benutzerverhaltens.
INHALTSVERZEICHNIS
i
Inhaltsverzeichnis
1
Hintergrund
1
1.1
Internet der Dinge . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
1
1.1.1
Relevanz . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
2
1.1.2
Definition . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
3
1.1.3
Herausforderungen . . . . . . . . . . . . . . . . . . . . . . . . . . .
4
Formale Methoden . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
6
1.2.1
Beispiele . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
7
1.2.2
B Methode . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
7
1.2.3
ProB . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
8
1.2
2
Lösungsentwicklung
11
2.1
Referenzarchitektur . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
11
2.1.1
Konzepte . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
11
2.1.2
Umsetzung . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
14
Anbindung an ProB . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
19
2.2.1
Maschinen und Nachrichten . . . . . . . . . . . . . . . . . . . . . .
20
2.2.2
Geräteinteraktion und Regeln . . . . . . . . . . . . . . . . . . . . . .
25
2.2.3
Visualisierung und Lehre . . . . . . . . . . . . . . . . . . . . . . . .
27
2.2
3
Fazit
29
A Anhang
31
A.1 Start . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
31
A.2 Erweiterung . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
32
A.3 Dateien und Datenträger . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
33
Literatur
34
Abbildungsverzeichnis
37
Listings
38
1
HINTERGRUND
1
1
Hintergrund
Die erste Hälfte dieses Abschnitts beschreibt typische Merkmale des Internet der Dinge (engl. Internet of Things, Kurzform IoT) – ganz egal, ob es sich beispielsweise um
eher kleinere Installationen aus Endkunden-orientierten Haushaltsgeräten (Smart Home)
oder um ganze Städte (Smart City1 ) handelt. Es werden die Historie sowie der Status quo
beschrieben, eine Definition für IoT hergeleitet und Beispiele sowie Herausforderungen
aufgelistet. Die zweite Hälfte erläutert Formale Methoden und deren Zweck anhand der
B Methode und stellt abschließend die ProB Java API vor. Diese dient im späteren Verlauf als Grundlage für die Zusammenführung vom Internet der Dinge und Formalen
Methoden.
1.1
Internet der Dinge
Die eigentliche Vision des Internet der Dinge als Ubiquitous Computing (Rechnerallgegenwart, Kurzform ubicomp) erwähnt Mark Weiser [Wei96] zum ersten Mal 1988 am
Computer Science Lab des Xerox PARC. In seinem 1991 erschienen Aufsatz „The Computer for the 21st Century“ [Wei91] beschreibt er eine Welt, bei der allgegenwärtige Computer die menschliche Umgebung berücksichtigen und sich in dieser im Hintergrund
unmerklich integrieren: „The most profound technologies are those that disappear. They
weave themselves into the fabric of everyday life until they are indistinguishable from
it.” Die dadurch resultierende unbewusste Nutzung erlaubt es dem Anwender, sich auf
seine eigentlichen Ziele zu konzentrieren. Dafür ist laut Weiser entscheidend, dass die
Silikon-basierte Informationstechnologie den physischen Ort als Kontext ermitteln kann
und dass die Geräte miteinander interagieren.
Zum ersten Mal erwähnt Kevin Ashton [Ash09] das „Internet der Dinge“ 1999 in einem
Vortrag rund um die funkbasierte Identifikation (RFID2 ) von Dingen in der Lieferkette.
Für Ihn zeichnet sich IoT dadurch aus, dass nicht mehr einzelne Menschen Daten erfassen, sondern Computer diese Aufgabe übernehmen, indem sie Informationen über die
Dinge in der physischen Welt durch Sensorik selbständig ermitteln: „We need to empower computers with their own means of gathering information, so they can see, hear
and smell the world for themselves, in all its random glory. RFID and sensor technology
enable computers to observe, identify and understand the world – without the limitations
of human-entered data.”
Überwiegend wird unter dem „Internet der Dinge“ jedoch weniger die eingegrenzte
Sichtweise von Kevin Ashton, beschränkt auf Lieferketten, als vielmehr das weiter gefasste Ubiquitous Computing verstanden. Das Internet der Dinge zeichnet sich dadurch
aus, dass Rechner in die Umgebung der Nutzer eindringen und so aus passiven Objekten intelligente Dinge machen, die ihren Zustand über Netze kommunizieren können
[MBH09, 43]. Zu den Varianten des Ubiquitous Computing zählen unter anderem Mobile
Computing und Wearable Computing [MBH09, 275].
1
2
http://de.wikipedia.org/wiki/Smart_City, Abgerufen am 29. Oktober 2015
http://de.wikipedia.org/wiki/RFID, Abgerufen am 19. Oktober 2015
1
HINTERGRUND
1.1.1
2
Relevanz
Praktische Beispiele für vernetzte Geräte gab es bereits vor der Erfindung des IoT. Als einer der ersten Industriestandards für die Gebäudeautomatisierung gilt das 1975 von Pico
Electronics entwickelte X-103 , das von der Firma Busch-Jäger ab 1981 als Busch-Timac X10 auch in Deutschland vertrieben wurde4 . X-10 ist ein hauptsächlich stromleitungsbasiertes Netzwerkprotokoll ohne Rückkanal. Für die Steuerung kann neben Fernschaltern
und Netzleitstellen auch auf einen Computer wie den Commodore C645 zurückgegriffen
werden.
Als überhaupt erstes Beispiel für das Internet der Dinge wird meist der vernetzte Coca
Cola Automat [Ste00] genannt. Die „CMU SCS Coke Machine“6 wurde 1982 an der
Carnegie Mellon School of Computer Science in Pittsburgh von Mike Kazar, David
Nichols, John Zsarnay und Ivor Durham vernetzt, um vom Schreibtisch aus prüfen zu
können, ob der Automat mit Flaschen befüllt ist.
Schon 1995 beschäftigte sich Nicholas Negroponte in seinem Buch „Being Digital”
[Neg95] mit einer Zukunft, in der alles was digitalisiert werden kann, auch digitalisiert wird. Timotheus Höttges, CEO der Deutsche Telekom, griff dies im Zusammenhang
mit der zunehmenden Vernetzung der Geräte auf dem Mobile World Congress 2014 auf
und brachte es aus Sicht des Telekommunikationskonzerns entsprechend auf den Punkt
[Cla14]: „Everything that can be connected, will be connected.”
Abbildung 1: Smart Home Marktprognose [BIT14, 10].
Ein stellvertretendes Beispiel für die Diskrepanz zwischen der Erwartungshaltung seitens der Hersteller und der tatsächlichen Akzeptanz beim Kunden sind die vernetzten
Kühlschränke aus den späten 90er Jahren. Electrolux präsentierte 1999 mit Screenfridge7
3
http://de.wikipedia.org/wiki/X10_(Protokoll), Abgerufen am 16. Oktober 2015
http://youtu.be/Kpfs2gGbRSk, Abgerufen am 16. Oktober 2015
5
http://files.buyitsellit.com/8181/CP290.pdf, Abgerufen am 16. Oktober 2015
6
http://www.cs.cmu.edu/~coke/, Abgerufen am 16. Oktober 2015
7
http://www.electroluxgroup.com/en/history-1990-1999-764/, Abgerufen am 16. Okto4
1
HINTERGRUND
3
einen intelligenten Kühlschrank, der laut eigener Aussage als erster Kühlschrank den Inhalt der einzelnen Fächer nachverfolgen konnte, Rezeptempfehlungen macht, InternetEinkäufe erlaubt, als Kommunikationszentrale inklusive Video für die Familie dient und
sich sogar als Monitor für Sicherheitssysteme eignet. Offensichtlich mit bescheidenem Erfolg für dieses Nutzenversprechen (engl. value proposition); zumindest wenn man mehr
als 15 Jahre später die Anzahl der vernetzten Wohnungen in der Praxis betrachtet.
Laut einer Studie von Deloitte und der Fokusgruppe „Connected Home“ des Nationalen
IT-Gipfels [BIT14] wurden in Deutschland Ende 2013 gerade einmal 315.000 vernetzte
Privathaushalte gezählt (siehe Abbildung 1). Um die Relevanz dieser Zahl zu verdeutlichen: Mit rund 330.000 aller Wohnungen (0,8 Prozent) verfügten laut Statistischem Bundesamt 20118 annähernd gleich viele Haushalte weder über Toilette noch Dusche. Immerhin könnten laut der Deloitte-Studie bei einer konservativen Schätzung bereits 2020
rund eine Millionen Haushalte in Deutschland mit Smart-Home-Lösungen ausgestattet
sein.
Dabei ist das intelligente und vernetzte Zuhause aus Sicht von IoT-Entwicklern noch
vor Wearable Computing das zurzeit populärste Segment [Vis15, 11], weshalb im späteren Verlauf dieser Bachelorarbeit der Schwerpunkt auf Beispielen aus diesem Bereich
liegt. Über alle Anwendungsgebiete hinweg erwarten Analysten und Konzerne einen
Multimilliarden-Dollarmarkt und überbieten sich gegenseitig mit ihren Prognosen. Beispielsweise rechnet die OECD [OEC12] für das Jahr 2020 alleine im M2M9 -Bereich (engl.
Machine-to-Machine Communication) mit rund 50 Milliarden vernetzten Geräten und
Cisco geht von einem Marktvolumen von 14 Trillionen Dollar Gewinn innerhalb des
nächsten Jahrzehnts für das von ihnen „Internet of Everything“ getaufte Geschäftsfeld
aus [End13]. Interessant: Laut einer Umfrage von Accenture unter 1400 Entscheidungsträgern haben nur 7 Prozent einen umfassenden Plan, um von diesem gewaltigen Kuchen
ein Stück abzubekommen [DB15].
1.1.2
Definition
Der inflationäre Gebrauch des Begriffs IoT und dessen zahlreiche anwendungsbezogene Varianten machen eine allgemeingültige Definition schwer. Einige Hersteller bemühen sich um eigene Begrifflichkeiten wie zum Beispiel Cisco mit „Internet of Everything“
[Cis15] oder Microsoft mit Internet of Your Things [Mic15], ohne dass fundamental etwas
anderes gemeint ist. Die Industrie nutzt den Begriff außerdem auch im Embedded10 - und
M2M-Umfeld – häufig abgewandelt als „Industrial Internet of Things“ oder als „Industrial Internet“11 .
Nichtsdestotrotz scheinen sich alle darin einig zu sein, dass das Internet der Dinge einen
zur virtuellen Realität gegensätzlichen Ansatz verfolgt: Reale Objekte werden um digitale
Funktionen erweitert. Es wird nicht der Mensch in die digitale Welt geführt, sondern Teile
ber 2015
8
http://www.destatis.de/DE/PresseService/Presse/Pressekonferenzen/2013/
Zensus2011/gwz_zensus2011.pdf, S. 14, Abgerufen am 16. Oktober 2015
9
http://de.wikipedia.org/wiki/Machine_to_Machine, Abgerufen am, 19. Oktober 2015
10
http://en.wikipedia.org/wiki/Embedded_system, Abgerufen am 22. Oktober 2015
11
http://en.wikipedia.org/wiki/Industrial_Internet, Abgerufen am 22. Oktober 2015
1
HINTERGRUND
4
der digitalen Welt in die reale Welt übertragen, indem man reale Objekte der physischen
Welt um digitale Funktionen erweitert. Rein technisch betrachtet ist es aus meiner Sicht
unerheblich, ob es sich bei den Dingen um Konsumgüter, Maschinen oder Lebewesen
handelt.
Die Brücke zwischen Internet und physikalischer Welt schlagen Sensoren und Aktuatoren [RGC+ 15, 48]: Reale Objekte werden mit Hilfe von Sensoren und Aktuatoren um digitale
Funktionen erweitert. Sensoren liefern den Kontext, indem sie den Zustand der Umgebung als digitalen Wert darstellen. Aktuatoren verwandeln digitale Anweisungen in mechanische Aktionen und erlauben es so, einem digitalen System mit der Umgebung zu
interagieren und beispielsweise einen Motor zu steuern oder eine Leuchte einzuschalten.
Das Internet der Dinge zeichnet sich außerdem dadurch aus, dass für die Verarbeitung
der Sensordaten ein Rechner und eine Vernetzung zum Einsatz kommen. Landläufig
werden hier, wie der Name schon sagt, Internet-basierte Protokolle und Dienste verwendet. Laut [RGC+ 15, 10] besteht solch ein typischer IoT-Dienst aus:
• einem oder mehreren eingebetteten Systemen (Embedded Devices),
• einem Internet-Dienst,
• optional einem Gateway (zusätzliches Gerät zur Anbindung der eingebetteten Systeme an das Internet) und
• einer oder mehreren mobilen- oder Web-Anwendungen, um mit dem Dienst zu
interagieren.
Anders als hier beschrieben, ist in der Praxis die Vernetzung auch ohne IP-basierte12
Technologie durchaus gängige Praxis, indem beispielsweise Bluetooth zum Einsatz
kommt. Außerdem sind mobile oder Web-Anwendungen nicht zwingend erforderlich,
zumal die Interaktion mit den Objekten auch direkt erfolgen kann, falls die Objekte sich
nicht ohnehin schon ohne weiteres Zutun eines Anwenders autonom verhalten.
Zusammenfassend bezieht sich das Internet der Dinge also auf reale Objekte, die mit Hilfe
von Sensoren und Aktuatoren um digitale Funktionen erweitert und direkt oder indirekt über
Internet-basierte Technologien vernetzt sind.
1.1.3
Herausforderungen
Die multidisziplinäre Natur des Internet der Dinge wirft zahlreiche Fragen auf. Zuallererst jene nach dem eigentlichen Nutzen (siehe Abchnitt 1.1.1, Seite 2). Denn trotz aller
technischer Möglichkeiten und Geschäftsmodelle fehlt es oftmals an einem klaren Nutzenversprechen. Insbesondere jetzt, wo sich der erste Hype um das Internet der Dinge
legt [Gar14] und nicht mehr in erster Linie technikaffine Early-Adopter Begeisterung zeigen, sondern normale Konsumenten gewonnen werden müssen [RGC+ 15, 118]. Doch
dafür ist ein wirklicher Nutzen erforderlich[Sin09], denn noch sind IoT-Anwendungen
häufig erst einmal teurer und komplizierter als konventionelle Lösungen.
12
http://en.wikipedia.org/wiki/Internet_Protocol, Abgerufen am 22. Oktober 2015
1
HINTERGRUND
5
Abbildung 2: Paradigmenwechsel bei der Interaktionsgestaltung [Wei96].
In diesem Zusammenhang sind auch neue Interaktionsformen gefragt [MBH09, 44], da
sich das Benutzererlebnis (User Experience13 ) durch einen Paradigmenwechsel in der Benutzerschnittstelle (User Interface) stark verändert (siehe Abbildung 2). Der Nutzer wird
nicht mehr 1-zu-1 mit einem einzelnen Gerät interagieren, sondern steht inmitten einer
die Benutzungsoberfläche ausmachenden Sammlung von intelligenten Geräten. Diese 1zu-n-Schnittstelle zwischen Mensch und Maschine geht über die heute gebräuchlichen
Interaktionsformen hinaus und wird auch als „Super-natural Interaction“ (über die natürliche Interaktion hinsausgehend) [Wol13] bezeichnet: Alles wird zu einer Bedienoberfläche und die Geräte werden unsichtbar (embodied virtuality [Wei91]).
Dan Saffer erwartet eine Unmenge an Arbeit für Interaktionsgestalter [Saf09, 196]. Diese
müssen [Saf09, 197] lernen sich mit den „Spimes“ im Internet der Dinge auseinanderzusetzen. Bruce Sterling sagt [Ste04]: “The most important thing to know about Spimes
is that they are precisely located in space and time” (darum der Name). Spimes sind
vernetzte, den Kontext-kennende (context aware), eindeutig identifizierbare Objekte, die
Daten über sich und ihre Umgebung teilen. Diese Idee haben unter anderem auch das
Social Internet of Things14 und die Smart Devices in Google’s Physical Web15 aufgegriffen.
Zu den Herausforderungen zählen die gesellschaftlich relevanten Aspekte rund um Sicherheit und Privatsphäre [Wol15]. Führende Experten wie Tim O’Reilly halten Sicherheit und Privatsphäre sogar für das größte Risiko16 des Internet der Dinge. Ein wichtiger
Aspekt hinsichtlich Sicherheit wird jedoch oft übersehen: Denn es geht nicht nur darum,
dass Systeme sicher gegen Einbruch sind, sondern auch darum, dass IoT-Lösungen und
13
http://en.wikipedia.org/wiki/User_experience, Abgerufen am 16. Oktober 2015
http://www.social-iot.org/, Abgerufen am 16. Oktober 2015
15
http://google.github.io/physical-web/, Abgerufen am 16. Oktober 2015
16
http://www.mckinsey.com/insights/high_tech_telecoms_internet/the_internet_
of_things_five_critical_questions, Abgerufen am 16. Oktober 2015
14
1
HINTERGRUND
6
die verwendeten mentalen Modelle sich wie erwartet verhalten und immer nur erlaubte Zustände erreichen. Aufgrund der Komplexität, Fragmentierung [Kre14] des Marktes
und fehlender Standards [Mü14] ist das Sicherstellen einer solchen interoperablen und
zuverlässigen Lösung (engl. reliable) eine der drängendsten Herausforderungen bei der
auch Formale Methoden helfen können (siehe Abschnitt 1.2, Seite 6).
1.2
Formale Methoden
In der Informatik versteht man unter Formalen Methoden17 (engl. Formal Methods) eine
Vielzahl an Notationen, Techniken und Werkzeugen zur Spezifikation und Modellierung
von Systemen [But01]. Formale Methoden beschreiben die Funktionsweise einer Softund/oder Hardware in einer abstrakten und mathematisch-logischen Form, so dass ein
solches Systemmodell formal analysierbar ist und auf diese Weise die Richtigkeit und
Sicherheit unabhängig von der Implementierung verifiziert werden kann.
In diesem Zusammenhang beschreibt [CW96, 2] die zunehmende Komplexität und die
dadurch resultierende Fehleranfälligkeit von Hardware- und Software-Systemen: “Hardware and software systems will inevitably grow in scale und functionality. Because of this
increase in complexity, the likelihood of subtle errors is much greater.” Durch IT-Produkte
verschuldete Unfälle18 wie die beim Start explodierte Ariane-5-Rakete im Juni 1996 und
die im November 2000 erfolgten Fehlberechnungen von Strahlendosen mit mindestens
8 Toten dürfen nicht passieren. Die Entwickler sind dafür verantwortlich, dass die Software und Hardware zuverlässig arbeitet! Insbesondere dann, wenn sicherheitskritische
Bereiche wie z. B. Fahrzeuge und Haushaltsgeräte betroffen sind.
Formale Methoden sind eine Möglichkeit, um zuverlässigere System zu erreichen. Auch
wenn Formale Methoden laut [CW96, 2] nicht von vornherein zu Korrektheit führen, so
helfen sie doch allein schon durch das Verfassen einer formalen Beschreibung, ein System besser zu verstehen und Unzulänglichkeiten zu vermeiden, die andernfalls unentdeckt geblieben wären [Sym97, 30]. Eine präzise Spezifikation hilft ganz nebenbei auch
als Kommunikationsmittel zwischen Kunde, Designer, Entwickler und Tester [CW96, 3],
gerade wenn es sich um eine eher visuelle Darstellung wie bei Zustandsdiagrammen
(state charts) handelt [Har87]. Sofern sich eine Spezifikation animieren oder ausführen
lässt, kann diese durchaus als Prototyp für die Validierung dienen, ohne dass zusätzlicher Implementierungsaufwand vonnöten wäre [AFPS11, 17].
Professor Jonathan Bowen hat im Januar 2007 rund 100 unterschiedliche Schreibweisen,
Methoden und Werkzeuge für Formale Methoden als „Formal Methods Virtual Library“19 zusammengetragen. In dieser Liste befinden sich auch abstrakte Automaten (engl.
abstract state machines, kurz ASM), die B Methode und eher visuelle Varianten wie PetriNetze.
Die Modellüberprüfung kann je nach Methode sowohl automatisch als auch unter Mitwirkung eines Menschen durchgeführt werden. Dieser initiiert Beispielsweise die Zu17
http://de.wikipedia.org/wiki/Formale_Methode, Abgerufen am 16. Oktober 2015
http://archive.wired.com/software/coolapps/news/2005/11/69355?currentPage=
all, Abgerufen am 4. September 2015
19
http://web.archive.org/web/20080723172731/http://vl.fmnet.info/, Abgerufen am
16. Oktober 2015
18
1
HINTERGRUND
7
standsübergänge und legt so einen Pfad durch den Zustandsraum fest [CW96, 5ff]:
„Roughly speaking the check is performed as an exhaustive state space search [. . . ]”
1.2.1
Beispiele
Formale Methoden werden in der Praxis gerade dort eingesetzt, wo die Richtigkeit und
Sicherheit eines Systems essentiell ist und ein unerwartetes oder sogar falsches Verhalten
katastrophale Folgen hätte [But01]: “The value of formal methods is that they provide a
means to symbolically examine the entire state space of a digital design (whether hardware or software) and establish a correctness or safety property that is true for all possible
inputs.”
Formale Methoden wurden aus diesem Grund beispielsweise von Airbus S.A.S. bei den
sekundären Flugkontrollsystemen des Airbus A340 und bei den primären Flugkontrollsystemen des Airbus A38020 genutzt. Ein weiteres Beispiel ist das Maeslantkering Sturmflutwehr21 . Dabei handelt es sich um eine bewegliche Barriere zum Schutz für etwas eine
Million Menschen vor Überschwemmungen. Mit der B Methode (siehe Abschnitt 1.2.2,
Seite 7) kamen Formale Methoden ebenfalls bei dem Eisenbahnsignalsystem der Line 14
der Pariser Metro (1998) und dem führerlosen Shuttle des Paris Roissy Airports (2007)
zum Einsatz22 .
1.2.2
B Methode
Für die Spezifikation von Systemzuständen und deren Übergängen eignen sich Transitionssysteme wie die B Methode. B basiert auf abstrakten Automaten und zählt zu den
Zustands- oder Model-basierten Spezifikationssprachen [AFPS11, 18]. Es gibt eine Vielzahl von Umsetzungen der B Methode, darunter Atelier B, ProB und Rodin.
Ein in B spezifizierter Automat beschreibt die internen Zustände, die einzuhaltenden
Eigenschaften und die zu erwartenden Übergange. Die Spezifikation eines Schalters mit
der B Sprache könnte beispielsweise wie in Listing 1 aussehen23 .
Listing 1: Schalter als in B spezifizierter Automat.
1
3
5
7
MACHINE Switch
SETS
STATES={on,off}
CONSTANTS initial_state
PROPERTIES
initial_state:STATES
VARIABLES
current_state
20
http://de.wikipedia.org/wiki/SCADE#Beispiele_industrieller_Nutzung, Abgerufen
am 17. Oktober 2015
21
http://eprints.eemcs.utwente.nl/6381/01/fmsd.pdf, Abgerufen am 16. Oktober 2015
22
http://www.dsi.unifi.it/~fantechi/ESD/presentationModelChecking.pdf, Abgerufen
am 18. Oktober 2015
23
http://tuatara.cs.uni-duesseldorf.de/wolter/FormalIoT/blob/master/src/main/
b/switch.mch, Revision c7faac8b
1
9
11
13
15
17
19
21
23
25
27
HINTERGRUND
8
INVARIANT
current_state : STATES
INITIALISATION current_state := initial_state
OPERATIONS
Toggle =
BEGIN
IF current_state = on THEN
current_state := off
ELSE
current_state := on
END
END;
Set(new_state) =
PRE
new_state : STATES
THEN
current_state := new_state
END
END
In diesem Beispiel wird ein Automat als MACHINE Switch definiert, dessen mögliche
Zustände als Wertemenge (engl. set) STATES={on,off} festgelegt sind. Den Initialisierungszustand beschreibt initial_state, das einen Wert aus der Menge STATES haben
muss. Den aktuellen Zustand hält die Variable current_state, deren Wert ebenfalls
aus dieser Menge ist. Außerdem verfügt dieser Automat noch über zwei Operationen
(engl. operations), um die Zustandsübergänge durchzuführen: Eine Operation namens
„Toggle“, um den aktuellen Wert wie bei einem Taster zu wechseln und eine Operation
„Set“, um den aktuellen Zustand current_state wie bei einem Schalter auf einen Wert
aus der Wertmenge STATES zu setzen – also auf on oder off.
1.2.3
ProB
In dieser Bachelorarbeit kommt für Formale Methoden ProB zum Einsatz. Bei ProB handelts es sich um einen Animator und Model-Checker für die B Methode [LB03]. Es stehen
zahlreiche Werkzeuge für ProB zur Verfügung24 :
• ProB Cli: Nutzung von ProB über die Kommandozeile;
• ProB Tcl/Tk: Grafische Benutzerschnittstelle für ProB;
• ProB Java API: Java basierte Schnittstelle zur Nutzung von ProB;
• BMotion Studio: Web-Oberfläche für die ProB Java API;
• ProB for Rodin: Plug-in für das Eclipse-basierte Rodin;
• ProB for TLA: Nutzung von ProB als Validator für TLA (Temporal Logic of Actions);
24
http://stups.hhu.de/ProB/, Abgerufen am 16. Oktober 2015
1
HINTERGRUND
9
Abbildung 3: ProB Tcl/Tk ist eine Standalone Version von ProB.
Für die Erstellung und den Test von B basierten Automaten eignet sich ProB Tcl/Tk (siehe Abbildung 3). Für die weitergehende Nutzung von B außerhalb dieses Kontexts ist
die ProB Java API hilfreich. Die Nutzung einer in B definierten Maschine erfolgt damit
wahlweise über eine Groovy-Konsole in der Web-Oberfläche25 (siehe Abbildung 4) oder
direkt in der Java-Anwendung. Im Listing 2 wird dafür in den Zeilen 7 bis 17 zuerst ein
ProB-basierter Server gestartet und anschließend die Methode initMachine(String
fileName) aufgerufen. Diese ab Zeile 24 deklarierte Methode lädt und initialisiert eine
Maschine für die weitere Verwendung mit der ProB Java API.
Listing 2: Server mit Web-Oberfläche auf Basis der ProB Java API.
public static void main(String[] args) {
2
// Enable Groovy
de.prob.servlet.Main.local = true;
de.prob.servlet.Main.restricted = false;
4
6
// Start Server
new Thread(new Runnable() {
@Override
public void run() {
try {
WebConsole.run("", "127.0.0.1", 17080);
} catch (Exception e) {
8
10
12
25
http://www3.hhu.de/stups/prob/index.php/ProB_Java_API_Tutorial#How_to_open_
the_Groovy_Shell, Abgerufen am 17. Oktober 2015
1
HINTERGRUND
10
Abbildung 4: ProB 2 Webclient mit einer Schalter-Maschine (Switch).
e.printStackTrace();
14
}
}
}).start();
16
18
// Load and initialize a machine based on B
initMachine("./src/main/b/switch.mch");
20
}
22
private static void initMachine(String fileName) {
24
26
28
30
32
34
36
Api api = de.prob.servlet.Main.getInjector().getInstance(Api.class);
StateSpace stateSpace = api.b_load(fileName);
Trace trace = new Trace(stateSpace);
trace = trace.execute("$setup_constants");
trace = trace.execute("$initialise_machine");
AnimationSelector animationSelector = de.prob.servlet.Main.getInjector().
getInstance(AnimationSelector.class);
animationSelector.addNewAnimation(trace);
animationSelector.registerAnimationChangeListener(
new IAnimationChangeListener() {
2
LÖSUNGSENTWICKLUNG
11
@Override
public void traceChange(Trace currentTrace, boolean
currentAnimationChanged) {
}
@Override
public void animatorStatus(boolean busy) {
}
});
38
40
42
44
}
2
Lösungsentwicklung
Hinsichtlich der im Folgenden vorgestellten IoT-Referenzarchitektur liegt der Schwerpunkt auf den im vorherigen Abschnitt 1.1.3 ab Seite 4 aufgeführten Herausforderungen des Internet der Dinge. Außerdem wird abschließend das Zusammenspiel dieser
Referenzarchitektur mit den in Abschnitt 1.2 ab Seite 6 erläuterten Formalen Methoden
gezeigt, und eine entsprechende Lösung vorgestellt, die ProB (siehe Abschnitt 1.2.3 ab
Seite 8) über einen Nachrichtenbus mit dieser Referenzarchitektur verbindet.
2.1
Referenzarchitektur
Insellösungen überwiegen in der zunehmend unübersichtlichen IoT-Welt (siehe Abbildung 5). Zahlreiche Unternehmen versuchen sich zu positionieren und eigene Standards
zu etablieren, was durch die Vielzahl der Konsortien26 rund um IoT noch unterstrichen
wird. Damit nicht genug, auch Forschungseinrichtungen wie The TerraSwarm Research
Center27 oder Salzburg Research28 tummeln sich in diesem Bereich mit teils akademischen, teils monetären Interessen.
Insgesamt ähnelt die IoT-Landschaft (siehe Abbildung 5) dem anfänglichen Markt für
mobile Ökosysteme. Bei diesen sind letztendlich nur einige wenige dauerhaft Relevant –
zum jetzigen Zeitpunkt in erster Linie Android und auf Platz zwei Apple. Glaubt man
VisionMobile [Vis15, 25], dann stehen die Chancen in der IoT-Welt aktuell für Google
Nest29 , Samsung SmartThings30 und die Eclipse Foundation31 gut.
2.1.1
Konzepte
Die am Markt befindlichen Lösungen unterscheiden sich unter anderem darin, wo
die Anwendungslogik liegt: Wahlweise in der Cloud wie bei SmartThings, auf einem
26
http://ianskerrett.wordpress.com/2014/12/11/abcs-of-iot-consortiums/, Abgerufen am 16. Oktober 2015
27
http://www.terraswarm.org/index.html, Abgerufen am 16. Oktober 2015
28
http://www.salzburgresearch.at, Abgerufen am 16. Oktober 2015
29
http://nest.com/, Abgerufen am 16.10.2015
30
http://www.smartthings.com/, Abgerufen am 16. Oktober 2015
31
http://iot.eclipse.org/, Abgerufen am 16. Oktober 2015
2
LÖSUNGSENTWICKLUNG
12
Abbildung 5: Die Internet-der-Dinge-Landschaft [RT13].
Gateway wie bei QIVICON32 oder eher auf den einzelnen Geräten wie üblicherweise
bei Wearables. Oft handelt es sich auch um eine Kombination, bei der Geräte einen Teil
der Logik autark selber übernehmen, übergreifende Szenarien jedoch über ein Gateway
oder durch eine Cloud-Anwendung gesteuert werden. Ein Cloud-Zugang wird von allen
gängigen Plattformen obligatorisch angeboten. In einigen Fällen mit Fokus auf die Internetunabhängigkeit eher nur mit administrativen Funktionen und einem Remote-Zugang
wie bei QIVICON, in anderen Fällen als zentrale Steuereinheit wie bei dem Applikationsorientierten IFTTT33 .
Allen Ansätzen gemein ist, dass ein zentraler Bus vonnöten ist. Über diesen werden
die Nachrichten unter den Geräten ausgetauscht (siehe Abbildung 6). Unterschiedliche
ereignisorientierte Bussysteme können auch kombiniert werden, um so Geräte mit einem
anderen Bussystem anzubinden und Nachrichten zwischen unterschiedlichen Plattformen auszutauschen (Event Bus oder Message Bus werden normalerweise synonym verwendet). Im Falle von zueinander inkompatiblen Bussystemen kommen in der Regel
eine Bridge oder ein Gateway zur Harmonisierung zum Einsatz. Eine Bridge ist wie zum
Beispiel im Falle der Philips Hue34 Lampen und Leuchten meist gerätespezifisch ausge32
http://www.qivicon.com/de/produkte/produktinformationen/qivicon-home-base/,
Abgerufen am 18. Oktober 2015
33
http://ifttt.com/, Abgerufen am 18. Oktober 2015
34
http://www2.meethue.com/de-de/productdetail/philips-hue-bridge, Abgerufen am 16.
2
LÖSUNGSENTWICKLUNG
13
Abbildung 6: System aus Systemen mit Nachrichtenbus.
legt, ein Gateway35 kann mehrere Vernetzungsstandards unterstützen und übergreifende Steuerungsaufgaben übernehmen. Je nach Szenario lassen sich mehrere Bridges auch
mit einem Gateway kombinieren. Oft kommt beispielsweise UPnP (Universal Plug and
Play36 ) in einem lokalen Netz zum Einsatz und wird dann via dem „Message Queuing
Telemetry Transport“ Protokoll (kurz MQTT37 ) weitergeleitet.
Das lizenzfreie MQTT wurde 1999 von Dr. Andy Stanford-Clark (IBM) and Arlen
Nipper (Cirrus Link Solutions) entwickelt [Nib14]. Mittlerweile hat sich dieses PublishSubscribe-Protokoll in der Praxis nicht nur für M2M-Szenarien, sondern auch für IoTund mobile Anwendungen bewährt. Facebook nutzt MQTT beispielsweise für den
Facebook Messenger38 . Im Internet der Dinge gilt das später auch für die Umsetzung
(siehe Abschnitt 2.1.2 ab Seite 14) gewählte MQTT als de-fakto-Standard für den Nachrichtenaustausch (sowohl TCP/IP-basiert als auch nicht-TCP/IP-basiert). Zu den Vorteilen zählen freie und weitreichende Verfügbarkeit für die wichtigsten Clients, ressourcenschonendes und somit für den Energieverbrauch günstiges Verhalten und OASIS Standardisierung39 . Die grundsätzliche Funktionsweise dieses Nachrichten-Protokolls ist
recht simpel: Es wird ein sogenannter Broker benötigt, der Nachrichten verteilt und deren Empfänger und Sender verwaltet; das Abonnieren (engl. subscribe) und Veröffentlichen (engl. publish) von Nachrichten erfolgt durch die jeweiligen MQTT-Clients. Die
Nachrichten bestehen im Wesentlichen aus einem Thema (engl. topic) und den Nutzdaten (engl. payload). Dem Topic kommt eine zentrale Funktion zu, da es gleichzeitig auch
als Nachrichtenfilter dient.
Oktober 2015
35
http://www.computerwoche.de/a/google-kuendigt-eigenen-wlan-router-fuerssmart-home-an,3214578, Abgerufen am 16. Oktober 2015
36
http://en.wikipedia.org/wiki/Universal_Plug_and_Play, Abgerufen am 18. Oktober 2015
37
http://mqtt.org/), Abgerufen am 16. Oktober 2015
38
http://www.facebook.com/notes/facebook-engineering/building-facebookmessenger/10150259350998920, Abgerufen am 16. Oktober 2015
39
http://docs.oasis-open.org/mqtt/mqtt/v3.1.1/os/mqtt-v3.1.1-os.html, Abgerufen
am 16. Oktober 2015
2
LÖSUNGSENTWICKLUNG
14
Einige Systeme erlauben die Integration und Konfiguration von Geräten sehr komfortabel via automatischer Verbindung (engl. pairing) zum Beispiel über Apple Bonjour40 ,
andere wie openHAB41 in Version 1 verlangen Konfigurationsdateien mit konkreten Parametern. Die eigentliche Logik kann dann in einer domänenspezifischen Sprache implementiert oder über dynamische Regeln definiert werden. Hier unterscheiden sich die Systeme hinsichtlich der erlaubten Komplexität und dem Bedienkomfort erheblich. Eclipse
SmartHome42 verfügt beispielsweise zum jetzigen Zeitpunkt über keine eigene Regelmaschine (siehe Abschnitt 2.2.2, Seite 25), so dass alles explizit programmiert werden muss.
IFTTT nennt seine Regeln Rezepte (engl. recipies) und erlaubt nur Auslöser (engl. trigger)
und Aktionen (engl. actions) aber keine Bedingungen. Node-RED43 hingegen unterstützt
sowohl eine grafische Herangehensweise als auch JavaScript und eignet sich somit gut
für die Umsetzung eines Durchstichs wie in dieser Bachelorarbeit (siehe Abschnitt 2.1.2
ab Seite 14).
Node-RED ist ein quelloffenes Werkzeug von IBM Emerging Technology44 , um Hardware und Software im Internet der Dinge miteinander zu verbinden. Es verfügt über eine
visuelle Benutzungsschnittstelle, in der die Funktionen eines Systems als Knoten dargestellt werden. Es gibt zahlreiche Knotentypen, darunter diverse Kommunikationsprotokolle und Hardwareschnittstellen. Die einzelnen Knoten werden über Ein- und Ausgänge als Fluss (engl. flow) miteinander in Beziehung gesetzt. Dieser Fluss wird als JSONDokument verwaltet und kann dadurch einfach ausgetauscht werden. Da Node-RED
auf Node.js45 basiert, können Node.js-JavaScript-Pakete (npm46 ) hinzugefügt und eigene
JavaScript-Funktionen mit einem Rich-Text-Editor ergänzt werden (siehe A.2 ab Seite 32).
Node-RED bietet bereits eine visuelle Oberfläche, doch wird häufig noch eine Endkunden taugliche Benutzungsschnittstelle für die Konfiguration und Benutzerinteraktion
benötigt, die nicht durch Automatismen abgedeckt sind. Dabei kann es sich um eine
mobile App, eine Website oder eine spezifische Bedieneinheit handeln. Als Lingua Franca
des Datenaustauschs zwischen diesen Komponenten hat sich die Web-orientierte Anbindung via JSON47 (engl. JavaScript Object Notation) über REST48 (engl. Representational
State Transfer) etabliert – in Kombination mit Server-Sent Events (SSE)49 teilweise sogar als eigenständige Alternative zu Bussystemen wie MQTT. Die meisten Plattformen
wie zum Beispiel Eclipse SmartHome und openHAB in der zweiten Version kombinieren
gleich einen oder mehrere Busse mit einer auf REST basierenden Programmierschnittstelle (RESTful API).
40
http://www.apple.com/support/bonjour/, Abgerufen am 16. Oktober 2015
http://www.openhab.org/, Abgerufen am 16. Oktober 2015
42
http://www.eclipse.org/smarthome/, Abgerufen am 16. Oktober 2015
43
http://nodered.org/, Abgerufen am 16. Oktober 2015
44
http://www.ibm.com/blogs/et, Abgerufen am 22. Oktober 2015
45
http://nodejs.org/, Abgerufen am 16. Oktober 2015
46
http://de.wikipedia.org/wiki/Node_Package_Manager, Abgerufen am 27. Oktober 2015
47
http://www.ecma-international.org/publications/files/ECMA-ST/ECMA-404.pdf,
Abgerufen am 16. Oktober 2015
48
http://en.wikipedia.org/wiki/Representational_state_transfer, Abgerufen am 16.
Oktober 2015
49
http://www.w3.org/TR/eventsource/, Abgerufen am 16. Oktober 2015
41
2
LÖSUNGSENTWICKLUNG
2.1.2
15
Umsetzung
Die wesentliche Zutat für eine IoT-Plattform ist ein ereignisbasierter Bus für den Nachrichtenaustausch, der mit der Laufzeitumgebung harmoniert (siehe Abschnitt 2.1.1 ab
Seite 11). Dieser kann sowohl von den Geräten direkt oder indirekt über eine Bridge bzw.
ein Gateway genutzt werden. Bewährt hat sich für diesen Bus MQTT (siehe Abschnitt
2.1.1, Seite 13). Als Vermittler zwischen den Geräten ist der quelloffene MQTT Broker
Mosquitto50 gängig. Dieser ist als ausführbare Anwendung für zahlreiche Betriebssysteme wie Windows, Mac OS und diverse Unix-Varianten (u. a. Rasperry Pi) erhältlich. Es
ist während der Entwicklung nützlich, den Broker im wortreichen Modus (engl. verbose)
via mosquitto -v zu starten, um den Nachrichtenfluss beobachten zu können.
Auch an Client-Implementierungen mangelt es nicht. Unterstützt werden alleine schon
durch das Eclipse Paho Projekt51 die Programmiersprachen C, C++, Java, JavaScript, Lua,
Python und Go. Daneben gibt es beispielsweise noch Clients für Delphi, Erlang, .Net,
Objective-C, PERL, PHP und Ruby. Die Java-Variante von Eclipse Paho kommt hier auch
zur Anbindung der ProB Java API zum Einsatz (siehe Abschnitt 2.2 ab Seite 19).
Für die Hardwareintegration auf Basis eines Arduino bzw. Genuino Gerätes kombiniert
mit Sensoren (z. B. Seeed Studio Grove52 ) gibt es den mit dem Arduino Ethernet Shield
kompatiblen „Arduino Client for MQTT“ als Bilbliothek53 . Ein einfacher MQTT-Client
könnte wie in Listing 3 aussehen54 .
Listing 3: Arduino als einfacher MQTT-Client.
2
#include <SPI.h>
#include <Ethernet.h>
#include <PubSubClient.h>
4
6
8
10
12
// the media access control (ethernet hardware) address for the shield
byte MAC[] = { 0x90, 0xA2, 0xDA, 0x0D, 0xAD, 0xD3 };
EthernetClient ethClient;
PubSubClient mqttClient(ethClient);
IPAddress broker(192, 168, 0, 12);
// setup function runs once when you press reset or power the board
void setup() {
14
// wait for connection to network and IP assignment
Ethernet.begin(MAC);
// set broker...
mqttClient.setServer(broker, 1883);
// ...and connect client
mqttClient.connect("grove_device");
16
18
20
50
http://mosquitto.org/, Abgerufen am 16. Oktober 2015
http://www.eclipse.org/paho/, Abgerufen am 16. Oktober 2015
52
http://www.seeedstudio.com/wiki/Grove_IoT_Starter_Kits_Powered_by_AWS, Abgerufen am 10. Oktober 2015.
53
http://pubsubclient.knolleary.net/, Abgerufen am 16. Oktober 2015
54
arduino/SimpleMQTT.ino, Revision 05b0c70b
51
2
LÖSUNGSENTWICKLUNG
16
}
22
24
// the loop function runs over and over again forever
void loop() {
// publish message
mqttClient.publish("formaliot/grove_device", "hello world");
// process incoming messages and maintain connection to server
mqttClient.loop();
26
28
30
delay(1000);
32
}
Das Topic der Nachricht ist in der Form Project/Device/Sensor aufgebaut, um anderen Clients wie im Listing 4 in den Zeilen 9 bis 11 ein selektives Abonnieren der Nachrichten zu erlauben und wie ab Zeile 14 den Payload zu verarbeiten.
Listing 4: Arduino als MQTT-Subscriber.
void setup() {
2
// wait for connection to network and IP assignment
Ethernet.begin(MAC);
// set broker...
mqttClient.setServer(broker, 1883);
// ...and connect client
mqttClient.connect("grove_device");
// set topic and callback for incoming messages
mqttClient.setCallback(callback);
mqttClient.subscribe("formaliot/grove_device/#");
4
6
8
10
12
}
14
// the callback functions handles subscribed messages
void callback(char* topic, byte* payload, unsigned int length) {
16
String response = "";
for (int i = 0; i < length; i++) {
response += (char)payload[i];
}
Serial.print(response);
18
20
22
}
Basierend auf MQTT fungiert der Client als Agent55 und sendet die Sensorwerte (siehe
Listing 5, Zeile 10, 12 und 22) an den Nachrichtenbus – in einer Produktionsumgebung
sollte der Versand noch logisch und technisch sinnvoll hinsichtlich der Last optimiert
werden (siehe Listing 5 ab Zeile 16).
Listing 5: Arduino als MQTT-Publisher.
2
double sensorSum = 0;
int sensorValuesCount = 0;
55
arduino/FormalIoT.ino, Revision 05b0c70b
2
4
LÖSUNGSENTWICKLUNG
17
void loop() {
int newSensorValue = digitalRead(3);
if (buttonValue != newSensorValue) {
buttonValue = newSensorValue;
if (buttonValue == HIGH) {
mqttClient.publish("formaliot/grove_device/button", "on");
} else {
mqttClient.publish("formaliot/grove_device/button", "off");
}
}
6
8
10
12
14
sensorSum += analogRead(A0);
sensorValuesCount++;
if (sensorValuesCount == 2000) {
char str[4];
// calculate average and convert to payload
String(sensorSum/2000).toCharArray(str, 4);
mqttClient.publish("formaliot/grove_device/sensor", str);
sensorSum = 0;
sensorValuesCount = 0;
}
16
18
20
22
24
26
// process messages and maintain connection to server
mqttClient.loop();
28
}
Für den Rückkanal wird ebenfalls der Nachrichtenbus genutzt und auf eingehende Nachrichten wie in Listing 4 gelauscht. Gefiltert wird auf das Topic formaliot/
grove_device/actuator, indem die Zeile 11 in Listing 4 durch mqttClient.subscribe
("formaliot/grove_device/actuator"); ersetzt wird. Die Callback-Methode in Listing 6) aktualisiert die Aktuatoren nun abhängig von der eingehenden Nachricht.
Listing 6: Arduino verarbeitet MQTT Payload für Aktuatoren.
void callback(char* topic, byte* payload, unsigned int length) {
2
String response = "";
for (int i = 0; i<length; i++) {
response += (char)payload[i];
}
4
6
// check payload and set current actuator’s state accordingly
if (response.indexOf("on")>-1) {
digitalWrite(7, HIGH);
} else if (response.indexOf("off")>-1) {
digitalWrite(7, LOW);
}
8
10
12
14
}
Zum Anbinden- und Zusammenführen unterschiedlicher Dienste und Geräte (zum Beispiel ein Embedded Device auf Basis eines Arudino) ist ein Gateway notwendig. Dieses
2
LÖSUNGSENTWICKLUNG
18
bildet außerdem die Anwendungslogik ab. Die auf der Google V8 JavaScript Engine56
basierende Laufzeitumgebung Node.js bietet sich an, da deren Programmierung zugänglich ist und es bereits zahlreiche Module gibt, um Dienste von Dritten zu nutzen und
Hardware direkt anzusprechen – unabhängig davon, ob diese direkt am Rechner angeschlossen oder indirekt verbunden sind. Ein weiterer Vorteil von Node.js ist, dass mit
Node-RED (siehe Abschnitt 2.1.1, Seite 14) ein darauf basierendes grafisches Werkzeug
verfügbar ist, das sich zum Modellieren der Konfiguration, der Steuerung und der Abhängigkeiten eignet57 .
Abbildung 7: Node-RED Funktionselement für eingehende MQTT-Nachrichten.
Für Node.js gibt es optionale MQTT-Unterstützung, bei Node-RED ist das gleich von
Haus aus dabei (siehe Abbildung 7). Zur Verfügung stehen folgende Funktionselemente:
• MQTT Eingabe: Verbindet sich mit dem angegebenen MQTT Broker und abonniert
ein Topic. Es sind auch Stellvertretersymbole (engl. wildcards) erlaubt, um Nachrichten zu filtern.
• MQTT Ausgabe: Verbindet sich mit dem angegebenen MQTT Broker und veröffentlicht Nachrichten u. a. mit Topic und Payload.
Für eine Vielzahl an Geräten, die direkt am Gateway angeschlossen sind oder indirekt
über andere Schnittstellen als MQTT Verwendung finden, gibt es zahlreiche zusätzliche
56
http://code.google.com/p/v8/, Abgerufen am 16. Oktober 2015
node-red/device.json, Revision e4163a36
57
2
LÖSUNGSENTWICKLUNG
19
Funktionselemente58 wie z. B. „Hue Nodes for Node Red” (Paketname ttb-node-hue) zur
Nutzung von Philips Hue Lampen und Leuchten.
Sollte das Angebot an Paketen für Node-RED einmal nicht ausreichen, kann auch auf
Node.js-JavaScript-Pakete oder gleich auf eigenes JavaScript innerhalb von Funktionsblöcken (function node) zurückgegriffen werden (siehe A.2 ab Seite 32).
Nachdem nun bereits ein Bus zum Nachrichtenaustausch vorhanden ist und die Einbindung von Geräten und deren Konfiguration innerhalb der Benutzungsoberfläche möglich sind, fehlt es noch an einer interaktiven Steuerung.
Abbildung 8: Node-RED Funktionselement zum Injizieren von Nachrichten.
Das interaktive Initiieren von Abläufen gelingt am einfachsten mit dem inject-Knoten
(siehe Abbildung 8). Durch Betätigung der links am Knoten angeordneten Schaltfläche
wird ein Fluss gestartet und eine Nachricht an ein verbundenes Gerät gesendet. Mithilfe
der Start- (engl. inject once at start) und Wiederholungseinstellung (engl. repeat) können
Abläufe auch automatisiert werden. Zur Verfügung stehen Intervalle sowie Wochentage
und Uhrzeiten.
Die Kontrolle des Flusses übernehmen wahlweise wieder Funktionsblöcke oder ganz ohne Programmierung der switch-Knoten (siehe Abbildung 9). Das switch leitet den Fluss
abhängig von der eingehenden Nachricht und basierend auf Regeln an unterschiedliche
Ausgänge weiter.
58
http://flows.nodered.org/, Abgerufen am 10. Oktober 2015
2
LÖSUNGSENTWICKLUNG
20
Abbildung 9: Node-RED Funktionselement zum Auswerten von Nachrichten.
2.2
Anbindung an ProB
Bei dem Internet der Dinge (siehe Abschnitt 1.1 ab Seite 1) handelt es sich um ein System aus Systemen (siehe Abbildung 6), das zahlreiche Zustände annehmen kann. Die
Modellierung solch zunehmend komplexer Lösungen erfordert die Berücksichtigung sowohl der Soft- als auch der Hardware. Formale Methoden (siehe Abschnitt 1.2 ab Seite 6)
erlauben die Spezifikation der Anforderungen, deren Validierung und den Nachweis
spezifischer und teils sicherheitsrelevanter Eigenschaften [KS11]. Dies führt sowohl zu
einer Qualitätsverbesserung durch Fehlervermeidung als auch zu einer früheren Fehlererkennung. Außerdem hilft eine formale Herangehensweise dabei, die Korrektheit von
Programmen bzgl. der Spezifikation zu sichern.
2.2.1
Maschinen und Nachrichten
Die bei der B Methode verwendeten abstrakten Maschinen umfassen
• Zustände, die aus einer Menge an Variablen bestehen und
• Operationen, durch die der Zustand geändert wird.
Diese Zustände und Operationen bilden die Schnittstelle einer Maschine (siehe Abbildung 10) und müssen nur noch über einen Bus an eine IoT-Lösung angebunden werden.
Als Konvention bieten sich Operationen als Eingabe und die Zustände als Ausgänge einer Maschine an. Dies entspricht auch der Nutzung durch gängige ProB-Werkzeuge wie
2
LÖSUNGSENTWICKLUNG
21
ProB Tcl/Tk (siehe Abbildung 3). Die Integritäts- und Konsistenzprüfung durch Invarianten und Vorbedingungen (engl. preconditions) wird weiterhin intern durch die Maschine sichergestellt.
Abbildung 10: Maschine mit Ein- und Ausgängen.
Die Methode executeOperation(String operation, String payload)59 in Listing 7 basiert auf dem Beispiel aus Abschnitt 1.2.3 auf Seite 8 und führt auf der aktuell
geladenen Maschine die angegebene Operation aus: In Zeile 18 ohne und und in Zeile 20
mit Payload.
Zusätzlich zu den in ProB bereits vordefinierten Operationen gibt es noch die Implementierung der $load-Funktionalität ab Zeile 26. Die zugehörige loadMachine-Methode erlaubt das Laden und Initialisieren neuer Maschinen zur Laufzeit.
Listing 7: Operation mit der ProB Java API ausführen.
2
4
// Access to ProB API
private static Api api =
de.prob.servlet.Main.getInjector().getInstance(Api.class);
private static AnimationSelector animationSelector =
de.prob.servlet.Main.getInjector().getInstance(AnimationSelector.class);
6
8
private static void executeOperation(String operation,
String payload) {
// Special operation to load a machine.
if (operation.equals("$load")) {
loadMachine(payload);
} else {
Trace trace = animationSelector.getCurrentTrace();
if (operation.equals("$any")) {
trace = trace.anyOperation(null);
} else if (payload.isEmpty()) {
trace = trace.execute(operation);
} else {
trace = trace.execute(operation, payload);
}
animationSelector.changeCurrentAnimation(trace);
}
10
12
14
16
18
20
22
24
}
59
java/biz/wolter/formaliot/Main.java, Revision 7dc9f371
2
26
LÖSUNGSENTWICKLUNG
22
private static void loadMachine(String fileName) {
StateSpace stateSpace = api.b_load(fileName);
Trace trace = new Trace(stateSpace);
if (trace.canExecuteEvent("$setup_constants"))
trace = trace.execute("$setup_constants");
if (trace.canExecuteEvent("$initialise_machine"))
trace = trace.execute("$initialise_machine");
animationSelector.addNewAnimation(trace);
28
30
32
34
}
Sowohl spezielle Operation wie das $load als auch in B definierte Operationen werden
als MQTT-Nachrichten über den Bus ausgetauscht. Dies geschieht durch Nachrichten mit
dem Topic formaliot/notify/[operation] und dem zur Operation optional dazugehörigen Prädikat im Payload. Eine $load-Nachricht wird durch das Topic formaliot/
notify/$load und einen Dateipfad wie z. B. "./src/main/b/switch.mch" im Payload
beschrieben. Der Empfang und die Ausführung auf der Maschine erfolgen durch den
vereinfachten Programmcode in Listing 8. Zeile 29 abonniert Nachrichten, die dann in
der Zeile 24 als Operation ausgeführt werden.
Listing 8: Empfang und Verarbeitung von MQTT Nachrichten mit der ProB Java API.
2
4
6
8
10
// MQTT Broker address
private static String broker = "tcp://127.0.0.1:1883";
private static MemoryPersistence persistence =
new MemoryPersistence();
private static MqttClient subscriber;
private static String subscriberId = "formaliotSubscriber";
private static String subscribeTopic = "formaliot/notify/";
private static void initEventBus() {
// Setup subscriber
subscriber = new MqttClient(broker, subscriberId, persistence);
MqttConnectOptions connOpts = new MqttConnectOptions();
connOpts.setCleanSession(true);
12
14
16
subscriber.setCallback(new MqttCallback() {
@Override
public void messageArrived(String topic, MqttMessage message)
throws Exception {
18
20
String payload = new String(message.getPayload());
String operation = topic.split(subscribeTopic)[1];
executeOperation(operation, payload);
22
24
}
});
26
subscriber.connect(connOpts);
subscriber.subscribe(subscribeTopic + "+", 2);
28
30
}
2
LÖSUNGSENTWICKLUNG
23
Neben dem Empfang von Nachrichten als Eingabe ist auch der Versand erforderlich,
damit Veränderungen der Maschinenzustände ausgegeben werden können. Dies erfolgt
wie in Lising 9 ebenfalls via MQTT. Die im IAnimationChangeListener festgestellten
Zustandsänderungen stehen in der ProB Java API mit den aktuellen und vorherigen Werte zur Verfügung. In diesem Fall wird in Zeile 47 jeder geänderte Wert erst einzeln serialisiert und dann ab Zeile 51 inklusive Variablenbezeichner als Nachricht veröffentlicht. Der
Versand erfolgt für jeden Wert separat, damit sowohl ein Gateway als auch andere Geräte
diese selektiv abonnieren können. Das Topic ist formaliot/stateChanged/[variable]
, wobei [variable] dem Variablenbezeichner entspricht. Der Payload enthält eine String
mit dem aktuellen Wert im JSON-Format.
Listing 9: Verarbeitung von Änderungen mit der ProB Java API.
private static void initProB() {
2
4
6
8
animationSelector.registerAnimationChangeListener(
new IAnimationChangeListener() {
@Override
public void traceChange(Trace currentTrace,
boolean currentAnimationChanged) {
State state = currentTrace.getCurrentState();
State prevState = currentTrace.getPreviousState();
Map<IEvalElement, AbstractEvalResult> values = state.getValues();
Map<IEvalElement, AbstractEvalResult> prevValues =
prevState.getValues();
10
12
14
for (Entry<IEvalElement,AbstractEvalResult> entry :
values.entrySet()){
16
18
ClassicalB key = (ClassicalB) entry.getKey();
EvalResult value = (EvalResult) entry.getValue();
20
// Try catch is needed to deal with uninitialized values...
EvalResult prevValue;
try {
prevValue = (EvalResult) prevValues.get(key);
} catch (Exception e) {
// ...and this forces to send the initial value
prevValue = null;
}
22
24
26
28
30
if (!value.equals(prevValue)) {
publishChangedVariable(key,value);
}
32
}
34
}
36
38
40
@Override
public void animatorStatus(boolean busy) {
}
});
2
LÖSUNGSENTWICKLUNG
24
}
42
44
private static void publishChangedVariable(ClassicalB key,
EvalResult value) {
// A little bit of marshalling for the message bus
JsonElement json = Serializer.Serialize(value.translate().getValue());
String jsonString = json.toString();
46
48
// Turn key value pair into a MQTT message...
MqttMessage message = new MqttMessage(jsonString.getBytes());
publisher.publish(publishTopic + key.getCode(), message);
50
52
}
Die Serialisierung der von ProB im Paket de.prob.translator.types bereitgestellten
und von der Klasse BObject abgeleiteten Datentypen erfolgt über die statische Methode biz.wolter.formaliot.utils.Serializer(BObject value)60 . Zu berücksichtigen ist, dass Sequenzen und Mengen beide als JSON-Arrays serialisiert werden. Außerdem werden von Tupel (A,B) nur die Werte B und nicht die Schlüssel A berücksichtigt;
Dadurch fällt nicht mehr ins Gewicht, dass die verwendete Version der ProB Java API
Sequenzen mit weniger als drei Elementen als Menge von Tupel behandelt; als die hier
verwendeten JSON-Arrays unterscheiden sich Mengen aus Tupel und Sequenzen nicht.
Abbildung 11: Node-RED JSON-Verabreitung.
Am einfachsten verarbeitet ein Client den so versandten Payload, indem er diesen wie
hier mit Node-RED zuerst wieder von String in JSON verwandelt und dann direkt in
60
java/biz/wolter/formaliot/utils/Serializer.java, Revision e56308a9
2
LÖSUNGSENTWICKLUNG
25
JavaScript weiterverarbeitet (siehe Abbildung 11). Der json-Knoten deserialisiert den
kompletten Payload und in dem im Flow folgenden Funktionsknoten wird dann beispielsweise das erste Element aus dem erzeugten Array gelesen (siehe Listing 10).
Listing 10: Node-RED-Programmcode zur Verabeitung eines JSON-Payload.
2
msg.payload = msg.payload[0];
return msg;
Sowohl dieses Element, als auch das Array und der Payload als Zeichenkette werden
zur Verdeutlichung durch einen debug-Knoten ausgegeben und sind in Abbildung 11
rechts in der Konsole inklusive Typ zu sehen61 . Alternativ kann ein Funktions-Knoten
auch mehrere Ausgänge haben und die Ergebnisse darauf verteilen (siehe Listing 11).
Listing 11: Node-RED-JSON-Verarbeitung mit zwei Ausgängen.
2
4
var jsonPayload = msg.payload;
msg = [];
msg[0] = {payload:jsonPayload[0]};
msg[1] = {payload:jsonPayload[1]};
return msg;
2.2.2
Geräteinteraktion und Regeln
Die grundsätzliche Interaktion mit Geräten, oder einem komplexen System aus mehreren Geräten, erfolgt durch den Austausch von Nachrichten. Dafür werden die Eigenschaften des Gesamtsystems als Variablen und die Funktionen als Operationen einer Maschine wie in Listing 12 definiert62 ; hier handelt es sich um ein Modell eines einfachen
Smart Home, dass aus zwei Leuchten A und B sowie einem Bewegungsmelder besteht.
Die Leuchten verfügen jeweils über eine Variable bulb_state, die den Schaltzustand
hält und die Operation Toggle() und Set(new_state) zum Ändern des Zustands (je
nach Leuchte jeweils mit a oder b im Bezeichner). Die Bewegung für den Bewegungsmelder wird mit der Methode SetMotion(new_motion) gesetzt und über die Variable
motion_detector gelesen.
Listing 12: Smart Home als in B spezifizierter Automat.
2
4
6
8
10
MACHINE SmartHome
SETS STATES = {on,off}
VARIABLES
bulb_a_state, bulb_b_state, motion_detector
INVARIANT
bulb_a_state : STATES & bulb_b_state : STATES
& motion_detector : NATURAL
INITIALISATION
bulb_a_state := off || bulb_b_state := off || motion_detector := 0
OPERATIONS
61
node-red/bulbset.json, Revision 5d98bd40
62
b/smarthome.mch, Revision c7faac8b
2
12
14
16
18
20
22
24
26
28
LÖSUNGSENTWICKLUNG
SetMotion(new_motion) =
PRE new_motion : NATURAL THEN
motion_detector := new_motion
END;
ToggleA =
BEGIN
IF bulb_a_state = on THEN bulb_a_state
ELSE bulb_a_state := on END
END;
SetA(new_state) =
PRE new_state : STATES THEN bulb_a_state
ToggleB =
BEGIN
IF bulb_b_state = on THEN bulb_b_state
ELSE bulb_b_state := on END
END;
SetB(new_state) =
PRE new_state : STATES THEN bulb_b_state
END
26
:= off
:= new_state END;
:= off
:= new_state END
Node-RED kommuniziert mit der ProB Java API über den MQTT-Broker mit der Standardadresse tcp://localhost:188363 . Dies kann direkt in den Ein- und Ausgabeknoten
für MQTT festgelegt und in der Information-Sidebar bearbeitet werden. Eine Maschine
wird durch einen „mqtt out“-Knoten mit der über einen inject-Knoten injizierten Nachricht geladen und initialisiert, die aus dem Topic formaliot/notify/$load und einem
Dateipfad wie "./src/main/b/smarthome.mch" im Payload besteht. Operationen auf
der Maschine werden ebenfalls via MQTT gesandt und dafür über inject-Knoten gesetzt.
Das Ausschalten einer Leuchte erfolgt mit der Operation formaliot/notify/SetA im
Topic und dem Prädikat "new_state=off" im Payload. Der Bewegungsmelder erhält
seinen Wert über die Nachricht mit der Operation formaliot/notify/SetMotion im
Topic und dem Prädikat "new_motion=0" im Payload.
Veränderungen des Maschinenzustands können ohne weiteres Zutun in der Weboberfläche von ProB kontrolliert werden. Natürlich lassen sich diese auch als Nachrichten
abonnieren und in Node-RED weiterverarbeiten. Dies gelingt über einen „mqtt in“Knoten für Nachrichten der Form formaliot/stateChanged/+. Bei dem + handelt es
sich um einen Platzhalter für beliebige Nachrichten dieser Struktur. Es steht somit für
die möglichen Variablennamen, deren Unterscheidung üblicherweise in einem switchKnoten über msg.topic erfolgt. Beispielsweise über einen regulären Ausdruck oder mit
Hilfe des Vergleichsoperators und dem Wert formaliot/stateChanged/bulb_a_state
. Hilfreich ist die Ausgabe des Topics inklusive Variablennamen und des zugehörigen
aktuellen Wertes aus dem Payload im Debug-Bereich von Node-RED. Dafür wird ein
debug-Knoten mit dem „mqtt in“-Knoten verbunden (siehe Abbildung 11).
Dieses Verhalten kann nun für eine Regelmaschine (engl. rules engine) genutzt werden64 .
Eine Regelmaschine ist letztendlich nur ein anderes Berechnungsmodell als Alternati63
node-red/smarthome.json, Revision e4163a36
64
node-red/rule.json, Revision 4411ce13
2
LÖSUNGSENTWICKLUNG
27
ve zur imperativen Programmierung [Fow09]. Üblicherweise bestehen Regeln aus Auslösern, Bedingungen und Aktionen und ähneln damit einer Folge von bedingten Anweisungen. Ein großer Vorteil von Regelmaschinen ist deren einfache Struktur, die von
einigen Systemen grafisch abgebildet wird, andere greifen auf populäre Sprachen wie
JavaScript oder domänenspezifische Sprachen (engl. Domain Specific Language65 , kurz
DSL) zurück.
Abbildung 12: Einfache Regel in Node-RED definiert.
In diesem Fall könnte auf Veränderungen der Variable motion_detector gelauscht werden, um davon abhängig eine Leuchte ein- oder auszuschalten. Diese Veränderung kann
direkt in ProB stattfinden oder aus Node-RED heraus als Nachricht an ProB gesandt werden. In Abbildung 12 wird dafür eine eingehende Nachricht mit einem switch-Knoten
erst auf das entsprechend Topic formaliot/stateChanged/motion_detector geprüft,
der Payload dann in JSON umgewandelt und im nächsten Schritt erneut mit switch auf
die möglichen Werte geprüft. Abschließend wird mit Hilfe zweier change-Knoten das
Topic auf formaliot/notify/SetB und der Payload Abhängig vom Wert wahlweise
auf new_state=off oder new_state=on gesetzt und als MQTT-Nachricht versandt.
Listing 13: Einfache Regel in B definiert.
2
4
6
OPERATIONS
SetMotion(new_motion) =
PRE new_motion : NATURAL THEN
motion_detector := new_motion;
IF motion_detector>0 THEN bulb_b_state := on END
END;
65
http://en.wikipedia.org/wiki/Domain-specific_language, Abgerufen am 29. Oktober
2015
2
LÖSUNGSENTWICKLUNG
28
Auch ProB eignent sich als Regelmaschine, indem entsprechende Regeln direkt in den
Operationen festgelegt werden. Im Listing 13 ist dies durch die zusätzliche Zeile 5 IF
motion_detector>0 THEN bulb_b_state := on END erfolgt. Für die automatisierte
Regelausführung kann neben konkreten Operationen der Maschine auch die ProB Java API Methode anyOperation aufgerufen werden. Dies gelingt über die Nachricht
formaliot/notify/$any. Dadurch wird eine beliebige verfügbare Operation der aktuellen Maschine ausgeführt. Außerdem können die Nachrichten aus Node-RED heraus
über den inject-Knoten zu spezifischen Zeitpunkten oder in regelmäßigen Intervallen
versandt und so der Ablauf automatisiert werden.
2.2.3
Visualisierung und Lehre
Abbildung 13: Node-RED als Gateway über eine RESTful API.
Um Systeme mit größerer Komplexität erfassen und diskutieren zu können, ist es erforderlich, das reale Verhalten haptisch durch Sensoren und Aktuatoren abzubilden und
die Zustandsveränderungen sowohl visuell als auch interaktiv erlebbar zu machen. Das
trägt nicht nur zum Verständnis bei, sondern erlaubt auch die Berücksichtigung des Benutzerverhaltens und der User Experience66 . Dies gelingt indem die Sensoren Nachrichten senden und Aktuatoren Nachrichten empfangen, die den Konventionen folgen (siehe
Abschnitt 2.1.2 ab Seite 14).
Node-RED kann bei der physischen Darstellung des Systemzustandes helfen: Dafür fungiert es wie in Abbildung 13 als Gateway und leitet eingehende Nachrichten an ein anderes Gerät weiter – beispielsweise über dessen RESTful API wie im mittleren Fluss. Im
66
http://en.wikipedia.org/wiki/User_experience, Abgerufen am 27. Oktober 2015
3
FAZIT
29
Abbildung 14: Alles zusammen: Virtuelle Leuchte, Node-RED als Gateway und ProB.
unteren Fluss in Abbildung 13 wird der umgekehrte Weg eingeschlagen und der aktuelle Wert über die RESTful API des Gerätes ermittelt. Dieser Wert wird anschließend als
MQTT-Nachricht formaliot/notify/SetA an ProB weitergeleitet.
Im Zusammenhang mit der Lehre zeichnet sich der hier gewählte Ansatz dadurch aus,
dass
• die Ergebnisse unmittelbar in Soft- und Hardware sichtbar sind (siehe Abbildung 14),
• kein aufwendiges Kompilieren notwendig ist,
• die Opportunitätskosten gering sind und
• dass das verwendete Werkzeug Node-RED dank seiner konkreten visuellen Arbeitsweise und steilen Lernkurve auch von Nicht-Informatikern verstanden wird.
Ein weiterer Vorteil ist, dass ausgehend von in B verfassten Anforderungen, diese bereits
zu Beginn an ein reales Szenario angebunden werden können. Die dafür in B verfasste
Maschine kann dann parallel Schritt-für-Schritt in die Zielsprache überführt werden –
vorausgesetzt ein entsprechendes Bussystem wie MQTT kommt zum Einsatz.
3
Fazit
Beim Internet der Dinge (siehe Abschnitt 1.1.2 ab Seite 3) handelt es sich um ein System aus Systemen (siehe Abbildung 6), dessen Komplexität durch die zunehmende Ver-
3
FAZIT
30
netzung und Vielzahl an Sensoren und Aktuatoren immer weiter ansteigt. Damit nehmen Abhängigkeiten und Risiken zu. Das betrifft sowohl die Zuverlässigkeit als auch
das erwartungskonforme Verhalten (siehe Abschnitt 1.1.3 ab Seite 4). Erst kürzlich gab
es Ausfälle im vernetzten Zuhause: Darunter der Wink HUB67 , der intelligente Netzwerklautsprecher Amazon Echo68 und die Telekom Smart Home Plattform QIVICON69 .
Glücklicherweise halten sich die Auswirkungen in Grenzen – abgesehen von nächtlicher Ruhestörung durch fälschlich aktivierte Alarmanlagen70 . Formale Methoden (siehe
Abschnitt 1.2 ab Seite 6) versprechen Abhilfe, indem sie ein Systems berechenbar und
dessen Korrektheit nachweisbar machen. Außerdem können durch Formale Methoden
Fehler bereits während der Spezifikation – beispielsweise durch das Verfassen in B (siehe
Abschnitt 1.2.2 ab Seite 7) – vermieden werden.
Die grundsätzliche Architektur gängiger IoT-Plattformen basiert auf einem Nachrichtenbus über den sich Geräte austauschen, wie in der Referenzarchitektur im Abschnitt 2.1
ab Seite 11 beschrieben. Die Anwendungslogik liegt meist in der Cloud oder auf einem Gateway und kommuniziert direkt oder über den Bus mit den Geräten (siehe Abschnitt 2.1.2 ab Seite 14). Der dafür passende Baukasten ist bereits verfügbar – kostenlos und als Open Source. Als Transportprotokoll für Nachrichten eignet sich das leichtgewichtige MQTT (siehe Abschnitt 37, Seite 13), für die Zentrale bietet sich Node.js in
Kombination mit Node-RED an (siehe Abschnitt 2.1.1, Seite 14). Diese Bausteine gelten landläufig als Standard, so dass die Umsetzung eher einer geschickten Kombination
als einer umfangreichen Neuentwicklung gleicht: Das erleichtert den Einsteig, denn die
Funktionsweise ist bekannt und Entwickler mit entsprechenden Kenntnissen sind weit
verbreitet.
ProB lässt sich stellvertretend für Formale Methoden via Java API an einen MQTTbasierten Nachrichtenbus binden (siehe Abschnitt 2.2 ab Seite 19) und kann dadurch mit
einem System kommunizieren, wenn nicht sogar die Kontrolle übernehmen. Dies funktioniert bidirektional, indem Änderungen über den Nachrichtenbus mit dem System synchronisiert werden. Eine in B definierte Maschine mit ihren Operationen als Eingängen
und Variablen als Ausgängen (siehe Abbildung 10) ist Spezifikation und Modell eines
IoT-Systems. Diese Maschine lässt sich mit den Mitteln von ProB auf Korrektheit prüfen.
Außerdem kann sie zur Interaktion mit Geräten und für automatisierte Abläufe (Regeln)
genutzt werden (siehe 2.2.2 ab Seite 25).
Nicht nur IoT-Systeme profitieren von Formalen Methoden: Die hier entwickelte Lösung
erlaubt es, Formale Methoden auf einfache Art und Weise aus einer eher abstrakten in
eine konkrete visuelle und haptische Welt zu überführen, indem die Operationen und
Variablen einer Maschine physisch abgebildet werden — dies erhöht das Verständnis
für eine in einer Sprache wie B definierten Maschine und erleichtert die Lehre (siehe
Abschnitt 2.2.3 ab Seite 27).
67
http://www.wired.com/2015/04/smart-home-headaches/, Abgerufen am 28. Oktober 2015
http://www.zdnet.com/article/the-night-alexa-lost-her-mind/, Abgerufen am 28.
Oktober 2015
69
http://www.heise.de/newsticker/meldung/Deutsche-Telekom-Ausfall-desQivicon-Servers-legt-Smart-Homes-lahm-2832456.html, Abgerufen am 28. Oktober 2015
70
http://smarthome.boeffi.net/blog/2015/10/25/bug0021-winterzeit-umstellungda-waren-selbst-die-einbrecher-ueberrascht/, Abgerufen am 28. Oktober 2015
68
A
ANHANG
A
31
Anhang
A.1
Start
Die Anwendung wird in der folgenden Reihenfolge gestartet:
1. Mosquitto Broker, die Adresse des Brokers muss in Main.java angepasst werden,
sofern nicht der Standard tcp://127.0.0.1:1883 zum Einsatz kommt;
2. Die Anwendung (Main.java), optional kann anschließend zusätzlich die Webbasierte Oberfläche http://127.0.0.1:17080 aufgerufen werden;
3. Node-RED;
Eine in B spezifizierte Maschine kann durch eine MQTT-Nachricht mit dem Topic
formaliot/notify/$load und dem Pfad zu der Maschinenbeschreibung im Payload
erfolgen. In Node-RED gelingt dies über den „mqtt out“-Knoten. Operationen der Maschine werden auf die gleiche Art aufgerufen, indem eine Nachricht das Topic formaliot
/notify/[operation] und das Prädikat dieser Operation als Payload erhält. Veränderungen der Maschine werden als MQTT-Nachrichten abonniert. Die Nachrichten enthalten Variablenbezeichner und -wert. In Node-RED erfolgt das mit dem „mqtt in“-Knoten
und dem Topic formaliot/stateChanged/[variable].
Beispiele für Node-RED flows sind im Verzeichnis src/main/node-red enthalten. Diese
können in Node-RED durch das Hamburger-Menü und dann Import | Clipboard eingefügt werden. Diverse Maschinen für ProB finden sich unter src/main/b. Ein Test-Sketch
für Arduino findet sich unter src/main/arduino/SimpleMQTT.ino und ein kompletter Arduino/Genuino basierter Agent für vorgefertigte Grove-Komponenten steht unter
src/main/arduino/FormalIoT.ino zur Verfügung.
Als Grundlage des Projektes dient ProB. Grundsätzlich würde es ausreichen, den reinen ProB Kernel der Java API einzubinden, doch müsste dann eine Visualisierung ähnlich dem BMotion Studio zusätzlich umgesetzt werden. Glücklicherweise liefern die
hier eingebundenen Servlets auf Basis des Kernels von ProB Version 2 eine interaktive Web-basierte Oberfläche frei Haus, die - sofern nicht anders konfiguriert - über
http://127.0.0.1:17080/ gestartet wird.
Falls kein physisches Testgerät vorhanden ist, kann auf die virtuelle Leuchte aus dem QIVICON SDK71 zurückgegriffen werden. Eine Kopie dieser Node.js-Anwendung befindet
sich im Verzeichnis virtualbulb und wird dort über die Kommandozeile via node bulb
.js gestartet. Die Nutzung der RESTful API erfolgt durch POST und GET über http://
localhost:3000/api/v1/smarthome/virtual/bulb. Eine Weboberfläche steht
unter http://localhost:3000/api/v1/smarthome/virtual/bulb/view ebenfalls zur Verfügung. Die genaue Verwendung und Konfigurationsmöglichkeiten sind in
der zugehörigen README.txt-Datei beschrieben.
71
http://developer.qivicon.com/sdk/qivicon-sdk/qivicon-sdk-download/, Abgerufen
am 27. Oktober 2015
A
ANHANG
A.2
32
Erweiterung
Sollte das Angebot an Paketen für Node-RED einmal nicht ausreichen, kann auch
auf Node.js-JavaScript-Pakete (npm) oder gleich auf eigenes JavaScript innerhalb von
Funktionsblöcken (function node) zurückgegriffen werden. Im Falle eines Paketes wie
„Node.js Sonos Interface“ (Paketname sonos) für die Steuerung vernetzter SonosLautsprecher72 müsste dieses nach der Installation noch in den Einstellungen settings
.js der Node-RED-Anwendung73 bekannt gemacht werden: functionGlobalContext
: {sonos:require(’sonos’)} Innerhalb eines Funktionsblocks kann das Paket dann
nach einem Neustart von Node-RED direkt im Programmcode genutzt werden (siehe
Listing 14).
Listing 14: Node-RED-Programmcode zur Nutzung von Sonos.
2
4
// set Sonos IP
var sonos = new context.global.sonos.Sonos(’192.168.178.64’);
// url with Sonos compatible soundfile
var url = ’https://foo.bla/sound.mp3’;
6
8
sonos.play(url, function (err, playing) {
console.log([err, playing]);
});
72
73
http://www.sonos.com/, Abgerufen am 26. Oktober 2015
http://nodered.org/docs/configuration.html, Abgerufen am 16. Oktober 2015
A
ANHANG
A.3
33
Dateien und Datenträger
Bitte hier
die Hülle mitsamt Datenträger einkleben
Der beiliegende Datenträger enthält:
• pdf -Version der Bachelorarbeit;
• LATEX- und Grafik-Dateien, die verwendet wurden;
• Quellcode, der während der Bachelorarbeit erstellt wurde;
• Virtuelle Leuchte als RESTful API, sollte einmal kein physisches Gerät vorhanden
sein;
Der Quellcode ist ebenfalls unter http://tuatara.cs.uni-duesseldorf.de/
wolter/FormalIoT.git verfügbar.
LITERATUR
34
Literatur
[AFPS11] A LMEIDA, José B. ; F RADE, Maria J. ; P INTO, Jorge S. ; S OUSA, Simão Melo d.:
An overview of formal methods tools and techniques. In: Rigorous Software
Development. Springer, 2011, S. 15–44
[Ash09]
A SHTON, Kevin:
That ’Internet of Things’ Thing.
http://www.
rfidjournal.com/articles/view?4986. Version: 2009. – Abgerufen
am 17. Oktober 2015
[BIT14]
Bitkom e.V.:
Vor dem Boom - Marktaussichten für Smart Home.
http://www2.deloitte.com/de/de/pages/technology-mediaand-telecommunications/articles/marktaussichten-fuersmart-home.html. Version: 2014. – Abgerufen am 17. Oktober 2015
[But01]
B UTLER, Ricky W.: NASA LaRC Formal Methods Program: What Is Formal Methods? http://shemesh.larc.nasa.gov/fm/fm-what.html.
Version: 2001. – Abgerufen am 17. Oktober 2015
[Cis15]
Cisco Systems, Inc.: Internet of Everything (IoE) | The Network. http:
//newsroom.cisco.com/ioef. Version: 2015. – Abgerufen am 17. Oktober 2015
[Cla14]
C LARK, Tim: Mobile World Congress 2014: “Everything that can be connected,
will be connected“.
http://scn.sap.com/community/businesstrends/blog/2014/02/26/mobile-world-congress-2014everything-that-can-be-connected-will-be-connected.
[CW96]
C LARKE, Edmund M. ; W ING, Jeannette M.: Formal methods: State of the art
and future directions. In: ACM Computing Surveys (CSUR) 28 (1996), Nr. 4, S.
626–643
[DB15]
D AUGHERTY, Paul ; B ERTHON, Bruno: Winning with the Industrial Internet of
Things. https://www.accenture.com/ng-en/~/media/Accenture/
Conversion-Assets/DotCom/Documents/Global/PDF/Digital_
1/Accenture-Industrial-Internet-of-Things-PositioningPaper-Report-2015.pdf. Version: 2015. – Abgerufen am 17. Oktober
2015
[End13]
E NDLER, Michael: Cisco CEO: We’re All In On Internet Of Everything.
http://www.informationweek.com/software/informationmanagement/cisco-ceo-were-all-in-on-internet-ofeverything/d/d-id/1108801.
Version: 2013. – Abgerufen am 17.
Oktober 2015
[Fow09]
F OWLER, Martin: RulesEngine. http://martinfowler.com/bliki/
RulesEngine.html. Version: 2009. – Abgerufen am 27. Oktober 2015
LITERATUR
35
[Gar14]
Gartner, Inc.: Gartner’s 2014 Hype Cycle for Emerging Technologies Maps the
Journey to Digital Business. http://www.gartner.com/newsroom/id/
2819918. Version: 2014. – Abgerufen am 17. Oktober 2015
[Har87]
H AREL, David: Statecharts: A visual formalism for complex systems. In:
Science of computer programming 8 (1987), Nr. 3, S. 231–274
[Kre14]
K REUZER, Kai:
openHAB 2.0 and Eclipse SmartHome.
http:
//kaikreuzer.blogspot.de/2014/06/openhab-20-and-eclipsesmarthome.html. Version: 2014. – Abgerufen am 17. Oktober 2015
[KS11]
K NAPP, Alexander ; S CHELLHORN, Gerhard: Formale Methoden - Universität Augsburg.
https://www.informatik.uni-augsburg.de/
lehrstuehle/swt/sse/lehre/fm/downloads/fm.pdf. Version: 2011.
– Abgerufen am 18. Oktober 2015
[LB03]
L EUSCHEL, Michael ; B UTLER, Michael: ProB: A Model Checker for B. In:
A RAKI, Keijiro (Hrsg.) ; G NESI, Stefania (Hrsg.) ; M ANDRIOLI, Dino (Hrsg.):
FME 2003: Formal Methods - International Symposium of Formal Methods Europe.
Pisa Italy, September 8-14, 2003, Proceedings. Springer, 2003, S. 855–874. – ISBN
978–3–540–40828–4
[Mü14]
M ÜLLER, Andreas: Bosch ConnectedWorld - Missing pieces to make the IoT a
real success. http://blog.bosch-si.com/categories/technology/
2014/11/missing-pieces-to-make-the-iot-a-real-success/.
[MBH09] M ALAKA, Prof. Dr. R. ; B UTZ, Prof. Dr. A. ; H USSMANN, Prof. Dr. H.: Medieninformatik - eine Einführung. 1. Auflage. München : Pearson Deutschland
GmbH, 2009. – ISBN 978–3–827–37353–3
[Mic15]
Microsoft Corporation: Internet of Things overview | Microsoft. http://www.
internetofyourthings.com/. Version: 2015. – Abgerufen am 22. Oktober 2015
[Neg95]
N EGROPONTE, Nicholas: Being Digital -. First Edition; later Printing. New
York : Knopf, 1995. – ISBN 978–0–679–43919–6
[Nib14]
N IBLETT, Peter: Introduction to the IoT Protocol, MQTT. https://www-304.
ibm.com/connections/files/basic/anonymous/api/library/
2f752ce8-0a65-478d-8ae4-6b0bb4a22656/document/6eb61ae3afb9-43c8-8c15-e4bddce7065b/media. Version: 2014. – Abgerufen
am 18. Oktober 2015
[OEC12]
OECD: Machine-to-Machine Communications. http://dx.doi.org/10.
1787/5k9gsh2gp043-en/content/workingpaper/5k9gsh2gp043en. Version: 2012. – Abgerufen am 17. Oktober 2015
[RGC+ 15] R OWLAND, Claire ; G OODMAN, Elizabeth ; C HARLIER, Martin ; L IGHT, Ann
; L UI, Alfred: Designing Connected Products - UX for the Consumer Internet of
Things. Sebastopol, CA : Ö’Reilly Media, Inc.", 2015. – ISBN 978–1–449–37272–
9
LITERATUR
36
[RT13]
R OUE -TAYLOR:
The technology that will enable the Internet of Things.
http://www.successfulworkplace.org/2013/05/25/thetechnology-that-will-enable-the-internet-of-things/.
[Saf09]
S AFFER, Dan: Designing for Interaction - Creating Innovative Applications and
Devices. 00002. Aufl. London : New Riders, 2009. – ISBN 978–0–321–64339–1
[Sin09]
S INEK, Simon: Simon Sinek: How great leaders inspire action | TED Talk
| TED.com. http://www.ted.com/talks/simon_sinek_how_great_
leaders_inspire_action. Version: 2009. – Abgerufen am 17. Oktober
2015
[Ste00]
S TEWART, William: Internet Coke Machine. http://www.livinginternet.
com/i/ia_myths_coke.htm. Version: 2000. – Abgerufen am 17. Oktober
2015
[Ste04]
S TERLING, Bruce:
Viridian Note 00422: The Spime - "When Blobjects Rule the Earth"by Bruce Sterling. SIGGRAPH, Los Angeles, August
2004.
http://www.viridiandesign.org/notes/401-450/00422_
the_spime.html. Version: 2004. – Abgerufen am 17. Oktober 2015
[Sym97]
S YME, Don: Proving Java Type Soundness. http://research.microsoft.
com/apps/pubs/default.aspx?id=68466. Version: 1997. – Abgerufen
am 19. Oktober 2015
[Vis15]
VisionMobile Ltd: IoT report series: The Smart Home Landscape 2015 - Free report sample. http://www.visionmobile.com/product/iot-reportseries-the-smart-home-landscape-2015/. Version: 2015. – Abgerufen am 17. Oktober 2015
[Wei91]
W EISER, Mark: The Computer for the 21st Century. http://www.ubiq.com/
hypertext/weiser/SciAmDraft3.html. Version: 1991. – Abgerufen am
17. Oktober 2015
[Wei96]
W EISER, Mark:
Ubiquitous Computing.
http://www.ubiq.com/
hypertext/weiser/UbiHome.html. Version: 1996. – Abgerufen am 17.
Oktober 2015
[Wol13]
W OLTER, Sascha: Jenseits mobiler Anwendungen: Super-natural interaction
und Spielzeuge. In: i-com - Zeitschrift für interaktive und kooperative Medien,
Vol. 12, Nr. 3, ISSN 2196-6826 (2013), S. 54–59
[Wol15]
W OLTER, Sascha:
Nutzen, Sicherheit und Privatsphäre.
http://www.
wolter.biz/2015/06/nutzen-sicherheit-und-privatsphare/.
ABBILDUNGSVERZEICHNIS
37
Abbildungsverzeichnis
1
Smart Home Marktprognose. . . . . . . . . . . . . . . . . . . . . . . . . . .
2
2
Paradigmenwechsel bei der Interaktionsgestaltung. . . . . . . . . . . . . .
5
3
ProB Tcl/Tk. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
9
4
ProB 2 Webclient mit einer Schalter-Maschine (Switch). . . . . . . . . . . .
10
5
Die Internet-der-Dinge-Landschaft. . . . . . . . . . . . . . . . . . . . . . . .
12
6
System aus Systemen mit Nachrichtenbus. . . . . . . . . . . . . . . . . . .
13
7
Node-RED Funktionselement für eingehende MQTT-Nachrichten. . . . .
18
8
Node-RED Funktionselement zum Injizieren von Nachrichten. . . . . . . .
19
9
Node-RED Funktionselement zum Auswerten von Nachrichten. . . . . . .
20
10
Maschine mit Ein- und Ausgängen. . . . . . . . . . . . . . . . . . . . . . . .
21
11
Node-RED JSON-Verabreitung. . . . . . . . . . . . . . . . . . . . . . . . . .
24
12
Einfache Regel in Node-RED definiert. . . . . . . . . . . . . . . . . . . . . .
27
13
Node-RED als Gateway über eine RESTful API. . . . . . . . . . . . . . . .
28
14
Alles zusammen: Virtuelle Leuchte, Node-RED als Gateway und ProB. . .
29
LISTINGS
38
Listings
1
Schalter als in B spezifizierter Automat. . . . . . . . . . . . . . . . . . . . .
7
2
Server mit Web-Oberfläche auf Basis der ProB Java API. . . . . . . . . . . .
9
3
Arduino als einfacher MQTT-Client. . . . . . . . . . . . . . . . . . . . . . .
15
4
Arduino als MQTT-Subscriber. . . . . . . . . . . . . . . . . . . . . . . . . .
16
5
Arduino als MQTT-Publisher. . . . . . . . . . . . . . . . . . . . . . . . . . .
16
6
Arduino verarbeitet MQTT Payload für Aktuatoren. . . . . . . . . . . . . .
17
7
Operation mit der ProB Java API ausführen. . . . . . . . . . . . . . . . . .
21
8
Empfang und Verarbeitung von MQTT Nachrichten mit der ProB Java API. 22
9
Verarbeitung von Änderungen mit der ProB Java API. . . . . . . . . . . . .
22
10
Node-RED-Programmcode zur Verabeitung eines JSON-Payload. . . . . .
24
11
Node-RED-JSON-Verarbeitung mit zwei Ausgängen. . . . . . . . . . . . .
25
12
Smart Home als in B spezifizierter Automat. . . . . . . . . . . . . . . . . .
25
13
Einfache Regel in B definiert. . . . . . . . . . . . . . . . . . . . . . . . . . .
27
14
Node-RED-Programmcode zur Nutzung von Sonos. . . . . . . . . . . . . .
32

Definition einer Internet-der-Dinge

Transcrição

Documentos relacionados

Impact Investing in Deutschland

mini med junior - MINI MED Upload

bizhub 160/160f/161/162/210

Kommunale Inklusionsplanung in Köln – Herausforderungen und

Commercial Banking – Kreditrisiko Aufgaben zur 2. Übung am 17

Leseprobe - Academy of Sports

Beilage Hum-Magazin 8. Ausgabe

Präsentation zum Referat zu Lernstandserhebungen

Soundkarte ultron PCI 7.1 Kanal Octosound retail Artikel

Mollier Diagram - PCE Instruments