Feature Articles

By Neil E. CaterManager, Ocean Instrumentation
School of Ocean Technology
Fisheries and Marine Institute of Memorial University
of Newfoundland
St. John's, Canada

The oceans community is presented with an immediate and challenging opportunity: to define a new generation of ocean sensors. These 'smart' sensors will ultimately be self-initiating as well as remotely monitored and controlled; in a word, autonomous. They will be deployed in networks and will be capable of simultaneous and sequenced measurement across multiple points and multiple networks.

For such sensors to realize their full potential, however, a standard must be fully developed and implemented to allow a smart sensor to physically connect to the backbone of an ocean observing system anywhere in the world and begin operating, automatically and without the need for prior notification or preparation on the part of the host network.

Need for Interoperability
Ocean observing systems provide critical information in support of decision-making, prediction and forecasting, as well as supporting offshore engineering and design activities. In short, these systems enable better understanding of the oceans. Collecting and delivering data in a cost-effective and timely manner is important to its viability and value.

Interest in the oceans, scientific or commercial, has inevitably resulted in a need to move farther afield and to collect more and richer data. These data are often expensive and logistically challenging to collect. Additionally, most data are collected for and suited to a single application, since often when data are shared by other applications or users, cumbersome and expensive translation is required.

However, it only makes good business sense that maximum value be derived from the investment made in collecting data. In order to derive the greatest benefit out of the sensors users deploy for specific purposes, these sensors must be interoperable—they should be able to be easily exploited by a variety of users for a range of purposes.

Sharing or reusing data often requires the development of specialized data interfaces that read data in one format and convert them to meet the requirements of another host system. Particularly in large enterprises, any operations that affect the functioning of the computing environment can be challenging and logistically difficult to implement. Not only does this result in additional up-front cost, but it can also have a recurring life cycle management component.

Sensor interoperability offers a framework that supports the principle of 'collect once, use often.' This standardized environment allows for a 'plug-and-play' life-cycle philosophy where sensors can be added or replaced in the field without the need for reconfiguration upstream in the host system. By establishing a network where there are connections, either dedicated or virtual, between multiple sensors and multiple host observatories, multiple users representing different applications can share sensor resources as well as their cost.

Accomplishing interoperability requires a cooperative effort by all aspects of the ocean observing community, from the manufacturer to the integrator, to the service provider and finally to the end user. Each group has its own perspective on what constitutes interoperability, as well as its particular challenges in achieving it. For the component manufacturer, the challenge may be to standardize a connector with the physical, mechanical and electrical specifications to accommodate all sensors regardless of function, complexity or operating environment. For the developer and the integrator, interoperability will entail implementation of standardized drivers to automatically manage and interpret data from smart ocean sensors regardless of the type of sensor or its application.

Collectively, the challenge is to create a sensor that is designed to allow it to be plugged into the information backbone of an observatory 'out of the box' with the capability to be recognized, accepted and begin operation automatically.

What Makes a Sensor 'Smart'
Fundamentally, a smart sensor must be locatable and uniquely identifiable both remotely and automatically over a communications link. First and foremost, it must be aware that someone or something is out there looking for it. It must also either contain or provide a path to all information necessary to accomplish this. At a minimum, this information includes a UUID, or Universally Unique Identifier, as well as a technical description of the unit, in an agreed standard format.

For true autonomy, this information is contained in an electronic file that physically resides in the instrument's memory. This configuration may not always be desirable or practical, so other methods can be used to accomplish the same functionality. As an example, the technical description of the sensor could also be retrieved from a library of descriptions stored by the host or on the manufacturer's website by referencing the UUID. Regardless of the instrument or the application, this process must use a standard protocol and be self-initiating once a sensor has been located.

While the UUID and data sheets for a sensor must be in a standardized, recognizable format, there is no requirement that all sensors present themselves in the same format. In any case the description must include such basic information as self-identification ('I am Sensor X by Manufacturer Y'), a standard description of data produced by the instrument (data record structure, units of measure, range of operation, etc.) as well as other unit-specific information such as the maintenance record and calibration status. In the case of more sophisticated instruments that are comprised of multiple sensors and carry out more complex measurements, additional information such as configuration instructions and interpretation of results may be necessary.

Finally, the host observatory needs the capability to recognize a smart sensor and to use the correct interface protocol in order to initiate a conversation with it. One key element that must be established is a standard communications protocol residing in the host that can recognize a smart sensor and request and retrieve its UUID, its instrument description and other information as necessary.

