Teil 4 Anwendungen

1. Aktuelle Themen bei Eingebetteten Systemen – Organic Computing SS 2010 Prof. Dr. Uwe Brinkschulte Teil 4 Anwendungen Organic Computing – Teil 4, Folie 1 - Prof. Dr. Uwe Brinkschulte

2. 4. Anwendungen 4.1 CAR-SoC und CARISMA 4.2 ASoC 4.3 DodOrg und AHS 4.4 Organic Traffic Control 4.5 Testen in selbstorganisierenden Dienstumgebungen Organic Computing – Teil 4, Folie 2 - Prof. Dr. Uwe Brinkschulte

3. 4.1 CAR-SoC und CARISMA CAR-SoC (Connective Autonomic Real-Time System on Chip) System on Chip Architektur, welche Prinzipien des Organic/Autonomic Computing nutzt: Connective: Mehrere SoC Knoten verbinden sich selbsttätig zu einem verteilten System Autonomic: Das System verfügt über Selbst-X Eigenschaften Real-Time: Das System ist echtzeitfähig (Ungerer - Univ. Augsburg, Brinkschulte - Uinv.Frankfurt) Organic Computing – Teil 4, Folie 3 - Prof. Dr. Uwe Brinkschulte

4. 4.1 CAR-SoC und CARISMA Systemarchitektur Organic Computing – Teil 4, Folie 4 - Prof. Dr. Uwe Brinkschulte

5. 4.1 CAR-SoC und CARISMA • Funktionsmechanismen • Mehrfädiger Prozessor- kern (SMT) • Echtzeit- scheduling • lokale und globale Regel- kreise für Organic Management • dezentrale Regelkreise (Univ. Augsburg, Karlsruhe, Frankfurt) Organic Computing – Teil 4, Folie 5 - Prof. Dr. Uwe Brinkschulte

6. 4.1 CAR-SoC und CARISMA CARSoC Hardware(CarCoreund Peripherie) Echtzeitfähige Ausführung einermehrfädigen Last Zweistufiges Echtzeit-Scheduling in Hardware Stufe 1: einfacherprioriätsbasierterEchtzeitscheduler Stufe 2: komplexerPrioritätsmanager Organic Computing – Teil 4, Folie 6 - Prof. Dr. Uwe Brinkschulte

7. 4.1 CAR-SoC und CARISMA • Die CAR-SoC Hardware besitzt keine besonderen Eigenschaften zur Realisierung der Selbst-X Eigenschaften • Diese werden hier auf drei Ebenen in Software realisiert • CAROS (Betriebsystem) • Untere Ebene (Reflex-Ebene) • Mittlere Ebene (lokale Planungebene) • CARISMA (Middleware) • Obere Ebene (globale Planungsebene) Organic Computing – Teil 4, Folie 7 - Prof. Dr. Uwe Brinkschulte

8. 4.1 CAR-SoC und CARISMA • Untere Ebene (Reflex-Ebene) • Einfache Management Einheiten (Modul-Manager) beobachten das Verhalten eines Threads oder einer Funktionseinheit (z.B. Spannungsversorgung) • Diese realisieren einen vereinfachten MAPE-Zyklus • Basierend auf einem festen statischen Regelsatz wird das Systemverhalten angepasst • Beispiel: Batteriespannung < 70% -> Taktfrequenzreduktion um 30% • Schnelles, reaktives Verhalten • Einfache Anpassungsaufgaben Organic Computing – Teil 4, Folie 8 - Prof. Dr. Uwe Brinkschulte

9. 4.1 CAR-SoC und CARISMA • Mittlere Ebene (Lokale Planungsebene) • Ist die untere Ebene nicht in der Lage, ein Problem zu lösen, greift die mittlere Ebene ein • Diese realisiert einen vollständigen MAPE-Zyklus auf dem Chip • Es werden Learning Classifier Systems benutzt, um komplexe, dynamische Planungsaufgaben durchführen zu können. • Hierzu werden die Informationen von allen einfachen Management-Einheiten zusammengeführt • Beispiel einer komplexeren kombinierten Planungskette: Chiptemperatur > 70° -> Taktfrequenzreduktion um 30% -> Thread würde Zeitschranke verpassen -> Erhöhung der Threadpriorität Organic Computing – Teil 4, Folie 9 - Prof. Dr. Uwe Brinkschulte

