Skip to content

SPS Extensions

Jump to bottom
Alex Robin edited this page Dec 21, 2016 · 10 revisions

Several extensions of the Sensor Planning Service (SPS) are implemented in OSH:

Command Streams

This extension allows requesting exclusive access to a taskable asset (direct tasking session) and sending it low latency commands (for real-time control). This is achieved by maintaining a persistent connection between the SPS client and server.

The server will have to manage priorities and session expiration. For example, the server will be able to cancel an on-going session if another higher priority request is received.

  1. Client issues a DirectTasking request to the SPS server to reserve a direct tasking session for a specified time range (which can start 'now') and obtains a sessionID.

  2. If request is accepted, the client can connect with the sessionID at anytime during the reserved time slot to initiate the persistent tasking connection (using either persistent HTTP or Websockets).

  3. Client can start sending low latency commands into the connection

Below is a UML sequence diagram illustrating these different phases:

![Direct Tasking Sequence Diagram](http://g.gravizo.com/g? @startuml; actor "SPS Client" as A; participant "SPS" as B; participant "Sensor" as C; A -> B: DescribeTasking; A -> B: DirectTasking; B -> A: ACK {session ID}; ...; A -> B: ConnectTasking {session ID}; activate B; A -> B: Send Command; B -> C: Send Command; A -> B: Send Command; B -> C: Send Command; A -> B: Send Command; B -> C: Send Command; ...;
hnote over B : End of session time slot; B ->x A: Close Connection; deactivate B; |||; @enduml )

Sensor Registration

This extension is to allow a sensor to register itself with an SPS endpoint (we'll call that SPS-T), much like it can register itself to an SOS-T endpoint.

  1. A sensor registers with a remote SPS-T endpoint using InsertSensor (same as SOS operation, already in the common SWES namespace).

  2. The sensor then registers supported command types using the InsertTaskingTemplate operation (mirror of InsertResultTemplate in SOS).

  3. The actual command stream is initiated when the sensors issues a ConnectTasking using Websocket.

  4. SPS capabilities are then updated with a new offering and clients can start submitting commands that will be forwarded to the sensor by the SPS server.

The first advantage of these new operations is that the SPS-T server can be completely generic since it just forwards SWE common encoded messages to the sensor (similarly to SOS-T, it doesn't need specific knowledge about the sensor). The second advantage is that the sensor itself does not need to run an HTTP server and can reside behind a firewall or NAT since it initiates the persistent connection (rather than having to accept incoming HTTP requests).

Below is a UML sequence diagram illustrating these different phases:

![Register Sensor Sequence Diagram](http://g.gravizo.com/g? @startuml; actor "SPS Client" as A; participant "SPS-T" as B; participant "Sensor" as C; C -> B: InsertSensor; C -> B: InsertTaskingTemplate; C -> B: ConnectTasking; hnote over B : Offering added; |||; ...; A -> B: DescribeTasking; A -> B: Submit; B -> C: Send Command; activate C; C -->> B: Command Executed; deactivate C; B -->> A: Notify; ...; A -> B: Submit; B -> C: Send Command; activate C; C -->> B: Command Executed; deactivate C; B -->> A: Notify; ...; C ->x B: Close Connection; hnote over B : Offering removed; |||; @enduml )

Clone this wiki locally