Hier wird Wissen Wirklichkeit Organic Computing – Teil 4, Folie 1 - Prof. Dr. Uwe Brinkschulte...

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


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


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 SystemAutonomic: Das System verfügt über Selbst-X EigenschaftenReal-Time: Das System ist echtzeitfähig

(Ungerer - Univ. Augsburg, Brinkschulte - Uinv.Frankfurt)



Systemarchitektur

CARCore

SMT Processor Core

Memory & Peripherals

CAROS Operating System Self-X Layers 1 & 2

CARCore

SMT Processor Core

Memory & Peripherals

CAROS Operating System Self-X Layers 1 & 2

CAR-SoC Node

CARISMA Middleware Self-X Layer 3

. . .

Communication Network

CAR-SoC Node


Funktionsmechanismeno Mehrfädiger

Prozessor-kern (SMT)

Echtzeit-scheduling

lokale und globale Regel-kreise für Organic Management

dezentrale Regelkreise

(Univ. Augsburg, Karlsruhe, Frankfurt)



CARSoC Hardware(CarCoreund Peripherie)Echtzeitfähige Ausführung einermehrfädigen LastZweistufiges Echtzeit-Scheduling in HardwareStufe 1: einfacherprioriätsbasierterEchtzeitschedulerStufe 2: komplexerPrioritätsmanager



Die CAR-SoC Hardware besitzt keine besonderen Eigenschaften zur Realisierung der Selbst-X EigenschaftenDiese werden hier auf drei Ebenen in Software realisiertCAROS (Betriebsystem)• Untere Ebene (Reflex-Ebene)• Mittlere Ebene (lokale Planungebene)CARISMA (Middleware)• Obere Ebene (globale Planungsebene)



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



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




Reflex-Ebene(Modul-Manager)

Lokale Planungsebene


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


Hier wird Wissen Wirklichkeit

Grundlegende Architektur der Middleware CARISMADienstbasierte Architektur

Mikrokern

Dienste übernehmendie Funktionalität

Dienste sind unabhängigelose gekoppelte Einheiten

Sie agieren als mobileintelligente Agenten(Service Agents)



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


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


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



Die Berechnung von Kosten und Nutzen für die Auktionen bedürfen einer GrundlageAbhängigkeiten und Eignungen müssen berücksichtigt werdenDieser Mechanismus muss generisch sein, da viele Abhängigkeiten und Eignungen anwendungsspezifisch sineEr muss in der Lage sein, Knotenkonfigurationen (verfügbare Sensoren, Aktoren, Dienste, …) zu erfassenEr muss transparent sein, d.h. die Anwendung braucht nicht zu wissen, wo ein Dienst gerade ausgeführt wird Capabilities



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)



Ein Beispiel




Ein Beispiel

Headlight Control benötigt Capability HEADLIGHTbietet Capability ILLUMINATE zu Kosten

0 bietet Capability SIGNAL zu Kosten 100

(Blinken mit dem Hauptscheinwerfer ist ungünstig)

Foglight Control benötigt Capability FOGLIGHTbietet Capability ILLUMINATE zu Kosten

100bietet 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)



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 DienstagentenEs sei die Menge der benötigten Capabilities eines Dienst-Agenten a A0, A0 : Menge der nicht ausgeführten Dienst-AgentenDann kann ein Dienstagent b A0 auf der Ressource r R ausgeführt werden, wenn gilt:

provrS

provaS

reqaS

