Automated metadata/software installation via PUCK protocol
This task will demonstrate automated retrieval and installation of 1451 and/or SWE components for instruments that implement PUCK protocol.
Goal
This task will demonstrate automated retrieval and installation of IEEE-1451 and/or SWE components for instruments that implement PUCK protocol. Retrieved components may include IEEE1451 TEDS, SensorML document, and instrument "driver" software to be installed on the instrument "host" computer (aka Network Capable Application Processor or "NCAP").
You can find the specification for PUCK v1.3 here.
Participants
Tom O'Reilly (MBARI)
Antoni Manuel, Joaquin Del Rio (UPC-SARTI)
Eric Delory (dbScale)
Christoph Waldmann, Jesper Zedlitz (University of Bremen, Christian Albrechts University at Kiel)
Neil Cater, Eric Davis (Marine Institute at Memorial University of St Johns)
Klaus Schleisiek (SEND Electronics GmbH)
Project description
PUCK protocol enables "plug-and-work" instruments, meaning that when the instrument is physically plugged into an observatory port, the observatory automatically determines the instrument identity and reconfigures itself to accommodate the new instrument and its data stream. This automation eliminates time-consuming and error-prone manual configuration steps. PUCK enables plug-and-work functionality through the following protocol features:
- The PUCK instrument data sheet includes a universal unique serial number (UUID) for the instrument, as well as manufacturer code, model code, model name. All PUCK implementations include the instrument data sheet. The observatory can utilize the UUID to retrieve instrument driver code and metadata from an external source (e.g. a database)
- The PUCK payload area is optional, and can be used to store instrument driver code and metadata. Most manufacturers implement the payload (except for WETLabs). The observatory can retrieve payload contents, then execute the retrieved driver code and append the retrieved metadata to the instrument telemetry stream. For this demonstration, payload will include appropriate driver code for the target observatory, SensorML document, and/or TEDS metadata.
The following test-bed observatories will participate in demonstration of this topic:
- MBARI: MBARI "SIAM" middleware recognizes PUCK protocol. SIAM-1451 has already demonstrated automated installation of 1451-compatible driver code and 1451 TEDS metadata. Most of the test-bed hardware is located in MBARI lab; it might be possible to utilize the SBE-37SM instrument currently deployed on MARS.
- UPC-SARTI: We will modify the UPC-SARTI software to recognize and utilize PUCK-enabled instruments. Note that the UPC-SARTI NCAP is implemented by the IMSYS SNAP microprocessor, running J2ME. Existing MBARI PUCK utility software may require modification to use the appropriate serial communication interfaces implemented by the IMSYS. In-lab test-bed only, or can we deploy a PUCK implementation on OBSEA?
- Marine Institute at Memorial University: RBR Ltd will supply a PUCK-aware mooring controller and PUCK-enabled instruments. In addition Axys will make their Watchman PUCK-aware; we plan to exchange instruments between the two controllers, demonstrating observatory-interoperability. In-lab test-bed only or can we deploy at-sea?
- MARUM, Bremen University: We'll modify the existing MARUM 1451.0 test-bed observatory software to utlize PUCK protocol.
Prerequisites
Each observatory must implement interfaces to either OGC-SWE or IEEE-1451.0. IEEE-1451.0 observatories must comply with the minimal IEEE-1451/OGC-SWE/PUCK demonstration interface specification , and must register with an appropriate IEEE-1451 STWS.
Each observatory must obtain one or more instruments that implement PUCK protocol.
The following PUCK protocol implementations are currently available:
- Seabird SBE-37SM
- Seabird SBE-16+
- Nortek Aquadopp
- RBR Ltd XR-420
- WETLabs Triplet
- MBARI external PUCK prototype (not deployable at sea)
- UPC-SARTI external PUCK(?)
Proposed OSIE-2 PUCK report template
Related topics
This topic is related to the IEEE-1451/SWE harmonization in that several of the test-bed observatories implement the IEEE-1451.0 interface. This topic is related to instrument control, since the driver retrieved from the PUCK could implement instrument control methods.
Notes
OSIE-2 PUCK telecon notes: 5/5/2009
OSIE-2 PUCK telecon notes: 6/2/2009
OSIE-2 PUCK telecon notes: 6/9/2009
OSIE-2 PUCK telecon notes: 6/16/2009
OSIE-2 PUCK telecon notes: 6/30/2009
Proposed external PUCK hardware change (Kent Headley)
Host port state transition diagram (version 1)
OSIE-2 PUCK telecon notes: 7/14/2009
OSIE-2 PUCK telecon notes: 7/21/2009
OSIE-2 PUCK telecon notes: 8/25/2009
OSIE-2 PUCK telecon notes: 9/9/2009


This is a test comment