Crowd Sensing und Social Data Mining mit Mobilen Agenten

Agenten

Motivation

• Crowdsensing ist verteilte Datenverarbeitung

• Verteilte Datenverarbeitung bedeutet verteilte Kommunikation zwischen Prozessen

• Traditionelle verteilte Netzwerke wie das Internet der Dinge (IoT) müssen mit einer Vielzahl von Kommunikationsprotokollen und Netzwerkstrukturen umgehen können → Stark heterogene Systeme

• Datenrepräsentation ist eine weitere Hürde in solchen verteilten Systemen

• Häufig HTTP basierte Klienten-Server Kommunikation (zentrale Serverinstanz)

Motivation

Agenten

Agenten besitzen eine Vielzahl von Fähigkeiten, die sie von klassischen Programmen unterscheiden - obwohl Agenten auch Programme sein können!

Merkmale

• Fähigkeit zu eigenständiger Aktivität (Nicht Nutzeraktiviert)

• Autonomes, “selbstbestimmtes” Verhalten (Nicht durch zentrale Instanz gesteuert)

• Fähigkeit zum selbstständigen Schlussfolgern (Umgang mit unsicheren Wissen)

• Flexibles und rationales Verhalten (Adaptivität an veränderliche Weltbedingungen)

• Fähigkeit zu Kommunikation und Interaktion (Synchronisation)

• Kooperatives oder konkurrierendes Verhalten (Lösung von Wettbewerbskonflikten)

• Fähigkeit zur ziel- und aufgabenorientierten Koordination (Kooperation)

Agenten

• Man unterscheidet zwischen realen und virtuellen Welten;
• Agenten können natürliche (reale) Welten abbilden oder in realen Welten agieren

Agenten und Weltumgebung

Agentenmodell

• Ein Agent in seiner Umgebung nimmt sensorische Eingaben aus der Umgebung auf und produziert Ausgabe-Aktionen, die ihn und die Umgebung beeinflussen.

• Die Interaktion ist gewöhnlich fortlaufend und nicht-terminierend!

Umgebung: Raum in Gebäude
Sensor: Temperatur T
Aktor:  Heizung
 
Verhalten:
(1) Temperatur zu niedrig → Heizung an
(2) Temperatur angenehem →  Heizung aus

Agenten und Weltumgebung

Reaktive und Zustandsbasierte Agenten

• Reaktive und zustandsbasierte Agenten führen einen Zyklus durch:
  • Perzeption ⇒ Verabeitung ⇒ Zustandsänderung ⇒ Entscheidung ⇒ Aktion

ATG Modell

Zustandsbasierter Agent

• Besteht aus: (1) Körpervariablen (2) Kontrollzustand und Verhalten

Aktivität und Zustand

• Das Verhalten eines aktivitätsbasierten Agenten ist durch einen Agentenzustand gekennzeichnet, der durch Aktivitäten verändert wird.

• Aktivitäten verarbeiten Wahrnehmungen, planen Aktionen und führen Aktionen aus, die den Steuerungs- und Datenzustand des Agenten ändern.

• Aktivitäten und Übergänge zwischen Aktivitäten werden durch einen Aktivitätsübergangsgraphen (Activity Transition Graph, ATG) dargestellt.

• Die Übergänge starten Aktivitäten in der Regel abhängig von der Auswertung von Agentendaten (Körpervariablen), die den Datenzustand des Agenten repräsentieren.

ATG Modell

ATG Modell

• Ein Aktivitätsübergangsgraph, der mit Agentenklassen assoziiert ist, besteht aus einer Menge von Aktivitäten 𝔸 = {A₁, A₂, ..} und einer Menge von Übergängen 𝕋 = {T₁ (C₁), T₂ (C₂), ..}, die die Kanten des gerichteten Graphen darstellen.

• Die Ausführung einer Aktivität, die selbst aus einer Folge von Aktionen und Berechnungen besteht, ist mit dem Erreichen eines Unterzieles oder das Erfüllen einer Voraussetzung verknüpft, um ein bestimmtes Ziel zu erreichen, z. B. Sensordatenverarbeitung und Verteilung von Informationen.

• Normalerweise werden Agenten verwendet, um komplexe Aufgaben zu zerlegen basierend auf der Zerlegung durch MAS.

• Agenten können ihr Verhalten basierend auf Lern- und Umgebungsänderungen oder durch Ausführen einer bestimmten Unteraufgabe mit nur einer Untermenge des ursprünglichen Agentenverhaltens ändern → Dynamische ATG.

ATG Modell

• Das ATG-Verhaltensmodell ist eng mit der Interaktion von Agenten mit deren Umgebung verbunden, hier hauptsächlich durch
  • Den Austausch von Daten unter Verwendung einer Tupelraum-Datenbank;
  • Durch Migration; und durch
  • Die Weitergabe von Nachrichten zwischen Agenten mittels Signalen.
  • Replikation und Instantiierung von Agenten

DATG Modell

• Ein ATG beschreibt das vollständige Agentenverhalten.

• Jedes Unterdiagramm und jeder Teil des ATG kann einem Unterklasseverhalten eines Agenten zugeordnet werden.

• Daher führt das Modifizieren der Menge von Aktivitäten 𝔸 und Übergängen 𝕋 des ursprünglichen ATG zu mehreren Unter- und Oberverhaltensweisen, die Algorithmen implementieren, um verschiedene unterschiedliche Ziele zu erfüllen.