For new instruments with onboard memory and digital output, there is the expectation that the instrument will carry enough onboard memory to store all knowledge necessary to ensure plug-and-play operation when deployed. For legacy instruments, in particular those that simply output an analog measurement, the knowledge may be stored in an external device in line with the sensor.

SOSC and OGC
In order to encourage the development and adoption of standard interfaces and protocols that would help achieve interoperability among ocean sensors, the Smart Ocean Sensor Consortium (SOSC), a group of sensor manufacturers and users dedicated to improving the reliability, utility and cost-effectiveness of ocean sensor networks, was created. The SOSC works to promote standardized development of smart ocean sensors that will be integrated onto the world's ocean observatories, collecting data for a wide range of uses in the most efficient way possible.

The SOSC was formed after a group of like-minded developers and end users of ocean sensors entered into discussions that led to the development of a prototype interoperable sensor network. This prototype was first demonstrated at an ocean sensor interoperability workshop held in St. John's in October 2008, sponsored by the Open Geospatial Consortium (OGC).

The OGC was originally created in response to an explosion in the use of geographic information systems (GIS) that led to a wide range of applications developing their own data formats and their own proprietary software for processing, analysis and presentation. The OGC's mandate is to develop and promote the concept of Open GIS, the vision of creating a set of open interface standards to enable diverse geoprocessing systems to share data and communicate directly and efficiently.

The OGC consists of more than 370 commercial, governmental and nonprofit research organizations worldwide.

The PUCK Protocol
Since its inception, the SOSC has been the driving force behind the creation of a specification for interoperable ocean sensors based on a standard defined by The Monterey Bay Aquarium Research Institute (MBARI) known as the PUCK protocol, which operates on the basic premise that all information and instructions required for instrument identification and operation are physically stored in instrument memory.

The PUCK protocol is comprised of a set of simple commands to query an instrument, establish communications and read from and write to the instrument memory. It does not include commands such as those used to 'wake up' an instrument and trigger data acquisition, information which is typically part of the instrument's native command set. Rather, PUCK defines a standard protocol for retrieving information needed to operate the instrument from the device itself.

If a host computer uses the PUCK protocol, it can discover and utilize any PUCK-enabled instrument that it is connected to via a communications port. When the host detects a PUCK-enabled instrument, it uses the protocol to retrieve information from or send instructions to the instrument's resident memory.

PUCK provides a standard way to manage the payload without specifying its format or content; host observatories are free to define payloads that best suit their application.

The protocol augments rather than replaces an instrument's native command set so the instrument can operate in either PUCK mode or in normal instrument mode using the native command set over the same interface.

SOSC determined that the PUCK protocol could be an ideal means of creating interoperable smart ocean sensors. The initial version of the specification that SOSC is actively working to promote is based on serial communications connectivity. This is in order to ensure maximum utility for currently deployed and commercially available instruments, the vast majority of which are equipped with a serial data interface.

The SOSC is now collaborating closely with the OGC to adopt PUCK as an OGC SWE standard. PUCK was presented to the OGC in late 2009, and in 2010 SOSC and OGC signed a formal memorandum of understanding, resolving that both consortia work cooperatively to pursue complementary goals.

Conclusions
SOSC and OGC are currently working together to extend the PUCK protocol to sensors that employ an Ethernet interface. It is predicted that the new paradigm in data collection will be based on the 'Web 2.0' principles of sharing, collaboration and interoperability.

As sensors evolve from the current model to a more distributed one, the power of the Web to move information from its source to those consuming it will cause a shift from centralized sites to direct connections between the source and the end user. Consequently, there will be a greater prevalence of Web-ready sensors directly connected and feeding information. Work is currently ongoing to develop an Ethernet-based PUCK protocol based on the specification for interoperable ocean sensors that has been developed by the SOSC and its collaborators.

Acknowledgments
The author would like to acknowledge the work of the members of the SOSC, in particular Tom O'Reilly from MBARI for his guidance.

Neil E. Cater has worked for 30 years in marine and ocean technology, most recently as manager of the applied research program in ocean instrumentation with the School of Ocean Technology at the Fisheries and Marine Institute of Memorial University of Newfoundland. His primary research interests lie in the area of autonomous or smart ocean sensors, instruments that are self-aware, self-powered, self-initiating and capable of long-term, unattended operation in harsh ocean conditions.

Sea Technology is
read worldwide in more than 110 countries by management, engineers,
scientists and technical personnel working in industry, government
and educational research institutions. Readers are involved with
oceanographic research, fisheries management, offshore oil and gas
exploration and production, undersea defense including antisubmarine
warfare, ocean mining and commercial diving.