20 Eingebettete Software 20.0 Einführung Lernziele Echtzeitsysteme Eingebettete Systeme 20.1 Entwurf eingebetteter Systeme Modellierung von Echtzeitsystemen Programmierung von Echtzeitsystemen 20.2 Architekturmuster Beobachten und Reagieren Umgebungssteuerung Pipelineverarbeitung

20 Eingebettete Software 20.3 Analyse des Zeitverhaltens Antwortzeiten Ausführungszeiten 20.4 Echtzeitbetriebssysteme Prozessverwaltung Prioritäten Scheduling

20.0 Lernziele das Konzept eingebetteter Software für Systeme, die auf externe Ereignisse reagieren, verstehen einen Entwurfsprozess für Echtzeitsysteme, bei dem die Software als eine Menge kooperierender Prozesse organisiert ist, kennen lernen, drei Architekturmuster für eingebettete Echtzeitsysteme kennen, die Organisation von Echtzeitbetriebssystemen und ihre Rolle in eingebetteten Echtzeitsystemen verstehen

20.0 Eingebettete Systeme Systeme aus Hardware und Software, die in einen technischen Kontext eingebettet sind Überwachung, Steuerung, Regelung Signalverarbeitung in technischen Geräten integrierte Computeranwendungen Kameras, Waschmaschinen, Kaffeemaschinen, medizinische Geräte, Router, DVD-Player, ABS etc. oft keine eigene oder unkonventionelle Benutzerschnittstelle Reaktion auf externe Ereignisse am meisten verbreitete Computeranwendung oft spezielle (einfache) Hardware

20.0 Zeitanforderungen Reaktion eingebetteter Systeme in der Regel innerhalb vorgegebener Zeitschranke erforderlich Unterschied zu Informationssystemen, Webanwendungen etc. Korrektheit zeitabhängig bestimmte Ausgabe zu bestimmter Eingabe nicht ausreichend muss auch innerhalb bestimmter Zeit erfolgen Echtzeitsystem

20.0 Echtzeitsystem Definition Harte Echtzeitanforderungen Echtzeitbetrieb ist der Betrieb eines Rechnersystems, bei dem Programme zur Verarbeitung anfallender Daten ständig betriebsbereit sind, derart, dass die Verarbeitungsergebnisse innerhalb einer vorgegebenen Zeitspanne verfügbar sind [DIN 44300]. Harte Echtzeitanforderungen Fehler, wenn Zeitschranke nicht eingehalten wird im Fehlerfall oft schwerwiegende Folgen Weiche Echtzeitanforderungen Überschreiten der Zeitschranke kann vorkommen bei Überschreiten eingeschränkte Leistung des Systems

20.0 Charakteristika eingebetteter Systeme Dauerbetrieb von Einschalten der Hardware bis Ausschalten der Hardware Interaktionen mit der Umgebung unvorhersagbar und nicht beschränkbar unerwartete Ereignisse zu verarbeiten Physikalische Beschränkungen Platz und Gewicht, Stromversorgung, Immissionen Direkte Ansteuerung externer Hardware keine Treiberschicht Sicherheit und Zuverlässigkeit im Vordergrund bei Fehlern oft gravierende Schäden

20.1.0 Entwurf eingebetteter Systeme Systems Engineering statt Software Engineering Berücksichtigung der Hardware Konstruktion und Leistung Geeignete Aufteilung der Systemfähigkeiten Software oder Hardware Systemnahe Entscheidungen schon zu Beginn Hardware, Hilfssoftware, Zeitsteuerung kein Top-down-Entwurf möglich Zusätzliche Funktionalität oft nötig Energiemanagement

20.1.0 Reaktive Systeme Eingebettete System reagieren auf externe Ereignisse Reiz-Reaktion-System bzw. Stimulus-Response-System Response auf Stimulus innerhalb bestimmter Zeit Verhalten des Systems als Tabelle beschreibbar Stimulus – Response Arten von Stimuli periodisch vorhersagbare regelmäßige Zeitabstände z.B. Sensorabfrage alle 50 Millisekunden sporadisch (aperiodisch) unregelmäßig, ggf. selten z.B. Stromausfall Verarbeitung meist über Interrupt

