Transcript SA-CIRCA

Selbstanpassende Software
Johannes Schick
&
Wolfram Urich
Referatsaufbau
 Interpretation von
Luftaufnahmen
Packen in Echtzeit
2
Selbstanpassende Software
Interpretation von
Luftaufnahmen
Gliederung




Ansatz selbstanpassender Software
Typ-2 Berechnungen
Die GRAVA-Softwarearchitektur
Identifikation von Regionen
4
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
5
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,...
6
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
7
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
8
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
9
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
10
Typ-2 Berechnungen
 Klassische Informatik befaßt sich nur mit Typ1 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:
11
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
12
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
13
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
14
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
15
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
16
17
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
18
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)
19
Pool von
Agenten
Bilder
Herstellen eines Bildinterpretations und
-segmentationskreislaufs
Der Bilderkorpus:
Eine Datenbank mit
Bildern und Expertenanmerkungen
Segmentieren
und Interpretieren
der Bilder
Bilderwissen
Interpretation
Auswertung
20
GRAVA-Architektur
 Innovationen der GRAVA-Architektur:
 Meta-Agenten produzieren
Agentenkreisläufe zur Bildsegmentation
und –interpretation
 benutzt Minimum Description LengthAnsatz
21
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
22
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
23
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
24
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
Beschreibungslänge
3) Für jede Region
Versuche die Beschreibungslänge durch das Verschmelzen
mit Nachregionen zu minimieren
25
GRAVA-Architektur
 3 Regionen: 1x
Hintergrund und 2x
See
 Beachte: Inseln
gehören noch zum
Hintergrund
26
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)
27
GRAVA-Architektur
 neue Seeregion
oben links (Stufe 1)
 durch Anwenden der
Stufen 1-3 ist große
Seeregion in
mehrere Regionen
aufgesplittet worden
28
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
29
GRAVA-Architektur
 Repräsentation des Bildes
R0
A2
R1
S2
G2
R2
R3
Grenzpixel

Rn1
Pixelaufzählung
Ri : Region
G i : Anzahl der Grenzpunkte
Ai : Art der Region
Si : Startpixel der Grenze
30
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
31
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
32
Regionenidentifikation
En


I1

Im
E4
I2
...
E3
E1
E2
 es werden Regeln aus Bildern
(aus dem Korpus) extrahiert, um
Zusammenhänge zwischen
Regionen miteinzubeziehen
 Region1 wird als Tripel
beschrieben:
Region1, I1, I 2 ,, I m , E1, E2 ,, En 
 Repräsentation der Regionen ist
invariant bzgl. Rotation
 sie kann mit „Verschleierung“
umgehen:
 Bildrand
 Nebel und Wolken
33
Regionenidentifikation


Verschleierung

E4

I2
E3
Im
I1
E2
En
E1
 Verschleierung kann
mehrere interne und
externe Regionen
überdecken => „*“
 Bildinterpretation sollte
Wahrscheinlichkeiten für
Inhalt der verdeckten
Regionen liefern
 Region1 wird
beschrieben durch
Regel:
Region1, I1, I 2 ,*, E1, E2 , E3 , E4 ,*
34
Regionenidentifikation
Felder 2
Felder
3
Felder 1
Straße
1
Sumpf
2
W.
Feld (1), See,*, Straße,*
0.33
Feld (3), *, *,Straße,Stadt, Fluß
0.33
Feld (2), *, *,Fluß, Sumpf 
Stadt
Sumpf
Regel
See
0.33
Sumpf (1), *, *,Feld, Fluß
0.50
Sumpf (2), *, *,Fluß, Stadt,Straße 0.50
Fluß, *, *,Feld,Stadt,Sumpf 
1.00
Stadt,  , Feld,Straße,Sumpf,Fluß 1.00
See,  , Feld
1.00
35
Regionenidentifikation
 aus Korpus werden Vielzahl von Regeln
