Die Präsentation wird geladen. Bitte warten

Die Präsentation wird geladen. Bitte warten

COMET-Methodik: Realzeit Karsten Balzer Entwicklung verteilter eingebetteter Systeme Februar 2002.

Ähnliche Präsentationen


Präsentation zum Thema: "COMET-Methodik: Realzeit Karsten Balzer Entwicklung verteilter eingebetteter Systeme Februar 2002."—  Präsentation transkript:

1 COMET-Methodik: Realzeit Karsten Balzer Entwicklung verteilter eingebetteter Systeme Februar 2002

2 Übersicht xTask Structuring Was sind Tasks? Was ist Task Structuring? Strukturierungskriterien Beispiele xPerformance Analysis Einleitung Verfahren zu Analyse Beispiel xWas tun bei Engpässen?

3 Was sind Tasks? xAuch Thread oder Prozeß xaktive Objekte, dies sind autonome Objekte mit eigenem, sequentiellen Kontrollfluß xsie repräsentieren sequentielle Programme oder sequentielle Teile aus nebenläufigen Programmen xinnerhalb von Tasks gibt es keine Nebenläufigkeit xUnterscheidung in Input/Output Tasks, für Objekte, die nach Außen kommunizieren interne Tasks

4 Task Structuring - Einleitung xCOMET-Phase: Software Design xZiele: Analyse-Modell zu Task Architektur umwandeln Separation of concerns, Tasks nach Aufgaben aufteilen Einfaches und klares Design Minimierung von Overhead in Form von Inter-Task Kommunikation und Synchronisation xKriterien sind Richtlinien und Heuristiken um diesen Konflikt zwischen übersichtlichem Design und geringem Overhead zu lösen

5 Task Structuring - Einleitung 2 yDie Strukturierung ist eingeteilt in zwei Phasen: xPhase 1: Jedes aktive Objekt erhält einen Task I/O task structuring criteria Internal task structuring criteria Task priority criteria xPhase 2: Zusammenfassen der Tasks aus Phase 1 Task clustering criteria Task inversion criteria

6 Task Structuring Phase 1 xJedem aktiven Objekt wird genau ein Candidate Task zugeordnet, also vorläufige Tasks, die später noch verändert werden xDadurch können die Aufgaben jedes einzelnen Tasks schnell ersehen werden xTasks werden Prioritäten zugeordnet Zeitkritische Tasks werden identifiziert und erhalten höhere Prioritäten oder Tasks mit kürzerer Periode erhalten eine höhere Priorität als Tasks mit längerer Periode xwichtig für die Performance Analyse

7 I/O Task Structuring Criteria xUnterscheidung nach Asynchrone/aktive I/O Devices, die einen Interrupt bei Input oder nach Output generieren Passive I/O Devices, Input bzw. Output wird nur bei Bedarf oder periodisch gelesen oder generiert Communication Links, die zur Kommunikation mit anderen Systemen dienen, z.B. via TCP/IP xJedem dieser Objekte wird ein eigener Task zugeordnet

8 Beispiel I/O Task yFloorButtonInterface yAsynchronous Input Device: xDurch Drücken eines Knopfes wird der Fahrstuhl gerufen yNach dem I/O Task Structuring Criteria erhält das FloorButtonInterface einen eigenen Task

9 Internal Task Structuring Criteria xUnterscheidung in Periodische Tasks: Ein durch einen Timer ausgelöster, periodischer Task Asynchrone Tasks: Bei Bedarf durch interne Nachrichten oder Events aktivierte Objekte Control Tasks: Tasks zu zustandsorientierten Kontrollobjekten, deren Statecharts keine parallelen Zustände aufweisen User Interface Tasks: Dienen zur Kommunikation zwischen Benutzer und System Mehrere Tasks desselben Typs: Tasks zu gleichartigen Objekten, die aber in unterschiedlichen Zuständen sein können xJedem dieser Objekte wird ein eigener Task zugeordnet

