Microcontroller-Projekt ITT11 - cyber-physische Systeme
Version ab Schuljahr 2023/24
Diese Übung begleitet dich über mehrere Blockwochen hinweg bis zum Ende des Abschnitts Microcontroller. Lies die Angaben auf dieser Seite aufmerksam durch und kontrolliere von Zeit zu Zeit, ob du noch alle wichtigen Punkte auf dem Schirm hast.
Situationsbeschreibung
Im Rahmen dieses Projekts soll für eine fiktive Kundenanforderung prototypisch ein CPS-Sensor/Aktor gebaut werden. Durch das Projekt soll die Machbarkeit und Einsatztauglichkeit des geplanten Sensor-Aktor-Produkts nachgewiesen werden, um im Erfolgsfall einen Fertigungsauftrag für eine Kleinserie zu vergeben oder eine weitere Iteration mit einem verbesserten Prototyp anschließen zu können.
Rahmenbedingungen
Das Microcontroller-Projekt ist in Teams zu 2 (in Ausnahmefällen 3) Personen durchzuführen.
Der erstellte Prototyp wird am Ende der Projektlaufzeit mit einer mündlichen Note bewertet. Die Arbeit zwischen den Teams ist so abzustimmen, dass keine 2 identischen Projekte erstellt werden. Doppelte Projekte werden wie Unterschleif (Note 6) bewertet. Ein Austausch zwischen den Teams zur Verwendung bestimmter Sensoren, Aktoren oder anderen Fragen der technischen Umsetzung ist jedoch grundsätzlich erwünscht.
Die Auswahl des Projektgegenstandes obliegt im Rahmen der Vorgaben und Möglichkeiten den Teammitgliedern.
Vorgaben für und Anforderungen an den Prototyp
Das Projektteam ist frei in der Gestaltung des Prototypen, solange er den hier gemachten Vorgaben und Anforderungen entspricht:
Die Funktion des Prototypen hat einen sinnvollen Bezug zum Einsatz im Unternehmens- oder Smart Home-Umfeld. (Im Zweifel vor Bearbeitung absegnen lassen.)
Der Prototyp ist auf Basis eines ESP-Microcontroller-Boards anzufertigen. Zur Verfügung stehen Boards mit ESP8266- oder ESP32-Chip.
Der Prototyp muss mindestens einen Sensor verwenden, dessen Eingaben direkt oder indirekt auf dem Node-RED-Server verarbeitet werden.
Der Prototyp muss mindestens einen Aktor verwenden, dessen Aktionen direkt oder indirekt vom Node-RED-Server beeinflusst werden.
Der Prototyp muss eine Netzwerkverbindung per WLAN herstellen.
Der Prototyp muss über das MQTT-Protokoll Nachrichten mit dem Node-RED-Server austauschen.
Auf dem Node-RED-Server muss eine Verarbeitung stattfinden, in der die Sensordaten des Prototypen mit einfließen und die direkt oder indirekt Einfluss auf die Aktorsteuerung des Prototypen hat.
Auf dem Node-RED-Server muss ein zusätzlicher Input verarbeitet werden, der auf die Steuerung des Prototypen Einfluss hat. (z. B. Messwert per MQTT, Datenabruf per HTTP aus dem Web, Dateneingang über Web/TCP/UDP, etc.)
Der Prototyp erfüllt zusätzlich eine beliebige der hier genannten Ergänzungsanforderungen
Der Prototyp verwendet ein Display um Sensordaten und Aktorbefehle anzuzeigen.
Der Prototyp ist über das Smartphone (z. B. ein MQTT-Dashboard) steuerbar und seine Sensordaten einsehbar.
Der Prototyp kommuniziert über LoRaWAN mit dem TTN.
Der Prototyp verwendet zusätzlich eine Arduino-Platine mit weiteren Sensoren oder Aktoren, welche von dem ESP-Prozessor gesteuert wird.
Der Prototyp kommuniziert über einen Chat-Bot (z. B. Discord, Telegram)
Der Prototyp ist über einen Cloud-Dienst steuerbar (z. B. Google Home, Alexa)
Der Prototyp speichert seine Messdaten in einer Datenbank und verfügt über eine Visualisierung der gespeicherten Daten (z. B. InfluxDB, MongoDB, Grafana Dashboard)
Die Entscheidung über das zu verwendende Board sowie zu verwendende Sensor- und Aktorkomponenten ist nach der Verfügbarkeit der Geräte zu richten und nötigenfalls mit den anderen Teams abzustimmen.
Vorgaben für und Anforderungen an die Dokumentation
Es wird zwar nicht gefordert, dass eine Dokumentation im Sinne einer klassischen Projektabschlussdokumentation erstellt wird, jedoch ist es für die Arbeit im Team unerlässlich, dass eine interne Arbeitsdokumentation geführt wird.
Diese Dokumentation sorgt dafür, dass z. B. bei krankheitsbedingten Ausfällen die benötigten Informationen verfügbar sind und dass der aktuelle Bearbeitungsstand jederzeit vorliegt. Alle Teammitglieder sind während des gesamten Projektverlaufs dafür verantwortlich ihre Erkenntnisse, Tätigkeiten und Planungen so zu dokumentieren, dass das Team weiterhin arbeitsfähig bleibt, auch wenn ein Teammitglied vorübergehend ausfällt.
Die Dokumentation erfüllt auch den Zweck den Prototypen jederzeit zerlegen und wieder neu aufbauen zu können (z. B. zwischen Stunden oder Blöcken).
Mit Hilfe der Dokumentation kann bei der Bewertung des Prototypen nachgewiesen werden, dass eventuell vorliegende Defizite nicht zu vertreten sind, was sich dann positiv auf die Bewertung auswirkt.
Während der Erstellung des Prototypen können unvorhergesehene Schwierigkeiten auftreten, die den Projekterfolg gefährden. Werden geeignete Maßnahmen getroffen diese Schwierigkeiten zu beseitigen, z. B. durch eine Anpassung der Planung und den Wechsel einer Komponente, kann auch ein nicht voll funktionstüchtiger Prototyp volle Punktzahl erreichen. Hierfür ist es zwingend erforderlich diesen Sachverhalt anhand ordentlicher Dokumentation nachweisen zu können.
Materialübersicht
Für die praktische Umsetzung steht folgendes Material in unterschiedlicher Stückzahl zur Verfügung:
Boards
Microcontroller-Board „NodeMCU“ mit ESP8266-Chip
Microcontroller-Board mit ESP32-Chip
Microcontroller-Board mit ESP32-Chip, LoRa-Modul und OLED-Display
Microcontroller-Board „ESP32-Cam“ mit ESP32-Chip und Kameramodul
Sensoren
Aktoren
Schrittmotor
Motor-Servo / Schranke
Relais mit Lüfter
NeoPixel-Mehrfarben-LED
verschiedene LEDs
Anzeigegeräte
zusätzliche Boards
Anregungen für den Projektgegenstand
Die hier aufgelisteten Beispiele dienen als Anregungen für den Entwurf einer eigenen Projektidee und sind nicht als Einschränkung oder verpflichtende Vorgabe zu verstehen.
Automatisches Öffnen und Schließen der Außenrollos im Verwaltungsgebäude je nach Anwesenheit, um unnötige Verwendung der Beleuchtung zu vermeiden, sofern die aktuelle Sonneneinstrahlung und Außentemperatur dies erlauben.
Die Anwesenheit kann mit Hilfe eines PIR-Bewegungsmelders ermittelt werden.
Die Außenrollos können durch einen Schrittmotor dargestellt werden.
Sonneneinstrahlung und Außentemperatur stehen durch LoRaWAN-Sensoren per MQTT zur Verfügung.
Aktivierung der Lüftungsanlage zur Kühlung eines Netzwerkraums in Abhängigkeit von Innen- und Außentemperatur, sofern die Temperaturdifferenz zur Außenluft ausreichend ist.
Die Innentemperatur kann mit einem Temperatursensor ermittelt werden.
Die Schaltung der Lüftungsanlage kann mit einem Relais und einem Lüfter dargestellt werden.
Die Außentemperatur steht durch LoRaWAN-Sensoren per MQTT zur Verfügung.
Automatisches Schwenken eines Scheinwerfers an der Verladerampe in Abhängigkeit des Abstandes zwischen Verladerampe und Fahrzeug, sofern es sich um ein GPS-getracktes, firmeneigenes Fahrzeug handelt.
Der Abstand kann mit Hilfe eines Entfernungsmessers ermittelt werden.
Das Schwenken des Scheinwerfers kann mit einem Schrittmotor dargestellt werden.
Die GPS-Position der Firmen-LKW steht durch die LoRaWAN-Sensoren über MQTT zur Verfügung.
Automatisches Öffnen der Schranke an der LKW-Zufahrt, wenn ein firmeneigener, GPS-getrackter LKW einfahren möchte. Als Fallback-Option soll ein RFID-Token genutzt werden können.
Das Vorhandensein eines Fahrzeuges kann durch einen Helligkeitssensor erfasst werden.
Die Zufahrtsschranke kann durch ein Motor-Servo oder eine Miniatur-Schranke dargestellt werden.
Die GPS-Position der Firmen-LKW steht durch die LoRaWAN-Sensoren über MQTT zur Verfügung.