Der Sensor Planning Service ist einer der Web-Dienste, die vom Open Geospatial Consortium (OGC) zur Realisierung des Sensor Web Enablement entwickelt wurde.
Der OGC Sensor Planning Service wurde entwickelt, um eine standardisierte Schnittstelle für parametrierbare Sensoren zur Verfügung zu stellen. Dabei kann es sich um reale Sensoren handeln, die ein manuelles Ansteuern erforderlich machen wie zum Beispiel ein Probenehmer oder eine steuerbare Kamera, aber auch um sogenannte virtuelle Sensoren. Als virtuelle Sensoren werden zum Beispiel mathematische- oder Simulationsmodelle bezeichnet, die errechnete, also virtuelle Messgrößen liefern.
Wenn Parameter oder Steuergrößen an diese Sensoren übermittelt werden müssen, kommt der SPS zum Einsatz.
Natürlich beschränkt sich dieser Dienst nicht auf Sensoren, sondern es können mit dem SPS auch zum Beispiel komplette Anlagen über das Internet gesteuert werden.

Zum Beispiel wurden in dem Projekt ProOptKa die SPS-Dienste eingesetzt, um die Simulationsmodelle STORM und STOAT zu parametrieren und zu steuern.
Die Anfragen an den Dienst sind in der Regel XML-basiert, beruhen auf einem standardisierten Schema und werden per POST-Request an den Dienst geschickt. Für einige Operationen sind allerdings auch GET-Requests zulässig, in denen die Parameter per Key-Value-Pair übermittelt werden.

Auch für den SPS gibt es zwingend vorgeschriebene und optionale Operationen.

Vorgeschriebene Operationen

  • GetCapabilities - Liefert ein Dokument mit einer ausführlichen Beschreibung des Dienstes und der angeschlossenen Sensoren.
  • DescribeTasking - Mit dieser Operation erhält man Auskunft über die Parametrierungsmöglichkeiten des Sensors. Dazu gehört, welche Wertebereiche erlaubt sind, in welcher Maßeinheit diese Werte übermittelt werden müssen und ob ein Wert gesetzt werden muss oder ob das Setzen eines bestimmten Werts optional ist.
  • Submit - mit dieser Operation werden die (neuen) Werte an den SPS übermittelt
  • DescribeResultAccesss - Hier wird beschrieben, wo das Ergebnis dieses Prozesses nach der Abarbeitung abgeholt werden kann. Dies kann ein SOS sein oder einfach ein Link zu einer Datei.

Optionale Operationen

  • GetFeasibility - Mit dieser Abfrage enthält man Informationen darüber, ob ein Sensor für neue Aufgaben bereit ist.
  • GetStatus - Mit dieser Abfrage enthält man Informationen darüber, wie weit die Abarbeitung einer Aufgabe fortgeschritten ist.
  • Update - Wird diese Operation unterstützt, können einem Sensor neue Werte übergeben werden.
  • Cancel - Mit dieser Operation wird die Abarbeitung einer Operation abgebrochen.

 

Interaktionsdiagramm mit einem SPS

Dieses Diagramm zeigt eine typische Interaktion mit einem SPS:

[caption id="attachment_325" align="alignleft" width="146"]Interaktionsdiagramm mit einem SPS Interaktionsdiagramm mit einem SPS[/caption]

  1. Zuerst wird eine GetCapabilities-Anfrage an den Dienst geschickt, um die nötigen Informationen zu erhalten
  2. Dieser liefert seine Capabilities zurück mit einer Liste der Sensoren und der einstellbaren Parameter
  3. möchte man einen oder mehrere Parameter für einen Sensor ändern, schickt man eine DescribeTasking-Anfrage mit der jeweiligen SensorID an den Dienst
  4. Dieser liefert dann mit einem DescribeTaskingRequestResponse eine genaue Beschreibung der einstellbaren Parameter
  5. wenn der Sensor nach Abarbeitung der Aufgabe Werte zurück liefert, muss man wissen, wie man an diese Daten kommt. Dafür schickt man eine DescribeResultAccess-Anfrage an den Dienst
  6. Der Dienst antwortet mit einem DescribeResultAccessRequestresponse mit einer Adresse, wo das Ergebnis der Abarbeitung stehen wird. Das kann zum Beispiel die Adresse von einem SOS sein.
  7. Anschließend wird mit einer GetFeasibility-Anfrage überprüft, ob der Sensor bereit ist, die neuen Parameter übermittelt zu bekommen und abzuarbeiten
  8. Der Dienst übermittelt die Antwort mit einem GetFeasibilityRequestResponse
  9. Wenn der Sensor bereit ist und der Dienst sein OK gegeben hat, übermittelt man die neuen Parameter mit einer Submit-Anfrage
  10. Der Dienst antwortet mit einem SubmitRequestResponse, ob die Werte übermittelt und angenommen wurden und teilt dem Client eine TaskID zu
  11. Wenn die Abarbeitung der übermittelten Aufgabe länger dauert, wie zum Beispiel bei einem Simulationsmodell, und man möchte zwischendurch Informationen über den Status der Abarbeitung haben, kann man eine GetStatus-Anfrage an den Dienst schicken
  12. Der Dienst antwortet dann mit einem GetStatusRequestResponse über den Abarbeitungs-Status
  13. Wenn nach der Abarbeitung weitere oder neue Werte übermittelt werden sollen, schickt man diese mit einer Update-Anfrage
  14. Der Dienst antwortet mit einem UpdateRequestResponse, ob die neuen Werte angenommen wurden
  15. Wenn alles erledigt ist, schickt man eine Cancel-Anfrage an den Dienst und gibt diesen für neue Aufgaben frei.

Wenn der Dienst, seine Sensoren und die Parametrierungsmöglichkeiten bekannt sind, zum beispiel bei einem fest eingebunden Dienst, können die Schritte 1-6 wegfallen.

Teilen:

Add comment