“The true value of the expenditure required to collect oceanographic data is found in the accuracy and the reliability of these data. The determination of the true accuracy of oceanographic information is becoming a complex problem where standard techniques of calibration are needed. In regard to standardization; it will come! The scope of the oceanographic program will demand a wide variety of proven, readily available instruments. There will be better interchange between laboratories in order to arrive at agreements on specifications which will suit the majority of their needs. This same cooperation between laboratories will result in a wider knowledge of the ideas that were tried and failed. Intercalibration will be practiced on a routine basis and all users of oceanographic data from cooperating laboratories will be assured of the quality control of these data.”

What you just read has been extracted from a keynote address by Gilbert Jaffe [1] presented at the Fourth National ISA Marine Science Instrumentation Symposium in 1968! Where are we as a community standing now, 52 years after these statements have been made? Sure enough, significant progress has been made resulting from pressures that came from global observing programs such as WOCE [2], CLIVAR [3], ARGO [4], GOOS [5] and others.

It seems that the developed best practices are mostly serving the needs of individual observing programs, and that a clear resistance can be felt in regard to harmonizing those practices across different programs. However, with the introduction of the UN Sustainable Development Goals (figure 1) a clear need for standards to allow for the comparability of ocean observations appear to be obvious.

Figure 1: Standards contribute to the development of the UN Sustainable Development Goals, in this case 9 and 14.

Only a handful of ISO standards has been developed during the past years (ISO 17208, 18405, 18406, ISO/IEC 30140 and ISO 22013, 21851). Standards like OGC® PUCK Protocol Standard [11], although being developed with a clear application scenario in mind, have not been adopted to a degree that one would have hoped for. What are the obstacles that hinder the introduction of standards and harmonized best practices in marine sciences although these advantages appear obvious? Resolving this issue will be a task that with  the highest priority in the work of the newly established OES Standing Committee of Standards.

We first note that there are obvious advantages to using standards:

• Interchangeability: User is not locked to a specific vendor and can use any component that implements the standard.
• Interoperability: System components can communicate through standard APIs, and exchange data in standard formats.
• Economy: Standards can reduce software development cost, as open-source standard implementations are frequently available.
• Shareability: Open-source systems that are standards based may be more likely to be adopted by others.

 However, there are some challenges to using standards:

• Some standards may have startup cost and “overhead” in the form of software development or operations costs; these may be more significant for small-scale systems.
• Standards may become obsolete with technology advances; for example, the SOAP internet protocol is no longer widely used for new systems, which use more modern compact protocols such as JSON.
• Manufacturers may see financial advantages to proprietary protocols and formats, and may be reluctant to adopt standards.

We can say that a “good” standard is one where advantages outweigh the drawbacks.  The OES Standing Committee of Standards will examine these criteria in some detail. A prerequisite for the development and successful introduction of standards and standard operating procedures is the broad acceptance by the ocean science community. To that purpose, those standards should meet real user needs with sufficient efficiency and reliability, and should be at least as easy to use as non-standard solutions while being reasonably cheap. The involvement of sensor manufacturers in the standards development process is also crucial as they must actually implement the standard in their devices. From a manufacturer standpoint, the standard specification should be concise, realistic, straightforward and economical to implement. The standard should also address actual market demand and should not inhibit the manufacturer’s valuable proprietary features. In other words, will users actually want to buy the sensor that implements the standard? The OES Standing Committee of Standards will engage manufacturers to address this question. The committee will also draw on member experience to determine why some standards such as OGC PUCK have not yet gained wide acceptance; we expect these “lessons learned” to be invaluable.

In particular, OGC PUCK [11] helps to address these user needs:

Figure 2: Fleets of autonomous oceanographic vehicles and sensors together with crewed ships and satellites track and sample ocean features in a coordinated way, as part of MBARI’s CANON project. Illustration by David Fierstein © 2011 MBARI [12]

• Simplify the sensor integration process (plug-and-work).
• Reliably provide instrument characteristics and other metadata to observing systems

But PUCK is not a complete solution to these user needs. The PUCK standard provides sensor “payload” memory on the device and a protocol to store and retrieve the payload contents, but does not define the content. And while PUCK defines the payload retrieval protocol, it does not implement it - so the user or another party must define payload content, must implement payload retrieval software, and must define how the host utilizes the payload content. For example, instrument driver code itself might be stored in PUCK payload, retrieved and run on the host. Or a “generic driver” might be installed beforehand on the host, and then parameterized from a sensor description retrieved from the sensor payload. In any case PUCK only partly solves the sensor integration challenge, and many users may find it easier to continue using the “manual” configuration process, especially for smaller systems.

As a matter of fact, the committee can build on the achievements that have been reached during the past years. First of all, the QARTOD [6] program initiated by NOAA should be mentioned, which has established a robust process of developing and revising manuals for individual measurement parameters. Another example is the IODE Ocean Best Practices System, set up with help of OES.  [7].

Looking to the near future, we see that oceanographic systems are increasingly dominated by robotic sensor platforms both underwater, on the surface and in the air.  For example, MBARI’s CANON field campaigns deploy such platforms to collect physical, chemical and biological data. These data are combined with satellite imagery to reveal ecosystem details of Monterey Bay [8] (Figure 2).  As our science hypotheses become more sophisticated, data acquisition by these platforms must often be coordinated. For example, an AUV may need to collect biomass acoustic data near the same time and place that a Wave Glider collects genomic data. Today this coordination requires careful time-consuming manual effort, and could benefit from automation, but there are currently few standards to describe such coordination. However, we are now seeing the emergence of standards such as OGC Sensor Things [8] to address autonomous data collection and even coordination between multiple robots linked by wireless networks. The OES committee will engage with other entities such as the OGC’s Marine and UxS (autonomous vehicles) Domain Working Groups [9,10] to further explore these standards.

References

• [1] Jaffe, Gilbert, Keynote Address, Oceanographic Instrumentation - Past, Present, And Future, Proceedings of the Fourth National ISA Marine Science Instrumentation Symposium, January 22-26, 1968, Cocoa Beach, Florida
• [2] https://en.wikipedia.org/wiki/World_Ocean_Circulation_Experiment
• [3] https://www.clivar.org
• [4] https://argo.ucsd.edu
• [5] https://goosocean.org
• [6] https://ioos.noaa.gov/project/qartod/
• [7] https://www.oceanbestpractices.org
• [8] https://www.ogc.org/standards/sensorthings
• [9] https://www.ogc.org/projects/groups/marinedwg
• [10] https://www.ogc.org/projects/groups/uxsdwg
• [11] https://www3.mbari.org/pw/
• [12] https://www.mbari.org/science/upper-ocean-systems/canon/