Neue digitale Services für Kunden. Entwurf einer IoT-Referenzarchitektur für SaaS-Anwendungen auf Basis von Microservices

Inhaltsverzeichnis

Abbildungsverzeichnis

Tabellenverzeichnis

Abkürzungsverzeichnis

1 Einleitung
1.1 Problemstellung
1.2 Aktueller Stand der Forschung
1.3 Forschungsfragen
1.4 Forschungsziel und Zielgruppen
1.5 Forschungsmethoden- und vorgehen

2 Anforderungen Referenzarchitektur
2.1 IoT-Referenzarchitekturen
2.1.1 5-Layer
2.1.2 Referenzarchitektur für IoT-basierende Geschäftsmodelle
2.1.2.1.. Funktionale Sicht
2.1.2.2.. Architekturschichten digitaler Geschäftsmodelle
2.1.2.3.. Technische Referenzarchitektur
2.1.2.4.. Zusammenfassung und Anforderungen
2.1.3 Microsoft Azure IoT Referenzarchitektur
2.1.3.1.. Architekturbeschreibung
2.1.3.2.. Querschnittsfunktionen
2.1.3.3.. Zusammenfassung und Anforderungen
2.1.4 Zusammenfassung und Anforderungen
2.2 Software as a Service Anwendungen
2.3 Zusammenfassung und Anforderungen

3 Theoretische Grundlagen
3.1 Big Data Architekturansätze
3.1.1 Lambda-Architektur
3.1.1.1.. Batch-Layer
3.1.1.2.. Serving Layer
3.1.1.3.. Speed Layer
3.1.1.4.. Bewertung
3.1.2 Kappa-Architektur
3.1.2.1.. Log
3.1.2.2.. Bewertung
3.1.3 Zusammenfassung und Bewertung
3.2 Microservices
3.2.1 Merkmale von Microservices
3.2.2 Architektur von Microservice-Systemen
3.2.2.1.. Skalierbarkeit
3.2.2.2.. Sicherheit
3.2.2.3.. Integration und Kommunikation
3.2.2.4.. Application Logging
3.2.3 Architektur eines Microservice
3.2.4 Zusammenfassung und Bewertung
3.3 Mandantenfähigkeit
3.3.1 Herausforderungen
3.3.2 Konzepte auf Datenmodellebene
3.3.2.1.. Shared Machine (Own Database)
3.3.2.2.. Shared Process (Own Schema)
3.3.2.3.. Shared Table
3.3.2.4.. Zusammenfassung
3.3.3 Kontext der Gesamtanwendung
3.4 Zusammenfassung

4 IoT-Referenzarchitektur
4.1 Überblick
4.1.1 Devices-Layer
4.1.2 Connectivity-Layer
4.1.3 Device and Data Management Layer
4.1.4 Application-Layer
4.1.5 Customer Integration Layer
4.2 Messaging
4.3 Microservices
4.3.1 Microservice Customer and User Management
4.3.2 Microservice Device Management
4.3.3 Microservice Device Identity and Access
4.4 Sicherheit
4.4.1 Innerhalb der IoT Anwendung
4.4.2 Zugriff durch Web User
4.4.3 Zugriff durch Systeme
4.5 Application Logging
4.6 Disaster Recovery
4.6.1 Ablauf
4.6.2 Herausforderungen
4.7 Zusammenfassung und Bewertung

5 Use-Case Logistikplattform
5.1 Beschreibung und Anforderungen
5.2 Architekturausprägung
5.2.1 Überblick
5.2.2 Microservices
5.2.2.1.. Microservice Device Management
5.2.2.2.. Microservice Fleet Management
5.2.2.3.. Microservice Transport Management
5.2.3 Sicherheit: Zugriff durch Web User
5.3 Zusammenfassung und Bewertung

6 Reflexion und Ausblick
6.1 Reflexion
6.2 Ausblick

Literaturverzeichnis

Kurzfassung

Unternehmen setzen zunehmend Internet of things (IoT) Projekte um. Nach einer Studie von IDG hat sich die Zahl der umgesetzten IoT Projekte von 2018 auf 2019 verdoppelt. Ein großer Teil der Unternehmen entwickelte die entsprechenden Lösungen dabei selbst (44 %). Die größten Chancen beim Einsatz von IoT sehen die Unternehmen in der Senkung von Kosten und der Erschließung neuer Kundenpotenziale.

Zur Erschließung neuer Kundenpotenziale bieten Unternehmen neue digitale Services für Ihre Kunden an oder bauen neue Geschäftsmodelle auf, die durch den Einsatz von IoT Geräten ermöglicht werden. Die Herausforderung besteht in der Entwicklung digitaler Plattformen, die ein breites Spektrum an technischem Know-how erfordern und es kosteneffizient ermöglichen den Service für viele Kunden bereitzustellen. Die Umsetzung solcher Anwendungen erfolgt zunehmend in Microservice-Architekturen, die vor allem Flexibilität in der Entwicklung, die Reduzierung von Abhängigkeiten und damit eine hohe Fehlertoleranz sowie eine gute Skalierbarkeit ermöglichen. Im Markt werden sowohl verschiedene IoT Plattformen angeboten, die Bausteine für die Entwicklung bieten, als auch teils umfangreichere Referenzarchitekturen und Best Practices bereitgestellt. Einen technologieunabhängigen, konzeptionellen Bauplan für eine IoT Anwendung liefern diese allerdings in den meisten Fällen nicht, da sie sich auf konkrete Technologien und Produkte der Anbieter fokussieren.

Im Rahmen dieser Arbeit wird eine neue, konzeptionelle IoT-Referenzarchitektur für SaaS Anwendungen entworfen, die für die Entwicklung derartiger Plattformen verwendet werden kann. Es werden dazu Anforderungen aus IoT-Referenzarchitekturen und dem Thema SaaS in der Literatur abgeleitet sowie relevante Architekturansätze in Bezug auf die Anforderungen analysiert und Aspekte abgeleitet, die diese Anforderungen unterstützen. Basierend auf den Erkenntnissen wird eine neue Referenzarchitektur entworfen, die sowohl diese Aspekte berücksichtigt und die Anforderungen erfüllt. Da die Ableitung der Referenzarchitektur auf theoretischen Erkenntnissen basiert, wird diese für einen konkreten Anwendungsfall ausgeprägt, um die Übertragbarkeit in die Praxis zu evaluieren.

Abbildungsverzeichnis

Abbildung 1: Vorgehensmodell

Abbildung 2: 5-Layer IoT Architektur (entnommen aus [Wu10], S. V5-486)

Abbildung 3: Funktionale Komponenten eines IoT-basierenden digitalen Geschäftsmodells (entnommen aus [BS15], S. 1)

Abbildung 4: Architekturschichten digitale Geschäftsmodelle (entnommen aus [BS15], S. 4)

Abbildung 5: Technische Referenzarchitektur für IoT-basierende Geschäftsmodelle (entnommen aus [BS15], S. 5)

Abbildung 6: Azure Referenzarchitektur Layer (entnommen aus [Ms18], S. 3)

Abbildung 7: Microsoft Azure IoT Referenzarchitektur (entnommen aus [Ms18], S. 7)

Abbildung 8: Metastruktur IoT-Referenzarchitekturen

Abbildung 9: Grundlegende konzeptionelle IoT-Referenzarchitektur

Abbildung 10: Lambda Architektur (entnommen aus [MW15], S. 19)

Abbildung 11: Batch-Layer Funktionsweise (entnommen aus [MW15], S. 87)

Abbildung 12: Beispiel semantische Normalisierung von Daten (entnommen aus [MW15], S. 33)

Abbildung 13: Beispiel unveränderliches Datenschema (entnommen aus [MW15], S. 35)

Abbildung 14: Kappa Architekturprinzip (entnommen aus [Kr14])

Abbildung 15: Publish/Subscribe Prinzip (entnommen aus [Kr13])

Abbildung 16: Mehrstufiger Datenfluss (entnommen aus [Kr13])

Abbildung 17: Microservice-System

Abbildung 18: Arten von Skalierung (in Anlehnung an [Wo18], Kindle-Position 3074ff.)

Abbildung 19: Ablauf Benutzer- und Rollenverwaltung

Abbildung 20: Logging mit Correlation ID

Abbildung 21: Architektur eines Microservice

Abbildung 22: Ansatz Mandantenfähigkeit auf Datenmodellebene

Abbildung 23: Mandantenfähigkeit im Gesamtkontext

Abbildung 24: IoT-Referenzarchitektur für SaaS Anwendungen basierend auf Microservices

Abbildung 25: Referenzarchitektur eines Microservice

Abbildung 26: Datenmodell Microservice Customer and User Management

Abbildung 27: Datenmodell Microservice Device Management

Abbildung 28: Sicherheit auf Datenebene RawDeviceData

Abbildung 29: Sicherheit auf Datenebene EventMessages

Abbildung 30: Sicherheit bidirektionale Kommunikation mit IoT Devices

Abbildung 31: Ablauf Authentifizierung Web Benutzer

Abbildung 32: Ablauf Authentifizierung durch Systeme

Abbildung 33: Zeitlicher Ablauf Disaster Recovery

Abbildung 34: Disaster Recovery Schritt 1

Abbildung 35: Disaster Recovery Schritt 2

Abbildung 36: Disaster Recovery Schritt 3

Abbildung 37: Domäne Logistikplattform

Abbildung 38: Architekturüberblick Logistikplattform

Abbildung 39: Aufbau eines Microservice in der Logistikplattform

Abbildung 40: Datenmodell Microservice Fleet Management

Abbildung 41: Datenmodell Microservice Transport Management