20.1.0 Beispiel: Stimulus-Response-Tabelle einzelner Sensor positiv Alarm auslösen, Lampen im Umfeld des Sensors einschalten zwei oder mehr Sensoren positiv Alarm auslösen, Lampen im Umfeld der Sensoren einschalten, Polizei alarmieren Spannungsabfall zwischen 10% und 20% Reservebatterie einschalten, Stromversorgung testen Spannungsabfall von mehr als 20% Reservebatterie einschalten, Stromversorgung testen, Alarm auslösen, Polizei alarmieren Ausfall der Stromversorgung Service benachrichtigen Sensorausfall Panikschalter positiv Alarm auslösen, Lampen im Umfeld des Schaltpults einschalten, Polizei alarmieren Alarmlöschung Alarm ausschalten, Lampen ausschalten

20.1.0 Aufbau eines eingebetteten Echtzeitsystems Sensor Echtzeit- steuerungssystem Aktor

20.1.0 Überlegungen zur Architektur Rechtzeitiges Reagieren erforderlich schnelles Umschalten zwischen Stimulusverarbeitungen Unterschiedliche Zeitanforderungen sequentielle Abarbeitung meist nicht angemessen Architekturansatz: Kooperierende nebenläufige Prozesse Echtzeitbetriebssystem unterschiedliche Prioritäten Interrupt-Steuerung

20.1.0 Einzelner Sensor-Aktor-Prozess Stimulus Response Sensor-steuerung Daten- verarbeitung Aktor- steuerung Sensorsteuerung sammelt Daten von Sensor, puffert diese Daten gegebenenfalls Datenverarbeitung verarbeitet gesammelte Daten und berechnet Reaktion Aktorsteuerung erzeugt Steuerungssignale für die Aktoren

20.1.0 Aktivitäten im Entwurfsprozess Auswahl der Ausführungsplattform Hardware, Echtzeitbetriebssystem Bestimmung der Stimuli und zugehörigen Responses Analyse des Zeitverhaltens Zeitvorgaben für Stimulus – Verarbeitung – Response Prozessentwurf nebenläufige Prozesse nach Architekturmuster -> 20.2 Algorithmenentwurf einschließlich Aufwandsanalyse (insbesondere Zeitaufwand) Datenentwurf Festlegung des Datenaustausches zwischen den Prozessen Prozessplanung (Scheduling)

20.1.0 Prozesskoordination Zugriff nebenläufiger Prozesse auf gemeinsame Ressourcen Lesen und Schreiben durch unterschiedliche Prozesse gegenseitiger Ausschluss erforderlich Semaphore kritische Bereiche Monitore Ausgleich unterschiedlicher Geschwindigkeiten Bereitstellen und Abarbeiten von Daten Puffer erforderlich häufig Ringpuffer

20.1.1 Modellierung von Echtzeitsystemen Stimuli bewirken Zustandsübergänge Modellierung durch Zustandsmodelle Darstellung mit UML-Zustandsdiagrammen

20.1.1 Zustandsmodell eines Echtzeitsystems

20.1.2 Programmierung von Echtzeitsystemen Anforderungen an die Programmierumgebung Zugriff auf Systemhardware Festlegung von Zeitpunkten / Zeitspannen für Operationen Effizienz Verwendete Sprachen Assembler und systemnahe Sprachen wie C effizient fehleranfällig wegen fehlender Features für Nebenläufigkeit Echtzeitsprachen wie PEARL Objektorientierte Sprachen wie Java mit Erweiterungen asynchrone Kommunikation absolute und relative Zeitangaben nicht unterbrechbare Threads keine Verzögerungen durch Speicherbereinigung

20.2.0 Architekturmuster Grundstruktur Echtzeitarchitekturmuster eingebettete Software prozessorientiert interaktive Software objekt- / komponentenorientiert Echtzeitarchitekturmuster Beobachten und Reagieren Überwachung und Darstellung von Sensorwerten Sensorereignis löst Prozess zur Ereignisbehandlung aus Umgebungssteuerung Sensoren zur Umgebungsüberwachung Aktoren zur Umgebungssteuerung Sensorwerte lösen Steuersignale aus Pipelineverarbeitung Umwandlung von Daten zur Weiterverarbeitung Folge von Verarbeitungsschritten ggf. auf verschiedenen Prozessoren