10. 4.1 CAR-SoC und CARISMA Lokale Planungsebene Reflex-Ebene(Modul-Manager) Organic Computing – Teil 4, Folie 10 - Prof. Dr. Uwe Brinkschulte

11. 4.1 CAR-SoC und CARISMA • Obere Ebene (Globale Planungsebene) • Ist die mittlere Ebene nicht in der Lage, ein Problem zu lösen, greift die obere Ebene ein • Diese besitzt globales Wissen über das gesamte System verteilter CAR-SoC Knoten • Basierend auf Auktionsmechanismen und Dienst Agenten (Service Agents) werden die Aufgaben je nach Eignung und aktueller Situation den Knoten zugewiesen • Beispiel: Chiptemperatur > 70° -> Taktfrequenzreduktion um 30% -> Thread würde Zeitschranke verpassen -> Erhöhung der Threadpriorität -> anderer Thread würde Zeitschranke verpassen -> Verlagerung dieses Threads auf anderen Knoten Organic Computing – Teil 4, Folie 11 - Prof. Dr. Uwe Brinkschulte

12. 4.1 CAR-SoC und CARISMA Grundlegende Architektur der Middleware CARISMA Dienstbasierte Architektur • Mikrokern • Dienste übernehmendie Funktionalität • Dienste sind unabhängigelose gekoppelte Einheiten • Sie agieren als mobileintelligente Agenten(Service Agents)

13. 4.1 CAR-SoC und CARISMA Verteilung der Dienst-Agenten mittels Auktionen (ContractNet Protokoll) Dienste bewegen sich nach Bedarf zwischen den Knoten Die Auktion basiert auf Kosten/Nutzen-Funktionen 1. Die Anwendung sendet Aufträge 2. Die Dienst-Agenten bieten für die Aufträge

14. 4.1 CAR-SoC und CARISMA Verteilung der Dienst-Agenten mittels Auktionen (ContractNet Protokoll) 3. Der Agent mit dem höchsten Gebot erhält den Zuschlag 4. Der Agent sendet das Ergebnis des Auftrags an die Anwendung

15. 4.1 CAR-SoC und CARISMA Echtzeitaspekte: • Vorgabe eines Zeitlimits für die Auktion • Angebote nach Verstreichen des Zeitlimits werden ignoriert => obere Zeitschranke für die Zuteilung kann angegeben werden => möglicherweise suboptimale Lösung Organic Computing – Teil 4, Folie 15 - Prof. Dr. Uwe Brinkschulte

16. 4.1 CAR-SoC und CARISMA Die Berechnung von Kosten und Nutzen für die Auktionen bedürfen einer Grundlage Abhängigkeiten und Eignungen müssen berücksichtigt werden Dieser Mechanismus muss generisch sein, da viele Abhängigkeiten und Eignungen anwendungsspezifisch sine Er muss in der Lage sein, Knotenkonfigurationen (verfügbare Sensoren, Aktoren, Dienste, …) zu erfassen Er muss transparent sein, d.h. die Anwendung braucht nicht zu wissen, wo ein Dienst gerade ausgeführt wird • Capabilities Organic Computing – Teil 4, Folie 16 - Prof. Dr. Uwe Brinkschulte

17. 4.1 CAR-SoC und CARISMA Capability-Mechanismus • Eine Capability C ist ein global eindeutiger, eventuell anwendungsspezifischer Bezeichner • Sie repräsentiert eine bestimmte Eigenschaft oder Fähigkeit • Hardware Ressourcen bieten eine Menge von Capabilities • Agenten benötigen eine Menge von Capabilities, um auf einem Knoten zu laufen oder einen bestimmten Dienst zu erbringen • Laufende Agenten können weitere Capabilities anbieten • Dies ermöglich die Beschreibung von Abhängigkeiten zwischen Agenten (ein Agent wird z.B. nur auf einem Knoten gestartet, wenn dort bereits ein andere Agent einen bestimmten Dienst erbringt)