Abbildung 42: Ablauf Authentifizierung durch Web Benutzer im Use-Case

Tabellenverzeichnis

Tabelle 1: Funktionale Anforderungen aus [BS15] 19

Tabelle 2: Nicht-funktionale Anforderungen aus [BS15]

Tabelle 3: Funktionale Anforderungen Azure IoT Referenzarchitektur

Tabelle 4: Nicht-funktionale Anforderungen Azure IoT Referenzarchitektur

Tabelle 5: Anforderungen an IoT-Referenzarchitekturen

Tabelle 6: Anforderungen an SaaS Anwendungen

Tabelle 7: Anforderung an IoT Referenzarchitekturen für SaaS Anwendungen

Tabelle 8: Unterstützung der Anforderungen durch Literaturansätze

Tabelle 9: Allgemeine Message Attribute

Tabelle 10: Zusätzliche Message Attribute RawDeviceData

Tabelle 11: Zusätzliche Message Attribute EventMessages

Tabelle 12: Funktionale Anforderungen Logistikplattform

Tabelle 13: Rahmenbedingungen Logistikplattform

Tabelle 14: Struktur Rohdaten Telematik

Tabelle 15: Struktur GPS-Nachricht

Tabelle 16: Struktur Reifendruck-Nachricht

Tabelle 17: Struktur Bremsverschleiß-Daten

Tabelle 18: Interne Services Fleet Management

Tabelle 19: Verarbeitung eingehender Nachrichten für Fleet Management

Tabelle 20: Interne Services Transport Management

Tabelle 21: Verarbeitung eingehender Nachrichten für Transport Management

Abkürzungsverzeichnis

Abbildung in dieser Leseprobe nicht enthalten

1 Einleitung

Unternehmen setzen zunehmend Internet of things (IoT) Projekte um. Nach einer Studie von IDG hat sich die Zahl der umgesetzten IoT Projekte von 2018 auf 2019 verdoppelt.¹ Ein großer Teil der Unternehmen entwickelte die entsprechenden Lösungen dabei selbst (ca. 44 %).² Eine mögliche Ursache könnte darin liegen, dass die umzusetzenden Anforderungen bei IoT Projekten oft tief in die Prozesse der Unternehmen greifen und daher sehr individuell sind. Die größten Chancen beim Einsatz von IoT sehen die Unternehmen in der Senkung von Kosten und der Erschließung neuer Kundenpotenziale.³

1.1 Problemstellung

Die Erschließung neuer Kundenpotenziale erfolgt bspw. durch das Angebot neuer, digitaler Services für die Kunden, die durch den Einsatz von IoT Geräten ermöglicht werden. Durch das Angebot solcher Services können Mehrwerte für den Kunden geschaffen werden, die als zusätzliche Einnahmequelle zum bisherigen Geschäft dienen. Darüber hinaus können damit neue Geschäftsmodelle aufgebaut werden. Die Unternehmen stehen hier vor der Herausforderung digitale Plattformen zu entwickeln, die ein breites Spektrum an technischem Know-how erfordern und es kosteneffizient ermöglichen den Service für viele Kunden bereitzustellen. Die Merkmale einer solchen Anwendung definieren sich dabei durch die Anbindung und Verwaltung von IoT Geräten, die Persistenz und Verarbeitung der Daten sowie die Bereitstellung der benötigten Informationen für eine Vielzahl von Kunden. Letzteres erfolgt meist durch Webportale und API-Schnittstellen. Der eigentliche Nutzen entfaltet sich dabei vorwiegend durch die Integration in die Prozesse des Kunden bspw. durch die automatisierte Auslösung von Aktionen. Die Umsetzung solcher Anwendungen erfolgt zunehmend in Microservice-Architekturen, die vor allem Flexibilität in der Entwicklung, die Reduzierung von Abhängigkeiten und damit eine hohe Fehlertoleranz sowie eine gute Skalierbarkeit ermöglichen.

Im Markt gibt es viele Anbieter von IoT Plattformen wie Microsoft, Amazon oder SAP. Diese stellen technische Grundfunktionen zur Kommunikation mit IoT Geräten, zur Persistenz der Daten und Anwendungsschnittstellen bereit, die Kunden als eine Komponente zur Entwicklung einer IoT Anwendung nutzen können. Weiterhin bieten sie Bausteine - z.B. für Stream Processing und Analytics - an, die für die Entwicklung einer IoT Anwendung verwendet werden können. Um dem Kunden den Einstieg zu ermöglichen, werden zum Teil umfangreiche Referenz-architekturen und Best Practices bereitgestellt wie die IoT-Referenzarchitektur von Microsoft. Dabei werden teilweise Referenzimplementierungen auf hohen Abstraktionslevel mit einer möglichen Zusammensetzung einer IoT Anwendung aus den einzelnen Bausteinen des Anbieters bereitgestellt. Einen technologieunabhängigen, konzeptionellen Bauplan für eine IoT Anwendung liefern diese in den meisten Fällen nicht. Dies ist aus Sicht der Anbieter nachvollziehbar, da sie ihre Produkte verkaufen wollen. Für die Unternehmen besteht allerdings die Herausforderung darin eine passende Lösung für ihren Anwendungsfall aus der Vielzahl von Angeboten zu finden. Entscheidend ist dabei, dass die Angebote zwar technische Grundlagen für verschiedene Anforderungen schaffen, die konkrete Nutzung und Implementierung aber individuell erfolgen und im Kontext des Gesamtsystems funktionieren muss.

System- und technologieunabhängige Architekturen, die die oben genannten Merkmale berücksichtigen, sind komplex und müssen durch die Kombination verschiedener Prinzipien, Merkmale und Patterns definiert werden. Dabei ist auf eine Vielzahl von Faktoren zu achten, die für die Entwicklung und den Betrieb des Gesamtsystems von Bedeutung sind. Die Definition dieser Architektur bildet die Grundlage für die Auswahl eines Anbieters und der einzelnen Systemkomponenten.

1.2 Aktueller Stand der Forschung

Ausgehend von der Problemstellung sind für die Definition einer Architektur für IoT Anwendungen verschiedene Aspekte der Forschung relevant. Die kosteneffiziente Bereitstellung der Anwendung für viele Kunden impliziert die Notwendigkeit einer Mandantenfähigkeit, wobei die Kunden sich Ressourcen teilen und damit Kostendegressionseffekte erzielt werden können. In der Literatur finden sich dazu Veröffentlichungen, die sich auf Datenbanken und Schema Mapping in Software as a Service Anwendungen beziehen. Stefan Aulbach als Hauptautor hat dazu „A Comparison of Flexible Schemas for Software as a Service“⁴, „Multi-Tenant Databases for Software as a Service: Schema-Mapping Techniques“⁵ und „Anforderungen an Datenbanksysteme für Multi-Tenancy und Software-as-a-Service-Applikationen“⁶ in Zusammenarbeit mit Mitarbeitern der SAP AG veröffentlich. Veröffentlichungen zu den Implikationen, die die Mandantenfähigkeit auf die anderen Teile eines Gesamtsystems hat, konnten zum Zeitpunkt der Erstellung dieser Arbeit nicht gefunden werden. Das Thema Software as a Service wird vor allem im Bitkom Leitfaden zum Cloud Computing⁷ sowie im „Leitfaden für SaaS-Anbieter“⁸ beleuchtet.

Weiterhin beschäftigt sich das Thema dieser Arbeit mit Microservice-Architekturen, die eine gute Skalierbarkeit ermöglichen. Eine umfangreiche Beschreibung dazu liefert Sam Newman in seinem Buch „Building Microservices: Designing Fine-Grained Systems“⁹. Im deutschsprachigen Raum liefert vor allem Eberhard Wolff viel zu diesem Thema sowie zu verwandten Themen wie DevOps und Continuous Delivery. Sein Buch „Microservices: Grundlagen flexibler Softwarearchitekturen“¹⁰ gibt einen guten Überblick über Microservices und angrenzende Bereiche und berücksichtigt dabei im Vergleich zu Newman weitergehende Aspekte.

Microservices nutzen verschiedene Prinzipien und Patterns, die bereits früher in der Literatur Erwähnung finden. Das erste Buch zu Patterns in der Softwareentwicklung stammt von der „Gang of four“ um Erich Gamma mit dem Buch „Design Patterns. Elements of Reusable Object-Oriented Software“¹¹ aus dem Jahr 1994. Als wichtiger Autor ist hier noch Martin Fowler zu nennen, der sich in „Patterns of Enterprise Application Architecture“¹² mit dem Thema auseinandersetzt. Einen guten Überblick über verschiedene allgemeine Architekturprinzipien und Patterns liefert Helmut Balzert in seinem „Lehrbuch der Softwaretechnik - Entwurf, Implementierung, Installation und Betrieb“¹³. Die Veröffentlichungen sind damit als Grundlagenarbeit für heutige Architekturkonzepte wie Microservices einzuordnen, werden aufgrund des sehr allgemeinen Charakters allerdings nicht tiefer betrachtet.

Die Problemstellung bezieht sich auf IoT Anwendungen, daher lässt sich von Massendaten sprechen, die nahezu in Echtzeit verarbeitet werden müssen. Um dies zu ermöglichen, haben sich in den letzten Jahren zwei wesentliche Architekturansätze herauskristallisiert. Der erste Ansatz ist die Lambda Architektur, die auf den Artikel „How to beat the CAP theorem“¹⁴ von Nathan Marz aus dem Jahr 2011 zurückgeht. Im Buch „Big Data: Principles and best practices of scalable realtime data systems“¹⁵ beschreiben Nathan Marz und James Warren im Jahr 2015 den Ansatz ausführlich unter dem Namen Lambda-Architektur. Der zweite etwas neuere Ansatz ist die Kappa-Architektur, die auf den Linked-In Artikel „The Log: What every software engineer should know about real-time data's unifying abstraction“¹⁶ von Jay Kreps aus dem Jahre 2013 zurückgeht. Der Name Kappa wurde später für diesen Ansatz verwendet, erstmals im Artikel „Questioning the Lambda Architecture“¹⁷ von Jay Kreps im Jahr 2014.

