Hier wird Wissen Wirklichkeit Organic Computing – Teil 4, Folie 1 - Prof. Dr. Uwe Brinkschulte Teil 4 Anwendungen Aktuelle Themen bei Eingebetteten Systemen.

Präsentation zum Thema: "Hier wird Wissen Wirklichkeit Organic Computing – Teil 4, Folie 1 - Prof. Dr. Uwe Brinkschulte Teil 4 Anwendungen Aktuelle Themen bei Eingebetteten Systemen."—  Präsentation transkript:

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

2 Hier wird Wissen Wirklichkeit Organic Computing – Teil 4, Folie 2 - Prof. Dr. Uwe Brinkschulte 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

3 Hier wird Wissen Wirklichkeit Organic Computing – Teil 4, Folie 3 - Prof. Dr. Uwe Brinkschulte 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)

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

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

6 Hier wird Wissen Wirklichkeit Organic Computing – Teil 4, Folie 6 - Prof. Dr. Uwe Brinkschulte CARSoC Hardware (CarCore und Peripherie) Echtzeitfähige Ausführung einer mehrfädigen Last Zweistufiges Echtzeit- Scheduling in Hardware Stufe 1: einfacher prioriätsbasierter Echtzeitscheduler Stufe 2: komplexer Prioritätsmanager 4.1 CAR-SoC und CARISMA

7 Hier wird Wissen Wirklichkeit Organic Computing – Teil 4, Folie 7 - Prof. Dr. Uwe Brinkschulte 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) 4.1 CAR-SoC und CARISMA

8 Hier wird Wissen Wirklichkeit Organic Computing – Teil 4, Folie 8 - Prof. Dr. Uwe Brinkschulte 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 Taktfrequenzreduktion um 30% Schnelles, reaktives Verhalten Einfache Anpassungsaufgaben 4.1 CAR-SoC und CARISMA

9 Hier wird Wissen Wirklichkeit Organic Computing – Teil 4, Folie 9 - Prof. Dr. Uwe Brinkschulte 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 4.1 CAR-SoC und CARISMA

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

11 Hier wird Wissen Wirklichkeit Organic Computing – Teil 4, Folie 11 - Prof. Dr. Uwe Brinkschulte 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 4.1 CAR-SoC und CARISMA

12 Hier wird Wissen Wirklichkeit 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) 4.1 CAR-SoC und CARISMA

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

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

15 Hier wird Wissen Wirklichkeit Organic Computing – Teil 4, Folie 15 - Prof. Dr. Uwe Brinkschulte 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 4.1 CAR-SoC und CARISMA

16 Hier wird Wissen Wirklichkeit Organic Computing – Teil 4, Folie 16 - Prof. Dr. Uwe Brinkschulte 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 4.1 CAR-SoC und CARISMA

17 Hier wird Wissen Wirklichkeit 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) 4.1 CAR-SoC und CARISMA

18 Hier wird Wissen Wirklichkeit Ein Beispiel 4.1 CAR-SoC und CARISMA

19 Hier wird Wissen Wirklichkeit 4.1 CAR-SoC und CARISMA Ein Beispiel Headlight Controlbenö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 Leftbenötigt Capabilities TURNSIGNAL & LEFT bietet Capability ILLUMINATE zu Kosten 500 bietet Capability SIGNAL zu Kosten 0 (Ideal zum Blinken, sehr schlecht zum Beleuchten)

20 Hier wird Wissen Wirklichkeit 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  A 1, A 1 : Menge der ausgeführten Dienstagenten Es sei die Menge der benötigten Capabilities eines Dienst- Agenten a  A 0, A 0 : Menge der nicht ausgeführten Dienst-Agenten Dann kann ein Dienstagent b  A 0 auf der Ressource r  R ausgeführt werden, wenn gilt:

21 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

22 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-Eigen- schaften in Capabilities und Kosten

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

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

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

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

27 Hier wird Wissen Wirklichkeit Organic Computing – Teil 4, Folie 27 - Prof. Dr. Uwe Brinkschulte Digital on Demand Real-Time Organism (DoDOrg) Rechnerarchi- tektur, die sich an biologischen Systemen orientiert 4.3 DoDOrg und AHS (Becker, Henkel, Karl - KIT, Brinkschulte - Univ. Frankfurt)

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

29 Hier wird Wissen Wirklichkeit Organic Computing – Teil 4, Folie 29 - Prof. Dr. Uwe Brinkschulte 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 ApplicationHardware Monitoring Raw & Cooked Data Feedback Configuration Requirements Status Middleware Low-Power Planning 4.3 DoDOrg und AHS

30 Hier wird Wissen Wirklichkeit Organic Computing – Teil 4, Folie 30 - Prof. Dr. Uwe Brinkschulte 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 4.3 DoDOrg und AHS

31 Hier wird Wissen Wirklichkeit Organic Computing – Teil 4, Folie 31 - Prof. Dr. Uwe Brinkschulte 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 4.3 DoDOrg und AHS

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

33 Hier wird Wissen Wirklichkeit Organic Computing – Teil 4, Folie 33 - Prof. Dr. Uwe Brinkschulte 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 4.3 DoDOrg und AHS

34 Hier wird Wissen Wirklichkeit Organic Computing – Teil 4, Folie 34 - Prof. Dr. Uwe Brinkschulte 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 4.3 DoDOrg und AHS

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

