Um die Idee des "Physischen Zwillings" eines Remote-Studis umzusetzen, wurde in der Konzeptionsphase der Lösungsarchitektur Wert auf die Einhaltung der Designprinzipien für IoT Anwendungen gelegt (Siehe Kap. 5). Hierbei sah das ursprüngliche Konzept den Einsatz von Scrollbots vor. Aufgrund dessen, dass voraussichtlich keine Scrollbots zur Verfügung stehen würden, haben wir uns frühzeitig dazu entschieden, auf 7"-Displays zu wechseln.
Diese Entscheidung beeinflusste die entworfene Architektur/das Konzept insoweit, dass von einem Python-Script zu einer Webpage für die Darstellung der Reaktionen gewechselt wurde. Ursprünglich war geplant, für das Senden der Reaktionen eine Webpage bereitzustellen, welche über Websockets mit dem MQTT-Broker HiveMQ kommuniziert. Diese Reaktionen sollten anschließend über das Script ausgelesen werden. Da sich unser Team mit dem Wechsel auf 7"-Displays ebenfalls dazu entschlossen hat, auf einen lokalen MQTT-Broker zur Förderung der Unabhängigkeit und Sicherheit der Lösung umzusteigen, beeinflusste diese Entscheidung ebenfalls die Lösungsarchitektur für das Senden von Reaktionen. Um zusätzlichen Implementationsaufwand der Websockets zu vermeiden und eine einheitliche Architektur auf beiden Seiten zu entwickeln, wurde die Funktionalität hinter der Webpage verworfen. Aufgrund der Vielseitigkeit bei gleichzeitig einfacher Implementierung wurde daher auf Node-RED zurückgegriffen und die Funktionalität für das Senden von MQTT-Nachrichten in ein **Backend** eingelagert, welches über HTTP-Schnittstellen nach außen erreichbar ist. Über diese Schnittstellen ist sowohl das **Frontend**, als auch weitere Informationen zugänglich, auf welche das Frontend wiederum selbst zugreift.
Diese Entscheidung beeinflusste die entworfene Architektur/das Konzept insoweit, dass von einem Python-Script zu einer Webpage für die Darstellung der Reaktionen gewechselt wurde. Ursprünglich war geplant, für das Senden der Reaktionen eine Webpage bereitzustellen, welche über Websockets mit dem MQTT-Broker HiveMQ kommuniziert. Diese Reaktionen sollten anschließend über das Script ausgelesen werden. Da sich unser Team mit dem Wechsel auf 7"-Displays ebenfalls dazu entschlossen hat, auf einen lokalen MQTT-Broker zur Förderung der Unabhängigkeit und Sicherheit der Lösung umzusteigen, beeinflusste diese Entscheidung ebenfalls die Lösungsarchitektur für das Senden von Reaktionen. Um zusätzlichen Implementationsaufwand der Websockets zu vermeiden und eine einheitliche Architektur auf beiden Seiten zu entwickeln, wurde die Funktionalität hinter der Webpage verworfen. Aufgrund der Vielseitigkeit bei gleichzeitig einfacher Implementierung wurde daher auf Node-RED zurückgegriffen und die Funktionalität für das Senden von MQTT-Nachrichten in ein **Backend** eingelagert, welches über HTTP-Schnittstellen nach außen erreichbar ist. Über diese Schnittstellen ist sowohl das **Frontend**, als auch weitere Informationen zugänglich, auf welche das Frontend wiederum selbst zugreift. Dabei war die Grundidee, NodeRED direkt auf dem Pi zu deployen. Allerdings sind dadurch die Reproduktion, Portabilität und Ausnutzung der Ressourcen nicht so optimal, wie im Vergleich zu einer Bereitstellung über einer Container-Umgebung (zusätzlich müsste ein weiterer Pi ausschließlich als Broker dienen). Wir haben uns daher damit beschäftigt, wie diese Umgebung mit Hilfe von Docker auf einem Pi realisiert werden kann. Im Laufe dieser Recherche sind wir dabei ebenfalls auf Portainer gestoßen, welches eine einfache Verwaltung von Container-Umgebungen ermöglicht.
Hierbei stellte es sich als **Herausforderung** dar, die Problematik von zustandsloser (HTTP) zu zustandsbasierter Kommunikation (MQTT) zu überwinden. Dies ist insofern ein Problem, als das bei einer zustandslosen Kommunikation kein physischer Zwilling erzeugt werden kann. So wurden verschiedene Lösungsansätze implementiert, um bspw. zu erkennen, dass die Verbindung für das Senden von Reaktionen beendet wurde, um nicht die Anzeige für das Darstellen von Reaktionen unnötig zu belegen und diese Problematik zu überwinden. Antrieb war dabei vor allem die **Technologie-Unabhängigkeit** von Webanwendungen, um den Prototypen auf so vielen Endgeräten wie möglich einsatzfähig zu machen. So deckt der neue Ansatz den Kerngedanken der Lösung (den Studierenden im Vorlesungsraum zu Präsenz zu verhelfen) nach wie vor ab (repräsentiert durch ein 7"-Display) und wird prototypisch umgesetzt.
Bei der Realisierung stellte es sich als **Herausforderung** dar, die Problematik von zustandsloser (HTTP) zu zustandsbasierter Kommunikation (MQTT) zu überwinden. Dies ist insofern ein Problem, als das bei einer zustandslosen Kommunikation kein physischer Zwilling erzeugt werden kann. So wurden verschiedene Lösungsansätze implementiert, um bspw. zu erkennen, dass die Verbindung für das Senden von Reaktionen beendet wurde, um nicht die Anzeige für das Darstellen von Reaktionen unnötig zu belegen und diese Problematik zu überwinden. Antrieb war dabei vor allem die **Technologie-Unabhängigkeit** von Webanwendungen, um den Prototypen auf so vielen Endgeräten wie möglich einsatzfähig zu machen. So deckt der neue Ansatz den Kerngedanken der Lösung (den Studierenden im Vorlesungsraum zu Präsenz zu verhelfen) nach wie vor ab (repräsentiert durch ein 7"-Display) und wird prototypisch umgesetzt.
Um die **Anforderungen** an das Minimum Viable Product (MVP) für den IoT Hackathon zu ermitteln, wird als Grundlage die erstellen VPC genutzt. Hieraus abgeleitet ergeben sich die wesentlichen Kernbestandteile, um den Nachweis des Mehrwertes der Lösung zu erbringen. Dabei fließen ebenfalls weitere Anforderungen ein, welche sich aus den IoT Designprinzipien und Projektvorgaben ergeben. Für die fachlich korrekte Dokumentation dieser Anforderungen wird auf Literatur zurückgegriffen (Vgl. Balzert 2009, S. 479 ff.; ISO/IEC/IEEE 29148:2018).
Die erstellte Anforderungsübersicht wird im Nachgang genutzt ([Abschnitt 9, Fazit & Ausblick](./09.-Fazit-&-Ausblick)), um anhand der Lösung die Zielerreichung zu **evaluieren**.