Referenzarchitekturen für IoT Anwendungen finden sich ebenfalls in der Literatur. Diese konzentrieren sich meist in kurzen Veröffentlichungen auf einen konkreten Anwendungsfall wie Smart Metering und beleuchten dabei mehr den technischen Teil vom IoT Gerät über die Übertragung bis hin zur Anwendung. Referenzarchitekturen, die sich mehr auf die Anwendung konzentrieren und damit näher mit dem Thema dieser Arbeit verwandt sind, finden sich ebenfalls. Hier ist die „Microsoft Azure IoT Reference Architecture“¹⁸ zu nennen, die sowohl konzeptionell als auch bezogen auf konkrete Microsoft Azure Produkte das Thema recht umfangreich betrachtet. Wu et al. beschreiben in „Research on the architecture of Internet of things“¹⁹ eine sehr abstrakte 5-Schichten Architektur, die die vorher bekannte 3-Schichten Architektur des Internet of things erweitert. In „Eine Referenzarchitektur für IoT-basierende digitale Geschäftsmodelle“²⁰ beschreiben Dominik Bial und Rolf Scheuch eine Referenzarchitektur, die den Aspekt der digitalen Geschäftsmodelle aufgreift.

Schaut man sich die Literatur zum Internet of things (IoT) an, beschäftigt sich diese im Wesentlichen mit den Sensoren und Geräten, die die Daten liefern bis hin zur Übertragung der Daten sowie der Absicherung von Geräten und Übertragung. Darüber hinaus ist ein wichtiger Teil das Edge Computing, bei dem es darum geht Logiken und auch Modelle auf die Geräte zu bringen, die Daten bereits direkt auf dem Gerät analysieren, aggregieren und nur die relevanten Daten weiter - z.B. an Cloud Plattformen - übertragen, um so die teilweise immensen Datenmengen vorzufiltern. Da die Problemstellung sich auf die Architektur für eine IoT Anwendung konzentriert, setzt diese bei der Ankunft der IoT-Daten zur Verarbeitung innerhalb der Anwendung auf. Dieser Teil der Forschung wird daher in der vorliegenden Arbeit nicht weiter betrachtet.

1.3 Forschungsfragen

Auf Basis der Problemstellung und des aktuellen Standes der Forschung lassen sich vier Forschungsfragen formulieren, deren Beantwortung den Kern dieser Arbeit darstellt. Um eine technologieunabhängige Referenzarchitektur entwerfen zu können, die die in der Problemstellung behandelten Hauptaspekte IoT und SaaS berücksichtigt, müssen zunächst Anforderungen aus den beiden Themen abgeleitet werden. Daher ergibt sich als erste Forschungsfrage:

RQ1 Welche Anforderungen an eine IoT-Referenzarchitektur ergeben sich aus bestehenden IoT-Architekturansätzen sowie Software as a Service Anwendungen im Allgemeinen?

In der Literatur werden Ansätze für Architekturen unterschiedlicher Anwendungsarten beschrieben. Um eine Referenzarchitektur abzuleiten, müssen die relevanten Ansätze vor dem Hintergrund der Anforderungen analysiert werden. Als zweite Forschungsfrage ergibt sich damit:

RQ2 Welche theoretischen Ansätze aus der Literatur sind hinsichtlich der Anforderungen an eine IoT-Referenzarchitektur für das Design in welcher Ausprägung relevant?

Die Problemstellung beschreibt im Kern die Herausforderung für Unternehmen eine IoT-Architektur für Software as a Service Anwendungen zu definieren, die es ihnen ermöglicht, neue Services und Geschäftsmodelle für ihre Kunden bereitzustellen. Der Kern der Arbeit besteht damit in der dritten Forschungsfrage:

RQ3 Welche Architektur ist als IoT-Referenzarchitektur hinsichtlich der Anforderungen - unter Berücksichtigung von Ansätzen aus der Literatur - geeignet, um Software as a Service Anwendungen basierend auf Microservices zu entwerfen?

Die Beantwortung der ersten drei Forschungsfragen und damit die Referenzarchitektur basiert im Wesentlichen auf der Analyse und Ableitung von theoretischen Inhalten. Um die Relevanz für die Praxis zu zeigen und damit das Ergebnis zu validieren, muss abschließend die vierte Forschungsfrage beantwortet werden:

RQ4 Lässt sich die entworfene IoT-Referenzarchitektur auf einen konkreten Use-Case anwenden?

1.4 Forschungsziel und Zielgruppen

Ausgehend von der Problemstellung und den Forschungsfragen ist das Ziel der Arbeit der Entwurf einer technologieunabhängigen Referenzarchitektur für die Entwicklung einer SaaS IoT Anwendung, die die folgenden Rahmenparameter berücksichtigt:

- Webportal für die Interaktion der Nutzer mit der Anwendung
- API-Schnittstellen zur Interaktion von Drittsystemen mit der Anwendung
- Architektur basierend auf Microservices

IoT Devices sowie die Übertragung der Daten bis hin zur IoT Anwendung werden in dieser Arbeit nicht betrachtet.

Für die Arbeit ergeben sich daraus drei wesentliche Ziele, die sich aus der Problemstellung und den formulierten Forschungsfragen ableiten lassen:

1. Das Erkenntnisziel besteht in der Identifikation von Anforderungen an die Referenzarchitektur, die sich aus den Bereichen IoT und SaaS ergeben, sowie in der Analyse von Ansätzen aus der Literatur, die für die Definition der Referenzarchitektur relevant sind.
2. Das erste Gestaltungsziel besteht im Entwurf einer Referenzarchitektur, die die Anforderungen erfüllt und für verschiedene IoT Anwendungsfälle als Grundlage verwendet werden kann.
3. Das zweite Gestaltungsziel besteht in der Validierung der Referenzarchitektur anhand eines konkreten Use Cases, womit die Übertragbarkeit in die Praxis evaluiert werden soll.

Das Erreichen des ersten Erkenntnisziels ist die Voraussetzung zur Erreichung des zweiten übergeordneten Gestaltungsziels. Ohne die Anforderungen und Implikationen aus den Themen IoT und Saas sowie relevanten Ansätzen aus der Literatur zu kennen, kann keine geeignete Referenzarchitektur entworfen werden. Damit liegt hier eine Zielhierarchie vor, in der das zweite Gestaltungsziel als übergeordnet und das Erkenntnisziel als untergeordnet angesehen werden können. Das Erreichen des zweiten Gestaltungsziels ist die Voraussetzung für das Erreichen des dritten übergeordneten Gestaltungsziels, denn ohne die Definition der Referenzarchitektur kann keine Übertragbarkeit anhand eines Use-Cases gezeigt werden. Somit liegt hier ebenfalls eine Zielhierarchie vor, bei der das zweite Gestaltungsziel als untergeordnet und das dritte Gestaltungsziel als übergeordnet angesehen werden kann.

Die Arbeit richtet sich an alle IT-Architekten in Unternehmen und anderen Organisationen, die vor der Herausforderung stehen, durch den Einsatz von IoT-Technologien, Lösungen für eine Vielzahl von Kunden zu konzipieren und zu entwickeln und dabei gleiche oder ähnliche Rahmenparameter berücksichtigen müssen. Als weitere Zielgruppe richtet sich die Arbeit an IT-Architekten im Beratungsumfeld, die vor der Herausforderung stehen, eine solche Architektur für Kunden zu konzipieren. Zuletzt ist die Arbeit an alle gerichtet, die das Thema IT-Architekturen und IoT Anwendungen interessiert und die sich ähnlichen Herausforderungen stellen müssen.

1.5 Forschungsmethoden- und vorgehen

Zur Erstellung von Referenzarchitekturen existieren in der Literatur keine einheitlichen Methodiken. Weder in der Literatur noch in der Praxis gibt es in dieser Ausprägung für das Thema offen verfügbare Architekturen. Für den Teilaspekt IoT-Referenzarchitektur gibt es wenige Publikationen, die sich auf einem hohen Abstraktionslevel befinden und den SaaS-Aspekt nicht berücksichtigen. Für den Aspekt SaaS gibt es keine Publikationen zu Referenzarchitekturen, lediglich Publikationen, die sich auf Datenmodelle in mandantenfähigen Systemen beschränken (vgl. 1.2). Es wird daher ein Vorgehensmodell in Anlehnung an [RK16] gewählt, die ebenfalls vor der Herausforderung standen, dass keine oder wenig offene Architekturen für das Thema existierten. Das Vorgehen orientiert sich an den Grundkonzepten der gestaltungsorientierten Wirtschaftsinformatik²¹ und beinhaltet die drei Phasen Analyse, Design und Evaluation. Die nachfolgende Abbildung zeigt die drei Phasen mit den jeweiligen Teilschritten und Abhängigkeiten.

Abbildung in dieser Leseprobe nicht enthalten

Abbildung 1: Vorgehensmodell

