Entwurfsstrategien und -muster für das (Industrielle) Internet der Dinge

[Vortrag auf der DWX - Developer Week 2019 in Nürnberg]

Charakteristisch für komplexe IoT-Systeme, beispielsweise im industriellen Kontext, sind häufig eine sehr große Anzahl unterschiedlichster Sensoren, Aktuatoren und auch reine Softwarekomponenten, die sehr stark verteilt sind und nicht selten über eher unzuverlässige Netzwerkverbindungen kommunizieren müssen. Mit einem einfachen Anschließen der "Things" über bekannte Internet-Protokolle ist es daher zumeist nicht getan. Beim Systemdesign müssen häufig noch Aspekte der Skalierbarkeit, Ausfallsicherheit, Fehlertoleranz (Resilienz), Echtzeitanforderungen und die Sicherheit (Security und Safety) berücksichtigt werden.

Transcript

1. Entwurfsstrategien und -muster für das (Industrielle) Internet der Dinge Lösungen für typische Entwurfsprobleme bei IoT- Systemen Stephan Roth oose Innovative Informatik eG 25.06.2019, DWX – Developer Week 2019, Nürnberg
2. Wer ich bin… (Model Based) Systems Engineering Software Engineering und Softwarearchitektur Software Craft und Clean Code Fachbuchautor Konferenzsprecher Stephan Roth Trainer, Berater und Coach stephan.roth@oose.de @_StephanRoth http://xing.to/sr
3. Was wir bieten… Zu relevanten Themen der Software-, System- und Organisationsentwicklung bieten wir Ihnen Trainings, Workshops, Beratung und Projektunterstützung.
4. Vollständig im Besitz der Mitarbeiter (Genossenschaft) Pionier auf dem Gebiet der sog. neuen Arbeitswelten (New Work) Keine Manager, keine „Chefs“, und keine klassische Top-Down-Hierarchie „Kreismodell“, Selbstorganisation, partizipatives Gehaltsmodell „Führung ist zu wichtig, um sie alleine Führungskräften zu überlassen.“ Bernd Oestereich, Gründer 3 x Finalist für den Training & Beratung für Software-, System- und Organisationsentwicklung Ein kollegial geführtes Unternehmen
5. Warum dieser Vortrag? Mit welchen typischen Entwurfsproblemen sind System- und Softwarearchitekten beim Konzipieren eines IoT-Systems konfrontiert? Welche klassischen und bekannten Entwurfsmuster sind auch bei IoT- Systemen gut anwendbar? Wurden vielleicht sogar schon neue Muster entdeckt, die speziell für IoT- Systeme prädestiniert sind?
6. Agenda Eine kurze Einführung in Entwurfsmuster Eine Auswahl von Mustern für IoT-Systeme 1 2 3 4 Der Hype „IoT“, und was dahinter steckt Das Internet (of Things): Ein System of Systems 5 Zusammenfassung und Fazit
7. Agenda Eine kurze Einführung in Entwurfsmuster Eine Auswahl von Mustern für IoT-Systeme 1 2 3 4 Der Hype „IoT“, und was dahinter steckt Das Internet (of Things): Ein System of Systems 5 Zusammenfassung und Fazit
8. Internet of Things
9. Internet of Things Das Internet der Dinge bezeichnet die Verknüpfung eindeutig identifizierbarer physischer Objekte mit einer virtuellen Repräsentation ihrer selbst in einer Struktur (Netzwerk), in der offene, interoperable Internet-Standardtechnologien zum Einsatz kommen.
10. Internet of Things Das Internet der Dinge bezeichnet die Verknüpfung eindeutig identifizierbarer physischer Objekte mit einer virtuellen Repräsentation ihrer selbst in einer Struktur (Netzwerk), in der offene, interoperable Internet-Standardtechnologien zum Einsatz kommen. !!!
11. Consumer IoT  Relativ geringe Komplexität.  Eine übersichtliche Anzahl an Devices („Things“).  Wenig architektureller Planungsaufwand erforderlich.  In der Regel keine Echtzeitanforderungen.  Fehler sind lästig, in ihren Auswirkungen aber zumeist nicht katastrophal.
12. Industrial Internet of Things Das Industrial Internet of Things (IIoT) bezeichnet den Einsatz von IoT- Technologien im industriellen Umfeld. Credit: CC-BY-SA 2.0 BMW Leipzig
13. Einsatzbereiche IIoT  Industrielle Fertigung und Produktion  Smart Grid  Vernetztes und autonomes Fahren  Logistik  Smart Healthcare  Smart Agriculture  …
14. Industrial IoT: Was ist anders?  Geschäftskritisch: Ausfälle bedeuten Verluste oder sind sogar bestandsgefährdend.  Hohe Komplexität.  Viele Devices (> 1.000 keine Seltenheit).  Ambitionierte Qualitäts- anforderungen, z.B. an die Zuverlässigkeit, IT-Sicherheit und Performanz.  Fehler können katastrophale Auswirkungen haben (funktionale Sicherheit).
15. Agenda Eine kurze Einführung in Entwurfsmuster Eine Auswahl von Mustern für IoT-Systeme 1 2 3 4 Der Hype „IoT“, und was dahinter steckt Das Internet (of Things): Ein System of Systems 5 Zusammenfassung und Fazit
17. System of Systems (SoS) Ein System of Systems (SoS) ist ein Zusammenschluss von aufgabenorientierten oder dedizierten Systemen, die ihre Ressourcen und Fähigkeiten bündeln, um ein neues, komplexeres System zu bilden, das mehr Funktionalität und Leistung bietet als nur die Summe der einzelnen Systeme.
18. System of Systems (SoS) Charakteristische Merkmale eines System of Systems:  Operative Unabhängigkeit der Elemente (Teilsysteme)  Administrative Unabhängigkeit der Elemente  Lose Kopplung (i.d.R. nur IT- Schnittstellen)  Evolutionäre Entwicklung  Emergente Eigenschaften  Geographische Verteilung
19. Beispiel für ein SoS: Das Internet  Milliarden lose gekoppelter Systeme (Server, Router, …).  Maximal (geographisch) verteilt.  Extrem gut skalierbar.  Eine wohl niemals endende, evolutionäre Weiterentwicklung.  Viele emergente Eigenschaften.  Sehr gute Interoperabilität durch standardisierte Schnittstellen und Netzwerkprotokolle. … of Things
20. Emergenz „Das Ganze ist mehr als die Summe seiner Teile.“ Aristoteles (384 - 322 v.Chr.); verkürztes Zitat aus Metaphysik VII 10.
21. Emergenz (Der „1 + 1 = 3“ Effekt) Bildet ein System („das Ganze“) durch die Interaktion seiner Elemente („die Teile“) neue Eigenschaften heraus, die nicht durch die Eigenschaften der beteiligten Elemente erklärt werden können, so spricht man von emergenten Eigenschaften des Systems.
22. Beispiel für Emergenz: Schwärme Eigenschaften, wie die Größe, Gestalt, Richtung und Geschwindigkeit in Vogel- oder Fischschwärmen sind emergent gegenüber dem Individuum, d.h. dem einzelnen Vogel oder Fisch.
23. Agenda Eine kurze Einführung in Entwurfsmuster Eine Auswahl von Mustern für IoT-Systeme 1 2 3 4 Der Hype „IoT“, und was dahinter steckt Das Internet (of Things): Ein System of Systems 5 Zusammenfassung und Fazit
24. 1977: A Pattern Language Der US-amerikanische Architekt, Systemtheoretiker und Philosoph Christopher Alexander beschreibt 270 Muster für die Gebäudearchitektur und Städteplanung. CC BY SA 4.0 Michael Mehaffy
25. 1994: Design Patterns  Der Klassiker von der „Gang of Four“ (GoF)  23 Entwurfsmuster  Gilt als die „Bibel des objekt- orientierten Designs“
26. Was ist ein Entwurfsmuster? Entwurfsmuster…  … sind bewährte Lösungen für immer wiederkehrende Entwurfsprobleme.  … machen Erfahrungen „wiederverwendbar“.  … definieren neue „Vokabeln“ für Architekten & Designer.  … werden gefunden und nicht erfunden. Erfahrene Entwickler haben einen Schatz von Musterlösungen.
27. Muster in der Softwarearchitektur
28. Agenda Eine kurze Einführung in Entwurfsmuster Eine Auswahl von Mustern für IoT-Systeme 1 2 3 4 Der Hype „IoT“, und was dahinter steckt Das Internet (of Things): Ein System of Systems 5 Zusammenfassung und Fazit
29. Herausforderung: Skalierbarkeit Bei einem großen, heterogenen IoT-System, das aus einer sehr hohen Anzahl an Knoten besteht, verursachen flache (hierarchiefreie) Topologien Effizienzprobleme. Problem Führe ein Systemkonzept ein: Organisiere das System in einer baumartigen, hierarchischen Struktur (Composite Pattern). Lösung
30. Composite Pattern
31. Composite Pattern Blattelemente (Leaf) Software Hardware
32. Beispiel: System zur Waldbranderkennung Kompositen Blätter
33. Vorteile + Leichterer Umgang mit Komplexität (Teile und Herrsche, Separation of Concerns). + Bessere Skalierbarkeit, da nicht mehr mit jedem Device direkt kommuniziert werden muss, sondern mit der Fassade eines Kompositen (Verwendung als Black-Box). + Dezentrale Daten(vor)verarbeitung auf den Kompositen möglich (Edge Computing). + Anreicherung der „rohen Sensordaten“ mit Metainformationen (z.B. geographische Position oder Zeitstempel) auf den Kompositen. + Device Management: Die Kompositen können bei Firmware-Updates als lokaler Verteiler eines Update-Packages dienen.
34. Hub and Spoke (Sterntopologie) Proximity Network (z.B. ZigBee/IEEE 802.15.4 Long-range Access Network Edge-Gateway & Message Broker, Verteilung von Software-Updates
35. Vorteile + Leichterer Umgang mit Komplexität (Teile und Herrsche, Separation of Concerns). + Bessere Skalierbarkeit, da nicht mehr mit jedem Device direkt kommuniziert werden muss, sondern mit der Fassade eines Kompositen (Verwendung als Black-Box). + Dezentrale Daten(vor)verarbeitung auf den Kompositen möglich (Edge Computing). + Anreicherung der „rohen Sensordaten“ mit Metainformationen (z.B. geographische Position oder Zeitstempel) auf den Kompositen. + Device Management: Die Kompositen können bei Firmware-Updates als lokaler Verteiler eines Update-Packages dienen. + Kompatibel zum hierarchischen Aufbau von RESTful API URLs.
36. REST (REpresentational State Transfer)  Grundmuster und Architekturstil des World Wide Web (WWW).  Der Anwendungszustands wird in wiederverwendbaren, gemeinsam genutzten Ressourcen externalisiert.  REST kann sofort überall dort eingesetzt werden, wo HTTPS eingesetzt werden kann.  …ABER: REST ist nicht beschränkt aufs WWW!  HTTP-Verben: GET, PUT, POST, DELETE  Repräsentationen (Status der Resource): plain text, HTML, JSON, CSV, XML, … /Ganzes/Teil/gleich,berechtigt?parameter
37. RESTful API GET /ffds/ acquisition/ monitored-segments/42/ fire-alerts
38. Herausforderung: Entkopplung + Skalierbarkeit In hochgradig verteilten IoT-Systemen treten eine große Anzahl von Ereignissen (Nachrichten) auf, die ihren jeweiligen Empfängern zugestellt werden müssen. Eine klassische Client-Server-Architektur skaliert schlecht und würde Sender und Empfänger dieser Nachrichten zu stark aneinander koppeln. Problem Publish/Subscribe (kurz: Pub/Sub) ist ein Messaging-Pattern, bei dem den Versendern (Publisher) einer Nachricht die Empfänger (Subscriber) dieser Nachricht nicht bekannt sind, und umgekehrt. Lösung
39. Basismuster von Pub/Sub: Observer Definiere eine 1-zu-n-Abhängigkeit zwischen Objekten, so dass die Änderung des Zustandes eines Objekts dazu führt, dass alle abhängigen Objekte benachrichtigt und automatisch aktualisiert werden. [GoF: Design Pattern] Beliebig viele Observer können sich beim Subjekt an- bzw. abmelden Das Subjekt sendet bei einer Zustands- änderung den angemeldeten Observern eine Aktualisierungs- nachricht.
40. Broker In verteilten Systemen, die aus einer Vielzahl heterogener Komponenten (Server + Clients) bestehen, sorgt ein zentraler Broker für die Koordination der Kommunikation und eine lose Kopplung. Client A Client B Client C Server 1 Server 2 Server 3 Broker
41. Observer + Broker = Publish/Subscribe  Server (Publisher) veröffentlichen Daten und definieren das Topic (Thema) dieser Daten.  Clients (Subscriber) können ein Topic abonnieren und bekommen ausschließlich die Daten dieses Topics zugestellt.  Sowohl die Server als auch die Clients kennen sich nicht direkt (Broker als Koordinator).
42. Topic-filtered Publish/Subscribe Publisher A Publisher B Pub/Sub-Broker Topic „temperature“ Topic „supply-voltage“ Subscriber 1 Subscriber 2 Subscriber 3 „15°C“ „3,7 V“ „15°C“ „15°C“ „3,7 V“ „3,7 V“ subscribe("temperature") subscribe("temperature, supply-voltage") subscribe("supply-voltage")
43. IoT Pub/Sub-Protokolle Message Queuing Telemetry Transport (MQTT)  OASIS- und ISO-Standard (v 3.1.1 = ISO/IEC 20922:2016).  Leichtgewichtiges, offenes Nachrichtenprotokoll für M2M-Kommunikation über unzuverlässige Netzwerke.  Topic-basierte Filterung.  Zentraler Broker erforderlich. Data Distribution Service (DDS, Data-Centric Pub/Sub)  OMG-Standard: Sowohl das Protokoll als auch die API der Middleware.  Für besonders hohe Qualitätsanforderungen (Performanz/Echtzeit, Zuverlässigkeit) optimiert.  Topic- und Content-basierte Filterung.  Sehr umfangreiche QoS-Parametrierung möglich.  Kein zentraler Broker erforderlich!
44. Herausforderung: Effizienz In einem IoT-System treffen verschiedenartige Nachrichten/Ereignisse in unvorhersehbarer Anzahl und Häufigkeit bei den Knoten (Devices) und Servern ein und müssen zügig weiterverarbeitet werden. Problem Das Leader/Follower Entwurfsmuster bietet ein Nebenläufigkeits- Modell, bei dem sehr effizient eintreffende Nachrichten/Ereignisse entgegengenommen und an die zuständigen I/O-Handler zur Verarbeitung zugeteilt werden können (Demultiplexing & Dispatching). Lösung
45. Leader/Follower
46. Leader/Follower
47. Leader/Follower: Vorteile + Es ist keine Kommunikation zwischen den Threads notwendig, d.h. keine Synchronisation oder Schutz gemeinsam genutzten Speichers (keine Sperren, keine Mutexe). + Weitere ConcreteEventHandler können leicht hinzugefügt werden, ohne andere, bereits existierende ConcreteEventHandler zu modifizieren (sog. Open-Closed Principle). + Erhöhung der Performanz aufgrund der Vielzahl von bereitstehenden Threads zur Verarbeitung des Events.
48. Herausforderung: Netzwerkprobleme In einem verteilten IoT-System sind Knoten zeitweise schlecht erreichbar (z.B. durch Netzwerkprobleme), oder aufgrund zu vieler Anfragen überlastet. Dadurch kommt es zu Timeouts. Problem Das Circuit Breaker Entwurfsmuster erkennt, wenn es zu einer großen Anzahl von Verbindungsfehlern kommt und unterbindet den Zugriff auf den Knoten, der angefragt wird, bis dieser wieder verfügbar ist. Lösung
49. Reality is worse! Beispiel: Eine Server-Anwendung, die von 30 Services abhängt, wobei jeder Service eine Verfügbarkeit von 99.99% hat. ► 99.7% Verfügbarkeit der gesamten Anwendung ► 0.3% von 1 Milliarde Anfragen = 3.000.000 Fehler! ► 2+ h Ausfallzeit/Monat, selbst bei exzellenter Verfügbarkeit einzelner Services.
50. Circuit Breaker
51. Circuit Breaker
52. Folgen von Verbindungsfehlern  Anwendungen werden durch nicht antwortende Server blockiert, bis der TCP bzw. UDP connection timeout auftritt.  Eine hohe Anzahl von Verbindungsfehlern führt zu vielen Fehlermeldungen und kaskadierenden Folgefehlern (Domino-Effekt).  Benutzer werden ungeduldig und lösen Aktionen wiederholt aus, was auf einem Server zur Erschöpfung des Thread-Pools führen kann.
53. Lösung: Circuit Breaker
54. Lösung: Circuit Breaker
55. Tipp 1: Netflix/Hystrix  Fault-Tolerance-Bibliothek zur Entwicklung von robusten, verteilten Anwendungen.  Entwickelt vom Video-On-Demand-Anbieter Netflix, verfügbar unter der Apache License 2.0.  Interaktionen mit externen Systemen und Services werden gekapselt und so vom eigenen System isoliert.  Einfache Implementierung von Circuit Breaker, sowie weiteren Mustern* zur Erhöhung der Robustheit. https://github.com/Netflix/Hystrix *) siehe: Michael T. Nygard. Release It!: Design and Deploy Production-Ready Software. Pragmatic Bookshelf, 2017.
56. Tipp 2: Testen! Port 30000 antwortet nie  Port 30001 sendet 1 Byte alle 30 s Port 30002 baut keine Verbindungen auf Mit einem Test-Harnisch (engl. test harness) lassen sich REST-Schnittstellen systematisch und automatisiert unter verschiedenen Umgebungsbedingungen testen.  Port 30000 hat ein ungültiges SSL- bzw. TLS-Zertifikat
57. Herausforderung: Constrained Devices/Nodes In einem IoT-System sind einige Knoten nur sporadisch online, beispielsweise um Energie zu sparen, aufgrund regulatorischer Auflagen an die drahtlose Netzverbindung, oder aufgrund von Netzwerkausfällen. Andere Knoten wollen mit ihnen interagieren, aber wissen nicht, wann sie erreichbar sein werden. Problem Das Device Shadow (synonym: Thing Shadow) Entwurfsmuster führt für den sporadisch verfügbaren Knoten einen persistenten, virtuellen Stellvertreter ein, mit dem die anderen Knoten immer kommunizieren können. Nach der Wiederverbindung des echten Knotens wird dieser mit seinem virtuellen Abbild synchronisiert. Lösung
58. Problem: Energieversorgung Netzbetriebene Geräte (Mains-Powered Devices) Keine direkte Begrenzung der verfügbaren Energie (Ausnahme: Ein Defekt oder Stromausfall). Periodenweise energiebegrenzte Geräte (Period Energy-Limited Devices) Besitzen eine Stromquelle, die regelmäßig ausgetauscht oder aufgeladen werden muss, z.B. Batterien, Stromgenerator, Brennstoffzelle, etc. Lebensdauer-energiebegrenzte Geräte (Lifetime Energy-Limited Devices) Enthalten eine nicht austauschbare bzw. nicht wiederaufladbare Stromquelle. Energieerntende Geräte (Energy Harvesting Devices) Wandeln Umgebungsenergie (Sonnenlicht, Luftströme, elektromagnetische Wechselfelder, Wärme, mechanische Kräfte, etc.) in elektrische Energie um.
59. Problem: Regulierter Aussteuerungsgrad Das Tastverhältnis (auch: Aussteuerungsgrad) für IoT- Weitverkehrs-Funknetze, d.h. das Verhältnis zwischen Sende- und Ruhezeiten, ist reguliert. 1%! Bild: LoRaWAN-Gateway auf dem Hörn-Campus in Kiel, Autor: Fabian Horst (CC BY-SA 4.0) max. 140 msg/h á 12 Byte!
60. Basismuster von Device Shadow: Proxy Kontrolliere den Zugriff auf ein Objekt mit Hilfe eines vorgelagerten Stellvertreterobjekts. [GoF: Design Pattern]
61. Device Shadow im Systemkonzept
62. Agenda Eine Auswahl von Mustern für IoT-Systeme Zusammenfassung und Fazit 1 2 3 4 Das Internet (of Things): Ein System of Systems Eine kurze Einführung in Entwurfsmuster
63. Zusammenfassung und Fazit REST Observer Publish/Subscribe Broker Device Shadow Resource Discovery Composite Remote Facade Circuit Breaker Semantic Hyperlinks Event Handler Leader/Follower Reactor/Proactor Gateway Layers/Tiers Fail fast/fail silent Adapter Distributed Ledger
64. Zusammenfassung und Fazit REST Observer Publish/Subscribe Broker Proxy Resource Discovery Composite Remote Facade Circuit Breaker Semantic Hyperlinks Event Handler Leader/Follower Reactor/Proactor Gateway Layers/Tiers Fail fast/fail silent Adapter Distributed Ledger  Viele bekannte Architektur- und Entwurfsmuster behalten auch bei IoT-Systemen ihre Relevanz.  Kombinationen bekannter Muster erzeugen neue Muster auf höherer Abstraktionsebene.  Starke Verteilung, hohe Datenmengen und ereignisgetriebene Verarbeitung lassen Concurrency- und Resilience-Pattern relevanter werden.
65. Danke… oose Innovative Informatik eG ♦ Schulterblatt 36 ♦ 20357 Hamburg ♦ +49 (0) 40 4142500 …für Ihre Aufmerksamkeit!