Selbstanpas sen de software
Download
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)


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


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


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