SENSOR User Best Practices and Infos

What SENSOR is

• a software to manage sensor metadata

What SENSOR is not

• a warehouse management for sensors
• a laboratory management system
• storage system for sensor or sample data (we have other systems for that)

What is an item?

• item Item is the general term for platforms or devices.
• be Be sure to distinguish between item type and instance of an item.
• several Several platforms of a specific platform type may existg. : Polarstern and Heincke are platforms of platform type ‘vessel’.
• several Several devices of a specific device type may existg. : TM_Ice_Corer_2 and UAF_TM_Ice_Corer_3 are both devices of device type ‘corer’’‘corer'.
• Generally, a platform carries 1-n devices, which in turn can also have their own (sub)devices.

Short names

• catchy abbreviations of your device or platform names
• cannot be modified once they are created! You need to contact sensor@awi.de for help in case you need to change the shortname.
• they are very important, because they are used by linked systems
• you cannot have two devices with the same short name under one parent device
• to avoid naming conflicts, one could use the serial number as a short name suffix (Example: adcp_23984059)

URNs

• URN means Uniform Resource Locator and points to exactly one device
  (Example: vessel:ms_hel:fb_740602 points to the ferrybox on MS Helgoland)
• They consist of "platform type + short name(s)"
• The path to your data is also based on the device / platform URN

Contacts:

• Contacts can have different roles e.g. Editor, Owner, Principal Investigator, etc.
• Make sure to have the following contacts assigned to your device
  1. At least one Editor:
  an
  1. An editor is allowed to modify the device/platform and its sub devices and acts as contact person. The editor may be inherited from the parent device/platform.
  2. At least one Owner:
  1. An Owner is usually the “Institute” owning the device. Select your institute contact from the list of contacts or send a request to o2a-support (at)
   awi
  1. awi.de to do so, if it is not available.
  2. Add Contact person with role 'Principal Investigator' for the device who can either edit the device in SensorWeb or knows who to contact this for.
  3. Add contact “polarstern dship” with role “dship connector” to have devices available in DSHIP
• Note: Contacts with role 'Editor' or 'Data Provider' will have write access on the MOSAiC Central Storage in the respective Device Directory.
• You you want to have more people being able to edit the device, enter them as 'editors'.

Collections:

• Add collection(s) to specify the project in which the sensor is being used. This facilitates the search for sensors used in a certain project and grouping sensors in AWIs data portal (data.awi.de)

Item States:

• Construction:

Seen only by “editor” of this device under “My Devices”

...

and not

...

ready for publication. This status is normally used for initial configuration

• Public:

Seen by everybody (no Login)

Ready for publication

Public devices should not be deleted. (Measured data would loose metadata)

• Store:Device they

Devices that are currently not in use

...

.

Set an item to state 'store' if it is a spare. 

Versioning

• Every time you add an action of type deployment, mount mount, calibration or commissioned, a version of your current sensor configuration is permanently stored.
• All versions get a citation with a persistent identifier (like DOI) and therefore can be referenced in publications
• Because of that deletion They can only be deleted by a system administrator. Deletion of versions is always critical, because we never know, if they are already referenced in other publications
• They can only be deleted by a system administrator
Just think about a version like a data publication
• Enter changes in the order they were done on the device / platform. This is a best practice, because once created versions cannot be modified afterwards.
• Every device should be versioned before first device operation with action type ‚comissioned‘ and label ‚PS122-Leg-No', e.g. "PS122-1" for Leg 1.

Cloning (Copying)

• A device / platform can be duplicated with all of it's attributes. This makes sense in case you have the same device several times for instance with different serial numbers.
• Be sure to enter everything you want to be cloned before cloning

Reassignment (Move device)

• Every reassignment triggers the creation of unmount and mount events in the source and target devices / platforms by default
• Event creation can be switched off, if you don't want this reassignment to be documented for the future

Actions (Events)

• can be entered to provide information about the state your device is in at a specific time e.g. calibration, maintenance, deployed
• Actions of the type deployment, mount, calibration or commissioned can create a citable version of your device.
• Actions are also imported from the DShip ActionLog (see MOSAiC Data Management).Example actions are: Deployment, Recovery, ...
• Action labels can be auto-completed for Polarstern and Heincke journeys
• Please type at least three characters to start auto-completion (Example: "PS1...", "HE4...")
• Actions can be inherited to all sub-devices
  Device / platform statusesA device / platform can be in different statuses such asConstruction
• Not publicly visible
• This status is normally used for initial configuration
• Public
  • Publicly visible
• Store
  • Device / Platform is not in use and may be used by other scientists
• Create other users
  • If you want others to also manage your device / platform, just enter them as editors under the contact tab

Resources: 

• Upload or link to documents containing SOPs, Data Formats, Manuals, Technical documentation 

• We strongly encourage you to use the second choice (link) for documentation that should be published along with your scientific data. Please upload the document to a place with a persistent identifier. AWI people can use the ePIC system and use the corresponding handle.  Others may have the possibility to use your institutional repository, if available.  If not available something like zenodo.org might work.  At the end a DOI would be desirable like doi: https://doi.org/10.1093/gigascience/giz067

Examples

for device structures and relations between devices (platform types with blue font color in the following)

• Remotely operated vehicle ‘Beast’

• Ice Corer ‘TM_Ice_Corer_2’

• Parent devices may have several subdevices which again may have subdevices.

vessel

Polarstern

Weather Station

Barometric Pressure Sensor
Cloud Height Detector
Global Radiation Sensor
Ship Rain Gauge
Sunshine Detector
Temperature and Humidity

Temperature and Humidity Sensor Portside (vessel:polarstern:weather:temperature_and_humidity:temperature_and_humidity_sensor_ps)

Temperature and Humidity Sensor Starbord (vessel:polarstern:weather:temperature_and_humidity:temperature_and_humidity_sensor_sb)

Visibility Sensor
Water temperature for weather station
Wind Sensors (anemometer)

Wind Sensor (Anemometer) Portside

Wind Sensor (Anemometer) Starbord

• example of devices used in combination: CTD used together with devices CTD and Nutrient Analyser
• CTD: vessel:polarstern:ctd_watersampler, with subdevices:
  1. Altimeter: vessel:polarstern:ctd_watersampler:altimeter
  2. Watersampler sbe32: vessel:polarstern:ctd_watersampler:sbe32
  3. Conductivity Sensor sbe4: vessel:polarstern:ctd_watersampler:sbe4
  4. …
• Nutrient Analyser: laboratory:awi-e-2080:iarc_aa3_iarc_rember
• relate run of nutrient analyser to CTD-cast from which water sample was obtained:
  1. create action for nutrient analyser and
  2. add new “Event Relations” of type
“Deployed with”
• 1. “Sample Taken From” and choose CTD for “Related Root Item Urn”
• Remotely operated vehicle ‘Beast’: vehicle:beast
• Icecorer:
  • Used on pack-ice platform called ice_station
  • pack_ice:ice_ps:tm_ice_corer_2
• Snowpits in which density cutter and snow micro pen is used for sampling/measuring
  • pack_ice:parent_snowpit with subdevices
  • Snow Micro Pen: pack_ice:parent_snowpit:slf_smp02
  • Snow density cutter: pack_ice:parent_snowpit:density_cutter01
• Handheld CTD
  • Can be used from multiple platform types, e.g. vessel, pack-ice, small_boat, etc.
  • Use platform “Unassigned Platform” of platform type ‘unassigned’
  • unassigned:unassigned_plattform:handheld_ctd

Ingest of Data for Dashboard

...