OGC PUCK is an Open Geospatial Consortium Sensor Web Enablement standard. PUCK defines a protocol at the device level to retrieve descriptive information from PUCK-enabled instruments. At a minimum, this information includes a 96-byte "PUCK datasheet" that specifies the instrument manufacturer, model, and a universally unique identifier (UUID) for the instrument. A PUCK-enabled instrument may also provide an arbitrary payload within its "PUCK memory" space. This optional payload can be any additional information needed to operate the instrument and interpret its data, e.g. a standardized description of the instrument and its protocol, or even driver code that can operate the instrument. A host computer that understands PUCK protocol can automatically retrieve and utilize this information from the instrument when the device is installed, minimizing the manual steps otherwise required for installing the instrument in the network. For example, a SensorML document and instrument driver code can be physically stored in the instrument's PUCK memory before deployment. When the instrument is deployed, a host controller can retrieve the driver code and SensorML, execute the driver code, and add the SensorML to the instrument's telemetry stream.
PUCK protocol is defined over RS-232 and Ethernet physical/electrical interfaces. You can download the PUCK v1.4 specification.
Note that OGC PUCK does not require the use of other SWE standards, although it does complement them.
Some demonstrations and oceanographic use scenarios for PUCK are described in the OGC Ocean Science Interoperability Experiment 2 technical report. A demonstration of PUCK for Ethernet instruments is available on YouTube.
PUCK protocol is currently implemented by the following manufacturers:
- RBR Ltd
These and other instrument manufacturers support instrument interface standards through membership in the Smart Ocean Sensors Consortium (SOSC).
In the following use scenarios and diagrams, we define several components:
- Instrument driver: software that communicates with physical instrument with PUCK protocol and "native" instrument protocol over a communication interface (e.g. RS-232, Ethernet/IP)
- Instrument host: computer that hosts instrument driver(s)
- Instrument manager: software that runs on instrument host; responsible for determining which driver and metadata to associate with an instrument on a specific port.
- Instrument registry: database containing information associated with each observatory instrument, e.g. manufacturer, model, serial number, applicable driver, contact person etc.
Use of PUCK payload is optional, with advantages and disadvantages, as described in the following use scenarios.
Scenario A-1: Instrument host uses PUCK datasheet information to retrieve driver and metadata from single "master" instrument registry.
Advantages: No need to update PUCK payload if instrument metadata/driver change. Single "master" instrument registry; no duplication/synching needed.
Disadvantage: Requires network connection between instrument host and external instrument registry.
Scenario A-2: Instrument uses PUCK datasheet information to retrieve driver and metadata from instrument registry.
Advantages: No need to update PUCK payload if instrument metadata/driver change. No network needed to connect instrument manager with registry.
Disadvantages: Must ensure that onboard registry contains entry for any instrument that may be installed on instrument host. Likely must duplicate entries from permanent shore registry.
Scenario B: Instrument host retrieves driver and metadata from PUCK payload. In this case, all information needed by the instrument manager to install and operate the instrument is retrieved from PUCK payload, including driver code and/or configuration information (e.g. in a SensorML document).
Advantage: Does not require separate instrument registry or network connection to shore
Disadvantage: Presumably the observatory does have a shore-side instrument registry somewhere; the information stored in the PUCK payload is almost certainly duplicated within the registry, and thus the two (payload and registry) must be kept in synch. Payload is an optional feature, thus registry access (onboard or external) is required for some instruments.