4.1 CAR-SoC und CARISMA
Werbung
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 Hier wird Wissen Wirklichkeit 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 Hier wird Wissen Wirklichkeit 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 Hier wird Wissen Wirklichkeit 4.1 CAR-SoC und CARISMA Systemarchitektur CARISMA Middleware Self-X Layer 3 CAROS Operating System Self-X Layers 1 & 2 CAROS Operating System Self-X Layers 1 & 2 CARCore SMT Processor Core Memory & Peripherals ... CARCore SMT Processor Core Memory & Peripherals CAR-SoC Node CAR-SoC Node Communication Network Organic Computing – Teil 4, Folie 4 - Prof. Dr. Uwe Brinkschulte Hier wird Wissen Wirklichkeit 4.1 CAR-SoC und CARISMA Funktionsmechanismen o Mehrfädiger Prozessorkern (SMT) Echtzeitscheduling lokale und globale Regelkreise für Organic Management dezentrale Regelkreise (Univ. Augsburg, Karlsruhe, Frankfurt) Organic Computing – Teil 4, Folie 5 - Prof. Dr. Uwe Brinkschulte Hier wird Wissen Wirklichkeit 4.1 CAR-SoC und CARISMA CARSoC Hardware (CarCore und Peripherie) Echtzeitfähige Ausführung einer mehrfädigen Last Zweistufiges EchtzeitScheduling in Hardware Stufe 1: einfacher prioriätsbasierter Echtzeitscheduler Stufe 2: komplexer Prioritätsmanager Organic Computing – Teil 4, Folie 6 - Prof. Dr. Uwe Brinkschulte Hier wird Wissen Wirklichkeit 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 Hier wird Wissen Wirklichkeit 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 Hier wird Wissen Wirklichkeit 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 Hier wird Wissen Wirklichkeit 4.1 CAR-SoC und CARISMA Lokale Planungsebene Reflex-Ebene (Modul-Manager) Organic Computing – Teil 4, Folie 10 - Prof. Dr. Uwe Brinkschulte Hier wird Wissen Wirklichkeit 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 Hier wird Wissen Wirklichkeit 4.1 CAR-SoC und CARISMA Grundlegende Architektur der Middleware CARISMA Dienstbasierte Architektur Mikrokern Dienste übernehmen die Funktionalität Dienste sind unabhängige lose gekoppelte Einheiten Sie agieren als mobile intelligente Agenten (Service Agents) Hier wird Wissen Wirklichkeit 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 Hier wird Wissen Wirklichkeit 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 Hier wird Wissen Wirklichkeit 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 Hier wird Wissen Wirklichkeit 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 Hier wird Wissen Wirklichkeit 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) Hier wird Wissen Wirklichkeit 4.1 CAR-SoC und CARISMA Ein Beispiel Hier wird Wissen Wirklichkeit 4.1 CAR-SoC und CARISMA Ein Beispiel Headlight 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) Hier wird Wissen Wirklichkeit 4.1 CAR-SoC und CARISMA Formal: prov Es sei S r die Menge der angebotenen Capabilities eine Hardware Ressource r R prov S Es sei a die Menge der angebotenen Capabilities eines DienstAgenten a A1, A1 : Menge der ausgeführten Dienstagenten req S Es sei a die Menge der benötigten Capabilities eines DienstAgenten 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: Sbreq ( S aprov S rprov ) a A1 rR Hier wird Wissen Wirklichkeit 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 Hier wird Wissen Wirklichkeit 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-Eigenschaften in Capabilities und Kosten Hier wird Wissen Wirklichkeit 4.2 ASoC Autonomic Systems on Chip (ASoC) o Problem: hohe Integrationsdichten verursachen zunehmend transiente Fehler während des Betriebs Autonomic Ebene AE AE AE ... o Idee: 2 Ebenen ... AE AE o Funktionale Ebene: Eigentliche Chip-Funktionalität o Autonomic Ebene: Überwachung der funktionalen Ebene AE Prozessorkern ROM ... Ein-/Ausgabe Prozessorkern RAM ... Netzwerk Funktionale Ebene AE (Autonomic Element) Schnittstelle Aktuator Evaluator Monitor (Herkersdorf - Univ. München, Rosenstil - Univ Tübingen, Brinkmann - FZI Karlsruhe) Organic Computing – Teil 4, Folie 23 - Prof. Dr. Uwe Brinkschulte Hier wird Wissen Wirklichkeit 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 Hier wird Wissen Wirklichkeit 4.2 ASoC Zusätzlich fehlertoleranter CPU Datenpfad durch Verwendung von ShadowRegistern => Entdeckung von transienten Fehlern Organic Computing – Teil 4, Folie 25 - Prof. Dr. Uwe Brinkschulte Hier wird Wissen Wirklichkeit 4.2 ASoC Entwurfsprozess: Architektur-Charakteristiken o Abbildung der Anwendungsanforderungen auf die Architektur-Charakteristiken Funktionale Elemente (FE) Autonomic Elemente (AE) o Auswahl der funktionalen Elemente o Auswahl dazu passender Autonomic Elemente Anwendungs- und AnforderungsCharakteristiken Parameterauswahl FE / AE ParameterEvaluation o Parametrierung der Elemente Modell FE / AE o Ableitung eines Modells zur Systemevaluation o Fortlaufende Verfeinerung Organic Computing – Teil 4, Folie 26 - Prof. Dr. Uwe Brinkschulte Evaluation Hier wird Wissen Wirklichkeit 4.3 DoDOrg und AHS Digital on Demand Real-Time Organism (DoDOrg) Rechnerarchitektur, die sich an biologischen Systemen orientiert (Becker, Henkel, Karl - KIT, Brinkschulte - Univ. Frankfurt) Organic Computing – Teil 4, Folie 27 - Prof. Dr. Uwe Brinkschulte Hier wird Wissen Wirklichkeit 4.3 DoDOrg und AHS Anwendung DodOrgKomponenten Tasks • Anwendung • Monitoring • Power Management • Prozessorzellen Monitoring • Middleware PZ PZ PZ PZ PZ PZ PZ PZ PZ PZ PZ PZ PZ PZ PZ PZ PZ PZ PZ PZ PZ PZ PZ PZ PZ PZ PZ PZ PZ PZ PZ PZ PZ PZ PZ PZ PZ PZ PZ PZ PZ PZ PZ PZ PZ PZ PZ PZ PZ Power Management Middleware Virtuelle Organe Organic Computing – Teil 4, Folie 28 - Prof. Dr. Uwe Brinkschulte Hier wird Wissen Wirklichkeit 4.3 DoDOrg und AHS Monitoring • Grundlage jeglicher Selbst-X Systems Status • Beständige Überwachung des Hardware Status Application Requirements Eigenschaften Monitoring Reaktionen • Proaktive Erkennung von Configuration Feedback • Korrelation von Ereignissen und Data (Hardware und Software) Raw & Cooked • Überwachung auf allen Ebenen Middleware Low-Power Planning kritischen Situationen Organic Computing – Teil 4, Folie 29 - Prof. Dr. Uwe Brinkschulte Hier wird Wissen Wirklichkeit 4.3 DoDOrg und AHS Monitoring • Jede Prozessorzelle (Organic Processing Cell, OPC) enthält ein Monitoring Modul (MM) • Dieses sammelt Daten über den aktuellen 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 Hier wird Wissen Wirklichkeit 4.3 DoDOrg und AHS Monitoring • Um dynamisch Ereignisse und Gruppen von Ereignissen zu behandeln, werden diese Originating Cell Cell Event Additional Specification (e.g. Memory Address) strukturiert • So können auch zur Laufzeit neue Unique Event Tag Ereignisse hinzugefügt werden Event Mask • Über Masken können Klassen von Ereignissen spezifiziert werden Cell Cluster Meta Event • Prinzip ähnlich der Maskierung Event Family Memory Page von Botenstoffen in der Biologie Organic Computing – Teil 4, Folie 31 - Prof. Dr. Uwe Brinkschulte Hier wird Wissen Wirklichkeit 4.3 DoDOrg und AHS Prozessorzellen Heterogeneous Array of Organic Processing Cells (OPCs) Memory Cell Monitor Cell OPC with common structure but with specific functionality I/O Cell N E S FPGA artNoc CellNoc Router W FPGA Cell Channel Noc Allocation/Release •broadcast •real time •adaptive routing I/OL Cell µProc Cell Configuration Cache Messenger Network Interface Peripheral Devices Clkglobal State Interface Configuration Control Monitor Status Observer Control Power Status Power Control Clklocal Monitoring Data Emergency Calls Cell Data path Configuration Low Level Monitoring DSP Cell Observer FPGA Cell Clock and Power Management (DVFS) Organic Computing – Teil 4, Folie 32 - Prof. Dr. Uwe Brinkschulte Cell-Specific Functionality ((?Proc, µProc,DSP, DSP, FPGA,FPFA, FPGA, Memory, Monitoring, etc.) Hier wird Wissen Wirklichkeit 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 Hier wird Wissen Wirklichkeit 4.3 DoDOrg und AHS Middleware • Hier wird das bereits ausführlich beschrieben künstliche Hormonsystem (Artificial Hormone System, AHS) verwendet • Es verteilt zusammengehörige Aufgaben gemäß Eignung und MonitoringDaten auf die Prozessorzellen => Ausbildung virtueller Organe Für i, γ empfangene Eignungswerte Emiγ Für i, γ empfangene Suppressoren Siγ Für i,γ empfangene Acceleratoren Aiγ Σ + + Lokaler Eignungswert Eiγ Von i, γ gesendeter modifizierten Eignungswert Emiγ b a>b a ? Von i, γ gesendete Suppressoren Siγ Übernehme Task Ti auf Kγ Von i, γ gesendete Acceleratoren Aiγ Task Ti auf Kγ γ Notation: Hi Hormon für Task Ti auf Knoten Kγ Hi γ: Hormon von Task Ti auf Knoten Kγ, lateinische Buchstaben stehen für Task-Indizes, griechische Buchstaben für Knoten-Indizes Organic Computing – Teil 4, Folie 34 - Prof. Dr. Uwe Brinkschulte Hier wird Wissen Wirklichkeit 4.3 DoDOrg und AHS Middleware Anwendung Tasks PZ PZ PZ PZ PZ PZ PZ PZ PZ PZ PZ PZ PZ PZ PZ PZ PZ PZ PZ PZ PZ PZ PZ PZ PZ PZ PZ PZ PZ PZ PZ PZ PZ PZ PZ PZ PZ PZ PZ PZ PZ PZ PZ PZ PZ PZ PZ PZ PZ Power Management Monitoring Middleware Virtuelle Organe Organic Computing – Teil 4, Folie 35 - Prof. Dr. Uwe Brinkschulte Hier wird Wissen Wirklichkeit 4.3 DoDOrg und AHS Power Management Power source ► Beeinflusst aus dem momentanen Organic Middleware Peers (in neighbored OPCs) Future energy level Actual energy level Efficiency RT criteria Power / RT Manager der von der Middleware zugeteilten Actual power state Policy FillMinimierung Consume Tasks mit dem Ziel der P1 des Energieverbrauchs bei P2 Fade Einhaltung der Zeitbedingungen Power Local Energy States P3 Budget P4 ► Konfiguriert den Energiezustand (Spannung, Frequenz) der Voltage / frequency Prozessorzellen Legend: setting data / information actions Organic Monitoring Negotiate Energy Budget ► Organisiert das zeitliche Scheduling Manager Assigned Tasks Temperature Local traffic Energie-Zustand undEnergy zusätzlichen Influencing Input Hormone Expression Informationen aus dem Monitoring (Temperatur, …) den Eignungswert (Hormon) einer Zelle für eine Energy level Cost Function Aufgabe Trade & Scheduled Tasks OPC Organic Computing – Teil 4, Folie 36 - Prof. Dr. Uwe Brinkschulte Hier wird Wissen Wirklichkeit 4.3 DoDOrg und AHS Power Management ► Gewährt den einzelnen Prozessorzellen ihr Organic Middleware Power source Influencing Hormone Expression Assigned Tasks ► Die zur Verfügung stehende Energiequelle bestimmt das Gesamtbudget Cost Function Energy level Fill data / information actions Budget Future energy level Actual energy level ► Sie kann Fade RT criteria Power / RT Manager dieses Budget mit Nachbarzellen Policy verhandeln, d.h. Teile ihres Budgets an Nachbarzellen P1 abgeben oder von dort zusätzliche erhalten PEnergie 2 Power States P3 ► Ziel: VermeidungPvon 4 Hotspots, Reduktion des Energieverbrauchs Actual power state Consume Local Energy Budget Legend: Efficiencyhieraus ein lokales ► Jede Zelle erhält Organic Monitoring Trade & Negotiate Energy Budget Manager Temperature Local traffic Peers (in neighbored OPCs) Energy Input Energiebudget Voltage / frequency setting Scheduled Tasks OPC Organic Computing – Teil 4, Folie 37 - Prof. Dr. Uwe Brinkschulte Hier wird Wissen Wirklichkeit 4.3 DoDOrg und AHS Anwendung Fahrerloses Transportsystem (wie in der bereits gezeigten Simulation auch schon zur Einzelevaluation des AHS genutzt Organic Computing – Teil 4, Folie 38 - Prof. Dr. Uwe Brinkschulte Hier wird Wissen Wirklichkeit 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 Hier wird Wissen Wirklichkeit 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 Hier wird Wissen Wirklichkeit 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 Hier wird Wissen Wirklichkeit 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 Hier wird Wissen Wirklichkeit 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 Hier wird Wissen Wirklichkeit 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 Hier wird Wissen Wirklichkeit 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 Hier wird Wissen Wirklichkeit 4.5 Testen in selbstorganisierenden 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 Hier wird Wissen Wirklichkeit 4.5 Testen in selbstorganisierenden Dienstumgebungen Architektur: Organic Computing – Teil 4, Folie 47 - Prof. Dr. Uwe Brinkschulte Hier wird Wissen Wirklichkeit 4.5 Testen in selbstorganisierenden 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 Hier wird Wissen Wirklichkeit 4.5 Testen in selbstorganisierenden 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 Hier wird Wissen Wirklichkeit 4.5 Testen in selbstorganisierenden 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 Hier wird Wissen Wirklichkeit 4.5 Testen in selbstorganisierenden Dienstumgebungen Grundsätzlich sind zu unterscheiden: Funktionale Testsätze: • testen funktionale Eigenschaften (wie z.B. das Liefern einer korrekten Lösung) • Individuelle Testsätze gehören somit immer zu einer DienstDomäne (z.B. mathematische Dienste) Nichtfunktionale Testsätze: • testen nichtfunktionale Eigenschaften (wie z.B. das Einhalten von Zeitbedingungen, Energieverbrauch, …) • Individuelle Testsätze gehören somit immer zu einer Qualitätskategorie (z.B. Test des Energieverbrauchs) Organic Computing – Teil 4, Folie 51 - Prof. Dr. Uwe Brinkschulte Hier wird Wissen Wirklichkeit 4.5 Testen in selbstorganisierenden Dienstumgebungen Genetische Algorithmen zur Generierung neuer (besserer) Testsätze: Funktionale Testsätze: • die Individuen sind Testsätze für eine Dienst-Domäne Nichtfunktionale Testsätze: • die Individuen sind Testsätze für eine Qualitätskategorie Die einzelnen Testfälle sind dann die Allelen (Ausprägung der Gene) eines Testsatzes Die Fitness eines Testsatzes ist dann die Anzahl der durch ihn aufgedeckten Fehler Organic Computing – Teil 4, Folie 52 - Prof. Dr. Uwe Brinkschulte Hier wird Wissen Wirklichkeit 4.5 Testen in selbstorganisierenden Dienstumgebungen Beispiel: Testsätze zur Ermittlung der Reaktionszeit Gene Fitness 12, 14, 28, 37 20 Individuum 1 (Testsatz 1) 4, 13, 23, 67 25 Individuum 2 (Testsatz 2) 22, 25, 39, 41 15 Individuum 3 (Testsatz 3) Jedes Gen entspricht einem Testfall. Diese sind in der obigen Darstellung durch Nummern gekennzeichnet Organic Computing – Teil 4, Folie 53 - Prof. Dr. Uwe Brinkschulte Hier wird Wissen Wirklichkeit 4.5 Testen in selbstorganisierenden Dienstumgebungen Durch genetische Algorithmen können nun neue Individuen erzeugt werden: • Selektion • Mutation • Kreuzung Organic Computing – Teil 4, Folie 54 - Prof. Dr. Uwe Brinkschulte Hier wird Wissen Wirklichkeit 4.5 Testen in selbstorganisierenden Dienstumgebungen Beispiel: Gene Fitness 12, 14, 28, 37 20 4, 13, 23, 67 25 Selektion 22, 25, 39, 41 15 Kreuzung 12, 14, 23, 67 Mutation 12, 14, 24, 67 Besonderheiten: - die Kreuzung erzeugt nur einen Nachkommen (die Standardform der Kreuzung erzeugt 2 Nachkommen) - die Reihenfolge der Gene spielt keine Rolle, da es sich um eine Menge von Testfällen handelt (in der Standardform spielt die Reihenfolge eine Rolle) Organic Computing – Teil 4, Folie 55 - Prof. Dr. Uwe Brinkschulte Hier wird Wissen Wirklichkeit 4.5 Testen in selbstorganisierenden Dienstumgebungen Bei funktionalen Tests wird meist ein Mehrheitsvotum zur Entscheidung über Korrektheit eingesetzt Beispiel numerische Ergebnisse: Beispiel Auswahl eines Textes: Organic Computing – Teil 4, Folie 56 - Prof. Dr. Uwe Brinkschulte Hier wird Wissen Wirklichkeit 4.5 Testen in selbstorganisierenden Dienstumgebungen Das Mehrheitsvotum kann auch mit der Reputation eines Dienstes gewichtet werden. Die Reputation wi kann z.B. aus der Unzufriedenheit ui (falsches Votum) mit einem Dienst i aus der Menge von S Diensten einer Klasse gewonnen werden: wi 1 ui S u j j 1 Organic Computing – Teil 4, Folie 57 - Prof. Dr. Uwe Brinkschulte Hier wird Wissen Wirklichkeit 4.5 Testen in selbstorganisierenden Dienstumgebungen Im kontinuierlichen Fall berechnet sich das Mehrheitsvotum dann aus den Ergebnissen ri der Dienste in S: S w r i MV i i 1 S w i i 1 Das Ergebnis der Dienste, die dem Mehrheitsvotum am nächsten kommen, wird dann als korrekt angesehen Organic Computing – Teil 4, Folie 58 - Prof. Dr. Uwe Brinkschulte Hier wird Wissen Wirklichkeit
