1 / 70

Selbstanpas sen de Software

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

salene
Download Presentation

Selbstanpas sen de Software

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. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript


  1. Selbstanpassende Software Johannes Schick & Wolfram Urich

  2. Referatsaufbau • Interpretation von Luftaufnahmen • Packen in Echtzeit

  3. Selbstanpassende Software Interpretation von Luftaufnahmen

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

  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

  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. 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 Bild- interpretations und -segmentations- kreislaufs Segmentieren und Interpretieren der Bilder Der Bilderkorpus: Eine Datenbank mit Bildern und Ex- pertenanmerkungen Bilderwissen Interpretation Auswer- tung

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

  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 Beschreibungs- länge 3) Für jede Region Versuche die Beschreibungs- länge durch das Verschmelzen mit Nachregionen zu mini- mieren

  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 Grenzpixel Pixel- aufzählung : Region : Art der Region : Startpixel der Grenze : Anzahl der Grenzpunkte

  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 • 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

  33. 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:

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

  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

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

  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. Ausführbares TAP Schedule Adaptive Mission Planner (II) Mission AMP Synthesis Control (Negotiation) AMP Problem Konfiguration Controller Synthesis Module

  42. 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. Problem Konfiguration Ausführbares TAP Schedule Controller Synthesis Module (II) Controller Synthesis Module Planner TAP Compiler Scheduler

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

  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

More Related