Im Analyseschritt werden zunächst in einer Literaturrecherche IoT Referenzarchitekturen beschrieben und hinsichtlich der Gemeinsamkeiten analysiert. Ziel der Analyse ist die Ableitung von funktionalen und nicht-funktionalen Anforderungen für den Teilaspekt Internet of Things, die für die Ableitung einer IoT-Referenzarchitektur für SaaS Anwendungen herangezogen werden können (Kapitel 2). Zusätzlich wird Literatur zum Thema SaaS analysiert, mit dem Ziel funktionale und nicht-funktionale Anforderungen für diesen Teilaspekt abzuleiten, die für die Referenzarchitektur herangezogen werden müssen. Mit diesen Schritten soll die erste Forschungsfrage RQ1 beantwortet werden. Im Rahmen der Analyse werden anschließend mittels Literaturrecherche Architekturansätze und Ansätze zur Umsetzung von Mandantenfähigkeit ermittelt, analysiert und Aspekte abgeleitet, die die vorher definierten Anforderungen unterstützen (Kapitel 3). Dieser Schritt soll die zweite Forschungsfrage RQ2 beantworten.

In der Designphase wird unter Berücksichtigung der Anforderungen und der Analyseergebnisse der Architekturansätze und der Ansätze zur Mandantenfähigkeit in einem konzeptionell-deduktiven Verfahren eine Referenzmodellierung durchgeführt. Diese beinhaltet die Ableitung einer IoT-Referenzarchitektur für SaaS Anwendungen, die auf Microservices basiert (Kapitel 4). Damit soll der Kern der Arbeit und damit die dritte Forschungsfrage RQ3 beantwortet werden.

Bei der Evaluation als dritte Phase wird zunächst ein realitätsnaher Use-Case zum Thema Logistikplattform mit spezifischen Anforderungen definiert. Anhand der Anforderungen wird die Referenzarchitektur auf den Use-Case übertragen und ausgeprägt. Abschließend erfolgt eine Evaluierung, ob die Anforderungen des Use-Cases mit der ausgeprägten Architektur erfüllt werden. Dieser Schritt dient dazu, die Übertragbarkeit der Referenzarchitektur, die auf theoretischen Erkenntnissen basiert, auf ein realitätsnahes Beispiel zu zeigen (Kapitel 5). Damit soll sichergestellt werden, dass die Referenzarchitektur einen echten Nutzen für Unternehmen mit ähnlichen Herausforderungen, wie in der Problemstellung beschrieben, erfüllt. Dieser Schritt soll die vierte und letzte Forschungsfrage RQ4 beantworten.

2 Anforderungen Referenzarchitektur

Zum Entwurf einer IoT-Referenzarchitektur für SaaS Anwendungen müssen zunächst Anforderungen ermittelt werden, die erfüllt werden müssen. In diesem Kapitel werden daher die beiden Teilaspekte IoT-Referenzarchitekturen und Software as a Service Anwendungen analysiert, mit dem Ziel die Anforderungen abzuleiten. Die Anforderungen werden in funktionale und nicht-funktionale Anforderungen aufgeteilt und mit einer eindeutigen Referenz beschrieben, die im weiteren Verlauf der Arbeit verwendet wird. Es wird damit in der Zusammenfassung die erste Forschungsfrage RQ1 dieser Arbeit beantwortet: Welche Anforderungen an eine IoT-Referenzarchitektur ergeben sich aus bestehenden IoT-Architekturansätzen sowie Software as a Service Anwendungen im Allgemeinen?

2.1 IoT-Referenzarchitekturen

In diesem Kapitel werden verschiedene IoT-Referenzarchitekturen aus der Wissenschaft und Wirtschaft beschrieben und analysiert. Ziel dabei ist es, grundlegende funktionale und nicht-funktionale Anforderungen abzuleiten für den Teilaspekt IoT Referenzarchitekturen. Für jede der analysierten Referenzarchitekturen werden Anforderungen mit einer Referenz abgeleitet. Am Ende des Kapitels werden die Anforderungen mit einer neuen Referenz konsolidiert.

Zum besseren Verständnis der Arbeit werden zunächst einige Begriffe im Kontext IoT definiert und voneinander abgegrenzt, die im Rahmen dieser Arbeit verwendet werden.

Für den Begriff Internet of Things existiert keine einheitliche Definition in der Literatur. In Anlehnung an [LS18] wird folgende Definition für die Zwecke dieser Arbeit festgelegt:

Internet of Things bezeichnet die Vernetzung von physischen Gegenständen durch den Einsatz von Sensoren und Aktuatoren mit dem Internet, um die Erledigung verschiedener Aufgaben, die Automatisierung von Prozessen und das Angebot neuer Geschäftsmodelle zu ermöglichen.

Edge-Computing bezeichnet die dezentrale Verarbeitung der Daten von IoT Devices in physikalischer Nähe zu den Devices. Die Verarbeitung erfolgt dabei häufig in lokalen Gateways, die Daten vorfiltern und an zentrale Systeme senden.

IoT Device bezeichnet die physischen Geräte im Internet of Things, die mittels Sensorik Daten erfassen und über ein Netzwerk übertragen. Dies können Geräte sein, die direkt über das Internet oder auch über Edge Komponenten kommunizieren. Im Rahmen dieser Arbeit wird der Begriff Device als Synonym zu IoT Device verwendet.

Es ist festzustellen, dass bisher wenige IoT-Referenzarchitekturen in der Literatur beschrieben werden. Diese lassen sich inhaltlich in zwei Kategorien aufteilen:

1. Layer-Architekturen mit hohem Abstraktionslevel

Bei diesen Ansätzen wird eine IoT-Anwendung in verschiedene Schichten unterteilt. Zu den Schichten werden Beschreibungen geliefert, welche Funktionen diese beinhalten. In dieser Kategorie finden sich die einzigen wissenschaftlichen Veröffentlichungen zu IoT-Referenzarchitekturen. In [Wu10] wird eine 5-Layer Referenzarchitektur definiert, die auf der vorher bekannten 3-Layer Architektur aufsetzt. Die 3-Layer Architektur hat einen sehr hohen Abstraktionslevel und ist wenig differenziert, was im mittleren Layer zu einer Vermischung von Datenübertragung und Datenverarbeitung führt, die nicht sinnvoll erscheint. Darüber hinaus wird die Architektur von [Wu10] sehr knapp und teilweise diffus beschrieben und es gibt keine Quelle, die den Ursprung dieses Ansatzes nachvollziehbar macht. Es können daher keine konkreten Anforderungen an IoT Referenzarchitekturen abgeleitet werden, weshalb die 3-Layer Architektur nicht weiter im Rahmen dieser Arbeit berücksichtigt wird.

Die 5-Layer Architektur wird von verschiedenen späteren Veröffentlichungen genutzt. In [Kh12] werden Entwicklungstrends, zukünftige Anwendungsfälle und die 5-Layer Architektur von [Wu10] als generische Architektur für das Internet of Things beschrieben. [Va17] beschreibt die 5-Layer Architektur von [Wu10], ohne diese zu referenzieren, sowie verschiedene Sicherheitsaspekte zu den verschiedenen Layern (Schichten). In [Pi20] wird die 5-Layer Architektur ebenfalls als Basis genommen, wobei ein Mapping auf die Cloud Services der drei großen Anbieter Google, Amazon und Microsoft erfolgt, mit dem Ziel eine Evaluierung der Performance der Anbieter durchzuführen. Die Architektur stellt eine Weiterentwicklung der 3-Layer Architektur dar, die eine differenziertere Aufteilung der Layer beinhaltet und mehrfach in der Literatur referenziert wird. Diese wird daher in der Arbeit näher betrachtet.

Darüber hinaus wird in einem White Paper Entwurf von Cisco ([Ci14]) eine 7-Layer Referenzarchitektur für IoT beschrieben, die keinen der anderen Ansätze referenziert. Inhaltlich lehnt sich diese stark an die 5-Layer Architektur an, jedoch mit zwei wesentlichen Unterschieden: Das Edge Computing wird als eigene Schicht dargestellt und die Verarbeitung der Daten wird in zwei Layer aufgeteilt. Ersteres ist nicht Betrachtungsgegenstand dieser Arbeit und inhaltlich nicht konsistent, da es lediglich eine Übertragungsschicht zwischen Devices und Edge Komponenten gibt, aber keine Übertragungsschicht von dort zur zentralen Schicht zur Datenverarbeitung. Die Aufteilung der Datenverarbeitung beinhaltet zunächst die Umwandlung der Event-basierten Daten der Devices zu persistent gespeicherten Daten, die dann weiter abgefragt werden. Es handelt sich dabei nach Auffassung des Autors dieser Arbeit um eine Meta-Struktur mit inhaltlichen Inkonsistenzen, aus der keine konkreten Anforderungen abgeleitet werden können und die keinen Mehrwert im Rahmen der Themenbearbeitung gegenüber der 5-Layer Architektur bietet. Die 7-Layer Architektur wird daher nicht weiter betrachtet.

2. Architekturen mit detaillierterer funktionaler Sicht

Detailliertere Architekturen finden sich in zwei Veröffentlichungen aus der Wirtschaft. Diese definieren ebenfalls Layer, zeigen darüber hinaus aber die Innensicht detaillierter. Bial und Scheuch definieren in [BS15] eine Referenzarchitektur, die den Aspekt der digitalen Geschäftsmodelle berücksichtigt. Vor dem Hintergrund der Problemstellung ist dieser Aspekt relevant, da IoT Anwendungen gänzlich neue Services oder Geschäftsmodelle für ein Unternehmen ermöglichen können (vgl. 1.1). Microsoft beschreibt in [Ms18] eine IoT-Referenzarchitektur, die die strukturelle Innensicht der Layer unter Berücksichtigung von Querschnittsfunktionen wie Security und Disaster Recovery sowie grundsätzlicher Konzepte und Prinzipien mit Bezug zu den einzusetzenden Komponenten von Microsoft Azure definiert. Die Veröffentlichung enthält sowohl rein konzeptionelle Teile als auch konkrete Empfehlungen zu Produkten, die im Rahmen dieser Arbeit nicht relevant sind. Beide Veröffentlichungen sind nah mit dem Thema dieser Arbeit verwandt und ermöglichen die Ableitung konkreter Anforderungen für den Teilaspekt IoT im Rahmen des Entwurfs einer Referenzarchitektur. Sie werden daher in der Arbeit näher beleuchtet.

