© Prof. Dr. Andreas M. Heinecke, WHS Gelsenkirchen. Wissen. Was praktisch zählt. Stand: 04.06.13 Folie 20.1 Software-Engineering SS 2013 – Alle Master-Studiengänge

© Prof. Dr. Andreas M. Heinecke, WHS Gelsenkirchen.

Wissen. Was praktisch zählt.

Stand: 04.06.13 Folie 20.1

Software-Engineering SS 2013 – Alle Master-Studiengänge der Informatik

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



Stand: 04.06.13 Folie 20.2


20 Eingebettete Software

20.3 Analyse des Zeitverhaltens Antwortzeiten Ausführungszeiten

20.4 Echtzeitbetriebssysteme Prozessverwaltung Prioritäten Scheduling



Stand: 04.06.13 Folie 20.3


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



Stand: 04.06.13 Folie 20.4


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



Stand: 04.06.13 Folie 20.5


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



Stand: 04.06.13 Folie 20.6


20.0 Echtzeitsystem

Definition 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



Stand: 04.06.13 Folie 20.7


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



Stand: 04.06.13 Folie 20.8


20.1.0Entwurf 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



Stand: 04.06.13 Folie 20.9


20.1.0Reaktive 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



Stand: 04.06.13 Folie 20.10


20.1.0Beispiel: Stimulus-Response-TabelleStimulus Response

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 Service benachrichtigen

Panikschalter positiv Alarm auslösen, Lampen im Umfeld des Schaltpults einschalten, Polizei alarmieren

Alarmlöschung Alarm ausschalten, Lampen ausschalten



Stand: 04.06.13 Folie 20.11


20.1.0Aufbau eines eingebetteten Echtzeitsystems

Sensor Sensor Sensor Sensor Sensor Sensor

Echtzeit-steuerungssystem

Aktor Aktor Aktor Aktor



Stand: 04.06.13 Folie 20.12


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



Stand: 04.06.13 Folie 20.13


20.1.0Einzelner Sensor-Aktor-Prozess

Sensor

Sensor-steuerung

Aktor

Daten-verarbeitun

g

Aktor-steuerung

Stimulus

Response

Sensorsteuerung sammelt Daten von Sensor, puffert diese Daten

gegebenenfalls Datenverarbeitung

verarbeitet gesammelte Daten und berechnet Reaktion Aktorsteuerung

erzeugt Steuerungssignale für die Aktoren



Stand: 04.06.13 Folie 20.14


20.1.0Aktivitä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)



Stand: 04.06.13 Folie 20.15


20.1.0Prozesskoordination

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



Stand: 04.06.13 Folie 20.16


20.1.1Modellierung von Echtzeitsystemen

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



Stand: 04.06.13 Folie 20.17


20.1.1Zustandsmodell eines Echtzeitsystems



Stand: 04.06.13 Folie 20.18


20.1.2Programmierung 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



Stand: 04.06.13 Folie 20.19


20.2.0Architekturmuster

Grundstruktur 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



Stand: 04.06.13 Folie 20.20


20.2.0Anwendung 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



Stand: 04.06.13 Folie 20.21


20.2.1Muster: Beobachten und Reagieren



Stand: 04.06.13 Folie 20.22


20.2.1Prozess: Beobachten und Reagieren



Stand: 04.06.13 Folie 20.23


20.2.1Beispiel: Beobachten und Reagieren



Stand: 04.06.13 Folie 20.24


20.2.2Muster: Umgebungssteuerung



Stand: 04.06.13 Folie 20.25


20.2.2Prozess: Umgebungssteuerung



Stand: 04.06.13 Folie 20.26


20.2.2Beispiel: Umgebungssteuerung



Stand: 04.06.13 Folie 20.27


20.2.3Muster: Pipelineverarbeitung



Stand: 04.06.13 Folie 20.28


20.2.3Prozess: Pipelineverarbeitung



Stand: 04.06.13 Folie 20.29


20.2.3Beispiel: Pipelineverarbeitung



Stand: 04.06.13 Folie 20.30


20.3 Analyse des Zeitverhaltens

Bestimmung der Häufigkeit von Prozessausführungenum 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



Stand: 04.06.13 Folie 20.31


20.3 Beispiel: Zeitanforderungen



Stand: 04.06.13 Folie 20.32


20.3 Beispiel: Zeitanforderungen im Prozessmodell



Stand: 04.06.13 Folie 20.33


20.4.0Echtzeitbetriebssysteme

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



Stand: 04.06.13 Folie 20.34


20.4.0Komponenten eines Echtzeitbetriebssystems



Stand: 04.06.13 Folie 20.35


20.4.1Prozessverwaltung

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



Stand: 04.06.13 Folie 20.36


20.4.1Prozessverwaltung

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



Stand: 04.06.13 Folie 20.37


20.4.1Starten von Prozessen



Stand: 04.06.13 Folie 20.38


20.4.1Einplanungsstrategien

Zeitplanung ohne Unterbrechungnon pre-emptive scheduling einmal gestarteter Prozess läuft,

bis er abgeschlossen oder blockiert ist

Zeitplanung mit Unterbrechungpre-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

Documents

© Prof. Dr. Andreas M. Heinecke, WHS Gelsenkirchen. Wissen. Was praktisch zählt. Stand: 04.06.13 Folie 20.1 Software-Engineering SS 2013 – Alle Master-Studiengänge