selbstanpas sen de software
Download
Skip this Video
Download Presentation
Selbstanpas sen de Software

Loading in 2 Seconds...

play fullscreen
1 / 70

Selbstanpas sen de Software - PowerPoint PPT Presentation


  • 38 Views
  • Uploaded on

Selbstanpas sen de Software. Joh annes Schick & Wolfram Urich. Referatsaufbau. Interpretation von Luftaufnahmen. Packen in Echtzeit. Selbstanpassende Software. Interpretation von Luftaufnahmen. Gliederung. Ansatz selbstanpassender Software Typ-2 Berechnungen

loader
I am the owner, or an agent authorized to act on behalf of the owner, of the copyrighted work described.
capcha
Download Presentation

PowerPoint Slideshow about ' Selbstanpas sen de Software' - salene


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.While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server.


- - - - - - - - - - - - - - - - - - - - - - - - - - E N D - - - - - - - - - - - - - - - - - - - - - - - - - -
Presentation Transcript
selbstanpas sen de software

Selbstanpassende Software

Johannes Schick

&

Wolfram Urich

referatsaufbau
Referatsaufbau
  • Interpretation von

Luftaufnahmen

  • Packen in Echtzeit
selbstanpassende software

Selbstanpassende Software

Interpretation von Luftaufnahmen

gliederung
Gliederung
  • Ansatz selbstanpassender Software
  • Typ-2 Berechnungen
  • Die GRAVA-Softwarearchitektur
  • Identifikation von Regionen
ansatz
Ansatz

Definition

Selbstanpassende Software wertet ihr eigenes Verhalten aus und ändert dieses Verhalten, wenn die Auswertung anzeigt, daß sie nicht das zustande bringt für was die Software konzipiert ist oder wenn bessere Funktionalität oder Leistungsfähigkeit erreicht werden können.

DARPA, 1998

ansatz1
Ansatz
  • Probleme mit nicht fest umrissener Umgebung können mit herkömmlichen Mitteln nicht gelöst werden, z.B. Bildinterpretation
  • Lösung: selbstanpassende Software
  • Ziel: Stabilität auch in unbekannten Umgebungen
  • Programmiersprachen: Java, objektorientiertes Lisp,...
ansatz2
Ansatz
  • Beispiele:
    • Raketen
    • Roboter zur Detektion von Unterwasserminen
    • unbemannte Aufklärungsflugzeuge
    • Roboter zur Erforschung von Planetenoberflächen
    • Maschinelles Packen
    • Active Trust Management
    • NASA, Projekt Morphing: selbstanpassende Flugsysteme für Raumfahrtvehikel
ansatz3
Ansatz
  • Merkmale selbstanpassender Software
    • besteht i.a. nicht nur aus einem einzelnen Programm, sondern aus verschiedenen, spezialisierten Einzelprogrammen, hier durch Agenten realisiert
    • Fähigkeit Zustand der Berechnungen zu beobachten
    • Fähigkeit des Diagnostizierens von Problemen
    • Fähigkeit Änderungen vorzunehmen, um Abweichungen vom verlangten Verhalten zu korrigieren => erneute Annäherung an Programmziel
ansatz4
Ansatz
  • Punkt 2 und 4 bekannt unter Stichwort „Reflektierende Software“ (alter, bekannter Ansatz)
  • Unterschied zwischen s.S. und Reflektion: Reflektierende Software weiß nicht welche Änderungen vorgenommen werden sollen und wie auf bessere Ergebnisse hingearbeitet werden kann
  • Reflektion = Mittel zur Selbstanpassung
typ 2 berechnungen
Typ-2 Berechnungen
  • Unterteilung der Berechnungen nach Vorhersagbarkeit der Umgebung
    • Typ-1 Berechnungen: Umgebung komplett bekannt
    • Typ-2 Berechnungen: Umgebung nicht bis ins letzte Detail vorhersagbar