2.1.1 5-Layer

Die 5-Layer Architektur ist eine Weiterentwicklung der 3-Layer Architektur von [Wu10] auf einem hohen Abstraktionslevel. Die Schichten sind dabei differenzierter und detaillierter beschrieben. Die folgende Abbildung zeigt die fünf Schichten der Referenzarchitektur.

Abbildung in dieser Leseprobe nicht enthalten

Abbildung 2: 5-Layer IoT Architektur (entnommen aus [Wu10], S. V5-486)

Der Perception Layer beinhaltet die Erfassung von Informationen zu physischen Objekten, bspw. über Sensoren, sowie die Transformation der Informationen in digitale Signale, die über Netzwerke übertragen und damit von anderen gelesen werden können.²² Der Layer beinhaltet vereinfacht gesagt die IoT Devices, die im Rahmen dieser Arbeit nicht näher betrachtet werden.

Der Transport Layer überträgt die Daten aus dem Perception Layer über verschiedene Netzwerke, damit diese vom Processing Layer verarbeitet werden können.²³ Die Übertragung der Daten ist ebenfalls nicht Bestandteil des Themas dieser Arbeit und wird nur rudimentär betrachtet.

Im Processing Layer werden die übertragenen Informationen zu Objekten aus dem Perception Layer gespeichert, analysiert und verarbeitet. Die Autoren haben hierfür einen eigenen Layer vorgesehen, da im IoT Bereich meist große Datenmengen anfallen, deren Speicherung und Verarbeitung eine Herausforderung darstellt und als komplex einzustufen ist.²⁴

Der Application Layer basiert auf den Daten aus dem Processing Layer und beinhaltet die Applikationen für verschiedene Anwendungsfälle wie z.B. intelligente Logistik, die den Geschäftsnutzen erzeugen.²⁵

Der Business Layer verwaltet die Applikationen und Geschäftsmodelle, überwacht die Geschäftsmodelle und entwickelt diese weiter. Darüber hinaus ist er für die Freigabe und Abrechnung der Applikationen sowie die Privatsphäre der Nutzer zuständig.²⁶ Die Beschreibung der Autoren ist nicht eindeutig zu interpretieren. Die Verwaltung und Überwachung von Geschäftsmodellen könnte ein technologieunabhängiges Management der Anwendungen meinen. Ebenso könnte dies aber auch dafürsprechen, dass hier Funktionalitäten enthalten sind, die die notwendigen Daten erfassen und auswerten, die für das Management der Geschäftsmodelle und Anwendungen notwendig sind. Die Freigabe und Abrechnung von Applikationen sowie der Schutz der Privatsphäre der Nutzer deuten darauf hin, dass eine zentrale Rollen- und Benutzerverwaltung enthalten sein soll, über die Applikationen für Nutzer freigeschaltet werden können.

Die 5-Layer Architektur bewegt sich auf einem hohen Abstraktionslevel. Die unteren vier Layer sind technisch geprägt und bauen aufeinander auf. Die Aufteilung und der Aufbau erscheinen dabei durchdacht und gut strukturiert. Darüber hinaus kommt mit dem Business Layer auch die Sicht auf Geschäftsmodelle dazu, wobei hier nicht klar zu verstehen ist, was genau die Aufgabe des Business Layers ist. Aufgrund des hohen Abstraktionslevels lassen sich hier keine konkreten Anforderungen an eine IoT-Referenzarchitektur ableiten. Die Aufteilung der Layer kann allerdings als Input für eine Metastruktur einer IoT Referenzarchitektur herangezogen werden.

2.1.2 Referenzarchitektur für IoT-basierende Geschäftsmodelle

In [BS15] beschreiben Bial und Scheuch eine technische Referenzarchitektur für IoT-basierende Geschäftsmodelle. Hier steht explizit der Aspekt digitaler Geschäftsmodelle im Vordergrund. In der Problemstellung werden das Angebot digitaler Services und neuer Geschäftsmodelle auf Basis von IoT als die zwei wesentlichen Gründe für Unternehmen zur Entwicklung von IoT Anwendungen beschrieben (vgl. 1.1). Das unterstreicht die Relevanz der Veröffentlichung von Bial und Scheuch für das Thema dieser Arbeit. Sie definieren ein digitales Geschäftsmodell wie folgt: „Ein digitales Geschäftsmodell beschreibt die Grundlogik wie eine Organisation mithilfe der Informationstechnologie und digitaler Produkte Werte schafft.“²⁷ Der Unterschied zu klassischen Geschäftsmodellen besteht hier in der absoluten Abhängigkeit von der Informationstechnologie. Mehrwerte werden durch digitale Produkte geschaffen.²⁸ Abgrenzend betrachten die Autoren nur digitale Geschäftsmodelle, die auf IoT basieren.

2.1.2.1 Funktionale Sicht

Die folgende Abbildung 3 spiegelt die funktionalen Komponenten eines digitalen Geschäftsmodells aus Sicht der Autoren wider.

Abbildung in dieser Leseprobe nicht enthalten

Abbildung 3: Funktionale Komponenten eines IoT-basierenden digitalen Geschäftsmodells (entnommen aus [BS15], S. 1)

Die Darstellung erfolgt anhand der Wertschöpfungskette, die beim Senden von Zustandsinformationen eines Devices (in der Abbildung „Ding“) beginnt. Die übermittelten Daten werden verarbeitet und aufbereitet (Data Routing & Analysis). Die aufbereiteten Daten werden von Applikationen genutzt, um neue Geschäftsmodelle und Services bereitzustellen und damit den eigentlichen Mehrwert für den Kunden zu erzeugen. Sowohl aus den übermittelten und aufbereiteten Daten als auch aus den Applikationen kann sich die Notwendigkeit ergeben, auf geänderte Bedingungen zu reagieren, die das Verhalten der Devices verändern. Dazu wird ein Device Management benötigt, das diese Verhaltensänderungen an die Devices überträgt. Daraus lassen sich zwei grundlegende Anforderungen an eine IoT Referenzarchitektur ableiten:

1. IoT Devices müssen Daten an die IoT Anwendung senden und die Anwendung muss diese entgegennehmen können.
2. IoT Anwendungen müssen mit IoT Devices kommunizieren können.

Die technische Referenzarchitektur (2.1.2.3) fokussiert sich auf den Bereich Daten- und Devicemanagement in Abbildung 3, da die Autoren Applikationen und Geschäftsmodelle für zu unterschiedlich halten, um diese zu abstrahieren. Nach Meinung des Autors dieser Arbeit sind die Applikationen und Geschäftsmodelle zwar sehr unterschiedlich, lassen sich jedoch unter Verwendung geeigneter Patterns konzeptionell abstrahieren und werden daher in der Referenzarchitektur im Rahmen dieser Arbeit berücksichtigt werden.

Die Autoren beschreiben weiterhin ausführlich ein Referenzmodell für autonome Gegenstände. Da im Rahmen dieser Arbeit die IoT Devices nicht betrachtet werden, wird hierauf im Rahmen der Arbeit nicht weiter eingegangen. Für nähere Informationen sei auf [BS15], S. 3f. verwiesen.

2.1.2.2 Architekturschichten digitaler Geschäftsmodelle

Abgeleitet aus den funktionalen Komponenten, definieren die Autoren grundlegende Architekturschichten für digitale Geschäftsmodelle wie in der folgenden Abbildung dargestellt.

Abbildung in dieser Leseprobe nicht enthalten

Abbildung 4: Architekturschichten digitale Geschäftsmodelle (entnommen aus [BS15], S. 4)

Hier wird eine grundsätzliche Aufteilung in die physische, lokale Welt (Devices) und die globale, digitale Welt vorgenommen. Dabei sind im gestrichelten Kasten die Bereiche gekennzeichnet, die von den Autoren in der technischen Referenzarchitektur betrachtet werden. Diese spiegeln das Daten- und Devicemanagement aus Abbildung 3 wieder. Die Schichten in Abbildung 4 können von unten nach oben als Wertschöpfungskette gesehen werden, in der die Daten durch jeden Verarbeitungsschritt einen höheren Mehrwert bieten. Im Rahmen dieser Arbeit wird gemäß der Themenabgrenzung die globale, digitale Welt betrachtet, die im Wesentlichen einer IoT Anwendung im Sinne der Definition des Themas entspricht. Diese kann wiederum verschiedene Applikationen beinhalten.

2.1.2.3 Technische Referenzarchitektur

Die technische Referenzarchitektur für den Bereich Daten- und Devicemanagement bildet den Kern der Veröffentlichung von Bial und Scheuch und beinhaltet die grundlegenden Komponenten für eine Architektur für IoT-basierende Geschäftsmodelle aus Sicht der Autoren. Die Referenzarchitektur wird in der folgenden Abbildung dargestellt und in diesem Kapitel näher erläutert.

Abbildung in dieser Leseprobe nicht enthalten

Abbildung 5: Technische Referenzarchitektur für IoT-basierende Geschäftsmodelle (entnommen aus [BS15], S. 5)