18. 4.1 CAR-SoC und CARISMA Ein Beispiel

19. 4.1 CAR-SoC und CARISMA Ein BeispielHeadlight Control benötigt Capability HEADLIGHT bietet Capability ILLUMINATE zu Kosten 0 bietet Capability SIGNAL zu Kosten 100(Blinken mit dem Hauptscheinwerfer ist ungünstig) Foglight Control benötigt Capability FOGLIGHT bietet Capability ILLUMINATE zu Kosten 100 bietet Capability SIGNAL zu Kosten 50(Kann besser Blinken als der Hauptscheinwerfer, aber schlechter Beleuchten) Turnsignal Control Left benötigt Capabilities TURNSIGNAL & LEFT bietet Capability ILLUMINATE zu Kosten 500 bietet Capability SIGNAL zu Kosten 0(Ideal zum Blinken, sehr schlecht zum Beleuchten)

20. 4.1 CAR-SoC und CARISMA Formal:Es sei die Menge der angebotenen Capabilities eine Hardware Ressource r  R Es sei die Menge der angebotenen Capabilities eines Dienst-Agenten a  A1,A1 : Menge der ausgeführten Dienstagenten Es sei die Menge der benötigten Capabilities eines Dienst-Agenten a  A0, A0 : Menge der nicht ausgeführten Dienst-Agenten Dann kann ein Dienstagent b  A0 auf der Ressource r  R ausgeführt werden, wenn gilt:

21. 4.1 CAR-SoC und CARISMA Implementierung von Capabilities als Bitstrings • Mengen-Operation → Bitstring-Operation • S  T → s OR t • S – T → s AND NOT t • T  S ? → (s AND t) = t ? • Effiziente Speicherung • Bitstring Operationen können in konstanter Zeit durchgeführt werden (kein Suchen) • Kosten können als Integer-Werte an Capabilities angehängt werden • Komplexere Alternative: Baumstruktur mit eigenen Namensräumen, flexibler als Bitstrings, aber aufwendiger und langsamer

22. 4.1 CAR-SoC und CARISMA Interaktion von CARISMA und CAROS • Dienst-Agenten des Hardware Abstraction Layer (HAL) von CARISMA registrieren sich als Modul-Manager von CAROS • Diese leisten die Umsetzung von Knoten-Eigen-schaften in Capabilities und Kosten

23. 4.2 ASoC • Autonomic Systems on Chip (ASoC) • Problem: hohe Integrationsdichten verursachen zunehmend transiente Fehler während des Betriebs • Idee: 2 Ebenen • Funktionale Ebene: Eigentliche Chip-Funktionalität • Autonomic Ebene: Überwachung der funktionalen Ebene (Herkersdorf - Univ. München, Rosenstil - Univ Tübingen, Brinkmann - FZI Karlsruhe) Organic Computing – Teil 4, Folie 23 - Prof. Dr. Uwe Brinkschulte

24. 4.2 ASoC MAPE Zyklus mit Learning Classifier Systems größtenteils in Hardware realisiert Aktualisierung der Regeln mittels genetischer Algorithmen in Software Organic Computing – Teil 4, Folie 24 - Prof. Dr. Uwe Brinkschulte

25. 4.2 ASoC Zusätzlich fehlertoleranter CPU Datenpfad durch Verwendung von Shadow-Registern => Entdeckung von transienten Fehlern Organic Computing – Teil 4, Folie 25 - Prof. Dr. Uwe Brinkschulte

26. 4.2 ASoC • Entwurfsprozess: • Abbildung der Anwendungs- anforderungen auf die Architektur-Charakteristiken • Auswahl der funktionalen Elemente • Auswahl dazu passender Autonomic Elemente • Parametrierung der Elemente • Ableitung eines Modells zur Systemevaluation • Fortlaufende Verfeinerung Organic Computing – Teil 4, Folie 26 - Prof. Dr. Uwe Brinkschulte