typ 2 berechnungen1
Typ-2 Berechnungen
  • Klassische Informatik befaßt sich nur mit Typ-1 Berechnungen
  • in der Natur vorkommende Berechnungen durchgehend vom 2. Typus, trotzdem stabil (Bsp.: Fliege: findet sich in Umgebung zurecht)
  • wenn Erfolg einer Berechnung aufgrund der Komplexität der Umgebung nicht gewährleistet werden kann:
typ 2 berechnungen2
Typ-2 Berechnungen
  • Überprüfen wie gut die angestellten Berechnungen waren
  • Änderungen vornehmen, die zu hoffentlich besserem Ergebnis führen
  • Hier zeigt sich: Typ-2 Berechnungen = Typ-1 Berechnungen eingeschlossen in Kontrollsystem
typ 2 berechnungen3
Typ-2 Berechnungen
  • können also gesamtes Wissen über Typ-1 Berechnungen übernehmen und zusätzlich:
    • Programmintention muß bekannt sein
    • es muß gemessen werden inwiefern diese Intention getroffen wurde
    • es muß „korrigierende Kraft“ existieren, die Programmverhalten dem gewünschten Verhalten annähert
typ 2 berechnungen4
Typ-2 Berechnungen
  • Selbstanpassende Software = Versuch Typ-2 Berechnungen durch System mit „korrigierender Kraft“ zu realisieren, die Änderungen am Programm vornimmt
  • Spektrum reicht vom Anpassen der Programmparameter bis hin zur Umschreibung des Programmcodes
grava architektur
GRAVA-Architektur
  • Bildinterpretation = Paradeanwendung für Selbstanpassung, da
    • Umwelt nie ganz vorhersagbar
    • diese meistens dynamischer Natur ist, z.B. verschiedene Flugphasen: Höhe, Tageszeit

(->Lichintensität), Wetterbedingungen, Jahreszeit

(->Schnee)

  • Architektur dient zur gleichzeitigen Segmentation und Interpretation von Luftaufnahmen
grava architektur1
GRAVA-Architektur
  • es existiert nicht die beste Segmentierung, da Aufteilung und Interpretation von Bedürfnissen des Anwenders abhängen, z.B. Aufteilung und Etikettierung nach Getreidearten >=< Aufteilung nach bewohnten und unbewohnten Gebieten
grava architektur2
GRAVA-Architektur
  • Systemarchitekt: Paul Robertson
  • University of Oxford, UK
  • Forschungsschwerpunkte:
    • AI, insb. „Computer Vision“
    • Selbstanpassende Software
    • Reflektierende Systeme
    • Höhere Programmierspachen, hat z.B. erstes 32-Bit-Lisp entwickelt
grava architektur3
GRAVA-Architektur
  • Arbeiten über Bildinterpretation gesponsert vom DARPA und der Air Force
  • Präsident und Leiter der Technologieabteilung der Dynamic Object Language Labs (-> Objektorientierte Programmiertools, z.B.Yolamba = obj.orient. SCHEME)
slide20

Pool von

Agenten

Bilder

Herstellen eines Bild-

interpretations und

-segmentations-

kreislaufs

Segmentieren

und Interpretieren

der Bilder

Der Bilderkorpus:

Eine Datenbank mit

Bildern und Ex-

pertenanmerkungen

Bilderwissen

Interpretation

Auswer-

tung

grava architektur4
GRAVA-Architektur
  • Innovationen der GRAVA-Architektur:
    • Meta-Agenten produzieren Agentenkreisläufe zur Bildsegmentation und –interpretation
    • benutzt Minimum Description Length-Ansatz
grava architektur5
GRAVA-Architektur
  • Bildinterpretation beruht auf Wahrscheinlichkeiten, gestehen den Dingen die größte Wahrscheinlichkeit zu, die wir glauben zu sehen („Optische Täuschungen“)
  • führt zu Ansatz der Minimum Description Length (MDL)
    • Agenten werden auf Bereiche eines Bildes angesetzt, ggf. mehrere Agenten auf selben Bereich
    • sie liefern Beschreibung, die dann codiert wird
    • Beschreibung, die kürzesten globalen Code liefert gilt als wahrscheinlichste und wird übernommen