Die Referenzarchitektur wird von den IoT Devices (links) über verschiedene Übertragungs- und Verarbeitungsstufen bis zu den Applikationen für das Geschäftsmodell (rechts) dargestellt und folgt damit der Darstellung der funktionalen Sicht und den Architekturschichten digitaler Geschäftsmodelle (Abbildung 3 und Abbildung 4), wobei nur der Teilbereich Daten- und Devicemanagement betrachtet wird. Im Folgenden werden die Schichten und Komponenten von links nach rechts aus Sicht der Autoren erläutert, wobei Komponenten wie Firewalls, die im Rahmen der Themenabgrenzung dieser Arbeit nicht relevant sind, ausgelassen werden.²⁹

„Daten sammeln“ beinhaltet physische Sensoren und Devices, die entweder direkt oder über ein lokales Gateway mit einem zentralen Gateway kommunizieren, also ihre Daten übertragen. Dieser Teil ist nicht Betrachtungsgegenstand der Arbeit und wird nicht näher beleuchtet.

„Daten anreichern“ beinhaltet lokale Gateways, die Edge Computing Funktionalitäten abbilden. Dieser Teil ist nicht Betrachtungsgegenstand der Arbeit und wird nicht näher beleuchtet.

„Daten übertragen“ beinhaltet ein zentrales Gateway, das die bidirektionale Kommunikation mit den Devices übernimmt. Hier beginnt nach der Definition der beiden Autoren die „globale, digitale Welt“ (vgl. Abbildung 4). Nach der Themenabgrenzung dieser Arbeit ist dies ein relevanter Bestandteil und wird als Komponente für den Entwurf der Referenzarchitektur berücksichtigt.

„Daten- / Device Management“ beinhaltet Komponenten zur Verwaltung der Devices auf der Anwendungsseite sowie Komponenten zum Datenmanagement. Das Device Management beinhaltet ein Identity und Access Management, das die Authentifizierung und Autorisierung der Devices sicherstellt. Damit soll die Manipulation von gesendeten Daten verhindert und sichergestellt werden, dass nur Daten von bekannten Devices entgegengenommen werden. Weiterer Bestandteil des Device Managements ist eine Device Registrierung, die das Ansteuern eines Gerätes - z.B. zum Update von Softwareständen oder von Parametern im Rahmen des Application Provisioning - ermöglicht. Das Datenmanagement beinhaltet eine erste Analyse der übertragenen Daten sowie eine schnelle Verarbeitung der Rohdaten und erzeugt ggfs. erste Events für die weitere Verarbeitung der Daten im Rahmen des Geschäftsmodells. Daraus lassen sich folgende Anforderungen ableiten:

- Bidirektionale Kommunikation der IoT-Anwendung mit den Devices muss möglich sein.
- Identität und Autorisierung der Devices muss sichergestellt werden (Security).
- Management von Devices

- Provisionierung von Änderungen auf das Device muss möglich sein (z.B. Softwareversionen, Parameteränderungen).
- Empfang von Device-Daten muss möglich sein.

„Daten aufbereiten und analysieren“ beinhaltet als übergreifende Komponente ein Monitoring der Systeme als Querschnittsfunktion. Weiterhin wird eine persistente Speicherung von Daten in passenden Systemen entsprechend der Anforderungen benötigt. Als Kernbestandteil sehen die Autoren die Notwendigkeit eines BPM-Systems, um komplexe Integrationsprozesse in andere Systeme sowie „Dunkelverarbeitungen“ zu ermöglichen. Damit soll die Integration in bestehende Backendsysteme ermöglicht werden (Enterprise Integration). Als letzte Komponente beschreiben die Autoren IoT Analytics. Dies ist eine übergreifende Analyse der Daten mit dem Ziel, Entscheidungshilfen zu schaffen, die einer verbesserten Wertschöpfung dienen. Auch können die gewonnen Informationen und Erkenntnisse selbst zu einem Produkt eines digitalen Geschäftsmodells werden.

2.1.2.4 Zusammenfassung und Anforderungen

Die Veröffentlichung von Bial und Scheuch bietet einen umfangreichen Blick auf grundsätzliche Anforderungen an eine IoT-Architektur. Insbesondere der Fokus auf digitale Geschäftsmodelle im Rahmen der funktionalen Sicht und Architekturschichten digitaler Geschäftsmodelle berücksichtigt wesentliche Beweggründe der Unternehmen für den Aufbau einer IoT-Anwendung (vgl. 1.1). Deutlich wird, dass IoT Anwendungen eine mehrstufige Wertschöpfung beinhalten. Dabei nimmt der Wert im Verlauf der Anreicherung bzw. Verarbeitung der Daten vom Device bis hin zu Prozessintegrationen in bestehende Systeme und zur Bereitstellung von Applikationen immer weiter zu. So wird es Unternehmen ermöglicht, neue Geschäftsmodelle anzubieten, die auf den gewonnenen Informationen und der Kombination dieser mit anderen Daten beruhen. Das Verständnis einer IoT Anwendung als Wertschöpfungskette findet sich inhaltlich, wenn auch nicht explizit so angegeben, ebenfalls in der 5-Layer Architektur wieder.

In der technischen Referenzarchitektur werden konkrete Systeme und Funktionen beschrieben, die aus Sicht der Autoren für eine IoT Anwendung benötigt werden. Für den Entwurf einer konzeptionellen, auf die Software gerichteten Referenzarchitektur sind die Systeme allerdings nicht relevant (vgl. 1.4). Aus den beschriebenen Funktionen der Systeme lassen sich aber konkrete funktionale und nicht-funktionale Anforderungen an eine IoT-Referenzarchitektur ableiten, die für den Entwurf im Rahmen der Themenabgrenzung dieser Arbeit herangezogen werden können. Im Folgenden werden die funktionalen und nicht-funktionalen Anforderungen aufgeführt, die aus [BS15] abgeleitet werden.

1. Funktionale Anforderungen

In Tabelle 1 werden zusammenfassend die funktionalen Anforderungen an eine IoT-Referenzarchitektur mit Referenznummer beschrieben, die aus der Referenzarchitektur für IoT-basierende digitale Geschäftsmodelle abgeleitet werden.

Tabelle 1: Funktionale Anforderungen aus [BS15]

Abbildung in dieser Leseprobe nicht enthalten

2. Nicht-funktionale Anforderungen

In der folgenden Tabelle 2 werden zusammenfassend die nicht-funktionalen Anforderungen an eine IoT-Referenzarchitektur mit Referenznummer beschrieben, die aus der Referenzarchitektur für IoT-basierende digitale Geschäftsmodelle abgeleitet werden.

Tabelle 2: Nicht-funktionale Anforderungen aus [BS15]

Abbildung in dieser Leseprobe nicht enthalten

2.1.3 Microsoft Azure IoT Referenzarchitektur

[Ms18] beschreibt eine technologieunabhängige Referenzarchitektur, die Querschnittsfunktionen, Prinzipien sowie Konzepte beinhaltet. Darüber hinaus erfolgt eine Einordnung anhand der für die Architekturkomponenten einzusetzenden Azure Services, Bausteine und Technologien. Da die zu entwerfende Referenzarchitektur im Rahmen dieser Arbeit technologieunabhängig definiert werden soll, wird auf konkrete Produkte und Technologien nicht näher eingegangen.

Der Grundaufbau der Architektur erfolgt in drei Layern, die prozessorientiert von der Entstehung der IoT Daten über verschiedene Verarbeitungsschritte hin zu auszuführenden Aktionen auf Basis der Informationen gehen (vgl. Abbildung 6). Die Grundlogik ist damit ähnlich zum Ansatz von Bial und Scheuch und kann auch hier als Wertschöpfungskette verstanden werden.

Abbildung in dieser Leseprobe nicht enthalten

Abbildung 6: Azure Referenzarchitektur Layer (entnommen aus [Ms18], S. 3)

Der Ansatz stützt sich auf zwei Grundüberlegungen. Es gibt verschiedene Subsysteme, die voneinander unabhängige, deploybare Einheiten sein müssen und sich unabhängig voneinander skalieren lassen.³⁰ Dieser Grundansatz folgt der Idee von Microservices, die für das Thema dieser Arbeit eine zentrale Rolle spielen (vgl. 1.4) und auf die im Verlaufe dieser Arbeit noch näher eingegangen wird. Die zweite Grundüberlegung ist, dass ein Monitoring der Subsysteme sowie der IoT Applikation im Ganzen möglich sein muss. Diese Notwendigkeit ergibt sich aus der Grundüberlegung von unabhängigen Subsystemen und wird in der weiteren Beschreibung des Ansatzes verdeutlicht.

2.1.3.1 Architekturbeschreibung

Abbildung 7 zeigt die Referenzarchitektur von Microsoft. Grün werden Subsysteme für Core Komponenten (relevant für jedes Szenario) dargestellt, blau sind optionale Subsysteme.

Die Subsysteme und deren Funktionalitäten werden im Folgenden aufgeteilt nach den drei Layern „Things“, „Insights“ und „Action“ beschrieben.

Things

Beinhaltet die IoT Devices (Dinge), die Daten generieren, senden und empfangen. IoT Devices sind dabei Devices, die sich direkt an der Cloud authentifizieren und die Konnektivität zum Senden und Empfangen von Daten direkt herstellen können.³¹

Abbildung in dieser Leseprobe nicht enthalten

Abbildung 7: Microsoft Azure IoT Referenzarchitektur (entnommen aus [Ms18], S. 7)

Das Bulk Device Provisioning als optionales Subsystem wird im Paper nicht erläutert, meint aber wahrscheinlich eine Funktionalität zum massenhaften Bereitstellen von Devices.

IoT Edge Devices bildet den Bereich Edge Computing ab, indem nahe am Device (dezentral) bereits Funktionen wie die Filterung und Aggregation von Daten, Zwischenspeicherung von Daten oder ein Protokoll Mapping durchgeführt werden. Auf den Bereich Things wird nicht näher eingegangen, da der Betrachtungsgegenstand dieser Arbeit erst ab der Datenübertragung an die IoT Anwendung beginnt.³²