• Die Rekonfiguration der Aktivitäten führt zu einer Menge von Aktivitätsmengen 𝔸^* = {𝔸_i ⊂ 𝔸, 𝔸_j ⊂ 𝔸, 𝔸_k ⊃ 𝔸, ..}, die von der ursprünglichen Menge 𝔸 abgeleitet sind, und die Modifikation oder Rekonfiguration von Übergängen 𝕋^* = {𝕋₁ ⊂ 𝕋, 𝕋₂ ⊂ 𝕋, ..} ermöglicht die dynamische ATG-Zusammensetzung (Komposition) und Agentenunterklassifizierung zur Laufzeit,

DATG Modell

Beispiel eines Agenten

ATG eines einfachen Umfrageagenten mit Unterklassen (master, requester, worker)

Agentenklassen

Eine Agentenklasse beschreibt ein bestimmtes Verhalten eines Agenten mittels eines ATG und einer Menge von Körpervariablen.

• Von einer Klasse können zur Laufzeit Agenten instantiiert (erzeugt) werden.

Verhalten

Eine bestimmte Agentenklasse AC_i bezieht sich auf das zuvor eingeführte ATG Modell, dass das Laufzeitverhalten und die von Agenten ausgeführten Aktion definiert.

Wahrnehmung

Ein Agent interagiert mit seiner Umgebung, indem er eine Datenübertragung unter Verwendung eines einheitlichen Tupelraums mit einer koordinierten datenbankähnlichen Schnittstelle durchführt.

Daten aus der Umgebung beeinflussen das folgende Verhalten und die Aktion eines Agenten. Daten, die an die Umgebung (z.B. die Datenbank) weitergegeben werden, beeinflussen das Verhalten anderer Agenten.

Agentenklassen

Speicher

Zustandsbasierte Agenten führen Berechnungen durch, indem sie Daten ändern. Da Agenten als autonome Datenverarbeitungseinheiten betrachtet werden können, werden sie hauptsächlich private Daten modifizieren, und ein Berechnungsergebnis, dass diese Daten verwendet, in die Umgebung übertragen.

Daher enthält jeder Agent und jede Agentenklasse eine Menge von Körpervariablen 𝕍 = {v₁:typ₁, v₂: typ₂, ..}, die durch Aktionen in Aktivitäten modifiziert und in Aktivitäten und Übergangsausdrücken gelesen werden.

Agentenklassen

Parameter

Agenten können zur Laufzeit von einer bestimmten Agentenklasse instantiiert werden, die Agenten mit gleichen anfänglichen Steuerungs- und Datenzuständen erstellt.

Um einzelne Agenten zu unterscheiden (Individuen zu erzeugen), wird eine externe sichtbare Parametermenge ℙ = {p₁: typ₁, p₂: typ₂, ..} hinzugefügt, die die Erstellung verschiedener Agenten bezüglich des Datenzustands ermöglicht. Innerhalb einer Agentenklasse werden Parameter wie Variablen behandelt.

Agentenklassen

Eine Agentenklasse AC_i ist daher zunächst definiert durch das folgende Mengentupel:

Agentenklassen

Multiagentensysteme

Agentenklassen

Tupelräume

• Tupel-Räume stellen ein assoziiertes Shared-Memory-Modell dar, wobei die gemeinsam genutzten Daten als Objekte mit einer Reihe von Operationen betrachtet werden, die den Zugriff der Datenobjekte unterstützen

• Tupel sind in Räumen organisiert, die als abstrakte Berechnungsumgebungen betrachtet werden können.

• Ein Tupelraum verbindet verschiedene Programme, die verteilt werden können, wenn der Tupel-Space oder zumindest sein operativer Zugriff verteilt ist.

  • Oder: Mobile Agenten als Tupel Verteiler!

• Das Tupelraum Organisations- und Zugangsmodell bietet generative Kommunikation, d.h. Datenobjekte können in einem Raum durch Prozesse mit einer Lebensdauer über das Ende des Erzeugungsprozesses hinaus gespeichert werden.

• Ein bekanntes Tupelraum-Organisations- und Koordinationsparadigma ist Linda [GEL85].

Tupelräume

Tupelräume

• Kommunikation von Agenten über Tupelräume ist eine Koordinationssprache.

Tupelräume - Datenmodell

• Die Daten sind mit Tupeln organisiert.

• Ein Tupel ist eine lose gekoppelte Verbindung einer beliebigen Anzahl von Werten beliebiger Art /Typ/

• Ein Tupel ist ein Wert und sobald es in einem Tupelraum gespeichert ist, ist es persistent.

• Tupeltypen ähneln den Datenstrukturtypen, sie sind jedoch dynamisch und können zur Laufzeit ohne statische Beschränkungen erstellt werden.

• Auf die Elemente von Tupeln kann nicht direkt zugegriffen werden, was üblicherweise Mustererkennung und musterbasierte Dekomposition erfordert, im Gegensatz zu Datenstrukturtypen, die einen benannten Zugriff auf Feldelemente bieten, obwohl die Behandlung von Tupeln als Arrays oder Listen diese Beschränkung lösen kann.

• Ein Tupel mit n Feldern heißt n-stellig und wird in der Notation <v₁, v₂, ..> angegeben.

Tupelräume - Operationale Semantik

• Es gibt eine Reihe von Operationen, die von Prozessen angewendet werden können, bestehend aus
  • einer Reihe reiner Datenzugriffsoperationen, die Tupel als passive Datenobjekte behandeln,
  • und Operationen, die Tupel als eine Art von aktiven Rechenobjekten behandeln (genauer gesagt, zu berechnende Daten).
  • RPC-Semantik (Remote Procedure Call).

