Das Internet der Dinge braucht Standards für eine Interoperabilität der Einzelkomponenten. Die Standards müssen gut sein und eine gute Verbreitung aufweisen. Open Source Konzepte helfen dabei, solche Standards zu spezifizieren und zu etablieren. Obsoleszenz ist dabei manchmal eine erstrebenswerte Eigenschaft.

1. Open Source als
Innovator und Treiber
von De-Facto Standards
für das Internet der Dinge
Dr. Torsten Fink
torsten.fink@akquinet.de

2. Zu meiner Person
„ 2003: Promotion an der FU zum Thema
SW-Architekturen und Verteilte Systeme
„ Ab 2004: Berater bei der akquinet
§ technischer Architekt, Projektleitung
§ Betriebsführung, Wartung
§ klassische Beratung und Schulungen
„ 2006-2010:
Leiter des JBoss-Competence-Centers bei der akquinet
„ Ab 2011:
Geschäftsführer der akquinet tech@spree
„ Ab etwa 2014:
Ausrichtung des Berliner Bereichs in Richtung Industrie 4.0 und IoT

3. Meine Firma

4. Wikipedia zu dem Internet of Things (IoT)
„The Internet of Things
§is the network of physical devices,
vehicles, home appliances, and other
items embedded with electronics,
software, sensors, actuators,
§and connectivity which enables these
things to connect and exchange data,
§creating opportunities for more direct
integration of the physical world into
computer-based systems,
§resulting in efficiency improvements,
economic benefits, and reduced
human exertions.
aus Wikipedia
Notwendigkeit
für Standards.

5. Noch mehr
Notwendigkeit
für Standards.

6. Was ist IMHO ein guter Standard?
„Gute Qualität
§Korrekt
=> Der Standard muss funktionieren.
§Konsistent
=> widerspruchsfreie Einzelteile
§Eindeutig
=> für Kompatibilität/Interoperabilität
(hilfreich: Referenzimplementierung)
§Lesbar
=> beschleunigt Verbreitung

7. ... außerdem
„Gute Verbreitung
§Ausreichend viele
Implementierungen für
relevante Einsatzszenarien
§nicht eingeschränkt durch
fehlende Implementierungen
• HW, OS, Programmiersprache
• zu hoher Preis
• zu aufwändiger Benutzung
• zu wenig kundige Fachkräfte

8. Geschlossene Standards ...
„Geschlossener Standard
§Dokumentation/Spezifikation ist
nicht frei verfügbar.
§Z.B:
ISO-Standards, Word-DOC
§Erlaubt direkte Geschäftsmodelle
(z.B. Lizenzierung, Zertifizierung)

9. ... vs. Offene Standards
„Offener Standard
§Dokumentation/Spezifikation ist frei
verfüg- und nutzbar
=> einfach einzusetzen
§Z.B.:
HTML, TCP/IP, Java
§Nur indirekte Geschäftsmodelle
(z.B. Beratung, Verkauf von
Implementierungen, Nutzung)

10. Die unternehmerische Perspektive

11. IoT als alleiniger USP
„IoT Anwendung als alleiniges
Produkt
„Schutz des Produkts durch
strikte, geschlossene
Lizensierung
„Z.B.
PaaS – Anbieter im
Plattformbereich; Azure IoT,
AWS, Google Cloud IoT,
EuroTech Everyware Cloud
„Lock-In als Geschäftsmodell

12. IoT bei den allgemeinen Merkmalen
„IoT wird als Hilfsmittel für die
USP/CSP genutzt.
„Beispiele
§Everyware Cloud nutzt
Eclipse Kura für Edge-
Devices; (Kapua ist kaum
nutzbar)
§Alle Cloud-Provider
unterstützen Docker
„Einsatz offener Standards ist
unternehmerisch sinnvoll.

13. „Kooperativer Einsatz von
IoT Frameworks, um
Dienste für den Kunden
bereit zu stellen
„Beispiel:
Kooperation von Nike, Apple, Spotify mit Run Club+, Spezial Apple
Watch mit Armbändern,
iOS-Anwendung
„Offene Standards sind
ebenfalls sinnvoll
Kooperierende allgemeine IoT-Anwendungen

14. Kooperierende spezielle IoT-Anwendungen
„Firmen kooperieren
im IoT – Bereich in ihren
speziellen Dienstleistungen
häufig in einer
Kundenbeziehung
§Z.B. Überweisungen per MTAN
• Bank bietet den Dienst per mobiler Anwendung an Kunden
• Für die automatisierte SMS-Auslösung wird ein Dienstleister
eingesetzt.
§Z.B. Heimautomatisierung von Osram setzt auf ZigBee und Alexa

15. Standards – aus persönlicher Perspektive
zusammengefasst
„Die Natur von IoT-Anwendungen bedingt Standards.
„Offene Standards unterstützen die Verbreitung.
„Der Einsatz offener Standards ist meistens (3 von 4)
unternehmerisch sinnvoll.
„Aber,
§Standards brauchen Zeit (insb. in Gremien)
§Standard sind manchmal Kompromisse (insb. in Gremien)
§Nur über Gremien kann man breite industrielle Akzeptanz
bewirken.