Insights

Beinhaltet die Verarbeitung der Daten von IoT Devices, um Erkenntnisse zu gewinnen, auf deren Basis Aktionen ausgeführt oder Entscheidungen getroffen werden können. Das Cloud Gateway ermöglicht die sichere, bidirektionale Kommunikation mit den Devices. Laut Microsoft sollen hier das Device Management, die Autorisierung der Devices sowie die Bereitstellung von Devices als Funktionalitäten enthalten sein. Dies ist ähnlich zum Ansatz von Bial und Scheuch, allerdings werden hier Konnektivität und Device Management in einem Subsystem vermischt. Konzeptionell gesehen können die Konnektivität der Devices und das Device Management aus Sicht des Autors dieser Arbeit getrennt werden wie beim Ansatz von Bial und Scheuch. Die Funktionalitäten des Device Managements teilen sich in die folgenden Bereiche:³³

- Device identity store: Dienst zur Authentifizierung von Devices. Validiert die Identität eines Devices z.B. anhand von Secrets. Diese Funktionalität findet sich bei [BS15] unter „Identity & Access Management“ wieder.
- Device provisioning: Dienst zum Erstellen von Identitäten von neuen Device sowie zur Deaktivierung und Löschung bestehender Devices. Diese Funktionalität findet sich ebenfalls bei [BS15] unter „Device Management“ als Komponente wieder.
- Device Topologie und Entity Store: Beschreibt die Notwendigkeit, dass es ein Datenmodell für Devices geben muss, das sich aus dem Kontext des Anwendungsfalls definiert. Ein Bestandteil ist ein Datenschema, dass ein Device mit seinen Metadaten beschreibt. Allgemeingültige Modelle können hier laut Microsoft nicht definiert werden, da diese vom Anwendungsfall abhängen. Einige grundsätzliche Daten wie eine Device ID, ein Device Typ oder eine Seriennummer werden als Beispiele aufgeführt, die wahrscheinlich für eine Vielzahl von Anwendungsfällen verwendet werden können. Ein zweiter Bestandteil sind Schemata, die beschreiben, wie die Daten aussehen, die ein Device senden und empfangen kann. Daraus lässt sich als Erkenntnis gewinnen, dass es Daten geben wird, die für alle Devices gleich sind und Daten, die nur für spezifische Device Typen oder Devices gültig sind. Eine Herausforderung in der Definition einer Referenzarchitektur besteht damit darin, dass dieser Sachverhalt geeignet berücksichtigt wird. Als dritter Bestandteil wird die Notwendigkeit der Abbildung von Beziehungen zwischen Devices in einem Domänenmodell abhängig vom Anwendungsfall beschrieben. Dies ist ein Punkt, der aus Sicht des Autors dieser Arbeit in konkreten Applikationen abgebildet werden sollte, um das Device Management möglichst unabhängig vom Anwendungsfall zu halten.

Data Transformation beschreibt einfache Transformationen der Rohdaten von Devices wie z.B. Protokolltransformationen sowie einfache Kombinationen von Daten.³⁴ Stream Processing beschreibt die Verarbeitung der eingehenden Daten anhand von Regeln nahezu in Echtzeit, um die Daten zu speichern und in Business Prozesse zu integrieren. Das Processing kann dabei in mehreren Schritten und teilweise parallel erfolgen. Die Innensicht dieses Subsystems ist damit flexibel und kann viele Komponenten und Verarbeitungsschritte enthalten. Es geht dabei im Kern um Big Data Processing. Microsoft empfiehlt hier z.B. die Lambda Architektur, auf die in den folgenden Kapiteln näher eingegangen wird. Dieses Subsystem bildet nach Ansicht des Autors dieser Arbeit den Kern der IoT Anwendung, da es viele Komponenten sowie Business Logiken enthalten kann und damit die Integration in Businessprozesse und die Bereitstellung von Daten für UI-Applikationen beinhaltet. Im Rahmen des Entwurfs einer Referenzarchitektur sollte daher eine detailliertere Sicht auf diese Komponente Verwendung finden. Für die Verarbeitung wird die Partitionierung von eingehenden Daten nach den Bedürfnissen der Anwendung als konzeptionelles Hilfsmittel beschrieben, um die Parallelisierung der Aufgabenbearbeitung und damit eine gute Skalierbarkeit zu erreichen.³⁵

Das Subsystem UI und Reporting Tools stellt das User Interface dar, das den Zugriff auf Device Daten und Analyseergebnisse sowie die Informationen aus den Verarbeitungsprozessen ermöglicht. Zusätzlich bietet es den Usern benötigte Funktionalitäten für das Device Management. Dieses Subsystem spiegelt damit den Rahmenparameter „Webportal für die Interaktion der Nutzer mit der Anwendung“ im Rahmen der Zielsetzung wider (vgl. 1.4).

Eng verbunden mit dem User Interface wird ein User Management als optionale Komponente beschrieben, über das die Authentifizierung und Autorisierung von Benutzern für den Zugriff auf die Daten oder verschiedene Anwendungsbereiche abgebildet werden soll. Da eine IoT Anwendung verschiedene Applikationen beinhalten kann und im Rahmen dieser Arbeit der Aspekt SaaS eine zentrale Rolle spielt, bei dem sich verschiedene Kunden das System teilen, ist eine geeignete Benutzerverwaltung im Rahmen der funktionalen Anforderungen für den Entwurf der Referenzarchitektur als Pflicht anzusehen.

Action

Beschreibt das Auslösen von Aktionen wie Business Prozessen auf Basis der generierten Informationen aus vorherigen Schritten. Hier entsteht die tiefste Form einer Integration und damit der größte Nutzen durch die Verbesserung von Entscheidungen, proaktive Reaktionen und die Automatisierung von Prozessen im Rahmen der Wertschöpfung. Mittels Business Integration erfolgt eine Integration in die Geschäftsprozesse, meist durch die Integration mit Drittsystemen wie ERP-Systemen. Dies kann über API-Schnittstellen erfolgen, die bereits als Rahmenparameter für die zu entwerfende Architektur im Rahmen dieser Arbeit definiert wurden (vgl. 1.4).

Als weiteres Subsystem beschreibt Microsoft Machine Learning, was die Gewinnung von Erkenntnissen durch Machine Learning Algorithmen auf Basis der bisherigen Daten beinhalten soll. Damit sollen Anwendungsfälle wie Predictive Maintenance ermöglicht werden.³⁶

2.1.3.2 Querschnittsfunktionen

Microsoft beschreibt Querschnittsfunktionen im Rahmen der Referenzarchitektur. Gemäß der Themenabgrenzung werden davon nur diese betrachtet, die für eine technologieunabhängige, konzeptionelle Referenzarchitektur von Bedeutung sind. Funktionen, die sich auf Systeme fokussieren, werden ausgelassen.

Application Logging

Aus der Architekturbeschreibung geht hervor, dass eine IoT Anwendung aus mehreren voneinander unabhängigen Komponenten besteht, über die Daten in verschiedenen Schritten verarbeitet werden.³⁷ Um eine schnelle Identifizierung und Behebung von Fehlern zu ermöglichen, sollte es daher ein übergreifendes Logging geben, damit nachvollzogen werden kann, was im Gesamtsystem passiert. Dabei ist insbesondere die Nachvollziehbarkeit, was mit den gesendeten Telemetriedaten im System in den verschiedenen Verarbeitungsschritten passiert, ein Kernpunkt, der berücksichtigt werden sollte.³⁸ Weiterhin ist das klassische Application Logging zu beachten, damit nachvollzogen werden kann, was in den Komponenten passiert und wo Fehlerzustände auftreten können.³⁹ Daraus lässt sich ableiten, dass ein geeignetes Application Logging im Rahmen der Definition einer IoT-Referenzarchitektur als Anforderung berücksichtigt werden sollte.

Security

Alle Subsysteme müssen durch geeignete Maßnahmen geschützt werden.⁴⁰ Bei der Beschreibung der Architektur im vorigen Kapitel wurden dazu bereits einige Maßnahmen wie eine Device- oder Benutzerauthentifizierung beschrieben. Es handelt sich hier um eine sehr breit gefasste, nicht-funktionale Anforderung, die in jedem IT-System berücksichtigt werden muss. Im Rahmen des Themas dieser Arbeit werden daher ebenfalls Security Aspekte in den Anforderungen berücksichtigt.

High availability and disaster recovery

Systeme müssen immer verfügbar sein und mit Fehlerzuständen umgehen können. Microsoft beschreibt dazu zahlreiche Strategien, auch in Abhängigkeit verschiedener Subsysteme und Funktionalitäten. Die Ausführungen sind system- und technologiebezogen und werden daher nicht tiefer betrachtet.⁴¹ Häufig denkt man bei Hochverfügbarkeit und Notfallwiederherstellungen systembezogen an Backups und redundante Systeme. Neben den Systemen muss die Architektur des Gesamtsystems so ausgelegt sein, dass bspw. Failovers von Systemen und das Wiederherstellen von Daten überhaupt ermöglicht werden. Dieser Aspekt wird insbesondere im Rahmen von Big-Data Architekturansätzen noch einmal aufgegriffen und muss im Rahmen des Entwurfs einer IoT-Referenzarchitektur berücksichtigt werden.

2.1.3.3 Zusammenfassung und Anforderungen