1

)(Aa Rr

provr

prova

reqb SSS



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



Interaktion von CARISMA und CAROSDienst-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


Autonomic Systems on Chip (ASoC)o Problem:

hohe Integrationsdichtenverursachen zunehmend transiente Fehler während des Betriebs

o Idee: 2 Ebenen o Funktionale Ebene:

Eigentliche Chip-Funktionalitäto Autonomic Ebene: Überwachung der

funktionalen Ebene

AE AE

AE AE

AE AE

Prozessorkern

RAM ROM

Ein-/Ausgabe

Prozessorkern

Netzwerk

. . . . . .

. . . . . .

Autonomic Ebene

Funktionale Ebene

AE (Autonomic Element) Aktuator

Evaluator Monitor

Schnittstelle

(Herkersdorf - Univ. München, Rosenstil - Univ Tübingen, Brinkmann - FZI Karlsruhe)

4.2 ASoC


MAPE Zyklus mit Learning Classifier Systems größtenteils in Hardware realisiert

Aktualisierung der Regeln mittels genetischer Algorithmen in Software

4.2 ASoC


Zusätzlich fehlertoleranter CPU Datenpfad durch Verwendung von Shadow-Registern => Entdeckung von transienten Fehlern

4.2 ASoC


Entwurfsprozess:o Abbildung der Anwendungs-

anforderungen auf die Architektur-Charakteristiken

o Auswahl der funktionalen Elemente

o Auswahl dazu passender Autonomic Elemente

o Parametrierung der Elementeo Ableitung eines Modells zur

Systemevaluationo Fortlaufende Verfeinerung

Architektur-Charakteristiken

Funktionale

Elemente (FE)

Autonomic Elemente

(AE)

Anwendungs- und

Anforderungs-Charakteristiken

Parameterauswahl FE / AE

Modell FE / AE

Evaluation

Parameter- Evaluation

4.2 ASoC


Digital on Demand Real-Time Organism (DoDOrg)

Rechnerarchi-tektur, die sichan biologischen Systemen orientiert

4.3 DoDOrg und AHS

Brai

n Le

vel

Orga

n Le

vel

Cell

Leve

l

Myo-cardial

Cell

Nervous System

Application API

Application Monitoring

HardwareMonitoring

MiddlewareMonitoring,Feedback

Application Testbed

Organic Middleware

Organic Processing Cells

Distributed Low Power Management

Organic Monitoring System

HeartHormone Level Computation

Dynamic Power ManagementReal-time considerations

Temperature,Local Traffic

Self-AdaptationSelf-Optimization

Self-Healing

Stable HormoneInteraction

Stable EnergyDistribution

OPC Interaction

Brai

n Le

vel

Orga

n Le

vel

Cell

Leve

l

Myo-cardial

Cell

Nervous System

Application API

Application Monitoring

HardwareMonitoring

MiddlewareMonitoring,Feedback

Application Testbed

Organic Middleware

Organic Processing Cells

Distributed Low Power Management

Organic Monitoring System

HeartHormone Level Computation

Dynamic Power ManagementReal-time considerations

Temperature,Local Traffic

Self-AdaptationSelf-Optimization

Self-Healing

Stable HormoneInteraction

Stable EnergyDistribution

OPC Interaction

(Becker, Henkel, Karl - KIT, Brinkschulte - Univ. Frankfurt)


Middleware M

onito

ring

Pow

er M

anag

emen

t

Tasks

PZ PZ PZ PZ PZ PZ PZ







Virtuelle Organe

Anwendung DodOrg-Komponenten

• Anwendung• Middleware• Monitoring• Power Management• Prozessorzellen

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

Application Hardware

Monitoring

Raw

& C

ooke

d

Dat

a

Feed

back

Con

figur

atio

n

Req

uire

men

ts

Stat

us

Stat

us

Middleware

Low-Power Planning

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

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

4.3 DoDOrg und AHS

Meta Event

Memory Page

Event Family

Cell Cluster

OriginatingCell Event

Cell(e.g. Memory Address)

Additional Specification

Event TagUnique

Event Mask


Prozessorzellen

4.3 DoDOrg und AHS

FPGACell

DSPCell

I/OCell

MemoryCell

MonitorCell

FPGACell

µProcCell

I/OCell

PeripheralDevices

Heterogeneous Array of Organic Processing Cells (OPCs)

Noc•broadcast•real time•adaptive routing

OPC with commonstructure but withspecific functionality

FPGACell

NES

W

Clkglobal Clklocal

Cell-SpecificFunctionality(?Proc, DSP,FPGA,FPFA, Memory, Monitoring, etc.)

Clock and Power Management (DVFS)

ConfigurationControl

State Interface

Configuration CacheartNocRouter

Obs

erve

r

Network Interface

L

Power StatusPower Control

Monitor StatusObserver Control

Cell Data path

Monitoring DataEmergency Calls

Messenger

Channel Allocation/Release Configuration

Low

Lev

el M

onito

ring

NES

W

Clkglobal Clklocal

Cell-SpecificFunctionality( µProc, DSP,FPGA,Memory, Monitoring, etc.)



State Interface

Configuration Cache



State Interface


State Interface

Configuration CacheConfiguration CacheNocRouter

Obs

erve

r

Network Interface

L

Power StatusPower Control

Monitor StatusObserver Control

Cell Data path

Monitoring DataEmergency Calls

Messenger

Channel Allocation/Release Configuration

Low

Lev

el M

onito

ring


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


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

Für i, γ empfangene

Suppressoren Siγ

Für i,γ empfangene

Acceleratoren Aiγ Lokaler

Eignungswert Eiγ

Σ -

+ +

Von i, γ gesendeter

modifizierten Eignungswert

Emiγ

Für i, γ empfangene

Eignungswerte Emiγ

a > b ?

Übernehme Task Ti auf Kγ

Von i, γ gesendete

Suppressoren Siγ

Von i, γ gesendete

Acceleratoren Aiγ

Task Ti auf Kγ

a

b

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


Middleware

4.3 DoDOrg und AHS

Middleware M

onito

ring

Pow

er M

anag

emen

t

Tasks








Virtuelle Organe

Anwendung


Cost Function

Organic MiddlewareInfluencing

Hormone Expression

Power / RTManager

Organic M

onitoring

Consume

Fade

Trade &Negotiate

Policy

Energy BudgetManager

Local EnergyBudget P4

P3

P2

P1

Fill

EnergyInput

EfficiencyRT criteria

Temperature

Local traffic

Power source

Pee

rs (i

n ne

ighb

ored

OP

Cs)

OPC

Voltage / frequencysetting

PowerStates

AssignedTasks

ScheduledTasks

data / information actions

Legend:

Future energy levelActual 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


Cost Function

Organic MiddlewareInfluencing

Hormone Expression

Power / RTManager

Organic M

onitoring

Consume

Fade

Trade &Negotiate

Policy

Energy BudgetManager

Local EnergyBudget P4

P3

P2

P1

Fill

EnergyInput

EfficiencyRT criteria

Temperature

Local traffic

Power source

Pee

rs (i

n ne

ighb

ored

OP

Cs)

OPC

Voltage / frequencysetting

PowerStates

AssignedTasks

ScheduledTasks

data / information actions

Legend:

Future energy levelActual 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


4.3 DoDOrg und AHS

Anwendung

Fahrerloses Transport-system(wie in der bereits gezeigten Simulation auch schon zur Einzelevaluation des AHS genutzt


4.4 Organic Traffic Control

Steuerung eines Netzwerks von Ampel-gesteuerten Kreuzungen nach organischen PrinzipienKein zentraler Rechner, welcher die Kreuzungen steuertInteraktion der einzelnen Kreuzungen im Netz mit verschiedenen Zielen:• Geringste Verzögerung• Geringste Anzahl von Stopps

(Schmeck - KIT, Müller-Schloer - Univ. Hannover)



Observer/Controller-Architektur mit Learning Classifier Systems (LCS) und genetischen Algorithmen (GA)



Veränderung der Rot/Grünphasen einer lokalen Ampel gemäß LCS, Veränderung der Regeln mittels GA



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



LCS zur On-Line Parameterauswahl

TLCXX: Parametersatz (Zeiten) des Standartcontrollers, Pred: vorhergesagte Verzögerung



GA zur Off-Line Parameterauswahl

Im Gegensatz zu klassischen LCS werden hier keine neuen Regeln generiert, sondern basierend auf Simulationen die Parameter weiter optimiert



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%


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)



Architektur:



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:



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 gesammeltDaraus werden zufällig Testsätze zusammengestellt



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

…



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)



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