16. Open Source Software kann helfen I
„ Implementierung einer Idee als Open Source
Produkt.
„ Verbreitung über Marketing
„ Schnelle kontinuierliche Produktverbesserung
anhand von Rückmeldungen aus konkreten
Praxiseinsätzen
(Pull-Requests helfen, benötigen aber auch
Integrationsaufwand)
„ Erfolgsvariante I:
Etablierung als de-facto Standard (z.B. Linux)
„ Erfolgsvariante II:
Grundlage für Spezifikation

17. Beispiel - MQTT
„ 1998: IBM und Cirrus Link Solutions spezifizieren das Protokoll für ein
Forschungsprojekt “Twittering Ferries“
(Andy Stanford-Clark, Arlen Nipper )
„ Interne Nutzung von IBM bis 2010, dann Veröffentlichung unter freier Lizenz
„ 2012: Start von Project Eclipse Paho (OS Server und Klienten, Erstes Release 2014)
„ 2014: Version 3.1.1 als OASIS – Standard
„ 2016: Version 3.1.1 als ISO – Standard ISO/IEC 20922:2016
„ 2017: Mosquitto, erster MQTT-Broker auf dem Technology Radar von ThoughtWorks
=> damit im Mainstream
„ Sep. 2018: 26 Implementierungen für unterschiedlichste Szenarien
(auf mqtt.org verlinkt, es gibt mehr)

18. Beispiel: Hypertext Transfer Protocol (HTTP)
„1991: Tim Berners-Lee überlegt einfaches, offenes Protokoll HTTP
(0.9) für Zugriff auf Dokumente (inkl. HTML, URL);
Implementierung eines offenen Prototyps
„1991-1995: Start des WWW
§Entwicklung von OS-Web-Browsern (WorldWideWeb,
ViolaWWW, Erwise, Mosaic)
§Entwicklung von OS-Web-Servern (CERN httpd, Apache httpd)
„1996: RFC 1945 HTTP/1.0 (btw. nur ein Vorschlag, wurde nie
offiziell verabschiedet)
„... Der Rest ist Geschichte. :-)

19. Open Source Software kann helfen II
„Einsatz von Open Source beschleunigt
Entwicklung
§leistungsfähige umfangreiche Palette
an SW-Produkten mit Schwerpunkt
auf Middleware, Frameworks
(weniger Fachanwendungen mit GUI),
§unkompliziert und günstig,
§kann Marketing unterstützen
„Passend, aber nicht notwendig:
Produkt selber unter OS-Lizenz stellen

20. Beispiel – Implementierung proprietärer
Kommunikationsprotokolle
mit Open Source

21. IoT - Datenhaltung mit Open Source
Extrem skalierbare
Datenhaltung
Schnelle Abfragen und
Datenanalyse

22. IoT - Datenanalyse und Maschinelles Lernen mit
Open Source
Schnelle Datenanalyse
Und Maschinelles Lernen
Für eine Interaktive Auswertung
Darstellung

23. Nicht IoT – Beispiel – Webframework - Seam
„ 2005: erste Veröffentlichung basierend auf JSF, Hibernate
„ 2005-2008: rasante Entwicklung und Verbreitung
„ 2006-2009: Spezifikation von CDI 1.0 mit Referenzimplementierung Weld
„ 2009: Aufnahme in Java EE 6
„ Danach immer weniger im Einsatz => Produktive Obsoleszenz
„ Benötigt Einsatz und Kapital
JSF
CDI

24. Der Vendor Lock-In

25. Abhängigkeit von der Lizenzpolitik
„Risiko:
Lizenzen werden n-jährlich
verhandelt,
=> Hersteller diktiert Lizenzpreise
„Bei Open Source:
Hersteller hat keine individuellen Lizenzrechte, statt dessen GPL,
LGPL etc.
„=> man kann SW ohne Einverständnis der Herstellers einsetzen
(im Rahmen der Lizenz)

26. Abhängigkeit vom Support
„Risiko:
Supportpreise werden n-jährlich verhandelt,
nur der Hersteller kennt das Produkt
=> Hersteller diktiert Supportpreise
(Upgradezwang)
„Bei Open Source:
§Quellcode ist frei verfügbar, jeder
kann sich einarbeiten.
=> Die Wahrscheinlichkeit ist gut, einen alternativen
Supportanbieter zu finden.

27. Abhängigkeit von der Entwicklungspolitik
„Risiko:
§Stop der Weiterentwicklung des Produkts
§Hersteller entscheidet sich für eine un-
gewünschte Entwicklungsrichtung
„Bei Open Source:
§Quellcode ist frei verfügbar,
=> jeder kann/darf eine alternative Version
entwickeln (Fork)
=> oder alte Versionen weiter warten

28. Mal zusammengefasst...

29. Der Argumentationsfaden
„Kern von IoT: Automatisierte Kommunikation mit einer Vielzahl
sehr heterogener Kommunikationspartner
„Notwendigkeit für Standards ist offensichtlich.
„Offene Standards sind für (fast) alle besser als geschlossene.
„Open Source hilft
§bei Etablierung von Standards
§beim Erstellen von Lösungen.