grava architektur6
GRAVA-Architektur
  • Erklärung: die am häufigsten vorkommenden Symbole (Häuser, Straßen, etc.) werden durch die wenigsten Bits codiert => je kürzer Code, desto wahrscheinlicher ist die Korrektheit der Beschreibung
  • Code wird nicht übertragen! Dient nur dem Auffinden der wahrscheinlichsten Beschreibung
  • Metaagenten sollen Agenten auswählen, die kürzeste globale Beschreibung liefern
grava architektur7
GRAVA-Architektur
  • Problem: ggf. können mehrere Agenten die Beschreibungslänge für Region verkürzen
  • keine Lösung: Wahl von Agent, der kürzeste Beschreibung für Region liefert, denn lokale Verbesserung der Beschreibung führt nicht notwendig zu globaler Verbesserung
  • Lösung: Monte-Carlo-Algorithmus, der Agenten (quasi-)zufällig auswählt; hierbei werden die Wahrscheinlichkeiten der Agenten gewichtet mit ihrer „Wahlstärke“, die sich aus Beitrag zur Beschreibungslänge berechnet
slide25

Start

Initialisiere das

gesamte Bild als

eine einzige Region

1) Für jede Region

Finde Agenten, die neue

Regionen entdecken, welche

ihrerseits einige/alle Pixel der

Region fortnehmen; dies

reduziert die Beschreibungslänge

2) Für jede Region

Versuche die Beschreibungslänge

durch das Abgeben von Pixeln

an Nachbar- bzw. innere

Regionen zu verkürzen

Ende

wenn keine neuen

Regionen oder keine

Reduktion der

Beschreibungs-

länge

3) Für jede Region

Versuche die Beschreibungs-

länge durch das Verschmelzen

mit Nachregionen zu mini-

mieren

grava architektur8
GRAVA-Architektur
  • 3 Regionen: 1x Hintergrund und 2x See
  • Beachte: Inseln gehören noch zum Hintergrund
grava architektur9
GRAVA-Architektur
  • 20 Iterationen später
  • Beachte: Inseln = neue Regionen (Stufe 1)
  • in Inselregionen werden von nun an keine neuen Regionen gefunden => STOP für diese 2 Regionen
  • Hintergrundregion hat Grenzpixel an Seeregion abgegeben (Stufe 2)
grava architektur10
GRAVA-Architektur
  • neue Seeregion oben links (Stufe 1)
  • durch Anwenden der Stufen 1-3 ist große Seeregion in mehrere Regionen aufgesplittet worden
grava architektur11
GRAVA-Architektur
  • 1 Iteration später
  • Seeregionen => eine einzige Seeregion (Verschmelzen, 3. Stufe)
  • kürzere Kodierung, da nicht für jede Seeregion Strukturinformationen gespeichert werden müssen und weniger Grenzinfos
grava architektur12
GRAVA-Architektur
  • Repräsentation des Bildes

Grenzpixel

Pixel-

aufzählung

: Region

: Art der Region

: Startpixel der Grenze

: Anzahl der Grenzpunkte

grava architektur13
GRAVA-Architektur
  • Grenzpixel: Beginn bei Startpixel, dann wird jeder Pixel in Abhängigkeit von Vorgänger angegeben
  • Anschließend werden innere Pixel von links oben nach rechts unten angegeben
  • Datenstruktur liefert Position und Form der Regionen
regionenidentifikation
Regionenidentifikation
  • mdst. 3 Möglichkeiten zur Bestimmung des Inhalts einer Region:
    • Vergleichen der Umrissform mit aus dem Korpus gelernten Umrissformen
    • Mustervergleich der inneren Pixel mit aus der Datenbank gelernten Grundmustern
    • Einbeziehung des Bildkontextes