Die Microsoft Azure IoT Referenzarchitektur kann ebenfalls als prozessorientiert entlang einer Wertschöpfungskette durch die Verarbeitung in mehreren Schritten bezeichnet werden. Sie ist insgesamt ähnlich zum Ansatz von Bial und Scheuch, jedoch in vielen Punkten umfangreicher, was konkrete Anforderungen und Funktionen betrifft. Insbesondere werden hier Prinzipien und Querschnittsfunktionen beschrieben, die sich bei Bial und Scheuch nicht wiederfinden. Der Blick auf Geschäftsmodelle ist bei [Ms18] gänzlich außen vorgelassen, hier können sich die Ansätze von [BS15] und Microsoft ergänzen. Die Aufteilung in Subsysteme scheint bei Microsoft - zumindest bei der Gateway Komponente, die alle Device-Management Funktionalitäten enthält - eher produktgetrieben (Azure IoT Hub) als konzeptionell unabhängig zu sein. Dies ist zu vernachlässigen, da die einzelnen Funktionalitäten trotzdem umfangreich beschrieben werden und somit konzeptionell genutzt werden können. Das Device-Management wird sowohl von Bial und Scheuch als auch Microsoft als zentrale Komponente einer IoT-Anwendung beschrieben, wobei sich die enthaltenen Funktionalitäten nach den Beschreibungen sehr ähnlich sind. Daraus wird abgeleitet, dass Device-Management auch eine zentrale funktionale Anforderung für den Entwurf der IoT-Referenzarchitektur im Rahmen dieser Arbeit sein wird. Durch die Beschreibung einer Komponente UI mit Benutzerverwaltung legt Microsoft den Blick der Architektur zum Teil auf die Applikationsseite, die im Rahmen des Themas ebenfalls berücksichtigt werden muss (vgl. 1.4).

Aus den beschriebenen Funktionen der Subsysteme und der Querschnittsfunktionen lassen sich konkrete funktionale und nicht-funktionale Anforderungen an eine IoT-Referenzarchitektur ableiten, die für den Entwurf im Rahmen der Themenabgrenzung dieser Arbeit herangezogen werden können. Im Folgenden werden die funktionalen und nicht-funktionalen Anforderungen aufgeführt, die aus [Ms18] abgeleitet werden.

1. Funktionale Anforderungen

In Tabelle 3 werden zusammenfassend die funktionalen Anforderungen an eine IoT-Referenzarchitektur mit Referenznummer beschrieben, die aus der Microsoft Azure IoT Referenzarchitektur abgeleitet werden können.

Tabelle 3: Funktionale Anforderungen Azure IoT Referenzarchitektur

Abbildung in dieser Leseprobe nicht enthalten

2. Nicht-funktionale Anforderungen

In Tabelle 4 werden zusammenfassend die nicht-funktionalen Anforderungen an eine IoT-Referenzarchitektur mit Referenznummer beschrieben, die aus der Microsoft Azure IoT Referenzarchitektur abgeleitet werden können.

Tabelle 4: Nicht-funktionale Anforderungen Azure IoT Referenzarchitektur

Abbildung in dieser Leseprobe nicht enthalten

2.1.4 Zusammenfassung und Anforderungen

In diesem Kapitel wurden drei IoT-Referenzarchitekturen beschrieben und hinsichtlich der Anforderungen analysiert, die sich an eine IoT-Referenzarchitektur stellen lassen. Die beschriebenen Ansätze unterscheiden sich im Abstraktionslevel, daher lassen sich teilweise nur wenige Anforderungen ableiten. Die 5-Layer Referenzarchitektur ist am abstraktesten, da diese lediglich eine Aufteilung in fünf Schichten enthält. Aus diesem Ansatz lassen sich keine konkreten Anforderungen ableiten, die im Rahmen dieser Arbeit weiterverwendet werden können. Die Aufteilung in die Schichten kann jedoch genutzt werden. Die Referenzarchitektur für IoT basierende Geschäftsmodelle beschreibt eine funktionale Sicht, eine fachliche Architektur sowie eine technische Referenzarchitektur und legt dabei den Blick auf Geschäftsmodelle, die durch IoT ermöglicht werden können. Der Ansatz ist deutlich detaillierter als die 5-Layer Architektur und ermöglicht die Ableitung konkreter Anforderungen an IoT Referenzarchitekturen. Die Microsoft Azure IoT Referenzarchitektur ist noch einmal detaillierter als der Ansatz von [BS15] und beinhaltet zusätzlich Querschnittsfunktionen, die aus der Sicht von Microsoft für eine Referenzarchitektur berücksichtigt werden müssen. Im Gegensatz zur Referenzarchitektur für IoT basierende Geschäftsmodelle fehlt hier die Sicht auf Geschäftsmodelle. Es können ebenfalls einige konkrete Anforderungen abgeleitet werden, wobei diese eine große Ähnlichkeit zu den abgeleiteten Anforderungen aus [BS15] aufweisen. Im Folgenden wird zunächst eine Aufteilung in Layer für den Entwurf der Referenzarchitektur abgeleitet. Anschließend werden die abgeleiteten Anforderungen aus den Ansätzen in eine Liste von Anforderungen konsolidiert, die die Referenzarchitektur erfüllen muss. Damit wird der erste Teil der Forschungsfrage RQ1 beantwortet.

Alle drei Ansätze beschreiben mehrere Schichten (Layer) für die jeweilige Referenzarchitektur. Obwohl die Schichten und deren Anzahl sowie die Details der Inhalte unterschiedlich sind, besitzen alle Ansätze den gleichen Kernaufbau. Der Aufbau der Schichten kann als digitale Wertschöpfungskette bezeichnet werden, die im Wesentlichen die Sammlung von Daten durch IoT Devices über verschiedene Verarbeitungsschritte der Daten bis hin zur Bereitstellung der Daten für Kunden im Rahmen von Applikationen und Integrationen in bestehende Business Systeme beinhaltet (vgl. Abbildung 8). Aus den betrachteten Ansätzen kann daher als Metastruktur für IoT Referenzarchitekturen die in Abbildung 8 dargestellte Struktur abstrahiert werden.

Abbildung in dieser Leseprobe nicht enthalten

Abbildung 8: Metastruktur IoT-Referenzarchitekturen

Diese Metastruktur entspricht im Wesentlichen dem elektronischen Wertschöpfungsprozess von Prof. Dr. Kollmann, der aus den Schritten Informationssammlung, Informationsverarbeitung und Informationsübertragung besteht.⁴² Da die Metastruktur sowohl auf alle betrachteten IoT Referenzarchitekturen als auch auf die gängige Definition eines elektronischen Wertschöpfungsprozesses aus der Literatur passt, wird diese Struktur den Rahmen für den Entwurf der Referenzarchitektur in dieser Arbeit bilden.

Unter 2.1.2.4 und 2.1.3.3 wurden bereits funktionale und nicht-funktionale Anforderungen an eine IoT Referenzarchitektur aus den jeweiligen Ansätzen abgeleitet. Aus der 5-Layer Architektur konnten keine konkreten Anforderungen abgeleitet werden, diese kann lediglich für die Definition der Metastruktur herangezogen werden. Die abgeleiteten Anforderungen weisen viele Ähnlichkeiten auf, daher werden diese in der folgenden Tabelle zu einer vollständigen Liste von Anforderungen konsolidiert, die die IoT Referenzarchitektur im Rahmen der Arbeit erfüllen bzw. berücksichtigen muss. Jede Anforderung wird mit einer Referenznummer gekennzeichnet, die für die Zusammenfassung aller Anforderungen (siehe 2.3) in der Arbeit verwendet wird. Die Referenznummer setzt sich wie folgt zusammen:

IOT-< NF für nicht-funktional/ F für funktional>-<Laufende Nummer>

Weiterhin werden die Referenznummern aus 2.1.2.4 und 2.1.3.3 angegeben, aus denen die Anforderung abgeleitet wurde.

Tabelle 5: Anforderungen an IoT-Referenzarchitekturen

Abbildung in dieser Leseprobe nicht enthalten

[...]

---

¹ vgl. [Mau19], S. 10

² vgl. [Mau19], S. 21

³ vgl. [Mau19], S. 14

⁴ [Au09b]

⁵ [Au09a]

⁶ [Au09c]

⁷ [BI09a]

⁸ [BI09b]

⁹ [Ne15]

¹⁰ [Wo18]

¹¹ [Ga94]

¹² [Fo02]

¹³ [Ba11]

¹⁴ [Mar11]

¹⁵ [MW15]

¹⁶ [Kr13]

¹⁷ [Kr14]

¹⁸ [Ms18]

¹⁹ [Wu10]

²⁰ [BS15]

²¹ vgl. [He07]

²² vgl. [Wu10], S. V5-487

²³ vgl. [Wu10], S. V5-487

²⁴ vgl. [Wu10], S. V5-487

²⁵ vgl. [Wu10], S. V5-487

²⁶ vgl. [Wu10], S. V5-487

²⁷ [BS15], S. 1

²⁸ vgl. [BS15], S. 2

²⁹ vgl. [BS15], S. 5ff.

³⁰ vgl. [Ms18], S. 4

³¹ vgl. [Ms18], S. 4

³² Nähere Informationen für den Bereich Things finden sich in [Ms18], S. 11ff.

³³ vgl. [Ms18], S. 16ff.

³⁴ vgl. [Ms18], S. 6

³⁵ vgl. [Ms18], S. 26ff.

³⁶ vgl. [Ms18], S. 6

³⁷ vgl. [Ms18], S. 43

³⁸ vgl. [Ms18], S. 35

³⁹ vgl. [Ms18], S. 36

⁴⁰ vgl. [Ms18], S. 8

⁴¹ vgl. [Ms18], S. 60ff.

⁴² vgl. [Ko19], S. 62f.