10 Task Priority Criteria xGenerell werden Prioritäten nach dem Rate Monotonic Algorithm vergeben xDarüber hinaus wird unterschieden in Zeitkritische Tasks: Typischerweise asynchrone I/O Tasks oder Tasks die für Output-Tasks wichtige Berechnungen durchführen. Diese erhalten höhere Prioritäten, damit das System schnell reagieren kann Nicht-zeitkritische Tasks: Diese Tasks können niedrigere Prioritäten erhalten, damit sie von zeitkritischen Tasks unterbrochen werden können

11 Task Structuring Phase 2 xKritierien: Task Clustering Task Inversion xCandidate Tasks aus Phase 1 werden zusammengefaßt xDadurch werden Overhead und Komplexität reduziert xTask Inversion faßt stärker zusammen als Task Clustering

12 Task Clustering Criteria xZusammenfassen von Tasks, dabei wird unterschieden nach Temporal Clustering: Tasks, die von dem selben Event ausgelöst werden und die in beliebiger Reihenfolge ausgeführt werden Sequential Clustering: Tasks, die sich sequentiell durch Events gegenseitig starten Control Clustering: Ein Task, der ein sequentielles Statechart startet, kann mit Objekten zusammengelegt werden, die von diesem Statechart angestoßen werden Mutually Exclusive Clustering: Tasks, von denen maximal einer gleichzeitig aktiv ist

13 Beispiel Task Clustering yElevatorContol, ElevatorLampInterface yPassive output device: Lampen für Fahrstuhl xOutput nur bei Bedarf xAufrufender Task muss warten, bis der Output-Task fertig ist yZusammenfassen nach Control Clustering Criterion

14 Task Inversion xZusammenfassen von Tasks zum Zweck der Reduzierung von Overhead xUnterscheidung in Multiple-Instance Task Inversion: Mehrere identische Tasks werden zusammengefaßt Sequential Task Inversion: Sequentiell ausgeführte Tasks, die mit Hilfe von Nachrichten kommunizieren Temporal Task Inversion: Tasks, die von dem selben Timer gestartet werden, können inklusive des Timers zusammengefaßt werden xFür das Design meist unschöne Veränderungen, daher oft nur für Optimierung benutzt

15 Ergebnis Elevator

16 Performance Analysis - Einleitung xCOMET-Phase: Detailed Software Design, kann gleich nach dem Task Structuring beginnen xZiel: Potentielle Performance Probleme finden und beheben xZeitkritische Tasks müssen Deadlines einhalten xDeadlines sind vorgegebene Termine, vor denen ein Task beendet sein muss xDabei sind gegeben: Hardwarekonfiguration Prozessorlast der einzelnen Tasks

17 Event Sequence Analysis xZu jedem Use-Case werden Event Sequenzen betrachtet und überprüft xDiese Sequenzen werden durch einen externer Event ausgelöst xBetrachtet werden die Rechenzeiten für: I/O-Task die folgende Sequenz interner Tasks CPU Overhead bekannte, parallel ablaufende Tasks xDie Summe diese Zeiten kleiner als die gewünschte Reaktionszeit des Systems, um Echzeitanforderungen zu erfüllen

18 Real-Time Scheduling Theory xursprünglich für unabhängige, periodische Tasks xBerechnung basiert auf Prioritäten der Tasks xCPU Belastung der Tasks wird als bekannt vorausgesetzt. Nach COMET basieren sie auf Abschätzungen aufgrund vorheriger Projekte xEin Task hält seine Deadline ein, wenn seine Ausführung innerhalb seiner Periode endet xRate Monotonic Algorithm: Jeder Task erhält basierend auf seiner Periode eine feste Priorität xJe kürzer die Periode desto höher die Priorität xDies stellt eine Vereinfachung dar, zeitkritische Tasks werden zunächst nicht betrachtet

19 Utilization Bound Theorem xGrobe Worst-Case-Abschätzung auf Basis des Rate Monotonic Algorithm xJeder Task hat eine Periode T und eine Ausführungszeit C xn unabhänge, periodische Tasks halten ihre Deadlines ein, wenn gilt: xU(n) konvergiert dabei zu 0.69 xUtilization U ist die prozentuale Nutzung des Prozessors während der betrachteten Zeitspanne