20.2.0 Anwendung der Architekturmuster Kombination der Muster Umgebungssteuerung mit Aktoren Beobachten der Aktoren und Reagieren bei Ausfall Grundstruktur für weitere Detaillierung mit Entwurfsmustern, z.B. Ausführungssteuerung Kommunikation Resourcenzuweisung Optimierung der Prozessstruktur erforderlich Architekturmuster als Entwurfsvorlagen meist ineffizient nicht zu viele Prozesse verwenden klarer Zusammenhang zwischen Prozessen und Sensoren und Aktoren erforderlich

20.2.1 Muster: Beobachten und Reagieren

20.2.1 Prozess: Beobachten und Reagieren

20.2.1 Beispiel: Beobachten und Reagieren

20.2.2 Muster: Umgebungssteuerung

20.2.2 Prozess: Umgebungssteuerung

20.2.2 Beispiel: Umgebungssteuerung

20.2.3 Muster: Pipelineverarbeitung

20.2.3 Prozess: Pipelineverarbeitung

20.2.3 Beispiel: Pipelineverarbeitung

20.3 Analyse des Zeitverhaltens Bestimmung der Häufigkeit von Prozessausführungen um Antwortzeiten garantieren zu können leicht zu berechnen bei periodischen Stimuli schwierig bei sporadischen Stimuli (Wahrscheinlichkeitsrechnung) Ersatz sporadischer Stimuli durch periodische möglich sporadisch: Interrupt bei Ausfall der Stromversorgung periodisch: Abfrage der Stromversorgung alle x msec Wesentliche Faktoren Fristen Häufigkeiten Ausführungszeiten

20.3 Beispiel: Zeitanforderungen

20.3 Beispiel: Zeitanforderungen im Prozessmodell

20.4.0 Echtzeitbetriebssysteme Grundlegende Komponenten Echtzeituhr: vorwiegend für periodische Prozesse Interrupt-Handler: für sporadische Ereignisse Scheduler (Einplaner): zur Auswahl des auszuführenden Prozesses Resourcenmanager: Zuordnung und Freigabe Dispatcher (Verteiler): zum Starten der Prozessausführung Zusätzliche Komponenten Plattenspeicherverwaltung Fehlerverwaltung Konfigurationsmanager

20.4.0 Komponenten eines Echtzeitbetriebssystems

20.4.1 Prozessverwaltung Grundlegende Prioritätsstufen Interrupt-Stufe Vorrangstufe für Prozesse mit sehr kurzer Antwortzeit Echtzeituhr immer auf Interrupt-Stufe Echtzeitstufe nachrangige Stufe für periodische Prozesse weitere Unterteilung der Prioritätsstufen möglich Ziel: Sicherung der Antwortzeit für alle Prozesse

20.4.1 Prozessverwaltung Bearbeitung von Interrupts Sprung zu Interrupt-Routine Interrupt-Routine muss kurz, einfach und schnell sein meist Sperrung anderer Interrupts Bearbeitung des Ereignisses Rückkehr zum unterbrochenen Prozess Bearbeitung von periodischen Prozessen unterschiedliche Häufigkeiten, Ausführungszeiten, Antwortzeiten Echtzeituhr erzeugt periodisch Interrupts Interrupt ruft Scheduler auf Scheduler wählt einen lauffähigen Prozess zur Ausführung aus

20.4.1 Starten von Prozessen

20.4.1 Einplanungsstrategien Zeitplanung ohne Unterbrechung non pre-emptive scheduling einmal gestarteter Prozess läuft, bis er abgeschlossen oder blockiert ist Zeitplanung mit Unterbrechung pre-emptive scheduling laufender Prozess kann durch Prozess höherer Priorität unterbrochen werden Zeitplanungsalgorithmen Ausführung reihum (Round-Robin) Vorzug für höchste Frequenz (Rate Monotonic Scheduling RMS) Dringlichkeitsorientiert: Prozess mit kürzester Anwortzeit zuerst