meta data for this page
  •  

Unterschiede

Hier werden die Unterschiede zwischen zwei Versionen der Seite angezeigt.

Link zu der Vergleichsansicht

Nächste Überarbeitung		Vorherige Überarbeitung
uebung:itt11:microcontroller-projekt [2023/01/17 21:14] – angelegt juergenhaasuebung:itt11:microcontroller-projekt [2024/01/18 14:09] (aktuell) – juergenhaas
Zeile 1: Zeile 1:
 ====== Microcontroller-Projekt ITT11 - cyber-physische Systeme ====== ====== 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. 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.
Zeile 6: Zeile 12:
 ===== Situationsbeschreibung ===== ===== 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. Fehlschäge sind dabei ebenso zu dokumentieren wie Verbesserungsvorschläge über den Endzustand des Prototyps hinaus, sofern sich diese im Verlauf des Projektes abzeichnen.+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 ===== ===== Rahmenbedingungen =====
  
   * Das Microcontroller-Projekt ist in Teams zu 2 (in Ausnahmefällen 3) Personen durchzuführen.   * Das Microcontroller-Projekt ist in Teams zu 2 (in Ausnahmefällen 3) Personen durchzuführen.
-  * Jedes Teammitglied verfasst eine eigenständige Dokumentation. Die Dokumentation wird zum Ende des Projekts mit einer **mündlichen Note** bewertet.+  * 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.   * Die Auswahl des Projektgegenstandes obliegt im Rahmen der Vorgaben und Möglichkeiten den Teammitgliedern.
  
Zeile 19: Zeile 25:
 Das Projektteam ist frei in der Gestaltung des Prototypen, solange er den hier gemachten Vorgaben und Anforderungen entspricht: 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 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 eine Netzwerkverbindung per WLAN herstellen.
   * Der Prototyp muss über das MQTT-Protokoll Nachrichten mit dem Node-RED-Server austauschen.   * 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 eine Verarbeitung stattfinden, in der die Sensordaten des Prototypen mit einfließen und die direkt oder indirekt Einfluss auf die Aktorsteuerung des Prototypen hat.
-  * In die Verarbeitung auf dem Node-RED-Server muss mindestens ein Faktor aus einer Drittquelle (z. B. LoRaWAN-Sensordaten oder Eingaben auf dem Dashboard) einfließen. +  * 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 muss mindestens einen Sensor verwenden, dessen Eingaben direkt oder indirekt auf dem Node-RED-Server verarbeitet werden. +  * Der Prototyp erfüllt zusätzlich **eine beliebige** der hier genannten Ergänzungsanforderungen 
-  * Der Prototyp muss mindestens einen Aktor verwenden.+    * 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.   * 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.
  
Zeile 31: Zeile 46:
 ===== Vorgaben für und Anforderungen an die Dokumentation ===== ===== Vorgaben für und Anforderungen an die Dokumentation =====
  
-  * Zielgruppe: Die Dokumentation ist so zu verfassen, dass eine fachkundige Person, die sich auf ähnlichem Niveau wie die Verfasser der Dokumentation befindet, die Dokumentation verstehen kann. +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.
-  * Die Dokumentation muss die folgenden Teilaspekte abdecken: +
-    * eine kurze Projektbeschreibung +
-    * die Projektplanung +
-    * die Realisierung des Projekts mit gewonnenen Erkenntnissen und Entscheidungen +
-    * Projektabschluss mit Fazit oder Ausblick auf die nächste Prototypeniteration +
-  * Die Dokumentation ist nicht nur im Hinblick darauf zu erstellen, dass zum Ende des Projekts eine Übergabe an den fiktiven Auftraggeber erfolgen kann. 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, z. B. krankheitsbedingt, ausfällt.+
  
 +  * 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 ===== ===== Materialübersicht =====
Zeile 66: Zeile 80:
     * LCD-Display     * LCD-Display
     * OLED-Display     * OLED-Display
 +  * zusätzliche Boards
 +    * Arduino-Board mit Sensoren-/Aktoren-Satz "Energiesparhaus"
 +
  
  
 +===== 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.