out

function (t:tuple)

Die Ausführung der Ausgabeoperation fügt das Tupel t in den Tupelraum ein. Mehrere Kopien desselben Tupelwerts können eingefügt werden, indem die Ausgabeoperation iterativ angewendet wird. Die gleichen Tupel können nach dem Einfügen in den Tupelraum nicht unterschieden werden.

Tupelräume - Operationale Semantik

inp

function (p:pattern, callback: function (tuple|tuple[]|null),all?:boolean)

Die Ausführung der Eingabeoperation entfernt ein Tupel t aus dem Tupelraum, der der Mustervorlage p entspricht. Wenn kein passendes Tupel gefunden wird führt das zu einer Blockierung des aufrufenden Prozesses bis ein passendes Tupel eingestellt wird.

rd

function (p:pattern, cb:function (tuple|tuple[]|null),all?:boolean)

Die Ausführung der Leseoperation gibt eine Kopie eines Tupels t zurück, dass der Vorlage p entspricht, entfernt sie jedoch nicht. Wenn kein passendes Tupel gefunden wird führt das zu einer Blockierung des aufrufenden Prozesses bis ein passendes Tupel eingestellt wird.

Tupelräume - Operationale Semantik

Beispiele

out(["Sensor",1,100]); 
out(["Sensor",2,121]);
inp(["Sensor",1,_], function (t) { if (t) v=t[2]; }); 
inp(["Sensor",_,_], function (t) { if (t) n=t[1],v=t[2] });`
rd(["Sensor",_,_], function (t) { if (t) n=t[1],v=t[2] });`

Tupelräume - Operationale Semantik

try_inp, try_rd

function (0,p:pattern,callback?:function,all?:boolean) → tuple|tuple[]|null

Nichtblockierende Version von inp/rd. Wird kein passendes Tupel gefunden wird die Operation ergebnislos terminiert.

try_inp, try_rd

function (tmo:number,p:pattern,callback:function,all?:boolean) → tuple|tuple[]|null

Teilblockierende Version von try_inp/try_rd, Wird innerhalb einer Zeit von tmo kein passendes Tupel gefunden wird die Operation ergebnislos abgebrochen.

• Die Verwendung von zeitlich unbegrenzt blockierenden Operationen kann unter Betrachtung der Lebendigkeit von Agenten nachteilig sein. Daher sollte immer eine zeitliche Begrenzung und anschließende Abfrage des Operationsstatus erfolgen (abgebrochen?)

Tupelräume - Operationale Semantik

test

function (pattern) → boolean

Nicht blockierender Test eines Tupels.

ts (testandset)

function (pattern,function (tuple) → tuple)

Nicht blockierender Test eines Tupels und atomare Veränderung eines Tupels, dass der Vorlage p entspricht. Das zweite Argument ist eine Abbildungsfunktion. Das Ergebnistupel ersetzt das ursprüngliche.

rm

function (p:pattern,all?:boolean)

Entfernung eines oder aller passenden Tupel.

Tupelräume - Operationale Semantik

Markierungen

• Tupel sind persistent und können für immer in einem Tupelraum verbleiben!
• Daher ist die Verwendung von Markierungen häufig sinnvoll.
• Eine Markierung ist ein Tupel mit einer Lebenszeit τ
• Nach Ablauf der Lebenszeit wird das Tupel - sofern es nicht entfernt wurde - durch einen Garbagecollector entfernt.

mark

function (tmo:number,t:tuple)

Ausgabe eines Tupels t mit einer Lebenszeit τ (im Tupelraum).

Tupelräume - Operationale Semantik

alt

function (pattern [], function (tuple|tuple[]|null),all?:boolean)

Gleichzeitige Mehrfachabfrage (mit inp Semantik) von einer Menge von Mustern. Das erste Tupel welches einem der Muster entspricht wird an die Rückruffunktion übergeben. Es gibt auch eine nicht- oder partiell blockierende Variante try_alt.

Tupelräume - Produzenten und Konsumenten

this.act = {
 percept : function () {
   out(["SENSORNODE"]);
   mark(1000,["SENSOR","CLOCK",time()])
   mark(1000,["SENSOR","GPS",
              {lati:x,long:y}])
 }
}

