I completed my external semester at 52°North on October 2, 2015. During this internship, my task was to gain experience in software development by developing a metadata editor for standarized sensor metadata. Please see my initial blog post for more information. I fulfilled this task by implementing an editor based on the smartEditor project and built a prototype which enables the editing of the metadata language SensorML. This prototype is called SmartSensorEditor. Currently, this editor supports several elements of the SensorML description language.

SensorML distinguishes between four different reference classes: PhysicalSystem, PhysicalComponent, SimpleProcess and AggregateProcess. This distinction is made because, not only the characteristics of one sensor, but also a bundle of sensors or non physical processes can be described with SensorML. A non physical processes is, for example, the calculation of multiple variables which can be sensor data. These calculations can not be referenced to a certain location (such as GPS) in the world. I have implemented the SmartSensorEditor to support the reference class PhysicalSystem. The decision to begin with the PhysicalSystem was based on the research project “NeXOS”, of which 52°North is a member. The project requires that the editor be able to edit this reference class.

In addition, the SmartSensorEditor can execute operations which are provided by the SOS (Sensor Observation Service). The SOS is a platform that stores sensor data and related metadata descriptions. These metadata descriptions, which use the SensorML format, can be loaded from the SOS, edited, and published to the SOS within the SmartSensorEditor. The SmartSensorEditor also has the feature that new sensor descriptions can be inserted completely or deleted. Communication with the SOS is based on the SOAP protocol.

Moreover, the metadata files created can be validated using the rules of SensorML and a part of the rules of the discovery profile. The discovery profile defines several elements and values which are required to query the SensorML metadata files for sensors with specific characteristics. It is important to validate the created files because these files should be processable within other software. Therefore it is necessary that the files conform to a standard format and contain specific elements and values. The validation checks if specific elements exist one or several times, are not empty or have a certain value.

In addition to the SmartSensorEditor, there are a number of editors available which could be used as a basis for the future SensorML editor. The work on the prototype and my experience concerning the extendibility of the editor, i.e. how easy it is and how much time it takes to extend the software help to evaluate whether or not the SmartSensorEditor could be used as a basis for a future SensorML editor.

The following pictures show the different views of the SmartSensorEditor. They describe the workflow for editing sensor data and uploading it to the server.

One of the buttons shown in figure 1 must be clicked to create a new sensor description file. The button “sensor” leads to a completely empty form, whereas the button “acousticSensor” leads to a form containing predefined values for every acoustic sensor of the NeXOS project.

 

A sensor description located in the SOS can be updated or deleted using the tab “Web Dienst”. A token is needed if the SOS expects an authorization token. After the SOS’s URL has been edited, all available procedure ids are listed within the choice box labeled “ProcedureId”. If the sensor description should be loaded in to or deleted from the SOS, it can be done using the choice box “Operation”.

 

Regardless of how the sensor description is loaded from the SOS, i.e. create a new one, edit a local file or create a new sensor description using a database template, the form is the same. The fields with a red border are mandatory fields. The red messages indicates the validation errors. This figure shows the validation of the NEXOS project’s discovery profile.

 

If no validation errors occur, the editor shows this form. The “sweObservableProperty”, “sosObservationType” and “sosFeatureOfInterestType” (not shown hier) fields need to be edited if a completely new sensor description should be uploaded to the SOS. If the service token and the URL were already specified in the “Web Dienst” view (figure 2) then these are inserted automatically into these fields.

The notification in figure 5 appears when the SensorML description has been uploaded successfully, If an error has been sent to the SmartSensorEditor, the log file needs to be checked.

 

The SmartSensorEditor is an OpenSource software and will be available at the 52°North GitHub account.