27. 4.3 DoDOrg und AHS Digital on Demand Real-Time Organism (DoDOrg) Rechnerarchi-tektur, die sichan biologischen Systemenorientiert (Becker, Henkel, Karl - KIT, Brinkschulte - Univ. Frankfurt) Organic Computing – Teil 4, Folie 27 - Prof. Dr. Uwe Brinkschulte

28. 4.3 DoDOrg und AHS • DodOrg-Komponenten • Anwendung • Middleware • Monitoring • Power Management • Prozessorzellen Organic Computing – Teil 4, Folie 28 - Prof. Dr. Uwe Brinkschulte

29. Application Hardware Status Status Requirements Monitoring Raw & Cooked Data Feedback Configuration Middleware Low-Power Planning 4.3 DoDOrg und AHS Monitoring • Grundlage jeglicher Selbst-X Eigenschaften • Beständige Überwachung des Systems • Überwachung auf allen Ebenen (Hardware und Software) • Korrelation von Ereignissen und Reaktionen • Proaktive Erkennung von kritischen Situationen Organic Computing – Teil 4, Folie 29 - Prof. Dr. Uwe Brinkschulte

30. 4.3 DoDOrg und AHS Monitoring • Jede Prozessorzelle (Organic Processing Cell, OPC) enthält ein Monitoring Modul (MM) • Dieses sammelt Daten über denaktuellen Zustand der Zelle • Spezielle Prozessorzellen (Monitoring Cells) werten diese Informationen aus und leiten aufbereitete Daten an Middleware und Power Management Organic Computing – Teil 4, Folie 30 - Prof. Dr. Uwe Brinkschulte

31. 4.3 DoDOrg und AHS Monitoring • Um dynamisch Ereignisse und Gruppen von Ereignissen zu behandeln, werden diese strukturiert • So können auch zur Laufzeit neue Ereignisse hinzugefügt werden • Über Masken können Klassen von Ereignissen spezifiziert werden • Prinzip ähnlich der Maskierung von Botenstoffen in der Biologie Organic Computing – Teil 4, Folie 31 - Prof. Dr. Uwe Brinkschulte

32. FPGA Cell N N Configuration Cache Configuration Cache Configuration Cache Configuration Cache E E Noc artNoc Router Router S S Channel Channel Configuration Configuration Allocation/Release Allocation/Release W W State Interface State Interface State Interface State Interface Configuration Configuration Configuration Configuration Cell Cell - - Specific Specific L L Low Level Monitoring Low Level Monitoring Messenger Messenger Control Control Control Control Functionality Functionality ( ( ? Proc µProc, DSP, , DSP, Power Status Power Status FPGA,FPFA, FPGA, Network Interface Network Interface Power Control Power Control Monitor Status Monitor Status Memory, Memory, Observer Control Observer Control Monitoring, Monitoring, Clk Clk Clk Clk local local global global etc.) etc.) Clock and Power Clock and Power Clock and Power Monitoring Data Monitoring Data Emergency Calls Emergency Calls Management (DVFS) Management (DVFS) Management (DVFS) Observer Observer Cell Data path Cell Data path 4.3 DoDOrg und AHS Prozessorzellen Heterogeneous Array of Organic Processing Cells (OPCs) OPC with common structure but with specific functionality FPGA DSP I/O Cell Cell Cell Memory Monitor Cell Cell • Noc • broadcast • real time • adaptive routing FPGA µ Proc I/O Cell Cell Cell Peripheral Devices Organic Computing – Teil 4, Folie 32 - Prof. Dr. Uwe Brinkschulte

33. 4.3 DoDOrg und AHS • Prozessorzellen • Grid unterschiedlicher Zellen • Monitoring Zellen, Ein-Ausgabe-Zellen, CPU-Zellen, Signalprozessor-Zellen, FPGA-Zellen, … • FPGA-Zellen können sich rekonfigurieren und an Aufgaben anpassen • Die aktuelle Ausprägung einer Zelle wird ähnlich der DNA in einem Konfigurations-Speicher aufbewahrt Organic Computing – Teil 4, Folie 33 - Prof. Dr. Uwe Brinkschulte

