You are viewing an old version of this page. View the current version.

Compare with Current View Page History

« Previous Version 6 Next »


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 is the general term for platforms or devices
    • be sure to distinguish between item type and instance of an item
    • several platforms of a specific platform type may exist
      • g. Polarstern and Heincke are platforms of platform type ‘vessel’
    • several devices of a specific device type may exist
      • g. TM_Ice_Corer_2 and UAF_TM_Ice_Corer_3 are both devices of device type ‘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!
    • 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
      • At least one Editor: 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
      • At least one Owner:
        • “Institute” owning the device. Select your institute contact from the list of contacts or send a request to o2a-support (at) awi.de to do so, if it is not available
      • 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.
      • 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


  • 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)


  • Versioning
    • Every time you add an action of type deployment, 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 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 ‚MOSAiC 122/Leg-No.‘


  • Cloning (Copying)
    • A device / platform can be duplicated with all of it's attributes
    • 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)
    • 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 statuses
    • A device / platform can be in different statuses such as
      • Construction
        • 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 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)
    • CTD and Nutrient Analyser
      • CTD: vessel:polarstern:ctd_watersampler, with subdevices:
        • Altimeter: vessel:polarstern:ctd_watersampler:altimeter
        • Watersampler sbe32: vessel:polarstern:ctd_watersampler:sbe32
        • Conductivity Sensor sbe4: vessel:polarstern:ctd_watersampler:sbe4
        • …
      • Nutrient Analyser: laboratory:awi-e-2080:iarc_aa3_iarc_rember
      • relate run of nutrient analyser to CTD-cast from which water sample was obtained:
        • create action for nutrient analyser and
        • add new “Event Relations” of type “Deployed with” 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


How do I display measured data in the dashboard?

There are three ways to pick up data automatically:

  • SMB (Windows Share)
  • FTP
  • E-Mail

Raw data requires a driver that converts the data to an NRT data file.
These scripts can be written in Python, Matlab or BASH-Shell.
These scripts can be deposited with our service and are automatically applied to every download. However, it is also possible to send an NRT data file directly, the description of an NRT data file follows on the next page. If the data is available in the NRT-Database, it can be used immediately in the dashboard.

How can I create a dashboard?

You need an account for SENSOR.awi.de
With this account you can also log in at DASHBOARD.awi.de.
With DASHBOARD.awi.de you can create your own dashboards. The data from the NRT-Database can be mapped into diagrams. There are five chart types available line chart, bar chart, stacked bar chart, scatter plot, box plot
All public dashboards can be found on the home page (if you are not logged in)

Description of an NRT-Datafile

The NRT-Datafile serves an interface between your own file format and the NRT-Database-Import-Software InsertDB. If measurement data is to be written to the NRT database, it must be provided in the format described below.

Construction:

Header row with Sensor-IDs and physical Unit

Time t with measured value

Time t+1 with measured value

Time t+n with measured value


Description of a Header row:

Timestamp and the sensor IDs are required in the header line, timestamp with time and the sensor URNs in the form platform:device:sensor. Blanks are replaced by underscore (_) in the device and sensor parts. Otherwise only alphanumeric characters are allowed. You see your sensor URN under the Parameters Tab, hover on a short name of a Parameter.  The separator between the timestamp and the sensor IDs is a semicolon. The physical Units are placed in square brackets and is optional.
Example:

time; vessel:polarstern:ctd964:pressure[hPa]; vessel:polarstern:ctd964:temperature[°C]

Description of measurement data line(s)

The time is given in UTC, so no local time or even summer time! The separator in the timestamp between Date and Time is either a T or a blank. The specification of milliseconds is optional.

YYYY-MM-DD hh:mm:ss[.mmm]

YYYY-MM-DDThh:mm:ss[.mmm]


The timestamp as well as the measured values ​​are also to be separated with semicolon. The decimal separator is a point.

Example:

2016-04-21 16:50:30;1004.0;22.5

 

Example of an NRT-Datafile


time; vessel:polarstern:ctd964:pressure[hPa]; vessel:polarstern:ctd964:temperature[°C]

2016-04-21 16:50:30;1004.0;22.5

2016-04-21 17:00:30;1003.0;22.4

or

time; vessel:polarstern:ctd964:pressure[hPa]; vessel:polarstern:ctd964:temperature[°C]

2016-04-21T16:50:30;1004.0;22.5

2016-04-21T17:00:30;1003.0;22.4

  • No labels