gelernt
 kommt Regel mehrfach vor wird
Wahrscheinlichkeit gemittelt =>
realitätstreuere Wahrscheinlichkeiten
36
Selbstanpassende Software
Packen in Echtzeit
Gliederung





Beispielanwendung
Systemübersicht
der Syntheseprozess
Fehleranalysen
Blick in die Zukunft
38
Die Modellumgebung
Die Modellumgebung besteht aus:
 Puma Roboterarm
 Fliessband
 unterschiedlichen geometrischen
Objekten
 Kisten für Objekte
 Schalter
 Alarmleuchte
39
Architekturübersicht
von SA-CIRCA
SA-CIRCA ist die
zentrale Komponente
 Adaptive Mission
Planner (AMP)
 Controller Synthesis
Module (CSM)
 Real Time Subsystem
(RTS)
Real World
Adaptive
Mission
Planner
Controller
Synthesis
Module
Real
Time
System
40
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)
41
Adaptive Mission
Planner (II)
Mission
AMP Synthesis Control
(Negotiation)
AMP
Problem Konfiguration
Controller
Synthesis
Module
42
Ausführbares TAP Schedule
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.
43
Controller Synthesis
Module (II)
Problem Konfiguration
Controller Synthesis Module
Planner
TAP Compiler
Scheduler
44
Ausführbares TAP Schedule
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
45
Scheduler
 der Scheduler ist Bestandteil vom CSM
 verwaltet die TAPs
 die TAPs werden eingeordnet um vom
RTS bearbeitet zu werden
46
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
Real World
Controller
Synthesis
Module
Real Time
System
47
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
48
Transition Description Ereignisarten
 Action Transitions:
stellen mögliche Aktionen dar, die auch ein
Resultat ergeben.
 Event Transitions:
stellen unkontrollierbare und unverzögerbare
Ereignisse dar
49
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
50
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]
51
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
Transition
Description
NFA
TAP wird
erstellt
52
Triggering Tradeoffs
 ist ein Handlungsplan nicht
durchführbar, kommt es zu Triggering
Tradeoffs
 dabei werden Handlungspläne korrigiert
53
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
54
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
Real
Time
System
SSP
neuer Handlungsplan
 der SSP muss einen modifizierten
Handlungsplan erstellen
55
Erstellen eines neuen
Handlungsplans
Der AMP erstellt einen neuen Plan und der
CSM generiert daraus einen neuen
Handlungsplan.
neuer Handlungsplan
neuer Plan
Adaptive
Mission
Planner
SSP
=> Die Tradeoffs können durch gewöhnliche
Prozeduren ausgeführt werden
56
Ignorieren eines TTF
 TTF bedeutet Temporal Transition to
Failure
 TTFs führen zu Fehlern
OK
Threatened
Safe
Failure
 Ein wirkungsvoller Tradeoff ist es Temporal
Transitions zu ignorieren
57
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
58
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-conveyor TTF
 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
59
Performanzeffekte durch das
Ignorieren eines TTF
 Das Systemverhalten nach dem Ignorieren
des part-falls-off-conveyor TTF
8
fallengelassene Teile
7
6
5
4
3
2
1
0
0
2
4
6
8
10
Teile pro Minute
12
14
16
18
60
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
61
Die Modifikation eines
Action Transitition
 Der AMP kann Action Transitions
modifizieren
 Beispiel ist die Veränderung des placepart-in-box Operators
 Teile können so unterschiedlich schnell
und sauber verpackt werden
62
Place-part-in-box
Operatoren
 Das RTS hat zwei Versionen des placepart-in-box Operators
 Fine-motion Version
 Coarse-motion Version
63
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
64
Weitere Anwendungen
von SA-CIRCA
 SA-CIRCA wird in
Multi-Aircraft
Systemen
verwendet
 dient zur autonomen
Steuerung von
Flugzeugen
65
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
66
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
67
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
68
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
69
70