Johannes Schick

&

Wolfram Urich

Selbstanpassende Software

2

Referatsaufbau

Interpretation von Luftaufnahmen

Packen in Echtzeit

Selbstanpassende Software

Interpretation von Luftaufnahmen

4

Gliederung

Ansatz selbstanpassender Software Typ-2 Berechnungen Die GRAVA-Softwarearchitektur Identifikation von Regionen

5

Ansatz

DefinitionSelbstanpassende 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

6

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,...

7

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

8

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

9

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

10

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

11

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:

12

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

13

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

14

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

15

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

16

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

17

18

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

19

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)

20

Pool von Agenten

Herstellen eines Bild-interpretations und

-segmentations-kreislaufs

Segmentierenund Interpretieren

der Bilder

Auswer-tung

Der Bilderkorpus:Eine Datenbank mit

Bildern und Ex-pertenanmerkungen

Bilderwissen

Bilder

Interpretation

21

GRAVA-Architektur

Innovationen der GRAVA-Architektur: Meta-Agenten produzieren

Agentenkreisläufe zur Bildsegmentation und –interpretation

benutzt Minimum Description Length-Ansatz

22

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

23

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

24

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

25

Endewenn keine neuen

Regionen oder keineReduktion der Beschreibungs-

länge

1) Für jede RegionFinde Agenten, die neue

Regionen entdecken, welcheihrerseits einige/alle Pixel der

Region fortnehmen; dies reduziert die Beschreibungslänge

2) Für jede RegionVersuche die Beschreibungslänge

durch das Abgeben von Pixelnan Nachbar- bzw. innere Regionen zu verkürzen

3) Für jede RegionVersuche die Beschreibungs-

länge durch das Verschmelzenmit Nachregionen zu mini-

mieren

StartInitialisiere das gesamte Bild als

eine einzige Region

26

GRAVA-Architektur

3 Regionen: 1x Hintergrund und 2x See

Beachte: Inseln gehören noch zum Hintergrund

27

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)

28

GRAVA-Architektur

neue Seeregion oben links (Stufe 1)

durch Anwenden der Stufen 1-3 ist große Seeregion in mehrere Regionen aufgesplittet worden

29

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

30

GRAVA-Architektur

Repräsentation des Bildes

GrenzpixelPixel-

aufzählung

2R0R 1R 1nR3R

2A 2G2S

: Region: Art der Region: Startpixel der Grenze

iR

iA

iS

iG : Anzahl der Grenzpunkte

31

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

32

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

33

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

1I

nE

4E 3E

2E

1E

2I

mI ...

nm EEEIII ,,,,,,,,1Region 2121

34

Regionenidentifikation

Verschleierung kann mehrere interne und externe Regionen überdecken => „*“

Bildinterpretation sollte Wahrscheinlichkeiten für Inhalt der verdeckten Regionen liefern

Region1 wird beschrieben durch Regel:

nE

3E 2E

1E

mI

2I1I

,*,,,,,*,,1Region 432121 EEEEII

4E

Verschleierung

35

Regionenidentifikation

Regel W.

See

Felder 1Felder 2

Sumpf 1

Sumpf 2

Fel-der3

Stadt Straße

Fluß

SumpfStadt,Feld,*,,*,Fluß

StraßeStadt,Fluß,*,,*,(2) Sumpf

Feld,,See

FlußSumpf,Straße,Feld,,,Stadt

*Straße,,,*See,(1) Feld

Fluß Stadt, Straße,*,,*,(3) Feld

SumpfFluß,*,,*,(2) Feld

FlußFeld,*,,*,(1) Sumpf

33.0

33.0

33.0

50.0

50.0

00.1

00.1

00.1

36

Regionenidentifikation

aus Korpus werden Vielzahl von Regeln gelernt

kommt Regel mehrfach vor wird Wahrscheinlichkeit gemittelt => realitätstreuere Wahrscheinlichkeiten

Selbstanpassende Software

Packen in Echtzeit

38

Beispielanwendung Systemübersicht der Syntheseprozess Fehleranalysen Blick in die Zukunft

Gliederung

39

Die Modellumgebung

Die Modellumgebung besteht aus: Puma Roboterarm Fliessband unterschiedlichen geometrischen

Objekten Kisten für Objekte Schalter Alarmleuchte

40

Architekturübersicht von SA-CIRCA

SA-CIRCA ist die zentrale Komponente

Adaptive Mission Planner (AMP)

Controller Synthesis Module (CSM)

Real Time Subsystem (RTS)

Adaptive Mission Planner

Controller Synthesis Module

Real Time

SystemReal World

41

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)

42

Adaptive Mission Planner (II)

Controller Synthesis Module

Ausführbares TAP Schedule

Problem Konfiguration

AMP Synthesis Control(Negotiation)

Mission

AMP

43

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.

44

Controller Synthesis Module (II)

Controller Synthesis Module

TAP Compiler

Scheduler

Problem Konfiguration

Ausführbares TAP Schedule

Planner

45

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

46

Scheduler

der Scheduler ist Bestandteil vom CSM verwaltet die TAPs die TAPs werden eingeordnet um vom

RTS bearbeitet zu werden

47

Das Real Time Subsystem

Controller Synthesis Module

Real Time System

Real World

ist die Schnittstelle zur realen

Welt ist für die Steuerung und

Wahrnehmung zuständig Steuerung erfolgt in Hard

Realtime führt TAPs aus

48

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

49

Transition Description - Ereignisarten Action Transitions:

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

Event Transitions:stellen unkontrollierbare und unverzögerbare Ereignisse dar

50

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

51

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 toPRECONDS: ((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]

52

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

53

Triggering Tradeoffs

ist ein Handlungsplan nicht durchführbar, kommt es zu Triggering Tradeoffs

dabei werden Handlungspläne korrigiert

54

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

55

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

56

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

neuer Plan

SSPAdaptive Mission Planner

neuer Handlungsplan

57

Ignorieren eines TTF

TTF bedeutet Temporal Transition to Failure

TTFs führen zu Fehlern

OK Threatened

Failure

Safe

Ein wirkungsvoller Tradeoff ist es Temporal Transitions zu ignorieren

58

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

59

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

60

Performanzeffekte durch das Ignorieren eines TTF

Das Systemverhalten nach dem Ignorieren des part-falls-off-conveyor TTF

0

1

2

3

4

5

6

7

8

0 2 4 6 8 10 12 14 16 18

Teile pro Minute

falle

ngel

asse

ne T

eile

61

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

62

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

63

Place-part-in-box Operatoren

Das RTS hat zwei Versionen des place-part-in-box Operators Fine-motion Version Coarse-motion Version

64

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

65

Weitere Anwendungen von SA-CIRCA

SA-CIRCA wird in Multi-Aircraft Systemen verwendet

dient zur autonomen Steuerung von Flugzeugen

66

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

67

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

68

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

69

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

70