SPS Plugin for OWS5 CITE testing

---

Overview

An instance of the sensor described here comes with the SPS distribution. The sensor only simulates behaviour and parameters to test the SPS installation and configuration. For testing you can use the OWS5 TEAM engine.

Note: the design of the CITE plugin was reused within the CITE testing in OWS-9 when testing the 52°North SPS 2.0 reference implementation.

The interface of the sensor is given by its list of taskable parameters and its SensorML document. Refer to the SensorConfiguration topic to get more information to configure the sensor and how to request the SPS when installing and registering the sensor at a running SPS.

Introduction

For being able to test an SPS, first of all you need to register some sensors. Then you are able to test basic operations like GetCapabilities. However, the SPS is a stateful service and thus you need to define the interface (taskable parameters) and behavior of the registered sensors. On this page we describe the usecase of the sensor, what requests and behaviour will be tested in reference to the CITE testing and what not. Furthermore problems and issues concerning the SPS testing are discussed here. The sensor plugin, its parameters and how it behaves in detail is described on this page.

Some Words about testing

The following subsections hopefully clarify what is tested and what not (and why).

What could be tested with the sensor?

• Correct handling of various SweCommon datatypes: Quantity, Count, Boolean, Text, Category, Time, Position
• Usage of InputDescriptor and InputParameter: the latter should be conformant (same type, uom, keeping the constraints) to its corresponding descriptor; otherwise a request should be rejected.
• Correct behavior based upon 'use' and 'updateable' attributes of an sps:!InputDescriptor.
• We could test that correct notifications are sent to the client depending on incoming request, current state or state change.
• If we had more than one sensor registered at the SPS, we could test correct creation of the SPS Capabilities' Contents section and also the response to a DescribeTasking request with more than one sensor ID.
• We can test that the SensorML document of a given sensor is valid according to the SensorML 1.0 schema.
• We can test that the service provides an ExceptionReport with exceptionCode='InvalidRequest' whenever we send an invalid request document to the service.
• We can test that the service generates ExceptionReports according to the rules from OWSCommon and SPS 1.0.
• We could test that the service generates alternatives for rejected parameter constellations. However, this is optional in the spec so a sensor is not required to be smart enough to do that.
• We could test that the service handles requests with IDs from feasibility studies as well as current (or already completed) task(s) in the right way.
• We could test that an Update request providing a different notification target is handled correctly ... if the engine is capable of handling asynchronous messages.
• We can test that the service includes the InputDescriptors of required parameters that are missing in an Update request.
• We can test that the correct status indicator is returned upon a GetStatus request at any time.
• Task cancellation.
• We can test situations in which the DescribeResultAccess response contains DataNotAvailable, a list of services with URL only and also with example request (though testing of the contents of this element is open for discussion).

What is not intended to be tested – at the moment

• Usage of a TaskMessageDefinition, GeometryDefinition and TemporalDefinition in an InputDescriptor.
• Correct handling of the NotificationTarget which may be provided in a GetStatus request. This target should be used (as the desination of an SPSMessage with StatusInformation) instead of the task's target only in case the response contains status=unknown.

What cannot be tested

• The correct AreaOfService is provided in a specific SensorOffering. This is because the AOS is determined by the sensor (provider) and the SPS interface has no mechanism to infer the AOS in another way.
• Ensure that a meaningful SensorML document is provided by the SPS for a sensor, because it is up to the provider which pieces of information he includes in that document.

The sensor

The following subsections describe the sensor how it behaves, what parameters it needs to be tasked, etc.

Use Case

The idea of the sensor is that it can be tasked to take measurements at two consecutive locations before having to return to the base station for loading/changing batteries. The following diagram exemplifies this behavior.

The use case should be as simple as possible but also be complex enough so that as many test cases can be supported as possible. Look at this page for a more detailed view of the sensor plugin.

Taskable Parameters

We should try to get as much of the simple SweCommon types in here as possible. We should also try to provide constraints on some of the parameters and provide at least one parameter for each combination of the 'use' and 'updateable' attributes of an sps:InputDescriptor

name	use (optional or required)	updateable (true or false)	type	uom (if applicable)	constraint(s)	description
measurement frequency	optional	true	swe:Quantity	Hz	a maximum will be defined	The client may specify the frequency with which the sensor generates measurements.
measurement location	required	false	swe:Position with swe:location in it	-	coordinates would be constrained to bounding box that has been declared in Capabilities (AreaOfService)	Defines the location at which measurements should be taken.
measurement count at location	optional	false	swe:Count	-	maybe a maximum value; could be explained by having limited battery on board	A client can define how many measurements should be taken at the specified location.
measurement purpose	optional	false	swe:Text	-	-	The client can provide a textual description of the measurement purpose.
priority	required	false	swe:Category	-	constrained to: low, medium, high	The client has to provide a priority level for his task. Normally, this parameter is hidden to a user and would be determined automatically by the service (infrastructure), but in this case it would help us to simulate that a task was cancelled by the system or an operator and not by the client.
shallMeasure	required	true	swe:Boolean	-	-	The client has to specify whether the sensor should start or stop measuring in each Submit or Update request.
maximum mission duration (? - could be useful)	optional	false	swe:Time	seconds (after mission start)	a minimum and / or maximum could be defined by the service	The client may indicate how long the execution of his task may take at most. We could define that whenever this parameter is provided in the GetFeasibility or Submit request, the respond indicates that no definite answer can be given but will be sent via a separate message instead. This would simulate that an operator has to take a look at the intended task. We could then test the SPS behavior when a response is delayed.

Sensor Behavior

• State diagram for GetFeasibility operation:
  
• State diagram for Submit operation:
  
• State diagram for GetStatus operation:
  
• The following state diagram is showing possible states of a task together with transitions between them and accompanying notifications. This diagram could serve as a general guideline for SPS developers. However, the specification does not clearly say when notifications should be sent to clients.