20 Completion Time Theorem xEbenfalls eine Worst-Case-Abschätzung, allerdings viel genauer als das Utilization Bound Theorem xVoraussetzung: Wenn ein Task seine erste Deadline einhält, hält er auch alle späteren Deadlines ein xWenn ein Task seine Deadline in der ersten Periode einhält und alle Tasks gleichzeitig gestartet werden, tun sie dies bei allen möglichen Kombinationen aus Startzeiten

21 Completion Time Theorem Beispiel zt1 : C1 = 20, T1 = 100, U1 = 0.2 zt2 : C2 = 30, T2 = 150, U2 = 0.2 zt3 : C3 = 90, T3 = 200, U3 = 0.45 zBeginn mit der Worst-Case- Annahme, dass alle drei Tasks gleichzeitig gestartet werden zNach dem Diagramm halten alle Tasks ihre Deadline ein zUtilization U = U1+U2+U3 = 0.85 zVergleich zum Utilization Bound Theorem: zU > U(n), trotzdem werden die Deadlines eingehalten

22 Completion Time Theorem Mathematische Formel xEine Menge aus n unabhängigen, periodischen Tasks hält bei Anwendung des Rate Monotonic Algorithm seine Deadlines genau dann ein, wenn gilt: xBetrachtungen am Ende einer Periode p des Tasks k xTask i ist der momentan betrachtete Task, alle Task k können diesen aufgrund höherer Priorität unterbrechen

23 Generalized Utilization Bound Theorem Läßt man neben dem Rate Monotonic Algorithm zu, dass zeitkritische Tasks höhere Prioritäten erhalten, müssen zusätzlich folgende Punkte beachtet werden: –Unterbrechung durch höher priorisierte Tasks mit längerer Periode –Blocken durch niedriger priorisierte Tasks Alle Deadlines werden eingehalten, wenn die Utilization jedes Tasks kleiner als 0,69 ist. Die Utilization wird hier berechnet mit: Eine entsprechende Verallgemeinerung existiert auch für das Completion Time Theorem

24 Beispiel: Request Elevator Event Sequence xPeriode: 200 msec xAusführungszeit der Tasks in der Event Sequenz Floor Button InterfaceScheduler Elevator Manager C = = 30 msec U = C/T = 0.15

25 Beispiel: Request Elevator Event Sequence 2 xUnterbrechung durch höher priorisierte Tasks mit kürzerer Periode Arrival Sensors Interface und Elevator Controller zusammen max. 28 msec Elevator Button Interface und Elevator Manager zusammen max. 18 msec C = = 46 U = C/T = 0.23

26 Beispiel: Request Elevator Event Sequence 3 xUnterbrechung durch höher priorisierte Tasks mit längerer Periode Diese Event Sequenz hat die längste Periode xZeit, die der Task beblockt werden kann keine, T = 0 xDa diese beiden Punkte nicht beachtet werden müssen, gilt der Rate Monotonic Algorithm. Also kann das Utilization Bound Theorem angewandt werden. xT = = 46 msec < period xU = = 0.38 < 0.69 xDie Deadline wird also eingehalten.

27 Was tun bei Engpässen? yEngpässe entstehen, wenn zeitkritische Tasks ihre Deadlines nicht einhalten können yTasks neu strukturieren xOverhead reduzieren durch Task Inversion yHardware ändern xschnellerer Prozessor,...

28 Zusammenfassung xTasks sind aktive Objekte mit Kontrollfluß xSie werden mit Hilfe von Scheduling Kriterien erst erzeugt und danach gruppiert xDabei erhalten sie eine Priorität xIn Echtzeit-Systemen müssen Tasks gegebene Deadlines einhalten xOb dies der Fall ist, lässt sich mit Hilfe von Eventsequenz-Analysen und verschiedenen Theoremen abschätzen xWerden die Grenzen nicht eingehalten, müssen die Tasks weiter zusammengefaßt werden


Herunterladen ppt "COMET-Methodik: Realzeit Karsten Balzer Entwicklung verteilter eingebetteter Systeme Februar 2002."

Ähnliche Präsentationen


Google-Anzeigen