36 Hier wird Wissen Wirklichkeit Organic Computing – Teil 4, Folie 36 - Prof. Dr. Uwe Brinkschulte Cost Function Organic Middleware Influencing Hormone Expression Power / RT Manager Power / RT Manager Organic Monitoring Consume Fade Trade & Negotiate Policy Energy Budget Manager Energy Budget Manager Local Energy Budget Local Energy Budget P4P4 P3P3 P2P2 P1P1 Fill Energy Input Efficiency RT criteria Temperature Local traffic Power source Peers (in neighbored OPCs) OPC Voltage / frequency setting Power States Assigned Tasks Scheduled Tasks data / information actions Legend: Future energy level Actual energy level Energy level Actual power state ► 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 4.3 DoDOrg und AHS Power Management

37 Hier wird Wissen Wirklichkeit Organic Computing – Teil 4, Folie 37 - Prof. Dr. Uwe Brinkschulte Cost Function Organic Middleware Influencing Hormone Expression Power / RT Manager Power / RT Manager Organic Monitoring Consume Fade Trade & Negotiate Policy Energy Budget Manager Energy Budget Manager Local Energy Budget Local Energy Budget P4P4 P3P3 P2P2 P1P1 Fill Energy Input Efficiency RT criteria Temperature Local traffic Power source Peers (in neighbored OPCs) OPC Voltage / frequency setting Power States Assigned Tasks Scheduled Tasks data / information actions Legend: Future energy level Actual energy level Energy level Actual power state 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

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

39 Hier wird Wissen Wirklichkeit Organic Computing – Teil 4, Folie 39 - Prof. Dr. Uwe Brinkschulte 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)

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

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

42 Hier wird Wissen Wirklichkeit Organic Computing – Teil 4, Folie 42 - Prof. Dr. Uwe Brinkschulte 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

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

44 Hier wird Wissen Wirklichkeit Organic Computing – Teil 4, Folie 44 - Prof. Dr. Uwe Brinkschulte 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

45 Hier wird Wissen Wirklichkeit Organic Computing – Teil 4, Folie 45 - Prof. Dr. Uwe Brinkschulte 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%

46 Hier wird Wissen Wirklichkeit Organic Computing – Teil 4, Folie 46 - Prof. Dr. Uwe Brinkschulte 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)

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

48 Hier wird Wissen Wirklichkeit Organic Computing – Teil 4, Folie 48 - Prof. Dr. Uwe Brinkschulte 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:

49 Hier wird Wissen Wirklichkeit Organic Computing – Teil 4, Folie 49 - Prof. Dr. Uwe Brinkschulte 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

50 Hier wird Wissen Wirklichkeit Organic Computing – Teil 4, Folie 50 - Prof. Dr. Uwe Brinkschulte 4.5 Testen in selbstorgani- sierenden Dienstumgebungen Beispiel: Dienst A liefert die Eingabe 0011101010 (= berechne 5 2 ) 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 …

51 Hier wird Wissen Wirklichkeit Organic Computing – Teil 4, Folie 51 - Prof. Dr. Uwe Brinkschulte 4.5 Testen in selbstorgani- sierenden 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 Dienst- Domä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)

52 Hier wird Wissen Wirklichkeit Organic Computing – Teil 4, Folie 52 - Prof. Dr. Uwe Brinkschulte 4.5 Testen in selbstorgani- sierenden 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

53 Hier wird Wissen Wirklichkeit Organic Computing – Teil 4, Folie 53 - Prof. Dr. Uwe Brinkschulte 4.5 Testen in selbstorgani- sierenden 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

54 Hier wird Wissen Wirklichkeit Organic Computing – Teil 4, Folie 54 - Prof. Dr. Uwe Brinkschulte 4.5 Testen in selbstorgani- sierenden Dienstumgebungen Durch genetische Algorithmen können nun neue Individuen erzeugt werden: Selektion Mutation Kreuzung

55 Hier wird Wissen Wirklichkeit Organic Computing – Teil 4, Folie 55 - Prof. Dr. Uwe Brinkschulte 4.5 Testen in selbstorgani- sierenden Dienstumgebungen Kreuzung Selektion Mutation Beispiel: Gene Fitness 12, 14, 28, 37 20 4, 13, 23, 67 25 22, 25, 39, 41 15 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) 12, 14, 23, 67 12, 14, 24, 67

56 Hier wird Wissen Wirklichkeit Organic Computing – Teil 4, Folie 56 - Prof. Dr. Uwe Brinkschulte 4.5 Testen in selbstorgani- sierenden Dienstumgebungen Bei funktionalen Tests wird meist ein Mehrheitsvotum zur Entscheidung über Korrektheit eingesetzt Beispiel numerische Ergebnisse: Beispiel Auswahl eines Textes:

57 Hier wird Wissen Wirklichkeit Organic Computing – Teil 4, Folie 57 - Prof. Dr. Uwe Brinkschulte 4.5 Testen in selbstorgani- sierenden Dienstumgebungen Das Mehrheitsvotum kann auch mit der Reputation eines Dienstes gewichtet werden. Die Reputation w i kann z.B. aus der Unzufriedenheit u i (falsches Votum) mit einem Dienst i aus der Menge von S Diensten einer Klasse gewonnen werden:

58 Hier wird Wissen Wirklichkeit Organic Computing – Teil 4, Folie 58 - Prof. Dr. Uwe Brinkschulte 4.5 Testen in selbstorgani- sierenden Dienstumgebungen Im kontinuierlichen Fall berechnet sich das Mehrheitsvotum dann aus den Ergebnissen r i der Dienste in S : Das Ergebnis der Dienste, die dem Mehrheitsvotum am nächsten kommen, wird dann als korrekt angesehen