regionenidentifikation1
Regionenidentifikation
  • es werden Regeln aus Bildern (aus dem Korpus) extrahiert, um Zusammenhänge zwischen Regionen miteinzubeziehen
  • Region1 wird als Tripel beschrieben:
  • Repräsentation der Regionen ist invariant bzgl. Rotation
  • sie kann mit „Verschleierung“ umgehen:
    • Bildrand
    • Nebel und Wolken
regionenidentifikation2
Regionenidentifikation

Verschleierung

  • Verschleierung kann mehrere interne und externe Regionen überdecken => „*“
  • Bildinterpretation sollte Wahrscheinlichkeiten für Inhalt der verdeckten Regionen liefern
  • Region1 wird beschrieben durch Regel:
regionenidentifikation3
Regionenidentifikation

Fel-

der

3

Regel W.

Felder 2

Felder 1

Stadt

See

Fluß

Straße

Sumpf 1

Sumpf

2

regionenidentifikation4
Regionenidentifikation
  • aus Korpus werden Vielzahl von Regeln gelernt
  • kommt Regel mehrfach vor wird Wahrscheinlichkeit gemittelt => realitätstreuere Wahrscheinlichkeiten
selbstanpassende software1

Selbstanpassende Software

Packen in Echtzeit

slide38

Gliederung

  • Beispielanwendung
  • Systemübersicht
  • der Syntheseprozess
  • Fehleranalysen
  • Blick in die Zukunft
die modellumgebung
Die Modellumgebung

Die Modellumgebung besteht aus:

  • Puma Roboterarm
  • Fliessband
  • unterschiedlichen geometrischen Objekten
  • Kisten für Objekte
  • Schalter
  • Alarmleuchte
architektur bersicht von sa circa
Architekturübersicht von SA-CIRCA

Adaptive Mission Planner

SA-CIRCA ist die zentrale Komponente

  • Adaptive Mission Planner (AMP)
  • Controller Synthesis Module (CSM)
  • Real Time Subsystem (RTS)

Controller Synthesis Module

Real Time System

Real World

adaptive mission planner i
Adaptive Mission Planner (I)

Der Adaptive Mission Planner (AMP) ist für folgendes zuständig:

  • Analyse von zeitlich längeren Prozessen

(im Beispiel betrachtet er den Vorgang vom Teile auf das Band legen bis zum Verpacken)

  • Analyse von Problemstrukturen

(Auswahl des geeigneten Verpackungsalgorithmus)

adaptive mission planner ii

Ausführbares TAP Schedule

Adaptive Mission Planner (II)

Mission

AMP Synthesis Control

(Negotiation)

AMP

Problem Konfiguration

Controller Synthesis Module

controller synthesis module i
Controller Synthesis Module (I)

Hauptaufgabe des CSM ist das Erstellen von Handlungsplänen.

Das CSM ist aus den Komponenten:

  • State Space Planner (SSP)
  • Scheduler
  • TAP Compiler

aufgebaut.

controller synthesis module ii

Problem Konfiguration

Ausführbares TAP Schedule

Controller Synthesis Module (II)

Controller Synthesis Module

Planner

TAP Compiler

Scheduler

ssp state space planner
SSP – State Space Planner
  • ist Bestandteil des CSM
  • State Space Planner entwirft Handlungsvorschriften
  • steht in Kommunikation mit dem AMP und RTS
  • Handlungsvorschriften werden vom RTS umgesetzt
scheduler
Scheduler
  • der Scheduler ist Bestandteil vom CSM
  • verwaltet die TAPs
  • die TAPs werden eingeordnet um vom RTS bearbeitet zu werden
das real time subsystem

Controller Synthesis Module

Real Time System

Real World

Das Real Time Subsystem
  • ist die Schnittstelle zur realen

Welt

  • ist für die Steuerung und

