1 / 90

Teil 3 Grundlegende Techniken und Architekturen

Aktuelle Themen bei Eingebetteten Systemen – Organic Computing SS 2010 Prof. Dr. Uwe Brinkschulte. Teil 3 Grundlegende Techniken und Architekturen. 3. Grundlegende Techniken und Architekturen. 3.1 Observer/Controller Architekturen 3.2 Der MAPE Zyklus

badru
Télécharger la présentation

Teil 3 Grundlegende Techniken und Architekturen

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

  1. Aktuelle Themen bei Eingebetteten Systemen – Organic Computing SS 2010 Prof. Dr. Uwe Brinkschulte Teil 3 Grundlegende Techniken und Architekturen Organic Computing – Teil 3a, Folie 1 - Prof. Dr. Uwe Brinkschulte

  2. 3. Grundlegende Techniken und Architekturen 3.1 Observer/Controller Architekturen 3.2 Der MAPE Zyklus 3.3 Learning Classifier Systems 3.4 Evolutionäre und Genetische Algorithmen 3.5 Organic Computing und Middleware 3.6 Multi-Agenten-Systeme und Auktionen 3.7 Künstliche Hormonsysteme 3.8 Verteilung abhängiger Aufgaben Organic Computing – Teil 3a, Folie 2 - Prof. Dr. Uwe Brinkschulte

  3. 3. Grundlegende Techniken und Architekturen Angestrebte Eigenschaften • Robustheit • Flexibilität • Anpassungsfähigkeit • Meistern unbekannter Sitatutionen • Lernfähigkeit • Vorhersage künftigen Verhaltens Wie festgestellt müssen selbstorganisierende Systeme beobachtet und kontrolliert werden, um das gewünschte Verhalten zu erreichen Organic Computing – Teil 3a, Folie 3 - Prof. Dr. Uwe Brinkschulte

  4. 3.1 Observer/Controller Architekturen Entwickelt am KIT (H. Schmeck) und der Universität Hannover (C. Müller-Schloer) System unter Beobachtung und Kontrolle(System under Observation and Control - SuOC) SuOC Eingabe Zustand Ausgabe Organic Computing – Teil 3a, Folie 4 - Prof. Dr. Uwe Brinkschulte

  5. 3.1 Observer/Controller Architekturen Das System unter Beobachtung und Kontrolle • ist ein beliebig komplexes System • kann unabhängig von externer Beobachtung und Kontrolle arbeiten • kann alle Eigenschaften eines komplexen Systems haben Eingabe: alle Informationen, auf die das System reagiert, die es aber nicht kontrolliere kann Ausgabe: alle Informationen, die das System erzeugt und die von aussen sichtbar sind Zustand: alle Informationen, die das Gedächtnis des Systems bilden, Teile des Zustandes können als Ausgabe von aussen sichtbar sein Ausgabe Organic Computing – Teil 3a, Folie 5 - Prof. Dr. Uwe Brinkschulte

  6. 3.1 Observer/Controller Architekturen Beispiel: Roboterschwarm zur Erforschung eines Geländes • Komplexes System aus einer Vielzahl von Robotern • Jeder Roboter folgt lokalen Regeln • Roboter interagieren Eingabe: Sensorinformationen der Robotor (z.B. über Temperatur, Druck, Strahlung an der jeweiligen Roboter-Position) Ausgabe: geeignete Position eines Stützpunktes Zustand: Position der jeweiligen Roboter, Bewegungsmuster, bereits gesammelte Informationen, … Ausgabe Organic Computing – Teil 3a, Folie 6 - Prof. Dr. Uwe Brinkschulte

  7. 3.1 Observer/Controller Architekturen SuOC ZustandPosition, Bewegung, Informationen der Roboter Ausgabegeeignete Stützpunkt-Koordinaten EingabeDruck, Temperatur, Strahlung Lokale Regel, Interaktion: Fahre geradeaus, bis du auf ein Hindernis oder einen anderen Roboter triffst. Dann drehe um einen zufälligen Wert und fahre wieder geradeaus Organic Computing – Teil 3a, Folie 7 - Prof. Dr. Uwe Brinkschulte

  8. 3.1 Observer/Controller Architekturen • Dieses System • ist dezentral • ist selbstorganisierend • besitzt Selbst-X Eigenschaften (zumindest Selbst- Konfiguration und Selbst-Heilung, da ein begrenzter Ausfall von Robotern durch andere kompensiert werden kann) • kann emergente Effekte zeigen • Zur gleichmäßigen Erforschung ist möglichst eine Gleichverteilung der Roboter erwünscht • Eine Bündelung an einem Ort reduziert die Performanz => negative Emergenz Organic Computing – Teil 3a, Folie 8 - Prof. Dr. Uwe Brinkschulte

  9. 3.1 Observer/Controller Architekturen Günstige (erwünschte) Roboterverteilung Entropie: Organic Computing – Teil 3a, Folie 9 - Prof. Dr. Uwe Brinkschulte

  10. 3.1 Observer/Controller Architekturen Ungünstige (unerwünschte) Roboterverteilung Entropie: Organic Computing – Teil 3a, Folie 10 - Prof. Dr. Uwe Brinkschulte

  11. 3.1 Observer/Controller Architekturen Wie bereits in Kapitel 2 gesehen kann die Zunahme der (hier unerwünschten) Emergenz durch Abnahme der Entropie erkannt werden: Hmax = log2(n) = log2(16) = 4 Mgünstig = Hmax - Hgünstig = 4 – 3.17 = 0.83 Mungünstig = Hmax – Hungünstig = 4 – 1.53 = 2.47 => Einführung eines Beobachters Organic Computing – Teil 3a, Folie 11 - Prof. Dr. Uwe Brinkschulte

  12. 3.1 Observer/Controller Architekturen Observer Ergebnis Beobachtung SuOC Eingabe Zustand Ausgabe • Der Beobachter (Observer) • erhält alle Informationen über das SuOC (Eingabe, Ausgabe, Zustand) • identifiziert und charakterisiert das gegenwärtige Verhalten • schätzt künftiges Verhalten ab Organic Computing – Teil 3a, Folie 12 - Prof. Dr. Uwe Brinkschulte

  13. 3.1 Observer/Controller Architekturen Observer Ergebnis M = 0.83 Beobachtung Roboterposition SuOC Ausgabegeeignete Stützpunkt-Koordinaten EingabeDruck, Temperatur, Strahlung ZustandPosition, Bewegung, … Im Beispiel Organic Computing – Teil 3a, Folie 13 - Prof. Dr. Uwe Brinkschulte

  14. 3.1 Observer/Controller Architekturen Observer Ergebnis M = 2.47 Beobachtung Roboterposition SuOC Ausgabegeeignete Stützpunkt-Koordinaten EingabeDruck, Temperatur, Strahlung ZustandPosition, Bewegung, … Im Beispiel Organic Computing – Teil 3a, Folie 14 - Prof. Dr. Uwe Brinkschulte

  15. 3.1 Observer/Controller Architekturen Auf Basis der vom Beobachter gelieferten Ergebnisse kann in das SuOC eingegriffen werden In unserem Beispiel: steigt die Emergenz M über einen Schwellwert, werden die Regeln im SuOC geändert, etwa: triffst du auf einen anderen Roboter, drehe um 180° Auch eine zentrale Instanz, welche bestimmten Robotern Fahranweisungen gibt, um einer drohenden Bündelung entgegenzuwirken, ist möglich => Einführung eines Controllers M Schwellwert t Organic Computing – Teil 3a, Folie 15 - Prof. Dr. Uwe Brinkschulte

  16. 3.1 Observer/Controller Architekturen Ergebnis Controller Ziele Observer Beobachtung Kontrolle SuOC Eingabe Zustand Ausgabe • Der Controller • beeinflusst und konfiguriert das SuOC gemäß der gewünschten Ziele • unterdrückt unerwünschtes Verhalten so schnell und effizient wie möglich Organic Computing – Teil 3a, Folie 16 - Prof. Dr. Uwe Brinkschulte

  17. 3.1 Observer/Controller Architekturen Ergebnis M = 0.83 ZieleschnelleErforschung Observer Controller Beobachtung Roboterposition Kontrollealles ok SuOC Ausgabegeeignete Stützpunkt-Koordinaten EingabeDruck, Temperatur, Strahlung ZustandPosition, Bewegung, … Im Beispiel Organic Computing – Teil 3a, Folie 17 - Prof. Dr. Uwe Brinkschulte

  18. 3.1 Observer/Controller Architekturen Ergebnis M = 2.47 ZieleschnelleErforschung Observer Controller Beobachtung Roboterposition KontrolleRegeländerung SuOC Ausgabegeeignete Stützpunkt-Koordinaten EingabeDruck, Temperatur, Strahlung ZustandPosition, Bewegung, … Im Beispiel Organic Computing – Teil 3a, Folie 18 - Prof. Dr. Uwe Brinkschulte

  19. 3.1 Observer/Controller Architekturen Ergebnis M = 0.83 ZieleschnelleErforschung Observer Controller Beobachtung Roboterposition Kontrollealles wieder ok SuOC Ausgabegeeignete Stützpunkt-Koordinaten EingabeDruck, Temperatur, Strahlung ZustandPosition, Bewegung, … Im Beispiel Organic Computing – Teil 3a, Folie 19 - Prof. Dr. Uwe Brinkschulte

  20. 3.1 Observer/Controller Architekturen M eigenständiges Verhalten des SuOC Schwellwert t M Controller greift ein Schwellwert Verhalten des SuOC mit Observer/Controller t Observer beobachtet Organic Computing – Teil 3a, Folie 20 - Prof. Dr. Uwe Brinkschulte

  21. 3.1 Observer/Controller Architekturen Selbstorganisierendes System mit Observer/Controller Architektur Ziele Ergebnis Observer Controller Beobachtung Kontrolle SuOC Eingabe Ausgabe Zustand Organic Computing – Teil 3a, Folie 21 - Prof. Dr. Uwe Brinkschulte

  22. 3.1 Observer/Controller Architekturen • Einige Anmerkungen zum Zusammenspiel von Observer und Controller: • Je nach Implementierung kann mehr Funktionalität in den Observer oder Controller gelegt werden • Der Observer kann die beobachteten Informationen mehr oder weniger bearbeitet an den Controller geben (Aggregation) • Der Controller kann hierbei auch Art und Grad der Aggregation steuern • Er ändert somit das Beobachtungsmodell des Observers • Er kann dadurch je nach gerade aktuellen Zielen die relevanten Daten auswählen Organic Computing – Teil 3a, Folie 22 - Prof. Dr. Uwe Brinkschulte

  23. 3.1 Observer/Controller Architekturen Selbstorganisierendes System mit Observer/Controller Architektur Ziele Ergebnis Ergebnis Observer Observer Controller Controller Beobachtungsmodell Beobachtungsmodell Beobachtung Beobachtung Kontrolle Kontrolle SuOC SuOC Eingabe Eingabe Ausgabe Ausgabe Zustand Zustand Organic Computing – Teil 3a, Folie 23 - Prof. Dr. Uwe Brinkschulte

  24. 3.1 Observer/Controller Architekturen • Das Beobachtungsmodell ist hierbei verantwortlich für: • die Auswahl der Daten-Attribute, welche beobachtet werden (z.B. eine kleine Auswahl oder die vollständige Menge) • die Auswahl geeigneter Analyse-Techniken und Methoden je nach den gegebenen Zielen (in unserem Beispiel: Minimierung der Emergenz bei schneller Erforschung, Maximierung der Emergenz bei genauer Untersuchung einzelner Punkte im Gelände) • die Auswahl geeigneter Vorhersagemodelle (z.B. lineare Vorhersage) Organic Computing – Teil 3a, Folie 24 - Prof. Dr. Uwe Brinkschulte

  25. 3.1 Observer/Controller Architekturen Exemplarischer Aufbau eines Observers1): • Monitor: • Beobachtet die gegenwärtige Situation • Sammelt Rohdaten gemäß dem aktuellen Beobachtungsmodell (Attribute, Abtastperiode, …) • Log: • Speichert die beobachteten Daten (z.B. für spätere Analyse, Vorhersage, …) Monitor Log Rohdaten Zeit Abtastperiode Rohdaten 1)nach Müller-Schloer/Schmeck Organic Computing – Teil 3a, Folie 25 - Prof. Dr. Uwe Brinkschulte

  26. 3.1 Observer/Controller Architekturen Exemplarischer Aufbau eines Observers: • Präprozessor: • Führt einige Vorbearbeitungen durch (z.B. Filter) • Berechnet neue Attribute Rohdaten Zeit Präprozessor Abtastperiode Filter Monitor Log Geglättete Daten Rohdaten Abtastperiode Zeit Organic Computing – Teil 3a, Folie 26 - Prof. Dr. Uwe Brinkschulte

  27. 3.1 Observer/Controller Architekturen Exemplarischer Aufbau eines Observers: • Analysator: • Wendet eine Reihe von Detektoren auf die vorverarbeiteten Daten an • Erkennt Muster in Zeit und Raum wie z.B. Cluster, statistische Werte, emergente Effekte (was immer gerade relevant ist) Analysator (Erkennung von Mustern in Zeit und Raum, verschiedene Emergenz-Detektoren, …) Präprozessor Monitor Log Rohdaten Organic Computing – Teil 3a, Folie 27 - Prof. Dr. Uwe Brinkschulte

  28. 3.1 Observer/Controller Architekturen Exemplarischer Aufbau eines Observers: • Vorhersage: • Betrachtet Daten des Prä- prozessors und Analysators über ein Zeitfenster • Macht Mustervorhersagen • Dies reduziert die Reaktionszeit des Observers und erlaubt proaktive Kontrolle Analysator (Erkennung von Mustern in Zeit und Raum, verschiedene Emergenz-Detektoren, …) Vorhersage (Vorhersage von Mustern in Zeit und Raum) Präprozessor Vorhersage Monitor Log Daten Zeit Rohdaten Zeitfenster jetzt Organic Computing – Teil 3a, Folie 28 - Prof. Dr. Uwe Brinkschulte

  29. 3.1 Observer/Controller Architekturen Exemplarischer Aufbau eines Observers: Aggregator Aggregierte Daten für den Controller Analysator (Erkennung von Mustern in Zeit und Raum, verschiedene Emergenz-Detektoren, …) Vorhersage (Vorhersage von Mustern in Zeit und Raum) • Aggregator: • aggregiert die Daten des Präprozessors, Analysators und der Vorhersage • filtert und bewertet die Ergebnisse und sendet sie an den Controller Präprozessor Monitor Log Rohdaten Organic Computing – Teil 3a, Folie 29 - Prof. Dr. Uwe Brinkschulte

  30. 3.1 Observer/Controller Architekturen Exemplarischer Aufbau eines Observers: Aggregator Aggregierte Daten für den Controller Analysator (Erkennung von Mustern in Zeit und Raum, verschiedene Emergenz-Detektoren, …) Vorhersage (Vorhersage von Mustern in Zeit und Raum) Das vom Controller gewählte Be-obachtungsmodell beeinflusst die ein-zelnen Komponenten (z.B. Wahl von Attributen, Emergenzdetektoren, …) Präprozessor Beobachtungsmodell Monitor Log Rohdaten Organic Computing – Teil 3a, Folie 30 - Prof. Dr. Uwe Brinkschulte

  31. 3.1 Observer/Controller Architekturen Exemplarischer Aufbau eines Controllers: Ziele Aktionsauswahl (Abbildung Bedingung –> Regel -> Aktion) Ziele, Systemstatus Aggr.Daten • Aktionsauswahl: • wählt aufgrund der empfang- enen Daten und Ziele eine Aktion aus • schnelle Reaktion in Echtzeit Beob.-modell Regeln Aktion Bedingungen Aktionen Organic Computing – Teil 3a, Folie 31 - Prof. Dr. Uwe Brinkschulte

  32. 3.1 Observer/Controller Architekturen Exemplarischer Aufbau eines Controllers: Ziele Aktionsauswahl (Abbildung Bedingung –> Regel -> Aktion) Ziele, Systemstatus Aggr.Daten • Online-Lernen: • Die Aktionen und daraus resultierenden Situationen werden evaluiert • Damit werden die Abbildungsregeln angepasst • Durch die Evaluation vergangener Aktionen wird die „Fitness“ der einzelnen Regeln dynamisch geändert, um bessere zukünftige Aktionen zu erhalten Online-Lernen Anpassung Beob.-modell Aktion Organic Computing – Teil 3a, Folie 32 - Prof. Dr. Uwe Brinkschulte

  33. 3.1 Observer/Controller Architekturen Exemplarischer Aufbau eines Controllers: Ziele Aktionsauswahl (Abbildung Bedingung –> Regel -> Aktion) Ziele, Systemstatus Aggr.Daten • Offline-Lernen: • erzeugt neue Regeln und simuliert deren Auswirkungen • Hierbei werden entweder bestehende Regeln verändert oder gänzlich neue generiert • Regeln, die sich in der Simulation als nützlich erweisen, werden in die Aktionsauswahl übernommen Online-Lernen Anpassung Simulation Offline-Lernen Beob.-modell Aktion Organic Computing – Teil 3a, Folie 33 - Prof. Dr. Uwe Brinkschulte

  34. 3.1 Observer/Controller Architekturen Varianten von Observer/Controller Architekturen Zentral: ein Observer/Controller für das gesamte System. Das gesamte System ist selbstgemanaged, Teile davon (das SuOC) können auch selbstorganisierend sein Organic Computing – Teil 3a, Folie 34 - Prof. Dr. Uwe Brinkschulte

  35. 3.1 Observer/Controller Architekturen Varianten von Observer/Controller Architekturen Verteilt: ein Observer/Controller für jede Systemkomponente. Das gesamte System ist organisierend, unkontrollierte emergente Effekte im Gesamtsystem sind möglich Organic Computing – Teil 3a, Folie 35 - Prof. Dr. Uwe Brinkschulte

  36. 3.1 Observer/Controller Architekturen Varianten von Observer/Controller Architekturen Hierarchisch: ein Observer/Controller für jede Systemkompo- nente sowie für das Gesamtsystem. Kontrollierte Selbstorganisation Organic Computing – Teil 3a, Folie 36 - Prof. Dr. Uwe Brinkschulte

  37. 3.1 Observer/Controller Architekturen • Mögliche Aktionen des Controllers: • Beeinflussung der Struktur des Systems (Hardware-Rekonfiguration, Task-Verteilung, …) • Beeinflussung des Verhaltens von Komponenten (Software-Update, Prioritäten, Ziele, Fähigkeiten, …) • Beeinflussung der Kommunikation zwischen Komponenten und Umgebung (Botschaften, Nachbarschaftsbeziehungen, Bandbreiten, …) Organic Computing – Teil 3a, Folie 37 - Prof. Dr. Uwe Brinkschulte

  38. 3.2 Der MAPE Zyklus MAPE Zyklus (Monitor Analyze Plan Execute) Grundbestandteil von Autonomic Computing, vorgeschlagen von IBM Grundidee: Eigenschaften des autonomen Nervensystems auf die Wartung und den Betrieb von Serversystemen übertragen(z.B autonome Kontrolle des Herzschlags <=> autonome Kontrolle von Serverressourcen wie z.B. Warteschlangen, Kommunikation, …) Organic Computing – Teil 3a, Folie 38 - Prof. Dr. Uwe Brinkschulte

  39. 3.2 Der MAPE Zyklus Übertragung der Eigenschaften Organic Computing – Teil 3a, Folie 39 - Prof. Dr. Uwe Brinkschulte

  40. 3.2 Der MAPE Zyklus • Autonome Systeme (Autonomic Systems) bestehen aus einer interaktiven Ansammlung von autonomen Elementen (Autonomic Elements) • Autonome Elemente sind individuelle Systeme und • enthalten Ressourcen • stellen Dienste für den Menschen oder andere autonome Elemente bereit • enthalten anpassbare bzw. veränderbare Parameter • Ziel: Entlastung des Systemadministrators von der Aufgabe des Einstellens dieser Parameter, Erreichen der höchst möglichen Systemleistung Organic Computing – Teil 3a, Folie 40 - Prof. Dr. Uwe Brinkschulte

  41. 3.2 Der MAPE Zyklus • Autonome Elemente und damit autonome Systeme sollen selbstmanagend sein. Avisierte Selbst-X Eigenschaften: • Selbstkonfiguration • Selbstoptimierung • Selbstheilung • Selbstschutz Organic Computing – Teil 3a, Folie 41 - Prof. Dr. Uwe Brinkschulte

  42. 3.2 Der MAPE Zyklus Autonome Elemente bestehen üblicherweise aus einem gemanagten Element sowie einem Autonomic Manager Autonomic Manager Aktoren Sensoren Gemanagtes Element Das gemanagte Element kann sein: • eine einzelne Hardware-Ressource • eine einzelne Software-Ressource • eine Kombination aus beiden bis hin zu einer vollständigen Anwendung Organic Computing – Teil 3a, Folie 42 - Prof. Dr. Uwe Brinkschulte

  43. 3.2 Der MAPE Zyklus Das gemanagte Element • enthält einstellbare Parameter (ist managbar) • erlaubt eine Änderung dieser Parameter von außen mittels Aktoren (Hardware oder Software) • ermöglicht eine Beobachtung seines inneren Zustandes mittels Sensoren (Hardware oder Software) • Beispiel: Kommunikationskanal • Einstellbare Parameter: Bandbreite, Prioritäten der Botschaften, … • Änderung dieser Parameter durch Steuerbefehle • Beobachtung von Zustandsinformation: Kanalauslastung, Transportzeit der Botschaften, … Organic Computing – Teil 3a, Folie 43 - Prof. Dr. Uwe Brinkschulte

  44. 3.2 Der MAPE Zyklus Beispiel: Kommunikationskanal • Sensoren messen: • Kanalauslastung • Transportzeit • Fehlerrate • … • Aktoren beeinflussen: • Bandbreite • Übertragungsrate • Prioritäten • … Gemanagtes Element:Kommunikationskanal Botschaften Botschaften Organic Computing – Teil 3a, Folie 44 - Prof. Dr. Uwe Brinkschulte

  45. 3.2 Der MAPE Zyklus Autonomic Manager: automatisiert die Einstellungen der Parameter des gemanagten Systems Wesentliche Funktionen: Monitor: beobachten des gemanagtes Systems Analyze: Analyse der beobachteten Daten Plan: Planung geeigneter Maßnahmen Execute: Ausführung der geplanten Maßnahmen Knowledge: Wissen über gegenwärtige und vergangene Daten, Strategien, etc., um das System erfolgreich zu managen Autonomic Manager Analyze Plan Knowledge Monitor Execute Sensoren Aktoren Gemanagtes Element Organic Computing – Teil 3a, Folie 45 - Prof. Dr. Uwe Brinkschulte

  46. Beispiel: Kommunikationskanal 3.2 Der MAPE Zyklus Aktuelle Parameter des Kanals: Sender 1: Priorität hoch Sender 2: Priorität niedrig Autonomic Manager Analyze Plan Knowledge Monitor Execute Sensoren Aktoren Kommunikationskanal Organic Computing – Teil 3a, Folie 46 - Prof. Dr. Uwe Brinkschulte

  47. Monitor: 3.2 Der MAPE Zyklus Sender 1: Botschaft 1, 4 Pakete1), tSende= 3, tEmpf = 3 Botschaft 2, 4 Pakete, tSende= 9, tEmpf = 9 Autonomic Manager Sender 2: Botschaft 1, 1 Paket1), tSende= 1, tEmpf = 4 Botschaft 2, 1 Paket, tSende= 6, tEmpf = 10 Analyze Plan Knowledge Monitor Execute Sensoren Aktoren Kommunikationskanal 1) tSende, tEmpf bezieht sich auf das jeweils letzte Paket der Botschaft Organic Computing – Teil 3a, Folie 47 - Prof. Dr. Uwe Brinkschulte

  48. Analyze: 3.2 Der MAPE Zyklus Sender 1: Botschaft 1, 4 Pakete, tTransport = 0 Botschaft 2, 4 Pakete, tTransport = 0 Kanalauslastung: 8/11 Autonomic Manager Sender 2: Botschaft 1, 1 Paket, tTransport= 3 Botschaft 2, 1 Paket, tTransport= 4 Kanalauslastung: 2/11 Analyze Plan Knowledge Monitor Execute Sensoren Aktoren Kommunikationskanal Kanalauslastung: 10/11 Organic Computing – Teil 3a, Folie 48 - Prof. Dr. Uwe Brinkschulte

  49. Plan: 3.2 Der MAPE Zyklus Autonomic Manager Analyze Plan Knowledge Monitor Execute Sensoren Aktoren Kommunikationskanal Knowledge: Kurze Botschaften mit niedriger Auslastung profitieren von höherer Priorität, ohne andere wesentlich zu stören => Plan: Tausch der Prioritäten Organic Computing – Teil 3a, Folie 49 - Prof. Dr. Uwe Brinkschulte

  50. Execute: 3.2 Der MAPE Zyklus Geänderte Parameter des Kanals: Sender 1: Priorität niedrig Sender 2: Priorität hoch Autonomic Manager Analyze Plan Knowledge Monitor Execute Sensoren Aktoren Kommunikationskanal Organic Computing – Teil 3a, Folie 50 - Prof. Dr. Uwe Brinkschulte

More Related