OGC PUCK integration prototype

1. OGC PUCK integration prototype • Tom O’Reilly • Monterey Bay Aquarium Research Institute

2. Tasks • Prototype integration of OGC PUCK-enabled instrument with ION (CIDEVSA-441) • Prototype minimum and desired OGC PUCK contents (CIDEVSA-440) • Address requirement L4-CI-SA-RQ-240 • Associated questions: • How to use PUCK? • How to integrate PUCK into ION?

3. 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

4. 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 $$$

5. 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 Consortium

6. Instrument Instrument OGC PUCK Step 1: Host gets instrument info with PUCK commands Step 2: Based on info retrieved in step 1, host issues “native” commands to operate instrument RS232 or Ethernet Datasheet Payload “Native” commands to configure, acquire, etc. Data

7. 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

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

9. 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

10. 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?

11. 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!

12. Approach 2: Use datasheet only, with ION instrument registry PREFERRED • 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

13. ION integration approach • Platform Agent discovers PUCK devices, accesses registry, retrieves and launches appropriate drivers (Link) • ION instrument drivers needn’t be PUCK-aware (launched after finished with PUCK)

14. New instrument ‘X’ User registers new instrument

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

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

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

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

19. 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

20. 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

21. 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

22. 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?

23. 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

24. END

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