SPS Adapter /Sensor Control Adapter

• Erweiterung der Sensor Gui um einen Button " Go to " um Sensor Manuell aus der Sensor Gui heraus zu steuern
  • SJ: Wobei es diese Option nur fuer die Sensoren geben sollte, die z.B. durch einen SPS steuerbar sind; bei anderen Sensoren koennte es sein, dass sie eine komplett autonome Bewegungsstrategie verfolgen

• Ueberlegungen:
  • • Wie soll der Adapter angebunden werden? Evtl. erstellen eines "kleineren" Common Connector, da die Adapter vom Umfang her geringer sind und nur beschraenkt Nachrichten Empfangen und versenden muss. Dieser koennte dann ebenfalls fïuer den schon bestehenden SOS Adapter eingesetzt werden.
    • Gui Oberflaeche zum Steuern des Sensors: Eingabe von Sensor ID und X.bzw. Y Postions Wert. Diese Informationen werden in einer Postion Command Message verpackt und via Mantaray an den Sensor geschickt, der mit Hilfe einer move To Methode diesen Befehl ausfuehrt
      • SJ: Eine Art CommonConnector fuer die Anbindung aller externen Komponenten waere sinnvoll, da die Kommunikationspattern dafuer meist einfacher/anders sind. Gerade auch im Hinblick auf eine externe Visualisierung koennte ein solcher "kleiner" Common Connerctor hilfreich sein.
    • Dictionary: Erstellen eines Adapter Dictionaries? Wuerde auch im Falle des SOS Adapters Sinn machen, da man so waehrend der Laufzeit einfach nachschlagen kann welche Sensoren und Phenomene schon in der DB eingetragen sind. Fuer den Sensor Control Adapter ( spaeter dann fuer den SPS) waere es so praktisch um die Destinations der Sensoren nachzuschlagen.
      • SJ: Das waere sinnvoll. Insbesondere koennte in dem Dictionary strategiespezifisch entschieden werden, welche Command-Message-Typen ein Sensor ueberhaupt annehmen kann. Ein Sensor mit einer Bewegungsstrategie, die in Stillstand besteht, kann mit Bewegungsbefehlen nichts anfangen.

AbstractCommandMessage Struktur

CommandAcknowledgement der Command Messages

Um eine Command Message zu identifizieren und direkt zu erkennen, welcher Command geschickt wurde und von welchem Adapter der Command geschickt wurde wird eine eindeutige ID vergeben, die zum Beispiel folgende Struktur haben könnte: Command Type_ Adapter Type +Adapter ID_ Message ID

Adapter Dictionary

• in dem Dictionary müssen die Sensor und ihre "Fähigkeiten" gespeichert sein, die sich zu dem Zeitpunkt im System befinden.
• das Dictionary wird erstellt und dem Adapter zugeschickt, sobald er sich anmeldet und muss bei Sensor An/Abmeldung aktualisiert werden
• Überlegungen:
  • ein Sensor könnte seine Fähigkeiten bestimmte Befehle ausführen zu können (Postion Command, Speed Command) im property file (in Form von boolean Attributen) speichern, mit Hilfe dessen der Sensor im System angemeldet wird.
    • SJ: flexibler wäre es evtl. wenn einfach nur die Namen der Commands aufgelistet werden, die ein Sensor versteht. Beim Erstellen des Propertyfiles sind ja nicht unbedingt alle Strategien bekannt die es gibt, bzw. die es je geen wird. Evtl. würde es sich als Name anbieten die Klassennamen der entsprechenden Command-Klassen zu nehmen
  • desweiteren könnten alle Commands die ein Adapter kennt mit Hilfe eines property files geladen werden und zur Dictionaryerstellung verwendet werden.
  • entsprechend den Commands könnten Methoden zur Command Ausführung definiert werden und im Sensor Interface oder Abstract Sensor Simulation zur Verfügung gestellt werden (move to, move in direction,....)
    • SJ: Hier würde ich das eher so machen, dass das Interface nur eine executeCommand-Methode hat, die als Parameter ein Command-Objekt erwartet. Je nachdem was für ein Command-Objekt dann reinkommt, wird innerhalb der Methode entschieden, was passiert. Sofern das Command bekannt ist, können dann intern die entsprechenden Methoden aufgerufen werden. Das hat den Vorteil, dass das Sensor-Interface bzw. das der AbstractSensorSimulation immer gleich bleibt und nicht bei neuen Command-Typen angepasst werden müsste.
  • wenn ein Sensor sich anmeldet wird er mit seiner Destination und seinen Fähigkeiten im Dictionary gespeichert. Somit ist abrufbar welche Sensoren im System zur Verfügung stehen und welche Commands sie entgegen nehmen können.
    • Evtl. sollte er bei der Anmeldung die Command-Klassen mit übergeben, die er versteht. Darin sollte es dann Methoden geben mit denen die entsprechenden Command-Namen, die Parameter (Parametername + Datentyp) abgefragt werden können. Dann liegen im Dictionary gleich alle Commands inklusive der benötigten Parameter vor. Damit kann man dann etwas dynamischer entsprechende Tasking-Clients bauen.
  • Dictionary Control erweitern: create Adapter Dictionary ()

* adapterdictionaries.jpg:

Status Abfrage der Commands

• Mögliche Status für Commands:
  • Command received
  • Command in execution
  • Command finished

• Um eine Abfrage des Status möglich zu machen, sollte der Sensor vorhalten, welchen Command er gerade ausführt und diesen mittels ID verfügbar machen.

Die Commands sollten beim Sensor in einer Liste / Queue gespeichert werden und entsprechend abgearbeitet werden (möglicherweise durch prioriäten Vergaben an Commands). somit kann bei der Statusabfrage auch zurückgegeben werden, an welcher Position der Command sich gerade befindet.

• Bei der Rückgabe eines Status sollte die aktuelle Postition des Sensors übergeben werden und relevante Informationen, wie Richtung, Geschwindigkeit,..( somit wäre evtl sogar eine Berechnung der Command Dauer auf Adapter Seite möglich)

Außerdem könnte der Sensor über seine Position Messages, die der Adapter abboniereren kann, propagieren welchen Command er gerade ausführt. Somit ist erkennbar unter welchem Command der Sensor sich bewegt.