Die Präsentation wird geladen. Bitte warten

Die Präsentation wird geladen. Bitte warten

Johannes Schick & Wolfram Urich Selbstanpassende Software.

Ähnliche Präsentationen


Präsentation zum Thema: "Johannes Schick & Wolfram Urich Selbstanpassende Software."—  Präsentation transkript:

1

2 Johannes Schick & Wolfram Urich Selbstanpassende Software

3 2 Referatsaufbau Interpretation von Luftaufnahmen Packen in Echtzeit

4 Selbstanpassende Software Interpretation von Luftaufnahmen

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

6 5 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

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

8 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

9 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

10 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

11 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

12 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:

13 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

14 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

15 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

16 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

17 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

18 17

19 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

20 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)

21 20 Pool von Agenten Herstellen eines Bild- interpretations und -segmentations- kreislaufs Segmentieren und Interpretieren der Bilder Auswer- tung Der Bilderkorpus: Eine Datenbank mit Bildern und Ex- pertenanmerkungen Bilderwissen Bilder Interpretation

22 21 GRAVA-Architektur Innovationen der GRAVA-Architektur: Meta-Agenten produzieren Agentenkreisläufe zur Bildsegmentation und –interpretation benutzt Minimum Description Length- Ansatz

23 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

24 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

25 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

26 25 Ende wenn keine neuen Regionen oder keine Reduktion der Beschreibungs- länge 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 3) Für jede Region Versuche die Beschreibungs- länge durch das Verschmelzen mit Nachregionen zu mini- mieren Start Initialisiere das gesamte Bild als eine einzige Region

27 26 GRAVA-Architektur 3 Regionen: 1x Hintergrund und 2x See Beachte: Inseln gehören noch zum Hintergrund

28 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)

29 28 GRAVA-Architektur neue Seeregion oben links (Stufe 1) durch Anwenden der Stufen 1-3 ist große Seeregion in mehrere Regionen aufgesplittet worden

30 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

31 30 GRAVA-Architektur Repräsentation des Bildes Grenzpixel Pixel- aufzählung : Region : Art der Region : Startpixel der Grenze : Anzahl der Grenzpunkte

32 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

33 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

34 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

35 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: Verschleierung

36 35 Regionenidentifikation Regel W. See Felder 1 Felder 2 Sumpf 1 Sumpf 2 Fel- der 3 Stadt Straße Fluß

37 36 Regionenidentifikation aus Korpus werden Vielzahl von Regeln gelernt kommt Regel mehrfach vor wird Wahrscheinlichkeit gemittelt => realitätstreuere Wahrscheinlichkeiten

38 Selbstanpassende Software Packen in Echtzeit

39 38 Beispielanwendung Systemübersicht der Syntheseprozess Fehleranalysen Blick in die Zukunft Gliederung

40 39 Die Modellumgebung Die Modellumgebung besteht aus: Puma Roboterarm Fliessband unterschiedlichen geometrischen Objekten Kisten für Objekte Schalter Alarmleuchte

41 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 System Real World

42 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)

43 42 Adaptive Mission Planner (II) Controller Synthesis Module Ausführbares TAP Schedule Problem Konfiguration AMP Synthesis Control (Negotiation) Mission AMP

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

45 44 Controller Synthesis Module (II) Controller Synthesis Module TAP Compiler Scheduler Problem Konfiguration Ausführbares TAP Schedule Planner

46 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

47 46 Scheduler der Scheduler ist Bestandteil vom CSM verwaltet die TAPs die TAPs werden eingeordnet um vom RTS bearbeitet zu werden

48 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

49 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

50 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

51 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

52 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 dont 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]

53 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

54 53 Triggering Tradeoffs ist ein Handlungsplan nicht durchführbar, kommt es zu Triggering Tradeoffs dabei werden Handlungspläne korrigiert

55 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

56 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

57 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 SSP Adaptive Mission Planner neuer Handlungsplan

58 57 Ignorieren eines TTF TTF bedeutet Temporal Transition to Failure TTFs führen zu Fehlern OKThreatened Failure Safe Ein wirkungsvoller Tradeoff ist es Temporal Transitions zu ignorieren

59 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

60 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

61 60 Performanzeffekte durch das Ignorieren eines TTF Das Systemverhalten nach dem Ignorieren des part-falls-off-conveyor TTF

62 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

63 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

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

65 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

66 65 Weitere Anwendungen von SA-CIRCA SA-CIRCA wird in Multi-Aircraft Systemen verwendet dient zur autonomen Steuerung von Flugzeugen

67 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

68 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

69 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

70 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

71 70


Herunterladen ppt "Johannes Schick & Wolfram Urich Selbstanpassende Software."

Ähnliche Präsentationen


Google-Anzeigen