Ocean Observatories Initiative OOI Cyberinfrastructure Life Cycle Objectives Review January 8-9, 2013 Tom O’Reilly Monterey Bay Aquarium Research Institute OGC PUCK integration prototype 1

OOI Cyberinfrastructure Life Cycle Objectives Review January 8-9, 2013 Tasks Prototype integration of OGC PUCK-enabled instrument with ION (CIDEVSA-441)CIDEVSA-441 Prototype minimum and desired OGC PUCK contents (CIDEVSA-440)CIDEVSA-440 Address requirement L4-CI-SA-RQ-240L4-CI-SA-RQ-240 Associated questions: How to use PUCK? How to integrate PUCK into ION? 2

OOI Cyberinfrastructure Life Cycle Objectives Review January 8-9, 2013 Sensor network configuration management Tracking instrument identity in challenging environments - “What instrument is installed on port X?” - “What instrument produced this data?” - May have lots of instruments, many protocols, multiple platforms Goal: simplify workflows, improve reliability through automation, standardization 3

OOI Cyberinfrastructure Life Cycle Objectives Review January 8-9, 2013 Consequences of misidentified instrument Wrong manufacturer/model – can’t communicate with instrument Wrong serial number - Invalid calibration, mis-matched characteristics, invalid science Costs time and $$$ to correct these Manual bookkeeping costs time and $$$ 4

OOI Cyberinfrastructure Life Cycle Objectives Review January 8-9, 2013 OGC PUCK standard protocol Simplifies, automates instrument installation, configuration, processing workflows Observatory retrieves standard instrument description, other info from device itself, using standard commands Sensor Web Enablement Standard of Open Geospatial ConsortiumOpen Geospatial Consortium 5

OOI Cyberinfrastructure Life Cycle Objectives Review January 8-9, 2013 OGC PUCK 6 Payload RS232 or Ethernet Datasheet Instrument Step 1: Host gets instrument info with PUCK commands “Native” commands to configure, acquire, etc. Data Step 2: Based on info retrieved in step 1, host issues “native” commands to operate instrument Instrument

OOI Cyberinfrastructure Life Cycle Objectives Review January 8-9, 2013 OGC PUCK Implemented in instrument firmware; no special hardware/connectors required Lab and at-sea demonstrations (MBARI, OGC, ESONET...) Endorsed by Smart Ocean Sensors Consortium - Includes Teledyne, Seabird, Nortek, WETLabs, RBR, AXYS - Implemented by four manufacturers; 2-3 weeks to implement 7

OOI Cyberinfrastructure Life Cycle Objectives Review January 8-9, 2013 PUCK memory map 8 Payload Datasheet (96 bytes) PUCK version Datasheet size Manufacturer ID Model ID Version ID Serial # Instrument name Mandatory Read-only, Filled in by manufacturer Optional Read-write, Currently filled in by user only UUID Unrestricted content, format, size (e.g. metadata, driver code) Universally unique ID (128 bits)

OOI Cyberinfrastructure Life Cycle Objectives Review January 8-9, 2013 Tracking instrument ID No PUCK - Must generate system-wide unique ID - Write ID on case; track visually - but beware: Human transcription errors Illegible ID due to biofouling, wear PUCK - Retrieve UUID when instrument powered on, through standard protocol 9

OOI Cyberinfrastructure Life Cycle Objectives Review January 8-9, 2013 OGC PUCK Instrument identifies itself – eliminates/minimizes configuration files, editing, manual steps Enables automatic driver installation UUID can be logged with data to track provenance How to integrate with ION? 10

OOI Cyberinfrastructure Life Cycle Objectives Review January 8-9, 2013 Approach 1: Store ION driver, metadata in PUCK payload Everything needed for basic operation stored in payload OOI must preconfigure payload before deployment Potential versioning issues between payload and observatory infrastructure - Must tightly control interfaces! 11

OOI Cyberinfrastructure Life Cycle Objectives Review January 8-9, 2013 Approach 2: Use datasheet only, with ION instrument registry Use datasheet UUID as index into external instrument registry, which contains metadata, drivers Register new instrument before deployment (one time only) No payload content to manage 12 PREFERRED

OOI Cyberinfrastructure Life Cycle Objectives Review January 8-9, 2013 ION integration approach Platform Agent discovers PUCK devices, accesses registry, retrieves and launches appropriate drivers (Link)Link ION instrument drivers needn’t be PUCK- aware (launched after finished with PUCK) 13

User registers new instrument New instrument ‘X’ 14

ION instrument registry UUID, Manufacturer, Model... ION instrument driver Data format description Calibration coefficients (other characteristics...) New instrument ‘X’ 15 PUCK datasheet

Instrument ‘X ’ Platform agent Scan port ION instrument registry PUCK soft break Port agent 16 Instrument deployment

Get instrument entry for UUID Instrument ‘X ’ Platform agent ION instrument registry UUID Read datasheet, UUID Port agent 17 Instrument deployment

Instrument ‘X ’ Platform agent ION instrument registry UUID 18 Instantiate ION driver from entry Instrument ‘X’ driver Instrument ‘X’ driver configure, acquire data, etc. Port agent Capture UUID to data log Automation works on any platform with access to registry Core functionality implemented in prototype Instrument deployment

OOI Cyberinfrastructure Life Cycle Objectives Review January 8-9, 2013 Knowing which instrument is on which port Non-PUCK instruments - Before deployment, visually confirm manufacturer and serial number on each port (can be many cables in harness) – careful bookkeeping required - After deployment, assume manufacturer/model, issue native command to get serial number (may take multiple guesses!) PUCK instruments - Issue standard PUCK command at any time to get UUID - Can quickly swap instruments - Simpler, faster workflow 19

OOI Cyberinfrastructure Life Cycle Objectives Review January 8-9, 2013 Cost of PUCK PUCK instrument cost - Not yet produced in bulk; hard to answer. But straightforward firmware implementation, no special hardware Observatory software cost - Read, interpret and process datasheet - Straightforward standard protocol - Free open-source tools and libraries 20

OOI Cyberinfrastructure Life Cycle Objectives Review January 8-9, 2013 Next steps Extend ION integration prototype - Working with Hunter, Rueda, French et al to design, implement - Design to “hide” difference between PUCK and non-PUCK instruments 21

OOI Cyberinfrastructure Life Cycle Objectives Review January 8-9, 2013 Further ahead Potentially eliminate need for driver software development - Manufacturer puts standard description of instrument protocol in PUCK payload; e.g. specifies commands to configure, acquire data, etc - Universal driver on platform operates any instrument with protocol descriptor How applicable is this approach? 22

OOI Cyberinfrastructure Life Cycle Objectives Review January 8-9, 2013 OGC PUCK: Summary Automates installation workflow; saves time and $$$ Provides standard datasheet, including universally unique identifier - Potential future uses for PUCK payload Straightforward standard protocol - Instrument manufacturers willing and able - Straightforward integration with observatory 23

OOI Cyberinfrastructure Life Cycle Objectives Review January 8-9, 2013 END 24

25 Merge data, metadata Metadata for UUID Parse data, apply calibration Quality assurance/ control etc... Instrument Instrument UUID + telemetry ‘Downstream’ processing with UUID