Beispiel: Testsätze zur Ermittlung der Reaktionszeit

Gene Fitness

12, 14, 28, 37 20 Individuum 1 (Testsatz 1)



Jedes Gen entspricht einem Testfall. Diese sind in der obigen Darstellung durch Nummern gekennzeichnet



Durch genetische Algorithmen können nun neue Individuen erzeugt werden:

• Selektion

• Mutation

• Kreuzung



Kreuzung

SelektionMutation

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



Bei funktionalen Tests wird meist ein Mehrheitsvotum zur Entscheidung über Korrektheit eingesetzt

Beispiel numerische Ergebnisse:

Beispiel Auswahl eines Textes:



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:

S

j

j

ii

u

uw

1

1



Im kontinuierlichen Fall berechnet sich das Mehrheitsvotum dann aus den Ergebnissen ri der Dienste in S:

Das Ergebnis der Dienste, die dem Mehrheitsvotum am nächsten kommen, wird dann als korrekt angesehen

S

i

i

S

i

ii

w

rwMV

1

1

Hier wird Wissen Wirklichkeit Organic Computing – Teil 4, Folie 1 - Prof. Dr. Uwe Brinkschulte...

Documents

Transcript of Hier wird Wissen Wirklichkeit Organic Computing – Teil 4, Folie 1 - Prof. Dr. Uwe Brinkschulte...