34. 4.3 DoDOrg und AHS • Middleware • Hier wird das bereits ausführlich beschrieben künstliche Hormonsystem (Artificial Hormone System, AHS) verwendet • Es verteilt zusammen- gehörige Aufgaben gemäß Eignung und Monitoring- Daten auf die Prozessorzellen • => Ausbildung virtueller Organe Organic Computing – Teil 4, Folie 34 - Prof. Dr. Uwe Brinkschulte

35. 4.3 DoDOrg und AHS Middleware Organic Computing – Teil 4, Folie 35 - Prof. Dr. Uwe Brinkschulte

36. Power source Organic Middleware Energy Input Influencing Hormone Expression Assigned Tasks Cost Function Energy level Temperature Local traffic Efficiency RT criteria Trade & Negotiate Future energy level Actual energy level Energy Budget Manager Power / RT Manager Actual power state Peers (in neighbored OPCs) Organic Monitoring Policy Fill Consume Local Energy Budget Fade Power States P1 P2 P3 Voltage / frequency setting Scheduled Tasks P4 Legend: data / information actions OPC 4.3 DoDOrg und AHS Power Management • Beeinflusst aus dem momentanen Energie-Zustand und zusätzlichen Informationen aus dem Monitoring (Temperatur, …) den Eignungswert (Hormon) einer Zelle für eine Aufgabe • Organisiert das zeitliche Scheduling der von der Middleware zugeteilten Tasks mit dem Ziel der Minimierung des Energieverbrauchs bei Einhaltung der Zeitbedingungen • Konfiguriert den Energiezustand (Spannung, Frequenz) der Prozessorzellen Organic Computing – Teil 4, Folie 36 - Prof. Dr. Uwe Brinkschulte

37. Power source Organic Middleware Energy Input Influencing Hormone Expression Assigned Tasks Cost Function Energy level Temperature Local traffic Efficiency RT criteria Trade & Negotiate Future energy level Actual energy level Energy Budget Manager Power / RT Manager Actual power state Peers (in neighbored OPCs) Organic Monitoring Policy Fill Consume Local Energy Budget Fade Power States P1 P2 P3 Voltage / frequency setting Scheduled Tasks P4 Legend: data / information actions OPC 4.3 DoDOrg und AHS Power Management • Gewährt den einzelnen Prozessorzellen ihr Energiebudget • Die zur Verfügung stehende Energiequelle bestimmt das Gesamtbudget • Jede Zelle erhält hieraus ein lokales Budget • Sie kann dieses Budget mit Nachbarzellen verhandeln, d.h. Teile ihres Budgets an Nachbarzellen abgeben oder von dort zusätzliche Energie erhalten • Ziel: Vermeidung von Hotspots, Reduktion des Energieverbrauchs Organic Computing – Teil 4, Folie 37 - Prof. Dr. Uwe Brinkschulte