Wahrnehmung zuständig

  • Steuerung erfolgt in Hard

Realtime

  • führt TAPs aus
transition description
Transition Description
  • werden vom Benutzer eingegeben
  • damit wird ein zu steuerndes System beschrieben
  • ein Transition Description definiert Ereignisse um zu einem Endzustand zu kommen.
  • es dient als Grundlage für die Steuerung eines Vorgangs
transition description ereignisarten
Transition Description - Ereignisarten
  • Action Transitions:

stellen mögliche Aktionen dar, die auch ein Resultat ergeben.

  • Event Transitions:

stellen unkontrollierbare und unverzögerbare Ereignisse dar

transition description ereignisarten1
Transition Description - Ereignisarten
  • Temporal Transitions:

sind nicht kontrollierbare Umgebungsprozesse, die sehr kurz sind

  • Reliable Temporal Transitions:

stellen Prozesse dar, die garantiert stattfinden werden und etwas Zeit in Anspruch nehmen

  • Goals:

beschreiben Zustandsziele

transition descriptions beispiel
Transition Descriptions - Beispiel

Teilmodellierung der Puma-Umgebung

EVENT emergency-alert ;; Emergency light goes on.

PRECONDS: ((emergency F))

POSTCONDS: ((emergency T))

TEMPORAL emergency-failure ;; Fail if don‘t attend to

PRECONDS: ((emergency T)) ;; light by deadline

POSTCONDS: ((failure T))

ACTION push-emergency-button ;; Pushing button cancels ;; emerg.

PRECONDS: ((part-in-gripper F)) ;; Requires ;;empty gripper

POSTCOND: ((emergency F))

WORST-CASE-EXEC-TIME: 2.0 [seconds]

erstellen von handlungspl nen

Transition Description

NFA

TAP wird erstellt

Erstellen von Handlungsplänen
  • der SSP generiert aus den Transition Descriptions einen NFA
  • aus dem NFA werden Test Action Pairs (TAPs) erstellt, die vom RTS ausgeführt werden
triggering tradeoffs
Triggering Tradeoffs
  • ist ein Handlungsplan nicht durchführbar, kommt es zu TriggeringTradeoffs
  • dabei werden Handlungspläne korrigiert
verschiedene arten von tradeoffs
Verschiedene Arten von Tradeoffs
  • Folgende Tradeoffs werden unterschieden:
    • Der SSP findet keinen durchführbaren Handlungsplan
    • Wenn der SSP zu lange braucht, um einen Handlungsplan zu erstellen, kommt es zum Abbruch der Generierungsphase
verschiedene arten von tradeoffs1

SSP

Real Time System

neuer Handlungsplan

Verschiedene Arten von Tradeoffs
  • Es wird ein Handlungsplan erstellt, der Scheduler kann dafür aber keinen durchführbaren Handlungsablauf erstellen
  • Der Handlungsplan ist erstellbar, aber das RTS ist nicht leistungsfähig genug

Backtracking

  • der SSP muss einen modifizierten Handlungsplan erstellen
erstellen eines neuen handlungsplans

Adaptive Mission Planner

neuer Handlungsplan

neuer Plan

SSP

Erstellen eines neuen Handlungsplans

Der AMP erstellt einen neuen Plan und der CSM generiert daraus einen neuen Handlungsplan.

=> Die Tradeoffs können durch gewöhnliche Prozeduren ausgeführt werden

ignorieren eines ttf

OK

Threatened

Safe

Failure

Ignorieren eines TTF
  • TTF bedeutet Temporal Transition to Failure
  • TTFs führen zu Fehlern
  • Ein wirkungsvoller Tradeoff ist es Temporal

Transitions zu ignorieren

besonderer effekte beim ignorieren eines ttf
Besonderer Effekte beim Ignorieren eines TTF
  • Beim Ignorieren eines TTFs kann ein Ereignis trotzdem modelliert werden

