Verteilte Verlässliche Eingebettete Systeme (2023/24)

Prof. Dr. Andreas Polze

Projektbetreuung

Arne Boockmeyer, Robert Schmid, Lukas Pirl

Termine

mittwochs 11:00 – 12:30 Uhr in K-1.03,
donnerstags 13:30 – 15:00 Uhr in K-1.03

Modus

standardmäßig in Präsenz, nach Absprache auch digital im Videokonferenzraum von Prof. Polze

Eingebettete Systeme zeichnen sich durch spezialisierte Aufgaben und enge Interaktion zwischen Hardware, Firmware und Software aus. Sie sind ein wichtiger Bestandteil des Alltags geworden, z. B. in Fahrzeugen, Industrie (4.0), Medizin und Haushalt. Neben ihren reduzierten Funktionalitäten, arbeiten eingebettete Systeme in der Regel auch mit stark eingeschränkten Ressourcen (z. B. CPU, Speicher, Energie). Neue und effizientere Anwendungen bedürfen oft einer Vernetzung der Systeme. Abgesehen von Komfortanwendungen, wie häufig im Kontext des Internets der Dinge (Internet of Things, IoT), übernehmen diese verteilten Systeme auch immer mehr sicherheitskritische Aufgaben (i. S. v. Safety). Ein strukturiertes Verständnis von Konzepten der Verlässlichkeit ist daher unerlässlich. Alle diese Besonderheiten – Spezialisierung, Ressourcenbeschränkung, Verteilung, Verlässlichkeit – lassen bei der Entwicklung Aspekte in den Vordergrund treten, die bei General-Purpose-Systemen tendenziell eine untergeordnete Rolle spielen.

Die Lehrveranstaltung setzt sich aus drei Teilen zusammen. Neben den Vorlesungen werden außerdem auch externe Vorträge an den Veranstaltungsterminen zu hören sein. Als dritte, praktische Komponente werden sich die Teilnehmer:innen in Gruppen zusammenfinden um ein gemeinsam ein Projekt zu gestalten und durchzuführen.

Der Vorlesungsteil beschäftigt sich insbesondere mit folgenden Themen:

vorhersagbares Zeitverhalten (Echtzeit)
Echtzeit-Betriebssysteme
- Performanzmaße & Optimierungskriterien
- Verwaltung der Ressource Prozessor
  - Echtzeit-Scheduling (z. B. RMS, EDF, LSF)
  - Task-Modell + periodische/aperiodische/sporadische Tasks
  - Herausforderungen des Echtzeit-Scheduling: Abhängigkeiten, Prioritäteninvertierung, Worst Case Execution Time (WCET)
- Verwaltung der Ressource Arbeitsspeicher
  - Protokolle für den konkurrierenden Zugriff
  - Protokolle für vorhersagbares Zeitverhalten von Allokationen
- Verwaltung von Interrupts (z. B. für Eingabe/Ausgabe)
- Beispiel: Echtzeit mit Linux
Echtzeitkommunikation
- Anforderungen
- Feldbusse (z. B. CAN)
- Netzwerkkommunikation
- Uhrensynchronisation
Programmiersprachen und Programmiermodelle (z. B. Ada, Rust)
Besonderheiten bei der Entwicklung eingebetteter Systeme
verlässliche Systeme: Dependability nach Laprie
IT-Sicherheit für eingebettete Systeme
Simulation verteilter Systeme

Die externen Vorträge werden interessante Einblicke in aktuelle Neuerungen und Herausforderungen in der Industrie gewähren.

Die Projekte sollen selbstverständlich Bezug zu den Inhalten der Vorlesung haben. Wir bringen Themenvorschläge ein, die Teilnehmer:innen können jedoch auch sehr gern selbst Themen mitbringen und entwickeln. Die genaue Ausgestaltung der Themen findet gemeinsam mit der Betreuung statt. Die Projektarbeit (meist donnerstags) findet parallel zu den Vorlesungen (meist mittwochs) statt. Für die Projektarbeit steht allen Teilnehmer:innen das IoT Lab zur Verfügung.

Projektarbeit

