1. MBARI’s SSDS Data Management for Ocean Observatories Brian Schlining ブライアン シュリニング

2. Overview About MBARI Overview of MOOS Functional Requirements of SSDS Metadata use by SSDS Dataflow through SSDS

3. Monterey Bay Aquarium Research Institute Established in 1987

4. Santa Cruz Monterey Monterey Canyon MBARI

5. MOOS History Monterey Ocean Observing System 1989: Began mooring-based observations. 1999: Adopted the term “MOOS” (Monterey Ocean Observing System) 1999: Began development of an integrated ocean observatory.

6. MOOS – The Present Concept Benthic Node Mooring Autonomous Underwater Vehicle (AUV) MBARI

7. MOOS – The Present Concept Benthic Node Mooring AUV Mooring ‘Plug and Work’ Instruments

8. Future of Ocean Observing Variety of platforms

9. Data Management Challenges: Large number of data sources Large variety of data sources Dynamic system  Data sources may appear and disappear No standard data format  Data can be instrument ‘native’

10. SSDS Shore-side Data System Data management system for MOOS

11. SSDS – Functional Requirements 1.Capture and store data from MOOS data sources  Includes files and ‘streams’ 2.Capture information (i.e. metadata) about the stored data  Location, instrument, platform, data format, etc. 3.Capture and store data products  Derived products, quality controlled data, plots, etc.

12. SSDS – Functional Requirements 4.Provide access to the original ‘raw’ data 5.Convert data to common formats for user application tools (Excel, Matlab, ARCView, …) 6.Present simple plots of any well-described data. 7.Provide access to data through an application program interface (API) and a web interface.

13. Metadata – What we have learned Metadata must accompany the data –A system’s power relies on good knowledge of its data –Without metadata, the data quickly becomes unusable Metadata must accompany the instrument –Every connector between the two increases error rates –Once data and metadata detached, reattaching is painful Metadata must be flexible and structured –Flexible: you’ll need to define new kinds of data sources –Structured: consistency => automation => value

14. SSDS – Metadata (Object View)

15. ‘Deployment’ information. SSDS tracks: Where the data was collected. When it was collected. What other data was used. Relation to other deployments SSDS – Metadata (Object View)

16. The data source. SSDS tracks: Software or hardware source Unique identifier Manufacturer information References to documentation SSDS – Metadata (Object View)

17. References to the data. SSDS tracks: The data storage location. The deployment that produced this data. SSDS – Metadata (Object View)

18. Format and contents of a DataContainer. SSDS tracks: The contents of a data-set. The data format (To allow parsing by software). SSDS – Metadata (Object View)

19. Why not? Multiple overlapping standards. Which to choose? –None have achieved broad community support –Some are not yet complete (Marine XML) –Excessive documentation requirements (FGDC) May use with SSDS later (Dublin Core) SSDS does not currently use metadata standards such as ESML, ESRI’s Marine Data Model, FGDC, Dublin Core or Marine XML. SSDS – Metadata Standards

20. MooringPortalSSDS Example SIAM to SSDS Data Flow

21. MooringPortalSSDS Device Example SIAM to SSDS Data Flow A device is connected to a platform, such as a Mooring.

22. Mooring PortalSSDSDevice <RecordVariable name="time" columnIndex="1" format="double" longName="Time(GMT)" units="milliseconds since Jan 01, 1970"/> <RecordVariable name="temperature" columnIndex="3" format="double" longName="Seawater temperature" units="degrees C"/> Example SIAM to SSDS Data Flow The mooring retrieves the metadata from the device.

23. PortalSSDSDevice Metadata Packet … Mooring Example SIAM to SSDS Data Flow The metadata is packaged and sent to a portal on shore before any data is sent to shore.

24. Portal SSDSDeviceMooring Example SIAM to SSDS Data Flow Metadata Packet … The portal forwards the metadata to SSDS.

25. PortalDeviceMooring DB SSDS … Example SIAM to SSDS Data Flow SSDS stores the metadata in a database. This allows applications to query for and use data.

26. PortalDeviceMooring DB SSDS Example SIAM to SSDS Data Flow

27. Portal Device Mooring DB SSDS 34,56.234,0.0023,... Example SIAM to SSDS Data Flow The device produces a data record.

28. PortalDeviceMooring DB SSDS Data Packet 34,56.234,0.0023,... Example SIAM to SSDS Data Flow The data is packaged and sent to SSDS.

29. PortalDeviceMooring DB SSDS VersionID, DeviceID, MetadataID, RecordType, PlatformID, SystemTime, SequenceNumber, DataBuffer(34,56.234,0.0023,…) Serialized Example SIAM to SSDS Data Flow SSDS uses information in the packet to sort and store the data in a ‘raw’ format.

30. PortalDeviceMooring DB SSDS netCDF Example SIAM to SSDS Data Flow Serialized VersionID, DeviceID, MetadataID, RecordType, PlatformID, SystemTime, SequenceNumber, DataBuffer(34,56.234,0.0023,…) The ‘raw’ data is parsed and stored as netCDF for easier access.

31. MBARI Software SSDS Software applications allow users to discover and obtain data in formats useful to the typical MBARI user. (netCDF, text, etc.) PortalDeviceMooring DB netCDF Example SIAM to SSDS Data Flow Serialized netcdf parosci { dimensions: time = UNLIMITED ; // (17761 currently) variables: double time(time) ; time:long_name = "Time (GMT)" ; time:units = "seconds since 1970-01-01 00:00:00" ; double depth(time) ; depth:long_name = "depth" ; depth:units = "UNKNOWN" ; // global attributes: :title = "AUV data" ; :created = "2003-06-12T23:34:58Z" ; :history0 = ": Deployment information for parosci.log" ; :deploymentName = "2003.099.10" ; :instrumentId = "3699" ; }

32. PortalDeviceMooring DB SSDS netCDF Example SIAM to SSDS Data Flow Serialized MBARI Software Software applications also provide simple visual representations of data

33. PortalDeviceMooring DB SSDS netCDF Example SIAM to SSDS Data Flow Serialized Web Pages MBARI Software Provide internet access

34. PortalDeviceMooring DB SSDS netCDF Existing netCDF Software Example SIAM to SSDS Data Flow Serialized MBARI Software Web Pages Save development time by using existing software applications

35. Requirements Development 200220032004 MTM AUV CTD MTM II Relational DB Schema Infrastructure & Capabilities Access & Visualization Extreme Week Tools Training MTM Deployed AUV Science Ops Start SSDS Schedule Metadata MOOS ‘Lite’

36. Development Team John Graybeal Kevin Gomes Michael McCann Brian Schlining ( 武頼庵 洲美守 ) Rich Schramm Daniel Wilkin

37. John Ryan Francisco Chavez Ken Johnson Drew Gashler Mark Chaffee Tom O’Reilly Mark Chaffee Science and Technical Advisors Funding provided by the David and Lucile Packard Foundation