aber: ein möglicher Fehler kann nicht mehr überwacht werden

  • andere mögliche Fehler können bemerkt werden
performanzeffekte durch das ignorieren eines ttf
Performanzeffekte durch das Ignorieren eines TTF
  • wird ein alert/minute Grenzwert überschritten, dürfte nicht mehr gescheduled werden

Abhilfe: Eine pickup-part-from-conveyor Aktion wird durch ein if-time TAP modelliert, ohne part-falls-off-conveyorTTF

  • das System bleibt schnell, auch wenn Teile verloren gehen, da ein Herunterfallen der Teile ignoriert wird
  • unter Stressbedingungen bleibt das System leistungsfähig und arbeitet weiter
performanzeffekte durch das ignorieren eines ttf1
Performanzeffekte durch das Ignorieren eines TTF
  • Das Systemverhalten nach dem Ignorieren des part-falls-off-conveyor TTF
nichtbeachten eines event transition
Nichtbeachten eines Event Transition
  • Vorteile sind:
    • Die Planungszeit wird reduziert
    • Die Anzahl der TAPs wird weniger
    • Das Scheduling wird vereinfacht (durch die Reduzierung der TAPs)

=> Es erfolgt eine Geschwindigkeitsoptimierung des Systems

  • Nachteil:
    • weggelassene Transitionen werden nicht mehr beachtet
die modifikation eines action transitition
Die Modifikation eines Action Transitition
  • Der AMP kann Action Transitions modifizieren
  • Beispiel ist die Veränderung des place-part-in-box Operators
  • Teile können so unterschiedlich schnell und sauber verpackt werden
place part in box operatoren
Place-part-in-box Operatoren
  • Das RTS hat zwei Versionen des place-part-in-box Operators
    • Fine-motion Version
    • Coarse-motion Version
place part in box operatoren1
Place-part-in-box Operatoren
  • Fine-motion Version:
    • die Teile können sehr eng zusammengepackt werden
    • benötigt relativ lange
  • Coarse-motion Version
    • schneller
    • schlechter gepackte Kisten
weitere anwendungen von sa circa
Weitere Anwendungen von SA-CIRCA
  • SA-CIRCA wird in Multi-Aircraft Systemen verwendet
  • dient zur autonomen Steuerung von Flugzeugen
aussichten der pssp
Aussichten - der PSSP

An der Universität von Michigan wird am Probabilistic State Space Planner (PSSP) gearbeitet

  • es werden wahrscheinlichkeitsbezogene Teilpläne erstellt
  • das RTS ist beschränkender Faktor
  • bereits bei autonomen Flugzeugen getestet
schlu bemerkungen
Schlußbemerkungen
  • Nachteile selbstanpassender Software:
    • selbstanpassende Software ist nicht so leicht verständlich wie konventionelle Programme
    • kann man s.S. Dinge wie Lenken von Raketen anvertrauen?
    • Robertson meint ja, denn:

Trifft konventionelle Lenksoftware auf Fehler => Totalausfall, während s.S. den Fehler mit größerer Wahrscheinlichkeit auffängt, d.h. s.S. ist robuster

schlu bemerkungen1
Schlußbemerkungen
  • zu entwickeln/erforschen ist noch:
    • Test- und/oder Beweisverfahren für s.S.

=> mehr Vertrauen, besseres Verständnis

    • Erforschung der Mächtigkeit/Möglichkeiten selbstanpassender Software
schlu bemerkungen2
Schlußbemerkungen
  • Fazit:
    • s.S. ist guter vielversprechender Ansatz, der jedoch noch in Kinderschuhen steckt
    • noch viel Forschung in diesem Bereich notwendig, dann ggf. größere Akzeptanz, bisher „Sache des Glaubens“ (Robertson)
    • jedoch: DARPA, Air Force und NASA arbeiten bereits intensiv an Erforschung dieses Ansatzes => gute Zukunftsprognose
ad