this.act = {
 process : function () {
  if (test(["SENSORNODE"])
   inp(["SENSOR","CLOCK",_], function (t) {
    if (t) log('It is time '+t[2]);
   })
 }
}

Aufgabe

Betrachte das zeitliche Verhalten im obigen Beispiel (Laufzeiteigenschaften)

1. Was könnte im Produzenten-Konsumenten System möglicherweise falsch laufen?

2. Wie müsste der Agentencode geändert werden um Laufzeitfehler zu vermeiden?

Signale

• Tupleraumkommunikation ist

  • Anonym und
  • Generativ (d.h. die “Nachricht” kann eine längere Lebensdauer als der Absender besitzen)

• Eignet sich daher für die Kommunikation von lose gekoppelten Ensembles

• Neben diesen lose gekoppelten Gruppen gibt es durch Replikation von Kindagenten Gruppen mit starker Kopplung und Kenntnis der Identiäten

  • Elternagent erfährt die Identität eines Kindagenten beim Forking
  • Kindagent kann die Indentität des Elternagenten durch die Operation myParent() erfahren.

• Signale sind zielgerichtete Nachrichten mit identifizierbaren Absender und Empfänger (wobei es bei Multi- und Broadcastnachrichten viele geben kann)

Signale

• Ein Signal signal(arg) besteht aus einem Signalnamen oder einer Signalnummer mit einem optionalen Argument.

• Signale müssen auf Empfängerseite mit einem Signalhandler im this.on Abschnitt des Agentenmodells eingerichtet werden.

send

function (target:id,signal:string|number,arg?:*)

Sendet eine Signalnachricht signal(arg) an den Empfängeragenten target.

broadcast

function (ac:string,r:number,signal:string|number,arg?:*)

Sendet eine Signalnachricht signal(arg) an alle Empfängeragenten der Klasse ac im Radius r.

this.on[“signal”]

function (arg,from)

Ein Signalhandler für das Signal signal.

Signale

this.act = {
  a1 : function () {
    this.child = fork()
  },
  a2 : function () {
    send(this.child,'ALARM',100)
  }
}

this.on = {
  ALARM : function (arg,from) {
    log('Got ALARM '+arg+' from '+from)
  }
}

Mobile Agenten

• Ein Agent in Ausführung wird durch einen Prozess repräsentiert.

• Der Prozesszustand setzt sich zusammen aus:

  • Körpervariablen (Datenzustand)
  • Nächste Aktivität und Mikroschedulingblöcke (Kontrollzustand)
  • Signale, Nachrichten
  • Pfad im Netzwerk (Plattformen auf denene der Agent bereits ausgeführt wurde)
  • Verhalten (D.h. ATG)!

• Mobile Agenten bedeuten mobile Prozesse!

• Bei der Migration muss ein Agentenprozess in einen

  1. Prozessschnappschuss (Container) eigenfroren und serialisiert werden,
  2. Der Schnappschuss in textueller Form (JSON+) von einer Plattform zu einer anderen übertragen werden, und
  3. Der Prozessschnappschuss wieder deserialisiert werden, und der Prozess wird weiter ausgeführt.

Mobile Agenten

Mobiler Code

• Anstelle von mobilen Daten (Kommunikation) wird durch Agenten mobiler Code in Netzwerken transportiert

Mobile Agenten

• Eine Agentenplattform repräsentiert einen physikalischen Knoten in einem Virtuellen Netzwerkgraphen

  • Es gibt virtuelle und physikalische Kommunikationsverbindungen zwischen den Netzwerkknoten
  • Beispiel: Internet Protokoll (IP/UDP/HTTP)

• Ports von Plattformen verbinden und stellen Links her

• Ein Agent kann auf einen anderen Knoten (Plattform) migrieren indem er die moveto Operation ausführt (innerhalb einer Aktivität):

  • Dabei muss der Agent als Argument das Ziel angeben
  • Ziel kann ein Knotenname (DIR.NODE(<nodename>), eine IP Adresse (DIR.IP(<url>)), oder bei gerichteten Verbindungen die Richtung sein (z.B. DIR.NORTH)

Mobile Agenten

• Alle aktuell mit einer Plattform verbundenen anderen Plattformen (Namen) können mit der link Funktion erfragt werden:

{
  var connected=link(DIR.IP('%'));
  if (connected.length) {
    var next = random(connected);
    moveto(DIR.NODE(next));
  }
}

Agentenplattformen

JavaScript Agent Machine

• Vollständig in JavaScript programmiert

• Portabel:

  • Web Browser
  • Cordova WebKit App
  • CLI mit nodejs/jxcore/jerryscript
  • Eingebettet in Java Programm

• Schlank: ca 1M Byte JS Code

• AgentJS Code kann direkt ausgeführt werden (nur Sandboxing erforderlich)!

• Eine physische JAM kann eine Vielzahl von virtuellen JAM Knoten ausführen (nur sequenzielles Scheduling)

JAM

AIOS

• Das AIOS kapselt eine Vielzahl von Modulen und stellt eine API für Agenten zur Verfügung:
  • TUPLE: Tupleraum Datenbank
  • SIGNAL: Signalpropagation zwischen Agenten und JAM Knoten
  • CODE: AgentJS Text ⇔ Code Transformation, Code Morphing, und Sandboxing
  • NODE: Virtueller JAM Knoten
  • WORLD: Bindung von virtuellen JAM Knoten in einem physischen Knoten (Virtualisierung)
  • PROC: Agentenprozesses (Ausführungscontainer für Agenten)
  • MOBI: Agentenmobilität, COMM: JAM Kommunikation
  • SECU: JAM Capabilities und Sicherheit
  • WATCHDOG: Faires Agentenscheduling durch Laufzeitüberwachung (Time slicing)
  • ML: Machine Learning → Fokus mobile Algorithmen und Modelle
  • SAT: SAT Logic Solver → Knowledge Base

JAM

JAM

Agentenrollen

• In der realen Welt ist die Anwendungssicherheit ein wichtiges Schlüsselmerkmal einer verteilten Agentenplattform.

• Die Ausführung von Agenten und der Zugriff auf Ressourcen müssen kontrolliert werden, um Denial-of-Service-Angriffe, Agent-Masquerading, Spionage oder anderen Missbrauch zu verhindern.

• Daher haben Agenten unterschiedliche Zugriffsebenen (Rollen):

  0. Gast (nicht vertrauenswürdig, semi-mobil)
  1. Normal (vielleicht vertrauenswürdig, mobil)
  2. Privilegiert (vertrauenswürdig, mobil)
  3. System (sehr vertrauenswürdig, System relevant, lokal, nicht mobil)

• Die unterste Ebene (0) ermöglicht keine Agentenreplikation, Migration oder das Erstellen neuer Agenten.

• Die JAM-Plattform entscheidet über die Sicherheitsstufe für neue empfangene Agenten. Ein Agent kann keine Agenten mit einer höheren Sicherheitsstufe als die eigene erstellen.

JAM

• Die höchste Stufe (3) hat einen erweiterten AIOS mit Host-Plattform-Gerätezugriffsfähigkeiten.

• Agenten können Ressourcen (z.B. CPU-Zeit) aushandeln und ein Level-Raise erreichen, das mit einem Schlüssel gesichert ist, der die erlaubten Upgrades definiert.

  • Die Systemebene (3) kann nicht ausgehandelt werden.

• Der Schlüssel ist knotenspezifisch. Eine Gruppe von Knoten kann sich einen gemeinsamen Schlüssel teilen (durch einen Server-Port identifiziert der den JAM Knoten identifiziert).

• Ein Schlüssel besteht aus einem Server-Port, einem Rechtefeld und einem verschlüsselten Schutzfeld das das Rechtefeld enthält, das mit einem zufälligen Port generiert wird, der nur dem Server (Knoten) bekannt ist.

JAM

Schlüssel (Capabilities)

• Ein Schlüssel kann verwendet werden um:
  • Einen Agenten von einer Plattform A nach B zu migrieren (B verlangt den Schlüssel um den Agenten auszuführen);
  • Eine neue Agentenrolle (Stufe) auszuhandeln;
  • In einer Agententrolle neue Ressourcen auszuhandeln (CPU, MEM, TS, SCHED, ..);
  • Um neue Agenten erzeugen und andere terminieren zu können

JAM

Schutz von Capabilities

• Das Rechtefeld ist zentral da es die durch die Capability erlaubten Operationen angibt.

  • CPU Zeit erhöhen
  • Änderung des Privilegienlevels
  • Migration usw.
  • Zugriff auf Sensoren und persönliche Nutzerdaten

• Damit das Rechtefeld nicht manipuliert werden kann ohne dass die Capability ungültig wird (und ggf. die Objektnummer) wird ein Schutzfeld erstellt welches die Rechte mit einem privaten Schlüssel (Port) mittels einer One-way Funktion verschlüsselt.

  • Nur der Service / Agentenplattform kennt den privaten Schlüssel

JAM

JAM

Kommunikation und Netzwerke

• JAM Plattformen können in beliebigen Netzwerken miteinander verbunden werden.

• Eine Vielzahl von Kommunikationsprotokolle sind verwendbar:

  • RS232
  • UDP
  • TCP
  • HTTP

• Beliebige Netzwerktoplogien können gebildet werden (physisch wie logisch):

  • Stern
  • Gitter (1D/2D/3D)
  • Bus
  • Intranet und Internet (allg. Graphen)

• AMP: Agent Management Port als gemeinsames Protokoll und Interface in heterogenen Systemen

JAM

• AMP definiert eine Menge von Nachrichten die dem Transport von
  • Agenten,
  • Signalen und Tupeln,
  • und Handshakes dienen.

JAM

Netzwerkstrukturen

• JAM Platfformen können über eine oder mehrere virtuelle Kanäle (AMP) miteinander verbunden werden
  • Verwendung von Relaisstationen führt zu sternartigen Kommunikationssnetzwerken
  • Browser und mobile JAM Knoten können nur an im Internet sichtbare JAM Knoten über HTTP sich verbinden → erfordert Relais Knoten (ohne Nutzerinteraktion, kopflos)

JAM

Programmierung

JavaScript :: Daten und Variablen

• Variablen werden mit dem Schlüsselwort var definiert → Erzeugung eines Datencontainers!

• Es gibt keine Typdeklaration in JS! Kerntypen:

  T_core={number, boolean, object, array, string, function}

• Alle Variablen sind polymorph und können alle Werttypen aufnehmen.

• Bei der Variabledefinition kann ein Ausdruckswert zugewiesen werden

var v = ε,..;  v = ε; 

JavaScript :: Funktionen

• Funktionen können mit einem Namen oder anonym definiert werden

• Funktionen sind Werte 1. Ordnung → Funktionen können Variablen oder Funktionsargumenten zugewiesen werden

• Eine Funktion kann einen Wert mit der return Anweisung zurückgeben. Ohne explizite Wertrückgabe → undefined

• Es wird nur Call-by-value Aufruf unterstützt - jedoch werden Objekte, Funktionen und Arrays als Referenz übergeben; Parameter p_i sind an Funktionsblock gebunden

function name (p1,p2,..) { statements ; return ε } name(ε1,ε2,..)

JavaScript :: Funktionen

• Da in JavaScript Funktionen Werte erster Ordnung sind können

  • Funktionen an Funktionen übergeben werden und
  • Funktionen neue Funktionen zurückgeben (als Ergebnis mit return)

• Es können daher anonyme Funktionen function (..) {..} definiert werden die entweder einer Variablen als Wert oder als Funktionsargument übergeben werden.

var x = function (pi) { ε(pi) }
array.forEach(function(elem,index) { ε(pi) }

JavaScript :: Datenstrukturen

In JavaScript sind Objekte universelle Datenstrukturen (sowohl Datenstrukturen als auch Objekte) die mit Hashtabellen implementiert werden. Arrays werden in JavaScript ebenfalls als Hashtabelle implementiert!. D.h. Objekte == Datenstrukturen == Arrays == Hashtabellen.

• Es gibt kein nutzerdefinierbares Typensystem in JavaScript.

• Eine Datenstruktur kann jederzeit definiert und verändert werden (d.h. Attribute hinzugefügt werden)

var dataobject = {
  a:ε,
  b:ε, ..
  f:function () { .. }
}
..
dataobject.c = ε

JavaScript :: Datenstrukturen

• Dadurch dass Objekte und Arrays mit Hashtabellen implementiert (d.h. Elemente werden durch eine Textzeichenkette referenziert) werden gibt es verschiedene Möglichkeiten auf Datenstrukturen und Objektattribute zuzugreifen:

dataobject.attribute
dataobject["attribute"]
array[index]
array["attribute"]

JavaScript :: Objekte

• Objekte zeichnen sich in der objektorientierten Programmierung durch Methoden aus mit der ein Zugriff auf die privaten Daten (Variablen) eines Objekts möglich wird.

• In JavaScript kann auf Variablen eines Objekts (die Attribute) immer direkt zugegriffen werden.

• Attribute können Funktionen sein - jedoch können die Funktionen nicht wie Methoden direkt auf die Daten des Objektes zugreifen.

• Daher definiert man Methoden über Prototypenerweiterung in JavaScript.

• Die Methoden können über die this Variable direkt auf das zugehörige Objekt zugreifen (also auch auf die Variablen/Attribute)

• Es gibt eine Konstruktionsfunktion für solche Objekte mit Prototypendefinition der Methoden

• Objekte werden mit dem new Operator und der Konstruktionsfunktion erzeugt.

JavaScript :: Objekte

function constructor (pi) {
  this.x=ε
  ..
}
constructor.prototype.methodi = function (..) {
  this.x=ε;
  ..
}
...
 
var obj = new constructor(..);

AgentJS

• AgentJS ist die JavaScript Implementierung von AAPL (Activity-based Agent Prorgramming Language)
  • Die meisten AAPL Operationen und Anweisungen sind in AgentJS verfügbar
  • Aber: JavaScript unterstützt nicht das Konzept der Prozessblockierung
  • Daher anderes Scheduling und Ablaufmodell mit Scheduling Blocks

Agentenklasse

• Agentenklassen werden in JS über Konstrukorfunktionen definiert.

• Eine Agentenklasse definiert:

  • Körpervariablen (nur mobile und werterhaltende)
  • Aktivitäten (als Funktionsobjekt)
  • Übergangsbedingungen (als Funktionsobjekt)
  • Optionale Signalhandler (als Funktionsobjekt)
  • Ein next Attribute initialisiert mit der Startaktivität

AgentJS

• Aber: Das this Objekt als Refernz auf eine Agenteninstanz ist auch in geschachtelten Funktionen gültig, d.h., in allen
  • Aktivitätsfunktionen,
  • Übergangsfunktionen,
  • Signalhandlerfunktionen, und in
  • Callback Funktionen erster Ordnung von eingebauten Funktionen (z.B. iter(list,function () { this is agent! }

• Ein Agentenprozess wird in einem Sandkasten gekapselt ausgeführt. Daher:
  • Ein Agent darf nur auf Körpervariablen zugreifen und keine freien Variablen oder lokale Variablen verwenden (d.h. welche die außerhalb des Konstruktors definiert wurden oder welche die innerhalb des Konstruktorkörper definiert wurden):

function ac (p) {
  var x;      // Wrong!!!
  this.y = p; // Correct!!!
  this.act = { ax: function () { var a; // is correct
}

AgentJS

function ac(p1,p2,..) {
  // Body Variables
  this.x=ε; ..
  this.act = {     // Activities
   a1: function () { .. },
   a2: function () { .. },
   ..
   an: function () { .. }
  }
  this.trans = {   // Transitions
   a1: function () { return cond?ai:aj },
   a2: aj,
   ..
  } 
  this.on = {      // Signal Handler
    error:   function (err) { .. },
    signal1: function (arg) { .. }
  }
  this.next = a1;
}

AgentJS

Agenteninstantiierung und Terminierung

function create(class:string,arguments:{},level?:number) → id:string
function fork(arguments?:{},level?:number) → id:string
function kill(id:string|undefined)

• Bei der create Operation die einen neuen Agenten der Klasse ac instantiiert werden die Klassenparameter der Instanz mit konkreten Werten mit dem Parameterargument arguments:{p1:v1,p2:v2,..} initialisiert.

• Bei der fork Operation die eine Kopie des aufrufenden Agenten erzeugt werden Klassenattribute (die this.x Variablen, nicht die Parameter {p}!) mit neuen Werten überschrieben, d.h. arguments:{x:v1,y:v2,..}

• Die kill Operation ohne Argument führt zur Terminierung des aufrufenden Agenten (== kill(me()))

AgentJS

Beispiele

id = create('explorer',{dir:DIR.NORTH,radius:1});
child = fork({x:10,y:20});
kill(child);
kill(me());

Asynchrone Operationen

• Da JavaScript Funktionen als Werte erster Ordnung behandelt werden häufig sog. Rückruffunktione (callback) an Funktionen als Argumente übergeben, die von der aufrufenden Funktion dann aufgerufen werden

• Rein synchrone Operationen (z.B. Tupelraumoperation out oder jegliche Berechnung, auch mit Rückruffunktionen wie iter) können in einer Sequenz innerhalb einer Agentenaktivität ausgeführt werden

• Es gibt aber auch asynchrone Operationen ((z.B. Tupelraumoperation rd), die zwar aufgerufen werden, aber erst später (ggfs. nach Durchlauf einer Aktivität) ausgeführt werden.

AgentJS

Prozessblockierung

• Eine Aktivität wird in einem Durchlauf ausgeführt und kann nicht blockieren, wie dies z.B. bei den Tupeloperationen der Fall sein könnte.
  • Daher darf sich in AgentJS maximal nur ein blockierende Operation (die tatsächlich dann die Aktivität blockiert, und nicht den Programmfluss) am Ende einer Aktivität befinden.
  • Bei einer Sequenz von blockierenden Operationen muss in der Aktivität ein Scheduling Block verwendet werden (Mikroaktivitäten).
  • Jede Mikroaktivität darf eine blockierende Operation enthalten!

• Es gibt drei verschiedene Blockkonstruktoren:
  • B: Ein sequenzieller Scheduling Block
  • L: Ein iterativer Schleifenblock
  • I: Ein Iteratorblock für Arrays und Objekte (Strukturen)

AgentJS

B([                    L([
   function () { .. },     function init () {..},
   function () { .. },     function cond () {..}, 
   function () { .. },     function next () {..},
  ..                       [ function () { .. },
])                           function () { .. }, ..
                           ]])
I(obj:[]|{},
  function next (elem:*) { },
  [
   function () {..},
   function () {..}, ..
  ],
   function finalize () { .. }
)

AgentJS

Tupeloperationen

function alt (pattern [],callback:function,all?:boolean,tmo?:number)
function collect (to:path,pattern) → number
function copyto (to:path,pattern) → number
function evaluate (pattern,callback:function (tuple)) → tuple
function inp (pattern,callback:function(tuple|tuple[]|none),all?:boolean,tmo?:number)
function listen (pattern,callback:function (pattern) → tuple)
function out (tuple)
function mark (tuple,tmo:number)
function rd (pattern,callback:function(tuple|tuple[]|none) ,all?:boolean,tmo?:number)
function rm (pattern,all?:boolean)
function store (to:path,tuple) → number
function test (pattern) → boolean
function ts (pattern,callback:function(tuple) → tuple)
function alt.try inp.try rd.try (tmo:number,..)

• collect, copyto, und store sind verteilte Tupelraumoperationen und wirken auf entfernten Tupelräumen

AgentJS

Beispiele

out(['MARKING1',1]);
out(['SENSORA',100,true]);
inp(['SENSORA',_,_],function (tuple) {
  if (tuple) this.s =tuple[1];
});
rm(['SENSORA',_,_],true);
rd.try(0,['SENSORA',_,_],function (tuple) { .. });
// oder bei Timeout 0 alternativ ohne callback =>
var t = rd.try(0,['SENSORA',_,_]);
ts(['MARKING',_],function (t) { t[1]++ });
alt([
  ['SENSORA',_,_],
  ['SESNORB',_],
  ['EVENT'],
],function (tuple) {
  if (tuple && tuple[0]=='EVENT') {..}
  else ..
});

AgentJS

Signale und Handler

function send (to:aid,sig:string|number,arg?:*)
fucntion broadcast (class:string,range,@sig,@arg?)
function sendto (to:dir,sig:string|number,arg?:*)
function sleep (milli:number)
function timer.add (milli:number,sig:string,arg:*,repeat:boolean) → string
function timer.delete (sig:string)
this.on = { SIGNAL : function (arg,from) { .. } }

Typen und Muster

type aid = string
type range = hops:number|region:{dx:number,dy:number,..}
enum DIR = {NORTH , SOUTH , WEST , EAST , ..
            PATH (path:string) , NODE(id:string),
            IP (ip:string) ,
            CAP {cap:string}
} : dir

AgentJS

• Signalhandler werden außerhalb von Aktivitäten in der this.on Sektion ausgeführt. Der Objektattributname ist der Signalname.

Code Muster

this.child=none;
this.act = {
  a1: function () {
    this.child=fork({child:none});
    timer.add(500,'QUERY',true);
  }
  a2: function () {
   // Raising of signal
   if (this.child) send(this.child,'PARENT',me());
  }
}
// Installation of Signal Handler
this.on : {
   PARENT : function (arg) {
     log('Got signal from my parent '+arg);
   }, 
   QUERY: function () { .. }
}

AgentJS

Mobilität von Agenten

enum DIR = {NORTH , SOUTH , WEST , EAST , ..
            PATH (path:string) , NODE{node:string),
            IP (ip:string) ,
            CAP (cap:string)
} : dir
function moveto (to:dir)
function opposite (dir) → dir
function link (dir) → boolean|string|[]

• Für die IP Richtung existiert eine Typkonstruktionsfunktion DIR.IP(ip:string|number) mit der Angabe einer IP Adresse und einer IP Portnummer im Format "IP:PORT", oder bei Verbindungen von JAM Knoten auf den gleichem Hostrechner nur die IP Portnummer.

• Die opposite Funktion liefert die entgegengesetzte Richtung, z.B. NORTH → SOUTH. Bei IP Ports i.A. nicht definiert oder bei bereits migrierten Agenten die IP Adresse des letzten Knotens.

• Als Ziel kann auch ein JAM Knotenname angegeben werden (DIR.NODE("name")).

AgentJS

moveto

function moveto (to:dir)

Der Agent wird eingefroren, zu der neuen Plattform gesendet, und dort weiter ausgeführt. Die Rcihtung kann einen geometrischen Bezug haben (z.B. DIR.NORTH), oder eine Plattformreferenz beschreiben (z.B. DIR.NODE(‘hanaqude’)). Eine geometrische Richtung macht nur in Maschennetzwerken it P2P Verbindungen Sinn.

• Wenn keine Verbindung in die angegebene Richtung existiert wird der Agent terminiert!

link

function link (dir) → boolean|string|[]

Liefert Informationen über aktuell erreichbare Nachbarknoten. Die link Funktion testet ob ein Port mit einer anderen Seite verbunden ist (nicht zuverlässig). Bei Multicast IP Ports (Standard) gibt die Funktion alle derzeitig angebundenen anderen Knotenadressen (Routes) zurück (Aufruf mit Argument DIR.IP('*')).

AgentJS

• Die von der aktuellen Plattform (JAM Knoten) erreichbaren JAM Knotennamen können z.B. mit der link(DIR.IP("%")) Operation als Liste ausgegeben werden.

• Nach einer Migration wird die nächste folgende Aktivität (definiert durch die Übergangsbedingungen) ausgeführt. Daher muss die moveto Anweisung die letzte in einer Aktivität oder eingebettet in einen Scheduling Block sein!

Simulation

• Neben der “realen” Ausführung von mobilen Agenten in Computernetzwerken stellt die Simulation von verteilten Netzwerken aus Agentenplattformen und “virtuellen” mobilen Agenten ein wichtiges experimentelles Werkzeug dar um auch komplexe Szenarien raum- und zeitaufgelöst zu untersuchen.

SEJAM

• SEJAM ist das Simulation Environment for JAM und baut auf einer “physischen” JAM Plattform auf
  • JAM wird um eine Bedieneroberfläche und Visualisierung ergänzt
  • Eine virtuelle Welt besteht aus einer Vielzahl virtueller (logische) JAM Knoten und eier geometrischen zweidimensionalen Welt
  • Agenten können in der virtuelen Welt zwischen virtuellen Knoten migrieren

Simulation

• Die virtuellen Knoten sind in der geometrischen Welt mobil
• Die virtuellen Knoten verfügen über virtuelle Kommunikationsverbindungen (z.B. radial wie Mobilfunk)
• Die JAM Plattform in SEJAM kann mit realen Netzwerken gekoppelt werden!

• Mobile Agenten können nicht nur zwischen virtuellen Knoten migrieren, sondern auch die auf externe Plattformen in der realen Welt migrieren

Simulation

Simulation

Augmented Virtuality

• Die Fusion von virtuellen Simulationswelten mit realen Netzwerken ermöglicht die Kopplung von virtuellen Welten mit realen Welten und Interaktion mit Menschen!

• Chat bots können sowohl in virtuellen als auch realen (menschbezogenen) Welten agieren!

• Das ermöglicht das Studium komplexer sozio-technischer Systeme

Human-in-the-loop simulation for Augmented Virtuality besteht daher aus:

• Virtueller Simulationswelt und Framework SEJAM2 mit JAM platform unf virtuellen JAM Netzwerken die mit dem Internet verbudnen sind

• Mobilen Gertäten mit JAM Plattform verbunden mit dem Internet oder via Baken (Bluetooth z.B.)

• Stationäre Geräte (Sensoren, IoT, und Baken) die über das Internet mit der virtuellen Welt verbunden sind

Simulation

Demonstrator

Smart City: Self-Organizing Light Control

Goal

Simulation and investigation of Crowd Interaction with Smart Cities

• Self-organized control of ambient light conditions (e.g., in streets or buildings) using Crowd Sensing

Virtual World

• World consists of streets and buildings

  • Beacons placed in buildings and beside streets
  • Smart Light Devices illuminating streets and buildings

• Agents (can) represent:

  • Technical devices → Light Control
  • Network Infrastructure and Communication
  • Computational units and Smart Controllers
  • Chat Bots performing Crowd Sensing
  • Robots
  • Artificial Humans (Artificial Crowd)

Smart City: Self-Organizing Light Control

Real World

• Mobile Devices using a WEB App with Chat Bot dialog

  • Users interact with remote agents via a chat dialog;
  • Remote agents investigate user location and an assessment of satisfaction of ambient light situation.

• Additionally, the device sensor data is collected (light, position, ..) if available

Self-organizing Light Control

• Beacons sent out mobile explorer agents performing question-answer dialogs on mobile devices (random walk)

• Based on collected crowd data:

  • The light conditions in buildings and streets should be adapted (darker or brighter);
  • Addressing 1. Crowd demands 2. Energy Saving.

Smart City: Self-Organizing Light Control

• If action is required, mobile notification agents are sent out to neighbouring nodes to change light intensity based on:
  • Directed diffusion
  • Random walk
  • Divide-and-Conquer

Smart City: Self-Organizing Light Control

Crowd Sensing App

Conclusions

1. Fusion of real and virtual worlds can contribute to investigate complex socio-technical systems with ensemble sizes beyond Millions of entities (users, devices, machines)

2. Using agent-based modelling and simulation with mobile agents create an unified model and representation for:

   • Artificial humans
   • Chat Bots
   • Devices and Machines
   • Distributed Computation

3. Augmented Virtuality means the integration and tight coupling of ABM simulation with Crowd Sensing and technical devices interaction

4. Issues:

   • Time scales in real and virtual worlds
   • Spatial scales and spaces in real and virtual worlds
   • Mapping of real on virtual worlds