38. 4.3 DoDOrg und AHS Anwendung Fahrerloses Transport-system (wie in der bereits gezeigten Simulation auch schon zur Einzelevaluation des AHS genutzt Organic Computing – Teil 4, Folie 38 - Prof. Dr. Uwe Brinkschulte

39. 4.4 Organic Traffic Control • Steuerung eines Netzwerks von Ampel-gesteuerten Kreuzungen nach organischen Prinzipien • Kein zentraler Rechner, welcher die Kreuzungen steuert • Interaktion der einzelnen Kreuzungen im Netz mit verschiedenen Zielen: • Geringste Verzögerung • Geringste Anzahl von Stopps (Schmeck - KIT, Müller-Schloer - Univ. Hannover) Organic Computing – Teil 4, Folie 39 - Prof. Dr. Uwe Brinkschulte

40. 4.4 Organic Traffic Control Observer/Controller-Architektur mit Learning Classifier Systems (LCS) und genetischen Algorithmen (GA) Organic Computing – Teil 4, Folie 40 - Prof. Dr. Uwe Brinkschulte

41. 4.4 Organic Traffic Control Veränderung der Rot/Grünphasen einer lokalen Ampel gemäß LCS, Veränderung der Regeln mittels GA Organic Computing – Teil 4, Folie 41 - Prof. Dr. Uwe Brinkschulte

42. 4.4 Organic Traffic Control Benutzer: Definition der Ziele Layer 2: Off-Line Parameter-Optimierung Simulation, GA erzeugt TLC Parameter Layer 1: On-Line Parameter-Optimierung Observer beobachtet Verkehr, LCS wählt TLC Parameter und gewichtet Regeln TLC: Standard System Feste Zeiten, adaptierbar Organic Computing – Teil 4, Folie 42 - Prof. Dr. Uwe Brinkschulte

43. 4.4 Organic Traffic Control LCS zur On-Line Parameterauswahl TLCXX: Parametersatz (Zeiten) des Standartcontrollers, Pred: vorhergesagte Verzögerung Organic Computing – Teil 4, Folie 43 - Prof. Dr. Uwe Brinkschulte

44. 4.4 Organic Traffic Control GA zur Off-Line Parameterauswahl Im Gegensatz zu klassischen LCS werden hier keine neuen Regeln generiert, sondern basierend auf Simulationen die Parameter weiter optimiert Organic Computing – Teil 4, Folie 44 - Prof. Dr. Uwe Brinkschulte

45. 4.4 Organic Traffic Control Ergebnisse einer Kreuzung in Hamburg(Simulation basierend auf Daten von einem Verkehrszensus, Referenz: Standard Controller mit festen Zeiten) Verbesserung durch den Organic Computing Ansatz Tag 1: 11,7%, Tag 2: 11,6%, Tag 3: 12,2% Organic Computing – Teil 4, Folie 45 - Prof. Dr. Uwe Brinkschulte

46. 4.5 Testen in selbstorgani-sierenden Dienstumgebungen • Problemstellung: die Güte und Verfügbarkeit von Diensten in selbstorganisierenden Umgebungen muss überprüft und bewertet werden • Testen dieser Dienste Geeignete Testfälle und Testsätze (Menge von Testfällen) müssen bereit gestellt werden, um die Leistungsfähigkeit und Fehlerfreiheit von Diensten zu bewerten Idee: Initiale Testsätze Weiterentwicklung dieser Testsätze durch genetische Algorithmen (Brinkschulte - Univ. Frankfurt) Organic Computing – Teil 4, Folie 46 - Prof. Dr. Uwe Brinkschulte

47. 4.5 Testen in selbstorgani-sierenden Dienstumgebungen Architektur: Organic Computing – Teil 4, Folie 47 - Prof. Dr. Uwe Brinkschulte

48. 4.5 Testen in selbstorgani-sierenden Dienstumgebungen Qualitätseigenschaften von Diensten (Quality of Service, QoS) werden hierzu in verschiedene Kategorien eingeteilt Diesen Kategorien werden dann geeignete Testfälle bzw. Testsätze zugeordnet Beispiel: Organic Computing – Teil 4, Folie 48 - Prof. Dr. Uwe Brinkschulte

49. 4.5 Testen in selbstorgani-sierenden Dienstumgebungen • Gewinnung initialer Testfälle bzw. Testsätze • Dienste liefern zu den jeweiligen Kategorien gehörende Testfälle • Das Testsystem beobachtet die Kommunikation mit Diensten und wählt Eingaben als Testfälle aus • Zufällige Generierung von Testfällen • Die Testfälle werden in zur jeweiligen Kategorie gehörenden Pools gesammelt • Daraus werden zufällig Testsätze zusammengestellt Organic Computing – Teil 4, Folie 49 - Prof. Dr. Uwe Brinkschulte

50. 4.5 Testen in selbstorgani-sierenden Dienstumgebungen Beispiel: Dienst A liefert die Eingabe 0011101010 (= berechne 52) als Testfall für Antwortzeit Dienst B liefert die Eingabe 0111101011 (= berechne ln(5)) als Testfall für Genauigkeit Das Testsystem wählt die zufällige Eingabe 10011011 als Testfall für die Reaktionsfähigkeit des Dienstes C … Organic Computing – Teil 4, Folie 50 - Prof. Dr. Uwe Brinkschulte