Im Rahmen der Lehrveranstaltung werden die Teilnehmer:innen in Gruppen ein selbst gewähltes Projekt bearbeiten. Die Gruppen sollten ca. drei bis fünf Personen umfassen. Bei größeren Projekten, bei denen die Arbeit mit wenig Abhängigkeiten parallelisiert werden kann, sind auch größere Gruppen möglich.

Wir stellen Projektideen vor, Vorschläge von den Teilnehmer:innen sind jedoch selbstverständlich auch sehr willkommen. Projekte von vorhergehenden Veranstaltungen (z. B. EOS 2022) können ebenso als Inspiration oder Grundlage verwendet werden. Ideen können variiert und kombiniert werden. Insbesondere sollten die Projektziele auch entsprechend der Vorerfahrungen in der Gruppe gewählt werden.

Es ist kein Problem, wenn unterschiedliche Gruppen das "gleiche Thema" bearbeiten. Üblicherweise finden sich genügend Varianten, sodass sich die tatsächlichen Arbeiten letztendlich doch unterscheiden. Im "Notfall" finden wir im persönlichen Gespräch eigentlich immer ein zu den individuellen Interessen und Vorerfahrungen passendes Thema.

In der Regel kann auch die Schwierigkeit von Projekten gut variiert werden. Es muss also nicht befürchtet werden, dass z. B. viel gelötet werden muss. Für fast alles gibt es Entwicklungs-/Dev-/Breakout-Boards die leicht zusammengesteckt werden können. Für den Einstieg sind z. B. auch Single-Board-Computer mit ihren IO-Pins gut geeignet. Auf der anderen Seite sind keine Grenzen gesetzt die Projekte beliebig anspruchsvoll zu gestalten – z. B. mit dem Entwurf eigener PCBs, Optimierung von Batterielaufzeiten, etc. Sollte Motivation vorhanden sein sich intensiv mit Hardware auseinanderzusetzen, dann ist dies also auch möglich.

Überlegt welche Hardware für die Projektidee nützlich wäre (bzw. welche Fähigkeiten sie haben sollte) und recherchiert nach möglichen Bauteilen (z. B. ESP32-Dev-Kit, GPS-Modul, je nach Projektidee) sowie nach Funktionsbestandteilen (z. B. "Wake Up Sources"). Dazu können sehr gern die vorhandenen Geräte der IoT-Labs/der IoT-Vitrine am Fachgebiet verwendet bzw. auf Anfrage auch neue Hardware angeschafft werden. Es ist auch nicht verkehrt zu schauen, wie eine Entwicklungsumgebung für die ausgewählte Infrastruktur aussehen würde (IDE, Programmiersprache, Frameworks/Bibliotheken, Bare-Metal vs. Betriebssystem, Debugging, etc.). Dabei sollte immer mit überlegt werden, wie sich das Projekt in die Themen der Veranstaltung einordnet.

Ziel ist nicht, am Ende ein fertiges "Produkt" zu entwickeln. Es geht vielmehr um dem Weg dorthin und darum, möglichst viele Erfahrungen mit dem Entwicklungsprozess zu sammeln. Wichtiger als das tatsächliche Produkt des Projekts ist also, dass etwas Neues mit Bezug zu den Themen der Vorlesung gelernt und sich mit anderen Teilnehmer:innen ausgetauscht wird.

Für die Betreuer:innen ist am interessantesten, was über die Entwicklung von eingebetteten Systemen gelernt wurde und mit welchen Problemen sich herumgeschlagen werden muss. Wir regen ausdrücklich an, dass sich die Teilnehmer:innen mit den Zusammenfassungen der Kommiliton:innen aus dem Vorjahr auseinandersetzen: z. B. EOS 2022. Das schärft nicht nur die Wahrnehmung für i. S. d. Veranstaltung interessante Aspekte, sondern legt teilweise auch Ratschläge der vorhergehenden Generationen offen.

Auftaktpräsentation

Pro Gruppe sollte in fünf bis zehn Minuten folgendes gezeigt werden:

Was ist eure Idee (Konzepte & Technologien, Hardware vs. Software)?
- Wie werden die Themen der Veranstaltung (Eingebettete Systeme, insbesondere beschränkte Ressourcen; Verlässlichkeit, insbesondere vorhersagbares Zeitverhalten; IT-Sicherheit; Simulation) tangiert?
Welche verschiedenen Wege das Problem zu lösen gibt es?
Welche verwandten Lösungen sind etabliert oder gescheitert?
Wie könnt ihr die Schwierigkeit bei Bedarf verringern oder erhöhen?
Was habt ihr bereits recherchiert bzw. ausprobiert?
Wie sieht eure Hardware-Wunschliste aus?

Zwischenpräsentation

Was wurde über die Entwicklung von eingebetteten Systemen gelernt und mit welchen Problemen musste sich herumgeschlagen werden? Folgende Dinge sollten in maximal 20 Minuten gezeigt werden:

Projektidee auffrischen
- Geht davon aus, dass eure Projektidee nicht mehr allen komplett bekannt ist.
Was wurde bisher gemacht (Hardware, Software)?
Hallo Welt!
- Es wäre toll, auch Quelltext und Details zu Frameworks & APIs, IDE, etc. zu sehen.
Erste Ergebnisse
- Es ist immer eine gute Idee, unterschiedliche Dinge zu vergleichen (Hardware, Algorithmen, Energie-Modi, Protokolle, …) und v. a. zu vermessen (Energieverbrauch, Speicher, Zeitverhalten).
Welche (ungeplanten) Probleme gab es und wie wurden sie gelöst?
Wie sieht der aktuelle Zeitplan aus (zu schnell, zu langsam, evtl. doppelter Boden)?

Endpräsentation

Jede Gruppe soll 20 Minuten für eine Präsentation und 10 Minuten für Diskussionen einplanen – insgesamt also 30 Minuten pro Gruppe.

Wichtig für uns ist zu sehen was gelernt wurde. Es bietet sich daher an, beispielsweise auf folgende Fragen einzugehen:

Was war eure Projektidee (geht wieder davon aus, dass eure Projektidee nicht mehr allen gänzlich bekannt ist) und was habt ihr letztendlich alles umsetzen können?
Mit welcher Embedded-Hardware und welchen Protokollen habt ihr euch beschäftigt?
Mit welcher Entwicklungsumgebung (ggf. mit welchen Erweiterungen) habt ihr entwickelt? Wie gut funktionierte die Installation und anschließende Arbeit damit?
Welche Frameworks & APIs habt ihr verwendet? Wie sieht der Quelltext aus, um ein konkretes Problem zu lösen?
Habt ihr irgendwelche "Geheimtipps" (z. B. schwer auffindbare Dokumentation) oder "Das-hätte-ich-gern-vorher-gewusst!"-Erfahrungen?
Welche (ungeplanten) Probleme gab es und wie wurden sie gelöst?
Wie ist das Zeitverhalten? Wie hoch ist der Ressourcenverbrauch (CPU, Speicher, etc.)?
(Falls ihr Strom gemessen habt:) Welche Messgeräte habt ihr verwendet? Wie einfach war das bzw. gab es Tricks, um die Messungen praktikabel durchzuführen?

Leistungserfassung

Die Endnote wird in einer abschließenden mündlichen Prüfung ermittelt. Voraussetzung für die Zulassung zur Prüfung ist die regelmäßige Lösung der Aufgaben im Praktikum (Auftakt-, Zwischenstands- und End-Präsentation; Konsultationen).

Die Prüfungsdauer beträgt 30 Minuten (Einzelprüfung).
Es steht euch frei, in den ersten fünf Minuten selbst über ein beliebiges, lehrveranstaltungsbezogenes Thema zu referieren (ohne Hilfsmittel, d. h. keine Notizen, keine Folien, etc.) – beispielsweise über eure Projektarbeit. Gegebenenfalls gibt es noch Anschlussfragen zur Projektarbeit und Überleitung zu den Prüfungsfragen.
In den restlichen 25 Minuten widmen wir uns Fragen aus allen in der Vorlesung behandelten Themenbereichen (die nicht unbedingt eine Verbindung zur Projektarbeit haben müssen).
Die Prüfungen finden im Büro von Prof. Polze statt (C-1.7, Zugang über C-1.8). Die Kandidaten sind gebeten in der Kommunikationszone C-1 auf Aufruf zu warten.